Gpc October 2004

gpc@gnu.de

23 participants
33 discussions

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

Re: GPC and Threads
by Jose Pascual 07 Oct '04

07 Oct '04

Hi Markus, first of all thank for you answer. > Jose Pascual wrote: > > I'm working in port some of my little application to linux. > All of my > > application has been writting in pascal. My porting to > linux is going > > ok but some of them use threads. > > > > I have read in GPC lists there are people working in a > thread unit for > > GPC, aren't you? > > Yep. great! > > Could someone share this unit with me? I could help to debugging it. > > I'm almost done with the threads themselves and mutexes. If > that is sufficient for your purposes, I'll put it online as > soon as I've finished testing. It'll be afable! I'm in a hurry so I have made some very alpha version with importing funtion from libpthread so I'd like to test your beta version. I'll need threading an semaphore in my application. Do you know (more or less) you are going to put it online? > > thank you so much > > You're welcome, > > Markus thank again best regards Jose Pascual

15 117

Brief comments / additions to docs
by Grant Jacobs 06 Oct '04

06 Oct '04

Here are a few random things I've spotted from a recent round of programming in GPC. (BTW - I know macros aren't part of Pascal, but they are useful, especially if you are porting code to/from C). Excuse me if any of these overlap with things previously covered - I haven't been following the list as I'm too busy of late. Debugging: If your source code is in multiple source files as units (or modules? - I've only tested for units), there is no need to specify the source filename as the GDB man pages suggest (e.g. break is defined as 'break [file:]function'). Just give the function/procedure name. Don't forget to make the first letter of the procedure/function identifier in uppercase - gpc adopts this (odd!) convention to avoid name-space conflicts with C and system libraries. Might be worth adding this to the docs - ? In my hands Exit doesn't seem to so much terminate the program as the proc/fn or the unit. Haven't tested this - I just gave up using it - but it certainly isn't stopping 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) rather than some sort of interface/implementation definition mis-match error. Its *very* confusing if you're down in the body of the unit looking at the source code for the function itself as its certainly present there and there is nothing to clue you into looking at the interface definition. 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 -- ? Reset() and rewrite() insist on the buffer size parameter rather than defaulting if an untyped file is used. OK, you can just set it to 1, but its not consistent with the definition of the procedures in the docs which indicate [to me!] that this is optional. 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. 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. [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). Just keeping you on your toes ;-) 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

Re: Overloads ?
by Waldek Hebisch 06 Oct '04

06 Oct '04

I have not seen Borland specs, but it seems that I independently arrived at similar rules. Let me consider few cases. Simplest is exact match overload -- types of arguments match exactly function arguments. I think we want to allow all such overloads. For example: type month_no = 1..12; servo_pos = 0..1000; for month_no modular increment may be more natural, for servo_pos intement should "stuck" at max value (both are differnt that normal increment). In general, we may want to have colletion of types and equip each one into given set of operations. I do not like discrimnating against subranges here... Next, we may distinguish between say strings and integers. In such case it is natural to allow subranges in place of integer arguments, and use just assignment compatibility. For objects, "standard" reasoning (assuming single inheritance) is: child is more special than parent, has all parent features, so child can appear when parent can apper. Hence, we would like to use most specific overloaded function, going up inheritance chain. We would like to avoid introducing many special cases, so for subranges it is also natural to take most specific one. Of course, with multiple arguments (and also for subranges), "more specific" is only partial order, so it may fail to uniquely determine outcome. Also multiple inheritance (even such as in Object Pascal) breaks linear order. I see the following solutions here: 1) forbid "unorderd" overloads (not so bad because one can force choice using casts, and such cases should be rare anyway) 2) impose some arbitrary order By the way, is 'var' parameter is used to produce a value, then exact match is requred which may in turn force many extra overloads. In such case 'copy in, copy out' parameters are more natural (or Ada 'in out'). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

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