Re: fpc-pascal Digest, Vol 19, Issue 24

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: fpc-pascal Digest, Vol 19, Issue 24

"Gökhan" Ersumer
Message: 7
Date: Thu, 16 Mar 2006 01:13:57 +0100
From: Mattias Gaertner <[hidden email]>
Subject: Re: [fpc-pascal] Re: OpenDelphi.org
To: FPC-Pascal users discussions
<[hidden email]>
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=US-ASCII

On Wed, 15 Mar 2006 15:57:23 -0800 (PST)

>
>
> --- [hidden email] wrote:
>

<snip>

>
> FPC is Ok but a few years ago I examined Lazarus
> codebase and I saw Lazarus is hacking Class parents
> on-the-fly for its normal operations so I
immediately
> lost my interest.
> Is this changed recently?

If you mean creating the VMT at runtime, then the
answer is: yes, it
still
does.
What are the alternatives?

Mattias

Yep I meant creating VMT at runtime,It does not seems
like a good practice to me.

Delphi's streaming system wont work without RTTI, and
Delphi's RTTI is only for streaming. RTTI and message/
dynamic methods is embedded in compiler to support VCL
and IDE. So writing a Delphi-like IDE without support
of FPC team / compiler could be hard work but I still
wont think
creating VMT in runtime is way to go. Cross-platform
issues and these kind of hacks/ shortcuts  is
overcomplicating things in Lazarus codebase, I think.

Alternative?
I prefer a solution based on non ref-counted
interfaces  for example (although this may need some
support from compiler side e.g UID's for non
ref-counted interfaces/ interface delegation or
something, and means nearly rewrite, so I dont think
this will happen)
User-level delphi compatibility is enough for masses
(e.g Form designer, properties vs), as long as it have
quality/stability,  internal workings of components is
not so important, but as I said above, with current
implementation I dont think Lazarus is
production-ready or it will become.

Sorry for my poor English.

Gokhan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Mattias Gaertner
On Thu, 16 Mar 2006 08:24:12 -0800 (PST)

> Message: 7
> Date: Thu, 16 Mar 2006 01:13:57 +0100
> From: Mattias Gaertner <[hidden email]>
> Subject: Re: [fpc-pascal] Re: OpenDelphi.org
> To: FPC-Pascal users discussions
> <[hidden email]>
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=US-ASCII
>
> On Wed, 15 Mar 2006 15:57:23 -0800 (PST)
>
> >
> >
> > --- [hidden email] wrote:
> >
>
> <snip>
>
> >
> > FPC is Ok but a few years ago I examined Lazarus
> > codebase and I saw Lazarus is hacking Class parents
> > on-the-fly for its normal operations so I
> immediately
> > lost my interest.
> > Is this changed recently?
>
> If you mean creating the VMT at runtime, then the
> answer is: yes, it
> still
> does.
> What are the alternatives?
>
> Mattias
>
> Yep I meant creating VMT at runtime,It does not seems
> like a good practice to me.
>
> Delphi's streaming system wont work without RTTI, and
> Delphi's RTTI is only for streaming. RTTI and message/
> dynamic methods is embedded in compiler to support VCL
> and IDE. So writing a Delphi-like IDE without support
> of FPC team / compiler could be hard work but I still
> wont think
> creating VMT in runtime is way to go. Cross-platform
> issues and these kind of hacks/ shortcuts  is
> overcomplicating things in Lazarus codebase, I think.

Overcomplicating is the wrong word, as this 'hack' was used to avoid
complication.
By creating a vmt, the rest of the code and any component work without
modifications.
The alternative is to create a normal TForm/TDataModule and fake/extend all
places, where the fake vmt is used. That are all places where RTTI or the
Classname are used. And of course some 'is' and 'as' operators.
The vmt itself are a few pretty simple records and they are cross platform.
The real hack is the method pointers. They will eventually replaced by
fakes.

 
> Alternative?
> I prefer a solution based on non ref-counted
> interfaces  for example (although this may need some
> support from compiler side e.g UID's for non
> ref-counted interfaces/ interface delegation or
> something, and means nearly rewrite, so I dont think
> this will happen)

Can you give an example, how this should work?


> User-level delphi compatibility is enough for masses
> (e.g Form designer, properties vs), as long as it have
> quality/stability,  internal workings of components is
> not so important, but as I said above, with current
> implementation I dont think Lazarus is
> production-ready or it will become.


Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Alexandre Leclerc
In reply to this post by "Gökhan" Ersumer
On 3/16/06, Gökhan Ersumer <[hidden email]> wrote:
> User-level delphi compatibility is enough for masses
> (e.g Form designer, properties vs), as long as it have
> quality/stability,  internal workings of components is
> not so important, but as I said above, with current
> implementation I dont think Lazarus is
> production-ready or it will become.

