Gpc March 2004

gpc@gnu.de

24 participants
41 discussions

Minor issue: command line parameters
by Scott Moore 23 Mar '04

23 Mar '04

From: Scott A. Moore Hello, A minor "it would be nice" request for you all. I have been working on personally certifying the compliance of several ISO 7185 compilers this last week. You all are no doubt aware that the ISO 7185 specifies header parameters such as: program test(input, output, file1, file2); ... Although ISO 7185 does not specify the mechanisim, most implementors have given a means to connect the header parameter files to external, named files, including the original Wirth implementation of Pascal on the CDC 6000 computer. GPC does this as well. Here is a roundup of the compilers that I have either tested or have seen the results of testing on: 1. Irie Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e., program test(input, output, file1, file2); appear on the command line: > ivm test thisfile thatfile 2. Compaq Pascal, header parameters can be connected to files by special command line syntax: > test $input=thisfile $output=thatfile 3. CDC 6000 Pascal (Wirths original), the command parameters are specified in a SCOPE operating system statement: EXECUTE,TEST(INPUT,OUTPUT,THISFILE,THATFILE) 4. GPC, each unfufilled program parameter is prompted for: > test Input file `File1': thisfile Input file `File2': thatfile 5. IP Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e., program test(input, output, file1, file2); appear on the command line: > test thisfile thatfile The ISO 7185 method of specifying program parameters is not much use without the (standard undefined) means of connecting them to outside parameters, so this is good. However, I also note that GPC does not provide a means to automatically connect these files, but requires operator intervention to do this. I wonder if I could talk you guys into implementing a slight enhancement to GPC, that is completely compatible with your present methodology ? The method of connecting program parameters to command line parameters is attractive. The FPC authors have expressed an interest in implementing it. For GPC, to keep compatibility with your present methods, I would suggest: If a program parameter file is present, and it can also be determined that a command line argument exists for it, then get that from the command line instead of prompting the user. This continues for as many parameters as exist in the program header. The command line parameters (argv/argc) can either be reduced at the left to remove the program parameters used as filenames, or the command line can be left alone. There are arguments for each method. Anyways, this would serve to further unify the operation methodologies of existing (and popular) ISO 7185 compilers, which is, I am happy to say, a growing club. Thank you for the consideration.

2 2

Re: Dereferencing variables of type Pointer
by Neil Santos 18 Mar '04

18 Mar '04

