[fpc-pascal]Re: 1. Mandrake & 2. FPC with WINE and crosscompiling

[Arne Hanssen]

On Sat, 18 Jan 2003 19:20:45 +0100 (MET), Holger Peterrs wrote:
>  Hi,
>  
>  1. At home I'm working with FreePascal for Windows. But in extra curricular
>  lessons, I work with Linux (Mandrake). I tried to install FreePascal for
>  Linux on this comuter, but it didn't work. For example there is no IDE and if I
>  start fpc in the console, there is no output. Is it because I am not logged in
>  as a root user? How can I solve this?

You must install as root.  'fpc' or 'ppc386' commands should invoke the
compiler.
As far as I know the IDE for Linux is not quite ready...  I use VIM to
edit my code.  Put this in your '.vimrc'-file:

  " Pascal syntax settings
  let pascal_vp=1
  let pascal_fpc=1
  " Set vim-make to run FPC compiler
  set makeprg=fpc.sh\ #<.pas

'fpc.sh' is my own shellscript:

  #!/bin/bash
  #mydef="DEBUG"
  mydef="RELEASE"
  ppc386 -d$mydef \
-FE/home/arne/bin \
FU/home/arne/bin/Units \
Fu/home/arne/bin/Units \
$*

Then I know where my executables and object files goes.

>  2. If there is no solution, can I run the windows version of FreePascal with
>  WINE and compile the programs for Linux (crosscompiling)? If yes, how can I
>  do this? 

I should guess so (crosscompiling is also possible, but I've never tried to
set up fpc to do so).

-- 
Vennlig hilsen / Best regards
Arne Hanssen
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal]Graphics woes

[Carl Eric Codere]

>> I can't test GGI. Maybe we should then remove all the GGI graph as it
>> doesn't work 100% correct?  Then it'll never get debugged and fixed!
>
>I can't remember exactly who added the GGI version to CVS, but IIRC I
>just posted a first version back then and clearly noted that ggigraph is
>not finished and may never get finished by me. And currently it doesn't
>seem to make sense to support GGI anymore: The graph unit cannot really
>handle large bit depths, GGI doesn't support the 4 bpp modes, and
>finally in the future fpGFX will support GGI much better than ggigraph
>ver could.
>If you want to, then remove it, I will not continue ggigraph.
>
>Sebastian---
>
>I cannot find much progress in fpGFX 'cept some reference to its being
>'really beta'.

Greetings,
   Personally i would remove ggigraph support from the CVS
