- Gpc - gnu.de

Re: Looking for some random-functions ... and maybe a bug report
by Orlando Llanes 23 Sep '97

23 Sep '97

>If all you need is system time, why do you go through all of the >... >misunderstand what exactly you need for a 'system time.' Why not just write a wrapper to the C functions? There's a standard time function isn't there? The Sources to Persistence Of Vision Raytracer have a Random function that works the same across all platforms. See ya! Orlando Llanes

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Kevin A. Foss 23 Sep '97

23 Sep '97

On Tue, 23 Sep 1997 15:21:11 +0200, Frank Heckenbach wrote: >But still I don't know how to get the system time in OS/2 or non-DPMI DOS >(I was using the DPMI call only to call a DOS int, since I'm not sure if >calling int 21 directly is OK) If all you need is system time, why do you go through all of the DPMI/int calls/&c, instead of just using extended Pascal's timestamp routines. Or are these not available because you are turning non-Borland features off when compiling these Borland-ish Units? Using gettimestamp() should work on all gpc platforms, right? I guess I must misunderstand what exactly you need for a 'system time.' -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Peter Gerwinski 23 Sep '97

23 Sep '97

According to Kevin A. Foss: > > If all you need is system time, why do you go through all of the > DPMI/int calls/&c, instead of just using extended Pascal's timestamp > routines. These only have a resolution of one second which probably is not "random" enough for this purpose. The 1/100s when a program was started is almost a true random number; if we use the second in the minute it might be too regular. > Or are these not available because you are turning > non-Borland features off when compiling these Borland-ish Units? No. > Using > gettimestamp() should work on all gpc platforms, right? Right. If you find a platform where it doesn't, it's a bug. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

EMX (was: Looking for some random-functions ... and maybe a bug report)
by Peter Gerwinski 23 Sep '97

23 Sep '97

According to Frank Heckenbach: > > According to myself (Peter Gerwinski): > > > You can get this information at run-time - and *only* at run-time since > > one and the same executable can run both on DOS (with and without DPMI) > > and on OS/2. If the variable `__osmode' contains a nonzero value, it > > is OS/2; if it is DOS and the variable `__emx_env' and $0180 is nonzero, > > it is DPMI (RSX). > > But still I don't know how to get the system time in OS/2 or non-DPMI DOS > [...] This was implied: If `__osmode' is zero and `__emx_env' and $0180 is zero as well, then it is DOS without DPMI. Once again the three EMX modes as a tabular: __osmode __emx_env and $0180 system nonzero doesn't matter OS/2 0 nonzero DOS with DPMI 0 0 DOS without DPMI (-; Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Frank Heckenbach 23 Sep '97

23 Sep '97

Peter Gerwinski wrote: > According to Frank Heckenbach: > > > > Kevin A. Foss wrote: > > > > > Unfortunately, I know of no easy way to test for what operating system > > > EMX is currently using. > > > > Neither do I, that's the problem... > > You can get this information at run-time - and *only* at run-time since > one and the same executable can run both on DOS (with and without DPMI) > and on OS/2. If the variable `__osmode' contains a nonzero value, it > is OS/2; if it is DOS and the variable `__emx_env' and $0180 is nonzero, > it is DPMI (RSX). Thanks for the info! But still I don't know how to get the system time in OS/2 or non-DPMI DOS (I was using the DPMI call only to call a DOS int, since I'm not sure if calling int 21 directly is OK) -- or some other way to init random; AFAICS, the system unit v1.00 doesn't do any random initialization at all... Besides, I couldn't test it with EMX, anyway. So I won't change it now. If someone who has EMX can change it, please do so and post the result here. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Frank Heckenbach 23 Sep '97

23 Sep '97

Christian Bockermann wrote: > Hello ! > > After I inserted the random-functions, which I got through this list, I > wanted to use the Rand-Unit by Frank Heckenbach. But I get some error- > messages when compiling this unit : > > [...] > > What exactly does this 'Cardinal'-expression mean ? Cardinal is an unsigned integer. It was introduced after 2.0, sometime around June, IIRC. With 2.0, you might be able to use "__unsigned__" or such a beast, but OTOH the random unit relies on the exact sizes (16, 32 and 64 bits) of some types, and AFAIR there was no way to specify those in 2.0 (you could use long, short and such, but that woudln't be portable). Su I suggest you to upgrade to a newer version (maybe wait for the next beta, or even for 2.1 which hopefully won't take too long now to complete). Sorry that you can't use it now, but these are temporary problems... Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Frank Heckenbach 23 Sep '97

23 Sep '97

Kevin A. Foss wrote: > >{$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} > >{$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} > > IMHO, this isn't a good way to do things in a portable unit. Remember > that the EMX version of GCC also works under OS/2. Trying to DOS-ish > things won't go over well if you only check for __EMX__. I assumed such interrupts would be eumlated, but if not... > Unfortunately, I know of no easy way to test for what operating system > EMX is currently using. Neither do I, that's the problem... > >{$W-} > >FUNCTION __DPMI_Simulate_Real_Mode_Interrupt(Vector:Integer;VAR Regs:TDPMIRegs):Integer; C; > >{$W+} > > Does this even work with the DOS version of EMX? Don't know. I've only got Linux and DJGPP. > It looks like some > type of DPMI call but EMX doesn't DPMI without the RSX extender. Oh! I didn't know that. Well anyway, it's not a serious thing at all. This last section of the units only deals with how the random number seed is initialized. If it doesn't work on any system, one can simply do it another way. (My way of doing it exactly the same way as BP under Dos was just a kind of fun, anyway; I don't think anyone would ever care.) If OS/2 has something like GetPID, one can use this or other "pseudo-random" data (such as the system time, received by other means than a Dos interrupt, but I don't know how). > [C:\kevin\pascal]gpc -c rand.pas > gpc: Internal compiler error: program gpc1 got fatal signal 11 > (I also get an OS/2 popup with a generic 3171 error -- this "program... > can not continue.") > > I take it the compiler should reply with some error and not a fatal > signal? Or this one of the things that has been fixed in the later > betas? Probably. I got such errors a lot with betas from Jul/Aug when compiling units. The latest developer version (to be published soon) doesn't seem to cause such problems any more. Oh yes, and there was a bug that caused a serious crash of the DJGPP GPC with the type declarations in the random unit. Perhaps that was in the version you're using, I don't remember exactly. Again, this is fixed in the current GPC. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

GPC on Solaris
by croy＠osiris.com 22 Sep '97

22 Sep '97

Hello, Boy it has been a long time for me waiting to have a Pascal Compiler on Unix.... C is OK but Pascal just feels better, Thanks to all the people involved Ok That is as much brown nosing I will ever do on this list, promissed... I have build Successfully but with some difficulties GPC-970714 on both Solaris x86 2.5.1 and Solaris Sparc 2.5.0 ... Should I give you access to the build to put it in the binaries distributions or should I wait for a more official 2.1 release.... Again Thanks and if I can be of help I have here quite a few different version of Unix in the Lab.... Good Test bed for the protability... Ciao ______________________________________________________________________________ Claude Roy Osiris Inc. The Network Architects Email : croy(a)osiris.com Http://www.osiris.com/

1 0

Re: Upgrading GPC (was: Looking for some random-functions ...)
by Peter Gerwinski 22 Sep '97

22 Sep '97

According to Orlando Llanes: > I downloaded the same gpc-970714.zip file from the gnu-pascal FTP site, > I even downloaded the gpc-970714.tar.gz, and I look all over through them, > but 0 executables turned up. I thoroughly searched the entire gnu-pascal > directory looking through every directory and subdirectory in it, nothing. > This is getting really frustrating... ????? What about ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ gpc-970714.i386-djgppv201.zip? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Upgrading GPC (was: Looking for some random-functions ...)
by Orlando Llanes 22 Sep '97

22 Sep '97

>What's that - 2.01b? The last official beta version that came with >binaries was gpc-970714; after that there were some (inofficial) I downloaded the same gpc-970714.zip file from the gnu-pascal FTP site, I even downloaded the gpc-970714.tar.gz, and I look all over through them, but 0 executables turned up. I thoroughly searched the entire gnu-pascal directory looking through every directory and subdirectory in it, nothing. This is getting really frustrating... See ya! Orlando Llanes

1 0

Re: GPC assembler
by Peter Gerwinski 22 Sep '97

22 Sep '97

According to cagliostro: > > I want to set the result of the function, directly from the asm > part.Is it possible ? Yes: You can define a return value variable for the function: Function foo ( x, y: Integer ) = bar: Integer begin (* foo *) asm ( ' <do something> ' : '=rm' ( bar ) : (* input *) : (* clobbered *) ); end (* foo *); Even if you don't define one, you can use `Result' for this purpose: Function foo ( x, y: Integer ): Integer begin (* foo *) asm ( ' <do something> ' : '=rm' ( Result ) : (* input *) : (* clobbered *) ); end (* foo *); 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Help running GPC on Linux 2.0.30.
by Peter Gerwinski 22 Sep '97

22 Sep '97

According to AuX: > > I keep receiving an error when trying to compile a program I just > finished. I run: 'gpc new.pas -o new' and receive 'cannot open -lgpc.' You obviously have an installation problem: The `gpc' compiler driver program cannot locate the libraries `crt0.o' and `libgpc.a'. (This is the common source of both problems you posted to this list.) It seems as if you have installed an "a.out" compiler on your ELF system. Please check whether the following directories (or something similar) exist and contain the files they should: `libgpc.a' should be in /usr/lib/gcc-lib/i486-linuxaout/2.7.2.1/ `crt0.o' should be in /usr/i486-linuxaout/lib/crt0.o Alternatively, both files may be in directories which are in your library path. If you don't have them, get them from your GPC and GCC distribution. sqr (Alternatively) (if my guess is right), you can install an ELF version of GPC, available on ftp://kampi.hut.fi/jtv/gnu-pascal/binary/ or on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/binary/. Alternatively pow 3, you can get the source of GPC (drop `binary' from the URLs above) and recompile. On a Linux system this is no real problem if you have the source of gcc-2.7.2.1 (no other version; 7MB compressed) and follow the instructions in the file `INSTALL'. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Peter Gerwinski 22 Sep '97

22 Sep '97

According to Frank Heckenbach: > > Kevin A. Foss wrote: > > > Unfortunately, I know of no easy way to test for what operating system > > EMX is currently using. > > Neither do I, that's the problem... You can get this information at run-time - and *only* at run-time since one and the same executable can run both on DOS (with and without DPMI) and on OS/2. If the variable `__osmode' contains a nonzero value, it is OS/2; if it is DOS and the variable `__emx_env' and $0180 is nonzero, it is DPMI (RSX). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

unsubscribe
by e1097963＠ceng.metu.edu.tr 22 Sep '97

22 Sep '97

help

1 0

String comparisons
by Frank Heckenbach 21 Sep '97

21 Sep '97

I just noticed that GPC ignores trailing spaces when comparing strings with the usual operators ("=" and so on). I see that this seems to be required by the standard, and that there are othere operators ("eq" or such) for exact comparisions. However, I find this behaviour quite inconsistent and annoying (took me quite some time to figure out why s='' was true when s wasn't empty...)-:, and it would cause much trouble when porting BP programs. When using "--borland-pascal", GPC says "warning: ISO 7185 Pascal does not define string functions". So, would it be possible to make "=" and so on work as exact comparisons (at least in the "--borland-pascal" mode, and preferably also with a separate switch)? Simple test program: ;-) program x; begin writeln(''=' ') end. Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Looking for some random-functions ... and maybe a bug report
by Kevin A. Foss 21 Sep '97

21 Sep '97

On Sun, 21 Sep 1997 17:50:53 +0200, Frank Heckenbach wrote: >File Rand.Pas: [...] > IMPORTANT NOTES: > > - This unit is only intended for BP compatibility. While it should be > portable (if not, please report) Okay... >{$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} >{$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} IMHO, this isn't a good way to do things in a portable unit. Remember that the EMX version of GCC also works under OS/2. Trying to DOS-ish things won't go over well if you only check for __EMX__. Unfortunately, I know of no easy way to test for what operating system EMX is currently using. >{$W-} >FUNCTION __DPMI_Simulate_Real_Mode_Interrupt(Vector:Integer;VAR Regs:TDPMIRegs):Integer; C; >{$W+} Does this even work with the DOS version of EMX? It looks like some type of DPMI call but EMX doesn't DPMI without the RSX extender. Possible bug report: For the heck of it I tried compiling this Unit in OS/2 [gpc 970714]and got: [C:\kevin\pascal]gpc -c rand.pas gpc: Internal compiler error: program gpc1 got fatal signal 11 (I also get an OS/2 popup with a generic 3171 error -- this "program... can not continue.") I take it the compiler should reply with some error and not a fatal signal? Or this one of the things that has been fixed in the later betas? I get the error whether or not the $IFDEF __EMX__ line is in the code. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Help running GPC on Linux 2.0.30.
by AuX 21 Sep '97

21 Sep '97

I keep receiving an error when trying to compile a program I just finished. I run: 'gpc new.pas -o new' and receive 'cannot open -lgpc.' What do I need to do to fix this?

1 0

GPC assembler
by cagliostro 21 Sep '97

21 Sep '97

hello everybody ! I want to use the inline assembler of GPC in a function, such as function fct:integer; begin asm(" mov $10,%%eax {just an example } : : :"eax"); end; ( I learned that in the excellent GPCASM of Dario "-PrEdAtOrZ-" Anzani ) I want to set the result of the function, directly from the asm part.Is it possible ? Is there something like the @result of turbo pascal in GPC ? If no ,what is the adress of the result ? ( %esp+x, %ebp+x ?).BTW, I use GPC for DOS I hope you can help me ! Anyway, thanks for your great job BYE Patrice BOUCHAND

1 0

Re: Looking for some random-functions ...
by Frank Heckenbach 21 Sep '97

21 Sep '97

Achim Kalwa wrote: > You can use the following external function declaration: > > FUNCTION Rand : Integer; C; > > and do the following example: > > FOR i := 1 TO 10 DO WriteLn(Rand); > > Alternatively, there is a random number generator unit called "Rand" written by > Frank Heckenbach (heckenb(a)mi.uni-erlangen.de). > > To Frank: Would you post your unit again, please? Im interested, too. The unit follows below. I did some minor changes since last time. But please note: - The changes might rely on some bug fixes in GPC that were done after the last beta release, so the unit might not work with the currently available version. But that'll not be a big problem, since the next beta will be available real soon now, and the unit should work with it then... :-) - See the notes at the beginning of the unit. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm File Rand.Pas: { Random unit for GPC for BP compatibility This package is released as part of the GNU Pascal project. IMPORTANT NOTES: - This unit is only intended for BP compatibility. While it should be portable (if not, please report), it's *not* meant to be GPC's default random generator. Especially, the range for integer randoms is only 16 bits, as in BP. OTOH, it provides the RandSeed variable, and if it's set to the same value, it produces the exact same sequence of random numbers as BP's random generator does (whoever might need this... ;-) If you don't care for such kind of compatibility, you might prefer to use the Rand/SRand C functions. (BTW: This unit uses them to initialize RandSeed on non-Dos systems, you can take that as an example on how to use them.) - Since function overloading doesn't work yet, you have to use "RandReal" instead of "Random" for real numbers. This library is a free library; you can redistribute and/or modify it under the terms of the GNU Library General Public License, version 2, as published by the Free Software Foundation. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library (see the file COPYING.LIB); if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. v1.0, September 1997, Frank Heckenbach, heckenb(a)mi.uni-erlangen.de } UNIT Rand; INTERFACE TYPE Card8 =Cardinal(8); Card16=Cardinal(16); Card32=Cardinal(32); Card64=Cardinal(64); Int32 =Integer(32); VAR RandSeed:Int32 VALUE 0; FUNCTION Random(Range:Card16):Card16; FUNCTION RandReal:Real; PROCEDURE Randomize; IMPLEMENTATION {### LOCAL $R-}{$W-,R-,W+} PROCEDURE NextRand; BEGIN RandSeed:=$8088405*RandSeed+1 END; {### END LOCAL $R} FUNCTION Random(Range:Card16):Card16; BEGIN NextRand; Random:=(Card64(RandSeed)*Range) DIV $100000000 END; FUNCTION RandReal:Real; BEGIN NextRand; RandReal:=RandSeed/$100000000+0.5 END; {$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} {$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} {$IFDEF DOS} TYPE PDPMIRegs=^TDPMIRegs; TDPMIRegs=RECORD CASE (d,x,h) OF d:(edi,esi,ebp,res,ebx,edx,ecx,eax:Card32); x:(di,di_hi,si,si_hi,bp,bp_hi,res_lo,res_hi,bx,bx_hi,dx,dx_hi, cx,cx_hi,ax,ax_hi,flags,es,ds,fs,gs,ip,cs,sp,ss:Card16); h:(edi_b,esi_b,ebp_b,res_b:ARRAY[0..3] OF Card8; bl,bh,ebx_b2,ebx_b3, dl,dh,edx_b2,edx_b3, cl,ch,ecx_b2,ecx_b3, al,ah,eax_b2,eax_b3:Card8) END; {$W-} FUNCTION __DPMI_Simulate_Real_Mode_Interrupt(Vector:Integer;VAR Regs:TDPMIRegs):Integer; C; {$W+} PROCEDURE Randomize; TYPE Card32LoHi=RECORD Lo,Hi:Card16 END; VAR DPMIRegs:TDPMIRegs; BEGIN DPMIRegs.ah:=$2C; {$X+} __DPMI_Simulate_Real_Mode_Interrupt($21,DPMIRegs); {$X-} WITH Card32LoHi(RandSeed) DO BEGIN Lo:=DPMIRegs.cx; Hi:=DPMIRegs.dx END END; {$ELSE} FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; {$ENDIF} END.

1 0

Re: Upgrading GPC (was: Looking for some random-functions ...)
by Orlando Llanes 21 Sep '97

21 Sep '97

>What's that - 2.01b? The last official beta version that came with >binaries was gpc-970714; after that there were some (inofficial) >patches. Doh! I goofed, I was trying to compile the sources *after* 970714, the diff file named: gpc-970714-970809.diff or soemthing like that. See ya! Orlando Llanes

1 0

Re: Upgrading GPC (was: Looking for some random-functions ...)
by Orlando Llanes 21 Sep '97

21 Sep '97

>You mean: DJGPP binaries? Linux runs on the PC, too. Compiling the PC binaries as in compiling the source to GPC for the DOS port. >What's that - 2.01b? The last official beta version that came with >binaries was gpc-970714; after that there were some (inofficial) >patches. For me, the latest executable binaries are 2.01b, the latest sources are gpc-970714. Meaning that I can't compile the sources under DOS. I have GPC in the same directory as DJGPP. I'm beyond the patch and diff stuff, I figured that out, the problem I'm having is that some filenames get mangled. Does DJGPP's DJTAR support Win '95 LFN? I tried WinZip, which is supposed to be able to restore long filenames, but there was one particular file (for example) gcc-2.7.2.1, something like that, which didn't extract to that file name. I've even resorted to manually renaming the files, but that didn't work either. Unfortunately I may have to resort to installing Linux in order to compile the sources. I promise you this is a legit problem I'm having. >It *is* easier to get a patched source tree from Linux than it is >... >from the `p' directory. After that, compilation should work. Ok, I'll try it out as a last resort because I'll have to download Linux and the DJGPP binaries. I just want to make sure I've exhausted my PC options first. See ya! Orlando Llanes

1 0

Re: Looking for some random-functions ...
by Orlando Llanes 21 Sep '97

21 Sep '97

>What's that, POV, and where can we get it? >What are the licensing conditions? Wow, I thought it didn't need introduction :P It's a cross-platform renderer (previewing the rendering only on MS-DOS, Windows, and Mac I think). As for licensing, I think it's distributed under the GNU License, but then again it might be freeware, I don't remember :( Where to find it? Check: http://www.povray.org See ya! Orlando Llanes

1 0

Upgrading GPC (was: Looking for some random-functions ...)
by Peter Gerwinski 21 Sep '97

21 Sep '97

According to Orlando Llanes: > > BTW, if I installed Linux, would it be easier to compile the PC > binaries? You mean: DJGPP binaries? Linux runs on the PC, too. > I'm going crazy trying to get updated, but I'm still with 2.01b :( What's that - 2.01b? The last official beta version that came with binaries was gpc-970714; after that there were some (inofficial) patches. It *is* easier to get a patched source tree from Linux than it is from DOS: Just start the Linux compilation process (or actually compile if you want to do that anyway), then move the source tree to your DJGPP partition, boot DOS, and run `config\msdos\configur.bat' from the `p' directory. After that, compilation should work. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Looking for some random-functions ...
by Peter Gerwinski 21 Sep '97

21 Sep '97

According to Orlando Llanes: > > POV has a protable random function in case you're interested. since they > were getting different results on diff platforms, they developed a random > function that would work as expected on all platforms it supports. What's that, POV, and where can we get it? What are the licensing conditions? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Inline keyword not recognized (+ work-around)
by Peter Gerwinski 21 Sep '97

21 Sep '97

According to Jesper Lund: > > Here is a minor problem (bug) in GPC: > > According to the GPC documentaion you can define a function/procedure to be > inlined with the "inline" keyword, [...] Thanks again for the report! :) I am just fixing it in a way that `Inline' remains a redefinable identifier. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Procedural parameters and types: bug report and work-around
by Peter Gerwinski 21 Sep '97

21 Sep '97

According to Jesper Lund: > > (Peter, thanks for the speedy response to my first bug report!) (No problem. Thanks, Jesper, for the reports and the very helpful example programs!) > Note that, contrary to the "incompatible pointers" problem that I reported a > few days ago, the program below does *not* compile (unless the work-around in > the example is used). Fixed now. :) > In the example below, there is one unit (u4) and the main program. The > example demonstrates all facets of the bug (type inconsistencies) that I have > discovered, and includes a simple bug work-around (I am assuming here that > the typecast needed to fix the problem is not a feature ...). Your assumption is right: Type-casting of a procedure or function is yet another bug in GPC - which is also fixed now. You can, however, cast the *address* of a function to the type you need - *that* is a feature: proc4 (ProcType (@pp)); (* Works *) proc3 (ProcType (@pp)); (* Should work, but doesn't; I'm on it ... *) (* okay, now it works, too. :*) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Running GPC on LINUX 2.0.30.
by AuX 21 Sep '97

21 Sep '97

When I attempt to compile a program i receive connot find crt1.o.. Where can I find these files??

1 0

Re: Looking for some random-functions
by chris＠bockermann.ping.de 20 Sep '97

20 Sep '97

Hello, all there ! I would like to thank all of you for the hints concerning the subject ! It works :-) Thanks a lot ! -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: Looking for some random-functions ...
by Peter Gerwinski 20 Sep '97

20 Sep '97

Hi! According to Christian Bockermann: > > I'm not sure, if this is the right place for my question, but I don't know > where else to look for help. So, if this is not the right way, please > appologize. This is absolutely the right place. Welcome to the GNU Pascal mailing list! :) > My actual problem is that I don't find any procedures of functions to get > randomized numbers. I tried "randomize" and "random(n)" as in Turbo Pascal, > but it didn't work. :-) > Is there any unit perhaps, which includes such functions in GPC ? Is there > perhaps something like the "CRT"-unit ? We are currently working on a built-in `random' function. For the moment, you can use one of the following: * On ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/, you can find a "BPcompat" package that contains a `System' Unit (with `random' etc.), a `CRT', and more. While it is written to work with DJGPP (DOS), it should not be too hard to port the relevant parts to Linux. I don't know whether somebody is already working on a Linux version of this. If you would like to do something in this direction, please let us know. * At the same location there is another package "BO5" which implements a portable `random' function and some replacement stuff for `CRT'. I am currently working on making it a complete user-interface library. * Here is `random': Function Rand: Integer; C; (* Use C's `rand' function. *) Procedure InitRandom ( Seed: Integer ); asmname 'srand'; (* Replacement for `RandSeed'. *) Function Random ( limit: Integer ): Integer; begin (* Random *) Random:= Rand mod limit; end (* Random *); You know how to get a real number 0 <= x < 1 out of `Rand'. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Inline keyword not recognized (+ work-around)
by Jesper Lund 19 Sep '97

19 Sep '97

Here is a minor problem (bug) in GPC: According to the GPC documentaion you can define a function/procedure to be inlined with the "inline" keyword, e.g. inline function Max (a, b : Integer); begin (* CODE *) end; This does not work in the 970714 distribution (DJGPP precompiled binary). However the __inline__ keyword (two underscores before and after inline) *is* recognized by the compiler, and correctly inlines the function/procedure (when compiled with optimization, of course). Jesper Lund

1 0

Looking for some random-functions ...
by chris＠bockermann.ping.de 19 Sep '97

19 Sep '97

Hello there ! I'm not sure, if this is the right place for my question, but I don't know where else to look for help. So, if this is not the right way, please appologize. I'm quite new to the use of GPC and started programming pascal with Borland's Turbo Pascal. After a system-change from Dos to Linux I'm now using GPC. My actual problem is that I don't find any procedures of functions to get randomized numbers. I tried "randomize" and "random(n)" as in Turbo Pascal, but it didn't work. :-) Is there any unit perhaps, which includes such functions in GPC ? Is there perhaps something like the "CRT"-unit ? Any help would be very nice and if this is the wrong place to ask for, please appologize. Thank you, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

2 1

Procedural parameters and types: bug report and work-around
by Jesper Lund 19 Sep '97

19 Sep '97

Dear GPC developers: In my recent post to the list about compiler warnings with "incompatible pointers" (when using user-defined types), I mentioned that I had a similar problem with procedural types/parameters. This statement is much, much too vague for a bug report, so here is an example that demonstrates the problem. (Peter, thanks for the speedy response to my first bug report!) Note that, contrary to the "incompatible pointers" problem that I reported a few days ago, the program below does *not* compile (unless the work-around in the example is used). In the example below, there is one unit (u4) and the main program. The example demonstrates all facets of the bug (type inconsistencies) that I have discovered, and includes a simple bug work-around (I am assuming here that the typecast needed to fix the problem is not a feature ...). ------------------------- u4. pas ---------------------------------- unit u4; { Note the start-up code } interface type procType = ^procedure (var x : Integer); procedure proc3 (procedure f (var x : Integer)); procedure proc4 (f : procType); implementation { Example with Procedural parameter (Standard Pascal) } procedure proc3 (procedure f (var x : Integer)); var y : Integer; begin f(y); Writeln (y); end; { proc3 } { Example with Procedural Types (Borland-like) } procedure proc4 (f : procType); var y : Integer; begin f(y); Writeln (y); end; { proc4 } procedure Test (var b : Integer); begin b := 2003; end; begin { Both of these call compile and work. Note that the procedure } { "Test" which is passed as argument is in the same unit. Hence, } { there is no need for a typecast (as in the main program). } proc3 (Test); { Procedural parameter example } proc4 (Test); { Procedural type example } end. --------------------------------- mainprg1.pas ---------------------- program Mainprg1; uses u4; procedure pp (var k : Integer); begin k := 120469; end; { pp } begin { Below the procedure passed as argument (pp) resides in another } { module than proc3/proc4. The code will only compile when there } { is a type cast. This applies both to procedural parameters } { (Standard Pascal) and types (Borland-like). } { These lines do not compile } proc3 (pp); { Line 18 } proc4 (pp); { Line 19 } { With the typecast everything works OK! Even in the standard } { Pascal version (proc3) which does not use the type "ProcType". } proc4 (ProcType (pp)); { Bug work-around for Borland-like example } proc3 (ProcType (pp)); { It also works for Standard Pascal example } end. ------------------------------------------------------------------------ I compile with gpc -o mainprg1.exe mainprg.pas --automake Compiler output: mainprg1.pas: In function `program_Mainprg1': mainprg1.pas:18: too few arguments to function `Pp' mainprg1.pas:18: invalid use of void expression mainprg1.pas:19: too few arguments to function `Pp' mainprg1.pas:19: invalid use of void expression (same error for procedural types and parameters). When line 18 and 19 is deleted, the program compiles correctly (because of the typecast bug work-around), and outputs (as intended) 2003 2003 120469 120469 The first two lines are from the start up code (procedural argument Test in unit u4), the third and fourth from "pp" in the main program. Finally (for the record), I use GPC version 970714 (beta), DJGPP precompiled binary. Sincerely, Jesper Lund

1 0

AW: Looking for some random-functions ...
by Achim Kalwa 18 Sep '97

18 Sep '97

Christian Bockermann wrote: > My actual problem is that I don't find any procedures of functions to get > randomized numbers. I tried "randomize" and "random(n)" as in Turbo Pascal, > but it didn't work. :-) > Is there any unit perhaps, which includes such functions in GPC ? Is there > perhaps something like the "CRT"-unit ? You can use the following external function declaration: FUNCTION Rand : Integer; C; and do the following example: FOR i := 1 TO 10 DO WriteLn(Rand); Alternatively, there is a random number generator unit called "Rand" written by Frank Heckenbach (heckenb(a)mi.uni-erlangen.de). To Frank: Would you post your unit again, please? Im interested, too. Achim

1 0

Re: Bug report (incompatible pointers)
by Peter Gerwinski 18 Sep '97

18 Sep '97

According to Jesper Lund: > [...] > This is my first mail to the list, so first of all: THANKS for a GREAT > pascal compiler! Thanks for the feedback! Getting e-mails like this is highly motivating. :-) > However, the current version (970714; DJGPP version) cannot compile > (correctly) some programs with user-defined types. [...] > > There is a similar (related) problem with procedural parameters (and types). > [...] I could reproduce both bugs and fix them in my current development snapshot. A new beta release is :(still): in preparation. Thanks for the report and for the helpful example programs. > mainprg.pas: In function `program_Mainprg': > mainprg.pas:14: warning: passing arg 1 of `Proc2' from incompatible pointer > type > > It is "only" a warning, and an .exe file is produces, but somestimes the > program crashes (not here, though). This is unrelated; the warning can be safely ignored. The bug causing the crash must be somewhere else in your program. Good luck with it! ;-) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Bug report (incompatible pointers)
by Jesper Lund 17 Sep '97

