- Gpc - gnu.de

GNU Binary for SGI
by Oliver Puetz 03 Jun '99

03 Jun '99

Hi, I've downloaded the binary beta "gpc-19990118_mips-sgi-irix6_2_tar.gz" from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/, as I'm not really familiar with unix. It should run on a SGI, Power-Challenge-XL12 with IRIX64 v6.2. GCC v2.7 is already installed. The environmental variable GPC_EXEC_PREFIX does not seem to work, setting the dir with -B as a command option helps. By compiling a little test program (no uses etc) a fatal error occured: ld32: FATAL 9: I/O error (-lgpc): No such file or directory I've copied the files from /gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 into the bin-dir, but it doesn't helped. Can anyone help or had made experiences with this version? Thanks in advance Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

2 1

run time trap with packed array of boolean
by Richard Sharman 02 Jun '99

02 Jun '99

gpc version 19990118, based on gcc-2.8.1 running on a sun % cat bug.pas program f(input, output) ; type lottery_number = 1..49 ; var lotto_1 : array[lottery_number] of boolean; lotto_2 : packed array[lottery_number] of boolean; n : integer ; begin n := 3 ; lotto_1[n] := true ; lotto_2[n] := true ; end . % gpc -o bug bug.pas % ./bug Bus error (core dumped) % ------------------------------------------------------------------------ What follows is a dump from gdb of the registers, the immediate context, and the full assember file (produced by gpc -S -g bug.pas). ------------------------------------------------------------------------ Continuing. Program received signal SIGBUS, Bus error. 0x231c in program_F () at bug.pas:16 1: x/i $pc 0x231c <program_F+140>: lduh [ %o4 + %o5 ], %o4 (gdb) p/x $pc-0x20 $pc A syntax error in expression, near `'. (gdb) disas $pc-0x20 $pc Dump of assembler code from 0x22fc to 0x231c: 0x22fc <program_F+108>: sethi %hi(0x2a800), %g2 0x2300 <program_F+112>: ld [ %g2 + 0x29c ], %g3 ! 0x2aa9c <N> 0x2304 <program_F+116>: add %g3, -1, %g2 0x2308 <program_F+120>: and %g2, 0xf, %g3 0x230c <program_F+124>: mov 1, %o7 0x2310 <program_F+128>: sll %o7, %g3, %g2 0x2314 <program_F+132>: mov %g2, %g3 0x2318 <program_F+136>: xnor %g3, 0, %g2 End of assembler dump. (gdb) sho reg Undefined show command: "reg". Try "help show". (gdb) info reg g0 0x0 0 g1 0xef780408 -277347320 g2 0xfffffffb -5 g3 0x4 4 g4 0x0 0 g5 0x0 0 g6 0x0 0 g7 0x0 0 o0 0x0 0 o1 0xeffff99c -268437092 o2 0x0 0 o3 0x2aa95 174741 o4 0x0 0 o5 0x2aa95 174741 sp 0xeffff860 -268437408 o7 0x1 1 l0 0x9 9 l1 0x21b8 8632 l2 0x0 0 l3 0x10000 65536 l4 0x10 16 l5 0x20008011 536903697 l6 0x38 56 l7 0x5 5 i0 0x1 1 i1 0xeffff99c -268437092 i2 0xeffff9a4 -268437084 i3 0x0 0 i4 0x0 0 i5 0x1834 6196 fp 0xeffff8d0 -268437296 i7 0x2504 9476 y 0x0 0 psr 0x41400080 1094713472 wim 0x0 0 tbr 0x0 0 pc 0x231c 8988 npc 0x2320 8992 fpsr 0x0 0 cpsr 0x0 0 (gdb) ------------------------------------------------------------------------ gcc2_compiled.: ___gnu_compiled_pascal: .stabs "/home/tools/sharman/pas-stuff/",100,0,0,Ltext0 .stabs "bug.pas",100,0,0,Ltext0 .text Ltext0: .stabs "Integer:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0 .stabs "Char:t(0,2)=@s8;-20;",128,0,0,0 .stabs "Medint:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0 .stabs "Sizetype:t(0,4)=r(0,4);0;-1;",128,0,0,0 .stabs "Medcard:t(0,5)=r(0,5);0;-1;",128,0,0,0 .stabs "Longestint:t(0,6)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0 .stabs "Longestcard:t(0,7)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0 .stabs "Smallint:t(0,8)=r(0,8);-32768;32767;",128,0,0,0 .stabs "Shortcard:t(0,9)=r(0,9);0;65535;",128,0,0,0 .stabs "Byteint:t(0,10)=r(0,10);-128;127;",128,0,0,0 .stabs "Bytecard:t(0,11)=r(0,11);0;255;",128,0,0,0 .stabs "Longestreal:t(0,12)=r(0,1);8;0;",128,0,0,0 .stabs " complex int:t(0,13)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0 .stabs " complex float:t(0,14)=r(0,14);4;0;",128,0,0,0 .stabs "Complex:t(0,15)=r(0,15);8;0;",128,0,0,0 .stabs " complex long double:t(0,16)=r(0,16);8;0;",128,0,0,0 .stabs "Ptrcard:t(0,17)=r(0,17);0;-1;",128,0,0,0 .stabs "Ptrint:t(0,18)=r(0,18);-2147483648;2147483647;",128,0,0,0 .stabs "String:t(0,19)=s12Capacity:(0,1),0,32;length:(0,1),32,32;string:(0,20)=ar(0,1);1;1;(0,21)=@s8;-20;,64,8;;",128,0,0,0 .stabs "Timestamp:t(0,22)=s36Datevalid:(0,23)=@s8;-16;,0,8;Timevalid:(0,23),8,8;Year:(0,1),32,32;Month:(0,24)=r(0,1);1;12;,64,32;Day:(0,25)=r(0,1);1;31;,96,32;Dayofweek:(0,26)=r(0,1);0;6;,128,32;Hour:(0,27)=r(0,1);0;23;,160,32;Minute:(0,28)=r(0,1);0;59;,192,32;Second:(0,28),224,32;Microsecond:(0,29)=r(0,1);0;999999;,256,32;;",128,0,0,0 .stabs "Bindingtype:t(0,30)=s312Bound:(0,23),0,8;Force:(0,23),8,8;Extensions_valid:(0,23),16,8;Readable:(0,23),24,8;Writable:(0,23),32,8;Executable:(0,23),40,8;Existing:(0,23),48,8;Directory:(0,23),56,8;Size:(0,6),64,64;Accesstime:(0,6),128,64;Modificationtime:(0,6),192,64;Changetime:(0,6),256,64;Error:(0,1),320,32;Cfile:(0,31)=*(0,32)=(0,32),352,32;Name:(0,33)=s264Capacity:(0,1),0,32;length:(0,1),32,32;string:(0,34)=ar(0,1);1;256;(0,21),64,2048;;,384,2112;;",128,0,0,0 .stabs "Pointer:t(0,31)",128,0,0,0 .stabs "Shortreal:t(0,35)=r(0,1);4;0;",128,0,0,0 .stabs "Real:t(0,36)=r(0,1);8;0;",128,0,0,0 .stabs "Cstring:t(0,37)=*(0,2)",128,0,0,0 .stabs "Boolean:t(0,23)",128,0,0,0 .stabs "Void:t(0,32)",128,0,0,0 .stabs "Text:t(0,38)=d(0,2)",128,0,0,0 .stabs "_p_MPNGHS:S(0,31)",40,0,1,__p_MPNGHS .reserve __p_MPNGHS,4,"bss",4 .stabs "_p_MPNGSL:S(0,31)",40,0,1,__p_MPNGSL .reserve __p_MPNGSL,4,"bss",4 .stabs "_p_MPNGFP:S(0,31)",40,0,1,__p_MPNGFP .reserve __p_MPNGFP,4,"bss",4 .stabs "Lottery_number:t(0,39)=(0,40)=r(0,1);1;49;",128,0,4,0 .stabs "Lotto_1:S(0,41)=ar(0,1);1;49;(0,23)",40,0,7,_Lotto_1 .reserve _Lotto_1,49,"bss",1 .stabs "Lotto_2:S(0,42)=ar(0,1);1;49;(0,23)",40,0,8,_Lotto_2 .reserve _Lotto_2,7,"bss",1 .stabs "N:S(0,1)",40,0,9,_N .reserve _N,4,"bss",4 .align 4 .global _program_F .proc 020 _program_F: .stabn 68,0,11,LM1 LM1: !#PROLOGUE# 0 save %sp,-112,%sp !#PROLOGUE# 1 .stabn 68,0,11,LM2 LM2: LBB2: LBB3: .stabn 68,0,13,LM3 LM3: sethi %hi(_N),%o2 mov 3,%o3 st %o3,[%o2+%lo(_N)] .stabn 68,0,15,LM4 LM4: sethi %hi(_Lotto_1),%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 or %o2,%lo(_Lotto_1),%o4 add %o3,%o4,%o2 mov 1,%o3 stb %o3,[%o2] .stabn 68,0,16,LM5 LM5: mov 1,%o2 stb %o2,[%fp-9] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o0 sra %o0,4,%o2 mov %o2,%o0 mov %o0,%o3 sll %o3,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 mov %o0,%o5 sll %o5,1,%o4 sethi %hi(_Lotto_2),%g2 or %g2,%lo(_Lotto_2),%o5 sethi %hi(_N),%g2 ld [%g2+%lo(_N)],%g3 add %g3,-1,%g2 and %g2,15,%g3 mov 1,%o7 sll %o7,%g3,%g2 mov %g2,%g3 xnor %g3,0,%g2 lduh [%o4+%o5],%o4 mov %g2,%o5 and %o4,%o5,%o4 sth %o4,[%o2+%o3] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o1 sra %o1,4,%o2 mov %o2,%o1 mov %o1,%o3 sll %o3,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 mov %o1,%o5 sll %o5,1,%o4 sethi %hi(_Lotto_2),%g2 or %g2,%lo(_Lotto_2),%o5 ldub [%fp-9],%g2 and %g2,1,%g3 and %g3,0xff,%g2 sethi %hi(_N),%g3 ld [%g3+%lo(_N)],%o7 add %o7,-1,%g3 and %g3,15,%o7 sll %g2,%o7,%g2 lduh [%o4+%o5],%o4 mov %g2,%o5 or %o4,%o5,%o4 sth %o4,[%o2+%o3] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o2 sra %o2,4,%o3 mov %o3,%o4 sll %o4,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 add %o2,%o3,%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 sra %o3,4,%o4 mov %o4,%o5 sll %o5,1,%o3 sethi %hi(_Lotto_2),%o5 or %o5,%lo(_Lotto_2),%o4 add %o3,%o4,%o3 sethi %hi(_N),%o4 ld [%o4+%lo(_N)],%o5 add %o5,-1,%o4 and %o4,15,%o5 mov 1,%g2 sll %g2,%o5,%o4 srl %o4,16,%o5 mov %o5,%o4 xnor %o4,0,%o5 lduh [%o3+2],%o3 mov %o5,%o4 and %o3,%o4,%o3 sth %o3,[%o2+2] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o2 sra %o2,4,%o3 mov %o3,%o4 sll %o4,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 add %o2,%o3,%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 sra %o3,4,%o4 mov %o4,%o5 sll %o5,1,%o3 sethi %hi(_Lotto_2),%o5 or %o5,%lo(_Lotto_2),%o4 add %o3,%o4,%o3 ldub [%fp-9],%o4 and %o4,1,%o5 and %o5,0xff,%o4 sethi %hi(_N),%o5 ld [%o5+%lo(_N)],%g2 add %g2,-1,%o5 and %o5,15,%g2 sll %o4,%g2,%o4 srl %o4,16,%o5 lduh [%o3+2],%o3 mov %o5,%o4 or %o3,%o4,%o3 sth %o3,[%o2+2] .stabn 68,0,18,LM6 LM6: LBE3: LBE2: .stabn 68,0,18,LM7 LM7: L1: ret restore .stabs "program_F:F(0,32)",36,0,11,_program_F .stabn 192,0,0,LBB2 .stabs "assign_packed_0:(0,23)",128,0,16,-9 .stabn 192,0,0,LBB3 .stabn 224,0,0,LBE3 .stabn 224,0,0,LBE2 .align 4 .global ___init_program_F .proc 020 ___init_program_F: .stabn 68,0,18,LM8 LM8: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 .stabn 68,0,18,LM9 LM9: LBB4: sethi %hi(__p_collect_flag),%o0 ld [%o0+%lo(__p_collect_flag)],%o1 cmp %o1,0 be L3 nop sethi %hi(___init_program_F),%o1 or %o1,%lo(___init_program_F),%o0 mov 0,%o1 call __p_collect,0 nop b L2 nop L3: LBE4: .stabn 68,0,18,LM10 LM10: L2: ret restore .stabs "__init_program_F:F(0,32)",36,0,18,___init_program_F .stabn 192,0,0,LBB4 .stabn 224,0,0,LBE4 .align 4 .global ___fini_program_F .proc 020 ___fini_program_F: .stabn 68,0,18,LM11 LM11: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 .stabn 68,0,18,LM12 LM12: L4: ret restore .stabs "__fini_program_F:F(0,32)",36,0,18,___fini_program_F .align 4 .global _main .proc 04 _main: .stabn 68,0,18,LM13 LM13: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 st %i0,[%fp+68] st %i1,[%fp+72] st %i2,[%fp+76] call ___main,0 nop ld [%fp+68],%o0 ld [%fp+72],%o1 ld [%fp+76],%o2 call __p_initialize,0 nop call _program_F,0 nop mov 0,%i0 b L5 nop .stabn 68,0,18,LM14 LM14: L5: ret restore .stabs "main:F(0,1)",36,0,18,_main .stabs "argc:p(0,1)",160,0,18,68 .stabs "argv:p(0,43)=*(0,37)",160,0,18,72 .stabs "envp:p(0,43)",160,0,18,76 .align 4 .global __GLOBAL_$I$program_F .proc 020 __GLOBAL_$I$program_F: .stabn 68,0,19,LM15 LM15: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 call ___init_program_F,0 nop .stabn 68,0,19,LM16 LM16: L6: ret restore .stabs "_GLOBAL_$I$program_F:F(0,32)",36,0,19,__GLOBAL_$I$program_F .align 4 .global __GLOBAL_$D$program_F .proc 020 __GLOBAL_$D$program_F: .stabn 68,0,19,LM17 LM17: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 call ___fini_program_F,0 nop .stabn 68,0,19,LM18 LM18: L7: ret restore .stabs "_GLOBAL_$D$program_F:F(0,32)",36,0,19,__GLOBAL_$D$program_F ------------------------------------------------------------------------

1 0

Re: Initialization of sets in a "var" statement inccorrect on the Sun.
by Frank Heckenbach 02 Jun '99

02 Jun '99

Richard Sharman wrote: > The example below shows that sets have the wrong value from the > initialization, but are ok if calcuated or if set in the code. > > var > vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; > > is inconrrect, > > vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; > > works fine. > > I suspect it would work on a low-endian machine, but does not work > on a big-endian. [...] Your observation is correct. We recently discovered that there is a disagreement about the representation of sets (as fields consisting of bytes or words) betweem the frontend and backend. On little-endian machines, this doesn't matter, but on big-endian ones, it's a problem. Since I experienced the problem on a Sun as well, and currently no-one has the time to make a real solution, I made a quick patch (aka kludge)-: for 32-bit big-endian machines. It doesn't change anything on little-endian machines, but it still does not work on 64-bit big-endian machines. The following is for GCC-2.8.1, but might work with EGCS as well (to be applied in the gcc source directory, not the p subdirectory). This is an "unofficial" patch, but your test program works with this patch under sparc-sun-solaris2. --- tree.c.orig Fri Apr 30 04:08:09 1999 +++ tree.c Fri Apr 30 04:13:13 1999 @@ -4801,8 +4801,7 @@ tree vals = TREE_OPERAND (init, 1); int set_word_size = BITS_PER_UNIT; int bit_size = wd_size * set_word_size; - int bit_pos = 0; - unsigned char *bytep = buffer; + int bit_pos = 0, byte_index = 0; char *bit_buffer = (char *) alloca(bit_size); tree non_const_bits = get_set_constructor_bits (init, bit_buffer, bit_size); @@ -4813,14 +4812,18 @@ { if (bit_buffer[i]) { +/* @@@@@@@@@@@ THIS IS A KLUDGE FOR GPC SETS!!! + IT WORKS ONLY FOR 32 BIT BIG-ENDIAN SYSTEMS. + (On little-endian systems, it works correctly.) */ +#define BYTES_PER_WORD 4 if (BYTES_BIG_ENDIAN) - *bytep |= (1 << (set_word_size - 1 - bit_pos)); + buffer [byte_index + BYTES_PER_WORD - 1 - 2 * (byte_index % BYTES_PER_WORD)] |= 1 << bit_pos; else - *bytep |= 1 << bit_pos; + buffer [byte_index] |= 1 << bit_pos; } bit_pos++; if (bit_pos >= set_word_size) - bit_pos = 0, bytep++; + bit_pos = 0, byte_index++; } return non_const_bits; } Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Virtual tables and GPC runtime?
by Frank Heckenbach 02 Jun '99

02 Jun '99

Jo Dillon wrote: > As I've said before on this list, I'm porting an Object Pascal application > to MacOS using a GPC cross-compiler. I've got a sort of minimal > runtime system on the Mac, which enables my application to run - however, > it explodes on (as far as I can see) the first call to a virtual function. > This may be because my implementation of GPC_New/_p_new just looks > like this: > > void * _p_new(int size) > { > return malloc(size); > } > > Whereas the proper one appears to do thinks like mark the object. My question > is, is it the case that I need to fix up the vtbl in _p_new, and if so where > do I do it? Where does marking fit into it? The "marking" mentioned in rts/heap.pas refers to the Mark/Release statements. If you don't use them, you could omit this for now. However, you should probalby check if the return value of malloc() is NULL, and cause a runtime error if so. Actually, can't you just take most of the code in rts/heap.pas (and the little bits in rts/rt0.c? AFAICS, they're essentially based on malloc()/free(), and therefore might work under MacOS as is. But all of this might not have anything to do with the problem you're experiencing... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: GPC BUG: String comparison with less or greater than does not work
by Frank Heckenbach 02 Jun '99

02 Jun '99

pdietrich(a)synstar.de wrote: > GPC cannot compare string with < or >. The following program shows this > fact: > > program test (output); > > var > str1 : string[10] := 'MODULE'; > str2 : string[10] := 'LABEL'; > > begin > writeln ('str1=str2: ', str1=str2); > writeln ('str1<str2: ', str1<str2); > writeln ('str1>str2: ', str1>str2); > end. > > The output of this program is: > > str1=str2: False > str1<str2: False > str1>str2: False There was a bug in the last beta release (only), in that the (non-trimming) '>' and '<=' string operators were mixed up. This will be fixed in the next release. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Virtual tables and GPC runtime?
by Jo Dillon 02 Jun '99

02 Jun '99

As I've said before on this list, I'm porting an Object Pascal application to MacOS using a GPC cross-compiler. I've got a sort of minimal runtime system on the Mac, which enables my application to run - however, it explodes on (as far as I can see) the first call to a virtual function. This may be because my implementation of GPC_New/_p_new just looks like this: void * _p_new(int size) { return malloc(size); } Whereas the proper one appears to do thinks like mark the object. My question is, is it the case that I need to fix up the vtbl in _p_new, and if so where do I do it? Where does marking fit into it? -- Jo

2 1

GPC BUG: String comparison with less or greater than does not work
by pdietrich＠synstar.de 02 Jun '99

02 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: GPC cannot compare string with < or >. The following program shows this fact: program test (output); var str1 : string[10] := 'MODULE'; str2 : string[10] := 'LABEL'; begin writeln ('str1=str2: ', str1=str2); writeln ('str1<str2: ', str1<str2); writeln ('str1>str2: ', str1>str2); end. The output of this program is: str1=str2: False str1<str2: False str1>str2: False

1 0

Initialization of sets in a "var" statement inccorrect on the Sun.
by Richard Sharman 01 Jun '99

01 Jun '99

The example below shows that sets have the wrong value from the initialization, but are ok if calcuated or if set in the code. var vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; is inconrrect, vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; works fine. I suspect it would work on a low-endian machine, but does not work on a big-endian. Dumping the set of vowels shows 44 41 04 00 which I thnk means [ 10 16 22 26 30 ] or [ j p v z ??? ] , whears it should be (and if you read from left you right you get) [ 1 5 9 15 21 ] or [ a e i o u ] . >From the assembly file _Vowels: .ascii "DA\4\0" is incorrect here. For the assigment at line 22 there is inline code with specific ORs rather than moving constants. % cat e.pas program e(input, output) ; type small = 0..10 ; small_set = set of small ; letter = 'a' .. 'z' ; letter_set = set of letter ; var vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; smalls : small_set := [ 1, 3, 5, 7, 9 ] ; c : letter ; i : integer ; begin writeln('vowels #1:') ; for c := 'a' to 'z' do if c in vowels then writeln(c) ; writeln ; vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; writeln('vowels #2 :') ; for c := 'a' to 'z' do if c in vowels then writeln(c) ; writeln ; writeln('smalls #1 :') ; for i := 0 to 10 do if i in smalls then write(i:1, ' ') ; writeln; smalls := [] ; for i := 0 to 10 do if odd(i) then smalls := smalls + [i] ; writeln('smalls #2:') ; for i := 0 to 10 do if i in smalls then write(i:1, ' ') ; writeln; end. % gpc -o e e.pas e.pas: In function `program_E': e.pas:38: warning: constructing limited integer set `0..255' % ./e vowels #1: j p v z vowels #2 : a e i o u smalls #1 : smalls #2: 1 3 5 7 9 % Richard

1 0

Re: can't compile crtc.c
by Frank Heckenbach 01 Jun '99

01 Jun '99

Russ Whitaker wrote: > Thanks > another small step forward > > Now when i compile and run > > program win; > uses CRT; > begin > end. > > i get: > Error opening terminal: linux. > Segmentation fault > > What did i overlook? Somehow the ncurses library doesn't find the Linux terminfo description. That seems quite strange to me on a Linux system... Do other ncurses programs (e.g. yast, vi) cause a similar problem? Did you download the ncurses binary from agnes, or do you use the one that came with your Linux distribution? I think, the latter is preferable, so if you downloaded the binary from agnes, you could try uninstalling it (if you didn't overwrite the other one with it). Can you check if the terminfo file is there and world-readable (on my system, it's /usr/lib/terminfo/l/linux, but it might be another directory, like share or lib/share instead of lib, or /usr/local instead of /usr)? You can also try putting the base directory (without the l, i.e. /usr/share/terminfo in this example) into the environment variable TERMINFO before starting the program. (The binary on agnes, searches in /usr/lib/terminfo, I think, so if it's elsewhere on your system and you have that binary, you might also be able to help it with a symlink.) The good news is that the next release will not segfault, but simply abort with an error status in this situation... :-/ Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: can't compile crtc.c
by Russ Whitaker 01 Jun '99

01 Jun '99

Thanks another small step forward Now when i compile and run program win; uses CRT; begin end. i get: Error opening terminal: linux. Segmentation fault What did i overlook? ---------- > From: Frank Heckenbach <frank(a)tim.gerwinski.de> > To: gpc(a)gnu.de > Subject: Re: can't compile crtc.c > Date: Monday, May 31, 1999 2:10 PM > > We are aware of this problem and are thinking about a "right" > solution. > > As a workaround, please insert the following line into crtc.c before > the first #include: > > #define _GNU_SOURCE

1 0

Re: can't compile crtc.c
by Frank Heckenbach 31 May '99

31 May '99

Russ Whitaker wrote: > changed motherboard from 486 to k6-2/400 > changed system tosuse linux 6.0 > > now crtc.c won't compile: "environ" undeclared > unisted.h is in /usr/include We are aware of this problem and are thinking about a "right" solution. As a workaround, please insert the following line into crtc.c before the first #include: #define _GNU_SOURCE Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: can't compile crtc.c
by Russ Whitaker 31 May '99

31 May '99

addendum: add recompiled gpc after line changed system... incidently, first time tried recompile with CFLAGS="O2" and it crashed in the rts subdirectory just after math.o: cc1 error 6. compiled ok without the CFLAGS ---------- > From: Russ Whitaker <russwhit(a)mind.net> > To: gpc(a)gnu.de > Subject: can't compile crtc.c > Date: Monday, May 31, 1999 11:27 AM > > Hi > > changed motherboard from 486 to k6-2/400 > changed system tosuse linux 6.0 > > now crtc.c won't compile: "environ" undeclared > unisted.h is in /usr/include > > any ideas? > > thanks, > Russ

1 0

can't compile crtc.c
by Russ Whitaker 31 May '99

31 May '99

Hi changed motherboard from 486 to k6-2/400 changed system tosuse linux 6.0 now crtc.c won't compile: "environ" undeclared unisted.h is in /usr/include any ideas? thanks, Russ

1 0

bugs in gpc-19990530-i386-pc-djgppv202.zip
by Maurice Lombardi 31 May '99

31 May '99

Hi all, I have found a couple of bugs after downloading this last version 1) A minor one, already present in the previous beta (january): the specs file is not correct. It seems to be the one used to cross-compile to DOS in your system. The correct one is contained in the gcc2.8.1 distribution of djgpp v2.02 and I have attached it for reference. 2) more serious a new bug (not present in the previous beta) has popped up in the automake process. It occurs when an unit is referred to both directly in the program and indirectly in an other unit as in the following example: ----------------------------------------- file bug.pas ----------------------------------------- program bug; uses u,uu; begin writeln(O,K); end. ------------------------------------------ file u.pas ------------------------------------------ unit u; interface uses uu; var O:string[2] = 'O'; implementation end. ---------------------------------------- file uu.pas ---------------------------------------- unit uu; interface var K: string[2] = 'K'; implementation end. ------------------------------------- compiled with redir -o bug.out -eo gpc -v -g --automake -o bug.exe bug.pas gives the attached bug.out file The error is in the link stage. The files u.o and uu.o are not included in the ld command (as they were in the previous beta). If I include them explicitly with gpc -v -g --automake -o bug.exe u.o uu.o bug.pas all is correct Hope this helps 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr *asm: *asm_final: *cpp: %{posix:-D_POSIX_SOURCE} *cc1: %(cc1_spec) *cc1plus: *endfile: *link: *lib: -lc *libgcc: -lgcc *startfile: crtf.o%s %{pg:gcrt0.o%s}%{!pg:crt0.o%s} *switches_need_spaces: *signed_char: %{funsigned-char:-D__CHAR_UNSIGNED__} *predefines: -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 *cross_compile: 0 *version: 2.8.1 *multilib: . ; *multilib_defaults: *multilib_extra: *multilib_matches: *cpp_cpu: -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) %{mcpu=i486:-Di486} %{m486:-Di486} %{mpentium:-Dpentium -Di586} %{mcpu=pentium:-Dpentium -Di586} %{mpentiumpro:-Dpentiumpro -Di686} %{mcpu=pentiumpro:-Dpentiumpro -Di686} *cc1_cpu: %{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{mno-486:-mcpu=i386 -march=i386} %{m486:-mcpu=i486 -march=i486} %{mno-386:-mcpu=i486 -march=i486} %{mno-pentium:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} %{mno-pentiumpro:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}} *link_command: %{!fsyntax-only: \ %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \ %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\ %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\ %{static:} %{L*} %D %o\ %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\ %{!A:%{!nostdlib:%{!nostartfiles:%E}}}\ -Tdjgpp.djl %{T*}}}}}}} %{!c:%{!M:%{!MM:%{!E:%{!S:stubify %{v} %{o*:%*} %{!o*:a.out} }}}}}

2 1

two problems with gpc, PLEASE HELP ME!!
by Marcos Lois 30 May '99

30 May '99

