2011/12/7 Graeme Geldenhuys graemeg.li...@gmail.com:
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.
Am 09.12.2011 09:02, schrieb Vincent Snijders:
2011/12/7 Graeme Geldenhuys graemeg.li...@gmail.com:
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
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.
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
graemeg.li...@gmail.com 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
- Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com schreef:
On Fri, Dec 9, 2011 at 9:39 AM, Graeme Geldenhuys
graemeg.li...@gmail.com 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
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
- Graeme Geldenhuys graemeg.li...@gmail.com 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
On Fri, 09 Dec 2011 09:19:53 +0100, Florian Klaempfl flor...@freepascal.org
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
- Virgo Pärna virgo.pa...@mail.ee schreef:
On Fri, 09 Dec 2011 09:19:53 +0100, Florian Klaempfl
flor...@freepascal.org 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
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(screenheight)]:=
On Fri, 09 Dec 2011 07:27:46 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de 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
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
Thanks Michael,
I'll try that!
Thierry
- Mail Original -
De: Michael Van Canneyt mich...@freepascal.org
À: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Envoyé: Vendredi 9 Décembre 2011 16h57:47 GMT +01:00 Amsterdam / Berlin / Berne
/ Rome / Stockholm / Vienne
Objet: Re:
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: THandleStream;
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 Random()
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 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
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 mich...@freepascal.org
À: FPC-Pascal
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
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.
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
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).
2011/5/1 Johann Glaser johann.gla...@gmx.at:
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
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 mich...@freepascal.org:
On Fri, 9 Dec 2011, Jorge Aldo G.
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 machines, then something
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;
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
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 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 :=
On Thu, 08 Dec 2011 10:52:01 +0100, Graeme Geldenhuys
graemeg.li...@gmail.com 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
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
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
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
On Fri, Apr 29, 2011 at 10:18 PM, Johann Glaser johann.gla...@gmx.at 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
34 matches
Mail list logo