17 Sep '97

Dear GPC developers: This is my first mail to the list, so first of all: THANKS for a GREAT pascal compiler! However, the current version (970714; DJGPP version) cannot compile (correctly) some programs with user-defined types. The problem occurs in the following situation: - Unit "u1" defined a type (say, myType) - Another unit, "u2", has a procedure with a parameter of type myType - The main program calls the procedure in "u2" (after having defined a variables of type myType). I am sorry if this sounds cryptic (I tried to be precise), but there is an example below. Now, this example/setup works if myType is a pointer to a built-in type, or an array of built-in types (ex: pointer to an array of doubles), but it does NOT work if myType is more "complicated", e.g. a pointer to a record type [as in the example below]. There is a similar (related) problem with procedural parameters (and types). I have included a simple example (below) which demonstrates the bug, and I hope you are able to reproduce it. Note that the program consists of two units (u1, u2), as well as the main program. Command line invoking GPC: gpc -o mainprg.exe mainprg.pas --automake Compiler output: mainprg.pas: In function `program_Mainprg': mainprg.pas:14: warning: passing arg 1 of `Proc2' from incompatible pointer type It is "only" a warning, and an .exe file is produces, but somestimes the program crashes (not here, though). Sincerely, Jesper Lund jel(a)hha.dk P.S. If you respond to the list, please include a CC to me (I may not have been added the list yet). Thanks. ------------------------------------------------------- program Mainprg; uses u1, u2; var y : RecPtr; begin New (y); Proc2 (y); { This call results in an incompatible pointer call } end. { Note that proc2 is in u2, where as recPtr is } { defined in u1. } ----------------------------------------------------------------- unit u1; interface type rec = record a, b : Integer; end; recPtr = ^rec; procedure Proc1 (x : recPtr); implementation procedure Proc1 (x : recPtr); begin { Do nothing } end; begin end. { u1 } ------------------------------------------------------------ unit u2; interface uses u1; procedure Proc2 (x : recPtr); implementation procedure Proc2 (x : recPtr); begin Proc1 (x); { This call is OK -- no compiler errors! } end; begin end. { u2 } ----------------------------------------------------------------

1 0

Re: Problems with the gcc patch
by Peter Gerwinski 15 Sep '97

15 Sep '97

According to Robert Ketzscher: > > I am now trying to install the beta-version gpc-970714 > I seem to fall at the very first hurdle: > After I downloaded and extracted both gpc and gcc (2.7.2.1) > I did as I was told in the README of gpc above. > I get the message: > I can't seem to find a patch in there anywhere. > when entering the patch command. What exactly did you type? The following is known to work on Linux and DEC-OSF: cd /where/ever/it/is/gcc-2.7.2.1 # This must contain a `p' subdirectory patch -p1 < p/patches/gcc-2.7.2.1.patch # The following commands may have more options ./configure make LANGUAGES=pascal Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 2

Problems with the gcc patch
by Robert Ketzscher 15 Sep '97

15 Sep '97

Hi, I am now trying to install the beta-version gpc-970714 I seem to fall at the very first hurdle: After I downloaded and extracted both gpc and gcc (2.7.2.1) I did as I was told in the README of gpc above. I get the message: I can't seem to find a patch in there anywhere. when entering the patch command. Any ideas? Thanks in advance Rob

1 0

Re: Overflow in implicit constant conversion
by Peter Gerwinski 14 Sep '97

14 Sep '97

According to Robert Ketzscher: > > first of all I hope this is the right address to pose my > problem. It is. Welcome to the GNU Pascal mailing list! > I get the message > Overflow in implicit constant conversion > at the end of the interface part (i.e. where implementation starts). > I only use a handful constants and even after I commented them out > I got the same message. I wrote a small unit typedefs as follows: > > unit typedefs; > > interface > > type longint = __long__ Integer; > byte = __byte__ Integer; > extended = __long__ Real; > word = __short__ Integer; > longstring = String[255]; > shortint = __byte__ Integer; > > implementation > > begin > end. Is this the unit which causes problems? It compiles well with all versions of GPC I have at hand. Which version do you use? If not, I only can guess that your problems come from initialized `Byte' variables (typed constants) initialized with values above 127 because you define `Byte' as a signed type. To get an unsigned `Byte', use Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; If you have more problems and you are using gpc-2.0 or earlier, you should upgrade to a more recent beta version of GPC, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pasal/beta/. The latest official beta release is gpc-970714; the next one is in preparation. This new GPC has the following types - and more - built in: Type LongInt = __long__ Integer; (* 64 bits *) ShortInt = __short__ Integer; (* 16 bits; `Integer' has 32 *) ByteInt = __byte__ Integer; (* 8 bits *) LongWord = __unsigned__ LongInt; (* 64 bits, unsigned *) Word = __unsigned__ Integer; (* 32 bits, unsigned *) ShortWord = __unsigned__ ShortInt; (* 16 bits, unsigned *) Byte = __unsigned__ ByteInt; (* 8 bits, unsigned *) Extended = __long__ Real; (* 80 bits *) 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: demo for using of qsort from lib and a little problem with it
by Frank Heckenbach 14 Sep '97

14 Sep '97

Peter Gerwinski wrote: > > function CompNum(var e1, e2: TestType):Integer; > > Var > > r : Real; > > begin > > r := e1 - e2; > > CompNum := Round(r); > > end; > > Consider this with "TestType = Byte", then in `CompNum' we are subtracting > two `Byte' variables from each other. GPC chooses the result type to be > `Byte' again, so the result is never negative. > > When I convert them to `Integer' by writing > > r:= Integer ( e1 ) - Integer ( e2 ); > > it works. (First it did not work because of a bug in conversions among > integer types, but I could fix this.;-) > > However, is this the correct behaviour? I think it is because... > Or should the result type of a > subtraction be the "nearest" signed integer type - `ShortInt' in this > example? Then, what to do when subtracting two `LongestCard's, especially > in cases like "$FFFFFFFFFFFFFFFF - 2" where the result does not fit in > `LongestInt'? That's the problem. Also, this problem is basically the same as a multiplication of two Integers resulting in a LongInt. GPC (and BP) do not do any automatic conversion there, either. IOW, the programmer is responsible for chosing the right types and converting when necessary. The best the compiler can do (and will do hopefully soon) is range checking. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

3 2

Overflow in implicit constant conversion
by Robert Ketzscher 14 Sep '97

14 Sep '97

Hi, first of all I hope this is the right address to pose my problem. If it is not then I apologise for wasting your time. I recently came across GPC and I am now trying to convert a huge Turbo Pascal program (15000 lines total in various units) to a UNIX executable. I thankfully wrote the code fairly modular so I did not expect many problems. However, already the first few units containing all type definitions seem to cause problems. I get the message Overflow in implicit constant conversion at the end of the interface part (i.e. where implementation starts). I only use a handful constants and even after I commented them out I got the same message. I wrote a small unit typedefs as follows: unit typedefs; interface type longint = __long__ Integer; byte = __byte__ Integer; extended = __long__ Real; word = __short__ Integer; longstring = String[255]; shortint = __byte__ Integer; implementation begin end. The interface part of the failing unit contains a few hundred type definitions and various variables all using those types (longint,bytes etc.). Is that what the problem is and if yes how can I avoid it? Any info much appreciated Robert Ketzscher

1 0

Re: Standardized Pascal class library
by Peter Gerwinski 12 Sep '97

12 Sep '97

Hi, Johan! Hi, everybody! According to Johan Larsson: > [...] > I am writing to you since I am trying to get in contact with people who > can and want to > port my works for the Borland dialect of Pascal to other languages such > as Delphi, > FPK and GNU Pascal -- and any other language which could profit by > getting a > standardized class library. > [...] (* Johan, better break your lines at column 72; otherwise it will get hard to read after the mailers will have done it for you. ;*) This approach (writing for more than one Pascal compiler) has obvious advantages, but also the disadvantage that you cannot use the full power of any of the compilers. For instance, you cannot use function over- loading (available in FPK Pascal), operator overloading (available in GNU Pascal), or object properties (available in Delphi). So the common denominator will probably be the language of Borland Pascal 7.0. It should not be too hard to port a program written in this language to GNU Pascal (speaking of recent beta versions, not of gpc-2.0). If you encounter any serious problems (for instance, GPC does not yet support `Block[Read|Write]'), be invited to report them here, so we can improve the GNU Pascal compiler until it compiles EFLIB without major changes to the source. > Why choose EFLIB? First of all, EFLIB will be distributed freely with > source and all - > that is, as soon as the juridical details have been worked out by > Swedish layers (within a > week or maybe a month). > [...] Why don't you choose the GNU LGPL as the distribution conditions? While I am not content with *all* points in the LGPL, it's not good to increase confusion by writing yet another license for Free Software. > EFLIB can thus be used by any Pascal programmer > with > non-commercial objectives. Read: You want to charge for commercial applications of EFLIB? > [...] Finally, EFLIB > is well- > documented since almost 50% of the source code is source code comments. Do you mean ordinary comments in the source, or do you use some system to write the documentation into the source next to the function, so you can extract it using another program? Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GRX graphics library (was: error calling capitalized c routines)
by Peter Gerwinski 11 Sep '97

11 Sep '97

Hello, everybody! According to Sven Hilscher: > > I've made a interface unit for gpc and grx20. Use them with the newest > beta release of gpc. grx20 is a very powerful grafix library for DOS > (DJGPP and Borland-C) and LINUX (SVGAlib and X11). I am installing the archive `grx20.arj' at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/grx20.arj Since the GRX library seems to be rather portable - it runs under plain DOS (DJGPP), Linux (svgalib), and hopefully under any other UNIX (X11) - and it is under the LGPL, it might become "the official" graphics library for GNU Pascal. Any comments? If you try GRX under any system other than DJGPP or Linux, please report the result here. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: demo for using of qsort from lib and a little problem with it
by Peter Gerwinski 11 Sep '97

11 Sep '97

Hallo, Sven! Hello, everybody! According to Sven Hilscher: > > [...] > > type > TestType = Integer; { works with Real, ShortInt, Integer, LongInt } > { crashs with Byte } > [...] > > function CompNum(var e1, e2: TestType):Integer; > Var > r : Real; > begin > r := e1 - e2; > CompNum := Round(r); > end; Consider this with "TestType = Byte", then in `CompNum' we are subtracting two `Byte' variables from each other. GPC chooses the result type to be `Byte' again, so the result is never negative. When I convert them to `Integer' by writing r:= Integer ( e1 ) - Integer ( e2 ); it works. (First it did not work because of a bug in conversions among integer types, but I could fix this.;-) However, is this the correct behaviour? Or should the result type of a subtraction be the "nearest" signed integer type - `ShortInt' in this example? Then, what to do when subtracting two `LongestCard's, especially in cases like "$FFFFFFFFFFFFFFFF - 2" where the result does not fit in `LongestInt'? BTW, Sven, this type casting problem does of course *not* explain the crash you have observed when calling `qsort' on an array of bytes. :-( Confused, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: demo for using of qsort from lib and a little problem with it
by Peter Gerwinski 11 Sep '97

11 Sep '97

According to Sven Hilscher: > > You found also the reason for the crash on sorting a "array of Byte"? Ah - it doesn't crash here, but it doesn't sort either! Okay, I will fix it. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: demo for using of qsort from lib and a little problem with it
by Peter Gerwinski 11 Sep '97

11 Sep '97

According to Sven Hilscher: > According to myself (Peter Gerwinski): > > > > Better say `cmp: Pointer' here because you don't really know the > > type of the function `cmp' is pointing to. > > No - IMHO qsort need always a function (cmp) that return an Integer, but > the parameters/arguments of this function are pointers on different types. True, but your `FuncType' points to a *parameterless* function which returns an integer. This is certainly a type conflict with the actual functions. > You found also the reason for the crash on sorting a "array of Byte"? I cannot reproduce this one - neither with gpc-970714 nor with my current development GPC. :-( With which version and on which platform does it occur? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Standardized Pascal class library
by Johan Larsson 10 Sep '97

10 Sep '97

Hi everybody. My name is Johan Larsson and I am the author of an application framework named EFLIB ("Extended Function Library"). EFLIB is primarily a set of data structures - like linked lists, trees, stacks, queues - streams, filters (conversion, searching algorithms), conversion, text handling, professional math OO classes (numerical methods, math objects such as integer class, complex numbers, matrixes, vectors, expressions, etc) and some other things. EFLIB is also intended to - within reasonable time - contain a full GUI. For more information, see http://www.ts.umu.se/~jola/EFLIB/. I am writing to you since I am trying to get in contact with people who can and want to port my works for the Borland dialect of Pascal to other languages such as Delphi, FPK and GNU Pascal -- and any other language which could profit by getting a standardized class library. I also look for partners all around the world. Maybe you have some material you would like to publish together with EFLIB or as a free EFLIB-friendly product (see http://www.ts.umu.se/~jola/EFLIB/Developing/Friends/)? Why choose EFLIB? First of all, EFLIB will be distributed freely with source and all - that is, as soon as the juridical details have been worked out by Swedish layers (within a week or maybe a month). EFLIB can thus be used by any Pascal programmer with non-commercial objectives. Furthermore, EFLIB is written in a somewhat different way than other tools I have seen around. I have tried to create an object-oriented framework that promote extendiblity into every single detail. For example, all data structures (or rather: ADTs) share common properties defined in abstract base classes. The same thing goes with math classes, streams and so on. Finally, EFLIB is well- documented since almost 50% of the source code is source code comments. I therefore believe that EFLIB is suitable as a multi-platform Pascal class library that can grow within time - it can be improved and extended whenever the user's or developer's want it to. Is EFLIB portable? Yes, I believe so! A high grade of extendibility, modularity and a high-level of abstraction tend to make platform conversions easier. Also, EFLIB does not contain any important MS-DOS-specifics (other than one or two assembler in-lines and a few procedures which is not much when one consider that EFLIB is based on at least 20,000 lines of source code). I have been working on EFLIB for a long time. Not all EFLIB components I have produced are yet published. I have established a certain network of programmers, provide mailing list services, an EFLIB FTP site, SimtelNet distribution and WWW services. Summary: I am looking for people who would like to help me to create a standardized class library for every Pascal programmer. Best Regards, Johan Larsson jola(a)ts.umu.se PS. For more information about EFLIB, please feel free to check out the following URLs: - http://www.ts.umu.se/~jola/EFLIB/ - http://www.ts.umu.se/~jola/EFLIB/Manual/ - http://ftp.sunet.se/pub/lang/EFLIB/

1 0

Re: gpc2.0/cygwin:"GPC.EXE: Inst. prob.: Cannot exec 'as': No such File/dir
by Jan-Jaap van der Heijden 10 Sep '97

10 Sep '97

In article <873835873.3962(a)dejanews.com> you wrote: [...] : When I try to compile anything I always get this message: : GPC.EXE: installation problem, cannot exec `as': No such file or directory : GPC.EXE: Internal compiler error: program as got fatal signal 127 : A "dir \as*.* /s" returns nothing. What is the 'as' the compiler is : looking for? `as' is the assembler. GPC is meant to be part of an existing cygwin32 toolchain, which you don't have. You can get the remaining b17.1 parts as: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/devtools.i486-cygwin32-b17.1.zip Or, you can get a b18 toolchain (GPC + required tools) as: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/gpc-970624.i386-cygwin32-b18.zip Don't mix up b17.1 and b18 binaries -- it won't work. JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

demo for using of qsort from lib and a little problem with it
by Peter Gerwinski 10 Sep '97

10 Sep '97

According to Sven Hilscher: > > program Sort_Test; > [...] > procedure qsort(var base; numelem, size : Integer; cmp: FuncType); C; Better say `cmp: Pointer' here because you don't really know the type of the function `cmp' is pointing to. Otherwise you get a warning: incompatible type for argument 4 of `Qsort'. > qsort(tb, 5, Sizeof(tb[1]), @CompString); The resulting error ("too few arguments") is fixed now. Thanks. A new GPC beta - probably the last one before we can release gpc-2.1 - will be uploaded to Agnes as soon as possible (whatever that means;-). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

gpc2.0: cannot exec `as': No such file or directory
by Kim Michael Eriksen 10 Sep '97

10 Sep '97

Hello I am trying to install a GNU Pascal binary for windows95 (version 2.0 b17.1 corresponding to GCC 2.7.2.1) with cygwin 17.1 (18 tried as well - no difference). In the autoexec.bat of win95 I have added e:\gpcwin32\bin (which is correct) to the path and added the following environment vars: set GCC_EXEC_PREFIX=e:\gpcwin32\lib\gcc-lib\ set LIBRARY_PATH=e:\gpcwin32\lib;e:\gpcwin32\H-i386-cygwin32\lib Spelling is ok. The terminal \ on the prefix IS there. When I try to compile anything I always get this message: GPC.EXE: installation problem, cannot exec `as': No such file or directory GPC.EXE: Internal compiler error: program as got fatal signal 127 A "dir \as*.* /s" returns nothing. What is the 'as' the compiler is looking for? I have read your gpc-list.1997 but did not find anything on this. Any ideas how I can solve this are most welcome! Michael Eriksen Department of Chemistry DTU DK-2800 Lyngby Denmark ------------------------------------------------------------- Kim Michael Eriksen michael.eriksen(a)kemi.dtu.dk Department of Chemistry http://www.kemi.dtu.dk Building 207 phone +45 4588 3111 Technical University of Denmark direct +45 4525 2391 DK-2800 Lyngby fax +45 4588 3136 DENMARK

1 0

Please Remove
by Nathan R. Yergler 10 Sep '97

10 Sep '97

I apologize in advance for posting this message to the whole list, but please either remove my name or let me know how to go about it. My humblest apologies. N. Yergler nate(a)parlorcity.com nate(a)purdue.edu

1 0

error calling capitalized c routines
by Olov Wilander 09 Sep '97

09 Sep '97

I am using DJGPP and the gpc20b.zip binaries from simtelnet, downloaded from simtelnet in september 1997. When I try using the grx20 graphics library (also aviable from the djgpp download sites) it fails. Most functions in this library have one or more capital letters in them, eg. GrSetMode(). I manage to declare this in pascal after reading the info, but when I compile, the linker can't find the functions, because it is looking for grsetmode(). I have found two workarounds: 1. Use "gpc -S", and replace "call _grsetmode" with "call _GrSetMode" in the resulting assembly file, then compile and link that. 2. Go back to C and define interface functions like int grsetmode(...) { GrSetMode(...); } Both methods have disadvantages... If you reply to this, please reply directly by mail, as I am not (yet) a regular reader of this mailing-list. Thanks! Olov Wilander olwi(a)dagy.danderyd.se

2 1

Unix blues...
by Orlando Llanes 09 Sep '97

09 Sep '97

I found out what I was doing wrong with the DIFF file, but despite my knowing what's wrong, it doesn't solve my problem :( I'm stuck with 2.01b until the next compiled ZIP'd version. The file names get corrupted despite my using WinZip, by corrupted, I mean that some filenames didn't translate properly (I just love the gpc-2.7.2.1.patch file). I'm sorry I'm being such a pain in the butt, I just want to get updated :( See ya! Orlando Llanes

1 0

Re: Binary installation
by Ken Linder (KC7RAD) 08 Sep '97

08 Sep '97

At 02:56 PM 9/6/97 -1000, Tom Dye <tdye(a)lava.net> wrote: >Hello, > >Sorry to bother with a question that is probably trivial, but I did >something wrong installing the 9707 beta binary for Linux and now can't >get gpc to work. > >Instead, I get the following error messages: >numeric constant with no digits >numeric constant with no digits >warning: missing program header >In function 'program_noname' >parse error at null character > >I'll appreciate any help you might offer, so that I can correct my >blunder. > >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. Alas, I now know I am not going nuts!!! Tom, I have the same problem with the binary executable as you! We discussed this problem briefly on the mail group but could only come up with the possibility that I am using an old version of libc.so (I am using libc.so.5.3.12 but Jan-Jaap reccomended 5.4.20 or newer. Just FYI, I have not solved it yet (work is incredibly busy). I am using RedHat 4.1 installation with nothing special added. Someone suggested that 4.2 works fine. Let us know your progress. As soon as I hire an assistant, fire a contractor, and finalize my 1998 department budget I will start working on it again! Later... Ken L.

1 0

Re: compiler bug? Call of sqr in a expression as parameter
by Peter Gerwinski 07 Sep '97

07 Sep '97

According to Sven Hilscher: > > Please check, if it is an error! > [...] > Test := TestNum(sqr(ReturnNum)); > { > the GPC compiler meant: > "argument to `sqr' must be of integer, real or complex type" > } It is an error, and the same problem holds for `abs', `round', and other functions. Thanks for the report. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: busg or features?
by Peter Gerwinski 07 Sep '97

07 Sep '97

According to Sven Hilscher: > > program Test; > > var > S : String(7); > > begin > S := 'SCHNAPS'; > S := S + #48 + #48; { wow, the string expands the size - that's right? } That's a bug: GPC is not yet able to catch range check errors like this one. > Writeln(S); > Writeln(S + #48#48); { This is needed for Borland style! } I will fix that. Thanks. > end. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: error calling capitalized c routines
by Peter Gerwinski 07 Sep '97

07 Sep '97

According to peter: >From peter Mon Sep 8 01:53:57 1997 Subject: Re: error calling capitalized c routines To: olwi(a)dagy.danderyd.se (Olov Wilander) Date: Mon, 8 Sep 1997 01:53:57 +0200 (MEST) Cc: gpc(a)hut.fi In-Reply-To: <34138C8A.1672(a)dagy.danderyd.se> from "Olov Wilander" at Sep 7, 97 10:26:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 698 According to Olov Wilander: > > When I try using the grx20 graphics library (also aviable from the djgpp > download sites) it fails. Most functions in this library have one or more > capital letters in them, eg. GrSetMode(). Declare it like this: Function GrSetMode ( m, w, h, nc, vx, vy: Integer ): Integer; AsmName 'GrSetMode'; or like this: Function GrSetMode ( m: Integer; ... ): Integer; AsmName 'GrSetMode'; 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

busg or features?
by Sven＠rufus.central.de 07 Sep '97

07 Sep '97

program Test; var S : String(7); begin S := 'SCHNAPS'; S := S + #48 + #48; { wow, the string expands the size - that's right? } Writeln(S); Writeln(S + #48#48); { This is needed for Borland style! } end.

1 0

Binary installation
by Tom Dye 07 Sep '97

07 Sep '97

Hello, Sorry to bother with a question that is probably trivial, but I did something wrong installing the 9707 beta binary for Linux and now can't get gpc to work. Instead, I get the following error messages: numeric constant with no digits numeric constant with no digits warning: missing program header In function 'program_noname' parse error at null character I'll appreciate any help you might offer, so that I can correct my blunder. 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

compiler bug? Call of sqr in a expression as parameter
by Sven＠rufus.central.de 06 Sep '97

06 Sep '97

Please check, if it is an error! greetings... ___, ((__ o ,____)) V E N I program Bug; function ReturnNum: Real; begin ReturnNum := 0; end; function TestNum(AnyNum: Real): Real; begin TestNum := AnyNum; end; var Test : Real; begin Test := sqr(ReturnNum); { no compiler error } Test := TestNum(sin(ReturnNum)); { no compiler error } Test := TestNum(sqr(0.1)); { no compiler error } Test := TestNum(sqr(ReturnNum)); { the GPC compiler meant: "argument to `sqr' must be of integer, real or complex type" } end.

1 0

demo for using of qsort from lib and a little problem with it
by Sven＠rufus.central.de 06 Sep '97

06 Sep '97

program Sort_Test; { demo for using of the qsort function from gpc } { sven(a)rufus.central.de } uses grx20; type TestType = Integer; { works with Real, ShortInt, Integer, LongInt } { crashs with Byte } StrType = String(8); FuncType = ^Function: TestType; function CompNum(var e1, e2: TestType):Integer; Var r : Real; begin r := e1 - e2; CompNum := Round(r); end; function CompString(var e1, e2: StrType):Integer; begin if e1 = e2 then CompString := 0 else if e1 > e2 then CompString := 1 else CompString := -1; end; procedure qsort(var base; numelem, size : Integer; cmp: FuncType); C; var i : Integer; ta : Array[1..5] of TestType; tb : Array[1..5] of StrType; begin ta[1] := 4; ta[2] := 2; ta[3] := 1; ta[4] := 3; for i := 1 to 5 do Writeln(ta[i]); qsort(ta, 5, Sizeof(ta[1]), @CompNum); Writeln; for i := 1 to 5 do Writeln(ta[i]); Writeln; tb[1] := 'Peter'; tb[2] := 'Paul'; tb[3] := 'Mary'; tb[4] := 'Sven'; tb[5] := 'Adam'; qsort(tb, 5, Sizeof(tb[1]), @CompString); for i := 1 to 5 do Writeln(tb[i]); Writeln; end.

1 0

gpi mechanism
by Peter Gerwinski 05 Sep '97

05 Sep '97

According to Tom Dye: > > I just ran into the bug in the gpi mechanism that is documented in the gpc > info file. My version of gpc is several months old. I have two > questions. > > 1) Is the gpi mechanism fixed in the latest beta release? Yes. > 2) If not, are bug reports on this still welcome? If you find any bugs in the GPI mechanism of the latest beta release, it will be highly welcome. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Objects question...
by Peter Gerwinski 05 Sep '97

05 Sep '97

According to Frank Heckenbach: > > I think he meant dynamically loading and freeing the code of the object's > method, not it's data. AFAIK, one needs to use dynamic linking in order to > achieve this, but I don't know much about it. I didn't refer to data only: Modern DPMI managers swap both code and data to disk if there is not enough physical memory. On such a platform just forget about overlays and such: You always have them automatically. (This holds for Borland Pascal 7.0 in protected mode, too.) > BTW: Do DJGPP and/or EMX do this, too? Yes. Under DOS, DJGPP and EMX swap memory to disk unless you disable it. When EMX runs under OS/2, the OS does the swapping. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Objects question...
by Peter Gerwinski 05 Sep '97

05 Sep '97

According to Bernhard Tschirren: > > BTW - Code size is so minimal compared with DATA, I personally dont see ANY > reason for trying to dynamically load code. The OS (or DPMI server) does this automatically if needed and not disabled. > GPC executables are only so BIG because there is a HEAP of unused > library code appended to the end (BTW: WHY IS THIS??) See the DJGPP FAQ list, section 8.15. > A procedure is > usually not much bigger than 20KB!! That depends on how long your procedures are. Other than with BP, there is no limit in GPC how long a procedure can become besides your virtual RAM. In practise, I am often surprised hwo small my procedures get when compiled with optimization (-O, -O2, or -O3). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Bug ??
by Frank Heckenbach 05 Sep '97

05 Sep '97

Stephane wrote: > Hi, my name is Stephane, I'm French and BP7 converted... to GNU GPC ! Hi! I'm also coming from BP7, like many of the GPC developers... > I think I found a BUG or something like that... > (file linked in ZIP) The problem is that your string constant was too long, and GPC didn't catch it. So the string extended to the memory area where the array was stored. This was fixed in a very recent patch which might not be publicly available. Just wait for the next release, and the bug should be gone! This means, you will get a proper error message then. :-) > {Another question :} > FOR I:=1 TO 400 DO S[I]:='X';{don't work why ?? (= Fillchar X)} What error shows up? It works fine with my version (provided, of course, that I declare the variable I). In your originial program, of course, you have the length of the string set to more than 400, so you'll get some "garbage" after the 400 X's if you write the string. Which GPC version are you using? If it's an older version, this might be an old bug which is fixed by now. The latest versions can be found at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ Anyway, thanks for your bug reports, such reports help to improve GPC. Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Bug ??
by Stéphane 05 Sep '97

05 Sep '97

Hi, my name is Stephane, I'm French and BP7 converted... to GNU GPC ! I think I found a BUG or something like that... (file linked in ZIP) Bye, The Kilobug Team

1 0

gpi mechanism
by Tom Dye 05 Sep '97

05 Sep '97

Hello, I just ran into the bug in the gpi mechanism that is documented in the gpc info file. My version of gpc is several months old. I have two questions. 1) Is the gpi mechanism fixed in the latest beta release? 2) If not, are bug reports on this still welcome? Thanks, 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: Objects question...
by Orlando Llanes 04 Sep '97

