On 2005-03-14, Willibald Krenn <
XXXX@XXXXX.COM >wrote:
Quote
Marco van de Voort schrieb:
>>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.
What have you heard? If you quote and dismiss it, you must have some scope
on it.
Quote
>It's uncertain. That is something else than dying.
In Delphi 2005 support for CLX was dropped;
So was win32 support in D8.
Quote
Borland announced the community project months ago, but nothing has
surfaced so far.
Months. You really think you can pull off something that can be a competitor
to any of the projects you named (Kylix/FreeCLX/FPC/Lazarus) in a few
months?
Quote
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?
For Borlands case: in the fridge. I'm a Borland critic, but it is a decently
sized corporation, and can throw money and manpower on something if it wants
to. It can have a Kylix 4 ready while you are still debatting how your
sourcecode will be formatted in CVS on your just new maillist.
Moreover, FPC/Lazarus are not dying, and already lightyears ahead in
compability, since a new project won't come up with something runnable in
at least 1 1/2 year (and then I'm already optimistic)
The missing features in FPC are partially already in development (except
one, which I leave as an exercise to the reader to name it, since it will
require a new branch), and might be operational before you even have
something that compiles a hello world level program.
I'd say it is still more worthwhile than going on a naieve wild goose chase,
starting from nothing.
To get some form of Delphi compability took FPC years to make somewhat
mature - the dialect is not easy. (maybe .NET cleaned it up a bit though)
Quote
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.
I don't think this is sane from a business perspective:
- .NET isn't as wanted on Linux as on Windows, despite what the mono guys
want to make you believe. On Windows you can't dismiss .NET, on
linux you can.
- The maturity of .NET on Linux is much less.
- Windows.forms is only very recently alpha in mono, and Borland
doesn't care about gtk#, since Delphi/.NET doesn't use it.
- The native compiler only needs modification and updating. This is trivial
compared to the release engineering for one single commercial release
the magnitude of Delphi or Kylix. (discounting D2005, they forgot
a few "testing" steps in the release engineering there :-)
So I have some doubts about a next Kylix (if it comes) having a .NET edition,
and even if so, it still will have a native one.
Quote
>Then start working. Where are your freeclx contributions btw?
I won't ever contribute to FreeClx, because it's GPL ONLY!
(good, where are your FPC/Lazarus contributions then?)
But seriously, the GPL is indeed a very serious issue, and that is mainly
why FPC never got involved in that too. OTOH such reasons haven't kept
you from using a commercial product in the past.
Quote
>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...
Code that works since TP1 breaks with the .NET move. This is no trivial
matter, and more gigantic than even D1->D2.
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?
- There is FPC. While it needs work, it is better than starting from zero. FPC
compiled QT, compiles CLX. People interested in some serious Kylix work
already have the no-nonsense get-out-of-jail-free card on the shelf.
- Borland might release some of its hold on the code (unlikely, I agree,
since not even the Pascal Turbo Vision has been released)
- Borland might come with a new Kylix.
Three options.
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.
But showing that somethings work might be signal enough to borland.
Quote
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.
FPC's framework will be much closer to Delphi/Kylix then a mono solution
can ever be. And it is already there for a very large percentage.
All the problems with CLX you'll have with any other attempt too. If you
discount developing in FPC as an island, what do you think mono/gtk# is?
Quote
Realistically - what choices do we have? .NET/Mono is pretty much the only
answer I can think of.
- legacy code will have to be thrown away. In that case, I can pick any
solution, and then I'll take a ready, portable, and commercially
supported solution as Java over your vague plans.
- .NET, while maybe useful on Windows, has no serious future or advantages
in linux for now.
Quote
It's cross platform
Mono is cross platform. however e.g. visual classes are not. GTK# apps won't
be accepted by Windows customers. Exit.....
So maybe _IF_ Mono gets windows.forms somewhat working, _and_ if you manage
to build a
- delphi(.NET) compiler
- VCL.NET framework (copyrights) on top of that.
- keep it working on Delphi.NET/Microsoft .NET too
than you might have something in (if you do it parttime, even with say 10
developers), it will take you 3-5 years minimum, at which time it will be
obsolete anyway.
Quote
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)
What you are saying now is that implementing a total system that uses GTK(#)
from scratch is less work than stabilising a system that works and already
supports GTK, AND has a working Delphi compability framework on top of that.
Admitted, Lazarus has its flaws and the compability is not 100%, not even
close, but that are all problems you will have to deal with too. And you
start from absolutely nothing, except some dreams and a bit of response
on the mono list?
I find that a bit strange reasoning.
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*.
(big snip)
It was not meant as a personal attack, but more trying to point to a defiency
in your original message. Specially because the whole endeavour is monumental
(just a basic visual library would be a horribly large task, why do you think
people muck around with CLX patches even despite the GPL problems and Kylix
incertainties)?
All I wanted to point out, is that all open source projects are notoriously
short on personel. And your project is truly huge, and will take at least
5-10 people 3-5 year. (when done on the side). I don't expect you to get
many more dedicated devels than that (of course some people working on
the simpler parts, and a large share of betatesters that occasionally
submit a patch).
Since your project is not a solution for people with large investments in
Kylix, you can probably forget massive work done by this experienced crowd,
and will mostly attract newbies (and quite some jumping to chrome, because
they don't give a @$^^ about Delphi(.NET) compability)
Your message had a certain naiveity about the schedule and manpower needed,
and I wanted to point that out. It was more an attack on you as a project
manager, than as programmer. I miss something that hints on a simple
feasability study or some market research.
(yes open source has a market too, but it is in devels. You have a product,
and that attracts devels, which help you to improve the product etc)
Quote
>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.
Partially yes.
Quote
Plus we get the complete framework, a working JIT
(Linux 32/64, Windows 32, Sparc, MAC AFAIK) and a non GPLed widget set.
FPC already provides this, with a native compiler, and includes some more
and Classic OS. Moreover it is running, not projected. Moreover I still hope
for Borland to have Kylix versions, since while lazarus is a good start, it
is not ready for all purposes yet. Or even close.
Moreover, while you will undoubtedly benefit strongly from the C# as far
as major features are concerned, that is not the real problem. You can
find that in nearly every compiler book. I'm talking about getting it
delphi compatible in all its quircks, so you can accept code.
While most talk about FPC here is about what features it is missing, it does
accept a whole lot of the quite complex delphi language set. Be sure to
inspect the FPC testsuite that is afaik the only resource of the many
Delphi language quirks outside the Delphi compiler source that you probably
don't have.
Quote
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?
I can then choose gcc or Java and take my pick from the libraries if I want
to start over.
Quote
Furthermore we only have to make this change once, afterwards we get every
single new platform for free.
In theory of course. Be sure to check the GNU Pascal site. They had the same
idea in 1986 with gcc as basis. It doesn't always work that way. GNU Pascal
development stalled, because gcc is difficult beast to harness.
You will be tracking a highly mobile project (mono) with parttimers. Each
new major revision will be a lot of work to keep up.
I don't want to say you are wrong with that mono gives you access to multiple
platforms, but it does have a cost.
Quote
>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.
C# is a Java clone with some Delphi aspects due to its chief developer.
But fact remains is that you take a set of languages, and cut off everything
you don't like (like pointers). It doesn't work that way.
The cleaned up Delphi.NET, Java and C# are basically the same language,
no wonder why they are so easily portable.
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..
Good example. I'm talking about languages, you are talking about libraries.
Different horse!
Quote
>(Wasted enough time on this cheap advocacy attempt)
I know that you strongly dislike the .NET framework.
This is not true.
While I'm no fan of GC, I would go to .NET if needed. At least on Windows.
The problems that I have are with advocacy that is idealistic and untrue:
- taking legacy code with you is hard, unless it is trivial.
- portability to non-Windows is theoretic for huge commercial apps, simply
because half of the commercial components use assemblies that are windows
only and /or proprietary.
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.
There is interest in you submitting the compiler, or do they build it for
you? And will they make a simple reference compiler, or something that can
take any Delphi.NET code?