I use gpc to make practics, in a asignature in the university of =coruña, and the program must run in a solaris machine, with gpc 2.0. I have in my house linux, rh 5.2 with gpc 2.0, and last year in the =university i use sun pascal, to make the practicas and i have a module =to manipulate screen, but now don't work in gpc: procedure CursorXY( x:integer; y:integer); begin write( chr(27), '[', y:0, ';', x:0, 'f'); end; this procedure to put cursor in coordinates xy, dont work on gpc. i need somthing that make this. this other to clear te screen work perfectly: procedure ClearScreen; begin write( chr(27), '[2J'); end; can anybody help me!!! the other problem, is that i use xxgdb to debug pascal programs but when =i wnat to inspect the vaule of a var, i need to write display <var> with =te first letter capitalized, but if i click in the var don't work, no =solution i found to this problem,

2 1

bad link on agnes
by Maurice Lombardi 28 May '99

28 May '99

Hi all The link to the last djgpp version of gpc in the directory gnu-pascal/djgpp on agnes is not correct: instead of gpc20bb -> ../binary/gpc-19990530-i386-pc-djgppv202.zip it should be gpc20bb -> ../beta/binary/gpc-19990530-i386-pc-djgppv202.zip Hope this helps 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

redhat problems
by nhi025＠abdn.ac.uk 27 May '99

27 May '99

Greetings, I unpacked gpc-19990118.i586-pc-linux-gnulibc1.tar.gz, distributed the files and now I can't compile anything at all. I have the same problem that was reported in January 1998 I am having trouble with GPC 971001 on my RedHat linux box. It doesn't compile _anything_, but always gives the following error, regardless of what I try to compile: /tmp/cca00834.i:1: numeric constant with no digits /tmp/cca00834.i:1: numeric constant with no digits /tmp/cca00834.i:1: invalid #line /tmp/cca00834.i:2: warning: missing program header /tmp/cca00834.i:2: parse error at null character the output of gpc 'trig.pas -v' is: Reading specs from /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/specs gpc version 971001(2.7.2.1) /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ trig.pas /tmp/cca00815.i GNU CPP version 971001(2.7.2.1) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i586-unknown-linux/include /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/include /usr/include End of search list. /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc1 /tmp/cca00815.i -quiet -dumpbase trig.pas -version -famtmpfile=trig.gpc -o /tmp/cca00815.s GNU Pascal version 971001(2.7.2.1) (i386 Linux/ELF) compiled by GNU C version 2.7.2.1. /tmp/cca00815.i:1: numeric constant with no digits /tmp/cca00815.i:1: numeric constant with no digits /tmp/cca00815.i:1: invalid #line /tmp/cca00815.i:2: warning: missing program header /tmp/cca00815.i:2: parse error at null character Has there been any progress in fixing this problem? Or is it something silly that I have done in the installation. Please reply to me by e-mail at nhi025(a)abdn.ac.uk Thanks in advance John Ollason

3 2

Re: Restricting posting to the GPC list? (was: SNN - Star Wars - WCLT)
by Frank Heckenbach 26 May '99

26 May '99

Peter Gerwinski wrote: > David James wrote: > > I take it from this that the GPC list doesn't restrict posting to > > members only. Since the SPAM/UCE merchants seem to be everywhere > > would it be a good idea to do this - I believe Majordomo has such a > > capability. > > This would have the drawback that the GPC mailing list could > no more serve as a place to call for help with GPC without > subscribing in the first place. > > Majordomo has some more capabilities that allow to check for > keywords first, so suscipious mails get sorted out and must be > approved by a moderator before further submission. Would it be possible to forward mails that are not from subscribers (and perhaps don't contain clear keywords like `GPC') to a moderator? Since most of the mails are from subscribers, this should eliminate all spam, without causing very much work for a moderator... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 3

GPC Html Docs for ver 19990409
by GPC on Ken Linder's Linux Box 23 May '99

23 May '99

Hi All, I have just successfuly brought up my own little WWW server & have placed the html docs to the latest ver (19990409) on it. Also, I have a rather strange itch to scratch by adding information to the docs and sort of 'fleshing' them out. I will post the newest html docs on my server, along with diff -u files of the originating .texi files, a change log, and soon... tar'd & gzipped html documentation files. Take a look at the server at http://kc7rad.lvcm.com/gpc/index.html If you have any questions or comments, send them to pas(a)kc7rad.lvcm.com or ken(a)kc7rad.lvcm.com Please note that this server is under construction and you may hit a link that points to nowhere. These will be resolved shortly. Thanks! Ken Linder

1 0

Re: Problem exporting enumerated type from Extended Pascal module
by david＠tcs01.demon.co.uk 22 May '99

22 May '99

In message <19990522190631.C292(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > I can reproduce this bug. This is one more instance of the > "two-interface problem" (see http://fjf.gnu.de/gpc-todo_2.html: > baby.pas et al.). > > Thanks for the detailed report. (-: You're welcome ... > > Since I am currently working on related parts of the compiler > there is some hope to have it fixed in the next snapshot. It would be wonderful if it was - this is a showstopper for me in using Extended Pascal modules; I could probably move to units, but that's quite a lot of extra work as the existing code is in modules. Will the next snapshot be in the alpha subdirectory? Do you have any estimate of when it might be? -- David James mailto:david@tcs01.demon.co.uk

2 1

Problem exporting enumerated type from Extended Pascal module
by david＠tcs01.demon.co.uk 22 May '99

22 May '99

I think I'm seeing a problem in exporting an enumerated type from an Extended Pascal module. My system is RedHat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. gpc -v reports as follows: ---------------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 -------------------------------------------------------------------- Below is a small module (dajmod2.p) and a program (daj2.p) which imports it. These have been cut down from a much bigger piece of code. When compiling daj2.p the compiler reports: -------------------------------------------------------------------- daj2.p: In function `program_Daj2': daj2.p:7: incompatible types in assignment daj2.p:8: invalid operands to binary = -------------------------------------------------------------------- 8<---- daj2.p ------------------------------------------------------ program daj2; import progtypes in 'dajmod2.p'; globalvars in 'dajmod2.p'; begin pgmtype:=prog_press; if (pgmtype=prog_press) then writeln('OK') else writeln('Error'); end. 8<--- dajmod2.p ----------------------------------------------------- module dajmod2 interface; export progtypes =(tprogtype, prog_none..prog_last); globalvars =(pgmtype); TYPE TPROGTYPE=(prog_none, prog_press, prog_last); VAR pgmtype:tprogtype; end. {of module header} module dajmod2 implementation; end. {of module implentation} -------------------------------------------------------------------- If I embed just the TYPE and VAR declarations from dajmod2 within daj2, the program compiles and runs correctly. -- David James mailto:david@tcs01.demon.co.uk

3 3

Re: Rhide and gpc
by Frank Heckenbach 22 May '99

22 May '99

Olivier PECHEUX wrote: > I have loaded the gpc (5/99). I use rhide and windoze. And I have > troubles: > When I compile, Rhide call > "gpc -o etape.exe --automake="-g" -g etape.pas -lm -lgpc" > > First, --automake="-g" aren't in the documentation and I have the > message > "ignoring AutoMake option -g"; This was changed in the last release of GPC. Instead of `--automake="-g" -g', you should now simply say `--automake -g' (i.e., no need to repeat the options for automake). > Is it possible to change the call? If you have the RHIDE source and can compile it, it should be easy to change the GPC invocation. Otherwise you'd have to ask Robert, the RHIDE author, to do it. > Second: with the -lgpc the program dosn't reconize the gpc librairie > (GPC_randomize is't reconize at all). But if I put "uses gpc" it does. > Why? > > Third: What does mean -lm? Is there an m librarie? There is a difference between libraries and units/modules. Libraries are originally a C concept -- they consist only of object code without any interface declarations (these are in header files in C), while Pascal units/modules consist of code and declarations. GNU Pascal can use libraries with `-l' switches, but this only provides the object code, not the interface declarations. E.g., the GPC Run Time System is in libgpc.a which is linked with the `-lgpc' switch. However, to make available the declarations, you have to use the unit GPC (which is in gpc.pas), as you noticed. (BTW, don't use GPC_Randomize in your programs. It's an internal routine. The compiler knows `Randomize' which will ultimately call GPC_Randomize, but is more portable. For `Randomize', you don't even have to use GPC, but for other declarations, you do.) Similarly, there's a math libarary (libm.a, -lm) which contains routines like sin and cos. For them, you don't need to use any unit, because the compiler knows about them. Actually, GPC knows already that it needs -lgpc and -lm, so one doesn't have to specify those two libraries explicitly (and this has been so for a few years at least). I don't know why RHIDE adds them, but that's unnecessary. To put it shortly, don't worry about libraries (i.e., `-lfoo' options). Just use the units you want, and you should be fine. This also holds for units like CRT which need additional libraries (curses), because they take care of the libraries automatically. > When I compile a librairie, I have an "undefinied reference to main" > message. For now I ignore it because it's work. What is your position? > What I have to do? I suppose you mean a unit. Indeed, it doesn't cause any problems except this error message, but you can give the `-c' option, and the message will disappear. (Perhaps in the future, you won't need `-c', but currently, you do.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

info
by GPC Pascal on Linux User 22 May '99

22 May '99

info

1 0

Rhide and gpc
by Olivier PECHEUX 21 May '99

21 May '99

Hi, ----------------------- I have loaded the gpc (5/99). I use rhide and windoze. And I have troubles: When I compile, Rhide call "gpc -o etape.exe --automake="-g" -g etape.pas -lm -lgpc" First, --automake="-g" aren't in the documentation and I have the message "ignoring AutoMake option -g"; Is it possible to change the call? Second: with the -lgpc the program dosn't reconize the gpc librairie (GPC_randomize is't reconize at all). But if I put "uses gpc" it does. Why? Third: What does mean -lm? Is there an m librarie? ------------------- When I compile a librairie, I have an "undefinied reference to main" message. For now I ignore it because it's work. What is your position? What I have to do? ------------------- I inform also that there is a french maling list on the Pascal and on the gnu: http://www.onelist.com/subscribe/prog_pascal_gnu --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux Abonnez-vous aux listes francaises: - Assembleur: http://www.onelist.com/subscribe/prog_nasm - C : http://www.onelist.com/subscribe/prog_c_gnu - Pascal : http://www.onelist.com/subscribe/prog_pascal_gnu

1 0

Re: Restricting posting to the GPC list? (was: SNN - Star Wars - WCLT)
by Nick Burrett 20 May '99

20 May '99

Frank Heckenbach <frank(a)tim.gerwinski.de> writes: > Peter Gerwinski wrote: > > > David James wrote: > > > I take it from this that the GPC list doesn't restrict posting to > > > members only. Since the SPAM/UCE merchants seem to be everywhere > > > would it be a good idea to do this - I believe Majordomo has such a > > > capability. > > > > This would have the drawback that the GPC mailing list could > > no more serve as a place to call for help with GPC without > > subscribing in the first place. > > > > Majordomo has some more capabilities that allow to check for > > keywords first, so suscipious mails get sorted out and must be > > approved by a moderator before further submission. > > Would it be possible to forward mails that are not from subscribers > (and perhaps don't contain clear keywords like `GPC') to a > moderator? Since most of the mails are from subscribers, this should > eliminate all spam, without causing very much work for a > moderator... One solution, that is used by the egcs.cygnus.com mail server, is to modify the mail delivery agent to check addresses against MAPS RBL and ORBS. This is quite easy if your MDA is sendmail 8.9. Nick.

1 0

Re: SNN - Star Wars - WCLT
by david＠tcs01.demon.co.uk 19 May '99

19 May '99

In message <359DFE77.4AC9(a)erols.com> oho87(a)jboy.com writes: > StockNetworking News > [etc., etc., etc] I take it from this that the GPC list doesn't restrict posting to members only. Since the SPAM/UCE merchants seem to be everywhere would it be a good idea to do this - I believe Majordomo has such a capability. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: GPC for AIX 4.3.1
by Frank Heckenbach 19 May '99

19 May '99

Marina Markus wrote: > stage1/xgcc -Bstage1/ -c -Wall -Wpointer-arith -Wmissing-prototypes > -Wmissing-declarations -O2 -g -O2 -I. -I../.. -I/usr/local/src/egcs-1.1.2/ > gcc/p/rts/../.. -I/usr/local/src/egcs-1.1.2/gcc/p/rts/../../config /usr/loc > al/src/egcs-1.1.2/gcc/p/rts/pexecute.c > In file included from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2. > 91.66/include/sys/wait.h:49, > from /usr/local/src/egcs-1.1.2/gcc/p/rts/pexecute.c:38: > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:121: warning: `SIGEMT' redefined > rts-config.h:182: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:126: warning: `SIGSYS' redefined > rts-config.h:178: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:130: warning: `SIGURG' redefined > rts-config.h:186: warning: this is the location of the previous definition > /usr/local/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/egcs-2.91.66/include/sys/sign > al.h:164: warning: `SIGIOT' redefined > rts-config.h:190: warning: this is the location of the previous definition To get rid of the warnings, you can insert #include <signal.h> into rts/pexecute.c, before the line #include "rts-config.h" > make: Cannot find a rule to create target heap.o from dependencies. > Stop. I think the problem is that the RTS makefile uses "pattern rules" which your version of make does not understand. So you can either use GNU make, or replace %.o:%.pas by .SUFFIXES: .pas .pas.o: This should fix the problem. Both things will be fixed in the next snapshot. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

GPC for AIX 4.3.1
by Marina Markus 19 May '99

19 May '99

Hello GPC users ! I need a binary GPC distribution for AIX 4.3.1 operating system. It is absent in collection of binary distributions at GPC site; maybe it exists anywhere else ? Thank you in advance, Marina Markus Ben-Gurion University Computer Center Beer-Sheva, Israel ====================== mary(a)bgumail.bgu.ac.il

2 8

Re: prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 19 May '99

19 May '99

In message <19990512012516.B1546(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > > The problem is at compile-time, attached is a small module which > > exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) > > running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc > > 19990118. > > > > gpc -v gives the following output > > ----------------------------------------------------------------- > > Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs > > gpc version 19990118, based on gcc-2.8.1 > > ----------------------------------------------------------------- > > Thanks for the detailed information. :-) > > Below is a version of your test program that is ready for our > test suite. > > To work around the bug, you can drop the first `protected'. I now have a significantly bigger module (which also imports from several other modules) which is exhibiting the same behaviour "prior parameter's size depends on `foo'" where `foo' is a protected string parameter in the function/procedure declaration. In this case if I drop all the `protected' in the procedure/function declarations in the interface, I get "gpc: Internal compiler error: program gpc1 got fatal signal 6". Any suggestions about more general work-arounds for this problem with string parameters in extended Pascal modules? Converting the extended Pascal module to a unit seems to be a work-around, but having to do that is going to make this migration much more difficult than staying with the extended Pascal modules that the system currently uses. -- David James mailto:david@tcs01.demon.co.uk

2 2

Re: environ
by Frank Heckenbach 17 May '99

17 May '99

Nick Burrett wrote: > > Now, `environ', as the name suggests, contains the current > > environment variables, i.e. the ones that were set when the process > > started plus the ones the process set itself (by setenv() or > > putenv()). > > The `environ' variable only contains the array of strings of the environment > at process startup. It does not change with calls to setenv or putenv. According to my tests, it does change!? > > Another way to get at the environment is the third parameter to > > `main' (which GPC could access internally, that's not a problem). > > However, this variable only contains the environment at the start of > > the process. When the process does some putenv()s, the pointer gets > > invalid (DJGPP), or the environment pointed to just seems to be > > unmodified (the other systems I tested). Perhaps the DJGPP behaviour > > is a bug, I don't know, but in any case the parameter is not useful > > to get the current environment at a later time. > > The third argument to main is equivalent to the `environ' variable and > should point to the same place. Well, not on the systems I tried. The third argument became invalid after putenv (DJGPP), or did not change (other systems). > > So, does anybody know what's the matter with `environ'? Can one just > > declare it as `extern char **environ;' even if it's not declared in > > any header? Or is there another way to get at the current > > environment? > > Yes you can just declare it as `extern char **environ'. There's no > guarantee that `environ' actually exists so just declaring it extern > and using it could give you linker errors. You'd have to find a > solution to this, perhaps using autoconf to check for it's existence > and declaring your own version if it doesn't. I think if I have to write my own version, anyway, I can just as well use it on all systems. I think it would be more consistent then than using a (partially undocumented) libc declaration on some systems and my own version on others. > > If not, in the worst case, this would mean that the GPC RTS has do > > to its own environment handling, i.e. get the initial environment > > for the `main' parameter, and provide its own versions of getenv() > > and putenv() which work on a copy of that. Though it would not be > > terribly much work, I hope to avoid it... > > I don't see why the GPC RTS would need to do it's own environment > handling. Unless you are thinking of the extreme case where the > `getenv', `setenv' and `putenv' functions are missing. Or are you > thinking that a Pascal character array pointer should always point > to an up-to-date environment list ? Yes, I think it should. E.g., in a program of mine, I do some `putenv's, and then I want to pass the up-to-date environment to a child process (started by execve() in the Pipe unit). But I also want to read the (new and old) environment variables via `getenv' in the program itself. So, if `environ' doesn't point to an up-to-date environment, I'd have to do each `putenv' twice, once for the (hidden?) environment that `getenv' uses, and once for my own environment that is given to execve(). I'd consider this quite ugly, and rather than doing this, I'd prefer to write my own versions of putenv, getenv. etc. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: environ
by Nick Burrett 17 May '99

17 May '99

Frank Heckenbach <frank(a)tim.gerwinski.de> writes: > a bug report of a GPC user drew my attention to a possible problem > with the `environ' libc variable (which is currently declared for > Pascal as `Environment' in gpc.pas). > > Now, `environ', as the name suggests, contains the current > environment variables, i.e. the ones that were set when the process > started plus the ones the process set itself (by setenv() or > putenv()). The `environ' variable only contains the array of strings of the environment at process startup. It does not change with calls to setenv or putenv. > Another way to get at the environment is the third parameter to > `main' (which GPC could access internally, that's not a problem). > However, this variable only contains the environment at the start of > the process. When the process does some putenv()s, the pointer gets > invalid (DJGPP), or the environment pointed to just seems to be > unmodified (the other systems I tested). Perhaps the DJGPP behaviour > is a bug, I don't know, but in any case the parameter is not useful > to get the current environment at a later time. The third argument to main is equivalent to the `environ' variable and should point to the same place. > So, does anybody know what's the matter with `environ'? Can one just > declare it as `extern char **environ;' even if it's not declared in > any header? Or is there another way to get at the current > environment? Yes you can just declare it as `extern char **environ'. There's no guarantee that `environ' actually exists so just declaring it extern and using it could give you linker errors. You'd have to find a solution to this, perhaps using autoconf to check for it's existence and declaring your own version if it doesn't. There isn't anything wrong with `environ', you have just misunderstood it slightly. > If not, in the worst case, this would mean that the GPC RTS has do > to its own environment handling, i.e. get the initial environment > for the `main' parameter, and provide its own versions of getenv() > and putenv() which work on a copy of that. Though it would not be > terribly much work, I hope to avoid it... I don't see why the GPC RTS would need to do it's own environment handling. Unless you are thinking of the extreme case where the `getenv', `setenv' and `putenv' functions are missing. Or are you thinking that a Pascal character array pointer should always point to an up-to-date environment list ? Nick.

1 0

Re: Word or Cardinal
by Frank Heckenbach 16 May '99

16 May '99

Olivier PECHEUX wrote: > I want to use the unsigned integers in GPC. If I compile: > > Program Unsigned; > Var i:Word; > Begin > For i:=1 To 10 Do Writeln(i) > End. > > I have the error: > Error:type name expected, identifier 'Word' given > > If I replace Word by Integer, that's OK. I try Cardinal insted of Word, > it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows > machine Please upgrade to a newer GPC, version 2.0 is very old. The last beta version (19990118) can be found at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/ It supports both Word and Cardinal. They're equivalent -- which one you use is up to your preference. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Word or Cardinal
by Olivier PECHEUX 16 May '99

16 May '99

Hi, I want to use the unsigned integers in GPC. If I compile: Program Unsigned; Var i:Word; Begin For i:=1 To 10 Do Writeln(i) End. I have the error: Error:type name expected, identifier 'Word' given If I replace Word by Integer, that's OK. I try Cardinal insted of Word, it does'n work. I'm using the GPC of gpc20b.zip and rhide on a windows machine What's wrong? Olivier. -- --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux

1 0

Re: help...
by Russ Whitaker 15 May '99

15 May '99

Qyrano writes: > Subject: help... > Date: Friday, May 14, 1999 3:25 PM > > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... > > Roberto you can download gmp from ftp://metalab.unc.edu/pub/gnu/gmp thanks Russ

1 0

Re: help...
by Frank Heckenbach 15 May '99

15 May '99

Qyrano wrote: > $ gpc factorial.pas > > ld> cannot open -lgmp: No such file or directory > > (demo program factorial.pas uses units gpc and gmp....) > > Can someone help me to solve this trouble?..... You need the GMP library, available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ You'll also need the rx library for the RegEx unit and the ncurses (Unix/terminal) or `curse' (Unix/X11, DJGPP) library for the CRT unit. There are sources and binaries for some systems. If you're using a system for which there are no binaries yet, and you compile the libraries, we'd appreciate if you upload a binary. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

help...
by Qyrano 14 May '99

14 May '99

$ gpc factorial.pas ld> cannot open -lgmp: No such file or directory (demo program factorial.pas uses units gpc and gmp....) Can someone help me to solve this trouble?..... Roberto

1 0

Re: Relationship between GPC and GCC on Linux (Compiling)
by Frank Heckenbach 14 May '99

14 May '99

Jose Romildo Malaquias wrote: > 2. The compilation goes smoothly. Installation too. But should > I keep the files > /usr/lib/gcc-lib/i386-redhat-linux/2.8.1/{libgcc.a,spec} > or they can be safely removed (and then GPC uses the ones > from the EGCS installation)? I think they can safely be removed -- for now. Currently, as you correctly noted, it is necessary to have the same version of GCC as of GPC. In the future, we hope to relax this restriction so GPC will work with any GCC version installed. If that's a different version, there won't be libgcc.a and specs in GPC's directory, so the files from GPC should be kept. But if it's the same version, the files from GCC should probably be used. This might be a problem. Does RPM provide a way to handle such situations? > I have worked out rpm packages for the latest GPC beta. As I am not > an experienced GPC user, would somebody take a look at the spec file > and comment it. I'm not familiar with RPM specs, so I won't comment on them. Just two points: : Copyright: GPL If you want to be very precise, you could add LGPL (which holds for the run time system) here. : Url: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ http://home.pages.de/~GNU-Pascal/ is preferable. Currently, it points to the same URL, but if the former should ever change, the latter will remain the same. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Learning Pascal (II)
by Frank Heckenbach 14 May '99

14 May '99

J Horacio MG wrote: > As I commented earlier, my only source for Pascal programming > information for a beginner is a short course of Borland Turbo Pascal in > windoze. I too have installed the Gnu Pascal Compiler in Linux, so I > thought it would be possible to learn with the former to use latest. > > Is there any document that explains (from scratch) the very basic > differences between one and another? I hope you will excuse my lack of > knowledge, but as I said these are my very first attempts to learning > programming at all. The GPC documentation contains a chapter about most of the differences and the degree of compatibility to BP. You can type info -f gpc -n "Borland Pascal" to read it (or an equivalent in your favourite info reader, e.g. `(gpc)Borland Pascal' in the RHIDE help). > Now, from the very first basic program (I guess sort of C's "hello > world"): > > Program saludo; > Uses WinCrt; > Begin > > {1} WriteLn ('Hola Mundo'); > > End. Ken Linder $KC7RAD$ replied: > The WinCrt unit in Turbo Pascal is just a set of functions that allow a > turbo Pascal for Windows program to work in a console (DOS) type window > under Windows. In Linux/GPC this is not necessary. That's correct, but since there are some misconceptions about the (Win)Crt unit in the BP world, let me say a few words to clarify the situation: The Dos version of Borland Pascal contains a Crt unit which provides things like text colors, cursor positioning, text windows, reading of single keys (not only whole lines), etc. To accomplish that, it takes over control of Input and Output (i.e., of Read[ln], Write[ln] statements that are not explicitly applied to other files), while in programs without Crt, Input and Output go to the standard input/output of the process, which are connected to the terminal, unless redirected, e.g. `program < inputfile > outputfile'. Unfortunately, many BP programmers have the habit of using Crt in each and every program, whether or not it needs its features. However, using Crt unnecessarily has some disadvantages, e.g. that input/output of such programs can't easily be redirected, the program gets bigger -- and BP's Crt unit contains a famous bug... Now, under windoze, AFAIK, there is no terminal, and therefore standard input/output are not connected by default. That's why the windoze version of BP provides this `WinCrt' unit which emulates a terminal and provides some (but by far not all) routines of the Crt unit (e.g., no colors). Now, for GPC: Since the last release (19990118), GPC contains a CRT unit which contains all the functionality from BP's Crt unit (and more). Like BP's unit, it has to take over Input and Output to do its job. It works on all Unix systems (and especially well on Linux/x86 :-), and on DJGPP. It probably will also work on windoze (mingw) and OS/2 (EMX), but someone would have to compile the PDCurses library (which it uses internally on these platforms), and perhaps make a few little adaptions in the CRT unit, but this shouldn't be hard. (BTW, if a mingw or EMX user could do this, and forward the library binary and any changes necessary in CRT to us, we could include them in the official distribution.) Therefore, GPC will not need a `WinCrt' unit, since its CRT unit will simply work on those systems... What I said above for BP, that using Crt unnecessarily has some disadvantages, holds for GPC as well (actually even more so, since the ability to redirect input/output is more valued under Unix than under Dos). So, when porting from BP/windoze to GPC, one can simply replace `WinCrt' by `CRT'. But one should think twice if CRT is really needed at all -- one can just remove the `uses WinCrt', and if this leads to undefined identifiers, insert `uses CRT'. In principle, we could provide a WinCrt unit for GPC which is identical to CRT, but apart from the fact that that's wasted space (at least on Dos where there are no symbolic or hard links), this would often lead to unnecessary uses of CRT which should be avoided. Therefore, I'd prefer to intentionally not provide a WinCrt unit for GPC. But we should probably include a section in the documentation about this issue... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

environ
by Frank Heckenbach 14 May '99

14 May '99

Hi, a bug report of a GPC user drew my attention to a possible problem with the `environ' libc variable (which is currently declared for Pascal as `Environment' in gpc.pas). After some research I found that Linux/libc5 (which I'm using) seems to be the only system which has environ declared in <unistd.h>. Linux/glibc declares it, but only if `_GNU_SOURCE' is defined. All the other systems I tried (DJGPP, Solaris, Irix) don't declare the variable, but still have it, i.e. when I declare it as `extern' manually, it is there. (Yeah, that's C...) Now, `environ', as the name suggests, contains the current environment variables, i.e. the ones that were set when the process started plus the ones the process set itself (by setenv() or putenv()). Another way to get at the environment is the third parameter to `main' (which GPC could access internally, that's not a problem). However, this variable only contains the environment at the start of the process. When the process does some putenv()s, the pointer gets invalid (DJGPP), or the environment pointed to just seems to be unmodified (the other systems I tested). Perhaps the DJGPP behaviour is a bug, I don't know, but in any case the parameter is not useful to get the current environment at a later time. So, does anybody know what's the matter with `environ'? Can one just declare it as `extern char **environ;' even if it's not declared in any header? Or is there another way to get at the current environment? If not, in the worst case, this would mean that the GPC RTS has do to its own environment handling, i.e. get the initial environment for the `main' parameter, and provide its own versions of getenv() and putenv() which work on a copy of that. Though it would not be terribly much work, I hope to avoid it... The following C (sorry;-) program demonstrates the effect. It will first print `environ', then the environment pointed to by the third parameter, at the start of the program (these should be identical), then do 1000 putenv()s (it can take quite a few of them to make the problem apparent ;-), then print `environ' again (which does contain the new variables on all systems I tried), and the parameter again (which does not show any changes, and under DJGPP even crashes the program). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <string.h> /* Not necessary under Linux/libc5, but doesn't hurt there, either */ extern char **environ; int main (int argc, char **argv, char **env) { char **a, b [10]; (void)argc;(void)argv; for (a = environ; *a; a++) printf ("%s ", *a); printf("\n"); for (a = env; *a; a++) printf ("%s ", *a); printf("\n"); strcpy (b, "f000=bar"); for (b [1] = '0'; b [1] <= '9'; b [1]++) for (b [2] = '0'; b [2] <= '9'; b [2]++) for (b [3] = '0'; b [3] <= '9'; b [3]++) putenv (strdup (b)); for (a = environ; *a; a++) printf ("%s ", *a); printf("\n"); fflush (stdout); for (a = env; *a; a++) printf ("%s ", *a); printf("\n"); return 0; }

1 0

Learning Pascal (II)
by J Horacio MG 14 May '99

14 May '99

As I commented earlier, my only source for Pascal programming information for a beginner is a short course of Borland Turbo Pascal in windoze. I too have installed the Gnu Pascal Compiler in Linux, so I thought it would be possible to learn with the former to use latest. Is there any document that explains (from scratch) the very basic differences between one and another? I hope you will excuse my lack of knowledge, but as I said these are my very first attempts to learning programming at all. Now, from the very first basic program (I guess sort of C's "hello world"): Program saludo; Uses WinCrt; Begin {1} WriteLn ('Hola Mundo'); End. I can only guess that the above syntax is correct both in windoze and Linux, except for the include file "WinCrt", but... how can I implement these for Unix/Linux? TIA Horacio

2 1

Re: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > Peter Gerwinski <peter(a)gerwinski.de> wrote: > > > > Sounds mostly okay - except that with Win32, a DLL does not need to > > > have the extension '.dll' (for example, Win32 device drivers are just > > > DLLs with the same interface, and with the extension '.drv' ). A > > > Win32 DLL can have any extension, or no extension at all. Thus it > > > might be that the extension will need to be specified. On the other > > > hand, I suppose that perhaps GPC can presume the extension '.dll' > > > unless another extension is suppled. However, how do you then deal > > > with a case where someone has written a DLL but does not want to give > > > it any extension? > > > > Let GPC first search for the name 'foo' as given, second for > > 'foo.dll' or 'libfoo.so' (depending on the OS) and last for > > 'libfoo.a'. > > Perhaps we are talking at cross-purposes here! The Win32 problem > will occur not a compile or link time, but at runtime, when the > program is trying to link to the DLL. I am not sure whose job it is > to search for the DLL at this point - whether it is the compiler's > job or the OS (I suspect that it is the job of the OS which should > then raise an exception if it cannot find the DLL). Indeed, it's not the compiler that searches for the libraries, but the (static or dynamic) linker. As it is now, `{$L filename.ext}' will: - pass `filename.ext' to the linker, if `.ext' is a known linker extension, currently `.o', `.a', `.so', `.lnk', - pass `-l filename' to the linker if `.ext' is missing. The linker will then search for a (static or dynamic) library called `filename' with the appropriate extension (i.e., `.a' for static and `.so' for dynamic libraries -- I suppose the windoze linker will search for `.dll' rather than `.so'), - pass a filename with any other extension to the compiler (with automake). The most common case here is `.c' to compile and link C code. So, this mechanism currently does not allow arbitrary linker extensions. We could turn it around, so that only known source extensions (`.pas', `.p', `.c', `.cc', `.i', `.S', perhaps `.f' (Fortran?) etc.) are passed to the compiler, and all other extensions to the linker. This would then only prevent a linker file with a source extension (but who would want to give a binary such an extension ;-), and without an extension (because that's reserved for `-l'). If the latter is a real issue, we might have to change the syntax for the second case (`{$L foo}' -> `-l foo'), which I'd consider unfortunate, since it's the most common one besides `{$L foo.c}'. BTW, using `-l foo' (or `{$L foo}' or later "external 'foo'") is preferable over `foo.a' (or `{$L foo.a}', or "external 'foo.dll'", etc.) for several reasons: `-l' will search the library path (`-L'), will find static or dynamic libraries, taking into account the `-static' switch, and can use the appropriate extensions (e.g. `.so' or `.dll'). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > > Instead of "Foobar" for an identifier `FooBar' declared in a > > unit/module `Baz', we could probably use `baz.foobar' (or > > `baz$foobar'), all lower-case, without risking name clashes with the > > libc. > > Since such routines should be calleable from programs with the > declaration "baz.foobar", it might be that the dot notation would be > preferable to the "$" notation (but of course, it might not make any > difference to the compiler which notation is used internally). Indeed, these two things are not bound to each other. In Pascal, it will be calleable as `baz.foobar' in any case (required by Extended Pascal and Borland Pascal, and the only reasonable thing, anyway, since `$' already has a different meaning in BP and GPC). > > For the external declarations, my suggestions is: > > Procedure Foo; external; (* extern void foo ( void ); *) > > > > (I.e., `external' will convert the name to lower-case, without the > > module name prefix.) > > > > Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) > > > > I've heard Delphi has something like this (`external' and `name'). > > Is it the same syntax, or what does it look like in Delphi? > > Delphi has the same notation, with the same syntax as above, used in > the context of *importing* routines from dynamic link libraries > (DLLs). Normally the DLL's name will be in-between "external" and > "name" -e.g., > > Procedure FooBar; external 'barfoo.dll' name 'FooBar'; I think we could do the same, with the 'barfoo.dll' being optional (is it optional in Delphi as well?). If it's omitted, the compiler will assume the library or object file which contains the routine to be linked by other means (e.g., other `external' statements, `{$L barfoo}' directives, or on the command line). Furthermore, I think we should drop the `.dll', i.e. just have external 'barfoo', to link `barfoo.dll' on Win32, and `barfoo.so' on Unix, or `barfoo.a' on any system. IOW, it's equivalent to `{$L barfoo}'. Also, we should allow "external 'foo.o'" to link an object file,', "external 'foo.c'" for C files etc. (which is also completely equivalent to the `{$L}' directive). > A slightly similar notation also exists for *exporting* routines from > DLLs, in which case it has to be used in a separate "EXPORTS" section > at the end of the DLL source (instead of the point where the function > is declared) - e.g., > > Library barfoo; > > Procedure foobar; > Begin > // blah, blah > End; > > Function foofoo : integer; > Begin > Result := -22; > End; > > EXPORTS > foobar name 'FooBar', > foofoo index 1 name 'FooFOO'; // index is optional > > Begin > End. > > I am not sure if (and if so, how) these should be supported by GPC. I think there should be some way to declare libraries in GPC, but we haven't made any design plans for them yet. Also I suppose they'll not be implemented too soon, since there are more urgent things to do, and it's possible (already now) to build libraries with a little bit of extra work, i.e. declare the public routines with `asmname' (later perhaps `name') directives, compile them with `-c', and build a library of them (with `ar' for static libraries and `gpc -shared' for dynamic ones). The problem I see with the syntax above is that the external name declaration is at the end. I doubt whether GPC can could with that well since AFAIK it expects to know the external name when it compiles a routine. Perhaps it could use a temporary name while compiling the routine, and declare the real external name as an alias of that temporary name later, but I'm not too sure if that's possible. If that's not possible, then perhaps a GPC library could look somewhat like a unit, i.e. library foo; interface procedure foobar; name 'FooBar'; implementation procedure foobar; begin end; end. This would not be so much different from what we have already, and therefore probably be easier to realize. > Note: > Identifiers exported in this way are case-sensitive when you want > to import the DLL functions with the "name" declaration. This is not > a Delphi thing but a Win32 thing, so GPC does not need to (and > probably should not) seek to copy that behaviour. `asmname' currently is case-sensitive, and so will `name' be. In order to interface to C code, we don't actually have another choice, because C identifiers are case-sensitive. > In any case, AFAIK, > DLLs are only relevant to OS/2 and Win32, so this may not be an issue > of serious concern. They're only called "DLL" on OS/2 and Win32, but dynamic libraries exist on any platform I know except DJGPP (and perhaps EMX for Dos?). Besides, I don't think we should make a distinction between static and dynamic libraries as far as the program directives are concerned, i.e. let "external 'foobar'" link foobar.dll, foobar.so or foobar.a, whichever is appropriate for the target system and exists (see above). In fact, one can (already now) use the `-static' switch to link the static versions of all libraries rather than the dynamic ones, without changing anything in the source. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 4