04 Sep '97

From: Bernhard Tschirren <bernie(a)icenet.com.au> >BTW - Code size is so minimal compared with DATA, I personally dont see ANY >... >usually not much bigger than 20KB!! That's what I'm trying to avoid, there's a lot of programs that take memory for granted, and also, I don't want anything in memory unless it's needed. If that's the way it is, then that's the way it'll have to be I guess, I'm just trying to reduce unnecessary overhead. See ya! Orlando Llanes

1 0

Re: Objects question...
by Bernhard Tschirren 04 Sep '97

04 Sep '97

>> You are obviously writing a memory manager to keep the amount of RAM >> your program uses small and to use the disk instead. On UNIX-like >> platforms you don't need to do this because the operating system does >> it for you. > >BTW: Do DJGPP and/or EMX do this, too? > If you are using CWSDPMI as your DPMI host, DJGPP does it by default (up to 128MB or 256MB of virtual ram) - however it can be disabled (For games and such). PMODETSR (another DPMI host) does NOT provide virtual memory. If you run your program from Windows it will obviously provide swap space. I dont know about EMX but I would presume that it does the same thing. ________________________ e-mail: bernie(a)icenet.com.au | _) | | ptschirrenb(a)cc.curtin.edu.au |___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Objects question...
by Orlando Llanes 04 Sep '97

04 Sep '97

From: Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> >You are obviously writing a memory manager to keep the amount of RAM >... >Your application does not even notice this. Sounds like you mean a Virtual Memory Manager, what I'm actually working on are the screen objects, and the reason I brought it up is because BP loads the object code whether it's needed or not. So basically, GPC loads all object code at startup? Or does it load it when it's called with New? See ya! Orlando Llanes

2 1

Re: Objects question...
by Frank Heckenbach 04 Sep '97

04 Sep '97

Peter Gerwinski wrote: > > Is there a way to > > create an object so that it will be loaded only if allocated with "New"? In > > other words, is there a way to keep the code for the object on disk until > > it's needed, and removed form memory when not? > > Write a constructor that fetches all needed data from the file when > the object is `New'ed; if you want to keep the stuff in the file > current, write a destructor that writes everything back to disk > when the object is `Dispose'd. (* BTW, this has nothing to do with > the internals how objects work at run-time. ;*) I think he meant dynamically loading and freeing the code of the object's method, not it's data. AFAIK, one needs to use dynamic linking in order to achieve this, but I don't know much about it. > You are obviously writing a memory manager to keep the amount of RAM > your program uses small and to use the disk instead. On UNIX-like > platforms you don't need to do this because the operating system does > it for you. BTW: Do DJGPP and/or EMX do this, too? Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Objects question...
by Peter Gerwinski 04 Sep '97

04 Sep '97

According to Orlando Llanes: > > I'm curious about something with objects as it will affect the game lib. > What I need to know is how objects work at run-time. Each instance of each object has an implicit "vmt" field which contains a pointer to the "virtual method table" where the addresses of all virtual methods are stored. GPC produces inline code to initialize the vmt immediately before a constructor is called. (BP does the assignment inside the constructor instead.) When a virtual method is called, the program dereferences the vmt field, and so on. > Is there a way to > create an object so that it will be loaded only if allocated with "New"? In > other words, is there a way to keep the code for the object on disk until > it's needed, and removed form memory when not? Write a constructor that fetches all needed data from the file when the object is `New'ed; if you want to keep the stuff in the file current, write a destructor that writes everything back to disk when the object is `Dispose'd. (* BTW, this has nothing to do with the internals how objects work at run-time. ;*) You are obviously writing a memory manager to keep the amount of RAM your program uses small and to use the disk instead. On UNIX-like platforms you don't need to do this because the operating system does it for you. Just allocate as many MegaBytes as you need; if this exceeds your physical RAM the operating system swaps out the unneeded parts automatically and restores them when they are needed again. Your application does not even notice this. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BUG !
by Peter Gerwinski 04 Sep '97

04 Sep '97

> There is a bug !!! > > in your Web page... > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_56.html#SEC93 > "See See section How you can contribute to GNU Pascal for details." > --^ :-) We know. In newer versions of the documentation this is already fixed. The problem is that the GNU "Texinfo" format which is standard for documentation of GNU programs requires a particular wording. Thanks for the report, anyway. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

BUG !
by Stéphane 04 Sep '97

04 Sep '97

There is a bug !!! in your Web page... http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_56.html#SEC93 "See See section How you can contribute to GNU Pascal for details." --^ Stephane From The Kilobug Team.

1 0

Objects question...
by Orlando Llanes 03 Sep '97

03 Sep '97

I'm curious about something with objects as it will affect the game lib. What I need to know is how objects work at run-time. Is there a way to create an object so that it will be loaded only if allocated with "New"? In other words, is there a way to keep the code for the object on disk until it's needed, and removed form memory when not? See ya! Orlando Llanes

1 0

Re: gpc objects
by Orlando Llanes 01 Sep '97

01 Sep '97

From: Paul Doerwald <clavicle(a)niagara.com> >It's something I'd be interested in doing, preferably with someone else, >because I'm not a stellar pascal programmer. I have a fair bit of TP >experience, and a reasonable grasp of programming language principles. Is >there someone who would join me on it? I'll be helping out too. See ya! Orlando Llanes

1 0

Re: gpc objects
by Paul Doerwald 01 Sep '97

01 Sep '97

>> I think a good documentation, explaining all gpc functioning, will be >> very useful to all pascal programmers that want to migrate to gpc. > I agree. Anybody interested to help writing such a thing? It's something I'd be interested in doing, preferably with someone else, because I'm not a stellar pascal programmer. I have a fair bit of TP experience, and a reasonable grasp of programming language principles. Is there someone who would join me on it? ----- Paul Doerwald clavicle(a)niagara.com www.niagara.com/~clavicle

1 0

Re: gpc objects
by Peter Gerwinski 31 Aug '97

31 Aug '97

According to Fausto Iannuzzi: > > I know gpc has both functions and operators overloading that are missing > form extended pascal It has operator overloading; function overloading is planned but not yet available. > because it does not support OOP and are also missing > from borland pascal and delphi (2.0). This has nothing to do with OOP. > From which standard they have been > implemented? >From Pascal-SC (PXSC). See http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html > Is there in gpc other OOP stuff that is not present in BP ? You can mix methods and data fields: Type MyObject = object a: Integer; Constructor Foo; b: Real; Destructor Bar; c: Char; Procedure Baz; d: ^String; end (* MyObject *); > I think a good documentation, explaining all gpc functioning, will be > very useful to all pascal programmers that want to migrate to gpc. I agree. Anybody interested to help writing such a thing? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

gpc objects
by Fausto Iannuzzi 31 Aug '97

31 Aug '97

Hi! I know gpc has both functions and operators overloading that are missing form extended pascal because it does not support OOP and are also missing from borland pascal and delphi (2.0). From which standard they have been implemented? Is there in gpc other OOP stuff that is not present in BP ? I think a good documentation, explaining all gpc functioning, will be very useful to all pascal programmers that want to migrate to gpc. bye, Fausto. Reply addresses: fausty(a)itb.it (primary - local provider) fausty(a)peacelink.it (gateway - please no files here) Homepage: www.itb.it/users/fausty/welcome.html

1 0

Re: bwGraphics Library
by Orlando Llanes 28 Aug '97

28 Aug '97

From: Bernhard Tschirren <bernie(a)icenet.com.au> >ZIP (~80KB). NOTE: As I meantioned to Orlando, the source will NOT compile >with the latest version of GPC - but it will compile with the NEXT update >(whenever that is released!) Which reminds me, what directory do I rebuild the source from for GPC? >It WAS working with BOTH. I used the protected mode bank swithing (VBE2), >if needed. I think that code is still in VESA.PAS. I also had VBE2 linear >frame buffer modes working. You have to think about the loud majority that don't have VBE2 tho. Not everybody has the UniVBE driver, think of how upset the person would be if they bought your game or application only to find out that they have to pay more (especially when they consider that they've spent enough as it is). Another thing is that VBE2 hasn't caught on to Video Card BIOS's yet, not everybody has a Matrox Millenium II. My point is that you can support it as an enhancement, but your libs should not depend on the driver being VBE2. Disregard this if you support direct bank switching for VBE 1.2+ >I have done it so that I have the best of both worlds! The VGA.DRV is in > ... >first attempt at explaining it: It is a nice scheme, but do you plan to make your lib portable? I ask because loadable drivers may not be portable to other platforms or OS' >This may sound confusing but it is NOT, its the HEART of my engine - and I > ... >of doing stuff across a network, however I have not thought much about that One of my major goals is simplicity. I aim for the beginner (hence the API being as it is), the novice, and the advanced user (exposing the virtual screen buffer for custom operations). >Now, back to the OBJECT problem. One of the FunctionNr's provided by the > ... >this will become clear - its very simple (for me anyway)! If you go with the COM architecture, I'd suggest writing a wrapper API to target the users who want to focus on the algorithms rather than the coding, or for the beginners. Somethign else you should consider is how you plan to release the code, I noticed you have it under the GPL, it may be better to release it under the LGPL, it gives the user more flexibility on how they can use it, and also retains your copyright. See ya! Orlando Llanes

1 0

bwGraphics Library
by Bernhard Tschirren 28 Aug '97

28 Aug '97

This is primarily directed towards Orlando Llanes, but Im sending it via this list because I would like some input from other people. If anybody would like the -current- source code, please mail me. I will attach it as a ZIP (~80KB). NOTE: As I meantioned to Orlando, the source will NOT compile with the latest version of GPC - but it will compile with the NEXT update (whenever that is released!) At 16:58 27/08/97 -0400, you wrote: >> (VESA.PAS) is included, but completely OLD and NON WORKING! > Using Linear Frame Buffers? Or using bank switching? I was thinking of It WAS working with BOTH. I used the protected mode bank swithing (VBE2), if needed. I think that code is still in VESA.PAS. I also had VBE2 linear frame buffer modes working. >page, then it allocates a new page. There's something I'm curious about, >does your lib use a loadable device driver? I ask because I saw VGA.DRV If >it is, it may be a bad idea to use one because you're prolly better off >using objects. I have done it so that I have the best of both worlds! The VGA.DRV is in fact a loadable device driver (DXE) HOWEVER if you look at VGA.PAS (Source of VGA.DRV) you will see that it mostly a heap of communication routines using an INGENIOUS scheme developed by me (as fas as I know)! Below is my first attempt at explaining it: The device driver loads as a record (pre-initialised) which is defined in bwGLOBAL.PAS as "bwTGraphDriver". This record defines pointers to two routines - "ComHandler" and "ComRequest". ANYTHING and EVERYTHING (except drawing to the screen at this stage) is done using these two routines. Below is a small diagram which shows how it all works: MAIN PROGRAM DRIVER ComRequest -------------------> ComHandler ComHandler <------------------- ComRequest To communicate with the graphics driver, the MAIN PROGRAM calls "ComRequest(FunctionNr)" which infact points at the "ComHandler" on the DRIVER. Similarly, the DRIVER may communicate with the MAIN PROGRAM by calling its "ComRequest(FunctionNr)" which points to "ComHandler" in the MAIN PROGRAM. FunctionNr is just a constant that says WHAT should be done by the handler. A list of these can be found in bwGLOBAL.PAS. This may sound confusing but it is NOT, its the HEART of my engine - and I LOVE IT! This means that any driver could be extended to become PRINTER DRIVERS, etc. by setting up and handling extra FunctionNr's in the "ComHandler" routine on the DRIVER. Hmm, it also sounds a bit networky with all that "communication" and stuff - BINGO! It is also an efficient method of doing stuff across a network, however I have not thought much about that yet... Now, back to the OBJECT problem. One of the FunctionNr's provided by the standard driver is to return a pointer to the SCREEN OBJECT. So, the user can have direct access to the screen via this object. The code below shows how simple it is to do this: Var Screen : bwPBaseBitmap; { Screen Object } Begin Error := ComRequest^(bwComGetScreen,@Screen); If (Error <> bwErrAllOK) Then Return(Error); End; This above code is actually never needed because it is automatically done when you initialise a graphics mode. The code for this is "bwGraphInit" in bwGRAPH.PAS. Therefore, the VGA.DRV file contains both the communication handlers, and the object definition/methods of the screen. If you take a look at the code this will become clear - its very simple (for me anyway)! The default screen/bitmap object is called "bwTBaseBitmap" and you can find the definition for it in bwGLOBAL.PAS. This object is overridden by "bwTBitmap8Bit" (bw8BIT.PAS) which implements 8 bit bitmaps in memory. In future, I will add other objects for 16, 24 and 32 bit bitmaps. The VGA driver (VGA.PAS) overrides the "bwTBitmap8Bit" object. The base screen object (bwTBaseBitmap) is set up so its easy to write drivers for harware accelerated graphics cards. So, a driver only needs to override the "PutBitmap" procedure on a board that supports hardware blitting. As a pleasant side effect, this overriding creates small driver files - Just take a look at VGA.DRV and VGA.PAS. If you have any more questions please mail me. Im happy that I can tell someone else my thoughts and ideas... ________________________ e-mail: bernie(a)icenet.com.au | _) | | ptschirrenb(a)cc.curtin.edu.au |___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Pascal for Pilots
by Matthias vonDavier 27 Aug '97

27 Aug '97

Hi there, I need some help. Please let me know how to find more specific information about how to configure the GPC as a cross compiler for use with the GCC 0.5.0. system for the PalmPilot PDAs. Probably there is someone who did that already, or at least someone who has built a cross compiler for the MC68k. Thanks for any ideas, Matthias.

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 27 Aug '97

27 Aug '97

At 07:19 PM 8/27/97 +0200, Peter Gerwinski wrote: >According to Jan-Jaap van der Heijden: >> On Wed, 27 Aug 1997, Ken Linder (KC7RAD) wrote: >> > >> > A few things I checked... >> > [...] >> > De-Installed/Re-Installed Linux > > =8-| > >> Could it be your libc is a a very old/very new one? >> Peter -- did you upgrade anything on your machine lately? >> >> I know at least libc-5.4.x with x<20 are buggy; A binary compiled against >> 5.4.x should (but isn't always) compatible to an older libc. > AHHHH!!!! You might have struck upon something! My libc is : libc.so.5.3.12 This just might be it... maybe... I will get a newer version & install it this week sometime. In the meantime, thanks for all the great help! I will let you know what happens! Ken Linder

1 0

[Long!] Game Lib specs...
by Orlando Llanes 27 Aug '97

27 Aug '97

BASE GRAPHICS OBJECT: Object Methods: * Init - Check for required drivers, init conditions, etc. * Done - Dispose of pre-allocated memory, dispose of off-screen buffer if neccessary Screen Methods: * GetRaw - Retrieves a section directly from the screen into a "Universal" format * PutRaw - Places a raw bitmap * SetMode - Handle modes specific to object, initialize look-up table, allocate off-screen buffer, change conditions if neccessary * ShowVirtScr - Shows default off-screen buffer * ShowUserVirtScr - Shows external off-screen buffers, for triple buffering Palette Methods: * GetPalette - Retrieves screen palette, intended for 256 color modes * SetPalette - Set palette, intended for 256 color modes * RotatePalette - Rotate screen palette, intended for 256 color modes * FadeIn - Fade in palette * FadeOut - Fade out palette GUI Primitive Methods: * HLine - Horizontal Line * VLine - Veritcal Line * Line - Line for any direction * Rect - Hollow rectangle * FilledRect - Filled rectangle * Shadedrect - Hollow rectangle, color1 for upper & left, color2 for lower & right line * FilledShadedRect - Hollow rectangle, color1 for upper & left, color2 for lower & right line, color3 for fill color Sprite Primitive Methods: * GetSpr - Retrieves a sprite directly form the screen * PutSpr - Places a sprite with transparency and clipping * PutTile - Places sprite/tile having square dimensions with transparency and clipping * PutBkgTile - Places sprite/tile having square dimensions with clipping Font Methods: * PutChar - Places a char using a monochrome font * PutString - Places a string with a monochrome font * DrawChar - Places a char using a bitmapped font * DrawString - Places a string with a bitmapped font Mouse Methods: * HideMouse - Hide current Mouse cursor * ShowMouse - Show current Mouse cursor * ButtonClick - Updates Mouse button press status * MouseMove - Updates Mouse coordinates according to current video mode * SetUserCursor - Sets cursor to either monochrome or bitmap Variables: * GraphErr - Graphic "driver" error code * GraphOk - Init failure/success * GraphMode - Current internal graphics mode * MinX, MinY, MaxX, MaxY - Screen resolution * ClipX, ClipY, ClipX2, ClipY2 - Clip region * DirectWrite - Write/Don't Write direct to screen * VirtSel - Selector for off-screen buffer * VirtOfs - Offset of off-screen buffer * VirtScr - Full pointer to off-screen buffer * wScrSel - Screen write selector * rScrSel - Screen read selector * LuT - Lookup Table, must be declared by inherited objects since Pascal doens't allow inherited variables to change in size GENERIC GRAPHICS ROUTINES: Screen Operations: * InitMode - Checks mode range, allocates appropriate "driver", sets base object pointer to allocated "driver", calls Init and SetMode methods * GetMode - Returns GraphMode variable * DoneMode - Disposes current "driver" after calling Done method GUI Primitives/Sprite Primitives/Mouse Primitives: * Procedural/Function wrappers to methods * Function methods to certain variables Mode specific support: VBE/Quantizing: * DecodeRGB - Convert from R/G/B to 256 color index * EncodeRGB - Convert from 256 color index to R/G/B value according to graphic mode memory model * SetFntDepth - Set depth of font if bitmapped; reduce colors if Pixel Bit Depth is less than Font Bit Depth, increase colors if greater than, nothing if equal * SetSprDepth - Set depth of sprite; reduce colors if Pixel Bit Depth is less than Font Bit Depth, increase colors if greater than, nothing if equal * SetRawDepth - Set depth of raw bitmap; reduce colors if Pixel Bit Depth is less than Font Bit Depth, increase colors if greater than, nothing if equal Mode-X: * Linear2PlanarFnt - Convert linear bitmapped font to Mode-X planar * Linear2PlanarSpr - Convert linear sprite to Mode-X planar * Linear2PlanarRaw - Convert linear bitmap to Mode-X planar KEYBOARD: Procedures/Functions: * KeyPressed - Reports whether or not a key has been pressed * ReadKey - If key is ready, returns scan code * PushKey - Simulates key press Variables: * CurKey - Scan Code of current key pressed * Key - Table for each key, status of whether or not key is pressed, used for multiple keypresses Cheat Code Support: * AddCheatCode - Places key combination in cheat code list, set appropriate handler via procedural pointer * DelCheatCode - Removes key combination from cheat code list SPRITES: Procedures (According to graphics mode memory model): * ScaleSprite - Resize sprite * RotateSprite - Rotates sprite * CreateMask - Used for collision detection * FlipSprite - Flips a sprite vertically * MirrorSprite - Flips a sprite horizontally File Operations: * LoadSprite - Load sprite file, if key is not blank, loads from resource file BASE BITMAP OBJECT: Object Methods: * Init - Sets file name, and resource key (if applicable) * Done - Disposes memory allocated to bitmap Bitmap Methods: * LoadBitmap - Loads BMP/PCX/etc file, if key is not blank, loads from resource file * LoadBitmapXY - Loads BMP/PCX/etc file, if key is not blank, loads from resource file. Loads a portion of the bitmap * GetMemUsed - Returns amount of memory used by "raw" bitmap * GetRawPtr - Returns pointer to bitmap buffer * GetPalettePtr - Returns pointer to bitmap's palette if present Format Saving Functions: * SavePCX * SaveBMP * SaveGIF * etc. SPECIAL EFFECTS: Sprite Operations: * GlassLens - Glass Lens effect * Sinus - Sinus effect Screen Operations: * DissolveIn - Dissolve screen from background * DissolveOut - Dissolve screen to background * ExitLeft - Slide screen to the left * ExitRight - Slide screen to the right * ExitUp - Slide screen upwards * ExitDown - Slide screen downwards * MotionBlur - Display sprite with a trail SOUND & MUSIC: Device Operations: * InitDevice - Initialize sound card, if specified to, installs handler * SetVolume - Set sound card volume * PollDevice - Manually checks sound card, used if programmer has their own timer MOD/S3M/669/MIDI operations: * LoadMusic - Loads music file, if key is not blank, loads from resource file * PauseMusic - Pause music * PlayMusic - Play music * DoneMusic - Unload music from memory * SetMusicVol - Change volume of music WAV/Raw operations: * LoadSound - Loads sound file, if key is not blank, loads from resource file * PauseSound - Pause sound * PlaySound - Play sound * DoneSound - Unload sound from memory * SetSoundVol - Change volume of sound Flags: * DevPoll - Flag to indicate that sound card is to be checked manually * DevDMA - Flag to indicate that DMA ISR handler should be installed * DevTimer - Flag to indicate that Timer ISR handler is to be used MISC ROUTINES: Procedures: * MoveFPU - FPU mode from dest to source, Pentium optimization * MoveSD - DWord moves from dest to source, 386+ optimization * IncPtr - Increments pointer to next offset * UIntStr - Converts a number up to DWord size to string, 0 padded if specified JOYSTICK: Procedures: * AddActionEvent - Activates specified procedure according to Joystick action Functions: * ReadAxis - Updates Axis matrix by reading joystick * ButtonPressed - Updates Button press status, used like Keypressed Variables: * Axis - Array of booleans coresponding to joystick axis * Button - Array of Booleans about whether or not a specific button on the specific joystick has been pressed RESOURCE FILE: Object Methods: * Init - Sets resource filename, if filename is blank, resource file is appended to the end of the application file. Loads file list into memory * Done - Unload file list, release allocated memory Compression Methods: * EncodeStored - Saves memory buffer to file as is * EncodeFixed - Saves memory buffer to file using fixed Huffman codes * EncodeDynamic - Saves memory buffer to file using dynamic Huffman codes * EncodeRes - Compresses and saves memory buffer to the main resource file, calls EncodeStored, EncodeFixed, and EncodeDynamic * EncodeFile - Adds a file to the main resource file Decompression Methods: * DecodeStored - Loads resource into memory as is * DecodeFixed - Loads resource into memory using fixed Huffman codes * DecodeDynamic - Loads resource into memory using dynamic Huffman codes * DecodeRes - Decompresses and loads into memory a resource from the main resource file, calls DecodeStored, DecodeFixed, and DecodeDynamic * DecodeFile - Decodes a file outside of the main resource file into memory Search Methods: * SearchRes - Searches for key, returns whether or not key has been found GUI: Objects: * TAppShell - Message/Event based application skeleton * TWindow - Window object * TDesktop - Area between TMenuBar and TStatusBar * TStatusBar - Shows hints, or in games shows game stats * TMenuBar - Menus at the top of the screen * TPopupMenu - Submenus for TMenuBar, or free floating Pop-up menus * TCheckBox - Check box handler * TRadioBtn - Radio button handler * TScrollBars - Scroll bars, horizontal or vertical * TStaticText - Shows a regular string * TInputLine - Takes non-modal input * TStringList - Returns which item has been clicked from a list * TStatusCounter - Returns percentage Common Dialog Objects: * TFileDlg - Multiple purpose file dialog, shows directory listing, file listing, file input line, returns file name chosen from list and button result * TColorDlg - Color picker dialog, shows available colors depending on memory model of current graphics mode * TMessageBox - Message box dialog, used for "About", Error messages, etc MOUSE: Procedures: * SetCustomMouseHandler - Installs custom mouse handler for mouse click, or mouse movement * ReadMouse - Updates variables manually * SimMouseAction - Simulates a mouse action Functions: * InitMouse - Initializes mouse, uses flags for Hardware reset, Software reset, or both. Returns whether or not driver is present Variables: * MouseDblClick - If true, mouse button has been clicked twice * MousePress - If true, mouse button is down * MouseRelease - If true, mouse button has been released * MouseBtn - Array of Booleans corresponding to mouse button * MouseX, MouseY - Coordinates of mouse cursor TIMER: Procedures: * StartTime - Installs timer, records start time (if slow clock) * StopTime - Removes timer, records stop time (if slow clock) * InitTimer - Installs timer handler * SetRate - Sets rate of timer Variables: * UserFastTimer - Hook for user defined fast timer * UserSlowTimer - Hook for user defined slow timer BASE ANIMATION OBJECT: Object Methods: * Init - Sets file name, and resource key (if applicable) * Done - Disposes memory allocated to animation Animation File Methods: * LoadAnim - Loads AVI/FLI/etc file, if key is not blank, loads from resource file Animation Action Methods: * PlayAnim - Plays animation until done * RevAnim - Reverses direction of animation * PauseAnim - Pause animation * StopAnim - Stop animation * NextFrame - Returns a pointer to a Raw bitmap frame, used to manually update frame * PrevFrame - Returns a pointer to a Raw bitmap frame, used to manually update frame * SetPlayRate - Sets playback rate * FFAnim - Fast forward * RWAnim - Rewind Animation Misc Methods: * GetMemUsed - Returns amount of memory used by "raw" bitmap * GetRawPtr - Returns pointer to bitmap buffer * GetPalettePtr - Returns pointer to bitmap's palette if present Animation Save Functions: * SaveAVI * SaveFLI * etc Variables: * DrawProc - Procedural pointer to draw frame * PlaySound - Procedural pointer to play sound <rambling> This is the preliminary draft, I got my ideas form things I liked, disliked, saw what could be done better, etc. There are a couple of things that are up in the air, especially the resource file manager, I want to structure it in a way that the file is opened as needed rather than having the file pointer opened until closed. Another goal of this lib is to be able to switch resolutions dynamically and everything will be scaled proportionately. I'd like for bitmap/font/sprite color depth to be reduced/incresed. Dynamic mode resolution change is especially useful for 3-D engines such as Quake as everything can merely scale itself and re-draw. <problem> The problem I face with this is the following example scenario: 320x200x256 color mode set 256 color sprites loaded 640x480x32k color mode set 256 color bitmaps converted from color indices to RGB encoded word (1:5:5:5) 640x480x256 color mode set 32k color bitmaps converted from RGB encoded Word to 256 color indices It's ok if you didn't understand the scenario, the point of it is how I should handle converting from palette indices to the appropriate RGB encoded model? I was thinking of loading the file, encoding it to a temporary buffer, releasing the loaded bitmap, and then setting the pointer to the buffer. Alternatively, the programmer can put bitmaps for every memory model, but as you know it would take up too much disk space. My goal is to be able to use the bitmap at any screen depth. </problem> Something else I planned about this library is the conversion of bitmaps, you load a bitmap from a specific format, when loaded it is in a "Raw universal format" meaning palette indices or (4 byte) RGB, you can then save it in a different format with the appropriate function. This isn't meant to be done in realtime, however the Save/Load functions will be as fast as possible (like the screen snapshots in games for previews, etc). The conversion is mainly intended for bitmap editors. This game lib can be useful for games, but I also intend to make it versatile enough to create other applications while not creating any overhead. The save functions in the ANIMATION: will most likely take a file name, and will read the filenames sequentially numbered and encode them. I haven't decided how to incorporate sound into them yet. On another note, I don't yet have a plan for how Network I/O will be structured, I want to create a generic "universal" API in which it can open a connection via serial ports, parallel ports, TCP/IP (using a dial-up PPP connection if neccessary) Also not listed is the scripting support, I want to the lib to be able to use a language engine which compiles codes rather than interpreting plain english for speed. I would like for the scripting engine to allow the programmer to code as little as possible. It will include a compiler so that the end-user can create the script and the engine will compile it into it's "native" form. Something that is up in the air as well are the file formats, there should be a flag to indicate the bit depth of the file. That's as much as I have planned at the moment for all file formats. Fonts and Mouse Cursors will be monochrome or bitmapped. I plan to have efficient pixel precise collision detection, but I wonder if built-in collision detection is the way to go when drawing the sprites. An alternative is creating masks of the sprites and doing the collision detection that way. Oh yeah, almost forgot, I'm not gonna skip on the 3-D stuff, but since I'm not even vaguely familiar with it, I can even design the API for now. Game utilities will be produced with these libs to demonstrate how versatile it is, and as an example on how to use the API. In a previous e-mail, I spoke of "emulating" video modes, an example of what I mean is let's say the game resolution uses Mode-X 360x240, the way it will be programmed on the Mac is a 360x240 window in the center of a full screen. Resolutions above 640x480 cannot be emulated unless the Mac supports them, I don't yet have a plan for this. </rambling> Phew! Excuse me while I catch my breath =B) -- See ya! Orlando Llanes

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 27 Aug '97

