Gpc

gpc@gnu.de

5400 discussions

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

28 Oct '97

According to Tomaz kolenko: > When compiling pas files with gpc I get a message: > cannot open -lgpc: No such file or directory > Version of gpc and gcc is 2.7.2.1 This looks like an installation problem. Please make sure that GPC can locate the file `libgpc.a'. It should be together with `gpc1' and `gpc-cpp' in a directory `/usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/'. Alternatively, you can keep `libgpc.a' in a directory in your library path, for example in `/usr/local/lib/'. If all this fails, please run `gpc' on your program with the `-v' option and post the output here. 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: String types in future GPC versions
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Jesper Lund: > According to myself (Peter Gerwinski): > >According to Extended Pascal, strings are written with parentheses > >("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax > >("Str255 = String [ 255 ]"). In the future we *might* change this such > >that GPC produces an Extended Pascal string (unlimited length, 8 bytes > >overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, > >1 byte overhead) with "[...]". > > Wouldn't that feature (choosing between two memory allocation/outline schemes > for strings) create a lot of problems for relatively little benefit? > > First, if I have a procedure with a var string type, > > procedure foo (var s : string) > > can I pass variables of either string type (Borland or Extended)? No, but you can pass them to Procedure Foo ( S: String ); or to Procedure Foo ( Const S: String ); > Second, a string variable in Borland Pascal does not contain information > about the maximum length (like the capacity field in GPC), so for procedures > that need this information (like Readln), the string capacity would have to > be passed as an implicit parameter (or am I missing something?). I thought about letting it overflow silently, but passing the capacity as an implicit parameter would be a good idea, indeed. > Finally, and most importantly, why is feature this needed in the first place? > [...] > > 1) A program reading string variables from a binary file created by a > Borland pascal program (.exe file). [...] I agree that this would not really be an issue. > 2) GPC "wastes" more memory than Borland Pascal [...]. This is one reason why I think that `ShortString's are desirable. The 8 bytes do certainly not matter in, say, a text processor handling strings with a typical length of 100; they do matter in a program that handles a large number of short strings with a typical length of 8. In this second case, an overhead of 8 bytes would double the needed amount of memory. But I'd like to add: 3) There are many programs written for Borland Pascal and/or Delphi waiting to be ported to GPC, many of which relying on the data format of strings in UCSD/Borland Pascal/Delphi in merely two cases: (a) explicit manipulations of `S [ 0 ]' (one may consider them broken, but they are *many*)-:, and (b) calculations of the current size as `length ( S ) + 1'. There already was a discussion about a `ShortString' type for GPC on this list in May 1997. The conclusion was to make it compatible to Borland's `String' type like other Extended Pascal compilers and Delphi do. 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: us_Timer in TimeStamp
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Kevin A. Foss: > > Well the proposal in the GPC docs also adds a TimerValid field, just > set that to False if the system doesn't support gettimeofday(), which > is already checked for in rts-time.c. Yes, that would be straightforward. Shouldn't the field better be called `us_TimerValid'? 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: rand unit (was: us_Timer in TimeStamp)
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Kevin A. Foss: > > IMHO, this code is still broken. On a non-DOS platform it tries to > pass an integer to a function expecting a cardinal and always returns a > type check error and doesn't compile. Uh - sorry! #-) GPC checks whether the return type of the function matches the expected parameter, and if that's not the case, it tries to pass the function itself as a parameter. It should check whether the return type of the function *is assignment compatible* with the type of the expected parameter ... I am noting this as a GPC bug report (kevin1.pas). However one can work around this by letting `GetPID' return a `Cardinal' instead of an `Integer' thus disallowing negative PIDs. 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: Portable random numbers
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >IMHO, this code is still broken. On a non-DOS platform it tries to > >pass an integer to a function expecting a cardinal and always returns a > >type check error and doesn't compile. Is there some advanced switch > >that should be used in situations like this to turn off type-checking > >(I've never really looked at all of the directives and didn't see where > >they were in the docs after a quick look) and the type-casting section > >is empty. > > > >The code in question: > >FUNCTION Rand:Integer; C; > >PROCEDURE SRand(Seed:Cardinal); C; > >FUNCTION GetPID:Integer; C; > > > > Regarding portability: in my DJGPP C library, there is no `srand' function, > but a `srandom' function which expects an int (=Integer) as parameter. Hold it, please! The code fragment you're quoting is inside an $ifdef. It's not used in DJGPP. Please refer to the complete unit. I posted it here recently, and I'll make it available under the following URL tomorrow or so: http://home.pages.de/~fjf/rand.pas > I don't see how this should emulate the Randomize procedure in Borland > Pascal. The DJGPP code does so, and that's all I claimed. On non-Dos systems, it's almost impossible to emulate BP's behaviour since it depends on the internal system timer format used by Dos. I now added a comment to the unit making this clear. > According the info docs for my C library, getpid returns the unique > process number for the program running on the system. If you call getpid > twice in the same program, you get the same integer. (* This can happen (with Randomize) in BP, too, if within the same 1/18.2 seconds interval. Therefore, doing so is not recommended! *) > Why not compute a seed > from the system time (somehow), as Borland Pascal does? If you tell me how to do it, I'd like to! To do it "good", we'd need more than 1 second resolution, and getting this was the original problem here... > That is, if we need a Randomize procedure at all? My C library (DJGPP) > doesn't have such a beast. Ok, there is Borland compatibility .... Well, there must be any way to seed the Random randomly... :-) Otherwise, the program would produce the same sequence of random numbers in each run. AFAIK, the usual way to do so in C under Unix is GetPID, therefore I did it like that. A better general way would be most welcome. > I use random numbers a great deal in my work (statistical simulations), and > in most cases (if not all) I specify the seed myself, since this is the only > way of gettting reproducible results. There'd be no problem doing so with my unit (though it should not be used here, because it's only for BP compatibility). OTOH, I'd guess, most game programmers wouldn't like this behaviour... ;-) > When I was programming in Turbo Pascal (the pre-GPC era), I *never* used the > Random function in the system unit because I did not have source code and > thus couldn't see how the pseudo-random sequence was generated. There are a > lot of bad (= non-random) random number generators out there! True. BTW, my unit uses the same algorithm (though, of course, completely different code) as BP (7.0 at least). Now you can check if it's a good algorithm. The main formula is: RandSeed := $8088405 * RandSeed + 1 {mod 2^32} > The following piece of code represents a widely used procedure for generating > uniform random numbers (reals between 0.0 and 1.0), but it could easily be > changed to generating integers between 0 and 2^31-1 (just modify the last > line in RanUni). > > The routine is portable to all systems with a 32-bit integer type. It does > not rely on controlled overflow which may not be portable. The technically > inclined can consult the reference given in the comments. BTW, GPC users > familiar with the book(s) `Numerical Recipes' may be interested in knowing > that the `ran04 routine in the latest (2nd) edition (C only; not Pascal) > corresponds to the algorithm below. Thanks for the code! If it's not copyrighted/patented, we can perhaps use it for a built-it Random function in GPC. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Frank Heckenbach 28 Oct '97

