Gpc

gpc@gnu.de

5400 discussions

gpc beta
by Lisa, Sian, Becki and Richard 31 Oct '97

31 Oct '97

I have just downloaded gpc beta for installation on a debian 1.3.1 system. I may become the new debian gpc maintainer, within the next month. Richard

1 0

Binary installation
by Tom Dye 31 Oct '97

31 Oct '97

Hello, Sorry to bother all of you with a question that is a bit off center for this list. After using gpc for several months I upgraded to the latest beta binary and managed to break everything. I don't know enough about the C compiler or Unix to puzzle this problem out for myself so I'm asking for whatever guidance you might be able to provide. My machine is running Linux RedHat 4.2. I think the problem is a temporary file that is created in the first step of the compile. My guess is that it is empty, but when everything is finished failing the file is gone so I can't have a look. I did save the output to standard error in the hope that it might mean something to someone who knows about such things. Here it is: /tmp/cca02238.i:1: numeric constant with no digits /tmp/cca02238.i:1: numeric constant with no digits /tmp/cca02238.i:1: invalid #line /tmp/cca02238.i:11: warning: missing program header /tmp/cca02238.i:11: parse error at null character If there are other diagnostics, I'll be happy to collect them and pass them along. Thanks much for your patience and help. I am loathe to embark on the project that would have me finding and installing the proper version of gcc so that I can compile gpc. Hopefully, it will be possible to get the binary version up and running. Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

Re: Problems with strings in GPC beta 971001
by Frank Heckenbach 30 Oct '97

30 Oct '97

Jesper Lund wrote: > Regarding the discussion of GPCs 3-4 different string types and the *planned* > generic string (AnyString): > > Could you use the Extended Pascal string (augmented with the extra byte to > hold the #0 char) as the generic string (AnyString), and let the compiler add > the necessary conversion code (Borland <-> EP string; Cstring <-> EP string; > array of char <-> EP string) whenever the program calls a built-in function > with a different string type than EP string? For value parameters, this seems the best solution, indeed. For constant parameters, things are even easier, because a capacity is not needed, so we only have to pass the address of the first character and the current (constant) length. However, what's problematic is var parameters. Since the procedure must be able to change their length, and that's done differently for each of the four string types (EP: setting an integer; BP: setting a byte; SP: filling with spaces; CString: setting a #0 terminator)-:, the procedure has to know the actual string type. According to my suggestion of AnyStrings, a procedure with a var AnyString parameter could do the following operations on it, which will do the right thing for the actual string type transparently to the programmer: - Length - AssignLength - Capacity - Assignment to/from other strings of any type. (This includes passing as value or const parameters.) - Passing as var parameters of AnyString (not "any string"! ;-) type - Accessing single characters with "[n]" -- where I'm not sure if the index should always start at 1, or as in the original string/array. The former would be easier to handle; for the latter, the starting index would have to be passed (internally), too. Of course, when we have AnyString, it's quite easy to convert all string parameters in the RTS functions to AnyString, so those functions will work on all string types. > P.S. Peter and Frank; you *have* convinced me that there is a need for the > Borland string type. When I wrote the message yesterday, I didn't realize > that there were so many undocumented BP features, nor the extent to which > people used them to work around limitations and inefficiencies in Borland > Pascal. Honestly, I wasn't aware of the extent until I came to GPC, though I'd been using the things in BP for years... > But you will probably have to draw a line somewhere: supporting any > undocumented feature in BP must be an implementation nightmare ... We've decided, *not* to produce a warning in "--borland-pascal" mode when the data exceed 64 KB... ;-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Does GPC have structured constants ?
by richard.kerry＠quantel.com 30 Oct '97

30 Oct '97

Does GPC have structured constants, as found in Oregon and Vax Pascal ? eg. type ThreeNumbersType = record a, b, c: integer; end{record}; const FirstConst = ThreeNumbersType( 1, 2, 3 ); SecondConst = ThreeNumbersType( 42, 64, 96 ); procedure StructuredConsts; var fred, bill: ThreeNumbersType; begin fred := FirstConst; bill := SecondConst; end; I know there's the schemas, but they change these from a constant declaration to a type or variable declaration and I'm trying to get the simplest possible (machine) translation from Oregon Pascal to GPC. Here's hoping the answer is "yes, do it like this ..." Richard

1 0

Re: Does GPC have structured constants ?
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to richard.kerry(a)quantel.com: > > Does GPC have structured constants, as found in Oregon and Vax Pascal ? Yes, do it like this: Type ThreeNumbersType = record a, b, c: integer; end (* ThreeNumbersType *); Const FirstConst: ThreeNumbersType = ( 1, 2, 3 ); SecondConst: ThreeNumbersType = ( a: 42; b: 64; c: 96 ); > Here's hoping the answer is "yes, do it like this ..." Hope this helps, ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Sizeof LongInt
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to Jesper Lund: > > Is code written using the portable `Integer ( 64 )' as efficient as code > using the type `LongInt' (assuming that LongInt is 64-bit), or is there some > performance loss? In short: There is no performance loss. :-) In long: If `LongInt' is 64-bit, then `Integer ( 64 )' is exactly the same as `LongInt'; if, on another machine, `Integer' is 64-bit, then `Integer ( 64 )' is exactly the same as `Integer'. A loss of performance can only occur on machines without registers whose width is a divisor of 64 - which I have never seen. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Sizeof LongInt
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? Not guaranteed. It might be 16 on some systems. > I am asking this because writing a good pseudo-random number generator is a > lot easier (transparent) and more efficient (execution speed) if a 64-bit > Integer is available. Use `Integer ( 64 )' which is guaranteed (to the extend of the GPL;-) to have 64 bits. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: gpc on Linux
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Tomaz kolenko: > $ gpc -v > gpc version 2.0(2.7.2.1) I meant: `gpc -v yourprogram.pas'. ;-) But never mind ... > Thank you for reply. Probably I should tell that I use Debian Linux. Yes, that's an important information. This problem already was discussed on this list in March 1997. (You can look it up from the archives which are reachable from http://home.pages.de/~GNU-Pascal/support.html.) To symlink `libgpc.so -> libgpc.so.2' in `/usr/lib' was reported to work. Hope this helps, Peter PS: Better always mail things like this through the GPC mailing list because there might be others on this list having the same problem. Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Portable random numbers
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > > Is there a well-defined standard for the ANSI, GNU or BSD `rand' function? > If so, where can I find it? The only thing I have is the source code for > rand in my DJGPP C library. What I have seen is the source code of the BSD random number generator. It contains kind of scientific paper about why these are good random numbers. BTW, to initialize the actual random number generator - and only for this purpose -, they use yet another, very primitive random number generator which has about the same quality as that of BP ... ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Trapping I/O runtime errors in GPC
by The African Chief 29 Oct '97

29 Oct '97

Bill Currie wrote: > > On 27 Oct 97 at 8:50, Frank Heckenbach wrote: > [...] > > - After calling an I/O function, if {$I+} is turned on, the calling > > program > > must check InOutRes. The code to be generated (perhaps you've > > already done so) would look like "if InOutRes<>0 then _p_ioerror;" > > where _p_ioerror will be a RTS function I can provide. (The check > > "if InOutRes<>0" could also be done in the function (like in BP!), > > but that's inefficient, because the function has to be called > > after each I/O operation then.) > > Actually, that's almost exactly what my mods do. If IO checking is > enabled ( {$I+} ), a proceedure taking no parameters is called that > would check the InOutRes state (though I used a different name) and > if it's set dumps a dirty message and aborts the program. For compatibility with BP, you would need to call the variable "InOutRes", and it should be exported, so that programmers can set it manually if they want (this feature of BP might be considered to be a bug by some, but I have found great use for it ...). Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

2 1

Jump to page:

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