27 Aug '97

At 09:21 PM 8/26/97 +0200, Peter Gerwinski wrote: >According to Ken Linder: >> >> Well, using the -dY option, I received the same errors as before... > >But GPC must also copy the source to the standard error device. >How does that output look like? Does the error message go before >or after the first source line? > >Greetings, > > Peter YAO... (Yet Another Oddity) The -dY option does not copy the source to the standard error device. The only thing that is displayed on the screen are the errors I sent before with two minor exceptions: there is a blank line after the 'Invalid #line' line; and the line immediately after the blank line starts with a 'p'. That line now reads: p/tmp/cca00292.i:2: warning: missing program header I am just guessing but is it possible that the intermediate files are not being written to the /tmp directory? A few things I checked... permissions in that directory disk space (only 54% used as reported by 'df') tried compiling as 'root' with same results untarred GPC ver 2, works fine ( tried swapping versions several times) can compile just about everything with GCC checked GCC version (2.7.2.1) De-Installed/Re-Installed Linux tried gpc -da t1.pas - many empty files and same errors Things I havn't tried using a different kernel version recompiling GPC myself ( Company network is torn apart & Linux is not on-line ) pentium motherboard (may do that this week but don't think this will help) I plan on looking at it heavily today since tomorrow starts a VERY busy two weeks here at work. If I notice anything, I will post it. TNX for all the help! Ken Linder

2 1

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 27 Aug '97

27 Aug '97

According to Jan-Jaap van der Heijden: > On Wed, 27 Aug 1997, Ken Linder (KC7RAD) wrote: > > > > A few things I checked... > > [...] > > De-Installed/Re-Installed Linux =8-| > Could it be your libc is a a very old/very new one? > Peter -- did you upgrade anything on your machine lately? > > I know at least libc-5.4.x with x<20 are buggy; A binary compiled against > 5.4.x should (but isn't always) compatible to an older libc. I am using libc.so.5.4.7. So this could be the reason. > Try recompiling yourself. Hmm ... I think it's sufficient if he recompiles his GPC; besides, recompiling a human could cause even more unexpected problems. ;-) Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Dr E. Buxbaum 27 Aug '97

27 Aug '97

> From: Orlando Llanes <a010111t(a)bc.seflin.org> > To: GNU Pascal Mailing List <gpc(a)hut.fi> > Subject: Re: Pointer & GPC question... > Date sent: Tue, 26 Aug 1997 13:11:28 -0400 > Cool, so would the admin have to install it? Or could it be >installed by a > normal user? Another thing I'm curious of is does Linux use or support DPMI > in it's native state? Or does it have it's own proprietary memory scheme? DPMI (Dos Protected Mode Interface) is a technique to allow the Dos operating system (which is 16 bit) to run 32-Bit software. Linux is a true 32 bit OS (on a x86 PC, anyway) and therefore does not require DPMI or similar crutches. One thing less to take care off...

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 26 Aug '97

26 Aug '97

At 11:06 PM 8/25/97 +0200, Peter Gerwinski wrote: >Okay, next try: Please run `gpc -E t1.pas'. The result >should look like the following: > > # 1 "t1.pas" > program t1; > > begin > writeln('test'); > end. > >(* I.e., your program with `# 1 "t1.pas"' in front of it. *) Yes, indeed! This is what I received after using the -E option > >If you get this, run `gpc -dY t1.pas'. The result should be >almost the same: > > 1"t1.pas" > program t1; > > begin > writeln('test'); > end. > Well, using the -dY option, I received the same errors as before... Should I start crying yet????? ;-) Good luck & thanks! Ken L.

1 0

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Ken Linder: > > Well, using the -dY option, I received the same errors as before... But GPC must also copy the source to the standard error device. How does that output look like? Does the error message go before or after the first source line? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Orlando Llanes: > > I know I'm pushing the envelope with this series of e-mails, so if it's > off-topic, then reply by e-mail, we'll discuss it there, and I'll post a > summary to the list if desired. Since it's about developping a library for GNU Pascal, it's on-topic. Please go on - it's very interesting. :-) > Cool, so would the admin have to install it? Or could it be installed by a > normal user? The admin. > Another thing I'm curious of is does Linux use or support DPMI > in it's native state? Or does it have it's own proprietary memory scheme? It has its own memory scheme. Well, I wouldn't call it "proprietary" since everything in the Linux kernel is FREE. ;-) Memory in Linux is much easier than in DOS because it uses a flat model - just forget about segment addresses, selectors and such. For details use the kernel source - it is always with you ... > If anybody has a suggestion on something to add, any ideas, or would like > me to send them the game lib specs, feel free to e-mail me. Your plan looks very good; just a general remark: Be careful when porting things from DOS to Linux. Some of the most useful features of DOS, DPMI for example, are just a workaround for other things that are implemented in a much cleaner and easier way in Linux. :-) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Orlando Llanes 26 Aug '97

26 Aug '97

I know I'm pushing the envelope with this series of e-mails, so if it's off-topic, then reply by e-mail, we'll discuss it there, and I'll post a summary to the list if desired. Cool, so would the admin have to install it? Or could it be installed by a normal user? Another thing I'm curious of is does Linux use or support DPMI in it's native state? Or does it have it's own proprietary memory scheme? > From: Michael Meeks <michael(a)zeus.imaginator.com> > Because ... this would invalidate all the security measures. At > ... > is youre uncle ( perhaps ). oh, and make the program run suid to that For the time being, I'll create wrappers for SVGALib. I'm not just creating a graphics lib, I'm creating a cross platform game programming lib (yes I'm aware of SVGALib ported to the PC, but it's buggy). I'm looking at how things are done on different OS's so I don't take a wrong turn with my lib. For example, while I was planning the Mode-X support and working on VBE support, I realized that graphics on the Macintosh are different (I decided to "emulate" these modes on the Mac if possible). > I would just use SVGAlib myself, as it is supported, and supports > lots of hardware + there is llittle point in duplicating effort ! :) and > IIRC it supports off screen buffers etc. The architecture I'm using for the graphics portion of the game lib is similar in concept to a loadable device driver, but it will use objects: * A unit defines a base object and is used as a pointer to the other objects in the "generic" unit * Each object overrides the base API * Methods added are proprietary to the object, otherwise there is no need to extend the base object API further * According to certain mode ranges, a specific object is initialized (de-initializing the previous one if neccessary) and the object base pointer is set to that of the new object * An off-screen buffer is allocated by the object * Error codes are returned so the programmer can handle errors and so that the programmer knows where the objects failed (memory error, driver failure, etc) * The off-screen buffer is exposed so that the programmer can implement their own custom routines, special effects, 3-D routines, etc * First set of inherited objects will support VBE 256/32k/64k/16M color modes, VGA, 3 to 7 Mode-X resolutions (VBE LFB will be supported after the VBE engine is in place) * Expandable to support triple buffering (I haven't fully thought this out yet) * Custom mouse handlers (also not fully thought out yet) with support for monochrome or 256/hi/true color cursors If anybody has a suggestion on something to add, any ideas, or would like me to send them the game lib specs, feel free to e-mail me. My goals are to make the libs logical, tight coded, handling as much of the platform/OS specific details as possible (Device Context Handles in Windows for example), to make the lib Modular yet Integrated, to provide flexibility, to make it easily extensible, and to provide a "load on use" style so that only what's needed is loaded. See ya! Orlando Llanes

1 0

Re: Diff Utility for the PC...
by Peter Gerwinski 26 Aug '97

26 Aug '97

According to Orlando Llanes: > > Does anybody know of a non-cryptic Diff utility for the PC? What do you consider "non-cryptic"? And what do you mean with "PC"? On my PC I use GNU diff exclusively, on Linux or FreeBSD as well as on [Caldera|DR|Novell|MS]-DOS (DJGPP); probably an OS/2 port (EMX) also exists. GNU diff is very configurable. If you don't like its default output # diff gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] 1966c1971 < error ("integer constant does not fit in integer type"); --- > error ("value does not fit in longest integer type"); use either the `-c' option to get a "context diff": # diff -c gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] *** 1963,1969 **** else { /* should be effectively unreachable */ ! error ("integer constant does not fit in integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; --- 1968,1974 ---- else { /* should be effectively unreachable */ ! error ("value does not fit in longest integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; or the `-u' option to get a "unified diff" (my preferred format): # diff -u gpc-oldgcc/p/gpc-lex.c gpc-egcs/p/gpc-lex.c [...] @@ -1963,7 +1968,7 @@ else { /* should be effectively unreachable */ - error ("integer constant does not fit in integer type"); + error ("value does not fit in longest integer type"); type = integer_type_node; } TREE_TYPE (yylval.ttype) = type; or type `diff --help' to get all options listed. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Diff Utility for the PC...
by Orlando Llanes 26 Aug '97

26 Aug '97

Does anybody know of a non-cryptic Diff utility for the PC? -- See ya! Orlando Llanes

1 0

GNU Pascal questions
by Fausto Iannuzzi 25 Aug '97

25 Aug '97

Hi! I have read it's possible to call gcc functions from a gpc program or unit adding "C;" to functions' declaration. Is it also possible to call or use gpc functions, or generally gpc code, from a gcc program? Does gpc support operator overloading? Thanks. bye, Fausto. Reply addresses: fausty(a)itb.it (primary - local provider) fausty(a)peacelink.it (gateway - please no files here) Homepage: www.itb.it/users/fausty/welcome.html

1 0

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 25 Aug '97

25 Aug '97

According to Ken Linder: > > I tried it and this is what I got: > [...] > > /tmp/cca00301.i:1: numeric constant with no digits > [...] That's indeed funny - I don't see any problem here. Okay, next try: Please run `gpc -E t1.pas'. The result should look like the following: # 1 "t1.pas" program t1; begin writeln('test'); end. (* I.e., your program with `# 1 "t1.pas"' in front of it. *) If you get this, run `gpc -dY t1.pas'. The result should be almost the same: 1"t1.pas" program t1; begin writeln('test'); end. (* Actually, it should be the same, but that's a minor bug in gpc-lex.c. #*) Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Can't run gpc_970714 :-(
by Ken Linder (KC7RAD) 25 Aug '97

25 Aug '97

At 03:22 PM 8/25/97 +0200, Peter Gerwinski wrote: ...snip... > > gpc -v <other options> foo.pas -o foo > ^^ >and post the result here? > Hi Peter, I tried it and this is what I got: { the command: } [klinder@kenslinux klinder]$ gpc -v t1.pas -o t1 { the result } gpc version 970714(2.7.2.1) /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ t1.pas /tmp/cca00301.i GNU CPP version 970714(2.7.2.1) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i586-unknown-linux/include /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/include /usr/include End of search list. /usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/gpc1 /tmp/cca00301.i -quiet -dumpbase t1.pas -version -famtmpfile=t1.gpc -o /tmp/cca00301.s GNU Pascal version 970714(2.7.2.1) (i386 Linux/ELF) compiled by GNU C version 2.7.2.1 /tmp/cca00301.i:1: numeric constant with no digits /tmp/cca00301.i:1: numeric constant with no digits /tmp/cca00301.i:1: invalid #line /tmp/cca00301.i:2: warning: missing program header /tmp/cca00301.i: In function 'program_noname': /tmp/cca00301.i:2: parse error at null character { now the program } program t1; begin writeln('test'); end. {***************** whew *****************} I thought perhaps something was funny with my Linux setup so I freshly installed RedHat 4.1 on a i486. Exact same thing (except for the temp file name) So, same result on three different computers, all with RedHat 4.1 installation. A laptop, and two desk-tops. Ver 2 of GPC works great! I removed the 970714 files and untared version 2. It works great!!! Good Luck! If anything becomes obvious to me I will let you know! Thanks! Confused in Las Vegas... Ken L.

1 0

Re: gpc questions
by Peter Gerwinski 25 Aug '97

25 Aug '97

Hello! According to Fausto Iannuzzi: > I have read it's possible to call gcc functions from a gpc program or unit > adding ";C" to functions' declaration. Is it also possible to call or use > gpc functions, or generally gpc code, from a gcc program? Yes: To call the Pascal procedure Procedure foo ( Var Bar: Integer ); from a C program, use the header extern void Foo ( int *bar ); Note that the First Character Of The Pascal Procedure Is Capitalized. Compile the Pascal source as a Unit or Module to avoid a `main()' function to be generated from it. > Does gpc support operator overloading? Yes: Type Foo = <whatever>; Operator + ( x, y: Foo ) = z: Foo; begin (* Foo + Foo *) <calculate z out of x and y>; end (* Foo + Foo *); 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Can't run gpc_970714 :-(
by Peter Gerwinski 25 Aug '97

25 Aug '97

According to Ken Linder: > > I am not too sure if I am experiencing brain damage or what... Since I > downloaded the binary Linux GPC file gpc-970714_i586-linux.tar and unzipped > it, I have not been able to compile ANY pascal code.:-( > > OS: Linux 2.0.27 > GCC: 2.7.2.1 That sounds rather strange. As you can imagine, this very same compiler worked fine here. > What I get when I try to compile and pascal source... > /tmp/cca00363.i:1: numeric constant with no digits > /tmp/cca00363.i:1: numeric constant with no digits > /tmp/cca00363.i:1: invalid #line > etc... etc... etc... Looks like a problem with the preprocessor. Can you please retry with gpc -v <other options> foo.pas -o foo ^^ and post the result here? > This wouldn't be because I am using 486 hardware would it? I cannot imagine that. GCC and GPC don't have true Pentium optimization (yet;). AFAIK, the code is essentially optimized for the i486 with a few optimizations switched off that would reduce performance on a Pentium (not sure about that). Later, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pointer & GPC question...
by Frank Heckenbach 25 Aug '97

25 Aug '97

Orlando Llanes wrote: > How would I do low level access for memory with a normal user privilege? > Why can't I just define a pointer and write data to it? Ugh, Linux is a > good OS, but it can be a pain in the butox :P Of course you can do it this way for your (i.e. this process's) memory. Sorry if I didn't make this clear. You need root privileges to access all memory -- that's the point of memory protection in a good OS (because a normal program can't accidentally overwrite/crash other processes or the kernel). The other thing is (as far as I've understood it so far) that Linux uses paging, so the same pointer doesn't necessarily mean the same thing in two different processes (because the memory of these processes is paged differently). Therefore, there's the /dev/mem device to allow you (i.e. root) to access memory at absolute addresses. About the video memory, I don't know very much. I think the user who uses a certain console *should* have direct access to its video memory, but I don't know if this is so. (Either this or accessing the ports is the reason why svgalib programs need root privileges.) If this wasn't quite correct/complete, plase someone correct me.

1 0

Re: Variable conformant arrays, and the price of fish...
by Peter Gerwinski 25 Aug '97

25 Aug '97

Hello! According to Michael Meeks: > > PROCEDURE print_str (name: PACKED ARRAY [lo..hi: integer] OF Char) ; {a} > [...] > It compiles to object fine with the {b} labeled code in, but the > {a} labeled code causes a crash : This is a bug in gpc-2.0 or below which has vanished in recent beta versions. To get a GPC without that bug, download gpc-970714.tar.gz from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/. > Is this perhaps one section of the ISO 10206 spec. that isn't > implemented yet ? or am I doing something extremely daft :-) It's part of level 1 of ISO-7185 Standard Pascal. > TYPE > ulong = 0..16#FFFFFFFF ; Also, gpc-970714 can compils this. In addition, it has an extension type `Cardinal' or `Word' (two names) which has the same size as `Integer' but is unsigned. As another extension, you can write `Cardinal ( 32 )' to be sure to get an unsigned integer type of 32 bits width. (`Integer' may actually have 64 bits or whatever on some machines.) > Thanks in advance for any help, its a great project, keep up the > good work. Thank you as well for your interest. Yes, we'll try to keep it up. :-) If you want to contribute to the project, too: You seem to have some experience with Extended Pascal. When we will face 100% compliance to Extended Pascal in the future we will need some test programs urgently, and useful and/or entertaining example programs and documentation are very welcome, too. Hope this helps, Peter PS: What has all this to do with the price of fish? Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Pointer & GPC question...
by Orlando Llanes 22 Aug '97

22 Aug '97

How would I do low level access for memory with a normal user privilege? Why can't I just define a pointer and write data to it? Ugh, Linux is a good OS, but it can be a pain in the butox :P > From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> > It means a bit more. Root (and only root, AFAIK) can directly access all > ... > because today, most Linux systems are single-user machines, AFAIK... See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Frank Heckenbach 22 Aug '97

22 Aug '97

Orlando Llanes wrote: > Cool :) Do I have to write a driver or something? Or will libs suffice? Or > do I even need to worry about the user not being root? suid refers to the > program? Like Ring 1/2/3 in PMode on Intel for example? > > From: Peter Gerwinski <peter(a)agnes.dida.physik.NO-SPAM-PLEASE.de> > > Well ... you can use the `/dev/mem' device to directly access memory, > > ... > > but then the program needs to be "suid root" to be executed. > > (In fact this is how `svgalib' accesses video memory.) It means a bit more. Root (and only root, AFAIK) can directly access all memory and ports, but root also has unlimited access to everything: all files (i.e. can read/modify/delete any private files of any user), all processes (i.e. can kill any user's processes), all devices (i.e. can format harddisks and all these things). So if I were the administrator of a multi-user system, I wouldn't install any unknown setuid root program -- that's the disadvantage. I guess it's not taken too seriously (and therefore not done much about it) by the Linux developers, because today, most Linux systems are single-user machines, AFAIK... (BTW: suid only means that the program runs under the ID and with the privileges of a certain user (usually, a program has the ID of the user who started it). So, a suid guest program would get all the privileges of the guest account, which probably isn't very much. Almost the only interesting thing is suid root...) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Pointer & GPC question...
by Orlando Llanes 22 Aug '97

22 Aug '97

Cool :) Do I have to write a driver or something? Or will libs suffice? Or do I even need to worry about the user not being root? suid refers to the program? Like Ring 1/2/3 in PMode on Intel for example? > From: Peter Gerwinski <peter(a)agnes.dida.physik.NO-SPAM-PLEASE.de> > Well ... you can use the `/dev/mem' device to directly access memory, > ... > but then the program needs to be "suid root" to be executed. > (In fact this is how `svgalib' accesses video memory.) Cool, that's the way I want it :) > That's what the LGPL stands for, *and* it allowes to link the library > with non-free software. The ordinary GPL would stand for the same, too, Noted :) > It's a good example how to use existing GCC libraries from GPC. See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 22 Aug '97

22 Aug '97

