Freepascal vs GNU-Pascal 
Author Message
 Freepascal vs GNU-Pascal

Hi,

I want to run a Pascal-environment under linux.
I found Free-Pascal and GNU-Pascal. As far as i saw they share most features.
Does anyone have experiences with both and can tell which one is choice Nr. 1 ?

thx

Marcus



Tue, 11 Jan 2005 17:00:58 GMT  
 Freepascal vs GNU-Pascal

Quote:

> Hi,

> I want to run a pascal-environment under linux.
> I found Free-Pascal and GNU-Pascal. As far as i saw they share most features.
> Does anyone have experiences with both and can tell which one is choice Nr. 1 ?

FPC has most of its Delphi compability in place, and doesn't miss certain
Borland features. There is also a lot of 3rd party source.

I advise you to use FPC (but I'm biassed as FPC developper), unless:
- You do large amounts of scientific numerical calculations. (maybe the GCC
    optimizer could speed things up a bit)
- You expect to need to run your programs on other architectures than PCs in
    say the next year.



Tue, 11 Jan 2005 18:16:20 GMT  
 Freepascal vs GNU-Pascal

Quote:

> Hi,

> I want to run a pascal-environment under linux.
> I found Free-Pascal and GNU-Pascal. As far as i saw they share most features.
> Does anyone have experiences with both and can tell which one is choice Nr. 1 ?

I use freepascal 1.0.4 for linux.  I don't recommend upgrading to 1.0.6
unless you are strongly typecasted, but it is a good replacement for
another package I used to use, BP7.01 and supports cross platform
development.  Also, get familiar with:

{$packrecords 1}
{$packenum 1}

If you don't, many byte size structures will occupy longint size space.



Tue, 11 Jan 2005 18:19:14 GMT  
 Freepascal vs GNU-Pascal

Quote:


>> Hi,

>> I want to run a pascal-environment under linux.
>> I found Free-Pascal and GNU-Pascal. As far as i saw they share most features.
>> Does anyone have experiences with both and can tell which one is choice Nr. 1 ?

> I use freepascal 1.0.4 for linux.  I don't recommend upgrading to 1.0.6
> unless you are strongly typecasted, but it is a good replacement for
> another package I used to use, BP7.01 and supports cross platform
> development.  Also, get familiar with:

> {$packrecords 1}
> {$packenum 1}

> If you don't, many byte size structures will occupy longint size space.

This should be automatical in strict TP mode.


Tue, 11 Jan 2005 19:05:29 GMT  
 Freepascal vs GNU-Pascal
On Thu, 8 Aug 2002 21:11:53 +0000 (UTC), Marco van de Voort

[...]

Quote:
>I don't like the missing of runtime checks either, but in my experiments
>with GPC(helped people compile existing pascal bases on Sparc), the
>identifier re-usage problem was more important, I'm glad it is finally
>tackled.

>This might not just affect
>BP code, but could also be a problem with the ISO 10206 standard.

>The qualified identifier problem is very annoying, but not a problem that
>can't be circumvented.

The qualified identifier problem is a linker problem (basically GNU
'ld' chokes when it comes across multiple definitions of an
identifier). Hopefully, this one will be solved in due course.

I think that the real point to make about fpc versus gpc is that it
all depends on what you want to do. If your aim is to keep using large
amounts of TP/Delphi code, then fpc should be your choice. If
portability is a serious concern, then gpc is hard to beat. You can
have it on almost any platform for which there is a GNU C compiler. If
you are coding from the scratch, then with some care and attention,
you can write portable code with either fpc or gpc - code that will
compile with both fpc and gpc, and also with Delphi, Kylix, and TP.
This is not only possible, it is quite easy to achieve (for example, I
have written programs (some commercial) and units that run into
thousands of lines and that compile with all of the above - under
Windows and Linux, and in the case of gpc, also under Solaris).

Best regards, The Chief
-----------------------
Prof. A{*filter*}la Olowofoyeku (The African Chief)
  http://www.*-*-*.com/ ~african_chief/



Fri, 04 Feb 2005 19:49:25 GMT  
 Freepascal vs GNU-Pascal

Quote:
> On Thu, 8 Aug 2002 21:11:53 +0000 (UTC), Marco van de Voort

>>This might not just affect
>>BP code, but could also be a problem with the ISO 10206 standard.

>>The qualified identifier problem is very annoying, but not a problem that
>>can't be circumvented.

> The qualified identifier problem is a linker problem (basically GNU
> 'ld' chokes when it comes across multiple definitions of an
> identifier). Hopefully, this one will be solved in due course.

Or GPC fails to create unique identifiers? E.g. by prefixing unitname?

Quote:
> I think that the real point to make about fpc versus gpc is that it
> all depends on what you want to do. If your aim is to keep using large
> amounts of TP/Delphi code, then fpc should be your choice. If
> portability is a serious concern, then gpc is hard to beat. You can
> have it on almost any platform for which there is a GNU C compiler.

If there are binaries for that problem, or building it is more or less
debugged. Otherwise you have to be a compiler guru to get it to build.

Quote:
> you are coding from the scratch, then with some care and attention,
> you can write portable code with either fpc or gpc - code that will
> compile with both fpc and gpc, and also with Delphi, Kylix, and TP.
> This is not only possible, it is quite easy to achieve (for example, I
> have written programs (some commercial) and units that run into
> thousands of lines and that compile with all of the above - under
> Windows and Linux, and in the case of gpc, also under Solaris).

FPC also compiles for Solaris, but only for x86 :-)