[Resent because I forgot to change To: field again. Damn it.] * [100304 :: 0133] Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > > I apologize for the vagueness of my original post. It was written at > > the end of the very tiring day (or the start of one; depends on how you > > look at it). > > I know. :-) Sometimes I begin to despise my choice to try and become a programmer--or, rather, try to be competent enough in programming to fake being a programmer. But then I remember that I know nothing else, and would have to feed my family with food bought through the money I'm hoping to earn through coding. :D > > inheritance for all the objects that need to be written to and read from > > a file, > > ... using a virtual method. That would be the OOP approach. I opted for a root object that has as a member an object that implements an interface for accessing data streams from a disk. Sounds more complicated than it is in code. :P > > but I'm lazy, and since these functions will be doing basically > > the same thing (managing binding types, reading to/writing from > > streams), > > Which could be done in a common ancestor's method. (No-one ever said > OOP would reduce the number of routines in total ... ;-) Aye. A teacher of mine tried to argue so; so I slapped him down. But, like I said, I'm lazy; so I still look for ways to have object orientation with reduced coding. I like having my cake and eating it, too. :) > BTW, if you don't want to be Extended Pascal conformant (and you > obviously don't), you can use GPC extensions such as: While I'll admit to not gunning for conformance, I like to stick to it as much as I can. But when I encounter limitations in the languages I use, I try to find ways that work around them. If there aren't, I try to make some. > There is no such thing as runtime type information in GPC. What you Which I sorely miss, coming from a Windows/Delphi background. [everything else snipped for brevity] I've been mulling over your suggestions for the past few days--and I must admit ignorance for a lot of the things you've said. Like I said, I'm lazy, and I like having my cake and being able to eat it, as well; so here's what I've done. I have a root object which implements a several functions that is common for all the Type 1* objects I have, and also has a member object that implements the disk-access functions I need. Part of the creation of a Type 1 object involves passing the parameters needed by the disk-access object's constructor, all of which are contained in a RRecdStream record. The RRecdStream record is declared as such: RRecdStream = record { pointer to the structure to be written } recd_ptr = pointer; { byte; denotes what kind of structure is held by recd_ptr } recd_type = TRecordType; { MAX_PATH_LEN is 2060 bytes; as defined in GPC 20030830. Is there any way to retrieve this at runtime? } file_name = string(MAX_PATH_LEN); end; And, oh, is there any way to turn a constructor into a function? :P The disk-interface module is *very* incomplete as of now, but I would gladly send it to anyone who's interested; or, for that matter, a tar-gzip'd file of the whole project. * A `Type 1' (made up term) object in this context is an object that has a member variable that gets written to/read from a stream. -- - Neil Santos Freelance Programmer & Web Designer - - http://nsantos.f2o.org/ Free Software advocate - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT d+@ s+:+ a? C++++ UL*++++ P++ L++ E--- W+++(--) N-- !o !K w(++) !O M-- V? PS++ PE-- Y++ PGP+ t* 5-- X- R++ tv+ b++>+++ DI+++ D--- G e>+++++ h r++ y? ------END GEEK CODE BLOCK------ Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

3 5

ld returned 1 exit status
by gunday＠poczta.onet.pl 17 Mar '04

17 Mar '04

The situation is just as follows: {----------- begin --------------} [ja@unicorn ja]$ cat test.pas program test; begin writeln('Hello World'); readln; end. [ja@unicorn ja]$ gpc test.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x595): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:897: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5b5): In function `_p_LoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:904: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5d4): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:909: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5f4): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:914: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x614): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:919: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x654): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:924: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x6c4): In function `_p_IsSpace': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:934: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x6e4):/home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:939: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status [ja@unicorn ja]$ { -------------------- end ---------------------- } Operating system: Fedora Core 1 GPC - release: binary, gpc-20030830-with-gcc.i686-pc-linux-gnu.tar.gz - probably not important, because there were similar messages with other versions. I've only tried binary, because i can't compile the source, there is a "command not found" message.

3 5

Re: ld returned 1 exit status
by Emil Jerabek 17 Mar '04

17 Mar '04

On Tue, Mar 16, 2004 at 07:14:51PM +0100, Tomasz Gandor wrote: > W li?cie z wto, 16-03-2004, godz. 17:44, Emil Jerabek pisze: > > > I've built Fedora binaries now (.tar.gz, I have no idea how to create > > rpm packages). Where can I upload it? > > There is no problem - if you have the tarball, you should use the > rpmbuild command (if you have installed all programmers packages, > as I did, you must have it). I guess it may be present in the > very basic installation of Fedora. > > As you're successful in building the binaries, this should not make > you much trouble. It is just matter of adding some command line > switches. Or, also, you can have a directory with the installation, > then you type: > rpmbuild --buildroot /usr/bin/gpc gpc.rpm > - this is just my theoretical wild guess... > But I plan to ivestigate into this topic. Yes, I know, using rpmbuild is quite straightforward. The tricky part is to write a spec file. Emil

1 0

Re: Building with non-GNU make(1)
by Frank Heckenbach 16 Mar '04

16 Mar '04

Thorsten Glaser wrote: > >exactly 22 leap seconds until then (since 1970-01-01), so if we > >treat both 48 and 26 as correct, will this be sufficient? > > Until the next leap second occurs, yes. But it seems like > there won't be another for a few semesters at the moment, > dur to changing earth rotation. But leap seconds are not inserted into the past, I suppose. As I said, it tests a fixed date (1999-11-29, for no particular reason, I think it was when the test was originally written), and the number of leap seconds between 1970-01-01 and 1999-11-29 should not change anymore. Any leap second inserted now or in the future is outside of this interval. > (As to POSIX: it makes impossible to determine age of > something or duration of an event; also, if you need > UTC (instead of TAI) to be displayed, using xntpd for > example, your clock jumps for- and backwards instead > of being monotonic, which is required for precision > time- and logkeeping - but I doubt it's on topic) If it jumps, it's indeed bad. I read somewhere that the clock is adjusted to run a bit slower or faster for a short time in order to remain monotonic. I don't remember exactly where I read it, but I'd have thought these programs do the same. BTW, monotonic clocks are also required for things like make (which brings us back near the original topic ;-). 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 GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Re: Building with non-GNU make(1)
by Frank Heckenbach 16 Mar '04

16 Mar '04

Thorsten Glaser wrote: > >> Seems like there is some preprocessor work to do, but look at > >> that locate output below. I have no idea why the file isn't found. > > > >> tg@odem:/home/tg/gpc-20030830/p/test $ locate gpc-in-c.h > >> /usr/lib/gcc-lib/i386-ecce-mirbsd7/3.2.3/include/gpc-in-c.h > > > >Does `gpc --print-file-name=include/gpc-in-c.h' find it? > > tg@odem:/home/tg $ gpc --print-file-name=include/gpc-in-c.h > /usr/lib/gcc-lib/i386-ecce-mirbsd7/3.2.3/include/gpc-in-c.h Did you check the output of `gpc -v' (or can you send it)? > >There's a small discrepancy in the time conversion (localtime() on > >the libc level). The given time corresponds to 02:19:48, but > >localtime returns 02:19:26. Maybe leap seconds? Are they supposed to > >be handled there (they're not on the system I've tested it on so > >far), hmm ... > > According to POSIX, both the UNIX time (kernel) and the user time > are set to UTC, that is, displaying lawful time (for us Germans, > just add 3600 seconds to get lawful time). > According to correctness, and described by djb, Who or what is djb? > (xntpd including ntpdate is POSIXly broken, so no help.) Just to be sure what we're talking about, is this going to be a holy war about different ways of handling leap seconds? If so, I think I'd prefer to follow POSIX (as most systems seem to). Or am I misunderstanding you? Anyway, to cut it short, for this particular test, since it tests a fixed date in the past, I suppose we can be sure that there were exactly 22 leap seconds until then (since 1970-01-01), so if we treat both 48 and 26 as correct, will this be sufficient? 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 GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Building with non-GNU make(1)
by Thorsten Glaser 15 Mar '04

