- Gpc - gnu.de

Re: gpc-20041017 released
by Prof A Olowofoyeku (The African Chief) 23 Oct '04

23 Oct '04

I have put the Mingw compiler through the testsuite. It passed everything, except for this: TEST pipetest.pas: cc1.exe: warnings being treated as errors ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

[Fwd: Re: gpc-20041017 released]
by Maurice Lombardi 22 Oct '04

22 Oct '04

-------- Message d'origine -------- Sujet: Re: gpc-20041017 released Date: Thu, 21 Oct 2004 16:34:27 +0200 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: cbfalconer(a)worldnet.att.net Références: <BC841B22-2079-11D9-A02D-000A27944772(a)microbizz.nl> <1098278943.2579.526904(a)goedel.fjf.gnu.de> <41779BAC.13355112(a)yahoo.com> CBFalconer a écrit: > Frank Heckenbach wrote: > >>Adriaan van Os wrote: >> >>>Frank Heckenbach wrote: >>> >>> >>>>I have uploaded a new beta version of GPC to >>>><http://www.g-n-u.de/gpc/>! >>> >>>Thanks for the new version ! >>> >>>I would be curious to know the status of: >>> >>>- Waldek's gcc-3.4.x and qualified identifier patches >>>- range checking >> >>Not yet included, in order to avoid further delays, especially >>because of the `CInteger' changes. > > > What about a DJGPP version to match gcc 3.4.2? > I have compiled successfully (no error while running the test suite) for DJGPP for gcc 3.2.3 and gcc 3.3.3. Not uploaded due to server problems. There is still the problem of CPP_PREDEFINES with gcc 3.3.3 It is worked around in the test suite by using the --print-needed-options trick, and the same is used in gp.exe. I do not know what to do with this: gpc.exe is always needed and even if I include gp.exe in the binary this will cause confusion among users (I have received complaints from users who call gpc.exe with the 3.3.3 compiled binary I uploaded to the server). 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

gpidump
by Adriaan van Os 19 Oct '04

19 Oct '04

Another problem - with most .gpi files, gpidump stops with the following error: gpidump: ... .gpi: unexpected flag `unused lang flag 1' I tried this with gpc-20030830 and gpc-20040516, both with gcc-3.3.2 on powerpc-apple-darwin. Regards, Adriaan van Os

5 9

Re: Brief comments / additions to docs
by Grant Jacobs 14 Oct '04

14 Oct '04

