Gpc

gpc@gnu.de

5400 discussions

Re: [GPC]: daily digest (#613)
by Tom Schneider 03 Feb '05

03 Feb '05

Maurice: > Strange. > doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 > behaves as expected. Hmm. I don't understand why it would be an issue on a Sun! > All is done manually with suitable tools to binary visualize the > true content of files, no shell scripts or functions which could be > too intelligent (I have bash, no tcsh) and hide something > "unimportant", for example no linefeed or ^Z (a DOS nicety on text > files) added at the end. The script demonstrated in three ways that the files had zero length. > A side comment: to make it work I needed to compile with > gpc add the --transparent-file-name > option to gpc (otherwise the filenames are asked at the beginning of the execution) > Why did you not need it ? You are right. I use a script, gpcc, which uses that option. The files are definitely empty - there is no need for me to clear them inside the Pascal program. The script uses `echo -n ""` to make them and three different standard unix tools (ls, wc, file) say they contain zero bytes. The results were in the initial report. I have just discovered something else. Using the *same* code and the *same* input files: gpc 20040516, based on gcc-3.3.3 fails (says empty files are not eof after reset). but the older GNU Pascal version 2.1 (20020510), based on gcc-2.95.2 19991024 (release). works! (says empty files are eof after reset) Thus the behavior of GPC has changed between these two. >From my viewpoint this is an extremly serious bug because so many of my programs use the eof test. What's happening is that I'm slowly updating programs and so I didn't notice it until now. I spent all night the other day trying to figure a way to replace eof with something that worked (using eof but is still standard) but failed. If I have to use the p2c converter to work with my programs, I will be forced to abandon GPC, just as I was converting all programs to function smoothly with it ... :-( This is now true for one program. I hope that this can be solved! Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

6 11

--mac-pascal
by Adriaan van Os 02 Feb '05

02 Feb '05

Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now. The new gpc builds and passes the testsuite on powerpc-apple-darwin. A few places in the source of the gpc compiler are unclear to me. They include: 1. predef.c line 423 chk_dialect ("direct access to files without declared domain is", B_D_PASCAL); 2. predef.c line 713 flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 | CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK; 3. expressions.c line 124 chk_dialect ("string concatenation without `Concat' or `+' is", B_D_PASCAL); Regards, Adriaan van Os

6 18

GPC binding to OpenGL or Mesa
by Rick Engebretson 02 Feb '05

02 Feb '05

I'm a little confused about the GPC approach to binding to C libraries. The documentation is a little sketchy and warns that some changes might occur. Is there some clarification available ? Also, bindings of FPC to OpenGL are available, which are derived from Delphi3D. These are mostly limited to Win32.DLLs . Has anybody started a GPC to OpenGL or Mesa binding for Linux ? Might it be appropriate to simply start from the FPC template ? Thanks, Rick.

3 5

Re: EOF is not true on reset empty file
by Tom Schneider 01 Feb '05

01 Feb '05

> Date: Sat, 29 Jan 2005 14:14:18 +0100 (CET) > From: Waldek Hebisch <hebisch(a)math.uni.wroc.pl> > > You missed an important information. If I type (with `eof.pas' beeing > your file): > ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O -ftransparent-file-names -fstandard-pascal eof.pas > ./a.out > > I get: > NOT eof of namebook > NOT eof of namelist > > However, if I type: > ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O --transparent-file-names eof.pas > ./a.out > > I get: > eof of namebook > eof of namelist > > Both with my (modified) copy of gpc-20041218 on Linux. Yes, standard requires > that you get EOF on empty file. Thanks for clarifying the standard for me. I'm using --transparent-file-names and with that get NOT eof. I hope that clarifies the issue for you. Tom

2 1

Re: EOF is not true on reset empty file
by Tom Schneider 01 Feb '05

01 Feb '05

Maurice: > Still please do the cross check. I have no Sun at hand do do it, > and may be nobody in this list has exactly the same system. > I know nothing on the inners of the Sun file system, whether > it stores somewhere the fact that this is a binary or a text file, > if the file length is obtained by looking truly to the file content, > or to some information on the length stored somewhere outside of the > file, etc. In DOS systems when running scandisk, you find sometimes > an error message like "file length as reported by the system is different > from the true file length" Ok. closetest.p: In main program: closetest.p:20: error: undeclared identifier `close' (first use in this routine) closetest.p:20: error: (Each undeclared identifier is reported only once closetest.p:20: error: for each routine it appears in.) The function 'close' is not standard Pascal. Since I'm not set up to avoid standard Pascal (and I don't think it is critical, correct me if I'm wrong please), remove those lines. A rewrite followed by a reset empties the file. ******************************************************************************** strawberry 21% more closetest.p program closetest(namebook, namelist, output); (* Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const version = 1.00; (* of closetest.p 2005 jan 31 *) var namebook, namelist: text; begin rewrite(namebook); { close(namebook); } reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook'); rewrite(namelist); { close(namelist); } reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. ******************************************************************************** NOT eof of namebook NOT eof of namelist The program failed. strawberry 15% ls -l nam* -rw------- 1 toms delila 0 Jan 31 19:40 namebook -rw------- 1 toms delila 0 Jan 31 19:40 namelist strawberry 16% wc nam* 0 0 0 namebook 0 0 0 namelist 0 0 0 total strawberry 17% file nam* namebook: empty file namelist: empty file The files made by the Pascal program are indeed empty by these three tests. Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

Re: [GPC]: daily digest (#614)
by Tom Schneider 01 Feb '05

01 Feb '05

> Date: Sat, 29 Jan 2005 04:42:00 -0600 > From: Rick Engebretson <reng(a)tcq.net> > > I think going to p2c will isolate your fine work. Thanks! However it is always good to have several different compilers around. By looking at p2c, I could see the problem in GPC and (presumably) vice versa. GPC is robust and has an active community. p2c works for standard Pascal (all I really need) but it is not active. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

EOF is not true on reset empty file
by Tom Schneider 30 Jan '05

30 Jan '05

One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this: EOF is not true on a reset empty file. Here is the program: ******************************************************************************** program gpcbug2005jan27(namebook, namelist, output); (* Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *) var namebook, namelist: text; begin reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook'); reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. ******************************************************************************** This is the result of running a script called mk (which displays itself): ******************************************************************************** version = 1.00 of mk 2005 Jan 27 #!/bin/tcsh -f #(ie run the tshell on this but don't read the .cshrc or .tcshrc) echo version = 1.00 of mk 2005 Jan 27 # 2005 Jan 27, 1.00: origin # show the script that does everything: cat mk echo -n "" > namebook echo -n "" > namelist echo 'file name*' file name* echo echo 'wc -l name*' wc -l name* echo echo 'ls -l name*' ls -l name* echo -------------------- compile gpcc gpcbug2005jan27.p echo -------------------- gpcbug2005jan27 file name* namebook: empty file namelist: empty file wc -l name* 0 namebook 0 namelist 0 total ls -l name* -rw------- 1 toms delila 0 Jan 27 02:25 namebook -rw------- 1 toms delila 0 Jan 27 02:25 namelist -------------------- compile version = 1.37 of gpcc 2004 Jan 11 Using /usr/local/gpc/bin/gpc instead of the one in the path gpc compiling gpcbug2005jan27.p output program name: gpcbug2005jan27 gpcbug2005jan27.p exists, so we can delete gpcbug2005jan27: REMOVING gpcbug2005jan27 version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *) optimization: 0 --- GPC version from "gpc --version | head -1" : gpc 20040516, based on gcc-3.3.3 GPC version from "gpc | head -1" : GNU Pascal version 20040516, based on gcc-3.3.3. --- ONLY STANDARD PASCAL IS ALLOWED ------ No errors ------ No warnings ------ gpcc is done -------------------- NOT eof of namebook NOT eof of namelist ******************************************************************************** Is this standard behavior for Pascal? I thought that if you reset an file, it would be at eof. Where else could it be? Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 3

Re: EOF is not true on reset empty file
by Tom Schneider 30 Jan '05

30 Jan '05

I wrote before: > EOF is not true on a reset empty file. for GPC. gpc 20040516, based on gcc-3.3.3 I just found in the book PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158: "A file is called \emph{empty} if its length is zero." As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof. Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

6 7

Sven nochmal(...)
by Sven SCHUBERT 21 Jan '05

21 Jan '05

aehm, hab gerade festgestellt, dass das ja eine deutsche Mailing liste ist. Wie schoen, ich spar mir die Uebersetzung in der Hoffnung, dass trotzdem die meisten wissen, worum es mir geht. Gruss, Sven. -- Sven Schubert I.T. Carlow - Software Engineering mobile: +353 85 7169848

2 1

Introduction & first question (c:
by Sven SCHUBERT 21 Jan '05

21 Jan '05

Hi all, this is me, Sven Schubert, 25 yo German and student of 'Software-Engineering' at the Institute of Technology Carlow, Ireland. My final year project is to come up with a Pascal compiler for the Parrot VM (www.parrotcode.org). While researching ways on how to do my project (i.e. write a new compiler from scratch or modifiy existing OSS-compilers to target Parrot), of course GPC was one of the open-source compilers I looked at. Now, I'm not exactly literate in compiler building and I could use some guidance regarding where to look at in GPC. Naturally, I'm looking for the Backend module of GPC, that would translate the intermediate representation into whatever its target language is. Because I guess, thats where I would have to start changing things (c: Can anyone point me, what part of the GPC source to look at? Anyone done anything similar in the past? As I'm still researching, I could use some third-party opinion on the feasability of modifying GPC instead of writing a new Pascal compiler from scratch. Any suggestions welcome. Thanks & cheers, Danke und viele Gruesse, Sven. -- Sven Schubert I.T. Carlow - Software Engineering mobile: +353 85 7169848

3 2

Jump to page:

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