Gpc May 1998

gpc@gnu.de

29 participants
71 discussions

using GNU Pascal
by Clyde Meli 12 May '98

12 May '98

> Subject: GPC -- Compatibility with TP/BP ???? > > Item Type: Note > > ** High Priority ** > Hello, Peter Gerwinski, > Would be great if somebody could tell me where I can find a USABLE > Pascal compiler for Linux. It should be TP/BP compatible as much as > possible. > > > Thanks in advance, > > Rainer Hantsch > > I think GNU PASCAL is very usable. It can be used for sockets programming under solaris for instance (that's what my students use it for). I just wrote a web robot using GNU Pascal. True, I don't do any socket calls to retrieve the html pages, instead I shell to the wget program, and my robot or spider takes care of the higher level information. I am using it for resource discovery of new Maltese web pages. I am using GNU Pascal 2.0 (release version) so I don't have the Copy function for instance. But there is Substr instead. Once I get a newer version of GNU installed I will be able to switch to the Copy function etc. And I hope to submit the socket unit (tested under solaris only) to the GNU developers if they would like to have it for the distribution. Regards, Clyde Meli http://www.cis.um.edu.mt/staff/cmeli -- My home page http://www.maltanetworkresources.com -- Maltese (true) search engine+Directory

1 0

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Frank Heckenbach 11 May '98

11 May '98

Andreas Prucha wrote: > I wrote: > >You asked if there is an description of Delphi/OP. I think there is an > helpfile > >available on www.interprise.com (I'll look if I can find it). > > And here you get it: > > ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Thanks, I've fetched a copy. BTW, does anybody know a utility to convert this .hlp file into something "readable" (i.e. some standard format)? -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Achim Kalwa 11 May '98

11 May '98

Frank Heckenbach wrote: > > Is there a way to get the exception that was caught into a > variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); > Frank, your "fantasy" syntax is right. In Delphi: try { do something that might raise an exception } except on Foo : Exception DO ShowMessage(Foo.Message) end Where "Foo" is an instance of the Exception class. There is no need to declare "Foo" as a variable first. Achim

1 0

Delphi properties (was Reformatted: EFLIB as class library for O
by The African Chief (Dr A Olowofoyeku) 10 May '98

10 May '98

Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote; >Thanks Andreas, Chief and the others for your explanations. >I've copied your message's IDs into the To-Do-List so that I and >others can easily find the messages when it's time to implement >these fatures. >I've got a few little questions left (for now :-): >Concerning properties: I assume you cannot pass property fields as >var parameters, right? Correct. If you try it, you get a "Constant object cannot be passed as var parameter" error message. However, you can pass a property as a value and "Const" parameter. >> try >> // code U try to execute >> except >> On EMyException do xxxx; // Do special exception handling here >>On EAnotherException do xxxx; // What you want else raise; // let > > the standard exception handler do the thing > >end; > >Is there a way to get the exception that was caught into a >variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); I have no idea. I don't use exceptions at all. >> And can for type-conversion easyly >> typecased with PChar: >> >> Procedure MyProc (xxx: PChar); > > > >var mystring: String; > > > >MyProc (PChar(MyString)); > >The most recent GPC versions can do this, but without the explicit >type cast, like "MyProc (MyString);". The explicit type cast gives a >warning, and not the intended result. Should GPC learn such type >casts between values of different string types, too? (Peter?) (Since >it seems to be necessary for Delphi compatibility, I suppose the >answer will be yes.) It will be good if GPC will accept the explicit type cast as well as do the implicit one. But note that this should only be done with long strings (at least, that is what Delphi does). With short strings, people should do their own conversion (I think - is there any reason why this should be supported with short strings other than to make life easier for programmers?). Best regards, The Chief ----------------------- Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v4.25 for Win16 and Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

1 0

Re: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Frank Heckenbach 10 May '98

10 May '98

Thanks Andreas, Chief and the others for your explanations. I've copied your message's IDs into the To-Do-List so that I and others can easily find the messages when it's time to implement these fatures. I've got a few little questions left (for now :-): Concerning properties: I assume you cannot pass property fields as var parameters, right? (Otherwise, this would greatly complicate the var parameter mechanism, even in programs that don't use properties at all.) > try > // code U try to execute > except > On EMyException do xxxx; // Do special exception handling here > On EAnotherException do xxxx; // What you want > else raise; // let the standard exception handler do the thing > end; Is there a way to get the exception that was caught into a variable or so? Something like (fantasy syntax): On Foo : EAnotherException do Something.With (Foo.ErrDevice); > And yes. Delphi's implementation is /great/ even the new referece counted > string types make live much easier. They can save more than > 255, This, of course, is true for GPC's strings, too. :-) > are dynamically allocated and referece-counted. Dynamical strings are not yet implemented, but are planned, anyway, in GPC (though they don't seem to be exactly the same as in Delphi). > And can for type-conversion easyly > typecased with PChar: > > Procedure MyProc (xxx: PChar); > > var mystring: String; > > MyProc (PChar(MyString)); The most recent GPC versions can do this, but without the explicit type cast, like "MyProc (MyString);". The explicit type cast gives a warning, and not the intended result. Should GPC learn such type casts between values of different string types, too? (Peter?) (Since it seems to be necessary for Delphi compatibility, I suppose the answer will be yes.) > - Interfaces (not really necessary but nice) Yes, we planned interfaces, too. (I know them from Java and from the OOE draft, I suppose they're similar in Delphi, are they?) However, the internals turned out to be quite difficult. So if someone knows about the internals of how Delphi handles interfaces, especially how it builds the VMTs of classes that inherit from/implement multiple interfaces, any information is welcome! > You asked if there is an description of Delphi/OP. I think there is an helpfile > available on www.interprise.com (I'll look if I can find it). But I doubt that > it is possible to implement it compatible w/o having a look at Delphi itself. > But I hope that I could explain some basic things. This might be useful for a "clean-room reimplementation"... Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Andreas Prucha [helicon] 09 May '98

09 May '98

Hi, I wrote: >You asked if there is an description of Delphi/OP. I think there is an helpfile >available on www.interprise.com (I'll look if I can find it). And here you get it: ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Andreas

1 0

Re[3]: troubles compiling gpc
by Peter Gerwinski 09 May '98

09 May '98

According to Paul Doerwald: > > I changed char *version_string = "2.8.0", compiled, and everything works > nicely now. [...] :-) > Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/specs > gpc driver version 980420(2.8.0) executing gpc version 2.8.0 > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Di586 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -D__i586__ -Asystem(unix) -Acpu(i386) -Amachine(i386) hello.pas /tmp/cca08525.i > GNU CPP version 980420(2.8.0) (i386 GNU/Linux with ELF) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/i586-pc-linux-gnulibc1/include > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/include > /usr/include > End of search list. > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc1 /tmp/cca08525.i -quiet -dumpbase hello.pas -version -famtmpfile=hello.gpc -o /tmp/cca08525.s > GNU Pascal version 980420(2.8.0) (i586-pc-linux-gnulibc1) compiled by GNU C version 2.8.0. > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: invalid #line > /tmp/cca08525.i:2: warning: missing program header > /tmp/cca08525.i:2: parse error at null character I cannot locate the problem from this. Since you reported that everything works now with the "version_string" change, I suspect that the problem leading to this was fixed somewhere after gpc-980420. Well, we will see after the next alpha release. > What I did was change 5987 to TREE_OPERAND (target), and when bison > complained, I changed it *back* to TREE_OPERAND (target,1), and everything > worked. ?? Now I understand: You had a correct version of `parse.y', but a wrong one of `parse.c'. After your changes, bison updated `parse.c', and everything was fine. :-) > Thank you, though, for helping me get gpc to compile. Now I can actually do > some programming (now that summer is here and school is over, and I have > *time* to program! :-) You lucky one! ;-) If you are ambitious, what about porting CRT to Linux? Many people would appreciate that. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

troubles compiling gpc
by Paul Doerwald 09 May '98

09 May '98

This seems an unlikely problem, but I'm actually confounded by it: I can't compile GPC. I've tried a number of different combinations, and it always fails with an abort, a core dump, and an Error 2 on rts-base.p. If I run the xgpc I have on a hello world program, it fails with a core dump. I'd tell you about what version this happened on, but as ftp logs to agnes.dida... will reveal, I have downloaded and tried countless combinations including: gcc 2.8.1 with gpc 980501 gcc 2.8.0 with gpc 980501 gcc 2.8.0 with gpc 980401, and then diffed with 980405 I also downloaded the binary for 980420, and even that came back with numerous errors on a hello-world compile. I'm running a plain Red Hat Linux 5.0 system (glibc2?) on a 486-DX50. The binary for 980420 came in a package with i586 in it, but I don't imagine that should make any difference... I've followed the instructions in the readme in /gnu-pascal/alpha on agnes, but it constantly fails. Here's the errors for a hello world program using the binary for 980420: pollux:~>gpc hello.pas /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: invalid #line /tmp/cca08381.i:2: warning: missing program header /tmp/cca08381.i:2: parse error at null character The source for the program: program hello; begin writeln ('hello, world!'); end. I don't see a problem... The error I'm getting with 980405 and 2.8.0 is this: make[1]: Entering directory `/usr/src/gcc-2.8.0/p/rts' ../..xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/src/gcc-2.8.0/p/rts/../.. -I/usr/src/gcc-2.8.0/p/rts/../../config rts-base.p make[1]: *** [rts-base.o] Aborted (core dumped) make[1]: leaving directory `/usr/src/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 This happens all the time. Once, the compile failed on parse.y, complaining about too many parameters in a function that ended up not existing on either line pointed to by the compiler, but about 10 lines lower down. I changed it, changed it back, and compiled, and it worked... ??? I have in the past successfully compiled gpc-2.0 on a RedHat Linux 4.1 machine Thanks for your help! At this point, I'd be happy with a working binary for my machine attached to a message (compiling on a 486 is SLOOOOW!) | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | Exodus 15:2b

2 1

Re: [rainer] Re: GPC for LINUX
by FPL 09 May '98

09 May '98

Peter wrote > sqr(BTW), right now I am porting a project of 150000 lines from > BP to GPC - not by just recompiling, but it makes progress as > expected. Gee! What is it about? 150000 pascal source code? Also, the rhide url and the old GPC info moping about the lack of borland pascal likewise IDE make me ask this question: what's better than emacs, using pascal mode, for writting pascal? Don't you think Borland ide is just ugly, unusable, unefficient, vomitting? Never understood why you made such a mess about it. Also, the assign example given by rainer seems not to be the better one. When I started using GPC, it was not provided, but one could find a (working) substitutes given in the info. IMHO, the actual problem of using GPC for a user who is not maintening and trakcing the GPC bugs is that he is so sure all his problem are coming from the compiler and not from himself or his debugger! AFAIK, there is no one bug of mine I haven't made GPC responsible for it. It eventually appears that it is never GPC but either gdb or the user who is wrong, but one can't go through his human nature (my experience learnt me GPC is in fact much more reliable that one could expect from a beta version, so with time the effect is dissipating slowly). F.P.L

2 1

Re: Another more striking example
by Peter Gerwinski 08 May '98

08 May '98

According to FPL: > > I think this program is a better example of what the problem is. > It is not as artificial as the prior one, and can be executed > without gdb so that one can see the problem may lie somewhere else that > in debugging informations. > > program loop2(input, output); > var > i, j : integer; > > begin > j:=0; > repeat > for i:=0 to 10 do > if (i div 2)=0 then > begin > write('*'); > j:=j+1; > end; > writeln; > until j=10; > end. > > Do you agree the output should be a rectangular array of 5 stars by ten, No. For each run of the `repeat' loop, only one star (for i = 0) is printed. Perhaps you mean `if i mod 2 = 0'? > Well, what *I* get when running the output code is ... correct. ;-) > Also, I have (in the other program) some file of text type ever opened, > and I have noticed in applying your advice that GPC complains it cannot > write on the default output device (the screen) because of my opened > file. Just a writeln('*') and *not* a writeln(f, '*') wille make it say > > ?GPC runtime error: File is not open for writing (#9) This sounds strange and *maybe* indicates a bug. How did you open the file? The following should work: Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile ); Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc May 1998