Board index » kylix » I - The Challenge

I - The Challenge


2005-03-14 04:08:25 AM
kylix0
Let's face it: Kylix is dead - desipte all the nice words we hear from Borland.
The FreeCLX project has not shown a sign of live yet, Delphi 05 has dropped CLX
alltogether and due to the NET 2.0 / Compact framework / Windows XY work Danny
and the Delphi team at Borland have to do, we won't get an update for Kylix in
near future (if ever). Additionally mono support of Delphi is pretty much non-
existant and the QT shipped with Kylix will soon be outdated by two majour
versions.
It's only due to us (most notably Andreas of course) that Kylix still runs on
Linux. However, this can not go on forever, as the class libraries (SOAP, WEB)
are outdating with each day passed even more and FreeCLX can't replace current
commercial CLX due to license and component issues.
The FPC guys have their own feature and class library set and are not willing to
build a bridge for current Kylix users to use their compiler (with CLX) in
future. Besides, even if they did, we still would have the problem of the CLX
being unsupported and the fpc compiler lacking some features (AFAIK).
In short, developing Delphi compatible applications that run on Linux is quite
impossible now and in no case future proof. It's a dying platform.
As you probably can imagine, I can not stand this situation: I like to have my
pet language (and framework) and I'm willing to invest time to reach this
goal.
So here is the idea: Jump on the Mono bandwagon and implement a Delphi com-
patible compiler plus add the VCL.NET (or CLX.MONO if you like) on top of
GTK#.
You might think "he's gone crazy now" or something along that line. It's obvious
that our small community can not build and maintain a class library (CLX, RTL,
WEB...), an IDE with De{*word*81} and a compiler at the same time (even if we would
have the source code), but let me explain why I think this idea is worth the
effort and why I think we can reach the goal:
Let us look at the chosen platform at first: Mono (or .NET). The downside of
course is that we don't get native executables if we take this path, but
because Novell stands behind this project with some full time employees, we
can be pretty sure that the platform will evolve. IIRC there is even a
version of python that runs on .NET. Regardeless - this downside is at the
same time also a very important strength: We will have to support only one
platform (.NET) that itself runs on all machines and operating systems Mono
is ported to.
Even more important is the key aspect of .NET, namely the "freedom of language":
Every line of C# code that is added to the mono libraries is automatically
available in Pascal. Basically this means that we only have to care about VCL -
everything else is done by other people not part of our project. It also means
we have a complete basic library from project start and can concentrate on
other things.
After the platform, it's probably the managed compiler that will need most
efforts. So let's think about it: As I see it (and please correct me if I'm
wrong here), we do not need to start from scratch. On the one hand there's the
Free Pascal Compiler that we can fork from and on the other hand we can use code
from the Mono C# compiler. If we take the Free Pascal approach, we can use
Delphi.NET for bootstrapping and I assume that the FPC community will be helpful
when we're hitting a wall. Going that route will probably be most beneficial as
we will get the ultimate unit test plus - by incorporating the FPC code base -
the complete experience of several million lines compiled Pascal code.
At the end we'll have our own Delphi compiler that probably won't be as fast or
efficient as Borland's product, but it will be future proof and truely ours.
(Note that we only have to emit IL-Assembler and let the dirty work do the
mono tool..)
All the things said above are - obviously - only half the fun, because without
any meaningful CLX.NET wrapper we get nowhere from Kylix. Personally I'd really
like to see CLX.NET on top of GTK# (which is the true Mono widget set) as this
would make an end to the desasterous license issues we have with QT. It might be
whishful thinking, but maybe Borland donates the old (complete) CLX under some
LGPL license, so we would not have to start from scratch and understands that as
new-old "Community Project".
Borland would not lose anything by doing that because practically noone is using
the CLX today - plus Borland does not update CLX and the CLX itself is
completely outdated. Additionally Borland would get a VCL.NET compatible wrapper
for GTK# for free while only having to maintain VCL.NET... This would - in turn
- also strengthen the position of Delphi on Windows.
I think this is a fair deal.
Now we have the compiler, the glue framework - but the package still lacks the
IDE: Fortunately there's MonoDevelop with included de{*word*81} that will only need
a few modifications to support Pascal as new language. Integrating the CLX.NET
will be more time consuming, but in the end we will only have to maintain the
"Pascal" part of the IDE: The rest already has a team responsible for it.
If you made it all the way down here, you're certainly interested and I want to
hear from you! What do you think about this? Can you imagine contributing some
pieces? Can you imagine taking over some part? Will you join the team?
To answer the question for myself: I'm terribly interested in compilers, so I'd
be happy to be part of the compiler team. I do have some insight into the mono
JIT engine and can help introducing new mono users to the Mono JIT code base.
I'm also the "owner" of a sourceforge project (if it's not deleted in the mean
time) that would be suitable for the compiler.
Now how about you?
Thanks,
Willi
P.S.: I'm also "discussing" the compiler issue on the mono-devel list.
 
 

