[fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
Hi At the moment I am using the following to compile FPC. make install INSTALL_PREFIX=/opt/fpc_2.0.x I never use the text ide (fp) and am getting compiler errors with it, after getting a svn update (revision 3626). 1) Conflict in the ide/MakeFile was checked into SVN. 2) After fixing that, I get a keyboard.pp unit was not found. All these errors occur in the ide/ directory. I use Lazarus, so really don't need to compile it. Is there some other command line I can add to my "make install..." mentioned above, that will skip the text ide project? Regards, - Graeme - -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Compiling fpc 2.0.x without text IDE (errors in revision 3626)
Hi, I looked into the main Makefile, to see if I could spot anything, so tried: make install INSTALL_PREFIX=/opt/fpc_2.0.x TARGET_DIRS_IDE=0 but that also didn't do it. It still tried to compile the text ide project. Regards, Graeme. On 5/22/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: Hi At the moment I am using the following to compile FPC. make install INSTALL_PREFIX=/opt/fpc_2.0.x I never use the text ide (fp) and am getting compiler errors with it, after getting a svn update (revision 3626). 1) Conflict in the ide/MakeFile was checked into SVN. 2) After fixing that, I get a keyboard.pp unit was not found. All these errors occur in the ide/ directory. I use Lazarus, so really don't need to compile it. Is there some other command line I can add to my "make install..." mentioned above, that will skip the text ide project? Regards, - Graeme - -- There's no place like 127.0.0.1 -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
Op Mon, 22 May 2006, schreef Graeme Geldenhuys: > Hi > At the moment I am using the following to compile FPC. > > make install INSTALL_PREFIX=/opt/fpc_2.0.x > > I never use the text ide (fp) and am getting compiler errors with it, > after getting a svn update (revision 3626). > > 1) Conflict in the ide/MakeFile was checked into SVN. > 2) After fixing that, I get a keyboard.pp unit was not found. > > All these errors occur in the ide/ directory. I use Lazarus, so > really don't need to compile it. > > > Is there some other command line I can add to my "make install..." > mentioned above, that will skip the text ide project? You can make individual subprojects, for example "make compiler_cycle rtl fv fcl", however, I don't think this is comfortable. Better fix the IDE compilation, try "fpcmake -Tall" in the IDE directory. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
On 5/22/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: You can make individual subprojects, for example "make compiler_cycle rtl fv fcl", however, I don't think this is comfortable. Better fix the IDE compilation, try "fpcmake -Tall" in the IDE directory. OK, I did that fpcmake, though I ain't sure what it did. I did say something of creating a new Makefile. I then did my normal make install with my install prefix and still got a error... The last few line: - [] make[2]: Leaving directory `/opt/svn/fpc_2.0.x/src' make ide_distinstall FPC=/opt/svn/fpc_2.0.x/src/compiler/ppc386 RELEASE=1 make[2]: Entering directory `/opt/svn/fpc_2.0.x/src' make -C ide distinstall make[3]: Entering directory `/opt/svn/fpc_2.0.x/src/ide' make buildfp make[4]: Entering directory `/opt/svn/fpc_2.0.x/src/ide' make compilerunits make[5]: Entering directory `/opt/svn/fpc_2.0.x/src/ide' make[5]: Nothing to be done for `compilerunits'. make[5]: Leaving directory `/opt/svn/fpc_2.0.x/src/ide' make testgdb make[5]: Entering directory `/opt/svn/fpc_2.0.x/src/ide' LibGDB not found LIBGDBFILE= GDBLIBDIR=/opt/svn/fpc_2.0.x/src/libgdb/linux make[5]: Leaving directory `/opt/svn/fpc_2.0.x/src/ide' make fpc_all make[5]: Entering directory `/opt/svn/fpc_2.0.x/src/ide' /opt/svn/fpc_2.0.x/src/compiler/ppc386 -Ur -Xs -OG2p3 -n -Sg -Fu/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux -Fu/opt/svn/fpc_2.0.x/src/fv/units/i386-linux -Fu/opt/svn/fpc_2.0.x/src/packages/base/gdbint/units/i386-linux -Fu/opt/svn/fpc_2.0.x/src/packages/base/regexpr/units/i386-linux -FE. -FUunits/i386-linux -Fl/usr/lib/gcc/i486-linux-gnu/4.0.2 -Fl/usr/lib/libc5-compat -Fl/lib/libc5-compat -Fl/usr/i486-linuxlibc1/lib -Fl/usr/lib/kylix3 -Fl/usr/lib -Fl/usr/local/lib -di386 -dRELEASE -dNODEBUG fp.pas keyboard.pp(76,10) Fatal: Can't find unit keyboard keyboard.pp(76,10) Fatal: Compilation aborted make[5]: *** [fp] Error 1 make[5]: Leaving directory `/opt/svn/fpc_2.0.x/src/ide' make[4]: *** [buildfp] Error 2 make[4]: Leaving directory `/opt/svn/fpc_2.0.x/src/ide' make[3]: *** [gdb] Error 2 make[3]: Leaving directory `/opt/svn/fpc_2.0.x/src/ide' make[2]: *** [ide_distinstall] Error 2 make[2]: Leaving directory `/opt/svn/fpc_2.0.x/src' make[1]: *** [installother] Error 2 make[1]: Leaving directory `/opt/svn/fpc_2.0.x/src' make: *** [install] Error 2 - Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
Op Mon, 22 May 2006, schreef Graeme Geldenhuys: > On 5/22/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > OK, I did that fpcmake, though I ain't sure what it did. I did say > > something of creating a new Makefile. That is what it does indeed. > > -Fu/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux It adds the rtl directory correctly. Please check is keyboard.ppu is present there. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess.output.read does not return until process stopped running.
Jonas Maebe wrote: On 19 mei 2006, at 15:20, ik wrote: When executing a program using TProcess, it seems that Output.read does not return from the reading, until the execution of the process is over. The returning probably happens every 4KB of data or so (and once the program has finished). The reason is that if the communications pipe flushes after every write, you get much less potential parallelism and more system overhead. And that's only the OS-part of the buffering, it's quite possible that the program you execute is also buffering its output and only flushes after every X KB of written data. I once tried to write a program (in FPC) that interactively communicated with other programs using stdin/stdout. (The client programs were AIs for a game from a programming contest, and the main program put everything together to play an actual game.) I found that it is important the 'client' programs calls Flush after every Write (or series of Write's yielding one 'message'), and if you don't want your program (the 'host') to wait forever if the client does not write some data as expected (e.g. because of a bug in the client, a client not flushing its output, or a time-out of the AI in my case), you can try to put the stream-reading code in a separate thread. Of course, this means you'll need to do make that code thread-safe. Unfortunately TProcess.Output.Read is blocking... This whole approach is mainly suitable if the client program flushes it output buffer. If you write the program yourself, have access to its source code, or can specify requirements to people writing it, this requirement can likely be satisfied. (In the case of the game contest mentioned, the contest rules obliged the Flush calls.) Regards, Bram PS The contest is yearly held at http://www.codecup.nl. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] slightly misleading fpc makefile hint
In recent binutils the program "pwd.exe" (it returns current directory name) is omitted. But makefile fails with a hint "You need GNU utils package..." (well, it does not explicitly write, that it needs binutils). Why don't emit "You need GNU utils package... (pwd.exe)"? (PWD.EXE and some versions of needed utils are supplied with FPC releases.) Also, it is good candidate to be mentioned in excellent "buildfaq.pdf" by Marco van de Voort. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
On 5/22/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > -Fu/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux It adds the rtl directory correctly. Please check is keyboard.ppu is present there. Yup! [EMAIL PROTECTED]:/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux$ ls -l keyboard.* -rw-r--r-- 1 graemeg graemeg 27020 2006-05-19 09:45 keyboard.o -rw-r--r-- 1 graemeg graemeg 29753 2006-05-19 09:45 keyboard.ppu I do notice that the date on those files are from the previous time I built fpc 2.0.3. I guess if keyboard.pp hasn't change since then, "make install ..." wouldn't recompile it. Or does 'make install...' clean out everything before it starts a new build? Regards, - Graeme - Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)t
> > At the moment I am using the following to compile FPC. > > make install INSTALL_PREFIX=/opt/fpc_2.0.x Try IDE=0, if that doesn't work, try renaming the fv dir. Both used to work, but don't know if they still do. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Michael Van Canneyt wrote: The following remark in the Delphi help sheds more light on the issue: "When working with negative TDateTime values, computations must handle time portion separately. The fractional part reflects the fraction of a 24-hour day without regard to the sign of the TDateTime value. For example, 6:00 am on 12/29/1899 is -1.25, Not -1 + 0.25, which would be -0.75. There are no TDateTime values between -1 and 0." This is really bad -- I supposed the TDateTime was a nice 'linear' mapping of time (which is much nicer for all kinds of calculations). As Joost said, dateutil.inc will need quite some fixes. I guess we will need plenty of unit tests to make sure all the functions work consistent, in particular also for dates close to and before 29-12-1899 :) (Note: I sent some mail explaining the TryEncodeDateTime function some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)t
I did notice that if I renamed the ide directory to ide.old, it managed to compile, but I wasn't sure if it would maybe skip other units it shouldn't have, so wondered it there was a parameter I could pass to make, to do it correctly. I will try the IDE=0 now... Graeme. On 5/22/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > At the moment I am using the following to compile FPC. > > make install INSTALL_PREFIX=/opt/fpc_2.0.x Try IDE=0, if that doesn't work, try renaming the fv dir. Both used to work, but don't know if they still do. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)t
Using IDE=0 doesn't work here, it still tried to compile the ide directory. Graeme. On 5/22/06, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > At the moment I am using the following to compile FPC. > > make install INSTALL_PREFIX=/opt/fpc_2.0.x Try IDE=0, if that doesn't work, try renaming the fv dir. Both used to work, but don't know if they still do. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Bram Kuijvenhoven wrote: Michael Van Canneyt wrote: The following remark in the Delphi help sheds more light on the issue: "When working with negative TDateTime values, computations must handle time portion separately. The fractional part reflects the fraction of a 24-hour day without regard to the sign of the TDateTime value. For example, 6:00 am on 12/29/1899 is -1.25, Not -1 + 0.25, which would be -0.75. There are no TDateTime values between -1 and 0." This is really bad -- I supposed the TDateTime was a nice 'linear' mapping of time (which is much nicer for all kinds of calculations). It is, but only for dates after 1899-12-30. God only knows why Microsoft picked this date. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
> On Mon, 22 May 2006, Bram Kuijvenhoven wrote: > > This is really bad -- I supposed the TDateTime was a nice 'linear' mapping > > of > > time (which is much nicer for all kinds of calculations). > > It is, but only for dates after 1899-12-30. God only knows why Microsoft > picked this date. Julian is 1900-1-1 noon iirc. The deviation comes from compability with older products that did leapyear calculation for the year 1900 wrong (and maybe more), needing to adjust the origin date. The noon definition was also not very practical. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
Op Mon, 22 May 2006, schreef Graeme Geldenhuys: > On 5/22/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > > -Fu/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux > > > > > > > > > > It adds the rtl directory correctly. Please check is > > > > keyboard.ppu is > > > > > present there. > > > > > > > > Yup! > > > > > > > > [EMAIL PROTECTED]:/opt/svn/fpc_2.0.x/src/rtl/units/i386-linux$ ls > > > > -l keyboard.* > > > > -rw-r--r-- 1 graemeg graemeg 27020 2006-05-19 09:45 keyboard.o > > > > -rw-r--r-- 1 graemeg graemeg 29753 2006-05-19 09:45 > > > > keyboard.ppu > > > > > > > > I do notice that the date on those files are from the previous > > > > time I > > > > built fpc 2.0.3. I guess if keyboard.pp hasn't change since > > > > then, > > > > "make install ..." wouldn't recompile it. Or does 'make > > > > install...' > > > > clean out everything before it starts a new build? I think this might be the source of the problem, try a clean before making it. The 2.0 svn repository compiles fine here, so the problem must be on your computer. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling fpc 2.0.x without text IDE (errors in revision 3626)
On 5/22/06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > > I do notice that the date on those files are from the previous > > > > time I > > > > built fpc 2.0.3. I guess if keyboard.pp hasn't change since > > > > then, > > > > "make install ..." wouldn't recompile it. Or does 'make > > > > install...' > > > > clean out everything before it starts a new build? I think this might be the source of the problem, try a clean before making it. The 2.0 svn repository compiles fine here, so the problem must be on your computer. Finally success!! Doing a 'make clean' before the 'make install ...' did the trick. Thanks guys...! Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: I guess we will need plenty of unit tests to make sure all the functions work consistent, in particular also for dates close to and before 29-12-1899 :) (Note: I sent some mail explaining the TryEncodeDateTime function some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) Hi Bram, Yeah, I had my share of uphill battles with old dates (Delphi and FPC). I works fine with recent dates, but don't venture to far off!! I already have a collection of unit tests for dates, which is incorporated into our products unit tests. We use fpcUnit extensively. I could always extend those tests a bit more, but as far as I understand, FPC developers dont' use fpcUnit, but rather some custom testing framework. Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Graeme Geldenhuys wrote: On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: I guess we will need plenty of unit tests to make sure all the functions work consistent, in particular also for dates close to and before 29-12-1899 :) (Note: I sent some mail explaining the TryEncodeDateTime function some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) Hi Bram, Yeah, I had my share of uphill battles with old dates (Delphi and FPC). I works fine with recent dates, but don't venture to far off!! I already have a collection of unit tests for dates, which is incorporated into our products unit tests. We use fpcUnit extensively. I could always extend those tests a bit more, but as far as I understand, FPC developers dont' use fpcUnit, but rather some custom testing framework. 1. fpcunit didn't exist at the time the FPC tests were implemented. 2. Using FPCunit creates a dependency on it. The tests can run mostly with only the system unit... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Michael Van Canneyt wrote: > > > On Mon, 22 May 2006, Graeme Geldenhuys wrote: > >> On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: >>> I guess we will need plenty of unit tests to make sure all the functions >> work consistent, in particular also for dates close to and before >> 29-12-1899 :) >>> >>> (Note: I sent some mail explaining the TryEncodeDateTime function >>> some time >> ago (21-4-2006), on Graeme's request. I also mentioned an overflow >> problem in that code + how to fix. Perhaps this fix can be integrated >> into the code as well.) >>> >> >> Hi Bram, >> >> Yeah, I had my share of uphill battles with old dates (Delphi and >> FPC). I works fine with recent dates, but don't venture to far off!! >> >> I already have a collection of unit tests for dates, which is >> incorporated into our products unit tests. We use fpcUnit >> extensively. I could always extend those tests a bit more, but as far >> as I understand, FPC developers dont' use fpcUnit, but rather some >> custom testing framework. > > 1. fpcunit didn't exist at the time the FPC tests were implemented. > 2. Using FPCunit creates a dependency on it. The tests can run mostly >with only the system unit... Which dependencies? Maybe they can be reduced and a fpcunit can be added to tests? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Mon, 22 May 2006, Graeme Geldenhuys wrote: On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: I guess we will need plenty of unit tests to make sure all the functions work consistent, in particular also for dates close to and before 29-12-1899 :) (Note: I sent some mail explaining the TryEncodeDateTime function some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) Hi Bram, Yeah, I had my share of uphill battles with old dates (Delphi and FPC). I works fine with recent dates, but don't venture to far off!! I already have a collection of unit tests for dates, which is incorporated into our products unit tests. We use fpcUnit extensively. I could always extend those tests a bit more, but as far as I understand, FPC developers dont' use fpcUnit, but rather some custom testing framework. 1. fpcunit didn't exist at the time the FPC tests were implemented. 2. Using FPCunit creates a dependency on it. The tests can run mostly with only the system unit... Which dependencies? Maybe they can be reduced and a fpcunit can be added to tests? fpcunit depends on not so much, but I want to avoid using the FCL in the testsuite... Creating a copy seems rather silly too... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Michael Van Canneyt wrote: > > > On Mon, 22 May 2006, Florian Klaempfl wrote: > >> Michael Van Canneyt wrote: >>> >>> >>> On Mon, 22 May 2006, Graeme Geldenhuys wrote: >>> On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: > I guess we will need plenty of unit tests to make sure all the > functions work consistent, in particular also for dates close to and before 29-12-1899 :) > > (Note: I sent some mail explaining the TryEncodeDateTime function > some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) > Hi Bram, Yeah, I had my share of uphill battles with old dates (Delphi and FPC). I works fine with recent dates, but don't venture to far off!! I already have a collection of unit tests for dates, which is incorporated into our products unit tests. We use fpcUnit extensively. I could always extend those tests a bit more, but as far as I understand, FPC developers dont' use fpcUnit, but rather some custom testing framework. >>> >>> 1. fpcunit didn't exist at the time the FPC tests were implemented. >>> 2. Using FPCunit creates a dependency on it. The tests can run mostly >>>with only the system unit... >> >> Which dependencies? Maybe they can be reduced and a fpcunit can be >> added to tests? > > fpcunit depends on not so much, but I want to avoid using the FCL in the > testsuite... Creating a copy seems rather silly too... You can create an svn:external to important that one from the fcl without creating a real copy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Mon, 22 May 2006, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Mon, 22 May 2006, Graeme Geldenhuys wrote: On 5/22/06, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: I guess we will need plenty of unit tests to make sure all the functions work consistent, in particular also for dates close to and before 29-12-1899 :) (Note: I sent some mail explaining the TryEncodeDateTime function some time ago (21-4-2006), on Graeme's request. I also mentioned an overflow problem in that code + how to fix. Perhaps this fix can be integrated into the code as well.) Hi Bram, Yeah, I had my share of uphill battles with old dates (Delphi and FPC). I works fine with recent dates, but don't venture to far off!! I already have a collection of unit tests for dates, which is incorporated into our products unit tests. We use fpcUnit extensively. I could always extend those tests a bit more, but as far as I understand, FPC developers dont' use fpcUnit, but rather some custom testing framework. 1. fpcunit didn't exist at the time the FPC tests were implemented. 2. Using FPCunit creates a dependency on it. The tests can run mostly with only the system unit... Which dependencies? Maybe they can be reduced and a fpcunit can be added to tests? fpcunit depends on not so much, but I want to avoid using the FCL in the testsuite... Creating a copy seems rather silly too... You can create an svn:external to important that one from the fcl without creating a real copy. Good idea. Should we convert existing tests to fpcunit ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Michael Van Canneyt wrote: > 1. fpcunit didn't exist at the time the FPC tests were implemented. > 2. Using FPCunit creates a dependency on it. The tests can run mostly >with only the system unit... Which dependencies? Maybe they can be reduced and a fpcunit can be added to tests? >>> >>> fpcunit depends on not so much, but I want to avoid using the FCL in the >>> testsuite... Creating a copy seems rather silly too... >> >> You can create an svn:external to important that one from the fcl without >> creating a real copy. > > Good idea. > > Should we convert existing tests to fpcunit ? No, too much work, no real gain :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Should we convert existing tests to fpcunit ?
No, too much work, no real gain :)
Just curious...
I have never looked at the tests created in FPC, but how much work
(lines of code) would it take to test something like the following
snippet of our tests we have. (very simple example) If it isn't to
much work, the benefits will be huge as fpcUnit has a lot of
advantages. TestDecorator, Exception testing, XML output, etc... As I
said, we use fpcUnit extensively. Currently running at around 1500+
unit tests, testing database connections, string utils, threading,
etc...
In the example below tiUtils.tiDateTimeAsIntlDateDisp outputs dates in
the ISO international datetime format. Most of our test are as easy
as this, 1 or 2 liners. Not to mention fpcUnit give you results in
XML output which we convert to a html page via xslt to be viewer over
the web to see what the nightly build did.
procedure TTestTIUtils.tiDateTimeAsIntlDateDisp;
var
dt: TDateTime;
begin
dt := EncodeDate(2006, 1, 18) + EncodeTime(15, 19, 22, 0);
CheckEquals('2006-01-18 15:19:22',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 1');
dt := EncodeDate(2002, 1, 02) + EncodeTime(12, 34, 56, 12);
CheckEquals('2002-01-02 12:34:56',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 2');
dt := EncodeDate(2006, 1, 18);
CheckEquals('2006-01-18 00:00:00',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 3');
dt := EncodeTime(9, 10, 41, 22);
CheckEquals('-00-00 09:10:41',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 4');
dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12);
CheckEquals('1652-06-15 12:34:56',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 5');
[]
end;
Regards,
- Graeme -
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Graeme Geldenhuys schreef:
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Should we convert existing tests to fpcunit ?
No, too much work, no real gain :)
Just curious...
I have never looked at the tests created in FPC, but how much work
(lines of code) would it take to test something like the following
snippet of our tests we have. (very simple example) If it isn't to
much work, the benefits will be huge as fpcUnit has a lot of
advantages. TestDecorator, Exception testing, XML output, etc... As I
said, we use fpcUnit extensively. Currently running at around 1500+
unit tests, testing database connections, string utils, threading,
etc...
In the example below tiUtils.tiDateTimeAsIntlDateDisp outputs dates in
the ISO international datetime format. Most of our test are as easy
as this, 1 or 2 liners. Not to mention fpcUnit give you results in
XML output which we convert to a html page via xslt to be viewer over
the web to see what the nightly build did.
procedure TTestTIUtils.tiDateTimeAsIntlDateDisp;
var
dt: TDateTime;
begin
dt := EncodeDate(2006, 1, 18) + EncodeTime(15, 19, 22, 0);
CheckEquals('2006-01-18 15:19:22',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 1');
dt := EncodeDate(2002, 1, 02) + EncodeTime(12, 34, 56, 12);
CheckEquals('2002-01-02 12:34:56',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 2');
dt := EncodeDate(2006, 1, 18);
CheckEquals('2006-01-18 00:00:00',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 3');
dt := EncodeTime(9, 10, 41, 22);
CheckEquals('-00-00 09:10:41',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 4');
dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12);
CheckEquals('1652-06-15 12:34:56',
tiUtils.tiDateTimeAsIntlDateDisp(dt), 'Failed on 5');
[]
end;
In the current framework it would look like this:
program tiDateTimeAsIntlDateDisp;
uses
tiUtils; // I am guessing it is a unit, but it could be an object too.
var
dt: TDateTime;
begin
dt := EncodeDate(2006, 1, 18) + EncodeTime(15, 19, 22, 0);
if '2006-01-18 15:19:22'<>
tiUtils.tiDateTimeAsIntlDateDisp(dt) then halt(1);
dt := EncodeDate(2002, 1, 02) + EncodeTime(12, 34, 56, 12);
if '2002-01-02 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt)
then halt(2);
dt := EncodeDate(2006, 1, 18);
if '2006-01-18 00:00:00'<>tiUtils.tiDateTimeAsIntlDateDisp(dt)
then halt(3);
dt := EncodeTime(9, 10, 41, 22);
if '-00-00 09:10:41'<>tiUtils.tiDateTimeAsIntlDateDisp(dt)
then halt(4);
dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12);
if '1652-06-15 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt)
then halt(5);
[]
end.
The results are gathered and published on:
http://www.freepascal.org/cgi-bin/testsuite.cgi
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Vincent Snijders wrote: > dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12); > if '1652-06-15 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt) >then halt(5); > > [] > end. We use the simple approach with halt because using the fpcunit for basic tests would require that OOP works always but it could be easily broken and thus all tests would fail. So we designed the test suite in a way which keeps prerequisits as low as possible. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Florian Klaempfl wrote: Vincent Snijders wrote: dt := EncodeDateTime(1652, 6, 15, 12, 34, 56, 12); if '1652-06-15 12:34:56' <> tiUtils.tiDateTimeAsIntlDateDisp(dt) then halt(5); [] end. We use the simple approach with halt because using the fpcunit for basic tests would require that OOP works always but it could be easily broken and thus all tests would fail. So we designed the test suite in a way which keeps prerequisits as low as possible. That is what I would like to keep :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 22 mei 2006, at 16:38, Florian Klaempfl wrote: We use the simple approach with halt because using the fpcunit for basic tests would require that OOP works always but it could be easily broken and thus all tests would fail. So we designed the test suite in a way which keeps prerequisits as low as possible. Given that the code generator is almost entirely OOP nowadays, I doubt we would even get to the testsuite if it were to be broken :) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Ok, so every set of tests is a actual program. [I am not forcing fpcUnit, just curious as what FPC's tests can do. Also not sure what your knowlegde is on the workings of a xUnit testing framework. ] So if you have to test something a little more complex, and every unittest needs some predefined state (example a set of objects need to be created or a database connection needs to be created) and then once the test has completed, those objects need to be freed or db connection closed. That will add a lof of extra code to the FPC test framework as far as I can see. Here is another big benefit of using a unittest framework like fpcUnit. In fpcUnit I could add two methods to my TestCase class (Setup and TearDown) which will be called before and after each test without me have to wrap anything in a try..finally block etc. Another example will be to test a method that needs to raise an exception and you are testing for a specific type of exception. Also as part of the XML results generated by fpcUnit, is the line number a Error occured (unexpected result) including the exception that was raised, or the message string a test failure occured at (eg: 'Failed on 1' including the Actual and Expected results). Tests could also be grouped in test suites. -- sample xml test output -- TTestTIUtils.tiFloatToCurrency: Failed on 4 expected: <$ 0.01> but was: <$ 0.00> EAssertionFailedError Failed on 4 expected: <$ 0.01> but was: <$ 0.00> TTestTIUtils.tiVariantArrayToString: Variant array locked EVariantArrayLockedError Variant array locked 1702 --- Where in SubVersion are the fpc tests located? Regards, - Graeme - On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: Graeme Geldenhuys schreef: > On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: The results are gathered and published on: http://www.freepascal.org/cgi-bin/testsuite.cgi Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 22 mei 2006, at 17:01, Graeme Geldenhuys wrote: Where in SubVersion are the fpc tests located? fpc/tests Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006, Graeme Geldenhuys wrote: Ok, so every set of tests is a actual program. [I am not forcing fpcUnit, just curious as what FPC's tests can do. Also not sure what your knowlegde is on the workings of a xUnit testing framework. ] So if you have to test something a little more complex, and every unittest needs some predefined state (example a set of objects need to be created or a database connection needs to be created) and then once the test has completed, those objects need to be freed or db connection closed. That will add a lof of extra code to the FPC test framework as far as I can see. Here is another big benefit of using a unittest framework like fpcUnit. In fpcUnit I could add two methods to my TestCase class (Setup and TearDown) which will be called before and after each test without me have to wrap anything in a try..finally block etc. Another example will be to test a method that needs to raise an exception and you are testing for a specific type of exception. Also as part of the XML results generated by fpcUnit, is the line number a Error occured (unexpected result) including the exception that was raised, or the message string a test failure occured at (eg: 'Failed on 1' including the Actual and Expected results). Tests could also be grouped in test suites. This is all correct. No-one questions the usefullness of fpcunit (on the contrary), but the point is to test the compiler and RTL. There are many tests which simply should fail when compiling, or where the compiler should give a specific error. -> You can't test that with fpcunit :-) If we need to design tests for the "Inherited;" construct, then you can't use fpcunit for that, since fpcunit relies on "Inherited;" working correctly in the first place. A kind of chicken-and-egg problem :-) But more high-level routines could definitely be implemented using fpcunit... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 5/22/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: We use the simple approach with halt because using the fpcunit for basic tests would require that OOP works always but it could be easily broken and thus all tests would fail. So we designed the test suite in a way which keeps prerequisits as low as possible. That's fair enough. I guess compiler development is a sensitive case and a low prerequisit is very important. Using you example though that would mean you will get a very visible indication that a major screw-up did occur on the last svn commit, and fpcUnit would still have done it's job. What we do [ and no we don't develop compilers :) ] in our organization is that before anybody is allowed to commit changes, they need to run the set of unit tests (and yes our unit test must run quickly - a few minutes < 10 max). Currently it takes just over 2minutes to complete our 1500+ test suite. A unit test is everything inside the procedure TTestTIUtils.tiDateTimeAsIntlDateDisp method mentioned earlier, so it is a lot of tests. Regards, Graeme . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] shared libraries on x86_64 Linux ?
Hello, I'm new to this list (and to Free Pascal...) What are the news from bug #6618 (ex 4733), on building shared libraries on a x86_64 architecture? http://www.freepascal.org/mantis/view.php?id=6618 I did some tests, and it seems to bee still present in 2.0.2 and current 2.1.1 snapshot (I encountered no problems with i386). In the BTS I see that the status is still new,open, and there seems to have been no activity on this bug since its submission. I also had a look at the thread "Hitting bug 4733" on this list http://lists.freepascal.org/lists/fpc-devel/2006-April/007514.html and to http://community.freepascal.org:1/bboards/message?message_id=152498&forum_id=24083 in the forums (AMD64 shared library link problem) Has anybody had a look at it? If yes, does it seem to be hard to fix? Is it the PIC generation that is broken for x86_64? Please tell me if there are any plans on the matter. I'm quite willing to help, but would appreciate a little help... Thanks a lot, Dominique Leducq ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Jonas Maebe wrote: > > On 22 mei 2006, at 16:38, Florian Klaempfl wrote: > >> We use the simple approach with halt because using the fpcunit for >> basic tests >> would require that OOP works always but it could be easily broken and >> thus all >> tests would fail. So we designed the test suite in a way which keeps >> prerequisits as low as possible. > > Given that the code generator is almost entirely OOP nowadays, I doubt > we would even get to the testsuite if it were to be broken :) Well, for regression testing this is true but not for bootstrap testing :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
The attached patch fixs some problems with negative TDateTimes.
It could be that the changes in DecodeDate are for the same problem as
Bram already send a patch for:
+ removed obsolete DayTable
+ fixed DateTimeToTimestamp, EncodeDate, DecodeDate, DecodeTime for
TDatetimes < 0
+ MSecsToTimeStamp must change day at 24:00, not at 12:00
+ removed double code in Now and DecodeDateFully
Regards,
Joost.
Index: objpas/sysutils/dati.inc
===
--- objpas/sysutils/dati.inc (revision 3468)
+++ objpas/sysutils/dati.inc (working copy)
@@ -24,11 +24,6 @@
{ internal functions }
{==}
-const
- DayTable: array[Boolean, 1..12] of longint =
- ((0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334),
- (0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335));
-
Function DoEncodeDate(Year, Month, Day: Word): longint;
Var
@@ -56,8 +51,8 @@
function DateTimeToTimeStamp(DateTime: TDateTime): TTimeStamp;
begin
- result.Time := Trunc(Frac(DateTime) * MSecsPerDay);
- result.Date := DateDelta + Round(System.Int(DateTime));
+ result.Time := Trunc(abs(Frac(DateTime)) * MSecsPerDay);
+ result.Date := DateDelta + trunc(DateTime);
end ;
{ TimeStampToDateTime converts TimeStamp to a TDateTime value }
@@ -71,7 +66,7 @@
function MSecsToTimeStamp(MSecs: comp): TTimeStamp;
begin
- result.Date := Round(msecs / msecsperday);
+ result.Date := Trunc(msecs / msecsperday);
msecs:= comp(msecs-result.date*msecsperday);
result.Time := Round(MSecs);
end ;
@@ -102,7 +97,10 @@
end;
c:= Year DIV 100;
ya:= Year - 100*c;
- Date := (146097*c) SHR 2 + (1461*ya) SHR 2 + (153*cardinal(Month)+2) DIV 5 + cardinal(Day) - 693900;
+ Date := (146097*c) SHR 2 + (1461*ya) SHR 2 + (153*cardinal(Month)+2) DIV 5 + cardinal(Day);
+ // Note that this line can't be part of the line above, since TDateTime is
+ // signed and c and ya are not
+ Date := Date - 693900;
end
end;
@@ -144,32 +142,41 @@
var
ly,ld,lm,j : cardinal;
begin
- j := pred((Trunc(System.Int(Date)) + 693900) SHL 2);
- ly:= j DIV 146097;
- j:= j - 146097 * cardinal(ly);
- ld := j SHR 2;
- j:=(ld SHL 2 + 3) DIV 1461;
- ld:= (cardinal(ld) SHL 2 + 7 - 1461*j) SHR 2;
- lm:=(5 * ld-3) DIV 153;
- ld:= (5 * ld +2 - 153*lm) DIV 5;
- ly:= 100 * cardinal(ly) + j;
- if lm < 10 then
- inc(lm,3)
+ if Date <= -datedelta then // If Date is before 1-1-1 then return 0-0-0
+begin
+Year := 0;
+Month := 0;
+Day := 0;
+end
else
begin
- dec(lm,9);
- inc(ly);
+j := pred((Trunc(System.Int(Date)) + 693900) SHL 2);
+ly:= j DIV 146097;
+j:= j - 146097 * cardinal(ly);
+ld := j SHR 2;
+j:=(ld SHL 2 + 3) DIV 1461;
+ld:= (cardinal(ld) SHL 2 + 7 - 1461*j) SHR 2;
+lm:=(5 * ld-3) DIV 153;
+ld:= (5 * ld +2 - 153*lm) DIV 5;
+ly:= 100 * cardinal(ly) + j;
+if lm < 10 then
+ inc(lm,3)
+else
+ begin
+dec(lm,9);
+inc(ly);
+ end;
+year:=ly;
+month:=lm;
+day:=ld;
end;
- year:=ly;
- month:=lm;
- day:=ld;
end;
function DecodeDateFully(const DateTime: TDateTime; var Year, Month, Day, DOW: Word): Boolean;
begin
DecodeDate(DateTime,Year,Month,Day);
- DOW:=DateTimeToTimeStamp(DateTime).Date mod 7+1;
+ DOW:=DayOfWeek(DateTime);
Result:=IsLeapYear(Year);
end;
@@ -181,7 +188,7 @@
Var
l : cardinal;
begin
- l := Round(Frac(time) * MSecsPerDay);
+ l := Round(abs(Frac(time)) * MSecsPerDay);
Hour := l div 360;
l := l mod 360;
Minute := l div 6;
@@ -241,9 +248,8 @@
SystemTime: TSystemTime;
begin
GetLocalTime(SystemTime);
- result := DoEncodeDate(SystemTime.Year,SystemTime.Month,SystemTime.Day) +
-DoEncodeTime(SystemTime.Hour,SystemTime.Minute,SystemTime.Second,SystemTime.MilliSecond);
-end ;
+ result := systemTimeToDateTime(SystemTime);
+end;
{ IncMonth increments DateTime with NumberOfMonths months,
NumberOfMonths can be less than zero }
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Michael Van Canneyt wrote: On Mon, 22 May 2006, Graeme Geldenhuys wrote: Ok, so every set of tests is a actual program. [I am not forcing fpcUnit, just curious as what FPC's tests can do. Also not sure what your knowlegde is on the workings of a xUnit testing framework. ] So if you have to test something a little more complex, and every unittest needs some predefined state (example a set of objects need to be created or a database connection needs to be created) and then once the test has completed, those objects need to be freed or db connection closed. That will add a lof of extra code to the FPC test framework as far as I can see. Here is another big benefit of using a unittest framework like fpcUnit. In fpcUnit I could add two methods to my TestCase class (Setup and TearDown) which will be called before and after each test without me have to wrap anything in a try..finally block etc. Another example will be to test a method that needs to raise an exception and you are testing for a specific type of exception. Also as part of the XML results generated by fpcUnit, is the line number a Error occured (unexpected result) including the exception that was raised, or the message string a test failure occured at (eg: 'Failed on 1' including the Actual and Expected results). Tests could also be grouped in test suites. This is all correct. No-one questions the usefullness of fpcunit (on the contrary), but the point is to test the compiler and RTL. There are many tests which simply should fail when compiling, or where the compiler should give a specific error. -> You can't test that with fpcunit :-) If we need to design tests for the "Inherited;" construct, then you can't use fpcunit for that, since fpcunit relies on "Inherited;" working correctly in the first place. A kind of chicken-and-egg problem :-) But more high-level routines could definitely be implemented using fpcunit... I would propose to create a tests\fpunit and/or a tests\webfpu directory where fpunit testcase could be added. This is not a replacement for the current method, since reports for IE or syntax errors cannot be adequately tested with it and in some / most cases a simple program showing the bug is easier to write and compiles faster (good for the fixer). From Greame I would like to know how he proposes to update the TestSuite, if a new tests it added. For the current test method, this is not an issue, since all programs in a directory are compiled. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
The makefile of the testsuite now simply gets the fpcunit from the fcl dir and compiles it if necessary. Since the fpcunit depends only on rtl units, I see no problem with this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] shared libraries on x86_64 Linux ?
Dominique Leducq wrote: > Hello, > > I'm new to this list (and to Free Pascal...) > > What are the news from bug #6618 (ex 4733), on building shared libraries on a > x86_64 architecture? > http://www.freepascal.org/mantis/view.php?id=6618 > > I did some tests, and it seems to bee still present in 2.0.2 and current > 2.1.1 snapshot (I encountered no problems with i386). > In the BTS I see that the status is still new,open, and there seems to have > been no activity on this bug since its submission. > > I also had a look at the thread "Hitting bug 4733" on this list > http://lists.freepascal.org/lists/fpc-devel/2006-April/007514.html > and to > http://community.freepascal.org:1/bboards/message?message_id=152498&forum_id=24083 > in the forums (AMD64 shared library link problem) > > Has anybody had a look at it? > If yes, does it seem to be hard to fix? The problem is that we don't want to compile the default rtl with PIC. > Is it the PIC generation that is broken for x86_64? Afaik not. > Please tell me if there are any plans on the matter. I'm quite willing to > help, but would appreciate a little help... You simply need to rebuild the rtl with PIC. > > Thanks a lot, > > Dominique Leducq > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding constants to defines.inc (windows)
Giulio Bernardi wrote:
> Hi,
> I was playing around with lazarus and I found that solution to a bug
> (6950) is trivial.
> But it needs a constant (SPI_GETFLATMENU) that is not in
> rtl/win/wininc/defines.inc
> (or rtl/win32/wininc/defines.inc for fpc 2.0.x).
> Is it ok if I send a patch to add all SPI* constants (taken from latest
> winuser.h) to defines.inc?
Yes.
> I see that constants are ordered alphabetically. Would you like them
> ordered this way or
> following MS order (by constant value)?.
Feel free to do it how you like ;)
> Also, there are win2000/me or higher constants and winxp or higher
> constants.
> Should they be merged or left separate from the others?
> I mean, something like:
>
> ..
> SPI_SETWORKAREA = 47;
> { Windows Me/2000 and higher }
> SPI_GETACTIVEWINDOWTRACKING = 4096;
> ..
> { Windows XP and higher }
> SPI_GETBLOCKSENDINPUTRESETS = 4134;
Constants don't hurt so they can be simply added.
> ..
>
> bye
> Giulio ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 22 May 2006 18:07:52 +0200 Joost van der Sluis <[EMAIL PROTECTED]> wrote: > The attached patch fixs some problems with negative TDateTimes. Can you introduce constants instead of all these hardcoded numbers so the code is more readable ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
Micha Nelissen wrote: On Mon, 22 May 2006 18:07:52 +0200 Joost van der Sluis <[EMAIL PROTECTED]> wrote: The attached patch fixs some problems with negative TDateTimes. Can you introduce constants instead of all these hardcoded numbers so the code is more readable ? Maybe Brams mail should be incorporated, given the fact that the constants don't have a clear meaning. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: > Can you introduce constants instead of all these hardcoded numbers so the > code is more readable ? > Maybe Brams mail should be incorporated, given the fact that the constants don't have a clear meaning. Vincent. This is exactly why I asked my original question regarding the date routines. After reading is email, I could see why constants where not used. I meant to document somewhere in fpcdoc or even better, in the code what all those numbers meant. Could we add his email as a comment above the code? Or a comment linking it to some help file explaining what he said. Regards, - Graeme - -- There's no place like 127.0.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
From Greame I would like to know how he proposes to update the
TestSuite, if a new tests it added.
I am busy looking at the /tests directory now, to understand how tests
get grouped. This should give me a clearer idea of what is possible.
It took us a while to get a decent test structure for our code as
well.
I agree that certain tests will have to stay in the format they are in
now. Things that shouldn't compile, etc... All other tests could be
group in test suites. RTL suite, FCL suite, etc..
Maybe Dean Zobec has some ideas on this too. Dean?
I like the idea you guys have of using the Bug Report Number as the
test name. This could be done with fpcUnit as well and should make
tracking of what tests have been converted to fpcUnit quite easy.
eg: Lets say we have a bug #1234 in the RTL. Edit the RTL suite, by
adding a new method to the test class and the same naming convention
could be used. No extra objects / classes need to be created, just a
new method needs to be added. Even the person reporting the bug could
write a simple fpcUnit test and submit that to Mantis, which can then
be copied into the correct suite. I submitted a couple of simple
fpcUnit test cases to show a bug, until I found out the FPCCore team
doesn't use the fpcUnit testing framework. At that stage, I thought
using fpcUnit was the logical choice as it shipped with FPC.
- simple example -
TRTLTestSuite= class(TTestCase)
published
[...]
procedure Bug1234;
end;
implementation
procedure TRTLTestSuite.Bug1234;
begin
Fail('Write your own test');
end;
--
Having had a look at a few random tests, they are really short and to
the point, so shouldn't take much time to convert to fpcUnit.
Graeme.
--
There's no place like 127.0.0.1
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Definition of the time-fration in a TDateTime before 30/12/1899
On Mon, 2006-05-22 at 23:06 +0200, Graeme Geldenhuys wrote: > On 5/22/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: > > From Greame I would like to know how he proposes to update the > > TestSuite, if a new tests it added. > > I am busy looking at the /tests directory now, to understand how tests > get grouped. This should give me a clearer idea of what is possible. > It took us a while to get a decent test structure for our code as > well. > > I agree that certain tests will have to stay in the format they are in > now. Things that shouldn't compile, etc... All other tests could be > group in test suites. RTL suite, FCL suite, etc.. > Maybe Dean Zobec has some ideas on this too. Dean? > > I like the idea you guys have of using the Bug Report Number as the > test name. This could be done with fpcUnit as well and should make > tracking of what tests have been converted to fpcUnit quite easy. > eg: Lets say we have a bug #1234 in the RTL. Edit the RTL suite, by > adding a new method to the test class and the same naming convention > could be used. No extra objects / classes need to be created, just a > new method needs to be added. Even the person reporting the bug could > write a simple fpcUnit test and submit that to Mantis, which can then > be copied into the correct suite. I submitted a couple of simple > fpcUnit test cases to show a bug, until I found out the FPCCore team > doesn't use the fpcUnit testing framework. At that stage, I thought > using fpcUnit was the logical choice as it shipped with FPC. Attached you can find an example for how this could be implemented. The fpcunittests program runs all tests. It get those tests from the testunits.inc file. Use the gentestunits.sh script to generate that include file and fill it with all files names test*.pp. (bash/unix only. Maybe put this in a sort of makefile-system, if that's possible?) So to add a new unit with tests, name it test*.pp and place it in the same dir as the rest and run the script. The output is XML, but we could easily add a resultswriter which generates plain text like a logfile. A unit with 'bug2345' test could be added easily. I've made a dateutils-test for my last changes. One test still fails, I have a patch ready for that, will send that tomorrow. What do you guys think? Regards, Joost. ps: No, Bram's patch for EncodeDate didn't get applied fpcunittests.tgz Description: application/compressed-tar ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding constants to defines.inc (windows)
On 5/21/06, Giulio Bernardi <[EMAIL PROTECTED]> wrote:
Should they be merged or left separate from the others?
I mean, something like:
SPI_SETWORKAREA = 47;
{ Windows Me/2000 and higher }
SPI_GETACTIVEWINDOWTRACKING = 4096;
I think it is a a good thing to add this small comment about the
availability of the constant. Not mandatory, but a good thing.
Comments are exactly hints for the person reading the code.
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] shared libraries on x86_64 Linux ?
> -Message d'origine- > De : Florian Klaempfl [mailto:[EMAIL PROTECTED] > Envoyé : lundi 22 mai 2006 19:56 > À : [EMAIL PROTECTED]; FPC developers' list > Objet : Re: [fpc-devel] shared libraries on x86_64 Linux ? > > Dominique Leducq wrote: > > Hello, > > > > I'm new to this list (and to Free Pascal...) > > > > What are the news from bug #6618 (ex 4733), on building shared libraries > on a x86_64 architecture? > > http://www.freepascal.org/mantis/view.php?id=6618 > > > > I did some tests, and it seems to bee still present in 2.0.2 and current > 2.1.1 snapshot (I encountered no problems with i386). > > In the BTS I see that the status is still new,open, and there seems to > have been no activity on this bug since its submission. > > > > I also had a look at the thread "Hitting bug 4733" on this list > > http://lists.freepascal.org/lists/fpc-devel/2006-April/007514.html > > and to > http://community.freepascal.org:1/bboards/message?message_id=152498&fo > rum_id=24083 > > in the forums (AMD64 shared library link problem) > > > > Has anybody had a look at it? > > If yes, does it seem to be hard to fix? > > The problem is that we don't want to compile the default rtl with PIC. > > > Is it the PIC generation that is broken for x86_64? > > Afaik not. > > > Please tell me if there are any plans on the matter. I'm quite willing > to help, but would appreciate a little help... > > You simply need to rebuild the rtl with PIC. [Dominique Leducq] Well, I already tried that with 2.0.2 : make rtl "OPT=-Cg" (is that right ?), but it didn't work (yes, I checked that the right system unit was used by the linker) I will try again with 2.1.1 I had nothing to recompile to make it work with i386 linux: is the default RTL compiled with PIC for i386? If so, why not for x86_64? I know that there are performances losses with PIC, but I thought that this losses where lessened with x86_64 arch? > > > > > Thanks a lot, > > > > Dominique Leducq > > > > > > > > ___ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-devel > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
