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

Re: Kylix now officially alive?


2004-12-11 06:54:08 PM
kylix2
theo < XXXX@XXXXX.COM >wrote:
Quote
>Anyways, for the LCL/Lazarus FPC is enough else lazarus wouldn't work, so where is the point?

www.freepascal.org/bugs/db.php3
;-)
Wrong: we're talking about the compiler, not the rtl/fcl/ide/lcl whatever and about i386/linux, right :)?
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.
Quote
>The LCL/Lazarus is 1.2 Mio lines of code and grows fast; so keeping Delphi/Kylix compatibility might be even a full time job.
>

I don't know how much work it would be. Maybe Andreas Hausladen could
tell us.
The problem isn't making the patches once but keep them up-to-date. I'am involved in OSS development for 12 years and I learned one lesson: 90 per cent of the people providing a patch to add this or that feature disappear after this one time contribution. This is fine, if somebody contributes some component, whatever. But if it effects the whole project, it must but discussed deeply which was done regarding compiling the lcl with delphi.
 
 

Re:Re: Kylix now officially alive?

Florian Klaempfl wrote:
Quote
.. If you compare the chain FPC-FPC/RTL-FCL-LCL-Lazarus with
Kylix/Delphi you'll find out that the FPC compiler itself is the only
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.
Quote
..
The Free Pascal Compiler (FPC) is collection of beautiful and well
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
 

Re:Re: Kylix now officially alive?

Quote
If you compare the chain FPC-FPC/RTL-FCL-LCL-Lazarus with Kylix/Delphi you'll find out that the FPC compiler itself is the only thing which plays in the same league with Delphi/Kylix. Neither the FPC/rtl nor FCL/LCL nor Lazarus do so.

Example: While FPC now and do threads in any target environment, there
is no TThread.synchronize yet in LCL on Linux, so the porting of many
Delphi applications is prevented.
-Michael
 

{smallsort}

Re:Re: Kylix now officially alive?

On 2004-12-10, oro06 <"oro06 at sf ">wrote:
Quote
Marco van de Voort wrote:
>On 2004-12-09, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
>
>They think it is not maintainable in a productive way. That is something
>else then not wanting it.

FPC and Lazarus are wonderful projects and i'm sure that it is this kind
of rare gems that create the solid base of open source. thank you for
that, thank you for your time.

but do you consider that 50 000 thousand line of code deployed vlc-based
prog can be reasonably migrated to fpc/lzs today ?
What other serious choice do you have, if you want to go forward? Long term
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.
Quote
it is not a long term need it's a TransitioN need , i mean many of us
think to migrate to linux but day to day requirements (and bread to
earn) make this reality : no time -for the moment- to spend one thousand
hours to have a deep linux/X knowledge and therefore migrating under
windows is a first step migration on a KnowN system - non accumulation
of all difficulties at the same time.
That's a touch decision. However these tens of thousands of lines were
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.
Quote
and you could be sure that having a dual plateform delphi/fpc-lazarus
compatible will result with thousand of users that will :
-migrate
-find bugs
-workaround/patch suggestion
I doubt it. It will more probably deluge us in bugreports, and except for a
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.
Quote
and the result will be :
Continuation and Improvement of all wonderful work you did !

It is like fish and fisher discussions last year concerning European
Community : No fish, No fisher :)
FPC buys the bait, and still no fish is more like it I'm afraid.
 

Re:Re: Kylix now officially alive?

On 2004-12-13, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>If you compare the chain FPC-FPC/RTL-FCL-LCL-Lazarus with Kylix/Delphi you'll find out that the FPC compiler itself is the only thing which plays in the same league with Delphi/Kylix. Neither the FPC/rtl nor FCL/LCL nor Lazarus do so.

Example: While FPC now and do threads in any target environment, there
is no TThread.synchronize yet in LCL on Linux, so the porting of many
Delphi applications is prevented.
However implementing it is several magnitudes work less than the alternative
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.
 

Re:Re: Kylix now officially alive?

Quote
>Example: While FPC now and do threads in any target environment, there
>is no TThread.synchronize yet in LCL on Linux, so the porting of many
>Delphi applications is prevented.


However implementing it is several magnitudes work less than the alternative
of maintaining huge source code bases multi compiler.
I'm sure it's quite easily doable.
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
 

Re:Re: Kylix now officially alive?

On 2004-12-17, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>>Example: While FPC now and do threads in any target environment, there
>>is no TThread.synchronize yet in LCL on Linux, so the porting of many
>>Delphi applications is prevented.
>
>
>However implementing it is several magnitudes work less than the alternative
>of maintaining huge source code bases multi compiler.

I'm sure it's quite easily doable.
tthread.synchronize implementation has been picked up again by Micha. He already
had a proposal patch, but we are now adapting it for inclusion.
Quote
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")....
There is POSIX ipc. Afaik that reasonbly works for the *nixes.
 

Re:Re: Kylix now officially alive?

"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
On 2004-12-17, Michael Schnell < XXXX@XXXXX.COM >
wrote:

>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")....

There is POSIX ipc. Afaik that reasonbly works for the *nixes.
Or my favourite, sockets.
 

Re:Re: Kylix now officially alive?

Quote
>There is POSIX ipc. Afaik that reasonbly works for the *nixes.


Or my favourite, sockets.


Ok. sockets (hopefully) are usable by the same code on all platforms.
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
 

Re:Re: Kylix now officially alive?

"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
Quote
>>There is POSIX ipc. Afaik that reasonbly works for the *nixes.
>
>
>Or my favourite, sockets.
>
>

Ok. sockets (hopefully) are usable by the same code on all platforms.
But as a means for simple thread communication
Just for the sake of being a geek, thread communication is slightly
different than inter-process communication.
Quote
I think they impose more
overhead than other means (e.g. messages), especially on Windows.
Not so sure about that, not disagreeing, just not so sure.
Quote
OTOH messages are easy to use and available on all platforms, too.
Using different mechanisms though, sockets are more generic there, for me
anyway.
Quote
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
Again, I believe the OP was asking about inter-process comm.
Quote
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):
Depends specifically what you're after of course, which I'm sure you kow.
Quote
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.
Sockets allow environment-agnostic, cross-platform, cross-architecture,
blah, blah, blah, independent of development language etc. In spite of all
the objective claims, I'll admit to being obviously biased as well.
Quote
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.
That's implicit in Windows, isn't it? Or I'm missing what you mean. What
about the windows message queue?
Rob
 

Re:Re: Kylix now officially alive?

Quote
>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.


That's implicit in Windows, isn't it? Or I'm missing what you mean. What
about the windows message queue?

AFAIK, in Delphi/Windows the event mechanism is built using Windows
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
 

Re:Re: Kylix now officially alive?

Quote
>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.


That's implicit in Windows, isn't it? Or I'm missing what you mean. What
about the windows message queue?

Hmm, in Delphi/Windows/VCL you hook a message with
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
 

Re:Re: Kylix now officially alive?

On 2004-12-22, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>>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.
>
>
>That's implicit in Windows, isn't it? Or I'm missing what you mean. What
>about the windows message queue?

AFAIK, in Delphi/Windows the event mechanism is built using Windows
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.
Neither do I. I also don't know if it is really necessary to duplicate that.
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.
Quote
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).
Yeah, so you just want to be able to postmessage custom messages, and have
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.
Quote
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.
No, tthreads have no handlers afaik. So that is another point, not only from
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.
 

Re:Re: Kylix now officially alive?

Quote
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.
Unix usually uses blocking I/O. So you don't need messages but you will
need to use threads even the more. Do (3) becomes more important.
Quote
3. Which leaves user messages.

Maybe it indeed is a decent way to implement user inter-thread messages
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.
Quote
Also what info a message can contain must be carefully considered.

However I'd have to study Unix messaging systems first.


I suppose the stuff above would take care of these issues.
Quote
So that is another point, not only from
thread to main, but also from main to tthread and tthreads amongst
eachother.
... and from the main thread to a TThread.
Should be not to hard to add when doing the TThread ->Main Thread thing
the way above.
-Michael
 

Re:Re: Kylix now officially alive?

On 2004-12-27, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>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.

Unix usually uses blocking I/O. So you don't need messages but you will
need to use threads even the more. Do (3) becomes more important.
IPC, since the classic unix server model forks a new process, doesn't create
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.
Quote
>3. Which leaves user messages.

Maybe it indeed is a decent way to implement user inter-thread messages
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.
The problem is how you send something to a thread without polling.
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?
Quote
I suppose the stuff above would take care of these issues.

>So that is another point, not only from
>thread to main, but also from main to tthread and tthreads amongst
>eachother.

... and from the main thread to a TThread.
Uh, that is "main to tthread" isn't it ? :-)
Quote
Should be not to hard to add when doing the TThread ->Main Thread thing
the way above.
As said, main is special in other ways. However that could be dealt with
in a tthread derivative.