Gpc April 2002

gpc@gnu.de

34 participants
54 discussions

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

26 Apr '02

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

2 1

Removed Pascal feature?
by Wood David 26 Apr '02

26 Apr '02

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

2 1

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

25 Apr '02

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

1 0

constructors+virtual methods
by Adam Naumowicz 24 Apr '02

24 Apr '02

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

5 22

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

24 Apr '02

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

2 1

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

24 Apr '02

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

2 1

CRT and numeric keypad
by Couperin 24 Apr '02

24 Apr '02

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

3 7

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

23 Apr '02

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

3 3

Storing Random Seed
by Silvio a Beccara 22 Apr '02

22 Apr '02

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

3 4

Current stable release?
by John Ollason 19 Apr '02

19 Apr '02

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

2 1

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 April 2002