Linking problems
by Peter Gerwinski 13 May '99

13 May '99

Hi, folks! Any linker experts out there? When I `ar' together a bulk of `.o' files compiled with GPC, I get lots of undefined references between the `.o's in the `.a'. The same compilation with `--autobuild' works. Any ideas what I am doing wrong? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 1

Re: integration of GPC into EGCS
by David Edelsohn 13 May '99

13 May '99

>>>>> Peter Gerwinski writes: Peter> This task involves changes to the EGCS backend which must Peter> be coordinated with the other EGCS developers. In earlier Peter> cases our very small suggestions were not accepted, so I do Peter> not really expect our major requirements to make it into the Peter> EGCS main line. The issue is whether something you need changed is the right way to accomodate that feature. We are trying to support all languages and compromise will be necessary. Given the broad, portable use of the compiler and common backend, changes need to be general where appropriate and consistent with maintainability. I have not seen all of the GPC changes, so I am not implying anything about their quality or correctness, just commenting on the broader goals that need to be achieved as part of incorporating GPC. David

1 0

Re: integration of GPC into EGCS
by Peter Gerwinski 12 May '99

12 May '99

Alexander V. Voinov wrote: > Are there any plans to *fully* integrate GNU Pascal into the main EGCS > source tree as is done for G77? Yes. > I.e. I mean to have GPC as a true proper > subtree of egcs as g77 is, and to find it by default in all stable and > experimental versions of egcs. For example, that moment one has > egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is > compatible only with the 1.1.1. Of course, but this also means some work - to get GPC integrated into EGCS, (This task involves changes to the EGCS backend which must be coordinated with the other EGCS developers. In earlier cases our very small suggestions were not accepted, so I do not really expect our major requirements to make it into the EGCS main line.) - to keep track with EGCS development, - not to lose support for stable releases (gcc-2.8.1, egcs-1.1.x). Due to a big lack of human resources we currently do not feel able to perform this task - although it is on our schedule. Help welcome! Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

integration of GPC into EGCS
by Alexander V. Voinov 12 May '99

12 May '99

Dear Colleagues, Are there any plans to *fully* integrate GNU Pascal into the main EGCS source tree as is done for G77? I.e. I mean to have GPC as a true proper subtree of egcs as g77 is, and to find it by default in all stable and experimental versions of egcs. For example, that moment one has egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is compatible only with the 1.1.1. Thank you in advance Alexander

1 0

Learning Pascal
by J Horacio MG 12 May '99

12 May '99

Greetings, I'd like to learn programming, and been asking around for recommendations. A vast majority suggested to learn C and then C++, but I've also been strongly suggested starting with a "well structured language" like Pascal before anything else. I don't fully understand the meaning of this, and would like some guidance for starting with Pascal. Actually this sounds as if C was about programming, and Pascal just a step towards it. I've tried to look for documentation both online/downloadable and books, and though I've found loads for C/C++, almost nothing for Pascal. All I have is a small course (with Borland programs) in windoze for Turbo Pascal, which means I've been forced to install windoze while my OS is Debian. I'm concerned that this Turbo Pascal course may not help me with learning Pascal with GPC... may be it can help me learning the basics? I would appreciate any suggestions, tips, pointers to docs and books,... and comments to the above. Thank You in Advanced, Horacio.

2 1

Re: Two GNU Pascal ideas
by Frank Heckenbach 12 May '99

12 May '99

Peter Gerwinski wrote: > > 3. Have some extension to indicate C linkage (like C++ and > > some C compilers do). Maybe an extension or alternative > > to the EXTERNAL keyword. > > This already exists. See `info -f gpc -n "Other languages"'. > > Procedure Foo; C; (* extern void foo ( void ); *) > > Procedure FooBar; asmname 'FooBar'; (* extern void FooBar ( void ); *) I should mention that we're thinking about changing the syntax of external declarations and the internal names of Pascal identifiers soon. In order to allow the same identifier in different units/modules (which is required by both the Standard and Borland Pascal and which GPC currently doesn't support), we need to change the "name mangling", anyway. Instead of "Foobar" for an identifier `FooBar' declared in a unit/module `Baz', we could probably use `baz.foobar' (or `baz$foobar'), all lower-case, without risking name clashes with the libc. For the external declarations, my suggestions is: Procedure Foo; external; (* extern void foo ( void ); *) (I.e., `external' will convert the name to lower-case, without the module name prefix.) Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) I've heard Delphi has something like this (`external' and `name'). Is it the same syntax, or what does it look like in Delphi? BTW, we could then also have: Procedure FooBar; name 'FooBar'; begin end; to declare a Pascal procedure with a given internal name, instead of the "strange" form that is now necessary: Procedure FooBar; asmname 'FooBar'; Procedure FooBar; begin end; These are just ideas right now. Any comments? Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

Interested about GNU Pascal development
by GrimReaperX 12 May '99

12 May '99

Hi, I am a 19 years old college student. I study programming. I like Linux/Unix* alot because of the open-source concept and also because these OS are highly configurable and customizable. I run RedHat 5.2 on a i386 machine (Pentium 166MhZ, 48MB ram) and If you need to traduct english-to-french or french-to-english feel free to ask me :) I can also do alpha/beta testings. This far, my teachers only showed us the basics of Pascal (Console..) and some C. But as my studies advances I will get better. In fact, I am willing to do whatever I can to help Linux/Unix*/GNU to grow. (Little anger toward microsoft....well let's rather say some hatred ;) reboot-reboot reboot) I live in Quebec, Canada. Cya soon! Pierre-Luc Vincent a.k.a. GrimReaperX grimreaperx(a)usa.net

3 3

Re: prior parameter's size depends on `foo'
by Frank Heckenbach 12 May '99

12 May '99

David James wrote: > There may well already be a provided routine to do this (return the > last i characters of a string), and if there is, I'd be grateful for > a pointer to it, but even so I think I'd still like to be able to > write similar procedures/functions. The functions `Copy' and `SubStr', when called with 2 parameters s and i, return all the characters of s starting from the i'th. The difference is that `SubStr' causes a runtime error when i < 1 or i > Length (s), while `Copy' returns the empty string then. So, to get the last i characters of s, you can use `Copy (s, Length (s) - i + 1)', or if you want to accept i > Length (s) here and get the whole string then, you could do `Copy (s, Max (1, Length (s) - i + 1))'. Peter Gerwinski wrote: > * In this example we are mixing Extended Pascal modules with > UCSD (Borland) Pascal units. EP wants `import' instead of > `uses'. > > While GPC accepts all this, it is maybe better to stick to one > flavour of modularized Pascal programming which means either > EP-style modules or UCSD-style unit, but not a mixture. He did `uses gpc;' which is correct since gpc.pas is indeed a unit (and is not available as a module). So I think it's alright to mix this unit with modules. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

In message <19990511213235.C1105(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > You probably stumbled about a bug in GPC. > > To help us to fix GPC it would be best if you reduced the > problem to a program `david1.pas' which > > * is as short as possible, > > * reproduces the bug, > > * and is intended to writeln 'OK' if no bug > occured and something else otherwise. The problem is at compile-time, attached is a small module which exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc 19990118. gpc -v gives the following output ----------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 ----------------------------------------------------------------- Compiling the following module with gpc -c dajmod.p gives the output shown below file dajmod.p: ----------------------------------------------------------------- module dajmod1 interface; export dajmod = (str_tail); procedure str_tail(protected source:string;protected i:integer;var dest:string); end. module dajmod1 implementation; uses gpc; var s1,s2:string(255); i:integer; procedure str_tail; var s2:string(255); begin (*str_tail*) if (length(source)=0) or (i<1) or (i>length(source)) then dest:='' else begin moveleft(source[length(source)-i+1], s2[1], i); (*$x+*) setlength(s2,i); (*$x-*) dest:=s2; end; end; (*str_tail*) end. ----------------------------------------------------------------- Output from compiler: dajmod.p: In function `Str_tail': dajmod.p:9: prior parameter's size depends on `Source' ----------------------------------------------------------------- There may well already be a provided routine to do this (return the last i characters of a string), and if there is, I'd be grateful for a pointer to it, but even so I think I'd still like to be able to write similar procedures/functions. -- David James mailto:david@tcs01.demon.co.uk

2 1

Re: Fw: gcc-19990330
by Frank Heckenbach 11 May '99

11 May '99

J. David Bryan wrote: > > > > p.s. think "Trim" should trim both spaces and tab chrs > > > > ( now only spaces) low priority wish list > > > > What does the standard say about this? (`Trim' is a predefined > > function of the standard, so we have to care about the standard > > here.) > > Section 6.7.6.7 (String functions) in ISO 10206 (Extended Pascal) says for > "Trim": > > ...the function shall yield the value of substr(sv,1,p-1), where p is > the least value in the closed interval 1..n such that each component of > sv[p..n] is the char-type value space. > > So "Trim" only trims spaces. > > > > Alternatively (if the standard wants only spaces), we could also make a > > different routine for spaces and tabs... > > A different function would be the proper implementation. I just noticed that the (non-standard) GPC procedures TrimLeft/TrimRight/TrimBoth and the equivalent functions TrimLeftStr/TrimRightStr/TrimBothStr do trim both spaces and tabs. So I suppose they can be used here. Or are there any votes for making them trim only spaces like Trim does? BTW, the same effect (trim all leading "space characters" (spaces and tabs)) could also be realized by: uses GPC; const NoSpaceCharacters = [Low (Char) .. High (Char)] - SpaceCharacters; ... foo := Copy (s, CharPos (NoSpaceCharacters, s)) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bash
by Frank Heckenbach 11 May '99

11 May '99

Russ Whitaker wrote: > hi frank > > i'm not a bash expert either: it took me 2 hours to come up with the > following > > enter the following 6 lines of code in a file called test > > #!/bin/sh > if [ $1 = $2 ]; then > echo "ok" > else > echo "oops" > fi > > next, chmod 777 test > then try it: > ./test 1 1 > and > ./test 1 2 > > now go back and change the = to == and try it and you get > > ./test: [: ==: binary operator expected > oops With my bash, it always reacts correctly, regardless whether I call it as `bash' or `sh'. > note: bash is from slakware 3.5 Which version is this (try `bash --version')? Not that it's really important for GPC, but I always like to find out the reasons for problems. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bash
by Russ Whitaker 11 May '99

11 May '99

hi ls -l /bin/sh gives lrwxrwxrwx ... /bin/sh ->bash bash -version give GNU bash, version 1.14.7(1) guess it's about time for me to update thanks Russ ---------- > From: Nick Burrett <nick.burrett(a)btinternet.com> > To: gpc(a)gnu.de > Subject: Re: bash > Date: Tuesday, May 11, 1999 4:19 AM > > > I tried this with bash 2.02 and there is no problem since = and == are > interpreted the same in this case. > > Are you sure you are executing the script with `bash' and not `sh' ? > The first line would seem to suggest `sh' which may be the cause of > the problem. > > Nick.

1 0

prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

I'm seeing the error message "prior parameter's size depends on `foo'" whilst trying to compile an extended pascal module. I'm finding it difficult to strip this down to a really small example which shows the behaviour, but it is associated with a var parameter which is typed as string. Before I spend a lot more time trying to make a very small example of this - anyone have any suggestions as to what I might be doing wrong? -- David James mailto:david@tcs01.demon.co.uk

2 1

Enhancing gdb for GNU Pascal
by Tranter, Jeff 11 May '99

11 May '99

We're looking at using GNU Pascal to replace a proprietary Pascal compiler developed internally. One of the issues with the users is debugging. They would like good source-level debugging capability. GDB seems to work quite well with GNU Pascal but it could be enhanced. I propose to make some changes to it to better support Pascal debugging: - a real Pascal mode, which would be associated with Pascal source file extensions so the debugger would automatically do into Pascal mode when debugging .pas or .p files - evaluation of Pascal expressions (initially I would just copy the modula-2 mode expression parser). The main features here are proper array subscripting and pointer expressions. I plan to add support for sets. - look at making matching of identifiers case-insensitive, so for example, the user could set a breakpoint on a routine called "FOO", "foo", or "Foo" and have it match with what the compiler generated symbol was. - look at allowing the user to set a breakpoint on a program's begin...end block, i.e. have the debugger know that program "FOO" starts at label "program_Foo". Similarly, handle the pseduo-variable used for function return values from the debugger expression evaluator. Currently the user needs to know that for function "FOO" the return value variable is called "retval_Foo". Would these changes be worthwhile? Is anyone already working on them? Are there any other debugging features that would be useful?

2 1

Two GNU Pascal ideas
by Tranter, Jeff 11 May '99

11 May '99

Two thoughts on GNU Pascal to discuss: Based on previous experiences with another Pascal system, one of the most useful features was run-time checking (array bounds, sub-ranges, enumerated types, etc.). This often found problems in code without much effort. It could also be selectively be turned off for efficiency. With GNU Pascal we have C-style run-time checking (i.e. essentially no run-time error checking unless a wild pointer causes some type of exeception). I'm wondering: 1. Would people find this a useful feature for GNU Pascal? 2. Would it be feasible to implement it in the compiler? -------------------------------------- GNU Pascal converts the case-insensitive Pascal identifiers to symbols that are lower-case with the first letter capitalized. This has two implications: - in gdb you need to use the capitalized identifier which is not intuitive to users - you cannot call C routines that do not match the capitalized naming scheme. The first issue can presumably be fixed in the debugger, but the second is more of a problem because I'd like to be able to call C code directly. I can see several approaches to solve this: 1 Make Pascal case sensitive (probably not an option since it would presumably not match the language spec) 2. Convert Pascal symnbols to all lowercase. You could then call C routines if they were all lowercase (which is the most common). 3. Have some extension to indicate C linkage (like C++ and some C compilers do). Maybe an extension or alternative to the EXTERNAL keyword. Note, a side effect of capitalizing all identifiers in the lexical analyzer is that currently the compiler may report an error such as foo.pas:1: parse error before `Error' when the source code actually used the string 'ERROR'.

2 1

Re: bash
by Nick Burrett 11 May '99

11 May '99

"Russ Whitaker" <russwhit(a)mind.net> writes: > hi frank > > i'm not a bash expert either: it took me 2 hours to come up with the > following > > enter the following 6 lines of code in a file called test > > #!/bin/sh > if [ $1 = $2 ]; then > echo "ok" > else > echo "oops" > fi > > next, chmod 777 test > then try it: > ./test 1 1 > and > ./test 1 2 > > now go back and change the = to == and try it and you get > > ./test: [: ==: binary operator expected > oops I tried this with bash 2.02 and there is no problem since = and == are interpreted the same in this case. Are you sure you are executing the script with `bash' and not `sh' ? The first line would seem to suggest `sh' which may be the cause of the problem. Nick.

1 0

bash
by Russ Whitaker 11 May '99

11 May '99

hi frank i'm not a bash expert either: it took me 2 hours to come up with the following enter the following 6 lines of code in a file called test #!/bin/sh if [ $1 = $2 ]; then echo "ok" else echo "oops" fi next, chmod 777 test then try it: ./test 1 1 and ./test 1 2 now go back and change the = to == and try it and you get ./test: [: ==: binary operator expected oops note: bash is from slakware 3.5 thanks russ

1 0

Re: Fw: gcc-19990330
by Frank Heckenbach 10 May '99

10 May '99

Once upon a time ago, Russ Whitaker wrote: > > near the end of make LANGUAGES=pascal there is a number of "if" > > statemnets followed by the message > > > > /bin/sh: [: ==: binary operator expected Unless this has already been solved, can you give more information where this accurs (perhaps a log of the make run)? > > p.s. think "Trim" should trim both spaces and tab chrs > > ( now only spaces) low priority wish list What does the standard say about this? (`Trim' is a predefined function of the standard, so we have to care about the standard here.) Technically, of course, it would be easy to do it. Alternatively (if the standard wants only spaces), we could also make a different routine for spaces and tabs... Frank -- Frank Heckenbach, frank(a)fjf.gnu.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: Fw: gcc-19990330
by Frank Heckenbach 10 May '99

10 May '99

Russ Whitaker wrote: > symptom: GPC would compile unit crtc.c but wouldn't link to ncurses > > so used text editor to search the Makefile.in files for == and replace with > = when it appeared in an "if" statement > then did cnfigure, etc, etc > > result: gpc now finds ncurses > > (bash defaults to always false when it sees == ) Sorry, I don't think I can follow you... First of all, I'm not so much of a bash expert. What do you mean by "bash defaults to always false when it sees =="? My man page says `==' may be used in place of `=' in comparisons, and I can't seem to find any difference in bash's behaviour. Does it mean that (some version of ?) bash does not recognize `==' as a comparison operator? Secondly, I'm a bit surprised about the symptom. The only `==' I could find were one in Make-lang.in in the main GPC source directory, and two in Makefile.in in the rts subdirectory. All of them were of the form "if [ x$(WITH_SHARED) == xyes ] ; then ...", to test whether one wants to build a shared library of the RTS. I can't see any connection to not linking ncurses. -- Well, perhaps, due to the make failing here, it did not get to the point of installing the new units, so GPC used the units of an older version which did not refer to ncurses correctly -- that might be the case... Anyway, replacing these three `==' by `=' (which I did now) fixes the whole problem, right? (Or just this symptom?) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Linking problems
by Frank Heckenbach 10 May '99

10 May '99

Peter Gerwinski wrote: > When I `ar' together a bulk of `.o' files compiled with GPC, > I get lots of undefined references between the `.o's in the `.a'. Did you `ranlib' the library? Though I couldn't seem to produce any problems without doing so with my sources, in general that's necessary, AFAIK... > The same compilation with `--autobuild' works. What do you mean? Do you compile the files with `--autobuild', then `ar' together the resulting objects, or do you use `--autobuild' without `ar'? What happens if you just link the object files? Does it make any difference whether they were compiled with `--autobuild' or `--automake'? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Fw: gcc-19990330
by Russ Whitaker 09 May '99

09 May '99

Hi Frank symptom: GPC would compile unit crtc.c but wouldn't link to ncurses so used text editor to search the Makefile.in files for == and replace with = when it appeared in an "if" statement then did cnfigure, etc, etc result: gpc now finds ncurses (bash defaults to always false when it sees == ) ---------- > From: Frank Heckenbach <frank(a)tim.gerwinski.de> > To: gpc(a)gnu.de > Subject: Re: Fw: gcc-19990330 > Date: Sunday, May 09, 1999 7:02 AM > > Once upon a time ago, Russ Whitaker wrote: > > > > near the end of make LANGUAGES=pascal there is a number of "if" > > > statemnets followed by the message > > > > > > /bin/sh: [: ==: binary operator expected > > Unless this has already been solved, can you give more information > where this accurs (perhaps a log of the make run)?

1 0

Global variables problem
by Ian Thurlbeck 07 May '99

07 May '99

Dear GPC-ers It's a while since a reported a bug in gpc, but hopefully this one is just me being stupid (again). I have a main program and a library program which share some global variables and I want to set the variable in the main program and print them out from the library program: ------main.p--------- program main(input,output); #include "main.h" begin global_int:=100; global_str:='Goodbye World'; print_globals; end. -------------------- ------lib.p----------- module lib(input,output); #include "main.h" var global_int:integer; global_str:string(40); procedure print_globals; begin writeln('global_int=',global_int); writeln('global_str=',global_str); end; end. ------------------- ------main.h-------- var global_int: external integer; global_str: external string(40); procedure print_globals; external; ------------------- Fairly straightforward, but I get: ida globals/ % gpc -o main main.p lib.p ida globals/ % main global_int=100 global_str= Not time to say goodbye yet, it seems. If I move the declarations of the global variable from lib.p to main.p I get: ida globals/ % main global_int=100 global_str=Goodbye World Success, but why ?? Many thanks for a great compiler Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

1 0

Re: Interested about GNU Pascal development
by Nick Burrett 07 May '99

07 May '99

Peter Gerwinski <peter(a)gerwinski.de> writes: > Hello, folks! > > > GrimReaperX wrote: In fact, I am willing to do whatever I can to help > > Linux/Unix*/GNU to grow.... > > > > I agrre with your position, And I'm happy beause I've just found the > > GNU-Pascal. I'm french and I have problems with my english, but if you do > > some translation ant need somebody to help you (only in french), I'm here! > > Having French translations of GNU Pascal documentation is > certainly a Good Thing. What would probably be the best thing to do is internationalise the Pascal compiler with GNU gettext and then translate all the warning and error messages into various languages. > Just one thing to take into account: The GNU Pascal > documentation is currently fairly incomplete. If you find > a missing section, be welcome to add it. Translating all the GNU Pascal documentation into another language can create a maintenance headache as you have to try and keep track of the alterations that will be made to the document. Certainly a one-off translation would probably be good, but trying to keep it up-to-date is likely to be more trouble than it is worth. Nick.

1 0

Re: Problem compiling regexdemo and pipedemo on Redhat linux 5.2
by Frank Heckenbach 05 May '99

05 May '99

David James wrote: > > BTW, I think one should generally *not* use `Reply-To' headers in > > the mailing list, unless in special cases (like the strawpoll > > recently), just like one should not ask for private replies in > > newsgroups. > > My apologies, my MUA puts in a reply-to header by default, I've never > needed to remove it on any other mailing list, but looking at mail > from those most of them appear to re-write the reply-to header to be > the mailing list submission address. > > With my MUA, if I try to reply to your message it is going to go > direct to you and not to the list. So perhaps this list should insert a reply-to-the-list header be default? Peter, can the mailing list software do that? Is that desirable? Frank -- Frank Heckenbach, frank(a)fjf.gnu.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: Problem compiling regexdemo and pipedemo on Redhat linux 5.2
by david＠tcs01.demon.co.uk 05 May '99

05 May '99

In message <7DB86F9E.19990505201803.FOO-2516.frank(a)goedel.fjf.gnu.de> Frank Heckenbach writes: > I answered this mail yesterday, but then I saw that the original > posting had a `Reply-To' header, so I'm sending it again, to the > list, because it might be of interest to others. > > BTW, I think one should generally *not* use `Reply-To' headers in > the mailing list, unless in special cases (like the strawpoll > recently), just like one should not ask for private replies in > newsgroups. My apologies, my MUA puts in a reply-to header by default, I've never needed to remove it on any other mailing list, but looking at mail from those most of them appear to re-write the reply-to header to be the mailing list submission address. With my MUA, if I try to reply to your message it is going to go direct to you and not to the list. > > David James wrote: > > > /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/regexc.c:24: rxposix.h: No > > such file or directory > > For the RegEx unit, you need the rx library. Sources and binaries > are available at > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ Thank you, I've now picked that up. Am I likely to need any of the other items from the libs directory? I ask because I see there is a gmp in there, but the demos using gmp work fine on my system ... > > > /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: > > `pid_t' undeclared (first use in this function) > > Oh yes, this is a bug. Please add the line > > #include <sys/types.h> > > in pipec.c (near the other #include statements), then it should > work. Thanks again. -- David James mailto:david@tcs01.demon.co.uk

1 0

Re: Problem compiling regexdemo and pipedemo on Redhat linux 5.2
by Frank Heckenbach 05 May '99

05 May '99

I answered this mail yesterday, but then I saw that the original posting had a `Reply-To' header, so I'm sending it again, to the list, because it might be of interest to others. BTW, I think one should generally *not* use `Reply-To' headers in the mailing list, unless in special cases (like the strawpoll recently), just like one should not ask for private replies in newsgroups. David James wrote: > /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/regexc.c:24: rxposix.h: No > such file or directory For the RegEx unit, you need the rx library. Sources and binaries are available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ > /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: > `pid_t' undeclared (first use in this function) Oh yes, this is a bug. Please add the line #include <sys/types.h> in pipec.c (near the other #include statements), then it should work. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re:hpux-units
by Olivier PECHEUX 05 May '99

05 May '99

Crt lib.... Thanks, I will use the the new one. For information, note that the real BP crt ver 7.0 does'n work on the hi-speed PC. There is a bug (error 200 divide by zero) when they count the number of loop for the function delay. Olivier

2 1

Problem compiling regexdemo and pipedemo on Redhat linux 5.2
by david＠tcs01.demon.co.uk 04 May '99

04 May '99

I have recently installed gpc 19990118 and gcc version 2.8.1 on a Redhat linux 5.2 system. I've been trying to build the programs in the p/demos directory, and (now that I've discovered the --automake option) all of them build successfully except regexdemo and pipedemo. Trying to compile these gives the output shown below. Does anyone have any suggestions as to what is wrong? Trying to compile regexdemo with the command line gpc --automake -o regexdemo regexdemo.pas gives the following output (lines wrapped for readability) /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/regexc.c:24: rxposix.h: No such file or directory gpc1: gpc exited with status 1 /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/regex.pas:77: `/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/regexc.c' could not be compiled gpc1: gpc exited with status 1 regexdemo.pas:25: module `regex' could not be compiled Trying to compile pipedemo with the command line gpc --automake -o pipedemo pipedemo.pas gives the following output (lines wrapped for readability) /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c: In function `_p_pipe': /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: `pid_t' undeclared (first use in this function) /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: (Each undeclared identifier is reported only once /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: for each function it appears in.) /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:34: parse error before `pid' /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c:39: `pid' undeclared (first use in this function) gpc1: gpc exited with status 1 /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipe.pas:65: `/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/pipec.c' could not be compiled gpc1: gpc exited with status 1 pipedemo.pas:25: module `pipe' could not be compiled -- David James mailto:david@tcs01.demon.co.uk

1 0

Re:hpux-units
by Olivier Pécheux 04 May '99

04 May '99

> Hello, > Does anyone know if > 2. Are there any precompiled units (crt,graph e.t.c) for > any platform? > > Thank you. I found the crt lib for gpc dos at ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/gpcbplib.zipOlivier --------Publicite--personnelle--------------------------------------- ........ABC de la Programmation: ................http://www.multimania.com/opecheux

2 1

Re: hpux-units
by Frank Heckenbach 04 May '99

04 May '99

Maurice Lombardi wrote: > Olivier PÃ©cheux wrote: > > > > > Hello, > > > Does anyone know if > > > 2. Are there any precompiled units (crt,graph e.t.c) for > > > any platform? > > > > > > Thank you. > > > > I found the crt lib for gpc dos at > > ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/gpcbplib.zip Olivier > > Beware: this is a very old library (1995) which seems to pertain to an > old version of gpc A very old version, indeed. ;-) That library is not quite complete WRT to BP compatibility, and was only written for one platform. However, the latest GPC release (19990118) contains a complete BP compatible and portable CRT unit. You can use it with `uses CRT' just like in BP, and the unit will be compiled automatically when you give gpc the `--automake' switch. You only need the ncurses (Unix, terminals) or PDCurses (DJGPP or X11) library which is available (as source and binaries) on agnes. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