So for one project I used GPC for Solaris, which quite doable, except for
the problems I mentioned.

Somebody else did build (or installed bins) for gpc though, I came only
later. Note that this wasn't very odd-ball TP/BP code, but written in a very
clean, portable minimal subset.

What is btw the largest known GPC program?



Fri, 04 Feb 2005 19:58:31 GMT  
 Freepascal vs GNU-Pascal

Quote:
> I think that the real point to make about fpc versus gpc is that it
> all depends on what you want to do. If your aim is to keep using large
> amounts of TP/Delphi code, then fpc should be your choice. If
> portability is a serious concern, then gpc is hard to beat. You can
> have it on almost any platform for which there is a GNU C compiler. If
> you are coding from the scratch, then with some care and attention,
> you can write portable code with either fpc or gpc - code that will
> compile with both fpc and gpc, and also with Delphi, Kylix, and TP.
> This is not only possible, it is quite easy to achieve (for example, I
> have written programs (some commercial) and units that run into
> thousands of lines and that compile with all of the above - under
> Windows and Linux, and in the case of gpc, also under Solaris).

> Best regards, The Chief
> -----------------------
> Prof. A{*filter*}la Olowofoyeku (The African Chief)
>   http://www.*-*-*.com/ ~african_chief/

I did some work a while back with implementing modules (units) that emulated
TPC functions, the idea being to make it easier to bring in some TPC
programs and run them. Even if you aren't %100 TPC compatible, the result
is a large decrease in the porting work, but at the same time, you are
still left with programs that are foreign to the general "flow" of your
compiler system, ie., don't use your standard libaries etc.

Perhaps more important, there are really two completely different ways
to go about that work. You can implement TPC units in such a way as
to act as a translation layer into your normal library calls, or you
can implement the modules so that they stand on their own. The first
method gives you units that, written once, port to anywhere your
standard libraries go, but give you a less perfect compatibility
layer for TPC. The second gives you better TPC compliance, but
less portability, etc.

I think the lesson is that a general compiler like GPC is better off
implementing TPC units whose goal is to allow TPC users to make perhaps
small program changes, but get better cross platform portability,
and for users who do not plan to stay TPC compatible. FPC serves
the user who wants to stay as compatible as possible with TPC, but
get the portability of cross platform.

Its also worth remembering that TPCs "portability" of base units occurs
mainly from its abstraction of base PC hardware, and it was never
really designed to be portable. A good example is the mode selection
in the crt unit. It is possible to do a lot to emulate that inherent
resolution changing feature on multiple platforms, but fundamentally
that is a PC platform dependent feature. What was easy for the
TPC developers is now a pain for the porters.



Sat, 05 Feb 2005 23:56:44 GMT  
 Freepascal vs GNU-Pascal

Quote:


> I think the lesson is that a general compiler like GPC is better off
> implementing TPC units whose goal is to allow TPC users to make perhaps
> small program changes, but get better cross platform portability,
> and for users who do not plan to stay TPC compatible. FPC serves
> the user who wants to stay as compatible as possible with TPC, but
> get the portability of cross platform.

> Its also worth remembering that TPCs "portability" of base units occurs
> mainly from its abstraction of base PC hardware, and it was never
> really designed to be portable. A good example is the mode selection
> in the crt unit. It is possible to do a lot to emulate that inherent
> resolution changing feature on multiple platforms, but fundamentally
> that is a PC platform dependent feature. What was easy for the
> TPC developers is now a pain for the porters.