Excuse my slow reply - I'm flat-out at the moment. >Grant Jacobs wrote: > >> >Grant Jacobs wrote: >> > >> > > Debugging: >> >No, it isn't. Why do you think it should? `Exit' is BP compatible. >> >To stop the program use `Halt'. >> >> My screw up, sorry. I've never used BP, btw; exit in other languages >> exits the program. > >In C, yes. (I don't know about `exit' in other languages.) In this >case, I'd rather follow BP and UCSD than C, since `Exit' to leave a >procedure is not really a misnomer. Just leave it - its just a name in the end. I was just explaining how I got confused. Most languages I know of use exit() to exit the program and return to leave a subroutine|procedure. I suspect for historical reasons languages that are (largely) Unix-based (e.g. perl, C, Unix shells) use exit(). Who knows...? > > I'll look at this again when I find time. I'd like to think I use a >> parameter in the routine though, it'd be a rather pointless parameter >> otherwise! > >Sure, and then the second error is clear (to me). But the first one >is more important, and if you don't get it, this would be a real >problem. One day...! Let's hope I remember. > > I think my confusion must have come from the fact that all other >> other descriptions other than that for rewrite (append, reset, etc.) >> say its optional. They do hint to read rewrite for more details. I.e. > > read alone (without reading the rewrite section) the descriptions for >> append, etc. would be misleading. The impression I got on reading the >> "for more details see rewrite", was that'd it'd be more of the same >> in more detail, not that'd there might be something that'd contradict >> the text preceding it. I'd be good to add a line: "If you're using >> untyped files, the last parameter is essential; see rewrite for >> details." to the descriptions for reset, append, etc. > >OK, I understand the confusion. I'll try to clarify things in the >next release. Ta. Hopefully it'll spare someone else the trouble. > > > > Macro expansion of __FILE__ seems to be inconsistent. In cases it >> > > expands to a full path and in others to just the local filename. It >> >> seems to be that if the file is in the local directory compared to >> >> the main program being compiled, just the filename is returned; if >> >> the source file is in another directory, a full path is returned. >> > >> >What do you suggest? Always a full path? >> > > I'd prefer a full path as that has all the info. Its easy enough to >> get a substring for the bits, etc. > >OK, I'll change that. Sounds good! >Anyway it should be possible to define C macros to the same effect, >such as: > >#if defined (__STDC__) || defined (ALMOST_STDC) >#define CONCAT2(a,b) a##b >#else >#define CONCAT2(a,b) a/**/b >#endif I was meaning varargs in particular, not macros in general (hope I'm reading you correctly.). I've got debugging macros in place already. I tried porting the ones I use in C code, but they have varags, so I've re-worked them as far as I could. >Making such a macro compatible to a new >Pascal macro will then also be a one-time setup, so it's acceptable >I hope. No chance you can allow the user to define a preprocessor as a command-line option, then anyone who wants to can feed the code through the C (or other) preprocessor? This could have a other uses to people who want their code preprocessed by their own means. Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm thinking in part here that although I can currently do push a single source file though the preprocessor, to compile a whole project like by first preprocessing it, I'd have to compile everything to .o files, then link them as I won't have access to pulling in things via 'uses' the way the Pascal compiler does. It'd be better for the compiler to feed each source code through my choice of pre-processor on my behalf. Follow my meaning?) > > About varargs in macros. I don't mind that varargs might be too much >> work (fair enough - there aren't enough hours in the day to do the > > things I want to either), but saying that debugging writes aren't a >> good enough use to justify varargs to me is not so valid... Like >> debugging, testing and verification isn't important enough...?! > >I didn't mean to imply this (since I put a lot of work into >maintaining GPC's test suite myself). I had hoped not :-) >Rather I'm still thinking of alternatives, and how the effort >required compares with implementing varargs macros (though, as I >said, I'm not sure yet, how much effort the latter will be, perhaps >it'll turn out rather easy). Of course you can always define >`DebugWrite1', `DebugWrite2', ... As I'm sure you already know, one of the key uses for varargs is so that you can blindly pass on argument lists without having to consider their syntax, e.g. the arguments to printf (in C). Two quick C e.g.s (not tested, based on e.g.s in Harbinson & Steele and what I recall off the top of my head my own use of them): #ifdef DEBUG #define DebugPrint(...) \ printf( debugFile, "%s %s %s > ", __FILE__, __LINE__, timestamp() ) \ printf( debugFile, __VARARGS__ ) ; printf( debugFile, "\n" ) ; #else #define DebugPrint(...) #end #define ArgList2String(...) #__VARARGS__ The reason I'm dropping these in is that they might be a couple of useful e.g.s to try test out your ideas on macros. Probably not much help, but... >I'm looking for ways to achieve a general form with the existing >capabilities. Unfortunately I haven't found any so far. The >direction I'm thinking along is something like > >{$define DebugWrite(X) WriteLn X} > >i.e. `DebugWrite ((foo, bar, baz))' -> `WriteLn (foo, bar,baz)' >(just an extra pair of parentheses needed). Unfortunately, you >probably don't want to write debug information to `Output' and I see >no way to get a file parameter in that macro expansion ... > >So varargs macros might be justified in the end, but I'm still >waiting for other arguments for both sides ... I'll try put my thinking cap in this. Jog my memory if I forget. Personally I'd plug for you popping in user-defined pre-processing options into gpc, then you're covered either way. >BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? >I'm wondering if (if we do it in the end) we shouldn't allow to >define a parameter name for the varargs instead of having such an >(ugly IMHO) "magic" name. Not sure precisely, but most likely something along the lines of VARiable (number of) ARGumentS. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

2 1

ignore-garbage-after-dot
by Adriaan van Os 14 Oct '04

14 Oct '04

The gpc manual states: --ignore-garbage-after-dot Ignore anything after the terminating ‘.’ (default in ‘--borland-pascal’). However, the following testprogram: {$ignore-garbage-after-dot} program Test; begin end. blabla #include <sys/types.h> results in: garbage.p:6: no include path in which to find sys/types.h So, this looks like a preprocessor problem. Regards, Adriaan van Os

4 4

ANNOUNCEMENT: ODBC unit
by Markus Gerwinski 11 Oct '04

11 Oct '04