Re:I - The Challenge

On 2005-03-13, Willibald Krenn < XXXX@XXXXX.COM >wrote:
Quote
The FPC guys have their own feature and class library set and are not willing to
build a bridge for current Kylix users to use their compiler (with CLX) in
future. Besides, even if they did, we still would have the problem of the CLX
being unsupported and the fpc compiler lacking some features (AFAIK).
While true, I wonder if you could specify AFAIK a bit more?
Quote
In short, developing Delphi compatible applications that run on Linux is quite
impossible now and in no case future proof. It's a dying platform.
It's uncertain. That is something else than dying.
Quote
As you probably can imagine, I can not stand this situation: I like to have my
pet language (and framework) and I'm willing to invest time to reach this
goal.
Then start working. Where are your freeclx contributions btw?
Quote
So here is the idea: Jump on the Mono bandwagon and implement a Delphi com-
patible compiler plus add the VCL.NET (or CLX.MONO if you like) on top of
GTK#.
First.
You can't create a Delphi compiler in .NET. Period. You can only
create a Delphi.NET compiler. Different horse.
Second. How long you think is this going to take? Do we grant you as much
time as you gave the current FreeCLX effort?
Third. It sounds a bit odd that there is an initiative to start from rock bottom
nothing, that is considered easier than efforts that have come a long way.
Fourth. Why you? What makes you so special that we would trust you over proven efforts
of Andreas, Simon and the decade old FPC team? A bit of cheap advocacy and dreaming is
quickly put together, but what do you actually have to show, that justifies trust in
this project? A start? Other projects you've done of this magnitude?
Quote
You might think "he's gone crazy now" or something along that line.
Can you read minds :_)
Quote
It's obvious that our small community can not build and maintain a class
library (CLX, RTL, WEB...), an IDE with De{*word*81} and a compiler at the
same time (even if we would have the source code), but let me explain why
Yes. However in the current situation we at least have parts of this.
Quote
Let us look at the chosen platform at first: Mono (or .NET). The downside of
course is that we don't get native executables if we take this path, but
because Novell stands behind this project with some full time employees, we
can be pretty sure that the platform will evolve
The most serious downside of course is that the current Kylix sources we are
all so anxious to keep working, have to be thrown out.
This because the widget set is different, OS interfacing has to be
rewritten, and the language is so different it doesn't even support a basic
language feature pointers.
Quote
IIRC there is even a version of python that runs on .NET.
What a wonder for a language one inch above a scripting language!
Quote
Regardeless - this downside is at the same time also a very important
strength: We will have to support only one platform (.NET) that itself
runs on all machines and operating systems Mono is ported to. Even more
important is the key aspect of .NET, namely the "freedom of language":
As long as it is a variant of C# with a slightly different syntax of course.
This is not entirely true, e.g. there are functional .NET languages, but
show me a typical solidly compiled language that can be compiled to
(managed) .NET without mods to the sourcecode, and I'll take that back.
(Wasted enough time on this cheap advocacy attempt)
 

Re:I - The Challenge

Marco van de Voort wrote:
Quote
but show me a typical solidly compiled language that can be
compiled to (managed) .NET without mods to the sourcecode, and I'll take
that back.
Simple VCL application to VCL.NET :-)
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

{smallsort}

Re:I - The Challenge

Marco van de Voort schrieb:
Quote
>The FPC guys have their own feature and class library set and are not willing to
>build a bridge for current Kylix users to use their compiler (with CLX) in
>future. Besides, even if they did, we still would have the problem of the CLX
>being unsupported and the fpc compiler lacking some features (AFAIK).


While true, I wonder if you could specify AFAIK a bit more?
As far as I know - or - last time I heared. I don't know if things have changed
recently, because I don't follow the FPC development.
Quote
>In short, developing Delphi compatible applications that run on Linux is quite
>impossible now and in no case future proof. It's a dying platform.


It's uncertain. That is something else than dying.
In Delphi 2005 support for CLX was dropped; Borland announced the community
project months ago, but nothing has surfaced so far. We have to work with a
class library that is outdated and Borland did not even care to donate us a new
QT binding. There was no compiler update and no IDE update. I wonder what
happens if everything will be NPTL only. There are officially no plans for Kylix
for this year AFAIK and it's questionable if thereafter Kylix even exists.
What else do you call this than dying? Phasing out?
The next thing Borland will do is to announce a new Kylix that compiles
applications for the managed runtime of mono/whatever, so that Borland can reuse
the Delphi.NET compiler. I'm pretty sure there won't be any new native Delphi
compiler for Linux in future and I highly doubt that the CLX will be used in
it's current form if Borland decides to introduce a new version of Kylix.
Quote
>As you probably can imagine, I can not stand this situation: I like to have my
>pet language (and framework) and I'm willing to invest time to reach this
>goal.


Then start working. Where are your freeclx contributions btw?
I won't ever contribute to FreeClx, because it's GPL ONLY! I can not work with
that license and even if I could, very important parts are missing. But if you
want, I can show you my backported unofficial CLX patches for Delphi 6. I hope
that counts in your eyes, even if it's not FreeCLX related and not GPLed.
Quote
>So here is the idea: Jump on the Mono bandwagon and implement a Delphi com-
>patible compiler plus add the VCL.NET (or CLX.MONO if you like) on top of
>GTK#.


First.
You can't create a Delphi compiler in .NET. Period. You can only
create a Delphi.NET compiler. Different horse.
You know what I meant. Surely the semantics of the language change a bit, but it
has changed all over time...
Quote
Second. How long you think is this going to take? Do we grant you as much
time as you gave the current FreeCLX effort?
Well, honestly, I can't say how long it will take - this depends on many things.
BTW: You're always talking about the current FreeCLX effort - other than Andreas
working on a QT 3 binding, that is GPL only (and therefore has some quite
limited use) and does not solve the IDE and compiler problem, I can't see any
efforts. All I did notice was the announcement that something inside Borland has
to be done. This was months ago. Since then nothing - except Andreas' screens -
happened. Lastly the FreeCLX effort is about the CLX - but what about the
compiler, the IDE? Do we have the source for these?
Quote
Third. It sounds a bit odd that there is an initiative to start from rock bottom
nothing, that is considered easier than efforts that have come a long way.
What efforts do you mean?
FreeCLX is crippled and GPL only, the CLX patches are no real solution because
it's still Borland's code, so we'll never be able to set up a public repo with
all the CLX files and fix/improve on that. Simon's cross compiler is cool,
because that eliminates the Kylix IDE, but if you want to develop under Linux
this doesn't help. FPC's framework will always be some island: Not Delphi/Kylix
compatible, not .NET compatible.
Realistically - what choices do we have? .NET/Mono is pretty much the only
answer I can think of.
It's cross platform, the architecture more or less Delphi(.NET) compatible, it
has people working on it full time and last, but not least, it's minimizing our
work while maximizing our access to third party libraries. I consider
FPC/Lazarus to be much more work than implementing a Kylix.Mono compiler on top
of the CLI with the addition of some CLX.NET on top of GTK# and some additional
stuff to make the Mono IDE Pascal aware. (If it was not for Kylix compatibility,
you would not even need the CLX.NET)
Quote
Fourth. Why you? What makes you so special that we would trust you over proven efforts
of Andreas, Simon and the decade old FPC team? A bit of cheap advocacy and dreaming is
quickly put together, but what do you actually have to show, that justifies trust in
this project? A start? Other projects you've done of this magnitude?
This is just ridiculous. Just because I'm not Andreas or part of the FPC team
you seem to think I can't do anything. Besides it's an open source project, so
hopefully there will be a team with the same goal and not just *me*.
But to answer your question: Sure, I've not done the 'big' thing yet! Until
today I've more experimented with things:
I was part of the Delphi Web Scripting team and made some proof of concept
implementation of using native Delphi packages from within DWS scripts without
any additional software layer (= writing wrappers). I thought this was pretty
cool stuff, but .NET was quicker.
In another project I experimented with a C version (Kylix 3 actually) of Martin
Waldenburg's Delphi parser to extend the Delphi language with simplistic
generics. (Compile Delphi+Generics to normal Delphi.) It's this project which I
now want to revive with different goals.
I did a D6 interface compatible backport of Andreas' patches that you can
download from my homepage. (Not quite up to date I'm afraid.) You can also find
scripts to re-build your D6 runtime packages there.
Lately I investigated the topic continuous optimization in mono and added some
initial continuous optimization framework for Mini on AMD64. (Not in the
official tree, the 100k patch that will surface on mono-devel waits for admin
approval due to size.)
I started Pascal back in the Turbo Vision days and I'm since {*word*60}ed.
Quote
>You might think "he's gone crazy now" or something along that line.


Can you read minds :_)
At least something I can do *g*..
Quote
>Let us look at the chosen platform at first: Mono (or .NET). The downside of
>course is that we don't get native executables if we take this path, but
>because Novell stands behind this project with some full time employees, we
>can be pretty sure that the platform will evolve


The most serious downside of course is that the current Kylix sources we are
all so anxious to keep working, have to be thrown out.

This because the widget set is different, OS interfacing has to be
rewritten, and the language is so different it doesn't even support a basic
language feature pointers.
CLR has limited support for pointers, but well. On the RTL side of things, I
agree, lots of changes are necessary, but the RTL is more or less part of the
compiler; On the positive side: We probably can use parts of the existing C#
compiler backend of Mono. Plus we get the complete framework, a working JIT
(Linux 32/64, Windows 32, Sparc, MAC AFAIK) and a non GPLed widget set.
It's the large and ever growing framework that makes this approach so
beautifully in the long run. What do we currently have for Kylix on 3D party
components?
Furthermore we only have to make this change once, afterwards we get every
single new platform for free.
Quote
>IIRC there is even a version of python that runs on .NET.


What a wonder for a language one inch above a scripting language!
IronPython IIRC was first seen as proof of concept why it can't be done, but
turned out as proof of concept 'it can be done'.
Even more
Quote
>important is the key aspect of .NET, namely the "freedom of language":

As long as it is a variant of C# with a slightly different syntax of course.
This is not entirely true, e.g. there are functional .NET languages,
All modern (strongly typed) languages have more or less the same concepts with
some exceptions. Java, Delphi, C# - all are somewhat similar.
but
Quote
show me a typical solidly compiled language that can be compiled to
(managed) .NET without mods to the sourcecode, and I'll take that back.
Andreas already mentioned VCL.NET; But anyways this is the wrong question,
because every new platform introduces the need of modifying the source here and
there. Take Delphi Windows (VCL) and Kylix (CLX) as an example..
Quote
(Wasted enough time on this cheap advocacy attempt)
I know that you strongly dislike the .NET framework.
Regardeless, there is interest on the mono-devel list for a free Delphi compiler
for Mono, so I think the compiler part already stands. It's just a question of
the CLX.NET now, I guess.
Willi
 

Re:I - The Challenge

Quote
If you made it all the way down here, you're certainly interested and I
want to
hear from you! What do you think about this? Can you imagine
contributing some
pieces? Can you imagine taking over some part? Will you join the team?
There will always be a soft spot in my heart for Delphi. However, given
that Kylix has been abandoned and Delphi is moving towards .net and away
from Win32/Win64, The best advice I would have would be to install
Lazarus on your machine, subscribe to the developer's newsgroup and help
it grow. Test it, find a problem, report it and include the fix. The
community is energized there and its exciting to be a part of it.
Think of it as Kylix 4.0. After all Kylix had its roots in open source.
Maybe things will change around here. Maybe Borland could somehow work
with the Lazarus team. Until then, Lazarus is my new home.
 

Re:I - The Challenge

Willibald Krenn wrote:
Quote
Regardeless, there is interest on the mono-devel list for a free Delphi
compiler for Mono, so I think the compiler part already stands. It's
just a question of the CLX.NET now, I guess.
Better make a VCL.NET for Mono. CLX applications are not that far away
from VCL. And the CLX is not really a good framework to reimplement. It is
a crippled Delphi 5 VCL.
And "procedure xxx(var Msg: TMessage); message xxx" is the better approach
that to override EventFilter.
Qt3/CLX is a patch against the original CLX. In other words: If you own a
valid commercial copy of Kylix and Qt 3 you can do anything the Borland
no-nonsens and the Qt 3 commercial license allow you to do.
But Qt3/CLX is far away from being released.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:I - The Challenge

You are not the first to think along these lines.
see:
www.chromesville.com/
You can already request a beta version for testing from them.
You also should read the newsgroup remobjects.public.chrome
-Michael
 

Re:I - The Challenge

Andreas Hausladen wrote:
Quote
Willibald Krenn wrote:

>Regardeless, there is interest on the mono-devel list for a free
>Delphi compiler for Mono, so I think the compiler part already
>stands. It's just a question of the CLX.NET now, I guess.

Better make a VCL.NET for Mono. CLX applications are not that far away
from VCL. And the CLX is not really a good framework to reimplement.
It is a crippled Delphi 5 VCL.

And "procedure xxx(var Msg: TMessage); message xxx" is the better
approach that to override EventFilter.

