Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Michael Van Canneyt
On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): On Sat, 10 Dec 2005, darekM wrote: Hi I've tested some of benchmark on http://shootout.alioth.debian.org/ I've see that reverse-complement benchmark

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Marco van de Voort
> On Sun, 11 Dec 2005, darekM wrote: > > But why it is in separated unit, nobody know about it (or to few). F.e. > > Lazarus has own implementation of buffering. Lazarus had to do a long time with FPC 1.0.x _and_ 2.0.x. Not all artefacts of that transition are already banned. > > If we want to

[fpc-devel] Search for existing bugs

2005-12-12 Thread Graeme Geldenhuys
Peter Vreman wrote: Please report bugs and incompatibilities in the bug repository with complete source codes to reproduce. Reports mailed to the mailinglist tend to be forgotten. Will do! Is there a way to search for bugs without having to list all known bugs first. It take quite long to lo

Re: [fpc-devel] Search for existing bugs

2005-12-12 Thread Daniël Mantione
Op Mon, 12 Dec 2005, schreef Graeme Geldenhuys: > Peter Vreman wrote: > > Please report bugs and incompatibilities in the bug repository with > > complete source codes to reproduce. Reports mailed to the mailinglist > > tend > > to be forgotten. > > Will do! Is there a way to search for bugs w

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread darekM
Michael Van Canneyt napisał(a): On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): Why not descend. Why not exceed tFileStream, its natural. I want read text file in the same way like binary file. Because then you must also descend THandlestream, TPipeStream, TIOStream, TD

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread darekM
Marco van de Voort napisał(a): On Sun, 11 Dec 2005, darekM wrote: But why it is in separated unit, nobody know about it (or to few). F.e. Lazarus has own implementation of buffering. Lazarus had to do a long time with FPC 1.0.x _and_ 2.0.x. Not all artefacts of that transiti

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Michael Van Canneyt
On Mon, 12 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): Why not descend. Why not exceed tFileStream, its natural. I want read text file in the same way like binary file. Because then you must also descend THa

Re: [fpc-devel] Access Violation with nested DLL's compiled byFPC(andsome more info on bug #4538)

