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
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
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
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
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
/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
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
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
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
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
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.
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
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
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.
> 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
15 matches
Mail list logo