tree and replace with a unified (except for DOS) graph unit based on SDL...
I think this is the way to go.. The only problem is of course implementing
and testing this :(...



___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Graphics woes

[Michael Van Canneyt]

On Tue, 28 Jan 2003, Carl Eric Codere wrote:

> >> I can't test GGI. Maybe we should then remove all the GGI graph as it
> >> doesn't work 100% correct?  Then it'll never get debugged and fixed!
> >
> >I can't remember exactly who added the GGI version to CVS, but IIRC I
> >just posted a first version back then and clearly noted that ggigraph is
> >not finished and may never get finished by me. And currently it doesn't
> >seem to make sense to support GGI anymore: The graph unit cannot really
> >handle large bit depths, GGI doesn't support the 4 bpp modes, and
> >finally in the future fpGFX will support GGI much better than ggigraph
> >ver could.
> >If you want to, then remove it, I will not continue ggigraph.
> >
> >Sebastian---
> >
> >I cannot find much progress in fpGFX 'cept some reference to its being
> >'really beta'.
>
> Greetings,
>Personally i would remove ggigraph support from the CVS
> tree and replace with a unified (except for DOS) graph unit based on SDL...
> I think this is the way to go.. The only problem is of course implementing
> and testing this :(...

This has been discussed before. SDL is not a standard library on most
systems, and hence is not a suitable choice to base the graph unit on.

The same goes for ggi, which is why it is a separate unit in the first
place.

Michael.

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Graphics woes

[Jonas Maebe]

On dinsdag, jan 28, 2003, at 11:08 Europe/Brussels, Michael Van Canneyt 
wrote:

   Personally i would remove ggigraph support from the CVS
tree and replace with a unified (except for DOS) graph unit based on 
SDL...
I think this is the way to go.. The only problem is of course 
implementing
and testing this :(...

This has been discussed before. SDL is not a standard library on most
systems, and hence is not a suitable choice to base the graph unit on.

The same goes for ggi, which is why it is a separate unit in the first
place.


Given the large amount of question about "can't find -lvga when 
compiling graph programs under linux" I would say the same about 
lib(s)vga. I also think SDL would be a better choice (though someone 
needs to do it of course :/ )


Jonas

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Andreas K. Foerster]

On Mon, Jan 27, 2003 at 10:42:37PM +0100, Marco van de Voort wrote:

> > Will there also be sopport for conformant Arrays as they are defined 
> > in standard Pascal (ISO-7185)?
> 
> Not that I'm aware of (unless you plan to implement it ? ).

No, I can't do it.

The point is just, that I'm still disappointed that FPC isn't
compatible to any of the official Pascal standards and that it's not
even trying to become compatible.

I'm very much drawn back and forth between FreePascal and GNU Pascal.
Both have their advantages, but also their disadvantages. FreePascal
has more commands, but GNU Pascal knows a much more elaborated syntax.
FreePascal supports just one dialect, GNU Pascal knows different
dialects including the standards. FreePascal has lots of systemspecific
extentions, but programs written with them aren't portable,
even not between the different variants of FreePascal itself. 
GNU Pascal tries to leave systemspecific things away, that means that
programs are nearly always portable, but also that things are missing.
GNU Pascal (the compiler itself) is very portable, while FreePascal is 
mainly targeted to PCs and porting to other platforms seems to take a
lot of time. On the other hand GNU Pascal is hard to install, 
especially on non-Unix systems. GNU Pascal is the better Pascal, when 
you look at the source code of your programming, but FreePascal is the 
better compiler, when you look at the binary that comes out...
  
What I really want would be a mixture of both!

At the moment I try to use only what both have in common. But
unfortunately that's not much. I have to avoid commands because of
GPC and I have to use a simpler syntax because of FPC.

That's why I try to suggest that FPC should become more standard
compatible, to be able to write more portable code. 

Okay, I see that it's difficult to implement.
But what about things that look similar? 

For example initialized variables...

FPC has this syntax:
const i: integer = 0;
But it's so very unlogical to use a "const" as variable. :-(
(GPC accepts this syntax, but gives a warning)

Extended Pascal (ISO-10206) declares this syntax:
var i: integer value 0;
Much nicer, isn't it?

That at least looks very similar so I hope, at least that will be
simpler for you to implement...

BTW. you might wonder why Extended Pascal uses "value" and not the
equal-sign. That is because it also defines initialized types:
type myint = integer value 0;
so that all variables that use this type are initialized.
Here a second equal-sign would look strange.

Or what about String definitions:
FPC: 
var s: string[255];
ISO-10206:
var s: string(255);  {btw. not limited to 255}
Would it be so difficult to accept parantheses instead of brackets?
GPC accepts both.

-- 
Tschuess
Andreas
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[James Mills]

On Tue, Jan 28, 2003 at 12:05:28PM +0100, Andreas K. Foerster wrote:
> On Mon, Jan 27, 2003 at 10:42:37PM +0100, Marco van de Voort wrote:
> 
> > > Will there also be sopport for conformant Arrays as they are defined 
> > > in standard Pascal (ISO-7185)?
> > 
> > Not that I'm aware of (unless you plan to implement it ? ).
> 
> No, I can't do it.
> 
> The point is just, that I'm still disappointed that FPC isn't
> compatible to any of the official Pascal standards and that it's not
> even trying to become compatible.
> 
> I'm very much drawn back and forth between FreePascal and GNU Pascal.
> Both have their advantages, but also their disadvantages. FreePascal
> has more commands, but GNU Pascal knows a much more elaborated syntax.
> FreePascal supports just one dialect, GNU Pascal knows different
> dialects including the standards. FreePascal has lots of systemspecific
> extentions, but programs written with them aren't portable,
> even not between the different variants of FreePascal itself. 
> GNU Pascal tries to leave systemspecific things away, that means that
> programs are nearly always portable, but also that things are missing.
> GNU Pascal (the compiler itself) is very portable, while FreePascal is 
> mainly targeted to PCs and porting to other platforms seems to take a
> lot of time. On the other hand GNU Pascal is hard to install, 
> especially on non-Unix systems. GNU Pascal is the better Pascal, when 
> you look at the source code of your programming, but FreePascal is the 
> better compiler, when you look at the binary that comes out...
>   
> What I really want would be a mixture of both!
> 
> At the moment I try to use only what both have in common. But
> unfortunately that's not much. I have to avoid commands because of
> GPC and I have to use a simpler syntax because of FPC.
> 
> That's why I try to suggest that FPC should become more standard
> compatible, to be able to write more portable code. 
> 
> Okay, I see that it's difficult to implement.
> But what about things that look similar? 
> 
> For example initialized variables...
> 
> FPC has this syntax:
> const i: integer = 0;
> But it's so very unlogical to use a "const" as variable. :-(
> (GPC accepts this syntax, but gives a warning)
> 
> Extended Pascal (ISO-10206) declares this syntax:
> var i: integer value 0;
> Much nicer, isn't it?
> 
> That at least looks very similar so I hope, at least that will be
> simpler for you to implement...
> 
> BTW. you might wonder why Extended Pascal uses "value" and not the
> equal-sign. That is because it also defines initialized types:
> type myint = integer value 0;
> so that all variables that use this type are initialized.
> Here a second equal-sign would look strange.
> 
> Or what about String definitions:
> FPC: 
> var s: string[255];
> ISO-10206:
> var s: string(255);  {btw. not limited to 255}
> Would it be so difficult to accept parantheses instead of brackets?
> GPC accepts both.
Try writing a compiler first instead of complaining about FPC's syntax
:)

You are toying with the issue of syntax. There is nothing wrong with
FPC's syntax, it's quite compatible with standard pascal and I disagree
with most of what you say above. FPC to my knowledge was created as an
alternative to Borland Pascal which only supported the 16-bit PC
architecture. We need a pascal compiler to support 32bit.

> FPC has this syntax:
> const i: integer = 0;
> But it's so very unlogical to use a "const" as variable. :-(
> (GPC accepts this syntax, but gives a warning)

What on earth would we want a more typed language ? Pascal is stongly
typed enough as it is, and is quite comfortable to use. People like
myself that have been using pascal for many many years will not be happy
to find that pascal now has a new syntax.

cheers
James

> 
> -- 
> Tschuess
>   Andreas
> ___
> fpc-pascal maillist  -  [EMAIL PROTECTED]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal]Re: CGI (Andreas K. Foerster)