15 Mar '04

Hello people, has anybody ever _successfully_ built gcc+gpc with BSD make? The hard I try, I only get a circular dependency which I don't find in the generated Makefile or the input graph (maybe I'm just too stupid tho). All other front-ends I have (c,c++,objc,fortran,ada) build with BSD make just fine (after minor, or - for ada - heavy, adjustments tho). If anybody would like to resolve that, I can send the Makefile or input graph before or after processing. Please tell me. cu, Thanks in Advance, //Thorsten -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

2 7

Re: Dereferencing variables of type Pointer
by Neil Santos 09 Mar '04

09 Mar '04

[Resent; stupid me forgot to change the To: field, and I've been waiting for the past two days for a reply. :P ] I apologize for the vagueness of my original post. It was written at the end of the very tiring day (or the start of one; depends on how you look at it). Anyway, here's what I failed to provide the first time around. I hope this is much more useful. I have several objects with no common parent, though all of them have a private member called structure. With each object, `structure' is of a different record type. What I'd like to be able to do is write generic functions that would take any object and write its structure member into file, or read a structure in a file and assign it to said object's structure member. I know I can make an abstract root object that implements a common inheritance for all the objects that need to be written to and read from a file, but I'm lazy, and since these functions will be doing basically the same thing (managing binding types, reading to/writing from streams), I'd like to write just one function for each job, which figures out how to bind bindable variables depending on which object/record I throw at it. Oh, and Frank mentioned storing objects in streams; I'm kind of curious how this works; I'm not exactly new at OO, but I've never written objects to streams. All I've been doing so far is writing records inside objects into files. Thanks for the help, guys. :) -- - Neil Santos Freelance Programmer & Web Designer - - http://nsantos.f2o.org/ Free Software advocate - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT d+@ s+:+ a? C++++ UL*++++ P++ L++ E--- W+++(--) N-- !o !K w(++) !O M-- V? PS++ PE-- Y++ PGP+ t* 5-- X- R++ tv+ b++>+++ DI+++ D--- G e>+++++ h r++ y? ------END GEEK CODE BLOCK------ Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

3 2

FreeBSD gpc status?
by Frank Jahnke 09 Mar '04

09 Mar '04

I am writing you all to inquire about the status of the GNU Pascal compiler on FreeBSD. It is mentioned quite prominently on the gpc homepage as a supported platform, yet it is not in the FreeBSD ports collection. Browsing the archives on gnu-pascal.de shows some intermittent interest, but no real success stories, at least for recent OS versions. I have quite some old pascal code that I would like to use with the rest of the GNU compiler family. gpc would seem to be the way to go, if that would be possible. Could anyone share with me what the status of gpc is on FreeBSD? For what it's worth, I'm running FreeBSD 5.2.1 with gcc 3.3.3. Frank Jahnke

2 7

bug (?) in Time Format
by Toby Ewing 07 Mar '04

07 Mar '04

Hi, all There have been some recent improvements to the Mersenne Twister (the random number generator that is used in the GPC unit), and I've been translating them into Pascal for eventual submission to the programming team. As part of this, I wanted to check the execution time, so I wrote a timer (I thought!) into a test program: program testMT; uses GPC, MTrand; {MTrand is the name of the unit I'm working on} const big = 10000000; TimeFormat = ' %Q'; var t1, t2, i, j : medCard; CurrentTime : TimeStamp; begin SeedRand(1234567890); GetTimeStamp (CurrentTime); WriteStr(FormatTime(CurrentTime, TimeFormat), t1); { line 17 } for i := 1 to big do j := randInt; GetTimeStamp (CurrentTime); WriteStr(FormatTime(CurrentTime, TimeFormat), t2); Writeln('Elapsed time: ', (t2 - t1):1); end. The compiler hangs with the following error: testmt.pas(17): Error: reference expected, value given testmt.pas(17): Error: reference expected, value given testmt.pas(17): Error: tree check: expected class 't', have 'x' (error_mark) in require_complete_type, at p/typecheck.c:63 Please submit a full bug report I'm guessing that it's not about my unit, but rather what I'm trying to do with capturing a string into an int... anyway, here is a bug report. Toby

5 11

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 March 2004