- Gpc - gnu.de

Mailing list problems (March 20-23)
by Frank Heckenbach 27 Mar '04

27 Mar '04

Hallo, due to a problem when installing spam and virus filters, the mailing lists were out of order from last Saturday till Tuesday. Incoming mails were probably dropped without notice. If you sent any mail to the lists in this time, please check in the archives to find out if it got through, and otherwise please resend it. Sorry for the inconvenience, 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

ISO 7185 compliance issue for GPC
by Scott Moore 25 Mar '04

25 Mar '04

Hello, My name is Scott A. Moore, I am the person who performed some of the ISO 7185 compliance testing on GPC. I have done a minor update to some of my ISO 7185 compliance testing material, and reran this against the current version of GPC (2.95). In the process, I have discovered a compliance problem with GPC. Please reference the program: ============================================================== program test(output); var f: text; c: char; begin rewrite(f); writeln(f, 'how now'); writeln(f, 'brown cow'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''how now<eoln> brown cow<eoln> '''); rewrite(f); writeln(f, 'too much'); write(f, 'too soon'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> '''); end. ================================================================ The results from GPC for running this command are as follows: ================================================================ C:\TEST>test 'how now<eoln> brown cow<eoln> ' s/b 'how now<eoln> brown cow<eoln> ' 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' C:\TEST> ================================================================ The first section of the test verifies that eoln in text file is replaced with space, GPC passes this. The second section of the test verifies that eoln is automatically inserted at the end of a text file if it was terminated without a eoln. See ISO 7185 section 6.4.3.5: ===================================================================== There shall be a file-type that is denoted by the required structured-type-identifier text. The structure of the type denoted by text shall de ne an additional sequence-type whose values shall be designated lines. A line shall be a sequence cs ~S(end-of-line), where cs is a sequence of components possessing the char-type, and end-of-line shall represent a special component-value. Any assertion in clause 6 that the end-of-line value is attributed to a variable other than a component of a sequence shall be construed as an assertion that the variable has attributed to it the char-type value space. If l is a line, then no component of l other than l.last shall be an end-of-line. There shall be an implementation-defined subset of the set of char-type values, designated characters prohibited from text les; the effect of causing a character in that subset to be attributed to a component of either t.L or t.R for any text le t shall be implementation-dependent. A line-sequence, ls, shall be either the empty sequence or the sequence l ~ ls' where l is a line and ls' is a line-sequence. Every value t of the type denoted by text shall satisfy the following two rules: a) If t.M = Inspection, then t.L ~t.R shall be a line-sequence. b) If t.M = Generation, then t.L ~t.R shall be ls ~cs, where ls is a line-sequence and cs is a sequence of components possessing the char-type. ==================================================================== Basically, the rules say that a text file shall consist of either whole lines, or be entirely empty. Whole lines are defined as "~S(end of line)", or a series of arbitrary characters terminated by end of line. In effect, the program processor must arrange for eoln to be true at the end of a file, either by faking it while reading, or by forcing an eoln to be written at the end of a file during generation. Thank you for your attention.

4 11

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