Hi Folks, the GNU Application Libraries for Pascal (GNUALP) framework has grown. After multithreading, it now also provides database access. As a default implementation, there is an ODBC unit available. The tarballs can be downloaded from http://www.markus.gerwinski.de/gnualp/. To run the ODBC part, you will have to install gnualp-0.1.5.tar.gz first, then gnualpodbc-0.1.1.tar.gz. Both projects can be installed, as usual, with ./configure, make, make install. To run the demo program(s) in the demos/pas resp. demos/c subdirs of gnualpodbc, you'll need to have a working ODBC environment installed. If you have, just start the odbcdemo program with a valid data source name as command line argument, and you'll see a nice little command-line SQL client. :-) gnualpodbc-0.1.1 is tested with the following system configurations: - SuSE Linux 8.0 and above, iodbc-3.51.2, and a mysql-4.0.20 database accessed via myodbc-3.51.09. - Windows XP with MinGW, mysql-4.0.20, and myodbc-3.51.9-win. You'll maybe have to download libmsvcp60 from somewhere (it was pre-installed in my MinGW distro, but that doesn't seem to be standard). Have fun, Markus

1 0

Gnu Pascal on Fedora/Red Hat
by Paul Igodt 09 Oct '04

09 Oct '04

Hello - where has www.gnu-pascal.de gone? It seems to be down? - I downloaded (couple of weeks ago) binaries for a Gnu Pascal installation on a Fedora Core 2, Intel processor, machine. (This is a sort of Red Hat Linux, fairly standard linux?). - After installation, I could not test yet enough, but anyhow, one of the pascal programmes which I wanted to compile (and in fact compiles under gpc on Cygwin), doesn't finish too well: upon gpc -o dbase --automake -I/usr/include/ncurses dbase.pas I get, after a while /usr/bin/lid: crt1.o: No such file or directory collect2: ld returned 1 exit status In the directory however, a file crt.o has been created meanwhile. Maybe I should have installed from a source distribution (which is now hard to get as the website seems down)? What is going wrong? Thanks Paul

2 1

wchar
by Markus Gerwinski 08 Oct '04

08 Oct '04

Hello, does GPC have a data type that corresponds to the wchar_t data type of gcc? If not, is there an easy way to port it and make sure it always has the same size as in gcc? Yours, Markus

6 21

Better Pascal mode for Emacs?
by Neil Santos 08 Oct '04

08 Oct '04