According to Orlando Llanes: > According to myself (Peter Gerwinski): > > No way. > Bummer :( Well ... you can use the `/dev/mem' device to directly access memory, (* Linux lo-level file system access (here: memory access) *) Function mmap ( addr: Pointer; len: Word; prot, flags, fd, off: Integer ): Word; C; (* In fact it returns a pointer. But we convert it to Word. *) Function open ( filename: CString; Flags: Integer; ... ): Integer; C; Procedure InitTools; Var Dummy: Word; Function Allocate ( address, length: Word ): Pointer; Var segMem: Pointer; result: Word; begin (* Allocate *) segMem:= GetMem ( length + $FFF ); if Word ( segMem ) and $FFF <> 0 then inc ( Word ( segMem ), $1000 - Word ( segMem ) and $FFF ); if segMem = Nil then FatalError ( 'Linux drivers: cannot allocate video memory' ); result:= mmap ( segMem, length, $03, $11, MemoryHandle, address ); if Integer ( result ) <= 0 then FatalError ( 'Linux drivers: cannot mmap video memory' ); Allocate:= Pointer ( result ); end (* Allocate *); ... MemA0000:= Allocate ( $A0000, $10000 ); but then the program needs to be "suid root" to be executed. (In fact this is how `svgalib' accesses video memory.) > I plan to put it in the license where it's Copyrighted Freeware :) > Hopefully it's what the LGPL stands for. I will release the source code, > but I do want to retain the copyright, I won't charge for it's use tho. ^^(corrected) That's what the LGPL stands for, *and* it allowes to link the library with non-free software. The ordinary GPL would stand for the same, too, but would only allow to link the library with other free software. > I saw it, but nothing about memory access, It's a good example how to use existing GCC libraries from GPC. > besides, I don't see why > Borland's BGI should live on. For compatibility's sake. Nothing else. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Can't run gpc_970714 :-(
by Ken Linder 22 Aug '97

22 Aug '97

Hi All I am not too sure if I am experiencing brain damage or what... Since I downloaded the binary Linux GPC file gpc-970714_i586-linux.tar and unzipped it, I have not been able to compile ANY pascal code.:-( OS: Linux 2.0.27 GCC: 2.7.2.1 What I get when I try to compile and pascal source... /tmp/cca00363.i:1: numeric constant with no digits /tmp/cca00363.i:1: numeric constant with no digits /tmp/cca00363.i:1: invalid #line etc... etc... etc... This wouldn't be because I am using 486 hardware would it? Thanks for the assist! Ken L.

1 0

Re: Pointer & GPC question...
by Orlando Llanes 21 Aug '97

21 Aug '97

I plan on using them to fill gaps where OS specific stuff is concerned, File I/O, Network I/O, etc. > From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> > Use them with care! This way, you can only support some limited set of known > ... > use "sizeof(pointer)"... I know it doens't, but I don't like Borland's API. > (* BTW: BGI2GRX doesn't use Borland's inefficient BGI drivers and such, it > just provides the same (nearly) interface as Borland's Graph unit. *) See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Frank Heckenbach 20 Aug '97

20 Aug '97

Orlando Llanes wrote: > > (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) > > ... > > (*$endif *) (*$endif *) (*$endif *) > Thanks :) Use them with care! This way, you can only support some limited set of known platforms, but the GNU compiler is ported to more and more platforms... Whenever you can, you might want to use portable way of doing things. E.g. to distinguish whether a pointer has 32 or 64 bits (or more), you can use "sizeof(pointer)"... > > For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, > > also known as GPC's `Graph' Unit. > I saw it, but nothing about memory access, besides, I don't see why > Borland's BGI should live on. (* BTW: BGI2GRX doesn't use Borland's inefficient BGI drivers and such, it just provides the same (nearly) interface as Borland's Graph unit. *) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Correction...
by Orlando Llanes 19 Aug '97

19 Aug '97

Errr... I DO want to retain the Copyright. -- See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Orlando Llanes 19 Aug '97

19 Aug '97

Thanks :) > (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) > ... > (*$endif *) (*$endif *) (*$endif *) Bummer :( > No way. Will do. > For DJGPP, see the GPC FAQ and the DJGPP FAQ. The "best" way for direct It is, but for starters I want to do it high level, I don't know much about PMode yet. In fact, I may not even have to code in low level ASM, reason I say this is because I saw a Mode-X lib (XLib for GCC I think), and upon examining the source, I didn't see a single ASM statement in it. > memory access IMHO is to use assembler. You can use the following function > to convert a segment address to a selector: Noted :) > Function SegToSel ( Seg: ShortWord ) Sel: Word; > ... > end (* SegToSel *); That's the problem, I heard SVGALib is a bit slow. Besides, I don't plan on going Linux just yet, once I have a strong base in PMode/DOS I'll work on the Linux port. I may use SVGALib for short term tho. > For Linux, better don't access memory directly. Instead, use (S)VGALIB or > some other well-documented interface to graphics mode. I plan to put it in the license where it's Copyrighted Freeware :) Hopefully it's what the LGPL stands for. I will release the source code, but I don't want to retain the copyright, I won't charge for it's use tho. > Sounds good. Do you consider to put it under the GNU Library General > Public License? Heard of it, saw the demo Caveman, and didn't like it much. The sound lib won't run under '95, I don't know exactly where the problem is, but I want the lib to run efficiently under a Full Screen Windows '95 DOS Box without being prompted to run in MS-DOS mode. I'll take a look at it tho, maybe it can tip me off on how to set the address of a pointer :) My ultimate goal is to provide an API so that it truly is recompile source on each platform and compiler rather than re-edit to recompile. > For DJGPP, there is a game library called `Allegro' for GNU C. > ... > good starting point for you to write such a Unit to use `Allegro' I saw it, but nothing about memory access, besides, I don't see why Borland's BGI should live on. I plan to make my libs work in VGA, VESA, VBE2, and certain Mode-X configurations. > For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, > also known as GPC's `Graph' Unit. See ya! Orlando Llanes

1 0

Re: Pointer & GPC question...
by Peter Gerwinski 18 Aug '97

18 Aug '97

According to Orlando Llanes: > > Do you have access to these machines for beta-testing? Yup. > That reminds me, are > there definitions for the environment GPC is compiling for? For example: > [...] Yes: (*$ifdef __MSDOS__ *) (* The definitions are case-sensitive *) ... (*$else *) (*$ifdef __osf__ *) (* One operating system for the Alpha *) ... (*$else *) (*$ifdef __linux__ *) (* Another operating system for *) (*$ifdef __i386__ *) (* the Alpha - or for the i386+ *) ... (*$else *) (*$ifdef __alpha__ *) ... (*$endif *) (*$endif *) (*$endif *) (*$endif *) > How do I set a pointer to point to the VGA (for example) in a way that can > be ported to at least Linux? No way. For DJGPP, see the GPC FAQ and the DJGPP FAQ. The "best" way for direct memory access IMHO is to use assembler. You can use the following function to convert a segment address to a selector: Function SegToSel ( Seg: ShortWord ) Sel: Word; begin (* SegToSel *) asm ( 'int $0x31' : '=a' ( Sel ) : 'a' ( 2 ), 'b' ( Seg ) : '%eax', '%ebx', '%ecx', '%edx', '%esi', '%edi', '%ebp' ); end (* SegToSel *); For Linux, better don't access memory directly. Instead, use (S)VGALIB or some other well-documented interface to graphics mode. > I'm going to start work again on my game lib > (graphics part), and M13h would be a start :) Another thing is how do I > modify the contents referenced by the pointer? Writing a byte so it's > portable, writing a word so it's portable, etc. My ultimate goal is to port > this lib to PMode DOS, Mac, '95, Linux, X, and whatever other platform I > can get my grubby hands on, but I'll settle for PMode DOS for now :) Sounds good. Do you consider to put it under the GNU Library General Public License? For DJGPP, there is a game library called `Allegro' for GNU C. To use it with GNU Pascal, you only need to translate the C header files to a Unit with empty implementation part. I think, `Allegro' is under the GNU LGPL, so it is available in source code. Maybe it's a good starting point for you to write such a Unit to use `Allegro' with GPC? For an example what I mean, look at Sven's excellent `BGI2GRX' Unit, also known as GPC's `Graph' Unit. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Testing...
by Orlando Llanes 18 Aug '97

18 Aug '97

Please don't flame me for this, I wrote to this mailing list, and it somehow ended up in the wrong e-mail address. See ya! Orlando Llanes

1 0

Pointer & GPC question...
by Peter Gerwinski 18 Aug '97

18 Aug '97

According to Orlando Llanes: > > Ok, I know you guys are gonna shoot me for this, but here goes anyway... No. To become shot by myself, you must do more than this. ;-) > My question is about Pointers, what I want to know are 3 things.. > 1) What is the format of a pointer? Is it 3 bytes (selector--1 byte, > base address--2 bytes)? Or is it 4 bytes? On iX86-based machines, pointers have four bytes; all of them "offset" (that's what you probably mean with "base address"). GPC works in just one memory segment with a maximum length of 4GB, while 16-bit compilers usually work in many memory segments of 64kB each. On other machines, pointers are different; e.g. on the DEC Alpha, a pointer has eight bytes. > 2) If I performed pointer arithmetic that works under MS-DOS, will it > also work under Linux without modification? Yes. Provided you use GPC's pointer arithmetic as implemented in gpc-somewhere-in-may-or-so. Casts to `Word' and such are *not* portable. > 3) How do I create a generic pointer? Can I just use "Pointer"? reason > I ask is because I tried plain Pointer once, and it didn't work. It works now. :-) > Another question I have now while we're at it, is the latest version of GPC > posted on the FTP site? Or is it still in patched versions? I want to > upgrade, but I don't want to mess with patches unless I could upgrade from > 2.01 Where can I find the upgrade? >From 2.01? What's that? While the official version of GPC is still 2.0, the latest beta version that is available in binary form is gpc-970714, available via ftp at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/. Some patches to gpc-970714 already exist on Agnes, too, but they are no official new beta yet. Due to administrative problems :-(some paper war must be resolved first - sigh)-: I am retaining more recent sources, but some bug fixes have been posted to this list now and then ... 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Pointer & GPC question...
by Orlando Llanes 18 Aug '97

18 Aug '97

<grin> > No. To become shot by myself, you must do more than this. ;-) Do you have access to these machines for beta-testing? That reminds me, are there definitions for the environment GPC is compiling for? For example: {$ifdef DOS} DOS specific stuff {$endif} {$ifdef Alpha} Alpha specific stuff {$endif} etc. > On other machines, pointers are different; e.g. on the DEC Alpha, a > pointer has eight bytes. How do I set a pointer to point to the VGA (for example) in a way that can be ported to at least Linux? I'm going to start work again on my game lib (graphics part), and M13h would be a start :) Another thing is how do I modify the contents referenced by the pointer? Writing a byte so it's portable, writing a word so it's portable, etc. My ultimate goal is to port this lib to PMode DOS, Mac, '95, Linux, X, and whatever other platform I can get my grubby hands on, but I'll settle for PMode DOS for now :) > Yes. Provided you use GPC's pointer arithmetic as implemented in > gpc-somewhere-in-may-or-so. Casts to `Word' and such are *not* > portable. Cool :) > It works now. :-) Will check it out! > While the official version of GPC is still 2.0, the latest beta version > ... > patches to gpc-970714 already exist on Agnes, too, but they are no Gee, I wonder why I don't like politics, hmmm :P > official new beta yet. Due to administrative problems :-(some paper war > must be resolved first - sigh)-: I am retaining more recent sources, but > some bug fixes have been posted to this list now and then ... See ya! Orlando Llanes

1 0

Re: gcp on HP-UX 10.20, alpha-dec-osf3.2
by Peter Gerwinski 18 Aug '97

18 Aug '97

Hello! According to John Miller: > > I wrote earlier about problems with gpc making on solaris 2.5 (SunOS 5.5). > [...] > ./xgcc -B./ -DIN_GCC -g -I./include -DNO_MEM (wrapping) > -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c > [...] This looks as if you are compiling GPC in the same directory where the source is. Did you already try to use a different directory for the source and the objects? Both for GCC and GPC? This is known to fix many problems. Also, recent beta versions of GPC, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/, are known to cause less problems than gpc-2.0 when compiling them on UNIX machines. (And they are more stable anyway.;-) Hope this helps a little, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Pointer & GPC question...
by Orlando Llanes 18 Aug '97

18 Aug '97

Ok, I know you guys are gonna shoot me for this, but here goes anyway... My question is about Pointers, what I want to know are 3 things.. 1) What is the format of a pointer? Is it 3 bytes (selector--1 byte, base address--2 bytes)? Or is it 4 bytes? 2) If I performed pointer arithmetic that works under MS-DOS, will it also work under Linux without modification? 3) How do I create a generic pointer? Can I just use "Pointer"? reason I ask is because I tried plain Pointer once, and it didn't work. Another question I have now while we're at it, is the latest version of GPC posted on the FTP site? Or is it still in patched versions? I want to upgrade, but I don't want to mess with patches unless I could upgrade from 2.01 Where can I find the upgrade? Thanks in advance! -- See ya! Orlando Llanes

1 0

Re: Enviroment variables
by Achim Kalwa 14 Aug '97

14 Aug '97

Hello! According to Fred: > I'd like to use GPC for some simple CGIs I'm writing for my own server. > >To accomplish this I need to know how to: > >1) Read from various environment variables like $QUERY_STRING. >2) Read from Standard Input. > >Any and all help greatly appreciated. > Here's a litte demo program (i learn best with demo programs :-). It declares the "getenv" function itself and doesn't need any other unit. But there is a "bpcompat" unit for that and a lot of other useful things. {$x+} (* <- Enable extended syntax *) PROGRAM cgi1(Input, Output); TYPE tStr255 = String(255); FUNCTION GetEnv(Name : pChar):pChar; C; (* get access to the getenv funktion in c rtl *) VAR St : tStr255; BEGIN (* write some environment variables *) WriteLn(' TERM : ', GetEnv('TERM')); WriteLn(' SHELL: ', GetEnv('SHELL')); (* now echo all stdin *) WHILE NOT Eof(Input) DO BEGIN ReadLn(Input, St); WriteLn('>>', St); END; END. Hope this helps, Achim

1 0

Enviroment variables
by Fred 14 Aug '97

14 Aug '97

I'd like to use GPC for some simple CGIs I'm writing for my own server. To accomplish this I need to know how to: 1) Read from various environment variables like $QUERY_STRING. 2) Read from Standard Input. Any and all help greatly appreciated. Fred pismo(a)mclv.net

1 0

Typed file functions
by Peter Gerwinski 13 Aug '97

13 Aug '97

Hello, Miguel! Hello, everybody! (* Below are some words about ISO vs. Borland Pascal ... *) According to JoÃ£o Miguel Domingos: > > Thank you for your very useful help. I apolagize about my constant > questions but I feel like someone in the desert searching for water. No problem. One day, you will read another one's question on this list, know the answer, and "become water" yourself. :-) > This code was gaved by you and I think it is working properlly. After > assigning the file I'm doing : > > reset(f1); > while not eof(f1) do > begin > seekread(f1,n); (n is integer); > end; > > After the seekread I want to read one record to the variable r1 of type > tf1. What function do I use to do this. `read'. > I know that GPC contains a get > procedure but the only parametres that it accepts if the file variable. You can use `get' as well, see below. The following example program worked on my Linux box: Program Test (output, f1); type tf1 = record preco : integer; idade : integer; titulo : string[90]; end; f1file = file[1..1000] of tf1; var r1 : tf1; f1 : f1file; n : integer; Procedure FAssign ( Var t: f1file; Name: String ); Var b : bindingtype; begin unbind(t); b:=binding(t); b.name:=name; bind(t,b); b:=binding(t); end; begin FAssign (f1, 'test.dat'); rewrite(f1); for n:= 1 to 3 do begin r1.preco:= n; write (f1, r1); end (* for *); FAssign (f1, 'test.dat'); reset(f1); seekread(f1,2); get (f1); (* Read a value into the "file variable" `f1^' *) r1:= f1^; (* Assign the value of the file variable to `r1' *) writeln (r1.preco); (* Must be 2 *) end. Or, using `read' (compatible to Borland Pascal which does not support `get'): reset(f1); seekread(f1,2); read (f1, r1); (* Same as `get (f1); r1:= f1^'; *) writeln (r1.preco); (* Must be 2 *) Without the `(output, f1)' in the program's headline it does not work. :-( I consider this a bug in GPC; others might consider this a feature. Okay, ISO Pascal, as far as I have understood it, requires all files to appear in the program headline. While GPC partially supports this, I am sure that it does not yet comply to the requirements of the standard. OTOH, I consider this a bug anyway: I see no use for this, and - correct me if I am wrong - makes it a pain to write a large program (> 50000 lines) which reads and writes *many* files at *many* uncorrelated places. Thus, GPC's standard behaviour should be as follows: * Accept program headline parameters, but don't require them. * If program headline parameters are given, do all checks required by ISO. * If they are not given, allow to do everything with files which is allowed by UCSD and Borland Pascal. * With `--standard-pascal', `--extended-pascal', or whatever, these parameters are required. (Already the case.) I would be glad if somebody sent me test programs which show deficiencies in GPC's treatment of program headline parameters - both concerning ISO Pascal requirements and the treatment of files in UCSD/Borland Pascal. For example, GPC should work with the following (but doesn't): Program Test; (* Doesn't work without `F' parameter *) Var F: file of Integer; n: Integer; begin Assign ( F, 'test.dat' ); rewrite ( F ); for n:= 0 to 5 do write ( F, n ); close ( F ); reset ( F ); Seek ( F, 4 ); (* `Seek' unknown; must use `SeekRead' *) read ( F, n ); writeln ( n ); close ( f ); end. There are probably more, independent cases where GPC fails to compile valid UCSD/Borland Pascal. And a similar example can certainly be constructed for valid Extended Pascal rejected by GPC - or invalid Extended Pascal accepted by "gpc --extended-pascal". Please help to improve GPC by finding all these cases and posting test programs here! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Typed file functions
by João Miguel Domingos 13 Aug '97

13 Aug '97

Dear Peter G. Thank you for your very useful help. I apolagize about my constant questions but I feel like someone in the desert searching for water. All my actual problems are with accessing files. The description of my file is the following: type tf1 = record preco : integer; idade : integer; titulo : string[90]; end; var r1 : tf1; f1 : file[1..1000] of tf1; Now i'm using the following routine to assign a types file: Procedure FAssign ( Var somefile; Name: String ); Var t : bindable text absolute somefile; b : bindingtype; begin unbind(t); b:=binding(t); b.name:=name; bind(t,b); b:=binding(t); end; This code was gaved by you and I think it is working properlly. After assigning the file I'm doing : reset(f1); while not eof(f1) do begin seekread(f1,n); (n is integer); end; After the seekread I want to read one record to the variable r1 of type tf1. What function do I use to do this. I know that GPC contains a get procedure but the only parametres that it accepts if the file variable. Can you help me once more ? Please ! Best regards Joao Miguel Domingos

1 0

Resign me from the list
by Hans Petter Fasteng 12 Aug '97

12 Aug '97

Plase drop me from this list, if I have to do something my self, please tell me how, or where I find the FAQ for doing so. -hans

1 0

Re: Typed file functions ?
by Peter Gerwinski 12 Aug '97

12 Aug '97

Hello! (* I am in hurry ... just some short notes ... *) According to JoÃ£o Miguel Domingos: > [...] > I'm defining the record variable this way: > > r1 : tf1 > > and the file variable like this: > > f1 : file of tf1; > > Is this correct ??? Yes. Maybe it is necessary to write `file [ 1..1000 ] of tf1;'. > I want to assign, reset, read and seek the file to > read records in a sequencial way or just read one in position "x".I have > downloaded the Peter's G. system.pas unit that have the bin* functions, > but I don't know how to use them. These are not written by me, but by The African Chief, and they are designed to work with "untyped" files, AFAIK. For what you have in mind, use the `Assign' procedure from the `System' Unit. Maybe you need to replace the untyped `Var' parameter with `Var foo: tf1File' (with tf1File being `bindable file [ 1..1000 ] of tf1;') and so on. > Do you have any other functions to > work with this type of files ??? `SeekRead', `SeekWrite', `SeekUpdate'. > Please help me with this problem. My boss is geting very bored with me > !!! Good luck! (* I am back in ~2 hours ... *) 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Typed file functions ?
by João Miguel Domingos 12 Aug '97

12 Aug '97

Dear Sirs, I'm writing a program that needs to work with a file with a predefined record structure like this below: type tf1 = record preco : integer; idade : integer; titulo : string[90]; tema : string[48]; end; I'm defining the record variable this way: r1 : tf1 and the file variable like this: f1 : file of tf1; Is this correct ??? I want to assign, reset, read and seek the file to read records in a sequencial way or just read one in position "x".I have downloaded the Peter's G. system.pas unit that have the bin* functions, but I don't know how to use them. Do you have any other functions to work with this type of files ??? Please help me with this problem. My boss is geting very bored with me !!! Best regards Joao Domingos

1 0

GPC on HP-UX 10.20, alpha-dec-osf3.2, solaris 2.5
by Peter Gerwinski 11 Aug '97

11 Aug '97

According to John Miller: > > I wrote earlier about problems with gpc making on solaris 2.5 (SunOS 5.5). > > I'm wanting to run this same program on a DEC alpha, a Sun ULTRA, an > HP9000 K370, and some kind of IBM box. > > [...] Unfortunately, I have no experience with these machines, and I can't read off anything I understand from the error messages. :-( Maybe you can use one of the binaries we are providing at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/binary? Otherwise, I recommend to try again with a recent beta version of GPC. The compilation/installation method has changed violently - in part for solving such incomatibility problems. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

A More Serious GPC Bug
by Phil Robertson 11 Aug '97

11 Aug '97

Here's a more serious problem I've found while attempting to port a "legacy" application (250,000 LOC) to GNU Pascal: FILE: test1.pas UNIT Test1; INTERFACE TYPE eFlagDefs = (IDEInterface,DoubleDensity,HighDensity); sFlagDefs = SET OF eFlagDefs; FUNCTION GetFlagVal : eFlagDefs; IMPLEMENTATION END. FILE: test.pas PROGRAM Test; USES Test1; VAR Flags : sFlagDefs; BEGIN Flags := [IDEInterface,HighDensity]; IF IDEInterface IN Flags THEN WRITELN ('IDE Interface'); IF GetFlagVal IN [HighDensity,DoubleDensity] THEN WRITELN ('Dump Core'); END. test.pas: In function `program_Test': test.pas:9: type of set constructor element must be the set basetype test.pas:9: type of set constructor element must be the set basetype test.pas:9: aggregate value used where an integer was expected test.pas:10: invalid operands to binary `in' test.pas:10: condition must be of Boolean type gpc: Internal compiler error: program gpc1 got fatal signal 11 Problem seems to be related to performing operations on "set elements" when defined in an external UNIT. Note that the same functions appear to work when all defined in one unit. Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

Minor GPC Bug
by Phil Robertson 11 Aug '97

11 Aug '97

I found this problem with the current "beta" GPC: Code Segment ============ PROGRAM TEST; VAR CharSet : SET OF CHAR; BEGIN CharSet := [#192, #193, #194, #195]; END. Error Message During Compile ============================ test.pas: In function `program_Test': test.pas:6: type of set constructor element must be the set basetype The error goes away if new-line after #193 is removed: CharSet := [#192,#193,#194,#195]; Thanks; Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

_p_initfdr() not called in units
by Bill Currie 11 Aug '97

11 Aug '97

The attached files give a gpc runtime error of 701 (?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701)). Is this a bug or is there a way I can force _p_initfdr to be called? Bill -- Leave others their otherness. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: bar.pas Date: 11 Aug 1997, 17:29 Size: 303 bytes. Type: Program-source The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: foo.pas Date: 11 Aug 1997, 17:25 Size: 34 bytes. Type: Program-source

1 0

gcp on HP-UX 10.20, alpha-dec-osf3.2
by John Miller 11 Aug '97

11 Aug '97

Hi, it's me again. I wrote earlier about problems with gpc making on solaris 2.5 (SunOS 5.5). I'm wanting to run this same program on a DEC alpha, a Sun ULTRA, an HP9000 K370, and some kind of IBM box. on HP unix, I get: ./xgcc -B./ -DIN_GCC -g -I./include -DNO_MEM (wrapping) -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c In file included from ./enquire.c:390: include/stdio.h:279: unterminated `#if' conditional In file included from /usr/include/sys/newsig.h:43, from include/sys/signal.h:17, from /usr/include/signal.h:5, from ./enquire.c:402: an so on for include/machine/save_state.h:879 and include/sys/signal.h:459. *** Error exit code 1. on Digital Unix, I get: gcc -DGPC -DIN_GCC -g -O -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 -I../gcc-2.7.2.1/config -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alpha-dec-osf3.2/2.7.2.1/include\" -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/g++-include\" -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" -DCROSS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/alpha-dec-osf3.2/2.7.2.1/sys-include\" -DTOOL_INCLUDE_DIR=\"/usr/local/alpha-dec-osf3.2/include\" -c `echo ./gpc-cccp.c | sed 's,^\./,,'` In file included from /usr/local/lib/gcc-lib/alpha-dec-osf2.1/2.6.3/include/time.h:195, from gpc-cccp.c:104: /usr/include/sys/timers.h:188: parse error before `clock_id' /usr/include/sys/timers.h:189: parse error before `clock_id' /usr/include/sys/timers.h:195: parse error before `clock_id' /usr/include/sys/timers.h:214: parse error before `clock_id' *** Exit 1 Stop. Which is odd since it referred to the files in 2.6.3, which is the current gcc on the machine. (I don't have root access on this particular machine, so I'm just trying to get by with compiling but not installing 2.7.2.1. I may see if I can find an alpha where I can become root, and then retry. I know that the times.h file is problematic for many packages. also the file /usr/sys/include/sys/mount.h is owned by [161,100] on this system, all others in the directory are [bin,bin] or [root,bin] !! Anyway, I'd really appreciate help on any of these three platforms. At this time it's zero for three attempts and I have no pascal compiler. Thanks, John Miller

1 0

Re: Mathematical functions
by Peter Gerwinski 10 Aug '97

10 Aug '97

According to Brin: > I agree Forget about the p_sin func, but make anlias, ie #define p_sin(x) > sin(x) This doesn't change anything since the GPC-compiled program and the run time library communicate through the linker, and a `#define' alias is invisible for the linker. There is, however, a "linker alias" we could use to define the symbol `_p_sin' as an alias for `sin'. Something like "__asm__ (.foobar "_p_sin", "sin"). Somebody knows? Should we use it? BTW, Neal (or Brin? <confused>), you bumped against my News spam blocker. My real e-mail address is peter.gerwinski(a)uni-essen.de or peter(a)agnes.dida.physik.uni-essen.de. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Help building gpc under solaris 2.5!
by John Miller 10 Aug '97

10 Aug '97

Dear gcp experts, I am trying to get gpc up so that we can do some benchmarking of a 2400-line pascal program that we have - transportations modelling. More on that later perhaps. The system is a SPARCcenter 2000 running sparc-sun-solaris2.5. I seem to have successfully installed GCC 2.7.2.1. I can compile and run a simple C program with it. My make is GNU Make version 3.74. The results of the ./configure in the gcc-2,0 directory seem to be without error. I include only the summary here: ------------------------------------------------- Configuration summary: Building a native sparc-sun-solaris2.5 compiler GPC sources in: . GCC sources in: ../gcc-2.7.2.1 GCC object code in: ../gcc-2.7.2.1 GCC version: 2.7.2.1 Compiler for GPC: gcc Compiler for libgpc.a: gcc Compiler flags: -g -O Installation path: /usr/local/bin, (wrapping) /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1 ------------------------------------------------------ But, when I go to do the make for gpc, I get: gcc -DGPC -DIN_GCC -g -O -I. -I. -I../gcc-2.7.2.1 -I../gcc-2.7.2.1 (line wrapped) -I../gcc-2.7.2.1/config \ -DSTANDARD_STARTFILE_PREFIX=\"/usr/local/lib/\" \ -DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc-lib/\" \ -DDEFAULT_TARGET_VERSION=\"2.7.2.1\" \ -DDEFAULT_TARGET_MACHINE=\"sparc-sun-solaris2.5\" \ -DTOOLDIR_BASE_PREFIX=\"/usr/local/\" \ \ -c `echo ./gcc.c | sed 's,^\./,,'` gcc.c: In function `fatal': gcc.c:5209: `__builtin_va_alist' undeclared (first use this function) gcc.c:5209: (Each undeclared identifier is reported only once gcc.c:5209: for each function it appears in.) gcc.c: In function `error': gcc.c:5231: `__builtin_va_alist' undeclared (first use this function) make: *** [../gcc-2.7.2.1/gcc.o] Error 1 I'm sure that this is a common problem, but I haven't a clue. No refs to this in your mail-archive or FAQ. Via alta-vista, I've found others having this problem with other packages. What did I do wrong, or fail to read between the lines, or just fail to read!? Any help appreciated! Other tips may be needed once I get the compiler working. The source program is from delphi. Please (cc) directly reply to me - I have not subscribed to your list. Thanks, John Miller

1 0

Re: Incorrect version display
by Kevin A. Foss 09 Aug '97

09 Aug '97

On Sat, 9 Aug 1997 11:09:15 +0200 (MEST), Peter Gerwinski wrote: >According to Bernhard Tschirren: >> >> I have installed GPC-970714 for DJGPP. However, typing 'GPC -v' at the >> command prompt shows the following information: >> >> Reading specs from e:/djgpp/lib\specs >> gpc version 970624(2.7.2.1) >> >> WRONG VERSION! What happened? > >Probably my fault: I forgot to change this for DJGPP, too, before >I compiled gpc-970714. My current DJGPP source tree is correct here, >but I don't remember whether I fixed it in time or afterwards. ;-) For what it's worth, the 970714 EMX version shows: [C:\bin]gpc -v gpc version [unknown] on my system. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: GPC reference
by Peter Gerwinski 09 Aug '97

09 Aug '97

Hello! According to Fred: > > I'm new to GPC, but have done a bit of programming with Pascal over the > last 12 years with Turbo Pascal (3.x to 5.5) and VAX-Pascal on VMS. I'd > like to find something approximating a complete reference and would > greatly appreciate any help in this quest. The best approximation to a complete GPC reference is my current draft of such a thing. I am uploading it to ftp://agnes.dida.physik.uni-essen.de/home/peter/gpc-doc.tar.gz It is in Texinfo format that can be automatically translated to DVI (for printing), Info, HTML, and other formats. Any help completing this is most welcome. > I'm more interested in > reference VS instruction material at this time. What's that? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GPC reference
by Fred 09 Aug '97

09 Aug '97

I'm new to GPC, but have done a bit of programming with Pascal over the last 12 years with Turbo Pascal (3.x to 5.5) and VAX-Pascal on VMS. I'd like to find something approximating a complete reference and would greatly appreciate any help in this quest. I'm more interested in reference VS instruction material at this time. Fred pismo(a)mclv.net

1 0

Re: Objects Bug
by Peter Gerwinski 09 Aug '97

09 Aug '97

Hello, again! According to Bernhard Tschirren: > > After hours of frigging around with HUGE test programs, I accidentally > stumbled on a stupidly simple test program! Even better - it crashes the > compiler! I only hope that you can reproduce the bug. I just fixed it. :-) The problem was that methods get an implicit `Var' parameter called `Self', so they need a pointer to the object be defined. Some centuries ago, I told GPC to define `ptr_to_Myobject = ^MyObject' implicitly (with the first casing being as written, i.e. inaccessible for the user program), so this did work in a program. What I had forgotten was to *export* `ptr_to_Myobject' if this was done in a Unit or Module. Diff follows. A new GPC beta will follow soon. (Some things in the run time library have to stabilize first.) For the impatient: I am uploading the current "state of the art" as a sequence of gzipped diffs to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ (without further comment). Thanks for the nice test program, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- --- ../../gpc-970806/p/util.c Wed Aug 6 14:47:15 1997 +++ util.c Sat Aug 9 13:39:50 1997 @@ -1526,8 +1526,7 @@ void check_object_pointer () { - tree p, ptr = NULL_TREE, d, ptr_name_node; - char ptr_name [256]; + tree p, ptr = NULL_TREE; /* In most practical cases the user program will have * explicitely specified a pointer type pointing to the @@ -1549,6 +1548,9 @@ */ if (!ptr && current_type_name) { + tree d, ptr_name_node; + char *ptr_name = xmalloc (IDENTIFIER_LENGTH (current_type_name) + + strlen ("ptr_to_") + 8); sprintf (ptr_name, "ptr_to_%s", IDENTIFIER_POINTER (current_type_name)); ptr = build_pascal_pointer_type (current_type_name); ptr_name_node = get_identifier (ptr_name); @@ -1558,6 +1560,9 @@ finish_decl (d, NULL_TREE, NULL_TREE); current_type_list = chainon (current_type_list, build_tree_list (NULL_TREE, ptr_name_node )); + if (this_is_an_interface_module) + handle_autoexport (ptr_name_node); + free (ptr_name); } }

1 0

Mathematical functions
by Peter Gerwinski 09 Aug '97

09 Aug '97

Hello! The GPC run time library contains a function `_p_sin' which does nothing else than to call the `sin' function from the C library. As a try, I told GPC to forget about `_p_sin' and to call `sin' directly. Here are the results for a test program (compiled with -O3 on Linux): Calling `_p_sin': 9.93user 0.01system 0:10.11elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (72major+14minor)pagefaults 0swaps Calling `sin' directly: 9.11user 0.01system 0:09.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (72major+14minor)pagefaults 0swaps This means a gain of speed of about 9%. If there is no special reason for having an extra `_p_sin' I would vote for dropping it in favour of calling `sin' directly, and similar for other mathematical functions. Comments? Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

3 2

-g Works
by Bernhard Tschirren 09 Aug '97

09 Aug '97

Compiling with '-g' seems to work. I dont usually compile with this option, so I cant be sure. However, the last couple of programs compiled OK with '-g'. Great Work! Au Revoir ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

2 1

Re: Mathematical functions
by Peter Gerwinski 09 Aug '97

09 Aug '97

According to Jan-Jaap van der Heijden: > > `sin()' is not doing any checking, so you could replace it > right away. But there are other functions that do some checking before > calling the underlying OS function (like `ln') > > GCC knows an optimzation switch -ffast-math, [...] What about this: For gpc-2.1: Drop `sin()' (without any alias) and other non-checking functions, but keep the `_p_foo()' variants for functions that *do* some checking. For gpc-2.2: Drop the `_p_foo()' versions of all mathematical functions but those not supported by the OS (read: by `libc.a') and do the checking inline. Make `--fast-math' turn out the checking. (Things like this can be faced together with range checking in general.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Objects Bug
by Peter Gerwinski 09 Aug '97

09 Aug '97

Hallo, Bernhard! Hello, everybody! I have found a workaround: According to Bernhard Tschirren: > Type PGlobalObject = ^tGlobalObject; > TGlobalObject = Object > Constructor Init; > Procedure Method1; Virtual; > Procedure Method2; Virtual; > Procedure Method3; Virtual; > End; It seems that GPC has problems with the implicit `Self' parameter of methods if there is no explicit pointer declared for the object. Later, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: {$L} Good - but not good enough!
by Peter Gerwinski 09 Aug '97

09 Aug '97

According to Bernhard Tschirren: > {$L filename} does not work with library files. For example {$L libgrx.a} > does not work because GPC tries to link 'libgrx.o' !? Ups - sorry, I should not produce such trivial errors. (-# Probably I was tired when I wrote that.) 8< -------------------------------------------------------------------------- --- gpc-970806/p/gpc-lex.c Wed Jun 25 01:56:57 1997 +++ gpc/p/gpc-lex.c Sat Aug 9 10:52:26 1997 @@ -232,7 +232,7 @@ while (p > filename && *p != '.') p--; if (*p == '.' - && (p[1] != 'o' || p[1] != 'a' || p[2] != 0)) + && ((p[1] != 'o' && p[1] != 'a') || p[2] != 0)) { /* Extension given, but not a linker input file. * Recompile it with --automake, if necessary. 8< -------------------------------------------------------------------------- One problem remains with this: GPC does not search the `-L' directories, but only checks the current one. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Size Of Objects - Revisited
by Peter Gerwinski 09 Aug '97

09 Aug '97

According to Bernhard Tschirren: > You cannot use SizeOf with an object TYPE. See test program below: > [...] Now you can. :-) Diff below. > Sayonara Do swidanya, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- --- ../../gpc-970806/p/parse.y Wed Aug 6 14:47:15 1997 +++ parse.y Sat Aug 9 11:30:51 1997 @@ -5238,14 +5240,30 @@ && DECL_BIT_FIELD (TREE_OPERAND ($3, 1))) error ("`SizeOf' applied to a packed record field"); + /* Now $3 is either a variable access or a type declaration. + * In both cases, TREE_TYPE ($3) carries the actual type. + */ if (PASCAL_TYPE_OBJECT (TREE_TYPE ($3))) { /* Read the size of the object at run time from the VMT. */ - tree vmt = build_component_ref ($3, - get_identifier ("vmt")); - $$ = build_component_ref (build_indirect_ref (vmt, - "`SizeOf'"), + tree vmt; + if (TREE_CODE ($3) == TYPE_DECL) + { + char *name = concat ("", "vmt_", IDENTIFIER_POINTER ( + TYPE_LANG_NAME (TREE_TYPE ($3)))); + vmt = lookup_name (get_identifier (name)); + if (! vmt) + abort (); + free (name); + } + else + { + vmt = build_component_ref ($3, + get_identifier ("vmt")); + vmt = build_indirect_ref (vmt, "`SizeOf'"); + } + $$ = build_component_ref (vmt, get_identifier ("object_size")); } else

1 0

Re: Objects Bug
by Peter Gerwinski 09 Aug '97

09 Aug '97

According to Bernhard Tschirren: > > After hours of frigging around with HUGE test programs, I accidentally > stumbled on a stupidly simple test program! Even better - it crashes the > compiler! I only hope that you can reproduce the bug. I can. :-) Okay, let's try to fix it ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Incorrect version display
by Peter Gerwinski 09 Aug '97

09 Aug '97

According to Bernhard Tschirren: > > I have installed GPC-970714 for DJGPP. However, typing 'GPC -v' at the > command prompt shows the following information: > > Reading specs from e:/djgpp/lib\specs > gpc version 970624(2.7.2.1) > > WRONG VERSION! What happened? Probably my fault: I forgot to change this for DJGPP, too, before I compiled gpc-970714. My current DJGPP source tree is correct here, but I don't remember whether I fixed it in time or afterwards. ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Incorrect version display
by Bernhard Tschirren 09 Aug '97

09 Aug '97

I have installed GPC-970714 for DJGPP. However, typing 'GPC -v' at the command prompt shows the following information: Reading specs from e:/djgpp/lib\specs gpc version 970624(2.7.2.1) WRONG VERSION! What happened? Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

{$L} Good - but not good enough!
by Bernhard Tschirren 09 Aug '97

09 Aug '97

{$L filename} does not work with library files. For example {$L libgrx.a} does not work because GPC tries to link 'libgrx.o' !? Tschuess ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Size Of Objects - Revisited
by Bernhard Tschirren 09 Aug '97

09 Aug '97

You cannot use SizeOf with an object TYPE. See test program below: Type TObj = Object Constructor Init; End; Constructor TObj.Init; Begin End; Var O : TObj; Begin O.Init; WriteLn(SizeOf(O)); { This Works (Only after Init) } WriteLn(SizeOf(TObj)); { This calls Abort! } End. Sayonara ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Objects Bug
by Bernhard Tschirren 09 Aug '97

09 Aug '97

After hours of frigging around with HUGE test programs, I accidentally stumbled on a stupidly simple test program! Even better - it crashes the compiler! I only hope that you can reproduce the bug. I am using GPC-970714 for DJGPP in a Win95 shell. The following command line was used to create the files in OBJBUG.ZIP: redir -e error.out gpc -c bug01.pas --automake Bye ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: curses suggestions wanted
by Ken Linder (KC7RAD) 07 Aug '97

07 Aug '97

At 02:19 PM 8/7/97 +0200, Frank Heckenbach wrote: > >Peter Gerwinski wrote: > >> In such situations, where the procedure/function does not change the >> parameter, you can declare it with a `PChar' parameter. GPC knows what >> to do if the user passes a String schema and implicitly passes the address >> of the string data instead of the address of the schema. > >But it doesn't add a #0 terminator, so the result may be wrong, as in the >following program: > >program x; >{$x+} > >procedure p(x:pchar); >begin > writeln(x) >end; > >var x:string(10)='abc'; >begin > x:='x'; > p(x) >end. > If I use the built in conversion this would be a problem, but I plan on converting string to cstring using a little strings unit I wrote just for this purpose. Ncurses expects a real zero terminated string. You can get around that by coding `x := x + chr(0)' in Frank's example above but I want the ncurses usage to be seemless (more or less) with as little calling overhead as possible. No problems with that, now that I know how to use AsmName. I will adopt the `foo' and 'cfoo' (where foo is pascal and cfoo is C) convention. Thanks for the comments! Ken L.

1 0

Re: curses suggestions wanted
by Frank Heckenbach 07 Aug '97

07 Aug '97

Peter Gerwinski wrote: > In such situations, where the procedure/function does not change the > parameter, you can declare it with a `PChar' parameter. GPC knows what > to do if the user passes a String schema and implicitly passes the address > of the string data instead of the address of the schema. But it doesn't add a #0 terminator, so the result may be wrong, as in the following program: program x; {$x+} procedure p(x:pchar); begin writeln(x) end; var x:string(10)='abc'; begin x:='x'; p(x) end.

1 0

Re: curses suggestions wanted
by Peter Gerwinski 07 Aug '97

07 Aug '97

According to Ken Linder: > > I have come across a problem (bug? feature?) trying to pass a string schema > parameter to a procedure with a parameter defined as a __cstring__. Please > note that I am still using ver 2.0 so if this is fixed in the newer version, > let me know. Here is the problem: It is fixed. Also the problem which occured with `foofoo' in a Unit. Since there are more bugs with `CString' in gpc-2.0, I suggest you to upgrade to gpc-970714. > [...] The way I understand linking to a C rtn like: > function cfoo(SomeNum : integer) : integer; C; > requires that I link a C library that contains a function called `cfoo'. Function CFoo ( SomeNum: Integer ): Integer; AsmName 'foo'; together with the Pascal version Function Foo ( SomeNum: Integer ): Integer; (* yields 'Foo' *) solves the problem. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: curses suggestions wanted
by Ken Linder 07 Aug '97

07 Aug '97

Hi all, I have come across a problem (bug? feature?) trying to pass a string schema parameter to a procedure with a parameter defined as a __cstring__. Please note that I am still using ver 2.0 so if this is fixed in the newer version, let me know. Here is the problem: This program works: 8<-------------------------------------------------- program works1; (* GPC 2.0 *) procedure foo(abar : __cstring__); begin (* dummy proc *) end; var blab : string (200); begin blab := 'Test Me'; foo(blab); end. 8<-------------------------------------------- However, the following program does not. I get the following error when trying to compile: dwork1.pas: In function 'program_Dwork1': dwork1.pas:16:incompatible type for argument 1 of 'Foo' 8<--------------------------------------------- program dwork1; (* GPC 2.0 *) type aCString = __cstring__; procedure foo(abar : aCString); begin (* dummy proc *) end; var blab : string (200); begin blab := 'Test Me'; foo(blab); end. 8<------------------------------------------ Also, if I define a proc in a unit like: procedure foofoo(acstr : __cstring__); and call it from a different program like: foofoo(SomeStrSchema); I get the same error as above DWORK1.PAS program. ******************************************************* Regarding the Pascal -vs- C calling, I like your suggestion, Peter. I would much rather have the string variant be the default but provive the bare ncurses calls just in case. However, the naming may need to be like: pfoo() and cfoo(). The way I understand linking to a C rtn like: function cfoo(SomeNum : integer) : integer; C; requires that I link a C library that contains a function called `cfoo'. If I could specify a different C fcn name to link to ( I think this was discussed before) I could call the procedures almost anything! Thanks much!!! Ken L.

1 0

Re: HI !
by Peter Gerwinski 06 Aug '97

06 Aug '97

> Hello ! Hello as well! > First, I want to thank you for this AWEsome Pascal compiler, > I love it ! Good. That's a good reason for us to go on! :-) > I have made a little program to play WAV file on SB16.Can I send it > to you ? , if yes , where ? You can upload it to ftp://agnes.dida.physik.uni-essen.de/incoming. As far as I understand "on SB16.Can" this program is specialized to the DJGPP platform with a SB16-compatible sound card, correct? What are your licensing terms? GNU GPL/LGPL (recommended)? If you have a README for your program, we could place it next to it. > For instance I use GPC with rhide, when the new IDE is available ? You mean: a new version of RHIDE? I don't know. Ask Robert Hoehne at the DJGPP newsgroup, news://comp.os.msdos.djgpp. I am sending this e-mail twice: One to yourself and one to the GPC mailing list. Since the list is maintained manually, it is probable that you are not yet subscribed to it, but this will happen soon. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

HI !
by cagliostro 06 Aug '97

06 Aug '97

Hello ! First, I want to thank you for this AWEsome Pascal compiler, I love it ! secondly, I want to subscribe to the mailing list I have made a little program to play WAV file on SB16.Can I send it to you ? , if yes , where ? For instance I use GPC with rhide, when the new IDE is available ? I know your time is precious, so I can be eager. Thanks again and bye Patrice BOUCHAND

1 0

Re: curses suggestions wanted
by Peter Gerwinski 06 Aug '97

06 Aug '97

According to Ken Linder: > > While working on a curses (ncurses) interface I have come upon a situation > whereby I need some directions from potential GPC ncurses users. Certain > ncurses functions require a PCHAR pointing to a string for the function to > use. Would you, the potential users, rather pass a string schema instead? Yes, but this is no real problem (see below). > Personaly I would like an ncurses lib where I only pass strings when I can. > > Any ideas or suggestions? > > I could also allow either type of call... > > C style: > addstr(PChar); > > GPC style > gaddstr(String); In such situations, where the procedure/function does not change the parameter, you can declare it with a `PChar' parameter. GPC knows what to do if the user passes a String schema and implicitly passes the address of the string data instead of the address of the schema. OTOH if the String is in fact a `Var' parameter (I don't know if such functions exist in [n]curses), you must decide whether this shall be a `PChar' or a String schema. In such cases I would prefer to have the `String' variant as the default and the `PChar' variant as an extensions, i.e. C style: Procedure cfoo ( Var S: pChar ); GPC style: Procedure foo ( Var S: String ); (* NB: You needn't specify the length of the string in `Var' parameters, but you must do so for the return value of a function. *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Some patches
by Peter Gerwinski 06 Aug '97

06 Aug '97

Hello, everybody! I uploaded four patches from gpc-970714 to the "current state of the art", gpc-970806, to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta. A detailed list of changes will follow with the next beta release. While there are only minor changes (bug fixes) to GPC, I started to make up the documentation crucially; comments are welcome. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

curses suggestions wanted
by Ken Linder (KC7RAD) 06 Aug '97

06 Aug '97

Hi all, While working on a curses (ncurses) interface I have come upon a situation whereby I need some directions from potential GPC ncurses users. Certain ncurses functions require a PCHAR pointing to a string for the function to use. Would you, the potential users, rather pass a string schema instead? Personaly I would like an ncurses lib where I only pass strings when I can. Any ideas or suggestions? I could also allow either type of call... C style: addstr(PChar); GPC style gaddstr(String); Later... Ken L.

1 0

attribute(section(".ltext)) segfault
by Bill Currie 06 Aug '97

06 Aug '97

:) Why's it always me that finds the seg-faults? :) The test on line 534 of gpc-common.c segfaults due to `args' (?) not being what's expected. I had a look at the attribute handling in parse.y, but couldn't figure it out myself, so I've attached an offending file. Also, how the heck do I get attribute() to work with variables? I keep getting parse errors or other wierdnesses. Bill -- Leave others their otherness. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: foo.pas Date: 6 Aug 1997, 17:20 Size: 111 bytes. Type: Program-source

1 0

bison and flex with GPC
by Peter Gerwinski 05 Aug '97

05 Aug '97

According to Tom Dye: > > Please excuse a newbie request for help. I'm interested in using a lexer > prepared with flex in a GPC program. I gather from the documentation that > this is possible, but I'm not enough of a C programmer to figure out how > it might be done. This is a special case of the question "How to use a function written in C from a GPC program?", correct? This is answered in the GPC FAQ: 8< ---- begin (* from the GPC FAQ *) ----------------------------------------- [15]How do I use <insert_your_function_here> from the C library? GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. `man(3) sleep' reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include <unistd.h> unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; var result : word; begin result := sleep(10); end. ---------------------------------------------------------- 8< ---- end (* from the GPC FAQ *) ------------------------------------------- Remark: Recent beta versions of GPC (available at ftp://agnes.dida.physik.uni-essen.de/~gnu-pascal/beta/) don't need `word = __unsigned__ integer' any more; they have `word' built in. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

bison and flex with GPC
by Tom Dye 05 Aug '97

05 Aug '97

Hello, Please excuse a newbie request for help. I'm interested in using a lexer prepared with flex in a GPC program. I gather from the documentation that this is possible, but I'm not enough of a C programmer to figure out how it might be done. Has anyone had experience with this? Can someone provide me with an example of how it might be done? Many thanks in advance. 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: gpi-hash.c segfaults
by Peter Gerwinski 04 Aug '97

04 Aug '97

According to Bill Currie: > On 31 Jul 97 at 15:08, Jukka Virtanen wrote: > > I suggest that this problem is fixed by casting > > the result of the pointer subtraction to > > (unsigned ptrdiff_t) which is always large enough, > > something like: > > One slight problem: I couldn't find a `ptrdiff_t' in djgpp. However, > it could always be created. Not a slight, but a big problem: (i) See `../cccp.c', line 51; (ii) `ptrdiff_t', even if it exists, is a signed type, and GCC doesn't accept `unsigned ptrdiff_t'. :-( To work around, what about the following? It only must produce a more-or-less unique number ... /* We must avoid negative values. Naturally, we would cast this to * `unsigned ptrdiff_t', but since we cannot be sure that the platform * we compile GPC on will support this, we use `abs' instead. */ #define HASH_FUNC(NODE) ((abs ((NODE) - (tree) 0) >> 2) % MAX_HASH_TABLE) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Pending bugs?
by Peter Gerwinski 04 Aug '97

04 Aug '97

Hi! I have only one thing to fix up before the next beta: The run-time system must learn how to read/write `LongInt's and such. `write[ln]' already works. (Thanks, Frank!) Anything else? Bernhard, did you succeed to reproduce that OOP-related bug? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GetFile builtin function
by Peter Gerwinski 04 Aug '97

04 Aug '97

Hi, Bill! Hi, everybody! According to Bill Currie: > > Isn't. That is: the function is provided in rts-file.c (_p_getfile), > but it's not supported by the compiler. You can write `Function GetFile: Pointer; AsmName `_p_getfile';' into your program and just use it, but I see, you want more than this. :-) > How do I go about adding > this (or others) function? I'ld rather get instructions on how to do > it myself rather than a patch (though I can study the patch) so I can > learn how do to it to add more functions later on (such as Lo, Hi > etc). That would be great! Here is a recipe how to introduce a new built-in function into GPC. If it looks like French for you, feel free to ask me - I can speak French (more or less). * Edit `util.c', go into the `KItable[]' and add this identifier with the appropriate flags (`GNU_PASCAL' since it is not part of any other standard). (Perhaps after `DefineSize' is a nice place?) (First Letter Capitalized.) * Edit `parse.y' and add `gpc_GETFILE' (my suggested name for it) to the list of tokens (= constant definitions), perhaps after `p_DEFINESIZE'. * In `parse.y', look how something similar is implemented (e.g., again, `p_DEFINESIZE') and do it similarly. This means: - Give it a return type: "%type <ttype> gpc_GETFILE". - Add it to `new_identifier_1', so the name remains redefinable. - Add it to `rts_fun_onepar', so the parser will take it into account. In case you are not familiar with Bison (I was not when I found GPC): This language essentially is a machine-readable form of syntax diagrams. The `bison' program translates this into a C file not intened to be read by humans. The C stuff indented with two tabs is the "action" to be taken if the pascal parser reads this syntax. * Again in `util.c', function `build_rts_call', write a handler for `gpc_GETFILE'. This is where the real work is done; all the above is administrative stuff. But in this case, it's quite simple: Do the same as `case p_DEFINESIZE' does, i.e. warn about ISO violation, check for errors (hmm ... these functions don't count their arguments ... looks like a bug in GPC ... we should check it ...), and pass the argument to the other parts of `build_rts_call' which will do the work. * Don't forget to follow the GNU coding style guidelines. * Don't forget to send me a patch, so I can study it. ;-) * What about doing the same for `ParamCount' and `ParamStr'? The RTL functions do *almost* the same as their BP equivalents do. Perhaps we should make them truly compatible and built-in? (One problem: `ParamStr' must return a String of unknown length. Where to allocate it?) Welcome to the GNU Pascal development team! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GetFile builtin function
by Bill Currie 03 Aug '97

03 Aug '97

Isn't. That is: the function is provided in rts-file.c (_p_getfile), but it's not supported by the compiler. How do I go about adding this (or others) function? I'ld rather get instructions on how to do it myself rather than a patch (though I can study the patch) so I can learn how do to it to add more functions later on (such as Lo, Hi etc). TIA Bill -- Leave others their otherness.

1 0

VB: EFLIB
by Johan Larsson 01 Aug '97

01 Aug '97

