Board index » kylix » Re: Kylix now officially alive?

2004-12-11 06:54:08 PM
kylix2
theo < XXXX@XXXXX.COM >wrote:
www.freepascal.org/bugs/db.php3
+ 4 in the categorie crash
+ 11 regression test failures
Most of them are very subtible and definitivly doesn't effect the lcl like alignment problems with sse2 inline assembler.
 

Florian Klaempfl wrote:
thing which plays in the same league with Delphi/Kylix. Neither the
FPC/rtl nor FCL/LCL nor Lazarus do so. The reason is simply: the
compiler itself is the first thing done, so it's most mature.
organised Pascal code. While, I think that the FPC could improve
compatibility (for practical reasons) with Delphi-Pascal (Kylix) the
very important thing is that FPC is capable to compile for many
different processors and platforms and this superior qualities
shouldn't be compromised. Another thing is that there is the compiler
source code accessible, so it can be modified for a special purpose,
it also gives stability and comfort of knowing that the future of the
product is secured. The Kylix compiler is also very nice and mostly
trouble free, but it only compiles for x86/Linux and there is no any
serious indication that it will be developed and maintained any
further by the owners of it. Specially it is hard to imagine that it
will be possible to compile with Kylix for different platforms in a
near future. There is already the x86-64 prototype of FPC, but we do
not know anything about Kylix compiler venture into 64bit world.
There is another very very interesting Pascal like compiler worth to
mention: Component Pascal which permits creation of Java bite code...
(and .NET) that's right.. you write you application with “Pascal?
and the output is a Java class (that's portability). It would be nice
to incorporate and/or develop further this Component Pascal ideas to
FPC or perhaps to the future version of Kylix compiler, if any...
juliusz
--
InstallMade - Kylix-specific installer
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

is no TThread.synchronize yet in LCL on Linux, so the porting of many
Delphi applications is prevented.
-Michael
 

{smallsort}

On 2004-12-10, oro06 <"oro06 at sf ">wrote:
IMHO none. Short term simply using (Cross) Kylix is good enough.
Adding delphi would make the result unproductive, and both would stall.
We tried this for the FPC compiler, and I can clearly remember the troubles,
it was _NOT_ fun due to Delphi bugs. The other way around will also be true,
Delphi people will find workarounds and minor imcompabilities annoying.
already designed on Linux. So the knowledge of the Kylix system is there.
Going back to windows is a step back, since that will effectively decrease
linux knowledge anymore.
select few, nothing more. These select few, if they wanted, have the
capabilities to use Lazarus with FPC anyway.
So effectively this will mean the already overstressed FPC and lazarus
coreteams can do the grunt work to keep some legacy applications running at
a minimum of effort of its users, while a commercial vendor got the big
bucks. I also think an alternative solution will ever be enough for people
that refuse to dive into the matter.
I prefer the serious users to cross over. IMHO no one can save the other ones
in the long run except Borland, if they were to take Kylix out of fridge.
 

On 2004-12-13, Michael Schnell < XXXX@XXXXX.COM >wrote:
of maintaining huge source code bases multi compiler.
If there are problems, they are more in the DB subsystem. However since that
is proprietary Borland technology, it will hard to get that right, and
before you do, you can't integrate it into LCL/Lazarus anyway because of FPC
compability.
 

A year ago, I tried to start to work together with the maintainer of the
TThread Linux stuff on "synchronize", but unfortunately he said he is
too busy with other activities, so that he can't be helpful at the
moment. And I'm not into the internals enough to do the plunge right by
myself :( .
Additionally, I'd like to see some platform independent interprocess
communication means that don't need to stall the worker thread (e.g.
Delphi "messages")....
-Michael
 

On 2004-12-17, Michael Schnell < XXXX@XXXXX.COM >wrote:
had a proposal patch, but we are now adapting it for inclusion.
 

"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
 

But as a means for simple thread communication I think they impose more
overhead than other means (e.g. messages), especially on Windows.
OTOH messages are easy to use and available on all platforms, too.
Windows is message driven by design and in Linux we have System V
message queues. Moreover it's quite easy to desingn a process internal,
pure user land inter-thread message passing mechanism in Pascal based on
semaphores. You can even use a standard TList as a message queue here.
So we "only" need appropriate support in the language/RTL/LCL (simiar to
what Delphi offers as well with VLC as with CLX (though not identically
on the two):
1) A platform independent function to send a message fram the main
thread or a TThread to a TThread and to the main thread.
2) A platform independent function that waits for a message in a TThread
3) A platform independent function that peeks into a message queue if a
message has arrived (to be used in a TTHread).
4) A platform independent way to have an main Thread event fired if a
message arrived.
Additionnaly fireing an event in a TThread when a message arrives would
be great, but I suppose a TThread "event scheduler" would need to be
designend for this.
-Michael
 

