Board index » kylix » Re: I - The Challenge

Re: I - The Challenge


2005-03-14 07:15:10 PM
kylix2
Andreas Hausladen schrieb:
Quote
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.
Ok, I'll think of it when we are that far :-)
Quote
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.
IIRC the license had the clause that you were only allowed to talk to QT over
the Borland-made QT unit. So with a new wrapper around QT, I fear the
no-nonsense license won't work anymore. But correct me, if I'm wrong!
Willi
 
 

Re:Re: I - The Challenge

Willibald Krenn wrote:
Quote
IIRC the license had the clause that you were only allowed to talk to QT
over the Borland-made QT unit. So with a new wrapper around QT, I fear
the no-nonsense license won't work anymore. But correct me, if I'm wrong!
"Für eine andere als die oben gestattete Verwendung der Unit Qt ist eine
separate kommerzielle Entwicklungslizenz von Trolltech erforderlich."
Borland had/have a contract with Trolltech so you can use Qt without bying
a Qt developer license with CLX application. In order to not allow the
exclusive usage of the Qt unit without any CLX code, Borland added this
paragraph (and the one above it that I have not quoted).
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: I - The Challenge

Bill Smith schrieb:
Quote
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.
Thanks for the kind invitation. I'm sure Lazarus is the way to go if you want
native executables - but somehow I like to have many of the new features that
were added to Delphi during the .NET transition (e.g. GC) and I like the fact
that the .NET platform enables Delphi to come out of it's corner (in terms of
components etc.).
Quote
Think of it as Kylix 4.0. After all Kylix had its roots in open source.
That's news to me. IIRC Borland contacted FPC developers before doing Kylix, but
I always thought they did not follow the call (if there was any).
Willi
 

{smallsort}

Re:Re: I - The Challenge

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?
 

Re:Re: I - The Challenge

Andreas Hausladen wrote:
Just for information: I'm a "MPL" open source developer and not a "GPL" OS
developer. So I try to workaround anything that brings me to virual GPL.
That's the reason why I release the UnVCLX patches as patches and not as
full source files based on FreeCLX.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Re: I - The Challenge

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

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.
Ok. Well actually I did think about it, since my code is not that old.
However I/we looked at D8 and .NET specs and decided to make it win32 only,
and make it last as long as possible. And to start over using .NET without
taking legacy code, so that I wouldn't end up with a .NETified win32 app,
but with something that was _designed_ for .NET.
 

Re:Re: I - The Challenge

Michael Schnell schrieb:
Quote
You are not the first to think along these lines.
Yes, I know - and I bet Borland does too.
Quote
see:

www.chromesville.com/

You can already request a beta version for testing from them.

You also should read the newsgroup remobjects.public.chrome
Thanks again for the links, but I guess I found my new spare time project.
Willi
 

Re:Re: I - The Challenge

On 2005-03-14, Willibald Krenn < XXXX@XXXXX.COM >wrote:
Quote
>Think of it as Kylix 4.0. After all Kylix had its roots in open source.

That's news to me. IIRC Borland contacted FPC developers before doing Kylix, but
I always thought they did not follow the call (if there was any).
Partially. There was no communication or negotiation between FPC and
Borland, except that Borland tried to hire the FPC devel that did the
initial Linux port. This didn't go through mostly because of reasons not
relating to FPC<->Borland. Also the devel wasn't allowed to do FPC work
anymore if hired. (which is less bad than it sounds btw, I would do the
same thing as employer probably)
There was some communication between Borland devels and this devel during
his application period, but he was under NDA, so we only got real Kylix info
after when the first Kylix beta's came out.
To my knowledge this was the last communication with Borland (and actually
that was already not really communication), except for a lazarus devel that
talked to a Borland executive on a radio show, in which the exec confessed
that "we are probably the first to recompile a new FPC/Lazarus release",
though I myself thought that more as flattery, since Borland was in their
"be nice to open source" phase.
Oh, and of course the pleads to release the old Turbo Pascal Turbo Vision
code for Delphi and/or FPC adaptation. But that was also relatively one
sided :_)
 

Re:Re: I - The Challenge

Andreas Hausladen wrote:
Quote
So I try to workaround anything that brings me to virual GPL.
FUD, the GPL is not viral.
Martin
 

Re:Re: I - The Challenge

I try to shorten this..
Marco van de Voort schrieb:
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?
No.
Quote
>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.
Of course it can do - but here you are forgetting the past few years where we
did not see any updates happen to Kylix or CLX.
Quote
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)
I wasn't saying that Lazarus was dying. (If it looked like I did, please take my
pardon.)
Quote
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.
Nice to know. So you'll do a .NET version?
Quote
- 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.
And you're sure this also includes QT versions other than 2?
This would be breaking news, if it was true!
Quote
- Borland might come with a new Kylix.
*lol*
Quote
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.
I see, we are talking about two different Delphi's here. I'm talking about the
.NET side.
Quote
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?
Surely some bigger island.
Quote
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.
Well, and if this is true, it still was a nice project to start with.
Quote
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.
No what I was saying is that FPC needed more work in total than building a
Delphi.NET compiler (and glue framework) for mono will need.
Quote
Your message had a certain naiveity about the schedule and manpower needed,
I did not mention a schedule with one word.
Quote
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.
So let's talk "plain language" then: FPC is a huge success for you and all the
developers part of it. I can remember buying some mag with FPC 1.0 on the mag-CD
and I've seen the vast amount of work that went into all the bits an pieces
(esp. Lazarus) since that time. Furthermore I know that you won't do a .NET
version, so basically there is/will be no open source Delphi.NET compiler from
the FPC team. While there are different commercial Delphi.NET compilers around,
I still think it is worthwhile to have some open source Delphi.NET compiler. (I
hope you agree on this.) Now, as mono already features a C# and a VB compiler -
why not try to add a Delphi(.NET) compiler, since this is our pet language?
My post here on the top level was meant to trigger respones and to see how much
interest there basically is. It was meant to be that way: Show up some very very
large goal and see how people react on it. Obviously there's not much interest,
so I guess the Delphi.Mono compiler will be the only thing that actually will be
implemented - and if it's in some limited version.
[Pointers]
Quote
Partially yes.
It was Borland's decision to only support safe code. Theoretically you can take
the old (normal) Delphi (including pointers) and do .NET applications, but you
are restricted to one particular CPU and unsafe code then.
After all there exists something like managed C++ and C++ is not particularly
known to be pointer free.
Quote
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.
You know, this is the goal. Let's see how it works out.
Quote
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.
Thanks for the offer. We'll use it.
[3rd party libraries]
Quote
I can then choose gcc or Java and take my pick from the libraries if I want
to start over.
Yes and that would be some wise decision. Note that I do not want to do the
compiler because I think everyone will use it. Personally I want to do it
because I like Pascal and I want to give people an open source Delphi.NET
compiler in hands, so everyone can use my favourite language even on .NET.
However, I'm realistically enough to know that only the nice .NET framework
we'll get for free makes this possible in the first place..
Quote
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.
Transition to NET 2.0 won't be a piece of cake, but support for NET 1.1 won't be
dropped that fast OTOH.
Quote
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 guess you misunderstood something here: The CIL is a standard, which does not
change anymore for NET 1.0. So basically the platform stays the same. It's just
the (C#) framework that is not part of the corlib (GTK#..) that will change -
but I'm confident we can deal with that once we reached this stage.
Quote
I don't want to say you are wrong with that mono gives you access to multiple
platforms, but it does have a cost.
I think this cost is justifiablely and significantly less than the cost FPC
had/has to pay..
Quote
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.
Again: Theoretically we could make our Delphi.NET compiler such, that it accepts
a wider range of Delphi language including pointers. But that would complicate
matters significantly plus we'd lose the nice mono platform that shields us
against changes in/of the OS and changes of the hardware platform.
Quote
Good example. I'm talking about languages, you are talking about libraries.
Different horse!
Ok, I guess every language has changes/extensions (C++) to be .NET compatible.
Quote
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.
Ahm, I don't think we'll run huge (commercial) apps in forseeable future. And I
guess the windows future is .NET or C++.. (Plus limited Delphi W32 of course.)
Quote
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?
Things are in flux currently, so ask me again in some weeks..
Willi
 

Re:Re: I - The Challenge

Martin Waldenburg wrote:
Quote
FUD, the GPL is not viral.
In the case of source code it has this effect. For external programs it is
not "viral". But if you have a closes source project and you want to add a
component that is GPL you must either make the component an external
program or you must make your project GPL.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Re: I - The Challenge

On 2005-03-14, Willibald Krenn < XXXX@XXXXX.COM >wrote:
Quote
I try to shorten this..
So will I.
[kylix in fridge]
Quote
Of course it can do - but here you are forgetting the past few years where
we did not see any updates happen to Kylix or CLX.
See win32 in D2005 example.
Quote
>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.

Nice to know. So you'll do a .NET version?
.NET is no Delphi feature. It is a Delphi.NET feature :-)
And no we won't. That is no .NET dismissal, but simply reality.
The amount of work involved is huge and leaves no part of the project
alone (keep in mind it is written in itself). Moreover we have some question
marks in longterm maintaining of combined native and .NET apps.
One of FPC's fundaments is that it strives to be a production compiler, and
not be one of those purer than pure language or VM technique experiments
that burns fast, and dies young. There is a reason we are going through the
pain of tracking a production compiler, and try to become (very) compatible.
Quote
>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.

I see, we are talking about two different Delphi's here. I'm talking about the
.NET side.
Of course, if you require .NET flat out, and dismiss everything else,
everything changes. I didn't get that from your original msg, and didn't
even think of that.
From that angle, I don't see a production .NET side on Linux currently. Mono
is already a niche player, and a Delphi platform on top of that is even
interesting for less people. Lots of tinkers of course, but the only serious
Mono use seems to be with Gnome that have a bit of a "chew your own dogfood"
mentality.
.Net is still fundamentally a Windows thing, and all the codebases
created on Windows typically use Borland assemblies and other 3rd party
windows only assemblies, and I don't see that change, even on mediumlong
term.
Quote
>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.

Well, and if this is true, it still was a nice project to start with.
I would kick away the legacy angle, and would start to redesign a Wirthian
.NET language without these constraints. It will make the product better,
and the work less. Chrome tries to do this, but I don't know enough about
it to recommend it.
Quote
No what I was saying is that FPC needed more work in total than building a
Delphi.NET compiler (and glue framework) for mono will need.
For a .NET compiler as ultimate purpose: surely. Since this is not even
planned for FPC.
If you mean for each to become on par with a Delphi version (native in FPC
case, .NET in mono's case), I strongly disagree.
Quote
>Your message had a certain naiveity about the schedule and manpower needed,

I did not mention a schedule with one word.
Exactly :-)
Quote
So let's talk "plain language" then: FPC is a huge success for you and all
the developers part of it. I can remember buying some mag with FPC 1.0 on
the mag-CD and I've seen the vast amount of work that went into all the
bits an pieces (esp. Lazarus) since that time. Furthermore I know that you
won't do a .NET version, so basically there is/will be no open source
Delphi.NET compiler from the FPC team.
The compiler is all GPL, just like Mono to my knowledge. You are free to
take the compiler, kick away the codegenerator and .NETify it. The runtime
libs are LGPL even.
However we don't see much synergy between the native and managed world (that
latter being .NET or Java, lots of FPC2JVM questions too). We believe both
sides are best served by a dedicated product that don't limit eachother.
Quote
While there are different commercial Delphi.NET compilers around, I still
think it is worthwhile to have some open source Delphi.NET compiler. (I
hope you agree on this.)
To be honest, no. Delphi.NET, as a language, is a beast full of legacy.
Maybe it is better to draw the line, and start over, and create something
that is something that optimally combines Wirthian language design
principles and managed environments (which is not that hard, since several
Wirthian languages were managed)
I'm more symptatetic to Chrome than to Delphi.NET,... as a language....
The strong point of the commercial product Delphi.NET is not the language,
but the whole set of tools that surround it. The db stuff, ECO etc. This
brings us back to FPC (and I as a person) being oriented/interested towards
productive use.
For me, the whole range of problems that I have to deal with in a project
as FPC is the kick.
If your purpose is e.g. education, the tradeoffs are different.
Quote
[Pointers]
>Partially yes.

It was Borland's decision to only support safe code. Theoretically you can
take the old (normal) Delphi (including pointers) and do .NET
applications, but you are restricted to one particular CPU and unsafe code
then. After all there exists something like managed C++ and C++ is not
particularly known to be pointer free.
Yes, but managed C++ is not C++. I know pointers are allowed as toothless
feature in .NET, but that makes it pretty point(er)less.
(My .NET using collegue also yells to me that using smartpointers are an
excellent way to kill performance in .NET)
Quote
[3rd party libraries]
because I like Pascal and I want to give people an open source Delphi.NET
compiler in hands, so everyone can use my favourite language even on .NET.
However, I'm realistically enough to know that only the nice .NET framework
we'll get for free makes this possible in the first place..
There already are lots of nice and clean Wirthian .NET languages (Oberon,
Component Pascal, Modula-2 IIRC). If Delphi.Net's clone isn't compatible,
what's its function.
Quote
>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 guess you misunderstood something here: The CIL is a standard, which
does not change anymore for NET 1.0.
Sure, but soon (in timescales of Open Source projects), Longhorn will ship
with 2.0, mono-C# with its commercial devels will adapt, and after a while
mono-1.0 will disappear from linux distro's, and you'll have no choice to
adapt.
Quote
>I don't want to say you are wrong with that mono gives you access to multiple
>platforms, but it does have a cost.

I think this cost is justifiablely and significantly less than the cost FPC
had/has to pay..
True. But there is no equal start. FPC/Lazarus has a 100MB sourcecode base
and a 11-12 years headstart. The painperiod is over (specially the 1.0.x to
1.9.x transition was no fun), and development has accelerated quickly during
2003-now.
Quote
>because half of the commercial components use assemblies that are windows
>only and /or proprietary.

Ahm, I don't think we'll run huge (commercial) apps in forseeable future.
Why torture yourself with legacy language support then?
 

Re:Re: I - The Challenge

Andreas Hausladen wrote:
Quote
In the case of source code it has this effect.
No.
It can't infect you against your will,
contrary to vira.
It's like with anything other:
If you don't want to pay the price don't use it.
Martin
 

Re:Re: I - The Challenge

On 14 Mar 2005 02:18:15 -0800
"Andreas Hausladen" < XXXX@XXXXX.COM >wrote:
Quote
Micha Nelissen wrote:

>Messages are yucky and slow, so I cannot imagine it being better
>than something else

Messages have syntax support in Delphi.
Uhm, what does that have to do with my claim of messages being yucky and slow ? Yucky: they are not typed. Slow: linear or binary search needed to find method every time a message comes by.
Quote
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.
Ok thanks for the explanation. I take it, "events" are not typed either ?
Quote
The best solution meight be a combination of both.
The best solution would be proper OOP virtual (abstract) methods. Which you could name "conveniently", for example WMKeyDown(Key: Word; ShiftState: TShiftState;...) or whatever.
Micha
 

Re:Re: I - The Challenge

Martin Waldenburg wrote:
Quote
It can't infect you against your will,
OK, that is one facet I had not recognized.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)