Gpc February 2003

gpc@gnu.de

38 participants
76 discussions

Standard question: `New' with variant records
by Frank Heckenbach 03 Mar '03

03 Mar '03

Another standard question. Is the following valid: program Foo; type t = record case Integer of 1: () end; var v: ^t; begin New (v, 2) end. Some of GPC's test programs (not written by me) do something like this, but I doubt whether that's ok. As usual, the language of the standard (6.7.5.3 in EP) is somewhat confusing, so I'm better asking to be sure ... Another thing: The standard allows to set variant tags or schema discriminants in `New', but not both together. Is this an artificial restriction, or would there be some deeper problem with code like this: program Foo; type t (n: Integer) = record case Integer of 1: () end; var v: ^t; begin New (v, 42 { discriminant }, 1 { variant tag }) end. 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

2 2

`external name'; dropping `c', `c_language'
by Frank Heckenbach 28 Feb '03

28 Feb '03

As another small step towards cleaning up the `external' mess in GPC, I'm now implementing `external name', i.e. procedure Foo; external name 'bar'; will be equivalent to procedure Foo; external; asmname 'bar'; `external name' is BP compatible, AFAIK. I'm not yet changing the fact that `asmname' implies `external' for routines -- this should be done, too, but I'd rather do it together with other incompatible changes later. However, unless there's heavy resistance, I'd like to deprecate the `c' and `c_language' directives, and drop them in a later release. So, procedure Foo; c; should be turned to: procedure Foo; external name 'foo'; What about a plain `external' without `name' or `asmname'? Currently, this keeps the "default" asmname (first letter uppercase, the rest lowercase). Some time in the future, we'll need name mangling (for qualified identifiers and overloading), so the default asmname will be something ugly which one should not have to know about in order to write interfacing C code or such. Of course, it would be possible to make `external' set the first-uppercase-asmname even then, but I'm not sure how useful this is. (Currently, it's chosen as the default to avoid linker conflicts with "usual" C routines, but with name mangling, this won't be an issue.) So, to me it seems more reasonable to make a plain `external' set the asmname to all-lowercase (just like `c' and `c_language' do now). Then, procedure Foo; c; can be turned to simply: procedure Foo; external; But a current procedure Foo; external; will have to be turned to: procedure Foo; external name 'Foo'; (or the corresponding C code turned to `foo' in lowercase, which I'd usually recommend -- since these routines are explicitly coded, you usually know that there are no conflicts with libc etc.). Another question is whether `asmname' should be dropped entirely. In external declarations (the most common case), it can be turned into `external name' as described above. But there are cases where you need to set the asmname of a non-external routine or variable. But perhaps we can just use `name' then, e.g.: var Foo: Integer; name 'bar'; (instead of asmname 'bar'). The advantage would be to have another non-standard (conditional) keyword less. Or we could even use `attribute', something like: var Foo: Integer; attribute (name ('foo')); (or `asmname' -- that doesn't matter since within `attributes' we don't have the problems of keywords, anyway). This way, `name' would not be a real keyword (only special after `external'), at the cost of a little stranges syntax. But while we're at it, I think the attribute syntax can be simplified to var Foo: Integer; attribute (name = 'foo'); (also for other attributes with parameters, and without changing the existing syntax -- there wouldn't be any conflicts). I think this could be an acceptable way (syntactically), so `asmname' can be dropped. 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

8 18

SDL support in GNU Pascal...
by Dominique Louis 28 Feb '03

28 Feb '03

Hi all, Are there many people using GNU Pascal for game development? I am the project leader for the JEDI-SDL project ( http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME ) and my aim from the start was to provide Pascal bindings/headers for as many Pascal compilers as is feasible. Currently I support Delphi 4^, Kylix 1^ and FreePascal. I noticed that there is already a partial SDL conversion for GNU Pascal made by Eike Lange. I believe that my bindings are more complete at this stage and would like to incorporate support for the GNU Pascal compiler if someone on this list can tell me how I can make that possible. The latest JEDI-SDL ditribution, that shipped with Delphi 7 and Kylix 3, can be downloaded from http://www.sf.net/project/jedi-sdl/ . Any feedback would be greatly appreciated. L8R, Dominique http://www.DelphiGamer.com := go on, write a game instead;

2 2

Stupid Question
by Richard D. Jackson 26 Feb '03

26 Feb '03

When trying to use the Stringutils unit I've run into a issue. In that how do you determin the number of strings returned from the Tokenize funcions? For instance TokenizeString returns PPStrings but does not use a nil sentinal at the end of the array of strings. So with out the use of a nil sentinal how do you find out how many strings are being returned? The PPStrings are dynamicaly allocated so can't use SizeOf on it to get what I need. I know there must be a way to do it or the Tokenize routines would use a nil sentinal. I made a local copy of the routine I'm using and added a nil sentinal to it so I can get done what I need but I'm still wondering how you would do this. Thanks Richard

2 3

bootstrap broken in gcc-2.95.3 with new alpha
by Matthias Klose 25 Feb '03

25 Feb '03

Building the new alpha based on gcc-2.95.[34] using the bootstrap process fails with: make[5]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/ch' make[5]: *** No rule to make target `../cc1chill'. Stop. make[5]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/ch' make[4]: *** [cc1chill] Error 2 It is necessary to build the CHILL language as well to see this failure. The same setup works using gpc-20020910.tar.gz. Comparing the build logs during configure you see the following differences: @@ -703,7 +697,7 @@ creating po/Makefile.in creating util/Makefile creating config.h -linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/texinfo/intl/libgettext.h to intl/libintl.h +linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/texinfo/intl/libgettext.h to intl/libintl.h Configuring gcc... loading cache ../config.cache checking LIBRARY_PATH variable... ok @@ -808,10 +802,10 @@ checking whether setrlimit must be declared... no checking for sys_siglist declaration in signal.h or unistd.h... yes checking if mkdir takes one argument... no -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/i386.c' to output insns. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/i386.md' as machine description file. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/linux.h' as target machine macro file. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/xm-i386.h' as host machine macro file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/i386.c' to output insns. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/i386.md' as machine description file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/linux.h' as target machine macro file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/xm-i386.h' as host machine macro file. checking for strerror in -lcposix... no checking for working const... (cached) yes checking for inline... (cached) inline @@ -847,8 +841,6 @@ checking assembler subsection support... working .subsection -1 checking assembler hidden support... yes checking assembler instructions... filds fists -Adjusting /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/p/Makefile.in for gcc>2.8.1 -Adjusting /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/p/Make-lang.in for gcc>2.8.1 Links are now set up to build a native compiler for i386-pc-linux-gnu updating cache ../config.cache creating ./config.status @@ -859,16 +851,7 @@ creating cp/Makefile creating f/Makefile creating auto-host.h -linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/intl/libgettext.h to intl/libintl.h -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `ch/Makefile'. -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `objc/Makefile'. -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `p/Makefile'. +linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/intl/libgettext.h to intl/libintl.h creating libintl.h Configuring etc... loading cache ../config.cache Here you see, that the t-linux files don't get merged and the ch, objc and p Makefiles are not created. So what's different/wrong? Removing the two patches in the gcc-2.95.3 diff to *** gcc/configure.orig Mon Apr 9 11:27:06 2001 --- gcc/configure Thu Nov 14 16:36:27 2002 and *** gcc/configure.lang.orig Thu Nov 14 17:05:00 2002 --- gcc/configure.lang Thu Nov 14 17:05:09 2002 correctly generates the other Makefiles, but then stops in the p sub directory: Bootstrapping the compiler make[3]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc' make[3]: *** No rule to make target `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/p/Makefile.in', needed by `Makefile'. Stop. make[3]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc' make[2]: *** [bootstrap-lean] Error 2 The relevant change seems to be: 2002-11-14 16:59 Frank Heckenbach <frank(a)pascal.gnu.de> * config-lang.in: create a dummy Makefile.in if needed (can't always be avoided, it seems)-: ... So this does not seem to work (src != build in my case) * diffs/gcc-2.*.diff: patch the gcc configure to check if <language>/Makefile.in exists before trying to use it (code taken from the configure of gcc-3.1.1); similarly for configure.lang Tried to revert it. * Makefile.in: merged with Make-lang.in; file removed How to undo/revert this? Thanks for any help Matthias

2 1

help needed - build gcc-2.95.[34] based gpc-20030209 and CHILL
by Matthias Klose 24 Feb '03

24 Feb '03

I am trying to build gpc and CHILL using 'make bootstrap'. This leads to a bootstrap error pointed below. The same setup works well, if only enabling one of gpc or CHILL. Please could somebody try to reproduce this (my current setup is i386-linux / Debian GNU/Linux unstable)? I have no problems to build CHILL and gpc-20020910 together with the same setup. Thanks, Matthias cd ch; /usr/bin/make "AR_FLAGS_FOR_TARGET=rc" "AR_FOR_TARGET=` if [ -f /build/pa ckages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils/ar ] ; then ec ho /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils/ar ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ar; else t= 's,x,x,'; echo ar | sed -e $t ; fi; fi`" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g -O2 " "CLIB=" "GCC_FOR_TARGET=./xgcc -B/usr/i386-linux/bin/ -B./ -I/usr/i386-lin ux/include" "LDFLAGS=" "LEX=`if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds 15/build-native/gcc/../flex/flex ] ; then echo /build/packages/gcc/2.95/gcc-2.95 -2.95.4.ds15/build-native/gcc/../flex/flex ; else echo flex ; fi`" "LEXFLAGS=" " LN=ln" "LN_S=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=` if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils /ranlib ] ; then echo /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native /gcc/../binutils/ranlib ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ranlib; else t='s,x,x,'; echo ranlib | sed -e $t ; fi; fi`" "RANLIB_ TEST_FOR_TARGET=[ -f ` if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/bui ld-native/gcc/../binutils/ranlib ] ; then echo /build/packages/gcc/2.95/gcc-2.95 -2.95.4.ds15/build-native/gcc/../binutils/ranlib ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ranlib; else t='s,x,x,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] && [ -f /us r/bin/ranlib -o -f /bin/ranlib ] )" "SHELL=/bin/sh" "STAGE_PREFIX=stage1/" "exee xt=" "build_exeext=" "objext=.o" "exec_prefix=/usr" "prefix=/usr" "local_prefix= /usr/local" "gxx_include_dir=/usr/lib/gcc-lib/i386-linux/2.95.4/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/]*|/..|g'`/include/g++-3" "tooldir=/usr/i38 6-linux" "gcc_tooldir=/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux" "bindir=/usr/bin" "libsubdir=/usr/lib/gcc-lib/i386-linux/2.95.4" "datadir=/usr/ share" "distdir=../tmp/\$(subdir)" "localedir=/usr/share/locale" "CC=stage1/xgcc -Bstage1/ -B/usr/i386-linux/bin/" "CHILLFLAGS=" "CHILL_FOR_TARGET=cc" "CHILL_LI B=-lchill" "GNUCHILL_VERSION=1.5.2" ../cc1chill make[5]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build -native/gcc/ch' make[5]: *** No rule to make target `../cc1chill'. Stop. make[5]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc/ch' make[4]: *** [cc1chill] Error 2 make[4]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc' make[3]: *** [boot_stage_c] Error 2 make[3]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc' make[2]: *** [bootstrap-lean] Error 2

1 0

beautifier
by Mehdi Khaldi 24 Feb '03

24 Feb '03

Hi, Where can I find a beautifier for my pascal program? Thanks

1 0

Re: gpc-20030209 (capitalization error message)
by Tom Schneider 24 Feb '03

24 Feb '03

> So, what's best now, "varying capitalisation", "varying capitals", > "mismatched caps"? > "varying capitalisation" would be my choice > "varying letter-cases" may be clearer, and it avoids > the ambiguity on "cases" that started the discussion > Keep it short. Maybe "varying id letter case: <oldid> <thisid>"? > Perhaps "mismatched <oldid> <thisid>"? It has to be CLEAR which means things like 'caps' won't do because it is not obvious that this is an abbreviation. How about straightforward English: The capitalization of the definition <original> does not match <current>. or more tightly: Capitalization of definition <original> does not match <current>. This way there would be no question as to what the message means. I think that a few extra bytes for clarity is worthwhile. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

7 8

bug in new alpha
by Russell Whitaker 24 Feb '03

24 Feb '03

hi minwidth for strings in writeln is broken: program hello; begin writeln('hello':30, ' ':30, 'world'); end. The output should be 25 spaces in front of hello and 30 spaces between hello and world. Russ

4 6

Update for Mac OS X
by Adriaan van Os 24 Feb '03

24 Feb '03

Updated sources, binaries and patches for GPC on Mac OS X can be downloaded from <www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

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 February 2003