Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

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

29 Oct '97

Jesper Lund wrote: > > > >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. Fine, I didn't know this. It would be fine if someone could extend the time data types and functions to make use of it and the functions that are available on other systems. Perhaps fields for 1/100 seconds and microseconds, along with flags that say if these values are good, so that the data types can be portable though the time functions will differ. Then a built-it Randomize could use the time stamps. For my compatibility random unit, I won't use it, but rather use a Dos call, exactly like BP. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

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

29 Oct '97

Jesper Lund wrote: > MY MISTAKE! Read[ln] work correctly and never exceeds the string capacity, > and my problems are totally UNrelated to the missing range checks in some > string expressions that I mentioned in the original post. I'm calmed! :-) > ADVICE TO GPC USERS: > > If you add #0 to a string (in order to call functions in the C library), it > is a *very* good idea to use strings whose capacity (max length) are not > divisible by 4. In that case, at least one byte is "wasted" to achieve > 4-byte alignment, and adding #0 should not overwrite other variables. I'm not sure if it's a good idea to rely on such internal things. The alignment could be different from 4 on some systems. However, we have already discussed automatically making the array bigger than the capacity by 1 for exactly this reason. I hope it's not much work, Peter, so perhaps you can do this change until the next version (whereas the automatic String-CString conversions will follow later). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Portable random numbers
by Frank Heckenbach 29 Oct '97

29 Oct '97

Peter Gerwinski wrote: > If the quality of these random numbers can compete with those produced by > the GNU or BSD C library, and if there are no problems with copyright, I > would be happy to incorporate this code into GPC's run time library and to > implement BP's `Randomize' and `Random' for GPC on top of that (perhaps > with Frank's unit as a replacement for those who specify `--borland-pascal' > for 100% compatibility;-). I'd prefer not to build in my random functions, but rather leave them in a separate unit, perhaps system whose main use will be for 100% BP compatibility, anyway -- when GPC has built-in all the other stuff. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 29 Oct '97

29 Oct '97

The African Chief wrote: > I had a problem with it in TESTMEM.PAS in the new bpcompat. > However, I have since discovered that the problem lies in mixing > the use of "ExitProc", and "AddExitProc" in the same program. Use > one or the other, and the problem disappears. Use both == > infinite loop. I see. AddExitProc is the C function atexit which I don't know much about. However, I like the simple way of adding an exit proc (rather than messing with pointer as in BP's ExitProc), so I wrote a replacement for AddExitProc in pure Pascal which is quite possible. It's included below, it can be used as a separate unit or merged into the existing units. A demo programs follows. BTW: Rather than an EP procedural parameter (as in sysutils.pas) I use a BP procedural type. One difference is that for a procedural parameter, a local procedure could be passed, which is unwanted here (since a local procedure would rely on its outer procedures to be active which is not the case during the finalization). unit aep; interface type TProc = procedure; procedure AddExitProc (Proc: TProc); implementation type PProcList = ^TProcList; TProcList = record Next: PProcList; Proc: TProc end; var ProcList: PProcList = nil; procedure AddExitProc (Proc: TProc); var Temp: PProcList; begin Temp := ProcList; New (ProcList); ProcList^.Next := Temp; ProcList^.Proc := Proc end; to end do while ProcList<>nil do begin {$W-}var Temp: PProcList;{$W+} Temp := ProcList; ProcList := ProcList^.Next; Temp^.Proc; Dispose (Temp) end; end. program x; uses aep; procedure world; begin writeln('world!') end; procedure hello; begin write('Hello ') end; begin AddExitProc(world); AddExitProc(hello) end. > > > > Assign is built-in now, so you can remove it from system.pas. > > Actually, the CygWin32 version still does not have it Strange. Actually, the built-in Assign in the RTS (rts/rts-assign.p) is written in Pascal in just the same way as in system.pas, so I think it should compile on any platform. Is this just an omission, or are there any hidden problems? Or is the CygWin version an older binary distribution? Peter, Jan-Jaap? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

gpc on Windows NT
by Jim Brander 29 Oct '97

29 Oct '97

The executable gpc1.exe included in the Cygwin32 release 18 falls over with an exception without doing anything. Its date is 19/12/96, whereas the gcc compiler in the same release is dated 15/4/97. The source to allow recompiling and debugging gpc for NT is not included in the Cygwin cdk source. You do not provide binary for Intel-Windows NT at your ftp site. There is a file explaining the problems back at Build 14 and suggesting the Cygwin sources for gcc will not be usable for compiling gpc. Can you direct me to the appropriate source, or suggest location of executables compatible with Build 18. Sorry to bother you. Thanks Jim Brander

1 0

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 28 Oct '97

28 Oct '97

Bill Currie wrote: > On 27 Oct 97 at 8:50, Frank Heckenbach wrote: > > > I think I can do the RTS part, if you send me a patch for your > > changes, along with a short description about how you did it. > > I'll have to sort though my mods to bring them up to date with the > latest beta. Fine! Don't hurry, I've got some other programming to do currently... > > - 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. I might modify this procedure a bit to use the (current) standard way of handling runtime errors (_p_generic and such), but this shouldn't be a problem. However, if you could move the check into the program, this would gain some efficiency. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

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

Jump to page:

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 October 1997