I've been trying to switch to using GNU Emacs while writing Pascal code, but the Pascal mode shipped with GNUmacs 21.2 is... let's just say, `not up to the task'. Google-ing for one wasn't much help--none of the projects I've checked support Extended or Object Pascal properly (most don't support them at all). So, I'd like to ask if anyone here has found/written a Pascal mode for Emacs that supports most (if not all) of the Pascal dialects supported by GNU Pascal, and, if so, where I could get a copy of it. I only know enough LISP to be able to edit my .emacs file (and then some); I'm nothing near the level of expertise needed to write an Emacs language mode of this scale. TIA. -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

3 4

Re: Brief comments / additions to docs
by Grant Jacobs 08 Oct '04

08 Oct '04

>Grant Jacobs wrote: > > > Debugging: >No, it isn't. Why do you think it should? `Exit' is BP compatible. >To stop the program use `Halt'. My screw up, sorry. I've never used BP, btw; exit in other languages exits the program. > > It would be good to see a more sensible error message generated when >> the compiler detects a missing parameter in the interface vs. >> implementation definitions of a proc/fn, e.g. >> >> if you have: >> >> interface >> >> function string_eq( str1, str2 : string; ) : boolean ; >> >> implementation >> >> function string_eq( str1, str2 : string; >> caseSensitive : boolean ): boolean ; >> begin >> ... >> end ; >> >> You get >> >> undeclared identifier `caseSensitive' (first use in this routine) > >Well, what *I* (since you say "you" ;-) You know I'm not using that as a personal pronoun! ;-) >actually get (after filling >in the missing parts and fixing the obvious syntax error) is this: > routine definition does not match previous declaration > -> previous declaration > >If you use `caseSensitive' within the body of `string_eq' (which you >didn't show in the `...') you might get that other message because >the second (wrong) redeclaration of the function is ignored, but the >first error message is the important one. If you don't get this, >please report with a full example (compilable code, compiler >version, etc., as usual). I'll look at this again when I find time. I'd like to think I use a parameter in the routine though, it'd be a rather pointless parameter otherwise! > > If you do a rewrite() or reset(), do nothing with the file, but >> forget to close the file(s) before ending the program, malloc >> complains about a "deallocation of a pointer not yet allocated". I >> presume the post-execution mop-up doesn't handle unused files well -- >> ? > >Again, *I* don't. A testing example (see above) would really help. I didn't, or I'd have said so ;-) I only added the close() and the message went away. More to the point the usual things apply: I'm flat out so it'll be a while to get an example together as it'll take a while to reduce to a small e.g. (its part of a lot of code). I'm in the middle of chunk of Perl/JavaScript/CSS/HTML stuff so I don't want to further confuse my mind by going back to Pascal until this current project is done. (I don't know about other people but I find when jumping between languages too much I write an idiom from another language accidently once in a while which does no good at all. ) But hopefully I get back to it... >From the docs: > >: The last optional parameter determines the block size of the file. >: It is valid only for untyped files. Often 1 is a reasonable value here. >: However, the existence of this parameter is a BP compatibility feature, >: and in BP it defaults to 128 because of historic misdesign. Therefore, >: GPC requires this parameter to be present. In `--borland-pascal' mode, >: it makes it optional (like BP does), but warns about the strange >: default if omitted. I think my confusion must have come from the fact that all other other descriptions other than that for rewrite (append, reset, etc.) say its optional. They do hint to read rewrite for more details. I.e. read alone (without reading the rewrite section) the descriptions for append, etc. would be misleading. The impression I got on reading the "for more details see rewrite", was that'd it'd be more of the same in more detail, not that'd there might be something that'd contradict the text preceding it. I'd be good to add a line: "If you're using untyped files, the last parameter is essential; see rewrite for details." to the descriptions for reset, append, etc. BTW, I must sound like I'm nitpicking (which I hate). I can't contribute easily to the docs as I'm not familiar with all the Pascal variants that have emerged and that GPC supports in various ways. All I can do is pick up the odd bit that throws me for whatever reason. > > Macro expansion of __FILE__ seems to be inconsistent. In cases it > > expands to a full path and in others to just the local filename. It >> seems to be that if the file is in the local directory compared to >> the main program being compiled, just the filename is returned; if >> the source file is in another directory, a full path is returned. > >What do you suggest? Always a full path? I'd prefer a full path as that has all the info. Its easy enough to get a substring for the bits, etc. > > While there is a CurrentRoutineName there is no CurrentUnitName. It'd >> be useful to have this for debugging writes, to indicate which source >> file to look for a routine in. > >For this purpose __FILE__ would seem more useful (think of include >files), I think. True ;-) In that case I'd definitely prefer a full path for __FILE__ (think: alternative build directories, libraries, etc.) > > [Fussy one] Macros can't do C99's >> #define many_arg_fn(...) some_fn( __VA_ARGS__ ) >> trick. The GNU C compiler does support this & its very useful for >> debugging writes (which, in turn, are useful for test-driven >> development). > >I plan to rewrite the preprocessor, and deal with macro facilities >in this course. For one thing, I'll surely not try hard to be C >compatible (e.g., I plan to replace that `##' stuff with something >more readable). I haven't had varargs macros on my list so far, but >I might consider them. Any other comments? If debugging writes are >the only use, I'm not sure they're justified well enough. (But I'd >also have to see how hard it is to implement them.) I'll differ with you on this on :-) :-- I like the compatibility with C as it aids porting to/from C. As you know macros are very much a part of a lot of C code, etc. I dislike changes purely for cosmetics if it forces changes on existing code for no practical gain. I know C-style macros are ugly and can be fiddly to code, but for me there is practicality in gpc current macro's compatibility (to whatever degree) with their C counterparts. To be fair, I suppose I could rig things up to put my code through the C pre-processor... About varargs in macros. I don't mind that varargs might be too much work (fair enough - there aren't enough hours in the day to do the things I want to either), but saying that debugging writes aren't a good enough use to justify varargs to me is not so valid... Like debugging, testing and verification isn't important enough...?! I don't want to say too much without trying to work around their absence again, but I presume you've used varargs in this context to understand why its useful? (macros to mimic write/writeln which take multiple args are much easier, etc.) My own use of them in C is to generate output for testing scripts to compare against (code verification). These tests remain as a test suite, etc. Without varargs the output a bit limited. (more accurately it takes too much time to make all the write's needed to generate the output, so you're inclined to skimp on debugging/testing writes). That, in turn, limits the amount of testing material generated and the sensitivity of the testing material. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

2 1