Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2001-03

Win32 Code Analysis

23 messages · 8 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Cryst
to Unknown author: We see these 'extensions' as useful :) Using .pp files marks them as files intended for…
> I wanted to re-compile the fpc in Delphi so I would not loose the > cross-platform compatiblity. The first part of the job was renaming all

the

> .pp files to .pas files. I have no idea why FPC uses .pp as the

extension,

> but using .pas makes the Delphi compatiablity much more easy. After a

long

> time renaming files, (I suppose I could have been more effecient) I

started

> recompiling the fpc under Delphi. Unfortunetly the FPC has all these > extensions to the language which makes it not-Delphi compatible. We see these 'extensions' as useful :)

I don't disagree, however they are not Delphi compatible, which makes it impossible to use Delphi for debugging. I understand wanting to be independent but really, it's more useful to be able to debug your code, which while possible under linux, isn't nearly so easy under windows.

Using .pp files marks them as files intended for Free Pascal. This can be an indication that FPC extensions are used, but this can also be useful for instance to be able to start up a different editor when double clicking a file in e.g. the windows explorer.

Seems then that what is wanted is not something that is Delphi compatible, but is compatible only unto itself.

And: The compiler does not name the files; it is the programmer that does this.

The compiler enforces the names in the uses clause. I believe this was the root of all my problems.

It is always up to the programmer to code compiler-independent, the

compiler

should not enforce anything.

By the compiler definition, it will enforce code which is compiler dependent. Using more then one compiler makes the code compiler independent, which to me seems a worthwhile goal.

Reply by email

Florian Klaempfl
to Florian Klaempfl: Now I'am confused! Delphi and C++ builder are the same?!?! I think, I need some…
you wrote
And: - Widestrings

Most stuff of widestrings is already implemented, the omissions are things which depend on the coding/code page, i.e. conversions between ansistring<->widestring<->shortstring; constant widestrings etc.

- Variants

Yes, this requires some work...

- INterfaces

Interface should work already quite good.

- Threads

It requires some work, especially on Linux!

(the comments above apply only to 1.1!!).

The FreeCLX contains almost no assembler except maybe in the system unit and typinfo unit.

Hmmm, at least in the classes unit I saw some assembler.

Reply by email

Unknown author
to Cryst: I looked into doing this a while back. The job is big. I looked at it as two parts.…
Cryst wrote 11 lines
I looked into doing this a while back. The job is big. I looked at it as two parts. First do the FPC and then the Lazarus. Just so that development time would be shortened. I wanted to re-compile the fpc in Delphi so I would not loose the cross-platform compatiblity. The first part of the job was renaming all the .pp files to .pas files. I have no idea why FPC uses .pp as the extension, but using .pas makes the Delphi compatiablity much more easy. After a long time renaming files, (I suppose I could have been more effecient) I started recompiling the fpc under Delphi. Unfortunetly the FPC has all these extensions to the language which makes it not-Delphi compatible.

We see these 'extensions' as useful :)

Show quoted text 14 lines
I started ifdef'ing my way around them but after a while decided that it was too big a job for the amount of payback. Then I type of problem. Gave up. This is not to discourage you though. I simply didn't have the time to spend, but with multiple hands the work would go much faster. So in view of this, I have some questions 1. Why are the source files named with the extension .pp. If the fpc compiler is Delphi compatible, why would the defualt extension be different? Is there a reason for this that I'm just not seeing? What would be the disadvantages to moving all lazarus (and fpc) source to .pas extensions?

Using .pp files marks them as files intended for Free Pascal. This can be an indication that FPC extensions are used, but this can also be useful for instance to be able to start up a different editor when double clicking a file in e.g. the windows explorer.

And: The compiler does not name the files; it is the programmer that does this.

Show quoted text 5 lines
2. Is there a way of making global macros in delphi that is simular to C. What I mean is is there a nice way of emulating fpc's extensions (like ++) in Delphi so that a common source that uses the extensions can be maintained, without all the ugly ifdef's (which defeat the purpose of the extensions in the first place).

None that I know of. Kylix introduces some extensions to directives, but none that will do this.

It is always up to the programmer to code compiler-independent, the compiler should not enforce anything.

