- Gpc - gnu.de

double inclusion of unit DOS with gpc (Mingwin version)
by Jean-Pierre Vial 03 Sep '02

03 Sep '02

When the DOS unit (and strangely only the DOS unit) is used both in a program and an unit used by this program, all the interface is flagged as redefined and compilation fails. This happens only with the Mingwin version, DJGPP and Linux version are OK (but they are older) Here is a test: a programm and a unit Note that the unit DOS is not actually used. ******************************** program testinc; uses dos,unitinut; begin writeln(affichage); end. ********************************** unit unitinut; interface var affichage:string; implementation uses dos; begin affichage:="affiche"; end. *********************************** -- Jean-Pierre Vial

4 3

Packed records
by Waldek Hebisch 29 Aug '02

29 Aug '02

Is there any definitive info how packed types _should_ work in GPC. The following program: Program BitSz; Var R: packed record aa: packed record c: Boolean; end; a: Boolean; b: 1..3; end (* R *); begin writeln ( ' R.aa:', BitSizeOf ( R.aa ), ' R.aa.c:', BitSizeOf ( R.aa.c), ' R.a:', BitSizeOf ( R.a ), ' R.b:', BitSizeOf ( R.b ), ' R:', BitSizeOf ( R )); end. writes: R.aa:8 R.aa.c:1 R.a:1 R.b:2 R:16 which shows that packed records inside packed records currently (with gpc 2.1) take the same space as outside. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 1

Problems compiling GPC on NetBSD/sparc
by Philip Plant 29 Aug '02

29 Aug '02

Hi folks, I've been trying to compile GPC on my NetBSD/sparc 1.5.2 system. Unfortunately it fails with a bunch of 'undefined reference' errors for calls to libc functions. Here are a few snips of the output from make. If anyone could suggest a fix, I'd be very grateful. bash-2.05$ uname -a NetBSD helios 1.5.2 NetBSD 1.5.2 (GENERIC) #0: Wed Aug 22 04:33:09 CST 2001 toor@proxima:/usr/src/sys/arch/sparc/compile/GENERIC sparc bash-2.05$ make make all-recursive Making all in intl Making all in lib Making all in makeinfo gcc -DIN_GCC -DHAIFA -g -O2 -DHAVE_CONFIG_H -o cccp cccp.o cexp.o intl.o prefix.o version.o mbchar.o obstack.o ../libiberty/libiberty.a /usr/lib/crt0.o: In function `___start': /usr/lib/crt0.o(.text+0xf8): undefined reference to `main' cccp.o: In function `safe_read': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x224): undefined reference to `_read' /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x238): undefined reference to `___errno' cccp.o: In function `safe_write': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x280): undefined reference to `_write' /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x294): undefined reference to `___errno' cccp.o: In function `eprint_string': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x2d8): undefined reference to `_(short, (void))' <snip> `___divdi3' /tmp/sky/share/bison.simple(.text+0xafc): undefined reference to `___udivdi3' /tmp/sky/share/bison.simple(.text+0xb70): undefined reference to `___moddi3' /tmp/sky/share/bison.simple(.text+0xb8c): undefined reference to `___umoddi3' <snip> /usr/tmp/gpc-build/gcc/obstack.c(.text+0x510): undefined reference to `_(short, (void))' /usr/tmp/gpc-build/gcc/obstack.c(.text+0x514): undefined reference to `_fputs' collect2: ld returned 1 exit status *** Error code 1 Stop. *** Error code 1 Stop. Regards, Philip.

4 5

GPC 2.1 (GCC 2.95.2) optimization.
by Martin G C Davies 28 Aug '02

28 Aug '02

Hi, What is the status as far as using optimization is concerned? Is it supposed to be usable? If so I have a problem... I'm on a Solaris 2.6 Ultra 1 using GPC 2.1 (based on GCC 2.95.2). Source code showing the problem is below. When I build and run with the commands:- gpc -c opt.pas gpc -c -DMYMODULE opt.pas -o lichkp1.o gpc opt.o lichkp1.o a.out I see "ok" but if I use -O i.e. gpc -c opt.pas gpc -c -DMYMODULE opt.pas -o lichkp1.o -O gpc opt.o lichkp1.o a.out I see "failed". Can anyone help? Cheers, Martin G C Davies. #if defined MYMODULE module opt; #else program opt(output); #endif const lmpages = 24576 ; lcpgsize = 4096 ; lcpgctrl = 28 ; lmalloc = lcpgsize - lcpgctrl - 4 ; type mylupage = record number : packed 0..lmpages ; datadisp : packed 0..lmalloc end ; mylopage = ^mylupage; function lichkp1( mypage : mylopage ) : boolean ; external ; #if defined MYMODULE function lichkp1( mypage : mylopage ) : boolean ; begin if mypage^.number <> 1 then lichkp1 := false else if ( mypage^.datadisp < lcpgctrl ) or ( mypage^.datadisp > ( lmalloc div 8 ) ) then lichkp1 := false else lichkp1 := true ; end ; #else var mypage : mylupage ; begin mypage.number := 1 ; mypage.datadisp := lcpgctrl ; if lichkp1(addr(mypage)) then writeln('ok') else writeln('failed'); #endif end.

2 2

Re: gpc with gcc 3.1.1
by Waldek Hebisch 27 Aug '02

27 Aug '02

strobe anarkhos wrote: >At 9:55 PM +0200 8/26/02, Waldek Hebisch wrote: >>I am trying to make gpc work with gpc 3.1.1. Currently gpc1 > >Good luck. > >Are you targeting 3.1.1 due to Apple using it, or is there another reason? For me it is largely a learning exercise -- how a front end fits into GCC back end. Newer technology is better for that, also 3.x series looks much cleaner then 2.x. On the other hand big plus for GCC is its wide reach -- it supports many architectures and many languages -- and I would like to have that all in a _single_ version. 2.95.3 today is probably best as production compiler, but I think in a few months 3.x will have fewer bugs. 3.1 have support for new architectures: s390, and better HP support. Also Ada is integrated in 3.1, and java in 3.x is much better then in 2.95.3. Finally, C++ in 3.1 is binary incompatible with 2.95.3 -- so currently that stops wide adoption of 3.x, but then the transition will be very fast. In other words: staying with newest 3.x seems only logical choice for Grand Unification. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

gpc statistics
by Prof. A Olowofoyeku (The African Chief) 27 Aug '02

27 Aug '02

Hi folks Since this list has been rather quiet of late, I thought to bore you all with statistics (sorry!) - but the download count of the GPC 2.1 binary release from the official Mingw website just hit 5,000, which to me is good news. Is GPC about to take over the world? Answers on a postcard ... Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

[bat@niipmm.tsu.ru: Questions about GNU Pascal]
by Dieter Schmitz 26 Aug '02

26 Aug '02

----- Forwarded message from "Alexei P. Baturin" <bat(a)niipmm.tsu.ru> ----- From: "Alexei P. Baturin" <bat(a)niipmm.tsu.ru> To: <gpc-owner(a)gnu.de> Subject: Questions about GNU Pascal Date: Thu, 15 Aug 2002 16:49:39 +0700 Good day, Would you like to answer two questions about GNU Pascal (MS DOS with DGJPP) for which I haven't found the answer in documentation? I work in MS-DOS under Windows 98 (processor Pentium II). 1. Is it possible to force the functions sin, cos, exp, ln, **, etc. to calculate a result of type LongReal (10 bytes) with a precision of 19 decimal digits (as in BP or Delphi)? 2. How to use DLL's in GP-programs? I tried to import a function from DLL by usual way (as in Delphi): function esin(x:extended):extended; external 'extenlib.dll' index 1; but the compiler didn't understand this. Can you help me to solve this problem? Best regards, Alexei Baturin (Tomsk, Russia) ----- End forwarded message -----

4 3

New bug in gpc 2.1 ?
by Maurice Lombardi 25 Aug '02

25 Aug '02

Hi all, It seems that a new bug has crept in in recent versions of gpc (I use 2.1 / djgpp). I found it in recompiling a program which worked correctly some times ago. A simple program to display the bug is obtained by splitting the docdemos/operatordemo.pas program into a main and a unit: ----------------------------------------------------------------- program bugoper; uses uoper; var a, b, c: Vector3 = (1, 2, 3); begin c := a + b end. ----------------------------------------------------------------- unit uoper; interface type Vector3 = record x, y, z: Real; end; operator + (u, v: Vector3) w: Vector3; implementation operator + (u, v: Vector3) w: Vector3; begin w.x := u.x + v.x; w.y := u.y + v.y; w.z := u.z + v.z; end; end. ------------------------------------------------------------------- I obtain the following error mesage bugoper.pas: In main program: bugoper.pas:10: invalid operands to binary + bugoper.pas:10: invalid operands to binary + Everything is correct of course with the original program Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Some strange behaviour of GPC
by Nick Ioffe 14 Aug '02

14 Aug '02

Hi! I use packed arrays of booleans and need to look for bit set and clear in them. The arrays are of different sizes, but I cannot use a conformant array. I've written function Find_First_bit_Set (buff_ptr:pointer, bit_size:integer) : integer; and then to pass Addr(bit_array) and BitSizeOf(bit_array). The problem is that for BitSizeOf (packed array of boolean) always returns me 8*SizeOf like in the following case: program tst; var aa : packed array [1..19] of boolean; begin writeln (SizeOf(aa), ' ', BitSizeOf(aa)); end. the output I get is: 4 32. what can be wrong? I use GPC 2.1 compiled on HP-UX B.11.00 Thank you in advance, Nick

3 2

bad configuration with mingwin
by Jean-Pierre Vial 13 Aug '02

13 Aug '02

I just tried, several times, to install gpc under Mingwin. I fail every time in the same way: when I launch gpc, it does not find its own parts. 1) I get a message <<cannot exec /mingw/lib.....>> even though the required exe does exist, precisely where gpc looks for it I have a dirty workaround for this problem: if I do not set GPC_EXEC_PREFIX but put the directory /mingw/lib/gcc-lib/mingw32/2.95.3-6 in the path the executables are found. I then fall on the second problem 2) Units are not found (crt, gpc, etc...) My last attempt was with a fresh Mingwin distribution, specially downloaded form the mingwin site, with just the same version number as the gpc package, so I do not know what to do. There is no problem with the djgpp version (well, almost: the crt unit does not display accented letters !) -- Jean-Pierre Vial

2 1

Build Problems
by Frank D. Engel, Jr. 11 Aug '02

11 Aug '02

I am trying to build GPC under IRIX. I followed the basic set of instructions from the GPC manual, or wherever it was that I found them, with the exception that I am building all of the compilers instead of just GPC (originally I tried using the specified option to only build GPC, then left it off afterward, and the result is the same). GCC Version: 2.95.3 GPC Version: 20020510 IRIX Version: 6.5.15m Using GNU make (called with the command 'gmake' under IRIX). The problem is this: The build gets to a certain point, then gives me an "internal error" in the compiler. I tried placing empty Pascal files in place of some of the originals, but the error simply changes to occur in a different source file (the original files are now restored). The error is as follows: ../.././xgpc -B../.././ -c <...> <home>/gcc-2.95.3/gcc/p/rts/string.pas <home>/gcc-2.95.3/gcc/p/rts/string.pas: In procedure 'Upcasestring': <home><.....>/string.pas: 177: Internal compiler error in 'modified_type_die', at gcc-2.95.3/gcc/dwarf2out.c:6485 Can someone please help me with this? I really want to get this working, but have not been able to get around this bug. If any further info is needed, let me know. Also, I have some experience programming in a variety of languages, etc., so if you need me to make changes/etc. and try things, I am open to suggestions -- I can at least try. I am familiar with C, thouroughly enjoy Pascal, and am somewhat knowledgeable about UNIX (I have worked with Linux, Solaris, IRIX), so I can handle the OS for the most part as well. Thank you for any help you can provide! Also: I did not see another means of bug reporting, if there is one, let me know so that I can resubmit this in the appropriate way. Thank you. ===== ======= Frank D. Engel, Jr. Please note my new address: fde101(a)yahoo.com __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com

2 1

ANN: ZLib Unit
by Eike Lange 08 Aug '02

08 Aug '02

Welcome to the wonderful world of Zlib zlib 1.1.4 is a general purpose data compression library. All the code is thread safe. The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files http://www.ietf.org/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format). These documents are also available in other formats from ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html This unit is based on zlib 1.1.4 Differences to zlib.h: ====================== - No underscores - ZLIB_VERSION is renamed to ZLibVersionConst - function ZlibVersion returns String - function GzEof returns boolean value - GzError returns String - SEEK_SET and SEEK_CUR are introduced in this unit as SeekSet and SeekCur. These consts are needed as the "whence" parameter to GzSeek It would be wonderful, if someone could review this unit. Download from: http://gnu-pascal.de/contrib/eike/ Eike

1 0

Re: Some strange behaviour of GPC
by da Silva, Joe 07 Aug '02

07 Aug '02

Not sure why you are doing things this way, anyhow ... Why not eliminate the non-standard "BitSize" function?, thus : program tst; const BitArraySize = 19; var aa : packed array [1..BitArraySize] of boolean; begin ...... Also, why are you using a pointer to your array, why not simply pass it to your "Find_First_bit_Set" function as a parameter (var parameter, if you wish)? Joe. > -----Original Message----- > From: Nick Ioffe [SMTP:ioffe_nick@mail.ru] > Sent: Tuesday, August 06, 2002 5:49 AM > To: gpc(a)gnu.de > Subject: Some strange behaviour of GPC > > Hi! > > I use packed arrays of booleans and need to look for bit > set and clear in them. > > The arrays are of different sizes, but I cannot use a conformant > array. > > I've written function > Find_First_bit_Set (buff_ptr:pointer, > bit_size:integer) : integer; > > and then to pass Addr(bit_array) and BitSizeOf(bit_array). > > The problem is that for BitSizeOf (packed array of boolean) > always returns me 8*SizeOf like in the following case: > program tst; > var > aa : packed array [1..19] of boolean; > begin > writeln (SizeOf(aa), ' ', BitSizeOf(aa)); > end. > > the output I get is: > 4 32. > > what can be wrong? > > I use GPC 2.1 compiled on HP-UX B.11.00 > > Thank you in advance, > Nick >

1 0

General GNU Pascal questions
by Heine Ferreira 06 Aug '02

06 Aug '02

Hi I am new to GNU Pascal so please forgive my basic questions. Does the compiler under Windows work in a text mode or GUI mode? Can you write GUI programs with this? Does it support ODBC or OLE DB or any particular database? Does the compiler have an IDE? Can it use DLL's or ActiveX controls? I don't understand how to download and install the Windows version. Can you help me please? Must you first install the DOS version? Thank you Heine Ferreira

3 2

sizeof/high/getstringcapacity
by Preben Mikael Bohn 02 Aug '02

02 Aug '02

Hi all. Will sizeof(somestring) always be 9 bytes larger than high(somestring)/getstringcapacity(somestring)? Or is it just in one case I have found this... Best regards Preben ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

3 4

ANN: XLib-Unit
by Eike Lange 29 Jul '02

29 Jul '02

Hi! Welcome to the wonderful world of XLib Unit. This unit interfaces Xlib.h and X.h. Xlib is a very basic library you may need for creating graphical user interfaces (GUI). If you need some documentation about XLib-Programming, please visit the following sites: (I am not responsible for the contents of these sites) * http://www.tronche.com/gui/x/xlib/introduction/ * http://www.rahul.net/kenton/xsites.framed.html It would be wonderful, if someone could review this unit. Download from: http://gnu-pascal.de/contrib/eike/ Eike

1 0

operators
by Kresimir Veselic 25 Jul '02

25 Jul '02

Dear gpc-ers, here is a question by an unskilled programmer: Upon the program program driver0; {$I complexop.p} var a,b,c,d: scomplex; begin a.re := 1; a.im := -0.1; b := a; c := b * b; c := a + c; d := c + b * b; writeln(c.re,' ',c.im); end. the gpc compiler reacts: driver0.p: In main program: driver0.p:10: reference expected, value given However if the incriminated line 10 (d := c + b * b) is commented out the program compiles and executes ok. The include file contains overloaded operations + and * for complex numbers as records. Can you tell what is wrong without looking into the (rather long) include file. Thanks in advance, K. Veselic.

1 0

Problems installing GPC
by Preben Mikael Bohn 24 Jul '02

24 Jul '02

Hi all, I have a problem installing both the gcc and the gpc compiler. I use the following (taken directly from http://www.gnu-pascal.de/gpc_51.html#SEC51 ): tar xzf gpc-20020510.tar.gz tar xzf gcc-core-2.95.2.tar.gz cd gpc-20020510 mv p /export/athen01/prb/programs/gcc-2.95.2/gcc/ cd .. mkdir gpcbuild cd gpcbuild /export/athen01/pmb/gpc/gcc-2.95.2/configure --prefix=/export/athen01/pmb/gpc make make -n install make install At the last step I get the following error: chmod a-x "/export/athen01/pmb/gpc/doc/gpc/BUGS" "/export/athen01/pmb/gpc/doc/gpc/demos"/* if [ "`cd p/docdemos && echo a*`" != "a*" ]; then \ (cd "/export/athen01/pmb/gpc/doc/gpc/docdemos"; for f in *; do rm -f "$f"; done) && \ for f in `cd p/docdemos && echo *`; do \ rm -f "/export/athen01/pmb/gpc/doc/gpc/docdemos/$f"; \ /bin/sh /export/athen01/pmb/gpc/gcc-2.95.2/install-sh -c -m 644 "p/docdemos/$f" "/export/athen01/pmb/gpc/doc/gpc/docdemos/$f" && \ chmod a-x "/export/athen01/pmb/gpc/doc/gpc/docdemos/$f" || exit 1; \ done; \ fi install: p/docdemos//export/athen01/pmb/gpc/gpcbuild/gcc/p/docdemos does not exist make[1]: *** [pascal.real-install-doc] Error 1 make[1]: Leaving directory `/export/athen01/pmb/gpc/gpcbuild/gcc' make: *** [install-gcc] Error 2 And gcc is not build. The strange thing is that it works flawlessly on another RedHat 7.3 system... On the RH7.3 I use gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110). On the "failure"-system I'm using gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) Any ideas what is wrong??? Best regards Preben Bohn ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 3

Latest sources...
by Orlando Llanes 18 Jul '02

18 Jul '02

Where can I find the latest sources? I checked on the web site but was confused and downloaded the wrong thing. Also, does GPC still require Linux in order to be compiled properly? See ya! Orlando

2 1

Re: GPC GMP units
by da Silva, Joe 18 Jul '02

18 Jul '02

Have you tried the "--autobuild" command line option? Joe. > -----Original Message----- > From: Kresimir Veselic [SMTP:Kresimir.Veselic@FernUni-Hagen.de] > Sent: Thursday, July 18, 2002 7:01 PM > To: gpc(a)gnu.de > Subject: GPC GMP units > > Dear GPC-ers, > > my gpc, version 2.1 (20020510), based on gcc-2.95.3 20010315 (release) > does not find the units GPC and GMP, upon compilation of the demo program > fibonacci.pas I get > > fibonacci.pas:31: module/unit interface `Gpc' could not be imported > > The same with GMP. What is wrong? > > Thanks, K. Veselic. >

1 0

Re: range checking in GPC
by da Silva, Joe 18 Jul '02

18 Jul '02

Range checking is not currently implemented in GPC. There has been debate in the past about what priority to give this and just who is willing to do it. However, IMHO, GPC should at least allow the range checking directive to be used, even if it doesn't do anything. I expect this oversight will be addressed in the near future. Joe. > -----Original Message----- > From: Kresimir Veselic [SMTP:Kresimir.Veselic@FernUni-Hagen.de] > Sent: Thursday, July 18, 2002 6:37 PM > To: gpc(a)gnu.de > Subject: range checking in GPC > > Dear GPC-ers, > > Upon including a range checking directive in the program > > program test1; > {$R+} > const nmax = 6; > type nrange = 1..nmax; > var n : nrange; > begin > read(n); writeln(n); > end. > > and compiling with > > gpc --borland-pascal test1.p > > the compiler answers: > > test1.p:2: warning: unknown compiler directive `r+' > > My questions: (i) In the gpc manual on p. I read ... "all of BP > compiler directives are supported by GPC..." > {$R+} is one of them. Why the reaction above? > > (ii) is there any possibility of range checking with GPC? I could not > find the expression "range checking" in the manual text. > > Thanks in advance, K. Veselic. >

1 0

GPC GMP units
by Kresimir Veselic 18 Jul '02

18 Jul '02

Dear GPC-ers, my gpc, version 2.1 (20020510), based on gcc-2.95.3 20010315 (release) does not find the units GPC and GMP, upon compilation of the demo program fibonacci.pas I get fibonacci.pas:31: module/unit interface `Gpc' could not be imported The same with GMP. What is wrong? Thanks, K. Veselic.

1 0

range checking in GPC
by Kresimir Veselic 18 Jul '02

18 Jul '02

Dear GPC-ers, Upon including a range checking directive in the program program test1; {$R+} const nmax = 6; type nrange = 1..nmax; var n : nrange; begin read(n); writeln(n); end. and compiling with gpc --borland-pascal test1.p the compiler answers: test1.p:2: warning: unknown compiler directive `r+' My questions: (i) In the gpc manual on p. I read ... "all of BP compiler directives are supported by GPC..." {$R+} is one of them. Why the reaction above? (ii) is there any possibility of range checking with GPC? I could not find the expression "range checking" in the manual text. Thanks in advance, K. Veselic.

1 0

None
by Kresimir Veselic 18 Jul '02

18 Jul '02

Dear GPC-ers, it seems that the complex arithmetic under GPC is not well implemented: (i) there is only one complex type, the one whose real and imaginary part are double precision reals. For numerical applications complex numbers in single and extended precision are needed as well (in fact, just the availability of these three real precisions is what makes gnu-pascal attractive in this context). (ii) the complex arithmetic of GPC lacks the elementary accuracy; see the following program program complmult; var a : complex; b : double; begin b := 1e+160; a := cmplx(b,0); writeln('abs(b) = ',abs(b)); writeln('abs(a) = ',abs(a)); end. Upon execution the results are abs(b) = 1.000000000000000e+160 abs(a) = Inf which is below even elementary standards. GNU g77 has none of the mentioned shortcomings, cannot one repair this? Sincerely, K. Veselic.

2 2

Translation of gpc documentation to spanish
by Francisco Javier Fernandez 16 Jul '02

16 Jul '02

Hello everybody! I announce you that we at Core Dumped in the Escuela Universitaria de Informatica, in Madrid (Spain) are interesting about translating all gpc documentation to Spanish. The project we have involved still needs to determine some details, but I'm sure that after summer holidays all will be arranged to start. Yours Javier Fernández

2 1

Where can I find information about exit-values below 300?
by michael paap 11 Jul '02

11 Jul '02

Hello, can anyone tell me, where I can find out the meaning of exit values of a program compiled with GPC? I know this sourcefile, where the values from 300 to 925 are listed. But what about the others? I did find out, that 8 means a division with zero, 11 occurs, when i tty to dereference nil, and 15 is returned, if i kill the process from outside. Is there a list of those values somewhere? Greetings, Michael

2 1

Re: RTL does not build
by Daniel Rudy 27 Jun '02

27 Jun '02

Frank Heckenbach wrote: > > > Frank Heckenbach wrote: > > > > > > Daniel Rudy wrote: > > > > > > > I am having problems getting GPC 2.1 20020510 to install correctly. It > > > > compiles with no errors, but when I try to compile a program with it, I > > > > get numerous unresolved references when I try to use one of the builtin > > > > units. In this example, the unit is CRT. It seems that every routine > > > > that I use in CRT generates an unresolved reference. > > > > > > Use `--automake' on the GPC command line. > > > > > > If that doesn't help, please post exact error messages. > > > > > > Frank > > > > > > -- > > > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > > > GPC To-Do list, latest features, fixed bugs: > > > http://www.gnu-pascal.de/todo.html > > > > strata:/usr/local/lib/gcc-lib/i386-unknown-freebsdelf/2.95.3/units 1028 > > ->gpc --automake -DNOX11R6 crt.pas > > When compiling a unit only, use `-c'. This will inhibit linking (as > a unit alone cannot become an executable) and cause no linking > errors. However, you normally don't habe to compile units yourself > at all, since when you compile a program (with `--automake'), all > units used will be compiled as well. > > To compile a program that uses CRT, `gpc --automake myprog.pas' > should work. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de > http://fjf.gnu.de/ > GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) Interesting. Though wouldn't it be good programming practice to individually and periodicly build peices of your code to make sure that your syntax and spelling is correct? I realize that this falls under different programming philosiphies, but coming from a BP 7.0 environment, it was extreamly easy to do to just check things out to make sure that everything was ok.

2 1

RTL does not build
by Daniel Rudy 26 Jun '02

26 Jun '02

Hello, I am having problems getting GPC 2.1 20020510 to install correctly. It compiles with no errors, but when I try to compile a program with it, I get numerous unresolved references when I try to use one of the builtin units. In this example, the unit is CRT. It seems that every routine that I use in CRT generates an unresolved reference. strata:/root 1025 ### ->gcc -v Using builtin specs. gcc version 2.95.3 20010315 (release) [FreeBSD] strata:/root 1026 ### ->gmake --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-portbld-freebsd4.5 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to <bug-make(a)gnu.org>. strata:/root 1027 ### ->

2 1

gpc 2.1 on DJGPP
by CBFalconer 25 Jun '02

25 Jun '02

Just got around to trying this out, and immediate problem: (pasted as quote to avoid line wraps) > [1] c:\p\src\junk>gpc --verbose records.p > Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs > gpc version 2.1 (20020510), based on 2.95.3 20010315/djgpp (release) > c:/djgpp/lib/gcc-lib/djgpp/2.953/gpcpp.exe -lang-pascal -v -famtmpfile=c:/djgpp > /tmp\ccaaaaaa -fstandard-pascal -D__STANDARD_PASCAL__ -fmixed-comments -undef -D > __GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2 > .1 -D__GPC_RELEASE__=20020510 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN > __=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO32 > -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 > -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asy > stem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i38 > 6) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros djgpp.ver -remap recor > ds.p c:/djgpp/tmp\ccn6vpV1.i > GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.3 200 > 10315/djgpp (release) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > c:/djgpp/i586-pc-msdosdjgpp/include > c:/djgpp/lib/gcc-lib/djgpp/2.953/include > c:/djgpp/include > End of search list. > gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) > > [1] c:\p\src\junk>locate c:gpcpp.exe > > C:\DJGPP\LIB\GCC-LIB\DJGPP\2.953\ > gpcpp.exe Fri May 10 2002 12:43:36p A.... 248,476 242.65 K > > 1 item found: 1 file, 0 directories. > Total of file sizes: 248,476 bytes 242.65 K > > [1] c:\p\src\junk>locate c:djgpp.ver > > C:\DJGPP\LIB\GCC-LIB\DJGPP\3.1\ > djgpp.ver Wed May 15 2002 11:07:18a A.... 26 0.02 K > > 1 item found: 1 file, 0 directories. > Total of file sizes: 26 bytes 0.02 K > > [1] c:\djgpp\lib\gcc-lib\djgpp>sd 2.953 > +-----------------------------------------------------------------------------+ > Â¦include <Dir> 17-May-02 01:31:32Â¦cc1 .exe 1856k 29-Mar-01 07:39:42Â¦ > Â¦specs 1770 29-Mar-01 07:39:42Â¦cc1plus .exe 2336k 29-Mar-01 07:39:42Â¦ > Â¦units <Dir> 17-May-02 01:31:32Â¦collect2.exe 226851 29-Mar-01 07:37:20Â¦ > Â¦libgcc .a 314490 29-Mar-01 07:37:24Â¦cpp0 .exe 243514 29-Mar-01 07:37:22Â¦ > Â¦libgpc .a 307342 10-May-02 12:43:36Â¦gpc1 .exe 2208k 10-May-02 12:45:32Â¦ > Â¦syscalls.cx 88205 29-Mar-01 07:37:20Â¦gpcpp .exe 248476 10-May-02 12:43:36Â¦ > +-----------------------------------------------------------------------------+ > Path: C:\DJGPP\LIB\GCC-LIB\DJGPP\2.953 > Dirs: 2 Files: 10 Size: 7,940,888 Clust: 247 Used: 98% > Used: 1,255,407,616 58% Free: 891,748,352 Total: 2,147,155,968 24-Jun-02 22:0 > > [1] c:\djgpp\lib\gcc-lib\djgpp>sd 3.1 > +-----------------------------------------------------------------------------+ > Â¦include <Dir> 23-May-02 21:56:58Â¦cc1 .exe 1024k 15-May-02 11:18:26Â¦ > Â¦specs 6032 15-May-02 11:07:18Â¦cc1plus .exe 1216k 15-May-02 11:18:26Â¦ > Â¦libgcc .a 90916 15-May-02 11:18:28Â¦collect2.exe 84352 15-May-02 11:07:18Â¦ > Â¦libstd~1.a 2080k 15-May-02 11:18:30Â¦cpp0 .exe 80912 15-May-02 11:07:20Â¦ > Â¦libsup~1.a 238670 15-May-02 11:18:32Â¦tradcpp0.exe 60824 15-May-02 11:07:20Â¦ > Â¦syscalls.cx 89492 15-May-02 11:18:48Â¦djgpp .ver 26 15-May-02 11:07:18Â¦ > Â¦djgpp-x .djl 1410 15-May-02 11:07:18Â¦......................................Â¦ > +-----------------------------------------------------------------------------+ > Path: C:\DJGPP\LIB\GCC-LIB\DJGPP\3.1 > Dirs: 1 Files: 12 Size: 5,057,764 Clust: 160 Used: 96% > Used: 1,255,407,616 58% Free: 891,748,352 Total: 2,147,155,968 24-Jun-02 22:0 > [1] c:\djgpp\zipsused>de g*.zip > > Volume in drive C is WD30-PRI41 Serial number is 3CE4:239B > Directory of C:\djgpp\zipsused\g*.zip > > gcc31b.zip 2527540 5-15-02 11:18 GCC v 3.1 for DJGPP > gdb511b.zip 1450671 2-24-02 21:52 GDB 5.11 for DJGPP > gmp401b.zip 576045 2-03-02 0:04 GNU Big Numbers 4.01 for DJGPP > gpc2953b.zip 2092209 5-10-02 14:11 GNU Pascal 2.1 20020510-gcc-2953 DJGPP > gpp31b.zip 2719237 5-15-02 11:18 G++ v 3.1 for DJGPP > gwk306b.zip 539175 1-10-02 9:37 GAWK 3.06 for DJGPP > 9,904,877 bytes in 6 files and 0 dirs 9,916,416 bytes allocated > 891,768,832 bytes free > Obviously something is misconfigured, but what, where, and where do I get it? The above is what is left of the gcc2.953 installation. -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

4 4

GPC for Mingw and Cygwin: announcements
by Prof. A Olowofoyeku (The African Chief) 25 Jun '02

25 Jun '02

Hi all This announcement might be of interest to the Windows users. 1. I have just released v1.0 of my Delphi-compatible Win32 API import units (Messages and Windows). Get them here: http://www.gnu-pascal.de/contrib/chief/winapi/ 2. I have extended the excellent GPLed DevPascal IDE to support GPC. It was written originally for Freepascal, and it now supports GPC on Windows platforms. Get the binaries here: http://www.gnu-pascal.de/contrib/chief/win32/devpas_gpc_191.zip The original (Freepascal only) sources can be obtained here: http://www.bloodshed.net/devpascal.html If you want the updated sources (with GPC support), let me know, and I can make them available. However, I have submitted them to the DevPascal people for them to merge with the official release, so it might be better to wait until this is done. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

Re: list trouble solved
by Toby Ewing 24 Jun '02

24 Jun '02

Finally got it. In the end the problem wasn't in the list work at all. Way earlier in the program, I'd allocated memory for an array [1..x], then accessed it as [0..x]. On freeing the memory, I guess something funny was set up in the memory manager that came back to bite me way later. So... is there a compiler option I could have set that would have told me about this illegal memory access? well, now perhaps I can sleep. Toby

4 8

Installing GPC on HP-UX 11.0
by Nick Ioffe 24 Jun '02

24 Jun '02

Hi! I'm trying to install GPC on HP-UX 11.00 machine I've got GPC and gcc-core.2.95.x sources from the archive site and tried to build it. After several failures I've tried to build GCC only and then failed again. Then I've checked the GCC site at gcc.gnu.org and that is what it says: http://gcc.gnu.org/install/specific.html#hppa*-hp-hpux11 GCC 3.0 and up support HP-UX 11. You must use GNU binutils 2.11 or above on this platform. Thread support is not currently implemented for this platform, so --enable-threads does not work. See http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html and http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html. GCC 2.95.x is not supported under HP-UX 11 and cannot be used to compile GCC 3.0 and up. Refer to binaries for information about obtaining precompiled GCC binaries for HP-UX. I wonder whether I can build the GPC in such a case??? Also what if I'll download gcc-core.3.x instead of gcc-core.2.95.x? Will I be able to build GPC in such a case??? Sincerely, Nick

1 0

Re: list trouble solved
by da Silva, Joe 24 Jun '02

24 Jun '02

To quote Frank on 2002/04/09 : The memory leak is not in the unit, but in GPC itself. It's a known problem with some string operations (especially concatenation) in a loop. (If you can read /proc/n/maps, you'll see that it's the stack, not the heap that grows.) Moving the thing out of the loop (syntactically, e.g. in a subroutine) is a work-around. Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Monday, June 24, 2002 12:45 PM > To: gpc(a)gnu.de > Subject: Re: list trouble solved > > "da Silva, Joe" wrote: > > > > I don't want to enter a debate over this, since clearly not everyone has > > the same concerns/priorities. However, I regard string handling memory > > leakage to be more serious than lack of range checking - but that's just > > my opinion, FWIW. (Which is not to say that range checking isn't also > > important, of course.) > > Are there such leaks, and how do they get triggered (if you know). > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! > >

1 0

Re: list trouble solved
by da Silva, Joe 24 Jun '02

24 Jun '02

I don't want to enter a debate over this, since clearly not everyone has the same concerns/priorities. However, I regard string handling memory leakage to be more serious than lack of range checking - but that's just my opinion, FWIW. (Which is not to say that range checking isn't also important, of course.) Joe. > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Saturday, June 22, 2002 6:48 PM > To: gpc(a)gnu.de > Subject: Re: list trouble solved > > Toby Ewing wrote: > > > Finally got it. > > > > In the end the problem wasn't in the list work at all. Way earlier in > the > > program, I'd allocated memory for an array [1..x], then accessed it as > [0..x]. > > On freeing the memory, I guess something funny was set up in the memory > > > manager that came back to bite me way later. > > > > So... is there a compiler option I could have set that would have told > me about > > this illegal memory access? > > > > _No array index checking_ in gpc up to now unfortunately > > > Franck, > > You have said some time ago that check of array addresses was not so > important ... > > You said also in an other mail that you were not fond of numeric analysis > ... > > The two are closely related because this kind of lost of days of time is > by > far the most important for anybody who does numeric analysis programs... > > Correcting this is in my opinion the most urgent thing to do after the 2.1 > release. > > > Maurice > > -- > Maurice Lombardi > Laboratoire de Spectrometrie Physique, > Universite Joseph Fourier de Grenoble, BP87 > 38402 Saint Martin d'Heres Cedex FRANCE > Tel: 33 (0)4 76 51 47 51 > Fax: 33 (0)4 76 63 54 95 > mailto:Maurice.Lombardi@ujf-grenoble.fr >

3 2

GPC libraries
by Kasper Souren 23 Jun '02

23 Jun '02

Hi, I'm working on a library for GPC, and I want to make it available to the public. But I don't know in which way. At the moment the library contains some wrappers to other libraries (libao, libsndfile, libggi and libfreetype) and some other functionality (loading/saving .ppm files (graphics)). The largest part of the wrappers is done in C, and then there is some Pascal to wrap that. If you want to take a look at the stuff, you can download http://industree.org/libguakagpc/download/PASCAL-0.20020619.tar.bz2 I don't know what would be a good place to put the files. And maybe I need to work with units, but I'm not a very experienced Pascal programmer, so I don't have experience with units. (I started doing Pascal just for this project actually.) What happens if you do a "uses GPC" or "uses GMP"? Are the files supposed to go into a directory like /usr/lib/gcc-lib/i386-linux/2.95.4/units/? Could this stuff also be incorporated into the GPC distribution? Just like GMP? One 'problem' might be that I don't provide all the functionality of the libraries in the wrappers. I'm writing it for someone who will never use all the available functionality, so right now that's a good idea. If it will become available to more people, it might be a good idea to make stuff more general. greetz, Kasper

2 2

Data structure like file system
by Preben Mikael Bohn 22 Jun '02

22 Jun '02

Hi all, this is not a GPC-specific question, but here it goes anyway... :-) I need a data structure or object in Pascal that basically can hold a file-system. Only difference between this and an ordinary filesystem is that permissions, timetags, etc, are not needed, "only" the directories and filenames as well as ~10-20 bytes storage for each file. Any idea how this could be accomplished, or pointers to already existing source? Best regards Preben Bohn ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

3 3

FSF directory
by Maurice Lombardi 22 Jun '02

22 Jun '02

Hi all While browsing informations on the Free software directory I have found the page http://www.gnu.org/directory/Software_development/Compilers/freePascal.html where there is complete confusion between FPC and GPC. One should ask to have two different pages for the two compilers. But who is entitled to ask for rectification and where to do that ? Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: list trouble
by Toby Ewing 22 Jun '02

22 Jun '02

Hi, again CBFalconer wrote: > Simplify your basic list handling and publish the whole thing. It > is highly suspect, because you are in the habit of making copies > of pointers in a rather undisciplined manner. You are not working > with the lists you think you are. I have to admit that everything I (formally) learned about programming I learned in Fortran on punch cards. But I didn't think my pointer work was all that bad! Below is the program, stripped of everything but the list handling. Now it works perfectly, of course. But perhaps the error is still lurking? I'd appreciate any suggestions. I'm flummoxed. The basic idea is that I start with a list with a bunch of entries. I pass through the list, using information in it to generate a new list. Each record I examine, I dispose. I then pass the new list to the old one (pointer), and repeat. Eventually, there are no more entries, and the program moves on to the next realization (main loop). I thought perhaps there was a systematic memory leak, so I have two simple detection schemes. One is that I print out the starting address of the list for each realization (no trend, just random drift). The other is that each pass through the first list should generate the same number of records that is deleted on the next pass (this is the countIn, countOut, prevIn stuff - it also checks out). regards, Toby ------------------------ Program Snowbird; Const Realize = 20; initial = 6500; Type PRec = ^Rec; Rec = record rx, ry, rz : shortCard; check : PtrCard; next : PRec; end; var r : shortCard; PrevIn : medCard; {________________________________________________ } Procedure NumLatt(var PrevIn : medCard); var Root : PRec; countIn : medCard; i : shortCard; {-----------------------} Procedure LInsert(var Root : PRec; x, y, z : shortCard); var temp : PRec; begin New(temp); with temp^ do begin rx := x; ry := y; rz := z; check := PtrCard(temp); next := Root; end; Root := temp; end; {LInsert} {-----------------------} Procedure Advance(var Root : PRec; var countIn, PrevIn : medCard); var LNext, PSelf : PRec; i, countOut : medCard; begin LNext := Nil; countOut := 0; while (Root <> Nil) do begin {walk through Root list} for i := 1 to trunc(2.98*random) do begin {build LNext list} inc(countIn); LInsert(LNext, i, 2*i, 3*i); end; PSelf := Root; {destroy Root in passing} Root := Root^.next; inc(countOut); Dispose(PSelf); PSelf := Nil; end; Root := LNext; {give LNext to Root} LNext := Nil; if (countOut <> PrevIn) then begin {do numbers balance?} writeln('error: countOut = ', countOut:1, ', PrevIn = ', PrevIn:1); readln; end; PrevIn := countIn; end; {Advance} {-----------------------} begin {NumLatt} Root := Nil; LInsert(Root, 1, 2, 3); writeln('Root starts at ', Root^.check:1); for i := 2 to Initial do LInsert(Root, i, 2*i, 3*i); repeat countIn := 0; Advance(Root, countIn, PrevIn); until (countIn = 0); end; {________________________________________________ } begin {Main Program} writeln; writeln('List checking'); writeln; Randomize; for r := 1 to Realize do begin write('Realization ', r:2, ': '); PrevIn := Initial; NumLatt(PrevIn); end; end.

1 0

Re: list trouble
by da Silva, Joe 21 Jun '02

21 Jun '02

Speaking of optimization, are you using any "heavy" optimization settings that may be giving side-effects? Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Friday, June 21, 2002 5:59 AM > To: gpc(a)gnu.de > Subject: Re: list trouble > > Toby Ewing wrote: > > CBFalconer wrote: > > > Toby Ewing wrote: > > > > > > > > I'm having trouble with list management again. > > ... snip ... > > > > It's probably an obvious problem, and I'm hoping fresh eyes can see > it. > > > > > > All I have done below is reformat, so I could follow it, and > > > separate out the mundane operations into a local procedure, so > > > that the actual list manipulation stands alone, and also because I > > > have no idea what that piece of code is doing. Many variables > > > should be moved into the local, and the item to manipulate should > > > be passed into it, but that is another matter. > > > > It's a trade-off between clarity and speed. The loop will execute > > several billions of times, and the run time is several days. I try not > > to call functions or procedures from inner loops. But as you say, > > that's a whole other discussion. > > You are doing enough in that routine that there should be no > perceptible difference in speed. The first rule of optimization > is don't. The second is profile first. > > > > > >Now go to the end > > > > > > > Procedure Advance(VAR Root : PRec; {rx, ry, rz: medcard; next: > PRec} > > > > VAR Latt : PPLary; (3D lattice in schema format} > > > > VAR here, > > > > count : medCard); > > > > {Local to NumLatt. > > > > 1. Identify adjacent, accessible sites. > > > > 2. if sites are unoccupied, insert them into LNext. > > > > 3. Delete Self from Root. > > > > 4. Set Root = Lnext.} > > > > > > > > VAR > > > > LNext, > > > > PSelf : PRec; > > > > lx, ly, lz, {neighboring locations} > > > > dir : medCard; {directions} > > > > Conduct : boolean; {=accessible site} > > > > > > > > (* 2--------------------2 *) > > > > > > > > PROCEDURE operate; > > > > > > > > BEGIN (* operate *) > ... snip ... > > > > END; (* operate *) > > > > > > > > (* 2--------------------2 *) > > > > > > > > BEGIN (* advance *) > > > > LNext := Nil; > > > > WHILE (Root <> Nil) DO BEGIN > > > > PSelf := Root; > > > > operate; > > > > Root := Root^.next; {advance through > list} > > > > write('a'); > > > > dispose(PSelf); { <<=== program crashes here } > > > > write('b. '); > > > > END; (* while *) > > > > Root := LNext; > > > > END; {Advance} > > > > > > The above makes it pretty obvious that the problem is NOT in the > > > operate action, but in the list itself. The fact that dispose > > > crashes shows that PSelf is not a valid pointer to a record, which > > > includes *the fact that the record was created with new* > > > > I agree that the problem is that PSelf is apparently not a valid > > pointer. I don't understand what you're saying about New. Is New not > > stable or trustworthy? > > Perfectly stable and trustworthy. > > > > > > I think you should look into the areas where the list is created. > > > You may have a global instance of an element, for example, that > > > you are incorporating into the list somehow. > > > > The list is created by > > 1) declaring the variable Root : PRec (outside procedure Advance), and > > 2) using the procedure LInsert to add elements to the list. > > LInsert is: > > > > Procedure LInsert(var Root : PRec; > > var x, y, z : medCard); > > var temp : PRec; > > begin > > new(temp); > > with temp^ do begin > > rx := x; > > ry := y; > > rz := z; > > next := Root; > > end; > > Root := temp; > > end; > > > > The only list manipulation is the LInsert procedure, and the dispose > > line that sometimes crashes the program. All records in the list come > > from LInsert. What I find disturbing is that this is a very simple > > piece of list work. The program sometimes runs through over 2,000,000 > > records without crashing - and sometimes crashes after about 100 > > records. Frustrating. > > > > CBFalconer continues: > > > GPC new/dispose is dependant on the C malloc, I believe. If you > > > are using DJGPP you can probably use my nmalloc, available on my > > > site, which provides some hooks for examining the allocation > > > chains and also detects most illegal frees. If it is linked ahead > > > of the runtime library it will replace the library malloc stuff. > > > But that should be only a last resort. > > > > Yes, I'm using DJGPP and will check out your nmalloc. I'm also > > installing GPC on a Linux box so I can try te program there. Because > > this is memory weirdness, I'm wondering if at heart it's a windows > > problem. > > I assume you have a declaration somewhere like: > > TYPE > prec = ^rec; > rec = RECORD > ... > next : prec; > END; > > and I was envisioning you had done something like declare > > VAR > root : rec; > ... > > but you say not. Have you ever initialized root to be NIL? > > VAR > root : prec; > > .... > root := NIL; (* <---- absolutely crucial *) > WHILE whatever DO linsert(root, ...); > .... > > If you don't have ECC memory it is conceivable you have hardware > problems. Another possibility is some bad indexing fouling the > chains (gpc doesn't have range checking :-[) where the nmalloc > stuff might come in handy. > > You could build a list validator, which only walks the list from > root to final NIL. To use it add a field set to a constant value, > and the validator checks that value is there for each entry. > Should be quite fast, and you can then call it here and there in > the program. This would give an early indication of fouled > storage. > > CONST > VALIDMARK = 1234; > > TYPE > rec = RECORD > validation : integer; > .... > END; > > PROCEDURE linsert(....) > .... > new(temp); > temp.validation := VALIDMARK; > ... > > PROCEDURE listvalidate(calledfrom : integer); > > LABEL 10; > > VAR temp : prec; > > BEGIN (* listvalidate *) > temp := root; > WHILE temp <> NIL DO > IF temp.validation <> VALIDMARK THEN BEGIN > takesomeaction(calledfrom); > goto 10; END; > 10: END; (* listvalidate *) > > (you may notice I don't believe in using things outside of ISO7185 > without very good reasons, none of which I see here <g>) > > If all else fails see line 2 of the sig. > > -- > Chuck F (cbfalconer@yahX-Mozilla-Status: 0009rldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address!

3 2

Re: list trouble
by Toby Ewing 20 Jun '02

20 Jun '02

Hi again CBFalconer sent me a list validating procedure, which I stuck into the program. I actually made two versions, one to check the immediate record, and one to check the entire list. I ran it in many ways, but the results are always the same. The checker says everything is fine, and then the program still crashes as before. Checking the record pointed at by PSelf, immediately before disposing it, finds nothing. I modified the checker procedure so it would write a new value (0) to the validation mark, then write the validmark again. Same result. Now here's the twister. I tried running the program on a linux machine - same code, same version of gpc. It crashed in a different place, but also on a dispose statement. In that case, it was disposing a schema (array). Any suggestions? I'm starting to get worried that this code will never work! regards, Toby

1 0

list trouble
by Toby Ewing 20 Jun '02

20 Jun '02

Hi, all I'm having trouble with list management again. The code snipper below is part of a much longer program. It crashes apparently at random, sometimes after looping several thousand times. A simplified version ran "forever", so I know the basic strategy is fine. The crash occurs upon "dispose"ing a record in list Root, and gives sometimes a Page Fault, sometimes a General Protection Fault. Examining the record being disposed shows no pattern, such as being at the end of the list, near the edge of the lattice, etc. The object of the procedure is to define pathways through the 3-D maze defined in array Latt. Latt codes for connections in the positive and negative x, y, and z directions, and whether a given point has been tested yet (via Occ). In each pass through the list Root, the record location is examined for connected neighbors. The record is then disposed, and connected neighbors are inserted into the list "LNext". Then LNext is given to Root for the next pass. All insertions and deletions are therefore at the first position in a list. It's probably an obvious problem, and I'm hoping fresh eyes can see it. thanks, Toby --------------------------------- Procedure Advance(var Root : PRec; {rx, ry, rz: medcard; next: PRec} var Latt : PPLary; (3D lattice in schema format} var here, count : medCard); {Local to NumLatt. 1. Identify adjacent, accessible sites. 2. if sites are unoccupied, insert them into LNext. 3. Delete Self from Root. 4. Set Root = Lnext.} var LNext, PSelf : PRec; lx, ly, lz, {neighboring locations} dir : medCard; {directions} Conduct : boolean; {=accessible site} begin LNext := Nil; while (Root <> Nil) do begin PSelf := Root; with PSelf^ do for dir := 1 to 6 do begin {check all 6 directions} lX := rX; lY := rY; lZ := rZ; case dir of 1 : if (rX > 1) then begin {-X direction} lX := rX-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Xn) = Xn); end else Conduct := False; 2 : begin {-Y direction} if (rY = 1) then lY := ny else lY := rY-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Yn) = Yn); end; 3 : begin {-Z direction} if (rZ = 1) then lZ := nz else lZ := rZ-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Zn) = Zn); end; 4 : begin {+Z direction} if (rZ = nz) then lZ := 1 else lZ := rZ+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Zp) = Zp); end; 5 : begin {+Y direction} if (rY = ny) then lY := 1 else lY := rY+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Yp) = Yp); end; 6 : if (rX >= nx) then Conduct := False else begin{+X direction} lX := rX+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Xp) = Xp); end; end; {case} if (Conduct and (Latt^[lX]^[lY,lZ] < Occ)) then begin {unoccupied site} inc(count); {count newly accessible} LInsert(LNext, lX, lY, lZ); {insert into LNext} Latt^[lX]^[lY,lZ] := Latt^[lX]^[lY,lZ] OR Occ;{mark as occupied} if ((not Infinite) and (lX = nx) {check for breakthrough} and ((Latt^[lX]^[lY,lZ] AND Xp) = Xp)) then begin Infinite := True; MinPath := here; end; end; {if Conduct} end; {for dir} Root := Root^.next; {advance through list} write('a'); dispose(PSelf); { <<=== program crashes here } write('b. '); end; Root := LNext; end; {Advance}

2 3

Problems compiler regexdemo
by Preben Mikael Bohn 20 Jun '02

20 Jun '02

Hi all, I'm having trouble compiling regexdemo.pas, I get a $ gpc --automake --executable-file-name regexdemo.pas regexdemo.pas:31: virtual memory exhausted Line 31 is "uses regex;" My version of GPC is GNU Pascal version 20020402, based on gcc-2.95.2 19991024 (release). Any ideas? Best regards Preben Bohn ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 2

Re: new user questions
by da Silva, Joe 18 Jun '02

18 Jun '02

Try the "--autobuild" option, ie. "gpc --autobuild payroll.pas". If that doesn't work, you might not have installed correctly, particularly depending on the use or non-use of "long file names". For more information, I suggest you might read : http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt Joe. > -----Original Message----- > From: leegold [SMTP:leegold@fastmail.fm] > Sent: Tuesday, June 18, 2002 2:23 PM > To: gpc(a)gnu.de > Subject: new user questions > > please email me, I am not list member yet. > Trying to get install correct and gnu pascal working. > > ques: I got the following error message: > > A:\Turbo>gpc payroll.pas > gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) > > what should I check or try to fix? > > THANK YOU > > -- > http://fastmail.fm/ - A fast, anti-spam email service.

1 0

new user questions
by leegold 18 Jun '02

18 Jun '02

please email me, I am not list member yet. Trying to get install correct and gnu pascal working. ques: I got the following error message: A:\Turbo>gpc payroll.pas gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) what should I check or try to fix? THANK YOU -- http://fastmail.fm/ - A fast, anti-spam email service.

1 0

Syntax problem
by Cserzo Miklos 15 Jun '02

15 Jun '02

Hi Folks, the 2.1 release under SuSE 8.0 misbehaving slightly. If there is a syntax error in the code like: .... if pass[i] in 'A'..'Z' then ... instead of the correct version: .... if pass[i] in ['A'..'Z'] then ... The compilation terminates with a fatal error instead of halt and correct syntax error message. Regards, miklos ======================================================================= Miklos Cserzo E-mail: cserzo(a)abc.hu Bioinformatics Group Agricultural Biotechnology Center Phone: +36-28-430-600 ext. 112 Godollo, Szent-Gyorgyi A. ut 4. Fax: +36-28-420-096 H-2100 Hungary =======================================================================

2 1

Re: Pascal-Standard Question
by da Silva, Joe 07 Jun '02