"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
different than inter-process communication.
anyway.
blah, blah, blah, independent of development language etc. In spite of all
the objective claims, I'll admit to being obviously biased as well.
about the windows message queue?
Rob
 

system means: there is no message scheduler in the RTL but Windows is
doing this for the Delphi program. I don't know how this is done in
Kylix/Linux or in Free Pascal on either OS.
When you want to fire a standard Delphi language event (in the main
thread) from a TThread, you can do this by hooking a message to an event
in the main thread and then sending a message from a TThread.
But it's not doable with the same code in Delphi and in Kylix and,
AFAIK, when using FP you need to create different code for Windows and
for Linux. So my request is a common language or RTL internal function
for this (like "TThread.Synchonize but without stalling the TThread).
AFAIK, in Delphi/Windows you can't create an event in a TThread and fire
it by sending a message from the main thread or another TThread to same.
-Michael
 

type
TForm1234 = class(TForm)
procedure Message1234(var Message: TWMChar); message 1234;
in a TForm type declaration.
So a message sent to the Window that is created by a (the only) instance
of TForm1234 arrives, fires the Message1234 event.
In a TThread you are not allowed to use any VCL functions that do any
Window handling and thus, AFAIK, you can't create a Window in a thread.
That means that you can't attach an event to a message in the Delphi/VCL
way.
-Michael
 

On 2004-12-22, Michael Schnell < XXXX@XXXXX.COM >wrote:
Windows puts all events
1 GUI internal.
2 I/O, including some forms of networking
3 user messages
And
1. is already solved in e.g. Lazarus by a cascade of plain procedure of
objects, instead of handling that in the OS.
2. is mostly not appopriate for *nix.
3. Which leaves user messages.
Note that the simple facts that there are less UI msgs, and that they are not handled by the
msg system, means that the messages system can be much lighter.
them handled by message handlers using the "message" kw? I can see that, I
use those in my Indy code too. (and typically don't use synchronize)
Also what info a message can contain must be carefully considered.
However I'd have to study Unix messaging systems first.
thread to main, but also from main to tthread and tthreads amongst
eachother.
I doubt this will happen soon, but if I happen to have to dig into this, I'll
keep your remarks in the back of my head.
 

need to use threads even the more. Do (3) becomes more important.
completely in Pascal using TThreadList as a queue. I seem to remember
that I somewhere found an extension to TThreadList to improve its
performance when used as a FIFO queue by doing the housekeeping only
each n deletes.
This leaves a single event that is to be fired on behalf of a semaphore
(TEvent) freed by a thread, i.e. by adding an "OnFired" event property
to TEvent.
Should be not to hard to add when doing the TThread ->Main Thread thing
the way above.
-Michael
 

On 2004-12-27, Michael Schnell < XXXX@XXXXX.COM >wrote:
threads. (windows: relative cheap threads, expensive processes, unix other
way around)
Classic Unix TCP/IP servers don't need much communication, so it depends
on the app if you need it.
The way it is done in Delphi only works for the main thread since that one
is event driven in principle (and latency is avoided via
application.processmessages), and, less important, has got a message window
Threads don't (maybe they have something to send msgs too, but that's why
that one is less important). So what will maintain and poll that event queue
in a tthread?
Do you envision a special event driven thread type that contains this
system, analogue to the application object for the main thread?
in a tthread derivative.