[Luis Del Aguila]

Message: 10
From: "Andreas K. Foerster" <[EMAIL PROTECTED]>
Date: Mon, 27 Jan 2003 21:13:45 +0100
To: [EMAIL PROTECTED]
Subject: Re: [fpc-pascal]CGI
Reply-To: [EMAIL PROTECTED]

On Sun, Jan 26, 2003 at 10:36:00AM -0500, Luis Del Aguila wrote:

> ¿ How to make a CGI program in pascal, that read and send for e-mail the
> Html form content ?

Look at the User's Guide, chapter 11.

There's also an unCGI Unit around.

HTH

--
Tschuess
Andreas

--__--__--
Pero, La guia de usuario, capitulo 11, no explica como escribir un programa
que envie el contenido de un formulario por correo elctrónico.
Alguien puede ayudarme.
Gracias

But, The User's Guide, chapter 11, don´t  to explain how write a program
that send the Form Content for e-mail.

Any body help me.

Thanks






___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Anton Tichawa]

Hello, List!

On Tuesday 28 January 2003 14:06, James Mills wrote:
>
> What on earth would we want a more typed language ? Pascal is stongly
> typed enough as it is, and is quite comfortable to use. People like
> myself that have been using pascal for many many years will not be happy
> to find that pascal now has a new syntax.
>

I aggree. Changes should be done carefully, because there is the risk of 
destroying existing (legacy?) software. What I'm doing is to use pascal 'as 
standard as possible', but to automatically create pascal files in cases 
where the standard requires too much typing.

Anton.


--

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte 
Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

--

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email: [EMAIL PROTECTED]

--
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Marco van de Voort]

> On Mon, Jan 27, 2003 at 10:42:37PM +0100, Marco van de Voort wrote:
> > > Will there also be sopport for conformant Arrays as they are defined 
> > > in standard Pascal (ISO-7185)?
> > 
> > Not that I'm aware of (unless you plan to implement it ? ).
> 
> No, I can't do it.
> 
> The point is just, that I'm still disappointed that FPC isn't
> compatible to any of the official Pascal standards and that it's not
> even trying to become compatible.

True. There is pretty much no point in that, since the Pascal standards are
effectively dead. (Borland 99.9% marketshare) Maybe we would do it if we had
significantly more manpower, but we don't, and there isn't much hope on
improvement.
 
> I'm very much drawn back and forth between FreePascal and GNU Pascal.
> Both have their advantages, but also their disadvantages. FreePascal
> has more commands, but GNU Pascal knows a much more elaborated syntax.

Then I'd advise you to look more into the Delphi modes of FPC.

> FreePascal supports just one dialect,

FPC supports both BP as Delphi syntax.

> GNU Pascal knows different dialects including the standards. 

But it doesn't implement them very well. To avoid this with FPC also, it was
decided to not fragment until the manpower is there.

> FreePascal has lots of systemspecific extentions, but programs written with
> them aren't portable, even not between the different variants of
> FreePascal itself.  GNU Pascal tries to leave systemspecific things away,
> that means that programs are nearly always portable, but also that things
> are missing. 

This is nonsense. Either one uses systemspecific extensions or not. This works
for both FPC and GPC.

> GNU Pascal (the compiler itself) is very portable, while FreePascal is
> mainly targeted to PCs and porting to other platforms seems to take a lot
> of time.

True, that is a fundamental problem. But note that this is also a reason for GPC being
so unpredictable. Again it is FPC's philosophy of doing one thing right, before
moving on.

Luckily, we are slowly moving away from that, and FPC runs decently on m68k already, 
and Sparc
and PPC are in advanced stages of development.

> On the other hand GNU Pascal is hard to install, especially on non-Unix
> systems. 

And more importantly, harder to work on. The overal build process + system + patching 
is 
a lot more complex.

> GNU Pascal is the better Pascal, when you look at the source code
> of your programming,

This is a matter of taste. I don't agree.

> What I really want would be a mixture of both!

Then there is only one option. Work on either of them. Both projects have manpower 
shortage,
the difference is how they handle that.
 
> At the moment I try to use only what both have in common. But
> unfortunately that's not much. I have to avoid commands because of
> GPC and I have to use a simpler syntax because of FPC.

I wouldn't do that anyway. GPC hardly knows any Delphi dialect features, and those are
the strong point of FPC (most of the development in language after 1997 deals with 
Delphi
extensions).
 
> That's why I try to suggest that FPC should become more standard
> compatible, to be able to write more portable code. 

That wouldn't help either, since there is no true standard for the object orientated 
extensions anyway,
only a draft that is interpreted differently by various people/companies.
 
> Okay, I see that it's difficult to implement.
> But what about things that look similar? 
> 
> For example initialized variables...
> 
> FPC has this syntax:
> const i: integer = 0;

And 

var i : integer = 0;

in Delphi mode.

> But it's so very unlogical to use a "const" as variable. :-(
> (GPC accepts this syntax, but gives a warning)

> Extended Pascal (ISO-10206) declares this syntax:
> var i: integer value 0;
> Much nicer, isn't it?

No. Why add a keyword "value" when an "=" is more logical? Bloat!
 
> That at least looks very similar so I hope, at least that will be
> simpler for you to implement...
 
> BTW. you might wonder why Extended Pascal uses "value" and not the
> equal-sign. That is because it also defines initialized types:
> type myint = integer value 0;

Ugly feature. I'm against it. A type doesn't have a value. I don't like
pre-initalisation anyway, don't use it much in any variant.

This kind of baroque syntax is what makes some languages so tiresome.

> Or what about String definitions:
> FPC: 
> var s: string[255];
> ISO-10206:
> var s: string(255);  {btw. not limited to 255}
> Would it be so difficult to accept parantheses instead of brackets?
> GPC accepts both.

Stringtypes (short, long and schemata based) are all fundamentally
different. This is not just syntax, but a lot more.

Delphi's (ansi-) string type doesn't have a size, and is fully automatic.
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Michael Van Canneyt]

On Tue, 28 Jan 2003, Andreas K. Foerster wrote:

> On Mon, Jan 27, 2003 at 10:42:37PM +0100, Marco van de Voort wrote:
>
> > > Will there also be sopport for conformant Arrays as they are defined
> > > in standard Pascal (ISO-7185)?
> >
> > Not that I'm aware of (unless you plan to implement it ? ).
>
> No, I can't do it.
>
> The point is just, that I'm still disappointed that FPC isn't
> compatible to any of the official Pascal standards and that it's not
> even trying to become compatible.

We only aim to be Delphi compatible. It is the de facto pascal standard,
and is a usable implementation of pascal.

Most other standards are academic and not very usable.

>
> I'm very much drawn back and forth between FreePascal and GNU Pascal.
> Both have their advantages, but also their disadvantages. FreePascal
> has more commands, but GNU Pascal knows a much more elaborated syntax.
> FreePascal supports just one dialect, GNU Pascal knows different
> dialects including the standards.

FPC has 4 dialects:
- plain
- TP compatible
- Object pascal
- Objectpascal, delphi compatible.

> FreePascal has lots of systemspecific
> extentions, but programs written with them aren't portable,
> even not between the different variants of FreePascal itself.

A. Which variants of FPC do you mean ?

B. It is in the nature of system specific things that they are not
   portable. Only the RTL and FCL are designed with as much portability as
   possible kept in mind.

All packages are system specific, and are used to make the compiler more
usable on all platforms.

> GNU Pascal tries to leave systemspecific things away, that means that
> programs are nearly always portable, but also that things are missing.

Exactly, thus severely limiting the usability.

> GNU Pascal (the compiler itself) is very portable, while FreePascal is
> mainly targeted to PCs and porting to other platforms seems to take a
> lot of time.

We are working on this, but this is not an easy task.

Do not forget that GPC used GCC as a basis which already existed for
more than 10 years when GPC was initially ported. So any comparison
in this is meaningless. In 10 years we'll look where FPC and GPC are.

> On the other hand GNU Pascal is hard to install,
> especially on non-Unix systems. GNU Pascal is the better Pascal, when
> you look at the source code of your programming, but FreePascal is the
> better compiler, when you look at the binary that comes out...
>
> What I really want would be a mixture of both!
>
> At the moment I try to use only what both have in common. But
> unfortunately that's not much. I have to avoid commands because of
> GPC and I have to use a simpler syntax because of FPC.
>
> That's why I try to suggest that FPC should become more standard
> compatible, to be able to write more portable code.

Portable code has nothing to do with standards.
We try implement the Delphi standard on all supported platforms.

>
> Okay, I see that it's difficult to implement.
> But what about things that look similar?
>
> For example initialized variables...
>
> FPC has this syntax:
> const i: integer = 0;
> But it's so very unlogical to use a "const" as variable. :-(
> (GPC accepts this syntax, but gives a warning)
>
> Extended Pascal (ISO-10206) declares this syntax:
> var i: integer value 0;
> Much nicer, isn't it?

What is so much nicer about this ?? We support the following:

var
  i: integer = 0;

Which is even much nicer.
'Nice' is largely a matter of taste, and hence is no argument.

That it is a standard is another matter.

>
> That at least looks very similar so I hope, at least that will be
> simpler for you to implement...
>
> BTW. you might wonder why Extended Pascal uses "value" and not the
> equal-sign. That is because it also defines initialized types:
> type myint = integer value 0;
> so that all variables that use this type are initialized.
> Here a second equal-sign would look strange.
>
> Or what about String definitions:
> FPC:
> var s: string[255];
> ISO-10206:
> var s: string(255);  {btw. not limited to 255}
> Would it be so difficult to accept parantheses instead of brackets?
> GPC accepts both.

If we decide finally to implement the ISO or ANSI pascal mode, then we
may consider all this, but at this moment it is definitely not a
priority.

FPC is an open source project. Feel free to grab a copy of CVS and
implement it yourself. We'll be happy to include your changes.
But our priorities lie elsewhere...

Michael.

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Aitor Santamaría Merino]

Andreas K. Foerster escribió:


GNU Pascal is the better Pascal, when 
you look at the source code of your programming, but FreePascal is the 
better compiler, when you look at the binary that comes out...

I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas 
GPC is a Pascal->C compiler...
(also explaining why FPC supports less platforms, because the GCC guys 
are doing the job ;-))

Aitor

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Andreas K. Foerster]

On Tue, Jan 28, 2003 at 03:12:11PM +0100, Marco van de Voort wrote:

> True. There is pretty much no point in that, since the Pascal standards are
> effectively dead. (Borland 99.9% marketshare)

Well, well... and who needs HTML standards when anybody uses Microsoft
products anyway...  I hate that argument!!!

> > FreePascal supports just one dialect,
> 
> FPC supports both BP as Delphi syntax.

Okay, then I say "the dialects of just one company".
 
> This is nonsense. Either one uses systemspecific extensions or not. This works
> for both FPC and GPC.

That's not what I said. I said GPC hasn't that much systemspecific
extentions. 
That can be seen as disadvantage or as advantage.

> > What I really want would be a mixture of both!
> 
> Then there is only one option. Work on either of them. Both projects
> have manpower shortage, the difference is how they handle that.

Well, may I port FPC units to GPC?
May I put them to their archive, even if no porting is necessary?
 
> GPC hardly knows any Delphi dialect features, and those are
> the strong point of FPC (most of the development in language after 
> 1997 deals with Delphi extensions).

Well, I never worked with Delphi. So maybe GPC is really better for me.
BTW. the name FreeDelphi would fit better then.

> var i : integer = 0;
> in Delphi mode.

Okay, I've overseen that.

-- 
Tschuess
Andreas
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Andreas K. Foerster]

On Tue, Jan 28, 2003 at 11:06:53PM +1000, James Mills wrote:

> it's quite compatible with standard pascal 

Oh, there is still a lot missing, even from the unextended standard.
For example conformant arrays, internal files, filebuffer variables,
global GOTO's(?)
Procedure variables are implemented, but not in a compatible way.

Okay, that's of course difficult to implement. That's why I only
mentioned differences, which I thought are more easy to implement.

> and I disagree with most of what you say above.

Please be a little more precise.

> FPC to my knowledge was created as an alternative to Borland Pascal

Okay.
As such it's a very good compiler.
But that dosn't mean, that it should keep their limitations.
Borland Pascal also was never fully Pascal compatible. 
I think that's why they changed the name to Delphi.

> People like
> myself that have been using pascal for many many years will not be happy
> to find that pascal now has a new syntax.

Hey, I don't want anything to be dropped, I want it to be extended!

-- 
Tschuess
Andreas
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Graphics woes

[John Coppens]

On Tue, 28 Jan 2003 11:02:43 +0100
Jonas Maebe <[EMAIL PROTECTED]> wrote:

> 
> Given the large amount of question about "can't find -lvga when 
> compiling graph programs under linux" I would say the same about 
> lib(s)vga. I also think SDL would be a better choice (though someone 
> needs to do it of course :/ )
> 
> 
> Jonas
> 