07 Jun '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, June 06, 2002 12:29 PM > To: gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > da Silva, Joe wrote: > > > I've been following this debate and wondering just what the ISO > standards > > define. As you know, it's not easy reading through the standards and > > finding obscure little details such as this. <g> > > > > However, I think section 6.13 of ISO-10206 indicates that a program can > > indeed consist of multiple modules and can include one main program, > > each of which is terminated by a "full stop" (aka. "period"). > > Yes, even in any order. This is rather difficult to handle, if a > program precedes a required module. A way to do it is to split the > source file and pass each part separately to the compiler. This > could be done transparently by a preprocessor, and serve as a (more > general) replacement for the current feature ... > [Joe da Silva] Yes, odd isn't it? Well, IMHO, if it's too difficult to handle sections (ie. program-components) in any order, it should be an acceptable implementation restriction to require that the main program is the last section (in the usual "define it before you use it" manner). > > Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When > > eoln(f) is activated, it shall be an error if ... eof(f) is true". > > This means, in my words, that it's a runtime error to test EOLn when > the file is already at EOF. However, 6.4.3.6 says: > > : The structure of the type denoted by text shall define an additional > : sequencetype whose values shall be designated lines. A line shall be a > : sequence cs~S(endofline), where cs is a sequence of components > possessing > : the chartype, and endofline shall represent a special componentvalue. > : > : [...] > : > : Every value t of the type denoted by text shall satisfy the following > two > : rules: > : > : a) If t.M = Inspection, then t.L~t.R shall be a linesequence. > : > : b) If t.M = Generation, then t.L~t.R shall be ls~cs, where ls is a > : linesequence and cs is a sequence of components possessing the > : chartype. > : > : NOTE --- 5 In rule b), cs may be considered, especially if it is > nonempty, > : to be a partial line that is being generated. Such a partial line cannot > : occur during inspection of a file. Also, cs does not correspond to t.R, > : since t.R is the empty sequence if t.M = Generation. > > This indicates that it doesn't support partial lines at the end of > the file except during writing -- whether or not that's a good idea > is certainly arguable (I don't really think so) ... > [Joe da Silva] Yes, the standards seem to consider that a text file must consist of lines and that therefore such a file is invalid (as a text file) if there isn't an EOLN before EOF. Of course, such a file can still be a "file of char", but this means the text file features of read() and write() are lost. IMHO, the ability of a compiler to handle invalid situations in a more "user friendly" manner, does not truly detract from it's standards compliance, provided this does not affect how it handles valid situations, of course. I consider it a form of "error recovery". Therefore, I see nothing really wrong with a compiler simply returning TRUE for eoln() when eof() is TRUE. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

1 0

Re: Crash & various misc problems
by Waldek Hebisch 06 Jun '02

06 Jun '02

Frank's patches fixed crash and --nested-comments works. Thanks -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Re: Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Pierre Muller pointed out that, in my post of July 2 on this topic, I forgot to indicate that the file to patch is `gdb/dbxread.c' under the source tree. Sorry. > Did you test it by using insight in non windowed mode (with --nw option), then you get the normal text mode version of gdb. In my original post I wrote: > insight running in non-graphical mode (with the --nowin flag ) does > not exhibit this problem. One difference, I think, between the two modes is that, in the graphical mode, the entire symbol table is read at the time the binary file is opened, whereas it is apparently NOT read, at least not by the same routine, in the text mode. *** A few more details: If you use gdb on itself, as I did, and you break at line 2768 of dbxread.c, within fcn. process_one_symbol (which is the first line of my patch), you'll see that the context of the call is below `gdb_load_disassembly'. Apparently this fcn. is not called, or not in the same way, in the text mode. (Alternatively, in the unpatched source, line 2755 is the pop_context macro invocation where the problem occurs, and provides a suitable breakpoint for analysis. After fewer than 10 breaks, if memory serves, you arrive at one where context_stack_depth is already 0 - which is the problem situation. It's only easier to see this in the patched version because the variable is right in front of you. BTW, my procedure is to give `gdb gdb', set args to "" and run, and when the `debuggee' appears, to command it to open `smalltest' or some other program built with gpc 2.1.) ***** With regard to my post of July 3, "GPC2.1: all types "void" under gdb", please note that this problem can be easily observed in the text mode by using the "print" commmand. Finally, as a user, I'd like to thank the developers collectively for an impressive and useful product. Bob Scher

1 0

Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Hello. Hopefully this will be of interest to some of you - if not, my apologies if I am off-topic. I found that when trying to use the "insight gdb" visual debugger on a binary made using (my locally built) GPC 2.1, the debugger crashes while performing an initial read of the "stabs" info in the binary. But it doesn't crash on binaries made from the (Redhat distributed binary) gpc-19990118. I'm not 100% sure that this is an insight gdb problem - it might take a stabs expert to decide whether insight's logic is correct here or whether there's anything invalid about the stabs sequence emitted by gpc. In any case, below is a simple patch of insight to work around the problem. It works for a couple of multi-module gpc programs that I've tried it with. BTW, the debugger source is ftp://sources.redhat.com/pub/gdb/releases/insight-5.2.tar.bz2 I just submitted a problem report to the insight developers - we'll see what they say. Here's the patch: 1,12d0 < /* modified 5/31/02 Robert Scher. Changes flagged with "RBS". < Works around a problem encountered when reading executables produced < by gpc (Gnu Pascal) version 2.1. Without this change - or hopefully < a more proper correction that attacks the problem head-on, < the "insight" (graphical) variant of gdb crashes at the point where it < reads the stabs section associated with the file error.pas in the < gpc 2.1 support files set. This is a problem peculiar to the graphical < mode (and has been seen on several versions of "insight"). < insight running in non-graphical mode (with the --nowin flag ) does < not exhibit this problem. < */ < 1613c1601 < { --- > { 1641d1628 < 1652a1640 > 2767,2771c2755 < // start RBS patch: check to prevent popping garbage when depth is already 0 < if (!context_stack_depth) < break; // ignore it! < // end RBS patch < new = pop_context (); --- > new = pop_context (); Bob Scher

2 1

Re: Pascal-Standard Question
by da Silva, Joe 06 Jun '02

06 Jun '02

I've been following this debate and wondering just what the ISO standards define. As you know, it's not easy reading through the standards and finding obscure little details such as this. <g> However, I think section 6.13 of ISO-10206 indicates that a program can indeed consist of multiple modules and can include one main program, each of which is terminated by a "full stop" (aka. "period"). Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When eoln(f) is activated, it shall be an error if ... eof(f) is true". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, June 05, 2002 8:00 PM > To: cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > CBFalconer wrote: > > > Frank Heckenbach wrote: > > > Eike Lange wrote: > > > > On Tue, Jun 04, 2002 at 10:16:21AM -0400, CBFalconer wrote: > > > > > Put in those terms, he is absolutely right IMO. Anything that > > > > > follows the "end ." should be ignored, in fact not even read. The > > > > > period should be parsed and cause compilation to stop. I think > > > > > the syntax is something like: > > > > > > > > > > program ::= 'program' progparms ';' declarations block '.' > > > > > > > > Yes, but there might be a statement like this (not exactly BNF :-) > > > > part ::= program or unit > > > > file ::= part until EOF > > > > > > Yes, I'd also think so. Normally, a grammar doesn't imply that > > > anything may follow the program. > > > > > > However, BP behaves like this, and GPC does so with > > > `--borland-pascal' (but I don't think we should make this the > > > default). > > > > Who are you agreeing with? I hope it is me :-) > > No, Eike who I quoted directly. > > > I actually had to go to some trouble to get this to work correctly > > in PascalP, because I allowed EOF to appear immediately after the > > '.', with no eoln. At the same time I wanted to collect source > > lines for a listing. > > Why don't you just read it as a text file (provided PascalP was > written in Pascal)? According to the standard, a text file in Pascal > consists of lines, so there is always an EOLn before EOF (whether or > not the external file contains a newline at the end). > > Obviously, GPC (written in C) doesn't do this, either. It just > processes the input character-wise and counts the newlines (for > messages) and outputs it character-wise (with `--debug-source'). > > > This characteristic is convenient for appending rambling notes > > after the final "end." without worrying about forming proper > > comments. > > The question is not whether it's convenient, but whether it's > allowed by the standards. Do you have any reference where they allow > it? > > > BTW I just ran across a fascinating essay at: > > > > <http://www.epemag.com/zuse/forword.htm> > > > > which might especially interest you. > > Gives me a 404. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

Pascal-Standard Question
by Eike Lange 05 Jun '02

05 Jun '02

Hi folks! In our department, we have a little conversion about Pascal-Standards: Is the following allowed and should the program be compiled if the unit and the program share the same file? It seems, that GPC does and TurboPascal (tm) does not AFAIK. 8<---------------- unit foo; interface ... implementation ... end. program bar; uses foo; begin ... end. ------------->8 Eike

5 12

GPC2.1: types "void" under gdb?
by Robert B. Scher 04 Jun '02

04 Jun '02

Hi everyone. My recenty build of GPC 2.1 from source produces programs that don't permit pascal variables to be examined within gdb! Since this is such an egregious problem I assume that it's peculiar to my build, but could someone please tell me? For example: {************************************} program smalltest; var n: integer; begin n := 3; while n > 0 do begin writeln( 'hello'); n := n - 1; end; end. {************************************} I have tried compiling this with either the -g and -gstabs flag. (With --ggdb, my gpc 2.1 crashes). -g or -gstabs both produce runnable but non-identical binaries. However, in either case, if I give `print n' within gdb, the response is `$1 = void'. I've tried this on larger programs as well, and variables of various types exhibit the same. And I get the same behavior whether using an old "stock binary" version of gdb or the newer "insight variant" version 5.2. On the other hand, when I compile using gpc-19990118, the variables CAN be examined using both versions of gdb. (BTW, I need to move to gpc 2.1 in order to get "crt" unit functionality, which AFAICS was not available under the redhat-distributed gpc-19990118.) With the command `objdump --stabs smalltest' I'm able to see that the type definitions produced by gpc 2.1 are quite different in form from those produced by gpc-19990118. (The order in which the C and Pascal type stabs occur is different, but I suspect that's unimportant.) For "integer", here's the comparison: Integer:t(0,1)=r(0,1); -2147483648; 2147483647 from gpc-19990118 and Integer:t(0,65)=(0,65) from my gpc 2.1 The previous type def. is of "range" type, and defines the integer range of the type. I suspect that the completely uninformative type def's. produced by my gpc 2.1 - and all of them are like the "integer" definition shown" - is the reason that gdb can't display values. Only other thing I could say is that I built gpc from gcc-core-2.95.2 and gpc-2.1 from http://www.gnu-pascal.de/current/. I ran configure using arguments `--enable-languages=pascal --prefix=/usr/gcc2.95.2' I did NOT use a separate build directory, but ran configure from the directory where I had unpacked it, /usr/src/gcc-2.95.2. Thanks for any suggestions or comments. Bob Scher

1 0

Crash & various misc problems (resent)
by Waldek Hebisch 04 Jun '02

04 Jun '02

Hi I just intalled gpc 2.1 on top of gcc 2.95.3 (all on slightly updated RedHat 7.0). When I type: gpc --interface-only tp.pp I get gpc: Internal compiler error: program gpc1 got fatal signal 11 The content of tp.pp is: program tp; begin end. It looks that compiler crashes when there is no interface in the file (I found it on much bigger files, and with lot of other options). The problem also appears in older version of gpc on another machine. The manual says that gpc 2.1 accepts nested comments but when I try gpc --nested-comments nn.pas with nn.pas beeing program nn; (* Can NOT compile with --nested-comments *) begin (* (* *) *) end. the compiler complains about '*' The following ugly syntax (taken from FPC sources :) is not accepted even in Borland Pascal mode (supposedly BP compiles the code): unit ttt; interface function foo(const s : string) : integer; implementation function foo(const s : string) : integer; var i,j:integer; begin for i:=1to 5 do j:=j+1; foo := j; end; end. The compiler complines about 'nondigits in number whose radix <= 10' in the line containing 'for' and then cannot find 'to' or 'downto'. Finally, the manual claims that all one-letter switches in BP are supported, but (again in FPC source) R switch (range check) is not recognized and compilation is aborted on {$ifopt R+} -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

3 4

GPC install script
by Ernst-Ludwig Bohnen 03 Jun '02

03 Jun '02

Hi all! A new version of the GPC install script (install.gpc) is available from URL: http://gnu-pascal.de/contrib/ernst/tools/install.gnu Installations of gpc-2.1 (and older) have been made successfully on: SunOS 5.7 as user under AFS Linux, SuSe 7.3 as local user, as root, and as user under AFS Users working under AFS und varying CPU architectures need to care about storing architecture dependent *.gpi, *.o files in different directories. This problem can't be solved by the installer. Feedback welcome. Ernst-Ludwig

1 0

StringUtils, FileUtils
by Frank Heckenbach 31 May '02

31 May '02

Hi, in the current GPC version, I've included a StringUtils unit for general string handling routines (on a higher level than the built-in and RTS routines). Up to now, it only contains routines for a string hash table, but I'm planning to add some more routines. Perhaps some of you also have some routines to contribute (or features to request). Conditions for inclusion into this unit should be, IMHO: - Generally useful (not meant specifically for a certain program or something), - self-contained (not relying on an external library etc.), - new functionality compared to the existing routines (whereas the same or similar functionality under a different interface for compatibility purposes should go into other units, like GPCUtil for compatibility to `Turbo Power' units), - and, of course, compilable with the current GPC version, portable, bug-free, etc. ;-) The same goes for the FileUtils unit which has been there for some months already. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 10

Speed Issue
by Silvio a Beccara 31 May '02

31 May '02

Hi everybody, anyone knows how the speed of a program making intensive use of floating point operations compares between a GPC and GCC executable? Thanks, regards Silvio a Beccara

1 0

Re: GPC for DOS instructions
by da Silva, Joe 30 May '02

30 May '02

Thanks for that tip Maurice. I'll may wait a few days to see if any other changes are required, then I'll update the document accordingly. Joe. > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.LOMBARDI@ujf-grenoble.fr] > Sent: Wednesday, May 29, 2002 11:25 PM > To: gpc(a)gnu.de > Subject: Re: GPC for DOS instructions > > "da Silva, Joe" <Joe.daSilva(a)emailmetering.com> a dit : > > > For anyone interested, I have written instructions for obtaining and > > installing GPC for DOS, based on DJGPP. This brings together > > information from various sources, and from my own findings. The > > information is concise but does not assume previous experience > > with DJGPP. You can obtain this document via the following URL : > > http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt > > (Feedback welcome) > > Seems OK > Only the following is no more necessary > > --------------------------------------------------------------------- > > - In the 'lib' subdirectory, check for a file called 'libcurso.a'. > If it does not exist, create it by copying the 'libpdcurses.a' > file (or, if not using long file names, 'LIBPDCUR.A'). > Eg. : CD lib > COPY libpdcurses.a libcurso.a > > --------------------------------------------------------------------- > > Frank changed recently the {$L } instruction in crt.pas for the official > new > name libpdcurses.a: official since pdcurses 2.4 release, which is the one > present now both on the gpc/djgpp download areas and on djgpp repositories > on > simtelnet and mirrors. > > Maurice > > -- > Maurice Lombardi > Laboratoire de Spectrometrie Physique, > Universite Joseph Fourier de Grenoble, BP87 > 38402 Saint Martin d'Heres Cedex FRANCE > Tel: 33 (0)4 76 51 47 51 > Fax: 33 (0)4 76 63 54 95 > mailto:Maurice.Lombardi@ujf-grenoble.fr > > >

1 0

Re: GPC for DOS instructions
by Maurice Lombardi 29 May '02

29 May '02

"da Silva, Joe" <Joe.daSilva(a)emailmetering.com> a dit : > For anyone interested, I have written instructions for obtaining and > installing GPC for DOS, based on DJGPP. This brings together > information from various sources, and from my own findings. The > information is concise but does not assume previous experience > with DJGPP. You can obtain this document via the following URL : > http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt > (Feedback welcome) Seems OK Only the following is no more necessary --------------------------------------------------------------------- - In the 'lib' subdirectory, check for a file called 'libcurso.a'. If it does not exist, create it by copying the 'libpdcurses.a' file (or, if not using long file names, 'LIBPDCUR.A'). Eg. : CD lib COPY libpdcurses.a libcurso.a --------------------------------------------------------------------- Frank changed recently the {$L } instruction in crt.pas for the official new name libpdcurses.a: official since pdcurses 2.4 release, which is the one present now both on the gpc/djgpp download areas and on djgpp repositories on simtelnet and mirrors. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

GPC for DOS instructions
by da Silva, Joe 29 May '02

29 May '02

For anyone interested, I have written instructions for obtaining and installing GPC for DOS, based on DJGPP. This brings together information from various sources, and from my own findings. The information is concise but does not assume previous experience with DJGPP. You can obtain this document via the following URL : http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt (Feedback welcome) Joe.

1 0

GPC EMX build
by Mike 24 May '02

24 May '02

Hello! Could you provide also EMX binaries of GPC ? Thank you!

3 2

gpcbuild on solaris 8
by Tom Schneider 24 May '02

24 May '02

Frank: > > (It gives lots of errors on the c compile on solaris ... > > don't these scripts detect their environment?) > > What scripts, what errors? Your statement is rather vague ... Here is a precise record for solaris: http://www.lecb.ncifcrf.gov/~toms/gpc/ I ran the gpcbuild script and captured the result with script. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Question on NEW(Ptr : Pointer_to_variant_Record; Tag)
by Jing Gloria 23 May '02

23 May '02

I have searched the mailing list archive and have not found the information that I needed. I hope somebody here can provide the answers or point me to where I can find them. I am porting existing code from a RISC/SunOS system to an Intel(PC)/Solaris7 system. I am using gpc version 20010623, based on gcc-2.95.2 19991024 (release). In the program below, GPC and the RISC/SunOS compiler do not produce the same results in the NEW call: New(point3, No). GPC will allocate the total size (168 bytes) of the record (ItemData) and will initialize the field 'tag' to 1 (which is NO in the enumeration type Answer). In the SunOS compiler, this same statement will allocate memory (92 bytes) to accomodate the following fields for ItemData: number, tag, A_string, False_entries) and will NOT initialize the tag field. How do I get GPC to compile the NEW call in the same way as the SunOS Pascal compiler? BTW, the Dispose call in SunOS Pascal passes both pointer and size (based on the second parameter to the dispose call) to the Dispose routine. program AlignOfDemo; Type Item_ptr = ^ItemData; Answer = (Yes, No, DontKnow, whatever); ItemData = Record number : Integer; Case tag : Answer of Yes : (RealData : Array [1..10] of Real; Num_entries : Integer); No : (A_String : Array [1..80] of char; False_entries : Integer); Whatever, DontKnow: (DontCare : Array [1..40] of Integer); End; var a: Integer; b: array [1 .. 8] of Char; c: Integer (12); d: packed record x: Integer (12); y: 0 .. 3; z: Integer end; point1, point2, point3 : Item_ptr; begin New(point1); New(point2, Whatever); (* Make sure to use same tag as in dispose *) New(Point3, No); (* Make sure to use same tag as in dispose *) Dispose (point1); Dispose(point2, Whatever); (* Make sure to use same tag as in NEW *) Dispose(Point3, No); (* Make sure to use same tag as in NEW *) WriteLn (AlignOf (a)); { Alignment of `Integer'; usually 4 bytes. } WriteLn (AlignOf (Integer)); { The same. } WriteLn (AlignOf (b)); { Alignment of `Char'; usually 1 byte. } Writeln (AlignOf (c)); Writeln ('AlingOf d is ', AlignOf (d)); { Alignment of 1 if packed record; 4 if record} { The following 3 statements cannot be compiled by AlignOf (cannot handle bit fields) if used with PACKED RECORD. Writeln ('d.x: Integer (12) is ', AlignOf (d.x)); (*Alginment of 2*) Writeln ('d.y: 1 ..3 is ', AlignOf (d.y)); (*Alginment of 4*) Writeln ('d.z: Integer is ', AlignOf (d.z)); (*alignment of 4*) {} Writeln('that''s all folks!!!') end. Here is the GPC compiled code for New(point3,NO) 108 0040 83C4F4 addl $-12,%esp 109 0043 68A80000 pushl $168 <<<<<<size to be allocated...... 109 00 110 0048 E8FCFFFF call _p_new 110 FF 111 004d 83C410 addl $16,%esp 112 0050 89C0 movl %eax,%eax 113 0052 A31C0000 movl %eax,Point3 113 00 114 0057 A11C0000 movl Point3,%eax 114 00 115 005c C7400401 movl $1,4(%eax) <<<initializes tag field.... 115 000000 34:align_demo.p **** New(Point3, No); (* Make sure to use same tag as in dispose *) and the correspoding SunOS Pascal translation: ! New(Point3, No); (* Make sure to use same tag as in dispose *) set _point3,%o0 mov 0x5c,%o1 <<<<<size to be allocated.......... call _NEW,2 nop The SunOS dispose call is translated as: ! Dispose(Point3, No); (* Make sure to use same tag as in NEW *) set _point3,%o0 mov 0x5c,%o1 call _DISPOSE,2 nop Thanks in advance for any inputs and suggestions. Regards, Jing Gloria Texas Instruments Sherman, Tx __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

4 3

$define - problems
by Eike Lange 22 May '02

22 May '02

Hi Folks! SetDate (from unit DOS) is a procedure, which is only available, if "__BP_UNPORTABLE_ROUTINES__" is defined. The following program does not work: 8<------------------- program foo; {$define __BP_UNPORTABLE_ROUTINES__} uses DOS; begin SetDate (2000, 3, 3) end. ------------------->8 Defining __BP_UNPORTABLE_ROUTINES__ on the command line (-D or --define) works well. What do I wrong? I'm using 2.1 (20020510), based on gcc-2.95.2 19991024 (release) Eike

2 1

gpcbuild - still failing
by toms＠ncifcrf.gov 17 May '02

17 May '02

Joe: > Well, perhaps there was a problem because you elected to use > a different directory to the default (ie. /usr/local)? OTOH, I would > expect that one of the steps should have stopped with an error > message, if there was a problem? Thanks. No errors to indicate that. OTOH there is so much stuff going by on the screen - how is one to know if a warning is a problem? I get ../../gcc-2.95.2/gcc/toplev.c:1178: warning: initialization from incompatible po is that a problem? > I was able to compile without problems by following the instructions > verbatim (except that I chose "/temp/build" rather than "/home/fred" > as the working directory and GCC 2.95.3 instead of 2.95.1). So, it > does work and the instructions are correct. I have Mandrake 8.0 > and build GPC based on the SuSE GCC source code (I was logged > as "root", so I didn't need to worry about write privileges). > > BTW, shouldn't "gpc-20020410" be "gpc-20020510", instead? I wish. I modified the code of gpcbuild so it would not make a mistake like that again. The problem was that, unfortunately, the directory inside package.tar.gz is NOT 'package'; that was a pain until I realized I could use tar tzf to get the current name. (The intent of gpcbuild is that it can just figure out all the names by itself. If there is an upgrade, I'll just run it again and get a complete build next time with one command. Only ... it doesn't work yet! :-) So it now seems to run just fine, doing all the steps. There is a cryptic statement at http://www.gnu-pascal.de/gpc_51.html#SEC51 to 'Make sure that GNU make is installed.' A clue as to how to check that would be useful!!! Please add something there in the manual, thanks. To be safe I switched to gmake but it made no difference. Does my script work on other systems? (It gives lots of errors on the c compile on solaris ... don't these scripts detect their environment?) Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Can't compile GPC for FreeBSD 4
by Michael Kochiashvili 16 May '02

16 May '02

Hello, trying compile GPC for FreeBsd... Have download packages from your page gpc-2.1.tar.gz gcc-core-2.95.2.tar.gz Have perform steps 2,3 (Unpacking the source, Configuring and building GCC) as described at http://www.gnu-pascal.de/gpc_51.html#SEC51 When make step 5 Compiling GPC I get this error =================================================================== ... src=`cd /usr/local/mine_sources/gcc-2.95.2/gcc && pwd` && cd /usr/local/mine_sources/gcc-2.95.2/gcc/p/rts && make -f Makefile.in srcdir=. SCRIPTDIR="$src/p/script" SHELL="/bin/sh" CFLAGS="-g -O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i386-unknown-freebsdelf" = "i386-unknown-freebsdelf" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." generated-files src=`cd /usr/local/mine_sources/gcc-2.95.2/gcc && pwd` && cd /usr/local/mine_sources/gcc-2.95.2/gcc/p/rts && make -f Makefile.in srcdir=. SCRIPTDIR="$src/p/script" SHELL="/bin/sh" CFLAGS="-g -O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i386-unknown-freebsdelf" = "i386-unknown-freebsdelf" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." generated-files /usr/local/mine_sources/gcc-2.95.2/gcc/p/script/mkdir-p p/rts src=`cd /usr/local/mine_sources/gcc-2.95.2/gcc && pwd` && cd p/rts && CC="`echo /usr/local/mine_sources/gpc-build/gcc/xgcc -B/usr/local/mine_sources/gpc-build/gcc/ -B/usr/local/i386-unknown-freebsdelf/bin/ -I/usr/local/i386-unknown-freebsdelf/include' ' | sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,'`" CONFIG_SITE=nonexisting-file $src/p/rts/configure --silent > /dev/null --srcdir=$src/p/rts `if [ x@with_shared@ = xyes ]; then echo '--with-shared'; fi` src=`cd /usr/local/mine_sources/gcc-2.95.2/gcc && pwd` && cd p/rts && make CC="`echo /usr/local/mine_sources/gpc-build/gcc/xgcc -B/usr/local/mine_sources/gpc-build/gcc/ -B/usr/local/i386-unknown-freebsdelf/bin/ -I/usr/local/i386-unknown-freebsdelf/include' ' | sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,'`" SCRIPTDIR="$src/p/script" SHELL="/bin/sh" CFLAGS="-g -O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i386-unknown-freebsdelf" = "i386-unknown-freebsdelf" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all ../.././xgpc -B../.././ -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /usr/local/mine_sources/gcc-2.95.2/gcc/p/rts/rts-version`'" --unit-path=/usr/local/mine_sources/gcc-2.95.2/gcc/p/rts --automake --print-needed-options "" 2> "needed-options" || true if grep -v '^--' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`"; rm -f "needed-options"; false; else true; fi needed-options: xgpc: : No such file or directory xgpc: No input files *** Error code 1 Stop in /usr/local/mine_sources/gpc-build/gcc/p/rts. *** Error code 1 Stop in /usr/local/mine_sources/gpc-build/gcc. *** Error code 1 Stop in /usr/local/mine_sources/gpc-build. =================================================================== Can you help me with any suggestion? Thank you -- Michael Kochiashvili http://www.iberiapac.ge/~kochini/

2 1

Re: almost there?
by da Silva, Joe 16 May '02

16 May '02

Well, perhaps there was a problem because you elected to use a different directory to the default (ie. /usr/local)? OTOH, I would expect that one of the steps should have stopped with an error message, if there was a problem? I was able to compile without problems by following the instructions verbatim (except that I chose "/temp/build" rather than "/home/fred" as the working directory and GCC 2.95.3 instead of 2.95.1). So, it does work and the instructions are correct. I have Mandrake 8.0 and build GPC based on the SuSE GCC source code (I was logged as "root", so I didn't need to worry about write privileges). BTW, shouldn't "gpc-20020410" be "gpc-20020510", instead? Joe. > -----Original Message----- > From: toms(a)ncifcrf.gov [SMTP:toms@ncifcrf.gov] > Sent: Thursday, May 16, 2002 3:57 PM > To: gpc(a)gnu.de; tds(a)fred.net > Subject: almost there? > > Folks: > > I seem to have done most everything to compile, but > > have nothing in my bin directory: > > /users/tds/now/gpc/current>ls > bin/ info/ > i386-unknown-freebsdelf/ lib/ > include/ man/ > /users/tds/now/gpc/current>ls bin > cpp* i386-unknown-freebsdelf-gcc* > gcc* protoize* > gcov* unprotoize* > > Any clues about where the binary went?? > > I didn't find this process simple at all. I'm building a script to do the > entire job automatically, because this process is pretty complicated to > repeat by hand each time: > > http://www.fred.net/tds/gpcbuild > > What's wrong with it? > > Tom > > Dr. Thomas D. Schneider > National Cancer Institute > Laboratory of Experimental and Computational Biology > Frederick, Maryland 21702-1201 > toms(a)ncifcrf.gov > permanent email: toms(a)alum.mit.edu > http://www.lecb.ncifcrf.gov/~toms/

1 0

almost there?
by toms＠ncifcrf.gov 16 May '02

16 May '02

Folks: I seem to have done most everything to compile, but have nothing in my bin directory: /users/tds/now/gpc/current>ls bin/ info/ i386-unknown-freebsdelf/ lib/ include/ man/ /users/tds/now/gpc/current>ls bin cpp* i386-unknown-freebsdelf-gcc* gcc* protoize* gcov* unprotoize* Any clues about where the binary went?? I didn't find this process simple at all. I'm building a script to do the entire job automatically, because this process is pretty complicated to repeat by hand each time: http://www.fred.net/tds/gpcbuild What's wrong with it? Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

1 0

compiler warning on shortCard
by Toby Ewing 15 May '02

15 May '02

Hi, all Having fun with Schema; thanks, Frank! I mentioned yesterday that I was getting a compiler warning when I used Cards rather than Integers for Schema, and Frank wanted to know more. Below is a (remarkably familiar) test program. When I compile the program, I get the warning: Warning: comparison is always "True" due to limited range of data type for the three "i" loops. Oddly enough, the "j" and "k" loops get no warning, though in other similar programs I've had warnings for each of nested loops. The medCard variables do not produce warnings when changed to shortCard, nor does the shortCard variable produce an error if it is changed to medCard. As you might guess, byteCard produces the same warning as shortCard. regards, Toby ----------------------------------- program testmem; type Fieldary(sY, sZ : medCard) = array[1..sY,1..sZ] of Real; FPary(sX : medCard) = array[0..sX] of ^Fieldary; var Field : ^FPary; i, j, k : byteCard; nx, ny, nz : medCard; begin write('Enter sizes in x, y, and z: '); readln(nx, ny, nz); New(Field, nx); for i := 0 to nx do New(Field^[i], ny, nz); writeln('Memory allocated OK'); for i := 0 to nx do for j := 1 to nx do for k := 1 to nx do Field^[i]^[j,k] := 1.0 * i * j * k; writeln('Freeing memory...'); for i := 0 to nx do Dispose(Field^[i]); Dispose(Field); end.

3 3

Record Field Alignment
by KOCHERALKOTA harikrishna 15 May '02

15 May '02

Hello, Is there any way in GPC for doing record field alignment to a byte which is default in Borland Pascal.? One more Clarification on the line given below which is taken from the GPC documetation? gpc.info-1(297): - True packed records and arrays. Pack 8 Booleans into 1 byte. I understood that GPC Does true packing on records and arrays. And i also tried the sample program (packingdemo.pas) given by gpc. see the declaration below var A: packed array [1 ..7] of Boolean; The size of A is expected to be 1 byte but it is 2 bytes. For values 9..16 the size is 2 bytes which is ok. once again for values 17...24 it gives 4 bytes(3 bytes expected). why it is so? Thanks and Regards Karthic And Harikrishna

1 0

accessing packed record fields
by KOCHERALKOTA harikrishna 14 May '02

14 May '02

Hello, When accessing the address of a field in a Packed record, it gives an compilation error(platform is solaris 2.6). The error says "cannot take address of bitfield <field name>". Is that true in gpc that one cannot take the address of a field in a packed record ? Is there any other way of solving it? Thanks and Regards, Harikrishna

3 2

Re: GPC 2.1 released
by da Silva, Joe 14 May '02

14 May '02

Yes, that's much better! :-) Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, May 14, 2002 5:14 AM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 released > > da Silva, Joe wrote: > > > Congratulations! Fantastic work!!! > > Thanks. :-) > > > I have one or two suggestions/queries regarding the web page > > "http://www.gnu-pascal.de/download.html" however ... > > > > Firstly, it states that the "http://www.gnu-pascal.de/current/" web > > page is a development snapshot, to be used "at your own risk". > > Is this correct? Isn't that what the "Alpha" and "Beta" directories > > are for? > > Whoops. I expected that some stupid bug would be left, but I'm glad > that it's only on the website (at least until now ;-). > > Fixed. > > > Secondly, it would be helpful to new visitors if the "download" > > page also included a link to "http://www.gnu-pascal.de/binary/". > > After all, new visitors are much more likely to want to download > > a binary than the source code, so this should be presented to > > them directly on the "download" page (also, they could easily > > overlook the "Binary" link at the top of the "Current" web page). > > OK. > > > Finally, it would also be helpful to new visitors if the notes at > > the bottom of the "Libraries" section of the "download" page, > > included a short (one sentence) description of what these > > libraries actually are. It's all rather cryptic otherwise. > > I've made a link to the libraries page. > > Better now? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

1 0

new coompiler, old problem?
by Toby Ewing 14 May '02

14 May '02

Hi, all I have encountered a bug in the old compiler. See test program below. I thought perhaps this had been fixed in version 2.1, but when I installed 2.1, I couldn't get it to compile! I get the message djgpp.ver: No such file or directory (ENOENT) I expect this is a simple fix. What am I missing? FYI, I installed the new gpc files into a new directory, then (because it uses gcc 2.95.3 rather than the new 3.0.0) I put my old 2.95.3 files into the new djgpp directory structure, being careful not to overwrite any new gpc files. I'm running on an Athlon usder win98, and have used gpc for about 5 years. The problem in the old compiler is a crash when writing. The reason for the program approach is this: I'm trying to distribute a program where the user specifies a matrix size in the input file, so I can distribute a binary and users don't need to have a compiler in order to resize the matrix. I've worked with this memory model before, and it worked fine. But now I'm having trouble, and I don't see the problem. many thanks for the old and new compilers, which make my work possible. Toby ------------------------------- program testmem; const Xmax = 25; type Fieldary = array[1..2] of real; FPary = array[0..Xmax] of ^Fieldary; var Field : FPary; FSize, i,j, k, nx : integer; begin writeln; write('Enter the size: '); {I used 5} readln(nx); FSize := 8 * sqr(nx); {making a cube. *8 is for "real"} for i := 0 to nx do GetMem(Field[i], FSize); writeln('Memory allocated OK'); for i := 0 to nx do for j := 1 to nx do for k := 1 to nx do Field[i]^[j+(nx*k)] := 1.0 * i * j * k; writeln('Done assigning. Writing...'); for i := 0 to nx do for j := 1 to nx do begin for k := 1 to nx do write(Field[i]^[j+(nx*k)]:8:1, ' '); {<== CRASHES HERE with a GPF} writeln; end; writeln('Freeing memory...'); for i := 0 to nx do if (Field[i] <> Nil) then FreeMem(Field[i]); end.

3 6

Re: GPC 2.1 released
by da Silva, Joe 13 May '02

13 May '02

Congratulations! Fantastic work!!! I have one or two suggestions/queries regarding the web page "http://www.gnu-pascal.de/download.html" however ... Firstly, it states that the "http://www.gnu-pascal.de/current/" web page is a development snapshot, to be used "at your own risk". Is this correct? Isn't that what the "Alpha" and "Beta" directories are for? Secondly, it would be helpful to new visitors if the "download" page also included a link to "http://www.gnu-pascal.de/binary/". After all, new visitors are much more likely to want to download a binary than the source code, so this should be presented to them directly on the "download" page (also, they could easily overlook the "Binary" link at the top of the "Current" web page). Finally, it would also be helpful to new visitors if the notes at the bottom of the "Libraries" section of the "download" page, included a short (one sentence) description of what these libraries actually are. It's all rather cryptic otherwise. Once again, many thanks from all of us, for the great efforts you and the team have made to bring us GPC 2.1 !!! Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, May 11, 2002 5:21 AM > To: gpc(a)gnu.de; gpc-announce(a)gnu.de > Subject: GPC 2.1 released > > This is the announcement of > > GNU Pascal, version 2.1 > > which is now available from > > http://www.gnu-pascal.de/current/ > > Binaries for some platforms are available in a subdirectory > > http://www.gnu-pascal.de/binary/ > > Binaries for more platforms will follow soon and will be announced > on the GPC mailing list which is archived at > > http://www.gnu-pascal.de/crystal/gpc/en/ > > > About GNU Pascal > ================ > > The GNU Pascal Compiler (GPC) is part of the GNU compiler family, > GNU CC or GCC. It combines a Pascal front-end with the proven GNU C > back-end for code generation and optimization. Unlike utilities such > as p2c, this is a true compiler, not just a converter. > > The purpose of the GNU Pascal project is to produce a Pascal > compiler which > > * combines the clarity of Pascal with powerful tools suitable > for real-life programming, > > * supports both the Pascal standard and the Extended Pascal > standard as defined by ISO, ANSI and IEEE (ISO 7185:1990, > ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989), > > * supports other Pascal standards (UCSD Pascal, Borland Pascal, > parts of Borland Delphi and Pascal-SC) in so far as this > serves the goal of clarity and usability, > > * may be distributed under GNU license conditions, and > > * can generate code for and run on any computer for which the > GNU C compiler can generate code and run on. > > Pascal was originally designed for teaching. GNU Pascal provides a > smooth way to proceed to challenging programming tasks without > learning a completely different language. > > The current release GPC 2.1 implements Standard Pascal (ISO 7185, > levels 0 and 1), a large subset of Extended Pascal (ISO 10206, > aiming for full compliance), is highly compatible to Borland Pascal > (version 7.0) with some Delphi extensions, and provides a lot of > useful GNU extensions. > > For more information about GNU Pascal, see > > http://www.gnu-pascal.de > > > Changes since the previous release > ================================== > > The previous release (GPC 2.0) was more than five years ago. Since > then, there have been numerous alpha and beta versions and literally > hundreds of new features and bug fixes. Trying to list them here, > even if only as a summary, would be far beyond the scope of such an > announcement. You can find descriptions of the new features since > 1999-01-18 at > > http://www.gnu-pascal.de/current/news-2.1.html > > and a detailed list of all new features and bug fixes since > 1997-11-01 at > > http://www.gnu-pascal.de/current/done-2.1.html > > In short, a large number of bugs have been fixed, so GPC 2.1 works > much more stable than its predecessor versions. Also, many relics > that made it sometimes look somewhat like a C compiler rather than a > Pascal compiler have been cleared up. > > Compared to GPC 2.0, the support of ISO 7185 Standard Pascal as well > as Borland Pascal has been mostly completed. Borland Pascal support > includes object oriented programming and a set of compatibility > units. > > Much of ISO 10206 Extended Pascal is now supported, including schema > types (i.e., types whose size can vary at runtime), complex numbers, > set extensions and more. > > Some features of other Pascal standards and dialects are supported, > such as operator overloading (Pascal-SC) and some OOP extensions > (Delphi). > > GPC also contains many extensions not found in other Pascal > compilers, e.g. to ease the interfacing with C and other languages > in a portable way, and to work with files, directories, dates and > more, mostly independent of the underlying operating system. > > A number of useful units is included with GPC, such as `RegEx' > (regular expressions), `GMP' (arithmetic with integer, rational and > real numbers of unlimited size), `Trap' (trapping runtime errors), > `Intl' (internationalization), `Pipe' (inter-process communication), > `MD5' (message digests) and many more. GPC includes a number of demo > programs to show the usage of these units and of many compiler > features. > > Further units, Pascal programs and other 3rd party contributions can > be found at > > http://www.gnu-pascal.de/contrib/ > > > Have fun, > > The GNU Pascal development team >

2 1

GPC v2.1 - Win32 binaries
by Prof. A Olowofoyeku (The African Chief) 13 May '02

13 May '02

Hi all I have released Win32 (Cygwin, and Mingw32) binaries for GPC 2.1: http://gnu-pascal.de/contrib/chief/win32/cygwin/ http://gnu-pascal.de/contrib/chief/win32/mingw32/ Enjoy! Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

Re: [Forwarded] GPC 2.1 released
by Matthias Klose 12 May '02

12 May '02

[CC ing the gpc list as well] Neil Booth writes: > Andreas Jaeger wrote:- > > > > > GPC is still using GCC 2.95. Are there plans to support GCC 3.1 - and > > to integrate GPC into the GCC repository? > > I hope so - I'd like to see that happen. Looks like missing resources: http://www.gnu-pascal.de/crystal/gpc/en/mail6394.html?pos=20026990#20026990 http://www.gnu-pascal.de/crystal/gpc/en/table-mail6789.html Would gpc given a chance to be integrated in a 3.1 point release?

2 1

GPC 2.1 released
by Frank Heckenbach 10 May '02

10 May '02

This is the announcement of GNU Pascal, version 2.1 which is now available from http://www.gnu-pascal.de/current/ Binaries for some platforms are available in a subdirectory http://www.gnu-pascal.de/binary/ Binaries for more platforms will follow soon and will be announced on the GPC mailing list which is archived at http://www.gnu-pascal.de/crystal/gpc/en/ About GNU Pascal ================ The GNU Pascal Compiler (GPC) is part of the GNU compiler family, GNU CC or GCC. It combines a Pascal front-end with the proven GNU C back-end for code generation and optimization. Unlike utilities such as p2c, this is a true compiler, not just a converter. The purpose of the GNU Pascal project is to produce a Pascal compiler which * combines the clarity of Pascal with powerful tools suitable for real-life programming, * supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989), * supports other Pascal standards (UCSD Pascal, Borland Pascal, parts of Borland Delphi and Pascal-SC) in so far as this serves the goal of clarity and usability, * may be distributed under GNU license conditions, and * can generate code for and run on any computer for which the GNU C compiler can generate code and run on. Pascal was originally designed for teaching. GNU Pascal provides a smooth way to proceed to challenging programming tasks without learning a completely different language. The current release GPC 2.1 implements Standard Pascal (ISO 7185, levels 0 and 1), a large subset of Extended Pascal (ISO 10206, aiming for full compliance), is highly compatible to Borland Pascal (version 7.0) with some Delphi extensions, and provides a lot of useful GNU extensions. For more information about GNU Pascal, see http://www.gnu-pascal.de Changes since the previous release ================================== The previous release (GPC 2.0) was more than five years ago. Since then, there have been numerous alpha and beta versions and literally hundreds of new features and bug fixes. Trying to list them here, even if only as a summary, would be far beyond the scope of such an announcement. You can find descriptions of the new features since 1999-01-18 at http://www.gnu-pascal.de/current/news-2.1.html and a detailed list of all new features and bug fixes since 1997-11-01 at http://www.gnu-pascal.de/current/done-2.1.html In short, a large number of bugs have been fixed, so GPC 2.1 works much more stable than its predecessor versions. Also, many relics that made it sometimes look somewhat like a C compiler rather than a Pascal compiler have been cleared up. Compared to GPC 2.0, the support of ISO 7185 Standard Pascal as well as Borland Pascal has been mostly completed. Borland Pascal support includes object oriented programming and a set of compatibility units. Much of ISO 10206 Extended Pascal is now supported, including schema types (i.e., types whose size can vary at runtime), complex numbers, set extensions and more. Some features of other Pascal standards and dialects are supported, such as operator overloading (Pascal-SC) and some OOP extensions (Delphi). GPC also contains many extensions not found in other Pascal compilers, e.g. to ease the interfacing with C and other languages in a portable way, and to work with files, directories, dates and more, mostly independent of the underlying operating system. A number of useful units is included with GPC, such as `RegEx' (regular expressions), `GMP' (arithmetic with integer, rational and real numbers of unlimited size), `Trap' (trapping runtime errors), `Intl' (internationalization), `Pipe' (inter-process communication), `MD5' (message digests) and many more. GPC includes a number of demo programs to show the usage of these units and of many compiler features. Further units, Pascal programs and other 3rd party contributions can be found at http://www.gnu-pascal.de/contrib/ Have fun, The GNU Pascal development team

3 3

GPC Online Documentation/Manual WWW Links
by Jing Gloria 08 May '02

08 May '02

thanks for the prompt response. I must have missed the announcemnt of the web site move. I have updated by browser bookmarks. Pls accept also my apologies for the HTML embedded in my original e-mail. This is due to our company mail server. I hope the Yahoo mail server sends this in true plain text format. Regards, Jing Gloria Texas Instruments Sherman, Tx __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

1 0

Re: final steps for gpc compile
by Emil Jerabek 06 May '02

06 May '02

Tom Schneider wrote: > Emil: > > Last month you described in detail how to install gpc. Almost everything > worked, but I can't install as root on the system since I am not an admin. > > Your instructions were: > > Install (as root): > > cd gcc > make pascal.install-with-gcc > > For laughs I tried it: > > /users/tds/now/gpc/gpc-build/gcc> make pascal.install-with-gcc > make: don't know how to make pascal.install-with-gcc. Stop > > Oh well! I didn't expect it to work, but this mesage is not right - it should > have objected about permissiones or something. Strange. I admit that I've never used this make target personally, maybe I just misinterpreted the docs. Anyway, if you need to install GPC in other place than /usr/local/bin, you must tell it to `configure' _before_ the compilation, e.g. ../gcc-2.95.2/configure --prefix=/some/dir --enable-languages=pascal This puts binaries into /some/dir/bin, the manual into /some/dir/info etc. If you install this way in a personal directory, it doesn't matter much which make target you use, so if `make pascal.install-with-gcc' doesn't work, do simple `make install' (from the build directory, not from its gcc subdirectory). Emil > > How do I do the final step to install in a directory that I pick? > > Thanks, > Tom

2 1

GPC 2.1 RC 8 released
by Frank Heckenbach 02 May '02

02 May '02

Hi everyone, GPC version 20020502, the release candidate #8 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020502.tar.gz A diff against RC 7 can be found at http://www.gnu-pascal.de/current/gpc-20020426-20020502.diff.gz This version contains only small changes compared to RC 7, mostly concerning the compiler driver (the `gpc' executable) and the test under Cygwin and mingw. Since there have been no new bug reports in the last several days, I have some hope that this might be the final RC for GPC 2.1. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

GPC Online Documentation/Manual WWW Links
by Gloria, Jing 02 May '02

02 May '02

Is the GPC on-line documentation server down? http://agnes.dida.physik.uni-essen.de/~gnu-pascal I have tried accessing it the past few days and I am always getting a URL Not Found error. Can somebody pls advise administrator to restore the server? Is there any other mirror for this documentation? Thanks in advance for any assistance. Regards, Jing Gloria Texas Instruments Sherman, Texas

2 1

Problem with linking
by Silvio a Beccara 02 May '02

02 May '02

Hi everybody, I'm trying to write a wrapper unit (called mpichwrap.pas) for the MPICH parallel programming library, with the same aim as for the LAM-MPI. When trying to compile a simple test program, called Prova9, with the command: gpc -L/fastcl/mpich-1.2.2/lib/ prova9.pas -o prova9 gpc is version: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20020318, based on 2.95.2 19991024 (release), running on a Linux machine. I get the following errors: /tmp/ccAmOjTJ1.o: In function `pascal_main_program': /tmp/ccAmOjTJ1.o(.text+0xc6): undefined reference to `MPI_Init' /tmp/ccAmOjTJ1.o(.text+0xdc): undefined reference to `MPI_Comm_size' /tmp/ccAmOjTJ1.o(.text+0xf2): undefined reference to `MPI_Comm_rank' /tmp/ccAmOjTJ1.o(.text+0x157e): undefined reference to `MPI_Barrier' /tmp/ccAmOjTJ1.o(.text+0x18c9): undefined reference to `MPI_Scatterv' /tmp/ccAmOjTJ1.o(.text+0x1bbe): undefined reference to `MPI_Gatherv' /tmp/ccAmOjTJ1.o(.text+0x2464): undefined reference to `MPI_Finalize' /tmp/ccAmOjTJ1.o: In function `init_pascal_main_program': /tmp/ccAmOjTJ1.o(.text+0x248f): undefined reference to `init_Mpichwrap' collect2: ld returned 1 exit status The linking instruction in the wrapper is as follows: {$L mpich} referring to the library libmpich.a It seems that the linker cannot link the object code. All the calls are to library functions. Anyone can help? Thank you in advance, best regards Silvio a Beccara

2 1

Bad "stabs" prevent debugging
by J. David Bryan 30 Apr '02

30 Apr '02

Dear ListFolks, I am unable to set breakpoints, and therefore unable to debug, GPC programs under GDB. The cause appears to be bad debugging information generated by GPC. For example, compiling: program debug (output); var i, j: integer; begin i := 1; j := 2; writeln ('A Pascal test'); writeln ('Variable i is ', i); writeln ('Variable j is ', j) end. with: gpc -g -o debug.exe debug.pas and starting GDB with: gdb debug.exe and then trying to set breakpoints, I see the following: (gdb) break 6 Breakpoint 1 at $4011f2: file <implicit code>, line 6. (gdb) break 8 Note: breakpoint 1 also set at pc $4011f2. Breakpoint 2 at $4011f2: file <implicit code>, line 8. (gdb) break 10 Note: breakpoints 1 and 2 also set at pc $4011f2. Breakpoint 3 at $4011f2: file <implicit code>, line 10. Note that all breakpoints reference the same address. Attempting to start the program gives: (gdb) r Starting program: D:/debug.exe Breakpoint 1, init_pascal_main_program () at <implicit code>:11 11 <implicit code>: No such file or directory. in <implicit code> If I try running "objdump", I see the following: objdump --debugging debug.exe debug.exe: file format pei-i386 Bad stab: Datevalid:(0,21)=@s8;16;,0,8;Timevalid:(0,21),8,8; Year:(0,1),32,32;Month:(0,22)=r(0,1);0000000000001;0000000000014;,64,32; Day:(0,23)=r(0,1);0000000000001;0000000000037;,96,32; Dayofweek:(0,24)=r(0,1);0000000000000;0000000000006;,128,32; [...] Running "objdump" on the object file yields a similar error report. I've reproduced this on several PCs, as follows: * OS: Win95, WinNT4, Win2K * GPC versions: 20011222 (i486-pc-mingw32msvc, 2.95.3) 20020318 (i386-unknown-mingw32 -- the Chief's distro) 20020410 (i486-pc-mingw32msvc, 2.95.3) 20020410 (i686-pc-cygwin, 2.95.3) * GDB versions: 4.18, 5.0, 5.1.1 Is this the same error that is listed in the "Known Bugs" section of the GPC manual as: "...error in debug entries generated for objects" <8F990E3D9A6FD1118F3B0000F81EA1D84985D7(a)exchsa2.dsto.defence.gov.au> -- Dave Bryan

3 4

Question about GPC string type.
by Pierre Muller 29 Apr '02

29 Apr '02

Hi all, I am currently trying to improve GDB pascal support by trying to add support for printing individual chars of a string. (printing the whole strings does work for both compilers). The code that I have works now nicely for Free Pascal, but when I tried to check the code for GPC, I got several bad surprises. test.p var S : string; begin S:='Simple test'; Writeln(s); end. 1) ptyp S where S is a pascal string leads to problems... because the stabs format for the strings is weird... .stabs "S:S(0,46)=s264Capacity:(0,4),0,32;length:(0,4),32,32;_p_schema_:(0,47)=@ s2048;@S;S(0,48)=r(0,1);0000000000001;0000000000400;,64,2048;;",40,0,5,_S Looking into stabsread.c I found out that @S sets is_string to 1, but the fact that after this the type is a S mans that GDB inteprets this as a set type which is transformed into a bitstring type... (you can see this if you use) (gdb) p S._p_schema_ Thus, if I add the missing support for bitstring indexes, I get a true or false printout.... where I would like to have a char output... The problem is that bitstring seems to be the wrong choice here, I understand bitstring as being a packed array of boolean values (probably fortran or modula-2) the correct choice would be to get the compiler to generate an array type instead of a set type after the @S; this would then give a correct TYPE_CODE_STRING type for the _p_schema_ field.... I am now rather clueless about how to add support for this feature for GPC :( PS: I would like to have more feedback about the pascal language support in GDB from all of you. Does noone on this list use GDB? If you ever encounter any pascal language problems in GDB, please report them, I does not read all GPC list mails completely, but I always give more attention if debugger is involved... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

3 2

WWW upload form
by Frank Heckenbach 29 Apr '02

29 Apr '02

Hi everyone, there is now a WWW upload form at http://gnu-pascal.de/contrib/upload.html If you would like to offer some GPC contributions, you can now upload them via this form. But, of course, other ways are also still possible, e.g. sending the files to me by email. If you'd like to make regular uploads, you might want to contact me about getting your own account. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

Problem with packed arrays of boolean in gpc20020402
by Martin Liddle 29 Apr '02

29 Apr '02

The following test program demonstrates a problem with packed arrays of boolean defined in a separate unit. What I see is D reported as 0 followed by a segmentation fault. The program works correctly if all the declarations are in the main program. I am using gpc20020402 based on gcc 2.95.2 on Red Hat 7.2 using kernel 2.4.9-31 with an i686 processor. Program PackedAssignTest; Uses mltestu; Var I,J:Integer; APackedBoolean:TPackedBoolean; Begin ARecord.C:=99; ARecord.D:=100; ARecord.PackedBoolean:=APackedBoolean; Writeln('D=',ARecord.D); End. Unit mltestu; Interface Const MaxA=5; MaxB=62; Type TPackedBoolean=Packed Array[1..MaxA] of Packed Array[1..MaxB] of Boolean; TRecord = Record C:Integer; PackedBoolean:TPackedBoolean; D:Integer; End; Var ARecord:TRecord; Implementation End. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

2 2

GPC 2.1 RC 7 released
by Frank Heckenbach 26 Apr '02

26 Apr '02

Hi everyone, GPC version 20020426, the release candidate #7 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020426.tar.gz A diff against RC 6 can be found at http://www.gnu-pascal.de/current/gpc-20020410-20020426.diff.gz The problem when building GPC with `-pipe' (reported by George Shapovalov) is now really fixed (hopefully). A runtime error on `EOLn' when a text file does not end in a newline (reported by Emil Jerabek), an error when declaring a forward pointer to an overwritten type of name `Word' (reported by Carel Fellinger), and a bug with packed array types declared in units (reported by Martin Liddle) have been fixed. The GMP unit now also supports version 4 of the GMP library. The (Delphi compatible) procedures `Initialize' and `Finalize' have been implemented. The GPC homepage is now also available in Croatian (http://www.gnu-pascal.de/index-hr.html). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

eoln and eof
by Emil Jerabek 26 Apr '02

26 Apr '02

Hi, the RTS sometimes fails to report EOLn before EOF, when a new-line character is missing in the file. For example, this simple program -------------------- program BufferedInput (Output, F); var F: Text; Buffer: String (100); begin Reset (F); while not EOF (F) do begin while not EOLn (F) do begin Read (F, Buffer); WriteLn ('read: `', Buffer, '''') end; WriteLn ('(end of line)'); ReadLn (F) end; WriteLn ('(end of file)') end. ------------------------- produces ---------------------- Input file `F': test read: `first line' (end of line) read: `second line, with no terminator' ./a.out: attempt to read past end of file `test' (error #454 at 8049c73) ---------------------- on this input (where line 2 doesn't end with <LF>): --------------------- first line second line, with no terminator --------------------- Emil Jerabek

2 3

A bug in gpc?
by j.g.ollason 26 Apr '02

26 Apr '02

Greetings everybody, I think that I have found a bug in gpc. The following program generates what I think is a spurious error...of course I could be mistaken. ------------------- program testzero1(input,output); type seabird= record alive:boolean; tomin:real; end ; var tu:real; i,ndives:integer; cguille:seabird; procedure zero(function target(x:real):real;lox,hix:real;var x:real; var found:boolean); begin end { zero }; function fed(var cbird:seabird;var tu:real):seabird; var found:boolean; function oo1(var t:real):real; begin oo1:=0; end { oo1 }; begin with cbird do zero(oo1,0,10000,tomin,found); fed:=cbird; end ; begin cguille:=fed(cguille,tu); end . ---- The error is: testzero1.p: In function `Fed': testzero1.p:26: type mismatch in argument 1 of `Zero' I don't think that there is an error, especially not the one indicated, but I usually believe the compiler's parser rather than my own. What do you think? Thanks, in advance, John Ollason

3 3

pointer forward decl bug
by Carel Fellinger 26 Apr '02

26 Apr '02

Hai, after porting a few thousand lines I think I spotted the next bug. take this simple program: program err; type pword = ^word; word = boolean; var pw : pword; begin new(pw); pw^ := true; end. This is rejected by gpc with: err.pas: In main program: err.pas:12: incompatible types in assignment But if I swap the order of the pword and word type decl's all's swell. Ofcourse using woord (dutch for word) instead of word solves it too. -- groetjes, carel

7 10

Re: GPC 2.1 RC 6 released
by da Silva, Joe 26 Apr '02

26 Apr '02

I see you have solved the mysterious failures. FWIW, yesterday I created a clean directory and tried "test_run" again, as below, except this time I redirected the output of the first run, as well as the second run. In fact (as you no doubt have also discovered), the first run (of "test_run") produces no failures, only the second run does. I also downloaded 'upx' V1.20 and am very impressed with it! It was able to achieve even better compression of the 210K executable file than either 'gzip' or 'zip', by about 5%. The approximate results are as follows (both compiled with GPC) : hello.c : initial size = 13K after 'strip' = 3K after 'upx' = too small to compress (3K) hello.p : initial size = 550K after 'strip' = 210K after 'upx' = 62K So, the smallest GPC executable, using 'strip' and 'upx', is about 62K, which is tolerable. I haven't yet checked what effect the compiler flags have on this, so there might be some more savings possible. Since 'upx' is also available for DOS, I will probably try it on the DJGPP version of GPC as well ... :-) Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, April 24, 2002 11:09 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 6 released > > da Silva, Joe wrote: > > > > > As expected, the "bill.pas" and "confarr9.pas" tests were OK > > > > with the "--automake" option. Although, thinking about it again > > > > now, I'm not sure why the required units for these programs > > > > weren't supplying the "missing" identifiers, since the failures > > > > reported below occurred on the second run of the script file, > > > > so the relevant units would/should have been available in > > > > compiled form. > > > > > > I don't really understand either, and can't seem to reproduce it. If > > > you can give me a recipe how to provoke the problem, starting from a > > > clean test directory, I might be able to say more ... > > > > > [Joe da Silva] > > > > As far as I recall, I simply : > > > > 1. Changed to the (pristine) test directory > > 2. Typed "./test_run" > > 3. Typed "./test_run > results.gpc" > > 4. Extracted the failure details from "results.gpc" > > Ah, now I see. The problem is that several test programs (in > particular, bill.pas and kevin5.pas) used an interface called `Foo', > so foo.gpi compiled from kevin5.pas was included when bill.pas > searched for its interface `Foo' in the 2nd turn. Same with `Test1' > (confarr9.pas and rphil6.pas). I'm renaming these now, to be sure. > > > > Should I add some "magic" variables to protect test_run from being > > > run except via make? > > > > > [Joe da Silva] > > > > Maybe. Or maybe just include a comment at the > > top of "test_run" such as : > > > > "Important : Read the README file first!" > > Since probably not everyone looks into a script before starting it, > I'm doing both ... > > > Hmmm ... so the 13K executable isn't self-contained? > > Not at all. Run `ldd filename' to see the dynamic library > dependencies, or compile with `-static' to get a self-contained > statically linked binary. > > > Does that mean that if this executable were redistributed, > > it might not run, depending on the version of RTS available > > on the recipient machine (assuming the same architecture > > of course)? > > In Pascal, quite likely, unless you distribute the RTS with it. In > C, the problem is less severe, since the interface of libc (C's > "RTS") is more stable. But still, there are enough subtle > differences, especially between different Linux distributions, so I > prefer to distribute any Linux binaries statically linked. YMMV. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

Website error ??
by Niels Ole Staub Kirkeby 25 Apr '02

25 Apr '02

Hi It seems that all subdirectories on the website, www.gnu-pascal.de, has vanished ! Who is webmaster ? Niels Ole Staub Kirkeby nok(a)kirkeby.nu

2 1

Removed Pascal feature?
by Wood David 25 Apr '02

25 Apr '02

Hi all, I've been using your Pascal compiler for a few years now to run a substantial simulation programme. The last copy I was using was dated 20011202. I've downloaded 20020402 and 20020410 and both have a new error with my software: internal error: non-constant actual discriminants not yet supported (they work with 'New' using a pointer to the schema type) Any reason for the change? Regards David Wood Guidance and Imaging Solutions Group QinetiQ X107/1022, Ively Road, Farnborough Phone: 01252-393974 -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 1

Re: eoln and eof
by Emil Jerabek 25 Apr '02

25 Apr '02

CBFalconer wrote: > Emil Jerabek wrote: > > > > the RTS sometimes fails to report EOLn before EOF, when > > a new-line character is missing in the file. For example, > > this simple program > > > > -------------------- > > program BufferedInput (Output, F); > > > > var > > F: Text; > > Buffer: String (100); > > > > begin > > Reset (F); > > while not EOF (F) do begin > > while not EOLn (F) do begin > > Read (F, Buffer); > > WriteLn ('read: `', Buffer, '''') > > end; > > WriteLn ('(end of line)'); > > ReadLn (F) > > end; > > WriteLn ('(end of file)') > > end. > > ------------------------- > > > > produces > > > > ---------------------- > > Input file `F': test > > read: `first line' > > (end of line) > > read: `second line, with no terminator' > > ./a.out: attempt to read past end of file `test' (error #454 at 8049c73) > > ---------------------- > > > > on this input (where line 2 doesn't end with <LF>): > > > > --------------------- > > first line > > second line, with no terminator > > --------------------- > > And it is absolutely correct, IMO. Let's rewrite a portion doing > the standard expansions: > > > while not EOF (F) do begin > > while not EOLn (F) do begin > > Read (F, Buffer); > > WriteLn ('read: `', Buffer, '''') > > end; > Write('(end of line)'); > writeln; > WHILE NOT eoln(F) DO get(f); > get(f); (* <<<<< THIS triggers the error, as it should *) No, it doesn't. Maybe its not aparent from the original program output, but the run-time error is triggered already by the call to EOLn. (Try a debugger, if you don't believe this.) Anyway, the last `get' in your modification should _not_ generate any error, it should bypass the end-of-line character (reported as ' ' in F^), and only after that `get' EOF (F) becomes true, F^ undefined, and get (F) invalid. Also note that both programs work if you declare `Buffer: Char;' instead of a string. > > end; > > The cure is to write "IF NOT eof(f) THEN readln(f);" The "(end of > line)" is probably lying about in some internal buffers and failed > to get completely flushed, which is an entirely different run-time > failing. GPC's run-time system doesn't buffer any output, AFAIK. Emil Jerabek > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! >

1 0

constructors+virtual methods
by Adam Naumowicz 24 Apr '02

24 Apr '02

Hello, I found out that, unfortunately, the newest GPC has a changed processing of constructors. As far as I know, even the virtual methods should be identified in the compilation time in the sense, that when calling a constructor for an object (for example one with destroyed layout) the methods are called inside the constructor the static way. GPC 20020410 causes segmentation fault when I try to call a constructor (and a virtual method inside) on an object which was FillChar'ed (obviously, the same is the case when we use a pointer to an array of objects created by GetMem). See the test program below: program tester; type t=object procedure proc;virtual; constructor Init; end; procedure t.proc; begin writeln('Proc'); end; constructor t.init; begin writeln('Init'); proc; end; var p:array[0..10] of t; begin fillchar(p,sizeof(p),0); p[1].Init; end. I assume, there was some optimalization added to call the virtual methods really the virtual way. Or maybe the constructor creates the VMTP at the end of the constructor process. Is there a chance to get the previous behavior back ? Regards, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

5 22

Re: GPC 2.1 RC 6 released
by da Silva, Joe 24 Apr '02

24 Apr '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, April 24, 2002 12:41 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 6 released > > da Silva, Joe wrote: > > > Well, I did some more experimenting last night ... > > > > As expected, the "bill.pas" and "confarr9.pas" tests were OK > > with the "--automake" option. Although, thinking about it again > > now, I'm not sure why the required units for these programs > > weren't supplying the "missing" identifiers, since the failures > > reported below occurred on the second run of the script file, > > so the relevant units would/should have been available in > > compiled form. > > I don't really understand either, and can't seem to reproduce it. If > you can give me a recipe how to provoke the problem, starting from a > clean test directory, I might be able to say more ... > [Joe da Silva] As far as I recall, I simply : 1. Changed to the (pristine) test directory 2. Typed "./test_run" 3. Typed "./test_run > results.gpc" 4. Extracted the failure details from "results.gpc" > > Not surprisingly, the "--automake" option didn't make any > > difference to the "fjf623.pas" test program. > > > > At this point, I had another look at all the files in the test > > directory and discovered one called "README" <G>. As > > you may have guessed by now, I was just running the > > "test_run" script file (executable files are highlighted in > > bright green on my directory listings, so the script files > > were what I had noticed, and the "test_run" script file in > > particular, looked like the right thing to run). > > Oh well ... > > Should I add some "magic" variables to protect test_run from being > run except via make? > [Joe da Silva] Maybe. Or maybe just include a comment at the top of "test_run" such as : "Important : Read the README file first!" > > So, running the mysterious "make" command instead > > (which seemed to supply a number of option flags to > > GPC, including "--automake"), no errors were reported > > (there were 8 tests skipped, because of some stuff I > > haven't installed)! I don't yet know which option flag fixed > > the "fjf623.pas" failure, although I suspect it might be > > the "-Wall" flag. I may investigate further, for curiosity. > > It was probably the `rm'. ;-) The error that fjf623 is meant to > provoke occurs when the units are compiled. If they have been > compiled in a previous run already, the error doesn't show. > > > I will check the FAQ again about the executable file > > size. I recall previous discussions about using "strip", > > but this only shrunk the file to over 200K. I don't have > > "upx" (yet), so I then simply zipped the 200K file, to > > see how compressible it was. I can't recall the exact > > result, but it was still much, much larger than the 13K > > executable produced by GPC, when it compiled the > > C version of the "hello" program. > > I didn't mean the FAQ document (apparently, it's only updated > sparingly -- when someone likes to add something, just send me the > text, preferable as a diff to faq.text; I don't really have the time > to maintain this document), but this list. > > In short: The RTS is linked statically. It is possible to build and > link it dynamically (make WITH_SHARED=yes), but since its interface > changes often, you might end up with a lot of RTS .so's over time > that some of your binaries depend on. > [Joe da Silva] Hmmm ... so the 13K executable isn't self-contained? Does that mean that if this executable were redistributed, it might not run, depending on the version of RTS available on the recipient machine (assuming the same architecture of course)? > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

Re: GPC 2.1 RC 6 released
by da Silva, Joe 24 Apr '02

24 Apr '02

Well, I did some more experimenting last night ... As expected, the "bill.pas" and "confarr9.pas" tests were OK with the "--automake" option. Although, thinking about it again now, I'm not sure why the required units for these programs weren't supplying the "missing" identifiers, since the failures reported below occurred on the second run of the script file, so the relevant units would/should have been available in compiled form. Not surprisingly, the "--automake" option didn't make any difference to the "fjf623.pas" test program. At this point, I had another look at all the files in the test directory and discovered one called "README" <G>. As you may have guessed by now, I was just running the "test_run" script file (executable files are highlighted in bright green on my directory listings, so the script files were what I had noticed, and the "test_run" script file in particular, looked like the right thing to run). So, running the mysterious "make" command instead (which seemed to supply a number of option flags to GPC, including "--automake"), no errors were reported (there were 8 tests skipped, because of some stuff I haven't installed)! I don't yet know which option flag fixed the "fjf623.pas" failure, although I suspect it might be the "-Wall" flag. I may investigate further, for curiosity. It seems to me therefore, that the build process was a success, thanks to the nice clear instructions on the web site! Since I'm new to Linux and since this was my first attempt to build GPC, I'm amazed! :-) I will check the FAQ again about the executable file size. I recall previous discussions about using "strip", but this only shrunk the file to over 200K. I don't have "upx" (yet), so I then simply zipped the 200K file, to see how compressible it was. I can't recall the exact result, but it was still much, much larger than the 13K executable produced by GPC, when it compiled the C version of the "hello" program. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, April 23, 2002 10:57 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 6 released > > da Silva, Joe wrote: > > > Well, just an update on my attempts to build GPC 20020410 on > > Mandrake (based on the SuSE GCC 2.95.3 source archive) ... > > > > I followed the instructions from the web pages verbatim, and as > > the Chief said, it's "quite straightforward". As far as I could tell, > > there were no errors in building gpc-20020410, just a warning or > > two, which AFAIK is "normal" with C programs. > > Maybe, maybe not. Without seeing the text of the warnings, it could > be anything. > > > I then ran the test script, expecting this would produce a summary > > at the end. > > What exactly did you do? Simply make, or make pascal.check-long or > whatever? > > > It didn't, so I ran this again but this time I redirected > > the output to a file. After this, I searched the file for the word > "failed" > > and extracted the following : > > > > TEST bill.pas: ./bill.pas: In main program: > > ./bill.pas:7: undeclared identifier `Dectobin' (first use in this > routine) > > ./bill.pas:7: (Each undeclared identifier is reported only once > > ./bill.pas:7: for each routine it appears in.) > > failed > > > > TEST confarr9.pas: ./confarr9.pas: In main program: > > ./confarr9.pas:7: undeclared identifier `Test' (first use in this > routine) > > ./confarr9.pas:7: (Each undeclared identifier is reported only once > > ./confarr9.pas:7: for each routine it appears in.) > > failed > > > > TEST fjf623.pas: failed: failed 1 2 > > > > I had a quick look at the first two "failures", and I am not sure > > why these would have failed. The Pascal code looked OK, so > > I suspect the problem might be in the script file, which I will try > > to decipher a bit later ... > > It might be easier to try compiling the programs manually (with > `gpc --automake'). If they still fail, the problem is not in the > script. > > > I also invoked GPC to compile a small "hello" program in both > > Pascal and in C. Both worked, however, the "a.out" file from > > the Pascal compilation was over 500K, whereas that from the > > C compilation was about 13K. Is this normal??? > > Yes, FAQ. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

CRT and numeric keypad
by Couperin 23 Apr '02

23 Apr '02

In programs compiled using the CRT unit, the keys /, *, -, + and ENTER of the numeric keypad are no longer availables (they display other characters). How to solve this problem ? [French Keyboard/Windows ME/GPC 20010331/GCC 2.95.2] Thanks for help. -- "couperin"

3 7

Re: GPC 2.1 RC 6 released
by da Silva, Joe 23 Apr '02

23 Apr '02

Well, just an update on my attempts to build GPC 20020410 on Mandrake (based on the SuSE GCC 2.95.3 source archive) ... I followed the instructions from the web pages verbatim, and as the Chief said, it's "quite straightforward". As far as I could tell, there were no errors in building gpc-20020410, just a warning or two, which AFAIK is "normal" with C programs. I then ran the test script, expecting this would produce a summary at the end. It didn't, so I ran this again but this time I redirected the output to a file. After this, I searched the file for the word "failed" and extracted the following : TEST bill.pas: ./bill.pas: In main program: ./bill.pas:7: undeclared identifier `Dectobin' (first use in this routine) ./bill.pas:7: (Each undeclared identifier is reported only once ./bill.pas:7: for each routine it appears in.) failed TEST confarr9.pas: ./confarr9.pas: In main program: ./confarr9.pas:7: undeclared identifier `Test' (first use in this routine) ./confarr9.pas:7: (Each undeclared identifier is reported only once ./confarr9.pas:7: for each routine it appears in.) failed TEST fjf623.pas: failed: failed 1 2 I had a quick look at the first two "failures", and I am not sure why these would have failed. The Pascal code looked OK, so I suspect the problem might be in the script file, which I will try to decipher a bit later ... I also invoked GPC to compile a small "hello" program in both Pascal and in C. Both worked, however, the "a.out" file from the Pascal compilation was over 500K, whereas that from the C compilation was about 13K. Is this normal??? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, April 11, 2002 9:31 PM > To: gpc(a)gnu.de > Subject: GPC 2.1 RC 6 released > > Hi everyone, > > GPC version 20020410, the release candidate #6 for GPC 2.1, has been > uploaded to > http://www.gnu-pascal.de/current/gpc-20020410.tar.gz > > A diff against RC 5 can be found at > http://www.gnu-pascal.de/current/gpc-20020402-20020410.diff.gz > > According to a request by the Chief, the install target > `pascal.install' and the Pascal only binary distributions > (`pascal.bindist') do not include libgcc.a anymore. It is now only > included with `pascal.install-with-gcc' and Pascal binaries with gcc > (`pascal.bindist-with-gcc'), since the former should be used if (and > only if) a matching GCC version is already installed which includes > libgcc.a. > > A module name conflict (which prohibited certain module names, e.g., > `Files') was resolved, thanks to a report by Carel Fellinger. In the > course of fixing this problem, the directive `asmname' was enabled > for programs, units and module interfaces. > > Some small bugs were fixed, including a problem when building GPC > with `-pipe' (thanks to a report by George Shapovalov), the problem > that ParamStr was not accepted as the first argument of `ReadStr' > and `Val' (thanks to a report by Maurice Lombardi), a bug with > differences of integer constans and a bug with a special case of > nested schema types (thanks to reports by Emil Jerabek) and some > other small bugs. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

3 3

Storing Random Seed
by Silvio a Beccara 22 Apr '02

22 Apr '02

Hi, is there a way to store and save the random seed state vector used to initialise the random generator of GPC (the Mersenne Twister)? This is very important when one has to restart simulations using the same seed. Thanks, regards Silvio a Beccara

3 4

Current stable release?
by John Ollason 19 Apr '02

19 Apr '02

I'm not much interested in the systems programming issues of installing gpc, and the version I downloaded as a binary and installed under Redhat 5.2 years ago (version 2.8.1) has been quite satisfactory until yesterday when it got itself into an endless loop while compiling a program. I know that the program compiles and runs under Redhat 6.2 and gpc version 2.95.2 19991024. I'd be very grateful if someone could tell me the latest version of gpc that is available as a Redhat .rpm file (and where to find it). Thanks, in advance, John Ollason

2 1

gpc almost complied - now what?
by toms＠ncifcrf.gov 19 Apr '02

19 Apr '02

Hi Folks! I got the latest packages and tried to install on a BSD system my ISP just set up (4.5-RELEASE FreeBSD 4.5-RELEASE). It went pretty well. Following are the things I did (approximately) ending on an error message that I can't interpret. What's next? wget http://www.gnu-pascal.de/current/gcc-core-2.95.2.tar.gz gunzip gcc-core-2.95.2.tar.gz tar xvf gcc-core-2.95.2.tar wget http://www.gnu-pascal.de/current/gpc-20020410.tar.gz gunzip gpc-20020410.tar.gz tar xvf gpc-20020410.tar cd gpc-20020410 mv p ../gcc-2.95.2/gcc mkdir gpc-build cd gpc-build/ /users/tds/gpc/gcc-2.95.2/configure --enable-languages=pascal This seems to have worked fine. make ******************************** (lots of compile messages) xgpc: xgpc:: No such file or directory xgpc: :: No such file or directory xgpc: No: No such file or directory xgpc: such: No such file or directory xgpc: file: No such file or directory xgpc: or: No such file or directory xgpc: directory: No such file or directory xgpc: xgpc:: No such file or directory xgpc: No: No such file or directory xgpc: input: No such file or directory xgpc: files: No such file or directory *** Error code 1 Stop in /users/tds/gpc/gpc-build/gcc/p/rts. *** Error code 1 Stop in /users/tds/gpc/gpc-build/gcc. *** Error code 1 Stop in /users/tds/gpc/gpc-build. ******************************** Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

5 7

Accessing Memory
by Rocker73＠aol.com 19 Apr '02

19 Apr '02

Hello, I have a question about accessing memory using GPC. I'm running GPC on a FreeBSD UNIX system. How do you directly access memory via a generic pointer in GPC? In Borlan Pascal 7, there are special array called Mem, MemW, and MemL. Does GPC have anything equivilent? Dan.

3 2

GPC 2.1 RC 6 released
by Frank Heckenbach 18 Apr '02

18 Apr '02

Hi everyone, GPC version 20020410, the release candidate #6 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020410.tar.gz A diff against RC 5 can be found at http://www.gnu-pascal.de/current/gpc-20020402-20020410.diff.gz According to a request by the Chief, the install target `pascal.install' and the Pascal only binary distributions (`pascal.bindist') do not include libgcc.a anymore. It is now only included with `pascal.install-with-gcc' and Pascal binaries with gcc (`pascal.bindist-with-gcc'), since the former should be used if (and only if) a matching GCC version is already installed which includes libgcc.a. A module name conflict (which prohibited certain module names, e.g., `Files') was resolved, thanks to a report by Carel Fellinger. In the course of fixing this problem, the directive `asmname' was enabled for programs, units and module interfaces. Some small bugs were fixed, including a problem when building GPC with `-pipe' (thanks to a report by George Shapovalov), the problem that ParamStr was not accepted as the first argument of `ReadStr' and `Val' (thanks to a report by Maurice Lombardi), a bug with differences of integer constans and a bug with a special case of nested schema types (thanks to reports by Emil Jerabek) and some other small bugs. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

3 5

Re: gpc almost complied - now what?
by Ernst-Ludwig Bohnen 17 Apr '02

17 Apr '02

On Wed, 17 Apr 2002, da Silva, Joe wrote: > Hi Ernst-Ludwig, > > I'm new to Linux, but my experience with learning *nix, is that the > safest "help" option to attempt with an unfamiliar program or script > is '--help'. So as a suggestion, if it's not difficult, you should also > detect a '--help' argument as equivalent to '-h'. > Regards, > Joe. OK, done. By the way, the script should not start working immediately after typing it's name, instead it should print some help. Change is under way. Regards, Ernst-Ludwig

1 0

editor contribution
by Russell Whitaker 17 Apr '02

17 Apr '02

Hi Attached is a tar.gz source listing of an editor written in pascal. Caution: It works just fine here ( linux box ) but it might not in yours - so approach with caution. enjoy Russ

3 4

Re: gpc ebuild for gentoo linux
by da Silva, Joe 17 Apr '02

17 Apr '02

Thanks again. Please see below ... Joe. > -----Original Message----- > From: Prof. A Olowofoyeku (The African Chief) > [SMTP:african_chief@bigfoot.com] > Sent: Thursday, April 11, 2002 8:27 PM > To: da Silva, Joe > Subject: RE: gpc ebuild for gentoo linux > > On 11 Apr 2002 at 19:38, da Silva, Joe wrote: > > > Thanks, Chief. > > > > Mandrake normally has GCC 2.96 (well, my copy at least), > > Yes, it does. But v8.1 only comes with gcc-3.0.x, but that is not the > default compiler that the system uses. > > > which from previous discussions is a "broken" version. > > I don't think it is broken in respect of what it can do (it can build > the linux kernel, and anything else). But the sources are probably > not compatible with building GPC on them. > > > So my plan to eventually > > install a GCC 2.95.3 and a similar build of GPC might be problematic? > > Not at all. I have done that. It is quite straightforward. However, > you will need to install GPC with "make install", rather than > "make pascal.install". That way, gcc-2.95.3 will also be installed > along with GPC. Just make sure that you don't overwrite the existing > gcc installation. I normally configure with "--prefix=/usr/local", so > [Joe da Silva] Is there any particular reason I should not overwrite an existing GCC installation? I had intended to use "make install" and standardize on 2.95.3 for both GCC and GPC (I'd rather not have two versions of GCC installed, unless I have to). > that the new installation goes to a different place from the system > compiler, and when I want to run GPC, I first do: > "export PATH=/usr/local/bin:$PATH > This means that the GPC path will be found first, and if GPC needs to > use the C compiler for something (e.g., building the crt unit), it > will use the new gcc-2.95.3 instead of the system gcc compiler). > > > Hmmm ... looks like I will have to become a lot more familiar with > > this Linux stuff, before I try this. :-/ > > There is nothing to fear. It is all quite straightforward. It is as > simple as: > configure --prefix=/usr/local > make > make install > export PATH=/usr/local/bin:$PATH > > Best regards, The Chief > --------- > Prof. Abimbola Olowofoyeku (The African Chief) > Email: African_Chief(a)bigfoot.com > http://www.bigfoot.com/~african_chief/

3 2

None
by Adam Naumowicz 17 Apr '02

17 Apr '02

Hello, A quick question - what can be wrong: after installing the newest GPC I still get the same error: /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x18): undefined reference to `main' collect2: ld returned 1 exit status while compiling simple: unit blah; interface implementation end. Is there something wrong with the installation ? (previously I had gcc 2.95.3 installed in /usr/lib, I compiled and installed GPC (by make install) into /usr/local/). Thanks for any hints. Best Regards, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

4 5

Re: GPC && ( BeOS || mac os x )
by Prof. A Olowofoyeku (The African Chief) 16 Apr '02

16 Apr '02

Hi [...] > I am including the output, but only the last 7 or 8 lines, since the > rest seems okay: > > gcc -c -DIN_GCC -g -O2 -DHAVE_CONFIG_H -I. > -I/boot/home/fred/fsf/gcc/gcc -I/boot/home/fred/fsf/gcc/gcc/config > -I/boot/home/fred/fsf/gcc/gcc/../include > /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c > /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c: In function > `i386_pe_dllimport_p': > /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: > `TARGET_NOP_FUN_DLLIMPORT' undeclared (first use in this function) > /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: (Each undeclared > identifier is reported only once > /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: for each function > it appears in.) make[1]: *** [winnt.o] Error 1 make[1]: Leaving > directory `/boot/home/buildarena/gcc' make: *** [all-gcc] Error 2 > > What I need to know is what flags I need to use with 'configure' > and/or 'make' to specify that I don't want anything related to Windows > compiled in. Isn't this possible? That would effectively skip right > over these headers and source files, right? Perhaps. Basically, gcc cannot compile itself. This makes it a gcc matter and not a GPC matter - but the prospects are not looking very bright at the moment. I think you need to speak to BeOS gcc porters about this, since no-one here will have a clue as to what the real probem is. I am surprised that the BeOS gcc porters didn't provide gcc sources that will compile without any need for tinkering. What is their advice concerning the configure scripts and the build process? Do they build gcc natively, or do they use a cross compiler? Obviously, 'configure', when left to its own devices, thinks that you are using Windows. This may be due to the deliberate actions of the porters, or 'configure' may just have guessed wrongly. Try running 'config.guess' and see what system it thinks you are running on. You may need to supply other arguments to 'configure' (e.g., '--build', '--host', '--target'). Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

GPC && ( BeOS || mac os x )
by Philip George 16 Apr '02

16 Apr '02

Chief, your suggestion was brilliant in its simplicity. I found two places that prepare gcc for BeOS: [1] http://www.geekgadgets.org [2] http://www.toyoshima-house.net I had a little luck with the latter, but not enough to complete the task. GeekGadgets provides all the source for gcc 2.95.1, but all the necessary changes were made to accommodate installation on BeOS. So, configuration now works perfectly: % cd ~/buildarea % make distclean % /..../configure --enable-languages=pascal --prefix=/boot/testloc Needless to say, this gave way to much whooping and hollering! :) --BUT-- (the inevitable 'BUT') Here is the problem I'm having now, and I'm POSITIVE that it's a simple one to resolve. I just can't quite get my brain around it: When I run 'make' after a successful configuration, it churns on it for about 5 minutes, spitting out the usual DHAVE_THIS and DHAVE_THAT, looking for the most part like a successful compilation in the works.... BUT... all of a sudden the whole thing comes to a screeching halt at: make[1]: *** [winnt.o] Error 1 make[1]: Leaving directory `/boot/home/buildarea/gcc' make: *** [all-gcc] Error 2 % I am including the output, but only the last 7 or 8 lines, since the rest seems okay: gcc -c -DIN_GCC -g -O2 -DHAVE_CONFIG_H -I. -I/boot/home/fred/fsf/gcc/gcc -I/boot/home/fred/fsf/gcc/gcc/config -I/boot/home/fred/fsf/gcc/gcc/../include /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c: In function `i386_pe_dllimport_p': /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: `TARGET_NOP_FUN_DLLIMPORT' undeclared (first use in this function) /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: (Each undeclared identifier is reported only once /boot/home/fred/fsf/gcc/gcc/config/i386/winnt.c:201: for each function it appears in.) make[1]: *** [winnt.o] Error 1 make[1]: Leaving directory `/boot/home/buildarena/gcc' make: *** [all-gcc] Error 2 What I need to know is what flags I need to use with 'configure' and/or 'make' to specify that I don't want anything related to Windows compiled in. Isn't this possible? That would effectively skip right over these headers and source files, right? Again, thanks in advance for any/all assistance. - pgeorge >> There are a couple threads about installing GPC onto Mac OS X and BeOS. >> The main one for BeOS ends with "just try it," which I did... and it >> didn't work. > [...] >> • The failure is the same on both platforms when running 'configure' >> - 'Configuration i586-pc-beos not supported' (BeOS) >> - 'Configuration powerpc-apple-bsd not supported' (Mac OS X) > > You may be able to solve this by amending the various configure.* > scripts, first, to remove the error being reported, and secondly, to > tell them what to do with BeOS and Mac OSX. You will find various > sections and entries which relate to the various platforms supported by > gcc (try searching for "linux" in the various "configure.in" scripts, > and you will see what I mean). Since you are writing an OS under BeOS, > you obviously know a lot about the system internals. You should be able > to supply the scripts with entries for BeOS. > >> I'm using GCC 2.95.2 source and GPC 20020417 (tried ...410 also) from >> which to attempt the builds and I'm cleaning between failed >> attempts. I >> am following the installation instructions to the T, right down to the >> folder called 'fred'. >> >> For those who are wondering, BeOS 5 is about 99% POSIX compliant (the >> other 1% is GUI-related I believe). Maybe that's the hitch; is there >> possibly a --posix flag or something like that??? HHHmmmmm.... Not >> sure. It's primary language is C/C++ and the default tools are gnu gcc >> and the rest of the gang, so one would thing that we could slide GPC >> right in there beside it without a problem. >> > > If you can build gcc under BeOS, then you are on your way. If gcc is > the default tool, then someone has obviously been able to build gcc. My > advice is - find that someone and ask them how they did it. It is > necessary for building GPC that gcc can be built on the system. > Presumably, whoever built the gcc compilers for BeOS have (under the > GPL) to make their gcc sources available. Use those sources instead of > the pristine GNU sources, and you may well have greater success. > > PS: it may well be that the GPC patches will fail under a patched gcc > version (if there had been too many changes), but I doubt that they > will fail.

1 0

GPC && ( BeOS || mac os x )
by Philip George 15 Apr '02

15 Apr '02

There are a couple threads about installing GPC onto Mac OS X and BeOS. The main one for BeOS ends with "just try it," which I did... and it didn't work. The most helpful one for Mac OS X links to a PDF that contains instructions for getting GPC compiled... but it's in French, and after the free French-English translation websites butcher it, it's more difficult to read than it was in French! Here's the deal: • I need to install GPC on BeOS 5 for Intel - Getting it installed in Mac OS X is secondary at best . BUT, it would be a nice bonus if you could help . I would like the focus of this thread to be on BeoS • I'm writing a new operating system from within BeOS - I am writing custom link libraries specific to my OS . So I don't care about lack of BeOS-specific libs in GPC • BePascal is no more, so it is not an option - Unless you know where I can still obtain it from • The failure is the same on both platforms when running 'configure' - 'Configuration i586-pc-beos not supported' (BeOS) - 'Configuration powerpc-apple-bsd not supported' (Mac OS X) I'm using GCC 2.95.2 source and GPC 20020417 (tried ...410 also) from which to attempt the builds and I'm cleaning between failed attempts. I am following the installation instructions to the T, right down to the folder called 'fred'. For those who are wondering, BeOS 5 is about 99% POSIX compliant (the other 1% is GUI-related I believe). Maybe that's the hitch; is there possibly a --posix flag or something like that??? HHHmmmmm.... Not sure. It's primary language is C/C++ and the default tools are gnu gcc and the rest of the gang, so one would thing that we could slide GPC right in there beside it without a problem. I've never had good experiences with mailing lists. People tend to get off topic or are unable to see THE BIG PICTURE sometimes, but I've seen some quality threads on this particular list, so I'm hopeful that a solution is right around the bend. Thanks in advance for any/all assistance. - pgeorge

2 1

Re: gpc almost complied - now what?
by Tom Schneider 15 Apr '02

15 Apr '02

Russell: > As a guess, instead of > make > try > make bootstrap make all-recursive Making all in intl Making all in lib Making all in makeinfo Bootstrapping the compiler make: don't know how to make bootstrap. Stop *** Error code 2 Tom

2 1

Re: gpc ebuild for gentoo linux
by da Silva, Joe 11 Apr '02

11 Apr '02

OK, if I may ask a possibly silly question ... I installed Linux (Mandrake) almost two weeks ago now (having never used Linux before), so there's a LOT I don't yet understand. So, is there any difference between a GPC build for one flavour of Linux, versus another? Assuming it's based on the same GCC version (eg. 2.95.3), and the same PC architecture, of course. Joe. > -----Original Message----- > From: George Shapovalov [SMTP:georges@its.caltech.edu] > Sent: Thursday, April 11, 2002 3:30 PM > To: gpc(a)gnu.de > Subject: Re: gpc ebuild for gentoo linux > > I completed and tested ebuild for gpc-20020402 (rc5) for Gentoo Linux. > It has been commited and now is available. Frank, thanks for help! > > If there are any gentoo users I would appreciate some testing :). > The instructions are pretty standard: > 1. unmask the package by commenting out gpc entry in > /usr/portage/profiles/package.mask > (I will keep it masked for a few days until I am completely sure) > 2. emerge gpc > > to test it you can unpack gpc tarball and run testsuite (4 tests will be > skipped since librx is not installed). > > George > >

3 2

Error in gpc makefile AND HPUX bug resolved!
by S. Achterop IWI-120 3932 11 Apr '02

11 Apr '02

Hello again on the gpc mailing list. This is to inform you of 2 things. 1 ============ During the "make" of gpc the assembler often gives the following message: cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled. In the HPUX this is the case with: GNU assembler version 2.9 (hppa1.1-hp-hpux10.20), using BFD version 2.9 That is no problem, but somehow the string gpc1: warning: -g is only supported when using GAS on this processor, gpc1: warning: -g option disabled. gets into the file gpc-build/gcc/p/rts/needed-options and make's the build to stop with an error. Using an empty file "needed-options" as a hack yields a complete and working gpc!! 2 ============= The known bug: # HP/UX: `unrecognizable insn' error in connection with conformant or const string parameters) <199809280741.JAA17719(a)rug105.cs.rug.nl> (sietse1.pas), <Pine.SOL.4.10.9908051751550.23095-100000(a)niflheim.rutgers.edu>, <396C3531.3A327722(a)cs.rug.nl> Seems to RESOLVED in the snapshot that I compiled! (gpc version 20020402, based on 2.95.2 19991024 (release)) Thanks ! Sietse Achterop

2 1

-pipe breaks gpc build
by George Shapovalov 11 Apr '02

11 Apr '02

Thanks for a great compiler to everybody involved! I would like to inform you that I am writing an ebuild script to make gpc available in Gentoo Linux distribution. (http://www.gentoo.org) In process I found the issue in the subject, thought it might be interesting. If I have "-pipe" in my CFLAGS when compiling gpc the compilation breaks when gpcpp is processing string.pas (removal of -pipe gets rid of the problem). Listing is included at the end of message. Also, INSTALL instructions say that I might need PDCurses under Linux to compile some crt programs. Is this a build-time dependency (when I compile gpc) or runtime (when I use gpc to compile some programs)? I guess the question is: should I have PDCurses installed when I compile gpc in order to be able to compile crt programs for use under X? Or will gpc pick the library up later when it is installed? What about ncurses, am I limited to terminal-only programs under X then? Thanks. George make[2]: Entering directory `/var/tmp/portage/gpc-20020402/work/gcc-2.95.3/gcc/p/rts' ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -march=i686 -O2 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-loop-opt -malign-functions=4 -DRTS_RELEASE_STRING="'`cat /var/tmp/portage/gpc-20020402/work/gcc-2.95.3/gcc/p/rts/rts-version`'" --unit-path=/var/tmp/portage/gpc-20020402/work/gcc-2.95.3/gcc/p/rts --automake `cat needed-options` string.pas xgpc: gpcpp:: No such file or directory xgpc: output: No such file or directory xgpc: pipe: No such file or directory xgpc: has: No such file or directory xgpc: been: No such file or directory xgpc: closed: No such file or directory xgpc: gpcpp:: No such file or directory xgpc: output: No such file or directory xgpc: pipe: No such file or directory xgpc: has: No such file or directory xgpc: been: No such file or directory xgpc: closed: No such file or directory gpc1: ../.././xgpc exited with status 1 gpcpp: output pipe has been closed make[2]: *** [string.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/gpc-20020402/work/gcc-2.95.3/gcc/p/rts' make[1]: *** [pascal.rts] Error 2 make[1]: Leaving directory `/var/tmp/portage/gpc-20020402/work/gcc-2.95.3/gcc' make: *** [all-gcc] Error 2

2 4

help request with Pexecute compile problem
by Tam Pikey 10 Apr '02

10 Apr '02

Hi I'm hoping someone out there has some suggestions for how to go about fixing this. I've got gpc & gcc installed on an Ultra 10 running Solaris 2.7. The program is simply suppose to invoke the system sort command but as you can see we're not getting it to compile. The compile error is: ------------------------ [09:44:46] sdis:~/sdis >gpc sort.pas sort.pas: In function `program_Sort': sort.pas:11: undeclared identifier `Pexecute' (first use this function) sort.pas:11: (Each undeclared identifier is reported only once sort.pas:11: for each function it appears in.) sort.pas:12: undeclared identifier `Pexecute_one' (first use this function) sort.pas:12: undeclared identifier `Pexecute_search' (first use this function) sort.pas:12: undeclared identifier `Pexecute_verbose' (first use this function) [09:44:55] sdis:~/sdis > The code consists of: ------------------------ program Sort (Input, Output); uses GPC, Pipe; var Status: Integer; Command: TString; Message: TString; Argument: array [0 .. 1] of CString = (nil, nil); begin Command := 'Sort -k .9,.10 test.txt'; Status := PExecute (Command, PCStrings (@Argument), Message, PExecute_One or PExecute_Search or PExecute_Verbose); if Status < 0 then WriteLn ('PExecute (Sort) : ', Message) else WriteLn ('PID ', Status) end. My compiler versions are: ------------------------ [09:23:29] root:~ >gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 [09:23:32] root:~ >gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) [09:23:39] root:~ > tam (axtlp(a)uaa.alaska.edu)

3 2

Integer constants
by Emil Jerabek 10 Apr '02

10 Apr '02

Hi all, this looks like a bug: non-negative integer constants are treated as LongestCard, i.e. an unsigned type. [pas]% gpc -v Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20020402, based on 2.95.2 19991024 (release) [pas]% cat sign.pas program Foo (Output); const Two = 2; begin if (0 < Two - 23) or (3 < 13 - 42) then WriteLn ('failed: ', Two - 23, ', ', 13 - 42) else WriteLn ('OK') end. [pas]% gpc sign.pas [pas]% ./a.out failed: 18446744073709551595, 18446744073709551587 And an unrelated one: a schema discriminant is not initialized in the situation below. [pas]% cat schema.pas program Foo (Output); type A (N: Integer) = Integer; B (N: Integer) = array [1 .. N] of A (N); var C : B (7); begin if (C.N = 7) and (C[3].N = 7) then WriteLn ('OK') else WriteLn ('failed: ', C.N, ' ', C[3].N) end. [pas]% gpc schema.pas [pas]% ./a.out failed: 7 0 Emil Jerabek

2 1

GPC 2.1 RC 5 released and moved
by Frank Heckenbach 09 Apr '02

09 Apr '02

Hi everyone, GPC version 20020402, the release candidate #5 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020402.tar.gz A diff against RC 4 can be found at http://www.gnu-pascal.de/current/gpc-20020318-20020402.diff.gz The home page of GPC is now http://www.gnu-pascal.de/ The download area has moved to the same URL. All the downloads are now offered via HTTP rather than FTP. Apart from the move, the changes since RC 4 are quite minor, so there is some real hope that this is the final RC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

2 4

MPI
by Silvio a Beccara 09 Apr '02

09 Apr '02

Hello, has anyone experienced problems in using the MPI function MPI_Type_vector with dynamic arrays in GPC? Everytime it "eats" away the second element of the array, and I don't know why. Thanks, best regards Silvio a Beccara

2 1

Re: Memory leak in stringutils.pas?
by da Silva, Joe 09 Apr '02

09 Apr '02

OK, just speculating here ... <G> I'd think that "known problem with some string operations (especially concatenation) in a loop" means "writeln(os1+' '+os2+os3+os4+os5+os6)" is the problem, since this is string concatenation and is within a "while" loop ... Joe. > -----Original Message----- > From: Preben Mikael Bohn [SMTP:preben_bohn@yahoo.com] > Sent: Tuesday, April 09, 2002 6:06 PM > To: gpc(a)gnu.de > Subject: Re: Memory leak in stringutils.pas? > > I don't know if I understand you the right way (I probably don't). > I just tried to move tokenize+dispose into a subroutine (but still > in the loop) like the following, but it still has a memory leak... > > program test1; > > uses > GPC, > stringutils; > > function split( > var inStr : string; > var os1,os2,os3,os4,os5,os6 : string; > var c : charset ) : integer; > var > tokens : PPStrings; > begin > tokens := TokenizeString (inStr, c); > os1 := tokens^[1]^; > os2 := tokens^[2]^; > os3 := tokens^[3]^; > os4 := tokens^[4]^; > os5 := tokens^[5]^; > os6 := tokens^[6]^; > split := tokens^.count; > DisposePPStrings (tokens); > end; > > var > line,os1,os2,os3,os4,os5,os6 : string; > lineNumber, count : integer; > c : charset; > > begin > c := ['¤']; > lineNumber := 0; > while lineNumber < 1000000 do > begin > line := 'string1¤string2¤string3¤string4¤string5¤string6'; > inc(lineNumber); > count := split(line, os1,os2,os3,os4,os5,os6,c); > if (linenumber mod 10) = 0 then > begin > writeln('Line number : ', lineNumber); > writeln(os1+' '+os2+os3+os4+os5+os6); > end; > end; > end. > > Best regards > > Preben Bohn > > > --- Frank Heckenbach <frank(a)g-n-u.de> wrote: > > =?iso-8859-1?q?Preben=20Mikael=20Bohn?= wrote: > > > > > After sucessfully installing GPC I tried the following > > (basically a > > > loop around the stringutils test-program). However it seems to > > have > > > a memoryleak, after a while (~14%MEM on my machine) it comes > > out > > > with a segmentation fault (and with top you can see that the > > memory > > > usage grows)... > > > > The memory leak is not in the unit, but in GPC itself. It's a > > known > > problem with some string operations (especially concatenation) in > > a > > loop. (If you can read /proc/n/maps, you'll see that it's the > > stack, > > not the heap that grows.) Moving the thing out of the loop > > (syntactically, e.g. in a subroutine) is a work-around. > > > > Frank > > > > -- > > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > > GPC To-Do list, latest features, fixed bugs: > > http://www.gnu-pascal.de/todo.html > > > > ===== > > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com

3 2

Memory leak in stringutils.pas?
by Preben Mikael Bohn 09 Apr '02

09 Apr '02

Hi all After sucessfully installing GPC I tried the following (basically a loop around the stringutils test-program). However it seems to have a memoryleak, after a while (~14%MEM on my machine) it comes out with a segmentation fault (and with top you can see that the memory usage grows)... What am I doing wrong? Best regards Preben Bohn program test1; uses GPC, stringutils; var tokens : PPStrings; line : string; lineNumber : integer; c : charset; begin c := ['Â¤']; lineNumber := 0; while lineNumber < 1000000 do begin line := 'string1Â¤string2Â¤string3Â¤string4Â¤string5Â¤string6'; inc(lineNumber); tokens := TokenizeString (line, c); if (linenumber mod 10) = 0 then begin writeln('Line number : ', lineNumber); writeln(tokens^[1]^ + ' ' + tokens^[2]^+ ' ' + tokens^[3]^+ ' ' + tokens^[4]^+ ' ' + tokens^[5]^+ ' ' + tokens^[6]^); end; DisposePPStrings (tokens); end; end. ===== __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 2

Installing GPC on RedHat 7.2
by Preben Mikael Bohn 08 Apr '02

08 Apr '02

Hi all I have tried several times in the past to install GPC on linux with different degrees of success... :) Are there any RPM or binary distibutions for the newest GPC for RedHat 7.2? If not, what version of gcc is the preferred one to use in the compilation step at the time? Currently I have downloaded gcc-core-2.95.2.tar.gz and gpc-20020402.tar.gz from http://www.gnu-pascal.de/current/ I already have the RH7.2 standard gcc installed, and I'd like to install gpc for a user, not root... Best regards Preben Bohn ===== Lack of skill dictates economy of style. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

3 3

forbidden files
by Carel Fellinger 07 Apr '02

07 Apr '02

Quite to my surprise I got a linker error with a module named "files": /usr/lib/gcc-lib/i386-linux/2.95.4/libgpc.a(files.o): In function `init_Files': files.o(.text+0xb28): multiple definition of `init_Files' general/target/files.o(.text+0xea4): first defined here /usr/bin/ld: Warning: size of symbol `init_Files' changed from 99 to 67 in /usr/lib/gcc-lib/i386-linux/2.95.4/libgpc.a(files.o) collect2: ld returned 1 exit status Changing the module name to e.g. "ffiles" get's me around this, bummers that I've to change the name in all imports. What other (module) names are forbidden in my code? And is there any change that a future release will do better then to polute my namespace with module names I didn't (explicitly) import? -- groetjes, carel

2 2

Test
by Peter Gerwinski 05 Apr '02

05 Apr '02

Sorry, but I must fix a problem with the GPC lists. Testing, Peter -- Don Apr 4 12:47:45 MEST 2002

2 1

1/0 0/0
by marcov＠stack.nl 04 Apr '02

04 Apr '02

Something encountered while testing FPC. What is your opinion on this, should this compile? Const inf=1/0; NaN=0/0; minusinf=-1/0;

3 6

Problem with gpc 2.1 RC 3
by Martin Liddle 04 Apr '02

04 Apr '02

I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem: Program WriteTest; Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End; Begin ZWriteln(' '); End. What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug? I also note that trying to set the Capacity of a string schema is now flagged as an error. Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

9 22

Random
by Silvio a Beccara 04 Apr '02

04 Apr '02

Hello, how could I obtain the system random seed? In GPC there doesn't seem to be any randseed variable. Thank you, regards Silvio a Beccara

2 1

Re: Problem with gpc 2.1 RC 3
by da Silva, Joe 04 Apr '02

04 Apr '02

Interesting. However, I wonder if this truncation is valid. Looking at ISO-10206, it states in section <6.4.6 Assignment-compatibility> : "At any place where the rule of assignment-compatibility is used ... c) it shall be an error if T1 and T2 are compatible, T1 is a string-type or the char-type, and the length of the value of T2 is greater than the capacity of T1;" My interpretation of this, is that in this situation, the statement <AString:=AString+'ML'> should have resulted in an error, since the compiler only allocated a capacity of 1 to AString, yet such a concatenation can never fit within this capacity. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, March 18, 2002 8:42 AM > To: gpc(a)gnu.de > Subject: Re: Problem with gpc 2.1 RC 3 > > Prof Abimbola Olowofoyeku wrote: > > > On 17 Mar 2002 at 13:16, Martin Liddle wrote: > > > > > I have just moved to RC 3. Looking at the list of fixed bugs it is > > > obvious that a lot of work has been done in the last few months; > thanks > > > to all concerned. The stricter type checking required a lot of effort > > > to get our code to compile but in fairness did highlight a number of > > > problems in our code; so I think it was time well spent. However I am > > > now stuck because of the following problem: > > > > > > Program WriteTest; > > > > > > Procedure ZWriteln(AString:String); > > > Begin > > > AString:=AString+'ML'; > > > Writeln('String [',AString,'] Length is ',Length(AString)); > > > End; > > > > > > Begin > > > ZWriteln(' '); > > > End. > > > > > > What I see is that length is reported as 1 i.e. the string > concatenation > > > is failing. Is this expected behaviour or a bug? > > > > It is a bug alright. If you pass a string variable rather than a > > literal to 'ZWriteln', the concatentation is successful. So, something > > seems to have gone awry somewhere. > > No, it's not a bug. `AString' is a formal parameter of > undiscriminated schema type. This means it assumes the discriminants > (in case of String: Capacity) of the actual parameter. In the > example, the actual parameter is a string constant of length 1. It > also has capacity 1, since constants can't change, anyway. > > So also the parameter has capacity 1 during the execution of > `ZWriteln'. Assigning ` ML' (the result of concatenation) to a > capacity 1 string results in truncation to ` '. This behaviour is > not new, BTW. > ------ snip ------

5 12

List up again
by Peter Gerwinski 04 Apr '02

04 Apr '02

Hello, this list should be up again now. Peter, making this final test -- Don Apr 4 13:36:04 MEST 2002

1 0

Test
by Peter Gerwinski 04 Apr '02

04 Apr '02

Sorry, but I must fix a problem with the GPC lists. Testing, Peter -- Don Apr 4 12:37:46 MEST 2002

1 0

C applet
by Martin Liddle 04 Apr '02

04 Apr '02

Forwarded as this doesn't seem to have been sent to the list. Alle 20:55, martedÃ¬ 26 marzo 2002, hai scritto: > In article <200203261732.SAA15974(a)science.unitn.it>, Silvio a Beccara > <abeccara(a)science.unitn.it> writes > > >Before I forget: with the C program, I just compiled it very normally, and > > it gave me no error, just the correct results. > > Post a small test program in C showing what you did. Here it is: #include <stdio.h> #include <math.h> int main() { int i; double ris, esp; for(i=1;i<=100;i++) { esp = (double)i * 1000.0; ris = exp(-esp); printf("Exp of %g = %g\n", esp, ris); } } -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

3 2

Re: GPC 2.1 RC 4 on Unixware 7.1
by Theo Carr-Brion 02 Apr '02

02 Apr '02

I think all the failures are all due to these warnings: TEST abso2.pas: UX:as: WARNING: /var/tmp/ccsfhyyl.s:46:name already bound as global: pascal_main_program UX:as: WARNING: /var/tmp/ccsfhyyl.s:50:name already bound as global: init_pascal_main_program OK which is repeated throughout the output. I have found a few more that may be real errors? TEST fjf53a.pas: failed: Foo UX:as: WARNING: /var/tmp/ccKfZDEe.s:24:name already bound as global: pascal_main _program UX:as: WARNING: /var/tmp/ccKfZDEe.s:28:name already bound as global: init_pascal _main_program TEST fjf53b.pas: failed: Foo UX:as: WARNING: /var/tmp/ccsbDjkJ.s:24:name already bound as global: pascal_main _program UX:as: WARNING: /var/tmp/ccsbDjkJ.s:28:name already bound as global: init_pascal _main_program TEST fjf53c.pas: failed: Foo UX:as: WARNING: /var/tmp/ccWp8Wbg.s:24:name already bound as global: pascal_main _program UX:as: WARNING: /var/tmp/ccWp8Wbg.s:28:name already bound as global: init_pascal _main_program TEST nest22.pas: failed: Foo Bar UX:as: WARNING: /var/tmp/cc0s626P.s:24:name already bound as global: pascal_main _program UX:as: WARNING: /var/tmp/cc0s626P.s:28:name already bound as global: init_pascal _main_program TEST nest23.pas: failed: Foo Bar UX:as: WARNING: /var/tmp/cc81wE9r.s:24:name already bound as global: pascal_main _program UX:as: WARNING: /var/tmp/cc81wE9r.s:28:name already bound as global: init_pascal _main_program Theo Carr-Brion -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: 02 April 2002 04:37 To: gpc(a)gnu.de Subject: Re: GPC 2.1 RC 4 on Unixware 7.1 Theo Carr-Brion wrote: > For your information. > > gpc --version > 20020318, based on gcc-2.95.3 20010315 (release) > > Compiling and installation gave no problems. > > Running the tests on unixware 7.1 gives > > # of GPC tests 2616 > # of GPC tests passed 681 > # of GPC tests skipped 5 > # of GPC tests failed 1930 > > However it looks like only 6 tests failed from the output! How can I tell if I don't see the output, especially the parts that look ok? Can you show it (not necessarily everything, for size reasons, but perhaps the first 10 or 20 lines)? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Packing
by Anuradha 02 Apr '02

02 Apr '02

Hello, We are still stuck with the interface to a database. The 2 major problems are : accessing fields of the packed structures .( it gives the below-described errors) and packing sets. Is there no plan for their implementation ? Doesnot all the databases pack the passed structures? Thanks and Regards, Anuradha Anuradha wrote: > Hello, > > We tried compiling a source with gpc-20010924 and made changes to the > records by 'packing' them to suit our needs of reading from already existing > files. > But then we changed to gpc-20011215 (we had also installed earlier) and > these changed programs that compiled in gpc-20010924 , give us errors like : > > " Cannot take address of bitfield <a field name>" > " packed fields may not be used as `var' parameters " > > Can you kindly tell me why this happens because i don't see it as an explicit > change made after the 24-09 version. > > Thanks and Regards, > Anuradha

2 1

GPC 2.1 RC 4 on Unixware 7.1
by Theo Carr-Brion 02 Apr '02

02 Apr '02

For your information. gpc --version 20020318, based on gcc-2.95.3 20010315 (release) Compiling and installation gave no problems. Running the tests on unixware 7.1 gives # of GPC tests 2616 # of GPC tests passed 681 # of GPC tests skipped 5 # of GPC tests failed 1930 However it looks like only 6 tests failed from the output! The following was produced. The other 3 fails are duplicates. TEST aturbo3test.pas: UX:as: WARNING: /var/tmp/ccyREJFc.s:102:name already bound as global: pascal_main_program UX:as: WARNING: /var/tmp/ccyREJFc.s:106:name already bound as global: init_pascal_main_program Undefined first referenced symbol in file getbegx /usr/ccs/lib/libpanel.a(move.o) getbegy /usr/ccs/lib/libpanel.a(move.o) getmaxx /usr/ccs/lib/libpanel.a(move.o) getmaxy /usr/ccs/lib/libpanel.a(move.o) UX:ld: ERROR: a.out: fatal error: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status failed TEST dialec3.pas: UX:as: WARNING: /var/tmp/ccSiB14a.s:1050:name already bound as global: _p_new UX:as: WARNING: /var/tmp/ccSiB14a.s:1051:name already bound as global: _p_dispose UX:as: ERROR: /var/tmp/cc4nnmDk.s:49:too many operands: outw: No such file or directory UX:as: ERROR: /var/tmp/cc4nnmDk.s:65:too many operands: outb UX:as: ERROR: /var/tmp/cc4nnmDk.s:81:too many operands: inw UX:as: ERROR: /var/tmp/cc4nnmDk.s:101:too many operands: inb gpc1: gpc exited with status 1 failed TEST fjf602.pas: UX:as: WARNING: /var/tmp/ccIfVTNM.s:303:name already bound as global: pascal_main_program UX:as: WARNING: /var/tmp/ccIfVTNM.s:381:name already bound as global: init_pascal_main_program failed 1 -100 4.987541511039074e-03 -5.012541823544287e-03 Debugging still crashes so I used -g0 for everything Theo Carr-Brion

2 1

Re: Record alignment
by KOCHERALKOTA harikrishna 01 Apr '02

01 Apr '02

Hello, Is it possible to make the set datatype to occupy only one byte? Now by default the compiler allocates 4 bytes.We even tried packing it,but it's still the same. Have a Great Day! Kind Regards, Karthic and Hari P.S: As specified in one of your mails in the mailing list for a similar problem, we even tried builiding the compiler by changing the P/rts/sets.pas(Tsetelement = byte) and also in P/util.c(set_word_size and set_alignment = 8).Still we are unsuccessful.

3 6

Re: GPC Bug?
by Ernst-Ludwig Bohnen 27 Mar '02

27 Mar '02

On Tue, 26 Mar 2002, Silvio a Beccara wrote: > Hello, > > thank you for your help; under which version have you tried compiling this, > and under which OS? > [pal06] bohnen $ gpc -v Reading specs from /afs/desy.de/user/b/bohnen/.gnu/lib/gcc-lib/i386-suse-linux/2.95.2/specs gpc version 20020304, based on 2.95.2 19991024 (release) [pal06] bohnen $ uname -a Linux pal06 2.4.18 #1 SMP Tue Mar 5 15:27:45 MET 2002 i686 unknown AFAIK any floating point unit can be configured to treat 'out of range' FP-numbers (NaNs) as legal infinity/zero values or as errors. I couldn't find any hint about 'NaN' or 'IEEE' in the gpc - units directory to control this behavior. If there is no user control on that, the current behavior of gpc seems to me the best solution. Otherwise one might run into severe mathematical problems without any notification. Ernst-Ludwig > Regards > > Silvio > > > > Hello, > > I changed your program somewhat: > > > > PROGRAM espa; > > var > > i, j, k : integer; > > esp, res : double; > > > > begin > > writeln (exp(1.0)); ^^^^^^^^^^^^^^^^^^^ this is garbage, I forgot the value of e > > for i := 1 to 50000 do > > begin > > esp := i * 0.1 ; > > res := exp ( -esp ); > > writeln (' Minus the exponential of ', esp :5 :1, ' is ', res ); > > end > > end. > > > > Last lines written are: > > ...... > > Minus the exponential of 744.9 is 4.940656458412465e-324 > > Minus the exponential of 745.0 is 4.940656458412465e-324 > > Minus the exponential of 745.1 is 4.940656458412465e-324 > > espa: error in exponentiation (Numerical result out of range) (error #700 > > at 8049c8a) > > > > This indicates that res runs into undefined range between zero and > > minimum valid value of IEEE double precision numbers. > > Minimum decimal value is approximately +/- 10**(-323). If your > > application allows lower values to be interpreted as zero (0.0) > > you may tell it to gpc, but I don't know how to do that.. > > > > Ernst-Ludwig > > > > On Tue, 26 Mar 2002, Silvio a Beccara wrote: > > > Hello, > > > > > > I tried compiling this simple program, with GPC RC3 (20020304), with GCC > > > 2.95.3 (20010315). > > > > > > > > > program espa; > > > > > > > > > var > > > > > > i, j, k: integer; > > > > > > esp: double; > > > > > > res: double; > > > > > > > > > begin > > > > > > > > > > > > for i := 1 to 50 do begin > > > > > > esp := i * 1000 ; > > > > > > res := exp ( -esp ); > > > > > > writeln (' Minus the exponential of ', esp :1 :0, ' is ', res :1 :15 > > > ); > > > > > > > > > end; > > > > > > > > > end. > > > > > > > > > > > > Surprisingly, and disappointingly, when I run it I get the following > > > result: > > > > > > espa: error in exponentiation (Numerical result out of range) (error #700 > > > at 8049c75) > > > > > > while with any Pascal (like FPC), and C compiler, I get no error (like it > > > should be ). It really looks like a bug. > > > > > > Can anyone help? > > > > > > Thanks, regards > > > > > > Silvio a Beccara >

4 4

Re: GPC Bug?
by Maurice Lombardi 26 Mar '02

26 Mar '02

Silvio a Beccara wrote: > Dear Monsieur Lombardi, > > thank you for your suggestion about the CEPHES library. I used your wrapper > unit, modified for double types, and it works! I do not get that foolish > error any longer. Do you know anything about its speed as compared to native > GPC functions? No way to compare with djgpp. There are no LongReal (long double: 80 bits) math routines there. Even those included in the x87 coprocessor are not declared in math.h nor in libm/math.h, and thus unknown in C (I think) and in gpc (I am sure). If I understand correctly, at least with the option -ffast-math they are used in intermediate calculations in C, which are done in the FP, but the final results are converted to double (real). Anyway after some unconclusive trials with these options when I begun to use gpc, I use CEPHES with a import unit each time I need mathematical accuracy. > > Silvio a Beccara > > ps: are your roots italian? What are roots ? The father of my father was italian, born in france, turned back to italy afterwards, and I still know cousins in Italy (two of them have migrated meanwhile to Spain and USA, and married there). The mother of my father came from corsica, and thus was french to begin with, but migrated to italy afterwards. My father was born in france, and chose the french nationality when doing military service. My mother was french, and I have also cousins round here. The husband of my daughter is malian. And there is presumably a drop of yellow somewhere in the ancestors of my mother. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: GPC 2.1 RC 4 released
by da Silva, Joe 26 Mar '02

26 Mar '02

Thanks, Maurice! Joe. > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Monday, March 25, 2002 11:14 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 4 released > > da Silva, Joe wrote: > > > Don't worry, I'm sure Maurice will have a DJGPP port > > available for us "in due course". <G> > > > I was out of office last week for family problems. > > It is uploaded as usual under the link > > ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip > > > Maurice > > > > -- > Maurice Lombardi > Laboratoire de Spectrometrie Physique, > Universite Joseph Fourier de Grenoble, BP87 > 38402 Saint Martin d'Heres Cedex FRANCE > Tel: 33 (0)4 76 51 47 51 > Fax: 33 (0)4 76 63 54 95 > mailto:Maurice.Lombardi@ujf-grenoble.fr >

1 0

Re: GPC 2.1 RC 4 released
by da Silva, Joe 25 Mar '02

25 Mar '02

Don't worry, I'm sure Maurice will have a DJGPP port available for us "in due course". <G> Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Tuesday, March 19, 2002 6:55 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 4 released > > Frank Heckenbach wrote: > > > > GPC version 20020318, the release candidate #4 for GPC 2.1, has > > been uploaded to > > > > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020318.tar.g > z > > > > Compared to RC 3, this release contains only some minor bug fixes > > and portability enhancements. > > > > One bug in the recent OOP extensions has been fixed (thanks to > > Maurice Lombardi for the report). Some build problems on > > Cygwin/mingw have been resolved (thanks to the Chief). Some minor > > problems on Linux/S390 have been fixed (thanks to Gerhard Tonn and > > Matthias Klose for providing a test account). Some bugs regarding > > types of size 0 have been fixed (thanks to reports by Emil Jerabek). > > The cooperation with GCC patched for Cygwin/mingw, gcc-2.95.3-5, > > gcc-2.95.3-6 and gcc-2.95.4 has been improved. > > Is there a DJGPP build available, and where is it located? I > assume such will be built on gcc 2.953. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > >

2 1

proper extension for interface modules
by Carel Fellinger 24 Mar '02

24 Mar '02

First let me thank all that are involved in creating this Pascal compiler on linux. You are doing a great job! It's mere exsistence and (hopefully:) its quality make it possible for me for the first time to undertake what has been a dream of me for so many years: porting this largish (over thousand prestine source files) 80's project. It went from unix pascal to VAX/VMS Pascal to MetaWare Pascal back on a sun, and now finally to Extended Pascal with gpc. I very much would like to stick to Extended Pascal as close as possible. But (un)fortunately iso10206 doesn't define all, so the first silly problem I have is that of naming the files. What is generally thought of as the proper extension to use for files holding an Extended Pascal Interface Module, and what is the proper extension for files holding the corresponding Implementation Module. Both for the simple case where each module only has one interface exported. And finally, do you deem it wise to use yet another extension to denote a file containig an Extended Pascal Program as opposed to a Module of some sort? -- groetjes, carel

2 7

String slices
by Emil Jerabek 23 Mar '02

23 Mar '02

Hi, it seems that GPC ignores the upper bounds of $SUBJ when they are automatically converted to CString: [pas]% cat slice.pas program Foo (Input, Output); procedure Bar (S: CString); begin {$local X+} WriteLn (S) {$endlocal} end; var S: String (20); begin S := 'failedOKfailed'; Bar (S[7 .. 8]) end. [pas]% gpc slice.pas [pas]% ./a.out OKfailed Emil Jerabek

2 1

Re: Zero-length types (was: Record alignment)
by Emil Jerabek 23 Mar '02

23 Mar '02

CBFalconer wrote: > Emil Jerabek wrote: > > > ... snip ... > > > > Sorry, should think twice before submitting a bugreport. The story with > > "file of record end" is more complicated then I wrote. > > > > The test below should pass for any type (which is permissible as > > a file component-type, of course). It indeed works with, say, > > "file of Integer", but with the empty record type it fails: [...] > > > > I have not checked the standards, but is the problem accepting the > empty record? It seems like a pointless thing to do, leading to > all sorts of problems, such as: > Sure, it is completely pointless, except that it _is_ mandated by the standard. Namely, section 6.4.3.4 (Record-types) of ISO 10206 says: ... record-type = `record' field-list `end' . field-list = [ ( fixed-part [ `;' variant-part ] | variant-part ) [ `;' ] ] . ... A field-list containing neither a fixed-part nor a variant-part shall have no components, shall determine a single value-bearing state bearing a null value, shall be designated empty, and shall denote the totally-undefined initial state. ... > TYPE per = ^emptyrecord; > VAR erarray : ARRAY[1..N] OF emptyrecord; > > ... > new(per); > erarray[i] := erarray[j]; > erarray[i] := per^; > per^ := erarray[i]; > dispose(per); > Well, what's the problem here? All these assignment statements are simply no-ops. > etc. Accepting that has further problems with the design of the > memory allocation mechanism - I have just built one for DJGPP and > had to detect a zero size and increment it, otherwise storage > needed for free block tracking would have been missing. The > ramifications of an empty object go on and on and on and .... > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > Emil Jerabek

2 1

Re: String slices
by Emil Jerabek 22 Mar '02

22 Mar '02

CBFalconer wrote: > Emil Jerabek wrote: > > > > it seems that GPC ignores the upper bounds of $SUBJ when they are > > automatically converted to CString: > > > > [pas]% cat slice.pas > > program Foo (Input, Output); > > > > procedure Bar (S: CString); > > begin > > {$local X+} > > WriteLn (S) > > {$endlocal} > > end; > > > > var > > S: String (20); > > > > begin > > S := 'failedOKfailed'; > > Bar (S[7 .. 8]) > > end. > > [pas]% gpc slice.pas > > [pas]% ./a.out > > OKfailed > > Is this part of any standard? or is it yet another extension? The String slices (and, more generally, array slices) are defined in ISO 10206. CString's (and implicit conversion of String's to CString's) are a GNU extension. Emil Jerabek > way I handled this in PascalP (a 7185 compiler) was with the > extension "dest := array[7 FOR 2]" (which was Doug Fraleys idea, > and may still be in HP Pascal). dest should then be of type > ARRAY[1..2]. The same construct could be used on the dest side, > i.e. "dest[7 FOR 2] := 'OK';" Everything could be checked at > compile time for constant indices and lengths, and run time checks > were no harder than any other index check. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) >

1 0

Berkeley DB
by Carel Fellinger 22 Mar '02

22 Mar '02

Lest I reinvent the wheel, I'd better ask here first:) Has anyone worked on a Gnu Pascal interface module to Berkeley DB? -- groetjes, carel

4 14

EMX ifdefs removed?
by Yuri Prokushev 21 Mar '02

21 Mar '02

Hello! As I see, most of EMX ifdefs removed from gpc.c. Why? Bye.

2 2

Re: Problem with gpc 2.1 RC 3
by Carel Fellinger 19 Mar '02

19 Mar '02

[ Sorry Frank, for sending it to your privat address first ] On Tue, Mar 19, 2002 at 12:50:52AM +0100, Frank Heckenbach wrote: > Carel Fellinger wrote: > > > How can I get more details on that bug? I can't find the file > > daj3.pas on my machine. > > It's part of the GPC source distributions, or the separate test > suite distributions in > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/. Okee, downloading both.. I see a file dajmod3.pas, no daj3.pas, seems like half of the test:) But I get the idea. > > Does this apply to constant strings only, so can you program around it > > by declaring var's and initialize them in the init-code of the > > implementation module? Sure hope so. > > No, it applies to variables declared in a module interface. Did me own test, and it seems that explicitly initializing the var as part of the var declaration can serve as a workaround, like in: module c interface; export c = all; type s = string(25); { comments, -> output } var x : s = 'pipo de clown'; { this seems to work } y : s = ''; { this seems to work } z : s; { this one fails } end. module c implementation; to begin do begin y := 'mama lou'; { this is caried over } z := 'invisible'; { useless } writeln(z.capacity, z, length(z)); {-> 00 } end; end. program b; import c; begin writeln(x.capacity, x, length(x)); {-> 25pipo de clown13 } writeln(y.capacity, y, length(y)); {-> 25mama lou8 } writeln(z.capacity, z, length(z)); {-> 00 } x := 'spam'; y := 'and'; z := 'eggs'; writeln(x.capacity, x, length(x)); {-> 25spam4 } writeln(y.capacity, y, length(y)); {-> 25and3 } writeln(z.capacity, z, length(z)); {-> 00 } end. I sure hope this is inline with your understanding of the bug as I need this feature in that largish 80's program I'm porting. -- groetjes, carel

2 2

Random
by Silvio a Beccara 19 Mar '02

19 Mar '02

Is there a way to obtain the system random seed with GPC? And to initialize it using system's time? Thank you Silvio

2 1

Float to string conversion
by Silvio a Beccara 19 Mar '02

19 Mar '02

Hello, is there a way, similar to Delphi, to convert float or integer values into a string? I mean something like the FLOATTOSTR or FORMATFLOAT function. Thank you, regards Silvio a Beccara

3 2

Download Binaries
by Caruso Aldo 19 Mar '02

19 Mar '02

> Hi, > > I've read that the binaries of the compiler are in the "Binary" > directory. But in the FTP site there's no such directory. > > Thanks for any help. > > Aldo >

2 1

Re: Record alignment
by Anuradha 19 Mar '02

19 Mar '02

Hello, We tried compiling a source with gpc-20010924 and made changes to the records by 'packing' them to suit our needs of reading from already existing files. But then we changed to gpc-20011215 (we had also installed earlier) and these changed programs that compiled in gpc-20010924 , give us errors like : " Cannot take address of bitfield <a field name>" " packed fields may not be used as `var' parameters " Can you kindly tell me why this happens because i don't see it as an explicit change made after the 24-09 version. Thanks and Regards, Anuradha

1 0

GPC 2.1 RC 4 released
by Frank Heckenbach 19 Mar '02

19 Mar '02

Hi everyone, GPC version 20020318, the release candidate #4 for GPC 2.1, has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020318.tar.gz Compared to RC 3, this release contains only some minor bug fixes and portability enhancements. One bug in the recent OOP extensions has been fixed (thanks to Maurice Lombardi for the report). Some build problems on Cygwin/mingw have been resolved (thanks to the Chief). Some minor problems on Linux/S390 have been fixed (thanks to Gerhard Tonn and Matthias Klose for providing a test account). Some bugs regarding types of size 0 have been fixed (thanks to reports by Emil Jerabek). The cooperation with GCC patched for Cygwin/mingw, gcc-2.95.3-5, gcc-2.95.3-6 and gcc-2.95.4 has been improved. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Record alignment
by KOCHERALKOTA harikrishna 19 Mar '02

19 Mar '02

Hello, Is it possible to make the set datatype to occupy only one byte? Now by default the compiler allocates 4 bytes.We even tried packing it,but it's still the same. Have a Great Day! Kind Regards, Karthic and Hari P.S: As specified in one of your mails in the mailing list for a similar problem, we even tried builiding the compiler by changing the P/rts/sets.pas(Tsetelement = byte) and also in P/util.c(set_word_size and set_alignment = 8).Still we are unsuccessful.

1 0

combining Gnu pascal and Fortran 77
by Dusan Fiala 18 Mar '02

18 Mar '02

Hi gpc-subscribers, has anybody experience or has tried to call a module written in GNU pascal from a Fortran 77 routine (run on unix platforms) and is happy to give advice on that? I would be grateful for any advice on whether or not it is (in principle) possible to (i) call modules available in GNU pascal from routines written in Fortran 77 (unix) and (ii) exchange data i.e. program parameters and variables (incl. arrays) between the modules. This bi-directional data exchange is supposed to be performed for every (time) step of a dynamic simulation process. Thanking in anticipation. Best regards Dusan Fiala --------------------------------------------------------------------------- Dr. Dusan Fiala Phone : (+44) 0116 257 7971 Institute of Energy and Sustainable Development De Montfort University, Scraptoft Campus Fax : (+44) 0116 257 7981 Leicester LE7 9SU - United Kingdom e-mail: dfiala(a)dmu.ac.uk ---------------------------------------------------------------------------

2 1

emx_os2 target works
by Yuri Prokushev 18 Mar '02

18 Mar '02

Compiled using pgcc 2.95.3 with emxlibc 0.9d fix 4. Not very fine, but works ;-) # of GPC tests 2602 # of GPC tests passed 2470 # of GPC tests skipped 12 # of GPC tests failed 120

2 1

Dynamic arrays
by Silvio a Beccara 18 Mar '02

18 Mar '02

Hello, is there a way that dynamic arrays can be created (using schemata) which are GLOBAL, i.e. not accessible in the sole main program, but also in all functions and procedures included in it? For instance this little piece of code gives me this error: espon.pas: In procedure `Merce': espon.pas:50: undeclared identifier `Vett' (first use in this routine) espon.pas:50: (Each undeclared identifier is reported only once espon.pas:50: for each routine it appears in.) espon.pas:50: subscripted object is not an array or string the code follows: program skifo; type TVecDob (Size: Integer) = array [ 1 .. Size ] of double; PVecDouble = ^TVecDob; Function Power ( base: real; espon: integer ): double; var i, j: integer; buff: real; begin buff := base; for i :=1 to espon - 1 do begin buff := buff * base; end; result := buff; end; Procedure merce; var i,j: integer; begin for i := 1 to 10 do begin writeln (' vett ', i, '=', vett [i] ); end; end; var nelem, i, j : integer; begin nelem := 10; var vett: TVecDob ( nelem ); for i := 1 to 10 do begin vett [i] := 1+0.1*i; end; merce; end. Thank you very much Silvio

4 6

Re: Again a question on Enumerated datatype
by Anuradha 18 Mar '02

18 Mar '02

Hello , It gives us 264 as size and capacity is 0. we have gpc-20010924.Is it corrected in a newer version? Thanks and Regards, Anuradha. Prof Abimbola Olowofoyeku wrote: > On 18 Mar 2002 at 13:05, Anuradha wrote: > > > Hello , > > > > The following program works in BP but prints blank in GPC. > > Can you tell us why. > > > > program sts; > > type mytype = (a,b,c,d); > > myrec =record > > st:string; > > end; > > var arr : array[mytype] of myrec; > > begin > > arr[d].st :='anu'; > > writeln(arr[d].st); > > end. > > It doesn't print blank here. It prints 'anu'. > > FWIW, there may be a problem with your record. What is the > size/capacity of the string 'st' ? > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.bigfoot.com/~African_Chief > email: African_Chief(a)bigfoot.com

3 3

Fwd: Re: constants in rts/rts.c
by Yuri Prokushev 18 Mar '02

18 Mar '02

==================BEGIN FORWARDED MESSAGE================== >From: "Yuri Prokushev" <prokushev(a)freemail.ru> >To: "Frank Heckenbach" <frank(a)g-n-u.de> >Date: Mon, 18 Mar 2002 11:10:59 -0500 (EST) >Reply-To: "Yuri Prokushev" <prokushev(a)freemail.ru> >Priority: Normal >X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 >In-Reply-To: <200203172125.WAA10698(a)goedel.fjf.gnu.de> >MIME-Version: 1.0 >Content-Type: text/plain; charset="koi8-r" >Content-Transfer-Encoding: 7bit >Subject: Re: constants in rts/rts.c > On Sun, 17 Mar 2002 22:25:07 +0100, Frank Heckenbach wrote: >Yuri Prokushev wrote: > >> Where defined F_* constants for rts.c? >> >These should be defined in <sys/stat.h> or some other system header. > >> rts.c: In function `_p_FlushHandle': >> rts.c:1682: warning: implicit declaration of function `fsync' > >This code is enclosed in `#ifdef HAVE_FSYNC'. Similar for other >functions (and the F_* constants which are in `#ifdef HAVE_FCNTL'). > >Since HAVE_FSYNC is set (by configure, unless you changed this >manually), I assume your system does in fact have these functions, >but it's missing the declarations in the headers (as for the S_* >constants). > >This is for EMX, is it? Well, I haven't used EMX myself so I don't >know what its headers look like. Perhaps you just have to include >some more header (if I know which one, I can do it automatically in >the future, but you can try adding #include statements in rts.c >manually). Yes. This is for emx. sys/stat.h contains all required definitions, but seem to be incorrect include path (/usr/local/... instead c:/emx/include). I don't understand yet how to fix it. But fcntl.h doesn't contain file lock definetions. fcntl.h from posix/2 lib seems to be more fine. >Is anyone on this lists who's used EMX recently? I haven't heard >much of it for some years ... Latest emx+gcc is 0.9d fix 4 (dated 20 march 2001). But in emx+gcc old gcc 2.8.1. Now presented pgcc-2.95.3 (I trying compile gpc with it), and GNU CC 3.0.x. This compilers patched and compiled by Andrew Zabolotny. So, now used emxlibc and gcc from AZ. Now developing libext (also known as libemu or posix/2) wich seems to be successor of emxlib. ===================END FORWARDED MESSAGE===================

2 1

Re: Again a question on Enumerated datatype
by Anuradha 18 Mar '02

18 Mar '02

Hello, Thankyou.It is working fine in 20011215.Sorry for the trouble. Regards, Anuradha Prof Abimbola Olowofoyeku wrote: > On 18 Mar 2002 at 13:42, Anuradha wrote: > > > Hello , > > > > It gives us 264 as size and capacity is 0. > > Hmmm ... the capacity (AFAIK) should not be 0. I thought GPC defaults > to a capacity of 255 when no capacity is supplied? > > > we have gpc-20010924.Is it corrected in a newer version? > > Apparently. But I think you need to correct it in your code. It is not > a good idea to declare a string field in a record without specifying > the size/capacity of the string. Basically, it means that you are > leaving it to someone else (e.g., the compiler) to determine the size > of your record - and it may decide on a size that is different from the > one you would like (as seems to have beem done here). > > Something like this would be a better solution, should work with all > compilers, and should solve your specific problem; > > type myrec = record > st : string [128]; > end; > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.bigfoot.com/~African_Chief > email: African_Chief(a)bigfoot.com

1 0

Again a question on Enumerated datatype
by Anuradha 18 Mar '02

18 Mar '02

Hello , The following program works in BP but prints blank in GPC. Can you tell us why. program sts; type mytype = (a,b,c,d); myrec =record st:string; end; var arr : array[mytype] of myrec; begin arr[d].st :='anu'; writeln(arr[d].st); end. Thanks and Regards, Anuradha

2 1

constants in rts/rts.c
by Yuri Prokushev 17 Mar '02

17 Mar '02

Where defined F_* constants for rts.c? ../.././xgcc -B/usr/local/i386-pc-os2_emx/bin/ -B../.././ -I/usr/local/i386-pc-os2_emx/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /gpc/pgcc-2.95.3/gcc/p/rts/rts-version`'" rts.c rts.c: In function `_p_Real_Ln1Plus': rts.c:717: warning: unused parameter `x' rts.c: In function `_p_Mode2SysMode': rts.c:1566: `S_IRUSR' undeclared (first use in this function) rts.c:1566: (Each undeclared identifier is reported only once rts.c:1566: for each function it appears in.) rts.c:1566: `S_IWUSR' undeclared (first use in this function) rts.c:1566: `S_IXUSR' undeclared (first use in this function) rts.c:1567: warning: control reaches end of non-void function rts.c: In function `_p_SysMode2Mode': rts.c:1571: `S_IRUSR' undeclared (first use in this function) rts.c:1571: `S_IWUSR' undeclared (first use in this function) rts.c:1571: `S_IXUSR' undeclared (first use in this function) rts.c:1572: warning: control reaches end of non-void function rts.c: In function `_p_Stat': rts.c:1610: storage size of `st' isn't known rts.c:1614: warning: implicit declaration of function `stat' rts.c:1635: warning: implicit declaration of function `S_ISDIR' rts.c:1610: warning: unused variable `st' rts.c: In function `_p_FlushHandle': rts.c:1682: warning: implicit declaration of function `fsync' rts.c: In function `_p_CStringChMod': rts.c:1757: warning: implicit declaration of function `chmod' rts.c: In function `_p_TruncateHandle': rts.c:1841: warning: implicit declaration of function `ftruncate' rts.c: In function `_p_LockHandle': rts.c:1855: storage size of `Lock' isn't known rts.c:1858: `F_WRLCK' undeclared (first use in this function) rts.c:1858: `F_RDLCK' undeclared (first use in this function) rts.c:1861: `F_SETLKW' undeclared (first use in this function) rts.c:1861: `F_SETLK' undeclared (first use in this function) rts.c:1855: warning: unused variable `Lock' rts.c: In function `_p_UnlockHandle': rts.c:1876: storage size of `Lock' isn't known rts.c:1879: `F_UNLCK' undeclared (first use in this function) rts.c:1882: `F_SETLK' undeclared (first use in this function) rts.c:1876: warning: unused variable `Lock' make[1]: *** [rts.o] Error 1 make[1]: Leaving directory `/gpc/pgcc-2.95.3/gcc/p/rts' make: *** [pascal.rts] Error 2

2 1

OS/2 EMX
by Yuri Prokushev 17 Mar '02

17 Mar '02

Hello. Currently GPC not builded for EMX (only old version). Will be new version for EMX (latest gcc/emx is 3.0.2)? Bye.

1 0

Re: Zero-length types (was: Record alignment)
by da Silva, Joe 13 Mar '02

13 Mar '02

With 20011222 (djgpp), the "set of void" example produces a similar result, except the internal error is not a "fatal signal 11", but rather, an "Internal compiler error in 'layout_type', at stor-layout.c:1055". The "array of void", "packed array of void" and "array of empty record" examples are OK with 20011222 - no errors or crashes, either at compile or run times. I wasn't brave enough to play around with the "file type" example, though. <g> Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, March 13, 2002 11:54 PM > To: gpc > Subject: Zero-length types (was: Record alignment) > > > Hello, > > Is it possible to make the set datatype to occupy only one byte? Now > > by default the compiler allocates 4 bytes.We even tried packing it,but > > it's still the same. > > After reading this message, I tried to experiment with set types > a little bit. It turned out that the compiler segfaults on "set of Void" > (this is a nonsense type, but anyway...) > > [pas]% gpc -v ; uname -a > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 20020308, based on 2.95.2 19991024 (release) > Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 > unknown > [pas]% cat voidset.pas > program VoidSet (Output); > > type > T = set of Void; (* WRONG *) > > begin > WriteLn ('failed') > end. > [pas]% gpc voidset.pas > voidset.pas:4: ordinal type expected > gpc: Internal compiler error: program gpc1 got fatal signal 11 > (Segmentation fault) > [pas]% gdb /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 core > GNU gdb 5.0rh-5 Red Hat Linux 7.1 > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-redhat-linux"... > Core was generated by > `/usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 /tmp/ccSEiSIV.i > -quiet -du'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > #0 0x0816d399 in layout_type (type=0x8274028) > at ../../../gcc-2.95.2/gcc/p/../stor-layout.c:1053 > 1053 ../../../gcc-2.95.2/gcc/p/../stor-layout.c: No such file or > directory. > in ../../../gcc-2.95.2/gcc/p/../stor-layout.c > (gdb) bt > #0 0x0816d399 in layout_type (type=0x8274028) > at ../../../gcc-2.95.2/gcc/p/../stor-layout.c:1053 > #1 0x081b2159 in build_set_type (members=0x8274014) > at ../../../gcc-2.95.2/gcc/p/types.c:579 > #2 0x081a358f in yyparse () at parse.y:2043 > #3 0x0816fae1 in compile_file (name=0xbffffb84 "/tmp/ccSEiSIV.i") > at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 > #4 0x08172dca in main (argc=8, argv=0xbffffa1c) > at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 > #5 0x40041e5e in __libc_start_main (main=0x8171e14 <main>, argc=8, > ubp_av=0xbffffa1c, init=0x80490f8 <_init>, fini=0x81ba7a0 <_fini>, > rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffa0c) > at ../sysdeps/generic/libc-start.c:129 > > > GPC accepts "array of Void" (and even static variables of that type; > should it?), but it crashes on "packed array of Void". More importantly, > it crashes the same way on the following ISO 7185 code: > > [pas]% cat recordend1.pas > program Foo (Output); > > type > T = packed array [1 .. 42] of record end; > > begin > WriteLn ('OK') > end. > [pas]% gpc recordend1.pas > recordend1.pas:4: Internal compiler error in `float_signal', at > toplev.c:2418 > Please submit a full bug report. > See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for > instructions. > > > A similar file-type generates a run-time error: > > [pas]% cat recordend2.pas > program Foo (Output); > > type > EmptyType = record end; > > var > F: file of EmptyType; > > begin > rewrite (F); > { F^ := EmptyType[]; } > put (F); > reset (F); > get (F); > writeln ('OK') > end. > [pas]% gpc recordend2.pas > [pas]% ./a.out > ./a.out: internal error: `InitFDR' has not been called for file (error > #913 at 8049c05) > > > Emil Jerabek

1 0

Bug in gpc-20020304 ?
by Maurice Lombardi 11 Mar '02

11 Mar '02

Hi all I have compiled gpc-20020304 with djgpp I found a (new ?) bug given by the following simple program: ---------------------------------------------------------------- program TestSize; type tR = object constructor init; function Size: integer; virtual; destructor fini; end; constructor tR.init; begin end; function tR.Size: integer; begin Size := 1 end; destructor tR.fini; begin end; begin end. --------------------------------------------------------------- Compilation fails with the message: TestSize.pas:7: duplicate field `Size' TestSize.pas:7: excess elements in record initializer after `vmt_Tr' "Virtual" is essential. Has Size become an hidden identifier (size of the vmt ?) Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 2

GPC 2.1 RC 3 released
by Frank Heckenbach 08 Mar '02

08 Mar '02

Hi everyone, I sent this announcement to gpc-announce(a)gnu.de on Monday, but it still hasn't appeared here. So apparently that list or its moderator is dead or something, or they've stopped forwarding gpc-announce to this list. (If the latter is not the case, you'll get the announcement again -- if this bothers you, please complain to the list owner, not me. ;-) As some of you have found out yourselves by now, GPC version 20020304, the release candidate #3 for GPC 2.1, has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020304.tar.gz (CVS is not available currently.) Due to a relatively large number of bug reports and discussions on the mailing list in the last several weeks, there have been many changes since RC 2. Some internal problems which led to compiler crashes (especially with `-O3' and/or `-g', and often hard to reproduce) have been resolved (thanks to J. Booij, Matthias Klose and others for reports). I hope that GPC will now crash noticeably less often than it did before. ;-) However, it is (still) a known problem that `-g' (debug info) does not work perfectly, and fails completely on some platforms (such as IRIX/MIPS). A number of other problems have been solved. Some of the most important ones are described below. For a more detailed listing, please refer to the `Fixed bugs' section of the To-Do list. First and foremost, the type checking has become much stricter. This might cause GPC to find some "new" bugs in your programs, but I suppose they often will turn out to be real bugs in the Pascal code which just were not detected before (as was the case with some bugs that appeared in my own Pascal code). E.g., two records which are declared separately with identically looking declarations are not compatible in Pascal, but GPC used to accept them as compatible. The automake and GPI file mechanisms have been changed (and hopefully improved) significantly (thanks to the Chief for some bugs reports). Since I can't test them in every conceivable way, please check if they (still) work for you. Many things related to schema types have been changed (only for the better I hope). Various other bugs have been fixed, e.g., the long-standing problem that initializers of arrays of length 1 didn't work and that the import and export of huge interfaces was very slow (quadratic time behaviour). Some complex number routines have been improved numerically, thanks to Emil Jerabek and Joe da Silva. The manual is now available (partly) in a Croatian translation, thanks to Mirsad Todorovac. A new feature is the `FormatString' function (a main use of which will be for internationalization support, together with Eike Lange's Intl unit). Many of the planned features are still missing, but it should be sufficient already for many ordinary purposes. Some things have been added in the object-orientation support. In particular, abstract objects and methods work fully now (they were only partially supported in previous versions), the `is' and `as' operators have been implemented, and `TypeOf' does not return an untyped pointer anymore, but a pointer of type `PObjectType' pointing to the object type record (a.k.a. VMT) which currently contains the fields `Size', `NegSize', `Parent' and `Name'. Due to some changes in GPC, some problems with debug info in the COFF output format (which only DJGPP still uses, as far as I know) may now appear more often than they did before. The problems arise when the same identifier is used in different units (even with different asmnames), or for a global variable and a local function (see test/fjf500.pas for further notes and an example). (The problems themselves are not now, and seem to be inherent in the COFF format, so only a switch of DJGPP to ELF would be a real solution, and it's uncertain if this will ever happen. However, when GPC will support qualified identifers, chances are that this will make one or both of the problems disappear.) If you are affected by this problem under DJGPP (error messages: `Fatal error: C_EFCN symbol out of scope', or duplicate definitions at link time even though asmnames are different), you might have to rename one of the offending identifiers, or compile without debug info. I've tested GPC on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them. I'll be out of town over the weekend, so I can't look into any new bugs until Monday ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 2

Re: Record alignment
by Anuradha 08 Mar '02

08 Mar '02

Hello, We attempted reading them bit by bit . We attempted giving 'packed' before records. We attempted giving --pack-struct . The last gave compilation errors and the first and the second are not all that simple to incorporate in the code because there are many types with records within records within records within records... Is there no way out other than to (vastly) change the code? BTW, Is implementation of the alignment-size-indication($Z) planned? Thanks for the support , Regards, Anuradha Frank Heckenbach wrote: > Anuradha wrote: > > > Hello, > > > > Sorry for the last mail.We are resending it. > > ================================ > > We have a problem as follows. > > We have a database file tabinfo.mdb created under WINDOWS using > > pervasive SQL(Btrieve).Now > > we are trying to access it with GPC. > > We fear that there is some allignment problem in the records stored > > and the record passed to read data > > out. > > The record we used to create the tabinfo in windows is : > > > > MDB_MLTABL_TYPE = RECORD > > MLTABLNM : CHAR_8 ; > > RID : word ; > > LENPHYS : word ; > > PHYSINF : PH_ADDR ; > > EDITION : BYTE ; > > DATALEV : FS_FILE_TYPE ; > > MLTABDES : PH_ADDR ; > > ATTCOUNT : BYTE ; > > ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] > > OF MDB_ATTR_INFO_TYPE ; > > RELFILES : ARRAY [ 1..MAX_RELFILES ] > > OF MDB_REL_FILE_TYPE ; > > END ; > > > > We use the same record structure to read data back from it (but in > > GPC).But it doesnot read properly. > > Can you tell us why this happens? > > BTW, fs_file_type is a Enumerated type . > > ph_addr is longint. > > (We have given > > longint=int32 > > word=word16 in our program). > > First of all, declare the record and the sub-arrays and sub-records > (if any; I don't know what MDB_ATTR_INFO_TYPE etc. is) as `packed' > (and be aware of the inefficiencies involved -- the first field > seems to a a single byte, so the following fields will be at odd > addresses which is clearly less efficient on IA32 and much less > efficient on RISCs; I guess you don't have much choice here, but if > you do serious processing, you might want to copy the data in/out of > the packed structure). > > Then check the sizes of each field, using `SizeOf', and use > `Integer (n)' or `Cardinal(n)' in GPC for a type of size n bits. > > For the enum field, you'll probably have to use `Cardinal(8)' (if > the other compiler makes it 8 bits big), since otherwise GPC would > pack it as small as possible (e.g., 4 bits if it has 9 .. 16 > values). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Re: Record alignment
by KOCHERALKOTA harikrishna 08 Mar '02

08 Mar '02

Hello, Thank you for the advice and it worked fine for enum type. We have many recordS and other structures and we have created a big database using these structures using BP. We have now problems in accesing this database, as lot of misalignments are resulting as we move from BP to GPC. we have problem in declaring all the records and arrays as 'PACKED' , Bcoz they are countless in number. Instead we used '--pack-struct' option. But this is resulting in an compilation error "Cannot take address of bit feild". Could you advise us on this . Thanks and Regards hari Frank Heckenbach wrote: > KOCHERALKOTA harikrishna wrote: > > > How can we set size of enumerated data type in GPC?. > > That's not possible currently. Your best bet probably is using an > integer type, e.g. `Cardinal (n)' (where n is the desired size in > bits), and declaring the enum values as constants (starting from 0). > > > Because in GPC, even if > > we give 2 values (0..1) also, it assigns 4 bytes by default. > > Yes (for alignment and efficiency reasons), and 1 bit in a packed > record/array. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Record alignment
by KOCHERALKOTA harikrishna 06 Mar '02

06 Mar '02

Hello, Good Morning! As you said , by default Enum type is 8-bit in BP.The Enumsize can be controlled by compiler directive {$Z} in Delphi. {$Z1} or {$Z2} or {$Z4} {$MINENUMSIZE 1} or {$MINENUMSIZE 2} or {$MINENUMSIZE 4} Default {$Z1} {$MINENUMSIZE 1} The $Z directive controls the minimum storage size of enumerated types. An enumerated type is stored as an unsigned byte if the enumeration has no more than 256 values, and if the type was declared in the {$Z1} state (the default). If an enumerated type has more than 256 values, or if the type was declared in the {$Z2} state, it is stored as an unsigned word. Finally, if an enumerated type is declared in the {$Z4} state, it is stored as an unsigned double-word. The {$Z2} and {$Z4} states are useful for interfacing with C and C++ libraries, which usually represent enumerated types as words or double-words. Note: For backwards compatibility with earlier versions of Delphi and Borland Pascal, the directives {$Z-} and {$Z+} are also supported. They correspond to {$Z1} and {$Z4}, respectively. How can we set size of enumerated data type in GPC?.Because in GPC, even if we give 2 values (0..1) also, it assigns 4 bytes by default. Have a Nice Day! Thanking You, Kind Regards, Karthic and Hari Frank Heckenbach wrote: > Anuradha wrote: > > > Hello, > > > > Sorry for the last mail.We are resending it. > > ================================ > > We have a problem as follows. > > We have a database file tabinfo.mdb created under WINDOWS using > > pervasive SQL(Btrieve).Now > > we are trying to access it with GPC. > > We fear that there is some allignment problem in the records stored > > and the record passed to read data > > out. > > The record we used to create the tabinfo in windows is : > > > > MDB_MLTABL_TYPE = RECORD > > MLTABLNM : CHAR_8 ; > > RID : word ; > > LENPHYS : word ; > > PHYSINF : PH_ADDR ; > > EDITION : BYTE ; > > DATALEV : FS_FILE_TYPE ; > > MLTABDES : PH_ADDR ; > > ATTCOUNT : BYTE ; > > ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] > > OF MDB_ATTR_INFO_TYPE ; > > RELFILES : ARRAY [ 1..MAX_RELFILES ] > > OF MDB_REL_FILE_TYPE ; > > END ; > > > > We use the same record structure to read data back from it (but in > > GPC).But it doesnot read properly. > > Can you tell us why this happens? > > BTW, fs_file_type is a Enumerated type . > > ph_addr is longint. > > (We have given > > longint=int32 > > word=word16 in our program). > > First of all, declare the record and the sub-arrays and sub-records > (if any; I don't know what MDB_ATTR_INFO_TYPE etc. is) as `packed' > (and be aware of the inefficiencies involved -- the first field > seems to a a single byte, so the following fields will be at odd > addresses which is clearly less efficient on IA32 and much less > efficient on RISCs; I guess you don't have much choice here, but if > you do serious processing, you might want to copy the data in/out of > the packed structure). > > Then check the sizes of each field, using `SizeOf', and use > `Integer (n)' or `Cardinal(n)' in GPC for a type of size n bits. > > For the enum field, you'll probably have to use `Cardinal(8)' (if > the other compiler makes it 8 bits big), since otherwise GPC would > pack it as small as possible (e.g., 4 bits if it has 9 .. 16 > values). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

zero function
by Michael Underwood 06 Mar '02

06 Mar '02

In the past I have been a Compaq VAX Pascal user. One useful feature was the ZERO function. Does GPC have an equivalent? Regards Michael Underwood Systems Analyst Consulting Division Hydro Tasmania Ph: (03) 6230 5494 This message and any attachments may contain confidential or privileged information, and are intended solely for the named recipient(s). If you are not a named recipient of this message, you are hereby notified that you must not use, disseminate, copy or take any action in reliance on this message or any part of it. If you have received this message in error, please notify the author immediately via mailto:michael.underwood@hydro.com.au <mailto:michael.underwood@hydro.com.au> NB: Unless otherwise specified, opinions and personal views expressed herein are purely those of the author and do not represent the views of Hydro Tasmania.

2 1

Re. Record alignment
by Anuradha 06 Mar '02

06 Mar '02

Hello, How can we set size of enumerated data type in GPC? thnaks and regards Anu -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

1 0

Re: Record alignment
by Anuradha 01 Mar '02

01 Mar '02

Hello, Sorry for the last mail.We are resending it. ================================ We have a problem as follows. We have a database file tabinfo.mdb created under WINDOWS using pervasive SQL(Btrieve).Now we are trying to access it with GPC. We fear that there is some allignment problem in the records stored and the record passed to read data out. The record we used to create the tabinfo in windows is : MDB_MLTABL_TYPE = RECORD MLTABLNM : CHAR_8 ; RID : word ; LENPHYS : word ; PHYSINF : PH_ADDR ; EDITION : BYTE ; DATALEV : FS_FILE_TYPE ; MLTABDES : PH_ADDR ; ATTCOUNT : BYTE ; ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] OF MDB_ATTR_INFO_TYPE ; RELFILES : ARRAY [ 1..MAX_RELFILES ] OF MDB_REL_FILE_TYPE ; END ; We use the same record structure to read data back from it (but in GPC).But it doesnot read properly. Can you tell us why this happens? BTW, fs_file_type is a Enumerated type . ph_addr is longint. (We have given longint=int32 word=word16 in our program). thanks and Regards Hari & Anu

2 1

Record alignment
by KOCHERALKOTA harikrishna 01 Mar '02

01 Mar '02

2 1

Re: Problems with pexecutedemo.pas
by da Silva, Joe 28 Feb '02

28 Feb '02

Compiles fine for me, with DJGPP GPC 20011222 (gpc --automake pexecutedemo.pas). However, AFAIK, you must install the GCC compiler too, so I assume that's what your problem is. Joe. > -----Original Message----- > From: Preben Mikael Bohn [SMTP:preben_bohn@yahoo.com] > Sent: Thursday, February 28, 2002 8:11 PM > To: gpc(a)gnu.de > Subject: Problems with pexecutedemo.pas > > Hi all > > I just tried to compile pexecutedemo.pas from > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/pexecutedemo.pas > with my installation of GNU Pascal, however I get the following > error: > > [beh@musvit test]$ gpc PExecuteDemo.p --automake > <command line>: warning: "system" re-asserted > <command line>: warning: "cpu" re-asserted > <command line>: warning: "machine" re-asserted > cpp: -lang-c: linker input file unused since linking not done > gpc: installation problem, cannot exec `cc1': No such file or > directory > gpc1: gpc exited with status 1 > gpc1: gpc exited with status 1 > > I use version 20011222 of gpc, and I have installed it locally > (i.e. on my own user account) without installing the C-compiler... > > Other (simple) programs seems to work fine, but I havn't testet > that many... Any ideas what is going wrong? > > Best regards > > Preben Bohn > > ===== > Denne signature er et fuldstændigt spild af tre a'er, > tre b'er, seks d'er, syvogfyrre e'er, otte f'er, seks g'er, > to h'er, otte i'er, fire k'er, fire l'er, tre m'er, > syv n'er, ti o'er, tre p'er, femogtredive r'er, tolv s'er, > tyve t'er, tre u'er, seks v'er, fem y'er og to æ'er > - Preben Bohn > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com

1 0

Problems with pexecutedemo.pas
by Preben Mikael Bohn 28 Feb '02

28 Feb '02

Hi all I just tried to compile pexecutedemo.pas from http://agnes.dida.physik.uni-essen.de/~gnu-pascal/pexecutedemo.pas with my installation of GNU Pascal, however I get the following error: [beh@musvit test]$ gpc PExecuteDemo.p --automake <command line>: warning: "system" re-asserted <command line>: warning: "cpu" re-asserted <command line>: warning: "machine" re-asserted cpp: -lang-c: linker input file unused since linking not done gpc: installation problem, cannot exec `cc1': No such file or directory gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 I use version 20011222 of gpc, and I have installed it locally (i.e. on my own user account) without installing the C-compiler... Other (simple) programs seems to work fine, but I havn't testet that many... Any ideas what is going wrong? Best regards Preben Bohn ===== Denne signature er et fuldstÃ¦ndigt spild af tre a'er, tre b'er, seks d'er, syvogfyrre e'er, otte f'er, seks g'er, to h'er, otte i'er, fire k'er, fire l'er, tre m'er, syv n'er, ti o'er, tre p'er, femogtredive r'er, tolv s'er, tyve t'er, tre u'er, seks v'er, fem y'er og to Ã¦'er - Preben Bohn __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

1 0

Re: gcc3+gpc working yet?
by da Silva, Joe 25 Feb '02

25 Feb '02

Just out of curiousity, how does one interpret that strange URL you have given? All it does for me is produce a "Host not found" error. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 25, 2002 1:32 PM > To: gpc(a)gnu.de > Subject: Re: gcc3+gpc working yet? > > da Silva, Joe wrote: > > > > From: Matthias Klose [SMTP:doko@cs.tu-berlin.de] > > > > > > and will probably get some serious priority, after gpc-2.1 is > released. > > > > > > did you volunteer working on it? > > > > No, this is just from the recent discussions about gcc-3 compatibility > > on this list (eg., Frank's posting of Fri 15/02/02 17:47). > > Perhaps I wasn't clear: I am *not* going to do the bulk of the work. > Though I see some advantages in advancing to gcc-3, there are many > more important issues for me to work on. The same probably applies > to Peter -- except for the really difficult parts (which he'll > probably have to do since he's the only one who can do them). > > So whether and when it gets some "serious priority" depends to a > large extend on whether/when someone else will volunteer to help. > > > Unfortunately, my expertise in GPC's inner workings and compilers > > in general is very poor, as I have mentioned on a previous occasion. > > I hope some day this will improve. > > Perhaps this is a good chance to improve it. Most of the jobs I've > described in <200202150646.HAA04772@@goedel.fjf.gnu.de> don't > require knowledge of the internals, and in fact one might get some > knowledge while doing them (provided, of course, one is not allergic > to seeing some C code ;-). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: gcc3+gpc working yet?
by da Silva, Joe 25 Feb '02

25 Feb '02

No, this is just from the recent discussions about gcc-3 compatibility on this list (eg., Frank's posting of Fri 15/02/02 17:47). Unfortunately, my expertise in GPC's inner workings and compilers in general is very poor, as I have mentioned on a previous occasion. I hope some day this will improve. Joe. > -----Original Message----- > From: Matthias Klose [SMTP:doko@cs.tu-berlin.de] > Sent: Friday, February 22, 2002 9:55 AM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: gcc3+gpc working yet? > > da Silva, Joe writes: > > Believe it or not, the many recent messages with "gcc-3+" in their > > title, started with a discussion of gcc3 compatibility issues, including > > the "current state of affairs", so this is certainly being looked into > > and will probably get some serious priority, after gpc-2.1 is released. > > did you volunteer working on it?

2 1

GNU Pascal and Borland Pascal
by Tim Ledgerwood 24 Feb '02

24 Feb '02

Hi Anybody still working on this? I am a windows developer, using Borland Delphi to develop a project. I have a code snippet that looks like it was developed in GNP - I need to convert it to run under Borland Pascal. The coding is for a static huffmann compression routine - and I can find such coding nowehere else on the web - lots of dynamic encoding, but no static ... PS - the links to the GNP Compiler and Docs are broken. Anyway, thanks Tim Ledgerwood tim(a)stowe.co.za

2 1

Re: gcc3+gpc working yet?
by da Silva, Joe 21 Feb '02

21 Feb '02

Believe it or not, the many recent messages with "gcc-3+" in their title, started with a discussion of gcc3 compatibility issues, including the "current state of affairs", so this is certainly being looked into and will probably get some serious priority, after gpc-2.1 is released. Joe. > -----Original Message----- > From: strobe anarkhos [SMTP:anarkhos@mac.com] > Sent: Thursday, February 21, 2002 9:26 AM > To: gpc(a)gnu.de > Subject: gcc3+gpc working yet? > > Has anybody tried to hammer gpc into gcc3? > > Apple is planning to move to gcc3 and cease support for 2.95x. They have > already dumped a huge load of patches in the Darwin CVS to make everything > gcc3 friendly and have cleaned up stuff like ObjC, ObjC++, gpj, g77, etc. > This will be a relief since 2.95x was a huge hack job of various parts > (NeXT's cc, gcc 2.7, MPW, etc.) and hopefully this will clean out a lot of > the rot. Unfortunately gpc isn't compatible with gcc3. > > Mac OS X is the perfect Pascal platform: > > * One of the two major APIs has Pascal interfaces, specifically Carbon. > Even though the library is likely written entirely in C, all the functions > are extern pascal and the strings are pascal strings. > > * Project Builder, a free graphical IDE, could be modified for Pascal. > Project Builder uses programs like jam (which in tern uses compilers like > gcc and javac) and gdb, parsing their output so if you click on an error, > it highlights the error in the source file. It also combines all the > resources to make executable graphical bundles. > > * Interface Builder was modified by Apple to support Carbon apps and so > should also work with Pascal Carbon development. Interface Builder is a > graphical app which allows developers to edit the layout of controls, > views, menus, windows, menus, panels, etc. A Carbon app then only has to > make simple calls to the abstract utility library. If you wish I can show > some example C code. > > Think of the possibilities |-)

2 1

Re: pointers (was: gcc-3+)
by da Silva, Joe 21 Feb '02

21 Feb '02

Yeah, "stored" and "referenced" seem okay. Other possibility is "master" and "slave". Anyway, as they say : "We'll cross that bridge when we come to it." (ie. I guess there's no need to worry about these details unless this concept looks like going ahead). Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Wednesday, February 20, 2002 11:31 PM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: pointers (was: gcc-3+) > > Hi folks, > > da Silva, Joe wrote: > > 1. I wonder if the words "store" and "reference" are complementary? > > Is complementarity a demand here? Clear distinction's sufficient, I > think... > > > How about "primary" and "secondary" instead? Or something else? > > This is subjective, but I'm not sure if the word "store" would "read" > > very well in the following suggested syntax (looks too much like a > > verb;-) : > > Agreed, but IMO "primary" and "secondary" are too general words to really > describe the use of the pointers. What about "stored" and "referenced"? > > type > pointer = ^integer; > pointer2 = stored ^integer; > pointer3 = referenced ^integer; > > Cheers > > Markus

1 0

Re: gcc-3+ (PS)
by da Silva, Joe 21 Feb '02

21 Feb '02

On reflection, perhaps I haven't been clear enough about this issue. To elaborate, some examples : a) procedure a (p : store pointer); --- wrong. b) procedure b (var p: store pointer); --- right. c) procedure c (p : reference pointer); --- right. d) procedure d (var p: reference pointer); --- right. e) c (a_store_pointer); --- right (assuming type compatibility). This all follows from the rules previously defined about the properties/restrictions of having distinct "store" and "reference" pointers. Hope that clears things up. Joe. > -----Original Message----- > From: da Silva, Joe > Sent: Thursday, February 21, 2002 3:48 PM > To: 'gpc(a)gnu.de' > Subject: RE: gcc-3+ > > OK then, Frank is wrong. <G> > > Given the rules applying to "store" pointers, they can be passed as > "var" parameters only. There is precedent for this type of restriction, > ie. file variables. > > Joe. > > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, February 21, 2002 2:29 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > da Silva, Joe wrote: > > > Frank is right. Just like you can't have "file" value parameters, > you > > also can't have "store pointer" value parameters, only var > parameters. > > That's not what I said! I said that it's not uncommon to pass a > directly allocated (i.e., "store") pointer by value, so I'm not > convinced of the distinction between store and reference pointers. I > wrote: > > : Though I'm not sure why the distinction between store and > reference > : pointers is necessary. Why not make all pointers the same, and > when > : one pointer to an object is disposed of, all the other ones are > : invalidated? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: gcc-3+
by da Silva, Joe 21 Feb '02

21 Feb '02

OK then, Frank is wrong. <G> Given the rules applying to "store" pointers, they can be passed as "var" parameters only. There is precedent for this type of restriction, ie. file variables. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, February 21, 2002 2:29 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > da Silva, Joe wrote: > > > Frank is right. Just like you can't have "file" value parameters, you > > also can't have "store pointer" value parameters, only var parameters. > > That's not what I said! I said that it's not uncommon to pass a > directly allocated (i.e., "store") pointer by value, so I'm not > convinced of the distinction between store and reference pointers. I > wrote: > > : Though I'm not sure why the distinction between store and reference > : pointers is necessary. Why not make all pointers the same, and when > : one pointer to an object is disposed of, all the other ones are > : invalidated? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: gcc-3+
by da Silva, Joe 21 Feb '02

21 Feb '02

Frank is right. Just like you can't have "file" value parameters, you also can't have "store pointer" value parameters, only var parameters. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, February 21, 2002 12:31 AM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Markus Gerwinski wrote: > > > Frank Heckenbach wrote: > > > > > I don't understand. Passing a value parameter is almost the same > as > > > > > an assignment. I.e., if the procedure disposes of the store > pointer > > > > > parameter, the also store pointer in the caller gets invalid which > > > > > should not happen. > > > > Where did I say that? > > > Well, maybe you didn't say that, but I assumed the purpose was to > > > make pointer access safe. > > > > It is, but I don't see why the possibility of passing store pointers as > > parameters would make pointer access unsafe. So you would have the > > possibility of writing something like this: > > > > ... > > > > Procedure foo ( var sp: store pointer ); > > I said value parameter. So let's assume you meant: > > Procedure foo ( sp: store pointer ); > > > begin (* foo *) > > ... > > dispose ( sp ); > > ... > > end (* foo *); > > > > ... > > foo ( some_global_sp ); (* disposes of sp, thus setting all *) > > ... (* pointers referencing sp^ to nil. *) > > > > What's the problem here? > > During the execution of foo you have two store pointers of the same > thing, some_global_sp and sp. If this isn't a problem, then why > allow this only in this special case and not allow copying store > pointers in general? IOW, what's the difference why it's ok in this > case, but not in other cases? > > For the implementation it means that it would not only have to keep > track of all reference pointers, but also of all the store pointers. > I.e., if foo disposes of sp, it would also have to set > some_global_sp to nil (and possibly other instances of this store > pointer in other active routines as well), therefore it must be able > to find them because sp and some_global_sp are not the same variable > (since we're talking about value, not var, parameters). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: GNU Pascal web site
by da Silva, Joe 20 Feb '02

20 Feb '02

Maybe just change the copyright notice from "-2001" to "-2002"? <G> While I generally agree the word "last" can sometimes imply a finality, in this particular context this is a weak implication. OTOH, the word "latest" has the implication of something recent, whereas I understand that gpc-2.0 is actually very outdated, so using the word "latest" would encourage people to think of using gpc-2.0, contrary to the what that sentence is actually trying to say. Well, the imminent (?) release of gpc-2.1 should change any perception that this project may be dead, and hopefully the web site update at that time will address your concerns. Joe. > -----Original Message----- > From: strobe anarkhos [SMTP:anarkhos@mac.com] > Sent: Thursday, February 21, 2002 9:31 AM > To: gpc(a)gnu.de > Subject: GNU Pascal web site > > Is it just be or does the web site look dead. It's almost begging for a > huge declaration "THIS PROJECT ISN'T DEAD!!" > > I don't think the language used helps much. For example does the statement > "We already can recommend using it instead of gpc-2.0, the last official > release." imply 2.0 is the last official release, or the latest official > release? > > It also makes you go through several web pages if you want to get a FAQ or > status report. The GNUStep web site is a lot better. > > Anyway, I'm not complaining, just an observation |-\

1 0

GNU Pascal web site
by strobe anarkhos 20 Feb '02

20 Feb '02

Is it just be or does the web site look dead. It's almost begging for a huge declaration "THIS PROJECT ISN'T DEAD!!" I don't think the language used helps much. For example does the statement "We already can recommend using it instead of gpc-2.0, the last official release." imply 2.0 is the last official release, or the latest official release? It also makes you go through several web pages if you want to get a FAQ or status report. The GNUStep web site is a lot better. Anyway, I'm not complaining, just an observation |-\

1 0

Re: gcc-3+
by da Silva, Joe 20 Feb '02

20 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 18, 2002 8:27 AM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Markus Gerwinski wrote: > > > Frank Heckenbach wrote: > > > Though I'm not sure why the distinction between store and reference > > > pointers is necessary. Why not make all pointers the same, and when > > > one pointer to an object is disposed of, all the other ones are > > > invalidated? > > > > This is usually not, what you do... is it? If the pointer p1 is the one > used > > to allocate p1^, and it is also referenced by p2..pn, you normally take > care > > to use p1 again to deallocate, don't you? > > I don't think so. It's not uncommon, e.g., for a function to > allocate and return (copy) something in a pointer, or to pass (copy) > a pointer to a procedure to clean it up and dispose it. Or to > allocate a pointer in a local variable, do something with it, then > put it in a global list from where it's later disposed, etc. > > Or do you have any arguments why these are less common situations > than what you describe? > > > > > > Besides, when you really want to evaluate things, you have to > > > > > describe all the hidden costs first. AFAICS, for every object you > > > > > need an implicit list containing all the reference pointers, so > they > > > > > can be invalidated later. > > > > Depends on the way how to implement it... > > > Now I'm interested how else you'd implement it. An alternative I > > > could think of are double-pointers, but these are slower to > > > dereference and cause another kind of memory leak: Each second-level > > > pointer allocated once can never be freed if you don't know if > > > there's somewhere a first-level pointer pointing to it. I suppose > > > that's not what you have it mind. > > > > To be honest, I don't quite get the idea nor the problem... What exactly > do > > you mean by double-pointers? > > The problem is, as Marco said, how do you find all the existing > reference pointers to invalidate when disposing of one store > pointer. > > With double pointers I mean: When you allocate some memory, you > allocate another pointer to it, and let the real pointers point to > that. So if you dispose of the memory, you set the other pointer to > nil (or something), and you don't have to iterate over all reference > pointers. The problem then would be that you can never dispose of > the other pointer if you don't keep track of all existing reference > pointers, so it's not a good solution. > > Or how do you implement it? > [Joe da Silva] FWIW, I see the "store pointer" being what you are describing here as the "other pointer" (I think). It points to the real data, and the "reference pointers" just point to it (the "store pointer"). Since you are not allowed to "re-new" a "store pointer" without "disposing" first, the "reference pointers" can't become "stale". I'm not sure that affects how you keep track of the "reference pointers" though, you probably still need to point back at them as you suggest ("double pointers"), since searching for them would generally be inefficient. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 7

Re: pointers (was: gcc-3+)
by da Silva, Joe 20 Feb '02

20 Feb '02

Yes. Linked lists are both possible and easy, with your "store" and "reference" pointer idea, provided there is a standard (ie. inbuilt) "procedure" to swap two "store" pointers. I think that's all you need to overcome the problem with linked lists. Also, note that if either or both "store" pointers has any "reference" pointers associated with it, these "reference" pointers must still point at the same objects after the "store" pointer swap, as they did prior to the swap. Finally, some suggestions on nomenclature and syntax ... 1. I wonder if the words "store" and "reference" are complementary? How about "primary" and "secondary" instead? Or something else? This is subjective, but I'm not sure if the word "store" would "read" very well in the following suggested syntax (looks too much like a verb;-) : 2. Syntax suggestion : Type pointer1 = ^integer; {a standard pointer} pointer2 = primary ^integer; {a "store" pointer} pointer3 = secondary ^integer; {a "reference" pointer} Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Wednesday, February 20, 2002 2:53 AM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: pointers (was: gcc-3+) > > Hi folks, > > da Silva, Joe wrote: > > All you need is a standard (ie. inbuilt) procedure/statement > > that can swap two store pointers ... I think. > > You mean, for linked lists? > > Bye > > Markus

4 5

Re: pointers (was: gcc-3+)
by Markus Gerwinski 20 Feb '02

20 Feb '02

Hi folks, da Silva, Joe wrote: > No, the last statement cannot result in a new assignment > for the reference pointer. That's just unacceptable. That's > why Frank was saying you needed "double pointers", so > that you could specifically set the reference pointer to "nil" > when you disposed it's corresponding store pointer. Exactly. The other method would be fatal. > You could also search the reference pointers when > disposing a store pointer, to find out which of these are > affected, but that would be inefficient (like GC;-). But it's done in several languages -- e.g. for interfaces in Delphi. There you don't have an explicit store pointer, but a reference counter keeps track on every piece of memory; if the number of pointers referencing it decreases to 0, it is automatically disposed of. This requires exactly what you say: Searching for all references to a piece of memory, whenever a pointer is set away from it. Bye Markus

2 2

Re: pointers (was: gcc-3+)
by da Silva, Joe 20 Feb '02

20 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, February 20, 2002 12:03 PM > To: gpc(a)gnu.de > Subject: Re: pointers (was: gcc-3+) > > da Silva, Joe wrote: > > > Yes. Linked lists are both possible and easy, with your "store" and > > "reference" pointer idea, provided there is a standard (ie. inbuilt) > > "procedure" to swap two "store" pointers. I think that's all you need > > to overcome the problem with linked lists. > > Sorry, but to me it seems a way to solve this particular situation > that occurs with simple linked lists (as you described in a previous > mail) where you have an exact overview what is going on (and > therefore don't need the whole concept at all -- *because* you know > exactly what's going on, and could just do things correctly with > normal pointers). Avoiding memory leaks with simple links lists is > not exactly a difficult problem. > [Joe da Silva] True, standard pointers are quite adequate for simple linked lists. ------ snip ------

1 0

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

Hmmm ... This may not be as bad as it appears. All you need is a standard (ie. inbuilt) procedure/statement that can swap two store pointers ... I think. Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Tuesday, February 19, 2002 5:26 AM > To: Maurice Lombardi > Cc: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Hi folks, > > Maurice Lombardi wrote: > > Gosh. How do you do with linked lists, a quite common situation I > believe. > > If you append records only at the end of the list, you can use the last > "next" > > pointer as a store pointer. But what do you do if you want to insert a > new > > record in the middle of the list. Usually either: > > you keep the address of the next record in a temporary pointer and > allocate > > the new record with the "next" pointer of the previous: invalid because > you > > try to new an undisposed pointer. > > you allocate the new record with a "temporary" pointer (no problem up to > that > > point, it will be a store pointer) and then insert it, playing with two > "next" > > pointers: but the previous "next" goes from store to reference status. > And you > > need to keep somewhere all "temporary" pointers which served you to > allocate > > the elements ... > > Hmm, right. Here you got me. For linked-list maintenance etc., we need the > free play with pointers. (Awkward... I missed the trivial case by modeling > the complex ones...) > > Bye > > Markus

2 1

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

You take things too seriously, Frank. The wink in reference to GC was a clue that you shouldn't have ... <G> One of the key advantages of Pascal over more primitive languages, and one of several reasons it is much less bug prone, is that it imposes discipline on the program. IMHO, GC is contrary to that philosophy and not appropriate to Pascal (which is what we are discussing, since we have already established that the GPC compiler needs to use GC to be compatible with GCC-3). What I was thinking (in the previous message), was that if "double pointers" were not employed for this "store" and "reference" pointer suggestion, then it would be necessary to search the "reference" pointers to find which ones were no longer valid. And I was also thinking that GC must also do similar searching of pointers, but instead to find what memory blocks were no longer in use. So I reasoned that although searching the "reference" pointers would be relatively inefficient (compared to using "double pointers"), it should be comparable to GC, so I was merely putting this in perspective. While on this topic (you'll note that I had changed the subject heading, since we really aren't talking about the original GCC-3 issue any more), I had a thought that perhaps rather than setting any "reference" pointers to nil when their corresponding "store" pointer was disposed, perhaps this should really result in a run-time error. That is, you cannot dispose a "store" pointer if it has any "reference" pointers associated with it. This would be better than later in the code, trying to dereference a "reference" pointer, then trying to figure out why/when it became invalid. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, February 19, 2002 6:06 PM > To: gpc(a)gnu.de > Subject: Re: pointers (was: gcc-3+) > > da Silva, Joe wrote: > > > You could also search the reference pointers when > > disposing a store pointer, to find out which of these are > > affected, but that would be inefficient (like GC;-). > > It's always easy to make such claims, but I've yet to see a solution > (for the general case) that is more efficient, considering any > hidden costs? > > BTW, have you studied GC algorithms? I haven't, but I've see that > some research has done in this area and a good GC algorithm is quite > a bit better than an implementation I'd come up with if I tried it > naively ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Compiling inline assembly code
by Anuradha 19 Feb '02

19 Feb '02

Hello , The code probably doesnt use system calls-i am not sure. But there are some asm units that could take some time if we try to rewrite them in pascal. I am attaching one such code. Thanks and Regards, Anuradha PAGE 58,132 TITLE Compare routine PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Following EQU has to be set to 0 for NEAR call {$L compress.obj} ³ ;³ 1 for FAR call {INTERFACE in unit} ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; @_NEAR_FAR EQU 1 ; ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Return codes for compare ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; @C_RC_1G2 EQU -1 ; Return code first parameter greater @C_RC_1S2 EQU 1 ; Return code first parameter smaller @C_RC_1E2 EQU 0 ; Return code parameters equal PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Do not change following equates ³ ;³ Internals and parameter definitions ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; ; ; Pascal parameter offsets on stack ; @P_RET_ADD EQU 2*(@_NEAR_FAR+1) ; Size of the return address @P_SOURCE1 EQU [BP+@P_RET_ADD+14] ; Address of structure1 @P_OFFSET1 EQU [BP+@P_RET_ADD+12] ; Offset in structure1 @P_SOURCE2 EQU [BP+@P_RET_ADD+8] ; Address of structure2 @P_OFFSET2 EQU [BP+@P_RET_ADD+6] ; Offset in structure2 @P_LENGTH EQU [BP+@P_RET_ADD+4] ; Length to compare PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Compare routine : ³ ;³ Definition in Pascal : ³ ;³ FUNCTION COMPARE( VAR structure 1 ; ³ ;³ offset in structure 1 : INTEGER ; ³ ;³ VAR structure 2 ; ³ ;³ offset in structure 2 : INTEGER ; ³ ;³ length to compare : WORD ) : INTEGER ; ³ ;³ Return codes : ³ ;³ See equates above. ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; CODE SEGMENT BYTE PUBLIC 'CODE' ASSUME CS:CODE ; COMPARE PROC NEAR ; PUSH DS ; Save Pascal environment and PUSH BP ; get parameter addressablitity MOV BP,SP PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Set source and target address for compare. ³ ;³ Initialize compare counter. ³ ;³ Do the compare ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; COMP_000: LDS SI,@P_SOURCE1 ; DS:SI to structure 1 ADD SI,@P_OFFSET1 LES DI,@P_SOURCE2 ; ES:DI to structure 2 ADD DI,@P_OFFSET2 MOV CX,@P_LENGTH ; Compare counter JCXZ COMP_001 ; If nothing to compare then equal CLD REPE CMPSB ; Do the compare JE COMP_001 JB COMP_002 MOV AX,@C_RC_1G2 ; Return 1 greater than 2 JMP SHORT COMP_EX COMP_001: MOV AX,@C_RC_1E2 ; Return 1 equal 2 JMP SHORT COMP_EX COMP_002: MOV AX,@C_RC_1S2 ; Return 1 smaller than 2 PAGE ;ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ;³ Return point : restore Pascal environment and remove parameters. ³ ;ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ; COMP_EX: MOV SP,BP ; Delete local scratch path POP BP ; Restore Pascal environment POP DS IF @_NEAR_FAR RETF 14 ; Kill parameters and return ELSE RETN 14 ; Kill parameters and return ENDIF ; COMPARE ENDP ; CODE ENDS ; PUBLIC COMPARE ; END

2 1

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Tuesday, February 19, 2002 6:10 AM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: gcc-3+ > > Hi folks, > > da Silva, Joe wrote: > > FWIW, I see the "store pointer" being what you are describing > > here as the "other pointer" (I think). It points to the real data, > > and the "reference pointers" just point to it (the "store pointer"). > > That was my idea, yes... but after re-thinking, I now found an > unintentional > side effect: This would cause the reference pointer to _always_ point to > the > data of the store pointer, even if you dispose and re-new the store; the > command sequence > > new ( store ); > ... > reference:= store; (* set reference^ to store^ *) > ... > dispose ( store ); (* set reference to nil *) > ... > new ( store ); (* set reference^ to store^ ... without a command > *) > [Joe da Silva] No, the last statement cannot result in a new assignment for the reference pointer. That's just unacceptable. That's why Frank was saying you needed "double pointers", so that you could specifically set the reference pointer to "nil" when you disposed it's corresponding store pointer. So, the subsequent "new" statement would not re-assign the reference pointer - if that's what you (ie. the programmer) want, you assign it explicitly after the "new" statement. You could also search the reference pointers when disposing a store pointer, to find out which of these are affected, but that would be inefficient (like GC;-). > > would then contain a new trap to tangle up the logic of the program. The > implicit handling of a store/reference concept doing exactly what it is > supposed to do (hooking the reference to the _data_, not to its store) > would, as Frank said, really be more complicated, I fear. > > Bye > > Markus

2 1

Re: gcc-3+
by da Silva, Joe 18 Feb '02

18 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, February 12, 2002 7:16 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Russell Whitaker wrote: > > > found this at http://gcc.gnu.org/projects/ > > > > Miscellaneous ideas: > > > > Chill should use garbage collection. > > > > Convert the Chill front end to use garbage collection instead of > > obstacks, so that it can work again with current GCC. > > > > Suspect this should apply to gpc as well. > > Indeed. That's one of the main issues when moving GPC to gcc-3. > Other issues are a numer of changed interfaces, though this will > probably mostly be "mechanical" work. > [Joe da Silva] Well, the pragmatist in me says GCC-3 compatibility is more important than ideological misgivings about garbage collection. <G> > > Any guess how much time > > and effort it would take to make the change? > > According to a talk with Peter, it will be on the order of several > days to a few weeks. If several people will work on it, it will be > easier on everyone, of course. Are you interested in helping? > > da Silva, Joe wrote: > > > IMHO, garbage collection is a kludge to fix memory leakage > > problems, which are a particularly common affliction with C, > > with it's particularly heavy reliance on pointers ... <BG> > > Excuse me, but I think that's more of a prejudice here. What the > compiler does internally relies heavily on tree structures. These > require pointers in *any* language -- though some languages hide the > fact. Pascal doesn't hide it, so the tree handling code and the > resulting memory management problems would be exactly the same if > GPC was written in Pascal. > > Other typical usages of pointers in C, such as for strings, are > relatively few in GCC/GPC, and are not the problem. > [Joe da Silva] My comments were general and relate to the excessive reliance of C on pointers, whereas Pascal often avoids them with safer alternatives, such as "var" parameters, etc. Of course, pointers are important and necessary in many situations (but I still consider garbage collection is a kludge for bad housekeeping - note also the <BG> ;-) My knowledge of the internal workings of GPC (compilers in general, actually) is next to zero, although I hope that one day this will improve. BTW, I do realize GPC is itself written in C, thereby taking advantage of the wide platform support of GCC (every cloud has a silver lining!;-). If this inter-dependence with GCC also means that garbage collection is a requirement, then "so be it" ... > The "obstacks" were something like a "half-hearted" garbage > collector and cause(d) many problems, so it's good to get rid of > them, anyway, even if gcc-3 would not require it. > > Of course, there are other alternatives to GC, such as reference > counting. But that's not without cost either: it requires traversing > all structures to get rid of, which costs runtime and is even a > little tricky in the presence of recursive structures. And it costs > memory to store the reference counters while GC has no significant > memory costs AFAIK (only runtime costs). > > So, from the programmer's perspective, GC is probably the easiest to > live with, and also at runtime, it might not be worse than the > alternatives. > > Or am I missing the perfect solution? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

6 13

Re: gcc-3+
by Maurice Lombardi 18 Feb '02

18 Feb '02

Markus Gerwinski <markus(a)gerwinski.de> a dit : > Hi folks, > > Frank Heckenbach wrote: > > Though I'm not sure why the distinction between store and reference > > pointers is necessary. Why not make all pointers the same, and when > > one pointer to an object is disposed of, all the other ones are > > invalidated? > > This is usually not, what you do... is it? If the pointer p1 is the one used > to allocate p1^, and it is also referenced by p2..pn, you normally take care > to use p1 again to deallocate, don't you? > > If so, you _are_ implicitly working with "store" and "reference" pointers. > Making this an explicit naming within the programming language would IMO > make the language more "speaking". It would enforce "clear responsibilities" > within the program: Only the pointer that created a piece of memory may > destroy it. > > If the restrictions are like this: > - store pointers may _only_ "new" or "dispose", but never be set to the > value of another pointer. Trying to "new" an already set store pointer > causes a runtime error. > - reference pointers may _only_ be set to the value of another pointer, but > never be "new"ed or "dispose"d. > ... then memory leaks are made impossible (you just _can't_ allocate a > pointer and then set somewhere else), and accidentally disposing of some > data still needed by a bunch of other pointers becomes at least less likely > (reference p42 just isn't able to dispose of p1). Gosh. How do you do with linked lists, a quite common situation I believe. If you append records only at the end of the list, you can use the last "next" pointer as a store pointer. But what do you do if you want to insert a new record in the middle of the list. Usually either: you keep the address of the next record in a temporary pointer and allocate the new record with the "next" pointer of the previous: invalid because you try to new an undisposed pointer. you allocate the new record with a "temporary" pointer (no problem up to that point, it will be a store pointer) and then insert it, playing with two "next" pointers: but the previous "next" goes from store to reference status. And you need to keep somewhere all "temporary" pointers which served you to allocate the elements ... Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

New versions of the sysutils and objects units
by Prof. A Olowofoyeku (The African Chief) 18 Feb '02

18 Feb '02

Hi all Updated versions of the sysutils and objects units have been released, and are now on agnes: ftp://agnes.dida.physik.uni-essen.de/home/chief/ Enjoy ... Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

4 3

Re: Compiling inline assembly code
by da Silva, Joe 18 Feb '02

18 Feb '02

There are two possible reasons for using inline assembler code : 1. For speed-critical portions of code. 2. For very low-level, machine-specific parts of the code. So, if it's reason #2, then you can't merely translate the code, either to Pascal, or to your new target machine language, Sparc. For example, suppose the inline assembly code is an interrupt service routine for INT4 (COM1: serial port interrupt). You can't just translate this to another platform, because INT4 (if there is such a thing) will be unrelated, the serial port I/O addresses will be different, the serial port UART probably has different registers and modes, the CPU will definitely have different registers, etc., etc. Good luck, you'll need it! Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 18, 2002 4:51 PM > To: gpc(a)gnu.de > Subject: Re: Compiling inline assembly code > > Anuradha wrote: > > > We have been trying to compile in-line assembler code in our pascal > > programs using gpc-20010623 .We are porting the sources from windows to > > sparc-sunsolaris 2.6 and we have some problems with compiling the asm > > code.The gas says that it is not able to recognise the opcodes > > "push","pop","cld".. > > Erm, well, different processors use different kinds of assembler > code. That's why assembler is considered low-level compared to > Pascal. > > Basically, you'll have to rewrite all your assembler code for any > new processor. Or you translate it to Pascal, then you need only one > version. (Since GPC is a Pascal compiler, I think I might mention > this option ... ;-) > > > The link to Mr.Brennan's site given in the FAQ has a ~ and we are not > > able to reach the site. > > Thanks for the hint. In the DJGPP FAQ, I found a new URL: > http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html > > BTW, I was misspelled (the `_djgpp' part was missing) or has moved > -- at least since v2.30 of the FAQ which I have here (in case any of > the DJGPP people are reading this, and it hasn't been fixed > already). > > > Can you kindly tell us where we can get some help on compiling asm on > > sparc-sun-solaris. > > No, I haven't had the need to program any asm on the Sparc. Have you > searched the net? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: gcc-3+
by da Silva, Joe 18 Feb '02

18 Feb '02

Am I the only one missing the previous message from CBF? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, February 15, 2002 10:47 PM > To: gpc(a)gnu.de; cbfalconer(a)worldnet.att.net > Subject: Re: gcc-3+ > > CBFalconer wrote: > > > I never heard of an 'obstack'. > > I guess not. It's a GNU invention, and I haven't seen it used > anywhere but in GCC itself (prior to version 3). Actually, now that > you mention it, they're not much different from Mark/Release except > that they support several independent instances. > > > P4 did most of this with mark/release, which sufficed, but is > > usually incompatible with new/dispose (another subject). > > FWIW, in GPC(*) they are compatible, but in a rather inefficient way > (i.e., Release just does a series of Dispose calls internally). > > (*) Here I mean for GPC programs, not in GPC internally, of course. > > > Are we talking about the same things? > > I think so, and after dealing with some of the more nasty problems > caused by obstacks and leading to compiler crashed that are hard to > debug (like many MM related problems, because the symptoms ofter > occur much later than the problem), I really like to get rid of > them. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de > http://fjf.gnu.de/ > GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Compiling inline assembly code
by Anuradha 18 Feb '02

18 Feb '02

Hello, We have been trying to compile in-line assembler code in our pascal programs using gpc-20010623 .We are porting the sources from windows to sparc-sunsolaris 2.6 and we have some problems with compiling the asm code.The gas says that it is not able to recognise the opcodes "push","pop","cld".. The link to Mr.Brennan's site given in the FAQ has a ~ and we are not able to reach the site. Can you kindly tell us where we can get some help on compiling asm on sparc-sun-solaris. Thanks and Regards, Anuradha -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Re: gcc-3+
by Frank Heckenbach 15 Feb '02

15 Feb '02

CBFalconer wrote: > I never heard of an 'obstack'. I guess not. It's a GNU invention, and I haven't seen it used anywhere but in GCC itself (prior to version 3). Actually, now that you mention it, they're not much different from Mark/Release except that they support several independent instances. > P4 did most of this with mark/release, which sufficed, but is > usually incompatible with new/dispose (another subject). FWIW, in GPC(*) they are compatible, but in a rather inefficient way (i.e., Release just does a series of Dispose calls internally). (*) Here I mean for GPC programs, not in GPC internally, of course. > Are we talking about the same things? I think so, and after dealing with some of the more nasty problems caused by obstacks and leading to compiler crashed that are hard to debug (like many MM related problems, because the symptoms ofter occur much later than the problem), I really like to get rid of them. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Multiple definition of procedures.
by HARIKRISHNA Kocheralkota 15 Feb '02

15 Feb '02

Hello, Is multiple definition of procedure like the following not allowed in GPC? =================================================== program myprg; uses mycase; begin x; end. =================================================== unit Mycase; interface uses Myunit; procedure x; implementation procedure X; begin writeln('i am in Mycase'); end; end. ================================================ unit myunit; interface procedure x; implementation procedure x; begin writeln(' i am in myuint'); end; end. ==================================================== This works fine in BP. Thanks and Regards, Hari

2 1

Re: gcc-3+
by Frank Heckenbach 15 Feb '02

15 Feb '02

CBFalconer wrote: > Frank Heckenbach wrote: > > > > Obviously, you need pointers to represent such structures. Creating > > them is not a problem, but how to clean up properly? You can > > traverse all pointers in the object and clean up the objects they > > point to recursively. But that's wrong because those objects might > > be referred to from elsewhere. Also, with cyclic references, you'd > > run into an endless loop. > > > > This is not to say it's impossible (I mentioned reference counting, > > and there are ways to avoid the endless loop), but is this much > > simpler than GC? In fact, if you consider the whole memory as a > > large tree(*), the resulting algorithm wouldn't look much > > differently from a GC algorithm ... > > > > (*) It's not really so, but in fact most of it is consumed by tree > > nodes, and whether you consider cleaning up one of several trees > > or cutting a branch from the only tree doesn't make a big > > difference. > > > > > If this > > > inter-dependence with GCC also means that garbage > > > collection is a requirement, then "so be it" ... > > > > Practically, it does. But if you know a better solution, even if > > only in theory, I'd be interested, just for curiosity. > > How about in practice. I wrote the attached package for precisely > this sort of problem. It is not completely tested yet, but I have > found very few problems, and the whole package represents about a > kilobyte of object code. > > So far the best usage example is the 'markov' program, which uses > two inter-related data bases. There is no need to keep track of > individual items, only the data base itself. The inner workings > are hidden. Read the header file, which provides the complete > abstraction. > > I envision each scope opening a new data base, and scope exit > releasing it. Access is fast, generally requiring about 1.5 > probes for finding, 2 for insertion. The package statistics > include the cost of reorganization, which is more efficient than > insertion, makes the database size irrelevant, and is again hidden > from view. There is no problem including usage counts, possibly > in a master spellings table, and interconnecting such with table > construction/destruction (see the dupe/undupe functions). > > For large numbers of items the only practical difficulty is the > slow operation of free() in some C systems. This becomes > noticeable in DJGPP by about 10,000 items, and is an O(N*N) > effect, related to merging of freed storage blocks. Yes, it seems to happen only with strong fragmentation as in the following test program (without fragmentation it's quite linear). #include <stdlib.h> #include <stdio.h> #include <sys/time.h> void *p [200000]; int main () { int i, j; clock_t c = clock (), c2; for (i = 1; i <= 20; i++) { for (j = 0; j < 10000 * i; j++) p[j] = malloc (42); for (j = 0; j < 10000 * i; j += 2) free (p[j]); for (j = 1; j < 10000 * i; j += 2) free (p[j]); c2 = clock (); printf ("%i ", (int) (c2 - c)); fflush (stdout); c = c2; } return 0; } > This probably > will not affect compiler use, since 10,000 items per scope is a > rare occurence IMNSHO. Probably. OTOH, I've just fixed some other O(n^2) problems (in the code that deals with unit/module) interfaces. The Chief had reported (long time ago) that the compilation of Windows API interfaces was very slow, and that might have been due to these problems (as soon as the next RC is release, he'll certainly test it, I guess). I don't know how many items there actually are, but I wouldn't be surprised if it actually reaches this order of magnitude (taking into account that e.g., each function parameter, its type and its name, use distinct nodes internally). > I am attaching the hashlib (preliminary) package only to you, > since it is preliminary and until I have finished with testing I > want to keep control of it, and the newlist should not be burdened > with a fairly large attachment. Feel free to pass it on to other > workers in the Pascal pits, and/or to forward this message to the > newslist. ... which I'm doing now. Since I'm quite busy I haven't had the time yet to look at it thoroughly. But at first sight, if I understand it correctly, one would start a new "block" for each Pascal routine (roughly), do all local allocations within it, and release it as a whole in the end. (Perhaps this understanding is completely wrong, then ignore the rest. ;-) Well, this is almost exactly the obstack idea. (Except that they kind of "buffer" the allocation and allocate and free larger blocks from the system MM, so the slowness of free() on DJGPP probably doesn't matter so much.) But problems occur when the usage pattern of the tree nodes is not strictly "scoped". This starts with parameters (which are declared within a function, but needed when calling it -- though perhaps you can just put them in the outer scope), goes on with inline routines (whose code is kept in an intermediary form ("RTX") while most of the tree nodes can be freed, but not all, since, e.g. some type information is still needed), and the most difficult (or ugly) problems are often seemingly little details. E.g., a node that represents a type contains a list of its "variants" (i.e., the same type but, e.g., a protected and/or restricted version). Perhaps that's only for efficiency (so that when `protected foo' appears in several places, only one node for the restricted type needs to be created). But for this to work, a new variant of a type is always placed on the same obstack (in this case), otherwise a pointer would dangle when another obstack is removed. These were just some examples (and perhaps not well described). The main point is that the more optimization and special features come into play, the more often one gets in conflict with the strict scoping that the obstacks imply by default. I suppose that's the reason why they were finally thrown out in gcc-3.0. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Re: gcc-3+
by da Silva, Joe 15 Feb '02

15 Feb '02

IMHO, garbage collection is a kludge to fix memory leakage problems, which are a particularly common affliction with C, with it's particularly heavy reliance on pointers ... <BG> Joe. > -----Original Message----- > From: Russell Whitaker [SMTP:russ@ashlandhome.net] > Sent: Tuesday, February 12, 2002 4:37 PM > To: gpc(a)gnu.de > Subject: gcc-3+ > > Hi > found this at http://gcc.gnu.org/projects/ > > Miscellaneous ideas: > > Chill should use garbage collection. > > Convert the Chill front end to use garbage collection instead of > obstacks, so that it can work again with current GCC. > > Suspect this should apply to gpc as well. Any guess how much time > and effort it would take to make the change? > > Russ > >

4 4

2025

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