crt
by Karadamoglou Kostas 03 May '99

03 May '99

Hello, I tried out the new beta version of gnu pascal. There seems to be a problem whith the crt unit. Although the compile goes fine, if I include the "uses crt" line in the program(even if no crt routine is used) the executable just makes a clear screen and then exits without doing anything else. If I delete the "uses crt" line the programs executes fine. Any idea? Kostas

1 0

Re: crt
by Frank Heckenbach 03 May '99

03 May '99

Karadamoglou Kostas wrote: > Hello, > I tried out the new beta version of gnu pascal. > There seems to be a problem whith the crt unit. > Although the compile goes fine, if I include > the "uses crt" line in the program(even if no > crt routine is used) the executable just makes > a clear screen and then exits without doing > anything else. If I delete the "uses crt" > line the programs executes fine. > Any idea? That's the defined behaviour of the curses library on which CRT builds. It was designed for "fullscreen" application rather than "text filters", so it makes sense to clear the screen at the beginning and ending of the program. Or do you mean that your program contains other code which is not executed? This would be a bug indeed. In this case, please post a test program and tell me what platform you're using. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: hpux-units
by Frank Heckenbach 01 May '99

01 May '99

Kostas Karadamoglou wrote: > 2. Are there any precompiled units (crt,graph e.t.c) for > any platform? No. With the current version (gpc-19990118), it should be trivial to compile them when needed, by just using the `--automake' switch. However, of the libraries that some units (e.g. CRT) use, there are binaries for i586-pc-linux-gnulibc1, i386-go32 and sparc-sun-solaris2 available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ Binaries for other platforms are not there yet, but if anyone builds them, we'd like to upload them. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

hpux-units
by Kostas Karadamoglou 01 May '99

01 May '99

Hello, Does anyone know if 1. Are there HP-UX binaries of gpc? 2. Are there any precompiled units (crt,graph e.t.c) for any platform? Thank you. Kostas

1 0

Further PowerPC compile woes
by Jo Dillon 30 Apr '99

30 Apr '99

Having had problems with my intel-to-AIX cross-compiler, I've now put LinuxPPC on my iMac and built a totally normal, non-cross-compiled egcs 1.1.1. This crashes in the same way as my cross-compiler did, so it looks like there's some problem with generating powerpc code (since an identical intel/egcs1.1.1/gpc-19990118 build works fine). So far as I can tell there's no problem with other languages, but since the compiler builds some fairly hefty Pascal files without crashing it's hard to tell. The error looks like this: realreg.pas: In function `Proxysearch': realreg.pas:463: internal error--unrecognizable insn: (insn 8385 8382 1558 (set (mem:SI (plus:SI (reg:SI 12 r12) (const_int 65536))) (reg:SI 14 r14)) -1 (nil) (nil)) ../../../egcs-1.1.1/gcc/p/../toplev.c:1378: Internal compiler error in function fatal_insn Any ideas? :/ -- Jo

2 1

Fw: gcc-19990330
by Russ Whitaker 29 Apr '99

29 Apr '99

---------- > From: Russ Whitaker <russwhit(a)mind.net> > To: gpc(a)gnu.de > Subject: gcc-19990330 > Date: Tuesday, April 27, 1999 3:05 PM > > Hi Peter > > well, it works > > but... > > near the end of make LANGUAGES=pascal there is a number of "if" > statemnets followed by the message > > /bin/sh: [: ==: binary operator expected > > Thanks, > Russ > > p.s. think "Trim" should trim both spaces and tab chrs > ( now only spaces) low priority wish list

1 0

Re: gpc compiler error
by Colin Osborne 22 Apr '99

22 Apr '99

> Okay, thanks. What happens if you give the `--automake' or > `--autobuild' option? > sceos2{cpo}9: !m make medrush gpc -c -w -v --automake soil_h2o.p Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w soil_h2o.p /var/tmp/cca000Di.i GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc1 /var/tmp/cca000Di.i -quiet -dumpbase soil_h2o.pas -w -version -famtmpfile=/var/tmp/cca000Di.gpc -fautomake -o /var/tmp/cca000Di.s GNU Pascal version 2.8.1 (sparc-sun-solaris2.6) compiled by GNU C version 2.8.1. GPC AutoMake: gpc --automake -w -v --amtmpfile=/var/tmp/cca000Di.gpc -M useful.p -o /var/tmp/cca000Dk Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w useful.p -o /var/tmp/cca000Dk GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -w -v --amtmpfile=/var/tmp/cca000Di.gpc -M functions.p -o /var/tmp/cca000Dk Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w functions.p -o /var/tmp/cca000Dk GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -w -v --amtmpfile=/var/tmp/cca000Di.gpc -M phys_lib.p -o /var/tmp/cca000Dk Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w phys_lib.p -o /var/tmp/cca000Dk GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -w -v --amtmpfile=/var/tmp/cca000Di.gpc -M useful.p -o /var/tmp/cca000Dk Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w useful.p -o /var/tmp/cca000Dk GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -w -v --amtmpfile=/var/tmp/cca000Di.gpc -M functions.p -o /var/tmp/cca000Dk Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w functions.p -o /var/tmp/cca000Dk GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done gpc: Internal compiler error: program gpc1 got fatal signal 6 *** Error code 1 make: Fatal error: Command failed for target `soil_h2o.o' ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Colin Osborne Dept. of Animal and Plant Sciences University of Sheffield Sheffield S10 2TN Tel: 0114 222 0086 Fax: 0114 222 0002 ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~

1 0

Re: gpc compiler error
by Colin Osborne 22 Apr '99

22 Apr '99

> What is the result when you specify the `-v' option when > compiling? It's certainly got a lot to say for itself. Boom! And it's off . . . . . . sceos2{cpo}3: make medrush gpc -c -w -v soil_h2o.p Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w soil_h2o.p /var/tmp/cca000Cx.i GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc1 /var/tmp/cca000Cx.i -quiet -dumpbase soil_h2o.pas -w -version -famtmpfile=/var/tmp/cca000Cx.gpc -o /var/tmp/cca000Cx.s GNU Pascal version 2.8.1 (sparc-sun-solaris2.6) compiled by GNU C version 2.8.1. GPC AutoMake: gpc --autolink -w -v --amtmpfile=/var/tmp/cca000Cx.gpc -M useful.p -o /var/tmp/cca000Cz Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w useful.p -o /var/tmp/cca000Cz GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --autolink -w -v --amtmpfile=/var/tmp/cca000Cx.gpc -M functions.p -o /var/tmp/cca000Cz Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w functions.p -o /var/tmp/cca000Cz GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --autolink -w -v --amtmpfile=/var/tmp/cca000Cx.gpc -M phys_lib.p -o /var/tmp/cca000Cz Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w phys_lib.p -o /var/tmp/cca000Cz GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --autolink -w -v --amtmpfile=/var/tmp/cca000Cx.gpc -M useful.p -o /var/tmp/cca000Cz Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w useful.p -o /var/tmp/cca000Cz GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --autolink -w -v --amtmpfile=/var/tmp/cca000Cx.gpc -M functions.p -o /var/tmp/cca000Cz Reading specs from /usr/local/lib/specs gpc version 19990118, based on gcc-2.8.1 /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -Dsun -Dsparc -Dunix -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__SVR4 -D__GCC_NEW_VARARGS__ -D__sun -D__sparc -D__unix -Asystem(unix) -Asystem(svr4) -Acpu(sparc) -Amachine(sparc) -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -w functions.p -o /var/tmp/cca000Cz GNU CPP version 2.8.1 (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/sparc-sun-solaris2.6/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/include /usr/include End of search list. GPC AutoMake: done gpc: Internal compiler error: program gpc1 got fatal signal 6 *** Error code 1 make: Fatal error: Command failed for target `soil_h2o.o' ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Colin Osborne Dept. of Animal and Plant Sciences University of Sheffield Sheffield S10 2TN Tel: 0114 222 0086 Fax: 0114 222 0002 ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~

2 1

Re: gpc compiler error
by C.P.Osborne 22 Apr '99

22 Apr '99

> Please check first whether there are any old `.gpi' files > present that have been compiled with gpc-2.0. The GPI format > has changed significantly between both versions of GPC, so all > `.gpi's need to be rebuilt. OK, now I get gpc: Internal compiler error: program gpc1 got fatal signal 6 *** Error code 1 make: Fatal error: Command failed for target `soil_h2o.o' Being a novice, this is highly likely to be something pretty dumb. Colin ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Colin Osborne Dept. of Animal and Plant Sciences University of Sheffield Sheffield S10 2TN Tel: 0114 222 0086 Fax: 0114 222 0002 ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~

2 1

GPC list has moved
by Peter Gerwinski 22 Apr '99

22 Apr '99

Hello all, the move of the GPC mailing list has been completed now. `gpc(a)hut.fi' (and `gpc-request(a)hut.fi') does still work and is forwarded to the new list, but the new official address of the list is `gpc(a)gnu.de'. To subscribe to or to unsubscribe from the GPC mailing list please send email to `majordomo(a)gnu.de' (or `gpc-request(a)gnu.de' which makes no difference). The subject is ignored, but the body can contain commands to the `majordomo' program, for instance: help --> request an email that tells you more about how to talk with majordomo subscribe gpc peter(a)gerwinski.de --> subscribe unsubscribe gpc peter(a)gerwinski.de --> unsubscribe Those of you who are only interested in announcements and not in discussions can unsubscribe from the `gpc' list and instead subscribe to the `gpc-announce' list. (Announcements will appear on both lists, but on `gpc-announce' there will be _only_ announcements.) Have fun, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

gpc compiler error
by C.P.Osborne 22 Apr '99

22 Apr '99

I am trying out the 2.1-beta version of gpc, in order to take advantage of its ability to handle the Turbo Pascal 'Assign' function. However, on compiling (a numerical model) on a unix solaris operating system, I get the following message: gpi-hash.c:406: failed assertion `rni == num_items' gpc: Internal compiler error: program gpc1 got fatal signal 6 *** Error code 1 make: Fatal error: Command failed for target `medrush' The programme compiles OK with the last (2.0, I think) release of gpc (but crashes - though that's a whole new problem!). Does anyone have any ideas? Thanks, Colin ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Colin Osborne Dept. of Animal and Plant Sciences University of Sheffield Sheffield S10 2TN Tel: 0114 222 0086 Fax: 0114 222 0002 ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~

1 0

pascal to C++
by Peter Coates 22 Apr '99

22 Apr '99

I am looking at using the front end of the GPC as a starting point for a Pascal to C++ converter. I am aware that there are pascal to C converters in existance, but the code they produce is in general code that only a C compiler can understand. My intension is to produce maintainable code, and I am helped by the fact that the starting point is a particular body of code over which I have some control and can be hacked before and after if necessary. What I would like (besides advice and guidance) is a good description of the intermediate data structure generated by the front end of the GPC (and GCC) compilers. A few months ago (when I was first considering this) I found a wonderful web site (in Sweden, I think) that described this beatifully. Since then, however, this computer has been upgraded, rebuilt, and generally hacked around and I have lost the link. Help? Peter. ----- "Time is an illusion. Launch times doubly so"

2 1

patches for egcs 1.1.2
by Maurice Lombardi 22 Apr '99

22 Apr '99

Hi all I have tried to install gpc on a Linux system for egcs 1.1.2. It failed beause of missing patches for egcs 2.91.66. Do you have them? I have been surprised because Delorie announced a beta version of egcs 1.1.2 for djgpp which includes sources and binaries for gpc. In his distribution there is no patch for 2.91.66 (only those in your current distribution gpc-19990118.tar.gz). I have not yet tried to install the djgpp binaries. Thanks in advance. -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: pascal to C++
by richard.kerry＠quantel.com 21 Apr '99

21 Apr '99

Whoops, meant to send this to the list. >I am looking at using the front end of the GPC as a starting point for a >Pascal to C++ converter. I am aware that there are pascal to C converters >in existance, but the code they produce is in general code that only a C >compiler can understand. There's quite a good Pascal to C converter, called p2c, at http://www.synaptics.com/people/daveg/ This does quite a good job of producing readable C, and has a switch to make it C++ compatible. Yours helpfully, Richard.

1 0

Testing: You should get this mail _twice_
by Peter Gerwinski 21 Apr '99

21 Apr '99

Hi, all, this is a test whether `gpc(a)hut.fi' and `gpc(a)gnu.de' are identical. If you do not get this mail _twice_, please let me know. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

Re: internal error: duplicate constructor
by Frank Heckenbach 19 Apr '99

19 Apr '99

