Gpc April 1997

gpc@gnu.de

24 participants
111 discussions

Re: New Alpha
by Peter Gerwinski 03 Apr '97

03 Apr '97

According to Frank Heckenbach answering to a mail by Phil Nelson: > Ok, then, if I got this right, you have to do > write(num_var:1) and write(string_var) > for output without spaces, whereas > write(num_var) and write(string_var:1) > both don't work this way. > > This seems a bit inconsistent and confusing to me. To me, too. That's why I prefer Borland's way to default to a width of 0 (or 1 in the above example) if nothing was specified (which does not contradict the standard, BTW), and to treat string values just like all the other ones, i.e. without clipping. > I see that your programs rely on this way, but my programs rely on BP's > way, and I don't think there's anything worse with BP's way than the > standard's way. So, obviously, gpc needs to support both ways. So it's okay that "gpc --borland-pascal" does switch off string clipping, while "gpc --standard-pascal" or "gpc --extended-pascal" turns it on. There must also be a pair of separate switches, e.g. "--clip-strings" and "--no-clip-strings", to make this decision independent of the selected Pascal dialect. (*** Does anybody know how UCSD behaves here? I don't want to dig out my old Apple //e in order to check this. ***) Now what about default field widths? The ISO Standard allows this to be implementation-dependent. If we just take Borland's method it still complies to the standard, so there is no a-priori reason to make this change at all. However it seems to be a de-facto-standard that ISO Pascal compilers have default field widths that are wide enough to ensure that numeric values are always output with leading spaces. Thus `--standard-pascal' and `--extended-pascal' should imply such wide field widths. Of course there must be a separate switch for them, for example "gpc --field-widths=12,24,6" (for Integer, Real, Boolean values). The above does not clarify how GPC's default behaviour should be. IMHO Borland's method is more logical than what most Standard Pascal compilers do. However the only true contradiction between Borland and ISO in this context is string clipping which only occurs in very rare cases (at least in my programs). Thus I could live with string clipping being "on" by default. Concerning field widths, it does not contradict ISO Standard to follow Borland, so we should do that. (Remember that `--borland-pascal' turns string clipping off and that `--standard-pascal' makes GPC behave like other Standard Pascal compilers.) BTW, there are some other strange things in GPC's interpretation of field widths: * When an Integer value is being output with a field width of zero, output is suppressed. Is this ISO Standard (doesn't seem so), or a bug? * When a Real value is being output with a too narrow field width, other compilers bother to make the output as short as possible. Should GPC do the same? * All Pascal compilers I have access to have the "feature" that it is impossible to output a positive Real value without at least one leading blank. This is annoying in some situations, so what about an additional switch, e.g. `--no-real-blank', to disable it optionally? (Better suggestions for the names of all compiler switches are welcome!) That's it for the moment. Sqr ( BTW ), this switcherism makes it more and more necessary to let GPC read in a configuration file, or to use `make' to keep all these switches in a Makefile, or to use RHIDE which provides a menu for them. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Command-line options and CFG file (was: New Alpha)
by The African Chief 03 Apr '97

03 Apr '97