I was gathering courage to take on debugging the actual ggiGraph unit and
try to get it running again. Somehow I believe this makes sense as so much
work is already done.

I'm no expert. Is SDL so much better? I noticed both libs are in active
development. I also notice there is no clear advantage as to which of both
is more 'standard'. I did notice that installing libggi went a lot easier
that SDL (maybe 'cause I don't have accelerated hardware).

John
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Graphics woes

[Jonas Maebe]

On dinsdag, jan 28, 2003, at 17:01 Europe/Brussels, John Coppens wrote:


I was gathering courage to take on debugging the actual ggiGraph unit 
and
try to get it running again. Somehow I believe this makes sense as so 
much
work is already done.

I'm no expert. Is SDL so much better?

It's at least more cross platform, it exists for pretty much every OS 
out there.


Jonas

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Marco van de Voort]

> On Tue, Jan 28, 2003 at 03:12:11PM +0100, Marco van de Voort wrote:
> 
> > True. There is pretty much no point in that, since the Pascal standards are
> > effectively dead. (Borland 99.9% marketshare)
> 
> Well, well... and who needs HTML standards when anybody uses Microsoft
> products anyway...  I hate that argument!!!

HTML is used for interoperation on the web. It affects much more people.
Totally different discussion.

The only reason to adapt the ISO standards is to gain access to ISO sources. Fact is,
there aren't many, so it is no top priority. So while we are not 100% opposed to it, 
it is
not scheduled, not even for the distant future, as long as there is work to do that 
_DOES_
have its merits. (like more processors, better optimizations, IDE's etc)
 
> > > FreePascal supports just one dialect,
> > 
> > FPC supports both BP as Delphi syntax.
> 
> Okay, then I say "the dialects of just one company".

Actually the Object Pascal (Delphi language) was also implemented (though
differently) by Apple.

> > This is nonsense. Either one uses systemspecific extensions or not. This works
> > for both FPC and GPC.
> 
> That's not what I said. I said GPC hasn't that much systemspecific
> extentions. 

It has. They are maybe not in the main distro. E.g. look at the Chief's packages,
and you will find a lot of win32 stuff.

> That can be seen as disadvantage or as advantage.

I fail to see the advantage. It's like saying that having no legs is an
advantage because then they can't be hurt. I prefer walking though.

I've dealt with arguments like this my entire Modula-2 period, which is why
I ultimately abandonned Modula2. The biggest problem, that all available
sourcecode were very simple or theoretic algorithmic problems. No real applications,
toolkits or so.

What good does a "pure" language + libraries do, when you can't work with them?
 
> > > What I really want would be a mixture of both!
> > 
> > Then there is only one option. Work on either of them. Both projects
> > have manpower shortage, the difference is how they handle that.
> 
> Well, may I port FPC units to GPC?
> May I put them to their archive, even if no porting is necessary?

Most of the FPC stuff is GPL or LGPL. If you keep to those very small
conditions, there will be no problem. 
  
> > GPC hardly knows any Delphi dialect features, and those are
> > the strong point of FPC (most of the development in language after 
> > 1997 deals with Delphi extensions).
> 
> Well, I never worked with Delphi. So maybe GPC is really better for me.

Frankly, that would depend on your history. If you have an extensive history
in ANSI pascal, (and more importantly) a large ANSI codebase to work with in
your field (some scientific disciplines have this), GPC may be better.

For new development, I'd use the more modern Delphi dialect (which GPC is
also implementing bit by bit, but only slowly), and the more stable compiler
(which IMHO is FPC)

> BTW. the name FreeDelphi would fit better then.

No. The language is called "Object Pascal", Delphi is much more (RAD etc),
besides we still have fundamental Borland Pascal mode. (or actually two, a
strict one, and one with extensions)
 
Besides that, the term "Delphi" is probably copyrighted.
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Preben Mikael Bohn]

> I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas  GPC
> is a Pascal->C compiler...
> (also explaining why FPC supports less platforms, because the GCC guys  are
> doing the job ;-))

I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use the
GCC-backend to some extend, but this is - as I see it - an advantage compared
to FPC.

Can FPC and GCC object files be linked together?

Best regards Preben

-- 
Don't take life too seriously. You'll never get out of it alive.


___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Marco van de Voort]

[ Charset ISO-8859-1 unsupported, converting... ]
> > I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas  GPC
> > is a Pascal->C compiler...
> > (also explaining why FPC supports less platforms, because the GCC guys  are
> > doing the job ;-))
> 
> I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use the
> GCC-backend to some extend, but this is - as I see it - an advantage compared
> to FPC.

