On 05/13/2015 11:16 AM, Sven Barth wrote:
You do know that there exist other synchronisation primitives beside
the event queue? And since the TParallel.For itself is a blocking call
I highly suspect that they *don't* use the event queue, but TEvent and
similar instead.
If using other
Mark Morgan Lloyd wrote on Wed, 13 May 2015:
That particular machine self-destructed, so I don't have an adequate
record of what versions of gld/ld were installed. A rebuilt system
using the SunFreeware libraries etc. (which are for Solaris 10
rather than 11) appears to be OK, except that
Am 13.05.2015 11:11 schrieb Michael Schnell mschn...@lumino.de:
And for the widgetsets: The VCL was never designed to be cross platform
in contrast to te LCL. It would have meant immensely more work for
Embarcadero to port the VCL to Mac, Android, etc. than to buy a third part
solution and to
On 05/12/2015 06:43 PM, Marco van de Voort wrote:
Will the fpc library provide the appropriate classes for doing
TParallel.For as described ?
That will depend on when you submit that patch :-)
This of course triggers my standard answer to such wording:
It does make sense to first decide
Am 13.05.2015 10:53 schrieb Michael Schnell mschn...@lumino.de:
On 05/12/2015 05:39 PM, Sven Barth wrote:
Why should that interfere in any kind?! Behind the scenes it's propably
using TThread anyway...
Because Foreground code (here the calls made by the visible code the
user creates to use
On 05/12/2015 05:49 PM, Sven Barth wrote:
Their own .Net compiler has shown that one can't simply map the
Delphi language to the CLR 1:1 and expect something seamless. We see
that with FPC's JVM support as well. So using a variant of the
language that embeds itself into the framework is a
Jonas Maebe wrote:
Mark Morgan Lloyd wrote on Wed, 13 May 2015:
That particular machine self-destructed, so I don't have an adequate
record of what versions of gld/ld were installed. A rebuilt system
using the SunFreeware libraries etc. (which are for Solaris 10 rather
than 11) appears to be
On 05/12/2015 05:39 PM, Sven Barth wrote:
Why should that interfere in any kind?! Behind the scenes it's
propably using TThread anyway...
Because Foreground code (here the calls made by the visible code the
user creates to use TParallel) and the background code in the
threads that
08.05.2015 у 10:20 Georg Hieber напісаў:
Anton,
Which version (build) of the compiler / rtl did you use?
This looks like an error that should have been fixed some time ago.
BR, Georg
Dear Georg!
I've used 3.1.1 svn trunk cherry-picked at 05 of May.
Binutils/libc were from Debian Jessie
Am 12.05.2015 um 22:15 schrieb Alfred:
Hello,
I would like to inform you that the interfacertti branch contains the
wrong patch !
E.g for i386, it implements:
ti386paramanager.get_para_regoff
but it should be:
tcpuparamanager.get_para_regoff
This is valid for all implemented architectures
In our previous episode, Michael Schnell said:
On 05/12/2015 06:43 PM, Marco van de Voort wrote:
Will the fpc library provide the appropriate classes for doing
TParallel.For as described ?
That will depend on when you submit that patch :-)
This of course triggers my standard answer to such
What is supposed to happen if the 2nd argument is negative?
program Project1;
uses sysutils;
var a: LongInt;
begin
a := StrToInt('-1');
WriteLn(2 a);
WriteLn(2 -1);
ReadLn;
end.
prints:
0
4294967296
2 a translates to shl eax,cl (cl being loaded with the result
from strtoint)
So at least
Mark Morgan Lloyd wrote:
I'm taking a minimal look at OpenSXCE, which is a compilation of Illumos
(formerly Open Solaris 11 etc.) for SPARC. I've already got SPARC
Solaris 10 running, so am able to see what's different rather than being
confused by a completely unfamiliar platform.
With a
13 matches
Mail list logo