On Wed, 2 Apr 1997 20:11:12 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> [...] In case you haven't done this, can you >> introduce a .CFG file (like with Borland) where one can >> put all the command line switches that they want to use? > >I have an old version of GCC for some special hardware here (without >source #@*!) which accepts a `@filename' option pointing to a file with >additional options. We could, for example, do the same and make > > gpc @gpc.cfg > >read a file `gpc.cfg' in the current directory. Yes, that would be nice. But why not just let it look for a 'gpc.cfg' file automatically? It could then take whatever it finds there as command line parameters (in addition to any other ones passed at the command line itself). There could also be provision for making comments in the .cfg file). I apprecite that looking for, and reading a .cfg file automatically may be strange to those not coming from a BP or DOS background, so I don't think that this is a wish that requires too nuch attention. >> You can make many sample .CFG files >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people >> can then rename to GPC.CFG or whatever. > >In principle this is not necessary: By default, GPC understands all of >these dialects (as far as implemented) and you can specify one (or more) >of `--standard-pascal', `--extended-pascal', `--borland-pascal' to >restrict GPC's language to the specified dialects. Ok. BTW: having just downloaded and installed GPC 2.0 and some of the DJGPP stuff referred to in the docs, I still can't get anything to compile. The place where I am stuck now when I try to compile is this message: "C:\DJGPP\BIN/ld.exe: cannot open linker script file djgpp.lnk: No such file or directory (ENOENT)" A search through my disk shows that no file with the .lnk extension exists. Any clues? This is not in the FAQ! Thanks. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

Re: New Alpha
by Frank Heckenbach 03 Apr '97

03 Apr '97

Peter Gerwinski wrote: > > > * Field widths now default to left-justified output. > > > > Did I miss a discussion on this? Doesn't this break a lot of programs? > > Or is this with "--borland-pascal"? > > Perhaps my formulation was misleading: I mean that > > writeln ( 123 ); > > will no more yield the output > > _______123 > > (with seven blanks), but instead > > 123 > > (left-justified). To produce "_______123" you must explicitly say > "writeln ( 123 : 10 );". Perhaps you should write "field width now defaults to 0" (or 1 - what is it?). By "left justified" I would mean "123_______". Since Phil mentioned why the default was a bigger width, I now think this should be toggled by the --borland-pascal switch, and a separate switch as well. E.g., I try to make my programs not dependent on the --borland-pascal switch, but this problem (together with the "clipping" in standard Pascal) would require a lot of changes that I can't do soon... BTW: Phil, how do you output a number without spaces (or, let's say with exactly one space) in standard Pascal, e.g. to write the simple line "There are 7 items" (with 7 being the value of a variable)? With no (or a big) format specifier, there would be more spaces than wanted, with a small format specifer, large numbers would be cut. Or does this "clipping" only apply to strings? But then again, how would you do "You name is Phil."? Do you have to "write(s:Length(s))" or such? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: C Header Files -> Pascal
by Frank Heckenbach 03 Apr '97

03 Apr '97

Carl-Eric.Codere wrote: > Greetings, > Supposedly it was the following link: > http://www.rrze.uni-erlangen.de/~sz2104/fpkpas.html but I should have > checked before speaking my voice! The server does not seem to respond, I > will e-mail Florian about this. I heard his university was moving (no > joke!), that may be the reason for the problem. If I can get a hold of > the program i will put it on my web page and will let you know. Oops! I think I ought to know if our university was moving... :-) I guess he meant he was moving to another university, since his new mail address (from the FPK homepage) is klaempfl(a)haegar.cip.mw.tu-muenchen.de Well, at least currently the above URL does exist, I just checked. Indeed, there is "H2PP.ZIP" (convert C header files to pascal units) there, but I didn't try it out yet. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Linking directives (was: C Header Files -> Pascal)
by Frank Heckenbach 03 Apr '97

03 Apr '97

Peter Gerwinski wrote: > If you really > must rely on C headers which change from time to time, ...or from system to system... > it is probably > the most reasonable thing to write a C module which uses the header > files and exports some well-defined functions. Then you can write a > Unit which imports these functions as `external' functions and makes > them accessible for your Pascal program. That's what I did. Specifically, I needed a routine to measure the CPU time. There is a C routine declared in time.h, but it uses a constant (#define) and a type (typedef). The value of the constant, and even the type (int or float) can vary on different systems, AFAIK. So the only way to use it in Pascal - without modifying the program on every system - is to write a Pascal wrapper, or is there any easier way? > Another thing I did experiments with was a C program which includes > the header files and writes out Pascal source for all constants > defined in the header. Wouldn't exactly make the program building process easier... :-| And, as I see it, there's no way to handle types defined in the C header, is there? (Well, there are not too many types in C programs, but anyway... :-) > According to Sven Engelhardt: > > nb. any way to issue linker-options (-lxxx -L) as preprocessor- > > directives, so one could write rater developer-friendly code. > > This is planned. > > My idea was to make "(*$L foo.o *)" equivalent to a file name `foo.o' > given in the command line. One could also make "(*$L /usr/lib *)" > equivalent to "-L /usr/lib" because GPC can check whether the given > name refers to a file or a directory. Something to add to this: it would be great if one could give a C file which would be compiled (if necessary) and the resulting object linked in, like {$L foo.c}. Then one could make any Pascal program with --automake, even if it uses some C files. BTW: Is it allowed with the current versions to give C files on the command line? I tried the following with the 0226 or 0227 version: gpc -o homology gettime.c sysdep.pas calc_hom.pas homology.pas With DJGPP, this works fine. But with Linux, it gives the message: In file included from /usr/include/features.h:134, from /usr/include/time.h:26, from gettime.h:4, from gettime.c:4: /usr/include/sys/cdefs.h:40: parse error However, the following works with Linux: gcc -c gettime.c gpc -o homology gettime.o sysdep.pas calc_hom.pas homology.pas Is this an installation problem on my system or a general problem? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: New Alpha
by The African Chief 03 Apr '97

03 Apr '97

On Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >(left-justified). To produce "_______123" you must explicitly say >"writeln ( 123 : 10 );". > >The Standard says that these default widths are implementation-dependent. >There was a short discussion about whether GPC's behavior (default width >10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. >We soon agreed that it would be better to produce left-justified output >when no width has been specified. Otherwise, you would have to say >"writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy >and misleading. We forgot to post a copy of the discussion to the list; >sorry about that. > >In case you have some arguments to set it back to the previous state, >just post it here. (These are only some constants in `rts/rts.h', so it >was not much work to change. Perhaps (yet another) command-line switch >would satisfy everybody?) I think this could be the way forward. Having a multitude of command line switches is very good, in that it gives the programmer more flexibility to use the compiler in the way that he/she likes, not in the way that somebody else thinks they should. However, the price of flexibility is complexity. In case you haven't done this, can you introduce a .CFG file (like with Borland) where one can put all the command line switches that they want to use? The compiler will read the .CFG file before doing anything else, and will adjust its behaviour accordingly. I personally prefer this approach to using environment variables or the such. You can make many sample .CFG files (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people can then rename to GPC.CFG or whatever. Sorry if all this already exists. I lurk in this list, because I am quite interested in GPC and its future (and its potential to release me from arbitrary decisions made by certain companies about where their compilers are going) but I am yet to fully utilise GPC myself. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