Odd example. For nearly all such non portable TPC features there is
no portable substitute at all.
So if you need such functionality, it will be non-portable per definition,
TPC or otherwise. IOW the difference in the story above are in the design
of the application, and have nothing to do with which dialect you choose.

If you want to bash TPC on portability, then please provide real examples.



Sun, 06 Feb 2005 02:57:31 GMT  
 Freepascal vs GNU-Pascal

Quote:



> > I think the lesson is that a general compiler like GPC is better off
> > implementing TPC units whose goal is to allow TPC users to make perhaps
> > small program changes, but get better cross platform portability,
> > and for users who do not plan to stay TPC compatible. FPC serves
> > the user who wants to stay as compatible as possible with TPC, but
> > get the portability of cross platform.

> > Its also worth remembering that TPCs "portability" of base units occurs
> > mainly from its abstraction of base PC hardware, and it was never
> > really designed to be portable. A good example is the mode selection
> > in the crt unit. It is possible to do a lot to emulate that inherent
> > resolution changing feature on multiple platforms, but fundamentally
> > that is a PC platform dependent feature. What was easy for the
> > TPC developers is now a pain for the porters.

> Odd example. For nearly all such non portable TPC features there is
> no portable substitute at all.
> So if you need such functionality, it will be non-portable per definition,
> TPC or otherwise. IOW the difference in the story above are in the design
> of the application, and have nothing to do with which dialect you choose.

> If you want to bash TPC on portability, then please provide real examples.

I don't remember "bashing TPC on portability" in that message. Sorry you got
that impression.


Sun, 06 Feb 2005 15:48:25 GMT  
 Freepascal vs GNU-Pascal

Quote:




>> > I think the lesson is that a general compiler like GPC is better off
>> > implementing TPC units whose goal is to allow TPC users to make perhaps
>> > small program changes, but get better cross platform portability,
>> > and for users who do not plan to stay TPC compatible. FPC serves
>> > the user who wants to stay as compatible as possible with TPC, but
>> > get the portability of cross platform.

>> > Its also worth remembering that TPCs "portability" of base units occurs
>> > mainly from its abstraction of base PC hardware, and it was never
>> > really designed to be portable. A good example is the mode selection
>> > in the crt unit. It is possible to do a lot to emulate that inherent
>> > resolution changing feature on multiple platforms, but fundamentally
>> > that is a PC platform dependent feature. What was easy for the
>> > TPC developers is now a pain for the porters.

>> Odd example. For nearly all such non portable TPC features there is
>> no portable substitute at all.
>> So if you need such functionality, it will be non-portable per definition,
>> TPC or otherwise. IOW the difference in the story above are in the design
>> of the application, and have nothing to do with which dialect you choose.

>> If you want to bash TPC on portability, then please provide real examples.

> I don't remember "bashing TPC on portability" in that message. Sorry you got
> that impression.

Bashing can occur on correct grounds, so it was not necessarily meant
negative.

However most unportabilities of TP/BP can be seen as usage of extra OS
dependant extensions (which nearly all compilers have), while the core
language is reasonly OS-independant (something we'd like to prove later next
month by porting FPC to PPC based machines.)



Sun, 06 Feb 2005 16:41:20 GMT  
 Freepascal vs GNU-Pascal
On Mon, 19 Aug 2002 11:58:31 +0000 (UTC), Marco van de Voort

Quote:


>> On Thu, 8 Aug 2002 21:11:53 +0000 (UTC), Marco van de Voort

[...]
>> The qualified identifier problem is a linker problem (basically GNU
>> 'ld' chokes when it comes across multiple definitions of an
>> identifier). Hopefully, this one will be solved in due course.

>Or GPC fails to create unique identifiers? E.g. by prefixing unitname?

If it were that simple, it would have been done a long time ago.

Quote:
>> I think that the real point to make about fpc versus gpc is that it
>> all depends on what you want to do. If your aim is to keep using large
>> amounts of TP/Delphi code, then fpc should be your choice. If
>> portability is a serious concern, then gpc is hard to beat. You can
>> have it on almost any platform for which there is a GNU C compiler.

>If there are binaries for that problem, or building it is more or less
>debugged. Otherwise you have to be a compiler guru to get it to build.

I think not. I am not a compiler guru (I am only a compiler user) but
I build gcc/gpc all the time. I think it requires knowing the
underlying OS and the GNU tools more than knowing about compilers.

[...]

Quote:
>What is btw the largest known GPC program?