Hi, I have written a program for Borland Pascal. I am currently looking for porters for the GNU Pascal environment. It will be released under a modified GNU Library GPL license. Check EFLIB at http://www.ts.umu.se/EFLIB/. Best Regards, Johan Larsson jola(a)ts.umu.se Also, REMEMBER to check out http://www.ts.umu.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

Re: pointer-compatibile integers
by Peter Gerwinski 01 Aug '97

01 Aug '97

According to Frank Heckenbach: > > Can there be any problems with signedness, or is it guaranteed that > ptrdiff_t is always signed and of the same size as a pointer? (I should > think so, but after all I've heard in the last time about such things, > I'm getting very careful...) If this is portable, there's no need to > predefine this type. Of course, this is *not* guaranteed. > What about size_t? > [...] > So perhaps only one more integer type (for now)... :-) GNU C has two special types here: SIZE_TYPE and PTR_DIFF_TYPE. Both are machine-dependent. To be compatible, maybe we must provide both? Following the notations for required identifiers in the Extended Pascal standard, we should not use underscores for predefined types. So what about `SizeType' and `PtrDiffType'? Since both are *not* guaranteed to have the same size as a pointer, the other thing, `Ptr[Int|Card|Word]', would be useful, too. This means five more integer types. More suggestions? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: pointer-compatibile integers (was: gpi-hash.c segfaults)
by Frank Heckenbach 01 Aug '97

01 Aug '97

Peter Gerwinski wrote: > According to Frank Heckenbach: > > > > While we're at it: would it be possible to have predefined Pascal types > > as size_t and ptrdiff_t (and maybe other types?) so that such > > calculations can be done in Pascal? > > Not enough integer types yet? ;-) :-) (But, fortunately, they're not really new types, just the same types with different names...) > This can be be implemented with > > Type > PtrInt = Integer ( BitSizeOf ( Pointer ) ); > > Is this sufficient? Can there be any problems with signedness, or is it guaranteed that ptrdiff_t is always signed and of the same size as a pointer? (I should think so, but after all I've heard in the last time about such things, I'm getting very careful...) If this is portable, there's no need to predefine this type. What about size_t? In BP, I've always used "Word" for memory sizes, and at least for DJGPP and Linux, this would work in gpc, too. But also on other machines (Alpha)? If not, I don't see a way to define size_t in Pascal, so it might have to be predefined... So perhaps only one more integer type (for now)... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: gpi-hash.c segfaults
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > I'VE FIXED IT!! The problem was caused by a negative index into the > hash table. Congratulations and thank you! > To fix it change the line (gci-hash.c:122): > > (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) > > to: > > (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) Since pointers and `long' integers don't have the same size on some sytems (I know it for the Alpha), I think this should be changed to something like `(unsigned size_t)'. > [...] > Well, anyway, maybe now this bug can be laid to rest... I hope so, too. Having this, it's realistic to have the next beta release within the next days ... Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

3 2