2005-12-12 Thread Stefan van den Berg
L505 wrote: I just tried the bug report source code at http://www.freepascal.org/bugs/showsource.php3?ID=4538 And I did not get an access violation or any errors. Which proves that it depends on your random luck on a random day ;) http://z505.com/images/BrokenDLLisWorking.png Interesting.

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Michael Van Canneyt
On Mon, 12 Dec 2005, darekM wrote: Marco van de Voort napisa(a): On Sun, 11 Dec 2005, darekM wrote: But why it is in separated unit, nobody know about it (or to few). F.e. Lazarus has own implementation of buffering. Lazarus had to do a long time with FPC 1.0.x _and_ 2.0.x. Not all

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Graeme Geldenhuys
Jonas Maebe wrote: No. I've fixed it and added a test. You can check whether something has been reported as a bug by going to http://www.freepascal.org/bugs.html Thanks for that! If possible, a copy of your unit tests would be nice addition to our test suite. I will go through the unit

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Graeme Geldenhuys
Marc Weustink wrote: StrPos is expecting 2 PChar params and not a Pointer. Please use PChar(lFrom) and PChar(lSearch) to let the compiler make the proper string to PChar conversion. You never ever can cast a string to a pchar using Pointer() I see your point, and amended my code. Nonetheless

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Jonas Maebe
On 12 dec 2005, at 08:12, Graeme Geldenhuys wrote: StrPos is expecting 2 PChar params and not a Pointer. Please use PChar(lFrom) and PChar(lSearch) to let the compiler make the proper string to PChar conversion. You never ever can cast a string to a pchar using Pointer() I see your point,

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Michalis Kamburelis
Are we talking here about making a class that can read any TStream descendant line-by-line (i.e. by simple a'la Readln method) ? Then I believe this was already discussed on fpc-pascal, I remember that I sent there my TTextReader class implementation that does just that. TTextReader class is a

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Micha Nelissen
Jonas Maebe wrote: strpos, I don't know about Delphi. If you typecast an ansistring to a pchar, then the compiler makes sure that if the ansistring is empty (and thus a null pointer), a valid pointer to an empty null-terminated string is returned. Is that not also undocumented behaviour ?

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Alexandrov Alexandru
On 12/11/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Sat, 10 Dec 2005, Alexandrov Alexandru wrote: > > > The following program will rise an error: > > Adress: $00401493 > > Procedure: fpc_pchar_length > > > > > > program project1; > > > > {$mode objfpc}{$H+} > > > > uses > > Class

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Jonas Maebe
On 12 dec 2005, at 12:17, Micha Nelissen wrote: strpos, I don't know about Delphi. If you typecast an ansistring to a pchar, then the compiler makes sure that if the ansistring is empty (and thus a null pointer), a valid pointer to an empty null-terminated string is returned. Is that

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Michael Van Canneyt
On Mon, 12 Dec 2005, Jonas Maebe wrote: On 12 dec 2005, at 12:17, Micha Nelissen wrote: strpos, I don't know about Delphi. If you typecast an ansistring to a pchar, then the compiler makes sure that if the ansistring is empty (and thus a null pointer), a valid pointer to an empty null-t

RE: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread peter green
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Micha > Nelissen > Sent: 12 December 2005 11:18 > To: FPC developers' list > Subject: Re: [fpc-devel] StrPos giving a access violation > > > Jonas Maebe wrote: > > strpos, I don't know about Delphi. If yo

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread Michael Van Canneyt
On Mon, 12 Dec 2005, Michalis Kamburelis wrote: Are we talking here about making a class that can read any TStream descendant line-by-line (i.e. by simple a'la Readln method) ? Then I believe this was already discussed on fpc-pascal, I remember that I sent there my TTextReader class impleme

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Jonas Maebe
On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: It depends on the specs of "length" :-) What do you mean with specs? How it is defined to behave in the documentation (i.e., whether the documentation says "if you call length with as argument a nil pointer, the result is defined to

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Michael Van Canneyt
On Mon, 12 Dec 2005, Jonas Maebe wrote: On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: It depends on the specs of "length" :-) What do you mean with specs? How it is defined to behave in the documentation (i.e., whether the documentation says "if you call length with as argument

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Graeme Geldenhuys
Jonas Maebe wrote: Is that not also undocumented behaviour ? I'm quite sure it isn't: afaik typecasting an ansistring to a pchar is fully supported. This means that an empty ansistring must result in an empty (as opposed to an invalid) pchar. Taken from Delphi 7 help: Mixing Delphi st

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Micha Nelissen
Graeme Geldenhuys wrote: Taken from Delphi 7 help: Mixing Delphi strings and null-terminated strings * You can also use Pointer(S) to cast a long string to an untyped pointer. But if S is empty, the typecast returns nil. * PChar(S) always returns a pointer to a memory block; if S is empty, a

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Jonas Maebe
On 12 dec 2005, at 13:30, Micha Nelissen wrote: Taken from Delphi 7 help: Mixing Delphi strings and null-terminated strings * You can also use Pointer(S) to cast a long string to an untyped pointer. But if S is empty, the typecast returns nil. * PChar(S) always returns a pointer to a memory b

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Micha Nelissen
Jonas Maebe wrote: It happens in more in Pascal. For example, single(longint_var) is also not the same as single(pointer(longint_var)) (let's assume a 32bit system). In the former case, the longint is convert to a floating point number with the same value. In the latter case, you get a floa

Re: [fpc-devel] StrPos giving a access violation

2005-12-12 Thread Jonas Maebe
On 12 dec 2005, at 13:57, Micha Nelissen wrote: It happens in more in Pascal. For example, single(longint_var) is also not the same as single(pointer(longint_var)) (let's assume a 32bit system). In the former case, the longint is convert to a floating point number with the same value. I

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Alexandrov Alexandru
On 12/12/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Mon, 12 Dec 2005, Jonas Maebe wrote: > > > > > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: > > > >>> It depends on the specs of "length" :-) > >> > >> What do you mean with specs? > > > > How it is defined to behave in t

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Alexandrov Alexandru
On 12/12/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Mon, 12 Dec 2005, Jonas Maebe wrote: > > > > > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: > > > >>> It depends on the specs of "length" :-) > >> > >> What do you mean with specs? > > > > How it is defined to behave in t

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread Jonas Maebe
On 12 dec 2005, at 14:29, Alexandrov Alexandru wrote: I agree with this position. A Nil pointer is usually a sign of a bad or uninitialized value. ..but we speak here about the length of the string. No, the length of pchar's. A string and a pchar are two different things in Pascal (althou

Re: [fpc-devel] Access Violation with nested DLL's compiled by FPC(and some more info on bug #4538)

2005-12-12 Thread Felipe Monteiro de Carvalho
On 12/10/05, Stefan van den Berg <[EMAIL PROTECTED]> wrote: > The usage of strings in the samples was just to verify which code was > executed and where things went wrong. I wasen't aware of the fact that > that alone could cause problems. In the actual application mainly > objects are passed to fu

Re: [fpc-devel] fpc_pchar_length error

2005-12-12 Thread dannym
Hi, Am Montag, den 12.12.2005, 15:29 +0200 schrieb Alexandrov Alexandru: > On 12/12/05, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 12 Dec 2005, Jonas Maebe wrote: > > > > > > > > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote: > > > > > >>> It depends on the specs of

Re: [fpc-devel] Benchmark for FreePascal

2005-12-12 Thread darekM
Hi My CPU war Welcome to the CPU war for StrLoadFile.. Please wait... test 1 (char) execution time: 1862654 test 2 (blockread 1) execution time: 27080 test 3 (blockread fsize) execution time: 46633 test 7 (blockread tHandle) execution time: 18569 test 4 (tStringList) execution time: 364999 test

[fpc-devel] GetAppConfigDir and GetAppConfigFile output

2005-12-12 Thread Felipe Monteiro de Carvalho
Hello, I recently tryed to use those two functions, so I created a test app with 4 functions: WriteLn(GetAppConfigDir(True)); WriteLn(GetAppConfigDir(False)); WriteLn(GetAppConfigFile(True)); WriteLn(GetAppConfigFile(False)); The output on a GNU/Linux system: /etc /home/felipe/project1