3 2

Command-line options and CFG file (was: New Alpha)
by Peter Gerwinski 02 Apr '97

02 Apr '97

According to The African Chief: > [...] In case you haven't done this, can you > introduce a .CFG file (like with Borland) where one can > put all the command line switches that they want to use? I have an old version of GCC for some special hardware here (without source #@*!) which accepts a `@filename' option pointing to a file with additional options. We could, for example, do the same and make gpc @gpc.cfg read a file `gpc.cfg' in the current directory. > The compiler will read the .CFG file before doing anything > else, and will adjust its behaviour accordingly. I personally > prefer this approach to using environment variables or the > such. So do I. > You can make many sample .CFG files > (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people > can then rename to GPC.CFG or whatever. In principle this is not necessary: By default, GPC understands all of these dialects (as far as implemented) and you can specify one (or more) of `--standard-pascal', `--extended-pascal', `--borland-pascal' to restrict GPC's language to the specified dialects. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: New Alpha
by Peter Gerwinski 02 Apr '97

02 Apr '97

According to Phil Nelson: > Thanks MUCH for all your work on gpc. You have greatly improved the > compiler!! Thank you! :-) My next goal are Schema types ... But I am sure that there are still bugs in the new features, especially in the import mechanism. > I do have a couple of questions about the most recent alpha. > > > * Field widths now default to left-justified output. > > Did I miss a discussion on this? Doesn't this break a lot of programs? > Or is this with "--borland-pascal"? Perhaps my formulation was misleading: I mean that writeln ( 123 ); will no more yield the output _______123 (with seven blanks), but instead 123 (left-justified). To produce "_______123" you must explicitly say "writeln ( 123 : 10 );". The Standard says that these default widths are implementation-dependent. There was a short discussion about whether GPC's behavior (default width 10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. We soon agreed that it would be better to produce left-justified output when no width has been specified. Otherwise, you would have to say "writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy and misleading. We forgot to post a copy of the discussion to the list; sorry about that. In case you have some arguments to set it back to the previous state, just post it here. (These are only some constants in `rts/rts.h', so it was not much work to change. Perhaps (yet another) command-line switch would satisfy everybody?) > > * `For' now accepts components of structured variables as control > > variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". > > Why? In short: Why not? In long: Indeed, the standard only allows an entire variable in this context. Thank you for pointing me to this; I will make this extension trigger a warning if `--standard-pascal' or `--extended-pascal' has been specified. (With `--pedantic-errors', the warning will be an error message.) But Borland Pascal allows this, I got it "for free" (just changed one line in `gpc-parse.y'), so why not allow it, too? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: C Header Files -> Pascal
by Peter Gerwinski 01 Apr '97

