On Fri, Apr 29, 2011 at 10:18 PM, Johann Glaser wrote:
> Hi!
>
> I want to equip a program with a command line and therefore want a
> powerful and user-friendly input prompt. Currently I use
> ReadLn(CmdLine);
> which is not as user-friendly as desired. :-)
>
> The usual answer for this question
On 12/9/2011 9:44 AM, tcoq wrote:
Hello,
I'm trying to poll the input stream to see whether there is a new character
available, without blocking my software.
Maybe TInputPipeStream.NumBytesAvailable can help. You can find it in
the documentation of the Pipes unit.
I tried an experiment to m
On 9 December 2011 20:54, wrote:
> In europe electricity is sometimes 220 volts. Twice as fast as 110 volts
> in Canada, but I'm not sure about africa ;-)
:-) South Africa uses 220 volts too.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform F
On 9 December 2011 19:55, Jorge Aldo G. de F. Junior wrote:
> Well, lets go to theory :
In case you didn't notice the unit name this code comes from
tiEncryptSimple.pas
The name should be a good enough hint that it wasn't meant for
real-world apps. ;-) For real-world apps, tiOPF has other en
On Thu, 08 Dec 2011 10:52:01 +0100, Graeme Geldenhuys
wrote:
On 8 December 2011 11:33, Henry Vermaak wrote:
I agree, quality first.
I would normally agree with that. But such huge magnitudes slower
(20ms vs 10585ms) on a new Quad-Core type system? That just seems a
bit excessive, and con
On Fri, 9 Dec 2011, tcoq wrote:
I have found and tried WaitForSingleObject, using the following syntax:
ThereIsACharacterToRead := WaitForSingleObject(StdInputHandle,0) = 0;
While ThereIsACharacterToRead do
begin
aByte := InputStream.ReadByte;
ThereIsACharacterToRead := WaitForSingleObj
On Fri, 9 Dec 2011, Jorge Aldo G. de F. Junior wrote:
I think the main problem is that TStream tries to abstract two kinds
of resources :
Character based resources and block based resources. The end result is
that it is no good for neither of the two cases.
You are not forced to use it :-)
On 09 Dec 2011, at 19:37, nore...@z505.com wrote:
> See what happened to common lisp clisp when they used it. Had to change
> license to GPL even though they didn't want to.
They changed the license because they didn't want to stop using GNU
libreadline. If they had switched to a BSD-licensed l
I have found and tried WaitForSingleObject, using the following syntax:
ThereIsACharacterToRead := WaitForSingleObject(StdInputHandle,0) = 0;
While ThereIsACharacterToRead do
begin
aByte := InputStream.ReadByte;
ThereIsACharacterToRead := WaitForSingleObject(StdInputHandle,0) = 0;
end;
Ho
> On 9 December 2011 09:47, Florian Klaempfl wrote:
>>
>> According to measurements of me and other peoples, random is only 7-10
>> times slower (depending on the CPU).
>
> What do you feed your computer, because mine differs vastly from yours.
>
In europe electricity is sometimes 220 volts. Twice
> On 28.11.2011 21:25, nore...@z505.com wrote:
>>> Am 14.11.2011 02:32, schrieb nore...@z505.com:
First I thought I would post this to the mailing list to ask you what
the
proper way to program with threads is. If we must call closethread on
MS
Win machines but not unix mac
I think the main problem is that TStream tries to abstract two kinds
of resources :
Character based resources and block based resources. The end result is
that it is no good for neither of the two cases.
2011/12/9 Michael Van Canneyt :
>
>
> On Fri, 9 Dec 2011, Jorge Aldo G. de F. Junior wrote:
>
> 2011/5/1 Johann Glaser :
>
>> If you find any improvements or comments don't hesitate to send me an
>> EMail.
>
> I just used it. I only needed readline() and add_history(), these two
> functions are already enough to make a ReadLn() substitute that really
> works and It works like a charm! Thank
On Fri, 9 Dec 2011, Jorge Aldo G. de F. Junior wrote:
Thats an old problem on the way TStream was implemented.
I for one needed to know the result size of a uncompress stream (IE.:
i have a compressed stream and want to know in advance how many bytes
the uncompress method would yield).
This
even if FPC implemented a ultra high tech PRNG it would be compatible
with DELPHI :
1 - Delphi asserts that you should not use the Random function to
encryption porpuses.
2 - Delphi asserts no speed guarantees.
3 - Delphi asserts no randomness quality guarantees.
IE : to be compatible you only ne
Well, lets go to theory :
One way to build a cypher is to XOR the stream that must be encrypted
against a fixed value.
But, this is easy to break using statistical methods.
So the next logical way to do this is to XOR the stream against
another stream of numbers, kind of one time password.
But,
Thats an old problem on the way TStream was implemented.
I for one needed to know the result size of a uncompress stream (IE.:
i have a compressed stream and want to know in advance how many bytes
the uncompress method would yield).
The stream system is currently a mess, sometimes you can know in
On windows, I did not find WaitForSingleObject, which is actually going to wait
for the file.
However I found ReadFileEx in the Windows API, which is an asynchronous read on
the file. I'll try using that.
- Mail Original -
De: "Michael Van Canneyt"
À: "FPC-Pascal users discussions"
Env
On 9 December 2011 12:50, Dimitri Smits wrote:
>
> I actually doubt that that codesnippet does any real encryption.
It isn't. The sample code / test program I posted is just a snippet of
the actual unit. No point in posting the whole unit here, just to
point out that a single section of code in o
On 9 December 2011 12:42, Jonas Maebe > wrote:
>
> It will improve the randomness of the generated numbers.
Thanks Jonas.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
On 9 December 2011 15:51, Reimar Grabowski wrote:
>knowledge to back up your statements. Next time please take the time to
>identify the problem >correctly before jumping to conclusions.
> No offense ment.
No offense take. Two unknown (to most) facts came out of this
discussion. 1) the FPC Rando
In our previous episode, Michael Van Canneyt said:
> > Is there a way to ask whether the input stream is not empty, without
> > waiting and without using threads/processes?
> > And, in addition, is there an OS-independent way (linux, windows)?
> >
> > something like:
> > var
> > inputStream: THan
Thanks Michael,
I'll try that!
Thierry
- Mail Original -
De: "Michael Van Canneyt"
À: "FPC-Pascal users discussions"
Envoyé: Vendredi 9 Décembre 2011 16h57:47 GMT +01:00 Amsterdam / Berlin / Berne
/ Rome / Stockholm / Vienne
Objet: Re: [fpc-pascal] How to poll for a byte in Input?
...
Y
On Fri, 9 Dec 2011, tcoq wrote:
Hello,
I'm trying to poll the input stream to see whether there is a new character
available, without blocking my software.
I've tried "Read" and "THandleStream.ReadByte" but with no success: when the
input is empty, the program just waits.
Is there a way to
Hello,
I'm trying to poll the input stream to see whether there is a new character
available, without blocking my software.
I've tried "Read" and "THandleStream.ReadByte" but with no success: when the
input is empty, the program just waits.
Is there a way to ask whether the input stream is not e
On Fri, 9 Dec 2011 10:47:15 +0200
Graeme Geldenhuys wrote:
> Like I said, I didn't write that code, and I don't specialise in
> encryption algorithms.
That's not your fault. Your fault was to not identify the problem correctly but
blame FPCs implementation and later rant about "double standards"
In our previous episode, Reimar Grabowski said:
> Like people already said, lots of talk about a 'problem' that 10 years noone
> has seen as one.
(it's afaik not the first. Has been noticed once or twice before. But those
people used it in unittests, and simply changed without much ado when the
p
On Fri, 09 Dec 2011 07:27:46 +0100
Jürgen Hestermann wrote:
>
>
> Reimar Grabowski schrieb:
> > The parameter should default to FALSE to not break existing code relying on
> > FPCs random function
> And what about existing code coming from Delphi/Turbo Pascal? This was a
> strong argument in
In our previous episode, Dimitri Smits said:
>
> Randomize() is supposed to be called only once to seed the generator with an
> initial value.
>
> If you made it something like so:
>
> begin
> for i := 0 to 1000 do
> begin
> randomize();
> pixel[random(screenwidth),random(screenhei
- "Virgo Pärna" schreef:
> On Fri, 09 Dec 2011 09:19:53 +0100, Florian Klaempfl
> wrote:
> >
> > Oops, mails crossed. The assignment to randseed is indeed the
> problem.
> > Why is it done? Bad random generator of delphi :)?
> >
>
> I don't know, how bad Delphis random generator is, bu
On Fri, 09 Dec 2011 09:19:53 +0100, Florian Klaempfl
wrote:
>
> Oops, mails crossed. The assignment to randseed is indeed the problem.
> Why is it done? Bad random generator of delphi :)?
>
I don't know, how bad Delphis random generator is, but I once years ago did
make a mistake
of callin
- "Graeme Geldenhuys" schreef:
> On 9 December 2011 10:42, Felipe Monteiro de Carvalho wrote:
> >
> > It is specifically written in the Delphi documentation that Random
> > should not be utilized for encryption...
>
> Delphi documentation mentions a lot of things you mustn't do... Does
> t
On 09 Dec 2011, at 09:39, Graeme Geldenhuys wrote:
Looking at the code again, I have no idea how it will affect the
encryption algorithm if I move the assignment to RandSeed outside the
loop
It will improve the randomness of the generated numbers. Changing the
random seed all the time remov
- "Felipe Monteiro de Carvalho" schreef:
> On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
> wrote:
> > I didn't write this encryption code, I merely debugged why the unit
> > tests for this unit took so long to complete, compared to under
> > Delphi.
>
> It is specifically written in th
On 9 December 2011 10:42, Felipe Monteiro de Carvalho wrote:
>
> It is specifically written in the Delphi documentation that Random
> should not be utilized for encryption...
Delphi documentation mentions a lot of things you mustn't do... Does
that stop anybody. ;-)
Like I said, I didn't write th
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
wrote:
> I didn't write this encryption code, I merely debugged why the unit
> tests for this unit took so long to complete, compared to under
> Delphi.
It is specifically written in the Delphi documentation that Random
should not be utilized for
On 9 December 2011 10:02, Vincent Snijders wrote:
>
> I have one question about this code, why is RandSeed set inside the
> loop and not outside the loop or even at the program start?
For the full code as used by tiOPF, see the following URL.
http://tiopf.svn.sourceforge.net/viewvc/tiopf/tiOPF
Am 09.12.2011 09:02, schrieb Vincent Snijders:
> 2011/12/7 Graeme Geldenhuys :
>> Hi,
>>
>> I did a simple GetTickCount() timing around this loop. Delphi executes
>> the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
>> loop runs 200400 iterations. The types for BitValue, ByteValue
Am 09.12.2011 08:59, schrieb Graeme Geldenhuys:
> On 9 December 2011 09:47, Florian Klaempfl wrote:
>>
>> According to measurements of me and other peoples, random is only 7-10
>> times slower (depending on the CPU).
>
> What do you feed your computer,
Nothing, but I don't mess with things I don
On 9 December 2011 09:55, Vincent Snijders wrote:
> Can you compile the fpc version for 32 bits (may make some difference)
> and run it on windows (probably make no difference) to reduce the
> differences in platform when you compare with Delphi?
---FPC 2.4.5 (r17953 from fix
2011/12/7 Graeme Geldenhuys :
> Hi,
>
> I did a simple GetTickCount() timing around this loop. Delphi executes
> the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
> loop runs 200400 iterations. The types for BitValue, ByteValue and
> RandSeed is of type Byte.
>
> 01 for Index :=
41 matches
Mail list logo
