- Gpc - gnu.de

"keypressed" from TP/BP?
by Robert P. Ewing 30 Dec '98

30 Dec '98

Hi, all. I've been enjoying great success with GPC since Maurice and others helped me get the graphics going. 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: begin massive loop if keypressed then begin ch := readkey; [ process keystroke here] end; [do the rest of the massive loop here] end; I can drag in "getch" from C to do the readkey, but I don't know how to do a "keypressed" function. So now I either have to wait for keystrokes at each pass through the loop, or take the getch completely out of the loop. Surely someone in the group knows how to do this, either with a (undocumented) GPC function, or by dragging in some other obscure C function! Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University

2 1

Hello???
by Ken Linder (KC7RAD) 30 Dec '98

30 Dec '98

Hey, is anybody out there or was I removed from the list after the my 'problem' with UNAME? :-) At any rate, am going to attempt to compile the alpha GPC on Red Hat 5.1 this weekend. Unfortunately the Debian compiled binary didn't work too well (at all). I know for some of you compiling this may be an easy exercise but for me... Well, wish me luck! Later & happy holidays where ever you are! Ken L. kc7rad(a)vegasnet.net

2 1

RHIDE question
by Pablo Bendersky 30 Dec '98

30 Dec '98

I know it might be offtopic, but I need some help configuring RHIDE for DOS / Windows. I want RHIDE to compile .RC files, and I don't know where to configure it. In the documentation it talks about an enviroment variable, but I tried and it didn't work. Thank you, --- Pablo Gabriel Bendersky bender(a)einstein.com.ar UIN : 1916679 Buenos Aires - Argentina

2 1

GPC bug involving rewrite?
by John C. Beatty 27 Dec '98

27 Dec '98

I'm in the process of moving some pascal code from an old sun compiler to gpc, and encountered a problem with rewrite. Here's a little program that illustrates it: Program Main(input,output); Var assembly : text; begin rewrite(assembly,'output.file'); writeln(assembly,'Hello'); writeln(assembly,'Goodbye...'); end. Ths compiles ok, but when I run it, I get the error message ?GPC runtime error: (gpc-rts) Internal file namei wrong (#700) when the rewrite is executed. We appear to have version 2.7.2.1 of gpc installed, and I'm running it on a Sun UltraSPARC (Solaris 2.5). I'd be grateful if someone could tell me whether this is a known bug, and if it is, whether it's fixed in a later version of gpc. Please reply directly to me at jcbeatty(a)uwaterloo.ca - I'm not yet a member of the gpc mailing list. Thanks immensely. regards, john beatty ------------------------------ Prof. John C. Beatty Computer Science Department University of Waterloo 200 University Avenue Waterloo, Ontario Canada N2L 3G1 +1 (519) 888-4567 x 4525 voice +1 (519) 885-1208 fax

2 1

case/break bug?
by Miguel Lobo 26 Dec '98

26 Dec '98

Actually, I don't know if it's a bug or a feature, but apparently in GPC when you use 'break' inside a case statement the execution jumps to the end of the case. In Borland Pascal executing break would exit the enclosing block. For example, in while ... do begin ... case ... of ...: ... break; end; {case} end; {while} when break is executed, the 'while' loop should be stopped. Of course, this is different from C. I have not found reference to this 'break' incompatibility in the GPC documentation, so I thought I should report it, just in case.

2 1

SPAM and Virus at kampi ?
by Maurice Lombardi 18 Dec '98

18 Dec '98

Hi all, I receive since a couple of weeks SPAM mail (with SNN in the subject). Sender and Dest are bogus, and change each time. But the mail is always relayed through santra.hut.fi, which I suppose is the gateway of kampi.hut.fi (IP numbers are 130.233.224.2 for kampi and 130.233.224.2 for santra). I suppose also that they had my mail address in the mailing list or ftp list of kampi. As usual they say that if you want to unsubscribe you have to send a message to some address, which is also bogus and change each time. I have replied the first time, so I receive a couple of messages each time. Now kampi seems permanently down (not replying to ping), while santra is on. May be they are aware of that and are down for this reason. If you know somebody there, you could give them these explanations to help them to fight. But a phone call is more appropriate than an e-mail !! Thanks 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

Realization of the Self =B)...
by Orlando Llanes 18 Dec '98

18 Dec '98

I'd like to see register EDI point to Self on entry into a method rather than Self being on the stack. The reason is because setting the address of a point right before using it (ie what GPC does now) causes an address calculation stall (on any cpu risc or cisc). It would also be more convenient to simply reference the pointer using a preset register. Doing this would also remove about 3 or 4 unnnecessary 32-bit instructions which means smaller code size (why does GPC save Self on the stack when it already is?). 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

Re: Bug Report GPC-19980830/egcs-1.1 Redhat-5.1
by Ross Cartlidge 16 Dec '98

16 Dec '98

I have a program which does this as well - though its 6000 lines and I have got round to find out what lines causes the problem - but I very interested in a fix :-) On Dec 16, 1:29pm, Ian Thurlbeck wrote: > Subject: Bug Report GPC-19980830/egcs-1.1 Redhat-5.1 > > Hi, me again! I've discovered another strange problem > with GPC-19980830 which appears to be a bug. The following > program produces a fatal signal 11 from gpc1: ...

1 0

Re: Bug Report GPC-19980830/egcs-1.1 Redhat-5.1
by Frank Heckenbach 16 Dec '98

16 Dec '98

Ian Thurlbeck wrote: > Hi, me again! I've discovered another strange problem > with GPC-19980830 which appears to be a bug. The following > program produces a fatal signal 11 from gpc1: I think this problem has been fixed recently, so the next release of GPC should compile your program correctly. Thanks for the report. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Bug Report GPC-19980830/egcs-1.1 Redhat-5.1
by Ian Thurlbeck 16 Dec '98

16 Dec '98

Hi, me again! I've discovered another strange problem with GPC-19980830 which appears to be a bug. The following program produces a fatal signal 11 from gpc1: -------cut----------- program MAPPER; type PtNo = 1..5; procedure DrawMap; var Sp: array [PtNo] of integer; begin end; procedure PrintMap; var Sp: array [PtNo] of integer; begin end; begin end. -------cut----------- ida % gpc -c bug.p gpc: Internal compiler error: program gpc1 got fatal signal 11 I'm using gpc version 19980830, based on egcs-2.91.57 19980901 (egcs-1.1 release) on Redhat 5.1. Now if I comment out either of the two procedure definitions above the problem goes away. Also if I change the var lines (either one or both of them) to: var Sp: array [1..5] of integer; That works ok too. Any help/suggestions/bug-fixes gratefully received!! Many thanks 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

More Red Hat troubles with binary distribution
by Ken Linder (KC7RAD) 16 Dec '98

16 Dec '98

Hi again all, Is there anyone out there using RH 5.0, 5.1, or 5.2 that is able to use the GPC binary to compile pascal code? I have a Slackware install @ home that runs without a problem but I just installed RH 5.1 @ work and have the same old problems I used to have. If I recall correctly, a solution was never found. Hints??? Ideas???? Solutions??? Anything would be appreciated!!! TNX Ken Linder kc7rad(a)vegasnet.net

3 2

re: link problem with gpc beta
by Russ Whitaker 16 Dec '98

16 Dec '98

Ross Cartidge wrote about problem with gpc and gcc 2.8.1 had same problem earlier do a make clean make CFLAGS="-O2" LANGUAGES=pascal make CFLAGS="-O2" pascal.install and the problem will go away Russ

1 0

Re: link problem with gpc beta
by Frank Heckenbach 15 Dec '98

15 Dec '98

Ross Cartlidge wrote: > I just compiled the version beta version of gpc with gcc 2.8.1. > It compiled and installed fine but when I tried to compile a pascal > program the following were undefined:- > > `_p_gpc_locase' > `_p_gpc_upcase' > `_p_strlen' > > > I couldnt find them in the source - where are they :-) They should be in rts/gstrings.pas, and go into libgpc.a when compiling GPC. Which beta version exactly did you get, and are you sure you use only files of the same version together (and not perhaps unintentionally a previously installed libgpc.a)? This might apply especially if you're using DJGPP where AFAIK there was a directory restructuring recently. When in doubt, you might want to remove all instances of libgpc.a and install again. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

link problem with gpc beta
by Ross Cartlidge 15 Dec '98

15 Dec '98

I just compiled the version beta version of gpc with gcc 2.8.1. It compiled and installed fine but when I tried to compile a pascal program the following were undefined:- `_p_gpc_locase' `_p_gpc_upcase' `_p_strlen' I couldnt find them in the source - where are they :-) -- Mr Ross Rodney Cartlidge, Data Network Manager, Information Technology Services Building H08, The University of Sydney, NSW, 2006, Australia R.Cartlidge(a)isu.usyd.edu.au Ph: +61 2 9351 5506 Fax: +61 2 9351 5001 Mobile: +61 412 551 283

1 0

Unsubscribe
by Donohue, Pat 14 Dec '98

14 Dec '98

Unsubscribe

1 0

Re: enumerations in units problem
by Sam B 13 Dec '98

13 Dec '98

Frank Heckenbach replied: >It has been >fixed by now, and your test program will compile with the next GPC >version. Thanks for the report, anyway. Has this next version been released? I have searched the net and the latest version I could find any reference to was the one I am already using (19980830). If a new version has not been released, is there somewhere I can get a patch for this particular problem? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: Why won't this work?...
by Frank Heckenbach 12 Dec '98

12 Dec '98

Orlando Llanes wrote: > I get the following error with the program listed below: > > 0c:/nano/tmp2.exe: could not read all the data from file `tmp.txt' in > `BlockRead' (#414) > > Seems that it prints the first character, but then ends unexpectedly. The > file tmp.txt is below the program. This seems to be due to a DJGPP bug (fflush() clobbers the file position -- or is this allowed, any standard experts here?). For now, I put a work-around in the RTS for Dos systems. Perhaps this should better be done by an autoconf test, but I don't know how to do this (any autoconf experts here?). -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Why won't this work?...
by Orlando Llanes 11 Dec '98

11 Dec '98

