March 2001 - Gpc

Suggestion: contributed units
by Eike Lange 20 Mar '01

20 Mar '01

Hi! There are a lot of units, someone has contributed. E.g. there is your email-unit, Nicolas svga-unit, my *sql unit and a lot more, which aren't in the GPC distribution. I'd like to suggest a _short_ description for each of these whithin our documentation. A possible good place could be Using GNU Pascal -> External Resources What d you think? Eike

2 1

Need GPC installation
by Mr. Veli Suorsa 19 Mar '01

19 Mar '01

Hi! I use latest Rhide and it works fine with Gnu C/ C++ and Fortran compiler. Some new features are still hoped ;-). I have tried to install GPC to Dos / Djgpp (from download sites a zip-file, >gpc20bb.zip). Can You help me, because I need pascal to my test and Gpc compiler don't works? Or can you tell me who can solve this problem! I have read your instructions and done all right, but they are not good enough to succeed installation in Dos / Djgpp. What should I do? With Best Regards and Thanks in advance! Veli Suorsa --- "People must believe to the future to be able to live!" ---------------------------------- J.V.Snellman, 1890. Oulu, FINLAND Mailto:VJSuorsa@Surfeu.Fi http://members.surfeu.fi/veli.suorsa/ http://www.surfeu.fi

2 1

Qualified Idents, possible work around...
by Orlando Llanes 19 Mar '01

19 Mar '01

I just thought of something, there could be one of two ways to call a "duplicate" function. The first way is using asmname, would that work with GPC compiled programs? The second way is to call the function by inserting Assembly Language. As for variables, would the above two methods work for them as well? See ya! Orlando

1 0

Networking in GPC
by Markus Gerwinski 18 Mar '01

18 Mar '01

Hello Folks! Are there any standard units for handling HTTP and FTP connections, sending e-mail and writing client/server software in GPC? Yours Markus

2 1

Validity check before downcasting / exception handling?
by Markus Gerwinski 18 Mar '01

18 Mar '01