In the simplest way it is (you don't have to program the backend). But life isn't about
theory only regrettably.

The practical problems of being a GCC patch, is that it makes the overall
system more complex. (as can seen by e.g. the complex buildsystem and
instability and slow progress of GPC), and that the maintenance has to
happen in a different language (C) than you are developping for (Pascal),
which limits the amount of possible contributors.
 
> Can FPC and GCC object files be linked together?

Yes, that is not the problem. There is still a problem though, specially on
Unix. FPC can't directly use C headers.
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Aitor Santamaría Merino]

Andreas K. Foerster wrote:


GPC hardly knows any Delphi dialect features, and those are
the strong point of FPC (most of the development in language after 
1997 deals with Delphi extensions).


Well, I never worked with Delphi. So maybe GPC is really better for me.
BTW. the name FreeDelphi would fit better then.


In my understanding, Delphi is the "big box" with the IDE/RAD, toolkits, 
etc, whereas the language itself they use is ObjectPascal, so I don't 
think the name is wrong.  FreeObjectPascal is a bit too much :)
The only possible correspondence would be to call Lazarus FreeDelphi, 
but Delphi is for Windows only (under Linux it is Kylix, and Kylix 2.0 
is now C++ as well), whereas Lazarus is available for more platforms...

Aitor

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC (was:FPC 1.0.6 and open arrays)

[Preben Mikael Bohn]

> Can FPC and GCC object files be linked together?

It seems so... :-)

Best regards Preben

-- 
Don't take life too seriously. You'll never get out of it alive.


___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Andreas K. Foerster]

On Tue, Jan 28, 2003 at 05:41:57PM +0100, Preben Mikael Bohn wrote:

> > I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas  GPC
> > is a Pascal->C compiler...
> > (also explaining why FPC supports less platforms, because the GCC guys  are
> > doing the job ;-))
> 
> I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use the
> GCC-backend to some extend,

That is true.

If you search a Pascal to C converter, have a look at p2c.

But it doesn't have any of the Units - but it supports the Unit
interface.

-- 
Tschuess
Andreas
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal]Destroy Instance

[Luis Del Aguila]

I don't Understand, I compile this code with FPC 1.06 for Windows and the
directive compiler -S2 -Rintel.
is it a bug?.

Thanks


Type
  TClase1 = Class
campo1:string;
  End;
  TClase2 = Class (TClase1)
campo2:string;
  End;

Var b:Tclase2;
Begin
  b:=TClase2.create;
  b.campo1:='hola';
  b.campo2:='hola2';
  Writeln(b.campo2);
  b.destroy; //if destroy the instance .
  Writeln(b.campo2); // Why the instance exist?
  Write('presione enter para terminar');readln
End.


___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Run Time Error codes

[Jonas Maebe]

On zaterdag, jan 25, 2003, at 02:34 Europe/Brussels, Eduardo Morras 
wrote:

Does anyone knows what means the next error codes: 998, 313. 
And where find information about the applications exit code?

Such strange error codes are error codes that come straight from the 
operating system and which are for some reason not properly translated 
by the RTL. If you say which routines cause such errors, we an have a 
look at them.


Jonas

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

RE: [fpc-pascal]Execution speed

[Lee, John]

So now you've had Marco's ideas + my 0.1 euro's worth (there are some
differences in our approaches + some common ideas) re what the problem is &
how you should test what's happening, please let us know what the results of
your experiments are...J 
---
 Now that the list seems to be working again...I'll try posting this again:
> 
> I am wondering why our new PC is not executing our fpc-compiled program
> very much faster than the old one. It was really quite a disappointment:
> 
> Old PC: Laptop, Intel PII, 300 MHz, 64 MB. Execution times: 8:30, 2:30
(min:sec)
> 
> New PC: Desktop, AMD Duron, 1.6 GHz, 128 MB. Execution times: 5:15, 1:15

I'm not the processor-crack of the FPC team, but I'll give it a shot. 
(Jonas and Florian will probably correct/comment on this heavily :-)

I'm afraid you have fell for the MHz'itis, iow that the throughput 
speed of a processor is purely dependant on the speed of the CPU 
(in MHz):

Some important things I noticed immediately from your msg:

- there is still a nearly two fold increase. (less for the first, exactly
twofold for the second)
- you use 4 MB memory, and I assume from the story that is rather 
random access
- The Duron has less cache than an Athlon, and the Duron's is probably about

   the same  magnitude as the P-II
- the 4 MB doesn't fit in the cache -> processor is waiting for memory all
the time.

> The new PC ought to be 5 times faster (1600 MHz / 300 MHz, right? 

Depends on the job. The memory interface is probably only two 
times faster (66 MHz <-> 133 MHz) or so, and the cache (that can 
in some cases "hide" the slower memory), is also hardly larger.

>Of course the speed of the memory is also a factor) but it's not even twice
> as fast.

Which is indeed the reason that it is memory bound. (together with 
the problem being not OS dependant, I assume you tried some *nix)

I went from a K6-2 500 to an Athlon 1666 (XP2000+), which is 
about a fat 3 step, but the compiler compiles itself more than 3 times 
as fast.