Brian Desmond wrote: > I have been trying to use gpc on a DEC Alpha Personal Workstation 600au. > gcc 2.8.1 was previously installed, and is not being rebuilt with the > pascal binary. From my reading of the docs, this *SHOULD* be OK. The C compiler does not have to be rebuilt. However, the GCC sources are patched while making GPC, and parts of them are recompiled. I suppose you did so, otherwise you wouldn't have got so far. > gpc builds and installs OK, compilation of the demos appears fine, but I > get the following message when running the built programs: > > bash> gpc --automake -Wall demoproc.pas -o demoproc > bash> ./demoproc > internal error: duplicate constructor > bash> That's interesting. I got this message when playing with a dynamically linked RTS (run time system). Apparently, the way linking works on your platform makes it occur with static linking as well. (BTW, the fact that noone else has noticed this problem doesn't mean it doesn't exist for others. The units, which cause the problem, are relatively new, and it might be that noone has tried to use them or to compile the demo programs on the Alpha before.) Anyway, this error is nothing serious. It was meant as a sanity check for something else long time ago, so in fact it's safe now to remove this error message. A patch (which will also be in the next release) is appended below. > I have tried installing the prebuilt binary, but it seems to require > that gcc is installed into the same tree, which it isn't on our system, > and so attempts to compile fail. Yes, the automake expects this. We've thought about this problem, so probably some future versions will accept any GCC installed somewhere. For now, if you really need it, you can try symlinking cc1 and cpp from the installed GCC to the GPC directory (<prefix>/lib/gcc-lib/<platform>/<version>). Of course, that's a bit of a kludge... Frank *** misc.c.orig Mon Apr 19 21:13:52 1999 --- misc.c Fri Mar 26 04:37:18 1999 *************** *** 71,78 **** --- 71,86 ---- { if (fun == scan->fun) { + /* dynamic RTS linking currently can produce a duplicate + constructor of gpc.pas -- it doesn't hurt much since the + constructor does nothing, and the object file it's in is + empty otherwise (19990307) */ + #if 1 + return; + #else fputs ("internal error: duplicate constructor\n", stderr); _exit (-1); + #endif } if (scan->run_id > run_id || !scan->next) -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Result: STRAWPOLL: GPC newsgroup
by Nick Burrett 19 Apr '99

19 Apr '99

Peter Gerwinski <peter(a)gerwinski.de> writes: > Here are the results from the STRAWPOLL. > > There were 15 votes, all valid, all saying "YES": > So there is interest in a newsgroup `comp.lang.pascal.gnu', but > there are not enough votes to succeed in a Usenet CfV. Perhaps you need to do the strawpoll again but announce it to the comp.lang.pascal group as well. It would reach a wider audience then. Nick.

1 0

CfV: Move the GPC list? Create an announcement list?
by Peter Gerwinski 19 Apr '99

19 Apr '99

Hello, while the STRAWPOLL about the creation of a newsgroup is still going on, there are yet two other subjects to vote about which we have discussed recently: * Shall we move the GPC mailing list to another place, gpc(a)gnu.de, where it can be maintained automatically? (The fact that gpc(a)hut.fi is maintained manually has caused long delays of subscriptions in the past.) * Shall we create a separate, moderated GPC mailing list gpc-announce(a)gnu.de for announcements? (I can act as the moderator if noone rejects this. Since I am sending most of the announcements anyway, this would be quite natural.:-) Again I ripped off a Usenet CfV ballot. Please fill out the form below and reply it to peter-votes(a)gerwinski.de (Reply-To header is set). Do not send votes to the GPC mailing list; only discussion should go here. Also please do not confuse the ongoing STRAWPOLL and this CfV. ;-) Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** 8< ------------------------------------------------------------- Votes must be received by 23:59:59 UTC, 18 Apr 1999. The CfV RESULT post will be mailed to the GPC mailing list. IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING Only one vote is allowed per person or per account. Duplicate votes will be resolved in favor of the most recent valid vote. Addresses and votes of all voters will be listed in the final voting results post. Votes must be mailed directly from the voter to the votetaker. Anonymous, forwarded, or proxy votes are not valid. Votes mailed by WWW/HTML/CGI forms are considered to be anonymous votes. HOW TO VOTE: Extract the ballot from the CfV by deleting everything before the "BEGINNING OF BALLOT" and after the "END OF BALLOT" lines. Don't worry about the spacing of the columns or any quote characters (">") that your reply inserts. Please do not send the entire CfV back to me. Fill in the ballot as shown below. Please provide a valid name and indicate your desired vote in the appropriate locations inside the ballot. When finished, MAIL the ballot to: <peter-votes(a)gerwinski.de> Just "replying" to this message should work, but check the "To:" line. Examples of how to properly indicate your vote (do not vote here): [ YES ] example.yes.vote [ NO ] example.no.vote [ ABSTAIN ] example.abstention [ CANCEL ] example.cancellation ======== BEGINNING OF BALLOT: Delete everything before this line ======= .----------------------------------------------------------------------- | Do not edit anything in this ballot, except to add your name and vote. | | CfV: gpc(a)gnu.de, gpc-announce(a)gnu.de | |----------------------------------------------------------------------- | Please provide a valid name, or your vote may be rejected. Place | ONLY your name (i.e., do not include your e-mail address or any other | information) after the colon on the line below. Voter name: | Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each | newsgroup listed below (do not delete the newsgroup name): Your Vote Mailing list --------- ----------------------------------------------------------- [ ] gpc(a)gnu.de (unmoderated, replacing gpc(a)hut.fi) [ ] gpc-announce(a)gnu.de (moderated) ======== END OF BALLOT: Delete everything after this line ============== Voting address: peter-votes(a)gerwinski.de

1 1

STRAWPOLL: GPC newsgroup
by Peter Gerwinski 19 Apr '99

19 Apr '99

Hello, folks! This is an informal strawpoll to get an overview about whether it makes sense to try to create an unmoderated Usenet newsgroup devoted to GPC, `comp.lang.pascal.gnu'. In order to create such a newsgroup we need at least 100 "YES" votes in the CfV. I ripped a ballot off a Usenet CfV, modified and shortened it (so do not wonder about the formal wording:-). Please fill out the form below and reply it to peter-strawpoll(a)gerwinski.de (Reply-To header is set). Do not send votes to the GPC mailing list; only discussion should go here. I think that we have already agreed that "the" GPC mailing list shall *not* be gated to the newsgroup or vice versa; maybe we can create a separate list for that purpose, but let us first create the newsgroup. ;-) Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** 8< ------------------------------------------------------------- Votes must be received by 23:59:59 UTC, 18 Apr 1999. The STRAWPOLL RESULT post will be mailed to the GPC mailing list. IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING Only one vote is allowed per person or per account. Duplicate votes will be resolved in favor of the most recent valid vote. Addresses and votes of all voters will be listed in the final voting results post. Votes must be mailed directly from the voter to the votetaker. Anonymous, forwarded, or proxy votes are not valid. Votes mailed by WWW/HTML/CGI forms are considered to be anonymous votes. The purpose of a Usenet vote is to determine the genuine interest of persons who would read a proposed newsgroup. Soliciting votes from uninterested parties defeats this purpose. Please do not distribute this STRAWPOLL. HOW TO VOTE: Extract the ballot from the STRAWPOLL by deleting everything before the "BEGINNING OF BALLOT" and after the "END OF BALLOT" lines. Don't worry about the spacing of the columns or any quote characters (">") that your reply inserts. Please do not send the entire STRAWPOLL back to me. Fill in the ballot as shown below. Please provide a valid name and indicate your desired vote in the appropriate locations inside the ballot. When finished, MAIL the ballot to: <peter-strawpoll(a)gerwinski.de> Just "replying" to this message should work, but check the "To:" line. Examples of how to properly indicate your vote (do not vote here): [ YES ] example.yes.vote [ NO ] example.no.vote [ ABSTAIN ] example.abstention [ CANCEL ] example.cancellation ======== BEGINNING OF BALLOT: Delete everything before this line ======= .----------------------------------------------------------------------- | Do not edit anything in this ballot, except to add your name and vote. | | STRAWPOLL: comp.lang.pascal.gnu | This is an inofficial voting ballot. (Do not take too serious!;-) |----------------------------------------------------------------------- | Please provide a valid name, or your vote may be rejected. Place | ONLY your name (i.e., do not include your e-mail address or any other | information) after the colon on the line below. Voter name: | Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each | newsgroup listed below (do not delete the newsgroup name): Your Vote Newsgroup --------- ----------------------------------------------------------- [ ] comp.lang.pascal.gnu ======== END OF BALLOT: Delete everything after this line ============== Voting address: peter-strawpoll(a)gerwinski.de

1 1

internal error: duplicate constructor
by Brian Desmond 19 Apr '99

19 Apr '99

Hi All, I have been trying to use gpc on a DEC Alpha Personal Workstation 600au. gcc 2.8.1 was previously installed, and is not being rebuilt with the pascal binary. From my reading of the docs, this *SHOULD* be OK. Version is: bash> gpc -v Reading specs from /usr/local/gcc/lib/gcc-lib/alphaev56-dec-osf4.0d/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 gpc builds and installs OK, compilation of the demos appears fine, but I get the following message when running the built programs: bash> gpc --automake -Wall demoproc.pas -o demoproc bash> ./demoproc internal error: duplicate constructor bash> I have tried installing the prebuilt binary, but it seems to require that gcc is installed into the same tree, which it isn't on our system, and so attempts to compile fail. Any ideas? I have not been able to find anything referring to this problem, and I have no doubt that it is working for others on this platform - particularly since there is a binary released for it. with thanks in advance, Brian -- Brian Desmond Department of Psychology University of Melbourne Parkville, Victoria 3052 Australia Email: brian(a)psych.unimelb.edu.au Phone: +61 3 9344 8156 Fax: +61 3 9347 6618

1 0

Does gpc-cpp forget about include paths?
by Peter Gerwinski 18 Apr '99

18 Apr '99

Hi, fellow GPC developers! This time I have a problem with GPC I hope to get help for. ;-) My version of `gpc-cpp' seems to forget include paths (option `-I') after one use. When compiling a program that includes several files from another directory I have to specify that same directory several times with `-I'. Since I cannot remember having seen this in the past nor to have touched this part of the preprocessor I am asking whether (a) anybody else has observed this behaviour, and/or (b) someone has hacked `gpc-cpp' in a way that might have caused this problem. Greetings, Peter PS: The STRAWPOLL and the CfV close today at 23:59:59 UTC. -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

subscribe devilman@jet.es
by Marcos Lois 18 Apr '99

18 Apr '99

1 0

Don't forget: STRAWPOLL and CfV
by Peter Gerwinski 16 Apr '99

16 Apr '99

Hi all, this is just to remember that the STRAWPOLL whether we want (and are able to) create a Usenet newsgroup `comp.lang.pascal.gnu' and the CfV whether we want to move the GPC mailing list and create an additional moderated list for announcements will close on 23:59:59 UTC, 18 Apr 1999. Happy voting, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

Re: Reading env
by Frank Heckenbach 13 Apr '99

13 Apr '99

Svetoslav B. Alexandroff wrote: > I have a question - how to read an environment variable under > Linux/FreeBSD? Looks like there is not getenv function... Assuming you use GPC-19990118, you only have to use the unit `GPC' in your program where `GetEnv' is declared: program Foo; uses GPC; begin Writeln (GetEnv ('HOME')) end. Frank PS: Your mail would be far more readable if you used line breaks at less than 80 columns, and came without that HTML attachment. -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Reading env
by Svetoslav B. Alexandroff 13 Apr '99

13 Apr '99

I have a question - how to read an environment variable under =Linux/FreeBSD? Looks like there is not getenv function...

1 0

-g option under IRIX
by Miklos Cserzo 13 Apr '99

13 Apr '99

Hi Folks, I compiled the latest beta with egcs. The -g option is still broken but this time I got different error messages on the p/test codes: Internal compiler error in function gen_type_die and Internal compiler error in function add_bound_info I hope it helps to some knowledgeable guys to fix it. Cheers, miklos

1 0

Re: RTS crashes gcc-2.8.1
by Frank Heckenbach 12 Apr '99

12 Apr '99

Jan-Jaap van der Heijden wrote: > The last snapshot will crash i386-linux gcc 2.8.1 while compiling the RTS > (maths.c) with a signal 6 (abort): Works on my i386-linux with gcc-2.8.1... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Cross-compiler fun
by Jo Dillon 12 Apr '99

12 Apr '99

I've got a cross-compiler of sorts built, although it doesn't install properly (seems to lack a libcrt.0). Anyway, using the version in gcc/ seems to work most of the time, but on some files it fails - e.g: /home/root/cross/build-gcc/gcc/gpc-cross -c -w realreg.pas -o realreg.coff realreg.pas: In function `Proxysearch': realreg.pas:463: internal error--unrecognizable insn: (insn 8383 8380 1439 (set (mem:SI (plus:SI (reg:SI 14 r14) (const_int 65536))) (reg:SI 17 r17)) -1 (nil) (nil)) ../../../egcs-1.1.1/gcc/p/../toplev.c:1378: Internal compiler error in function fatal_insn (the line in question is at the end of a function definition). I've set my path to point to /home/root/cross/build-gcc/gcc/ first; is it possible that something's ignoring the path and using the wrong backend? Does this look like a genuine compiler bug, or is it time for me to investigate that lack of a runtime? (Incidentally, the file in question compiles fine with a normal gpc, and twiddling optimisation levels can, in some cases, make the problem go away - but not in others). -- Jo

1 0

Re: efence?
by Frank Heckenbach 11 Apr '99

11 Apr '99

Jan-Jaap van der Heijden wrote: > Did anybody ever perform a gpc malloc debug with something like > electric fence? I tried once with efence, and it found some problems already while compiling the RTS. These must not necessarily have been errors, but I didn't pursue them further. Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

RTS crashes gcc-2.8.1
by Jan-Jaap van der Heijden 11 Apr '99

11 Apr '99

Hello all, The last snapshot will crash i386-linux gcc 2.8.1 while compiling the RTS (maths.c) with a signal 6 (abort): #0 0x81637f1 in __kill () #1 0x81637d2 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x8153821 in abort () at ../sysdeps/generic/abort.c:83 #3 0x814f6c7 in output_fix_trunc (insn=0x82eb24c, operands=0x81a9984) at ../gcc-2.8.1/config/i386/i386.c:3900 #4 0x813e44a in output_120 (operands=0x81a9984, insn=0x82eb24c) at insn-output.c:1608 #5 0x812aae8 in final_scan_insn (insn=0x82eb24c, file=0x81be6e0, optimize=2, prescan=0, nopeepholes=0) at ../gcc-2.8.1/final.c:2155 #6 0x8129dc7 in final (first=0x82eaa4c, file=0x81be6e0, optimize=2, prescan=0) at ../gcc-2.8.1/final.c:1340 #7 0x8064d52 in rest_of_compilation (decl=0x827676c) at ../gcc-2.8.1/toplev.c:3648 #8 0x805620d in finish_function (nested=0) at ../gcc-2.8.1/c-decl.c:7100 #9 0x8048f03 in yyparse () at c-parse.y:355 #10 0x8063406 in compile_file (name=0xbffff94d "/tmp/cca14071.i") at ../gcc-2.8.1/toplev.c:2496 #11 0x8065cea in main (argc=13, argv=0xbffff844, envp=0xbffff87c) at ../gcc-2.8.1/toplev.c:4379 EGCS works. BTW: the configuration of the RTS "--with-shared" option is rather broken. A fix will follow shortly... JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

efence?
by Jan-Jaap van der Heijden 11 Apr '99

11 Apr '99

Did anybody ever perform a gpc malloc debug with something like electric fence? JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

GPC snapshot: gpc-19990409
by Peter Gerwinski 11 Apr '99

11 Apr '99

Hi, all, well ... you wanted it like that ... ;-) I have just uploaded a snapshot of the current GPC WIP code to the usual place on Agnes: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ I do not even guarantee this code to compile, but if you are curious, be welcome to try it out, fix bugs, and so on. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

2 1

newsflash: updated mingw32 binary.
by Jan-Jaap van der Heijden 10 Apr '99

10 Apr '99

Hi all, Unfortunately, an old bug slipped through in the binary I announced yesterday. It will crash gpc-cpp when including a file. This happens when the -remap cpp option is enabled, which very few platforms do. For the interested, the fix (already submitted) was: Tue Feb 23 21:55:09 1999 J.J. van der Heijden <J.J.vanderHeijden(a)student.utwente.nl> * gpc-cccp.c (do_include): Initialize searchptr->fname --- gpc-cccp.c.orig Thu Jan 7 02:34:50 1999 +++ gpc-cccp.c Tue Feb 23 21:50:43 1999 @@ -5083,6 +5083,8 @@ fname[0] = 0; } strncat (fname, (char *) fbeg, flen); + searchptr->fname = (char *) xmalloc (flen + 1); + strncpy (searchptr->fname, fname, flen); #ifdef VMS /* Change this 1/2 Unix 1/2 VMS file specification into a full VMS file specification */ (to peter: of course this is the modifed fix). Anyway, I updated the binary. For those who have the old binary: you can also fix this by removing "-remap" from cpp options in "specs". Thanks to the Chief for informing me about this glitch. JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

GNU Pascal 2.0 trouble
by Svetoslav B. Alexandroff 10 Apr '99

10 Apr '99

Hello. I downloaded from Linuxberg gpc-19990118.tar.gz and tried to compile it =using GCC 2.8.1 under FreeBSD 2.2.7. Everything was great, but make did =not produce gpc1. I have no idea why, I did eveything as exactly чscribed in the INSTALL document. Where is my mistake? My e-mail is: alexandroff(a)gmx.net

2 1

Problems compiling 19990118
by Morten S. Jensen 10 Apr '99

10 Apr '99

I am trying to compile gpc-19990118 on Alpha DEC OSF/1 v.4.0 I have met a couple of problems that I have corrected (listed below), but eventually the make in p/rts stops with the message "Don't know how to make write.pas.". Does anyone know how to treat this error? Please send me a copy of the reply as I have only just asked to join the mailing list. Morten ----------------------- The following fixes were necessary in order to compile with DEC's C-compiler: 'p/gpc-typeck.c' line 3560: 'p/types.c' line 959: change from default: to default:; 'p/Makefile.in' line 139: change from ALL_WARNINGS = -Wall to # ALL_WARNINGS = -Wall 'p/gpc-cccp.c' line 149 change from #else to #else -------------------------------------------- Morten Skaarup Jensen Department of Acoustic Technology Technical University of Denmark Bygning 352 DK-2800 Lyngby Denmark Direct: (+45) 45 25 39 54 Fax: (+45) 45 88 05 77 Recep.: (+45) 45 88 16 22 http://www.dat.dtu.dk/~msj

2 1

GNU Pascal website updated
by Peter Gerwinski 10 Apr '99

10 Apr '99

Hello, in order to address recent developments, we have done a major update on the GNU Pascal website, http://home.pages.de/~GNU-Pascal/ . The `about' section now lists the features of gpc-19990118 with example programs (which BTW are also part of the GPC distribtion (subdirectory `demos')). The online documentation now reflects the current state of what is distributed with GPC. Comments welcome, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

Re: Compiler bug
by Jan-Jaap van der Heijden 10 Apr '99

10 Apr '99

On Mon, 5 Apr 1999, The African Chief wrote: > Hi Peter and Jan-Jaap! > > > > > Hi, please, have a few days patience. I fried my /usr disk > > > > :-( You seem to be an expert in frying disks ... ;-)-: > > I was also beginning to think so ;/ Fortunately, most scsi hardware comes with a 5 year warranty :-) I've put a gcc-2.8.1 based mingw32 gpc binary (19990118) on agnes. That means it doesn't have the egcs related new(pfile) bug. Have fun, JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

Interesting cross-compiler behaviour
by Jo Dillon 10 Apr '99

10 Apr '99

I'm trying to build a Linux/Intel compiler to generate PowerPC/AIX binaries (as part of my ongoing quest not to use the Codewarrior pascal compiler). I've been following the instructs in http://www.objsw.com/CrossGCC. These instructions work fine when building a non-gpc-patched version of egcs 1.1.1, but the gpc-patched version goes into some sort of recursive make - it spews out the following over and over again, making a new make each time, until it hits about 200 make processes, whereupon they all exit and the process aborts with an error. The circular dependency thing looks interesting...any ideas? make[1]: Entering directory `/home/root/cross/build-gcc/gcc' if [ -f libgcc2.ready ] ; then \ true; \ else \ touch libgcc2.ready; \ fi make[1]: Circular cplib2.ready <- pascal dependency dropped. for i in `/home/root/cross/build-gcc/gcc/xgcc -B/home/root/cross/build-gcc/gcc/ --print-multi-lib`; do \ dir=`echo $i | sed -e 's/;.*$//'`; \ flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \ make GCC_FOR_TARGET="/home/root/cross/build-gcc/gcc/xgcc -B/home/root/cross/build-gcc/gcc/" \ AR="powerpc-ibm-aix4.2-ar" AR_FLAGS="rc" CC="gcc" CFLAGS="-g -O2" \ RANLIB="powerpc-ibm-aix4.2-ranlib" RANLIB_TEST="[ -f powerpc-ibm-aix4.2-ranlib ] || ( [ "i586-pc-linux-gnu" = "powerpc-ibm-aix4.2" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" \ LANGUAGES="c proto gcov c++ f77 pascal" \ HOST_PREFIX="" HOST_PREFIX_1="loser-" \ LIBGCC2_CFLAGS="-O2 -I/usr/include -DCROSS_COMPILE -DIN_GCC -g -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED ${flags}" \ MULTILIB_CFLAGS="${flags}" \ LIBGCC1="" LIBGCC2="libgcc2.a" \ dir="${dir}" stmp-multilib-sub; \ if [ $? -eq 0 ] ; then true; else exit 1; fi; \ done make[2]: Entering directory `/home/root/cross/build-gcc/gcc' rm -f libgcc2.a if [ -d . ]; then \ cd .; \ rm -f libgcc.a ; \ else true; \ fi make GCC_FOR_TARGET="/home/root/cross/build-gcc/gcc/xgcc -B/home/root/cross/build-gcc/gcc/" \ AR="powerpc-ibm-aix4.2-ar" AR_FLAGS="rc" CC="gcc" CFLAGS="-g -O2" \ HOST_PREFIX="" HOST_PREFIX_1="loser-" \ LANGUAGES="c proto gcov c++ f77 pascal" \ LIBGCC2_CFLAGS="-O2 -I/usr/include -DCROSS_COMPILE -DIN_GCC -g -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED " libgcc2.a -- Jo

2 1

Gpc and MacOS?
by Jo Dillon 10 Apr '99

10 Apr '99

Is there any way - any way at all - to get GPC to produce MacOS binaries? I have a huge chunk of code in Turbo Pascal-flavoured Object Pascal I need to port to the Mac. Metrowerks' Object Pascal compiler speaks a different dialect of the language - no virtual keyword (override's instead), no polymorphic functions (you can only override if you use the same parameters), and no constructors or destructors. Does anyone have any idea how this might be achieved? Getting 60,000-odd lines of Object Pascal to compile on the Mac is going to be a nightmare. -- Jo

2 1

Small and unimportant suggestion
by Jo Dillon 10 Apr '99

10 Apr '99

Perhaps you could indicate (in the diffs directory of the source) which release numbers of egcs the patches correspond to? If you've just downloaded egcs 1.1.1 and haven't built it yet it's hard to find out that it's actually egcs-2.91.60; if you /have/ built it yet then it's a bit late to patch the source. -- Jo

2 1

Re: FV4GPC (was Free Vision)
by The African Chief 10 Apr '99

10 Apr '99

Peter Gerwinski wrote: > > The African Chief wrote: > > > > I do not have the energy, time, or even the knowhow to port the > > other FV units (especially those with asm code in them) to GPC, > > so others will have to take on that task on (IIRC Peter is > > looking into doing this - am I right, Peter?). > > Yes, but the amount of other things I have to do is ... well ... > nicht mehr feierlich (= no more solemn; means: no joke). > Better don't hold your breath. :-( Ok. Are there any other takers? > > AFAICS the FV license terms are not GPL compatible and there may > > be other copyright issues that will make the ported FV Objects > > unit not distributable with GPC. > > That's indeed a problem, but I think that they did not decide to > be incompatible to the GPL but just wrote their license in a > careless way. I would be glad if someone could take over the > negotiations. I wrote to the alleged overseer of the FV project quite a while ago - I never got any response. I suppose I could write to Florian Klaempfl (who oversees the FPC development) and see what he can do. > > If anyone is interested, I can > > make a copy of my current "development" version available > > (perhaps on my homepage). > > I can set up a link to that project from the main GPC homepage > if that makes some sense. Or else we can place a homepage for > the FV4GPC project on Agnes in the GPC homepage tree. > > Any thoughts? I would think that Agnes is the best place for it, so the latter idea seems preferable. Basically, I have finished with the Objects unit. That could probably go on immediately (with the caveats [a] that EGCS-based GPC users on Linux and Win32 will not be able to compile the unit until the "New(pFile)" problem is solved, [b] that, for those on Solaris, etc., there may be "endian" issues that I am unaware of). We could just put the Objects unit there, since that is already ported to GPC - or we could put the whole package there for people to see what is required to port the rest of the units to GPC. Any thoughts? -- Best regards, Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.0 for Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

1 0

Re: move-string bug?
by Frank Heckenbach 10 Apr '99

10 Apr '99