Dunno. I have ported a large-ish commercial application from
Delphi/Windows to GPC running under Windows, Linux and Solaris
(Sparc). It didn't take that long to accomplish and most of my
problems came from some rather sloppy programming by the original
coders which Delphi covered up for them, but I cannot say any more
about that project ...

Best regards, The Chief
-----------------------
Prof. A{*filter*}la Olowofoyeku (The African Chief)
  http://www.*-*-*.com/ ~african_chief/



Sun, 06 Feb 2005 20:51:50 GMT  
 Freepascal vs GNU-Pascal
On Tue, 20 Aug 2002 18:57:31 +0000 (UTC), Marco van de Voort

Quote:


[...]
>> Its also worth remembering that TPCs "portability" of base units occurs
>> mainly from its abstraction of base PC hardware, and it was never
>> really designed to be portable. A good example is the mode selection
>> in the crt unit. It is possible to do a lot to emulate that inherent
>> resolution changing feature on multiple platforms, but fundamentally
>> that is a PC platform dependent feature. What was easy for the
>> TPC developers is now a pain for the porters.

>Odd example. For nearly all such non portable TPC features there is
>no portable substitute at all.
>So if you need such functionality, it will be non-portable per definition,

Not necessarily. There are free portable libraries around to do all
sorts of things. All you need to do is to interface to them, rather
than reinvent the wheel yourself. With regard to the Crt unit for
example, using the *curses libraries means that you don't have to
re-code from the scratch for every platform that you wish to support.
You immediately have support for all platforms supported by
ncurses/pdcurses/xcurses, etc. Even if the *curses sources themselves
are not 100% portable, they are probably more portable than what one
could achieve by reinventing the wheel.

Best regards, The Chief
-----------------------
Prof. A{*filter*}la Olowofoyeku (The African Chief)
  http://www.*-*-*.com/ ~african_chief/



Sun, 06 Feb 2005 20:59:24 GMT  
 Freepascal vs GNU-Pascal

Quote:
> On Tue, 20 Aug 2002 18:57:31 +0000 (UTC), Marco van de Voort


> [...]
>>> Its also worth remembering that TPCs "portability" of base units occurs
>>> mainly from its abstraction of base PC hardware, and it was never
>>> really designed to be portable. A good example is the mode selection
>>> in the crt unit. It is possible to do a lot to emulate that inherent
>>> resolution changing feature on multiple platforms, but fundamentally
>>> that is a PC platform dependent feature. What was easy for the
>>> TPC developers is now a pain for the porters.

>>Odd example. For nearly all such non portable TPC features there is
>>no portable substitute at all.
>>So if you need such functionality, it will be non-portable per definition,

> Not necessarily. There are free portable libraries around to do all
> sorts of things. All you need to do is to interface to them, rather
> than reinvent the wheel yourself

Crt can be based on NCurses, and the things that can't, can only be done by special
libraries like SVGALIB, which are less portable.

So that is not a pre. One has to have a interface to such libraries, and I
prefer the Pascal interfaces of Crt and Turbo Vision more than the direct
NCurses interface that is, euuh, crappy.

Quote:
> With regard to the Crt unit for example, using the *curses libraries
> means that you don't have to re-code from the scratch for every platform
> that you wish to support. You immediately have support for all platforms
> supported by ncurses/pdcurses/xcurses, etc.

No. With Crt I can e.g. capture ctrl-alt-F9. It was quite difficult to get that right with
FreeBSD/Linux, there are several other examples (like textmode mouse support in an xterm other
than Linux etc)

It works fine under Linux, Windows and Dos,  but if you move to *BSD, quite a
lot already breaks, and Windows and Dos weren't a problem in the first place.

Quote:
> Even if the *curses sources themselves are not 100% portable, they are
> probably more portable than what one could achieve by reinventing the
> wheel.

I don't think so. They are overly complex and slow.  (I actually traced 2
hours through it before it wrote a character to the screen), doing a lot of
hashing and pattermatching, which might have been nice in the 300 baud
teletype period, but is over the top for a modern intranet.

One can better base a few lines of code directly on the NCurses terminfo
part, and cover most of the usually used platforms.

NCurses is nice for a first approximation, but not more than that. I use it
a lot, but often abandon it when the application matures.

For that I've several different implementations (and ifdef compile options)
for one set of interfaces.



Sun, 06 Feb 2005 21:33:30 GMT  
 Freepascal vs GNU-Pascal
On Wed, 21 Aug 2002 13:33:30 +0000 (UTC), Marco van de Voort

Quote:


[...]
>Crt can be based on NCurses, and the things that can't, can only be done by special
>libraries like SVGALIB, which are less portable.