> The execution time pairs are determined from three time stamps that
> occur during one run of the program. The sequence is as follows:
> 
> * Stamp 1
> -Initialize (5-10 secs reading/processing from HD)
> -Process 1 (5-9 mins)
> * Stamp 2
> -Process 2 (1-3 mins)
> * Stamp 3

Since the second process scales better, I assume it approaches 
memory in a way that can be better

> Both machines are running Win98 Second Edition (could Windows 98 be
> preventing the faster machine from running at full capacity?

Not for pure calculation I think. Maybe for heavily IO-bound or 
threading programs 98 makes a huge difference, but if there is a 
difference in calculation speed in 98, it won't be more than a few 
percent (and since NT and unix have more to do in the background, 
this could even be positive)

> Or perhaps it's because fpc runs in a DOS window, and the DOS mode is
forcing it to
> run slow?)
> 
> The program is very processor intensive. Only about 4MB of memory space
> is used.

You could try to change the memory usage in a way that 
subsequent memory access will be adjacent in memory, and play 
with alignments.

You could also try to find/borrow a processor with a large cache 
(e.g. a P-III Xeon with 2 MB cache would be ideal, but an Athlon MP 
or even a simple Athlon would be interesting), and do the test on 
such a machine.

> During runtime, we are doing less than 400 kb of read/write combined to
> the HD. We put about 10 lines of text on the DOS screen to show
> progress. So I can't imagine the I/O could be slowing us down.

Not likely no.

> I tried compiling with the two different target platforms, but it didn't
> make a difference. Stackchecking is on, but it was on on both computers.

Did you use the same amounts of optimization? Maybe you 
have -OG3p3r or so in the ppc386.cfg on the P-II (which 
automatically adds the heaviest optimizations), and not on the Duron.

> I also tried a few different bios settings (the computer has ready-made
> bios configurations for "Optimal" and "Best Performance" (?) as well as
> the factory default I started with.) But the compile times were the same
> regardless of the bios settings.

Usually this is a few percent max, not magnitudes.

Action list: (in order that I would do them, from first to last resort)
1 verify that you use the same degree of optimizations. 
2 Try on a machine with more cache.
3 Try to rewrite programs to do more accesses to the same block of 
memory.
___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

This e-mail and any attachment is for authorised use by the intended recipient(s) 
only.  It may contain proprietary material, confidential information and/or be subject 
to legal privilege.  It should not be copied, disclosed to, retained or used by, any 
other party.  If you are not an intended recipient then please promptly delete this 
e-mail and any attachment and all copi

Re: [fpc-pascal]Destroy Instance

[Sebastian Günther]

Luis Del Aguila schrieb:


  b.destroy; //if destroy the instance .
  Writeln(b.campo2); // Why the instance exist?


You have to call b.Free instead of b.Destroy to properly destruct the 
instance.

And don't forget that the destruction will free the memory, but not 
override it with some initialization value; so it is possible that 
b.campo2 will still hold a value.


- Sebastian

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]FPC vs. GPC

[Preben Mikael Bohn]

>> I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use
>> the GCC-backend to some extend,
> That is true.

I thought so. :-)

> If you search a Pascal to C converter, have a look at p2c.

I must admit that I prefer ptoc instead, don't remember the URL, though...

Best regards Preben

-- 
Don't take life too seriously. You'll never get out of it alive.


___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal]Destroy Instance

[Andrew J.Swan [home]]

* Luis Del Aguila [LDA] [Tuesday, January 28, 2003] wrote:
* subject: [fpc-pascal]Destroy Instance
* msgid:00af01c2c6fb$8a85a320$491e30c8@mesajil

LDA> Type
LDA>   TClase1 = Class
LDA> campo1:string;
LDA>   End;
LDA>   TClase2 = Class (TClase1)
LDA> campo2:string;
LDA>   End;

LDA> Var b:Tclase2;
LDA> Begin
LDA>   b:=TClase2.create;
LDA>   b.campo1:='hola';
LDA>   b.campo2:='hola2';
LDA>   Writeln(b.campo2);
LDA>   b.destroy; //if destroy the instance .
   b.Free ;
LDA>   Writeln(b.campo2); // Why the instance exist?
LDA>   Write('presione enter para terminar');readln
LDA> End.

8o)

* Best regards ...
-- 
  `  _ ,  '   :: Linux Registered User [#168882]
 -  (o)o)  -  :: The-Bat! 1.63 Beta/5
-ooO'(_)--Ooo :: Weakened by Windows 98/4.10.  A 
- They might or they might not, You never can tell with bees.  --  [Winnie-the-Pooh]

>00af01c2c6fb$8a85a320$491e30c8@mesajil">mid:00af01c2c6fb$8a85a320$491e30c8@mesajil

___
fpc-pascal maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal