Board index » kylix » Re: I - The Challenge

Re: I - The Challenge


2005-03-15 05:20:57 PM
kylix1
On 2005-03-14, Willibald Krenn < XXXX@XXXXX.COM >wrote:
(last paragraph first)
Quote
>Why torture yourself with legacy language support then?

Because otherwise we should stick to managed Oberon or virtual pascal or
...?
Component pascal (which is more of an oberon too) But would that be that bad?
Oberon is closer to .NET in design decisions than e.g. Pascal.
Quote
Of course Mono is no strong platform at the moment, but I believe it will become
more popular in future - and if we then can provide some open source flavour of
Delphi, this would be a cool achievement at least.
(I have serious doubts about that. Or at least that mono on *nix goes beyond
the GNOME project, some academic use and some miminal porting from the smaller
Windows .NET apps. So that is definitely difference in our opinions)
Quote
Honestly stated, I'll be happy if we manage to implement most parts of
Delphi.NET without having to do a complete language re-design. We can still
extend the language later on. Starting to argue about language syntax now would
bring us nowhere, besides the attracted user base would be even smaller.
That was why I would like to point you in the direction of the other
Wirthian dialects. Less a moving target, simpler, and existing codebases
that you have a chance of running, the later ones also have so much machine
abstraction that they naturally suit .NET.
But a good first step if you go through with it would be to immediately
start inventarising if the many parser artefacts of the delphi/win32
language made it into the Delphi.NET language. Get the dirty laundry on the
table asap. Hunt the newsgroups, available testcode and QC for strange code
artefacts.
Quote
>The compiler is all GPL, just like Mono to my knowledge.

Nope. Parts of the mono runtime are LGPL (and possibly other licenses).
Mono is not GPL only.
FPC is the same. runtime is LGPL, tools and compiler GPL.
Quote
People who buy Delphi Enterprise won't need/use open source compilers.
Well, here is your first exception then.
Quote
>For me, the whole range of problems that I have to deal with in a project
>as FPC is the kick.

And by 'kick' you mean?
What I like about the project.
Quote
>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.

You can even add native code to .NET assemblies and call it.
True. I can bridge C from most Pascal compilers. However that is not a
feature of Pascal :-)
 
 

Re:Re: I - The Challenge

On 15 Mar 2005 01:13:04 -0800
"Matthias Thoma" < XXXX@XXXXX.COM >wrote:
Quote
FWIW: The term "viral" is much older - maybe as old as the GPL itself :-)

As one reference
< XXXX@XXXXX.COM >

(from 1993)
Ok, then google ran out of hits or something.
Quote
groups.google.com finds many more before July'6th 2001.
How did you search?
Micha
 

Re:Re: I - The Challenge

Hello,
Quote
How did you search?
Advanced Search / Find Messages Between May, 12th 1981 and January, 1st 2001.
Search term: "GPL viral"
- Matthias
 

{smallsort}

Re:Re: I - The Challenge

On Tue, 15 Mar 2005 10:27:03 +0100
Micha Nelissen < XXXX@XXXXX.COM >wrote:
Quote
>groups.google.com finds many more before July'6th 2001.

How did you search?
I'll answer myself:
Using advanced search, you can return older hits, it seems. There are about 1130 older than june 2001 (in google groups). Example:
groups.google.nl/groups&lr=&as_drrb=b&as_mind=12&as_minm=5&as_miny=1995&as_maxd=15&as_maxm=3&as_maxy=1997&selm=4att84%24cqi%40park.uvsc.edu&rnum=2
Weird coincidence, those 2 dates so close together (june/july 2001)! And it wasn't the 100th page, the 87th or so, so I really thought it ended there.
Micha
 

Re:Re: I - The Challenge

Dave Nottage [TeamB] wrote:
Quote
If you don't like it, use something else
I mostly use MPL1.1 for OpenSource
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:Re: I - The Challenge

On 2005-03-15, Micha Nelissen < XXXX@XXXXX.COM >wrote:
Quote

>Calling the GPL is no Microsoft term afaik. I encountered in frequently
>in the *BSD, e.g. FreeBSD, to this day, keeps all GNU userland code in a
>separate tree contrib/

Well, most FreeBSD'ers love their BSD license and tools I guess, and
"hate" gnu/linux ;-).
It's not a hate thing per se, it's simply avoiding license contamination,
and in general avoiding a strong external entity (read: GNU) with an
agressive license in taking over the project.
The GPL is not necessary evil, just like dynamite isn't evil per se. However
it is kind of dangerous.
 

Re:Re: I - The Challenge

Marco van de Voort schrieb:
Quote
Component pascal (which is more of an oberon too) But would that be that bad?
Oberon is closer to .NET in design decisions than e.g. Pascal.
I guess I have to look at Oberon then. I've only had the nice experience of
coding in Occam, but I guess Modula/Oberon were not on my list until now.
Quote
>Of course Mono is no strong platform at the moment, but I believe it will become
>more popular in future - and if we then can provide some open source flavour of
>Delphi, this would be a cool achievement at least.


(I have serious doubts about that. Or at least that mono on *nix goes beyond
the GNOME project, some academic use and some miminal porting from the smaller
Windows .NET apps. So that is definitely difference in our opinions)
Yes, but what would be the world without different opinions? Quite sad place..
Quote
But a good first step if you go through with it would be to immediately
start inventarising if the many parser artefacts of the delphi/win32
language made it into the Delphi.NET language. Get the dirty laundry on the
table asap. Hunt the newsgroups, available testcode and QC for strange code
artefacts.
I'll keep that in mind if the project takes off. (It's still somewhat uncertain,
due to "mono-pascal" issues)
Quote
>People who buy Delphi Enterprise won't need/use open source compilers.


Well, here is your first exception then.
:-))
Quote
What I like about the project.
Yes, of course. I did not read your sentence very carefully I guess..
Quote
>>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.
>
>You can even add native code to .NET assemblies and call it.


True. I can bridge C from most Pascal compilers. However that is not a
feature of Pascal :-)
It's more a feature of .NET to have methods not in CIL, but in native machine code..
Willi
 

Re:Re: I - The Challenge

Why don't you just work on Lazurus?
Why start from total scratch?
 

Re:Re: I - The Challenge

Except for one problem (The use of a logo that is a predator upon birds
in Linux, an OS represented by a bird) I think that the Lazarus FPC
people got it right in the first place. GTK+ with its Free Software but
allowable use in Proprietary software LGPL license was the way to go
for a VCL replacement for several reasons that go beyond Proprietary
Software friendly licensing alone.
The first of these is that GTK+ is a C written api Like Win32 and thuss
much better for building Object Oriented wrappers like the VCL around
than an API like QT's which is already heavy into Templates, Multiple
Inheratence, Non standard Preprossing requirements and other C++
features that the ObjectPascal Object Oriented Model doesn't support.
GTK+ is ubiquitous on Linux and can pretty much be considered THE
"High Level" GUI API for linux. (X 11 is the "Low Level" GUI API
regardles of the API Toolkit used at the higher easier to understand
level.) QT is pretty much an interloper brought into Linux by the KDE
developers who wanted to develop their interface in C++.
QT is not even standard C++ but is based on a proprietary system of
pseudo C++ programming called "signals and slots" that requires a
special preprocessor called "moc" to compile. I believe this was also
pretty much a factor in the failure of Kylix as it's developers had to
develop work arounds for this "moc" requirement tied to QT.
I would have just two pieces of advice for the Lasacru FPC people:
1. merge your projects, these days a good compiler needs a good IDE.
1. Ixnay the eetachay and develop a new logo that emphazises the
cross platform capabilities of Lazarus/FreePascal instead of simply its
speed. I believe that there are several people like me who are just a
little uncomfortable with having a loose predatory beast that close ot
our adorable little Tux. ;c)
 

Re:Re: I - The Challenge

Quote

Thanks again for the links, but I guess I found my new spare time project.

Don't you think it's a bit of a waste of time to reinvent something that
already is available. Of course it's a nice idea to reproduce it in the
open source world, but here you need more manpower than you can
contribute. IMHO the better way would be to work together with the Free
Pascal / Lazarus team to firstly get a really usable version of Lazarus
out of the door and based on this do a port to .NET/Mono.
-Michael
 

Re:Re: I - The Challenge

On 2005-03-16, Michael Schnell < XXXX@XXXXX.COM >wrote:
Quote
>
>Thanks again for the links, but I guess I found my new spare time project.
>

Don't you think it's a bit of a waste of time to reinvent something that
already is available. Of course it's a nice idea to reproduce it in the
open source world, but here you need more manpower than you can
contribute. IMHO the better way would be to work together with the Free
Pascal / Lazarus team to firstly get a really usable version of Lazarus
out of the door and based on this do a port to .NET/Mono.
There is virtually nothing in the FPC project you can reuse for .NET I
think, everything uses pointers, and everything is in Pascal. Moreover all
visual libraries have to be reprogrammed ground up. (too many gtk/win32 and
pointer entanglements)
For a .NET adventure you need to start from rock bottom (but you can look at
the parser of course)
Also keep in mind that FPC is written in FPC (or plain Delphi with some
trouble), and mono doesn't support that yet. So you would have to port FPC
first to Delphi (doable) Delphi.NET (pretty hard) first, and then back to
mono. However I guess the mono team will probably make you use C# anyway,
for bootstrapping reasons.