I get the following error with the program listed below: 0c:/nano/tmp2.exe: could not read all the data from file `tmp.txt' in `BlockRead' (#414) Seems that it prints the first character, but then ends unexpectedly. The file tmp.txt is below the program. {--- Cut here for tmp2.pas ---} program Tmp2; var F : File; Ch : Char; begin Assign( F, 'tmp.txt' ); Reset( F, 1 ); while not EOF(F) do begin BlockRead( F, Ch, 1 ); Write( Ch ); end; Close( F ); end. {--- Cut here ---} {--- Cut here for tmp.txt ---} 0x3dF 0X3Af ++ TestOJL, ++= 1e0 1.2 22.3e-3 309 , _1234567890_1234567890_1234567890_1234567890_1234567890_1234567890 _Testing_123 This_is_a_really_long_variable_in_fact_only_part_of_it_will_be_kept_the_rest_will_be_ignored ' ' '' '''' print( 'foo' ) foo 'a string' 'another string' __test__ == -= << >> >>= if main print() endmain {--- Cut here ---} 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

1 0

unsubscribe
by Harald A. Irmer 11 Dec '98

11 Dec '98

unsubscribe

1 0

Re: enumerations in units problem
by Frank Heckenbach 11 Dec '98

11 Dec '98

Sam B wrote: > Greetings, > I am having a rather strange problem when using an enumerated > type declared in a unit. If that type is used in a second unit, > and also in a third that uses both the first and second, the > type cannot be used as a parameter to a function. This probably > isn't a very good description Actually, it is ;-), because this was a notorious bug. It has been fixed by now, and your test program will compile with the next GPC version. Thanks for the report, anyway. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

enumerations in units problem
by Sam B 11 Dec '98

11 Dec '98

Greetings, I am having a rather strange problem when using an enumerated type declared in a unit. If that type is used in a second unit, and also in a third that uses both the first and second, the type cannot be used as a parameter to a function. This probably isn't a very good description, so please just look at the example I have included at the end of this post, it is the smallest program I could produce to generate the problem. The output from gpc is: > gpc p.pas p.pas: In function `program_P': p.pas:23: incompatible type for argument 1 of `U_proc' I am running on Redhat Linux 5.0, and my gpc version is version 19980830, based on gcc-2.8.1. Does anyone know what might be causing this, and if there is a workaround or fix? Thanks in advance, Sam. --- begin example (p.pas) --- 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); { error is generated on this line } end. --- end example --- ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Bug in gpc-cpp ?
by Ian Thurlbeck 08 Dec '98

08 Dec '98

Hello again, fellow Pascalers! After getting a bug fix for the set addition problem from Peter (thanks very much Peter!) within 24 hours I've decided to try my luck again. There is some strangeness with the gpc-cpp preprocessor; here is some code to trigger it: ------- main.h --------- #ifndef Funny #define Funny 1 #endif {**} {**} ------- end ------------ ------- main.p --------- program MxFiler; #include "main.h" BEGIN writeln('Hello '); END. ------- end ------------ If you do: ida % gpc -E main.p then gpc-cpp goes into a infinite loop. Now the strange bit. If you remove any of these lines/characters the preprocessing works as expected: 1) Change #ifndef to #ifdef in main.h 2) Remove the #ifndef and #endif lines in main.h 3) Remove either of the comment lines in main.h 4) Remove the trailing '}' from the first comment line in main.h 5) Remove #include from main.p and replace it with the contents of main.h I can easily work around this of course, but a fix would be better! Thanks for any 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

2 1

GPC 19980830 Bug in SET handling ?
by Ian Thurlbeck 08 Dec '98

08 Dec '98

Dear Pascalers The following code core dumps during the set 'in' operation: ------ cut ---------- program setbug(input,output); CONST FirstChar = ['+','-','0'..'9']; #ifdef FIX GoodChar = ['+','-','0'..'9','.','e','E']; #else GoodChar = FirstChar+['.','e','E']; #endif VAR ch:CHAR; in_set:BOOLEAN; BEGIN ch:='0'; writeln('Here we go:'); in_set:= ch IN GoodChar; writeln('in_set is ', in_set); END. ------ cut ---------- ida % gpc -g -o tt tt.p ida % ./tt Here we go: Segmentation fault (core dumped) ida % gdb /usr/local/egcs-1.1b-obj/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.57/gpc1 core [ ... ] Core was generated by `./tt'. Program terminated with signal 11, Segmentation fault. #0 0x80491f5 in rindex () (gdb) backtrace #0 0x80491f5 in rindex () #1 0x4000a1f8 in ?? () #2 0x8049348 in ftell () (gdb) Note I can fix it by using the alternate code: ida % gpc -DFIX -g -o tt tt.p ida % ./tt Here we go: in_set is True ida % Compiler details: ida % gpc -v Reading specs from /usr/local/egcs-1.1b-obj/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.57/specs gpc version 19980830, based on egcs-2.91.57 19980901 (egcs-1.1 release) Any suggestions ? Of course I can always use the workaround. Many thanks 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

2 1

Re: GPC 19980830 Bug in SET handling ?
by Frank Heckenbach 07 Dec '98

07 Dec '98

Ian Thurlbeck wrote: > #ifdef FIX > GoodChar = ['+','-','0'..'9','.','e','E']; > #else > GoodChar = FirstChar+['.','e','E']; > #endif > > [...] > > Any suggestions ? Of course I can always use the workaround. Unfortunately no other suggestion. GPC's set code is not very reliable, and esp. set addition is known to be buggy. :-( Since there don't seem to be many programmers using sets (besides you and me), this problem doesn't have very high priority on the to-do list... So, you'll probably have to live with workarounds for awhile -- unless you want to hack GPC itself and fix the bugs... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Patch for building gpc-19980830 with egcs-1.1.1.
by Niels Kristian Bech Jensen 06 Dec '98

06 Dec '98

Hi, I've built gpc-19980830 with egcs-1.1.1 using gcc-egcs-2.91.55.diff and the patch below. This patch ensures that -DEGCS is added to CFLAGS if gpc is built with egcs. diff -urN gpc.orig/p/Make-lang.in gpc/p/Make-lang.in --- gpc.orig/p/Make-lang.in Mon Aug 31 03:05:02 1998 +++ gpc/p/Make-lang.in Sun Dec 6 13:39:11 1998 @@ -45,6 +45,11 @@ gpc_version=$(gpc_release) rts_version=$(gpc_release) +is_egcs := $(shell if $(CC) --version | grep 'egcs' > /dev/null; then echo y; else echo n; fi) +ifeq ($(is_egcs),y) +GPC_EGCS_FLAG=-DEGCS +endif + # Extra flags to pass to recursive makes. GPC_FLAGS_TO_PASS = \ "CROSS=$(CROSS)" \ @@ -54,6 +59,7 @@ "BISONFLAGS=$(BISONFLAGS)" \ "CFLAGS=$(CFLAGS)" \ "X_CFLAGS=$(X_CFLAGS)" \ + "GPC_EGCS_FLAG=$(GPC_EGCS_FLAG)" \ "LDFLAGS=$(LDFLAGS)" \ "LEX=$(LEX)" \ "LEXFLAGS=$(LEXFLAGS)" \ @@ -219,7 +225,7 @@ $(srcdir)/p/doc/sets.texi p/gpc.o: $(srcdir)/p/gpc.c $(CONFIG_H) gansidecl.h multilib.h Makefile $(lang_specs_files) - $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ + $(CC) -DGPC $(GPC_EGCS_FLAG) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ -DGPC_MAJOR="\"$(gpc_major)\"" \ -DGPC_MINOR="\"$(gpc_minor)\"" \ -DGPC_RELEASE="\"$(gpc_release)\"" \ diff -urN gpc.orig/p/Makefile.in gpc/p/Makefile.in --- gpc.orig/p/Makefile.in Thu Jul 30 14:11:35 1998 +++ gpc/p/Makefile.in Sun Dec 6 13:39:41 1998 @@ -126,7 +126,7 @@ all.indirect: Makefile ../gpc1$(exeext) ../gpc-cpp$(exeext) ../libgpc.a # IN_GCC tells obstack.h that we are using gcc's <stddef.h> file. -INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC +INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC $(GPC_EGCS_FLAG) # This is the variable actually used when we compile. ALL_CFLAGS = $(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS) \ -- Niels Kristian Bech Jensen - nkbj(a)image.dk - http://www.image.dk/~nkbj/ ---------->> Stop software piracy --- use free software! <<----------

2 1

gpc gets segfault
by Miguel Lobo 06 Dec '98

06 Dec '98

I have recently downloaded GPC and tried to convert some of my Borland Pascal 7.0 files to compile with it. One of them stopped compiling with a segfault. After a while I managed to make a small source file which reproduces the bug: unit bug interface type o = object procedure f1(s: string(255)); end; var a: integer; implementation procedure f2; begin end; procedure f1(s: string(255)); begin end; Later I realized that maybe I shouldn't be using string(255) as a parameter's type, and when I defined string255 = string(255) and used string255 as the type for 's', it worked fine. Anyway, I think that it can be still called a bug since gpc stops with a "Internal compiler error". GPC's output when I try to compile that file is: parse error before '(' missing semicolon parse error before 'Implementation' gpc: Internal compiler error: program gpc1 got fatal signal 11. I am using Kernel 2.0.35, glibc-2.0.7, and gcc 2.7.2-3. Keep up the good work.

2 1

Re:
by Pablo Bendersky 03 Dec '98

03 Dec '98

> hi there i have a problem, i just starting this pascal programming and i > can't do question 10 on page 158, chapter 4. in pascal programming and > problem solving, by sanford leestma and larry nyhoff. think you can help, > please respond, thank you. melissa Maybe if you tell us the question of the book. I personally, don't know it. BTW, where is the .tt address from ? --- Pablo Gabriel Bendersky bender(a)einstein.com.ar UIN : 1916679 Buenos Aires - Argentina

1 0

Problem with compiling a program.
by Andrew Cameron 29 Nov '98

29 Nov '98

Hi, I have a problem in that I need to compile a program where a function is declared as type string. Here is a sample program test(input,output); function getname: string; begin getname := 'somestring'; end; begin end. The compiler aborts with parse error before 'String' If I declare the function as char it compiles. How do I get this to compile? Please reply directly as I have just subscribed to the List. I am using gpc version 2.0 Thanks in Anticipation Andrew Cameron

2 1

Re: Append on untyped files?...
by Frank Heckenbach 29 Nov '98

29 Nov '98

Orlando Llanes wrote: > On Thu, 26 Nov 1998, Frank Heckenbach wrote: > > Yes, use `Reset' and then `Seek' to the `FileSize' (BP compatible) > > or use `SeekWrite' or `SeekUpdate' (Extended Pascal standard) > > instead. (I hope this all works correctly now -- there were some > > problems with these things earlier. If there still are problems, > > send me a test program.) > > I tried with both BP and GPC, I don't think using Reset is supposed to > work since it's read only (I don't think it should either, it'll make > Reset -a read only statement- into an ambiguos statement). Well, that's what BP does. It's funny -- when GPC behaves differently as BP does, we get requests to make GPC "compatible"; and when we do, people start to realize BP's strangenesses. ;-) In BP, Reset is read-only only for text files, and for typed and untyped files when the global variable FileMode is set to 0 (default 2). In GPC, it's the same now... > I even tried > with SeekWrite, didn't bother to write SeekUpdate since 2 out of 3 are not > good odds :P The program I wrote to test it is at the end of this e-mail. Well, I tried it with BP 7.0 and the current GPC, and it does work with both. Of course, foo.txt has to exist before starting the program, just like it has to with Append in BP. If this is the problem, you can check FileExists before opening or use I/O checking like in the following code fragment (again, works well with BP and GPC for me). If there are other problems, tell me which ones. Assign( f, 'foo.txt' ); {$I-} Reset( F, 1 ); {$I+} if IOResult = 0 then Seek( F, FileSize(F) ) else Rewrite (F, 1); BlockWrite( F, V, sizeof(V) ); Close( F ); > Rename the file > Create a new file with the old name > Copy the contents of the renamed file into the new one > Delete the renamed file > > This is prolly also the only way to do it. I hope not. Besides the fact that it's very inefficient as you pointed out, it also loses information about file ownership, permissions etc. (maybe not applicable under Dos). Kevin A. Foss wrote: > If you want (non-extended) standard Pascal, you'll have to do this on > any type of file -- because there is no choice other than to rewrite() > when doing file output. The file handling that is there is as simple > as possible, probably so > it would be portable, but it has always been a pain with Pascal. True, but I think we should really allow ourselves at least the luxury of Extended Pascal... ;-) > Anyways, here's a use of extend (based on Orlando's code) on an untyped > file: This code doesn't work with the current GPC any more because of too strict type checking, but I fixed it so it should work again with the next GPC version, except that you have to replace rewrite(out); [...] extend(out); by rewrite(out,1); [...] extend(out,1); (Another stupid BP legacy for untyped files...)-: So, this will be the best solution after the next release. Until then, Reset and Seek should work fine. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: Some questions
by Frank Heckenbach 29 Nov '98

29 Nov '98

Gerry Dubois wrote: > RE Translating C header files > > Contact Florian Klaempfl <ba2395(a)fen.baynet.de> > a C to P header conversion program does exist and is currently being > inproved as part > of the FPC Pascal development. Especially for the PalmPilot port which > requires the conversion of all the PALM O/S C header files. > > You can download a copy from > > ftp://tflily.fys.kuleuven.ac.be/pub/fpc/source/ > > It's in rtl.zip utils/convert/h2pas How well does it work now? Last time I checked (which was some weeks ago), it wasn't quite usable. It failed for stdio.h and other standard headers, and what it did translate was far from a verbatim translation -- ISTR that it got the types quite mixed up, and tried to translate preprocessor macros to Pascal functions -- which I think causes more problems than it solves -- and other things... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Append on untyped files?...
by Kevin A. Foss 29 Nov '98

29 Nov '98

On Sat, 28 Nov 1998 19:50:35 -0500 (EST), Orlando Llanes wrote: >On Thu, 26 Nov 1998, Frank Heckenbach wrote: >> BTW, should we make `Append'/`Extend' work on typed and untyped >> files? Neither BP or the standard do it/allow it, but I don't see >> any reason why not, and it doesn't *seem* too hard to implement... As far as I know, Extend already does. I tried the code that follows with GPC 980420 (the last version that worked with gcc 2.7.x) and it worked fine for me. > > So far, the easiest way I've seen is to.. > >Rename the file >Create a new file with the old name >Copy the contents of the renamed file into the new one >Delete the renamed file If you want (non-extended) standard Pascal, you'll have to do this on any type of file -- because there is no choice other than to rewrite() when doing file output. The file handling that is there is as simple as possible, probably so it would be portable, but it has always been a pain with Pascal. Anyways, here's a use of extend (based on Orlando's code) on an untyped file: program Tmp(output); var out : bindable file; b : BindingType; V : array[ 1..4 ] of char; begin b := binding(out); b.name := 'foo.txt'; bind(out,b); b := binding(out); rewrite(out); V := 'Foo,'; BlockWrite(out, V, sizeof(V)); unbind(out); b := binding(out); b.name := 'foo.txt'; bind(out, b); b := binding(out); extend(out); V := 'Bar'; BlockWrite(out, V, sizeof(V)); unbind(out); end. -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Re: Append on untyped files?...
by Frank Heckenbach 29 Nov '98

29 Nov '98

Orlando Llanes wrote: > Is it possible to open a file for writing without truncating it? Yes, use `Reset' and then `Seek' to the `FileSize' (BP compatible) or use `SeekWrite' or `SeekUpdate' (Extended Pascal standard) instead. (I hope this all works correctly now -- there were some problems with these things earlier. If there still are problems, send me a test program.) BTW, should we make `Append'/`Extend' work on typed and untyped files? Neither BP or the standard do it/allow it, but I don't see any reason why not, and it doesn't *seem* too hard to implement... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Do nothing program does something???
by kc7rad＠vegasnet.net 26 Nov '98

26 Nov '98

The following program displays 'Linux' as if I did a writeln('Linux') when it is run. I am running an older ver of Slackware & GPC beta. Any ideas? Ken L. %<----------------------------------------------- program uname; const BuffSize = 2048; var read_fp : file; buffer : array[1..BuffSize+1] of char; chars_read : integer; procedure memset(cPtr : PChar; SetVal : char; size : integer); C; begin (* memset(buffer, char($00), BuffSize);*) (* This strange program looks like it is doing a writeln('Linux') when run! *) end.

2 2

Append on untyped files?...
by Orlando Llanes 26 Nov '98

26 Nov '98

Is it possible to open a file for writing without truncating it? The reason I ask is because recently I thought about how POV Ray allows you to stop a rendering in progress and save a partial file, then later allows you to continue where you left off. The only way I can think of is by renaming the file to a temporary name, writing a new file with the same name (truncates it to 0), copy the contents of the temporary file into the new one, delete the temporary file, then you write to the new file from then on. Is there a better way? Am I doing it the hard way? :) 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

1 0

Some questions
by Pablo Bendersky 21 Nov '98

21 Nov '98

Hello, Maybe my questions are a little bit off topic, but I think here is the best place to ask Pascal related questions. I'm currently programming in Delphi, and I wold like to "translate" it to GPC. How can it be done ? Can it be done ? Other question. Is there any way to translate a C header file into a Delphi Unit ? Thanks --- Pablo Gabriel Bendersky bender(a)einstein.com.ar UIN : 1916679 Buenos Aires - Argentina

3 4

Re: Pipes, Shared memory & other Linux stuff...
by Frank Heckenbach 21 Nov '98

21 Nov '98

kc7rad(a)vegasnet.net wrote: > Has anyone here experimented with pipes, shared memory, > semaphores, message queues, etc in Linux with GPC? I curious > if there are any units or modules that help do any of this. I've done a little with pipes. I wrote the following routines (mainly because I needed one of them to do some printing via lpr in GPC). They're written in C (but the Pascal declarations are included), so that they're portable (among Unix systems, this is -- of course, they won't work under Dos). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan begin 600 pipe.tar.gz M'XL(`%OR5C8"`^U8;7/;-A+V9_Z*;>XFHCRR3,J)?(F:FRJNE6CJV!I)OIRO MX]-`)"AA0H$<`)2CIOGOW05)F7)3UVE[[4V&.Q[)6`#[^NQ"0"I2W@[V_J?D M>U[7\V`/`([\_-M_\L1^$QU[3X\`NMW.TZ?=8]_KXJS7[?I[X.W]"91IPQ3` M7J28?'?O.J[TWA='A_M.:B$`!P>`_PFY@)`9!I%*5L!D"":!5"4!UYIK9T!1 M@M<\>,?EG`7+%OC/GOWCP/<._([C3)="0R1B3CO6(N0XRF1@1"(UW`BS!+/D M$"5QG-R0HA'3`8LAY$',%+/+GCM.N05(a)A)8-R`Y+[HBAA.=P,C$*=_>@KQ;_ M:L&I7(^0.RK8NHDK!FC#R*@>G/3NB)LF!>H>*JX';YDP+3B)$\TO,I-F!J=? M)DG,F;RKRP8JS!3?FMZ7(:I\L*XU8I&VS:S8%DR3_#^H*KK/(&L&)H)K7HD] M8=S8X!>IA)LE[H:4S,*<+<2:2YAO@.QLV50YM)JI1;;BTFAK,+A6#F4N1T<Q M"U[3(H7+M5")M"QRK>40-U"<&4[8(C@4J#I,%`&K8A'7#3)3ADR%D%BW#H7$ MSS9Y4VQG&%G%3:8D#X'I/"8:7!0UYX`E&N8PZVLM%M+.-MMP(1VN5*):($5, M[I8BVC",;#2)J3D&=2=$(HY!)H9$6\=YZ&32H`@6F(S%\2:O%#)*D\^E0U1/ M)+F:H8H")UB*.-Q5$]!2$(92%:+W+1`2$A5RE=<?7Y."!3<V^N0<B[43811/ MC(H/3H";H.T4%1B+N6)J0SHCQ=&X)#(W:&4/-DD&`9,8@%!HQ-P\,Z2US,@J M"46T<9"12:L:O3%<K30DD1V\.K^$LT+Z*RZYPNH=9?-8!,@.N$0?,"LI<?02 MDS'?6!@-R(I)804,$I1NJ[T%:VRJ5)N=]L]MOS4QI&B0H&62HD5+9LAH&[@\ M[5$6MP!7.F^'T]<7EU/HGU_!V_YXW#^?7O4L)C"H0%&T<L0JC06!A2EL:&9# M_KTY'9^\QO7]E\.SX?3*P7(a),AM/ST\D$!A=CZ,.H/YX.3R[/^F,878Y'%Y/3 M-L"$\U^)C%-&)K(1Q@"$W#`1:W3Y"O.AT32$PY*M"=L!QU)$;$.0I)N'A]UA M<8+`*'KL;1Q[B+K<0-N63RY&5\/S5^VSX4NT'2&*\,9R5P)A8))?R=50!NT6 M/'T&4X[APQ87LX##`4PRVGYTY+6P"VF#2YTW??`ZON\?^$?><0LN)_VVLW_H M.'\3,HBSD,/7F<3LANWE/RL\9(CD#FNC#\T&2_\3;+'B/^=BH1KB.K0KY!$B MF:H%0QHLL;<6;1);)"W$^`DLJQOL`+;5@-MT/C@`43C#8L4OW<,1HC`+#+4` M_)@39_#M[#^GXPMP'^.29L&9G$[!Q1AL>3=+"KFK><QQN^OG4RWP\K\FO'B! MG[0R[T<06156AI[GT_#X,>IL:S/3X@<.7R&KYWQTG,'P[!3VJ=/8CNI:Y_93 MV[WS_[$YK^'[ZW*(O3G%8>X?.1V%\'WGFK2G(IP9^J2!B,!E(a)6U,;B[NW[.+ M[YKPXX^VKX$;A7;@NK@!7A"HWV'8FO`U^M(L/?%*4;BHZ=!I^\')3]V\T;FD MW;^VSA.5`0BQOF4^ZZ'IC]2C8LE'_.0QXKPJ*\S2#I2R\)?(5EQ%B7?]*6Y% M-7_/`ZR\PEF*6HL.LG2[8,;?"TK?76.]TK*==&"W?G`R6B4<+0)O1Y5SX_\I M7]Z]^:(,/+IY:+XHN]YORA=960U0N<S?6?$5193\KM9V\X])]CK!2):EAR?G MYZ4\A\H^[=T.3/*94)C9JD<\M&B`!OQ&:.#6W3')O0<O.^FT/N`2-!]>E!$J M(W8+@_MA57CB?R+MY!?L(*+4>(N[8OMNLP!K$NPNS(5]#DJW^JM0O9TM#?]D MX]G:]8M3#_/X[M1?50@$_+V:OCRBR@_Y*FFG3/]%[S_^DXY?O/\<>]W.,7(Z M^%V___PI^5?)0K&5?:_X%G&`OXS14PVO1O2.\('N"'AI5+!(`X((A`G7LH$W MQABO]>$&KRD2+S-TJZ+F<^<EAWZ#8_O8OF]@1_[O=/O8@3/3R@Q=Q3;8_*#= MAC?L_5"::[K_E$\F#BXOGT!P]2C!DY`K9*^9PJG3RMO#<[R$KB1;<6C,TAFU MM4;EC86.\`]_/\NOZ<''^KGI]S\WY2D@_I2_-Y185*@I#Y6<^M5T8@;=QCQH MV"<9/&.<.5\(21MO7V[`1;5%$-W&8:;5X5S(0[MKZX/[#:EJMJH`P-]5#$_U MXJMIC[`QSV^YKK'#MS2(I571Z,(^'#>:#I=ANS[E:JJIIIIJJJFFFFJJJ::: 0:JJIIB^-?@)^VS9'`"@````` ` end

1 0

Pipes, Shared memory & other Linux stuff...
by kc7rad＠vegasnet.net 21 Nov '98

21 Nov '98

Has anyone here experimented with pipes, shared memory, semaphores, message queues, etc in Linux with GPC? I curious if there are any units or modules that help do any of this. TNX es 73s Ken

1 0

gpc on HPUX 10.20?
by Nicholas Geovanis 20 Nov '98

20 Nov '98

Guten Morgen Has anyone compiled gpc-19980830 on HPUX 10.20 with the HP ANSI C compiler? I'm using their ANSI compiler in K-and-R mode (should I be using ANSI mode?). The first three or four source files compile OK but gpc.c has problems. At least one error looks completely bogus and I've worked around it easily, in other words it looks like a compiler bug. But I have another and I'm starting to get concerned. In general, are you using gcc as your "cc" rather than a vendor's? tschues - Nick G. <---------------------------------------------------------------------------> America's a pretty good country but you should | Nick Geovanis never love it more than it loves you. | IT Computing Svcs - Horace Coleman - "Nam Boogie (Tet Version)" | Northwestern Univ from The Veteran, Spring 1998 V n-geovanis(a)nwu.edu

2 1

YEE HAW!!!...
by Orlando Llanes 19 Nov '98

19 Nov '98

Just had to say KEEP UP THE GREAT WORK GPC TEAM!!! :) The latest Borland extensions work great! I wrote a program that saves PCX files in BP a while ago, and all I had to do was change 2 declarations and it compiled without any other changes!!! Not only that, but the program works as expected!!!! :) 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

1 0

minor graphics questions
by Robert P. Ewing 18 Nov '98

18 Nov '98

Hi, all. A few questions on the use of graphics in grx20. I am coming from Borlad Pascal, and have a lot to learn about graphics. 1) How do I flip back and forth between text and graphics screens? I know how to initialize the graphics, and the computer reverts to text mode when the progrma terminates. But I don't know how to flip between them myself. 2) How do I -- or can I? -- control the 0-15th entries in the palette? I have no trouble changing 16-255, but the bottom 16 seem resistant. Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University

2 1

Re: random number generator
by Frank Heckenbach 18 Nov '98

18 Nov '98

Robert P. Ewing wrote: > I've seen some discussion about random number generators here > recently. I came across a quite good one (this being something > I use extensively in my work), and thought I'd share it. It is > written up in ACM Transactions on Modeling and Computer Simulation > 8(1) 3-30, 1990. Supposedly it has a period of -1 + 2^19937. > The original was in C; this translation returns the same values > as the original. It is called the Mersenne Twister. Fine. If we want to use it in GPC, we have to be sure about copyright and patent issues. Is this algorithm free of patents? > This library is free software; you can redistribute it and/or > modify it under the terms of the GNU Library General Public > License [...] Was this the license of the original C code, too? > LI = __longlong__ integer; > UL = __unsigned__ LI; {define 64-bit unsigned integer} BTW, UL can be defined in a more readable way as `LongCard' now -- or `Cardinal (64)' if you want it to be exactly 64 bits wide, regardless of the word size of the target platform. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Curious bug with gpc 19980830
by sam.littlewood＠quantel.com 16 Nov '98

16 Nov '98

Has anyone a fix for this rather curious bug? - it seems subranges, packed records and VAR arguments conspire to make the compiler throw a bogus error!? Thanks for any help. SamL -------8<--------- program foo; { Using a subrange type in a packed recrod seems to break passing the type by reference } type t1 = 0..100; {Has to be subrange} r1 = packed record { Has to be packed } f1 : t1; end; procedure proc1(var a1: t1); { Has to be var } external; procedure proc2(var a1: t1); { Also has to be var } begin proc1(a1); end; begin end. -------8<--------- Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19980830, based on gcc-2.8.1 /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19980830 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Di586 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386 -D__i586 -Asystem(unix) -Acpu(i386) -Amachine(i386) foo.pas /tmp/cca16201.i GNU CPP version 2.8.1 (i386 GNU/Linux with ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/i586-pc-linux-gnu/include /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/gpc1 /tmp/cca16201.i -quiet -dumpbase foo.pas -version -famtmpfile=foo.gpc -o /tmp/cca16201.s GNU Pascal version 2.8.1 (i586-pc-linux-gnu) compiled by GNU C version 2.7.2.3. foo.pas: In function `Proc2': foo.pas:19: type mismatch in argument 1 of `Proc1' foo.pas:19: passing arg 1 of `Proc1' from incompatible pointer type

2 1

random number generator
by Robert P. Ewing 15 Nov '98

15 Nov '98

Hi all. I've seen some discussion about random number generators here recently. I came across a quite good one (this being something I use extensively in my work), and thought I'd share it. It is written up in ACM Transactions on Modeling and Computer Simulation 8(1) 3-30, 1990. Supposedly it has a period of -1 + 2^19937. The original was in C; this translation returns the same values as the original. It is called the Mersenne Twister. enjoy. Toby (* A Pascal program for MT19937: Real number version([0,1)-interval). Written in C 4/6/1998 by Takuji Nishimura. Translated to GNU Pascal 11/2/1998 by Toby Ewing. genrand() generates one pseudorandom real number (double) which is uniformly distributed in [0,1)-interval, for each call. sgenrand(seed) sets initial values to the working area of 624 words. Before genrand(), sgenrand(seed) must be called once. (The seed is any 32-bit integer except for 0). Coded by Takuji Nishimura, considering the suggestions by Topher Cooper and Marc Rieffel in July-Aug. 1997. This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Copyright (C) 1997 Makoto Matsumoto and Takuji Nishimura. When you use this, send an email to: matumoto(a)math.keio.ac.jp with an appropriate reference to your work. *) Program MersenneTwister; Const N = 624; {Period parameters} M = 397; type LI = __longlong__ integer; UL = __unsigned__ LI; {define 64-bit unsigned integer} mtary = array[0..N] of UL; magary = array[0..1] of UL; var j : integer; mti : integer value N+1; {mti = 1 means mt[N] is not initialized} mt : mtary; {the array for the state vector} Procedure sgenrand(seed : UL); { Set initial seeds to mt[N] using the generator Line 25 of Table 1 in [KNUTH 1981, The Art of Computer Programming Vol. 2 (2nd Ed.), pp 102]. } begin mt[0] := seed AND 16#ffffffff; for mti := 1 to N do mt[mti] := (69069 * mt[mti-1]) AND 16#ffffffff; end; Function genrand : real; var y : UL; kk : __short__ integer; Matrix_A : UL value 16#9908b0df; {constant vector a} Up_Mask : UL value 16#80000000; {most significant w-r bits} Low_Mask : UL value 16#7fffffff; {least significant r bits} T_Mask_B : UL value 16#9d2c5680; {Tempering parameters} T_Mask_C : UL value 16#efc60000; mag01 : magary value (0, Matrix_A); begin if (mti >= N) then begin {generate N words at one time} if (mti = N+1) then sgenrand(4357);{If sgenrand hasn't been called, use default seed.} for kk := 0 to N-M do begin y := (mt[kk] AND Up_Mask) OR (mt[kk+1] AND Low_Mask); mt[kk] := mt[kk+M] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; for kk := N-M to N-1 do begin y := (mt[kk] AND Up_Mask) OR (mt[kk+1] AND Low_Mask); mt[kk] := mt[kk+(M-N)] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; y := (mt[N-1] AND Up_Mask) OR (mt[0] AND Low_Mask); mt[N-1] := mt[M-1] XOR (y shr 1) XOR mag01[y AND 16#00000001]; mti := 0; end; y := mt[mti]; inc(mti); y := y XOR (y shr 11); y := y XOR ((y shl 7) AND T_Mask_B); y := y XOR ((y shl 15) AND T_Mask_C); y := y XOR (y shr 18); genrand := real(y) * 2.3283064365386963e-10; end; begin {Output first 1000 generated numbers} sgenrand(4357); {any integer > 0 works as a seed} for j := 1 to 1000 do begin write(genrand:10:8); if ((j mod 8) = 0) then writeln else write(' '); end; end.

1 0

Re: Curious bug with gpc 19980830
by Frank Heckenbach 13 Nov '98

13 Nov '98

sam.littlewood(a)quantel.com wrote: > Has anyone a fix for this rather curious bug? - it seems subranges, packed > records and VAR arguments conspire to make the compiler throw a bogus > error!? I don't have a fix (apart from the obvious workarounds such are using the base type instead of the subtype or a non-packed record, if these are options), but I added it to the list of known bugs (sam8.pas). -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: What is the latest ver of gpc?...
by Frank Heckenbach 12 Nov '98

12 Nov '98

Orlando Llanes wrote: > PROGRAM Tmp; > > var > F : File Of Byte; > V : Char; > > BEGIN > Assign( F, 'tmp.txt' ); > Reset( F ); > BlockRead( F, V, 1 ); > Close( F ); > END. BlockRead and BlockWrite only work with untyped files (simply `File'), not typed files (`File of Byte'), just like in BP. So try: PROGRAM Tmp; var F : File; V : Char; BEGIN Assign( F, 'tmp.txt' ); Reset( F, 1 ); BlockRead( F, V, 1 ); Close( F ); END. (The 1 in the `Reset' is needed because of compatibility to a stupid CPM legacy in TP.)-: -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Re: What is the latest ver of gpc?...
by Frank Heckenbach 12 Nov '98

12 Nov '98

Orlando Llanes wrote: > > BlockRead and BlockWrite only work with untyped files (simply `File'), > > not typed files (`File of Byte'), just like in BP. So try: > > I get a bunch of weird parsing errors if I only use FILE, besides, the > problem was not that the file was not being read, the problem is that > BlockRead is not being recognized as a built-in routine. Well, BlockRead will be rejected for typed files at compile time, not at run time... Anyway, please be more specific with your descriptions: what errors do you get with the original and the modified test program? Are you sure you're using the correct GPC -- try `gpc -v', and especially check if gpc1.exe (the actual compiler) is current. (ISTR, there were some directory changes under DJGPP recently that might cause an older previously installed version to be used...) -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: odd bug with constants
by Frank Heckenbach 11 Nov '98

11 Nov '98

Robert P. Ewing wrote: > I've been moving an old program over to GPC, and ran across > the following. Apparently the '**' operator works fine on > variables, but it crashes if I put a hard-coded numerical > value in for the base. The old y^x = exp(y ln x) > workaround from Turbo seems to work fine. I don't know whether > this is a new or a known bug. This seems to be a bug in how the arguments to some operations on LongReal's (aka Extended) are passed, and real constants are assumed Extended by default. I added it to the bug list. Thanks for the report. > I note that if I write 'real(10.0)' rather than '10.0', the > program runs just fine... This would indeed be a useful workaround for now. (But AFAIR, TP doesn't like this -- if that's of any concern to you...) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

odd bug with constants
by Robert P. Ewing 11 Nov '98

11 Nov '98

Hi, all. I've been moving an old program over to GPC, and ran across the following. Apparently the '**' operator works fine on variables, but it crashes if I put a hard-coded numerical value in for the base. The old y^x = exp(y ln x) workaround from Turbo seems to work fine. I don't know whether this is a new or a known bug. Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University --------------------------------------------------- program StarStar(input, output); var y : real; x : real value 10.0; begin writeln('via exp(x ln y):'); {all these are fine} y := 5.557; write('variables, y > 0 '); writeln('exp(y ln x) = ', exp(y * ln(x))); y := -5.557; write('variables, y < 0 '); writeln('exp(y ln x) = ', exp(y * ln(x))); y := 5.557; write('constants, y > 0 '); writeln('exp(y ln x) = ', exp(y * ln(10.0))); y := -5.557; write('constants, y < 0 '); writeln('exp(y ln x) = ', exp(y * ln(10.0))); readln; writeln('via y ** x:'); {now for problems} y := 5.557; write('variables, y > 0 '); writeln(' x ** y = ', (x ** y)); y := -5.557; write('variables, y < 0 '); writeln(' x ** y = ', (x ** y)); y := 5.557; write('constants, y > 0 '); writeln(' x ** y = ', (10.0 ** y)); { <--- crashes here } y := -5.557; write('constants, y < 0 '); writeln(' x ** y = ', (10.0 ** y)); { <-- or, if you prefer, here } end. I note that if I write 'real(10.0)' rather than '10.0', the program runs just fine...

1 0

Re: ncurses
by Frank Heckenbach 11 Nov '98

11 Nov '98

Matthew Wiggins wrote: > I was tring to use ncurses in a pascal program. and I defined a packed > record of the WINDOW type, but how do I import the stdscr etc etc so I can > use the functions? The simple answer is var StdScr : asmname 'stdscr' WINDOW; but please read on... > I guess some people have done it. I'm not sure... Yes, I've done it (when writing a BP compatible CRT unit), and the way I did it was via a C layer. So I made a file crtc.c which #include's <ncurses.h> and defines some routines on top of that. These routines are declared as "C;" in crt.pas (the Pascal unit). Some other routines in crt.pas are implemented in Pascal, but they only call the routines from crtc.c, not directly those from ncurses. The reason why I did it this way is because that guarantees some portability. E.g., the WINDOW type might change in different releases of ncurses, or in different curses libraries. -- In fact, there is a library called PDCurses which is widely ncurses compatible, but, not surprisingly, the internal structure of its WINDOW type is quite different. In the CRT unit, however, I can just drop in PDCurses for ncurses, and it works, because the only routines that need to know about the internals (and if only about the size of the WINDOW type) are written in C and can read the ncurses.h header. Of course, the better solution, as I pointed out in some other mails to this list, would be an automatic C header to Pascal translator which is quite a difficult thing to write. Anyone wants to try? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Ellipsis formal parameter & CRT module questions...
by Frank Heckenbach 11 Nov '98

11 Nov '98

kc7rad(a)vegasnet.net wrote: > 2) According to http://fjf.gnu.de/gpc-todo_6.html#SEC6 (Implemented > features) there is a portable ncurses CRT unit. Is this built into the RTL > (I couldn't find it on first look) or is it a seperate unit (or module)? It hasn't been published yet, but will be soon... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: What is the latest ver of gpc?...
by Frank Heckenbach 11 Nov '98

11 Nov '98

Orlando Llanes wrote: > Doh! Sorry for the typo, I downloaded 19980830 and it says that > BlockRead is undeclared :( I can't reproduce it. Can you send a test program, please? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Ellipsis formal parameter & CRT module questions...
by kc7rad＠vegasnet.net 11 Nov '98

11 Nov '98

Two quick questions... 1) According to the HTML docs, ellipsis (...) are allowed in formal parameters but the code has no way (yet) of accessing them. If I specify procedure printf(cpFmt : cstring; ...); C; in a program & use it in that program, I can pass as many actual parms as I want. If I specify this in the 'interface' section of a UNIT, I cannot pass more than one parm to the procedure without the compiler stating that I passed too many parameters. I can come up with a work-around but if this will work in the next release, I won't worry about it. 2) According to http://fjf.gnu.de/gpc-todo_6.html#SEC6 (Implemented features) there is a portable ncurses CRT unit. Is this built into the RTL (I couldn't find it on first look) or is it a seperate unit (or module)? TNX! and BTW, GREAT WORK EVERYBODY! Ken L. kc7rad(a)vegasnet.net

2 1

ncurses
by Matthew Wiggins 11 Nov '98

11 Nov '98

I was tring to use ncurses in a pascal program. and I defined a packed record of the WINDOW type, but how do I import the stdscr etc etc so I can use the functions? I guess some people have done it. I'm not sure... /Matthew Wiggins bong.triax.com

1 0

compiling with grx20 under RHIDE
by Robert P. Ewing 10 Nov '98

10 Nov '98

Hello, all. I am having trouble with compiling grx20-using programs under RHIDE. Specifically, I can't seem to compile BLT_TEST.PAS under RHIDE, even though I *can* compile it successfully from the command line. >From the command line, the program compiles with: gpc -g --automake="-g" -o blt_test.exe blt_test.pas -lgrx20 I report this with gratitude to Maurice Lombardi, who patiently walked me through the procedure and sent me several files I was missing. >From RHIDE, if the grx20.o and grx20.gpi files are present, I get: ../Pascal/blt_test.pas (3) Error: module/unit Interface 'Grx20' could not be imported. If the grx20.o and grx20.gpi files are not present, I get: ../Pascal/blt_test.pas (3) Error: module 'Grx20' could not be compiled Compiler options such as --automake="-g" and -lgrx20 have no apparent effect. I am greatly encouraged that I have gotten the program to compile, but it seems that it ought to compile under RHIDE too (that is, after all, some of the point of RHIDE!). Any suggestions? Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University

2 2

RE: Automake
by Thamm, Russell 09 Nov '98

09 Nov '98

Thanks Peter, This weekend I wrote a quick and dirty program to produce a makefile from the USES clauses in the main pascal program and all the used files. It doesn't support included files. I then define the environment variable: RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=make -f$(subst .exe,.mk,$(OUTFILE)) This seems to work pretty well despite the fact that RHIDE maintains its own list of dependencies. Following is a sample makefile produced by the command: mkdep demo ticks.o lgrx20 %.o %.gpi: %.pas gpc -g -c $< all::demo.exe DEPS_demo=colors.gpi objects.gpi cydriver.gpi cyviews.gpi cybutton.gpi windows.gpi plots.gpi axes.gpi graph.gpi arrplot.gpi evedisp.gpi DEPS_colors= DEPS_objects=colors.gpi DEPS_cydriver=colors.gpi objects.gpi DEPS_cyviews=objects.gpi colors.gpi cydriver.gpi DEPS_cybutton=objects.gpi colors.gpi cydriver.gpi cyviews.gpi DEPS_windows=objects.gpi cydriver.gpi cyviews.gpi colors.gpi cybutton.gpi DEPS_plots=colors.gpi coords.gpi clip.gpi objects.gpi cyviews.gpi DEPS_axes=colors.gpi coords.gpi objects.gpi plots.gpi DEPS_graph=objects.gpi plots.gpi axes.gpi DEPS_arrplot=colors.gpi rfarray.gpi objects.gpi cydriver.gpi plots.gpi axes.gpi DEPS_evedisp=colors.gpi objects.gpi cydriver.gpi cyviews.gpi DEPS_coords= DEPS_clip= DEPS_rfarray=colors.gpi objects.gpi coords.gpi plots.gpi axes.gpi OBJS=colors.o objects.o cydriver.o cyviews.o cybutton.o windows.o plots.o axes.o graph.o arrplot.o evedisp.o coords.o clip.o rfarray.o ticks.o demo.o:demo.pas $(DEPS_demo) colors.o colors.gpi:colors.pas $(DEPS_colors) objects.o objects.gpi:objects.pas $(DEPS_objects) cydriver.o cydriver.gpi:cydriver.pas $(DEPS_cydriver) cyviews.o cyviews.gpi:cyviews.pas $(DEPS_cyviews) cybutton.o cybutton.gpi:cybutton.pas $(DEPS_cybutton) windows.o windows.gpi:windows.pas $(DEPS_windows) plots.o plots.gpi:plots.pas $(DEPS_plots) axes.o axes.gpi:axes.pas $(DEPS_axes) graph.o graph.gpi:graph.pas $(DEPS_graph) arrplot.o arrplot.gpi:arrplot.pas $(DEPS_arrplot) evedisp.o evedisp.gpi:evedisp.pas $(DEPS_evedisp) coords.o coords.gpi:coords.pas $(DEPS_coords) clip.o clip.gpi:clip.pas $(DEPS_clip) rfarray.o rfarray.gpi:rfarray.pas $(DEPS_rfarray) demo.exe: demo.o $(OBJS) gpc -odemo.exe -g demo.o $(OBJS) -lgrx20 Russell > -----Original Message----- > From: Peter Gerwinski [SMTP:peter@gerwinski.de] > Sent: Friday, November 06, 1998 10:24 PM > To: Thamm, Russell > Cc: gpc(a)hut.fi > Subject: Re: Automake > > Thamm, Russell wrote: > > I am having so much trouble with automake that I am considering > abandoning > > GPC > > altogether. > > [...] > > :-( > > > I keep running out of virtual memory on a machine with 256 MBytes of > memory. > > This looks like a circular dependency between some units. > > > Using a makefile is much better. > > Our current project (together with the related issue of > re-writing the GPI mechanism) is to re-implement the AutoMake > mechanism using `make'. > > > I am not absolutely sure how to express the > > dependencies. > > To get the (*$include ... *) dependencies, run `gpc -M foo.pas'. > It will produce a rule > > foo.o: foo.pas foobar.incl foobaz.incl > > you only need to extend by adding the gpi files of the units > used by this one and the action `gpc -c $(PFLAGS) foo.pas'. > The result will look like the following: > > foo.o: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > > Make seems to have no concept of a compilation producing more than one > > output file. > > If you duplicate the rule above for the GPI file, > > foo.o: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > foo.gpi: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > then `make' will nevertheless compile `foo.pas' only once (at > least according to my tests with GNU make:-). > > > I can get RHIDE to bypass automake by not specifying a primary file and > > adding all > > source files to the project. But Rhide apparently ignores the Uses > clauses > > when > > determining dependencies and I ca't work out how to use user-defined > > dependencies > > with it. > > What about producing a Makefile with RHIDE and adding the > `uses' dependencies manually? > > > A library for gpi's would be nice? > > Any suggestion how this could be implemented? > > > Any options to indicate to automake that certain units don't need to > be > > checked? > > Nope. But if AutoMake does not see the source, it will not try > to recompile. > > > I suspect that if automake kept track of the units not requiring > > compilation, things > > might improve.things. That is, the first time it checks grx20.pas, it > should > > note that > > no recompilation is required rather than rechecking the same file many > > times. > > Indeed. That's one reason why we think that `make' should be > invoked instead of `gpc1' duplicating the features of `make'. > > Greetings, > > 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

What is the latest ver of gpc?...
by Orlando Llanes 08 Nov '98

08 Nov '98

Is it 19980803? The reason I ask is because I had to do the seasonal reformatting of the drive, reinstalled GPC, and now it's telling me that BlockRead is undeclared :( 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

Re: next attempts
by Maurice Lombardi 07 Nov '98

07 Nov '98

Toby Robert P. Ewing a Ã©crit: > I tried, as you suggested, doing a redir -oe -o ....... >I got nothing -- Nothing! -- in the test1.out (redirected output) >file, lots of stuff on the screen. The reason is that you must type redir -o out.lst -eo ... in that order (redir output to out.lst and then error to output) I had made the mistake in my previous mail. To compare I have done this on my system, and out.lst is attached. redir -o out.lst -eo gpc -g -v --automake="-g" -o blt_test.exe blt_test.pas -lgrx20 Notice the parameter ="-g" to automake. With no parameter I got a SIGSEGV error if the unit grx20.pas had indeed to be recompiled (probably only in that case gpc looks for parameters to automake). This seems a new bug in gpc. But I may have not noticed it before because I usually give always some parameters to automake. > > So I made notes about where the original files were, made backup > copies, and traded in your files, being sure to move specs to > c:\gpc\lib\gcc-lib\djgpp\2.81. (I put djgpp.djl in c:\gpc\lib. no djgpp.djl belongs also to c:\gpc\lib\gcc-lib\djgpp\2.81 in addition by looking to the attached out.lst I have noticed that an other file crtf.o is needed in that directory (and not contained in the djgpp binary distribution). I give it also to you in attachment. Those two files djgpp.djl and crtf.o should be included in future betas, to avoid troubles for people like you who work only in pascal (all this stuff otherwise comes with gcc). >The relevant parts are, from gpc -g -v > --automake -o blt_test.exe c:\gpc\pascal\blt_test.pas -lgrx20 are: you should first cd \gpc\pascal and then from there issue the command: the path is no more necesary > reading specs from c:\gpc\lib\gcc-lib\djgpp\2.81\specs > gpc version 19980830, based on gcc 2.8.1 > {then there's a 6-line translated command line...} > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > $DJDIR/djgpp/include > $DJDIR/lib/gcc-lib/djgpp/2.81/include > /usr/include > end of search list > c:\gpc\lib\gcc-lib\djgpp\2.81\gpc1.exe c:/gpc/tmp\ccbaaaa -quiet -dumpbase blt > _test.pas -g -version -famtmpfile=blttest.gpc -fautomake -o c:/gpc/tmp\cccaaaa > > GNU Pascal version 2.8.1 (djgpp) compiled by GNU C version 2.8.1 > c:\\gpc\\pascal\\blt_test.pas:3: module '*' could not be compiled > > where, on the last line, the * is ascii 5, the "club" from playing cards. > Well you should really compile from within the directory c:\gpc\pascal I do not like this syntax c:\\gpc\\pascal\\blt_test.pas:3, even if it is logical \ have to be escaped in unix shells: gpc obviously reads wrongly the file. Good luck -- 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

Re: GNU Pascal: pascal library
by Frank Heckenbach 07 Nov '98

07 Nov '98

Peter Gerwinski wrote: > Be welcome! :-) But first have a look on what is already there > (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/) and what is > needed (see below for one suggestion). > > > 2) A standard (borland or watcom or something) Pascal library > > reference (or one of each type to write multiple libraries :), with > > descriptions of what each does etc. > > I have never seen a Watcom Pascal compiler. The only de-facto > standard I have seen in Pascal libraries are Borland's ones. As far as these are concerned, we now have everything of the non-object oriented units (i.e., except Turbo Vision and OWL), apart from the "Graph3" unit (primitive turtle graphics, probably not exactly in wide use ;-) and a few details. Other more or less "standard" libraries I heard of are some units by Turbo Power which seem to be some extentsions to the Borland units, and the units of Delphi. I saw the interface of Delphi's SysUtils units, and it's quite large and would require a lot of work to implement. > > Yes, I realize that this may be a huge task (how long did it take > > them to write the DJGPP2 libc? :), and that it would take a little > > while, but hey, it sounds interesting :) and you could take that little > > 'con' out of the cons section. In addition, non-C (but Pascal) > > programmers could use your compiler because you'd have a > > similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c > > reference :). > > > > NOTE: Just in case I wasn't clear, what I meant by writing a > > "standard Pascal lib" is writing the lib that is to Pascal as libc is to > > DJGPP :) > > There is no library in Pascal that corresponds to `libc'. > The closest thing is GPC's run-time library which implements > Pascal's `writeln' and such. But that one is ready and > working well. ;-) Yes, exactly. If you meant to re-implement the libc functionality in Pascal, I doubt whether that would be such a good idea. The implementation of libc, AFAIK, is quite system-specific, but its interface on the C level is rather portable, so it seems more sensible to use this interface, like the RTS does now, than to reimplement it. I recently added some functionality from the libc to GPC (e.g. some routines about file name, file name matching and globbing and getopt parameter parsing). The way I did it was to write a (thin) C layer over the libc interface if necessary to use C macros or such things, then a small Pascal layer if necessary to convert from or to Pascal strings (which are not easy to access from C code) or such stuff, and finally provide a Pascal declaration. This seems to be the best way for now. You can get the most recent GPC source distribution and see some examples of this in the rts/ directory (e.g., the unit filename.pas). However, not all the things I mentioned above are in that distribution yet, so if you want, we can provide you with the more current developer sources that contain them all. There are certainly a lot of things left in the libc and other libraries (portable ones as well as system dependent ones) that could be made available to Pascal in this way, and if that's what you like to do, you won't get out of work soon... ;-) Another (better, IMHO, but more difficult) approach would be writing a C-header-to-Pascal translator that translates a C header with all the details to Pascal in order to be used with GPC. If we had this, we could use libc and other libraries written in C directly from Pascal. This would take away not only the work of translating them and writing wrappers, but also the maintenance work and probably a lot of portability problems. However, writing such a translator is not easy. Yes, there are a number of "C to Pascal translators" available, but none of those I saw came even close to being useful for this purpose because they only provide a more or less close approximation of the C code and declarations in Pascal. But what we need here is really a 1:1 translation -- which *is* possible in GPC for almost all features of C. Peter and I have discussed this problem and came to some conclusions about how to approach it. So, if you like to try this (which wouldn't exactly be writing a library, but making available a lot of existing libraries), we can discuss with you our ideas so far. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GNU Pascal: pascal library
by Frank Heckenbach 07 Nov '98

07 Nov '98

Clyde Meli wrote: > Bpcompat already exists, and as far I am aware most of the stuff is now > incorporated in the gpc library. Ah, I have one suggestion - please > add FillChar and StrPas to the main library.... FillChar is already built into the compiler. StrPas is available under the name `CString2String' (which is more understandable than `StrPas' which tells almost nothing to me). In case you need it as `StrPas', here's the complete(!) BP compatible `Strings' unit for the next release of BPCompat (all the other CString functions are already or will then be in a RTS unit). { BP compatible strings unit. Everything else is in the RTS. Donated to the public domain. :-) } unit Strings; interface uses GPC; function StrPas (Str : CString) : TString; implementation function StrPas (Str : CString) : TString; begin StrPas := CString2String (Str) end; end. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GNU Pascal: pascal library
by Clyde Meli 07 Nov '98

07 Nov '98

> An interesting project...Well anyways, I'm a programmer that knows > cross-processor asm, C, C++, VC++, VB, Basic (eww), Euphoria (the > predecessor to C (and Pascal?)), and am learning Pascal. > Anyways, I noticed how GNU Pascal is lacking a standard Pascallian > library, and am interested in writing it. I would do so in DGJPP C (not > C++: too hard to interface with pascal (i think)), NASM assembly, and > possibly something else...however, I would need a few things first: > 1) your approval > 2) A standard (borland or watcom or something) Pascal library > reference (or one of each type to write multiple libraries :), with > descriptions of what each does etc. Bpcompat already exists, and as far I am aware most of the stuff is now incorporated in the gpc library. Ah, I have one suggestion - please add FillChar and StrPas to the main library.... > 3) A knowledge of how GNU Pascal calling convention works: (it should > interface nicely with DJGPP-C type, right?), offsets that function > paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), > etc. Did you look at the info file documentation? > If given the above, I would write a full-featured library for use > with GNU Pascal (or, at least, get pretty darn close :) that would be > almost 100% compatible with normal Pascal libraries, and I would also > maintain it, too :) > Yes, I realize that this may be a huge task (how long did it take > them to write the DJGPP2 libc? :), and that it would take a little > while, but hey, it sounds interesting :) and you could take that little > 'con' out of the cons section. In addition, non-C (but Pascal) > programmers could use your compiler because you'd have a > similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c > reference :). I use GNU PASCAL under unix and think that portability is a major asset of this compiler (and the fact it runs under solaris unix too!). What is needed is Pascal units with declarations translating the C include file definitions of system structures and the like. The problem is when we do them they are system specific (platform and OS) e.g. sockets programming under Solaris. Regards, Clyde

1 0

GNU Pascal: pascal library
by Iron Helix 07 Nov '98

07 Nov '98

An interesting project...Well anyways, I'm a programmer that knows cross-processor asm, C, C++, VC++, VB, Basic (eww), Euphoria (the predecessor to C (and Pascal?)), and am learning Pascal. Anyways, I noticed how GNU Pascal is lacking a standard Pascallian library, and am interested in writing it. I would do so in DGJPP C (not C++: too hard to interface with pascal (i think)), NASM assembly, and possibly something else...however, I would need a few things first: 1) your approval 2) A standard (borland or watcom or something) Pascal library reference (or one of each type to write multiple libraries :), with descriptions of what each does etc. 3) A knowledge of how GNU Pascal calling convention works: (it should interface nicely with DJGPP-C type, right?), offsets that function paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), etc. 4) A quick reference of GNU Pascal supported pointer types (far, near, huge), supported data types, how structures are setup 5) A reference of how the filetypes in the libraries are setup If given the above, I would write a full-featured library for use with GNU Pascal (or, at least, get pretty darn close :) that would be almost 100% compatible with normal Pascal libraries, and I would also maintain it, too :) Yes, I realize that this may be a huge task (how long did it take them to write the DJGPP2 libc? :), and that it would take a little while, but hey, it sounds interesting :) and you could take that little 'con' out of the cons section. In addition, non-C (but Pascal) programmers could use your compiler because you'd have a similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c reference :). NOTE: Just in case I wasn't clear, what I meant by writing a "standard Pascal lib" is writing the lib that is to Pascal as libc is to DJGPP :) Oh, and on the side, wouldn't it be an interesting thing to write a GNU Basic compiler that was _FAST_, had unsigned numbers, had more needed functions that aren't able to be made/used (i.e. an 'asm'-like command ;), used pointers, and some more stuff like being almost completely compatible with existing QBASIC programs and compiler-commands (i.e. '#include') and some more stuff? If you guys would want to do the lex. analyzer/compiler/etc. part, I'd write the library that would be the _FAST_ version of the normal BASIC lib...we could help BASIC programmers out there do alot better :) even tho it still wouldn't be as good as C... Anyways, thanx for your time. -Iron Helix ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: Automake
by Frank Heckenbach 06 Nov '98

06 Nov '98

Peter Gerwinski wrote: > > A library for gpi's would be nice? > > Any suggestion how this could be implemented? I suppose it could be done with `ar', just like with object libraries. However, I'm not sure if this will be really very important, once GPC has better automake and doesn't try to recompile unnecessarily. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 binary for DJGPP
by Frank Heckenbach 06 Nov '98

06 Nov '98

Hi, folks! A binary distribution of gpc-19980830 for DJGPP has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-19980830.i386-djgppv201.zip Greetings, Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Automake
by Thamm, Russell 06 Nov '98

06 Nov '98

I am having so much trouble with automake that I am considering abandoning GPC altogether. Everytime that I add a few more modules to my program, I have to spend several hours reorganizing units in order to get the program to compile. The only solution seems to be to combine all units into one giant unit. This is not really satisfactory. I keep running out of virtual memory on a machine with 256 MBytes of memory. My concern is that eventually my program will grow to a point where I won't be able to compile it at all. Or that compilation takes so long that development becomes impossible. Currently, the code only implements part of the GUI. Using a makefile is much better. I am not absolutely sure how to express the dependencies. Make seems to have no concept of a compilation producing more than one output file. I can get RHIDE to bypass automake by not specifying a primary file and adding all source files to the project. But Rhide apparently ignores the Uses clauses when determining dependencies and I ca't work out how to use user-defined dependencies with it. Does anyone know how I can use Rhide and avoid automake? Alternatively, is there some other solutions - A library for gpi's would be nice? Any options to indicate to automake that certain units don't need to be checked? I suspect that if automake kept track of the units not requiring compilation, things might improve.things. That is, the first time it checks grx20.pas, it should note that no recompilation is required rather than rechecking the same file many times. I'd be grateful for any advice. Russell Thamm

2 1

Another enumeration question
by Jo Dillon 05 Nov '98

05 Nov '98

Ok, I got it wrong with my previous question about enumerations, but what about this: (file babyunit2) unit babyunit2; interface type MyType = (a,b,c); implementation end. (file babyunit) unit babyunit; interface uses babyunit2; procedure printmytype(b : mytype); implementation procedure printmytype(b : mytype); begin writeln(ord(b)); end; end. (file baby) program baby; uses babyunit,babyunit2; var x : mytype; begin for x:=a to c do printmytype(x); end. [root@twentyfour aargh]# gpc -g -c -w babyunit2.pas [root@twentyfour aargh]# gpc -g -c -w babyunit.pas [root@twentyfour aargh]# gpc baby.pas babyunit2.o babyunit.o -o baby baby.pas: In function `program_Baby': baby.pas:19: incompatible type for argument 1 of `Printmytype' However, when I combine all three files like this: program baby; type MyType = (a,b,c); procedure printmytype(b : mytype); begin writeln(ord(b)); end; var x : mytype; begin for x:=a to c do printmytype(x); end. Everything works fine. Surely this has to be a compiler problem? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 3

Re: Another enumeration question
by Frank Heckenbach 05 Nov '98

05 Nov '98

Jo Dillon wrote: > Ok, I got it wrong with my previous question about enumerations, > but what about this: > > (file babyunit2) > [...] Yes, this seems to be the same bug as in russell2.pas, but I added your program to the test suite, anyway. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Tests
by Miklos Cserzo 05 Nov '98

05 Nov '98

Hi Folks, I am testing the 0830 alpha distribution on different systems. The compilation is OK but the a number of sample codes in p/test are failed. Is there a system where ALL the tests are OK? Cheers, miklos

2 1

GPC enumerations bug?
by Jo Dillon 05 Nov '98

05 Nov '98

Hi, I have a small test program which doesn't compile: (file babyunit.pas) unit babyunit; interface type bug=(beetle, ant); procedure printbug(b : bug); implementation procedure printbug(b : bug); begin case b of beetle : writeln('beetle'); ant : writeln('ant') end end; end. (file baby.pas) program baby; uses babyunit; var lp : bug; type insect=(beetle, ant); begin {for lp:=bug(beetle) to bug(ant) do} { this compiles! } for lp:=beetle to ant do printbug(lp); end. Compiler error: gpc -g -c -w babyunit.pas gpc -g -c -w baby.pas baby.pas: In function `program_Baby': baby.pas:10: incompatible types in assignment It looks to be a problem with having the same identifier used in two enumerations; if those two enumerations are in the same unit a more informative error message results, such as: baby.pas:7: conflicting types for `Beetle' baby.pas:6: previous declaration of `Beetle' baby.pas:7: conflicting types for `Ant' baby.pas:6: previous declaration of `Ant' baby.pas: In function `program_Baby': baby.pas:11: incompatible types in assignment (when type foo=(beetle,ant); is added immediately after type insect in baby.pas). This is the most recent gpc beta snapshot compiled against the gcc 2.8.1 backend on intel/linux. Any ideas? Is this a compiler bug? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 1

libgcc.a
by Thamm, Russell 05 Nov '98

05 Nov '98

I always wondered why the GPC distribution contained a different libgcc.a than the GCC distribution. I assumed that the GPC version had some extra stuff in it. However, it appears that the latest GPC version is incompatible with GNU C++. I've just spent all morning trying to make the GAWS package. Every time I tried to make any examples, I got heaps of linker errors. Eventually, in desparation, I replaced libgcc.a with the copy in GCC281b.ZIP. Suddenly all my linker errors dissappeared. I also note that the libgcc.a in the latest beta version of GPC is considerably shorter than the ones in previous versions. So what is the story with the GPC version of libgcc.a? thanks Russell BTW. I'm finally subscribed to this mailing list.

3 3

compiling grx20.pas
by Robert P. Ewing 04 Nov '98

04 Nov '98

Hi, all. I'm having trouble getting the grx20.pas unit to compile. If I just do a compile (gpc -g-c grx20.pas -o grx20.o), there are no errors. But when I attempt to Make it (this is in RHIDE), I see: compiling: c:\gpc\pascal\grx20.pas crt0.s: undefined reference to 'main' crt1.c: undefined reference to 'main' there were some errors Now I can't find any crt0.s or crt1.c files anywhere on the hard drive, so I don't think that's the problem... Is this a compiler bug, or can I get around it by changing some compiler flags or a few lines in the code? By the way, I'm using RHIDE 1.4, and the new beta gpc binary downloaded just a month ago. Any help would be appreciated. Toby Ewing ewing(a)iastate.edu

2 1

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 02 Nov '98

02 Nov '98

Kevin A. Foss wrote: > Yes, it is hard to say what would be "correct" for the system. The C > standard however does require a minimum of 32767, so setting it to that > should be safe or you could even set it to INT_MAX I suppose (which > -should- be defined in limits.h.) Not in general. Under Solaris, INT_MAX is $7fffffff, but RAND_MAX is only 32767. But when you say 32767 is the required minimum, I can use that if RAND_MAX isn't defined. This gives 15 random bits with one rand() call, so a 64 bit random number requires 5 rand() calls which is at least not *terribly* inefficient... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Kevin A. Foss 01 Nov '98

01 Nov '98

On Sun, 1 Nov 1998 18:30:46 +0100, Frank Heckenbach wrote: >Harald A. Irmer wrote: >> 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my >> purpose #define RAND_MAX 32767 > >Hmmm... according to my rand() manpage, it's part of ISO, but anyway... The problem here stems from the fact that SunOS does not normally come with an ANSI C compiler. (I ran into these problems several years ago back when I used a SunOS in college -- although not with gpc which I never tried as Sun's Pascal compiler isn't too bad.) On some systems there are compliant headers in /usr/5include but not in /usr/include. Basically the latter is for the "BSD environment" [icky.] and the former is for the "SysV environment" [the ANSI C we all love.] Unfortunately I never played around enough to figure out how to get SysV as the default :( The original poster put "BSD" in the header so if he wants that environment he should be prepared for the problem that this is going to cause trying to compile ANSI C code. To be honest I thought gcc came with scripts to 'fix' the SunOS headers -- but I don't have a source tree handy to check the READMEs. A Sun FAQ I found on dejanews recommends running 'fixincludes' after installing GCC but that is with the precompiled binaries. >Or to say it differently: how do you know that 32767 is correct for >SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or >is it written in some header in some way? Yes, it is hard to say what would be "correct" for the system. The C standard however does require a minimum of 32767, so setting it to that should be safe or you could even set it to INT_MAX I suppose (which -should- be defined in limits.h.) -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 01 Nov '98

01 Nov '98

Harald A. Irmer wrote: > 2.`memmove' in run-time-system is Sys5ish, replace by memcpy (in memory.h), at > least please set conditions, #ifdef Sys5 memmove ... > memmove is in GNU C++ The run time system already uses memcpy, not memmove (memmove was still mentioned in a comment and a #define, but it wasn't used anymore, so I removed it). memmove is used in rts.c which is actually part of the compiler, not the RTS, for the Move function. But using memcpy here would be wrong, because according to the memcpy manpage, the source and destination areas may not overlap, but they may overlap for Move. So, I implemented _p_move in rts/move.pas. Peter, can you use that in rts.c instead of memmove? > 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my > purpose #define RAND_MAX 32767 Hmmm... according to my rand() manpage, it's part of ISO, but anyway... I inserted: #ifndef RAND_MAX #define RAND_MAX 32767 #endif But is that safe? I'm applying a modulo (RAND_MAX + 1) to the numbers returned by rand(), so it wouldn't hurt much if RAND_MAX is chosen too small. (Theoretically I could set it to 1, to be safe, but that would be quite inefficient, because then rand() would be called for every bit needed.) Or to say it differently: how do you know that 32767 is correct for SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or is it written in some header in some way? Peter Gerwinski wrote: > > 5.p/gpi-hash.c needs <sys/stdtypes.h> (size_t) > > I do not have <sys/stdtypes.h> here (under Linux). Is there any > portable way to include it? (AutoConf experts around here?) Perhaps <sys/stdtypes.h> is included in some other, more common, system header in SunOS, so we can include that one? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

date format problem with GPC 19980830
by Harald A. Irmer 31 Oct '98

31 Oct '98

hi folks, the main Makefile contains a date command option SunOs does not understand: (neither /bin/date nor /5bin/date) p/gpc_date: date '+%h %e %Y' > $@ gives: date '+%h %e %Y' > p/gpc_date date: bad format character - e make: *** [p/gpc_date] Error 64 (found out what was meant by using DEC Unix 4.0d and correct it in my version, - I'll send a patch later) Yours, Harald A. Irmer / hirmer(a)gwdg.de Biomed. NMR-Forschungs GmbH am MPI f"ur biophys. Chemie Am Fa"sberg 11 / D-37077 G"ottingen Tel. +49-551-201-1042 / Fax +49-551-201-1307

2 2

Unsubscribe
by George C. Jackson III 31 Oct '98

31 Oct '98

I keep sending requests to gpc-request(a)hut.fi but to no avail. Please unsubscribe me from the list ..thanks. csgcj(a)olemiss.edu ------------------------------------------------------------------ George C. Jackson Systems Programmer III csgcj(a)olemiss.edu University of Mississippi Powers Hall 317 (601) 232-1075 ------------------------------------------------------------------

1 0

small omissions in GPC 971001
by Harald A. Irmer 29 Oct '98

29 Oct '98

hi folks, the last version of GPC I could get was 971001. It did not compile with Sun cc (SunOs 4.1.4/sun4m) Had to write: make *CC=gcc* LANGUAGES=pascal `SEEK_SET' was unknown in gpc-lex.c: #include <unistd.d> `size_t' was unknown in gpi-hash.h: #include <sys/stdtypes.h> Yours, Harald Artur Irmer Harald A. Irmer / hirmer(a)gwdg.de Biomed. NMR-Forschungs GmbH am MPI f"ur biophys. Chemie Am Fa"sberg 11 / D-37077 G"ottingen Tel. +49-551-201-1042 / Fax +49-551-201-1307

2 1

Re: More GPC bugs ???
by Frank Heckenbach 27 Oct '98

27 Oct '98

Thamm, Russell wrote: > The three following files show two apparent bugs: > > 1) The compiler seems to get confused between a standard procedure and an > object > method with the same name. Yes, that's true. I came across this problem as well recently. > 2) Types declared in other units are still problematical. Comment out > procedure aaa > in unit 1. Now the main program fails to compile: > > Error Incompatible type for argument 2 of Twoobj_Bbb. Hmpf... this problem was fixed for schema, pointer and record types, but apparently not for enum types. :-( I added it to the bug list. Anyway, Peter is working on a new GPI format which will hopefully get rid of this kind of bugs (there are a few more of them) altogether... > I can't even seem to find a workaround for this (apart from abandoning the > user-defined type). Perhaps some type-casting to Integer and back will help, but it's not nice... Perhaps it's better, until the bug is fixed, to turn the enum type into an integer: type RRtype = Integer; const rr_one = 0; rr_two = 1; ... Not very nice, either, but then there's ugliness only in one place -- but of course, you lose some degree of type-safety... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

More GPC bugs ???
by Thamm, Russell 26 Oct '98

26 Oct '98

The three following files show two apparent bugs: 1) The compiler seems to get confused between a standard procedure and an object method with the same name. In unit 1, the compiler confuses OneObj.aaa with aaa. So unit two fails to compile: Error Too many arguments to function Oneobj_Aaa. If I comment out the procedure declaration for aaa, the compiler error disappears too. 2) Types declared in other units are still problematical. Comment out procedure aaa in unit 1. Now the main program fails to compile: Error Incompatible type for argument 2 of Twoobj_Bbb. I can't even seem to find a workaround for this (apart from abandoning the user-defined type). I am using the latest BETA. (30/08/98). Russell Thamm {--------------------------------------------------------------------------- -------------------------------} Unit one; INTERFACE TYPE RRtype = (rr_one,rr_two,rr_three,rr_four); OneObj = OBJECT a : Integer; procedure aaa(r : RRType); end; procedure aaa; IMPLEMENTATION procedure OneObj.aaa(r : RRType); begin end; procedure aaa; begin end; END. {--------------------------------------------} unit two; interface uses one; type TwoObj = OBJECT MyOne : OneObj; procedure bbb(r : RRType); end; implementation procedure TwoObj.bbb(r : RRtype); begin MyOne.aaa(r); end; end. {-----------------------------------------------------------------} program crap; uses one,two; var MyTwo : TwoObj; begin MyTwo.bbb(rr_one); end.

1 0

subscribe
by Nicholas Geovanis 19 Oct '98

19 Oct '98

subscribe hello Please subscribe me to the Gnu Pascal mailing list. Thanks. <---------------------------------------------------------------------------> "I believe that we are in the most serious | Nick Geovanis financial crisis since World War II." | IT Computing Svcs -- William McDonough, President | Northwestern Univ New York Federal Reserve Bank, 10/6/98 V n-geovanis(a)nwu.edu

1 0

where do I get gnu pascal?
by Hamish Short 18 Oct '98

18 Oct '98

I hae been trying to get gpc for installation on a Sun solaris system here in Marseille for our students. Unfortunately kampi is not responding to ping, and there is no other computer I can find withh gpc on it... the machine sunsite.ic.ac.uk does not have gpc in the advertised directory gnu/pascal. Is there a problem here? best wishes hamish short

3 2

[Q] about error message...
by wrkim 16 Oct '98

16 Oct '98

Hi. After install GPC(GNU Pascal Compiler), When run gpc, I get error message . My system environment is sparc-solaris-2.5.1 and gcc-2.7.2.1. Error message :: gpc:Internal compiler error:program gpc-cpp got fatal signal 4 ************************************************************************* Dongguk Uni. Computer Science Email :: wrkim(a)wonhyo.dongguk.ac.kr Name :: Kim Mi Young Homepage::http://wwwcs.dongguk.ac.kr/~wrkim *************************************************************************

2 1

Help: make
by dang hai 15 Oct '98

15 Oct '98

Would you help me with the error below. Thanks in advance Minh sh ./move-if-change tmp-gpc-parse.h ./gpc-parse.h ./gpc-parse.h is unchanged cc -c -DGPC -DIN_GCC -g -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 -I../gcc-2. 7.2.1/config gpc-parse.c cc -c -DGPC -DIN_GCC -g -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 -I../gcc-2. 7.2.1/config gpc-decl.c cc: Error: gpc-decl.c, line 2962: In this statement, "((enum tree_code)(((tail)- >list.value))->common.code)" is not an lvalue, but occurs in a context that requ ires one. TREE_CODE (TREE_VALUE (tail)) = code; ----------------^ make: *** [gpc-decl.o] Error 1 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Help: make
by dang hai 15 Oct '98

15 Oct '98

Would you help me with the error below. Thanks in advance Minh sh ./move-if-change tmp-gpc-parse.h ./gpc-parse.h ./gpc-parse.h is unchanged cc -c -DGPC -DIN_GCC -g -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 -I../gcc-2. 7.2.1/config gpc-parse.c cc -c -DGPC -DIN_GCC -g -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 -I../gcc-2. 7.2.1/config gpc-decl.c cc: Error: gpc-decl.c, line 2962: In this statement, "((enum tree_code)(((tail)- >list.value))->common.code)" is not an lvalue, but occurs in a context that requ ires one. TREE_CODE (TREE_VALUE (tail)) = code; ----------------^ make: *** [gpc-decl.o] Error 1 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Configure problem
by minh.h.cao＠boeing.com 14 Oct '98

14 Oct '98

Hi, When I run make to build pascal 2.0, I get the following error. Would you help me on this ? Thanks in advance. cc -DGPC -DIN_GCC -g -o gpc gcc.o gpc-version.o ../gcc-2.7.2.1/obstack.o `if [ -f "../gcc-2.7.2.1/alloca.o" ]; then echo "../gcc-2.7.2.1/alloca.o" ; else true ; fi` `if [ -f "../gcc-2.7.2.1/mall.c cc: Error: gpc-decl.c, line 2962: In this statement, "((enum tree_code)(((tail)->list.value))->common.code)" is not an lvalue, but occurs in a context that requires one. TREE_CODE (TREE_VALUE (tail)) = code; ----------------^ *** Exit 1 Stop. ----------------------------------------------------------------------- Another thing I see when run ./configure is not the same with a example from install note. Compiler for GPC: cc My showing cc not gcc. Is this a problem ? -------------------------------------------------------------------------- Configuration summary: Building a native alpha-dec-osf4.0 compiler GPC sources in: . GCC sources in: ../gcc-2.7.2.1 GCC object code in: ../gcc-2.7.2.1 GCC version: 2.7.2.1 Compiler for GPC: cc Compiler for libgpc.a: ../gcc-2.7.2.1/xgcc -B../gcc-2.7.2.1/ Compiler flags: -g Installation path: /usr/local/bin, /usr/local/lib/gcc-lib/alpha-dec-osf4.0/2.7.2.1 -------------------------------------------------------------------------- Now, type "make" to build the compiler and runtime system.

2 1

Re: External references
by Frank Heckenbach 14 Oct '98

14 Oct '98

Peter Gerwinski wrote: > > Yes, I think that's this problem. If you compile a unit with `-S', > > you'll find that global variables in the implementation > > ... where it _must_ be like this ... (* Why? *) > > (as well as global variables in a program) > > ... where we should discuss about ... > > > are `local' instead of `global' or `comm'. > > Global variables of the program must be in the data (and not in > the stack) segment in order to circumvent limitations of the > stack size. Normally, there is no need to make them visible to > the linker because programs cannot be "used" (imported) by > other Pascal programs, modules, or units. (In C, such > variables are declared `static'.) > > If you want to make a global variable of the program visible to > the linker (and thus to external assembler routines), you can > use the following trick: > > Program Test; > > Var > Foo: external Integer; > Foo: Integer; > > begin > end. > > This produces a `comm' variable without `local'. > > The first declaration of `Foo' tells the compiler that there > is some external integer variable `Foo'. The second one > allocates storage for this variable, remembering that it must > be accessible from the external world. > > Okay like this? I think so, for the following reason: when GPC will get qualified identifiers and/or function overloading, the translation Pascal identifier -> asmname can't be as simple as it is now. Therefore, it's not wrong to get used to do special declarations for variables one wants to use externally. What I find strange is the `external' in the example and having to repeat the declaration -- though I understand why it is currently necessary. I think in the long run, we should think of a better syntax for that. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

unresolved references in libgpc.a
by Bernd Kurzan E1 14 Oct '98

14 Oct '98

Hello! After applying the new patch to the gcc-2.8.1 source code the gpc-19980830 compiler is now built by gcc-2.8.1 without any errors. When compiling the Pascal-programs in the "test" directory, however, most of the programs cannot be correctly compiled by gpc, because there are apparently some unresolved references in libgpc.a (see below an excerpt from the screen!). Is there a parameter file missing? Bernd =============================== typical error messages: /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(write.o): In function `_p_write': /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:123: undefined reference to `_p_strlen' /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:124: undefined reference to `_p_strlen' /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:138: undefined reference to `_p_strlen' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(file.o): In function `_p_nameit': /usr/local/src/gcc-2.8.1/p/rts/file.c:204: undefined reference to `_p_strlen' /usr/local/src/gcc-2.8.1/p/rts/file.c:218: undefined reference to `_p_strlen' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(rtsstr.o): In function `Upcasestring': /usr/local/src/gcc-2.8.1/p/rts/rtsstr.pas:109: undefined reference to `_p_gpc_upcase' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(rtsstr.o): In function `Locasestring': /usr/local/src/gcc-2.8.1/p/rts/rtsstr.pas:115: undefined reference to `_p_gpc_locase' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(rtsstr.o): In function `Strdup': /usr/local/src/gcc-2.8.1/p/rts/rtsstr.pas:206: undefined reference to `_p_strlen' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(string.o): In function `_p_writestr': /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:123: undefined reference to `_p_strlen' /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:124: undefined reference to `_p_strlen' /usr/local/src/gcc-2.8.1/p/rts/wrtinc.c:138: undefined reference to `_p_strlen' /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/libgpc.a(string.o): In function `_p_readstr': /usr/local/src/gcc-2.8.1/p/rts/string.c:521: undefined reference to `_p_strlen' =========================================

2 1

Re: External references (Was: Code Gen Prob -- Retraction...)...
by Frank Heckenbach 13 Oct '98

13 Oct '98

Orlando Llanes wrote: > On Mon, 12 Oct 1998, Frank Heckenbach wrote: > > This seems to be a bug in fact. They are declared "local" in the > > assembler output (or shouldn't they be global for some reason, Peter?). > > I meant at a low level within the unit. In my example, a variable was > declared in the unit, and another variable declared in the asm file. The > unit had access to the asm's variables, but not vice versa. Yes, I think that's this problem. If you compile a unit with `-S', you'll find that global variables in the implementation (as well as global variables in a program) are `local' instead of `global' or `comm'. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: argc/argv?
by Frank Heckenbach 13 Oct '98

13 Oct '98

Jo Dillon wrote: > Just a quick question - how do I get access to command-line parameters > from gpc? (I.e. the equivalent of main(argc,argv)) I looked through the info > documentation and couldn't find anything. ParamCount and ParamStr(n). Note, ParamCount does not include the 0th argument (program name), unlike argc. (However, ParamStr(0) does return it.) You are using a newer GPC than 2.0, aren't you? (2.0 did not have those functions. They were added sometime in 1997.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

argc/argv?
by Jo Dillon 13 Oct '98

13 Oct '98

Just a quick question - how do I get access to command-line parameters from gpc? (I.e. the equivalent of main(argc,argv)) I looked through the info documentation and couldn't find anything. -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 1

re:libgtk-use
by Mike Neuhaus 13 Oct '98

13 Oct '98

The problem is - gtk has no list of "extern" - definitions in one(!) file in the header - directory... and the link-process of libgtk needs many compiler-commandline-switches (...or use of gtkconfig). In libtk8.0 is this no problem. One (!) extern-list and simple link-process. Bud gtk has more from the good look and feel of free dynamic software. -- http://ekim.home.pages.de Mike Neuhaus ********PRO Heimerziehung heißt PRO Zukunft********** Die Heimerziehung bedarf nicht ihrer eigenen Abschaffung,sondern einer durch Innovation geprägten Reform

2 1

Re: Code Gen Prob -- Retraction...
by Frank Heckenbach 12 Oct '98

12 Oct '98

Orlando Llanes wrote: > There is one thing tho, it seems > that variables declared within the program are not properly exported > outside of the source module. I attatched a simple example program to show > what I mean. This seems to be a bug in fact. They are declared "local" in the assembler output (or shouldn't they be global for some reason, Peter?). The following program can even test this in Pascal. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan program orland2; uses orland2u; var bar : string (10); begin bar := 'failed'; baz; writeln (bar) end. unit orland2u; interface procedure baz; implementation var bar : external string(10); procedure baz; begin bar := 'OK' end; end.

3 2

libgtk-use in gpc-pascal-programs under linux
by Mike Neuhaus 11 Oct '98

11 Oct '98

Hallo,...... ......i want to use the libgtk for my gpc-pascal-programs. for this i search an unit/module, that implements the gtk-library. Who can help me? thanks and cu Mike -- http://ekim.home.pages.de Mike Neuhaus ********PRO Heimerziehung heit PRO Zukunft********** Die Heimerziehung bedarf nicht ihrer eigenen Abschaffung,sondern einer durch Innovation geprgten Reform m

2 1

Re: Code Gen Prob -- Retraction...
by Frank Heckenbach 11 Oct '98

11 Oct '98

Orlando Llanes wrote: > Before I begin, the reason I didn't notice this at first is because > the previous version of GPC compiled my program without a problem despite > the following... I use external assembly routines that access variables > declared in a Pascal unit (the assembler doesn't matter, it happens with > both AS and NASM). To declare the variables defined in the Pascal unit, I > declared them "common". Then I changed all "common" references to global > references and added declarations in the .data section and the program no > longer crashed. Weird. Fine to hear so. However, did you find out what the previous GPC did differently so the problem did not occur? If you still have that version installed, can you compare the -S output of the previous and the current GPC version to see what's different? (Just to be sure it really isn't a code generation problem...) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 2

Code Gen Prob -- Retraction...
by Orlando Llanes 10 Oct '98

10 Oct '98

Argh! I can't believe how extremely simple the mistake was!!! A while back I reported that my program crashed after compiling with the latest version of GPC. I finally figured out why! Before I begin, the reason I didn't notice this at first is because the previous version of GPC compiled my program without a problem despite the following... I use external assembly routines that access variables declared in a Pascal unit (the assembler doesn't matter, it happens with both AS and NASM). To declare the variables defined in the Pascal unit, I declared them "common". Then I changed all "common" references to global references and added declarations in the .data section and the program no longer crashed. Weird. Thanks for your help Frank! 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

1 0

RE: gnu-pascal compiler for Delphi?
by Andreas Prucha [helicon] 10 Oct '98

10 Oct '98

>Delphi is basically a Windows-version of Pascal. Made also by borland, >it should work. The last text version of Pascal from Borland that I hvae >is7.0 which was object oriented, and pre-windows. Delphi came out as the >next version. Yep, but Delphi's Object Pascal has a lot of extensions over TP7. For example a redesigned class-model with RTTI and properties, exception handling and so on. Thus, the usual Delphi program won't compile on TP7-compatible compiler. Delphi got a lot of extension. Andreas

3 2

Re:
by Alec Cawley 09 Oct '98

09 Oct '98

In article <907967940.209538.0(a)tvweb1.hiway.co.uk>, writes >Andreas Prucha [helicon] wrote: >> >> Yep, but Delphi's Object Pascal has a lot of extensions over TP7. For >> example a redesigned class-model with RTTI and properties, [...] > >RTTI? What's that? ?Run Time Type Identification? -- Alec Cawley

1 0

gnu-pascal compiler for Delphi?
by Thomas Keller 09 Oct '98

09 Oct '98

Hi there I have problem with my Delphi application. I want to compile it under Linux. Do you know if gnu-pascal supports the Delphi language? Or exist any other ways to translate it first to C or Pascal? Thanks for your help Regards Thomas

3 2

success: newbi-problem
by Mike Neuhaus 08 Oct '98

08 Oct '98

thanks for the Tip. The libc6 - version of the gpc works fine on my debian2.0. cu -- http://ekim.home.pages.de Mike Neuhaus ********PRO Heimerziehung heißt PRO Zukunft********** Die Heimerziehung bedarf nicht ihrer eigenen Abschaffung,sondern einer durch Innovation geprägten Reform

1 0

I want to subscribe. Help
by Alfredo Cesar Fontana 08 Oct '98

08 Oct '98

Hello there, I want to subscribe this mailing list. I program in Turbo Pascal 7.0. I met DJGPP, and then the GPC 2.0(2.7.2.1). I want to migrate there. But I have some problems. Also, I can contribute, if it is posible. I want to know how to meet people who are in similar situation. Sorry my english is poor. Thanks. Alfredo Buenos Aires ARGENTINA

1 0

Re: ref string bug
by Frank Heckenbach 08 Oct '98

08 Oct '98

Russ Whitaker wrote: > tried program by Jo Dillon > > changing the function GetMem to the procedure GetMem makes the problem go > away > > why i don't know (* See my previous mail for the description of the problem. *) When using the GetMem procedure, GPC seems to initialize the Capacity field. However, this is a misfeature, and needs to be turned off! Sorry if that's unpopular, but here's the reason why: when the record contains a string (or any schema) in any position but the first, and the size requested from GetMem is smaller than the size of the fields before, the discriminants (here: Capacity) will be outside the allocated space, and must not be written to. The following version of the program demonstrates the problem. It will just allocate enough space for the first string (s), which would be sufficient for what the program does here. However, GPC's trying to initialize t and u will go outside the allocated memory -- I increased the size of the strings here, so that this will most likely result in a segfault. program baby; type BigString = String(200000); type trec = record s, t, u : bigstring; end; prec = ^trec; var r : prec; begin GetMem(r, sizeof(bigstring)); r^.s := 'OK'; writeln (r^.s) end. The bottom line here is that GetMem (as well as FillChar, for that matter) are low-level routines, and mixing them with (high-level) Pascal objects like schemata (e.g. Strings) or files, requires precise understanding of the internals, is non-portable (between compilers as well as between architectures) and should be avoided (here: by using New) whenever possible. It might even be worthwhile to think about disabling GetMem etc. by default to protect against such bugs, and enabling them only with a special switch (something like a "weaker `--extended-syntax'") and, of course, in `--borland-pascal'. Now the good news as far as strings are concerned: BP compatible "short strings" are on the To-Do list, and when they will have been implemented, whenever this will be, such things like GetMem, even `GetMem (StringPtr, Length (StringVal) + 1); StringPtr^ := StringVal', FillChar, or accessing `StringVar [0]' to get and/or modify their length, will work with short strings, as they won't have a Capacity field. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: String assignment bug?
by Frank Heckenbach 07 Oct '98

07 Oct '98

Jo Dillon wrote: > Hi, I think I've found a bug in the latest beta snapshot of gpc > (linked against gcc 2.8.1). Basically, when assigning one string > to another the result seems to be a null string. A program that isolates > the bug is included below: No, it's not a GPC bug. The problem is the following line in your code: > r:=GetMem(sizeof(trec)); A (Pascal) string is a schema record type which has, besides the Length and the actual characters, a Capacity field which contains the maximum length of the string. When you declare a global or local string variable, or allocate a string via `New', the compiler will automatically set this field to the correct value. However, when you allocate the memory via `GetMem', the compiler does not know that there will be a string in the allocated memory, so it can't set the Capacity. Therefore, Capacity will contain the value that just happens to be in that memory location, in this case probably 0. So, the string will have a capacity of 0, i.e. it can't get longer than 0 chars. To solve the problem, you could either set the Capacity manually (`r^.s.Capacity := 200;') -- but that's quite error-prone -- or just use `New(r);' instead of the GetMem statement -- which is IMHO easier and safer, anyway. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

ref string bug
by Russ Whitaker 07 Oct '98

07 Oct '98

tried program by Jo Dillon changing the function GetMem to the procedure GetMem makes the problem go away why i don't know thanks Russ

1 0

String bug?
by Jo Dillon 07 Oct '98

07 Oct '98

Hi, I think I've found a bug in the latest beta snapshot of gpc (linked against gcc 2.8.1). Basically, when assigning one string to another the result seems to be a null string. A program that isolates the bug is included below: program baby; type BigString = String[200]; type trec = record s : bigstring; a : integer; end; prec = ^trec; var r : prec; b : BigString; begin {memmanagerinit(10);} b:='Hello world'; r:=GetMem(sizeof(trec)); r^.s:=b; r^.a:=1245; WriteLn(r^.a); write('Message '); writeln(r^.s); writeln('String ',b); end. -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

1 0

Re: Fw: success
by Frank Heckenbach 07 Oct '98

07 Oct '98

Russ Whitaker wrote: > following reported as returned > Thanks (It did arrive the first time.) > > ref gpc-19980830 in gcc-2.8.1 > > > > did a > > make clean > > make CFLAGS="-O2" LANGUAGES=pascal > > make CFLAGS="-O2" pascal.install > > now works ok Fine! :-) > > In /usr/local/bin: > > gpc 94012 bytes > > gpc-bad 186982 bytes > > gpc.old 171724 bytes > > where gpc.old is gpc-980511 in gcc-2.8.0 That's really a difference! :-) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Fw: success
by Russ Whitaker 07 Oct '98

07 Oct '98

following reported as returned Thanks ---------- > From: Russ Whitaker <russwhit(a)mind.net> > To: gpc(a)hut.fi > Subject: success > Date: Monday, October 05, 1998 2:33 PM > > ref gpc-19980830 in gcc-2.8.1 > > did a > make clean > make CFLAGS="-O2" LANGUAGES=pascal > make CFLAGS="-O2" pascal.install > now works ok > > In /usr/local/bin: > gpc 94012 bytes > gpc-bad 186982 bytes > gpc.old 171724 bytes > where gpc.old is gpc-980511 in gcc-2.8.0 > > Thanks > Russ > russwhit(a)mind.net

1 0

newbi-problem
by Mike Neuhaus 06 Oct '98

06 Oct '98

Hallo,... .....while compiling a simple test-program the gpc 2.0 gives no error messages. The start of the program results a "segmentation faults". I work on an debian 2.0. (x86, libc6 - system). As attachement you will find the simple test program. -- http://ekim.home.pages.de Mike Neuhaus ********PRO Heimerziehung heißt PRO Zukunft********** Die Heimerziehung bedarf nicht ihrer eigenen Abschaffung,sondern einer durch Innovation geprägten Reform

2 1

Beginner strange problem, please help!!!
by Grzegorz Zlotowicz 06 Oct '98

06 Oct '98

Hi all. At first, excuse me for my maybe lame and stupid question, but as mentioned above, i'm only beginner in DJGPP, but i'm fascinated by this software, and i would like to solve my problem... OK, let describe the problem: I've been downloaded following zips from djgpp: csdpmi4b CWSDPMI binary distribution (release 4) djdev201 Development Kit and Runtime bnu281b GNU binutils 2.8.1 for DJGPP V2 (binaries and docs) gdb416b GNU Debugger 4.16 for DJGPP V2 gpc20b GNU Pascal 2.0 for DJGPP V2 gpp281b.zip GNU C++ compiler version 2.8.1 (binaries), needs gcc281b.zip !! txi390b GNU texinfo 3.9 for DJGPP V2 I unpacked above files into previously created c:\djgpp directory, preserving directory structure. And this is what happened, when i run gpc: --- C:\DJGPP\TEST\STANDARD>gpc hello.pas Exiting due to signal SIGSEGV Stack Fault at eip=00118156 eax=00000000 ebx=00001008 ecx=00001008 edx=001900ef esi=00000054 edi=00000000 ebp=00000000 esp=133cb893 program=c:\djgpp\bin\GPC.EXE cs: sel=00e7 base=10080000 limit=0018ffff ds: sel=00ef base=10080000 limit=0018ffff es: sel=00ef base=10080000 limit=0018ffff fs: sel=00cf base=00036340 limit=0000ffff gs: sel=0000 ss: sel=00ef base=10080000 limit=0018ffff General Protection Fault at eip=3e82; flags=3006 eax=00000300 ebx=00000021 ecx=00000000 edx=0000000f esi=00060140 edi=0005eb50 ebp=0005e9ec esp=00002566 cs=18 ds=33 es=b7 fs=8f gs=bf ss=20 error=00ac C:\DJGPP\TEST\STANDARD> --- And this is my autoexec.bat and config.sys: ---<autoexec.bat>--- @echo off verify on set djgpp=c:\djgpp\djgpp.env PATH=C:\DOS\BATCH;C:\DOS;... set path=%path%;c:\djgpp\bin set tmp =c:\dos\temp ---<end-of-file>--- ---<config.sys>--- BUFFERS=40,8 FILES=25 ---<end-of-file>--- At this point, i tried to find problem solve in the general djgpp faq, and i tried using stubedit.exe on the gpc.exe: i changed original "min stack limit=0x40000" to "stacklimit=0x80000", but without effects. So my next step was to prepair this e-mail - maybe too early, sorry..., but it's my last possibility. So, if anybody can help, i'll be grateful... Please help!!! _Important_: Please reply or CCopy your replies to my e-mail - i'm not subscriber of gpc mailing list (no time and account space:-)). Thanks in advance. Greetings, Grzegorz Zlotowicz From Walbrzych in Poland... Send-reply-to: grzezlo(a)wanet.pl.

2 1

success
by Russ Whitaker 05 Oct '98

05 Oct '98

ref gpc-19980830 in gcc-2.8.1 did a make clean make CFLAGS="-O2" LANGUAGES=pascal make CFLAGS="-O2" pascal.install now works ok In /usr/local/bin: gpc 94012 bytes gpc-bad 186982 bytes gpc.old 171724 bytes where gpc.old is gpc-980511 in gcc-2.8.0 Thanks Russ russwhit(a)mind.net

1 0

Re: gpc-19980830 bug
by Frank Heckenbach 04 Oct '98

04 Oct '98

Russ Whitaker wrote: > gpc-199808 in gcc-2.8.1 now seems to compile and install correctly > > however when i tried to use it to compile the classic "Hello World" got a > whole slew of error messages: " undefined reference to '_p_strlen' " I think this is the problem Maurice Lombardi described recently. It's caused by the `inline's in rts/rtsstr.pas while compiling GPC without optimizations. Try commenting out these `inlines' and compiling GPC again -- or, better yet, compile GPC with optimizations, i.e. give `CFLAGS="-O2"' to the make command, this will result in a faster compiler, anyway. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 bug
by Russ Whitaker 04 Oct '98

04 Oct '98

gpc-199808 in gcc-2.8.1 now seems to compile and install correctly however when i tried to use it to compile the classic "Hello World" got a whole slew of error messages: " undefined reference to '_p_strlen' " gpc.old ( gpc-980511 in gcc-2.8.0 ) works ok Thanks Russ russwhit(a)mind.net

1 0

GPC doc
by Sergey Rostopchin 01 Oct '98

01 Oct '98

Hi, a lot of gpc documentation in http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc-doc.html Unfortunately we have a very slow link to Internet. Is there possible to get these html pages in "tar.gz" form? In that case I could put in on my computer and read without problem. Sergey Rostopchin

2 1

Is GPC object oriented?
by Sergey Rostopchin 01 Oct '98

01 Oct '98

Hi, I'm interested gnu pascal under unix (Solaris). The main question for me is the GPC support object oriented programing? With best wishes, Sergey Rostopchin

2 1

Re: gpc bug on HPUX
by Frank Heckenbach 30 Sep '98

30 Sep '98

S. Achterop IWI-120 3932 wrote: > Earlier I mailed a problem in compiling p/rts/filename.pas on HPUX 10.20 with egcs1.1b. > After a replay from Frank Heckenbach (thanks!) I reduced the file to the > following, and found a workaround. Does the following also fail? This would be in the format for out test suite, i.e. it writes 'OK' when it works: unit Sietse1u; interface const TStringSize = 2048; type TString = String (TStringSize); implementation end. program Sietse1; uses Sietse1u; function F : TString; begin F := 'OK' end; begin writeln (F) end. If it doesn't work on hpux, I'll put it into the test suite. > Removing the comment brackets makes the internal error go away. > The workaround of course is defining TString locally in the file filename.pas OK, I did this in the RTS for now. > Mayby this information helps to find the bug more easily. I hope so. Thanks for the information. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

compile error of gpc-19980830
by Bernd Kurzan E1 29 Sep '98

29 Sep '98

I installed the gcc-2.8.1 source tree and put the contents of the "p" directory of gpc-19980830 into the gcc-tree. Then I applied the patch, as given in the INSTALL file. After configuring with "configure --prefix=/usr" as suggested in "INSTALL" and "make LANGUAGES=pascal" the gcc-2.8.1 compiler starts to compile, but does not complete the full build. Instead it ends with the error message given below (screen dump). Is this a bug in the source code, or did I make a mistake? B. Kurzan ========================================================== gcc -c -DIN_GCC -DGPC -DUSE_GNULIBC_1 -g -Wall -I. -I.. -I. -I./.. -I./.. /config setop.c echo " ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute .o mkstemp.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-type ck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o set op.o version.o" >stamp-gpc1 rm -f ../gpc1 gcc -DIN_GCC -DGPC -DUSE_GNULIBC_1 -g -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-tem p.o ../pexecute.o mkstemp.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc -lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o typ es.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; e lse true; fi` `case "gcc" in "cc") if [ x != x ]; then echo ../; else true; fi ; ; esac` `if [ x != x ]; then echo ../; else true; fi` module.o: In function `execute': /usr/local/src/gcc-2.8.1/p/module.c:510: undefined reference to `version_flag' module.o: In function `module_must_be_recompiled': /usr/local/src/gcc-2.8.1/p/module.c:796: undefined reference to `version_flag' module.o: In function `compile_module': /usr/local/src/gcc-2.8.1/p/module.c:920: undefined reference to `version_flag' make[1]: *** [../gpc1] Error 1 make[1]: Leaving directory `/usr/local/src/gcc-2.8.1/p' make: *** [gpc1] Error 2 pentium:/usr/local/src/gcc-2.8.1#

2 1

gpc bug on HPUX
by S. Achterop IWI-120 3932 29 Sep '98

29 Sep '98

Hello, Earlier I mailed a problem in compiling p/rts/filename.pas on HPUX 10.20 with egcs1.1b. After a replay from Frank Heckenbach (thanks!) I reduced the file to the following, and found a workaround. ================================================ filename-fout.pas unit FileName; interface uses gpc; implementation { const TStringSize = 2048; type TString = String (TStringSize); } function F : TString; begin end; end. ================================================== This program (executed in the rts directory) yields the following error on HPUX10.20: filename-fout.pas: In function `F': filename-fout.pas:11: warning: return value of function not assigned filename-fout.pas:11: internal error--unrecognizable insn: (insn 13 12 15 (set (zero_extract:SI (reg:SI 94) (const_int 32) (const_int 0)) (reg:SI 95)) -1 (nil) (nil)) ../toplev.c:1378: Internal compiler error in function fatal_insn Removing the comment brackets makes the internal error go away. The workaround of course is defining TString locally in the file filename.pas Mayby this information helps to find the bug more easily. Sietse

1 0

Re: gpc and egcs-1.1b on Linux and HPUX10.20
by Frank Heckenbach 28 Sep '98

28 Sep '98

S. Achterop IWI-120 3932 wrote: > BUT on hpux10 the following PROBLEM occurs during COMPILING the runtime system: > > here last part of the output of the make command: > > [...] > > Anyone have a clue? The code in this file seems to be OK, so it must be a compiler problem. I added it to the To-Do list. Until it is fixed, you can comment out the offending routines. The routines in filename.pas are not vital for GPC. > P.S. the were also a few (probably non-relevant) warnings in the rts compilation: > write.c:199: warning: no previous prototype for `_p_write' > read.c:175: warning: no previous prototype for `_p_read' > string.c:193: warning: no previous prototype for `_p_string' > string.c:396: warning: no previous prototype for `_p_writestr' > string.c:511: warning: no previous prototype for `_p_readstr' Yes, they're non-relevant. Actually, they're about C functions with varargs, and I don't know how to create prototypes for them, so I can't fix them. If anyone knows how to, please go ahead. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc on Linux and HPUX10.20 (using egcs-1.1b)
by S. Achterop IWI-120 3932 28 Sep '98

28 Sep '98

L.S. When trying to create a binary for Linux and HPUX 10.20 of the latest gpc beta-release, using egcs-2.91.57 (19980901 (egcs-1.1 release)) I encountered the following problems. Using: ./configure --prefix=/opt/egcs --with-gnu-as --enable-shared (also without enable shared) and with both gcc version 2.7.2.3 or the egc-1.1 C-compiler On BOTH linux and hpux the file gcc/p/Makefile had to be changed to signal the use of egcs: Added -DEGCS to ALL_CFLAGS in Makefile With this change the Linux version works as advertised. BUT on hpux10 the following PROBLEM occurs during COMPILING the runtime system: here last part of the output of the make command: .... ../../xgpc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -O2 -I. -I../.. -I/wing3/home1/users/sietse/egcs-1.1b/gcc/p/rts/../.. -I/wing3/home1/users/sietse/egcs-1.1b/gcc/p/rts/../../config filename.pas filename.pas: In function `Slash2osdirseparator': filename.pas:180: internal error--unrecognizable insn: (insn 15 6 19 (set (zero_extract:SI (reg:SI 96) (const_int 32) (const_int 0)) (reg:SI 97)) -1 (insn_list 12 (insn_list 14 (nil))) (nil)) ../toplev.c:1378: Internal compiler error in function fatal_insn make[2]: *** [filename.o] Error 1 make[2]: Leaving directory `/wing3/home1/users/sietse/egcs-1.1b/gcc/p/rts' make[1]: *** [libgpc.a] Error 2 make[1]: Leaving directory `/wing3/home1/users/sietse/egcs-1.1b/gcc' make: *** [all-gcc] Error 2 Anyone have a clue? Sietse Achterop Computing Science Department University of Groningen The Netherlands P.S. the were also a few (probably non-relevant) warnings in the rts compilation: write.c:199: warning: no previous prototype for `_p_write' read.c:175: warning: no previous prototype for `_p_read' string.c:193: warning: no previous prototype for `_p_string' string.c:396: warning: no previous prototype for `_p_writestr' string.c:511: warning: no previous prototype for `_p_readstr'

1 0

Re: gpc-19980830 bug
by Frank Heckenbach 25 Sep '98

25 Sep '98

Maurice Lombardi wrote: > I have found a bug (at least an unwanted feature) in the last beta > (19980830), when trying to compile the file rtsstr.pas contained in the > distribution (directory p/rts). In this unit there are some inline > functions (e.g. Strlen). When compiled without any optimisation option > (-On), the function in simply not contained in the resulting rtsstr.o > file, and no error message nor warning is issued. With -O it works fine. > Of course it is somewhat contradictory to compile without optimisation > and to include explicit inline functions. But at least the inline > directive should be ignored in this case if this causes problems with > the compiler, and a warning issued. It seems to be the combination of "asmname" (in the interface) and "inline" that causes this problem. I've made a test suite program for it, and until it's solved, I'll comment out the "inline"s in rtsstr.pas. Thanks for the bug report. program maur3; procedure foo; asmname 'bar'; inline procedure foo; begin writeln('OK') end; begin foo end. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 bug
by Maurice Lombardi 25 Sep '98

25 Sep '98

Hi all I have found a bug (at least an unwanted feature) in the last beta (19980830), when trying to compile the file rtsstr.pas contained in the distribution (directory p/rts). In this unit there are some inline functions (e.g. Strlen). When compiled without any optimisation option (-On), the function in simply not contained in the resulting rtsstr.o file, and no error message nor warning is issued. With -O it works fine. Of course it is somewhat contradictory to compile without optimisation and to include explicit inline functions. But at least the inline directive should be ignored in this case if this causes problems with the compiler, and a warning issued. Hope this helps. -- 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

Re: beta didn't finish compiling
by Frank Heckenbach 25 Sep '98

25 Sep '98

Russ Whitaker wrote: > running slakware 3.5 on an i486. Liked gpc 2.0 so downloaded gpc-199808* > > [...] > > module.o: In function 'execute': > /usr/local/src/gcc-2.8.1/p/module.c: 510 undefined reference to > 'version_flag' > > [...] > > fix, please Yes, gpc-19980830 contains an incomplete file p/gcc-2.8.1.diff (which does some patches to the GCC sources). You can find a corrected file at: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/gcc-2.8.1.diff.gz After putting it in place, be sure to start with fresh GCC sources -- otherwise GPC will think GCC is alredy patched and not apply the correct patch. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

beta didn't finish compiling
by Russ Whitaker 25 Sep '98

25 Sep '98

running slakware 3.5 on an i486. Liked gpc 2.0 so downloaded gpc-199808* put gpc-2.8.1 in /usr/local/src and unpacked gpc. Moved p to gpc-2.8.1 ran patch -s -p1 < p/diffs/gcc-2.8.1.diff while in /usr/local/src/gpc-2.8.1 ran ../gcc-2.8.1/configure --prefix=/usr ( also tried --prefix=/usr/local with same end result ) ran make LANGUAGES=pascal after about 45 min program quit with following lines: module.o: In function 'execute': /usr/local/src/gcc-2.8.1/p/module.c: 510 undefined reference to 'version_flag' module.o: In function 'module_must_be_recompiled': /usr/local/src/gcc-2.8.1/p/module.c: 796 undefined reference to 'version_flag' module.o: In function 'compile_module': /usr/local/src/gcc-2.8.1/p/module.c: 920 undefined reference to 'version_flag' Collect2 ld returned 1 exit status make[1]: ***[../gpc1] Error 1 etc fix, please thank you, Russ email russwhit(a)mind.net

1 0

beta didn't finish compiling
by Russ Whitaker 24 Sep '98

24 Sep '98

running slakware 3.5 on an i486. liked gpc 2.0 so downloaded gpc-199808 * put gcc-2.8.1 in /usr/local/src from dist. disk unpacked gpc-199808* and moved p to gcc-2.8.1 ran patch -s -p1 < p/diffs/gcc-2.8.1.diff ( while in gcc-2.8.1 directory) ran ../gcc-2.8.1/configure --prefix=/usr ( got same end result using --prefix=/usr/local ) ran make LANGUAGES=pascal about 45 min later program stopped with these last lines: module.o: In function 'execute': /usr/local/src/gcc-2.8.1/p/module.c: 510 undefined reference to 'version_flag' module o: In function 'compile_module': /usr/local/src/gcc-2.8.1/p/module.c: 796 undefined reference to 'version_flag' module.o: In function 'compile_module': /usr/local/src/gcc-2.8.1/p/module.c 920 undefined reference to 'version_flag' Collect2: ld returned 1 exit status make[1]: ***[../gpc1] Error 1 etc fix, please thanks, Russ email: russwhit(a)mind.net

1 0

Code Generation Problem, btw...
by Orlando Llanes 21 Sep '98

21 Sep '98

Now that I think about it, the problem I'm having might be a linking problem rather than a code generation problem (or maybe it's a combination of both?) 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

1 0

Re: Code generator problem?...
by Frank Heckenbach 18 Sep '98

18 Sep '98

Orlando Llanes wrote: > I recompiled a program to test my libs, and my program crashed. I > suspect that it's the importing of externals because I recompiled Bernie's > BWGraph libs and they also crashed (both his sources and my sources did > not crash with the previous version of GPC). The reason I suspect > importing of externals is because I printed a value that should have been > filled by an externally declared program, it seems as if none of the > routines declared outside are working properly. I'll have to warn you if > you need the code, I don't know if there's anyway to reduce it to > reproduce the error. BTW, I'm using the DOS version of GPC. Alright, as you may suppose, we can't find the problem with this description alone. So perhaps you can mail the sources to me privately, not to the list if they're big (please with an exact description how to compile them and how to run the program to reproduce the error)... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Code generator problem?...
by Orlando Llanes 18 Sep '98

18 Sep '98

I recompiled a program to test my libs, and my program crashed. I suspect that it's the importing of externals because I recompiled Bernie's BWGraph libs and they also crashed (both his sources and my sources did not crash with the previous version of GPC). The reason I suspect importing of externals is because I printed a value that should have been filled by an externally declared program, it seems as if none of the routines declared outside are working properly. I'll have to warn you if you need the code, I don't know if there's anyway to reduce it to reproduce the error. BTW, I'm using the DOS version of GPC. 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

1 0

Re: gpc-19980830 with gcc-2.8.1 - version_flag is undefined
by Frank Heckenbach 15 Sep '98

15 Sep '98

Benedict Lofstedt wrote: Hi, > [please respond by direct mail as well as I'm only just in the process of > joining the list] I'm sending a Cc. > I cannot build gpc-19980830 with gcc-2.8.1. It seems that the patch in > p/diffs/gcc-2.8.1.diff is incomplete in regard to the 'toplev.c' file. It > only changes some empty lines, where it seems that it should make the > variable 'version_flag' available as en external symbol, as this is what > the file 'gbe.h' assumes to be the case: > > [...] > > Anyone with a patch ready for this? Yes, indeed the gcc-2.8.1.diff supplied with the last source release was incomplete. A corrected file has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/gcc-2.8.1.diff.gz -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 with gcc-2.8.1 - version_flag is undefined
by Benedict Lofstedt 14 Sep '98

14 Sep '98

Hi, [please respond by direct mail as well as I'm only just in the process of joining the list] I cannot build gpc-19980830 with gcc-2.8.1. It seems that the patch in p/diffs/gcc-2.8.1.diff is incomplete in regard to the 'toplev.c' file. It only changes some empty lines, where it seems that it should make the variable 'version_flag' available as en external symbol, as this is what the file 'gbe.h' assumes to be the case: /* toplev.c */ extern char *progname; extern int version_flag; extern void pedwarn PVPROTO ((char *, ...)); extern void warning PVPROTO ((char *, ...)); extern void error PVPROTO ((char *, ...)); extern void fatal PVPROTO ((char *, ...)); extern void error_with_decl PVPROTO((tree, char *, ...)); extern void rest_of_decl_compilation PROTO ((tree, char *, int, int)); extern void warning_with_file_and_line PVPROTO ((char *, int, char *, ...)); The result is a linking problem. gcc -DIN_GCC -DGPC -DSVR4 -g -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute.o mkstemp.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `case "gcc" in "cc") if [ xalloca.o != x ]; then echo ../alloca.o; else true; fi ;; esac` `if [ x != x ]; then echo ../; else true; fi` Undefined first referenced symbol in file version_flag module.o ld: fatal: Symbol referencing errors. No output written to ../gpc1 gmake[1]: *** [../gpc1] Error 1 Anyone with a patch ready for this? --- benedict -- Benedict Lofstedt <blofstedt(a)daimi.aau.dk> University of Aarhus, Department of Computer Science Fax: + 45 8942 3255 Building 540, Ny Munkegade, DK-8000 Aarhus C, Denmark. Phone: + 45 8942 3222

1 0

Re: gpc-19980830 binary for DJGPP
by Frank Heckenbach 09 Sep '98

09 Sep '98

Maurice Lombardi wrote: > I have found an other small error in this distribution. > The info files have short filenames gpc.iXX (which is good to enable to > work on plain DOS with 8.3 limitations), but in the gpc.inf file, in the > "Indirect:" section they are referred to with long filenames > gpc.info-XX, so that the info reader is unable to find them. This seems > the only error, and correcting manually these lines in the file gpc.inf > makes all to work properly. Thanks for the report. I've fixed it so it won't happen again with binaries I produce. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

time bug
by Maurice Lombardi 08 Sep '98

08 Sep '98

Hi all I have finally found the answer to a very old DOS bug 34396148.5C71(a)ujf-grenoble.fr namely a bug appearing when running time.exe from command.com, and not when running it within rhide or under the bash shell. This has nothing to do with gpc, but it is due to a bizarre characteristic of DOS. When there is no explicit directory in a command, the name is looked for in the set of "internal commands", the current directory and in the paths listed is the PATH variable, in that order. And time is an "internal command" in DOS. So when you type "time.exe" DOS understands the command "time" with a parameter (which should be the new time) .exe (or exe with . as a separator), which makes no sense, and it barks invalid time. The workaround is to type explicitly the directory .\time.exe, so that there is no search for implicit directories. This is a common practice in unix shells, because the current directory is not prepended to the path list, but is usually never done in DOS. So remove the bug from the bug list and forget it. Or may be change the name time.p in the test list to tim.p (an change accordingly the makefile) to avoid the bug popping anew for an other user. Greetings 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

3 2

Re: time bug
by Frank Heckenbach 08 Sep '98

08 Sep '98

Maurice Lombardi wrote: > I have finally found the answer to a very old DOS bug > 34396148.5C71(a)ujf-grenoble.fr Glad to hear so. This was one of the few bugs in the list that I didn't really know what they were about... :-) > [...] > So remove the bug from the bug list and forget it. Or may be change the > name time.p in the test list to tim.p (an change accordingly the > makefile) to avoid the bug popping anew for an other user. Another solution would be to let the Makefile prepend ".\" to all file names under Dos, just as it prepends "./" on Unix. However, this test was part of the old test suite which isn't included in GPC anymore. I don't know if anyone still maintains that test suite. If so, s/he may change this... Anyway, I removed this bug from the list now, and for the first time (I think) since I have the list, DJGPP is not the system with the most system-specific bugs known... ;-) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

C Arrays
by Thamm, Russell 08 Sep '98

08 Sep '98

There seems to be subtle inconsistancies with accessing 'C' Arrays from PASCAL. I am concerned that array variables need to be treated differently than array parameters. Basically, variables need to be declared as arrays and parameters need to be declared as pointers to arrays. I would have thought that if I declared a 'C' array variable to be a pointer, and a function parameter to be a pointer, that when I pass the variable to the function, PASCAL should pass a pointer. However, this is not the case for 'C' array variables. The following code fragments demonstrate this: <<TEST.C>> int carray[5] = {0x01010101,0x02020202,0x03030303,0x04040404,0x05050505}; int c1array[5] = {0x01010101,0x02020202,0x03030303,0x04040404,0x05050505}; void print_array(int *arr) { int i; for (i=0; i < 5; i++) printf("%8X\n",arr[i]); } <<ARRTEST.PAS>> program ArrTest; {$L test.c} type CCARRAY = array[0..4] of Integer; CCARRAY_PTR = ^CCARRAY; var carray : __asmname__ 'carray' CCARRAY_PTR; c1array : __asmname__ 'c1array' CCARRAY; pas_arr : CCARRAY value ($01010101,$02020202,$03030303,$04040404,$05050505); p : CCARRAY_PTR; procedure print_array(arr : CCARRAY_PTR); AsmName 'print_array'; begin p := &pas_arr; WRITELN('c array'); print_array(&carray); {this & seems wrong} WRITELN('c1 array'); print_array(&c1array); WRITELN('pascal array'); print_array(p); WRITELN('pascal array'); print_array(&pas_arr); end. PASCAL treats 'C' arrays the same, irrespective of whether they are declared as a plain array or as a pointer to an array. The & operator is required to pass 'C' arrays to 'C' subroutines. Alternatively, in my PASCAL declarations of 'C' functions, I could declare all 'C' array parameters to be VAR parameters. But this just doesn't seem right. On another matter, I downloaded the latest binary of GPC (gpc-19980830.i386-djgppv201.zip). Now, I keep getting a linker error about crt0.o. How do I overcome this? thanks Russell

4 4

kampi must be down
by Marcelo Pereira Nunes 08 Sep '98

08 Sep '98

Hey guys, I tried to connect ftp://kampi.hut.fi/jtv/gnu-pascal/ from Brazil and my Netscape said that it shoud be down. Does anybody know what happend? Could you tell me any mirror site for download? Thanks, Marcelo.

2 1

'-lgpc: not found' and '-lgpc: not found'
by Ricardo Luis Kulzer 04 Sep '98

04 Sep '98

I got the binary code of gpc (ftp://ftp.unicamp.br/pub/gnu/gpc-2.0.sparc-sun-solaris2.5.1.tar.gz), and put it on my system (Sparc workstation running Solaris 2.5.1) When I try to compile a pascal program, I receive the message: gpc -o tmp tmp.pas ld: fatal: library -lgpc: not found ld: fatal: library -lgcc: not found ld: fatal: library -lgcc: not found ld: fatal: File processing errors. No output written to t What is wrong? Ricardo Kulzer rkulzer(a)lacesm.ufsm.br CRSPE-INPE/UFSM

2 1

GPC Beta release: gpc-19980830
by Peter Gerwinski 04 Sep '98

04 Sep '98

Hello everybody! A new Beta version of GNU Pascal is now available: gpc-19980830. News ==== Apart from many bug fixes, we have significantly improved GPC's compatibility to Borland Pascal. Things like Extended Pascal's schema types are now more stable, and many functions such as conversion functions between Pascal and C strings are now built in. In particular: - A unit `gpc.pas' is now included which contains declarations of almost all the routines in the run time system. Many of them, including all that are required by the standard, are available without using this unit, but some new extensions, in particular most of the new string, CString and file name routines listed below, are only available when this unit is used. (It is planned to let GPC automatically use this unit in a later version, and then more declarations will go there that are currently built into the compiler.) - BP compatible runtime I/O error handling that is enabled/disabled by the compiler options {$I-} and {$I+}. In "disabled" mode, I/O errors don't cause runtime errors, but can be checked for by the program with the `IOResult' function. - Error messsages of the run time system are now output in the form: "a.out: [internal error:] unknown code in `Write' (#904)" which is closer to the GNU coding standards than the previous format was. - A symbol `__GPC_RELEASE__' is predefined, containing the release date of the GPC version in the format YYYYMMDD. This can be used in units that require certain features of the compiler to make sure they are now compiled with a too old compiler. Such a test might look like the following: {$if __GPC_RELEASE__ < 19980830} {$error This unit requires GPC release 19980830 or newer} {$endif} - New/GetMem/Dispose/FreeMem can now be mixed freely with malloc()/free(), to ease interfacing GPC code to C routines, and with Mark/Release. (The only thing that does not work is free()ing a New/GetMem'ed block between a Mark and the corresponsing Release, something which is not likely to happen unintentionally.) - New compiler options: --autolink (link units as used, but don't recompile them) When several --automake="foo", --autobuild="bar" and --autolink="baz" options are given, the "highest" one is valid, and the options of all of them are collected. --no-automake, --no-autobuild, --no-autolink (each of them disables all of --autolink, --automake and --autobuild) --gnu-pascal (disables any previously selected dialect options) --uses="foo" (automatically use a unit) --longest{int,real}-field-width (specify the field width in Write[ln] of long integer and real types) - String routines: UpCase (B) LoCase UpCaseString LoCaseString UpCaseStr LoCaseStr - CString routines: StrLen (B) StrEnd (B) StrScan (B) StrRScan (B) StrDup StrCmp StrCaseCmp StrPCopy (B) NewCString CString2String String2CString - File and I/O routines and declarations: IOResult (B) InOutRes (B) Erase (B) Rename (B) ChDir (B) MkDir (B) RmDir (B) FileMode (B) Flush (B) FilePos (B) FileSize (B) Truncate (B) Append (B) GPC_StatFS - File name routines and declarations: PathSeparator DirSeparator DirSeparators ExtSeparator DirSelf DirParent NullDevice TTYDevice ConsoleDevice GetCurrentDirectory GetTempDirectory GetTempFileName GetTempFileName_CString Slash2OSDirSeparator OSDirSeparator2Slash Slash2OSDirSeparator_CString OSDirSeparator2Slash_CString FileExists DirectoryExists FSearch (B) FSearch_Executable Expand_Environment FExpand (B) FSplit (B) DirFromPath NameFromPath ExtFromPath OpenDir ReadDir CloseDir - Other routines and declarations: ExitCode (B) ErrorAddr (B) RunError (B) SizeType PtrDiffType High (B) Low (B) Random (B) Randomize (B) Pi (B) DayOfWeek new fields DayOfWeek, MicroSecond in the TimeStamp record Items marked "(B)" are BP compatible routines/declarations. For a more detailed list of fixed bugs and new features, see the GPC TODO list, available online at http://fjf.gnu.de/gpc-todo_toc.html or as Texinfo source at http://fjf.gnu.de/gpc-todo.texi.gz . This version of GPC has been tested with and is expected to work on Linux on the Pentium and the Alpha platform, but there are known problems with packed arrays and "long" data types on 64-bit machines like the Alpha. The GNU Pascal development team welcomes the new members Nick Burrett and Matthias Klose. Where to get it =============== The source is available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/gpc-19980830.tar.gz . Binaries for DOS (DJGPP), and Linux (ELF) will follow as soon as possible and will be announced separately. Acknowledgement =============== I still have lost overview, but the GNU Pascal development team thanks everybody who helped us by contributing useful ideas and reporting bugs. Thanks to all of you! Greetings, The GNU Pascal Development Team Peter, Frank, Matthias, Jan-Jaap, and Nick -- 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/

3 4

Re: GPC Beta release: gpc-19980830
by Peter Gerwinski 04 Sep '98

04 Sep '98

Miklos Cserzo wrote: > > This time it is OK. How can I test it without actually installing it? (The > naiv way from p/test/: "make" failed.) make PC="../../xgpc -B../../" Greetings, 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

Documentation
by Paul Doerwald 04 Sep '98

04 Sep '98

Since it is widely grokked that community efforts (especially in the software industry) work better than individual efforts, Peter and I have been discussing how we can, as a community, best work on the GPC documentation. Here is an idea that we came up with: Rather than a web-based form like I suggested, we propose an e-mail based system. With a simple syntax, you can request a portion of the GPC reference documentation, and it will be e-mailed back to you. You can reply, quote the text, and edit what you like, and when you send it back, your changes will be automatically added to the official GPC (texinfo) documentation, and will also be kept online in an HTML format so that everyone has immediate access to your contribution. This way we can all contribute to the GPC documentation effectively. Any thoughts? | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | ICQ#13902938 Exodus 15:2b

2 1

gpc-19980830 binaries for Linux
by Peter Gerwinski 02 Sep '98

02 Sep '98

Hi, folks! Two binary distributions of gpc-19980830 for i586-pc-linux-gnulibc1, one based on gcc-2.8.1 and one on egcs-2.91.55, are being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ . Greetings, 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/

2 1

Allegro and ASM
by Thamm, Russell 01 Sep '98

01 Sep '98

Hi, I've been trying to convert allegro.h into a Pascal unit. Has anyone already done this? One of the problems I'm having is translating the asm statements from C to PASCAL. I keep getting the compiler error: allegro.pas(1204) Error: cannot reload integer constant operand in `asm'. I have absolutely no idea what this means. The offending code is as follows: asm ('call *%3' : '=a' (result) { result in eax } : 'd' (bmp), { bitmap in edx } '0' (line), { line number in eax } 'r' (bmp^.write_bank) { the bank switch routine } ); All I've done is changed all double quotes to single quotes and changed -> to ^. Could you please cc any replies to me as I am not subscribed to this mailing list despite several requests. thanks russell

3 2

GPC version question...
by Orlando Llanes 26 Aug '98

26 Aug '98

What's the name of the most recent patch (ok, I'm feeling a bit adventurous here now :P) or binary for GPC? I downloaded the 98-05-11 release (installed *after* DJGPP 2.8.1 and all its tools were installed), is that the most recent one? If so, I can't figure out why I get the "unit information deterioration" bug. Could installing GPC over DJGPP be the reason? Should I leave GPC in its own directory? 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

Re: RunError
by Frank Heckenbach 22 Aug '98

22 Aug '98

Orlando Llanes wrote: > Is it possible to hook the RunError in GPC? I would definitely be > interested in a feature like that so that custom handlers can be used. If you mean the RunError procedure, yes (just write your own RunError procedure :-). If you mean the runtime error handling in general, no, not yet (except by modifying the RTS itself). For the time after GPC 2.1, I'm planning some form of exception handling like Delphi or Java which would make this possible. > Awesome 8o~~~ (<--- Drooling with goofy eyes) I think the C workaround > was not a good work-around anyway, I got weird results using them, for a > text file (for example) it worked fine, but (also for example) the pcx > encoder didn't properly encode a file despite using a proven algorithm. I didn't look to closely at the code, so I don't know if there were any problems with it. Another possible problem, if e.g. the code was tested with TP, is the different sizes of data types in GPC, buf I suppose you've thought of that... > I'm trying to eliminate > warnings wherever possible without requiring special command-lines :) Yes, me too. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: RunError
by heckenb＠helena.hut.fi 22 Aug '98

22 Aug '98

Peter Gerwinski wrote: > > BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should > > allow that, too. However, BP gives a "Runtime Error 0" then, which I don't > > like very much, since the exit status 0 usually means success. So, GPC > > should probably use some other error code... > > Which one? I'd say one in the "unsorted errors" range 0..99, perhaps 99 -- or 42. ;-) -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Re: Weird error...
by Frank Heckenbach 22 Aug '98

22 Aug '98

Orlando Llanes wrote: > I got the following error: > > testpcx.pas:4: storage class specified for parameter `Close' Can't reproduce this one with my current version, so I assume it's been fixed by now. Much has changed since the last release, and this was probably among the bug fixes made. BTW (seeing the contents of edsys.pas and edfile.pas): GPC does support untyped files and BlockRead/BlockWrite (already since January), so there's actually no reason for you to do these workarounds you do with C files and direct libc calls. (And FillChar is build in which is internally the same as memset.) > testpcx.pas: In function `program_Testpcx': > testpcx.pas:33: warning: passing arg 4 of `Pcxencode' from incompatible > pointer type > > I have simplified the source as much as possible while leaving the > source structure as is to reproduce the error. I'm using GPC 2.8.1 under > DOS. The warning on line 33 is insignificant as far as I know, I'm passing > an address, and the routine expects a pointer. The warning is correct. You pass a pointer to EDUInt8 and the routine expects a PArray8 which is a quite different type. (Not all pointer types are the same in Pascal!) To get rid of the warning, you can use type casting. > BTW, if you recall, I got an error a long time ago about an empty > record. I found a way around that, I left the unit to keep up the source > structure, but I defined everything in an include file and included it > into the unit itself, now I don't have that problem anymore (I hope :}). This bug should have been fixed in the next version, too. (I had a lot of problems with various instances of this bug, too...) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: RunError
by Frank Heckenbach 22 Aug '98

22 Aug '98

Peter Gerwinski wrote: > Frank Heckenbach wrote: > > I (Peter Gerwinski) wrote: > > > > BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should > > > > allow that, too. However, BP gives a "Runtime Error 0" then, which I don't > > > > like very much, since the exit status 0 usually means success. So, GPC > > > > should probably use some other error code... > > > > > > Which one? > > > > I'd say one in the "unsorted errors" range 0..99, perhaps 99 -- or 42. ;-) > > What about 81 (assertion failure)? Don't think so. It's got nothing do to with assertions -- or rather, it might have, but then, it might be something completely different. It's up to the programmer what s/he uses this error for... I think 80 (call to predefined procedure `Bug') would be closer. AFAICS, there's no predefined procedure `Bug' currently. Does the standard or some dialect demand one? If not, we could use that and replace `Bug' by `RunError'. But we can just as well use a new error code (error codes are not a scarce resource -- we have the full Integer range available, and currently only nearly 200 out of the first 1000 are used ;-)... And apropos assertions: it's easy to write a procedure for runtime assertions, like the following: procedure Assert (Condition : Boolean; const Message : String); begin if not Condition then Runtime_Error_CString (81, Message) end; (changing the text of the error message to "failed assertion `%s'"). Should I put this routine into the RTS? (This would also make it easier to change the error number, when the error numbers are rearranged.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Weird error...
by Orlando Llanes 21 Aug '98

21 Aug '98

I got the following error: testpcx.pas:4: storage class specified for parameter `Close' testpcx.pas: In function `program_Testpcx': testpcx.pas:33: warning: passing arg 4 of `Pcxencode' from incompatible pointer type I have simplified the source as much as possible while leaving the source structure as is to reproduce the error. I'm using GPC 2.8.1 under DOS. The warning on line 33 is insignificant as far as I know, I'm passing an address, and the routine expects a pointer. BTW, if you recall, I got an error a long time ago about an empty record. I found a way around that, I left the unit to keep up the source structure, but I defined everything in an include file and included it into the unit itself, now I don't have that problem anymore (I hope :}). 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

1 0

Re[4]: trouble compiling
by Paul Doerwald 14 Aug '98

14 Aug '98

> I think it's better to continue this discussion on the list. If you agree, > be invited to bounce my mail there. Did I not reply to all? oops. You might want to update the list software so it changes the Reply-To: field to gpc(a)hut.fi -- I've made this mistake more than once... > (So do I. If only I had the time I would happily WTFM.)-: Many moons ago, I volunteered to wtfm -- I realized shortly after that I was incapable of doing so (time, and knowledge of Pascal). And since things always work better in a community effort, I made the suggestion I did... Sadly, though, I still haven't gotten anyone else's thoughts. I found a gcc-2.8.1 distribution on my computer that I had downloaded (and left in a stupid place that I never thought to look), so I unpacked that, and stuck gpc-980511 in the p directory. It detected the patch file. I suspect this will work now. (No more trying short cuts for me -- maybe in a few years when I've used Linux enough, and I'm a bit more into the programming loop -- I'm a university music student who hasn't coded actively since early high school, so I'm somewhat (read: very) out of the loop) Sorry to trouble you with all my pedantic questions... | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | ICQ#13902938 Exodus 15:2b

1 0

trouble compiling
by Paul Doerwald 13 Aug '98

13 Aug '98

It seems that the only reason I ever post in this list is for help compiling GPC. I've got gcc 2.8.1 and gpc-980511. These are the errors I get: (root) pollux:/usr/src/gcc-2.8.1>make LANGUAGES=pascal cd p; make "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CC=gcc" "CFLAGS=-g" "CLIB=" "GCC_FOR_TARGET=./xgcc -B./" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "objext=.o" "exec_prefix=/usr" "prefix=/usr" "tooldir=/usr/i486-pc-linux-gnu" "bindir=/usr/bin" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "CROSS=" "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g" "X_CFLAGS=" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "MAYBE_TARGET_DEFAULT=" "MAYBE_USE_COLLECT2=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "bindir=/usr/bin" "exec_prefix=/usr" "gxx_include_dir=/usr/include/! ! ! g++" "includedir=/usr/local/include" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "prefix=/usr" "target_alias=i486-pc-linux-gnu" "tooldir=/usr/i486-pc-linux-gnu" "gpc_version=980511" "rts_version=2.8" "version=2.8.1" ../gpc1 make[1]: Entering directory `/usr/src/gcc-2.8.1/p' rm -f ../gpc1 gcc -DIN_GCC -DGPC -g -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `case "gcc" in "cc") if [ x != x ]; then echo ../; else true; fi ;; esac` `if [ x != x ]; then echo ../; else true; fi` gpc-common.o: In function `build_pascal_binary_op': /usr/src/gcc-2.8.1/p/gpc-common.c:2572: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/gpc-common.c:2587: undefined reference to `emit_string_move' gpc-decl.o: In function `grokdeclarator': /usr/src/gcc-2.8.1/p/gpc-decl.c:5924: undefined reference to `size_volatile' gpc-decl.o: In function `handle_forward_pointers': /usr/src/gcc-2.8.1/p/gpc-decl.c:9049: undefined reference to `dbxout_set_type_status' /usr/src/gcc-2.8.1/p/gpc-decl.c:9055: undefined reference to `dbxout_set_type_status' module.o: In function `execute': /usr/src/gcc-2.8.1/p/module.c:466: undefined reference to `version_flag' module.o: In function `module_must_be_recompiled': /usr/src/gcc-2.8.1/p/module.c:685: undefined reference to `version_flag' module.o: In function `compile_module': /usr/src/gcc-2.8.1/p/module.c:802: undefined reference to `version_flag' module.o: In function `load_tree': /usr/src/gcc-2.8.1/p/module.c:1799: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/module.c:1853: undefined reference to `size_volatile' parse.o: In function `yyparse': /usr/src/gcc-2.8.1/p/parse.y:1563: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:1629: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:4766: undefined reference to `maybe_find_function_data' rts.o: In function `build_rts_call': /usr/src/gcc-2.8.1/p/rts.c:3503: undefined reference to `emit_string_move' types.o: In function `assign_string': /usr/src/gcc-2.8.1/p/types.c:639: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/types.c:690: undefined reference to `emit_string_pad' types.o: In function `prediscriminate_schema': /usr/src/gcc-2.8.1/p/types.c:1056: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1058: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1089: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1092: undefined reference to `size_volatile' types.o: In function `build_pascal_pointer_type': /usr/src/gcc-2.8.1/p/types.c:1738: undefined reference to `dbxout_set_type_status' util.o: In function `handle_formal_conf_array_param_list': /usr/src/gcc-2.8.1/p/util.c:738: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:763: undefined reference to `size_volatile' util.o: In function `initialize_world': /usr/src/gcc-2.8.1/p/util.c:1816: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:1819: undefined reference to `size_volatile' make[1]: *** [../gpc1] Error 1 make[1]: Leaving directory `/usr/src/gcc-2.8.1/p' make: *** [gpc1] Error 2 Any suggestions? Paul.

2 1

an idea for documentation
by Paul Doerwald 13 Aug '98

13 Aug '98

A couple months ago, there was a big struggle on the list over the out-of-date reference manual for GPC, and people proposed suggesting changes through the list. I have another idea, and I just thought I'd run it past all of you (especially you, Peter) Since there are a few people who *really* know GPC and all its function and procedure calls, but they don't have the time to document the whole thing as well as write it, but they always had corrections to what people submitted.... What I'm thinking is an extensive, online script (I would give it a shot, in Perl) that would allow everyone to update an online version of the documentation (that would be stored in HTML). Everyone could make their own changes; if they see a little problem, they can clarify it, and expand on each others' work. I wouldn't bother with passwords and special access -- I would just have regular backups made so that if someone hit it and tried to screw it up, we'd have a good copy backed up. The HTML file could (somehow?) be translated into texi, for distribution with GPC. Is this something that would be of value? I'd be interested to hear your suggestions. Paul.

1 0

Re: Memory access...
by heckenb＠helena.hut.fi 05 Aug '98

05 Aug '98

Orlando Llanes wrote: > The question I'm about to ask pertains to the DJGPP/DOS platform, tho > it may apply to other platforms if present. How can I access mroe than 8MB > while keeping compatible with the GPC Pointer type? I ask because I tried > allocating >8MB and I got a runtime error saying that GPC is out of heap > space. I know there are DPMI functions, but which one can allocate >8MB > while still maintaining the near pointer type? Thanks in advance! Looks like a DPMI configuration issue. I just ran the following program in DosEmu succesfully, after I increased the DPMI memory size (in DosEmu, that's as simple as setting "dpmi 32768" in /etc/dosemu.conf, but I don't know how this is done in native Dos): program x; const m=33000000; type t=array[1..m] of byte; var a:^t; i:integer; begin new(a); for i:=1 to m do a^[i]:=i and $ff; for i:=1 to m do if a^[i]<>i and $ff then runerror(42); writeln('OK') end. However, I can't seem to allocate more than 32 MB in DPMI, so this might be the limit of DPMI. (Anyone knows? From other source, I sometimes hear 16 MB, sometimes 64 MB as the limit. 32 MB is just in between, so according to the usual Dos kind of logic, this might be correct... >:-) BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should allow that, too. However, BP gives a "Runtime Error 0" then, which I don't like very much, since the exit status 0 usually means success. So, GPC should probably use some other error code... -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Memory access...
by Orlando Llanes 04 Aug '98

04 Aug '98

The question I'm about to ask pertains to the DJGPP/DOS platform, tho it may apply to other platforms if present. How can I access mroe than 8MB while keeping compatible with the GPC Pointer type? I ask because I tried allocating >8MB and I got a runtime error saying that GPC is out of heap space. I know there are DPMI functions, but which one can allocate >8MB while still maintaining the near pointer type? Thanks in advance! 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

1 0

compiling gpc sources in plain dos / djgpp
by Maurice Lombardi 04 Aug '98

04 Aug '98

Hi all, Sometimes ago I have seen in a message of DJ Delorie in comp.os.msdos.djgpp, saying that now djgpp with the autoconf port can build with minor modification nearly every unix program governed by configure shell scripts. I have thus retried to build gpc under plain DOS from gcc-2.8.1 and the latest alpha sources gpc-980511.tar.gz. It works indeed with very few modifications, but everything contained in the directory p/config/msdos is now outdated, the configuration for gcc has been completely changed between 2.7.2.x and 2.8.x. I give in attachment a couple of files suggested for doing the modifications automatically (a driver prepare.bat and a shell script doprepar.sh), and a couple of instruction files (install.txt for binaries, the old one only slightly updated, and readme.djgpp for sources) to be put into the p/config/msdos directory (replacing the old ones). The modifications are - a few 8.3 issues stamp-objlist -> s-objlist .gdbinit -> gdb.ini g??.info-NN -> g??.iNN (only when LFN=n) - GCC is built into the build.djgpp subdirectory of the gnu/gc-2.81 source directory, while gpc must be built into the source directory itself. - enlarge the stack for gpc1 and gpc-cpp. Done by modifying a file config/i386/x-go32 which is already used by Delorie for enlarging the stack of cc1 cc1plus and cc1obj. With these modifications (plus one below to be done in the gpc sources themselves) all compiles, and the built compiler gives the same results as the binaries contained in the distribution for everything I have tried, some private programs, test programs from bgi2grx, the gpc test and testsuite. The modification suggested to gpc sources themselves is the following While looking around in the gcc "makefile.in" I have found the following: # Install the info files. # $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir # to do the install. The sed rule was copied from stmp-int-hdrs. install-info: doc installdirs lang.install-info -rm -f $(infodir)/cpp.i* $(infodir)/gcc.i* for f in $(srcdir)/cpp.i* $(srcdir)/gcc.i*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/cpp.i* $(infodir)/gcc.i* ... and in the file "make-lang.in" from gpc, we indeed cd into the srcdir, and this fails when I install in a relative directory (to see what happens without overwriting my previous binary installation of gpc). So I suggest to replace in "gpc/p/make-lan.in" the old content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; cd $(srcdir)/p/doc; for f in gpc.info*; \ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gpc.info* by the new content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; for f in $(srcdir)/p/doc/gpc.info*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/gpc.info* The doprepar.sh will take care of info* -> i* afterwards, only for the dos/LFN=no case. I have checked thas this works. Finally I have taken the .tar.gz sources untarred by the djtar utility. For .zip sources there remain a couple of problems to be solved: .gdbinit is ignored by pkzip and extracted as _.gdb by infozip. The extraction as _gdbinit done by djtar is supposed in the doprepar.sh script. in gpc-980401.zip I have tried, the info files have the long names gpc.info-NN, which cause problem both with pkunzip and infozip. This is also the case in the .tar.gz archive, but djtar takes care of this, by translating them to gpc.iNN, when LFN=no. The simplest workaround is probably not to include these files, since they are rebuilt easily from texi sources. the gpc diff filenames gpc-2.8.0.diff and gpc-2.8.1.diff are extracted by djtar as gpc-2.8-0 and gpc-2.8-1, which is fine for doprepar.sh, while infozip extract both as gpc-2_8_.dif (and barks for overwriting). This has no importance for alpha or beta stages, where you can supply only .tar.gz files, but needs to be solved when releasing an official version (everything is in zip format in the djgpp archives). Hope this helps. -- 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 @echo off echo ... starting from p/config/msdos directory: pwd echo ... going to gcc source dir: cd ..\..\.. pwd echo ... running doprepar shell script sh p\config\msdos\doprepar.sh

1 0

DiskSize and DiskFree
by heckenb＠helena.hut.fi 03 Aug '98

03 Aug '98

Hi! I just implemented some routines of BP's Dos unit in a portable way. Some of them are too Dos specific to be done portably, but most of the others are implemented. What is a bit problematic is the functions DiskSize and DiskFree which return the total or free space of a disk volume (mounted file system), respectively. The only routine I found to implement them with is statfs() which is unfortunately not standardized. E.g. Linux and DJGPP have compatible statfs()'s, but Solaris' one is a little different and deprecated in favour of statvfs() which isn't present on the former two systems. I don't know what it's like on other systems. Then I looked at the source code of df(1) which gets this information, and it's full of ifdefs and other nice things which confirms my guess that there's no portable way. So, I see only the following possibilities: - Not implement these routines in the Dos unit at all. - Implement them only for some known systems via ifdefs -- which would be Linux, DJGPP and Solaris for me, and perhaps other people will add support for other systems. - Test for some known functions (e.g. statfs() with the Linux/DJGPP arguments and statvfs() as found in Solaris) from GPC's RTS configure, and put a little system-independent wrapper into the RTS. (Advantage compared to the previous suggestion: configure is more general than ifdefs and can support systems I don't even know about if they have a compatible routine. Disadvantage: adding support for other systems requires changing the RTS, not only a unit.) - Pipe the output of df(1) and extract the information from that (not so seriously...) Any suggestions how to go ahead, or perhaps even better suggestions than the above? Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Documentation: AsmName...
by Orlando Llanes 01 Aug '98

01 Aug '98

@node asmname @unnumberedsec asmname @cindex asmname (Modified) @unnumberedsubsec Syntax @smallexample Var MyVar : asmname 'ExternalName' @var{some type}; Procedure MyProcedure; asmname 'externalproc'; Procedure MyProcedure( MyParam1 : @var{some type} ); asmname 'externalproc'; Function MyFunction: @var{some type}; asmname 'externalfunc'; @end smallexample @unnumberedsubsec Description @samp{asmname} allows one to access variables, functions, and/or procedures compiled externally. The difference between @samp{asmname} and @samp{C} is that ASMName sets the name of the procedure to one that will be recognized by the linker. @unnumberedsubsec Standards @unnumberedsubsec Example @unnumberedsubsec See also @ref{C} 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 3

Various GPC Questions
by Thamm, Russell 29 Jul '98

29 Jul '98

I have found a couple of apparent bugs in GPC: 1. Debugger and objects. ------------------------------ There appears to be an error in debug entries generated for objects. When viewing object fields under the debugger, the wrong values are shown for the right field. If I set a breakpoint at the end of the constructor and examine *Self, I get *Self: {One = 74404, Two = 1, Three = 2} program bad; type MyObject = object One : Integer; Two : Integer; Three : Integer; constructor init; end; var x : MyObject; constructor MyObject.init; begin One := 1; Two := 2; Three := 3; end; begin x.init; end. Direct Access Files ----------------------- There appears to be some discrepancy between record numbering for reading and writing. To read record n, I specify SeekRead(n). But to write record n, I specify SeekWrite(n). When I execute the following program, I get: Created File 0 : 0 1 : 1 2 : 2 3 : 3 4 : 4 5 : 5 Modified file at position 0 to 55 Modified file at position 2 to 66 Modified file at position 6 to 77 0 : 0 1 : 66 2 : 2 3 : 3 4 : 4 5 : 77 PROGRAM Bad1; TYPE DAFile = File [0..5] of Integer; VAR MyFile : bindable DAFile; procedure AssignFile; var b : BindingType; begin unbind(MyFile); b := binding(MyFile); b.name := 'test.dat' + chr(0); bind(MyFile,b); end; procedure CreateFile; var i : Integer; begin AssignFile; Rewrite(MyFile); for i := 0 to 5 do Write(MyFile,i); Close(MyFile); end; procedure ModifyFile(index : Integer; val : Integer); var pos : Integer; begin AssignFile; SeekWrite(MyFile,Index); pos := Position(MyFile); Write(MyFile,val); Close(MyFile); Writeln('Modified file at position ',pos,' to ',val); end; procedure PrintFile; var i,val,pos : Integer; begin AssignFile; for i := 0 to 5 do begin SeekRead(MyFile,i); pos := Position(MyFile); Read(MyFile,val); WRITELN(pos,' : ',val); end; Close(MyFile); end; begin CreateFile; WRITELN('Created File'); PrintFile; ModifyFile(0,55); ModifyFile(2,66); ModifyFile(6,77); PrintFile; end. TurboVision --------------- I was surprised to see that the Turbo Vision source code is in C++ and I see that Turbo Vision is still in the TO DO list for GPC. Whats the current situation? I presume that GPC can't access Gnu C++ classes. Therefore someone needs to either write a wrapper or to convert the C++ classes into PASCAL objects. Is anyone currently working on a port? Turbo Vision is fairly important to me so I'd be interested porting it to GPC. Russell Thamm

2 1

Re: Various GPC Questions
by Frank Heckenbach 29 Jul '98

29 Jul '98

Thamm, Russell wrote: > Direct Access Files > ----------------------- > > There appears to be some discrepancy between record numbering for > reading and writing. > To read record n, I specify SeekRead(n). But to write record n, I > specify SeekWrite(n). Thanks for the report. I fixed the bug. (Just wait for the next version.) But two comments about your test program. You declare a file [0..5], but then seek to 6. I don't think that's really OK, is it? (But GPC accepts it, at least currently. This might be due to the missing range checking, and would not work anymore when range checking will be implemented.) You terminate the file name with a chr (0). That's not only unnecessary (because the Name field of BindingType is a Pascal string, not a CString), but also potentially problematic: the run time system (RTS) uses libc routines internally to open the file. Those use CStrings, and therefore regard the #0 as a terminator. But perhaps the RTS does some other things with the file name, treating it as a Pascal string, and counting the #0 as part of the name (AFAIK, it doesn't do so currently, but it might do later, when parts of it are translated into Pascal). Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Question
by ceo＠digital-concepts.net 28 Jul '98

28 Jul '98

I am a windows pascal programmer and unix perl. I am trying to convert some perl scripts over to c++ and learning c++ at the same time. I would love to code in pascal on unix, but my current perl program uses dbm files. Is there a library for interfacing with gdbm or ndbm files for the GPC? I dont want to have to write c declarations, I dont know how, I want to know if something already exists. Thank you, Chris Ihlenfeld

2 1

i386-mingw32 (Windows9X/NT) GPC available
by Jan-Jaap van der Heijden 20 Jul '98

20 Jul '98

OK, it's about 1 year after it's scheduled appearance, but here it is anyway: GPC/mingw32 :-) For those who are not familiar with mingw32: it's essentially cygwin32 without the unix emulation stuff. Leaving this out also makes it an order of magnitude faster. Patches have been sent to Peter for inclusion in the next alpha/beta Because not all of you may have a unix system with the necessary crosscompilers at hand, I have made prebuilt binaries available: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/binaries/gpc-980715.i386-pc-mingw32.zip equals: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/mingw32/beta/gpc-980715.zip This compiler requires components (binutils etc.) from an existing mingw32 installation. If you don't want to install the C compiler toolchain, get ftp://agnes.dida.physik.uni-essen.de/home/janjaap/mingw32/beta/gpckit-980715.zip which includes all tools and libraries required to compile Pascal programs. Go to http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32 for additional mingw32 info, links and installation instructions. Greetings, JanJaap ------------------------------------------------------------------------- J.J.vanderHeijden(a)student.utwente.nl : At home http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32 : Mingw32 GNU site http://www.bbv-software.com : Solutions for Integrated Optics

1 0

FIXED: gpc on AIX: troubles!
by Klaus Espenlaub 14 Jul '98

14 Jul '98

Hi all! With the help of a lot of mail between Nick Cremelie (the submitter of the original bug report) and me the bug has been finally found. At least things look very promising currently. It's very likely that this patch fixes the IRIX bug Frank mentioned, too. There are 2 main components in the attached patch: - the RS6000 no longer needs the GNU Pascal vs GNU PASCAL hack - for some platforms (COFF based without GNU ld) the static constructors were never called. This was the only real GNU Pascal bug. Refer to gpc-lang.c (finish_file) if you want to know what was missing. The first change is pretty obvious. The second change seems to work, but it hasn't been thoroughly checked yet. I'm not 100% sure that the place I put the calls to finish_file() is really correct. I just don't know enough about the Pascal frontend. Peter, please cross-check this. The attached patch has to be applied in the p subdirectory. Suggested ChangeLog entry for GNU Pascal: Tue 14 Jul 1998 13:01 Klaus Espenlaub <kespenla(a)student.informatik.uni-ulm.de> * parse.y: remove Pascal vs PASCAL hack for rs6000. pascal_program: Added call to finish_file(), writing out the static constructor/destructor calling code. * gpc-lang.h: add prototype for finish_file(). Note that this patch isn't enough to get a working GPC on at least some rs6000 based machines (e.g. ibm-aix4.1). This is because the RS6000 machine description contains a stupid bug. No static constructors were called. I wonder if really no one has tested this for GNU C (no, this didn't affect GNU C++). For those who ask: yes, it is possible to define constructors in GNU C. I'll submit a patch for this bug to the GCC developer mailing list. For those rs6000 users who cannot wait for the next GPC release, here's the patch for config/rs6000/rs6000.h in "human diff" format: search for ASM_OUTPUT_CONSTRUCTOR in config/rs6000/rs6000.h and delete the first matching line and the five lines below. Klaus diff -c parse.y~ parse.y *** parse.y~ Mon May 11 20:04:13 1998 --- parse.y Tue Jul 14 13:16:22 1998 *************** *** 112,132 **** /* Since parsers are distinct for each language, put the language string * definition here. - * - * rs6000.c calls abort() if this is "GNU Pascal" :-) - * - * I have modified rs6000.c. Since "Pascal" is a person's name - * like "Ada" it has the right to be written in the same manner. :-) - * - PG - * - * Sigh, I don't want to change rs6000.c; I will inform Kenner to change - * it in the next release. */ - #ifdef _IBMR2 - char *language_string = "GNU PASCAL"; - #else char *language_string = "GNU Pascal"; - #endif /* Sigh */ tree main_program_name = NULL_TREE; --- 112,119 ---- *************** *** 723,730 **** pascal_program: /* empty */ ! { warning ("empty input file"); } | program_component_list ; /* Allow multiple modules in input file. --- 710,721 ---- pascal_program: /* empty */ ! { ! warning ("empty input file"); ! finish_file(); ! } | program_component_list + { finish_file(); } ; /* Allow multiple modules in input file. diff -c gpc-lang.h~ gpc-lang.h *** gpc-lang.h~ Sat Sep 13 15:42:40 1997 --- gpc-lang.h Tue Jul 14 13:01:42 1998 *************** *** 49,51 **** --- 49,57 ---- union tree_node *directive; union tree_node *parms; }; + + /* + * GPC Specific prototypes for functions in gpc-lang.c + */ + + extern void finish_file PROTO ((void));

1 0

RE: GPC compiler errors
by Thamm, Russell 14 Jul '98

14 Jul '98

Maurice, Sorry to be difficult but neither crtf.o nor DJGPP.ENV is in the binaries that I downloaded. I can't find any sign of it in the latest sources archive. I'd be grateful if you could point me to a source for crtf.o. BTW congratulations on France's World Cup victory. Russell Thamm > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Friday, July 10, 1998 2:40 AM > To: Thamm, Russell > Cc: 'gpc(a)hut.fi' > Subject: Re: GPC compiler errors > > Thamm, Russell a Ã©crit: > > I recently installed Gnu Pascal (DJGPP-MSDOS) > > Eventually, I downloaded the latest alpha > > (gpc-980511.i386-pc-msdos-djgpp.zip) > > If someone could tell me where to get the crtf.o file, the linker > keeps > > asking for, > > it is in %DJGPP%\lib\djgpp\gcc-lib\2.81 > > There have been a major reorganisation of the djgpp directory > structure > when going from 2.7.2.x to 2.8.x > If you have kept the old installation with the new gpc, you will have > such kind of troubles. Notably DJGPP.ENV has been changed to look to > the > new directory structure and files like djgpp.djl and specs. have been > changed and moved from %DJGPP%\lib to the abovementioned directory. If > both old and new versions of these files are there, the wrong one is > selected ! > > -- > 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

gpc-libc6
by Victor R. Ruiz 13 Jul '98

13 Jul '98

Hello: I've been trying to compile this file in gpc-2.0.i486-linux.tgz on my RedHat 5.0 Â· Â· Â· Â· program Trying; begin writeln('Hello'); end. Â· Â· Â· Â· But I get "ld: cannot open crtbegin.o: No such file or directory" I've modified /etc/ld.so.conf, /etc/profile (LD_LIBRARY_PATH) and run ldconfig, but still can't compile. What's wrong? Let's see: -rwxr-xr-x 1 root root 50500 Nov 20 1996 gpc [root@MicroMAT bin]# ldd gpc libc.so.5 => not found It would be nice is someone could generate the glibc2 of gpc -I can't compile large files (i.e. kernel) due to hardware failure-. If my problem is not this, please help me. Thanks, --------------------------------------------- VÃctor R. Ruiz rvr(a)idecnet.com AgrupaciÃ³n AstronÃ³mica de Gran Canaria Sociedad de Meteoros y Cometas de EspaÃ±a AsociaciÃ³n de Variabilistas de EspaÃ±a - AVE info.astro http://www.astrored.org/infoastro http://ccdis.dis.ulpgc.es:8086/AAGC/aagc.html ---------------------------------------------

2 1

egcs
by Alexander V. Voinov 13 Jul '98

13 Jul '98

Dear GNU Pascal authors, Would you be so kind to release a version for egcs-1.0.x? In our institute we need to combine together pieces written in pascal and fortran and use egcs-fortran. Thank you in advance. Alexander

3 3

Re: LongestReal problems
by Frank Heckenbach 12 Jul '98

12 Jul '98

Marius Gedminas wrote: > I have written an expression parser and evaluator in Borland Pascal and I do > not use calculators any more (besides most of them do not have 18 digit > precision, not to mention another functionality). In the past I have relied > on BP run-time system to show only `accurate' (I hope you understand what I > have in mind ;) digits and it would be very great if I could rely on GPC too. > I do not request this to be the default behavior, but I would want to know of > a way to achieve it. The file float.h contains a number of useful constants, e.g. {FLT,DBL,LDBL}_MANT_DIG for the number of digits is the internal radix, and even {FLT,DBL,LDBL}_DIG for the number of decimal digits. (You may have to generate a correct version with enquire -- e.g., mine had the same values for long reals as for reals. I wonder if the GCC installation shouldn't do this automatically.) So, there's only the problem how to get the constants into a Pascal program: - Directly including the file doesn't work because of the C comments in it. (BTW, how about an option for the Pascal preprocessor to accept C comments? AFAICS, they can't occur in a legal Pascal program, anyway.) - One could write a small C wrapper, as always. - The GPC installation could Pascalify this file, i.e. remove or Pascalify the comments, remove the "F" and "L" postfixes from some numbers, and perhaps translate the defines into constants and make a unit out of it. This does not seem very difficult to do. I think the following sed script should do the job -- at least it does on my machine (sorry for the long line ;-): sed 's,/\*,{,;s,\*/,},;/^#undef/d;/FLOAT_H/d;s/float\.h/Automatically generated from &/;s/#define[[:space:]]*$[A-Za-z0-9_]*$[[:space:]]*$[-+0-9.Ee()]*$[FfLl]\?$/const \1 = \2;/' The resulting declarations could be merged with the RTS, e.g. by including them into into gpc.pas which contains most RTS declarations. So, we only have to tell the makefiles to do this, and then, I think, it would be the best solution. Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

RE: EFLIB as class library for Object-Pascal
by Johan Larsson 12 Jul '98

12 Jul '98

Hi Frank and Everyone, Sorry for the late reply, but I had better wait for the legal matters to settle. There are now news for those that are interested in EFLIB as a free Object-Pascal R&D cross-platform. EFLIB prototype 6 is my ongoing master thesis and research project seen at: http://ftp.sunet.se/EFLIB/Introduction.html http://ftp.sunet.se/Documentation/Technology/ [ In short to newcomers: it is all about flexibility, reuse, object-orientation, data structures, cross-platform technique, aesthetics, mathematics, numeric, generic programming and GUI/HCI. We still need collaborators, especially for database support and CORBA. ] Frank Heckenbach wrote 980507: > I appreciate that it will be free software. However, due to the > recent creation of the NPL, MPL and other more or less compatible > free licenses, I'm a bit wary that it will really be a GPC compatible > license. I looked at the license mentioned above, but I'm not a > lawyer :-), therefore I'd like to see an official statement > confirming the possibility to combine it with GPL/LGPL licensed > software (i.e. to use and distribute without conflicting with > either of the licenses). I hope this will be possible. The new license agreement should be fully compatible with GNU GPL (but maybe need some more adjustments) and is according to Richard Stallman fully compatible with GNU LGPL. Peter has helped me to adjust it too. See for yourself at: http://ftp.sunet.se/EFLIB/Legal/License/ > GPC is also about platform independence and easy to integrate with > other languages, so this could be a good combination. :-) Indeed - since EFLIB, with help from Miroslav Kharchuk and Michael Van Canneyt, will support Delphi VCL though built on top of a much more modern GUI cross-platform technology, we can actually create a complete FREE platform for Object-Pascal development! > These things are actually planned for GPC: > > - Properties > - Classes > - Exception handling Frank, this is excellent! These things are all you need for EFLIB to run natively under both GNU and FPK Pascal. Please inform me about the progress! I'd be happy to deliver a standard framework / class library for your excellent compiler. I offer you the ability of changing EFLIB designs according to your personal preferences -- but I would appreciate to hear all your comments ASAP since the architecture must settle soon. Please direct them to: eflib-developers(a)acc.umu.se. Yours Sincerely, Johan Larsson <jola(a)csd.uu.se> PS. Please CC to my mailbox - I cannot subscribe due to the flow of incoming messages. Sernanders vÃ¤g 8:241 - SE-752 61 UPPSALA - SWEDEN Phone +46-18-460046 - WWW http://www.csd.uu.se/~jola/ Also, see EFLIB on the Internet at http://ftp.sunet.se/EFLIB/Introduction.html

1 0

Re: LongestReal problems
by Peter Gerwinski 11 Jul '98

11 Jul '98

Hi, Marius! Let's rather continue this discussion on the list. Be invited to bounce my article there if you reply publicly. > Perhaps in the distant future `LongestReal' will have greater precision > than `Extended' ;) Yes, I expect that too. That's why we have `LongestReal' as an alias for `LongReal' (= `Extended'). > I understand that. But how can I determine the precision of data in a > portable way? I don't know right now, but it should be possible. With high probability, someone on the list knows a way. > The goal I'm trying to achieve is to get the value of a real > number to a string in a not-scientific notation with highest possible > precision. You can't do it this way. In order to express some numbers represented in one system (say, the binary system) you need an infinite number of digits to express it in another system (say, the decimal one). 1/3, for instance, is a finite fraction in a system based on 3. > [...] > I agree with the first half: BP should also output 70 digits (add some > zeroes, for example). Zeros would be intuitive, but simply wrong in most cases. > I see that I should have asked this question in another way: how to get > decimal representation of a real number with maximum precision. You can't without loss of precision. A hexadecimal representation would do it. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/

2 1

LongestReal problems
by Marius Gedminas 10 Jul '98

10 Jul '98

From: Marius Gedminas <mgedmin(a)pub.osf.lt> To: gpc(a)hut.fi Cc: Bcc: Subject: LongestReal problems Reply-To: Hi, developers! DJGPP version of GPC-980511 complains when I try to use ArcTan function on LongestReals (in fact is is `ld', not `gpc', which complains). The error message is as follows: c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0xd):rts-emath.c: undefined reference to `tanl' c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0x29):rts-emath.c: undefined reference to `tanl' Another (unrelated) problem: let's say we have a source like this: program StrangeLongReals; { This compiles both under GPC and Borland Pascal } {$IFNDEF __GPC__} {$N+,E+} {$ENDIF} var R: {$IFDEF __GPC} LongestReal {$ELSE} Extended {$ENDIF}; begin R := 0.123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } R := 0.1234512345123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } end. When compiled with Borland Pascal I get the following output: 1.23451234512345E-0001 0.123451234512345000 1.23451234512345E-0001 0.123451234512345123 And GPC version gives: 1.234512345123450e-01 0.1234512345123449999978669759571270816137668263830656896932817737042602 1.234512345123451e-01 0.1234512345123451234478368405878757685782057823543386991840842994341343 I don't know if this is a bug or a feature, but I would prefer the behavior of BP. Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

2 1

unsubscribe
by dtroeger＠ix.netcom.com 10 Jul '98

10 Jul '98

Please unsubscribe me --

1 0

GPC compiler errors
by Thamm, Russell 09 Jul '98

09 Jul '98

I recently installed Gnu Pascal (DJGPP-MSDOS) and was appalled at the fragility of the compiler. I had enormous problems with procedural-parameters, file types and proper accessing of types defined in Units. Eventually, I downloaded the latest alpha (gpc-980511.i386-pc-msdos-djgpp.zip) and am delighted that this version will at least compile my program. If someone could tell me where to get the crtf.o file, the linker keeps asking for, I might even be able to see if the code actually runs. The compiler still apparently has problems with type definitions in units. I have a program that uses two units: 1) pktdefs - type definitions 2) frames - unit to handle access to large data files The frames unit declares an object that has a method: function GetNextDataPkt(VAR pkt : PacketPtr) : BOOLEAN; The type PacketPtr is declared in pktdefs and my main program and frames USE pktdefs. When my main program tries to call GetNextDataPkt, I get a compiler error: Error: type mismatch in argument 2 of `Tframes_Getnextdatapkt' The code in question is: while MyFrames.GetNextDataPkt(pp) do If I move the PacketPtr declaration into frames.pas, the compiler error disappears. I don't know how there can be an error in argument 2 of a function with only one parameter. Perhaps the return value is argument 1. However, the compiler apparently thinks that the type "PacketPtr" used in frames is different from "PacketPtr" used in the main program, even though both "import" the declaration from the same unit. Russell Thamm

3 2

Re: gpc on AIX: troubles!
by Frank Heckenbach 07 Jul '98

07 Jul '98

Nick Cremelie wrote: > > A clever idea! The problem is to get the parameters right. The > > above work for text files, but they're a bit unusual (and I wonder > > why GPC uses them for Input and Output). > > So do I. But if I set them to e.g. 256,1 ("large" buffer, type text > files), it didn't work. So I just took the values as for Input, Output). The "buffer" is not a temporary buffer like in BP (if you know that), but Standard Pascal's file buffer. For text files, this must be a char, i.e. 1 byte, or 8 bits (where bits are indicated by the bit with value 2 in the flags), otherwise the routines won't work properly. > I'm not familiar with assembler listings, but I definitely see _p_initfdr > somewhere in there. But don't forget that Input and Output are always > initialized with that function. That's different as their _p_initfdr calls are done from another RTS function, not from the program. OK, I now have a suspicion what's wrong. I think both problems are related, and they're not really I/O problems, but due to the fact that the initialization code of the program is not executed. Please try the following things: - writeln (s.capacity), where s is a global string variable. If my theory is correct, it should write 0 or some nonsense value, instead of the correct capacity. That's why a wrong value will be passed to the read routine, and the varargs are not guilty. - s.capacity := 255 (or whatever your capacity is) before the read. Then the read should work. This can serve as a workaround, just like the explicit InitFDR, until the real problem is found. - Move all the code and (especially!) the variable declarations into a procedure. Then, both issues should be OK. - Try a unit (or module) with initialization code, e.g. the following: file foo.pas: program foo; uses bar; begin end. file bar.pas: unit bar; interface implementation to begin do writeln('Hello, world'); end. Then `gpc foo.pas bar.pas' or `gpc --automake foo.pas', and see if it writes anything. - Try your test program (one with a global file variable) with RTS debugging. That's a little more complicated: - change into p/rts and `make clean' - change back into the main (GCC) source directory and `make LANGUAGES="pascal" CFLAGS="-O2 -DDEBUG"' Perhaps you'll get an error about an undefined `_p_rts_version' in rts-rt0.c -- in this case replace this by `gpc_rts_version'. I hope you won't get any other errors. - install GPC - compile your program with the new GPC - run it with the command line options `-Grts -ddddd', and send me the output Now for the reason why the initialization code of the program is not executed. I think I have got bad news: As far as I understand the remarks in the GCC doc (see `info -f gcc -n Initialization'), this feature is not needed in C, and therefore has not been ported to all platforms. :-( To confirm that, I checked config/rs6000/rs6000.h (which is included by the config/rs6000/aix*.h files), and it contains: #define ASM_OUTPUT_CONSTRUCTOR(file, name) #define ASM_OUTPUT_DESTRUCTOR(file, name) IOW, it just ignores the initialization and finalization code! Great, isn't it? :-( So, what can be done: - Implement this feature for your platform. But since you don't program in assembler, I don't suppose you know how to do this. I don't, either, but I suppose it's even more difficult than "ordinary" assembler programming... - Find someone to implement it, perhaps in the GCC mailing lists or newsgroups. But seeing how much most C programmers "love" Pascal, I wish you best luck... - Do it otherwise. Peter and I already discussed how to implement the initialization and finalization code with constructors and destructors. Actually, this was last week, and we were thinking about long-term ideas. We didn't expect it would come back to us so soon... Since most of this work would probably have to been done by Peter, I can't say how soon or late he can do this, but I fear, not so soon... Here's another possible workaround: Don't use units or modules with initializers or finalizers (if you need them, put the code into procedures, and call them manually). For the program's initialization, insert the following into your program's declarations: { Dirty workaround for GCC bug } var p_collect_flag : asmname '_p_collect_flag' Integer; procedure program_initialize; asmname '__init_program_Foo'; where Foo is the name of your program with the first and only the first letter capitalized, no matter how you capitalized it in the "program foo;" declaration. Immediately after the main "begin", add: p_collect_flag := 0; program_initialize; That's not very nice, I know, but it might work... To test it, try the following program. It should output 0 and 42. program foo; { Dirty workaround for GCC bug } var p_collect_flag : asmname '_p_collect_flag' Integer; procedure program_initialize; asmname '__init_program_Foo'; var s : string (42); begin { Simulate on my platform the missing initialization and test it } s.capacity := 0; writeln (s.capacity); { Now do the initialization manually } p_collect_flag := 0; program_initialize; { Test it } writeln (s.capacity); end. The only thing I can do to simplify this is to let the RTS clear the p_collect_flag. That's what I did now, so with the next GPC version, it could work without the two lines referring to p_collect_flag. > > Also, did you get any warnings (especially of type mismatches and > > the like) when compiling the RTS? This might indicate some non-portable > > type conversions in the C files. > > These are all the warnings I got during the stage2 build for c and > pascal using the stage 1 gcc-2.8.1 compiler (I didn't really worry > about them, they did not seem too severe): Most of the warnings are (a) known, (b) unrelated to the problem and (c) fixed in the next version. :-) Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: gpc on AIX: troubles!
by Frank Heckenbach 06 Jul '98

06 Jul '98

Nick Cremelie wrote: > > Not really with bindings, but anyway: There's a known bug "On IRIX work > > stations, _p_initfdr() must be called manually" on the To-Do list. > > So, I'm adding AIX there. I don't know anything about these architectures, > > but I agree that fixing this would be a good idea... :-/ > > I don't see how I can call _p_initfdr() manually. From within the > Pascal program, the compiler complains when I call that function. When > I try to call InitFDR (defined in p/rts/gpc.pas I thought), the compiler > says: > > txtfile.pas: In function `Assign': > txtfile.pas:16: undeclared identifier `Initfdr' (first use this function) > txtfile.pas:16: (Each undeclared identifier is reported only once > txtfile.pas:16: for each function it appears in.) > > So how do I call initfdr manually??? Yes, the above description for the work around is a bit too simplistic. If you want to call it from Pascal, you have to copy the declaration of InitFDR from gpc.pas, or add an "uses gpc;" to your program (however, the latter is not yet completely worked out, so it may cause some name conflicts). > As you will recall, I had problems with gpc on AIX when opening > files. I made a little change in rts-file.c: I replaced line > 370: > > _p_generic (701); /* FDR not initialized */ > > with > > _p_initfdr(File,filename,8,0xf); > > This means: if m_SIZ(File) == 0 (indicating that _p_initfdr was > not called), I call it with a standard buffersize and flags). > This enables me indeed to open files for reading and writing! > However, I have no clue about the impact of this change. A clever idea! The problem is to get the parameters right. The above work for text files, but they're a bit unusual (and I wonder why GPC uses them for Input and Output). The following are the parameters GPC uses for the different kinds of files -- however, they're subject to change in future versions, but not too soon (i.e. not until GPC version 2.1): Text files (text): 1, 1 Typed files (file of foo): Sizeof(f^), 0 Direct typed files (file [bar..baz] of foo): Sizeof(f^), 16 Untyped files (file) (BP extension): 1, 64 For "external" files, i.e. those declared in the program header, add 4 to the last parameter. The second parameter is actually the internal file name (i.e. the name of the variable as declared in the program), but it's only used for the Standard Pascal feature of asking the user for a name for file "foo", and for some error messages. But it seems strange to me in the first place why _p_initfdr() isn't called automatically -- after all, the compiler (util.c, function init_simple() generates code to do so). Could you generate an assembler output of your Pascal program (gpc -S), and check if it contains some calls to _p_initfdr(), and if so, what parameters are pushed before it. > But then we noticed something else: reading a string (string[255]) > with readln (from file or stdin) always returned an empty string, > although eoln and eof are set appropriately (so it is actually > reading the file!). We checked and noticed that the argument maxlen > to _p_reads in rts-rdsub.c is always zero. Question: would this be > because va_arg (which gets maxlen from a variable argument list) doesn't > work probably, or because the variable argument list is not set > properly when calling _p_read in rts-read.c ? Could you please check which parameters are pushed before the call to _p_read() in the assembler code of your program (or just send me the assembler file if that's easier to you)? For another test, you could check the value of s_maxlen in the READ_STRING macro in rts-rdinc.c (with some printf) and see if it's already wrong there. (I suppose it is, but one never knows...) Also, did you get any warnings (especially of type mismatches and the like) when compiling the RTS? This might indicate some non-portable type conversions in the C files. Perhaps really the varargs are to blame -- I don't know much about their inner workings. I intend to get rid of them, anyway. If they're the problem here, this might be a reason to get rid of them even earlier than planned... Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: installing gpc on SGI under Irix5.3
by Kevin A. Foss 05 Jul '98

05 Jul '98

On Sun, 5 Jul 1998 12:13:51 +0200 (MEST), Peter Gerwinski wrote: >According to Robert P. Ewing: >> I get: >> gpc: installation problem, cannot exec 'as': No such file or directory. >> >> Looking in the /usr/local/bin directory shows I have gpc, but nothing >> else (no as, no ld...). > >Your system's `as', `ld' etc must be installed somewhere (e.g. in >/usr/bin); please try to find out their place. It is also possible >to use the GNU versions of those programs; in that case you have to >`./configure' GPC with `--with-gnu-as' and/or `--with-gnu-ld' and >to provide the corresponding packages. I haven't used an IRIX machine in years, and even then it was quite brief. However it is important to note that SGI led the pack as far as commercial vendors un-bundling parts of their UNIX implementations. Most notably, such rarely used items as the development tools. :) With 5.3 they don't even ship the C headers and runtime libraries, so I wouldn't be surprised if "as" wasn't in the base OS either -- or at least not in the default install. Most versions of gcc for IRIX on the net use gnu-as from what I can tell. Hopefully someone more familiar with IRIX knows better. 'ld' should definately be someplace on his system. Try out this site for IRIX freeware (including gcc information): http://reality.sgi.com/ariel/freeware This site has the SGI/IRIX faqs: http://www-viz.tamu.edu/~sgi-faq/ Again however, GCC for IRIX 5.3 is DOA unless you bought the development disc -- which is going to make it difficult to recompile GPC to use gnu-as. I would suggest the original poster ask his system administrator what exactly he can expect to find on his system. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

gpc on AIX: troubles!
by Nick Cremelie 05 Jul '98

05 Jul '98

Hello all, I downloaded the most recent version of gpc, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ (gpc-980511) and I also got gcc-2.8.1. I tried to make gpc on an RS/6000 with AIX4.1.4, using gnu make 3.76. This is the result at a certain stage during the make: ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -O2 -I. -I../.. -I/backup/gnu/gcc-2.8.1/p/rts/.. /.. -I/backup/gnu/gcc-2.8.1/p/rts/../../config rts-base.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 6 gmake[1]: *** [rts-base.o] Error 1 gmake[1]: Leaving directory `/backup/gnu/gcc-2.8.1/p/rts' gmake: *** [libgpc.a] Error 2 Again, an Internal Compiler Error seems to be the problem, just as it was the case with gpc-971001. My debugger can't find much useful information in the core. A "where" just shows me this: __start() at 0x100001c8 How do I solve this problem???????????? Please reply by mail as I'm not yet subscribed to the mailing list. Nick Cremelie

4 12

Download the doc...
by Spidey 04 Jul '98

04 Jul '98

Hi! I'm sorry if I fill you're mailboxes for a stupid question but, is it possible to download the doc in one big file instead of borwsing it always online? Thanks! -- Spidey ________________________________________ | Imagine a good steak (8 oz)... | | | | Then imagine 45 to 50 persons sitting | | around you with there plate empty. | | | | Then remember that you could replace | | your meat by enough cereal to feed all | | these 50 persons... | | | | Think of it twice when you'll feed your| | belly with sick meat. | | | | Source: Small diet for a small planet, | | 1980, Frances Moore. | \----------------------------------------/

2 1

__OS_DOS__ symbol
by Frank Heckenbach 04 Jul '98

04 Jul '98

Hi, all! While Peter, The Chief and I were discussing some issues about GPC on Dos like systems, we found that it seems like a good idea to let GPC pre-define the symbol __OS_DOS__ on all such platforms automatically. This would make it easy to do an {$ifdef __OS_DOS__} around things that are different on these systems, e.g. the different directory separators ('\', not '/') and path separators (';', not ':'), or the different way of printing (writing to a priter device like 'lpt1', not calling a printer spooler like 'lpr'). Up to now, one has to use a series of ifdefs which is not very convenient, error-prone, and a maintenance problem when new such platforms are "created". A predefined __OS_DOS__ would reduce this maintenance to one place within the compiler. So, what I'm asking you is (a) if anyone would see any (hidden) problems with doing so -- perhaps an already existing different use of the symbol __OS_DOS__ --, and (b) which platforms this should be defined on exactly: I looked at the GCC sources to find out which platforms use ';' as a path separator, these are: ./config/i386/xm-dos.h ./config/i386/xm-go32.h ./config/i386/xm-mingw32.h ./config/i386/xm-os2.h ./config/i386/xm-vsta.h ./config/winnt/xm-winnt.h Searching for '\' as a dir separator yields: ./config/i386/xm-cygwin32.h ./config/i386/xm-dos.h ./config/i386/xm-mingw32.h ./config/i386/xm-os2.h ./config/winnt/xm-winnt.h I'm a bit surprised that the lists are different, but that's probably by mistake, e.g. the go32 (i.e. DJGPP Dos extender) platform surely has a '\' dir separator. (I'm aware of the fact that most, if not all, DJGPP routines do an automatic translation from '/' to '\'; that's not the issue here.) So, I hope it's correct to assume that the union of both sets is a complete list of (currently supported) Dos-like systems: ./config/i386/xm-dos.h ./config/i386/xm-go32.h ./config/i386/xm-mingw32.h ./config/i386/xm-cygwin32.h ./config/i386/xm-os2.h ./config/i386/xm-vsta.h ./config/winnt/xm-winnt.h Any comments? BTW, what's vsta? Regards, Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

GPC troubles on AIX (cont'd)
by Nick Cremelie 03 Jul '98

03 Jul '98

Hi again, As you will recall, I had problems with gpc on AIX when opening files. I made a little change in rts-file.c: I replaced line 370: _p_generic (701); /* FDR not initialized */ with _p_initfdr(File,filename,8,0xf); This means: if m_SIZ(File) == 0 (indicating that _p_initfdr was not called), I call it with a standard buffersize and flags). This enables me indeed to open files for reading and writing! However, I have no clue about the impact of this change. But then we noticed something else: reading a string (string[255]) with readln (from file or stdin) always returned an empty string, although eoln and eof are set appropriately (so it is actually reading the file!). We checked and noticed that the argument maxlen to _p_reads in rts-rdsub.c is always zero. Question: would this be because va_arg (which gets maxlen from a variable argument list) doesn't work probably, or because the variable argument list is not set properly when calling _p_read in rts-read.c ? Anyone any idea about what's going wrong?? If I hard code maxlen=256 then everything runs (on a simple test at least; again, the impact of this setting is not clear and it may be a dangerous setting!) We've come that far now, I hope we can eventually get gpc running on our aix boxes...... Nick

1 0

Re: gpc on AIX: troubles!
by Frank Heckenbach 03 Jul '98

03 Jul '98

Klaus Espenlaub wrote: > > To continue: I resumed gmake and > > now the rts part of p has been built! I got a few errors which did not > > cause s stop of gmake, I'm not sure if they are a problem (should I > > worry about them?): > > I would worry about them. But it's possible that they go away after you > installed gpc and re-do the gpc compilation. You can check if something is > wrong with the gpc driver program if you start it with option -v for the > program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" > or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. > Similarly for BITS and WORD. > > I wouldn't trust gpc until there are no #error lines left. True. When these things are not defined, some of the RTS will not work realiably. I think the problems are due to the fact that a previously installed GPC was used to compile the RTS. I think (hope) that this will be fixed in the next version. > Part of the > problem seems to be that the automake feature doesn't pass the error code > of a failed sub-compile command back to the calling make program. > > Peter: can you put this on the automake todo list? It is already on the To-Do list, namely under "Fixed Bugs". :-) IOW, it will work this way in the next version. Nick Cremelie wrote: > ...but: txtfile and binfile both crash with: > > ?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701) > > Now what's that??????? > > I suppose it has something to do with the "bind" functionality in gpc > for binding an external file to a variable??? Not really with bindings, but anyway: There's a known bug "On IRIX work stations, _p_initfdr() must be called manually" on the To-Do list. So, I'm adding AIX there. I don't know anything about these architectures, but I agree that fixing this would be a good idea... :-/ Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: gpc on AIX: troubles!
by Klaus Espenlaub 02 Jul '98

02 Jul '98

Nick Cremelie wrote: > And this is what gdb shows me (I think it's pretty much the same) > ---begin--- > GDB 4.16 (rs6000-ibm-aix4), Copyright 1996 Free Software Foundation, Inc... > Core was generated by `gpc1'. > Program terminated with signal 6, IOT/Abort trap. > #0 0xd0077eac in raise () > (gdb) bt > #0 0xd0077eac in raise () > #1 0xd0019a74 in abort () > #2 0x1004f258 in output_epilog (file=0xf013f4c0, size=-1) at rs6000.c:4027 > #3 0x10142664 in final_end_function (first=0x0, file=0xf013f4c0, optimize=-1) > at final.c:1151 > #4 0x10005548 in rest_of_compilation (decl=0x20080a2c) at toplev.c:3647 > #5 0x100b8ce4 in finish_function (nested=0) at gpc-decl.c:8734 > #6 0x1018dbc0 in yyparse () at parse.y:6628 > #7 0x10003084 in compile_file (name=0x0) at toplev.c:2494 > #8 0x10006624 in main (argc=15, argv=0x2ff227cc, envp=0xffffffff) > at toplev.c:4377 > #9 0x100001f4 in __start () > ---end--- > > Apparently there's something not right in rs6000.c. What do you think? I haven't read the previous stack dump closely enough, I think. And I think your analysis is correct. The code around line 4027 in rs6000.c looks like this: /* Language type. Unfortunately, there doesn't seem to be any official way to get this info, so we use language_string. C is 0. C++ is 9. No number defined for Obj-C, so use the value for C for now. */ if (! strcmp (language_string, "GNU C") || ! strcmp (language_string, "GNU Obj-C")) i = 0; else if (! strcmp (language_string, "GNU F77")) i = 1; else if (! strcmp (language_string, "GNU Ada")) i = 3; else if (! strcmp (language_string, "GNU Pascal")) i = 2; else if (! strcmp (language_string, "GNU C++")) i = 9; else abort (); fprintf (file, "%d,", i); So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below. oops, just noticed that I forgot to add useful options to diff. I hope that the following works for you, Peter. If not, drop me a note. I got to run now, and probably won't be back till 12:30 CEST. Klaus 115,123d114 < * < * rs6000.c calls abort() if this is "GNU Pascal" :-) < * < * I have modified rs6000.c. Since "Pascal" is a person's name < * like "Ada" it has the right to be written in the same manner. :-) < * - PG < * < * Sigh, I don't want to change rs6000.c; I will inform Kenner to change < * it in the next release. 125,127d115 < #ifdef _IBMR2 < char *language_string = "GNU PASCAL"; < #else 129d116 < #endif /* Sigh */

2 3

unsubscribe
by jgouv＠pop03.ca.us.ibm.net 30 Jun '98

30 Jun '98

unsubscribe

1 0

unsubscribe
by csap00jp 28 Jun '98

28 Jun '98

Unsubscribe me please

1 0

SizeOf bug
by Maurice Lombardi 27 Jun '98

27 Jun '98

Hi all, When looking to a redent discussion on the fpk-mailing list with this subject, I have tried to make the same tests on gpc. I have found a bug in gpc which has nothing to do with the subject of the discussion. Working on plain dos djgpp with gpc-980511. The program is: program size_bug; type Time = object h,m,s:byte; constructor init; destructor done; virtual; end; var OT:Time; constructor Time.init; begin end; destructor Time.done; begin end; begin OT.init; writeln(SizeOf(OT)); end. when compiling it says Abort! with the message: Reading specs from f:/djgpp/lib/gcc-lib/djgpp/2.81/specs gpc driver version 2.81 executing gpc version 2.8.1 f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 size_bug.pas G:/ccba5tpj GNU CPP version 2.81 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/djgpp/contrib/grx23/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.81/include $DJDIR/include End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc1.exe G:/ccba5tpj -quiet -dumpbase size_bug.pas -version -famtmpfile=size_bug.gpc -o G:/ccca5tpj GNU Pascal version 2.81 (djgpp) compiled by GNU C version 2.8.1. size_bug.pas: In function `Time_Init': size_bug.pas:13: `with' element is of wrong type Abort! It is the identifier Time which causes the problem. All becomes correct if it is replaced everywhere by Tim. As far as I know time is not a reserved word, and anyway you have allowed to redefine nearly all identifiers. ??? (otherwise gpc has the correct behaviour with respect to the purpose of the test: it bangs under CWSDPMI for dereferencing uninitialized pointer if OT is not initialized before computing SizeOf(OT), and gives a nonsense result when working in a WIN 3.11 DOS box which does not catch this illegal memory addressing, but this behavior is different from BP) -- 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

gpc for aix
by Nick Cremelie 25 Jun '98

25 Jun '98

Hi all, After a few days work, I finally got gpc compiled on a powerpc based RS/6000 with AIX4.1.4. I thought I'd first try it with a simple program called littletest.pas: program littletest; var i,j: integer; begin i:=1; j:=2; writeln('Sum is ',i+j); end. Well, this is the result: $ gpc --verbose littletest.pas Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/specs gpc version 971001(2.7.2.1) /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -Asystem(unix) -Asystem(aix) -Acpu(powerpc) -Amachine(powerpc) -D__CHAR_UNSIGNED__ -D_ARCH_PPC littetest.pas /tmp/ccQLxsya.i GNU CPP version 971001(2.7.2.1) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/powerpc-ibm-aix4.1.4.0/include /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc1 /tmp/ccQLxsya.i -quiet -dumpbase littletest.pas -version -famtmpfile=littletest.gpc -o /tmp/ccQLxsya.s GNU PASCAL version 971001(2.7.2.1) compiled by GNU C version 2.7.2.1. gpc: Internal compiler error: program gpc1 got fatal signal 6 Needless to say, I get a beautiful coredump out of that which my debugger dbx can't read very well, but anyways this is the result of a "where": raise(??) at 0xd0077eac abort() at 0xd0019a70 emit_stack_save(??, ??, ??), line 887 in "explow.c" init_main_program_rtx(), line 1588 in "util.c" yyparse(), line 545 in "parse.y" compile_file(name = "/tmp/ccQLxsya.i")line 2232 in "toplev.c" main(argc = 9, argv = 0x2ff22b94, envp = 0xffffffff), line 3931 in "toplev.c" If anyone would have any idea on how to solve this, it would be greatly appreciated. Please reply by mail as I am not yet subscribed to this mailing list! Nick Cremelie

2 1

ld problem under RH 5.0 with gpc rpm
by dtroeger＠ix.netcom.com 25 Jun '98

25 Jun '98

I have installed (Redhat 5.0) gpc-2.0-1.i386.rpm, but running it on any pascal program produces an error: ld: cannot open crtbegin.o: No such file or directory (If I use gpc -S hello.pas, I _do_ get successful compilation; the problems clearly arise later.) Can anyone point me in the right direction on this? Specifically, are there configuration steps which must be taken _after_ rpm has completed its installation? Thanks, Doug Troeger

2 1

unsubacribe
by Dr Montaz Ali 25 Jun '98

25 Jun '98

Unsubscribe me please ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Montaz Ali, Ph.D | Email : mali(a)pc55.cam.wits.ac.za Dept. of Computational & Applied | Tel :(011)-716-3969 (W) Mathematics, | Tel :(011)-403-0250 (H) The University of Witwatersrand | Fax :(011)-403-9317 (W) Private Bag - 3, Wits - 2050 | Johannesburg, Republic of South Africa| ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Test files (was: No crt0.o with cygwin32 version solved)
by Frank Heckenbach 24 Jun '98

24 Jun '98

Hans Lunsing wrote: > I commented out iso.pas, because it gave errors: > > iso.pas: In function `program_Iso': > iso.pas:13: parse error before `Operator' > iso.pas:13: comma missing after identifier `Uses' > iso.pas:13: parse error before `Shl' > iso.pas:13: comma missing after identifier `Uses' > iso.pas:13: parse error before `;' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: pointer domain type undefined > iso.pas:14: parse error before `Uses' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: parse error before `Value' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: parse error before `Absolute' > iso.pas:21: comma missing after identifier `Uses' > iso.pas:21: parse error before `(' > iso.pas:21: comma missing after identifier `Uses' > iso.pas:21: parse error before `Operator' > iso.pas:21: extra comma following id_list This file seems to be in the wrong directory. It must not be compiled with --borland-pascal, but with --extended-pascal. > That was not the case in GPC for Cygwin32 b17.1. Harakiri.pas in = > test\misc gave errors as well: > > harakiri.pas: In function `Paramstr': > harakiri.pas:40: condition must be of Boolean type This message is correct. The test program declares some obsolete external functions (now built-in), and it even does it twice (???) and wrong (it tries to use an integer as a boolean -- wrong language ;-). If GPC didn't complain before, that was a bug. Removing all the ParamCount and ParamStr declarations (C, external and Pascal) gets rid of this error. > harakiri.pas: In function `Atoi': > harakiri.pas:54: warning: cast to type of different size > harakiri.pas:54: invalid lvalue in address expression Another bug in the test file. It tries to round a real number by "casting" it into an integer which is AFAIK wrong. Replace "integer" by "round" in this line, and the program works. (Of course, one could also get rid of atoi altogether, and use ReadStr instead...) Oh yes, and getpid and kill should also be declared only once. -- Seems like this test suite really is outdated... Well, here's the corrected program, just in case anyone cares: (* Commit suicide with a signal of your choice *) program Harakiri(output); (* I assume these are in your C library: * pid_t getpid(void); * int kill(pid_t pid, int sig); * and pid_t is really int *) {$X+} type pid_t = integer; (* We really should get some standard libraries <sigh> *) function getpid: pid_t; C; function kill(pid: pid_t; sig: integer): integer; C; var signal: Integer; begin if (ParamCount < 1) then writeln('Usage: ', ParamStr(0), ' [signal number]') else begin ReadStr (ParamStr(1), signal); kill(getpid, signal); end end. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

No crt0.o with cygwin32 version solved
by Hans Lunsing 23 Jun '98

23 Jun '98

Hi, Regarding my problem with the linker not able to open crt0.o: it is solved. But oh, to get the system working! Peter Gerwinski wrote me: >Not being a CygWin32 expert I can only recommend to double-check whether >you have installed the corresponding (beta-??) version of CygWin32 for >your version of GPC. It must contain `crt0.o'. > >Hope this helps, :-/ It did indeed. I had installed the beta 18 version of Cygwin32(it was compatible with 17.1, so I could use it with the GPCWIN version for 17.1), but only the usertools. After I installed the complete C development kit, it worked. That is to say, after a while. It proved rather difficult to let the compiler and the linker both find the files they needed. The environment variables mentioned in GPC.HLP did nothing. I had to point the environment variabele GCC_EXEC_PREFIX to the Cygwin32 directory containing crt0.o, to use the -B (directory for binaries) and -L (directory for libraries) switches on the GPC command line, and to point the DOS path to the compiler itself and to the Cygwin32 binaries (assembler and linker). The make files I had to adjust accordingly. But after some hours of experimenting it worked as it should do! My setup batch file for the new version working with Cygwin32 b18 is now as follows (assuming I installed Gpcwin32 in c:\gpcwin32): set GPC_EXEC_PREFIX=c:\gpcwin32\lib\gcc-lib\i386-cygwin32\2.7.2.1\ set GCC_EXEC_PREFIX=c:\gpcwin32\lib\ set PATH=%PATH%;c:\gpcwin32\bin and I use the following command line: gpc -B%GPC_EXEC_PREFIX% -L%GPC_EXEC_PREFIX% (well, I use a 4DOS alias instead, that's easier!) As regards makefiles, this is now my makefile for the Borland_Pascal test sources (without the comments): #-------------------------------------------------------------------- # c:\bin\sh.exe must exist! .SUFFIXES: .p .pas .o .h .pas.o: $(PC) -c $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< PC = gpc DIRFLAGS = -B$(subst \,\\,$(GPC_EXEC_PREFIX)) -L$(subst \,\\,$(GPC_EXEC_PREFIX)) ALLPFLAGS = $(PFLAGS) -g -O3 --automake="$(DIRFLAGS) -g -O3" EXE = .exe TESTS = abso$(EXE) asmnames$(EXE) bitmanip$(EXE) caseelse$(EXE) \ cstparam$(EXE) head$(EXE) incdec$(EXE) kohl$(EXE) \ mem$(EXE) minimax$(EXE) nohead$(EXE) objects$(EXE) \ openarr$(EXE) switches$(EXE) varrec$(EXE) voidparm$(EXE) TESTSRC = head.pas nohead.pas cstparam.pas caseelse.pas switches.pas \ bitmanip.pas incdec.pas minimax.pas mem.pas abso.pas \ asmnames.pas openarr.pas varrec.pas voidparm.pas all: bptest bptest: for x in $(TESTSRC) ; do \ rm -f a.out 2>/dev/null ; \ $(PC) $(ALLPFLAGS) $$x 2>/dev/null ; \ echo -n "$$x: " ; \ if [ -f "a.out" ] ; then ./a.out ; else echo "failed" ; fi ; \ done ; \ rm myunit.o myunit.gpi a.out 2>/dev/null ; # DOS can't run shell script dostest: $(TESTS) clean: -rm -f $(TESTS) -rm -f *.o *.gpi *.gpc distclean: clean -rm -f *~ core a.out #* *.BAK *.bak *.orig # empty install: abso$(EXE): abso.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ asmnames$(EXE): asmnames.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ bitmanip$(EXE): bitmanip.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ caseelse$(EXE): caseelse.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ cstparam$(EXE): cstparam.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ head$(EXE): head.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ incdec$(EXE): incdec.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ #iso$(EXE): iso.pas # $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< # strip $@ # :-) kohl$(EXE): kohl.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ mem$(EXE): mem.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ minimax$(EXE): minimax.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ nohead$(EXE): nohead.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ objects$(EXE): objects.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ openarr$(EXE): openarr.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ switches$(EXE): switches.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ varrec$(EXE): varrec.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ voidparm$(EXE): voidparm.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ #-------------------------------------------------------------------- A rule for making voidparm.exe had to be added, and I could run it with the command make dostest as Maurice Lombardi pointed out to me. I commented out iso.pas, because it gave errors: iso.pas: In function `program_Iso': iso.pas:13: parse error before `Operator' iso.pas:13: comma missing after identifier `Uses' iso.pas:13: parse error before `Shl' iso.pas:13: comma missing after identifier `Uses' iso.pas:13: parse error before `;' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: pointer domain type undefined iso.pas:14: parse error before `Uses' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: parse error before `Value' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: parse error before `Absolute' iso.pas:21: comma missing after identifier `Uses' iso.pas:21: parse error before `(' iso.pas:21: comma missing after identifier `Uses' iso.pas:21: parse error before `Operator' iso.pas:21: extra comma following id_list That was not the case in GPC for Cygwin32 b17.1. Harakiri.pas in test\misc gave errors as well: harakiri.pas: In function `Paramstr': harakiri.pas:40: condition must be of Boolean type harakiri.pas: In function `Atoi': harakiri.pas:54: warning: cast to type of different size harakiri.pas:54: invalid lvalue in address expression and that was also not the case in the previous version of GPC. Till so far I didn't try the DLL demo. Kind regards, Hans Lunsing Leiden, The Netherlands, e-mail jlunsing(a)doge.nl

1 0

Re: Some GPC bugs
by Frank Heckenbach 22 Jun '98

22 Jun '98

Marius Gedminas wrote: > >> 3. (I think this one is not new) `--automake' does pass all required > >> .o files to the linker if it didn't need to recompile the > >> sources. > > > >That's not new, but again a better analysis of the problem. > >In order to hunt the bug, an example program which will output > >"OK" when the bug will be fixed would be helpful. (Or do we > >already have one? I have lost overview a little ... #-) > > I never had it (overview, that is), but I do not think it is easy to write > such a program. Well, maybe... Well, it was almost perfect! :-) > First time it compiles nicely, second time ld complains about `Callsecond' > being undefined. It might be possible to write a wrapper to execute > `gpc --automake automakebug.pas' twice and output 'Ok' if the second > compilation succeeds. The test suite currently doesn't support this, but I think it's easy to achieve by just putting two copies of the main program into the test suite. This would look like the following (I just renamed the files and changed the output string): --- marius2.pas AND marius2c.pas: program Marius2; { This tests a bug in the automake mechanism. When the first program (marius2.pas) is compiled, it works well, but when the seconds program (marius2c.pas, identical to marius2.pas!) is compiled, and the pre-compiled units are already there, it fails. -- Just in case anyone wonders why there are two identical files in the test suite... } uses Marius2a; begin CallFirst; end. --- marius2a.pas: unit Marius2a; interface procedure CallFirst; implementation uses Marius2b; procedure CallFirst; begin CallSecond; end; end. --- marius2b.pas: unit Marius2b; interface procedure CallSecond; implementation procedure CallSecond; begin WriteLn('OK'); end; end. --- When I run it through the test suite, it gives "OK" for marius2.pas and an error for marius2c.pas. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Some GPC bugs
by Marius Gedminas 22 Jun '98

22 Jun '98

Hi, developers! I have successfully downloaded and compiled GPC-980511 for Linux. There still are two problems with the makefile: 1. Subdirectory /p in the gcc source directory may not be a symlink (make finds out the real directory and complains about missing `../configure') - I remember I've seen this problem reported together with a patch on the list. 2. Compiling the RTL for the first time fails because `gpc' is not found (it is still called `xgpc' at the moment) However I was unable to install RHIDE for Linux (rpm2tgz from Slackware 3.4 distribution fails with the rpm package) so I used DJGPP version to examine the following bugs: 1. GPC preprocessor outputs too many empty lines when removing text between {$IFDEF} ... {$ENDIF}. A sample program: {1} program LineNumberBug; {2} {3} {$IFDEF NotDefined} {4} This line is not compiled {5} {$ENDIF} {6} {7} begin {8} ! { Generate syntax error on line 8 } {9} end. ...>gpc main.pas main.pas: In function `program_Linenumberbug': main.pas:11: parse error before `!' ^^ should be 8 2. Procedural variables are always passed by value. program ProcBug; type TProc = procedure; procedure NoBug(X: TProc); begin { X is passed by value as it should be } end; procedure Bug(var X: TProc); begin { X is passed by value here too! } { If I tried to modify X, I would corrupt code of some procedure } end; var Tmp: TProc; begin NoBug(Tmp); { These two calls in .S file are identical } Bug(Tmp); end. 3. (I think this one is not new) `--automake' does pass all required .o files to the linker if it didn't need to recompile the sources. (Windows 95 crashed as usual and I had to retype everything from scratch. I should once again try to install RHIDE for Linux...) Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

2 3

UNSUBCRIBE
by moriaud＠drfmc.ceng.cea.fr 22 Jun '98

22 Jun '98

PLEASE UNSUBCRIBE ME FROM THIS MAILING LIST

1 0

No crt0.o with cygwin32 version
by Hans Lunsing 21 Jun '98

21 Jun '98

Hi, 1. I installed GNU Pascal for Cygwin32. When I try to compile and link a pascal source file I get the message ld.exe: cannot open crt0.o: No such file or directory (ENOENT) I know crt0.o contains the startup code for C. Where can I find that file, and if found, where do I place it so that the linker can find it? 2. I tried to run the Makefile for the borland pascal extensions with GNU Make 3.75 for DJGPP V2. It gave an error message: for x in head.pas nohead.pas cstparam.pas caseelse.pas switches.pas bitmanip.pas incdec.pas minimax.pas mem.pas abso.pas asmnames.pas openarr.pas varrec.pas voidparm.pas ; do \ rm -f a.out 2>/dev/null ; \ gpc -g -O3 --automake="-g -O3" $x 2>/dev/null ; \ echo -n "$x: " ; \ if [ -f "a.out" ] ; then ./a.out ; else echo "failed" ; fi ; \ done ; \ rm myunit.o myunit.gpi a.out 2>/dev/null ; Command line too long. make.exe: *** [bptest] Error -1 So I wonder, is this the right version of Make to use? 3. I also installed GNU Pascal for DJGPP version 2. That works fine (till now)! Hans Lunsing e-mail: jlunsing(a)doge.nl

3 2

GPC 2.1 for EGCS 1.1?
by Peter Gerwinski 19 Jun '98

19 Jun '98

Hello, Jeff! Hello, all! (I am citing everything, so the GPC list members know what we are talking about without browsing the HTML page.) On Wed, 17 Jun 1998 22:46:37 -0600, Jeffrey A Law (law(a)cygnus.com) wrote in http://www.cygnus.com/ml/egcs/1998-Jun/0628.html: > > egcs-1.1 > > The egcs project is rapidly approaching its second major release > (egcs-1.1). > > This page is meant to provide information about the current schedule > for egcs-1.1, the testing/release criteria for egcs-1.1, new features > to be found in egcs-1.1, etc. Maybe this schedule is also reasonable for the next mejor release of GPC (gpc-2.1). I don't know how realistic this is, but the list of bug reports for the latest alpha release was much shorter than for previous ones. It is probably not reasonable to try to integrate the BP compatibility package and other independent contributions (such as GRX) into the GPC distribution by this date, so let's keep them independent. > The tenative schedule for the egcs-1.1 release is: > * July 3, 1998. Feature freeze date. > All new features, optimizations, etc need to be submitted by this > date. It is very likely we will not be able to integrate all the > submissions, but we want to have all of them available for > evaluation by this date. > It is also possible some patches which have been submitted and are > accepted for egcs-1.1 will not have been installed by this date > due to EOQ committments for many of the Cygnus volunteers. > After July 3, 1998, only bugfix submissions will be considered for > the egcs-1.1 release. > By July 3, 1998, we also want to have a testing plan and release > criteria in place. For GPC this means that all scheduled features (e.g. some filled BP holes) have to be in place by that date. This merely concerns my own work. I will try to compose a new :-) beta (-: GPC snapshot by this weekend. > * July 11, 1998. Branch Creation & Testing. > We will create the egcs-1.1 branch on this date and snapshots will > occur from the egcs-1.1 branch instead of the mainline sources. > By this date we'd like to have all the new features, > optimizations, etc slated for the egcs-1.1 release installed in > the source tree. > We also expect wide scale, focused testing to start on July 11th. It would be desirable to release updated versions of BPcompat etc. together with gpc-2.1 (while in a separate package). In order to make this possible, gpc-980711 must be about the final version of gpc-2.1. > * July 31, 1998. Critial Bug Freeze Date. > If at all possible we would like to see the release sources freeze > except for critical bug fixes by July 31st. This may be overly > optimistic, but it's important to have a goal to shoot for. Besides the actual work on GPC, this means that all administrative tasks (copyright assignments etc.) must be finished before August. Those of you who are considering to contribute to the GPC compiler itself should contact me NOW so we have a chance to get these jobs done in time. (It involves papers that have to fly over the Atlantic!) > I would like to release as soon as possible in early August. > > Note that we have the ability to install changes into the mainline > sources during this process. However, I personally will be focusing > more and more on egcs-1.1 specific issues. > > It is highly likely we will have some minor releases based on > egcs-1.1; we will cross that bridge when the time comes. For GPC, we are planning to split the development into a "stable" line (gpc-2.1.x) and an "experimental" one (gpc-1998mmdd) in order to avoid long delays between the releases (about sqrt(3) years in this case)-: to happen again. > I also want to do a post-release review of the proposed schedule vs > the actual schedule used for egcs-1.1 so that we can improve the > process in the future. > > This message (and future updates) is available on > http://www.cygnus.com/egcs/egcs-1.1.html Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/

3 3

GPC REF: do (texi)
by Miklos Cserzo 19 Jun '98

19 Jun '98

Hi Folks, here goes the "final" version. I am going to have a break for the next 3 weeks. More sections to come after that. miklos ___________________________ @c---------------------------------------------------------------------------- @node do @unnumberedsec do @cindex do @unnumberedsubsec Description The @samp{do} reserved word is used in combination with other Pascal keywords in many ways. For description and examples see the relevant reference sections: @samp{for}, @samp{while}, @samp{with}, @samp{to begin}, @samp{to end}. @unnumberedsubsec Standards @samp{do} is defined in the ISO-7185 Standard Pascal and supported by all known Pascal variants. @unnumberedsubsec See also @ref{for}, @ref{while}, @ref{with}, @ref{to begin}, @ref{to end}. @c----------------------------------------------------------------------------

1 0

subscribe
by Robert P. Ewing 18 Jun '98

18 Jun '98

Please subscribe me to the gpc mailing list.

1 0

None
by None 18 Jun '98

18 Jun '98

k by faui45.informatik.uni-erlangen.de (8.8.8/8.1.16-FAU) with ESMTP id PAA07137 for <heckenb(a)mi.uni-erlangen.de>; Thu, 18 Jun 1998 15:42:32 +0200 (MET DST) Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by santra.hut.fi (8.9.0/8.9.0) with ESMTP id QAA27401 for <gpc(a)hut.fi>; Thu, 18 Jun 1998 16:25:12 +0300 (EET DST) Received: from icekool (207-172-110-153.s26.as3.frd.erols.com [207.172.110.153]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id JAA01871 for <gpc(a)hut.fi>; Thu, 18 Jun 1998 09:25:08 -0400 (EDT) From: "Billy Johnson" <icekool(a)erols.com> To: <gpc(a)hut.fi> Subject: unsubscribe Date: Thu, 18 Jun 1998 09:26:13 -0400 Message-ID: <01bd9abc$aa0f4ae0$996eaccf@icekool> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BD9A9B.22FDAAE0" Content-Length: 979 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BD9A9B.22FDAAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please, unsubscribe me from GPC mailing list.=20 Thanks for all. Billy Johnson ------=_NextPart_000_000A_01BD9A9B.22FDAAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Please, unsubscribe me from GPC = mailing list.=20 </FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>Thanks for all.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Billy = Johnson</FONT></DIV></BODY></HTML> ------=_NextPart_000_000A_01BD9A9B.22FDAAE0--

1 0

gpc-980511.i386-msdos-djgpp bug
by Marius Gedminas 18 Jun '98

18 Jun '98

Hi, developers! This is not urgent but should be fixed before the release goes out. GPC-980511 for DJGPP crashes if the DJGPP variable is set incorrectly (In my case it was set to C:\DJGPP instead of C:\DJGPP\DJGPP.ENV). This happens only if there are some arguments on the command line: ...>gpc --verbose Exiting due to signal SIGSEGV Page fault at eip=0000f0a5, error=0006 eax=00064924 ebx=00000013 ecx=00010000 edx=0000f109 esi=00000000 edi=00000000 ebp=00064928 esp=00064914 program=C:\DJGPP\BIN/gpc.exe cs: sel=00e7 base=10060000 limit=0142ffff ds: sel=00ef base=10060000 limit=0142ffff es: sel=00ef base=10060000 limit=0142ffff fs: sel=00cf base=00020270 limit=0000ffff gs: sel=00ff base=00000000 limit=ffffffff ss: sel=00ef base=10060000 limit=0142ffff Call frame traceback EIPs: 0x0000f0a5 0x0000f251 0x0000f2f5 0x00006b47 0x00008afe 0x0000d0eb 0x00010592 And sometimes the PC hangs after this. This was plain MS-DOS 7.10 with CWSDPMI V0.90+ (r3). Another question: gpc-980511.i386-pc-msdos-djgpp.zip contains a different LIBGCC.A than gcc281b.zip - should it be so? gpc-980511.i386-pc-msdos-djgpp.zip: libgcc.a 332,018 1998 Mar 29 21:26 gcc281b.zip: libgcc.a 282,626 1998 Jun 06 13:47 Besides, gpc-980511.i386-pc-msdos-djgpp.zip does not contain crtf.o. Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

1 0

unsubscribe me please
by Tano Fotang 17 Jun '98

17 Jun '98

would someone help me get off the list for now? holiday time.. /tano -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

None
by Dr Montaz Ali 17 Jun '98

17 Jun '98

Please include me in the user group

1 0

How to unsubscribe
by Peter Gerwinski 17 Jun '98

17 Jun '98

Hello, everybody! Since many people seem to have overlooked this in the various places: To unsubscribe from this list, write to gpc-request(a)hut.fi . The list is maintained by a human, so delays are possible. But why should you? ;-) See you, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

unsubscribe
by Bot, Willem Jan 17 Jun '98

17 Jun '98

unsubscribe me please.

1 0

Goodbye! (were: unsubscribe requests)
by Peter Gerwinski 16 Jun '98

16 Jun '98

Hello - and goodbye to all unsubscribers! Thanks for your warm greetings to all contributors, and I hope that you enjoyed your time with us. I am joining in the appreciation that I have the opportunity to work with such creative and productive people as I meet here. Anyway: The address to unsubscribe from (or subscribe to;-) the list is `gpc-request(a)hut.fi'. (-; Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

State of the art
by Marius Gedminas 16 Jun '98

16 Jun '98

Hi all! I think it's time for me to start programming for Linux, so I decided to download the sources of the latest GPC alpha version. However, there are a few questions I want to ask: * Just in case: is there a newer version about to be released? (I think I could wait a few days then ;) * What do I need to successfully compile and run GPC? My current configuration includes GCC 2.7.2.3 (yes, I know it's too old), libc 5.4.33 and GNU binutils 2.8.1.0.1 (BTW I've tried to find GCC 2.8.x on ftp://tsx-11.mit.edu (the official GCC site according to GCC-HOWTO), but only EGCS 1.0.3 was present there - readme said something about problems with gcc, so now I don't know whether I should choose GCC or EGCS.) Thanks in advance! -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

4 3

unsubscribe
by pirin 16 Jun '98

16 Jun '98

Unsubscribe Please, unsubscribe me from GPC mailing list. Thanks for all. Pirin Sergei

1 0

UNSUBCRIBE
by Patricio Domingues 16 Jun '98

16 Jun '98

Please unsubscribe me from the GPC mailing list. Thanks, Patricio.

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