Re: [fpc-devel] I get duplicate GUIDs under Linux
Why can't FPC automatically call randomize() in the RTL. Put it in some initialization section. That way, at application startup, randomize() is already called and only Random() needs to be used? Please not! This would hamper all kinds of scientific, statistical and financial modelling. For all those (and more) it is sometimes necessary to have a *reproducable* random distribution. There's more to random than random ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
Isn't that exactly what is done in C++? It is prepared in library code. On 10/14/2014 12:40 PM, Marco van de Voort wrote: I recently had to dive a bit into C++ again, and reconnected with a feature I liked at first sight, the C++ covariance of virtual methods (changing the return type of a overriden method to a descendant of the original type). Googling a bit it seems that some languages(C#) also seem to allow this for parameters. (not just return types) I suddenly wondered why it was never proposed or talked about for FPC, since it seems such a nice feature. Is there something particularly wrong with it? To a certain degree it can be emulated with generics, but that it requires a generic for every type, and must be prepared in the library code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
This is known. I forgot a bit about my rasp, but I will try to make a new build + build instructions within a week. The warnings can be -partially - ignored though... Tnx Paul, maybe we can coordinate this? On 10/17/2014 1:02 PM, Paul Michell wrote: On Friday 17 Oct 2014 11:35:30 Henry Vermaak wrote: fpmake.pp(46) Warning: crti.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtbegin.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtend.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtn.o not found, this will probably cause a linking failure Where are these files on your system? I remember after multiarch happened on debian I had to add some library paths to get fpc to link. This sounds like a similar issue. They do not exist in my FP directory tree. However there are copies in the Raspian /usr/lib tree here: /usr/lib/arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/arm-linux-gnueabihf/crtn.o Thanks, Paul ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
That may be true, but takes tricks. The compiler from me WILL build trunk, because it is a trunk. I do not have much time but as I stated before i WILL update it. It just takes a bit longer. Also, I won't do a full .deb for it, unless some helps with that. I wasn't able to do that yet and do not have experience with package building for Debian.. My starting compiler still will compile trunk with OVERRIDEVERSIONCHECK=1. This is a temporary solution until 2.8 is released and the debian guys will accept the latest stable 2.8 (which is a long way off, I understand): debian won't accept 2.71, because it is experimental. Raspbian follows Debeian. Debian is rightfully slow in accepting anything but the most stable and release versions. Debian will almost never accept anything else. Point is: to obtain best results on the Raspberry Pi, you WILL need the latest FPC. It is really a great compiler for the platform. The instructions I wrote still work as of 28898 (todays checkout) Thaddy On 10/23/2014 2:11 AM, peter green wrote: Pierre Free Pascal wrote: https://archive.raspbian.org/raspbian/pool/main/f/fpc/ The 2.6.4 release is able to successfully compile a 2.7.1 trunk compiler. :) Thanks for confirming. Several files are missing in this source release: The source package which is made up of fpc_2.6.4+dfsg-4+rpi1.dsc , fpc_2.6.4+dfsg-4+rpi1.debian.tar.xz and fpc_2.6.4+dfsg.orig.tar.gz does contain the files you mention. To extract it you use dpkg-source -x on the dsc file. This is the source used to build the deb files. The binary package fpc-source exists primerally for the benefit of lazarus users, it appears to contain more than is needed for lazarus use but not enough to actually build the compiler which does seem a bit strange. This is not raspbian specific, the packages in debian are the same way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. Maybe the guy(s) or/and girl(s) who have done the original build for the Raspberry Pi can shed a light on that one... On 10/23/2014 10:55 AM, Thaddy de Koning wrote: Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Which means you shut out the platform. Which is a teaching platform. On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, By never saying that people should build trunk with trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. On 10/23/2014 11:10 AM, Jonas Maebe wrote: On 23/10/14 11:00, Thaddy de Koning wrote: At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. The real starting compiler is a cross-compiler. You always have to start using a cross-compiler when building for a platform on which the previous release is not available. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Not for ARMV6 EABIHF On 10/23/2014 11:23 AM, Jonas Maebe wrote: On 23/10/14 11:16, Thaddy de Koning wrote: I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Bad practise is the only practise if knowledge about good practise is not available. I am fully prepared to accept you are right. In fact, in my professional settings I would not do otherwise. But this is a special case, for a huge platform, and somebody, somehow, forgot about the license Because the starting compiler for Raspbian is not available.. That's the point: In war ( I am a former tank commander when it was still relevant for an 19 year old) You improvise when resources are not available. I agree with you. Get it? But where's the stuff we can use to do it properly? My stuff works, is based on trunk, but not usable? Ofcourse not. This goes to the core of the project: either one sticks to the rules, or one deviates from it. This is a blatant case of GPL ignorance, since the starting compiler is not made available. And the compiler is GPL'd THAT'S my point. On 10/23/2014 11:16 AM, Jonas Maebe wrote: On 23/10/14 11:09, Thaddy de Koning wrote: On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: Plz advice on how to progress, By never saying that people should build trunk with trunk. Which means you shut out the platform. I'm not saying you can't provide any downloads, nor that Debian/Raspbian must remove their custom patched 2.6.4 releases. I'm only saying that you should never encourage people to build trunk with trunk for the reasons that I have explained many times before. Which is a teaching platform. So don't teach them bad practices that will get them into trouble. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bitset assembler
Before I answer that: did you check what assembler code the compiler generates? That may be just as efficient as handcoded assembly in this case. With the proper optimizations it will probably hard to improve on. Compile the code with -O4 and -s. That generates the assembler output in a *.s file. The compiler is rather good at bitmaniputations. > Hello to all assembler experts, > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error seeking resources when copiling with {$R *.res}
On Fri, 4 Nov 2016 11:46:24 +0200 (EEST)
{$R *.res} in ONLY allowed for the project file.
You should never try to link in a * resource in a unit, because the *
resolves to the main project name.
Same as in Delphi.
If you need a resource in a unit, resolve the full name, like {$R
myunit1.res}
The main *.res is available over all units in a project.
"NetSpirit"
wrote:
> CONDITIONS
> Unit file contains {$R *.res} directive. File *.res exists in the same
> directory where *.pp file for unit exists.
> Compiled units resides in subdirectory, for example called
> 'units' (-FU command line switch).
>
> DESCRIPTION
> When project with such unit compiled first time - all work as
> expected. Compiled *.ppu files goes to 'units', resulting binary
> created.
>
> On the second and next compilations we encounter en error:
> "Error: Can't open file 'D:\projectpath\units\Unit1.res'".
>
> This error is a result of searching *.res in a directory where
> compiled units exists, but not in a directory where unit source file
> resided.
>
> FPC VERSION: FPC 3.0.0, precompiled binaries for win32, win64
> OS: Windows
>
> TEST PROJECT:
> Demo project for this bug in attach or download here:
> http://rgho.st/8GRBWVWcM
> (Extract all files to disk; correct path to your FPC in
> 'compile.bat'; run 'compile.bat' two times)
>
>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
Of course 64 and 32 bit are the sizes, not the platform! That may not be clear. On 5/24/2017 9:35 AM, Thaddy de Koning wrote: Jonas, sorry for the late response: The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_. Because you seem to have implemented it or most of it. It renders a mathematical comparable distribution in the negative to the positive values. In both Turbo Pascal as in Delphi and because they use a different algorithm and made an implementation error as well, the negative values are indeed not defined. But that's because of the algorithm and because of the implementation by Borland (yes, it stems from Borland times). The Mersenne Twister we use is also valid for negative values and if you want I can send you the mathematical proof. I already made the LCG in Delphi compatible mode available on the wiki and that implementation differs in so far as that it corrects the "undefined for negative values" for that algorithm too. It is 100% compatible for the Delphi documented range, btw. I am busy evaluating important Random implementions for different languages, so an FPC library is available for data that is generated in a different language and relies on a particular PRNG. Also note that the output of the current random is strictly valid for 32 bit only. In my code I already added a 64 bit version. Regards, Thaddy On 5/20/2017 2:57 PM, Jonas Maebe wrote: On 20/05/17 14:36, Martin Schreiber wrote: Is this intended? If not, which one is correct? random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
Jonas, sorry for the late response: The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_. Because you seem to have implemented it or most of it. It renders a mathematical comparable distribution in the negative to the positive values. In both Turbo Pascal as in Delphi and because they use a different algorithm and made an implementation error as well, the negative values are indeed not defined. But that's because of the algorithm and because of the implementation by Borland (yes, it stems from Borland times). The Mersenne Twister we use is also valid for negative values and if you want I can send you the mathematical proof. I already made the LCG in Delphi compatible mode available on the wiki and that implementation differs in so far as that it corrects the "undefined for negative values" for that algorithm too. It is 100% compatible for the Delphi documented range, btw. I am busy evaluating important Random implementions for different languages, so an FPC library is available for data that is generated in a different language and relies on a particular PRNG. Also note that the output of the current random is strictly valid for 32 bit only. In my code I already added a 64 bit version. Regards, Thaddy On 5/20/2017 2:57 PM, Jonas Maebe wrote: On 20/05/17 14:36, Martin Schreiber wrote: Is this intended? If not, which one is correct? random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimizing unused return values of inline functions
> On 21.08.2017 13:22, Michael Van Canneyt wrote:
>>
>>
>> On Mon, 21 Aug 2017, Benito van der Zander wrote:
>>
>>> Hi,
>>>
This pattern is not inherently efficient. Why should it be ?
>>>
>>>
>>> It is not efficient, because of the pointless instruction!
>>
>> I am not speaking of the current FPC implementation. It may well be that
>> the
>> code is not most optimal.
>>
>> I am asking, why do you think *this pattern* (of always returning self)
>> should be inherently more efficient ?
>
> The pattern definitely has its uses. E.g. in the user space of our
> operating system at work we have a StdOutPrinter class that is used like
> this:
>
> === code begin ===
>
> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
> ")->hex()->out(42)->line();
>
> === code end ===
>
> Each function returns again the instance that was returned by
> StdIO::stdOutPrinter().
>
> The whole pattern is called method chaining or fluent interface:
> - https://en.wikipedia.org/wiki/Method_chaining
> - https://en.wikipedia.org/wiki/Fluent_interface
>
> Regards,
> Sven
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
E.g. KOL is based on this (or very close). The core methods always return
self.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
