Gpc

gpc@gnu.de

5400 discussions

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

29 Oct '97

Bill Currie wrote: > > 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. > > Shouldn't be too difficult. I'll just have to figure out which > expression tree's I need (a call is easier to build, that's all). Yes, I guess so... BTW: When I've done all the RTS work, I'll send you a list of all the RTS functions that need checking. Or did you already figure them all out? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Portable random numbers
by Jesper Lund 29 Oct '97

29 Oct '97

Jesper Lund wrote: > >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. I found the code for the BSD random number function (it was in another subdirectory of /djgpp/src/ than the ANSI `rand' function). Jesper Lund

1 0

Sizeof LongInt
by Jesper Lund 29 Oct '97

29 Oct '97

Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? 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. Regards, Jesper Lund

1 0

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

29 Oct '97

According to Jesper Lund: > > >PROCEDURE Randomize; > >BEGIN > > SRand(GetPID); > > RandSeed:=Rand > >END; > > I don't see how this should emulate the Randomize procedure in Borland > Pascal. 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. Why not compute a seed > from the system time (somehow), as Borland Pascal does? If the sysetm time is always available, I agree. OTOH, `Randomize' should never be used twice in the same program! I know someone who tried to get "even more random" numbers by calling `Randomize' before each sequence of calls to `Random', but the calculations in between were so fast that the time did not change between two `Randomize's. As a result, the random numbers were the same in all sequences - with Borland Pascal. > 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 .... > > 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. [...] For scientific application I agree. For games and such, that little bit of "true random" is a must. > 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). 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;-). 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]

2 1

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

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