Hello folks! When downcasting object pointers, I often wish there was a way to check the cast before. Peter has already told, in one of the next alpha releases of GPC there will be a new downcast-operator named 'as' firing a runtime error in case of an invalid downcast; like this: ... tBar = object ( tFoo ) ...; ... foo: pFoo; ... with foo^ as tBar do (* if "foo^" isn't a tBar actually, the 'as' *) ... (* interrupts the program with a runtime error. *) Nevertheless I'd like to have a way to check the validity _before_ casting, thus preventing the runtime error in cases where I don't want the program to be interrupted. Currently, I'd suggest the following additional functions in GPC itself: Function getObjectType ( obj: object ): "type"; Function isOfObjectType ( obj: object; runtimeType: "type" ): boolean; Example: ... p: pObject; ... p:= new ( pBar, init ); ... getObjectType ( p^ ) ... (* returns "tBar" *) ... ... isOfObjectType ( p^, pFoo ) ... (* returns "true", since tBar *) (* is derived from tFoo. *) For downcasting, I'd only need the latter one, but the first function seems useful to me, too. Alternatively, I could need a mechanism to absorb the runtime error fired by "as" before it interrupts the program. Something like this: foo: pFoo; ... with foo^ as tBar do ...; catchRuntimeError ( @procedureToHandleRuntimeError, parameters ); Anyway, when implementing a catchRuntimeError mechanism in GPC, it would not seem reasonable to me to just do it for this special kind of runtime error; thus, here we'd need a general exception handling mechanism to catch and handle _any_ runtime error without interrupting the program. Hope this description of my ideas wasn't too confuse... Yours Markus -- http://www.gerwinski.de/~markus/

4 4

Re: Rép. : Re: gpc en Mac OS X.
by Frank Heckenbach 17 Mar '01

17 Mar '01

Blady wrote: > <flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;0L;</param>Hi, > > [...] First of all: Your mail is *very* hard to read because of all these tags (they don't even appear to be HTML... what is it???). Please, when posting to this list, turn off all such tags, and use a reasonable line length (68 or 72 characters), thanks. > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: undeclared identifier `$f' (first use in this routine) > > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:650: undeclared identifier `$10' (first use in this routine) > > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:897: undeclared identifier `$deadbeef' (first use in this routine) Whoa, Borland-style hex numbers are mistaken as identifiers... > then I type this that fix it: > > make CFLAGS="-O -DMACOSX -g -fno-dollars-in-identifiers" I see. The option `--dollars-in-identifiers' enables `$' in identifiers, thereby breaking Borland-style hex numbers. Usually it is off by default, but apparently for some reason it's on by default in Max OS X (perhaps for GCC because there are system routines with `$' in them or something). Well, turning it off, as you did, fixes the problem. I'm now making `-fno-dollars-in-identifiers' the default for GPC on all platforms. General questions: Is this option useful at all? Does someone (or some other Pascal compiler) use `$' in identifiers, so we should retain this for compatibility, or is it just a GCC relic that we can drop? > By default the libm.a library is include in the ld command line so I disable it, since the library is not provided. > > Modifiction of gpc.c : > > << #define MATH_LIBRARY "-lm" > > -- > > > //#define MATH_LIBRARY "-lm" > > > #define MATH_LIBRARY "" AFAIR, the same holds for MS-Windows (at least Mingw, not sure about CygWin). I think the setting of MATH_LIBRARY in ../config/i386/mingw32.h makes sure that -lm is not linked there without haveing to change gpc.c. The same should be possible for Mac OS X, I guess, in the appropriate config file. If you find it, you can send us that change, so we can include it... > 3) link error : > > /usr/bin/ld -arch ppc -dynamic -lcrt1.o /var/tmp/cc0003231.o -lgpc = > -lcc_dynamic -framework System > > /usr/bin/ld: /usr/lib/libgpc.a(error.o) has external relocation entries = > in non-writable section (__TEXT,__text) for symbols: > > _memcpy > > _strlen > > Is there an explanation for that ? It seems to have something to do with GPC using `__builtin_strlen' and `__builtin_memcpy' for some CString operations. Apparently, they don't work well here. Try replacing `__builtin_strlen' (3 times in rts.c) and `__builtin_memcpy' (once in util.c) by simply `strlen' and `memcpy', then rebuild GPC, and let me know if this works. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 5

GNU Pascal Manual
by Clive Rodgers 17 Mar '01

17 Mar '01

A long-standing problem (irritation?) that maybe noone has mentioned is that the index link on every page (that I have tried) takes you to section 9.114 Index (under construction) rather than to section D. GPC Index. Clive ----------------------------------------------------------------------------- Atmospheric, Oceanic and Planetary Physics +44-1865-272905 (desk) Clarendon Laboratory +44-1865-272923 (fax) Parks Road Oxford OX1 3PU c.rodgers(a)physics.ox.ac.uk U.K. http://www.atm.ox.ac.uk/user/rodgers/ MIME, NeXTMail and SunMail attachments welcomed. HTML attachments tolerated Proprietary document formats (especially WORD) binned. Use rtf instead -----------------------------------------------------------------------------

2 1

fail to install gpc on Linux
by Johanna Johnston 17 Mar '01

17 Mar '01

I downloaded gpc-20010315.tar.gz (and per instructions, gcc-2.95.2.tar.gz) and followed the gpc INSTALL instructions with great success, (including "/home/jj/gcc-2.95.1/configure --enable-languages=pascal"and /home/jj/gpc-build/gcc/make) until I came to the install: "make install.pascal" This failed with make: *** No rule to make target `pascal.install'. Stop. I was unable to figure what I had done wrong. Any advice? There is no reference to "pascal" in my Makefile, I don't know where it should come from. My config.status file looks like this: #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: /home/jj/gcc-2.95.2/configure --with-gcc-version-trigger=/home/jj/gcc-2.95.2 /gcc/version.c --host=i686-pc-linux-gnu --enable-languages =pascal --norecursion # using "mt-frag" Thank you, Johanna ********************************* * Johanna Johnston * * Bay Computer Associates * * johanna(a)baycomp.com * * http:// www.baycomp.com * *********************************

4 3

Re: const isn't constant?
by Prof. A Olowofoyeku (The African Chief) 17 Mar '01

17 Mar '01

On 16 Mar 2001, at 13:00, Eike Lange wrote: > Hi! > With the following program, I get the error > storage size of 'Bar' isn't constant > Whats wrong? > Is there another way to tell the compiler the storage > size of a const value? > > > program test; > const > Foo : integer = 4; > var > Bar:array[1..foo] of integer; > begin > end. What you have done is to "misuse" an initialized variable as a constant (I think that BP calls them "typed constants"). While that may be accepted (with a warning under GPC) for some uses, it cannot be used as a constant value in declaring data types. Why? Because, as a typed constant, its value can be changed - then what happens to your array? The compiler needs a value that is truly constant (i.e., that cannot be changed) for these purposes. This is what you want; program test; const Foo = 4; var Bar:array[1..foo] of integer; begin end. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.24 for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

2 1

PACKED ARRAYS (was Re: Has class become a reserved word?)
by david＠tcs01.demon.co.uk 17 Mar '01

17 Mar '01

In message <20010310012841.A3478(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > David James wrote: > > Have there been any changes in the packing of data in records or > > packed records between 19991030 and 20010306? Or any changes in the > > data transfer between variables and typed files (is that the correct > > name? I mean FILE OF Twhatever, where Twhatever is a TYPE defined in > > the source)? > > I am not aware of any. > > But do not rely too much on such things since they might change, for > instance, when new types of processors show up. My need is that I have FILEs of Twhatever that have been written by executables compiled under GPC 19991030 and I now want to read them using executables compiled under GPC 20010306. Now I'd like to report a difference in this area (actually in the in-memory usage) between GPC19991024 and GPC20010306: The following program: program test9(input,output); const maxnum=4; TYPE T1=RECORD a1:array[1..maxnum] of byte; END; T2=RECORD a2:packed array[1..maxnum] of byte; END; T3=RECORD a3:packed array[1..maxnum] of 0..255; END; T4=RECORD a4:array[1..maxnum] of 0..255; END; begin writeln('t1: ',sizeof(t1):1); writeln('t2: ',sizeof(t2):1); writeln('t3: ',sizeof(t3):1); writeln('t4: ',sizeof(t4):1); end. gives t1: 4 t2: 4 t3: 16 t4: 16 under GPC20010306, and gives 4,4,4,16 under GPC19991030. That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

4 6