Qt3/CLX is a patch against the original CLX. In other words: If you
own a valid commercial copy of Kylix and Qt 3 you can do anything the
Borland no-nonsens and the Qt 3 commercial license allow you to do.
But Qt3/CLX is far away from being released.
You seem to be incapable of saying that with the Qt3/CLX patches you
cannot create a commercial closed source product without buying a
commercial licence from Trolltech. The above statement is as close to
it as you have been.
B
 

Re:I - The Challenge

On 2005-03-13, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
Quote
Marco van de Voort wrote:

>but show me a typical solidly compiled language that can be
>compiled to (managed) .NET without mods to the sourcecode, and I'll take
>that back.

Simple VCL application to VCL.NET :-)
Breaks on the first pointer.
 

Re:I - The Challenge

On 2005-03-14, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
Quote

And "procedure xxx(var Msg: TMessage); message xxx" is the better approach
that to override EventFilter.
Not really. The first requires a message based event system.
 

Re:I - The Challenge

On 13 Mar 2005 23:19:58 -0800
"Andreas Hausladen" < XXXX@XXXXX.COM >wrote:
Quote
And "procedure xxx(var Msg: TMessage); message xxx" is the better approach
that to override EventFilter.
How do EventFilters work? Messages are yucky and slow, so I cannot imagine it being better than something else ;-).
Micha
 

Re:I - The Challenge

Marco van de Voort wrote:
Quote
>Simple VCL application to VCL.NET :-)

Breaks on the first pointer.
You must have missed the word "Simple" ;-)
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:I - The Challenge

Micha Nelissen wrote:
Quote
Messages are yucky and slow, so I cannot imagine it being better than
something else
Messages have syntax support in Delphi.
Quote
How do EventFilters work?
A QObject has two methods: event() and eventFilter(). If a X11 or Win32
message occurs the platform dependent code translates it to an event. This
event is then sent to the QApplication where QApplication checks for
installed eventFilters and passes the unprocessed event to all
eventFilters installed for QApplication until one returns True (=Handled)
or the last QApplication eventFilter has passed. Then the event is sent to
the receiver. The receiver passes the event to all eventFilters which are
installed for the receiver and if non of them return True the event it
passed to event() where the widget reacts on it.
Because Delphi/Kylix cannot override the virtual QObject::event() method
Borland decided to install a hook object that redirects the eventFilter()
method to a cdecl function pointer (the place where CLX can hook in).
eventFilters are a great thing but you have to write long "case of"
statements where you can simply use a message method for a message based
system.
The best solution meight be a combination of both.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:I - The Challenge

On 2005-03-14, Andreas Hausladen < XXXX@XXXXX.COM >wrote:
Quote
Marco van de Voort wrote:

>>Simple VCL application to VCL.NET :-)
>
>Breaks on the first pointer.

You must have missed the word "Simple" ;-)
I don't program in VCL, I program in the Delphi language (while I still
prefer Object Pascal as designation btw). (extreme) subsets can be converted
to nearly anything, but except as academic exercise it is pretty pointless.
If I'm concerned about migration, I have a significant codebase, and proving
portability with homework assignment level code has no relevance, specially
if one knows up-front that elementary language features are missing.
Pointer code that works on _all_ Borland pascal dialects, and even a good
deal of non-Borland dialects and on all OS/Architectures fails on
Delphi.NET. I'd say that is a pretty good reason to call Delphi.NET a
separate language.
That doesn't mean it is evil, it just makes a win32->Delphi.NET migration
a totally different magnitude than say D<x>->D<x+1>with x=2..6, and
probably even to D2005/win32.
Borland probably realises all this, which is why there is a d2005/win32.
Win32 and compiled languages don't go away for the next 5 years. (and
happens in longer timeframes is unpredictable). I don't want to imply that
.NET will go away either, it will probably pick up most of the
business/database oriented programming, while hw interfacing and control
apps will remain compiled.
To put stuff in perspective: my companies app uses more pointers than
memproof can count. So that pretty much makes .NET impossible.
 

Re:I - The Challenge

Marco van de Voort wrote:
Quote
If I'm concerned about migration, I have a significant codebase, and
proving portability with homework assignment level code has no
relevance, specially if one knows up-front that elementary language
features are missing.
To clarify this: You wrote:
but show me a typical solidly compiled language that can be
compiled to (managed) .NET without mods to the sourcecode, and I'll take
that back.
I made the joke with a "Simple VCL application".
So you must not justify you point to me. I also have applications that
cannot be migrated to .NET even they are VCL applications. Delphi Win32
supports pointers so you use pointers without thinking 5 year in future.
For example the VirtualTreeView component is a candidate for pointer
usage. It will not port to .NET without rewriting the component and the
interface of the component. PVirtualNode = ^record does not work in
managed code.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)