01 Apr '97

According to Berend de Boer: > When my Lex/Yacc compile I'll try to do such. > [...] It's great that you are all planning to write the C header -> Pascal converter, but please don't forget to coordinate your work. ;-) And have a look at Florian's development first, as Carl-Eric Cod\hre reported. BTW, Carl-Eric, you didn't tell us an URL. Do you mean Florian Klaempfl's FPK Pascal page, http://home.pages.de/FPK-Pascal/ ? I think it's a good idea to coordinate with FPK-Pascal. We are both producing free software and can learn from each other; we are no competitors like e.g. Borland and Microsoft. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

2 1

New Alpha
by Peter Gerwinski 01 Apr '97

01 Apr '97

Hello folks, it's time again for a new GPC alpha version. Changes since gpc-970227: * Field widths now default to left-justified output. * Some bugs fixed concerning field widths. * Strings being too long for the field are now output completely if `--borland-pascal' has been specified. * `For' now accepts components of structured variables as control variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". * `--pedantic-errors' no more implies `--pedantic'. Like this, you can specify `--pedantic-errors --extended-pascal' and you will get error messages when using Borland extensions, but no warnings for ISO 7185 Standard Pascal violations (i.e. the ISO 10206 extensions). * Fixed bug concerning empty sets. * Fixed bug concerning Strings without specified capacity as value parameters. * Initialized sets now work in procedures. (They still don't work in the main program or in the top level of a Unit.)-: * Fixed bug concerning arrays as `Const' parameters. * `Char' subranges like 'A'..'Z' work again. (Was broken in gpc-970115.) * `Const' parameters of known, small size are passed by value now. In this cases, `Const' is equivalent to `protected'; otherwise `Const' is equivalent to `protected Var'. * Now you can pass constant values to `Const' or `protected Var' parameters. * In Extended Pascal Modules, the following features have been implemented: - Export and import renaming, - `protected' export, - `only' import. * Fixed some bugs in the GPI mechanism, in particular concerning pointers and `Var' parameters. * `Asm' works again. (It was broken in gpc-970115 - and it still has problems with input and output registers.)-: * Fixed a bug concerning conformant arrays. If you have programs which use conformant arrays GPC didn't compile up to now, please retry and report remaining bugs. * `New' applied to "^String" variables (i.e. pointers to String Schemas without specified capacity) works now: you call `New' with a second parameter being the desired capacity of the newly allocated String. The source - a diff against gpc-970226 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ Binaries for DOS (DJGPP), Linux (ELF), and FreeBSD will follow this evening after 21 o' clock MET (when it will be less expensive). I thank Berend de Boer for many useful bug reports and the donation of a licensed copy of the Prospero Extended Pascal compiler. I also thank Stephen Lindholm, Tomas Srb, Miklos Cserzo, and Frank Heckenbach for reporting the bugs mentioned above. (* If I forgot your name, it's a bug - please report. ;*) And I thank everybody on the GPC mailing list for fruitful discussions about the future of GPC. I hope you had a happy Eastern. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

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 1997