28 Oct '97

Kevin A. Foss wrote: > On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: > > >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > >which implements a `random' and a `randomize' function just this > >way. You can extract it from the GPC mailing list archives (see > >http://home.pages.de/~GNU-Pascal/support.html) or download it from > >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. > > IMHO, this code is still broken. True, to some extent. See my previous mail. > On a non-DOS platform it tries to > pass an integer to a function expecting a cardinal and always returns a > type check error and doesn't compile. Assigning an integer to a cardinal is *NOT* a type check error, since the different integer types are assignment compatible. It could cause a range check error -- as soon as range checking will be implemented in GPC. The fact that GPC does report an "incompatible type" here (it didn't in earlier versions, otherwise I'd have noted when I wrote the unit), is indeed a bug in GPC. I'll add it to the bugs section of the To-Do list. Thanks for the (accidental ;-) bug report! Here is a short example program for this bug. This program should compile, but currently doesn't (it works, however, when I replace the functions v and w by variables): program x; procedure a(v:integer;w:cardinal); begin writeln(v,' ',w) end; function v:cardinal; begin v:=1 end; function w:integer; begin w:=2 end; begin a(v,w) end. > Is there some advanced switch > that should be used in situations like this to turn off type-checking > (I've never really looked at all of the directives and didn't see where > they were in the docs after a quick look) and the type-casting section > is empty. Turning off type checking in general would be a bit much, but type casting is indeed the right thing to do. Type casting works like - variable type casting: TypeName ( Variable or reference expression {"lvalue"} ) - value type casting (for ordinal and real type values): TypeName ( expression ) > SRand(GetPID); So change this line to: SRand(Cardinal(GetPID)); -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: String types in future GPC versions
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >According to Extended Pascal, strings are written with parentheses > >("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax > >("Str255 = String [ 255 ]"). In the future we *might* change this such > >that GPC produces an Extended Pascal string (unlimited length, 8 bytes > >overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, > >1 byte overhead) with "[...]". > > > > Wouldn't that feature (choosing between two memory allocation/outline schemes > for strings) create a lot of problems Yes. > for relatively little benefit? I don't think so. > First, if I have a procedure with a var string type, > > procedure foo (var s : string) > > can I pass variables of either string type (Borland or Extended)? No. But we're discussing something like "AnyString" parameters for which you will be able to pass any string type. First of all, there are already now three different string types in GPC, namely the (EP) string schema, the (SP/BP) arrays of char and the "CStrings" (necessary for interfacing with C functions, esp. system functions). These string types are already handled in some places (e.g. the Read/Write functions), and will have to be handled in other places, too. So what we're talking about here is actually the introduction of a fourth string type... Since the distinction between the string types is a lot of work, and often a bit chaotic, we're looking for ways to simplify things. I hope, the AnyString parameters will be such a way. If things go as I hope, the distinction will only have to be done at a few places in the compiler rather than in each procedure operating on strings. When we aachive this for the three existing string types, adding a fourth one should not be so much work. So, we're not overly keen on doing this work, but it seems inevitable. > Second, a string variable in Borland Pascal does not contain information > about the maximum length (like the capacity field in GPC), so for procedures > that need this information (like Readln), the string capacity would have to > be passed as an implicit parameter (or am I missing something?). You're right. But it's the same for arrays of char and CStrings, where the capacity is passed separately already now. In the future, the AnyString parameters should cater for this. > Finally, and most importantly, why is feature this needed in the first place? > The Extended Pascal string concept is more powerful that the Borland one (as > it stores the string capacity in a field which my procedure `foo' can > access). However, the extra features of GPC (capacity field, and strings > larger than 255 bytes) are *extensions* compated to Borland Pascal, so any > Borland code with string manipulations should compile under GPC, and the > binary (program) should produce the same results. Not any code, unfortunately. It's not uncommon in BP to manipulate the string length by accessing "s[0]", lacking a proper way to access the length. (GPC will soon provide a better way in the form of "AssignLength", working on all string types...) (You might say that directly accessing the length should not be done in a good program, but it's necessary for efficiency, e.g. in order to append one character to a string. The proper way "s := s + ch" will produce code that copies the whole string around at least twice, in BP as well as (currently) in GPC.) Another example would be dynamically allocating strings of varying length in BP which is usually done (again, lacking a better way) with statements like: New(p,Length(s)+1); p^:=s; To make such statements work under GPC, it's important to have the exact string type as BP does. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Frank Heckenbach 28 Oct '97

28 Oct '97

Peter Gerwinski wrote: > According to Thomas Tan: > > Are you guys going to implement us_Timer field of TimeStamps soon? > > If you tell us how to do that in a portable way - at once! ;-) > > > I need a seed for a random function and this seems to be the best way to go. > > On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > which implements a `random' and a `randomize' function just this > way. Sorry, but this is probably not the best thing to look at. First of all, it's not portable (it uses the system time under DJGPP, the process ID on other systems where available, and doesn't appear to work under EMX). Then, the unit (and especially the random algorithms and data sizes) are particularly for compatibility with BP's random generator, nothing else. So, a portable way to get fractions of a second would be a fine thing (micro seconds will not always be possible; under Dos, e.g., the resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Jesper Lund 28 Oct '97

28 Oct '97

> >So, a portable way to get fractions of a second would be a fine thing >(micro seconds will not always be possible; under Dos, e.g., the >resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... > If we forget about portability for a minute, under DOS (DJGPP) there is a libc function, uclock (), which provides (very) high-resolution timing. Jesper Lund

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Kevin A. Foss 28 Oct '97

28 Oct '97

On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list >which implements a `random' and a `randomize' function just this >way. You can extract it from the GPC mailing list archives (see >http://home.pages.de/~GNU-Pascal/support.html) or download it from >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. IMHO, this code is still broken. On a non-DOS platform it tries to pass an integer to a function expecting a cardinal and always returns a type check error and doesn't compile. Is there some advanced switch that should be used in situations like this to turn off type-checking (I've never really looked at all of the directives and didn't see where they were in the docs after a quick look) and the type-casting section is empty. The code in question: FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

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