pointer-compatibile integers (was: gpi-hash.c segfaults)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Frank Heckenbach: > > While we're at it: would it be possible to have predefined Pascal types > as size_t and ptrdiff_t (and maybe other types?) so that such > calculations can be done in Pascal? Not enough integer types yet? ;-) This can be be implemented with Type PtrInt = Integer ( BitSizeOf ( Pointer ) ); Is this sufficient? Since GPC fully supports pointer arithmetics, I don't see too much applications for this. If not ... what about `PtrInt', `PtrCard', and `PtrWord'? Greetings, Peter (* For those who have not followed the recent discussion about integer types in GPC, here is some background: Besides `Integer' (signed), GPC supports `Cardinal' (unsigned) and `Word' (don't care about signedness, in fact unsigned). These types exist in several sizes which guarantee compatibility to GNU C and introduce some portability to other Pascal compilers: GNU Pascal GNU C ByteInt signed char ShortInt short int Integer int MedInt long int LongInt long long int There are also `*Card' and `*Word' versions of these, yielding a total of fifteen basic integer types. Besides this, GPC supports a synonym `LongestInt' for `LongInt' which guarantees the longest possible integer type (for the case that GNU C introduces `long long long int' which we would implement as `LongLongInt'); same with `LongestCard' and `LongestWord'. Eighteen. Compatibility to Borland Pascal and Delphi requires `Comp' (same as `LongInt' and `SmallInt' (same as `ShortInt' in GPC). Twenty. Okay? Good. Now it *really* begins. Like all Pascal compilers, GPC supports subranges like `1..42'. This adds 2 * sqr ( 2 pow 64 ) more possible integer types to our zoo. The `2' comes from signed and unsigned variants ... let's speak of "20 + two classes" of integer types. As an extension, GPC allows these subranges to be `packed' (i.e. allocate only one byte for `packed 1..42'; the default of allocating four bytes results in faster code) which leaves us with 20 + four classes of integer types. In low-level programming you often have the situation that you want to know exactly how many bits a variable occupies. While this could be done with packed subranges, it is more comfortable to have an extended syntax for `Integer'. In GPC, `Integer ( 42 )' yields a 42-bit integer. Depending on the machine (which might not have 42-bit registers) this will probably be stored in a 64-bit word, except in packed records; however on those machines where you need, say, `Integer ( 8 )' for your low-level stuff, you can be sure that the hardware supports it. Having this for `Cardinal' and `Word' as well yields 20 + 7 classes. Adding `Ptr[Int|Card|Word]' as suggested above would make it 23 + 7 classes of integer types. Well, no big deal. I know this is a great source of confusion, but the discussion convinced me that all these integer types have their place where they are important. Greetings, Peter :*) Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: gpi-hash.c segfaults
by Frank Heckenbach 31 Jul '97

31 Jul '97

Jukka Virtanen wrote: > In ANSI C the result of (ptr - ptr) is of type ptrdiff_t, > which in the alpha is (signed long). > Using cast (unsigned size_t) might not be a good idea, at least > I do not know if Ansi C quarantees that size_t always > is as large as ptrdiff_t. While we're at it: would it be possible to have predefined Pascal types as size_t and ptrdiff_t (and maybe other types?) so that such calculations can be done in Pascal?

1 0

Re: More crashing in gpc (970727)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > Sigh, got gpi-hash fixed and now this :( > > At least it's easy to reproduce, I just have absolutly no > understanding of what's going on. > > Just compile with `gpc -O2 -c system.pas'. Reproducible. :-) > A warning is given (doesn't make sense to me yet) You commented out the definition of `LongInt' to be `Integer' (32 bits), so GPC used its built-in `LongInt' (64 bits), whereas pointers on iX86 processors only have 32 bits. > and then the call > to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes > bananas (infinite(?) recursion). This happens in fillchar (line 178) > [...] Fixed. :-) Patch for `gpc-typeck.c' below. > There's also a strange bug where an untytped constant that's declared > in one unit that's used by onother and both of those are used by a > third gets lost to the third unit if the second unit is `used' after > the first. Unfortunatly, I have yet to reproduce this in small > files. And unfortunately, I cannot reproduce it by myself. :-( But I don't expect this to be as weird as the "hashing" bug you just fixed. :-) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- gpc-typeck.c.diff ---------------------------------------------------- @@ -5303,7 +5308,9 @@ pedwarn ("constant out of range - truncated"); } - if (TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) + if (TREE_CODE (type) != POINTER_TYPE + && TREE_CODE (TREE_TYPE (value)) != POINTER_TYPE + && TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (value))) { /* Do the conversion in two stages, e.g.

1 0

Re: Linking error
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Joao Miguel: > > I'm trying to compile the system.pas unit (contained in bpcompat.zip) with > my program. The compiler gives the error: > > "system.o: Undefined symbol `__fmode' referenced from text segment" > > I'm using Free-BSD 2.1. [...] I am afraid this system Unit is not {yet} very portable. It is known to run under DJGPP (DOS), but to make it usable for FreeBSD, probably some work will be necessary. AFAIK, `FMode' is responsible for write access when `reset'ting a file; to get the same functionality without this variable you can use `update' instead of `reset'. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pascal Compiler
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Tsee Lee: > > I saw on the web site that there is a version for Win95, but can't find > it on the ftp server. Is ther really such a version? Thanks. Yes: Look out for the `cygwin32' binaries. You will probably need more CygWin32 stuff for program development under Windows 95 with GNU Pascal. You can look for it at ftp://ftp.cygnus.com, but somebody else on this list can probably tell you more about that. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Linking error
by Joao Miguel 30 Jul '97

30 Jul '97

Hi, I'm trying to compile the system.pas unit (contained in bpcompat.zip) with my program. The compiler gives the error: "system.o: Undefined symbol `__fmode' referenced from text segment" I'm using Free-BSD 2.1. Can anyone tell me what is the name in BSD of the symbol referenced in the source: "FMode : AsmName '_fmode' integer;" Best regards Joao Domingos

1 0

More crashing in gpc (970727)
by Bill Currie 30 Jul '97

30 Jul '97

Sigh, got gpi-hash fixed and now this :( At least it's easy to reproduce, I just have absolutly no understanding of what's going on. Just compile with `gpc -O2 -c system.pas'. A warning is given (doesn't make sense to me yet) and then the call to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes bananas (infinite(?) recursion). This happens in fillchar (line 178) Oh well, here's my version of system.pas (a few functions added and fillchar's parameter changed to Byte) There's also a strange bug where an untytped constant that's declared in one unit that's used by onother and both of those are used by a third gets lost to the third unit if the second unit is `used' after the first. Unfortunatly, I have yet to reproduce this in small files. Bill -- Leave others their otherness. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: system.pas Date: 30 Jul 1997, 18:27 Size: 8054 bytes. Type: Program-source

1 0

gpi-hash.c segfaults
by Bill Currie 30 Jul '97

30 Jul '97

I'VE FIXED IT!! The problem was caused by a negative index into the hash table. To fix it change the line (gci-hash.c:122): (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) to: (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) (patch attached) Now for the explanation: when gcc subtracts pointers, a SIGNED integer is produced and all further operations on that value used the signed versions (eg cwd,idiv to get the modulus). The reason this showed up for me and not Peter is djgpp's sbrk algorithm mixed with window's memory allocation: sbrk allocates separate dpmi memory chunks each time it is called and under windows (3.x or 95), the allocated memory can very easily come from BELOW the beginning of the program. This will result in pointers in the range 0xfxxxxxxx. As to the reproducability: it all depends on the fragmentation of dpmi memory under windows (cwsdpmi doesn't seem to have this problem, and nor does dosemu I suppose). Well, anyway, maybe now this bug can be laid to rest... Bill -- Leave others their otherness. *** gpi-hash.c~ Tue Jul 22 14:04:30 1997 --- gpi-hash.c Wed Jul 30 16:04:00 1997 *************** *** 119,125 **** #define HASH_FUNC(NODE) \ ! (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) /* return pointer to a node uid field */ int * --- 119,125 ---- #define HASH_FUNC(NODE) \ ! (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) /* return pointer to a node uid field */ int *

1 0

Pascal Compiler
by Tsee Lee 30 Jul '97

30 Jul '97

I saw on the web site that there is a version for Win95, but can't find it on the ftp server. Is ther really such a version? Thanks.

1 0

Re: Unit files
by Peter Gerwinski 29 Jul '97

29 Jul '97

According to Joao Miguel: > > Can anyone tell me if GPC 2.0 supports units (like borland's) and how ? It does, just like Borland Pascal. > I downloaded the zip file bpcompat-1.0.zip that encloses a lot of very > useful units. When trying to compile the program test.pas that comes on > it, the compiler "says": "no exported interface matching gpctypes" and so > on. One error for each uses clause. Like with Borland Pascal, you must either first "compile" all Units, and then the main program, gpc -c myfirstunit.pas gpc -c mysecondunit.pas gpc myprogram.pas myfirstunit.o mysecondunit.o -o myprogram or else you "make" the program, i.e. you tell the compiler to compile all Units automatically. With GPC, this is done with the `--automake' option. The following gpc --automake myprogram.pas -o myprogram automatically compiles `myfirstunit' and `mysecondunit' and links them to the main program. (* Just for completeness: The `-o myprogram' means: output an executable `myprogram' (or `myprogram.exe') rather than `a.out' (or `a.exe'). *) 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Unit files
by The African Chief 29 Jul '97

29 Jul '97

On Tue, 29 Jul 1997 09:55:34 +0100 (WEST) Joao Miguel <castor(a)suprabk.supra.pt> wrote: >Hi, > >Can anyone tell me if GPC 2.0 supports units (like borland's) and how ? > >I downloaded the zip file bpcompat-1.0.zip that encloses a lot of very >useful units. When trying to compile the program test.pas that comes on >it, the compiler "says": "no exported interface matching gpctypes" and so >on. One error for each uses clause. The bpcompat package that you are talking about was written with the latest beta releases of GPC. I am quite sure that it will not compile under GPC 2.0, because many extensions have been implemented since then. You need to get the latest beta release from agnes. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: --
by Peter Gerwinski 29 Jul '97

29 Jul '97

According to Herbert Voss: > [...] > Var i : Real; > Begin > For i := 0 to 25 Do > WriteLn; > End; Obviously, your version of GPC (2.0?) has a bug with type-checking in `for' loops. Recent beta versions of GPC (available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/) are correct here and complain: test.pas: In function `program_Test': test.pas:7: `for' variable must be of ordinal type > /usr/lib/crt1.o: In function start': > /usr/lib/crt1.o(.text+0x5a): undefined reference to main' This is what Borland Pascal would comment with "Cannot run a Unit". Use `gpc -c foo.pas' if you only want to *compile* a Unit, not to link it and produce an executable. > Another problem comes, when I choosed the Type Byte for the variable i. gpc-2.0 has no built-in `Byte' data type (recent beta versions have), but you can use the definitions in the `BPcompat' package. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Borland file functions
by Peter Gerwinski 29 Jul '97

29 Jul '97

According to Joao Miguel: > > Can anyone help me, telling me the name of the corresponding function to: > > Borland GPC > Sizeof() ? > Filepos() ? > Filesize() ? >From the GPC info documentation, node `Extensions' (type "info -f gpc -n Extensions"): `SeekRead (F, N); { Open file in Inspection mode, seek to record N }' `SeekWrite (F, N); { Open file in Generation mode, seek to record N }' `SeekUpdate (F, N); { Open file in Update mode, seek to record N }' `Update (F); { Writes F^, position not changed. F^ kept. }' `p := Position (F); { Return current record number }' `p := LastPosition (F); { Return the last record number in file }' > I'm working with GPC 2.0 and I have no documentation about all the native > procedures and functions of the compiler. Do you know where I can get it ? This is one of our most striking problems: The existing documentation is rather incomplete and outdated. To read what we have, use "info -f gpc"; in RHIDE, press <F1> Ctrl-G (gpc) <ENTER>. (Yes, `gpc' in parentheses.) Any help in improving the documentation is greatly appreciated. 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Unit files
by Joao Miguel 29 Jul '97

29 Jul '97

Hi, Can anyone tell me if GPC 2.0 supports units (like borland's) and how ? I downloaded the zip file bpcompat-1.0.zip that encloses a lot of very useful units. When trying to compile the program test.pas that comes on it, the compiler "says": "no exported interface matching gpctypes" and so on. One error for each uses clause. Your help will be very, very useful Best regards Joao Domingos

1 0

Borland file functions
by Joao Miguel 29 Jul '97

29 Jul '97

Hi, Can anyone help me, telling me the name of the corresponding function to: Borland GPC Sizeof() ? Filepos() ? Filesize() ? I'm working with GPC 2.0 and I have no documentation about all the native procedures and functions of the compiler. Do you know where I can get it ? Best regards, Joao Domingos

1 0

Re: Allocation/Memory Leak question
by Ken Linder (KC7RAD) 29 Jul '97

29 Jul '97

At 12:50 PM 7/26/97 +0200, Peter Gerwinski wrote: >According to Ken: >> >> program allo2; >> var >> mm: array[1..500000] of real; >> indx : __long__ integer; > >(* JFYI, `__long__ Integer's have 64 bits. For your program, an ordinary >32-bit `Integer' would be sufficient. *) > >> ma: array[1..500000] of real; >> [...] > >> This program realy does nothing of value but when the second FOR >> loop is running, the program starts eating up memory. > >Really at the second FOR loop, not already at the first one? >I don't know the details of the memory management of Linux, but >AFAIK, the storage is physically allocated when the array is >referenced. > >> According to TOP, >> the program uses 8094 kBytes just before the loop ends. Why should >> this program be so memory hungry at that time? [...] > >Simply because one `Real' has eight bytes, and you are allocating one >million of `Real's. 8000000 bytes are 7812.5kB; if you include code, >runtime library, etc., 8094kB seems realistic for me. > It must be something associated with Linux. I also thought the allocation of memory should take place when the array is referenced. I stopped the program with a readln after the first FOR loop and sure enough, ~8108M was allocated (as seen from top). What is strange is when I run it without the readln, top shows the allocation to be incremental, not complete after the first FOR loop like what I see when the readln is in the program... Thanks... Ken L.

2 1

Re: --
by Ken Linder (KC7RAD) 28 Jul '97

28 Jul '97

At 09:14 PM 7/28/97 +0200, Herbert Voss <Herbert.Voss(a)ck.b.shuttle.de> wrote: >Hello, > >I'm a novice in gpc and I hav a lot of problems. Here comes the first >one: > >unit unit1; { reine testunit fuer gpc } >Interface > Procedure ClrScr; > >Implementation > >Procedure ClrScr; >Var i : Real; >Begin > For i := 0 to 25 Do > WriteLn; >End; > >Begin >End. > >I run gpc under Linux 2.0.30 and had the following output: > >voss@crazy_horse:/home/voss/pascal > gpc unit1.pas >/usr/lib/crt1.o: In function start': >/usr/lib/crt1.o(.text+0x5a): undefined reference to main' > To compile a unit do this: gpc unit1.pas -c The -c option tells gpc to just compile and not to link. >Another problem comes, when I choosed the Type Byte for the variable i. > If you want to define a byte variable do it this way: var JustAByte : __byte__ integer; or even define a 'byte' type (This is what I do) type byte = __byte__ integer; There are many other type 'modifiers' available. I don't have my Linux PC with me here at work but I think the type modifier list is in the 'news' file somewhere in the distribution. Hope this helps! Ken L.

1 0

Some bugs fixed :-)
by Peter Gerwinski 28 Jul '97

28 Jul '97

Hello, everybody! According to myself (Peter Gerwinski): > > bo5-6u.pas: In function `Writeit': > bo5-6u.pas:12: prior parameter's size depends on `What' > > (Read: A bug I already fixed twice in the foregoing days > is back again and again ... )-: It's fixed now {again}. According to Bernhard Tschirren: > > [Subject: __Volatile__ BUG ...] > > OK, the following code does not seem to actually define the variable - just > take a look at the asm produced by gpc! It's fixed now. AND the volatility of the variable now survives transport through the GPI file - which wasn't the case before, either. (-: UUencoded gzipped diff below.) There is one remaining bug I want to fix before I release the next beta, the GPI problem reported by Bill Currie. (See our recent mail on this list.) Unfortunately, I cannot reproduce this bug on any platform I have access to. If somebody else can reproduce it and help to find out under what circum- stances the error occurs and when it doesn't, it would be great help. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- gpc-970721-970727.diff.gz.uu ----------------------------------------- begin 644 gpc-970721-970727.diff.gz M'XL(`,P2VS,"`^Q=>W?:2++_VYS[(7JR/A,PB$'XC3<[(1@[S&+P!3R3N7/G M:(5HC-8@L9*(X\WDNV]5=4MJ/7"PYV;.Y!Z<!Z*[NKNZNOI7U0^56S/3N>4^ MF[H>NUU:;.JY"WS03H]KQW6]6BBT)(7ML*D]AX<'=\4LTV$>MUS'#[R5%;![ M.YBQ-[;O.A7&`_/6K["%><=M9^I6"J8S82/^CLW,]YR-.7>8N["#@$^JC`W= M!6?NE`4S[G/9@.EQMEI.3*!@_USY`1L_%,8K>SZQG5LD9):[6`*E!^5_ELP( M>LKU.!1)50DU\`_<6@6B"MO'.A;`6*'`&+'*1LW+(4.&V>2]S;0INX)4+%VU MG4(!>H]U3VSH=>!Z#]C`Y76+^>[*LSAT=^FY[^T)<(QD#H<TWP2RP'7G?J&8 ME@G)`^42\`]V'1HL4:]MD*<YGX-D"H61R\SE<OX@^S&QIU.HX=:%*E.LQ,-% M5:Y\'DHIZB%;FH$U8]I2+Q2FG),D[8#(INY\[MYC`C7!3!SJY2JH%D8SCJ/L MF`N>:A%8@$:!R0*689K'M)M]IO68]H'M55WQ,7=OY??Y!!]">>(S:,[4OJU: MIC53OT/O@Y6/"=BG]]SS;=>I6E3-TO1\GGB>A82W2^Y-Q5<:19%<_?[[^"FL MM&JN/M#C]U851V)/IN]59\%B+OBE\<>'P!7-17F=WG#4[';Q\>+Z[^_]R]X- M/OM+;OFB&QYU1W*.CU[@)SN"";*[80?"?EC+I7S4\7-NCXEC14!48OR+7;%^ MU8CUF9H1J%]`EQQMK_J+59G]BM_=90`\^"*3.):/@;E84EW!0G+$G3V9<\M_ MT;6#7T5]UGPUH>Y]7RX3@27XM"R+^);L<^=?*UO(83IWS:`Z$T)6ORQ6\\"& M_HD&X6%/='/E3$!6*$8AK`\P3O0YMP$R0H[M@%?YAZ48F[%Y)Q[\>R$]R]+J MU>-J'?X(K8_GQW?+[P2<=4$W(5G]7M`T;0WISA6,Y0^K.8,9IA\UZJ>-PQ.F MGYX>%\KE<KJ>G>%*$A\S76_HIXW:@2!^_9II>F6?E?5*_82]?ETH(RF0(352 M('WMD+%K'G"/77(/IJ5_9[._+C&A>ALFO%XYM@8`PYWJA/^M4"Z4=_:(]>`! MQO6N:C78K>?>&1/;MSP0G&,Z0;'4``!V)C#_0'2`D3YI`Q1E,,>-N0FP'AA8 M`5).7.=E`%KBVG.:^J.?K]O&>?^JV>DA\IE4#(D!P!;+.4*OZ7GF0S5BQM9F MIC]#5O#3",SQG/_R:P64"@;7F'$3!KI8JC!0BHFQ<">K>9S:H.H!"%T+:XXK M8),'0"/;@BP"(9]S=C\S`R!9+CETA[$1@CO\#5RJ9&H#(H)]X)X'%L[C2]=# MLS)^`&LUG[/6RO-LSCIH0QPW0`(/>+&@40XZR%A#*\HN"1ZQ0\1RX'&2E&4" MW/[8'!CG[58W$O$_WKL@%`"[EX@)")OSAS-B2!&^$`W*=P%R<=D])U-&9A** MK``TWB=&BRHH^H"9"S,PP<H(<[,HA6(7N/C08/YJ[*$^TH`VV+WI.<P<PP@# MB74'Q4("J0$F-'#K++@3&*YGH'P-Q&*.*0U(a)1G,]&!D^.6.."U_-.;-(WT7I M]Z9GX_!@V>G*L1!H#--"&]A@-NB';=D(a)`(953.&?8PF#(GK"BKN[I0I5A$-@ M,M`Z!R<`###8*!(a)V?P6SN+BK1_T$.S['D0#)Q#H><$-4F%9@V4RHJ8+G(BD* M*-`"=44('?K&IU,8+`;S':S[2W`<..388.0K;`S2`W[N33$.T"_0)9A9Y#N! M'P0FU*^6*&_"K3G8<P,$XR,W.(+<@Q;^M3+G]M0&C*,15]0DE*$O6*=J;GG` M_L$_@"P<<_X2.\\0B0"%8L0X:NCZDQ&#%1A(L7DS>ML?#!N@2/?D)U6WYGQK MSK\N<ZY:/6F)U:2L45=S-['K"7K%M-?T1OVDH=<4TWZB[U>.P;KC)V2`@4?/ MFWT4'V`OP60P[[TYKY#I/(-IJ/W%GH*,:"U1*,.7Z%D4^6Z/79L^X#$#_\(3 M2R-S?F\^^"!;A&Q<*DA:MO<=5,'G8(^@&$(I+E`@D45U#5=C1,LE+8-HS48V M'+#<0YLYM^^X,*QSU^>`$8B#)JQ:K)GMH*4%["9BP4C8/M`-76%CD-YY"$L( MS!2:BB:[*N6T?UC1T0TZV3_!!Q046D8RT<47Y$B@@1*L(F-D%Z!V#Q8N(`MD M^D7IC$IY/%AYTKX;"].[,QQW@K+=^03216D\*A1["I9(a)T&X;K?YY6SZBL\.* MX#CP#Z42^^85X,2H?=D>4$8):OZX(;]HQ@""-V35`?!%)B6#Y3A%95L9S:8C MG"ZPI28U2RP+[P:\`]?1:($.)@J;EQ[.F`L7;((+>A-XNK5],!5GZ'TL:+$- M&H:N%FC!Q!4#=EH[KIS">)WJ-?C$X5(T-59M4*)7($)T%=%1-,`KZC1[HX14 MB6&0ZJM7S!(VDUP4DD0I[%OT\[WL8`,!$V`W,.B[$;A&Z"3(&L\^/]@QC\"Z M"8AEB$H)VM5J-AN(J$KT,//K%"IT%@X:3N:56'1+S<`QZ/3.R94E/VGZ(-4* M#*EU!]*ITK06HU`_(7@YW=?A,T07ML?T$ON)B\%'K1,BPY5_2%`O"141+2,9 M*`NX\=(UI?E4B#!$2D#M=U+YUL\9TQ,3YKJ/4R::,$SBH.C&45UTX^A0Z0:- MG224\X2V?`S@E[8=#'`=65&DC0$%O`?#7;+B=?=F:+3?70\JT.\*]J[":N!- MLL_^R'E+\@!!O]A$A1Y%BURL"+O.=IX$%T)2Q[J0U/&!E%3A_TX^.SL[CPIB MTTGPJ8!__XLXKI_L$U#43PYJE2/B^!,R+2R/Y^+V&^WV)1><#<8N8;D*:.1# M^_-H7:`N7ZL%C>WA/U:$ELAW7]BW,X0K"[<0X_72/>Y:W7-:/MZKJR?(L:T9 MU0&3-#!Q0]/U%F!/U(9HHQ,G2G)U6ZU6<32QS^C5VA;-_4)VG<V*V&1)RN/@ M!.10IL]]72I[2HF('/&PU[^FD0J5YMMOV75SV&IV#:(^[PQ;@\Y5IT>02J6D M?E%V_[H]:`*44`Z.,6#2%%WU8GXVC')93KNR4%'I1OC@%^!R*V+1:'6;PV&6 M9V@^]#SBTOA#2^*7^R\;:F(^F_52DH8!USDBS2\JNA#_@)I=@#L_>COHWUR^ M):W-LE5/LB42_[H)K_KS>=6?QZN>QRO?A-?:\WFM/957:?D:F4(3%[%BAKXF ME@ES/HG'3X48RK#E,P$68MX<DZFKG];V55.G.M.1^9VX"YS*KQ)[5$6<O6AY MXY]HV@G`%L5`AS65ZZBR)$)%Y"G)K"6WW.4#^31Q0PEF5'.7JBI;-%%2N%?D M775OXGZL&=]\8JAQN]#?+O2_LH5^N*,<+<S#A+Q%?IBWV1(_HK[P;$%]B-2' M]<;A:;S`/T(WK'P4.F-_`>!#?Z;7''5^;!LWG?,B_"NQ(GW\K0:K%Y'08!H] ME-`7"DM=-=\9;YO#M\:H^:;;9GJM=EK0I&LA#U57]L18!A[X*\H6>K+<KV<[ M`+3V1.PDCU?6'0</!M$V78=:R;I"P)X[G1H!M`B?OEAL`?K,78#P.,7P[7]S MX:/6CVL$U/!Q(G':]ZMW_`'PJ`8EY5("DJ?W'@P_*W[KX]8G5`!N8-'W2V`< MX3OZG(R-_\T]EQ5C1B/*.$E`L'(D`$O.3%\SUH]9=)K`BDGQ*9RDJI!X;3MV M8`"LCV&]7'0<5H:!JA^4SI2!O![T6^WAT.B!9U1T*K209>Q_";.I.N#0YX$! MSU`%Y%880#I2H`#W:V3I]FNG4H!DX,0H6,NS^(NW_+.*"+*^L1<@(0.MA.&. M08NM.P-%QR>EU!X8S/($!2A$MNS6/FWMT]=FG\+C06E3PJ]9VQ3F;&*9(MKD MF7*M#G]CNU0_/@3P*(L/VDP5:WOR=J]O!M?]8;A9(?U`WS+!"XQW`6IRAY+V M/2)'.2I*Y+1$O>F*U2BXS3O"]X\/NI)-Y#3'=I3%`=XJ(:.C$0^?Y54M2SXV M&KEG\)#\41DI;\9(NGS(#%M7O/665B39JDH5-,,(@LGB*O>/%*;6\4`Q+EX+ MMXX.#FH576?E\$%=0H$1\;AYIZPJ/D4;NH3[[:LW[7.Q+H(6]F&&<\]T)F*T MHH7HF\[(N.BTN^?&H'W14#):_=XY;62HB5?MT=O^N=$"E%/SE)V#3%-E9=6; M:DS-4II3D[,-EG/7D.(^`JTD4\OA@';*&+@K$[X,9FC[DTNQ1XOJSR]:SQ85 M@WJX7SFLX:"*A\\.:JRC]^Z:46SUKZ[[O79OE![%YF#0_#D[M$!]DS>\_?/. MQ<^9Y$X/QBV=F-8!2HSV*1.U=GIYJ3?=;*6CP4VO99QW?LPVU^YT<S,NNOW^ M(#=G0'W,RQ'-0&_SF\G+$)7EYN2UT'[7;(URV\9U?"8-?+5T6G?XMG.1E=`@ M/[D[Z(^:HW:6?$TZSL0.R"TO_=V:]&:.QLCT44ODL*201V\QLW.1-P"0UQ^L MS<IK*RRT)B./[1P5ZV:%<9FENLQ2M?\[D]1KY\R53-*P/3)R6@6@R&D%YV:W M_6X-NN9-=C5+F>Z9$C?Y`*M.>35#F?2)JC)(G)[XB=J5J9](CR>_FIR>_HF& MDP"@9J4A0,U+@T"VN7A.9YK+STI#02(OOZ4T'*1DE)<:08*:F@"%1+OK,I+` MD"BR-B<)#NF<=VMSFKD:EH&(U!"D0"*;J\!$;M%'"J[-RN]$KE)V\T1TF4=Y MF4<9P8::V&OGSKB<Q`1X)(9/@8_T7(\!Y$_M+8DM_&"-GW18.ZCL'X&?)!\V M]Y-</)X4?E+23>J`G@W:K8R7].;FXJ(]2*=>=-X9`B(R/@?D$$#D90@TRLL9 MY#I=0-\<Y9B6RSR[W7R3]:0N+H:Y=KG7'ZTQE7DYK>8@QQWJ]WYL#W*XDX>< MR;2>T:7%39;K\_.L1$#:[4&[U\JQM+W1X&<CORK@Z(><JIK=ZV8.GYVKYF4Z M(VU.DTJ10"Y%+1+V)J48Z3Q%-=)9JG*D\P9K3+2J($D0N<S'[UA)$M5<#->@ M<ZP.6:#,SU.4);6(4]0EP6ND,,G4E,HD>A$K30+W4FJ3P-J,XJ2X^R&WPH3R M)%0CJ3Y?'DS7(F*FT'1NWOK4A)_,S@*CECC>E7/`]'WN!:Q8BP]#LR?`*I$\ M!(ANKOUE13<>AZ/^('E1K"";I3VMFD[7A.1G$L+QJKW1:UY1C]FK^$(^*Z[O M?4),FQ:BEH:=__E$=P/D]<UJ!#,RYOK;F<X^FQ)91_^>14\;MRD./?W*_4: MRA,?3I3;1"SU"H-ZUJXE=KH&7*/[1>)Z#')"Q]2>"=\]O&'F$)-,;&AIJ7-Z MW&>K@&(LQ(.X`5M.-/`:?I[0BKC(G[A;L+ZMBG+WGBD[F>*MC)6#V^I85AR] M![6$6.D5N`V'0+:Z*3EM'SZJ6,DK#%'UKXBK]/V%Q%ZHN`U&O9K;/DS'J-<5 M4;B2+)W\$5)3BBB/*<;H.L,?QLACM)F6(B40[U$8]J0DV"_3P(/6W8#VFVRR M6BP>%'VC2]"FT$(!F8Y[7Y$:A[?.3'S/\IY';^&P\%T.(L_531IDB;_?!C6! MP/0N270WY6UG:/S8[S9'G6Z;B$HEN<V=4%]K9MH.7C%57BB1=!O*11F!D'&4 M31*/5(7[)E2X+$.SC`E67FR0I4WUFOUI9ST[*2IZ=ZME@8)H4B5)W1?'51I M5)6FQWB=AQ6+I%A[):BPS.H5%GV'$18I!V0I,[OP*5[H4!=;Y!-Y1PB:7(&P MXK-V`?>'!Q6]5D>\/ZK#TV'"@GYZI*4_8L=?4[N$[T3+OEAX=JX(-\<IV@PJ M<]:7SRQ8?TK!C;P+[1'%T5)V7$O<F/LR9R'EI(9EAZ.\L0J6UUU*_/S0/594 M?W[1^M.*;C2`Y8WGOAC$\O9$9GLBLSV1V9[(?!W6[\L9,6V[R[K=9=UHE_6/ MF2)?6-,WV#C;GLIN3V6WI[+;4]GGG,K^OUNW?>G%5WG=,>_V3&][IO>[SO3^ MG%/Q#YI/&QW^I<[^0(?/<X_^MJ]];%_[^*I>^Y`1U^3[&O);]J4/F9'SSL=I M^IV/D'1H!H+TB-7W&_!7/U%B#1V?UC&R`'V&+WU\@O]^8]?-UM_;YRP,_<)& M/_7/^Z.A$@D!:3_BZP[B@&?))T!G6^RWW^CHRL"(>L:2P@Z5!!EC0$0!?HHO M.L-^&)-HXG(1O$*^"I>*+4<G+;Z(?@.5[-8)&Q_&89RVU,O*,AP,4!A`0C&) MBKOTEK\H?O",X@=1<>SI=?L<L*;38D4`5D,<MLM(#;6C0WD^?G0<GH]#*1EQ MR*#@&(:(DP+"8[N[P,RN?L:$S,5KD8*(SJ->5E[FE=6BLM&)V:Y>8;O[^$:A MAFP^/&"<D#NLN!R-TKH29;4$?OL4G_'\)(a)+)9`.A?(P"%V&$H%@K*!Y0JA\P M=BQ19Z:CHJYL5T4!T>&PO87M8X`/$9CV!1U]ACU<2Y)S?J=*(Q)&WIFP*LOU MN1FYY0ZF$*:V7IC\0^"9,=_:&KZ%SF3828DA55EY?66?YY[JW&$LCWGPA<,F M[<720Y\8XW]Q3\13G.0J1/)NQQ-Z]]S6/M_]'8JQ1#/YX$"'F:RS\L%!_3"^ MZ1)&NT$8"$P/(RM^\RH=BJM$KU%]E*^DA1=2KA!S1-!H/.OWV73ET5V4,$:3 M?',,Z$<NP\I$M*5[+J)*BMB:>$G`I5HD.=N+8CY6&04BY0X&R70=^&_E"WK$ MXY@^C*T)!><KK@3M]*/HE"+*5UQD3$&E[8D(N'D!RY11!_QLO.F#)F)BB]AL M<0%S[+ZGEXHQ2">&^:$X.B+J-X8$$TAOQ@7H7!Q#8(K8VQ3/0_`G8G!GV:^( MR-<H(RHL(R`5X?N<F[["O15*I431QKV)"%M&=S)D93&QN"%@8F)5<$[R\9D9 M76ZBJQT*0Y)KY*(:6KHPF%Y,!CIP`92)?3J0.(RO/W-7X(V*NTE*O3!J@DF; MST%AL+MXBX#)&%S@$H-P8GJU/QB_B+0+Y!Z6O^>>PG6H3]58JZ/073L[.YD` M0R)$.;V_&>WV2<I4F"&,%C)H#T>#3FL$+H1ZLU!6@O%29,F/2AVD(P8&7O=L M"V:R(<@Q*,O@IGWV&*6<C%E*Y9%>,=^`25&79#(+0EBA&K>/Q6PD%1=\"#$- MQ_'L)5#?R;G2$E8'DR-1(UE!=_Q/;@5KRGZ*N@A/<GQID8;B$'TYD\GW,USI MJ*,:B`%5=;(4Z@@3\LPL'\/:4@HBJ@KG2%R+E+A803>'P\YE#P5.*TK]+"*3 M/TEM!##\*0XZ_,;UYC@)I-_X`F4S$2[J"P8V'^`N1YL3"<AS,>V>LF_9&^,\ M].2P%S5I!`Y.*_HI&H&CHTJ]+AWDI/A5A<+_SEO]WG"4JU`RFD6R!KQ;J3T- M^;4G(K_V=.37GHK\VE.17]L8^;4G([_V%.37GHS\VEKDWY$W7!/3UZ]&J*M: M@XU\@LVP62I8<OYIGYE_89EX$FZ"^.5G(WXY0OSRQHA?WACQ8TKE\>F(7\Y# M_/+O1?SR[T#\<A[BER/$9_*=?;ZP`_!V'=PRQ``Y],LW*!R*N!")68Y+440% MM!WK%4*V4[VBA\B&%3UQ6$M1](=(/-1Q7'ZMZU84K!+'5$B(J=XR&^'O7L%P MXM&OAL%8IKC%B=&&78I^:BMA'^+"K>AWR9@8+D?^LA$1C9ABQ4-:B)IQM`:, M+,F#-?-T0V[R"C^%F[A\&(9A?9C0V*"\HJ,@3%5B<<(0KIG&:)H&-ZU1?Q"/ M6S3EHNX9R)<L5Y$N1"6*"G&X+R+('NX?AA%DI0P[^3'ZP]\T$-KFT":O[]_N MKNC;H-WJ#\Y%][0UN#-LO6U?-9/%]<14WJ#`KE3D:%$H;@;C;PAR'?QU!A06 M=7>W(CMCB+NRX6;9([^Y`*8C$&]WI+<[TE_7CK3XW1AR,UE\R>Y'B_1-MJ,E MI1KYOMZH'S?J2@`BO0ZVZ(25Z5,&=$_]T$H6)S3`L1%]61_?-B+[3VM7LQ(Q M#(3/]2GF6'?!=1&J5L1W\`5D+X+@8;&U[,5W=_Z2F:1)6T'84_DR369FTR3M M]TWA#%":ZPY'!7($.]=]MMNE>+.?,6@J%"S#HZ$*)O1WW_R3(<CX4:^R9-$B M9YAALOCWM4Y4%GTXQ%E\2,[/=F$O`BVFHJN=@OT)=5+P>7^3-CKDI!#<*7R) MH!_MN0(GQ,NKXI+\.D['+/$N3(@<4R7IS8!HC9RGI1.RCZJ5-=@]WJL>8<H: M].\YZ'FQ_#IC^#Y3;1<F3.(,`;B[&`9'$]%UC[[0'?%)P3+2[HP^7O3L$CO) M76OC-&!=\^"J'Z'NT9(a)XV.\G7"4$.4:NJ(`.H!H4=PG-#^T+N<;"4N3/I-*Y M=!?7!_=IGC/GQR`7R^->;U4?^=4V"XO*[TO#3HA'ML$'WBNV$]X-%PO<[`DF M_"432CN)&O86+#"X4!I$:8->ZVNR0,C)T,A2SC'L\.+\T5M>!75.7NB1,EP7 M%GPS%K+Z5*5'_Y(:4$N1IO$&?9#D8IX<Z_CUM"@-1=X6\N<8>LULJN)=G#D> M;CN1KC\>M<8%SY8<#)Z5G^%,GS)0G42<CL)A!+E(H9GX6V\4LQ0(a)H04$1./\ MK]J5,M:;;'JIU+#?`B;[L:Y#'1TZ0R4VR.]T=!/&B3DLZGC2/1.HXS1N?/_W L!4`Z0E!$09JP9Q&\C]/G&V_&2U#SF84_]:K>$JB:U66LQ^H7CZFPF/%T```` ` end

2 1

--
by Herbert Voss 28 Jul '97

28 Jul '97

Hello, I'm a novice in gpc and I hav a lot of problems. Here comes the first one: unit unit1; { reine testunit fuer gpc } Interface Procedure ClrScr; Implementation Procedure ClrScr; Var i : Real; Begin For i := 0 to 25 Do WriteLn; End; Begin End. I run gpc under Linux 2.0.30 and had the following output: voss@crazy_horse:/home/voss/pascal > gpc unit1.pas /usr/lib/crt1.o: In function start': /usr/lib/crt1.o(.text+0x5a): undefined reference to main' Another problem comes, when I choosed the Type Byte for the variable i. Herbert

1 0

Re: Allocation/Memory Leak question
by Peter Gerwinski 26 Jul '97

26 Jul '97

According to Ken: > > program allo2; > var > mm: array[1..500000] of real; > indx : __long__ integer; (* JFYI, `__long__ Integer's have 64 bits. For your program, an ordinary 32-bit `Integer' would be sufficient. *) > ma: array[1..500000] of real; > [...] > This program realy does nothing of value but when the second FOR > loop is running, the program starts eating up memory. Really at the second FOR loop, not already at the first one? I don't know the details of the memory management of Linux, but AFAIK, the storage is physically allocated when the array is referenced. > According to TOP, > the program uses 8094 kBytes just before the loop ends. Why should > this program be so memory hungry at that time? [...] Simply because one `Real' has eight bytes, and you are allocating one million of `Real's. 8000000 bytes are 7812.5kB; if you include code, runtime library, etc., 8094kB seems realistic for me. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: problems with allocation?
by Peter Gerwinski 26 Jul '97

26 Jul '97

According to Giuseppe Petrella: > > The following simple program gave segmentation fault compiled on > digital alpha running osf > > PROGRAM prova(input,output); > var > mm: array[1..500000]of real; > BEGIN > END. Global variables of the program are allocated in the stack segment, not in the data segment. DJGPP limits the stack to 256kB, Linux seems to have no limit here. Obviously, OSF has a limit, too. This is a known problem. I would like to do something against it, but I was told that this would break Extended Pascal's nonlocal `goto' (whatever that is), so I don't dare to touch this part of the compiler as long as I don't have test programs. To work around, either move the array to a Unit (or Module), or make it a `__static__ array [...] of Real'. ^^^^^^^^^^ 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/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Allocation/Memory Leak question
by Ken 25 Jul '97

25 Jul '97

Just a quick note/question/observation. Consider this program: ---------------------------------------------------------------------------- program allo2; var mm: array[1..500000] of real; indx : __long__ integer; ma: array[1..500000] of real; begin for indx := 1 to 500000 do begin mm[indx] := indx / 2.2; if indx = 1 then ma[indx] := 1.0 else ma[indx] := (ma[indx-1] + mm[indx]) / indx; end; for indx := 1 to 500000 do writeln(indx, mm[indx], ma[indx]); end. ---------------------------------------------------------------------------- This program realy does nothing of value but when the second FOR loop is running, the program starts eating up memory. According to TOP, the program uses 8094 kBytes just before the loop ends. Why should this program be so memory hungry at that time? FYI, I am using GPC 2.0 with Linux 2.??? later... Ken L.

1 0

Re: problems with allocation?
by Ken 25 Jul '97

25 Jul '97

At 05:28 PM 7/25/97 +0200, Giuseppe Petrella wrote: >Hallo! >The following simple program gave segmentation fault compiled on >digital alpha running osf > >PROGRAM prova(input,output); >var > mm: array[1..500000]of real; >BEGIN >END. > >however array[1..1000] gives no problem. ???? >Thank you for your attention >Fulvio Ciriaco > > Compiles fine on a Linux box. What version of GPC are you using? Later... Ken L.

1 0

problems with allocation?
by Giuseppe Petrella 25 Jul '97

25 Jul '97

Hallo! The following simple program gave segmentation fault compiled on digital alpha running osf PROGRAM prova(input,output); var mm: array[1..500000]of real; BEGIN END. however array[1..1000] gives no problem. ???? Thank you for your attention Fulvio Ciriaco

1 0

Re: SizeOf with Objects BUG
by Frank Heckenbach 25 Jul '97

25 Jul '97

Bernhard Tschirren wrote: > You cannot use SizeOf with objects?!?! It just does not work. It either > aborts during compilation, or it returns rediculous values during execution. Did you initialize the object with a constructor call? BTW: There is a little difference to BP: In BP, objects that have neither constructors, destructors nor virtual methods don't have a VMT link. So it's possible in BP to get their size without initalizing them. I think that's kind of a misfeature, since the following program produces the wrong result for vy in BP, so IMHO, BP's behaviour should not be duplicated by gpc. (Though it's not 100% BP compatible then, a good BP program shouldn't make use of it, anyway.) type x=object a:integer; end; y=object(x) b:integer; end; procedure w(var p:x); begin writeln(sizeof(p)) end; var vx:x; vy:y; begin w(vx); w(vy); end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: SizeOf with Objects BUG
by Peter Gerwinski 24 Jul '97

24 Jul '97

According to Bernhard Tschirren: > You cannot use SizeOf with objects?!?! It just does not work. It either > aborts during compilation, or it returns rediculous values during execution. Some of my test programs check that `SizeOf' *does* work with objects. If it doesn't for one of your programs, please post it here. Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

SizeOf with Objects BUG
by Bernhard Tschirren 24 Jul '97

24 Jul '97

You cannot use SizeOf with objects?!?! It just does not work. It either aborts during compilation, or it returns rediculous values during execution. Bye ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

__Volatile__ BUG
by Bernhard Tschirren 24 Jul '97

24 Jul '97

OK, the following code does not seem to actually define the variable - just take a look at the asm produced by gpc! Unit Testing; Interface Var TheBug : __Volatile__ Integer; Implementation End. To work around this bug you can use the code below: Unit Testing; Interface Var TheBug : __Volatile__ __AsmName__ 'Thebug' Integer; TheBug : Integer; Implementation Begin Asm(".globl _Thebug"); End. WHY: The __AsmName__? GPC defines '_thebug' instead of '_Thebug' (capital) The second definition? GPC does not define TheBug with __Volatile__. It knows that 'TheBug' exists, but it does not output it into the asm. The explicit .globl? GPC forgets to do this! Cya ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Procedural types seem to work!
by Bernhard Tschirren 24 Jul '97

24 Jul '97

Im BACK! :-) I backed up my entire system on tape, formatted the HDDs and installed Win95. Naturally, it took me a while to get my computer back into working order... But now, everything seems OK - Only a whole lot slower due to Win95 :-) Remember those procedural type errors? They seem to have disappeared in the latest beta (using GPC1.EXE in GPC1_EXE.gz)! I havent done any extensive tests, however my programs compiled OK. Good work Peter! Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Objects Bug :-(
by Bernhard Tschirren 24 Jul '97

24 Jul '97

A new bug has crept its way into the latest beta of GPC (970714 for DJGPP 2.01). It does not appear in the earlier versions! Unfortunately I could not make a small test program which demonstrats this bug. Im working on it... The bug occurs when loading a unit that contains an object with virtual methods. The following error message occurs: bug.pas:2: storage class specified for parameter 'Tobject_Tobject_Methodname' bug.pas:2: storage class specified for parameter `Tobject_Methodname' Im hoping that these example error messages reveal what the problem is. I suspect it has something to do with the duplicate 'Tobject' in the first line. NOTE: Line 2 of BUG.PAS is 'USES TheUnit;' Good Luck ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Installing GPC binary on Windows 95/NT
by Andy Seila 23 Jul '97

23 Jul '97

I downloaded the binary distribution for gpc: gpc-2.0i386-cygwin32-b17.1.zip and unzipped it into a directory. (This is all the installation instructions on the GPC WWW site said to do.) I added the \bin subdirectory to my PATH. When I tried to compile the "hello.pas" program, I got an error message: GPC.EXE: installation problem, cannot exec 'gpc-cpp': no such file or directory. GPC.EXE: Internal compiler error: program gpc-cpp got fatal signal 127 I actually think this program is looking for the file 'cygwin.dll', but this file was not included with the distribution. I did also install Cygwin32, but that did not help. Can someone please tell me what I am doing wrong? Thanks! Andy Seila -- ======================================================================== Andrew F. Seila e-mail andy(a)ms.cba.uga.edu Terry College of Business voice campus 706-542-4290 201 Brooks Hall fax campus 706-542-4295 The University of Georgia voice home 706-353-2221 Athens, GA 30602-6255 fax home 706-369-9791 ========================================================================

2 1

Mailing list question...
by Orlando Llanes 23 Jul '97

23 Jul '97

How do I (un)subscribe to this group? I'm changing ISPs and I forgot the e-mail address :( Thanks in advance! See ya! Orlando Llanes

1 0

Re: gpi-hash.c segfaults
by Peter Gerwinski 23 Jul '97

23 Jul '97

According to myself (Peter Gerwinski): > > I just succeeded to reproduce the bug under Linux DOSEMU. That was bogus. :-( What I did was to move `gpc1' around after compiling, but my `gpc1.exe' was still gpc-970714. With gpc-970721 I still cannot reproduce the bug. :-( :-( I am uploading my version of `gpc1.exe' (which happily compiled your "foo.pas" sample program) to ftp://agnes.dida.physik.uni-essen.de/home/peter/gpc1.exe.gz If the error still occurs ... well, what can we do then? Then we are in trouble: To produce the error, in line 134 of `gpi-hash.c', for (l = hash_table[hi]; l && l->node; l = l->next) `l' must be nonzero, but point to some nonsense. How do entries in `hash_table' get their values? At the beginning of each storing/loading of a GPI file, `hash_table' is `bzero'ed now, and the only other access to `hash_table' is in `set_uid()' (line 173-177) - where I don't see any error. So the only remaining origin of this error I can think of is if some other part of GPC destroys the contents of `hash_table' ... :-( Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: gpi-hash.c segfaults
by Peter Gerwinski 23 Jul '97

23 Jul '97

According to Bill Currie: > > Yup, I suspected that. You use linux, don't you? Yep. > Probably got a very > different memory allocation scheme. Probably. But I just succeeded to reproduce the bug under Linux DOSEMU. :-) So I have a chance now to find this bug. However I cannot promise anything because Alexey who is on holidays at the moment hacked that code. > What do you think of my > theory about destroyed trees? I'd normally agree, but one of my latest changes was to zero out the hash table at the beginning of each GPI file ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: gpi-hash.c segfaults
by Peter Gerwinski 22 Jul '97

22 Jul '97

According to peter: >From peter Tue Jul 22 12:41:31 1997 Subject: gpi-hash.c segfaults To: gpc(a)hut.fi Date: Tue, 22 Jul 1997 12:41:31 +0200 (MEST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1483 According to Bill Currie: > > I just applied both sets of patches to gpc to take it up to 970721 > (hopefully properly) and unfortunatly, gpc still segfaults in > get_uid. > [...] > Hmm, I just tried out my previous sample file (under windows 95) and > got a crash as well, so my above reasoning may be incorrect. As you probably were afraid of already, I cannot reproduce the bug. :-( > Call frame traceback EIPs: > 0x000ee4d0 _get_uid+32, line 134 of gpi-hash.c > [...] Just to be sure that we are talking about the same GPC: My line 134 of gpi-hash.c reads for (l = hash_table[hi]; l && l->node; l =l->next) If the "l &&" is missing or commented out in your version, this would be the origin of the error. :-(But it isn't. That would be too easy.) > the command line uses was:gpc -O2 -o foo.o -c foo.pas It compiles fine on my system: % gpc -O2 -o foo.o -c foo.pas foo.pas: In function `Dectobin': foo.pas:22: warning: return value of function not assigned > Sigh, this is getting frustrating (and probably more so for you, > Peter) Such is life. But it's good that you have found this error *now* and not later when gpc-2.1 will be released. That's what beta test phases are for. Thanks a lot for your patience with GPC! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

... it's back again ... !
by Peter Gerwinski 22 Jul '97

22 Jul '97

Hello, everybody! Just for your information (with gpc-970721): bo5-6u.pas: In function `Writeit': bo5-6u.pas:12: prior parameter's size depends on `What' (Read: A bug I already fixed twice in the foregoing days is back again and again ... )-: This happens with a parameter of a schema type like this: Type Matrix ( n: Integer ) = array [ 1..n, 1..n ] of Real; I will see what I can do against it <sigh> ... Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

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