Graeme Geldenhuys schreef:
On 28/09/06, Vincent Snijders [EMAIL PROTECTED] wrote:
I know about this report:
http://www.freepascal.org/mantis/view.php?id=1906
Threading related, but not the same, as you are not using synchronize,
are you?
Vincent
Do you mean like below - which then means, I
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
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
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 2005.
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 nothing
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, you
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
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
On 9/29/06, Adrian Maier [EMAIL PROTECTED] wrote:
not_serious_suggestion
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
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, 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
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
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 changes)
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.
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't be
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 using
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,
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.
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
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 threading
20 matches
Mail list logo