Michael.

Reply by email

Florian Klaempfl
to Eric Lai: After reading the discussion about the problems which occured in the Win32 code. I have…
you wrote
1. Why are the source files named with the extension .pp. If the fpc compiler is Delphi compatible, why would the defualt extension be different?

If you've FPC and Delphi files on your PC, you (or windows) can distinct between them to
start the right editor when double clicking them.

Is there a reason for this that I'm just not seeing?

One (and the main) reason is history:
The very first versions of FPC ('93, the 0.1
versions) were no real pascal, it was some kind of "Pascal++", so I decided to name the source files .pp and this extensions is still used. The reason why the compiler files have the extension .pas is also easy to explain: FPC was bootstrapped using TP 7.0 and then we never changed it to .pp.

Show quoted text 35 lines
What would be the disadvantages to moving all lazarus (and fpc) source to .pas extensions? 2. Is there a way of making global macros in delphi that is simular to C. What I mean is is there a nice way of emulating fpc's extensions (like ++) in Delphi so that a common source that uses the extensions can be maintained, without all the ugly ifdef's (which defeat the purpose of the extensions in the first place). Chris Bruner ----- Original Message ----- From: "Eric Lai" To: Sent: Friday, March 30, 2001 3:34 PM Subject: [lazarus] Win32 Code Analysis > After reading the discussion about the problems which occured in the Win32 > code. I have decided to analysis the code and rewrite it in Delphi 5. I > believe that the development will be quicker and also produce faster and > smaller exe. If you would like to help please contact me. > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.miraclec.com/list_archives/lazarus _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Florian Klaempfl
to Marco van de Voort: Hmm, lets turn this discussion into something more constructive; Then I misunderstood,…
you wrote 10 lines
Thank you all for responding to my queries and comments. If I understand you all correctly then: 1. fpc uses .pas and is a better compiler then Delphi so no need to change to Delphi for development purposes on win32 systems. 2. lazarus uses .pp for mainly historical reasons, but the people who use it think it's nice, and don't feel a need for compiling in Delphi on win32 systems. 3. Views are divided on the idea of multiple compilers making compiler independant code.

....

5. Florian thinks that compiling the IDE in Delphi will not be productive because of Delphi's buggy compiler.

I think the main point is that every compiler is buggy and if you've a medium sized project (100000-1000000 lines of code), it's already quite hard to port it to another compiler because there are a lot of workarounds to hide bugs of a compiler. Especially if you've a language like Object Pascal for which no real standard or test suites exit.

I think that sums up the discussions, did I miss anything important?

Yes, see below.

Show quoted text 5 lines
OK, my comments back. 1. I must have been mistaken in this. 2. I don't like, but maybe that's just me. 3. My view is it's better to use multiple compilers to reduce compiler dependence. (To me it seems self evident).

...

5. I'm not so sure, since the current editor was originally written as a delphi component, that shouldn't be too much to make compatible again. Also the reason I want to be able to develop Lazarus in Delphi was not so much because of the editor, but because of the debugger.

I may point out one thing:
- Lazarus isn't only an editor, it's a RAD. And a RAD is very dependend from the compiler internals, e.g. type information, resources. The object inspector is depended on the FCL etc..

If you want a debugger, you may try the text mode IDE for win32 till lazarus is able to debug itself. I thought already a long time ago about making a description how to compile/debug lazarus with the text mode IDE, but I didn't find the time yet ...

Reply by email

Florian Klaempfl
to Florian Klaempfl: I doubt this :) We tried to compile FPC itself with Delphi 4 and Delphi 5 and our…
you wrote 5 lines
> > So I don't think that it is easy to compile Lazarus with Delphi. Afaik > the Delphi IDE isn't written in Delphi either... It is. The IDE is written in Delphi, or C++ builder. Which is the same.

Now I'am confused! Delphi and C++ builder are the same?!?! I think, I need some explanation here :)

BTW: I'd a short look on the FreeCLX and I'am quite shocked how Borland did the porting: it's full of {$ifdef Linux}...{$endif} etc.. The next weeks, I'll spend some time in trying to get it compiled with FPC. The main problem will be probably the assembler...

Reply by email

Unknown author
to Cryst: the long started I don't disagree, however they are not Delphi compatible, which makes it…
Cryst wrote 5 lines
> And: The compiler does not name the files; it is the programmer that does > this. The compiler enforces the names in the uses clause. I believe this was the root of all my problems.

The compiler enforces only 1 thing: on linux, all filenames are converted to lower case before looking for a file. Other than that, you are free to use the .pp or .pas extension; the compiler will first look for .pp files, if it doesn't find that, it will look for .pas files.

The latest development compiler on linux now also looks for files that are not lowercased, since Kylix for some strange reason decided to make the uses clause case sensitive. Which goes against pascal syntax rules.

So where filenames are concerned, we're very Delphi compatible, I hope.

Show quoted text 7 lines
> It is always up to the programmer to code compiler-independent, the compiler > should not enforce anything. By the compiler definition, it will enforce code which is compiler dependent.

No, it will enforce code that adheres to the language syntax. In our case Pascal, and we differentiate between 4 different syntaxes in pascal. This is needed for TP and Delphi compatibility, by which I mean that we want to be able to compile code written for TP or code written for Delphi.

If a programmer decides to use a certain syntax, then that is his choice.

Using more then one compiler makes the code compiler independent, which to me seems a worthwhile goal.

With this I can only agree, but as I tried to show, it is up to the programmer to code in this way. If the programmer decides to write code that will only compile when using this-or-that compiler feature, then his code is not portable...

Naming files with .pp is one of these things: by doing this, a programmer is expliicitly saying that this code must be compiled with FPC. Lazarus is such a project.

Michael.

Reply by email

Cryst
to Eric Lai: After reading the discussion about the problems which occured in the Win32 code. I have…

I looked into doing this a while back. The job is big. I looked at it as two parts. First do the FPC and then the Lazarus. Just so that development time would be shortened.

I wanted to re-compile the fpc in Delphi so I would not loose the cross-platform compatiblity. The first part of the job was renaming all the .pp files to .pas files. I have no idea why FPC uses .pp as the extension, but using .pas makes the Delphi compatiablity much more easy. After a long time renaming files, (I suppose I could have been more effecient) I started recompiling the fpc under Delphi. Unfortunetly the FPC has all these extensions to the language which makes it not-Delphi compatible. I started ifdef'ing my way around them but after a while decided that it was too big a job for the amount of payback.

Then I type of problem. Gave up.

This is not to discourage you though. I simply didn't have the time to spend, but with multiple hands the work would go much faster. So in view of this, I have some questions

1. Why are the source files named with the extension .pp. If the fpc compiler is Delphi compatible, why would the defualt extension be different? Is there a reason for this that I'm just not seeing? What would be the disadvantages to moving all lazarus (and fpc) source to .pas extensions?
2. Is there a way of making global macros in delphi that is simular to C. What I mean is is there a nice way of emulating fpc's extensions (like ++) in Delphi so that a common source that uses the extensions can be maintained, without all the ugly ifdef's (which defeat the purpose of the extensions in the first place).

Chris Bruner

Earlier message 18 lines
----- Original Message ----- From: "Eric Lai" To: Sent: Friday, March 30, 2001 3:34 PM Subject: [lazarus] Win32 Code Analysis > After reading the discussion about the problems which occured in the Win32 > code. I have decided to analysis the code and rewrite it in Delphi 5. I > believe that the development will be quicker and also produce faster and > smaller exe. If you would like to help please contact me. > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Marco van de Voort
to Cryst: the long started I don't disagree, however they are not Delphi compatible, which makes it…
Show quoted text 8 lines
started > > recompiling the fpc under Delphi. Unfortunetly the FPC has all these > > extensions to the language which makes it not-Delphi compatible. > > We see these 'extensions' as useful :) I don't disagree, however they are not Delphi compatible, which makes it impossible to use Delphi for debugging.

No, it just needs some more IFDEFs, temporarily too afaik, since unit aliasing is going to disappear in the long run from Delphi too?

I understand wanting to be independent but really, it's more useful to be able to debug your code, which while possible under linux, isn't nearly so easy under windows.

This has nothing to do with a cramped sense of independance. Delphi is a reasonably good product.

However, sometimes different choices, and managing developper time economically can create things like this. The mere fact that it differs from Delphi already says enough. Most of those differences are choices that already had a fair share of discussion about them being different from Delphi.

Show quoted text 7 lines
> Using .pp files marks them as files intended for Free Pascal. > This can be an indication that FPC extensions are used, but this can > also be useful for instance to be able to start up a different editor > when double clicking a file in e.g. the windows explorer. Seems then that what is wanted is not something that is Delphi compatible, but is compatible only unto itself.

That is not true. What Michael tries to say is that the fact that we aren't Delphi itself, while Delphi might be on a developpers system already imposes restrictions in FPC.

Show quoted text 5 lines
> And: The compiler does not name the files; it is the programmer that does > this. The compiler enforces the names in the uses clause. I believe this was the root of all my problems.

That's consistancy :-)

Show quoted text 8 lines
> It is always up to the programmer to code compiler-independent, the compiler > should not enforce anything. By the compiler definition, it will enforce code which is compiler dependent. Using more then one compiler makes the code compiler independent, which to me seems a worthwhile goal.

That's theory :-) Praxis Theory :-)

Reply by email

Unknown author
to Florian Klaempfl: I doubt this :) We tried to compile FPC itself with Delphi 4 and Delphi 5 and our…
Florian Klaempfl wrote 20 lines
At 15:34 30.03.01 +0000, you wrote: >After reading the discussion about the problems which occured in the Win32 >code. I have decided to analysis the code and rewrite it in Delphi 5. I >believe that the development will be quicker and also produce faster and >smaller exe. I doubt this :) We tried to compile FPC itself with Delphi 4 and Delphi 5 and our experiences were very bad: First, it took a lot of time to work around the delphi compiler bugs, the main problems were the unit interdependencies and the optimizer. Secondly (if you get something running), the compiler compiled by delphi is two times slower than a compiler compiled by FPC :). Reasons: - the Delphi heap manager is slow - the optimizer was switched off for several units (see above) - the Delphi register allocator is good when your using simple expressions while the FPC sources are full of rather complex expressions

Resulting in internal error U701 or so...

So I don't think that it is easy to compile Lazarus with Delphi. Afaik the Delphi IDE isn't written in Delphi either...

It is. The IDE is written in Delphi, or C++ builder. Which is the same.

The compiler backend is written in C(++)

Michael.

Reply by email

Jeff Wormsley
to Unknown author: We see these 'extensions' as useful :) Using .pp files marks them as files intended for…
AM wrote
And: The compiler does not name the files; it is the programmer that does this.

True, but if you type "Uses blahblah;" in your code, the compiler will look for blahblah.pp, not blahblah.pas. It would be very nice if this were a command-line switch (if it is, it's one I've missed.)

It is always up to the programmer to code compiler-independent, the compiler should not enforce anything.

True, although it is sometimes difficult where compiler features do not intersect.

Jeff.

Reply by email

Unknown author
to Jeff Wormsley
Jeff Wormsley wrote 8 lines
On 03/31/2001 at 1:07 AM wrote: >And: The compiler does not name the files; it is the programmer that does >this. True, but if you type "Uses blahblah;" in your code, the compiler will look for blahblah.pp, not blahblah.pas. It would be very nice if this were a command-line switch (if it is, it's one I've missed.)

It DOES look for blahblah.pas, but FIRST it searches for blahblah.pp

The compiler itself is written using '.pas' files, so this definitely works.

Show quoted text 6 lines
>It is always up to the programmer to code compiler-independent, the compiler >should not enforce anything. True, although it is sometimes difficult where compiler features do not intersect.

Then these features should not be used. This is part of programming compiler-independently...

Michael.

Reply by email

Unknown author
to Florian Klaempfl: Most stuff of widestrings is already implemented, the omissions are things which depend…
Florian Klaempfl wrote 9 lines
At 19:20 31.03.01 +0200, you wrote: >And: >- Widestrings Most stuff of widestrings is already implemented, the omissions are things which depend on the coding/code page, i.e. conversions between ansistring<->widestring<->shortstring; constant widestrings etc.

But this is an essential part. It will compile, but it won't work without the conversion routines.

Show quoted text 12 lines
>- Variants Yes, this requires some work... >- INterfaces Interface should work already quite good. >- Threads It requires some work, especially on Linux!

I know :/
I can't get this Kylix book finished soon enough.
Do some real development work again :/

Show quoted text 8 lines
(the comments above apply only to 1.1!!). >The FreeCLX contains almost no assembler except maybe in the system unit and >typinfo unit. Hmmm, at least in the classes unit I saw some assembler.

I also noticed. It is in the streaming routines. Apparently they tried to make the form loading a bit faster :) But it's not so much, and you can always subsitute some FPC code for it...

Michael.

Reply by email

Chris
to Marco van de Voort: No, it just needs some more IFDEFs, temporarily too afaik, since unit aliasing is going…
Show quoted text 11 lines
> started > > > recompiling the fpc under Delphi. Unfortunetly the FPC has all these > > > extensions to the language which makes it not-Delphi compatible. > > > > We see these 'extensions' as useful :) > > I don't disagree, however they are not Delphi compatible, which makes it > impossible to use Delphi for debugging. No, it just needs some more IFDEFs, temporarily too afaik, since unit aliasing is going to disappear in the long run from Delphi too?

Um, I was talking at this point about the pascal extensions like ++. Lack of unit aliasing isn't going to help any of the problems with file name extensions as well. It will probably just make them more pronounced.

> I understand wanting to be independent but really, it's more useful to

be

> able to debug your code, which while possible under linux, isn't nearly

so

> easy under windows. This has nothing to do with a cramped sense of independance. Delphi is a reasonably good product.

No argument there, I would like to use it to help develop FPC and lazarus.

However, sometimes different choices, and managing developper time economically can create things like this. The mere fact that it differs

from

Delphi already says enough. Most of those differences are choices that already had a fair share of discussion about them being different from Delphi.

The mere fact that it differs from Delphi already says enough? Very circular reasoning. I'm saying being different is not in our best interests, your saying that because it's different it should be.

Show quoted text 6 lines
> > Using .pp files marks them as files intended for Free Pascal. > > This can be an indication that FPC extensions are used, but this can > > also be useful for instance to be able to start up a different editor > > when double clicking a file in e.g. the windows explorer. > > Seems then that what is wanted is not something that is Delphi

compatible,

Show quoted text 5 lines
> but is compatible only unto itself. That is not true. What Michael tries to say is that the fact that we aren't Delphi itself, while Delphi might be on a developpers system already imposes restrictions in FPC.

I very rarly open any ide envioronment by clicking on the file. Not in, C++, Python or Pascal. The fact that there might be another IDE on your system that understands the same filename extensions, is a very weak argument for having different extensions. Especialy when compatiblity between Lazarus and Dephi is one of the criteria. I have been sitting here on my win32 machine not contributing because debugging using fpc on a win32 machine is not possible. (or at least not pleasent). If I were to be able to use Delphi I'm sure the development would move much more quickly.

> > And: The compiler does not name the files; it is the programmer that

does

> > this. > > The compiler enforces the names in the uses clause. I believe this was

the

> root of all my problems. That's consistancy :-)

Ok, ok, maybe not ALL my problems. :-)

Show quoted text 6 lines
> > It is always up to the programmer to code compiler-independent, the > compiler > > should not enforce anything. > > By the compiler definition, it will enforce code which is compiler > dependent. Using more then one compiler makes the code compiler

independent,

> which to me seems a worthwhile goal. > That's theory :-) Praxis Theory :-)

Your lack of experience is showing. I've had plenty of practice, and I know that when you use more then one compiler on one piece of code, that code becomes more independent of the compiler. Are you saying that you have used more then one compiler on a piece of code and have it become less independant?

regards,
Chris

Reply by email

Eric Lai

After reading the discussion about the problems which occured in the Win32 code. I have decided to analysis the code and rewrite it in Delphi 5. I believe that the development will be quicker and also produce faster and smaller exe. If you would like to help please contact me. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Reply by email

Marco van de Voort
to Chris: Um, I was talking at this point about the pascal extensions like ++. Lack of unit…
Hmm, lets turn this discussion into something more constructive;
Show quoted text 7 lines
> > I don't disagree, however they are not Delphi compatible, which > > makes it impossible to use Delphi for debugging. > > No, it just needs some more IFDEFs, temporarily too afaik, since unit > aliasing is going to disappear in the long run from Delphi too? Um, I was talking at this point about the pascal extensions like ++.

Then I misunderstood, and then I'm very interested in a list of language incompabilities.

I never saw the ++ thing in the wild, and it was only meant for easy porting. If Lazarus contains it, it should be killed IMHO, period.

Actually the only extension I really miss in Delphi (and therefore have to use amd fix sometimes) is the ^simpletype thing.

Show quoted text 9 lines
> However, sometimes different choices, and managing developper time > economically can create things like this. The mere fact that it > differs from > Delphi already says enough. Most of those differences are choices that > already had a fair share of discussion about them being different from > Delphi. The mere fact that it differs from Delphi already says enough?

Lazarus/FPC was meant to be a standalone system. Not a Delphi plugin. Anyway, we could try to create a script that renames some files.

I very rarly open any ide envioronment by clicking on the file. Not in, C++, Python or Pascal. The fact that there might be another IDE on your system that understands the same filename extensions, is a very weak argument for having different extensions.

Actually that isn't. Most people that use FPC (semi-)professionally have Delphi installed.

Show quoted text 6 lines
Especialy when compatiblity between Lazarus and Dephi is one of the criteria. I have been sitting here on my win32 machine not contributing because debugging using fpc on a win32 machine is not possible. (or at least not pleasent). If I were to be able to use Delphi I'm sure the development would move much more quickly.

Then, let's
- create the script that copy/renames the local repository,
- kill C style operators.

Show quoted text 9 lines
> > By the compiler definition, it will enforce code which is compiler > > dependent. Using more then one compiler makes the code compiler independent, > > which to me seems a worthwhile goal. > > > > That's theory :-) Praxis Theory :-) Your lack of experience is showing.

As FPC core member or as Delphi programmer? :-)

I've had plenty of practice, and I know that when you use more then one compiler on one piece of code, that code becomes more independent of the compiler.

Hmm, I was more thinking of the IFDEFing and maintainability. Then using more compilers obfuscates.

Are you saying that you have used more then one compiler on a piece of code and have it become less independant?

Sure. You use technique C which both compiler A and B provide as ugly backdoor construct. That turns out to be incompabitle with D.

Marco van de Voort ( or )

Reply by email

Florian Klaempfl
to Eric Lai: After reading the discussion about the problems which occured in the Win32 code. I have…
you wrote
After reading the discussion about the problems which occured in the Win32 code. I have decided to analysis the code and rewrite it in Delphi 5. I believe that the development will be quicker and also produce faster and smaller exe.

I doubt this :)
We tried to compile FPC itself with Delphi 4 and Delphi 5 and our experiences were very bad:
First, it took a lot of time to work around the delphi compiler bugs, the main problems were the unit interdependencies and the optimizer.

Secondly (if you get something running), the compiler compiled by delphi is two times slower than a compiler compiled by FPC :). Reasons:
- the Delphi heap manager is slow
- the optimizer was switched off for several units (see above)
- the Delphi register allocator is good when your using simple expressions while the FPC sources are full of rather complex expressions

So I don't think that it is easy to compile Lazarus with Delphi. Afaik the Delphi IDE isn't written in Delphi either...

Reply by email

Unknown author
to Chris: Thank you all for responding to my queries and comments. If I understand you all…
Chris wrote 7 lines
I think that sums up the discussions, did I miss anything important? OK, my comments back. 1. I must have been mistaken in this. 2. I don't like, but maybe that's just me. 3. My view is it's better to use multiple compilers to reduce compiler dependence. (To me it seems self evident).

I also think that if compiler independence is a goal, then you should use different compilers to test this. It is indeed self-evident.

I don't think compiler independence has ever been stated as a goal, but I also don't think that this 'omission' was intentional...

Michael.

Reply by email

Unknown author
to Florian Klaempfl: Now I'am confused! Delphi and C++ builder are the same?!?! I think, I need some…
Florian Klaempfl wrote 9 lines
At 17:00 31.03.01 +0200, you wrote: > > > > So I don't think that it is easy to compile Lazarus with Delphi. Afaik > > the Delphi IDE isn't written in Delphi either... > >It is. The IDE is written in Delphi, or C++ builder. Which is the same. Now I'am confused! Delphi and C++ builder are the same?!?! I think, I need some explanation here :)

They use the same back end and the same IDE.
What more can be the same ?
The only thing which is different is the parser and probably the expression evaluator.

BTW: I'd a short look on the FreeCLX and I'am quite shocked how Borland did the porting: it's full of {$ifdef Linux}...{$endif} etc..

Well, we have some experience with cross-platform development, which they don't.

The next weeks, I'll spend some time in trying to get it compiled with FPC. The main problem will be probably the assembler...

And:
- Widestrings
- Variants
- INterfaces
- Threads
The FreeCLX contains almost no assembler except maybe in the system unit and typinfo unit.

Michael.

Reply by email

Thierry Coq
to Chris: Thank you all for responding to my queries and comments. If I understand you all…
you wrote 8 lines
I think the main point is that every compiler is buggy and if you've a medium sized project (100000-1000000 lines of code), it's already quite hard to port it to another compiler because there are a lot of workarounds to hide bugs of a compiler. Especially if you've a language like Object Pascal for which no real standard or test suites exit.

Talking about test suites : does FPC or Lazarus compile with DUnit ? Is there someone out there thinking about it ?

Would it be useful to implement a set of tests for compilers to pass in order to qualify as 'object pascal' ? or at least to measure the features and lacks of various compilers and/or options ? This could a very interesting tool in (semi-) professional situations...

Thierry Coq

Reply by email

Chris
to Marco van de Voort: Hmm, lets turn this discussion into something more constructive; Then I misunderstood,…

Thank you all for responding to my queries and comments.

If I understand you all correctly then:
1. fpc uses .pas and is a better compiler then Delphi so no need to change to Delphi for development purposes on win32 systems.
2. lazarus uses .pp for mainly historical reasons, but the people who use it think it's nice, and don't feel a need for compiling in Delphi on win32 systems.
3. Views are divided on the idea of multiple compilers making compiler independant code.
4. There are no FPC language extensions in Lazarus and if there are then they should be removed.
5. Florian thinks that compiling the IDE in Delphi will not be productive because of Delphi's buggy compiler.

I think that sums up the discussions, did I miss anything important?

OK, my comments back.
1. I must have been mistaken in this.
2. I don't like, but maybe that's just me.
3. My view is it's better to use multiple compilers to reduce compiler dependence. (To me it seems self evident).
4. I agree.
5. I'm not so sure, since the current editor was originally written as a delphi component, that shouldn't be too much to make compatible again. Also the reason I want to be able to develop Lazarus in Delphi was not so much because of the editor, but because of the debugger.

Hope this doesn't sound so caustic this time. It wasn't intentional.

Regards,
Chris.

Reply by email

Marco van de Voort
to Florian Klaempfl: Of course, it would. But who should make such a test suite? We (FPC), Borland or the VP…
Show quoted text 6 lines
>Would it be useful to implement a set of tests for compilers to pass >in order to qualify as 'object pascal' ? Of course, it would. But who should make such a test suite? We (FPC), Borland or the VP people? Or an independend team? First, a proper definition of the "Object Pascal" language would be necessary.

And the problem is also that the players are not equal. What would keep Borland from breaking them?

At least FPC has it's own test suite which consist of >1000 files. You can get it via cvs: fpc/tests

Reply by email

Florian Klaempfl
to Florian Klaempfl: .... I think the main point is that every compiler is buggy and if you've a medium sized…
you wrote
Would it be useful to implement a set of tests for compilers to pass in order to qualify as 'object pascal' ?

Of course, it would. But who should make such a test suite? We (FPC), Borland or the VP people? Or an independend team? First, a proper definition of the "Object Pascal" language would be necessary.

At least FPC has it's own test suite which consist of >1000 files. You can get it via cvs: fpc/tests

Reply by email