I'm just stepping in to ask a question, from the point of view that I
do not understand the issue... but why lazarus would/will not become
production-ready? If I plan to use it as core devel tool... what I do
not know (that I should) so that I should absolutely refrain from
using fpc/lazarus? Is it stability? Is it usability? What is it?

--
Alexandre Leclerc
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Michael Van Canneyt


On Thu, 16 Mar 2006, Alexandre Leclerc wrote:

> On 3/16/06, Gökhan Ersumer <[hidden email]> wrote:
> > User-level delphi compatibility is enough for masses
> > (e.g Form designer, properties vs), as long as it have
> > quality/stability,  internal workings of components is
> > not so important, but as I said above, with current
> > implementation I dont think Lazarus is
> > production-ready or it will become.
>
> I'm just stepping in to ask a question, from the point of view that I
> do not understand the issue... but why lazarus would/will not become
> production-ready? If I plan to use it as core devel tool... what I do
> not know (that I should) so that I should absolutely refrain from
> using fpc/lazarus? Is it stability? Is it usability? What is it?
There is no reason why Lazarys would/will not become production ready.
Proof: It is in production use already.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Felipe Monteiro de Carvalho
In reply to this post by "Gökhan" Ersumer
On 3/16/06, Gökhan Ersumer <[hidden email]> wrote:
> Yep I meant creating VMT at runtime,It does not seems
> like a good practice to me.

Where is the code that creates VMT at runtime? Just curiosity, because
I've being working with Lazarus, but I never noticed it.

It probably doesn't matter from a user point of view.

thanks,
--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

A.J. Venter-2
In reply to this post by Michael Van Canneyt

> There is no reason why Lazarys would/will not become production ready.
> Proof: It is in production use already.
As one of the production users - I can vouch for this. There are several
others on this list whom I know are doing production work in Lazarus as well,
Graeme and Tony for starters.
One of the things I think works best for lazarus is that it is written in the
same language it uses - so every user is a potential contributor (unlike most
programs and IDE's users typically CAN program) which is why I think it has
such an amazing rate of expansion - we must be averaging about 5 or 6 patches
on most days.
So not only IS lazarus production ready - it's getting better at a huge rate,
and because it is free software, when you lack a feature, you can add it with
relative ease as most of us has done at least once - which is why it grows so
well and in response to the current most urgent needs of it's userbase.

Okay enough me-too'ism :)

PS. Michael, I have been chasing deadlines all week, I will draw up a standard
interview set tomorrow and send you the questions.

Ciao
A.J.
--
"there's nothing as inspirational for a hacker as a cat obscuring a bug
by sitting in front of the monitor" - Boudewijn Rempt
A.J. Venter
Chief Software Architect
OpenLab International
www.getopenlab.com
www.silentcoder.co.za
+27 82 726 5103
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

L505

> One of the things I think works best for lazarus is that it is written in the
> same language it uses - so every user is a potential contributor (unlike most
> programs and IDE's users typically CAN program) which is why I think it has
> such an amazing rate of expansion - we must be averaging about 5 or 6 patches
> on most days.

I always harp on this fact - for example perl is written in C, python is written
in C, php is written in C, but if you want to learn from the sources why
shouldn't it be python is written in python and php is written with a php
compiler. And we all know delphi ide kernel and compiler is written in lots of C
and some Delphi for the gui parts, but not all of them. Java is written in C.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Vinzent Höfler
On Thursday 16 March 2006 23:12, L505 wrote:

> I always harp on this fact - for example perl is written in C, python
> is written in C, php is written in C, but if you want to learn from
> the sources why shouldn't it be python is written in python and php
> is written with a php compiler. And we all know delphi ide kernel and
> compiler is written in lots of C and some Delphi for the gui parts,
> but not all of them. Java is written in C.

Well, just to mention a counter-example: My favourite Ada compiler is
written in Ada.


Vinzent.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 19, Issue 24

Geoff Bagley
>
>
>Well, just to mention a counter-example: My favourite Ada compiler is
>written in Ada.
>
>
>Vinzent.
>  
>
I used to use an Algol 60 compiler which had been written in a
(gradually  growing)
sub-set of Algol 60.  A new meaning to "boot-strapping" ?

Geoff

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal