My apologies Jason. I totally miss understood what you meant in your
first email! The second post explained it much better. Yeah, it's
Friday - my brain was already in weekend mode, but my body stuck at
the office. A terrible situation to be in. :-)
Regards,
- Graeme -
On 29/09/06, Jaso
On 29/09/06, Пётр Косаревский <[EMAIL PROTECTED]> wrote:
> I would first port one or
> two of the top 10 threading applications that was submitted to Borland
> in a Threading Contest which Borland held in 2002. Search Borland's
> CodeCentral or I could post the link. There are some good threadin
On 29/09/06, Micha Nelissen <[EMAIL PROTECTED]> wrote:
There is no bug. The time slice management is simply different. Try
attached demo (it's your demo modified). You will notice that output
will be mixed.
Linux simply gives longer timeslices to threads (for efficiency reasons).
Micha
Ah, f
Graeme Wrote:
>Thanks Jason - I don't recall you mentioning what platform you are working
>on, but I gather in is some *nix platform. The only thing you just proofed
>with your post is - threading is not working correctly!
>There shouldn't be a need for workarounds like suspending threads to get
> I would first port one or
> two of the top 10 threading applications that was submitted to Borland
> in a Threading Contest which Borland held in 2002. Search Borland's
> CodeCentral or I could post the link. There are some good threading
> examples available. :-)
I have troubles searching. Pl
Graeme Geldenhuys wrote:
> The Sort Demo, which is a port of the Threads demo included with
> Delphi 7, shows this clearly. I can archive and post the source, but
Try inserting some Sleep(0) to force the kernel to switch to another
thread ? In real worker threads you wouldn't do this of course, b
Graeme Geldenhuys wrote:
> We have a problem!!!
>
> The test project /fcl/tests/threads.pp as well as a Sort Demo (Bubble,
> Section and Quick Sort) all execute the threads in sequence, waiting
> for the previous thread to complete, before the next one executes.
> Kind of defeats the point of usin
Am Freitag, den 29.09.2006, 19:00 +0200 schrieb Graeme Geldenhuys:
> Thanks Jason - I don't recall you mentioning what platform you are
> working on, but I gather in is some *nix platform. The only thing you
> just proofed with your post is - threading is not working correctly!
>
> There shouldn'
Thanks Jason - I don't recall you mentioning what platform you are
working on, but I gather in is some *nix platform. The only thing you
just proofed with your post is - threading is not working correctly!
There shouldn't be a need for workarounds like suspending threads to
get others to work. T
Some rambling observations:
> I was fighting the serial execution - and then I ran that little tiny test
> program - and it worked. I tried to fix my code some more - same problem -
> but the little test program worked... so I finally (this is what I mean
> when
> I say I resigned to design chang
Hi - I read enough of this topic to compel me to respond.
I have been working with Multi-threading in Free Pascal for a only a month
or so now and I learned a great deal - and I have resigned to accepting
there are design considerations I have had to adopt to get the results I
wanted - that some
On 9/29/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
> What is LLVM?
Check this out: http://llvm.org
Cheers,
Krishna
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 29/09/06, Krishna <[EMAIL PROTECTED]> wrote:
Why not target LLVM instead?
What is LLVM?
Regards,
- Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 9/29/06, Adrian Maier <[EMAIL PROTECTED]> wrote:
By the way : why dotnet and not java ? At least java has been
around for a longer
time, and there are compatible jdk's for more platforms ... So we
wouldn't have to
deal with differences like those between Mono and the .Net platform.
The Lazarus team is glad to announce the 0.9.18 release. This release is
based on fpc 2.0.4.
This release can be downloaded from the sourceforge download page:
http://sourceforge.net/project/showfiles.php?group_id=89339
Detailed list of changes:
lazbuild: There is now a command line tool to comp
On 9/29/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote:
I know writing FPC port for .Net is far from easy. But the difficulty should
be on compiler code side only. On the user/app code, it shouldn't cause
significant changes. Since Delphi and FPC has same language root, object
pascal, I wonder why e
> On Fri, 29 Sep 2006, Bisma Jayadi wrote:
> The .NET CLR does not know the 'untyped pointer' type. That means that a
> lot of RTL code must be rewritten; if not most of it. I'm not saying it
> can't be done, but none of the core developers sees this as a need or even
> a challenge.
Moreover, yo
On Fri, 29 Sep 2006, Bisma Jayadi wrote:
> > Current text:
> > There is nothing practical known yet about how portable an average .NET code
> > will be. Little experiments with hello world level code mean nothing, that
> > kind of code works with plain C too.
> >
> > Proposed text:
> > There is
> Why Delphi has no problem supporting .Net without sacrificing backward
> compatibility (too much)?
There is a problem.
> If I'm not mistaken (CMIIW), during Borcon 2005, Borland demoed a Delphi 1
> application (the famous FishFact demo) that can be run on .Net by simply
> recompile it on BDS 2
Current text:
There is nothing practical known yet about how portable an average .NET
code will be. Little experiments with hello world level code mean
nothing, that kind of code works with plain C too.
Proposed text:
There is nothing practical known yet about how portable an average .NET
cod
On 29/09/06, Vincent Snijders <[EMAIL PROTECTED]> wrote:
All gui stuff I run on windows. Non visual test apps, I can run on linux too.
If I really want I could do GUI in linux too, but I don't know too much about
gtk
and I rather spent time on improving things on the windows platform.
No prob
> I think the supposed advantage of portability should be refuted more clearly.
> I
> think object pascal code compiled with fpc is more portable than the
> Delphi.NET
> code. I propose the following change.
>
> Current text:
> There is nothing practical known yet about how portable an average
I read the .NET FAQ http://www.freepascal.org/faq.html#dotnet.
I think the supposed advantage of portability should be refuted more clearly. I
think object pascal code compiled with fpc is more portable than the Delphi.NET
code. I propose the following change.
Current text:
There is nothing p
23 matches
Mail list logo