Russ Whitaker wrote: > hi Frank > is this a miss-use of move, a bug, or something that has already been > fixed? The former. The capacity is stored internally as the first field of a string, so if you move to "temp", you'll overwrite temp's capacity. What you can do (and that's about the only case where a "move" seems acceptable besides low-level stuff) is to move the characters of a string, like the following: program astrings; var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr [1], temp [1], length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); {$X+} SetLength (temp, length (srcstr)); {$X-} writeln( temp.capacity, ' ', length(temp), ' ', temp); end. However, as you see in this program, to modify the length of a string, you need `SetLength', and this requires extended syntax, so I don't really recommend this method. It's usually easier to use the existing string operations (in this case, of course, a simple `:=' assignment would do, but I assume you have something more complicated in mind -- if you don't know how to achieve it with the string operations, be welcome to ask). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

move-string bug?
by Russ Whitaker 10 Apr '99

10 Apr '99

hi Frank is this a miss-use of move, a bug, or something that has already been fixed? gpc version 19990118, based on gcc-2.8.1 program as follows: program astrings; { show string bug } var srcstr : string(255); temp : string(120); begin srcstr := 'abcdefghi'; writeln( srcstr.capacity, ' ', length(srcstr), ' ', srcstr); writeln( temp.capacity ); move( srcstr, temp, length(srcstr)); writeln( temp.capacity, ' ', length(temp), ' ', temp); move( srcstr, temp, length(srcstr)+8); writeln( temp.capacity, ' ', length(temp), ' ', temp); end. Output is as follows: 255 9 abcdefghi 120 255 9 a 255 9 abcdefghi thanks, russ

1 0

Re: Free Vision (was File names, DPMI, and Turbo Vision for GPC)
by The African Chief 04 Apr '99

04 Apr '99

Marius Gedminas wrote: [...] > >The port of Free Vision to GPC is currently being worked on. > >Be welcome to join the project, so it will become usable sooner. > > I cannot promise much due to lack of free time, but it's already been > some time since I last inspected Free Vision. Is there a home page for > it now? Not that I know of - but you can get the latest versions from the FPC home page. I have ported the Objects unit to GPC (well, at least until the problem with "New'ing" pointer to files under the EGCS-based GPC compilers for Linux and Win32 are solved). I do not have the energy, time, or even the knowhow to port the other FV units (especially those with asm code in them) to GPC, so others will have to take on that task on (IIRC Peter is looking into doing this - am I right, Peter?). AFAICS the FV license terms are not GPL compatible and there may be other copyright issues that will make the ported FV Objects unit not distributable with GPC. If anyone is interested, I can make a copy of my current "development" version available (perhaps on my homepage). -- Best regards, Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.0 for Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

2 1

Re: File names (was: File names, DPMI, and Turbo Vision for GPC)
by Frank Heckenbach 04 Apr '99

04 Apr '99

Marius Gedminas wrote: > On Sat, Apr 03, 1999 at 12:29:12PM +0200, Peter Gerwinski wrote: > >Don't we need an additional variable `CasePreserving' then which > >is false on FAT but true on VFAT filesystems? > > What would it be used for? I don't think we need it. Actually, one can't rely on file names being stored unmodified at all. E.g., Dos (without LFN) will strip a trailing `.', except in `.' and `..', and anything beyond the 8+3 limitation, anyway. So, one must not rely on finding the file name as one stores it. All one can expect (I hope, at least) is that one can access the file by the same file name one used for storing (i.e., it will be modified the same way...) If one wants to canonicalize a file name, one can try `FExpand'... > >Even worse: This needn't be a constant for one OS but depends > >on the path you are accessing. A file on a FAT filesystem > >mounted under Linux has LFN=CaseSensitive=CasePreserving=false. > > I really think there is no need to go into that level of details. Other > Linux programs do not care for this, why should programs compiled with > GPC be an exception? I agree. I don't think a Linux user mounting a FAT FS with a file `foo' would expect it to show up when expanding `F*' (better mount it umsdos, anyway ;-). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: bugs under DOS/DJGPP
by Frank Heckenbach 03 Apr '99

03 Apr '99

Maurice Lombardi wrote: > Hi all > I have found a couple of small bugs in the last beta > gpc-19990118.i386-pc-djgppv201.zip > when using LFN=n 8.3 limitation in DOS 6.2 > > The problem comes from the fact that in this situation DOS makes > uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an > odd behavior displayed by the following short program: > > program ff; > uses dos; > var F:SearchRec; > begin > FindFirst('ff.pas',Anyfile,F); > writeln('l ',DosError); > FindFirst('FF.PAS',Anyfile,F); > writeln('u ',DosError); > end. > > DJGPP answers > l 0 > u 18 > i.e. it does NOT recognize the UPPERCASE filename, finding only the > lowercase one. > > In the same situation BP answers > l 0 > u 0 > i.e. it recognizes both. > > The defect can be traced to the function MatchPart in the FindNext > procedure. Correction need to be done only under DJGPP (at compilation > time) when LFN=n at execution time. A possible solution is given by the > attached diff. Thanks for the report. I fixed this -- actually a bit more general: I put into the RTS a new constant FileNamesCaseSensitive and a new function FLoCase to convert a character to lower case if FileNamesCaseSensitive is False and leave it unchanged otherwise, and use them in the Dos unit, so that unit doesn't need any ifdefs. However, I'm not sure about when FileNamesCaseSensitive should be set to False: First of all, I think it should be on all __OS_DOS__ platforms, not only __DJGPP__. Then, what about the LFN stuff? I haven't used such a system, but I've read that it's not really case-sensitive (something like, the case of the files as given on creation is stored, but matching is still insensitive). If that's so, FileNamesCaseSensitive should still be False, and we don't have to check LFN. Can anyone confirm or deny? > Similarly the environment names are always capitalized, so that > GetEnv('path') and GetEnv('PATH') give the same result as displyed in > the following short program: > > program ge; > uses dos; > var F:SearchRec; > begin > writeln('LFN=',GetEnv('LFN')); > writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); > writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); > writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); > end. BTW, something unrelated to your request: when searching for an executable, you might prefer to use: FSearchExecutable ('rhide', GetEnv (PathEnvVar)); This searches for `rhide.com', `rhide.exe' and `rhide.bat' under Dos (so you get more flexibility there), and on other systems for `rhide' without extension (so it works there, too) and only with executable permission (so it's safer than "FSearch ('rhide', ...)" there). PathEnvVar is currently 'PATH' on all systems, but one never knows what will happen... ;-) BTW, FSearchExecutable and PathEnvVar need the `gpc' unit rather than `dos' (and `FSearch' and `GetEnv' are also present in `gpc' as well as in `dos'). > DJGPP in DOS 6 with LFN=n answers: > > LFN=n > ll > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > whereas in BP gives always (even in a W95 dos box) > > LFN= > ll F:\DJGPP\BIN\rhide.exe > uu F:\DJGPP\BIN\RHIDE.EXE > lu F:\DJGPP\BIN\rhide.exe > > This behavior of automatic capitalization of environment variables is so > strange that I am not sure it must be reproduced in a unit which aims at > portability: I think that nearly everybody would write naturally > programs with environment variables uppercase as displayed by the set > command. Actually, I have changed this after 19990118 (only for Dos, of course, not affecting other systems where case matters). This is the corresponding entry from the `Fixed bugs' section of the To-Do list (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html): 19990202: Dos-like systems: convert parameter to GetEnv and CGetEnv to upper case (actually, libc should do so) > A completely different bug is in the crt unit. Readkey returns #10 i.e. > linefeed when one hits the return as well as the ^M keys which should be > #13. > THis is very strange since the demo program testcurs.c which comes with > the sources of PDcurses has the correct behavior. Oh yes, these CR/LF stuff is a bit nasty because if seems to depend on a number of things like terminal modes, which are affected by CheckBreak (perhaps a bug in PDCurses, at least a bit of undocumented behaviour there ;-). I changed CRT a little after 1990118, hope this will also fix the symptom you've experienced: 19990202: DJGPP: CRT: ReadKey returns #10, not #13, for the enter key when CheckBreak is True Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 3

bugs under DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta gpc-19990118.i386-pc-djgppv201.zip when using LFN=n 8.3 limitation in DOS 6.2 The problem comes from the fact that in this situation DOS makes uppercase all filenames. FindFirst/FindNext in the dos.pas unit has an odd behavior displayed by the following short program: program ff; uses dos; var F:SearchRec; begin FindFirst('ff.pas',Anyfile,F); writeln('l ',DosError); FindFirst('FF.PAS',Anyfile,F); writeln('u ',DosError); end. DJGPP answers l 0 u 18 i.e. it does NOT recognize the UPPERCASE filename, finding only the lowercase one. In the same situation BP answers l 0 u 0 i.e. it recognizes both. The defect can be traced to the function MatchPart in the FindNext procedure. Correction need to be done only under DJGPP (at compilation time) when LFN=n at execution time. A possible solution is given by the attached diff. Similarly the environment names are always capitalized, so that GetEnv('path') and GetEnv('PATH') give the same result as displyed in the following short program: program ge; uses dos; var F:SearchRec; begin writeln('LFN=',GetEnv('LFN')); writeln('ll ',FSearch('rhide.exe',GetEnv('path'))); writeln('uu ',FSearch('RHIDE.EXE',GetEnv('PATH'))); writeln('lu ',FSearch('rhide.exe',GetEnv('PATH'))); end. DJGPP in DOS 6 with LFN=n answers: LFN=n ll uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe whereas in BP gives always (even in a W95 dos box) LFN= ll F:\DJGPP\BIN\rhide.exe uu F:\DJGPP\BIN\RHIDE.EXE lu F:\DJGPP\BIN\rhide.exe This behavior of automatic capitalization of environment variables is so strange that I am not sure it must be reproduced in a unit which aims at portability: I think that nearly everybody would write naturally programs with environment variables uppercase as displayed by the set command. But for the same reason the first issue on FindFirst/FindNext must be corrected, because filename are usually written in uppercase in DOS, so that the actual behavior of gpc is completely unnatural. A completely different bug is in the crt unit. Readkey returns #10 i.e. linefeed when one hits the return as well as the ^M keys which should be #13. THis is very strange since the demo program testcurs.c which comes with the sources of PDcurses has the correct behavior. Hope this helps Maurice Lombardi -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

bugs in DOS/DJGPP
by Maurice Lombardi 03 Apr '99

03 Apr '99

Hi all I have found a couple of small bugs in the last beta -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

External references in GNU Pascal
by Mike Ainsworth 02 Apr '99

02 Apr '99

I've just started using GNU Pascal to port some legacy code across to Windows95/NT. I'm using DJGPP with the 19990118 beta copy of GPC. Everything appears to be working fine until I get to the linking stage. I'm getting unresolved references to Pascal procedures declared externally. I suspect I must be getting something fairly basic wrong, but I can't even get an example from the GPC documentation to build successfully! Suggestions would be gratefully received. Mike Ainsworth Example: -- foobar.pas -- module foobar; type footype = integer; var foo : footype; procedure setfoo(f : footype); begin foo := f; end; function getfoo : footype; begin getfoo := foo; end; end. -- what.pas -- program what(output); type footype = integer; procedure setfoo(f : footype); external; function getfoo : footype; external; begin setfoo(999); writeln(getfoo); end. -- Output -- gpc -o modtest.exe foobar.o what.o -lm -lgpc Error: what.o: In function `program_What': what.pas(8) Error: undefined reference to `Setfoo' what.pas(10) Error: undefined reference to `Getfoo' ========================================================================== Mike Ainsworth Praxis Critical Systems Limited, 20 Manvers Street, Bath BA1 1PX Tel: +44 1225 466991 Fax: +44 1225 469006 Email: ma(a)praxis-cs.co.uk ======= Software Engineering Safety-Critical Systems =======

3 2

Re: Bug in the arithmetics
by Frank Heckenbach 28 Mar '99

28 Mar '99

Miklos Cserzo wrote: > > Can you just send the correct results? Of course, we could try to > > compute them ourselves, but I suppose you already have them handy. > > Sure, possibly I should do so at the first time. > > More info: The program scans the input twice. First it computes the > central point of the vector space (average vector) and than it supposed to > report the distance of the individual vectors from it during the second > scan. The first phase is correct with the beta version but in the second > phase all the distances are 0. This is nonsense of course. I am not > absolutely sure whether it is an arithmetic bug. It could be anything in > the second 'repeat' cycle. I'll take a look at it in a few days, unless Peter finds out something before. BTW, was your compiler cross-built by any chance? ISTR that cross-building can cause problems with floating point operations. > Unfortunately the -g option is not able to > produce binaries on IRIX 6.2 so I can not debug the code. However, the > same code on the same input works fine if I use the 2.0 version of the > compiler. By the way, is the -g works on different platforms? More or less. It usually works, but it can cause compiler errors in some situations. In general, it can't handle well those things that don't exist in C, i.e. it might produce wrong debugging info or compiler errors. Any volunteers who know about the internals of debugging info? (I don't.) Meanwhile you could try "Writeln debugging", i.e. insert some Writeln's here and there to pin down the instruction that's wrong. BTW, the results are correct under Linux, so it really seems to be something system-specific. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Bug in the arithmetics
by Frank Heckenbach 28 Mar '99

28 Mar '99

I think I sent this already, but it didn't come back to me. Sorry if someone gets this twice. Miklos Cserzo wrote: > > Can you just send the correct results? Of course, we could try to > > compute them ourselves, but I suppose you already have them handy. > > Sure, possibly I should do so at the first time. > > More info: The program scans the input twice. First it computes the > central point of the vector space (average vector) and than it supposed to > report the distance of the individual vectors from it during the second > scan. The first phase is correct with the beta version but in the second > phase all the distances are 0. This is nonsense of course. I am not > absolutely sure whether it is an arithmetic bug. It could be anything in > the second 'repeat' cycle. I'll take a look at it in a few days, unless Peter finds out something before. BTW, was your compiler cross-built by any chance? ISTR that cross-building can cause problems with floating point operations. > Unfortunately the -g option is not able to > produce binaries on IRIX 6.2 so I can not debug the code. However, the > same code on the same input works fine if I use the 2.0 version of the > compiler. By the way, is the -g works on different platforms? More or less. It usually works, but it can cause compiler errors in some situations. In general, it can't handle well those things that don't exist in C, i.e. it might produce wrong debugging info or compiler errors. Any volunteers who know about the internals of debugging info? (I don't.) Meanwhile you could try "Writeln debugging", i.e. insert some Writeln's here and there to pin down the instruction that's wrong. BTW, the results are correct under Linux, so it really seems to be something system-specific. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Bug in the arithmetics
by Frank Heckenbach 25 Mar '99

25 Mar '99

Miklos Cserzo wrote: > The attached code compiles and runs on the attached sample input file but > the result is incorrect. (Under IRIX 6.2, latest beta source.) The program > supposed to calculate vector distance in a multi dimensional space. The > same code is working fine with the 2.0 version on the same input file. Can you just send the correct results? Of course, we could try to compute them ourselves, but I suppose you already have them handy. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Bug in the arithmetics
by Miklos Cserzo 24 Mar '99

24 Mar '99

Muchachos! The attached code compiles and runs on the attached sample input file but the result is incorrect. (Under IRIX 6.2, latest beta source.) The program supposed to calculate vector distance in a multi dimensional space. The same code is working fine with the 2.0 version on the same input file. Cheers, miklos

1 0

-g on IRIX
by Miklos Cserzo 23 Mar '99

23 Mar '99

Hi Folks, the debug-option (-g) of the latest beta-kit is broken under IRIX 6.2. It is not able to produce binaries. Cheers, miklos

1 0

gcc sources
by Paulo Tomé 22 Mar '99

22 Mar '99

Hello. For the gpc installation I need gcc 2.7.2.1 sources. Where can I get them? Regards. Paulo Tomé

1 0

Re: gcc sources
by Peter Gerwinski 22 Mar '99

22 Mar '99

Hello! Paulo TomÃ© wrote: > For the gpc installation I need gcc 2.7.2.1 sources. > Where can I get them? >From any GNU mirror. But I recommand to get gpc-19990118 from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ instead. It works with gcc-2.8.1 or egcs-1.1.1 and is more stable than gpc-2.0 anyway. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

GPC newsgroup and announce list?
by Peter Gerwinski 17 Mar '99

17 Mar '99

Hi, folks! A long time ago we already had discussed about this, but let us try it again ... It seems as if people looking for help with GPC do not find this mailing list, and even if they do, they might not want to subscribe but would prefer to have a look at us first. Other people would like to stay up-to-date with information about GPC but are not interesting in our discussions. So what about following the example of the DJGPP folks and do the following: * Create a Usenet newsgroup `comp.lang.pascal.gnu'. * Gate all emails to the GPC mailing list to the newsgroup and vice versa. * Create an additional, moderated mailing list especially for GPC announcements. This could be combined with a move of the GPC mailing list to a host which runs a list server software (majordomo) which would simplify subscribing and unsubscribung to the mailing list, allow for an automatic online list archive, etc. (I have one with the nice domain name `gnu.de'.:-) What do you think? We also would be glad if someone familiar with Usenet management (RfD, CfV, etc.) and/or setting up a mail/news gateway could take that job. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

4 9

Re: [ANN] Chief's Unzip v1.10 released
by Frank Heckenbach 15 Mar '99

15 Mar '99

Dr A A Olowofoyeku wrote: > Unzip comes to GPC! This is to announce the release of Chief's Unzip > v1.10. [...] > > PS: I would like to keep a list of the various GPC platforms on which > the package has been used successfully, so if you are able to compile > and use it successfully under anything other than Linux, mingw32 and > djgpp, please drop me a line. If you have had to amend anything to > make it compile/work correctly, please send me the diffs so that I > can find ways of merging the changes into the main distribution. Works fine under Linux, as far as I can tell, but is missing some error handling (e.g. given an invalid zip file name, it says "-12 files processed"). Crashes with Bus error under Solaris when trying to access a zip file. I suppose it's an endianness problem with the file contents. You might want to look at the "Routines to handle endianness" in gpc.pas. Frank PS: I'd prefer lower case file names (in the sample command lines, the files themselves etc.), because upper case file names are quite uncommon on those systems where it makes a difference. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

[ANN] Chief's Unzip v1.10 released
by Dr A A Olowofoyeku 15 Mar '99

15 Mar '99

Hi folks! Unzip comes to GPC! This is to announce the release of Chief's Unzip v1.10. This is a freeware package with sources for unzipping ZIP archives. The package supports GPC (January '99 beta: tested under Linux, mingw32, and djgpp); BP 7.0 (Dos, Dpmi, Win16); Delphi (Win16 and Win32), Virtual Pascal (OS/2 and Win32), and FreePascal (Dos, Linux). This package is a Pascal port of the InfoZip C sources. Example programs are included. Thanks to Frank for identifying some non-portable things in the previous releases and to Peter for supplying a "portable continuation". This is the URL to the package; http://ourworld.compuserve.com/homepages/African_Chief/chfzip11.zip PS: I would like to keep a list of the various GPC platforms on which the package has been used successfully, so if you are able to compile and use it successfully under anything other than Linux, mingw32 and djgpp, please drop me a line. If you have had to amend anything to make it compile/work correctly, please send me the diffs so that I can find ways of merging the changes into the main distribution. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.00 for Win32 ftp://ftp.simtel.net/pub/simtelnet/win95/install/chief500.zip

2 2

new email, temporary (ii)
by stefand＠ferrari.lcam.u-psud.fr 11 Mar '99

11 Mar '99

Hallo, you are receiving this message because your name is in my nickname list, or because I have more or less recently received an email from you, sent to one of my accounts at the University of Tennessee, be that sad(a)utkux.utcc.utk.edu or sad(a)utk.edu or anything else along the lines of sad@..(ending in utk.edu). Unfortunately, the mail server on this is account is currently in a state of confusion about my person. Email sent to me bounces and the system claims that I don't exist or you have mistyped my name. These claims are greatly exaggerated. I have notified the sysadmins at UTK asking for it to be fixed asap. For now please use the following address to get in touch with me: stefand(a)lcam.u-psud.fr Please, take a note of it and update your nickname or email alias files accordingly. I will let you know as soon as my usual email address starts working again. The 'Reply-To:' header in my own email setup has been updated, so simple replies to recent email messages from me should work as expected. Kind regard & cheers, Stefan A. Deutscher PS1: This message is generated automatically. You should receive it only about once, and for email sent to any of my accounts at utk.edu. PS2: The local system being used to mail this message decided to mess up as well and some people received only an empty message. So I send it again, hoping that this should arrive in all its beauty.

1 0

new email (temporary)
by stefand＠ferrari.lcam.u-psud.fr 11 Mar '99

11 Mar '99

Hallo, I have more or less recently received an email from you, sent to one of my accounts at the University of Tennessee, be that sad(a)utkux.utcc.utk.edu or sad(a)utk.edu or anything else along the lines of sad@..(ending in utk.edu). Unfortunately, the mail server on this is account is currently in a state of confusion about my person. Email sent to me bounces and the system claims that I don't exist or you have mistyped my name. These claims are greatly exaggerated. I have notified the sysadmins at UTK asking for it to be fixed asap. For now please use the following address to get in touch with me: stefand(a)lcam.u-psud.fr Please, take a note of it and update your nickname or email alias files accordingly. I will let you know as soon as my usual email address starts working again. The 'Reply-To:' header in my own email setup has been updated, so simple replies to recent email messages from me should work as expected. Kind regard & cheers, Stefan A. Deutscher PS: This message is generated automatically. You should receive it only once, and for email sent to any of my accounts at utk.edu.

1 0

arrays of dynamic size
by scholle＠pol-15.uni-duisburg.de 11 Mar '99

11 Mar '99

Hi, Folks! I am still working on this damned dyn-array problem. For what reason is it that a construction of type MaxFirmenGroesse = ^integer; type workers = array [1..MaxFirmenGroesse] of (anything) does not work? Can you please tell me how the correct form would look like? Where is my mistake? -- Stefan Czinczoll scholle(a)uni-duisburg.de

2 1

Arrays with variable size?
by FSR SoWi 10 Mar '99

10 Mar '99

Hi, Folks! I am still working on my global working simulation and for performance reasons I thougt it would be better to use arrays of variable size (so that the machine will not go _completely_ to its knees ;-). Can you please give me some advice on this one? How has the declaration to look like? Thanks in advance -- Stefan Czinczoll scholle(a)uni-duisburg.de

2 1

Internal implementation of files
by Frank Heckenbach 07 Mar '99

07 Mar '99

Hi, this posting is about the internal implementation of Pascal files in the Run Time Systems. Most Pascal programs are not affected by this, so many programmers can just ignore this. In the C library, there are two kinds of file access routines. One kind of them is for integer file handles (which interface directly to the OS on most platforms), the others use `FILE *' pointers. They do internal buffering and some other things, and internally use integer file handles. Pascal files in GPC are currently based on `FILE *' pointers. I want to change them to use integer file handles, because I've found that using `FILE *' causes some disadvantages: - It's obviously less efficient to go through 2 extra layers (Pascal file -> FILE * and FILE * -> Integer) than only 1 layer. So this change should speed up file operations (though probably not by very much). - Both FILE * and Pascal files do internal buffering which is not only inefficient, but makes it hard to control how much data is read ahead. This is important for terminals, pipes etc. and currently involves some kludges to get it approximately right. - I've found that the semantics of FILE * and those of Pascal files don't really fit together well (e.g. the ways of representing run time errors or end-of-file), so currently a lot of RTS code deals with converting between those semantics. - By using integer handles, we get less dependent on bugs in routines out of our control. E.g., I just came across a bug (I think) in fwrite() (a FILE * routine) in a special situation, while write() (the corresponding integer routine) works correctly in this situation. Note, this does not mean that one should use integer file handles in Pascal programs, it's just about the way that `Text', `File' and `File of foo' are represented internally. The interface to Pascal programs would not change except for the 2 things that currently deal with FILE * (aka CFilePtr): - AssignCFile and the CFile field of BindingType. I added them only recently, so most of you probably don't even know they exist. ;-) They are needed for some purposes in the RTS and the units, but I could do the same with integer handles. - The GetFile function which currently returns the FILE * of a Pascal file. This function would vanish, and instead there would be GetFileHandle which does the same that currently `FileNo (GetFile (f))' does. Since most usages of GetFile that I'm aware of are in fact together with FileNo, this change would actually simplify those programs. A problem would only be there if a program really uses the FILE * for anything directly. However, a solution using fdopen() seems possible. So, if there are no protests, I'm going to do this change until the next release. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

conformance tests
by hchang-tky＠umin.u-tokyo.ac.jp 24 Feb '99

24 Feb '99

I am developing a Pascal interpreter adapted for simulation of biological systems. I want to check my interpreter, and could you please let me know how (or if) I can get conformance tests? Thank you. Hangil Chang.

2 1

Re: bug in sin/cos (longreal) ?
by Frank Heckenbach 24 Feb '99

24 Feb '99

Maurice Lombardi wrote: > Hi all, > I have found a strange bug which popped up in the last beta. > when compiling the following short program > > program bug; > var x:real; y:LongReal; > begin > x:=1; y:=1; > writeln(cos(x)); > writeln(cos(y)); > writeln(cos(pi*x)); > end. > > the linker says that it cannot find module cosl (* Not module cosl, but the C routine cosl(). *) > in the lines containing the second and third writeln > which demand for cos(longreal) either directly > or indirecly (presumably pi is long real). Yes, that's a new bug. Since it only shows on systems without cosl() etc. in their libm, like DJGPP, we didn't note it so far. Here's the fix, if you have the GPC sources and can recompile them: diff -p -r -U3 -N -X /home/frank/script/gpcdiff.exclude orig/p/rts.c p/rts.c --- orig/p/rts.c Wed Feb 17 21:56:06 1999 +++ p/rts.c Wed Feb 24 02:01:13 1999 @@ -78,16 +78,16 @@ struct rts_symbol rts[] = { { r_COLLECT,"_p_collect", NULL_RTX, NULL_TREE, 0}, - { p_ARCTAN, "atan", NULL_RTX, NULL_TREE, 0}, - { p_COS, "cos", NULL_RTX, NULL_TREE, 0}, + { p_ARCTAN, "_p_arctan", NULL_RTX, NULL_TREE, 0}, + { p_COS, "_p_cos", NULL_RTX, NULL_TREE, 0}, { p_EXP, "_p_exp", NULL_RTX, NULL_TREE, 0}, { p_LN, "_p_ln", NULL_RTX, NULL_TREE, 0}, - { p_SIN, "sin", NULL_RTX, NULL_TREE, 0}, + { p_SIN, "_p_sin", NULL_RTX, NULL_TREE, 0}, { p_SQRT, "_p_sqrt", NULL_RTX, NULL_TREE, 0}, - { pp_ARCTAN, "atanl", NULL_RTX, NULL_TREE, 0}, - { pp_SIN, "sinl", NULL_RTX, NULL_TREE, 0}, - { pp_COS, "cosl", NULL_RTX, NULL_TREE, 0}, + { pp_ARCTAN, "_pp_arctan", NULL_RTX, NULL_TREE, 0}, + { pp_SIN, "_pp_sin", NULL_RTX, NULL_TREE, 0}, + { pp_COS, "_pp_cos", NULL_RTX, NULL_TREE, 0}, { pp_EXP, "_pp_exp", NULL_RTX, NULL_TREE, 0}, { pp_LN, "_pp_ln", NULL_RTX, NULL_TREE, 0}, { pp_SQRT, "_pp_sqrt", NULL_RTX, NULL_TREE, 0}, Otherwise, you can work around the bug until the next release by linking the following C file: #include <math.h> long double sinl (long double x) { return sin (x); } long double cosl (long double x) { return cos (x); } long double sqrtl (long double x) { return sqrt (x); } long double logl (long double x) { return log (x); } long double expl (long double x) { return exp (x); } long double atanl (long double x) { return atan (x); } long double powl (long double x, long double y) { return pow (x, y); } Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

bug in sin/cos (longreal) ?
by Maurice Lombardi 23 Feb '99

23 Feb '99

Hi all, I have found a strange bug which popped up in the last beta. when compiling the following short program program bug; var x:real; y:LongReal; begin x:=1; y:=1; writeln(cos(x)); writeln(cos(y)); writeln(cos(pi*x)); end. the linker says that it cannot find module cosl in the lines containing the second and third writeln which demand for cos(longreal) either directly or indirecly (presumably pi is long real). It popped up when I tried to recompile old programs which used a lot of cos(pi* ). With grep I do not find cosl (and sinl) in any library, only in gpc1.exe (and similars cc1.exe cc1plus.exe f771.exe). Have I missed something in the installation ? (I work with DJGPP / gpc-19990118_i386-pc-djgppv201.zip) thanks in advance ! -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

demo
by Russ Whitaker 21 Feb '99

21 Feb '99

tried to compile "pi.pas" and got as far as ld: cannot open -lgmp: No such file or directory so how do i create -lgmp and what directory does it belong in? thanks Russ russwhit(a)mind.net

2 1

subscribe
by Paolo M. Pumilia 20 Feb '99

20 Feb '99

subscribe pumilia(a)est.it

2 1

Re: Are `gpc-*.c' still modified GCC source files?
by Nick Burrett 19 Feb '99

19 Feb '99

Peter Gerwinski <peter(a)gerwinski.de> writes: > I am thinking about doing a major change in the structure of the > GPC source. > > Until now, some GPC source files (gpc-typeck.c, gpc-common.c, ...) > are modified GCC source files, and all GPC-specific changes are > marked `#ifdef GPC'. > > AFAIK, the reason for this is that we want to profit with GPC > from bug fixes in the GCC frontend. But are we really doing this ? > Meanwhile the `#ifdef GPC' parts are getting more and more > making the files in question less and less readable. > Furthermore, sticking to the GCC frontend prevents me from > changing the parameter lists of certain central functions, > thus introducing code duplication and unncessary bugs. > > What do you think? I think it is a good idea. I had been considering starting the effort on this myself. It should make the front end simpler. Nick.

3 2

Pascal
by Gareth Batley 19 Feb '99

19 Feb '99

Hello, I have been trying to connect with your ftp site but I cannot find the no. for it anywhere. Can you supply me with your IP no. Thanks, Gareth Batley. ----------------------------------------------------------------------- Gareth Batley, Tel: +44-0113-2335180 Email: gab(a)ast.leeds.ac.uk Leeds University +44-0113-2336691 -----------------------------------------------------------------------

2 1

Re: Pascal
by Nick Burrett 19 Feb '99

19 Feb '99

Gareth Batley <gab(a)ast.leeds.ac.uk> writes: > I have been trying to connect with your ftp site but I cannot find the no. for > it anywhere. Can you supply me with your IP no. agnes.dida.physik.uni-essen.de is 132.252.78.226 You may want to use the mirror at Imperial College, London. ftp://sunsite.doc.ic.ac.uk/packages/gnu/MORE_GNU/gnu_pascal/beta sunsite.doc.ic.ac.uk is 193.63.255.4 Nick.

1 0

Are `gpc-*.c' still modified GCC source files?
by Peter Gerwinski 18 Feb '99

18 Feb '99

Hi, all! I am thinking about doing a major change in the structure of the GPC source. Until now, some GPC source files (gpc-typeck.c, gpc-common.c, ...) are modified GCC source files, and all GPC-specific changes are marked `#ifdef GPC'. AFAIK, the reason for this is that we want to profit with GPC from bug fixes in the GCC frontend. Meanwhile the `#ifdef GPC' parts are getting more and more making the files in question less and less readable. Furthermore, sticking to the GCC frontend prevents me from changing the parameter lists of certain central functions, thus introducing code duplication and unncessary bugs. Maybe I have overlooked some crucial benefit we get from keeping the current structure, but if not, I am planning to drop all `#ifdef GPC' constructs when doing the next major changes on GPC. What do you think? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

Lots of Junk mail via gpc list lately
by stefand＠ferrari.lcam.u-psud.fr 17 Feb '99

17 Feb '99

Hi all, lately, I receive lots of junk mail seemingly sent via the gpc mailing list. One example of the many is appended. If there is a whole in the list, could this be plugged with some sort of spam filter, or some mechanism that allows only properly subscribed users to mail via the list? Thanks in advance! Stefan Forwarded message: > From gpc-request(a)santra.hut.fi Tue Feb 16 15:26:20 1999 > From: remove(a)1vm.com > Subject: New Dual Mount Copy Holder by Rubbermaid > Date: Tue, 16 Feb 1999 11:19:44 > Message-Id: <331.343203.708664@unknown> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > > > Amazing new copy holder can be mounted directly on your computer > monitor or it can be used freestanding. Unique design is specifically > engineered to increase your efficiency while reducing eye strain, > stress, and fatigue. > > Quality Rubbermaid features include adjustable viewing positions, > non-glare surface, spring load paper clamp and detachable line guide. > Folds flat for easy out-of-the-way storage. > > This isn't a cheap clip on, but a full platform copy holder. > > Special internet savings click here http://www.1vm.com/~rcc and save > over $20 from comparable models. > > Sender: Robert Craig Corp. Phone: 1-800-890-7510 Email: > robertcraigcorp(a)prodigy.net Details: http://www.1vm.com/~rcc Remove: > REMOVE(a)1vm.com > > To be removed from future service notifications reply to: > REMOVE(a)1vm.com > > > > > Emerge Corporate Email System for Windows 95/98/NT. *** Evaluation > version *** Copyright (c) 1994-99 EOL Corporation. > http://www.earthonline.com/eval > -- ========================================================================= Stefan A. Deutscher | (+33-(0)1) voice fax Laboratoire des Collisions Atomiques et | LCAM : 6915-7699 6915-7671 Mol\'{e}culaires (LCAM), B\^{a}timent 351 | home : 5624-0992 call first Universit\'{e} de Paris-Sud | email: sad(a)utk.edu 91405 Orsay Cedex, France (Europe) | (forwarded to France) ========================================================================= Do you know what they call a quarter-pounder with cheese in Paris?

2 1

[PATCH] Fixing gpc-19990118 install process.
by Niels Kristian Bech Jensen 15 Feb '99

15 Feb '99

Hi, This patch fixes the install process for gpc-19990118. If you do a ``make LANGUAGES=c; make LANGUAGES=c install'' from a source tree which includes gpc, the following files are built and installed: ${prefix}/doc/gpc/demos/* ${prefix}/info/gpc.info* ${prefix}/lib/gcc-lib/.../gpc-cpp ${prefix}/lib/gcc-lib/.../units/* The patch fixes this problem (and corrects a typo in gpc/p/units/crt.pas.) diff -urN gpc.orig/p/Make-lang.in gpc/p/Make-lang.in --- gpc.orig/p/Make-lang.in Mon Jan 18 18:10:16 1999 +++ gpc/p/Make-lang.in Sun Feb 14 07:14:49 1999 @@ -226,11 +226,13 @@ cd p; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) ../gpc1$(exeext) gpc-cpp$(exeext): $(P) mbchar.o cexp.o $(srcdir)/p/gpc-cccp.c $(srcdir)/p/version.c - cd p; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) ../gpc-cpp$(exeext) + case "$(LANGUAGES)" in \ + *[Pp]ascal*) cd p; $(MAKE) $(FLAGS_TO_PASS) $(GPC_FLAGS_TO_PASS) ../gpc-cpp$(exeext) ;; \ + *) ;; esac pascal.rts: p/rts/Makefile case "$(LANGUAGES)" in \ - *pascal*) cd p/rts && $(MAKE) \ + *[Pp]ascal*) cd p/rts && $(MAKE) \ GCC_FOR_TARGET="`case '$(GCC_FOR_TARGET)' in \ './xgcc -B./'*) echo ../../xgcc -B../../;; \ *) echo '$(GCC_FOR_TARGET)';; esac`" \ @@ -249,7 +251,8 @@ # mk: but it needs $(EXTRA_OBJS) and $(LIBGCC), what to do? p/rts/Makefile: $(srcdir)/p/rts/Makefile.in $(srcdir)/p/rts/configure \ $(GCC_PARTS) stmp-headers - if [ -d p/rts ]; then true; else mkdir p/rts; fi + case "$(LANGUAGES)" in \ + *[Pp]ascal*) if [ -d p/rts ]; then true; else mkdir p/rts; fi; \ src=`cd $(srcdir); pwd`; \ cd p/rts; \ CC="`case '$(GCC_FOR_TARGET)' in \ @@ -259,7 +262,8 @@ './xgpc -B./'*) echo ../../xgpc -B../../;; \ *) echo '$(GPC_FOR_TARGET)';; esac`" \ $(RTS_FLAGS_TO_PASS) CONFIG_SITE=nonexisting-file $(SHELL) \ - $${src}/p/rts/configure --srcdir=$${src}/p/rts + $${src}/p/rts/configure --srcdir=$${src}/p/rts ;; \ + *) ;; esac # Derive parts of the documentation of the run time library directly # from the source. @@ -300,8 +304,10 @@ pascal.install-normal: install-gpc-cpp install-libgpc pascal.install-units pascal.install-demos install-gpc-cpp: gpc-cpp$(exeext) - -rm -f $(libsubdir)/gpc-cpp$(exeext) - $(INSTALL_PROGRAM) gpc-cpp$(exeext) $(libsubdir)/gpc-cpp$(exeext) + case "$(LANGUAGES)" in \ + *[Pp]ascal*) rm -f $(libsubdir)/gpc-cpp$(exeext); \ + $(INSTALL_PROGRAM) gpc-cpp$(exeext) $(libsubdir)/gpc-cpp$(exeext) ;; \ + *) ;; esac install-libgpc: pascal.install-dir pascal.rts -if [ -f libgpc.a ] ; then \ @@ -313,13 +319,16 @@ else true; fi $(srcdir)/p/units/crtc.h: $(srcdir)/p/units/crt.inc - (echo '/* Automatically generated from crt.inc'; \ + case "$(LANGUAGES)" in \ + *[Pp]ascal*) (echo '/* Automatically generated from crt.inc'; \ echo ' DO NOT CHANGE THIS FILE MANUALLY! */'; \ sed -e '1,/^const/d;s/^$[^=]*$= #\?$[^;]*$;$.*;$\?$$/#define \1 \2/' \ - -e '/^.\$$/d' < $(srcdir)/p/units/crt.inc) > $(srcdir)/p/units//crtc.h + -e '/^.\$$/d' < $(srcdir)/p/units/crt.inc) > $(srcdir)/p/units//crtc.h ;; \ + *) ;; esac pascal.install-units: pascal.install-dir $(srcdir)/p/units/crtc.h - $(INSTALL_DATA) $(srcdir)/p/rts/gpc.pas $(unitsubdir)/gpc.pas; \ + case "$(LANGUAGES)" in \ + *[Pp]ascal*) $(INSTALL_DATA) $(srcdir)/p/rts/gpc.pas $(unitsubdir)/gpc.pas; \ chmod a-x $(unitsubdir)/gpc.pas; \ $(INSTALL_DATA) $(srcdir)/p/rts/internal.pas $(unitsubdir)/internal.pas; \ chmod a-x $(unitsubdir)/internal.pas; \ @@ -331,14 +340,17 @@ for file in *.pas *.inc *.c *.h; do \ $(INSTALL_DATA) $$file $(unitsubdir)/$$file; \ chmod a-x $(unitsubdir)/$$file; \ - done + done ;; \ + *) ;; esac pascal.install-demos: pascal.install-dir - cd $(srcdir)/p/demos; \ + case "$(LANGUAGES)" in \ + *[Pp]ascal*) cd $(srcdir)/p/demos; \ for file in *; do \ $(INSTALL_DATA) $$file $(demodir)/$$file; \ chmod a-x $(demodir)/$$file; \ - done + done ;; \ + *) ;; esac # Install the driver program as $(target)-gpc # and also as either gpc (if native) or $(tooldir)/bin/gpc. @@ -380,7 +392,8 @@ fi pascal.install-info: pascal.info - -rm -f $(infodir)/gpc.info* ; + case "$(LANGUAGES)" in \ + *[Pp]ascal*) rm -f $(infodir)/gpc.info* ; \ if [ -f p/doc/gpc.info ]; then \ cd p/doc; \ else \ @@ -388,8 +401,9 @@ fi; \ for f in gpc.info*; do \ $(INSTALL_DATA) $$f $(infodir)/$$f; \ - done - -chmod a-x $(infodir)/gpc.info* + done; \ + chmod a-x $(infodir)/gpc.info* ;; \ + *) ;; esac pascal.install-man: $(srcdir)/p/gpc.1 -if [ -f gpc1$(exeext) ] ; then \ @@ -413,13 +427,15 @@ else true; fi pascal.install-dir: - -for directory in $(bindir) $(libsubdir) $(unitsubdir) $(demodir) $(infodir) $(mandir); do \ + case "$(LANGUAGES)" in \ + *[Pp]ascal*) for directory in $(bindir) $(libsubdir) $(unitsubdir) $(demodir) $(infodir) $(mandir); do \ if [ -d $$directory ]; then \ true; \ else \ mkdir -p $$directory; \ fi; \ - done + done ;; \ + *) ;; esac # Install gpc1 et.al. # Do *not* overwrite files if they exist. diff -urN gpc.orig/p/units/crt.pas gpc/p/units/crt.pas --- gpc.orig/p/units/crt.pas Sat Jan 9 10:55:24 1999 +++ gpc/p/units/crt.pas Sun Feb 14 07:17:19 1999 @@ -6,7 +6,7 @@ CRT (Crt Replacement Tool) -- BP compatible CRT unit This unit needs the ncurses library which should be available for -almost any system. For Dos systems, where ncurses is not availale, +almost any system. For Dos systems, where ncurses is not available, AFAIK, it is configured to use PDCurses 2.3 instead (file curse23.zip). On Unix systems with X11, it can also use PDCurses to produce pure X11 programs. The advantage is that they don't need an xterm with a valid -- Niels Kristian Bech Jensen -- nkbj(a)image.dk -- http://www.image.dk/~nkbj/ ----------->> Stop software piracy --- use free software! <<-----------

1 0

Mailing list
by Pablo Bendersky 14 Feb '99

14 Feb '99

Hi, Does anyone knows about a mingw32 mailing list ? I've been looking for one for weeks and I couldn't find it. Thanks, --- Pablo Gabriel Bendersky bender(a)einstein.com.ar UIN : 1916679 Buenos Aires - Argentina

4 4

Re: enum bug in gpc-19990118
by Frank Heckenbach 13 Feb '99

13 Feb '99

Sam B wrote: > Hello all, > I posted several months ago about a bug involving the incorrect > recognition of an enumerated type by the compiler, when the type > was imported from a unit in two different modules. I understand that > this bug was on the list of fixed bugs for gpc-19990118, but I still > get exactly the same error! Has anyone else tested this bug under > the current version? Well, yes... :-( This bug is quite involved... some instances of it were fixed, but as it turned out not all of them... :-( At least I can reproduce the bug, and all I can say now is that I hope it will be fixed by the next release. I'm adding your test program to the test suite (sam12.pas), so we'll test this program explicitly when we believe the bug to be fixed next time... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

enum bug in gpc-19990118
by Sam B 13 Feb '99

13 Feb '99

Hello all, I posted several months ago about a bug involving the incorrect recognition of an enumerated type by the compiler, when the type was imported from a unit in two different modules. I understand that this bug was on the list of fixed bugs for gpc-19990118, but I still get exactly the same error! Has anyone else tested this bug under the current version? Sam B. PS. I am running on redhat 5.0, configured as followes: > gpc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 And the error produced is: > gpc p.pas p.pas: In function `program_P': p.pas:23: incompatible type for argument 1 of `U_proc' Test program follows: --- begin test program --- unit e; interface type t_e = ( e_a, e_b ); implementation begin end. unit u; interface uses e; procedure u_proc(e: t_e); implementation procedure u_proc; begin end; begin end. program p; uses e, u; begin u_proc(e_a); end. --- end test program --- ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Turbo Pascal 'Append' Procedure
by C.P.Osborne 11 Feb '99

11 Feb '99

I hope this is the right place to come for this sort of advice - if not, please point me in a better direction . . . . . I am trying to convert my Turbo Pascal code to allow compilation using GNU Pascal. I have hit a problem with the 'Append' procedure, which does not seem to be supported in gpc. How should I go about adding lines to the end of existing text files? I have replaced 'Assign' with the appropriate procedure outlined on the GNU Pascal web pages - is there a similar 'fix' for 'Append'?? With thanks, Colin ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Colin Osborne Dept. of Animal and Plant Sciences University of Sheffield Sheffield S10 2TN Tel: 0114 222 0086 Fax: 0114 222 0002 ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~

2 1

Please give me some advice!
by Fachschaftsrat SoWi 11 Feb '99

11 Feb '99

Hello, Folks! My Name is Stefan Czinczoll and I am working on an simulation project for our faculty of Social Sciences. I decided to code it in GNU-Pascal for maximum transparency and portability. Can you please subscribe me to your mailing-list and also provide me of a location where I can find some example programs? I would like to get your mailing-list under my personal account / email: scholle(a)uni-duisburg.de The machine i am currently working on is a HP-UX hp9000s800. Best regards and thanx in advance, Stefan Czinczoll -- Fachschaft SoWi Universitaet Duisburg http://www.uni-duisburg.de/FB1/FSR/home.html fsrsowi(a)uni-duisburg.de

2 1

unsubscribe
by Christian Bockermann 10 Feb '99

10 Feb '99

unsubscribe It was a nice time reading this list and I think GPC is a great compiler. Unfortunately I have no more time reading all the mails, so I have to unsubscribe. Bis denn, Chris ____________________________________________ PGP : mail to pgp-request(a)bockermann.ping.de

1 0

linux 2.2 NFS bug
by Patrick Goetz 09 Feb '99

09 Feb '99

Some day I'll get it right. :^(p Anyway, turns out the NFS bug is NOT in linux 2.2, but rather in Solaris 2.5/2.6 which is what we are using for our NFS servers. ********************************************** The meek shall inherit nothing. - Frank Zappa ********************************************** _ Patrick Goetz _| ~-. Dept. of Mathematics \, *_} The University of Texas at Austin pgoetz(a)mail.utexas.edu \( Austin, Texas 78712-1084 Phone: (512) 232-2746 http://www.ma.utexas.edu/users/pgoetz

1 0

gpc segmentation fault
by Patrick Goetz 09 Feb '99

09 Feb '99

Hi - A couple of days ago I called to report random segmentation faults when running simple gpc compiled programs under linux 2.2.0-pre4. I'm just writing back to report that we discovered what the bug is, and it has nothing to do with gpc. Apparently linux 2.2 is suffering from a rather serious NFS bug which causes a byte to be lost during file transfer. Losing a byte when trying execute a program of course most likely result in a segmentation fault. This explains why the problem was inexplicably sporadic. Sorry for the bad bug report. ********************************************** The meek shall inherit nothing. - Frank Zappa ********************************************** _ Patrick Goetz _| ~-. Dept. of Mathematics \, *_} The University of Texas at Austin pgoetz(a)mail.utexas.edu \( Austin, Texas 78712-1084 Phone: (512) 232-2746 http://www.ma.utexas.edu/users/pgoetz

1 0

Segmentation fault when using gpc 2.0 with linux 2.2.0-pre4
by Patrick Goetz 09 Feb '99

09 Feb '99

Hi - I've been running gpc version 2.0 on my linux 2.0.x machines without any problems. Recently we upgraded some of them to linux 2.2.0-pre4. Now, simple arithmetic assignments cause segmentation violations. For example, program add2(input, output); var first : real; second : real; sum : real; begin write('Please enter the first value: '); readln(first); write('Now enter the second value: '); readln(second); sum := first / second; writeln(first, ' div ', second, ' is ', sum); end. compiles OK, but causes a segmentation violation, but not consistently. If I compile it again adding, say a single space somewhere, it runs fine the next time.

2 1

Re: bug??
by Frank Heckenbach 08 Feb '99

08 Feb '99

Maurice Lombardi wrote: > Hi all > I obtain abort! when compiling this short program > > program essai; > var c:complex; > begin > c:=cmplx(1,5); > c:=c/2.0; > end. > > dividing a complex by a real does not work, > with * it works, even with /cmplx(2.0,0.0); Yes. :-( I'm adding it to the list of known bugs (maur4.pas). At least you have a workaround... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

bug??
by Maurice Lombardi 08 Feb '99

08 Feb '99

Hi all I obtain abort! when compiling this short program program essai; var c:complex; begin c:=cmplx(1,5); c:=c/2.0; end. dividing a complex by a real does not work, with * it works, even with /cmplx(2.0,0.0); What is broken ? (I work with DJGPP / gpc-19990118_i386-pc-djgppv201.zip) thanks in advance ! -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Beta
by Oliver Puetz 08 Feb '99

08 Feb '99

Hi I've downloaded the beta binary "gpc-19990118.mips-sgi-irix6.2.tar.gz" for our SGI power challenge, but there is still a problem. GNU is already installed, and when compiling a little test program, GPC answers: ld32: FATAL 9: I/O error (-lgpc): No such file or directory There are no environmental variables defined, as GPC seems not to use GPC_EXEC_PREFIX. Only when adding the dir with -B, GPC finds e.g. CRTBEGIN.O. Can anyone help? Thanks in advance Oliver

1 0

None
by Stephan Goetter 06 Feb '99

06 Feb '99

Hi, after your announce i've the follow. feature request: Linking OOP-ObjectPascal-Progs to (shared) C++-Libs ! Of course you can't use templates and exceptions and so on, but it would be really useful. Regards, Stephan

4 4

Re: GNU Pascal
by Frank Heckenbach 03 Feb '99

03 Feb '99

Peter Gerwinski wrote: > The African Chief wrote: > > > > [...] WinCRT is not a > > direct port of the Dos "crt" unit (although there are several > > compatible routines such as Readkey, GotoXY, etc), but is rather a > > wrapper around several WinAPI calls to produce a standard > > Windows window - but one that can process Readln/Writeln/Readkey > > calls, etc. [...] It's mostly a port of the Dos Crt unit -- though a lot is missing, and there are a few additions (some of them are emulated in GPC's CRT unit), but these additions are not essential for normal usage. > Unless I am missing something, the same holds for the X11 > version of our CRT unit (replacing "WinAPI" with "X11 API", > encapsulated in some `*curses' library). So `uses CRT' with > GPC should give the desired result. Yes. > > - but this would not result in an X application - is this > > correct, Peter? > > If you follow the instructions in `crt.pas' you can produce an > X11 application as well as a console application (that will of > course run under X11 without any restrictions) - just at your > option. > > (However I noticed some problems with the window not being > selectable under X11. Somebody knows what happens there?) Seems to be a library problem: GPC reverses the order of libraries in a `{$L}' directive. Obviously, the X libraries don't like that too much... So it's up to you to fix it. ;-) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

GNU Pascal
by Rees 03 Feb '99

03 Feb '99

Dear GNU Pascal development team, I wonder if you could please answer a couple of quick questions for me. I have been using Borland TPW1.5 and have many thousands of line of Pascal code , some for the WinCrt unit but mainly have used WObjects,WinTypes, WinProcs,Strings & BWCC units in combination with OOP programming and resources defined in the resource workshop. I will be switching to Linux before the end of the year and departing the Windows platform forever. GNU Pascal looks like it will be the perfect replacement for TPW1.5 and still mean I can retain the same(or similar) code. If I compile my programs in GNU Pascal will they work directly (i.e does GNU Pascal convert all the calls to XWindows calls) or will they have to be run via the Linux filter Wine ? The other possibility is how easy would it be to convert my current programs to Linux/Xwindows programs making use of your Linux libraries ? Thankyou for your help, I have only found out about GNU Pascal today and am very pleased that someone is producing such a language & compiler. Best Regards Kevin Rees

3 3

unsubscription
by Matthew Wiggins 03 Feb '99

03 Feb '99

I tried sending mail to the subscribe address, but nothing happened, please unsubscribe me. /Matthew Wiggins[, lithium] lithium(a)bong.triax.com

2 1

Problems connecting to agnes...
by Orlando Llanes 30 Jan '99

30 Jan '99

I could not connect to ftp://agnes... does this normally happen? See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 2

He, this program is already in the known bug list
by Berend de Boer 29 Jan '99

29 Jan '99

Hai All, Sorry for this message. I see I was already in the known bug list. Any takers for this error? Groetjes, Berend.

1 0

label used before containingn binding contour
by Berend de Boer 29 Jan '99

29 Jan '99

Since about 5 years I try to compile lex for extended pascal with gpc. However, I still don't succeed. This program is a real test case I assume :-) Here the latest error, boiled down to the most minimal code: ------------------------ program Test; type string255=string(255); function Test(filename, ext : String): string255; label 1,2; begin Test := ''; goto 1; goto 2; 2: Test := filename+'.'; 1: ; end; begin end. ------------------------ Groetjes, Berend.

1 0

Re: Compiling for FreeBSD
by Frank Heckenbach 29 Jan '99

29 Jan '99

Berend de Boer wrote: > I compiled the latest release for FreeBSD. However it thought STAT_HAVEFS (* you mean HAVE_STATFS :*) > was OK (in p/rts), but I don't have a sys/vfs.h anywhere on my system. > > How can I fix this? I deleted the check for statfs in configure, but there > should be a better way. I think we need another configure check for sys/vfs.h (and probably sys/statvfs.h as well). configure can check for header files (`AC_CHECK_HEADERS'), and this is supposed to be the "best" (i.e., most portable) way... Will you try it yourself (it should affect rts/configure.in, rts/rts-config.in and rts/file.c), or should I try to make a patch? If so, I need some information. What is the correct way to stat a file system in BSD? Is it statfs() or statvfs() or something else, and which header does it need (if any). Perhaps you can send me the synopsis of the manpage and the declaration of the `struct statfs', `struct statvfs' or whatever it uses... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GPC-19990118 - bug in cpp ?
by Frank Heckenbach 29 Jan '99

29 Jan '99

ian(a)stams.strath.ac.uk wrote: > I have a problem with egcs-1.1.1 (egcs-2.91.60 19981201) and > gpc-19990118 on Sun Solaris 2.6. > > Basically the #ifdef and #if defined() preprocessor stuff seems > broken. [...] > > Am I doing something hopelessly stupid or is this a bug ? It's a known bug. It's listed on the To-Do list at http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html : @item Sparc: `if defined' doesn't work (fjf238.pas) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

GPC-19990118 - bug in cpp ?
by ian＠stams.strath.ac.uk 29 Jan '99

29 Jan '99

Hello fellow pascalers! I have a problem with egcs-1.1.1 (egcs-2.91.60 19981201) and gpc-19990118 on Sun Solaris 2.6. Basically the #ifdef and #if defined() preprocessor stuff seems broken. The following code illustrates the problem: -------cut-------- program cpptest(input,output); begin #ifdef __GPC__ writeln('#ifdef __GPC__'); #endif #if defined (__GPC__) writeln('defined (__GPC__)'); #endif end. ------cut---------- When this is compiled with gpc -o test test.p (!) and you run it you get the following output on Sun Solaris: #ifdef __GPC__ On Linux and Digital UNIX (same compiler combination) you get: #ifdef __GPC__ defined (__GPC__) which is of course correct. Note that using the -v switch indicates that the compile is setting -D__GPC__=2 on all systems. Am I doing something hopelessly stupid or is this a bug ? Thanks for all your help. Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

1 0

Compiling for FreeBSD
by Berend de Boer 29 Jan '99

29 Jan '99

Hai All, I compiled the latest release for FreeBSD. However it thought STAT_HAVEFS was OK (in p/rts), but I don't have a sys/vfs.h anywhere on my system. How can I fix this? I deleted the check for statfs in configure, but there should be a better way. Groetjes, Berend.

1 0

gpc-19990118 binaries for EMX available.
by Kevin A. Foss 28 Jan '99

28 Jan '99

Hello, I've uploaded binaries for the EMX port of gpc to agnes (source patches are also available) and Peter has moved them into the beta/binary directory. They appear to work fine in OS/2 -- in theory they'd work in DOS, but no guarantees. They do require the latest EMX dlls (0.9d) and the 0.9d level binutils. Hopefully I'll be able to do work on fully testing the new units with EMX and OS/2 in the next couple of weeks. Enjoy, -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

gpc-19990118: C compiler cannot create executables.
by Kevin Broadey 26 Jan '99

26 Jan '99

I downloaded the gpc-19990118.tar.gz release from Peter's area on agnes.dida.physik.uni-essen.de, moved it into the egcs-1.1.1 release from Cygnus (egcs-2.91.60), applied the appropriate patch, ran 'configure' and did 'make bootstrap'. The stage 1 compiler built correctly, but when the 'final' compiler was compiling I got this... creating cache ./config.cache checking for gcc... ../../xgcc -B../../ checking whether the C compiler (../../xgcc -B../../ -O2 -g -O2 -Wl,-bbigtoc) works... no configure: error: installation or configuration problem: C compiler cannot create executables. gmake[4]: *** [p/rts/Makefile] Error 1 gmake[4]: Leaving directory `/local/kevinb/build/egcs-1.1.1/objdir/gcc' gmake[3]: *** [stmp-multilib-sub] Error 2 gmake[3]: Leaving directory `/local/kevinb/build/egcs-1.1.1/objdir/gcc' gmake[2]: *** [stmp-multilib] Error 1 gmake[2]: Leaving directory `/local/kevinb/build/egcs-1.1.1/objdir/gcc' gmake[1]: *** [bootstrap] Error 2 gmake[1]: Leaving directory `/local/kevinb/build/egcs-1.1.1/objdir/gcc' gmake: *** [bootstrap] Error 2 Any ideas? -- Kevin Broadey

4 7

Bug in Make-lang.in of gpc-19980830.tar.gz
by beru＠col.bsf.alcatel.fr 26 Jan '99

26 Jan '99

I found a bug in gpc-19980830.tar.gz ( file Make-lang.in ). When i devekkoppe it with VPATH, i have ht message : install-info --info-dir=/users/dhs3/beru/tools/gnu/info /users/dhs3/beru/tools/gnu/info/g77.info rm -f /users/dhs3/beru/tools/gnu/info/gpc.info* ; cd p/doc; for f in gpc.info*; \ do /bin/sh /twdhs3/beru/ws/my_tools/domain_public/code/gnu/compilo/srclib/srcdir/install-sh -c -m 644 $f /users/dhs3/beru/tools/gnu/info/$f; done /bin/sh: p/doc: does not exist make[1]: *** [pascal.install-info] Error 1 make[1]: Leaving directory `/twdhs3/beru/ws/my_tools/domain_public/code/gnu/compilo/srclib/objdir/gcc' make: *** [install-gcc] Error 2 I have analysed the mistake: A short work around : touch gpc.texi in srclib, this provoque the build of gpc.info* in objlib. an another correction possible : Apply this patch : ###################### on directory gcc/p/ ############# --- Make-lang.in.orig Mon Aug 31 03:05:02 1998 +++ Make-lang.in Tue Jan 19 13:01:06 1999 @@ -385,7 +385,8 @@ pascal.install-info: pascal.info -rm -f $(infodir)/gpc.info* ; - cd p/doc; for f in gpc.info*; \ + if [ -d p/doc ]; then cd p/doc; else cd $(srcdir)/p/doc; fi \ + for f in gpc.info*; \ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gpc.info* ######################################## EOF ################# Thanks for your jobs.

2 1

RE: how to bootstrap egcs-1.1.1
by kevin.broadey＠ats.uk.eds.com 25 Jan '99

25 Jan '99

> -----Original Message----- > From: Peter Gerwinski [mailto:peter@gerwinski.de] > Sent: 25 January 1999 17:52 > To: kevin.broadey(a)ats.uk.eds.com > Cc: gpc(a)hut.fi > Subject: Re: how to bootstrap egcs-1.1.1 > > > kevin.broadey(a)ats.uk.eds.com wrote: > > > > The "gmake LANGUAGES=c" bombed out trying to make (I guess) > > one of the C++ libraries that comes bundled with egcs, so > > that's not surprising, and it did manage to build the C > > compiler first. > > > > The "gmake LANGUAGES=pascal" bombed out in the same place, but > > again it built the compiler first. > > For me this looks like a problem with C++, not with Pascal. > If you are not going to install the C++ compiler, better use the > egcs-1.1.1.core distribution instead of the full egcs-1.1.1, or > remove the `cp' directory before installing. I think the problem is that I ran "make" in the top-level objdir, so egcs went off and tried to build its associated libraries without having the compiler in place to do the job. Maybe I should have used "make all-gcc" instead. Dunno. But I really do want to install the C++ compiler, so "make bootstrap" looks like the thing I should be doing. > > But the problem is that I now have a compiler built with > > gcc-2.8.1 rather than egcs-1.1.1. So is there some way I can > > do the equivalent of "make bootstrap" without tripping over > > the circular dependency Peter referred to? > > What about `make CC="gcc/xgcc -Bgcc/ -Lgcc/" LANGUAGES=pascal'? I don't think that will help with the "make bootstrap" problem. What I'm trying now is to hack gcc/Makefile to remove "pascal" from LANGUAGES, then added a rule at the end of the "bootstrap" target to do a "make LANGUAGES=pascal" directly. Dirty, but It Should Work (tm). I'll let you know how I get on. > > (BTW, better truncate your lines to make your emails more > readable.;-) Sorry, beaten by M$ Outlook, I'm afraid :-( Cheers Kevin

1 0

ANNOUNCE: gpc-19990118
by Peter Gerwinski 25 Jan '99

25 Jan '99

This is the announcement of GNU Pascal, beta version gpc-19990118 which is now available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ . Binaries for various platforms are available in a subdirectory `binary/'. These platforms include: i586-pc-linux-gnulibc1 (gcc-2.8.1 and egcs-1.1.1) alpha-unknown-linux-gnu alphaev56-dec-osf4.0d mips-sgi-irix6.2 sparc-sun-solaris2.6 i386-pc-djgppv201 (MS-DOS) Binaries for more platforms, including i586-pc-linux-gnulibc2, ix86-mingw32 (MS-Windows 9x/NT) and sparc-sun-solaris2.5.1 will follow soon and announced separately. This is intended to be the next-to-last beta release before the release of GPC 2.1. If you have some suggestions for GPC 2.1 that are not yet listed in the GPC To-Do list at http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html, please contact us at the GPC mailing list <gpc(a)hut.fi> without delay. 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. This version of GPC corresponds to GCC version 2.8.1 or EGCS 1.1.1. The purpose of the GNU Pascal project is to produce a Pascal compiler which: 1) combines the clarity of Pascal with powerful tools suitable for real-life programming, 2) 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) 3) supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, 4) can generate code for and run on any computer for which the GNU C compiler can generate code and run on. The current beta release gpc-19990118 implements Standard Pascal (ISO 7185, level 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://home.pages.de/~GNU-Pascal/ . Changes since the previous beta release ======================================= Units ----- The main focus in this GPC release is the inclusion of many standard units. Besides a complete set of BP compatibility units -- except the Graph unit (which is currently distributed separately due to its license) and the OOP stuff --, there are some units to make C functionality available for GPC and some new units. BP compatibility units: - CRT: Curses based text screen handling. Compatible to BP's unit, even in a lot of minor details like the values of function key codes. Includes some routines for compatibility with TP5's `Win' unit as well as BP's `WinCrt' and Turbo Power's `TPCrt' units, and some extensions. - Dos: Portable implementation of those routines from BP's unit that are useful to most programs. Those routines that are only meant for access to Dos internals and cannot be implemented in a portable way, have intentionally been left out. - Overlay: Dummy replacement for BP's unit, since GPC doesn't need overlays. - Ports: Access routines for the hardware ports on the x86, as a partial replacement for BP's `Port' and `PortW' pseudo arrays. - Printer: Implementation of BP's interface for Dos (using printer devices) and Unix systems (using printer utilities). Might need porting to mingw32 to use its native printing abilities. - Strings: Almost empty since most of BP's CString routines have been included into GPC's RTS (available by using the `GPC' unit). - System: Portable implementations for BP's more exotic routines which are not built into GPC's RTS (ExitProc, Lo, Hi, Swap, GetDir, HeapError, MemAvail, MaxAvail), and on special request (by setting some defines), also BP compatible integer type sizes and a 100% BP compatible random number generator. - Turbo3: Compatibility unit for BP's TP3 compatibility unit. ;-) - WinDos: Portable implementation of BP's unit, see the comments for the Dos unit. Other units: - DosUnix: A unit, intented to be growing when necessary, to overcome some differences between Dos and Unix systems. Currently features translation of bash style input/output redirections (`foo 2>&1') into `redir' calls for DJGPP (`redir -eo foo') and a way to read files with Dos CR/LF pairs on any system. - GetOpt: Comfortable command line option parsing. - GMP: Interface to the GNU Multiprecision Library to handle integer, rational and real numbers of unlimited size/precision. - GPCUtil: Some utility routines by The Chief, including implementations of some routines from Turbo Power's units for BP. - Internal: Unit which contains declarations for internal RTS routines that are not declared in the `GPC' unit. Only meant for low-level access by people who know what they're doing. - PExecute: Executing processes. Overcomes some of the differences between Dos and Unix systems. - Pipe: Start a child process and write to/read from its Input/Output/StdErr via pipes. Emulated transparently under Dos as far as possible. - RegEx: Matching and replacing text with regular expressions. Some of the units come with demo programs to show their usage that are installed in <prefix>/doc/gpc/demos/ . A few of the units (in particular: CRT, GMP and RegEx) require C libraries. The sources of the libraries, sometimes with small patches when necessary, and binaries for i586-pc-linux-gnulibc1, i386-pc-go32 and sparc-sun-solaris2 are available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ . Compiler features ----------------- The new compiler features have concentrated on making it easier to write and use the units. The AutoMake mechanism is now much more reliable than it was, doesn't recompile units unnecessarily any more, and does not require repeating the options, i.e. instead of writing `--foo --bar --baz --automake="--foo --baz --baz"' one can now simply write `--foo --bar --baz --automake'. The following directives, related to units, are now understood: - --unit-path -- search path(s) (can be used multiple times) for units used by a program. - --object-path -- search paths(s) for object, assembler, C, or other external files used by a program. Defaults to the unit path(s). - --unit-destination-path -- the destination path for units compiled by AutoMake. - --object-destination-path -- the destination path for C, assembler or other external files compiled by AutoMake. Defaults to the unit destination path. - --executable-path -- the destination path for executables compiled. - --uses=foo(bar.pas),bar,baz(../baz.pas) -- automatically using units in a program, optionally specifying a source file name. Useful e.g. for maximum BP compatibility to use units like `GPC' and `System' without changing the source code. The unit and object paths default to the directory where the standard units are installed, i.e. <prefix>/lib/gcc-lib/<target>/<version>/units/, so these units are found automatically. Libraries can now be used by a `{$L foo}' compiler directive, just like simple object files, and this directive also works in units (used a lot in the standard units). The compiler pre-defines `__BORLAND_PASCAL__' etc. depending on the dialect option used or `__GNU_PASCAL__' by default if no dialect option was given (besides `__GPC__' as before, regardless of the dialect used). `__OS_DOS__' is pre-defined on Dos-like systems. Other declarations ------------------ Some of the following declarations are built into the compiler, others are declared in the `GPC' unit. - Memory: Addr (B) Assigned (B) CGetMem CFreeMem ConvertFromLittleEndian ConvertFromBigEndian ConvertToLittleEndian ConvertToBigEndian FreeMemPtr GetMemPtr Null (D?) ReAlloc ReverseBytes - Files and I/O: BlockReadLittleEndian BlockReadBigEndian BlockWriteLittleEndian BlockWriteBigEndian DataReady FileName New fields Force, AccessTime, ModificationTime and ChangeTime in the BindingType record. Text files now use internal buffering to speed up reading and writing -- even on operating systems that do good buffering themselves. (B ;-) - Strings: Copy with only 2 arguments SetString (D) StringOfChar (D) A number of new CString routines, including almost all (that weren't already there) of BP's `Strings' unit. (B) The string comparison operators (`=', `>', etc.) now work like in BP by default, and as described in the ISO-10206 Standard in `--extended-pascal' mode or with the `--no-exact-compare-strings' switch. (B) - Date/Time: GetUnixTime IsLeapYear TimeStampToUnixTime UnixTimeToTimeStamp `(B)': BP compatibility `(D)': Delphi compatibility Have fun, The GNU Pascal development team

3 3

Re: __OS_DOS__
by Frank Heckenbach 25 Jan '99

25 Jan '99

Kevin A. Foss wrote: > On Sat, 23 Jan 1999 22:15:55 +0100, Frank Heckenbach wrote: > > >2) __OS_DOS__ is defined in Pascal on Dos like systems (including > > EMX). It is defined automatically and should not (need to) be > > defined by the user. It's used in Pascal parts of the RTS > > (rts/filename.pas [1], e.g. for directory and path separators), > > in some standard units (DosUnix and Printer) and is available to > > user programs (I need it for a few things in my own programs). > > Okay this is more what I was concerned about (GPC's behavior with > __OS_DOS__ defined) and once I get the system working I'll investigate > its effects, my only real issue is that OS/2 can use either / or \ as a > directory separator internally and I don't know if that will mess up > some routines. In fact you can even mix separators within a path. A > quick look at the source doesn't show any problems as most of the > routines in filename.pas are looking at DirSeparators rather than > DirSeparator and the ones using DirSeparator are mostly 'fixing' paths > for the OS -- if I read them correctly. Yes, exactly. The `DirSeparator' char constant is used when appending a slash or converting paths before passing them to libc routines (though this might not even be necessary, I think it shouldn't hurt), and the `DirSeparators' set of char constant is used when checking for directroy separators. Since the situation is the same on DJGPP, I tested it at least moderately. BTW, other units might need some porting as well: CRT needs a curses version, but I suppose either or both ncurses and/or PDCurses should work under OS/2 (probably PDCurses would be preferable for EMX, since it runs under Dos as well), so CRT should work after setting some ifdefs. A few system specific functions (which are not vital, however), can be ported as well, cf. crtdospc.h for the DJGPP version for them. The printer unit needs porting if you want it to use some native printing capabilities of OS/2. (I don't know if there are any, and what they look like, however.) Otherwise, it will currently use the Dos printer device ('lpt1') which might work under OS/2, but perhaps not be optimal, I don't know. The system unit contains specific MemAvail/MaxAvail routines for DJGPP and mingw. If you want to port them to EMX, go ahead, otherwise the unit will just use the portable (but in this case less efficient) replacements. If the shell supports I/O redirections beyond the simple ones that Dos' command.com knows, and their syntax is different from bash's, (like DJGPP's redir utility), the DosUnix unit should be adapted. If accessing I/O ports requires getting special permissions (like under Linux), the ports unit needs adaption. A few other units require C libraries that ought to just be recompiled for EMX. Binaries can then be stored on Agnes together with the other library binaries. Frank PS: Does EMX work again? Last thing I heard was that it didn't work with GCC 2.8.x. Did you fix it, or did EM finally do something about it? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Re: __OS_DOS__
by Frank Heckenbach 25 Jan '99

25 Jan '99

Kevin A. Foss wrote: > The short of it is that I have a working > 19990118 now and once I clean stuff up I should be able to upload the > patches and binaries in the next couple days. Fine. :-) > Another sticky problem was with the OS_DOS code in gpc.c (ironically > considering how this thread started). Basically I dump core when it > reaches 'free (cpp_predefines);' [line 1620 or so] which I don't find > too unreasonable because I didn't think you could free(3) static > globals. Of course the code does work on other systems so maybe it is > just EMX being picky. I just #ifdef'd the line out for EMX and it > compiles now. Indeed it looks like the code tries to free() a constant, and even though it seems to work under Linux, it's not correct, so it should be fixed. Correct, Peter? > There is also a weird looking "If False" block in the > same area which looks like the code is still under construction. I think the currently active version is meant to be the correct one, the other one was a previous attempt which was less efficient, and perhaps had some problems, I don't remember exactly... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Debian gpc-19990118 binaries available.
by Matthias Klose 24 Jan '99

24 Jan '99

The upcoming Debian GNU/Linux 2.1 version includes a gpc package based on 19990118. Currently it's available from the Debian ftp archive and it's mirrors (look for gpc-2.91.60-4 or newer). Currently it's available for i386 only, packages for m68k, alpha, sparc and arm are expected next week on the archives. For more information please see http://www.debian.org/

1 0

Re: ANNOUNCE: gpc-19990118
by Frank Heckenbach 24 Jan '99

24 Jan '99

Kevin A. Foss wrote: > >The compiler pre-defines `__BORLAND_PASCAL__' etc. depending on the > >dialect option used or `__GNU_PASCAL__' by default if no dialect > >option was given (besides `__GPC__' as before, regardless of the > >dialect used). `__OS_DOS__' is pre-defined on Dos-like systems. > > I remember some discussion on the list about this, but never heard what > the final verdict was -- can someone give a brief description of what > is affected when defining __OS_DOS__. I know at one time things like > device names (lptX) and path separators (which I think may be an issue > with EMX) were an issue and I was just wondering if anything else was > altered. Well, I think there are two things to consider. 1) Some C routines in the RTS do some OS dependent stuff (like device names). Since __OS_DOS__ is not available in C, they use a combination of #ifdefs. You might want to check them in rts/{bind,file,pexecute}.c. The former two check for `__EMX__', the latter checks for `OS2' and `__MSDOS__', so they should be OK for EMX. 2) __OS_DOS__ is defined in Pascal on Dos like systems (including EMX). It is defined automatically and should not (need to) be defined by the user. It's used in Pascal parts of the RTS (rts/filename.pas [1], e.g. for directory and path separators), in some standard units (DosUnix and Printer) and is available to user programs (I need it for a few things in my own programs). [1] To see exactly what is affected, please see rts/filename.pas. Users of GPC binaries can look at the GPC unit (gpc.pas) which also contains the constants affected by __OS_DOS__ (just search for `__OS_DOS__' in gpc.pas). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

New gpc-19990118 binaries available
by Jan-Jaap van der Heijden 23 Jan '99

23 Jan '99

I have made gpc-19990118 binaries available for i386-linux-glibc2 (RedHat 5.2) and i386-mingw32. Both are egcs-1.1.1 based. A word of caution about the mingw32 binary: I'm rearranging my PC's, and I currently don't have a Windows PC to test this compiler, so this one is really Zero Tested(TM). Hopefully I'll have everything up and running again in a few days. A few other random notes about the mingw32 binary: * You need binutils, mingw32 libraries and probably want GDB. These are available from the usual mingw32 ftp sources. * BP compat units have not been ported. If somebody wants to do this, he'll probably have to get pdcurses, which is available from my mingw32 FTP. These pdcurses come in two flavours: a static version and a DLL. It is probably best to use the static version. The DLL version requires __dllimport/__dllexport capabilities in the compiler. GPC/egcs/mingw32 has these, btw. Happy compiling, JanJaap --- GNU mingw32: http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32

1 0

Gnu Pascal
by Yishay 22 Jan '99

22 Jan '99

Is gpc compatible with DEC pascal and can I use it on MS_DOS? thanks, yishay.

2 1

Re: varargs
by Frank Heckenbach 22 Jan '99

22 Jan '99

Russ Whitaker wrote: > on 1/18 you wrote > > ...the varargs functions are intended to be replaced sooner or later > > ok so how about changing some of the .c files to .cpp? > Then you could use c++'s "function overloading" to replace the varargs Nice idea (apart from the fact that I don't like C++ very much ;-), and it might make building GPC more difficult if it depends on a C++ compiler), but it would only work for one of the five varargs functions (_p_string). The others (_p_write etc.) can have an infinite number of combinations of arguments (just like Write etc. in Pascal), which can't be done by overloading. But, as I said, it's not *too* bad since we're planning to simply break up the functions, i.e. instead of: _p_write (f, CODE_FOR_INTEGER, integer_value, CODE_FOR_REAL, real_value, CODE_FOR_WRITELN); the compiler will issue calls to: _p_write_integer (f, integer_value); _p_write_real (f, real_value); _p_writeln (f); This should also be a little bit more efficient at runtime, since the RTS doesn't have to do dispatching... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

re: varargs
by Russ Whitaker 22 Jan '99

22 Jan '99

hi Frank on 1/18 you wrote > ...the varargs functions are intended to be replaced sooner or later ok so how about changing some of the .c files to .cpp? Then you could use c++'s "function overloading" to replace the varargs The attached illustrative example compliles and runs as proto.cpp but proto.c gives 11 error messages thanks, Russ

1 0

Re: Build of GPC-19980830 (more questions...)
by Frank Heckenbach 18 Jan '99

18 Jan '99

Ken Linder wrote: > YES! It worked! I have successfully built the compiler! > I know, this may be a minor thing for some of you out there, but for me, > this is a large accomplishment! Congratulations! :-) For the first time, it can be a bit difficult. Once you've figured it out, you can automate it rather easily -- particularly on Linux... :-) > Since this don't work too well in a fcn prototype, I just coded the proto > as int; __va_ellipsis. Is this portable? I think it is on Intel based > hardware but otherwise no. I base this on the fact that there are many > #defines for va_dcl in the va-*.h files in the gcc-2.8.1/include dir. Why > can't there be something like va_dclp, generated in the varargs.h that will > allow protos to be portable? Maybe there is & I just missed it. > Definitely possible at this time of night! ;-) If you find something portable, let me know. Otherwise, it will not be *too* bad, since the varargs functions are intended to be replaced by non-varargs functions sooner or later... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Build of GPC-19980830 (more questions...)
by Frank Heckenbach 18 Jan '99

18 Jan '99

Ken Linder wrote: > Ok, I added the following code into the hdr.h file: > > ... > #include "varargs.h" > ... > extern void _p_write PROTO((FDR, int, int, __va_ellipsis)); > extern void _p_read PROTO((FDR, int, int, __va_ellipsis)); > extern int _p_string PROTO((int, __va_ellipsis)); > extern void _p_writestr PROTO((int, char *, int, __va_ellipsis)); > extern void _p_readstr PROTO(char *, int, int, int, __va_ellipsis)); > > Well, Peter, I think the above varargs will work fine with Intel Linux but > will probably do wierd things on other platforms. Hey, its my first shot > at it! :-) What I don't really understand is the additional `int' parameter before the ellipsis. Yes, I see that GCC wants it, but why? And is this portable? (Anyone knows for sure?) > The above fixed my immediate problems... but now when trying to compile > pascal code, I get problems linking to _p_strlen, _p_gpc_locase, and > _p_gpc_upcase. ARRGGHHH. I can't seem to find where these fcns are > defined in the RTS. (* They're defined in rts/gstrings.pas. Some other people had problems finding the definitions, too -- seems they're not used to things being implemented in Pascal actually. ;-) *) > I do see the protos though. Would anyone care to > shove me in the right direction to solve this? This is a known bug caused by inline functions being compiled without optimization. So there are two obvious solutions: remove the `inline' from these functions (the next GPC version will have this done), or compile with optimization, i.e. give `CFLAGS=-O2' to the make command line (the latter is, of course, preferable, since it produces a faster compiler, anyway). > Also, do I need to fix up the Makefile? I change hdr.h but when I do a > MAKE, nothing realy happens... :-# Yes, the Makefiles are quite broken in this regard. :-( Even worse if you should make substantial changes (esp. changing the size of some RTS data structure) in rts/types.h -- then you need to recompile some parts of the compiler, or you might get very strange behaviour, i.e. you better do a complete rebuild then... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Build of GPC-19980830 (more questions...)
by Ken Linder 17 Jan '99

17 Jan '99

Ok, I added the following code into the hdr.h file: ... #include "varargs.h" ... extern void _p_write PROTO((FDR, int, int, __va_ellipsis)); extern void _p_read PROTO((FDR, int, int, __va_ellipsis)); extern int _p_string PROTO((int, __va_ellipsis)); extern void _p_writestr PROTO((int, char *, int, __va_ellipsis)); extern void _p_readstr PROTO(char *, int, int, int, __va_ellipsis)); Well, Peter, I think the above varargs will work fine with Intel Linux but will probably do wierd things on other platforms. Hey, its my first shot at it! :-) The above fixed my immediate problems... but now when trying to compile pascal code, I get problems linking to _p_strlen, _p_gpc_locase, and _p_gpc_upcase. ARRGGHHH. I can't seem to find where these fcns are defined in the RTS. I do see the protos though. Would anyone care to shove me in the right direction to solve this? Also, do I need to fix up the Makefile? I change hdr.h but when I do a MAKE, nothing realy happens... :-# Later all, its bed time here in Vegas! Ken Linder KC7RAD

1 0

unsubscribe
by Chris Russell 15 Jan '99

15 Jan '99

unsubscribe

1 0

Self, and OO asm...
by Orlando Llanes 15 Jan '99

15 Jan '99

I was cleaning out my box and ran across my "Realization Of The Self..." post, just wanted to say nevermind :} I wrote that post because at the time I figured that since GPC objects are not compatible with DJGPP classes EDI might as well contain Self. I was porting my libs to DJGPP for the heck of it and found out that GPC and DJGPP are OO compatible to a certain point. All you have to do when writing an external assembly program for an object member is to declare a global for each version of the name. The following is an example of what I mean (not tested, writing it off the top of my head, tho it should work. If not let me know and I'll repost it after verifying): // begin test.cc #include <stdio.h> class tmyclass { public: int bar; int foo(); }; main() { tmyclass myclass; myclass.bar = 35; printf( "Should be equal %i %i\n", myclass.bar, myclass.foo() ); } // end test.cc { begin test.pas } program test; type tmyclass = object bar : Integer; function foo: Integer; end; var myclass : tmyclass; begin myclass.bar := 35; WriteLn( 'Should be equal ', myclass.bar, ' ', myclass.foo ); end; { end test.pas } # begin testo.s .globl _foo__8tmyclass # DJGPP name .globl _Tmyclass_Foo # GPC name .text _Tmyclass_Foo: _foo__8tmyclass: movl 4(%esp), %edi # Get Self pointer from the stack movl 4(%edi), %eax # Set function result to tmyclass.bar ret # end testo.s rem begin mktest.bat gpc test.pas testo.s -o testp.exe gcc test.cc testo.s -o testc.exe rem end mktest.bat Reason number 1,000,001 to use GPC =B) See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 2

remove
by c.wendt＠CHATEAU.line.org 15 Jan '99

15 Jan '99

remove please remove me from the mailing-list. thanks

1 0

Build of GPC-19980830
by Ken Linder (KC7RAD) 14 Jan '99

14 Jan '99

SUCCESS!! sort of... I managed to make gcc 2.8.1, do a make install, and then make gpc. To make things short, there are some fcn prototype declarations missing from the rtm.h file. Is there a newer rtm.h or should I just put the protos in myself? gpc works fine as long as I am not linking anything. ;-) Later and tnx for all the help! Ken Linder

2 1

Re: Using 'flock' in GNU Pascal.
by Frank Heckenbach 10 Jan '99

10 Jan '99

Chris Wood wrote: > I am in the process of developing a CGI program using GNU Pascal. The = > CGI program is to be used in a Linux environment. It is a database CGI = > script and I would like to have one running process of the CGI script = > have exclusive write access. I was hoping that someone could provide me = > with an example, or a place where I can find further (detailed) = > information, of using the flock() function from the C library in a GNU = > Pascal program. I also need to know how to detect when a file is = > locked. A million thanks for your time and help. The best way (WRT portability and security for future versions) is currently to write a small C wrapper. This is because "constants" (i.e., #defines) from a C header cannot be easily made available in Pascal. (I hope one day GPC will have a C header translator which would solve the problem more elegantly.) What you need to know from the Pascal side is that `GetFile' returns a C file (i.e., a `FILE *') for a Pascal file. The file handle (integer), which is needed by flock(), can then be obtained by the libc function fileno(). So, here's an example. First the C wrapper (fileno.c): #include <stdio.h> #include <sys/file.h> typedef unsigned char Boolean; int filelock (FILE*, Boolean, Boolean); int filelock (FILE* f, Boolean Exclusive, Boolean NoBlock) { return flock (fileno (f), (Exclusive ? LOCK_EX : LOCK_SH) | (NoBlock ? LOCK_NB : 0)); } int fileunlock (FILE*); int fileunlock (FILE* f) { return flock (fileno (f), LOCK_UN); } Now a test program: program FileLockDemo; uses GPC; {$L fileno.c} function FileLock (f : CFilePtr; Exclusive, NoBlock : Boolean) : Integer; C; function FileUnlock (f : CFilePtr) : Integer; C; var a, b : Text; begin Rewrite (a, 'foo.bar'); Reset (b, 'foo.bar'); { Non-exclusive locks, succeed } Writeln (FileLock (GetFile (a), False, True)); Writeln (FileLock (GetFile (b), False, True)); { Exclusive lock, fails } Writeln (FileLock (GetFile (a), True, True)); { Remove the non-exclusive locks, succeed } Writeln (FileUnLock (GetFile (a))); Writeln (FileUnLock (GetFile (b))); { Exclusive lock, succeeds } Writeln (FileLock (GetFile (a), True, True)); { Another exclusive lock, fails } Writeln (FileLock (GetFile (b), True, True)); { An exclusive lock *with* blocking, will block the program forever! } Writeln (FileLock (GetFile (b), True, False)); end. As the example shows, you can find out if a file is locked, by trying to lock it without blocking (and removing the lock again if not needed). I don't know if there's another way to check... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Using 'flock' in GNU Pascal.
by Chris Wood 10 Jan '99

10 Jan '99

I am in the process of developing a CGI program using GNU Pascal. The CGI program is to be used in a Linux environment. It is a database CGI script and I would like to have one running process of the CGI script have exclusive write access. I was hoping that someone could provide me with an example, or a place where I can find further (detailed) information, of using the flock() function from the C library in a GNU Pascal program. I also need to know how to detect when a file is locked. A million thanks for your time and help. Sincerely, Chris Wood

1 0

Some help building GPC-19980830
by Ken Linder 09 Jan '99

09 Jan '99

Ok, Oh GPC & make masters... I was a good little boy & spent the best part of a day downloading GCC-2.8.1 and GPC-19980830. This is what I did & the error I got... Background Info: RH Linux 4.2 with GCC 2.7.2.1 1) gunzip GCC & GPC 2) untar GCC into /usr/src/gcc-2.8.1 3) untar gpc into /tmp/gpc 4) in the gcc source dir make a link ln -s p /tmp/gpc/p 5) apply the patch patch -p -s1 < p/gcc-2.8.1.diff 6) do in the gcc source dir configure -prefix=/usr 7) compile the thing in gcc source dir make LANGUAGES=pascal OK... problem... This is what I get... make[1]: entering directory '/tmp/gpc/p' make[1]: *** No rule to make target '../configure', needed by 'Makefile', stop. make[1]: leaving directory '/tmp/gpc/p' make: ***[gpc1] Error 2 Ok, oh mighty GPC wizards... What did I do wrong? Did I miss something? TNX... Ken Linder kc7rad(a)vegasnet.net

2 2

Re: Some help building GPC-19980830
by Frank Heckenbach 09 Jan '99

09 Jan '99

Ken Linder wrote: > Ok, Oh GPC & make masters... > > I was a good little boy & spent the best part of a day downloading > GCC-2.8.1 and GPC-19980830. This is what I did & the error I got... > > Background Info: RH Linux 4.2 with GCC 2.7.2.1 > > 1) gunzip GCC & GPC > 2) untar GCC into /usr/src/gcc-2.8.1 > 3) untar gpc into /tmp/gpc > 4) in the gcc source dir make a link ln -s p /tmp/gpc/p > > [...] > > make[1]: entering directory '/tmp/gpc/p' > make[1]: *** No rule to make target '../configure', needed by 'Makefile', > stop. I'm not sure, but ISTR that building GPC doesn't work with a symlink, because then `..' points to the wrong directory, and the GPC Makefiles use `..' a lot. So you might want to try moving the GPC directory below the GCC directory. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: enum definition bug
by Frank Heckenbach 09 Jan '99

09 Jan '99

Miguel Lobo wrote: > By the way, it would be nice if an updated "known > bugs" list was put in GPC's web page. That way, when > a program doesn't do what I expected, I would > know if it's GPC's fault or mine. It is already there. Please look at: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html Hmmm... perhaps we should post a short FAQ here regularly that mentions the most important URLs and other stuff. Your bug was indeed already known and listed there (`enum types do not properly survive transport through two interfaces (russell2.pas, baby2.pas)'), but unfortunately not fixed yet. > And finally, if there is a beta release, would you > please build some binaries? (Compiling GCC is too much > for my computer and me; last time I tried I ran out > of disk space after about two hours of compilation). Which platform please? > Well, that was all by now. Happy new year, and good luck > fixing the bug :) Thanks. Happy New Year, Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

enum definition bug
by Miguel Lobo 03 Jan '99

03 Jan '99

This bug appears when you use an enumerated type, defined in a unit, in the "interface" of another unit which is used by the first (complicated, eh? :) ). Well, better look at the attached example to see what I mean. I compiled the main program with "--automake" and got "incompatible type" errors. By the way, it would be nice if an updated "known bugs" list was put in GPC's web page. That way, when a program doesn't do what I expected, I would know if it's GPC's fault or mine. And finally, if there is a beta release, would you please build some binaries? (Compiling GCC is too much for my computer and me; last time I tried I ran out of disk space after about two hours of compilation). Well, that was all by now. Happy new year, and good luck fixing the bug :) Miguel. uses bugenum1,bugenum2; begin q(e1); end. unit bugenum1; interface type enum = (e1,e2,e3,e4); function q(v: enum): boolean; implementation uses bugenum2; function q(v: enum): boolean; begin q :=p(v,e1); end; end. unit bugenum2; interface uses bugenum1; function p(v1,v2: enum): boolean; implementation function p(v1,v2: enum): boolean; begin p :=(v1=v2); end; end.

1 0

None
by The Magician 31 Dec '98

31 Dec '98

I study in the University of Coruña I.S.Informatica and we use the G.N.U. compiler. I need your help, please. I need the font codig ('codigo fuente' en español) of a function to Append like append of Turbo Pascal. Please, hurry up. Thanks. ================================================== Obtenga GRATIS su E-Mail permanente en http://www.mixmail.com

1 0

gpc bug?
by Miguel Lobo 31 Dec '98

31 Dec '98

I wrote a week ago about some 'Internal compiler error' message. Unfortunately I was using gpc 2.0 and, as Peter Gerwinsky pointed, that was the cause of the error; I downloaded gpc-19981124 from debian.org and now that bug has disappeared. I am glad to see that the compiler is now much better (although compiling a file with errors often causes strange messages), but I think that I might have found a new bug. The problem arises when calling a destructor inside a dispose statement. I send a program which manifests the problem attached to this message. Specifically, when the list.done method is called, it should dispose all the items in the list by calling their 'done' destructor. But apparently sometimes this does not happen. When I run the program I get: descend-init: 1 descend-init: 2 descend-init: 3 descend-init: 4 extracting: descend: 1 descend-done: 1 extracting: descend: 2 extracting: descend: 3 descend-done: 3 extracting: descend: 4 So items 2 and 4 are not freed (or at least their destructors are not called). Changing the line "dispose(extfirst, done);" to "item :=extfirst; dispose(item,done);" solves the problem. I have checked the program in Borland Pascal and it works, so I think is a GPC bug. BTW, although I plan to join the mailing list in the future I haven't done so yet, so please mail me any answer. Thank you. type pitem = ^item; item = object prev,next: pitem; constructor init; destructor done; virtual; procedure write; virtual; end; pdescend = ^descend; descend = object(item) i: integer; constructor init(ii: integer); destructor done; virtual; procedure write; virtual; end; plist = ^list; list = object first,last: pitem; constructor init; destructor done; function extfirst: pitem; procedure add(l: pitem); procedure adddesc(i: integer); end; constructor item.init; begin prev :=nil; next :=nil; end; destructor item.done; begin end; procedure item.write; begin writeln('item'); end; constructor descend.init(ii: integer); begin inherited init; i :=ii; writeln('descend-init: ',i); end; destructor descend.done; begin writeln('descend-done: ',i); inherited done; end; procedure descend.write; begin writeln('descend: ',i); end; constructor list.init; begin first :=nil; last :=nil; end; destructor list.done; begin while (first<>nil) do dispose(extfirst,done); end; function list.extfirst: pitem; var item: pitem; begin write('extracting: '); first^.write; extfirst :=first; if (first=nil) then exit; item :=first; first :=first^.next; item^.next :=nil; if (first<>nil) then first^.prev :=nil else last :=nil; end; procedure list.add(l: pitem); begin if (first=nil) then first :=l else last^.next :=l; l^.prev :=last; last :=l; end; procedure list.adddesc(i: integer); begin add(new(pdescend,init(i))); end; var alist: plist; begin new(alist,init); alist^.adddesc(1); alist^.adddesc(2); alist^.adddesc(3); alist^.adddesc(4); dispose(alist,done); end.

2 2

Re: Help for G.N.U.
by Peter Gerwinski 31 Dec '98

31 Dec '98

Hello, "The Magician"! (I'd prefer to know to whom I speak. Also, your other, identical email came without subject.)-: > I study in the University of CoruÃ±a I.S.Informatica and we > use the G.N.U. compiler. Which version? (Run `gpc -v' if you are not sure.) > I need your help, please. I need > the font codig ('codigo fuente' en espaÃ±ol) of a function > to Append like append of Turbo Pascal. I do not understand what you mean with "font codig", but recent versions of GNU Pascal have a built-in `Append' procedure; all versions of GNU Pascal have an `Extend' procedure (according to ISO-10206 Extended Pascal) which does the same. > Please, hurry up. Please be aware that I am giving you this help in my free time without being paid for it. (Of course if you want that I assign a high priority to your specific problems, you can pay me for that.;-) Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980830 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

Re: "keypressed" from TP/BP?
by Frank Heckenbach 31 Dec '98

31 Dec '98

Peter Gerwinski wrote: > GRX? If so, your `KeyPressed' problem can easily be solved; see > the `MouseEvent'-related functions of GRX. (Although they are > named `MouseEvent', they cover the keyboard as well and in a > more flexible way than `KeyPressed' and `ReadKey' do.) > > > I'm now hung up on a little side issue. In TP and BP, there > > was a useful Boolean function "keypressed". This let you > > do things like: [...] > > The next (beta) release of GPC (scheduled for ... er ... last > week #-) will come with a portable standard unit that will cover > this. Yes, a BP compatible CRT unit. However, it does not (yet?) work well together with graphics under all circumstances. So you can try it on your own risk (and perhaps improve the unit's ability to work together with graphics), but when working with GRX, it might be easier to use the GRX keyboard functions (at least for now). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

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