>So that is not a pre. One has to have a interface to such libraries, and I
>prefer the Pascal interfaces of Crt and Turbo Vision more than the direct
>NCurses interface that is, euuh, crappy.

Perhaps we are speaking at cross purposes. I was not advocating
calling curses directly in programs, but rather basing the Crt unit on
curses code, which is what gpc does. AFAICS there is nothing crappy in
the Crt unit, where the interface is the same as TP/BP's Crt unit. I
don't have to look at the curses code itself, which is written in C.

Quote:
>> With regard to the Crt unit for example, using the *curses libraries
>> means that you don't have to re-code from the scratch for every platform
>> that you wish to support. You immediately have support for all platforms
>> supported by ncurses/pdcurses/xcurses, etc.

>No. With Crt I can e.g. capture ctrl-alt-F9. It was quite difficult to get that right with
>FreeBSD/Linux, there are several other examples (like textmode mouse support in an xterm other
>than Linux etc)

I have no problem capturing that with gpc's Crt unit.

Quote:
>It works fine under Linux, Windows and Dos,  but if you move to *BSD, quite a
>lot already breaks, and Windows and Dos weren't a problem in the first place.

That just means that they haven't got ncurses working right under BSD.
If so, that can change at any time.

Quote:
>> Even if the *curses sources themselves are not 100% portable, they are
>> probably more portable than what one could achieve by reinventing the
>> wheel.

>I don't think so. They are overly complex and slow.  (I actually traced 2
>hours through it before it wrote a character to the screen), doing a lot of
>hashing and pattermatching, which might have been nice in the 300 baud
>teletype period, but is over the top for a modern intranet.

Each to his own - but I haven't had any problems using the
curses-based Crt unit, and I have not found it to be either complex or
slow. It is exactly the same as any other Crt unit that I have used,
and the same code compiles and behaves the same way. Perhaps I just
don't do the types of complex Crt unit programming that you do.

Quote:
>One can better base a few lines of code directly on the NCurses terminfo
>part, and cover most of the usually used platforms.

Involves direct coding for each platform that you want to support. To
me, that is not portable programming - it is multiple coding. Not
exactly very efficient time-wise, even if the code runs faster because
of the direct use of native (hence non-portable) APIs. My time is far
more expensive than cpu or gpu processing power - and I am sure that
the same goes for every programmer.

Best regards, The Chief
-----------------------
Prof. A{*filter*}la Olowofoyeku (The African Chief)
  http://www.*-*-*.com/ ~african_chief/



Sun, 06 Feb 2005 23:02:48 GMT  
 Freepascal vs GNU-Pascal

Quote:
> Bashing can occur on correct grounds, so it was not necessarily meant
> negative.

> However most unportabilities of TP/BP can be seen as usage of extra OS
> dependant extensions (which nearly all compilers have), while the core
> language is reasonly OS-independant (something we'd like to prove later next
> month by porting FPC to PPC based machines.)

I gave it some thought. Can we agree on some ground rules ? I don't believe
TPC was meant to be truly portable. Its not a bash. The system was designed
to run on the PC, the largest platform then and now. There are some things
done wrong there, some things done right (I have copied a few things I like
from TPC). They got that language out in a short amount of time, and made
lots of important milestones (the IDE for instance).

Neither I believe was TPC ever designed to be particularly compatible with
the original Pascal language. Borland first claimed it was, then said they
didn't need to be, and now are deemphasising the name "Pascal" in general,
prefering "delphi" with "Pascal" left in the small print.

TPC was an important project. Its gone now as a commercial project, and
has passed on to public supporters such as FPC. It is what it is. I admit
I didn't like a lot of the decisions Borland made, but those days are long
gone, and I only want to talk about TPC objectively. If I get out of line,
you surely will let me know :)



Mon, 07 Feb 2005 00:55:18 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Best of GNU-PAscal, FreePAscal, VPascal???

2. GNU Pascal: type of File vs. GPC_AnyFile

3. GNU Pascal vs. output of tangle

4. TP4 vs FreePascal

5. Turbo Pascal to GNU Pascal

6. TTable vs TQuery vs TwwQuery vs TwwTable - SPEED

7. GNU Pascal 2.1 released

8. Full-featured debugger, and pretty-printer, for GNU Pascal (gpc)

9. intalling gnu pascal - help

10. GNU Pascal 2.1 released

11. GNU pascal binaries for Windows

12. Looking for GNU Pascal consultant

 

 
Powered by phpBB® Forum Software