Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 01:40, Frank Church wrote: As the solution doesn't seem to be too difficult which file or files can we zoom in on to fix it? Thanks for showing interest in this. I know near zero about Makefiles and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now use fpmake everywhere? If yes, then why are there still so many Makefiles in FPC Trunk? Quite possibly I just don't understand the use of fpmake I guess. The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known latest stable compiler version constant, then report an error and terminate. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Seems Delphi is moving to Java-style primitive types
Well, kind-of... I don't know if C# also supports this (like Java). It
probably does, because for the last few years, Delphi has just been
copying whatever is in C#. [sad]
eg: This compiles and works in Delphi XE3.
ShowMessage('Hello World!'.ToUpper);
And there are lots more string functions (like .ToUpper) out of the box.
http://www.youtube.com/watch?v=ndeJeBdZQIwfeature=sharelist=UUStifH8LUsnsTQNcT_BDTVw
It actually uses record helpers, but the end result looks very much like
Java primitive types where you have type.ToString, type.Equals,
type.Split etc...
Interesting.
Regards,
- Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
Graeme Geldenhuys wrote: On 2012-10-17 01:40, Frank Church wrote: As the solution doesn't seem to be too difficult which file or files can we zoom in on to fix it? Thanks for showing interest in this. I know near zero about Makefiles and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now use fpmake everywhere? If yes, then why are there still so many Makefiles in FPC Trunk? Quite possibly I just don't understand the use of fpmake I guess. The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known latest stable compiler version constant, then report an error and terminate. Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Perhaps we need something like FORCE=1 to allow a minor version bump to be accepted, or FORCE=1.1 to accept anything up to 2.7.1. However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for compilation. Ditto for Lazarus, it shouldn't be necessary to delve into the source to find this. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 17 Oct 2012, at 10:53, Graeme Geldenhuys wrote: The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known latest stable compiler version constant, then report an error and terminate. See http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg25868.html and the rest of the thread. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
Am Wednesday 17 October 2012 11:10:22 schrieb Mark Morgan Lloyd: Graeme Geldenhuys wrote: On 2012-10-17 01:40, Frank Church wrote: As the solution doesn't seem to be too difficult which file or files can we zoom in on to fix it? Thanks for showing interest in this. I know near zero about Makefiles and Makefile.fpc. I'm still a bit confused with FPC though. Does FPC now use fpmake everywhere? If yes, then why are there still so many Makefiles in FPC Trunk? Quite possibly I just don't understand the use of fpmake I guess. The idea seems quite simple though. Do a `$compiler -iV` where $compiler is the starting compiler use to compile the FPC source code. If that version doesn't match a known latest stable compiler version constant, then report an error and terminate. Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Perhaps we need something like FORCE=1 to allow a minor version bump to be accepted, or FORCE=1.1 to accept anything up to 2.7.1. ACCEPTEDVERSION=x.x.x also could be a flexible solution. However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for compilation. Ditto for Lazarus, it shouldn't be necessary to delve into the source to find this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpmake compiles the same unit multiple times
Hi, I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be honest I don't really use it, but to keep it up to date. Anyway, I noticed that if I do a 'fpmake build', that fpmake compiles many of my units multiple times. Anywhere from 2-4 times. I double checked my fpmake.pas unit, and I haven't added those units multiple times in the code, so why is fpmake building them more than once? The fpmake.pas unit in question can be viewed at the following URL with your web browser: https://github.com/graemeg/fpGUI/blob/master/src/fpmake.pas Belowo you can see the fpmake output. The first part is going well... units are only compiled once. But then later most units are compiled 2-4 times?? [src (wip)]$ ./fpmake build -UG /home/graemeg/devel/fpc-2.6.0/x86_64-linux/lib/fpc/2.6.0/units/x86_64-linux/ Start building package fpgui for target x86_64-linux. Compiling corelib/fpg_base.pas Compiling ./corelib/x11/fpg_impl.pas Compiling corelib/fpg_main.pas Compiling ./corelib/x11/fpg_interface.pas Compiling ./corelib/x11/fpg_x11.pas Compiling ./corelib/x11/fpg_xft_x11.pas Compiling ./corelib/x11/fpg_netlayer_x11.pas Compiling corelib/fpg_main.pas Compiling ./corelib/x11/fpg_interface.pas Compiling corelib/fpg_imgfmt_bmp.pas Compiling corelib/fpg_utils.pas ...snip... Compiling gui/fpg_spinedit.pas Compiling gui/fpg_spinedit.pas Compiling gui/fpg_colorwheel.pas Compiling gui/fpg_colorwheel.pas Compiling gui/fpg_colormapping.pas Compiling gui/fpg_colormapping.pas Compiling gui/fpg_editbtn.pas Compiling reportengine/u_command.pas Compiling reportengine/u_pdf.pas Compiling reportengine/u_report.pas Compiling reportengine/u_command.pas Compiling reportengine/u_visu.pas Compiling reportengine/u_reportimages.pas Compiling reportengine/u_reportimages.pas Compiling reportengine/u_pdf.pas Compiling reportengine/u_report.pas Compiling reportengine/u_report.pas Compiling reportengine/u_visu.pas Compiling reportengine/u_visu.pas [100%] Built target fpgui Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Seems Delphi is moving to Java-style primitive types
17.10.12, 17:00, Graeme Geldenhuys пишет: Well, kind-of... I don't know if C# also supports this (like Java). It probably does, because for the last few years, Delphi has just been copying whatever is in C#. [sad] ... Interesting. This was already discussed here or fpc-devel list. Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 10:10, Mark Morgan Lloyd wrote: Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could. The fixes branch is mislabelled. Contrary to the name, not only fixes get applied to that branch. In recent months, more and more minor new features got added to the fixes branch too. Perhaps we need something like FORCE=1 to allow a minor version bump to be accepted, or FORCE=1.1 to accept anything up to 2.7.1. This is exactly what I mentioned too, but only for very specific cases (though I don't know if such cases exist). Allow a --force or something parameter to allow the developer to use a different starting compiler (thus ignoring the version check), but ONLY if they know what they are doing. However the thing that's really needed in my opinion is a clear statement for each SVN tag which FPC version should be used for That will be a ridiculous amount of work. The existing rule of always using the latest released FPC as the starting compiler is good enough. Regards, Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On 17 Oct 2012, at 12:08, Graeme Geldenhuys wrote: I'm using FPC 2.6.0 and have a fpmake.pas program for fpGUI. To be honest I don't really use it, but to keep it up to date. Anyway, I noticed that if I do a 'fpmake build', that fpmake compiles many of my units multiple times. Anywhere from 2-4 times. I double checked my fpmake.pas unit, and I haven't added those units multiple times in the code, so why is fpmake building them more than once? fpmake does not know about unit dependencies, so it compiles all units once. The compiler may however already compile a unit earlier on because it's required by another unit. At least the trunk version of fpmake supports automatically generating a build unit that simply adds all the to be compiled units to the uses clause. It then compiles only this build unit, so that every unit will be compiled only once. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 10:15, Jonas Maebe wrote: See http://www.mail-archive.com//msg25868.html and the rest of the thread. [embarrassed] Clearly my age is starting to show. :-) How do you find this old messages in any case. Your concern about cross-compiling could be an exception - FPC version restriction is not applied in such cases. Cross-compiling in by far the less used option. Most people that complain about this issue is simply trying to compile a new FPC version for their current target. The --force or --ignore-fpc-version option could still help those corner cases, like new platforms where a previous released version did not exist. The developers working on such features should know what they are doing anyway, so fits in with my earlier statement too. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On 2012-10-17 11:17, Jonas Maebe wrote: fpmake does not know about unit dependencies, Ah OK. Thanks for the explanation. So if I ordered my units better in the fpmake program, then that might reduce the multiple compiling too. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Seems Delphi is moving to Java-style primitive types
On 2012-10-17 11:15, Paul Ishenin wrote: This was already discussed here or fpc-devel list. The video was about Delphi XE3, which just got release... was this Delphi functionality already existing in earlier Delphi versions too? [sorry, I don't keep up with every Delphi feature any more] Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Seems Delphi is moving to Java-style primitive types
Am 17.10.2012 12:31 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk: On 2012-10-17 11:15, Paul Ishenin wrote: This was already discussed here or fpc-devel list. The video was about Delphi XE3, which just got release... was this Delphi functionality already existing in earlier Delphi versions too? Yes, it's a Delphi XE3 feature, but XE3 isn't that new anymore either. In fact I already have a proof of concept implementation working for FPC (constants are not yet supported though) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
Graeme Geldenhuys wrote: On 2012-10-17 10:10, Mark Morgan Lloyd wrote: Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could. Graeme, I know what policy is. However I'd point out that right now you /need/ 2.6.1 to compile FPC for SPARC due to code generation issues, and there have previously been similar problems with ARM while FP stuff was work-in-progress. So saying if it won't compile with stable then sod off isn't helpful. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: problems compiling FPC
On 17-10-2012 12:49, Mark Morgan Lloyd wrote: Graeme Geldenhuys wrote: On 2012-10-17 10:10, Mark Morgan Lloyd wrote: Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could. Graeme, I know what policy is. However I'd point out that right now you /need/ 2.6.1 to compile FPC for SPARC due to code generation issues, and there have previously been similar problems with ARM while FP stuff was work-in-progress. So saying if it won't compile with stable then sod off isn't helpful. Mark, I understand what you mean. Regardless of the way Graeme put his point, I think having: - a rough check on latest stable compiler - a way to force the makefile to override the check for people who need this such as SPARC users) will lessen the amount of problems significantly Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
Reinier Olislagers wrote: On 17-10-2012 12:49, Mark Morgan Lloyd wrote: Graeme Geldenhuys wrote: On 2012-10-17 10:10, Mark Morgan Lloyd wrote: Some slack would be desirable: stable is 2.6.0 but there are known issues which are fixed by 2.6.1. Nope, the FPC developers made the rules quite clear! Not even the fixes branch is guaranteed to compile FPC Trunk. ONLY the last released FPC is guaranteed. I have even stumbled over this too, where the fixes branch couldn't compile FPC Trunk, but the latest released version could. Graeme, I know what policy is. However I'd point out that right now you /need/ 2.6.1 to compile FPC for SPARC due to code generation issues, and there have previously been similar problems with ARM while FP stuff was work-in-progress. So saying if it won't compile with stable then sod off isn't helpful. Mark, I understand what you mean. Regardless of the way Graeme put his point, I think having: - a rough check on latest stable compiler - a way to force the makefile to override the check for people who need this such as SPARC users) will lessen the amount of problems significantly I agree, I was only arguing with the dogmaticism of Graeme's assertion. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
On 2012-10-17 12:43, Marco van de Voort wrote: It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel all target, the required version is also kept there (toplevel Makefile.fpc as only place). Nice, works perfectly here under 64-bit Linux. Tested compiling latest Trunk with FPC 2.6.0 and FPC 2.6.1. I haven't tested cross-compiling, but the OVERRIDEVERSIONCHECK option did work when I used FPC 2.6.1 Hopefully that will be the end of this popular problem. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] problems compiling FPC
On 2012-10-17 11:49, Mark Morgan Lloyd wrote: So saying if it won't compile with stable then sod off isn't helpful. That's definitely not how I meant for it to sound [the joys of email conversations]. Reinier summed up my thoughts. Default behaviour is to only allow last released FPC version, but there must be an option to force an override or disable the version check (for special cases like you mentioned, or for cross-compiling purposes). Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
In our previous episode, Reinier Olislagers said: work-in-progress. So saying if it won't compile with stable then sod off isn't helpful. Mark, I understand what you mean. Regardless of the way Graeme put his point, I think having: - a rough check on latest stable compiler - a way to force the makefile to override the check for people who need this such as SPARC users) will lessen the amount of problems significantly http://www.stack.nl/~marcov/toplevelMakefile.fpc.patch Don't forget to regenerate makefile after applying It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel all target, the required version is also kept there (toplevel Makefile.fpc as only place). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
On 17 Oct 2012, at 14:54, Jonas Maebe wrote: I think it's annoying that you then have to type OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even more: it will suggest that building a cross-compiler should also be done starting with the latest release, while in fact it they should be built using a native compiler built from the same svn version. Therefore I don't think think that we can check anything in case of cross-building. Also, maybe the printed message should be more explicit about the fact that using the latest release is the only supported way to bootstrap the compiler, and that OVERRIDEVERSIONCHECK=1 must only be used if you know for a fact that the starting compiler was built from the same sources that you are currently compiler. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
On 2012-10-17 13:54, Jonas Maebe wrote: ...whenever you build a cross-compiler. Even more: it will suggest that building a cross-compiler should also be done starting with the latest... Simply update the error message to say that the version check rules might not apply to newly implemented platforms, or for cross-compiling. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
In our previous episode, Jonas Maebe said: It is kept simple on purpose. Only works on toplevel makefile (easy to maintain), only on the toplevel all target, the required version is also kept there (toplevel Makefile.fpc as only place). I think it's annoying that you then have to type OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Yes. I already experimented by ifndef CROSSCOMPILE, but that is also when not cross-architecture. Even more: it will suggest that building a cross-compiler should also be done starting with the latest release, while in fact it they should be built using a native compiler built from the same svn version. Therefore I don't think think that we can check anything in case of cross-building. Ok. Then it is actually easier, and it is just a matter of disabling it totally for CROSSCOMPILE=1. I expected more complicated rules there. Another problem I came up with is that the system compares textually, and thus immediately after 2.6.2 release will only allow one of those two (2.6.0 or 2.6.2), not both to allow for a graceperiod of a few weeks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On Wed, 17 Oct 2012, Graeme Geldenhuys wrote: On 2012-10-17 11:17, Jonas Maebe wrote: fpmake does not know about unit dependencies, Ah OK. Thanks for the explanation. So if I ordered my units better in the fpmake program, then that might reduce the multiple compiling too. If you specify the dependencies right, it should figure out the order by itself. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On 2012-10-17 14:18, michael.vancann...@wisa.be wrote: If you specify the dependencies right, it should figure out the order by itself. I tried but it seems impossible, especially with uses clause pulling in other dependencies. I then tried fpmake from FPC 2.7.1... WOW, that made a huge difference in compiling speed, and all units were compiled only once. So it seems that to improve fpmake with FPC 2.6.0 is a lost cause, as 2.7.1 works so much better without any extra effort. Anyway, it wasn't a major issue to start with, I was just curious as to why there was so many duplicate compilations. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
In our previous episode, Jonas Maebe said: OVERRIDEVERSIONCHECK=1 whenever you build a cross-compiler. Even more: it will suggest that building a cross-compiler should also be done starting with the latest release, while in fact it they should be built using a native compiler built from the same svn version. Therefore I don't think think that we can check anything in case of cross-building. Also, maybe the printed message should be more explicit about the fact that using the latest release is the only supported way to bootstrap the compiler, and that OVERRIDEVERSIONCHECK=1 must only be used if you know for a fact that the starting compiler was built from the same sources that you are currently compiler. New text: D:\repo\fpcmake all makefile:2717: *** The only supported starting compiler version is 2.6.0. You are trying to build with 2.7.1. If you are absolutely sure that the current compiler is built from the exact same version/revision, you can try to use OVERRIDEVERSIONCHECK=1 to override . Stop. + a ifndef crosscompile around the whole version check. I thought about the 2.6.0-2.6.2 transition, but it is easy to temporarily wrap another version check around it for a few weeks. More work, but not a problem. (just needs documentation in rel_eng) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
2012/10/17 Marco van de Voort mar...@stack.nl: D:\repo\fpcmake all makefile:2717: *** The only supported starting compiler version is 2.6.0. You are trying to build with 2.7.1. If you are absolutely sure that the current compiler is built from the exact same version/revision, you can try to use OVERRIDEVERSIONCHECK=1 to override . Stop. + a ifndef crosscompile around the whole version check. I thought about the 2.6.0-2.6.2 transition, but it is easy to temporarily wrap another version check around it for a few weeks. More work, but not a problem. (just needs documentation in rel_eng) Alternatively, it could just be a warning. Then if it fails later, the complete output will show the reason. Then OVERRIDEVERSIONCHECK is not necessary anymore. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
On 2012-10-17 15:57, Vincent Snijders wrote: Alternatively, it could just be a warning. Then if it fails later, the complete output will show the reason. I disagree. To prevent any strange side-effects (undefined behaviour), the version check should happen as early as possible - before any compiling commences. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: problems compiling FPC
In our previous episode, Vincent Snijders said: I thought about the 2.6.0-2.6.2 transition, but it is easy to temporarily wrap another version check around it for a few weeks. More work, but not a problem. (just needs documentation in rel_eng) Alternatively, it could just be a warning. Then if it fails later, the complete output will show the reason. True, but I think that will only resolve something in such a low number of cases that it is makes the whole effort negiable. IOW that defeats the purpose of the check IMHO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Seems Delphi is moving to Java-style primitive types
C# is a full OO language, so I guess yes it's supported. Anyway, Delphi doesn't seem to move toward Java, but Embarcadero is missing Anders' touch. And this is the way they get it for free :p -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Seems-Delphi-is-moving-to-Java-style-primitive-types-tp5711555p5711583.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Seems Delphi is moving to Java-style primitive types
It actually uses record helpers, but the end result looks very much like Java primitive types where you have type.ToString, type.Equals, type.Split etc... Not with the intent to be contrary, but for the sake of clarity in discussion, String in Java is not a primitive type; it is a full-fledged class like any other except the compiler has a couple pieces of special knowledge about it. That is why it can have methods. The actual primitive types such as short, int, long, etc., do not have methods. However, this must not be confused with the boxed form of the primitive types, which again are full-fledged classes (Integer, Long, etc.) and have methods. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
