- Gpc - gnu.de

$D directive
by Peter N Lewis 03 Jul '05

03 Jul '05

The warning message for $D is: ignoring BP directive `{$d-}' which is unnecessary in GPC CW Pascal uses $D to turn symbol generation on and off (typically used to disable around sensitive areas of code like password / serial number / authentication / etc). I don't know if there is any equivalent for the Mac directive, but the warning is a bit inaccurate for Mac. Perhaps it should just be the normal "unknown directive", or perhaps there should be a general scheme for setting ignored directives (which could include $D for BP, and could include $unused for Mac). Or perhaps the warning message should just be changed a little? Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 1

Dropping some misfeatures in for-loops and `absolute' variables
by Frank Heckenbach 02 Jul '05

02 Jul '05

GPC accepts the following program, but produces quite silly results: program Foo; var a: array [1 .. 2] of Integer value (0, 0); i: Integer; begin i := 1; for a[i] := 1 to 10 do begin WriteLn (i, ' ', a[i]); if a[i] = 5 then i := 2 end end. The problem is that it evaluates the index i each time, not once before the loop. It would be possible to fix it, but do we really want that? Neither BP nor CP/EP allow it, they allow only identifiers in for-loops. Waldek and I see no need for such a feature. (If it made it possible to nest a compile-time-unknown number of `for' loops, I could see some point, but of course, it doesn't.) So, would anybody mind dropping this misfeature, and requiring an identifier in for-loop counters? The same (and probably a lot of other weird stuff) can be achieved with "extended" `absolute' variables, such as: program Foo; var a: array [1 .. 2] of Integer value (0, 0); i: Integer; {$local W-} c: Integer absolute a[i]; {$endlocal} begin i := 1; for c := 1 to 10 do begin WriteLn (i, ' ', c); if a[i] = 5 then i := 2 end end. We support `absolute' for BP compatibility, but IMHO then we should restrict it to what BP requires, i.e. really absolute addresses, or the address of entire variables or parameters. I suppose (hope) few users actually knew about the extended (mis)features GPC allowed, so I hope we can drop them. (If not, we probably should change semantics to evaluate the address once, and not on each usage, as is done now, so if you rely on this behaviour, you might have to change your code anyway -- if nothing else helps, you can always achieve the same effect with type-casting of pointers.) BP compatible code will not be affected. Any objections? Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

10 13

$no-methods-always-virtual
by Adriaan van Os 30 Jun '05

30 Jun '05

Peter N. Lewis pointed me to the following: {$methods-always-virtual} {allowed} {$no-methods-always-virtual} {error message} program P; begin end. GPC accepts {$methods-always-virtual} as a directive in source code, but it rejects {$no-methods-always-virtual}. Is there a special reason why ? The value of the flag changes also (I think) when switching from {$mac-pascal} to {$gnu-pascal}. Regards, Adriaan van Os

2 1

Fw: Wikipedia
by Frank Heckenbach 29 Jun '05

29 Jun '05

Scott A. Moore wrote me: > So I've been upgrading the Pascal pages on Wikipedia > recently. I can't help but notice that GPC is almost entirely > unmentioned. Even many DEAD Pascal editions have a page. > > Just a thought. Thanks for the notice, Scott. Anyone here on the list feels like writing a bit (http://en.wikipedia.org/wiki/Pascal_programming_language)? Of course, you can also write on the pages for other languages that you know. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Question on a warning
by Pascal Viandier 28 Jun '05

28 Jun '05

Hello, When compiling a Pascal source with gpc, I receive the following warning: gpc -g -O0 -D_DEBUG --setlimit=2000 --unit-path=gpi:gpc --gpi-destination-path=gpi --implementation-only -D_DBG -Icommon/include -Imain/include -I/data2/informix-7.31.UD6/include -I/data2/informix-7.31.UD6/incl/esql -I/usr/local/devapps/ISAM/include -c common/src/fdb.pas -o obj/dbg/fdb.o common/src/fdb.pas: In procedure `CreeFDB': common/src/fdb.pas:1041: warning: `for' loop counter is threatened in a subroutine And here is the code that triggers the warning: FOR I := PosARec TO NbChamps DO BEGIN IF ((Champs[I].TipeNb > 1) AND (I <> PosARec)) THEN BEGIN WRITELN('Error: Array in an Array of Records! (line:', Line,')'); RETURN; END; Champs[I].Pos := Champs[I].Pos + AjusARec; Champs[I].TipeNb := TipeNb; Champs[I].DifByte := NbByteARec; END; The code inside the 'for' loop does not call any subroutine, except WriteLn and Return (conditionally) and they don't make any use of the counter. I wonder how the loop counter may be threatened in any way... My question is: did I missed something, or is gpc so delicate that one cannot use a 'for' loop counter outside of the loop for other purpose (that's the case here, the 'for' loop in the middle of a procedure)? How gpc determines that a 'for' loop counter may be altered in the body of the loop? Thanks Pascal Viandier pascal(a)accovia.com

2 1

error: `prefkeys.gpi' must be recompiled?
by Peter N Lewis 28 Jun '05

28 Jun '05

I'm using gp, and it is giving me the following error: /Source/InterarchySupportBundle.p:18: error: `prefkeys.gpi' must be recompiled Clearly this is actually a gpc error. I've attached a -v3 output from gp. Interestingly, it ends with: /Source/PrefKeys.p: recompiling because interface of `GPCMacOSAll.pas' has changed /Source/InterarchySupportBundle.p: recompiling because an interface used indirectly has changed and then proceeds to compile InterarchySupportBundle.p, so GPC may well be quite correct that PrefKeys.p does indeed need recompiling and gp either skipped it for some reason or is doing it in the wrong order. Any ideas as to why this might happen or what I should look in to to try to debug the cause? I'm guessing that the cyclic dependencies (in the implementation section) are causing problems. Peter. gp -v3 -g -gstabs -O0 --uses=GPCMacOSAll --no-check-platform -DINTERARCHY -Wall --unit-path=/Developer/Pascal/GPCPInterfaces:/Source/PNLLibraries:/Source/MacOSXSupport:/Source:/Build --object-path=/IAObjects --unit-destination-path=/IAObjects --Pascal=--include=/Source/PNLLibraries/Prefix.GPC --c=-no-cpp-precomp --c=-I/Developer/Headers/FlatCarbon --c=-I/usr/include/libxml2 --c=-flat_namespace /Source/URLFiles.p gpc -dumpmachine gpc -dumpversion gpc -print-file-name=units gpc --print-needed-options -x Preprocessed-Pascal /var/tmp/GPaaa00594 Needed option for GPC: -D__ppc__ Needed option for GPC: -D__POWERPC__ Needed option for GPC: -D__NATURAL_ALIGNMENT__ Needed option for GPC: -D__MACH__ Needed option for GPC: -D__APPLE__ /Source/URLFiles.p: compiling because target files not found or not up to date /Source/BaseGlobals.p: compiling because target files not found or not up to date /Source/Logs.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCleverAlerts.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyInternetConfig.p: recompiling interface because source has changed /Source/PNLLibraries/MyInternetConfig.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyKeychain.p: compiling implementation because target files not found or not up to date /Source/PNLLibraries/MyScrap.p: compiling implementation because target files not found or not up to date /Source/PNLLibraries/MyAEUtils.p: compiling implementation because target files not found or not up to date /Source/Utils.p: compiling because target files not found or not up to date /Source/Permissions.p: compiling because target files not found or not up to date /Source/DisplayWindow.p: compiling because target files not found or not up to date /Source/FileMapping.p: compiling implementation because target files not found or not up to date /Source/InterarchyIcons.p: compiling because target files not found or not up to date /Source/PrefKeys.p: compiling implementation because target files not found or not up to date /Source/ReportPrinting.p: compiling implementation because target files not found or not up to date /Source/TransferMode.p: compiling because target files not found or not up to date /Source/Transcript.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCarbonEvents.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyControls.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyNotifier.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyProcesses.p: recompiling interface because source has changed /Source/PNLLibraries/MyProcesses.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyUnicode.p: compiling because target files not found or not up to date /Source/InterarchyInterface.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyDrag.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyWindow.p: compiling because target files not found or not up to date /Source/ActionToolbarItem.p: compiling because target files not found or not up to date /Source/EditWith.p: compiling because target files not found or not up to date /Source/Resume.p: compiling because target files not found or not up to date /Source/TransferActions.p: compiling because target files not found or not up to date /Source/TransferProgress.p: compiling because target files not found or not up to date /Source/URLMapping.p: compiling because target files not found or not up to date /Source/ViewWith.p: compiling because target files not found or not up to date /Source/GenericBookmarkWindow.p: compiling because target files not found or not up to date /Source/TransferNotificationCenter.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTextDisplayWindow.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAppearance.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyHIToolbar.p: compiling because target files not found or not up to date /Source/BookmarkManager.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyApplication.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyEditTextToolbarItem.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyHIView.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyNavigation.p: compiling because target files not found or not up to date /Source/PNLLibraries/MySegmentedView.p: compiling because target files not found or not up to date /Source/SendRecordedCommand.p: compiling because target files not found or not up to date /Source/TemporaryFiles.p: compiling because target files not found or not up to date /Source/CheckWebWindow.p: compiling because target files not found or not up to date /Source/DirectoryList.p: compiling because target files not found or not up to date /Source/DirectoryPathList.p: compiling because target files not found or not up to date /Source/DirectoryRemoveList.p: compiling because target files not found or not up to date /Source/DirectorySpecList.p: compiling because target files not found or not up to date /Source/HTTPPathList.p: compiling because target files not found or not up to date /Source/HTTPPathSuccess.p: compiling because target files not found or not up to date /Source/MirrorCache.p: compiling because target files not found or not up to date /Source/MirrorFileCollection.p: compiling because target files not found or not up to date /Source/MirrorFTPDiskPathList.p: compiling because target files not found or not up to date /Source/MirrorPutMembers.p: compiling because target files not found or not up to date /Source/MirrorPutPathList.p: compiling because target files not found or not up to date /Source/MirrorReportWindow.p: compiling because target files not found or not up to date /Source/PNLLibraries/MySuspendedEvents.p: compiling because target files not found or not up to date /Source/NotifyUser.p: compiling because target files not found or not up to date /Source/ParseFTPList.p: compiling because target files not found or not up to date /Source/ParseHTMLFile.p: compiling because target files not found or not up to date /Source/Transfer.p: compiling because target files not found or not up to date /Source/TransferUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCustomControl.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyDataBrowser.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTextDisplay.p: compiling because target files not found or not up to date /Source/AutoUploadsEngine.p: compiling because target files not found or not up to date /Source/BookmarksBar.p: compiling because target files not found or not up to date /Source/ChasingArrows.p: compiling because target files not found or not up to date /Source/FTPDiskScriptingSupport.p: compiling because target files not found or not up to date /Source/FTPDisksEngine.p: compiling because target files not found or not up to date /Source/QueueManager.p: compiling because target files not found or not up to date /Source/ScheduledBookmarksEngine.p: compiling because target files not found or not up to date /Source/SplitViewControl.p: compiling because target files not found or not up to date /Source/StartupItems.p: compiling because target files not found or not up to date /Source/FileActions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCharsets.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTXNControl.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyPlayAsyncSound.p: compiling because target files not found or not up to date /Source/HostInfoMapping.p: compiling implementation because target files not found or not up to date /Source/HostUploadPermissionsMapping.p: compiling implementation because target files not found or not up to date /Source/PNLLibraries/MyDataBrowserColumnView.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyDataBrowserIconView.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFind.p: compiling because target files not found or not up to date /Source/ScheduleWindow.p: compiling because target files not found or not up to date /Source/PrefKeys.p: recompiling because interface of `GPCMacOSAll.pas' has changed /Source/InterarchySupportBundle.p: recompiling because an interface used indirectly has changed Compiling InterarchySupportBundle.p (603) gpc -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__APPLE__ -g -gstabs -O0 -DINTERARCHY -Wall --unit-path=/Developer/Pascal/GPCPInterfaces:/Source/PNLLibraries:/Source/MacOSXSupport:/Source:/Build --object-path=/IAObjects --include=/Source/PNLLibraries/Prefix.GPC -I /IAObjects -I /IAObjects/ -I /Developer/Pascal/GPCPInterfaces -I /Source/PNLLibraries -I /Source/MacOSXSupport -I /Source -I /Build -I /IAObjects/ -I . -I /Developer/Pascal/gpc-20050331/lib/gcc/powerpc-apple-darwin8.1.0/3.4.3/units -I /Source/ --unit-path=/Source/ --gpi-destination-path=/IAObjects/ --unit-path=/IAObjects/ --no-automake -c -o /IAObjects/InterarchySupportBundle.o /Source/InterarchySupportBundle.p --uses=GPCMacOSAll /Source/InterarchySupportBundle.p:18: error: `prefkeys.gpi' must be recompiled -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

gpc crash
by Peter N Lewis 28 Jun '05

28 Jun '05

The following program (with an error in it) crashes the compiler. The error (BSET undeclared) is detected, but then the compiler crashes trying to bail out. I'm using gpc-20050331/gcc-3.4.3 with the delphi object patch. Program, execution, and crash report follows. Peter. program peterM; type MyCollection = object function GetDataHandle: Integer; end; function MyCollection.GetDataHandle: Integer; var flags: longint; begin flags := 0; BSET(flags, 16); GetDataHandle := flags; end; begin WriteLn( 'OK' ); end. gpc -o peterM peterM.pas peterM.pas: In method `MyCollection.GetDataHandle': peterM.pas:14: error: undeclared identifier `BSET' (first use in this routine) peterM.pas:14: error: (Each undeclared identifier is reported only once peterM.pas:14: error: for each routine it appears in.) peterM.pas:15: confused by earlier errors, bailing out [crash] Date/Time: 2005-06-27 12:32:35.975 +0800 OS Version: 10.4.1 (Build 8B15) Report Version: 3 Command: gpc1 Path: /Developer/Pascal/gpc-20050331/libexec/gcc/powerpc-apple-darwin8.1.0/3.4.3/gpc1 Parent: gpc [2697] Version: ??? (???) PID: 2699 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000034 Thread 0 Crashed: 0 gpc1 0x0005324c expand_pascal_assignment + 288 (statements.c:1116) 1 gpc1 0x00009048 yyuserAction + 22488 (parse.c:4561) 2 gpc1 0x00010f9c main_yyparse + 544 (parse.c:7900) 3 gpc1 0x000c17c4 toplev_main + 1976 (toplev.c:1826) 4 gpc1 0x00002438 _start + 344 (crt.c:272) 5 gpc1 0x000022dc start + 60 Thread 0 crashed with PPC Thread State: srr0: 0x0005324c srr1: 0x0200f930 vrsave: 0x00000000 cr: 0x44004242 xer: 0x00000000 lr: 0x00053138 ctr: 0x00008ff4 r0: 0x00000028 r1: 0xbfffed00 r2: 0x00000000 r3: 0x40d29078 r4: 0x40d21e00 r5: 0xfefefeff r6: 0x80808080 r7: 0x00000000 r8: 0x00000000 r9: 0x40d26000 r10: 0x40d25b80 r11: 0x40d25b80 r12: 0x00008080 r13: 0x0033ad0c r14: 0x003455d8 r15: 0x00000001 r16: 0x0044bca8 r17: 0x0033a2fc r18: 0x00300d84 r19: 0x00000190 r20: 0x00300d84 r21: 0x00345be4 r22: 0x404cc4bc r23: 0x00000029 r24: 0xa0001bc8 r25: 0x00340d84 r26: 0x00000000 r27: 0x00000000 r28: 0x40d21e00 r29: 0x40d26f80 r30: 0x40d29078 r31: 0x00053138 Binary Images Description: 0x1000 - 0x443fff gpc1 /Developer/Pascal/gpc-20050331/libexec/gcc/powerpc-apple-darwin8.1.0/3.4.3/gpc1 0x40b54000 - 0x40b5bfff libintl.3.dylib /usr/local/lib/libintl.3.dylib 0x8fe00000 - 0x8fe50fff dyld 43 /usr/lib/dyld 0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x90727000 - 0x90800fff com.apple.CoreFoundation 6.4.1 (368.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x9084b000 - 0x9094dfff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x909a7000 - 0x90a2bfff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90ae3000 - 0x90af5fff libauto.dylib /usr/lib/libauto.dylib 0x91d33000 - 0x91d53fff libmx.A.dylib /usr/lib/libmx.A.dylib 0x92c9b000 - 0x92d89fff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x93614000 - 0x9361cfff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib Model: PowerMac7,3, BootROM 5.1.8f7, 2 processors, PowerPC G5 (3.0), 2 GHz, 1.5 GB Graphics: GeForce FX 5200, GeForce FX 5200, AGP, 64 MB Memory Module: DIMM0/J11, 256 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM1/J12, 256 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM2/J13, 512 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM3/J14, 512 MB, DDR SDRAM, PC3200U-30330 Modem: Jump, , V.92, Version 1.0, Network Service: Built-in Ethernet, Ethernet, en0 Serial ATA Device: ST3160023AS, 149.05 GB Parallel ATA Device: HL-DT-ST DVD-RW GWA-4082B, USB Device: CanoScan, Canon, Up to 12 Mb/sec, 500 mA USB Device: Hub, , Up to 12 Mb/sec, 500 mA USB Device: CF076, CF076, Up to 12 Mb/sec, 500 mA USB Device: Hub in Apple Pro Keyboard, Chicony, Up to 12 Mb/sec, 500 mA USB Device: Apple Optical USB Mouse, Logitech, Up to 1.5 Mb/sec, 100 mA USB Device: Apple Pro Keyboard, Chicony, Up to 12 Mb/sec, 250 mA USB Device: Studio Display, , Up to 1.5 Mb/sec, 500 mA -- <http://www.stairways.com/> <http://download.stairways.com/>

2 2

"reference expected, value given" weird error
by Peter N Lewis 27 Jun '05

27 Jun '05

The following gives the error "reference expected, value given", which is very confusing (it took me ages to spot the problem as being a mismatched procedure type in one of the parameters. I realize error messages are often very difficult, and it looks like in this case, the error was actually changed from "type mismatch in argument 1 of" (see Subject: Protected Var parameter bug in the list archives). You can mark this as a low priority, but it took me quite a while to figure out what was wrong. Peter. gpc -c peterS.pas peterS.pas: In main program: peterS.pas:25: error: reference expected, value given // This program is meant to fail to compile, but would hopefully display a better error message. program PeterS; type SInt16 = Integer attribute( size = 16 ); function InitIcons( var msg: SInt16 ): Integer; begin return 0; end; type StartupInitProc = function( var msg: Integer ): Integer; procedure SetStartup( init: StartupInitProc ); begin end; begin SetStartup( InitIcons ); end. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

Which gpc version is recommended for windows (C and pascal code parts)?
by Peter Radloff 26 Jun '05

26 Jun '05

Hi everybody, I want to start porting a old DOS application written with Metaware Pascal and some C to Windows. I have found gcc 3.2.3 and gpc for the same gcc version (last year). Is this the recommend stable version? Is gpc support complete dead now? No compiled version available for download anymore. No WEB site update,... no hints, archive of mailing list broken long time. Please can somebody give a statement what happend with gpc. I am not sure is gpc the right compiler for this port, if nobody support it. On the other site i like to use of gcc compiler. Only if there is no other way i will switch to Free Pascal or Delphi. Thanks Peter

4 5

Unix compatibility
by Rick Engebretson 26 Jun '05

26 Jun '05

While trying to learn and exploit the unix (linux) platform, my google searches have turned up ms.net references (for example named pipes or fifos). MS is re-learning unix. In unix, software is built as small programs (tools) and assembled via scripting languages into executables. Tool instances are managed as "processes" by the OS itself. This script level approach is similar to compiled level classes, polymorphism, encapsulation, etc, of other languages. But of course, scripts are far simpler and more flexible. Many of these unix tools are quite old, but still useful. For example the cron program is a background job scheduler. Where modern pascal works so well is in building new compiled unix tools. C is just not an option for most applications programmers. So I am less concerned with "new" features than I am with stability and clarity. Both GPC and FPC are fantastic contributions to the world's technical community (on the linux platform). The learning process is very long, so stability and clarity are essential.

6 6

Re: essential pascal
by Frank Heckenbach 24 Jun '05

24 Jun '05

Forwarding from Marco van de Voort (with my comments): : I sometimes see "how does this work in delphi" kind of msgs in the NG. : : I don't know if you are aware of it, but there is a language tutorial for : this that is public (so can be pointed to in the maillist) and quite decent : on : : http://www.marcocantu.com/epascal/default.htm : : It is no deep treatise for a compiler writer, but it might be useful anyawy. Thanks. Though the author makes the usual mistake of claiming that Turbo Pascal supported J&W Pascal, and a few other small factual errors I noticed at a quick glance, it may be useful as a reference sometimes. : (for compiler writer, the quite up to date "keyword/reserved words" list : might be useful, it also lists the other OOP method modifiers besides virtual : and override. (see automated, dynamic, reintroduce, abstract, message) : : Not all might be interesting for your purposes, but reintroduce and abstract : could be. Where is `reintroduce' described? (Couldn't find it browsing through, and the book doesn't seem to have a real index. The keyword list only mentions that is exists.) I suppose `abstract' means the same as in GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

GPC and Mac implicit pointer objects
by Waldek Hebisch 23 Jun '05

23 Jun '05

I have updated my class patch to gpc-2005031. Testing I get failure with fjf903c.pas: TEST fjf903c.pas: /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas:14: error: method `p', overrides parent method /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas: In main program: /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas:31: error: assignment from incompatible pointer type And the question now: what happens if the child tries to make a method with the same name as a parent, but without `override'. Is it an error (like OOP) or maybe just "shadows" parent method? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

5 14

Re: GPC and Mac implicit pointer objects
by Waldek Hebisch 23 Jun '05

23 Jun '05

Peter N Lewis wrote: > >the in the case of overriding `b.dop' prints `b.p'. but in the case > >of shadowing it just prints `a.p', because `b.p' beeing a new method > >gets a new VMT slot, but `b.dop' calls old slot (so old method). > > Ok, I think I understand. When is shadowing used? > In Borland Delphi methods are by default shadowed, and overriden only if `override' is given. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: GPC and Mac implicit pointer objects
by Peter N Lewis 23 Jun '05

23 Jun '05

At 8:19 +0200 22/6/05, Frank Heckenbach wrote: >Peter N Lewis wrote: > >> b) a name in a parent object, with the same parameters (same by type >> anyway, the formal parameter name is not typically checked, although >> GPC typically requires the formal names to match), and must have >> "override" > >The latter condition is a consequence of the fact that all methods >are virtual. If we support/require `override' without >all-methods-virtual in another dialect (mix), this condition >wouldn't apply IMHO. Applying Frank's corrections/clarifications, we have: For a given subclassed object method p, which might be virtual or static, there are three possible parent method states: no method named p in any parent; a static method named p in a parent method; a virtual method named p in a parent method. It is also possible there might be a mix of static and virtual methods named p, only the most recently (object hierarchy wise) defined one is relevant. So that gives six possible combinations: 1. static method p defined and no method named p in any parent Legal. "override" is not allowed. "inherited p" not allowed. 2. virtual method p defined and no method named p in any parent Legal. "override" is not allowed. "inherited p" not allowed. 3. static method p defined where a static method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters do not have to match. 4. virtual method p defined where a static method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters do not have to match. 5. static method p defined where a virtual method named p in a parent Not Legal. Warning emitted and automatically made virtual. See 6. 6. virtual method p defined where a virtual method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters must match. Whether a method is virtual or static depends on whether the "virtual" keyword is there or the dialect "all-methods-virtual" state. Whether override is enabled depends on the dialect "override" state. If the override dialect is enabled, then "override" is required in any of the last four cases. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

GPC and Mac implicit pointer objects
by Peter N Lewis 23 Jun '05

23 Jun '05

With the recently announced move by Apple to convert the Mac platform over to Intel processors (at least initially still closed hardware, but with an Intel processor instead of a PowerPC) starting next year and completing the transition in 2007, the need for Pascal users to move from Metrowerks CodeWarrior Pascal to XCode/GPC (or FPC) is now much more immediate. I presume since GCC can build a fat bundle application for both PPC and x86 that there will not be any problem with GPC doing that too. So the primary problem that remains is the difference between Mac style objects and Borland style objects which we've discussed before. The primary requirement as I see it is the ability to write code where the use of the objects is source compatible (possibly using Macros if necessary), and the object definition has as few changes as possible, preferably also handled by macros. As I see it, the minimal changes required are: 1. Allow objectptr.field as a synonym for objectptr^.field (currently this would be an error, so it is a relatively safe allowance) 2. Allow type newobject = object(objectptr) ... end; (currently this would be an error, so it is a relatively safe allowance) 3. Support the "override" keyword and add a compiler flag to require it. 4. Add a compiler flag to disable the "virtual" keyword and make all methods virtual by default. 5. Preferably add a compiler flag to say "objects are pointers" which simply adds an implicit pointer reference to the object type definition, ie: type myobject = object(superobject) ... end; implicitly becomes type myobject = ^object(superobject) ... end; Without this change, but with the other changes, the user could change the object definition from: type myobject = object(superobject) ... end; to type myobject = ^myrealobject; myrealobject = object(superobject) ... end; which is workable, but a bit ugly to have to do for every object definition. If a small amount of funding would help make this happen, I can look at trying to drum some up (just give me a figure, perhaps off-list). Any possibility of this happening. I'd rather not have to try to delve into the compiler to try to figure this out myself as they are clearly quite technical changes (although generally I suspect mostly not too challenging if you know what you're doing with the compiler source already). Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

8 42

gp and dependencies
by Peter N Lewis 21 Jun '05

21 Jun '05

Adriaan pointed me at the --print-only option of gp, and I was wondering about its use in setting up a Makefile (which is probably pointless since gp does that anyway). I haven't previously used gp, I've only used gpc with perl generate Makefiles. So I figured I'd try using gp. But I'm running in to some problems. First, gp never finished (well, the Makefile compiles everything in a bit over a minute, and gp was still going after 12 minutes, probably not making any progress, but possibly make progress very slowly). I turned on -v and it is endlessly listing out files "compiling implementation because target files not found or not up to date". I use --unit-destination-path and --object-path to keep the source directory unpolluted, and possibly because the names have capitals in them, or perhaps the compile options are not identical, some combination of all that means that gp cannot find the .gpi or .o file when it looks at each source file. So it has to go and compile the source file. But because it is "print only" the output of the compilation is not stored, so GPC has to compile each unit once for each unit it is included in, which is horrendous duplication. The first problem can be resolved presumably by using gp instead of gpc to compile it, and then either the object-path/unit-destination-path will work for both saving them and finding them, or a bug will have to be noted and resolved. But the second problem would appear to be challenging since it would always be the case after a clean rebuild. I don't quite see how this can be resolved, but I don't have a deep understanding of gp or the problem just yet. Hmm, no, it seems worse than that, even without --print-only it is doing much the same thing, endlessly saying it cannot find things. Ahh, hmm, interesting error. If I compile one of my base units, then it endlessly tries to compile GPCMacOSAll.pas - because it cannot find the .gpi or the .o, and so tries to compile it, but then it uses the unit in the unit, and dies recursively. Does --uses actually work in any useful way with gp? Because it appears if the --uses option is on, then gp does not find the pre-existing compiled unit, but you cannot compile it using gp with the --uses flag. So either way it does not seem to work. And even if I remove the --uses option, and the --print-only option then the compilation still seems to be endlessly listing out files it jas to compile. It does seem to make very slow forward progress, but seems to be endlessly recompiling the lower level units, for example: gpc -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__APPLE__ -g -O2 --include=/Source/PNLLibraries/Prefix.GPC --unit-path=/Developer/Pascal/GPCPInterfaces:/Source/PNLLibraries:/Source/MacOSXSupport:/Users/peter/Interarchy/Project/Build/ --object-path=/Users/peter/Interarchy/Project/Build/Objects -I /Users/peter/Interarchy/Project/Build/Objects -I /Users/peter/Interarchy/Project/Build/Objects/ -I /Developer/Pascal/GPCPInterfaces -I /Source/PNLLibraries -I /Source/MacOSXSupport -I /Users/peter/Interarchy/Project/Build/ -I /Users/peter/Interarchy/Project/Build/Objects/ -I . -I /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/units -I /Source/MacOSXSupport/ --unit-path=/Source/MacOSXSupport/ -E -H /Source/PNLLibraries/MyCalcCRC.p #progress+# #progress-# #progress# /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFileSystemUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMemory.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyExtraErrors.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFSXSpecs.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStrNums.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/MacOSXSupport/MyUnixTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFSXSpecs.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyGetString.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLongStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStartup.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date... So basically the same units are being compiled over and over again. It is possible there are implementation unit cyclic dependencies, perhaps that is the problem? It's possibly because some of the units are not successfully compiling because of the lack of --uses since I can't get that to work. So it may come back to the question of "can you use --uses" with gp successfully? I know I need to go and build some smaller examples of the problem, but I figured I'd ask if any of these are known issues first. Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

GDB vs GPC
by Pascal Viandier 20 Jun '05

20 Jun '05

Hi, I use gpc 20050331 build with gcc 3.4.3 on SUN Solaris2.6. I have gdb 5.3 installed, but it does not work very well with gpc: - The current source line is wrong most of the time - 'Next' do strange steps backward and forward - I cannot see strings contents (it says incomplete type) - Arrays of characters are displayed as binary (0's and 1's) - Some randomized gdb coredumps - Program does not stop where I put the breakpoints, but some lines before or after I use DDD on top of gdb, but I have exactly the same problems when I use gdb alone. Since I am presently converting a lot of code from SUN Pascal to gpc, the debugger is somewhat essential... So, is there a 'recommended' version of gdb to use with gpc 20050331? Also, are there some 'recommended' gdb settings for gpc? Thanks Pascal Viandier pascal(a)accovia.com

4 3

Segfault when calling Pascal RuntimeError from within C code
by Markus Gerwinski 18 Jun '05

18 Jun '05

Hi Folks, I attached some test code to this mail that reproduces a bug in GPC that just occurred in one of my projects. In short: When I link a Pascal unit to a C project, and a function in the Pascal unit calls RuntimeError, this results in a segfault when called from within the C code. (I'm using gpc-20050331 together with gcc-3.4.3.) Pure Pascal projects are not affected, there the RuntimeError just works fine. Yours, Markus

3 4

GPC on i686-apple-darwin
by Adriaan van Os 16 Jun '05

16 Jun '05

I installed the x86 version of the Mac OS X kernel (Darwin 7.2.1) on a PC and I am now trying to build GPC-20050331 with gcc-3.3.6 for i686-apple-darwin. I checked that the C compiler bootstraps. The Pascal build stops at heap.pas:38 with the message error.gpi must be recompiled. An rts makefile problem ? I can provide more information as needed. Regards, Adriaan van Os

3 9

Re: Pascal front-end integration
by Adriaan van Os 15 Jun '05

15 Jun '05

James A. Morrison wrote: > I've decided I'm going to try to take the time and cleanup and update > the Pascal frontend for gcc and try it get it integrated into the > upstream source. Can you give us some news on the progress ? Regards, Adriaan van Os

2 1

TclExpect and Pascal
by Rick Engebretson 15 Jun '05

15 Jun '05

The EXPECT extension to TCL is made for controlling and communicating with other user specific programs. Pascal user specific programs would be perfect. TCL was developed at UCBerkeley and Sun. Expect was developed at the US NIST. Nice, stable, well documented, public domain software. Pascal is the weak link. You are very talented people with GPC. I really appreciate CBFalconer's concerns.

2 4

Symbol names clash
by Pascal Viandier 14 Jun '05

14 Jun '05

Hi, While converting some SUN Pascal Code to GNU Pascal, I encounter a problem of symbol name clash: I have a module named 'Screen' that contains (and exports) a procedure named 'Screen'. When I compile the module, there is no problem, but when I want to Import SCREEN in an other module, the compiler produces an error on the Import line saying: bad import, and an other saying 'redeclaration of 'Screen'. So it looks like one cannot have a module and a procedure with the same name. However the two are very different entities - from my point of view -. Are there other possible entities conflicts? (variable or type names) Is there a way to circumvent this problem? Thanks Pascal Viandier pascal(a)accovia.com

2 1

Re: GPC ALPHA 20050331 released
by Adriaan van Os 12 Jun '05

12 Jun '05

Below are the testsuite results for gpc-20050331 with gcc-3.4.3 on powerpc-apple-darwin. Regards, Adriaan van Os [G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2005-06-12 18:33:59 Native configuration is powerpc-apple-darwin7 (G5.local) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: chief56.pas FAIL: fjf1021d.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas FAIL: fjf1021j.pas FAIL: fjf1021k.pas UNSUPPORTED: fjf165a.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: systemtest.pas === gpc Summary === # of tests 4946 # of expected passes 4931 # of unexpected failures 8 # of unsupported tests 7 gpc version 20050331, based on gcc-3.4.3 [G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc343d8/lib/gcc/powerpc-apple-darwin7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --prefix=/Developer/Pascal/gpc343d8 Thread model: posix gpc version 20050331, based on gcc-3.4.3

1 0

Question on procedure parameters
by Pascal Viandier 12 Jun '05

12 Jun '05

Hi, I have a question regarding arrays of characters passed as parameters to procedures. If I declare: Type Str40 = Array[1..40] Of Char; Str80 = Array[1..80] Of Char; Var S40 : Str40; S80 : Str80; S : String(50); Procedure DoArray(SParam : STRING); .. Procedure DoArrayVar(VAR SParam : STRING); ... I can call DoArray with S40, S80 and S as parameter with no problem, but I cannot call DoArrayVar with S40 or S80 (It gives the error: type mismatch in argument 1 of 'DoArrayVar' at compilation time). I don't understand why it works when the parameter is not VAR and why it does not work when it is VAR. To have DoArrayVar work, I had to remove the parameter type, and assign the parameter S to a local variable pointer to a Str80. It works for S40 and S80 but not anymore for S. Is there a way to declare a VAR parameter that would accept S40, S80 and S? Or is there a way to disable temporarily the type checking? Or something else ;-) Thanks Pascal Viandier pascal(a)accovia.com

4 5

[Fwd: Re: source code formatting]
by Maurice Lombardi 12 Jun '05

12 Jun '05

Any body here has a copy ? -------- Message d'origine -------- Sujet: Re: source code formatting Date: Sat, 11 Jun 2005 15:40:29 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: eng(a)pinenet.com Références: <8C73C552CB889D8-BD4-B903(a)mblk-d31.sysops.aol.com> <42AAB4E6.5060907(a)pinenet.com> Rick Engebretson a écrit: > mingeborg(a)aol.com wrote: > >> We have a large GPC application with inconsistent source code >> formatting - unpredictable indentation, several statements on one >> line, etc. >> >> Is there a quick and easy way to fix this? For instance, can any of >> the available GUI interfaces be used to reformat the code? There has been a formatting program pindent written by Peter Gerwinskii. But the goc mailing list and archives are down. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

4 4

TclX with Unix
by Rick Engebretson 11 Jun '05

11 Jun '05

My apologies for rambling on, here. My earlier point was that I believe Pascal has a different context in Unix(Linux) than it did in DOS or with Delphi. Unix has many existing tools that do what Pascal does on other platforms. But Pascal can replace C for low level Unix programming. For those who might be interested, TclX is quite a Unix system shell extension to TCL. The last source version I found was 8.35 at sourceforge. It compiles with TCL8.4, but I'm trying it with TCL8.35. I had problems but I always have problems :) TclX includes system calls to fork, and other process management system calls. Exec can then launch a GPC program. In other words, you can create a process "multiplexer" of many Pascal programs running independently from a controller parent process. Robotics?? Signals are also dealt with in TclX. As well, stdin and stdout can be piped. I don't know much about fifos and sockets and mmaps yet. Since TCL after 8.0 is compiled to bytecode (afaik), it is faster than migh be assumed.

1 0

Default linker names
by Adriaan van Os 11 Jun '05

11 Jun '05

Frank Heckenbach wrote: > Relying on the default linker names was never reliable. OK, but how to solve the following problem, without relying on linker names: - create a Mac OS X dynamic library (dylib) - for that purpose, use a GPC unit "MyDylib" - pass -init _MyDylibInit to ld so that MyDylibInit is called when the dynamic library is loaded - declare a procedure MyDylibInit with attribute( name = 'MyDylibInit') So far no problem, but MyDylibInit ... - first calls GPCRuntimeInitialize (or GPC_Initialize if you like) declared with external name '_p_initialize' (relying on a linker name that may change) - then calls MyDylibUnitInit, the compiler glue that initializes the MyDylib unit. The external name used to be init_Mydylib but has recently changed to _p__M7_Mydylib_init (relying on a linker name again). Regards, Adriaan van Os

2 2

source code formatting
by mingeborg＠aol.com 11 Jun '05

11 Jun '05

We have a large GPC application with inconsistent source code formatting - unpredictable indentation, several statements on one line, etc. Is there a quick and easy way to fix this? For instance, can any of the available GUI interfaces be used to reformat the code? Thanks, - Inga

2 1

Passing by reference
by Adriaan van Os 06 Jun '05

06 Jun '05

Another problem, also reported on the macpascal mailing list and reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo12.pas program avo12; type Str255 = record sLength: Byte; sChars: packed array[1..255] of char; end; function StringToStr255 ( const s: String ) = Result : Str255; begin Result.sLength := Min( Length( s ), 255 ); if Result.sLength > 0 then begin Result.sChars[1..Result.sLength] := s[1..Result.sLength]; end; end; procedure DrawString1( const s: Str255); external name 'DrawString'; procedure DrawString2( protected var s: Str255); external name 'DrawString'; begin DrawString1( StringToStr255( 'Hello')); {OK} DrawString2( StringToStr255( 'Hello')) {Error: reference expected, value given} end. [G5:gcc/p/test] adriaan% gpc avo12.pas avo12.pas: In main program: avo12.pas:19: error: reference expected, value given In gpc-20030830, this was no problem, but now it is no longer allowed, which is quite inconvenient. In the GPC interfaces for Mac OS X, we use the external declaration form with a "protected var" because (according to the gc docs) the "const" declaration form doesn't guarantuee that the parameter is passed by reference, which is an ABI requirement. Regards, Adriaan van Os

5 23

The CRT Unit
by Alex v.Below 06 Jun '05

06 Jun '05

Hello, I am trying to help students use gpc (on Mac OS X, in particular) instead of TurboPascal, which is still taught in some schools: http://macentwicklerwelt.net/index.php?title=Leben_ohne_TurboPascal (Sorry, German only) However, I have been unsuccessful in getting the CRT Unit to work on OS X: I tried to compile the crtdemo.pas in the demo folder, and after searching the mail archives, tried the --automake option. Neither was successful. Is there any other trick in getting the CRT Unit to work? I installed the binary installation of gpc for OS X. If anyone is interested I will gladly post the error output. I am a pretty skilled OS X coder, but my memory of pascal seems to have faded away... Thanks for your help! Alex

9 20

Questions about GPI files and gpc options
by Pascal Viandier 06 Jun '05

06 Jun '05

Hi, I have some questions about gpi files: - What is a difference between file.gpi and file-all.gpi - Are they all necessary? - I set the gpc options --unit-destination-path and --unit-path to a specific directory (which does exists and have the right permissions) but gpi and objects file files are still created where the makefile is. Do I use wrong options? (I have many source files to compile and I don't want to clutter the application's root directory) I work with gpc 20050331 on SUN Solaris 2.6 Thanks Pascal

2 3

Re: RE : bigsetdemo strange result
by Waldek Hebisch 02 Jun '05

02 Jun '05

Pascal Viandier wrote: > Hi, > > At your suggestion, I ran the gpc test suite. > Here is the summary result: > <snip> I had build gpc-20050331 with gcc-3.4.3 on Sparc-Solaris 2.6. I have found one new problem: gpc passed incorrect comparison function to qsort. On Linux it did not matter, but on Solaris it may crash or produce wrong code. There are few other test failures, but I can not reproduce the problem with sets. Could you try the patch below? It fixes the qsort problem. On my machine sets work even without that patch, but in principle that particular bug may cause quite weird problems with sets. BTW, if you re-make, make sure that gpc runtime is re-build (quite likely the runtime got mis-compiled). diff -u p.orig/types.c p/types.c --- p.orig/types.c Thu Mar 31 02:10:15 2005 +++ p/types.c Tue May 31 23:04:05 2005 @@ -201,7 +201,14 @@ static int sce_cmp (const PTR xp, const PTR yp) { - return const_lt (TREE_PURPOSE (*(tree *) xp), TREE_PURPOSE (*(tree *) yp)) ? -1 : 1; + tree c1 = TREE_PURPOSE (*(tree *) xp); + tree c2 = TREE_PURPOSE (*(tree *) yp); + if (const_lt (c1, c2)) + return -1; + else if (const_lt (c2, c1)) + return 1; + else + return 0; } /* Build a constructor node for set elements. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 2

TRIM() wrong behavior or misunderstanding?
by Pascal Viandier 30 May '05

30 May '05

Hi, During some tests I ran with gpc 2050331 to evaluate the gap between SUN and GNU Pascal, I discovered that the function TRIM() is broken when it is passed a packed array of char. The small program bellow shows incorrect result: PROGRAM Trim; VAR St : PACKED ARRAY [1..20] OF CHAR; I : INTEGER; BEGIN WriteLn('Before assignment:'); FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { This shows a series of 0 } WriteLn('After assignment:'); St := 'The String'; FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { This shows the string padded with blanks (CHR(32)} St := Trim(St); WriteLn('After Trim:'); FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { ***This shows the string exactly AS BEFORE! } END. Am I right when I think the function TRIM should replace the blanks with some CHR(0)? Thanks Pascal Viandier

4 3

Pascal-OpenOffice.org binding
by Rick Engebretson 29 May '05

29 May '05

A Pascal binding to OpenOffice (StarOffice) seems possible. Visual Basic for Applications, the macro language bindings, is a lot like object pascal. OO.org uses new terms that are confusing to pascal unix users. But basically, OO.org is a "document object server" that uses TCP-IP over a client-server network. A Java Virtual Machine services the architecture. Pascal runs using the Operating System (or at least that's what I like about pascal). The less "virtual machine" the better. There are several IPC methods; "named pipes or fifos", and "sockets and socketpairs". So there are many types of bindings possible. These two programming environments might combine nicely.

1 0

Question about string type
by Pascal Viandier 28 May '05

28 May '05

Hi, I am porting SUN Pascal code to GNU Pascal. When I first read the GNU Pascal documentation (the pdf manual), I was pleased to see that GNU Pascal strings were in fact records with the length and the string text: this map perfectly with SUN Pascal VARYING[..] OF CHAR we use, since it is a record with 4 bytes for the length and an array of char. So, no porting problem... But now, I see in gdb that a GNU Pascal variable of type STRING(20) is not anymore as in the documentation: There are two fields of type Cardinal holding the capacity and the actual length of the string, plus the array of char. Since the low-level part of our applications are written in C, many of them get Pascal strings as parameters and map them on C struct's. They rely on the SUN Pascal type to find the length and the text. Is there a way (a compiler option?) to have the STRING type map as explained in the documentation, or will have I to modify all the C routines (a big task)? Pascal

4 4

shell scripts using pascal commands
by Rick Engebretson 26 May '05

26 May '05

I've been trying to learn how one would use pascal programs to be used in shell scripts. The original pascal used the program header to specify such input, output interfaces. ie; Program foo(input, output, file1, file2) ; The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this. Building shell commands with pascal seems promising.

4 13

Re: RE : bigsetdemo strange result
by Waldek Hebisch 25 May '05

25 May '05

Pascal Viandier wrote: > Hi, > > At your suggestion, I ran the gpc test suite. > Here is the summary result: > > Test Run By pascal on 2005-05-25 10:45:41 > Native configuration is sparc-sun-solaris2.6 (perfdev) > gpc 20050331, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused > > Nuber of tests: 4947 > Number of Ok: 4828 > Number of tests skipped: 7 > Number of failures: 56 (includes internal compiler error and some > coredumps) > Number of coredumps: 47 > Number of compiler errors: 2 > > > Should I worry? > Something is really broken. At first glance all failures involve sets, so it may be just a single problem. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

bigsetdemo strange result
by Pascal Viandier 24 May '05

24 May '05

Hi, Now that gpc runs, I compiled and tested the bigsetdemo sample program that comes with gpc. I am concerned with that since the SUN Pascal code I must convert to GNU Pascal uses some big sets. The program works, but outputs all the values I enter minus 1. I don't see anything strange in the source so, is there a bug in the 'set' mechanism? Here is a sreenshot of the bigsetdemo program: <Sigourney> bigsetsdemo Enter some numbers between 1 and 100000 (one or several per line). Enter an empty line when finished. 2 56 21 You entered the following numbers: 1 20 55 <Sigourney> bigsetsdemo Enter some numbers between 1 and 100000 (one or several per line). Enter an empty line when finished. 1 8352 76 You entered the following numbers: 75 8351 <Sigourney> Pascal Viandier pascal(a)accovia.com

2 1

Help! Cannot execute any Pascal program!
by Pascal Viandier 24 May '05

24 May '05

I have problems executing Pascal programs build from gpc-20050331. I followed rigorously the directions of the INSTALL file, build and rebuild gcc and gpc many times, always ending with the same problem The problem: ------------ Even the simplest program you can think of produces a segmentation fault. However, the compilation and linking steps give no errors. The sample program: program test1; begin end. I tried to diagnose at my best for a full week, but I am now totally lost. However, I gathered some elements: 1- When I truss the program, I see it enters in an long loop of brk() calls (malloc), until it crashes. End of the truss: brk(0x012D8410) = 0 brk(0x012D8410) = 0 brk(0x012DC410) = 0 brk(0x012DC410) = 0 brk(0x012E0410) = 0 brk(0x012E0410) = 0 brk(0x012E4410) = 0 brk(0x012E4410) = 0 brk(0x012EA410) = 0 brk(0x012EA410) = 0 brk(0x012EE410) = 0 Incurred fault #6, FLTBOUNDS %pc = 0x00019708 siginfo: SIGSEGV SEGV_MAPERR addr=0xEF7FE000 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0xEF7FE000 *** process killed *** * Run the program under gdb: GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.6"... (gdb) b main Breakpoint 1 at $18060: file <implicit code>, line 5. (gdb) r Starting program: /data1/Pascal/tests/test1 Breakpoint 1, $00018060 in main (argc=1, argv=$effff964, envp=$effff96c) at <implicit code>:5 5 <implicit code>: No such file or directory. in <implicit code> (gdb) s Program received signal SIGSEGV, Segmentation fault. _p__rts_Error_S34_Finisherrormessage (N=300) at /data1/Pascal/gcc-3.4.3/gcc/p/rts/error.pas:887 887 s := ReturnAddr2Hex (ErrorAddr); (gdb) p ErrorAddr Address of symbol "Erroraddr" is unknown. (gdb) l 882 begin 883 ExitCode := n; 884 ErrorAddr := CurrentReturnAddr; 885 CurrentReturnAddr := nil; 886 CurrentReturnAddrCounter := 0; 887 s := ReturnAddr2Hex (ErrorAddr); 888 {$local cstrings-as-strings} 889 { @@ stack problem } var foo:CString;foo:=ErrorMessageString;WriteStr (ErrorMessageString, foo, ' (error #', n, ' at ', s, ')') 890 {$endlocal} 891 end; (gdb) p ExitCode Address of symbol "Exitcode" is unknown. (gdb) where #0 _p__rts_Error_S34_Finisherrormessage (N=300) at /data1/Pascal/gcc-3.4.3/gcc/p/rts/error.pas:887 Cannot access memory at address $ef7ff4dc (gdb) s Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) It is strange to see the program jumping right in the middle of the Finisherrormessage() function! I cannot get more information, unless someone helps me. Configuration: -------------- Hardware: gcc-3.4.3 on a Sun Ultra5 with Solaris 2.6 with 384 Mb of RAM Software: gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.3/specs Configured with: ../gcc-3.4.3/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=pascal,c,c++ Thread model: posix gcc version 3.4.3 gpc --verbose Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.3/specs Configured with: ../gcc-3.4.3/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=pascal,c,c++ Thread model: posix gpc version 20050331, based on gcc-3.4.3 I use all the GNU packages suggested in the INSTALL file: bison 1.27 flex 2.5.4a make 3.75 patch 2.5.4 sed 3.02 except for binutils 2.10, that is not recommended with Solaris because of as and ld replacements. Help would be greatly appreciated since I have 450 000 lines of SUN Pascal to convert to GNU Pascal to make our applications platform-independent. Thanks in advance. Pascal Viandier pascal(a)accovia.com

2 1

Temporary web server
by Frank Heckenbach 23 May '05

23 May '05

I've put a copy of the GPC home page on a new web server: http://www2.gnu-pascal.de It is also available on the usual URLs (http://www.gnu-pascal.de etc.), but due to DNS caching it may take a few days until your machine will recognize the change. The mailing list archives are not there yet, and the downloads are missing. Only the latest alpha is there. If some of the contributors would like to put some files there, please PM me at frank(a)g-n-u.de (either send the files directly, even if large, or a URL where I can get them). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www2.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

4 18

Re: gcc-3.4.4 (fwd)
by Russell Whitaker 22 May '05

22 May '05

---------- Forwarded message ---------- Date: Sun, 22 May 2005 13:15:32 -0700 (PDT) From: Russell Whitaker <russ(a)ashlandhome.net> To: Frank Heckenbach <ih8mj(a)fjf.gnu.de> Subject: Re: gcc-3.4.4 On Sun, 22 May 2005, Frank Heckenbach wrote: > Russell Whitaker wrote: > [..] > >> Since have 2 cpu's, tried "make -j3 bootstrap". The c part ran ok, it >> quit in the rts with an error message. > > Which message? Rebuilt it: mkdir rebuild, etc, and "make -j3 bootstrap >msgs 2>&1" Edited the result to be a lot shorter and included it as an attachment. >> Ran gpc's test using gcc-3.3.5 and then gcc-3.4.4, got one new fail: >> avo7.pas > > This is the gcc.c diff. Did you apply it manually? no. Wasn't sure if I should have. Russ

1 0

gnu p compilation on redhat variant
by Patrice Seyed 17 May '05

17 May '05

Hi, As following instructions at: http://www2.gnu-pascal.de/gpc/Compiling-GPC.html#Compiling-GPC In terms of creating symlink to unpackaged "p" and so forth, and the configure line with --enable-languages=pascal, when I then do the "make" I get the following errors at the end: p/declarations.c: In function `mark_binding_level': p/declarations.c:1587: `shared_decl_lang_specific' undeclared (first use in this function) p/declarations.c:1587: (Each undeclared identifier is reported only once p/declarations.c:1587: for each function it appears in.) make[1]: *** [p/declarations.o] Error 1 make[1]: Leaving directory `/home/apseyed/software/gcc-3.2.3/gcc' make: *** [all-gcc] Error 2 Any help appreciated. This is a system based on RHEL 3. I tried the gpc rpm binary that runs on rh 6 and received the error: ld: cannot open crtbegin.o: No such file or directory Thanks, Patrice Seyed Linux System Administrator - LinGA RHCE, SCSA Boston University Medical Campus

2 1

Re: RE : gnu p compilation on redhat variant
by Patrice Seyed 17 May '05

17 May '05

Thanks and you were correct: p/lang.c:1236: conflicting types for `lang_mark_tree' ggc.h:184: previous declaration of `lang_mark_tree' p/lang.c: In function `lang_mark_tree': p/lang.c:1237: invalid type argument of `->' p/lang.c:1243: invalid type argument of `->' p/lang.c:1249: invalid type argument of `->' p/lang.c:1249: invalid type argument of `->' p/lang.c:1251: invalid type argument of `->' p/lang.c:1260: invalid type argument of `->' p/lang.c:1260: invalid type argument of `->' p/lang.c:1262: invalid type argument of `->' make[1]: *** [p/lang.o] Error 1 make[1]: Leaving directory `/home/apseyed/software/gcc-3.2.3/gcc' make: *** [all-gcc] Error 2 not having much success with p2c either. -Patrice -----Original Message----- From: Pascal Viandier [mailto:pascal@accovia.com] Sent: Tuesday, May 17, 2005 1:10 PM To: 'Patrice Seyed'; gpc(a)gnu.de Subject: RE : gnu p compilation on redhat variant Hi, I have the same problem under Solaris - among others - with gpc-20050331. I fixed it this this way: In declarations.c Line 1587 was not compiling because of shared_decl_lang_specific undefined ggc_mark (shared_decl_lang_specific); I replaced it by: ggc_mark (level->shared_decl_lang_specific); Then it passed. But, be prepared to have other compilation problems after this one... Anyway, even when I fixed the compilation errors, the gpc1 compiler crash on some Pascal sources (string1.pas in rts directory for example) Pascal Viandier -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Patrice Seyed Envoyé : May 17, 2005 12:56 À : gpc(a)gnu.de Cc : apseyed(a)bu.edu Objet : gnu p compilation on redhat variant Hi, As following instructions at: http://www2.gnu-pascal.de/gpc/Compiling-GPC.html#Compiling-GPC In terms of creating symlink to unpackaged "p" and so forth, and the configure line with --enable-languages=pascal, when I then do the "make" I get the following errors at the end: p/declarations.c: In function `mark_binding_level': p/declarations.c:1587: `shared_decl_lang_specific' undeclared (first use in this function) p/declarations.c:1587: (Each undeclared identifier is reported only once p/declarations.c:1587: for each function it appears in.) make[1]: *** [p/declarations.o] Error 1 make[1]: Leaving directory `/home/apseyed/software/gcc-3.2.3/gcc' make: *** [all-gcc] Error 2 Any help appreciated. This is a system based on RHEL 3. I tried the gpc rpm binary that runs on rh 6 and received the error: ld: cannot open crtbegin.o: No such file or directory Thanks, Patrice Seyed Linux System Administrator - LinGA RHCE, SCSA Boston University Medical Campus

1 0

types for ncurses
by willett 17 May '05

17 May '05

Frank Heckenbach: Apologies for duplication, but you replied to subsequent messages and a copied part of this one, so I'm guessing you didn't see the questions below. I'm responding to your complex (to me) message about ncurses types and automatic configuration for multiple hosts. Any verification or correction of my approach would be appreciated. Earlier Message from willett(a)udel.edu: Frank, thanks very much for all your advice. I'm trying to get up to speed here. Ok, based on your message, I'm now using: MedCard for chtype in ncurses.h (assuming typedef unsigned long chtype) CBoolean for "bool" in ncurses.h (assuming typedef unsigned int bool) CBoolean for an "int" which contains only TRUE or FALSE CInteger for an "int" used as an integer (on older gpc I use "integer") tacs now uses index of char128 = #0 .. #127 The c translation types are very useful! Thanks. Did I understand you to say I should use CBoolean in both the above cases? To create the ncurses.h file, I have to run ./configure within the ncurses source directory. I could run this several times for different hosts, to find what the range of types are. Right? Could you suggest a couple of different hosts to try out? Say, the most common? or perhaps, the most different? or better, how do I read the configuration file directly? I see that "configure" is a readable text file, but I can't find a list of alternative "bool" (for example) definitions in that configuration file. In fact, I can't figure out what my own host (Mac OSX) is called, when I try ./configure host=powerpc-apple-darwin I get an "unknown host" message. Any suggestions? When you said: > BTW (unrelated), I'd suggest to rename the package to > `gpc-ncurses-...' or `ncurses-gpc-...', to avoid confusion with an > ncurses library package. Did you mean I should name the interface file, e.g. ncurses.pas -> gpc-ncurses.pas or the unit, e.g. unit ncurses; -> unit gpc-ncurses; (If the latter, wouldn't gpc_ncurses be a more standard Pascal name than gpc-ncurses?) To do more things like reading the ncurses.h headers and then automatically configuring ncurses.pas types to be consistent, that's a bit beyond me. Beyond, both in that I wouldn't know how to and that I don't have time to learn how to and test all these. I wouldn't want to write c wrappers, a lot of work and then we're stuck with double calls. What I'm thinking now is to use all your MedCard, CBoolean, etc types, and put in documentation warning about what types of hosts would need edits before use. and/or how to check ncurses.h and hand-modify ncurses.pas. Does this approach and the above modifications seem reasonable? Willett Kempton

6 10

Internal gpc compiler error
by Angelo.Fumagalli＠alcatel.it 16 May '05

16 May '05

Hello, running gpc testsuite (gpc version 20041218, based on gcc-3.2.3) on x86_64-unknown-linux-gnu environment we have as result that 78 tests failed, some are related to an Internal compiler error on the same file: Internal compiler error in classify_argument, at config/i386/i386.c:1841 This internal compiler error was detected also compiling some of our own pascal modules ported under gpc. In attachment you find included the gpc testsuite log file. Some advise? Regards. Angelo Fumagalli

3 8

-mlong-double-128
by Adriaan van Os 13 May '05

13 May '05

The following produces an internal compiler error: [G4:~/gnu/testgpc/adriaan] adriaan% cat compare.pas program Compare; procedure R ( var r1, r2: real); begin if r1 <> r2 then r1:= r2 - 1.0 end; begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o compare compare.pas -mlong-double-128 compare.pas: In procedure `R': compare.pas:6: error: unrecognizable insn: (insn 26 34 27 2 0x0 (set (reg:SI 126) (subreg:SI (reg:TF 33 f1) 0)) -1 (nil) (nil)) compare.pas:6: internal compiler error: in extract_insn, at recog.c:2175 It may be, of course, that the Darwin target doesn't properly support the -mlong-double-128 PowerPC processor option. If it's a gcc back-end bug, I can report it to Bugzilla. However, the "real" type used is 64-bit on the Darwin target, with or without -mlong-double-128 ... The option only changes the size of the "longreal" and "extended" types to 128-bit. Regards, Adriaan van Os [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3

6 15

Re: Who uses Pascal?
by Garth Fletcher 11 May '05

11 May '05

I use it for a CAD system widely used in commercial Jacquard weaving (where the design is woven into the fabric) of upholstery, decorative and apparel fabrics, throws, etc. About 250,000 lines of code of which 96%+ is Pascal, a bit less than 4% assembler for bottleneck procedures. You may be wearing, sitting on, or wrapping yourself in something designed with a Pascal program... -- Garth Fletcher, JacqCAD International JacqCAD MASTER website: www.JacqCAD.com

2 1

Pascal Macro Compiler
by Contestcen＠aol.com 09 May '05

09 May '05

The first release of the Pascal Macro Compiler is now available. The Pascal Macro Compiler is a preprocessor or code generator for the Pascal language. It can generate Pascal expressions, statements, declarations, functions and procedures, up to complete Pascal programs. A small library of macros, such as a sort generator, is provided. The complete Pascal Macro Compiler User Manual is found online at http://www.pascalmacro.com I will make a few demo copies available at no cost. Frank Rubin

1 0

ProcPtr question
by Alain 07 May '05

07 May '05

Maxbe 'stupid' ... But I'm dealing with it ! ---------------------------------------- Type ptrRecord = ^theRecord; Type theRecord = record move : ProcPtr; hit : ProcPtr end; Procedure moveIt; Begin end; Procedure hitIt; Begin end; Procedure Init; Begin object^.move := @moveIt; object^.hit := @hitIt end; Procedure Run; Begin repeat with object^ do ???? Until ... End; ---------------------------------------- HOW can I make the actions point to moveIt and hitIt ? HOW is it possible to call the ProcPtr's procedures (Osx.3, GNU pascal) ? If you can help me, thank you ! Alain

3 3

ShortString
by Prof A Olowofoyeku (The African Chief) 06 May '05

06 May '05

Hi Would it be possible to predefine "ShortString" in GPC? (as "String [255]"). I appreciate that GPC doesn't yet have longstrings so this may seem pointless - but I can't see any harm in having ShortString already defined (at least, in Delphi mode). Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 3

small ncurses demo
by Rick Engebretson 06 May '05

06 May '05

Here is an example of the gpc-ncurses "software label key" terminal display : ======================================================= > program slk ; > > uses ncurses ; > > > > var > label1, label2, label3, label4, label5, label6, label7, label8 : > CString ; > n : int32 ; > > begin > n := slk_init(1); > stdscr := initscr ; > n := start_color ; > > label1 := 'one' ; > label2 := 'two' ; > label3 := 'three' ; > label4 := 'four' ; > label5 := 'five' ; > label6 := 'six' ; > label7 := 'seven' ; > label8 := 'eight' ; > > n := slk_set(1, label1, 1); > n := slk_set(2, label2, 1); > n := slk_set(3, label3, 1); > n := slk_set(4, label4, 1); > n := slk_set(5, label5, 1); > n := slk_set(6, label6, 1); > n := slk_set(7, label7, 1); > n := slk_set(8, label8, 1); > > n := slk_refresh ; > > > n := init_pair (1, COLOR_RED, COLOR_BLUE ) ; > n := attron ( COLOR_PAIR(1)) ; > > n := getch ; > > n := endwin ; > end. > It especially looks nice on a SuSE 8.1 xterm. If the __p* name conflict gets resolved, gpc-libplot will complement nicely.

2 2

bug: ncurses + slackware 10.0, 10.1
by Russell Whitaker 01 May '05

01 May '05

Hi Program below illustrates a bug: lower case a, lower case f thru z, and number 0 are printed with graphic characters. This bug did not appear in earlier versions of slackware. If you make the window with a frame around it, (uncomment the framewin line) the characters are printed normally, and afterwards any window written to is also printed normally. program ncurtest; uses GPC, GPCUtil, CRT, FrameWin; var submenu : WinState; Data : array[1..3] of string( 32 ) = ( 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz', '0123456789'); i : integer; begin i := (ScreenSize.X - 32) div 2; MakeWin( SubMenu, i, 2, i + 32, 7 ); { FrameWin('HELP: hit Enter to exit', DoubleFrame ); } FillWin( ' ', 16 * Blue ); HideCursor; for i := 1 to 3 do WriteStrAt( 2,i, Data[ i ], 16 * Blue + LightGray ); end. Russ Note to support(a)slackware.com, bug-ncurses(a)gnu.org: gpc(a)gnu.de is a pascal mailing list unit CRT is a pascal interface to ncurses

4 8

GPC ALPHA 20050331 released
by Frank Heckenbach 29 Apr '05

29 Apr '05

I have uploaded a new alpha version of GPC to <http://www.gnu-pascal.de/alpha/>. This is an ALPHA version. Not so many extensive tests have been made and the test suite is not expected to pass without errors. I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work. New features: * new options `--[no]-nonlocal-exit' (default in `--ucsd-pascal' and `--mac-pascal') (fjf988[fijk].pas, fjf1062*.pas) (U) (M) * new options `--[no]-object-checking' (on by default) to check on virtual method calls if VMT pointer is not nil and has matching `Size' and `NegatedSize' entries, new options `--[no]-range-and-object-checking' which are now equivalent to `$R[+-]' (fjf1053*.pas) (B) * new options `--[no]-pointer-checking', `--[no]-pointer-checking-user-defined'; new variable `ValidatePointerPtr' (fjf1052*.pas, pcerrorc.pas) (these options are _off_ by default!) * new options `--[no]-implicit-result' (fjf1022*.pas) (on by default *only* in `--delphi' mode!) (D) (@) * new options `--{en,dis}able-predefined-identifier' (fjf1037*.pas) - Bug fixes: * check initializers of unused types (fjf898*.pas) * check identifier scopes stricter (az25.pas, fjf1059*.pas) * in `--borland-pascal' give only a warning, not an error, for duplicate `case' elements (drf6*.pas) * multi-dimensional `packed' arrays are not correctly packed (fjf149*.pas) * check arithmetical overflow in constants somewhat better (fjf206*.pas) * check duplicate external declarations stricter (fjf948.pas) * check that actual discriminants match in parameters and assignments, and in strict EP mode, check that actual discriminants of parameters within one identifier list match (berend4.pas, fjf104[45]*.pas, typeof[2-4].pas) * check pointer to schema types stricter (fjf130.pas, fjf614.pas, schema3a.pas affected) * allow importing the same value as a result of distinct expressions under the same name for EP modules for ordinal, pointer, string and set constants (fjf1040*.pas, stef1.pas) * allow attributes for procedural types (chief56.pas) * problem with string operations and `goto' (contour0.pas, contourbug.pas, martin1.pas, berend3.pas) * check `goto' targets more strictly <261020020000077022%gpaeper(a)empirenet.com>, <Pine.LNX.4.44.0210281004000.31943-100000(a)duch.mimuw.edu.pl> (az48.pas, fjf701*.pas, fjf1038*.pas, gale6.pas) * `Result' is not completely Delphi compatible (fjf1022*.pas) * problem if a `Write' or `WriteLn' argument calls a routine which writes to the same file (fjf1036.pas) * `Update' as well as writing after reading or checking `EOF' can get the file position wrong in some cases (arp2*.pas, fjf159.pas, fjf160*.pas) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

9 37

better framebuffer upload
by Rick Engebretson 26 Apr '05

26 Apr '05

I just uploaded a better formatting of the framebuffer draw stuff. http://www.pinenet.com/~eng/fbDraw.html Same code as before. Just better formatting. It should work. It probably has some debug stuff still in it. Certainly not done.

1 0

Portability issues
by Rick Engebretson 26 Apr '05

26 Apr '05

Maintaining a broadly portable compiler is no easy task. But it seems clear that the Unix-like OSs are the future. Today I took time to read up on signals, IPC, terminals (ie; any serial character device). Of course all the system calls are unreadable C. Readable Object Pascal on a powerful Unix desktop. For a guy who started by feeding punched cards with fortran; wow. Great progress. Thanks.

1 0

curses and graphics window
by Anonymous 23 Apr '05

23 Apr '05

I want to move beyond my TurboPascal program in DOS. Can I keep my character based menu (very fast, compact, and efficient with screen space) for the interface, and open a graphics window for the data graphing? KDE with Qt are daunting, while Curses is appealing. Thanks.

3 4

dereferencing untyped pointer
by Prof A Olowofoyeku (The African Chief) 23 Apr '05

23 Apr '05

Hi How does one get rid of the "dereferencing untyped pointer" error without endless typecasting? Is there a switch or compiler directive? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

8 18

Re: bug: ncurses + slackware 10.0, 10.1
by Frank Heckenbach 11 Apr '05

11 Apr '05

Thomas Dickey wrote: > On Sun, 10 Apr 2005, Frank Heckenbach wrote: > > > Russell Whitaker wrote: > > > >> Program below illustrates a bug: lower case a, lower case f thru z, > >> and number 0 are printed with graphic characters. This bug did not > >> appear in earlier versions of slackware. > > With the given example, I see a difference which I assume is what you're > talking about: if I run the sample in Linux console, linked against > ncurses 5.4 (or current), I'm seeing the cells 32-127 as line-drawing. > (Cells 0-31 are control characters, and are blank). > > Running against ncurses 5.3 or earlier, I don't see line-drawing. > > In each case, cells 128-255 are displaying the PC-specific font (some > double-width lines, etc). Indeed 128-255 are ok in all versions I tried. (I left 0-31 out of the test to avoid side-effects, and they don't seem relevant here.) > Since the difference is in how cells 32-127 are displayed, I assume that's > the issue. (Though the comments about direct access to the PC font are > a little confusing to me...). > > I agree with part of this. The part that I don't agree with is the > assumption that setting A_ALTCHARSET would in some cases not try to use > the terminal's alternate character set. (The sample code sets it in every > cell). Yes, it does, but in addition to setting smacs/rmacs ncurses does some internal remapping by means of real_map[] which it didn't do before AIUI. > > Anyway, the affected characters are all printable ASCII characters > > which are the same, at least in the IBM PC character mapping and > > probably most other fonts, so if necessary I could just turn off > > A_ALTCHARSET for those characters (#if 0 in the example below). > > yes - that sounds right. > > Bear in mind that you're actually using the smpch/rmpch feature, which > happens to work because smacs/smpch and rmacs/rmpch are the same strings. > I seem to recall that long ago ncurses had something like A_PCCHARSET > to distinguish these, but since it was not part of X/Open curses, that > was dropped. It was still available, I could probably use it, but now, A_ALTCHARSET is the only way to get at the font directly, isn't it? > > Is this the recommended thing to do, or is there another way to get > > direct access to all characters of the underlying font (on the Linux > > console)? > > As I understand the issue yes (though actually there's underlying font for > cells 32-127, which you don't seem to want). Maybe we have different definitions of underlying font, but in the end, we seem to mean the same. What I mean is the font as loaded which has the standard ASCII characters in 32-127 (and other characters such as line drawing in higher positions), and I want to output them just this way. Since ncurses remaps some of the ASCII characters, and since they're usually mapped 1:1 to the font anyway, I think I should just not set A_ALTCHARSET for those charaters as my patch did. If that's just it, I think we can consider the issue solved. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Strange error message in GPC20050331
by Markus Gerwinski 11 Apr '05

11 Apr '05

Hi folks, the line: if getMouseButtonPressStream^ .getLastEvent^ .getTarget = fLastEvent^ .getTarget then results in an error message: alpevents.pas:1255: error: invalid type of argument of `^' The error message disappears if I change the line into: if ( getMouseButtonPressStream^ .getLastEvent )^ .getTarget = fLastEvent^ .getTarget then What's that? Regards, Markus

2 4

"pos" and whole words
by Prof A Olowofoyeku (The African Chief) 10 Apr '05

10 Apr '05

Hi I have been trying to implement a "pos" function that only matches whole words. Below is my best effort. Is there a more efficient (or "better") way of implementing this? Thanks. { a "pos" function that matches whole words only } function PosInString (const sub, str : String) : Cardinal; Const nSeparators = ['a'..'z', 'A'..'Z', '0'..'9']; { non-separators } Var i, j : Cardinal; begin result := 0; If (sub = '') or (str = '') then Exit; i := pos (sub, str); { any match? } if (i = 0) then exit; { search for whole words only } result := i; j := length (sub) + i; if (i = 1) or ((i >1) and (Not (str [pred (i)] in nSeparators))) then begin if (j < length (str)) and (str [j] in nSeparators) then result := 0; end else result := 0; end; { test: correct results in comments } begin writeln (PosInString ('adam', 'he is adamant')); {0} writeln (PosInString ('adam', 'why is he so adamant about it?')); {0} writeln (PosInString ('adam', 'he knows about adam ant')); {16} writeln (PosInString ('adam', 'adam and eve')); {1} writeln (PosInString ('adam', 'eve and adam')); {9} writeln (PosInString ('adam', 'eve and adam ate the apple')); {9} end. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

7 13

framebuffer dev note
by Rick Engebretson 09 Apr '05

09 Apr '05

In playing with framebuffer drawing efforts, something interesting came up. In brief (so as not to bore everyone) the same draw program and unit works differently between fpc and gpc. But neither work. I suspect it is in the rewrite and/or blockwrite functions. I'm using 16bit pixels so I'm dealing with converting 16 bit to byte writes. Anyway, for a simple red horizontal line on a solid background. Fpc gives me two red lines on a clean blue background. While gpc gives me a single red line on a spotted blue background. Also, gpc gave me the proper error code for using blockwrite on a typed file. Conclusion; a bad program performs differently on fpc and gpc.

3 14

[Fwd: Re: Link/Load problem using gpc Trap unit]
by Maurice Lombardi 07 Apr '05

07 Apr '05

-------- Message d'origine -------- Sujet: Re: Link/Load problem using gpc Trap unit Date: Thu, 07 Apr 2005 18:17:09 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: Angelo FUMAGALLI <Angelo.Fumagalli(a)alcatel.it> Références: <E1DIUER-00032L-00(a)hera.math.uni.wroc.pl><1112730270.11406.474775(a)goedel.fjf.gnu.de><003901c53b74$ef09f720$7c286297@Fumagalli> <1112886396.968.886374(a)goedel.fjf.gnu.de> <013601c53b8c$5a79a930$7c286297@Fumagalli> Angelo.Fumagalli(a)alcatel.it a écrit: > gpc pi.o ulib.a gpclib.a gcclib.a -o p.exe gpclib.a or libgpc.a ?? > > to solve the undefined reference have I also to link the trap.o and trapc.o > files??? yes, everything you need in that case, but when you link with gpc (instead of ld) it finds himself libgpc.a and libgcc.a (so a wrong name may succeed). Try to use the option -v to see what is done. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Environment Variables
by Andy Ball 06 Apr '05

06 Apr '05

Hello, How do I read an environment variable from my gpc Pascal program? This should enable me to accept data input via a form on the Web. - Andy Ball

8 14

Who uses Pascal?
by John Ollason 06 Apr '05

06 Apr '05

Greetings, I follow the postings on the mailing list with interest but seldom feel that I have anything to contribute. I am becoming concerned that some fundamental questions that we ought to address are simply being ignored. The most important question is Is Pascal a dead language? This might look like flame bait, but it isn't. Evidently the development of GPC presents a variety of interesting technical problems in the construction of a portable compiler, but the solution of such problems, though interesting in itself, deteriorates into navel-gazing if there isn't a group of users, reasonably sophisticated programmers who use write programs in Pascal. While there is a cohort of people like me who learnt Pascal in the '70s and '80s, the language is no longer taught in the introductory courses in programming at Aberdeen University of which I am a member, and as far as I can discover it certainly is not taught at school. With the decreasing number of recruits to the population of Pascal programmers it seems to me that Pascal is dying out and there is little anybody can do to conserve it. Perhaps my perceptions are mistaken, perhaps there is still a thriving process of recruitment to the ALGOL tradition, but I fear that the recruitment is not happening in Britain and certainly not in America. I belong to a fortunate group of programmers, those whose first language was ALGOL 60, trapped for a while with FORTRAN 4---What a dog's dinner after ALGOL!--- forced on to PL/1---a dog's banquet after FORTRAN---starvation rations then with BASIC, then the revelation of Pascal, which I started to use in 1978 and have used ever since as my favoured language, currently using GPC under linux. My programming is entirely scientific, simulating dynamical systems of interacting animals. I have no interest in GUIs and all my programs work from the command line. With a colleague I used to teach an introductory programming course for students with an interest in ecological modelling, using Level 0 ISO Pascal. Now, I believe introductory courses are taught using Visual BASIC or Java, neither of which, it seems to me, have the elegance and security of Pascal. So the base of users in my immediate vicinity is shrinking year by year, and to my eyes the quality of programs written by graduate students and postdocs is much worse now than it was when Pascal was the first language learnt. After all when you have learnt how to program in Pascal, you can write Pascal in any language, even PERL. So the question is Where is Pascal taught and used? I don't think that it's in computing science departments: my contact with computer scientists suggests that they regard themselves as far too grand for code-bashing. I suspect that the language is primarily used by what we might call gentleman-programmers, people who need fairly elaborate programs for their work that don't fit easily into the Mathematica, Matlab, systems, but which, for all that, require fairly sophisticated number crunching. Typically such programs are used by the programmers who write them, and so there is little need for fancy user (noddy) friendly interfaces. So who uses Pascal now? Who teaches Pascal now? Anybody interested in discussing these matters? John O.

7 12

[Fwd: Re: GPC ALPHA 20050331 released]
by Maurice Lombardi 06 Apr '05

06 Apr '05

-------- Message d'origine -------- Sujet: Re: GPC ALPHA 20050331 released Date: Tue, 05 Apr 2005 11:16:46 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: James A. Morrison <jim.morrison(a)gmail.com> Références: <1112304080.8194.673009(a)goedel.fjf.gnu.de> <676645fc050331161525d4e1e2(a)mail.gmail.com> <42516C85.5000803(a)ujf-grenoble.fr> <676645fc05040410363c400c7(a)mail.gmail.com> James A. Morrison a écrit: >>> A diff is available at >>>http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503.diff.gz >> >>I have tried to use it because of current gpc server unavailability. >>I does not work as is because of missing files, >>notably predef.h which was renamed as predef.def. >> > > > A new diff is at > http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503-1.diff.gz Thanks I used it to compile with gcc-3.2.3 / DJGPP Success, with the following results of the test suite Test Run By dosuser on 2005-04-04 21:39:45 Native configuration is djgpp (KNAUTIE) # of tests 4946 # of expected passes 4938 # of unexpected failures 6 # of unsupported tests 2 c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20050331, based on gcc-3.2.3 in detail: TEST fjf1021d.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021d.pas:7: expressions with side-effects are not allowed in schema types failed TEST fjf1021h.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021h.pas:6: expressions with side-effects are not allowed in schema types failed TEST fjf1021i.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021i.pas:8: expressions with side-effects are not allowed in schema types failed TEST fjf1021j.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021j.pas:6: expressions with side-effects are not allowed in schema types failed TEST fjf1021k.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1021k.pas:7: expressions with side-effects are not allowed in schema types failed TEST fjf1044s.pas: c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1044s.pas: In procedure `p': c:/djgpp/b/gnu/gcc-3.23/gcc/p/test/fjf1044s.pas:36: Internal compiler error in expand_call, at calls.c:3078 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available Rather good, only fjf1044s is new w/r to the previous alpha. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: Who uses Pascal? Part 2
by Andrew Gregory 06 Apr '05

06 Apr '05

> -----Original Message----- > From: Frank Heckenbach [mailto:ih8mj@fjf.gnu.de] > Sent: 05 April 2005 12:23 > To: gpc(a)gnu.de > Subject: Re: Who uses Pascal? Part 2 > > > Andrew Gregory wrote: > > > I think that Pascal is still one of the better compiled languages. > > For someone who wants to write GUI applications on Windows, Delphi > > is a good choice because of features such as the form designer. > > But things have moved on: Powerful dynamic scripting languages > > such as Python contain a lot of new thinking, and really do save > > time in many applications (e.g. data processing). There is a good > > case for writing core functions (e.g. maths) in a compiled > > standardised language such as Pascal or extended Pascal, which > > will be around for decades, then writing interfaces to scripting > > languages as required. Unfortunately, to interface Python and gpc, > > you have to go via C, so for new code it's tempting just to use C. > > But what does "go via C" actually mean? I remember a joint project I > did with a C++ programmer. We also "went via C" which means he wrote > `extern "C"' and I wrote `external name' etc. No actual C code was > involved (apart from the GMP library which is written in C (and > assembler) and was used by both Pascal and C++ parts of the > program). So "going via C" doesn't have to mean more than using a > simple (i.e., only types available in C, no schemata, templates or > objects etc.) and well-defined (no name-mangling) calling interface. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html > GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 > 4C9D 0FE0 E5E8 > At the highest level Python is a "typeless" language - all of the parameters supplied to a function are references to objects of type PyObject (as Python is written in C I assume that a PyObject is a C struct although I've not looked into this in detail). A PyObject may contain a float, string, complex etc., or a sequence of references to other objects. Dynamic typing (i.e. type checking at run time rather than compile time) is a feature if Python. Python library functions (prototypes in Python.h, binary library libpython24.a) such as PyComplex_AsCComplex for example must be called for type checking and for conversions to C types at run time. Correct me if I'm wrong, but as far as I know you cannot do that directly from Pascal without quite a lot of work to get Python.h and the many include files within into a Pascal-compatible form. Therefore you have to use C or C++. If you declare a file of C externs for your Pascal procedures and functions, you can generate Python wrapper interface code automatically using SWIG (www.swig.org) although this is not always worthwhile. I've interfaced several Pascal mathematical libraries to Python via C - it doesn't take that long and the results are excellent. Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire RG27 9UY United Kingdom -------------------------------------------------------------------

3 2

Re: Who uses Pascal? Part 2
by Andrew Gregory 05 Apr '05

05 Apr '05

> On Thu, 31 Mar 2005, John L. Ries wrote: > > > On Thu, 31 Mar 2005, John Ollason wrote: > > > > > My main reason for asking the question was to try to find > out if there > > > would be any interest in a modern primer, based on GPC, > as an introduction > > > to scientific programming. Years ago, with a colleague, > we talked of > > > writing a book entitled 'Brute force programming' which > was designed for > > > scientists. One very important group of users are those who need to maintain legacy code. I have a mix of programs written in C, C++, VMS and HP Pascals, and Fortran 77, in some cases written 20 years or more ago. I converted the whole lot to Python modules. The result: A huge improvement in usability, as I can use all these modules from simple scripts. I can now do many things easily that were previously too awkward and time-consuming to contemplate. Furthermore, the use of GCC compilers will help portability. Users of these modules need only know one language - Python (which is an Algol family language). I think that Pascal is still one of the better compiled languages. For someone who wants to write GUI applications on Windows, Delphi is a good choice because of features such as the form designer. But things have moved on: Powerful dynamic scripting languages such as Python contain a lot of new thinking, and really do save time in many applications (e.g. data processing). There is a good case for writing core functions (e.g. maths) in a compiled standardised language such as Pascal or extended Pascal, which will be around for decades, then writing interfaces to scripting languages as required. Unfortunately, to interface Python and gpc, you have to go via C, so for new code it's tempting just to use C. I suspect that many of the Pascal books are now out of print. I once used "Pascal Programs for Engineers and Scientists", author Alan R Miller, published in 1985. I don't think that I'm qualified to say how big a market there would be for the proposed new book. Although I don't contribute much to this list either, I would like to say thank you to the maintainers of gpc for improving it and keeping it up to date with GCC. Andrew Gregory. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire RG27 9UY United Kingdom -------------------------------------------------------------------

2 1

Re: GPC ALPHA 20050331 released
by Waldek Hebisch 04 Apr '05

04 Apr '05

Since the WWW server seem to be down I have put a copy of "minimal" snapshot at my web page: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20050331-minimal.tar.bz2 Note that this requires that you have bison-2.0. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: GPC ALPHA 20050331 released
by James A. Morrison 04 Apr '05

04 Apr '05

> > A diff is available at > > http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503.diff.gz > > I have tried to use it because of current gpc server unavailability. > I does not work as is because of missing files, > notably predef.h which was renamed as predef.def. > A new diff is at http://www.csclub.uwaterloo.ca/~ja2morri/pascal/200502-200503-1.diff.gz -- Thanks, Jim http://phython.blogspot.com

1 0

Who uses Pascal? Part 2
by John Ollason 01 Apr '05

01 Apr '05

My main reason for asking the question was to try to find out if there would be any interest in a modern primer, based on GPC, as an introduction to scientific programming. Years ago, with a colleague, we talked of writing a book entitled 'Brute force programming' which was designed for scientists. The design cycle was based on our appreciation of the fact that for our modelling work most of the time was spent on the development of the code, and only a small proportion spent on production running. This meant that we weren't concerned with saving bytes or running efficiently. All we wanted was to get our ideas coded and tested as conveniently (for us) as we could manage. We were teaching ISO Pascal level 0 at the time and thought that this would be the ideal language for our purposes. I am not sure that there is enough interest to make it worthwhile, or indeed, if our irresponsible approach would be valued by the wider programming community. John O.

3 4

gcc 3.4.4 diff
by James A. Morrison 01 Apr '05

01 Apr '05

Hi, I'm trying to compile gpc with gcc 3.4 from cvs. To get gcc patched for gcc 3.4.4 I needed the attached diff. The only real change is in varasm.c:3610 where dest_type is used instead of TREE_TYPE (value) and src is used instead of TREE_OPERAND (value, 0) -- Thanks, Jim http://phython.blogspot.com

1 0

gpc-20050331 test results
by Russell Whitaker 01 Apr '05

01 Apr '05

hi Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs Configured with: ../gcc-3.3.5/configure --enable-languages=c,pascal Thread model: posix gpc version 20050331, based on gcc-3.3.5 test results were: # tests 4946 # expected passes 4940 # unexpected fail 5 # unsuported 1 failures were: fjf1021d.pas, fjf1021h.pas, fjf1021i.pas, fjf1021j.pas, fjf1021k.pas as these look alot alike, tried this: program modtest; var a: integer = 42; type t(b:integer) = integer value b mod 4; var b:t(99); begin writeln(b); end. and the result i got: <implicit code>: In main program: <implicit code>:10: internal compiler error: in make_decl_rtl, at varasm.c:797 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. Over all: GOOD JOB russ

1 0

Who uses Pascal.
by Anonymous 31 Mar '05

31 Mar '05

Pascal numbers _are_ dwindeling. Very slowly but surely. It reminds me a bit of Apple before Mac OS X. Not many desert, but the ones that do are not replaced. I agree with Tom that there is still quite some use in the Brazil and Eastern Europe countries. They count for quite a lot of the download counters (FPC Bloodshed Pascal downloads are in the 6 figures) In the professional world, Delphi is still quite strong, mainly in NW Europe (the heartland seems to be Benelux+Germany+Scandinavia) However any group without a influx of new persons is bound to die, even though that can take another 5-10 years. Another problem I have with the push to so called industry languages is not so much the change of language, but also e.g. IDE. I've seen students wrestle with overly complex Java GUI IDEs and frameworks (SWING) that are slow and slightly instable. Most students don't get it, and simply go with the flow, copy assignments etc. They never actually get the bigger picture, and were fighting to master the IDE and the designer most of the class. (Tom: this was in the institution just on the other side of the road from your perspective). So the problem is not that (only) that the language is changed, but that other standards of educational usability slip too. Most notably simplicity and stability, all because of industry standard use that the students don't get any real benefit from in the first place.

1 0

C types.
by Anonymous 31 Mar '05

31 Mar '05

Frank said: >For interfacing to C in GPC use the C compatible types (see manual). >For fixed size types use `Integer attribute (Size = 32)' or >`Cardinal attribute (Size = 32)' etc. I don't know what FPC has. FPC 1.9.x+ has in the "ctypes" unit all C types prefixed with "c". So clong, culong, cuint32 etc. Not all existing headers are converted to this already. Most older header conversions were submitted by users, so they use all kinds of conventions. Some dedicated users are slowly "ctypes"ifying them.

1 0

Posting via web
by Anonymous 31 Mar '05

31 Mar '05

Recently some people wanted to post to this mailing list, but didn't want to sub-scribe. Since this list allows posts only from subscribers, this was a problem. Therefore, I've now set up an experimental web posting facility. It is available under "Mailing list archives" on the web site. One can send a new mail from the main archive page, or reply to mails in the archive. If this service starts to be abused by spammers, we might have to stop it. Let's hope this doesn't happen so soon. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Testsuite results on MirOS #8-beta / 3.4.4-20050325 / gpc-20050217
by Thorsten Glaser 30 Mar '05

30 Mar '05

Hi, this time it looks a bit better (though -ftrampolines is now required for generating them, and you broke GNAT with the version_string changes). I've kept closer to original sources while integrating, because this time, I can use GNU Make for building the stuff. Test Run By tg on 2005-03-29 00:07:02 Native configuration is i386-ecce-mirbsd8 (odem.66h.42h.de) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: crttest.pas FAIL: filehand.pas UNSUPPORTED: fjf165a.pas FAIL: fjf684.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: formattimetest.pas UNSUPPORTED: gmptest.pas FAIL: gpc_c_p.pas FAIL: gpctest.pas FAIL: gpcu_c_u.pas UNSUPPORTED: longr2.pas FAIL: random.pas === gpc Summary === # of tests 4537 # of expected passes 4520 # of unexpected failures 10 # of unsupported tests 7 gpc version 20050217, based on gcc-3.4.4 (propolice; MirOS 0825) TEST filehand.pas: ./filehand.pas: In main program: ./filehand.pas:11: error: statement used as an expression failed TEST fjf684.pas: ./fjf684.pas: In main program: ./fjf684.pas:12: error: invalid operands to =' failed TEST fjf751k.pas: ./fjf751k.pas: In main program: ./fjf751k.pas:8: error: argument to riteLn' is of wrong type failed TEST fjf751l.pas: ./fjf751l.pas: In main program: ./fjf751l.pas:8: error: argument to riteLn' is of wrong type failed TEST fjf800.pas: ./fjf800.pas:65: error: redeclaration of jf800' ./fjf800.pas:1: error: previous declaration ./fjf800.pas:65: error: redeclaration of jf800' ./fjf800.pas:1: error: previous declaration failed TEST formattimetest.pas: failed: could not compile strftime() test program TEST gpc_c_p.pas: gpc_c_c.c:2:22: gpc-in-c.h: No such file or directory gpc_c_c.c: In function ain': gpc_c_c.c:27: warning: implicit declaration of function p_initialize' gpc_c_c.c:31: warning: implicit declaration of function nit_pascal_main_program' gpc_c_c.c:53: warning: implicit declaration of function p_finalize' gpc1: gpc exited with status 1 failed TEST gpctest.pas: 86400 0 943841988 True True 1999 1999 11 11 29 29 1 1 2 2 19 19 26 48 0 0 Error in UnixTimeToTimeStamp TEST gpcu_c_u.pas: gpcu_c_c.c:2:22: gpc-in-c.h: No such file or directory gpcu_c_c.c: In function ain': gpcu_c_c.c:26: warning: implicit declaration of function p_initialize' gpcu_c_c.c:45: warning: implicit declaration of function p_finalize' gpc1: gpc exited with status 1 gpc: gpcu_c_c.o: No such file or directory failed TEST random.pas: ./random.pas: In main program: ./random.pas:22: error: invalid operands to *' ./random.pas:22: error: invalid operands to *' failed ------------------------------------------------------------ Some reasoning: strftime.cmp | if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ]; then What if gcc is not /usr/bin/gcc? Use $(CC) instead. After fixing that and rts-config.inc (which didn't get that I have got strftime() due to a mismatching prototype and -Werror): TEST formattimetest.pas: OK I'll fix that (the second issue) in the build process, then. After moving gpc-in-c.h to /usr/include, I get: TEST gpc_c_p.pas: OK TEST gpcu_c_u.pas: OK As for the gpctest.pas failure, I suspect that, somewhere, the system doesn't realise that time_t == int64_t even on 32 bit machines on MirOS/i386 (not for MirOS/sparc). That leaves me with 6 failures, which is kind of good, I guess. bye, //mirabile -- > [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der > richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt. Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...] weil selbst einfachste Operationen *echt* *Zeit* brauchen. (aus d.a.s.r)

2 1

Compile with gcc 3.3 CVS and new tools
by James A. Morrison 29 Mar '05

29 Mar '05

Hi, I needed the attached patch to compile gpc with gcc 3.3 cvs. I am using flex 2.5.31 and I copied gcc-3.3.5.diff to gcc-3.3.6.diff. I don't know what happened to set_word_size and set_words_big_endian from gcc 3.3.5 to cvs. Having gpc-lex.c define malloc and realloc instead of yyalloc and yyrealloc allows gpc to link against libiberty which defines xmalloc and xrealloc. -- Thanks, Jim http://phython.blogspot.com

2 4

GPC and GNU plotutils - problem
by Prof A Olowofoyeku (The African Chief) 25 Mar '05

25 Mar '05

Hi I have produced a GPC interface unit for GNU plotutils (courtesy of the "headconv" program). However, there is a problem. Trying to compile a test program gives this error: "d:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/libgpc.a(init.o): In function `p_initialize': d:/src/mingw/gcc-3.2.3/gcc/p/rts/init.pas:266: multiple definition of `_p_initialize' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here" "p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif Any ideas? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

5 24

Re: GPC and GNU plotutils - problem
by Prof A Olowofoyeku (The African Chief) 24 Mar '05

24 Mar '05

On 22 Mar 2005 at 22:28, Frank Heckenbach wrote: [...] > Of course, you could also convert the octal to (hexa)decimal > numbers. [...] Can we have a series of conversion routines (perhaps in gpcutil.pas)? octal2hex hex2octal int2octal octal2int Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

3 4

installation trouble
by Toby Ewing 23 Mar '05

23 Mar '05

Hi, I wrote earlier and got no response. Now I'm trying again. I installed gpc on a new machine with redhat 9. I can compile and run easy demo programs. But any program the has C-code in it, or uses a unit with C-code, gets rejected. Under gp, the message is gp: Pascal and C compilers specified seem to be for different platforms gp: ('i686-pc-linux-gnu' and 'i386-redhat-linux') Using gpc directly, I can compile the unit crt.pas, but when I try to compile a program that uses it, I get a message saying that crt.gpi needs to be recompiled. Recompiling crt.gpi does not change anything. What do I need to do to get some version of gpc working on this system? thanks, Toby

5 7

Pointer and object checks
by Frank Heckenbach 20 Mar '05

20 Mar '05

I'm considering adding runtime checks for nil pointer access. The benefits are not as big as one might suppose, since most systems catch a nil pointer access anyway and give a segmentation fault automatically. Whereas explicit runtime checks might add considerable runtime overhead. Additionally, some valid (well, let's at least say, working) BP and similar programs might fail then, e.g. if they pass dereferenced pointers (which may be nil) as var parameters, and the called routine either doesn't access the parameter or explicitly checks if it's address is nil. On the positive side, such a check might provide a somewhat nicer error message (proper runtime error instead of segfault), and it can be caught like other runtime errors (e.g. via `AtExit') rather than with a signal handler as for segfaults. Also, strict standard conformance makes it an error, even in a situation as described above where the var parameter is never used. Therefore, perhaps, the check should be off by default, and on only in standard modes, and of course, triggered by its own new option (`--[no-]pointer-checking'?). Another runtime check (which BTW should also be rather easy to implement now), is for objects, whether they point to a valid VMT, using the `NegatedSize' VMT field, just like BP does. AFAIR, BP does it on virtual method calls, where the VMT is used. In principle, the check could be done on every object operation/access, but that might be overkill. Since a simple check per virtual method call is not much overhead, I propose the check to be on by default, in all dialects. Of course, it will also get its own option (`--[no-]object-checking'?). BP couples it to range-checking (I can only guess why -- perhaps because they only have short, i.e. one-letter, compiler directives, and they wanted to save a letter). For strict compatibility, we could add a combined option (`--[no-]range-and-object-checking'), and make `{$R[+-]}' equivalent to that. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 13

assert -> gcc_assert
by James A. Morrison 20 Mar '05

20 Mar '05

Hi, GCC 4.0.0 and up use gcc_assert and gcc_unreachable for assertions and unreachable code. This patch updates gpc's assert to be gcc_assert and gcc_unreachable and have the same sematics as the upstream assertion functions. This along with the other patch was built and tested against gcc 3.3 cvs on ia64-linux. -- Thanks, Jim http://phython.blogspot.com

2 2

Re: bug: ncurses + slackware 10.0, 10.1
by Frank Heckenbach 18 Mar '05

18 Mar '05

Thomas Dickey wrote: > On Thu, 17 Mar 2005, Russell Whitaker wrote: > > > Program below illustrates a bug: lower case a, lower case f thru z, > > and number 0 are printed with graphic characters. This bug did not > > appear in earlier versions of slackware. > > I don't have Slackware 10.0 or 10.1; a quick try at testing this with > Debian isn't working out, since the Debian package apparently doesn't > build any of the units - just the compiler. Please use the option `--automake' when calling gpc, then it will build the units together with the program. Also, you might have to remove the `FrameWin' unit (it's not a standard unit, and the call to it is already commented out). > However, if it's an ncurses change (nothing offhand occurs to me, reading > the example), one could use ltrace to get a reasonable idea of the calls > that are being made in ncurses (not 100%, since some of the interface may > modify the WINDOW struct directly, but probably good enough to see this > sort of problem). I don't have Slackware 10.x here either, and the program works correctly for me. Unless you can reproduce a bug with the hints above, I guess I'll have to check it with the respective ncurses version to find out if it's a GPC or CRT bug (which would be my responsibility ...) Russ, which ncurses version is it that you have? Look in /usr/include/ncurses.h for: #define NCURSES_VERSION_MAJOR #define NCURSES_VERSION_MINOR #define NCURSES_VERSION_PATCH Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

ada libplot bindings uploaded
by Rick Engebretson 18 Mar '05

18 Mar '05

I've uploaded the ada-libplot bindings; http://www.pinenet.com/~eng/plotutils/ Not all links will work because other source was not uploaded. Also, my earlier email did not seem to go through. But to repeat; the _p_initialize problem is probably limited to the postscript plotter code and can probably be dealt with.

1 0

Re: bug: ncurses + slackware 10.0, 10.1
by Frank Heckenbach 18 Mar '05

18 Mar '05

Thomas Dickey wrote: > ok (I'll try this when I get home). My ncurses shared libraries are > current, but I do have static libraries for different versions, against > which I may be able to test (though I'm not sure how to tell gpc to do > that). GPC basically accepts all GCC options, so you can pass library file name on the command line. In addition you might have to edit the CRT unit (`gpc --print-file-name=units/crt.pas' to get its file name) and change this line (~790): {$L crtc.c, panel, ncurses} to just: {$L crtc.c} (The deleted part yields the effects of `-lpanel -lncurses'. Since explicitly names files take precedence on the linker command line AFAIK, this might not be necessary, but I'm not sure.) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Re: NCurses
by Prof A Olowofoyeku (The African Chief) 16 Mar '05

16 Mar '05

Hi My GPC port of the FPC ncurses unit: http://gnu-pascal.de/contrib/chief/ncurses.zip Note that there were linker problems with the "acs_map" variable. You can avoid the linker problems by treating acs_map as an internal (not external) variable. But this probably means missing some functionality. You might have to rebuild your ncurses library, configuring with "--enable-broken_linker" to solve it. I don't know about these things. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

3 3

How do I create records that point to a record of the same type?
by loop lopy 16 Mar '05

16 Mar '05

I have changed from gpc into turbo pascal. The code that compiled for me in gpc doesnt compile now in turbo pascal. The code: type NumNode = record Value: integer; pNext: ^ NumNode; end; The compile error I get: Undefined type in pointer definition (NUMNODE) __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

5 4

Re: PowerPC and ncurses
by Frank Heckenbach 16 Mar '05

16 Mar '05

Forwarded from marcov(a)stack.nl: > In answer to Rick's remark: > > fpimage has nothing to do with GNU Plotutils, and to my knowledge there is > no libplot binding in FPC. > > fpimage is totally standalone pascal code, delphi dialect. So not much > chance of running it on GPC short term. (while it now uses paszlib and > pasjpeg, it is switchable to use the C versions of those libraries when > building a FPC release) [Rather than porting this, it might be easier to translate the Plotutils interface ... -- Frank] Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

2 2

problems with assignment of whole records on PowerPC
by Igor Marnat 15 Mar '05

15 Mar '05

Hello, List! I've successfully built cross-compiler for PowerPC GPC configuration attached below. Anyway, I cannot execute simple program built with my new compiler. Program looks like: program test; type MyRecord = record x: word; y: word; end; var t1, t2: MyRecord; begin writeln ('SizeOf (word)', Sizeof (word)); writeln ('SizeOf (longword)', Sizeof (longword)); writeln ('SizeOf (CInteger)', Sizeof (CInteger)); t1.x := 1; t1.y := 1; writeln ('before assignment'); t2 := t1; writeln ('after assignment'); end. Program output: bash-2.05b# ./test SizeOf (word)4 SizeOf (longword)8 SizeOf (CInteger)4 before assignment Illegal instruction When I change type of fields fo MyRecord to longword, it works fine. Is it anything wrong with alignment or packed records? But my record isn't packed ... I could avoid usage of whole records assignments and assign the values field by field but there are two reason why I don't want to do that: 1. it shows that something is wrong, isn't it? 2. assignment of the whole records is used in crt.pas unit, for example, in function ScreenSize of crt.pas unit which return the value of TPoint type which is record (this assignment doesn't work as well). I really don't want change anything in crt.pas unit:). Please, any ideas or hints ... Thank you, regards, Igor Marnat GPC configuration: (Reading specs from /home/igor/denx_tools/usr/lib/gcc-lib/ppc-linux/3.3.3/specs Configured with: ../configure --prefix=/home/igor/denx_tools/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib --enable-languages=c,c++,pascal --disable-libgcj --host=i386-redhat-linux --target=ppc-linux Thread model: posix gpc version 20050217, based on gcc-3.3.3 (DENX ELDK custom version 3.3.3-8) ). ~

2 2

Fwd: PowerPC and ncurses.
by Frank Heckenbach 15 Mar '05

15 Mar '05

Forwarded from marcov(a)stack.nl: > Some small comments > > Powerpc: The 603 has floating point alignment requirements iirc. If he has > a 603, check what the default ppc processor is, and if it is a ppc603 (quite > old, think 100-200 MHz range) try to specify codegeneration for a ppc603 > > ncurses: > > The addition of library to external symbols is standard delphi syntax. I > think it has to do with the way Windows loads DLLs (OS X also seems to > require it sometimes, Mach O can have multiple namespaces IIRC). > > A nice sideeffect could be that it allows the linker to better pinpoint the cause > of a missing symbol (not symbol x is missing, but symbol x is missing from > lib y), but LD doesn't do that yet. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

2 1

Fwd: NCurses
by Frank Heckenbach 14 Mar '05

14 Mar '05

Forwarded from: marcov(a)stack.nl (Marco van de Voort) A.s. reproduction to list allowed. The Ncurses author is Michael van Canneyt, however most other FPC authors contributed to it, and we don't have a sign away rights to a foundation system. Be sure to get ncurses from current CVS, and don't use e.g. 1 1/2 year old 1.0.10 sources. CVS is open for anonymous use, and there is also a webinterface development page: http://www.freepascal.org/develop.html webcvs ncurses dir: http://www.freepascal.org/cgi-bin/viewcvs.cgi/fpc/packages/extra/ncurses/ FPC used to have an own version of the LGPL (which we still call LIBRARY GPL btw), from before LGPL existed. Somewhere in 2000 this was rectified, but because users felt incertain about some of the clauses, an additional clarification to the base LGPL text was added, which is quoted below: ---------------------------------------------------------------------------- This is the file COPYING.FPC, it applies to the Free Pascal Run-Time Library (RTL) and packages (packages) distributed by members of the Free Pascal Development Team. The source code of the Free Pascal Runtime Libraries and packages are distributed under the Library GNU General Public License (see the file COPYING) with the following modification: As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you a are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you didn't receive a copy of the file COPYING, contact: Free Software Foundation 675 Mass Ave Cambridge, MA 02139 USA

3 3

compiler quarrels
by Toby Ewing 14 Mar '05

14 Mar '05

Hi, I'm running into an odd problem here. Compiling simple Pascal programs goes fine, but when I compile a unit that has some C code (e.g., crt.pas) I get the message: gp: Pascal and C compilers specified seem to be for different platforms gp: ('i686-pc-linux-gnu' and 'i386-redhat-linux') Seems to me that this shouldn't be a problem, but clearly the compiler thinks it is. At this point, I haven't been able to compile any unit that uses C-code. What do I change, where, to make the two happy with each other? I'm running redhat (obviously) which has gcc 3.4.3-9, whereas the gpc is using the 3.3.3 library. A possible "cure" would be to install an older version of gcc in (say) /usr/local, but I'd just as soon not go backwards if I can avoid it. Also, the issue seems more about that apparent target platforms, than the library versions themselves. thanks, Toby

2 1

End of string
by loop lopy 14 Mar '05

14 Mar '05

How does writeln knows its the end of a string? I have the following code: String = packed array[1..256] of char; var Test: String; begin Test:='Hello world'; writeln (Test); Test[8] := Test[12]; writeln (Test); end. The output is: Hello world Hello w rld How does writeln knows where to stop printing the string? __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

5 7

PARAMS and k&r definitions
by James A. Morrison 14 Mar '05

14 Mar '05

Hi, The coding conventions for gcc 3.4 and up say to no longer use k&r style definitions. Is gpc going to follow suit? I.e. Will patches to remove PARAMS and switch away from k&r style definitions be accepted? -- Thanks, Jim http://phython.blogspot.com

2 5

Wrap long lines in declarations.c
by James A. Morrison 13 Mar '05

13 Mar '05

Hi, This patch wraps most long lines to under 79 characters. It has been built and tested on ia64-linux along with the other previous two patches. -- Thanks, Jim http://phython.blogspot.com

1 0

Re: ncurses
by Rick Engebretson 13 Mar '05

13 Mar '05

FPC has a complete ncurses unit that might just slip right in GPC. Of course credit is due the author.

5 7

Calling a function
by loop lopy 12 Mar '05

12 Mar '05

I have the following code: function nString2nList (Str: String; var Num:Number):boolean; var CurrentChar: integer; begin CurrentChar:=0; while (Str[CurrentChar]<>'a') do begin writeln (Str[CurrentChar]); CurrentChar:= CurrentChar+1; end; nString2nList:=true; end; begin nString2nList ('-0123a', Num1); end. I get the following error on the one before last line: function call as a statement - value is ignored __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

2 1

Homework
by loop lopy 12 Mar '05

12 Mar '05

The trouble is we had only one hour lecture on pascal and we wont have any more on this issue. I havnt found any decent refernce on GPC pascal. Is there any good reference on the web for GPC pascal? I hope that people wont get tired on answering me on those compilation errors, eventhough they are simple because these errors really get me stuck. Of course you dont have to answer if you dont want to. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Compiler error (small fix)
by loop lopy 12 Mar '05

12 Mar '05

I have defined a String = ^ char type which fixed the error in line 44. However I still have an error in line 17. Additional question, how do I get a data from ^ char pointer? If I have: a: ^ char; In c I would do the follwoing, either: *a = 'a'; or a[0] = 'a'; How do I do the equvalent in GPC? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Compilation errors (no HTML, I think)
by loop lopy 12 Mar '05

12 Mar '05

I omitted the additional type and the first compilation error has been removed. Now I have two additional compilation errors. My code is: program Ex1 (input, output); type NumNode = record Value: integer; pNext: ^ NumNode; end; nNumber = record DigitsAmount: integer; DigitValue:^ NumNode; MSD: integer; DigitBase: integer; end; function nNumberIsEmpty (Num: nNumber): boolean; begin nNumberIsEmpty := (Num.DigitValue=0); end; function nNumberPop (var Number: nNumber): integer; var pNextValue:^ NumNode; begin if (nNumberIsEmpty(Number)) then nNumberPop:=0; else begin Number.DigitsAmount:=Number.DigitsAmount-1; pNextValue := Number.DigitValue^.pNext; dispose (Number.DigitValue); Number.DigitValue:=pNextValue; if (Number.DigitsAmount=0) then begin Number.MSD:=0; nNumberPop:=0; end else begin nNumberPop:=pNextValue^.Value; end; end; end; function nString2nList (String:^ char; var Number:nNumber;):boolean; begin end; begin writeln ('Hello world'); end. The errors I get: ex1.pas: In function 'Nnumberisempty': ex1.pas:17: invalid operands to binary = ex1.pas: At top level: ex1.pas:44: parse error before '^' What causes these errors? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Packed array (strings) update
by loop lopy 12 Mar '05

12 Mar '05

I have changed the string to start from 1: String = packed array[1..256] of char; var Test:string; begin readln (Test); end. Now I get the following error: ISO 7185 Pascal does not allow reading strings from textfiles So, how am I suppose to read a string? Read a char one after another? Another question, how do I mark the end of string? Is there a special char for that, like '/0' in C? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Packed array (correction)
by loop lopy 12 Mar '05

12 Mar '05

It suppose to be: String = packed array [0..255] of char; __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Packed array
by loop lopy 12 Mar '05

12 Mar '05

In order to read strings I have defined the following type: String: packed array[0..255] of char; However, when I have the following code: var Test: String; begin readln (Test); end. I get the compil error: only packed array of char may be read from 'Text' files How should I read a string with readln? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

String type
by loop lopy 12 Mar '05

12 Mar '05

It seems there is a string type in turbo pascal. Howver, in gpc it gives a compiler error if something is defined : String; So, there is no type string in gpc --standard-pascal? How do I read a string from the input? I need to use readln? I need to use a Text type variable or is there a predefined variable of text type that is used for standard input? How do I use readln? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Compiling errors
by loop lopy 12 Mar '05

12 Mar '05

I omitted the additional type and the first compilation error has been removed. Now I have two additional compilation errors. My code is: program Ex1 (input, output); type NumNode = record Value: integer; pNext: ^ NumNode; end; nNumber = record DigitsAmount: integer; DigitValue:^ NumNode; MSD: integer; DigitBase: integer; end; function nNumberIsEmpty (Num: nNumber): boolean; begin nNumberIsEmpty := (Num.DigitValue=0); end; function nNumberPop (var Number: nNumber): integer; var pNextValue:^ NumNode; begin if (nNumberIsEmpty(Number)) then nNumberPop:=0; else begin Number.DigitsAmount:=Number.DigitsAmount-1; pNextValue := Number.DigitValue^.pNext; dispose (Number.DigitValue); Number.DigitValue:=pNextValue; if (Number.DigitsAmount=0) then begin Number.MSD:=0; nNumberPop:=0; end else begin nNumberPop:=pNextValue^.Value; end; end; end; function nString2nList (String:^ char; var Number:nNumber;):boolean; begin end; begin writeln ('Hello world'); end. The errors I get: ex1.pas: In function 'Nnumberisempty': ex1.pas:17: invalid operands to binary = ex1.pas: At top level: ex1.pas:44: parse error before '^' What causes these errors? --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site!

2 1

Another sample of the wrong order of declaration error
by loop lopy 12 Mar '05

12 Mar '05

I have the following code: program Test (input, output); type Num1 = record Value: integer; end; type Num2 = record Value: integer; end; type Num3 = record Value: integer; end; function a (b:integer): integer; begin end; begin end. I get the following errors: test.pas:11: wrong order of declarations according to ISO 7185 Pascal test.pas:15: wrong order of declarations according to ISO 7185 Pascal How do I fix this? --------------------------------- Do you Yahoo!? Make Yahoo! your home page

1 0

Wrong order of declaration
by loop lopy 12 Mar '05

12 Mar '05

If I write the following code: program Ex1 (input, output); type NumNode = record Value: integer; pNext: ^ NumNode; end; function a (b:integer): integer; begin end; begin end. Then the compilation works. So it seems the second record is somehow not accepted. --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site!

2 1

Wrong declaration order
by loop lopy 12 Mar '05

12 Mar '05

Hello Here is my code: program Ex1 (input, output); type NumNode = record Value: integer; pNext: ^ NumNode; end; type nNumber = record DigitsAmount:integer; DigitValue:^ NumNode; MSD: integer; DigitBase: integer; end; function a (b:integer): integer; begin end; There is nore code, but I dont think it is needed to understand what causes the compiler error. What might cause this compilation error? P.S.: I didnt see where I can turn off HTML email. --------------------------------- Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more.

2 1

wrong order of declaration
by loop lopy 12 Mar '05

12 Mar '05

Hello I have compiled my program with gpc --standard-pascal ex1.pas -o ex1.aout I got the following error: ex1.pas:15:Wrong order of declerations according to ISO 7158 Pascal in function 'A' : My code at line 15 is: function a (b:integer): integer; What is wrong with it? --------------------------------- Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses.

3 2

Wrong order of declaration
by loop lopy 12 Mar '05

12 Mar '05

Hello I have compiled my program with gpc --standard-pascal ex1.pas -o ex1.aout I got the following error: ex1.pas:15:Wrong order of declerations according to ISO 7158 Pascal in function 'A' : My code at line 15 is: function a (b:integer): integer; What is wrong with it? --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we.

1 0

building cross compiler for PowerPC using 20050217 version
by Igor Marnat 11 Mar '05

11 Mar '05

Hello, all! I'm trying to build cross-compiler to build the programs for PowerPC processor. Host is Fedora Core 3, i686, kernel of 2.6.10 version. GPC is of 20050217 version, is being built together with GCC 3.3.3. I've configured it with ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib --enable-languages=c,pascal --disable-libgcj --target=ppc-linux. Compiler itself (xgpc) has been built successfully but it doesn't want to build rts and tells me that c compiler cannot create executables. In the <build>/gcc/p/rts there is the only one file, config.log (attached) where cc1 (of just built xgcc) tells that arch=i686 is an invalid option for him (sounds reasonable since it's the compiler for ppc platform). So, could you please make some clarifications for me: 1. why GPC didn't see that it's being built as a cross compiler (there is nothing about it in config.log, it even doesn't try to determine it). 2. what should be done to avoid passing of the CFLAGS of the native host compiler to cross compiler xgcc which has been just built. 3. as I can see from configure script from rts directory of 20050217 version, it's used another way to determine if it's being built the cross-compiler (there was used other method to determine it in 20030830 version). It's written "FIXME: to remove some days" in current "rts/configure" script near this lines. Is it really wrong and needs to be fixed? Current method uses the value of host_alias variable. As I can see from the config.log file, host_alias variable of "rts/configure" script is empty - how should it get its value? In the same script we try to assign it the value using the options entered by user but "rts/configure"script is called automatically during p/rts/Makefile target building and there is no --host parameter. How should it get its value? It will be really nice if somebody can give me any hint or point to any source to read about. Regards, Igor Marnat marny(a)rambler.ru

3 4

const keyword: problems migrating code from gpc on Linux to gpc on OsX
by Stefano Carpin 11 Mar '05

11 Mar '05

Hi all. The follwing three files reproduce an error I've encountered while porting some code from gpc on Linux to gpc on OsX. ----------- file p1.pas -------- module p1; export p1 = all; const P = 155; function Something() :boolean; end; function Something: boolean; begin Something := false; end; end. ------------ file p2.pas --------- module p2; export p2 = all; const P = 155; function SomethingElse :boolean; end; function SomethingElse: boolean; begin SomethingElse := false; end; end. ----------- file testconst.pas ------- program test(input, output); import p1;p2; var a,b : boolean; c : integer; begin a := Something; b := SomethingElse; c := P; writeln('test'); end. --------------------------------------------------- If I try gpc --automake testconst.pas on my linux box it works fine. If I try the same command on my Mac I receive the following output: p2.pas:5: error: redeclaration of `P' p1.pas:5: error: previous declaration Please note that if you change both P and c to boolean type, everything works fine both on Linux and OsX Precisely, on Linux I am running gpc 20041218 based on gcc-3.3.3. On the Mac I run GNU Pascal version 20041218, based on gcc-3.4.3, i.e. the one currently available on microbizz. Any hint? Thanks, Stefano

2 1

GPC ALPHA 20050217 released
by Frank Heckenbach 11 Mar '05

11 Mar '05

I have uploaded a new alpha version of GPC to <http://www.gnu-pascal.de/alpha/>. Important notes: - This is an ALPHA version, as discussed on the mailing list before. Not so many extensive tests have been made (though the test suite passes on my system). I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work. - Bison (building GPC) Bison version 2.0 has been released. It can be obtained at <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz>. This is now the recommended version for all GPC compilations. Fortunately, we now don't depend on changing alpha/beta versions of bison anymore. Bison is required when building a minimal distribution of GPC (which now doesn't include the Bison generated files anymore, as it did temporarily); when building a full source distribution and not modifying the bison input files (*.y), bison is not strictly needed, but in case of doubt, it can't hurt to install the new bison version. New features: - Support for gcc-3.4.x (tested with 3.4.3) The caveats that apply to gcc-3.3.x (especially on Dos/Windows) also apply here. - Renamed options Due to the way that gcc-3.4.x handles options, we had to rename two options (command line and compiler directive, respectively). To avoid confusion, we did this for all backend versions: --no-default-paths -> --disable-default-paths --no-debug-info -> --disable-debug-info Note: `--disable-debug-info' is only used in very special cases, and usually as a compiler directive. To turn off debug info one would normally use `-g0' which remains unaffected. - Qualified identifiers (chief18.pas, fjf260*.pas, fjf921*.pas, grp1.pas, kurzw1.pas, mod{9,10,13..17}*.pas) GPC now supports qualified identifiers, both Extended Pascal and Borland Pascal style. A small incompatibility to previous versions arises when a declaration has the same name as an interface, which is not EP conformant, but GPC previously allowed. This will now cause compile-time errors. The solution is to rename either the interface or the declaration. The linker names, if not specified explicitly, are now completely different. Since those linker names should not be relied upon anyway, we hope this is no problem. If you get problems here, just add `name' attributes where necesssary. (This will also make the code more robust, in case the internal conventions ever change again.) - Importing within a routine (EP feature) works now. (mod15[c-e].pas) - Range checking (chuck5.pas, fjf446.pas, fjf989*.pas, fjf992*.pas, fsc{01..37}*.pas, miklos1[bc].pas, mir{016,021..028,030..047}*.pas, russ4*.pas) GPC now supports full range checking (previously it did so only for dynamic ranges and sets). Range checking is on by default (in all dialects) and can be turned off and on again by command-line arguments or compiler directives (`{$[no-]range-checking}' and also `{$R-}' and `{$R+}', BP compatible). Note, this is not overflow checking, which may be implemented later and will be a separate option, just like in BP. Range checking applies when a value of a larger type (e.g., an `Integer' variable or the result of an integer operation) is used in a place where a subrange is expected (e.g., an array index, or assignment to a variable with more limited range). Overflow checking would apply if the result of an arithmetic or other operation exceeds the representable values (e.g., `var a: Integer = MaxInt; [...] WriteLn (a + a)'). This is not yet checked. For input operations (`Read', `ReadLn', `ReadStr', `Val'), range checking errors are treated as I/O errors, so they can be trapped with `{$I-}' via `IOResult' (for `Read*'), or for `Val' via the 3rd parameter (while range errors in the 3rd parameter of `Val' itself are treated as regular runtime errors; this paramter is the error position, so range errors there can be avoided simply by declaring it of a sufficiently larger type, usually just `Integer' or `Cardinal'). For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as if MyString[1] = '-' ... without a check if (MyString <> '') and ... may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code. The same applies with `var' parameters and the address operator as well, so e.g. code such as: BlockRead (f, StringLength, SizeOf (StringLength)); BlockRead (f, s[1], StringLength); SetLength (s, StringLength); needs two changes to be range safe now: BlockRead (f, StringLength, SizeOf (StringLength)); SetLength (s, StringLength); if StringLength > 0 then BlockRead (f, s[1], StringLength); Another example (rather low-level code, found e.g. in the RTS): BufPtr := PChars0 (@s[1]); BufSize := Length (s); will fail if `s' is empty. Possible change (provided the using code doesn't access `BufPtr' if `BufSize' is empty, which would be undefined anyway when reading): if s = '' then BufPtr := nil else BufPtr := PChars0 (@s[1]); BufSize := Length (s); - `pow', `Trim', `Card', set operations (`-', `*', `><'), set comparisons, string comparisons and array slices with constant arguments can now be used in constants (fjf998*.pas, fjf1000*.pas, fjf1009*.pas) - Initialized types in record and object fields and in schemata work now. (inirec[24].pas, fjf1016*.pas) - Types and initializers containing variable expressions, including schemata with non-constant discriminants work now. (couper[45].pas, fjf186.pas, fjf548.pas, fjf612a.pas, fjf997*.pas, fjf1003*.pas, john1a.pas) - With `-Wnested-comments' and without `--nested-comments' warn about comment openers found within comments. (fjf1017*.pas) - New options `--[no-]case-value-checking' (fjf1012*.pas) - Arithmetics with a complex and a real operand are now better optimized. (<20020118143553.B28837(a)artax.karlin.mff.cuni.cz>) - Bug fixes: * warn if an lhs cast decreases alignment (avo9.pas) * don't require result variables in forward declarations except in strict ISO mode (marku10*.pas) * writing to a file buffer at EOF didn't work (eof1.pas) * don't allow `f^' for unopened files `f' (pcerror[ij].pas) * evaluate initializers exactly as often as specified (fjf1019.pas) * in standard Pascal modes, `EOF' is false on an empty file (tom7.pas) * wrong `arithmetical overflow' with `set of byte' (igor1.pas) * `ParamStr' evaluated its argument twice (fjf963b.pas) * user-defined operators must not be applied to implicit operations (fjf991.pas and many other cases) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

11 86

Re: c library imports revisited (fwd)
by Frank Heckenbach 10 Mar '05

10 Mar '05

Forwarded message from marcov(a)stack.nl (Marco van de Voort): Subject: Re: c library imports revisited In-Reply-To: <1109917477.4701.80683(a)goedel.fjf.gnu.de> To: Frank Heckenbach <ih8mj(a)fjf.gnu.de> Date: Mon, 7 Mar 2005 13:12:30 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL118 (25)] > : We do offer a limited selection of Unix calls though, but these are targeted > : for specific Unix use, and in no way a substitute for the general calls in > : e.g. an unit sysutils. They are prototyped roughly as the C calls, but > : with "fp" prefixed, so manual pages still apply. > > This probably explains what Rick was wondering about. If even glibc > interfaces changes frequently (I suppose so, I'm not following them > closely myself), other system's libcs are vastly different ... About half the breakage occurs in startup files, mangling, and dealing with stuff like tls and threadsafe errno workarounds. GPC being gcc based might have less problems with that. OTOH GPC will typically rely heavier on libc, which might also cause different problems. (for FPC, the only thing that matters is the binary api, no C code) The other half are more definitions changing, and distro maintainers that retire legacy calls earlier than others. > constant, rewriting) AFAICS would be either to have a 100% automatic > translator that handles everything that occurs in some libc headers > (which is likely to be all of standard C + extensions, via macros > and inline functions), or to write wrappers in C that use the libc > routines in the C way (thus being able to include headers as > designed) and provide a well-defined C/Pascal interface. That's > basically what we do in the RTS for a subset of libc (sometimes > providing a bare-bones interfaces, sometimes higher-level). This is extremely difficult (we also thought/tried this). Personally, I have given up on C2pascal like programs being fully automatic, and consider them more as a tool for manual translation. Even if it works, the output is horribly ugly, comments are stripped etc. For the commctrl windows header, 1) I wrote a simple (200 line) pascal program that did some basic conversion and stripping of microsoft directives etc, sorting constants, structures and procedure defs into separate files, expanding simple macro's (that only were a bunch of typecasts). All done very simple, basic on heuristics, and modifying till output is ok. 2) Then I postedited the individual files with some global search and replace, and ran them through h2pas for the basic conversion (for the structs). The constants I fully converted using block-editor commands and search-n-replace. 3) Then again search and replace time and some simple filter procs (e.g. external clauses in calls) 4) Then manually merging, checking and fixing (days of work, but these are 10000+ lines), converting more complex macro's etc. (the commctrl macro's where very picky about typing. They contained such systematic typecasting, one could infer the parameters typing, greatly increasing the automatic conversion ratio) The basic problem with this process is the amount of manual labour (I did it in lost hours in trains etc), and the batchwise operating. Noticing an error in the conversion of (1) can't be corrected by redoing (1) since then all manual editing must be redone. The trouble with C to pascal parsing is that everybody tries to go for the silver bullet of 100% automatic conversion. They all fail, and nobody is interested long enough to try a second approach, something what is more a construction kit for converting headers or so, or a scriptable or assisted system. > As I wrote the other day, automatic translation for most other C > libraries is probably a whole lot easier (as glibc headers contain > some of the most complicated macros I've seen so far in external > headers, apart from the Linux kernel headers) ... Try *BSD startup binary sources (crtbegin/crt0 etc) I once had 6 pages (roughly 100-150 lines) that became 12 asm instructions. They have cleaned up a bit since though. The big funny thing was that it was a portable wrapper for syscalls. However the file was marked as "i386 only". Even if it was portable, it was so complex that I only figured it out by comparing 1) objdumped assembler files, 2) -S output 3) the source P.s. Jedi also did an attempt at a header convertor, based on an experiment of dr Bob: http://delphi-jedi.org/TEAM_DARTH_HOME or search for "headconv" Afaik it is roughly the same principle as the FPC one, but less maintained (and the FPC one is already essentially unmaintained)

3 4

Fwd: Re: Initialised variables
by Frank Heckenbach 10 Mar '05

10 Mar '05

Forwarded message from marcov(a)stack.nl (Marco van de Voort): Hmm, this is starting to become a daily routine, BUT, I couldn't pass by Waldek "initialised variables" subject without a few comments, you can throw this msg on the list. (note this is all from memory, and I'm not even a compiler guy, so check it yourself. Just to get you on the trail) Note that the reason the example fails in any mode but delphi is simply that the integer size=16-bit in those modes. (BP compat) [And the routine must be declared `far' in BP AFAIR. -- Frank] If you correct the program by - substituting longint for integer - adding () to the bar call. - use normal mode (no params) or objfpc mode (-S2) then the program works in a recent (1.9.9) version, but I think this is pretty invariant within 1.9.x. The delphi case fails, afaik out of compability. The rules for FPC are simple (though there might be gotcha's, or changed things) is to roughly follow delphi, but - when in doubt allow () to force function call. - when in doubt use @ to force assignment of proc variable. FPC modi use/require a '@' a lot more than Delphi mode to resolve ambiguity. IIRC Delphi also knows @@ to take the address of the procvar itself. Delphi has a lot of special rules with respect to procvars and methodvars. The FPC testsuite probably contains quite a few. program bug1; {$X+} type tfunc = function : pointer; function baz : longint; begin baz := 1024 * 2; end; var bar : tfunc; function foo : longint; begin foo := longint(@baz); // force assignment. end; begin bar := tfunc (foo); { this is where Delphi and BP barf } writeln (longint (bar())); // force call end.

1 0

Initialised variables
by Prof A Olowofoyeku (The African Chief) 10 Mar '05

10 Mar '05

Hi I have found a possible problem, illustrated in the three programs below (and in the comments): program one; uses windows; var h : THandle = LoadLibrary ('winstl32.dll'); v : ^function : integer = GetProcAddress (h, 'Chief32DllVersion'); begin Writeln ('Handle=', h); Writeln ('V is assigned=', Assigned (v)); { TRUE } Writeln ('Version=', v^); { correct result } Writeln ('DLL Unloaded=',FreeLibrary (h)); { TRUE } end. program two; uses windows; var h : THandle = LoadLibrary ('winstl32.dll'); v : function : integer = GetProcAddress (h, 'Chief32DllVersion'); begin Writeln ('Handle=', h); Writeln ('V is assigned=', Assigned (v)); { TRUE } Writeln ('Version=', v); { wrong result } Writeln ('DLL Unloaded=',FreeLibrary (h)); { TRUE } end. program three; uses windows; var h : THandle = LoadLibrary ('winstl32.dll'); v : function : integer = GetProcAddress (h, 'Chief32DllVersion'); begin Writeln ('Handle=', h); Writeln ('V is assigned=', Assigned (v)); { TRUE } @v := GetProcAddress (h, 'Chief32DllVersion'); { saves the day } Writeln ('Version=', v); { correct result } Writeln ('DLL Unloaded=', FreeLibrary (h)); { TRUE } end. What is the possible problem? 1. With all programs, declarations of "h" and "v" are accepted by GPC. But they are not accepted by Delphi, FreePascal, VirtualPascal, or BP ("cannot evaluate this expression" or "constant expression expected"). Is this an EP thing or is it a GPC extension? BTW: gcc (Mingw) doesn't accept this type of initialisation. 2. As you can see from the comments, the assignment of "v" to GetProcAddress ... seems to succeed (in that the variable is indeed assigned), but silently produces a wrong result, meaning that it didn't really get assigned as it should. Any comments? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 6

Re: Bug? Delphi-style result variable
by Markus Gerwinski 09 Mar '05

09 Mar '05

Frank Heckenbach wrote: > Markus Gerwinski wrote: > > compiling the program > > > > Program Test; > > > > var > > x: integer; > > > > Function foo: integer; > > > > Procedure bar; > > begin (* bar *) > > result:= 7; > > end (* bar *); > > > > begin (* foo *) > > bar; > > end (* foo *); > > > > begin > > x:= foo; > > end. > > > > yields an error message > > > > test.pas: In procedure `bar': > > test.pas:14: error: invalid access to `Result' > > test.pas: In function `foo': > > test.pas:20: error: result of function not assigned > > > > Bug or feature? > An interesting case indeed. Since `Result' is a Delphi feature, we > probably should check if Delphi allows this, and if so do so as > well. I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function. > Notice, though, that if it does, it's somewhat confusing (if both > `foo' and `bar' are functions, one implicit `Result' probably > shadows the other -- please try this case with Delphi as well), and > error-prone (in your example, if you later decide to make `bar' a > function with an integer type result, the code would silently change > its meaning). Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.) Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before. Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

9 23

Re: c library imports revisited
by Prof A Olowofoyeku (The African Chief) 08 Mar '05

08 Mar '05

On 28 Feb 2005, 15:31:48, Rick Engebretson wrote: >OK, I've updated gpc and begun to probe for "clarification." > >I'm glad an automated c-header translator is being discussed. The fpc >people have such a tool and have translated libc. A terrific pascal >development. [...] There is something else which has been exercising me, in respect of imports from Windows DLLs. In gcc, I can do something like this: FARPROC foo; /*pointer to DLL function "char *foo (char *x, char * y, int z)" */ void main(){ char *str; HINSTANCE h = LoadLibrary ("myfoo.dll"); if (h > 0) { foo = GetProcAddress (h, "foo@12"); str = foo ("foo", "bar", 24); } } In GPC, this kind of thing will (naturally) not work, because the (function) pointer "foo" cannot be passed arbitrary parameters like that. gcc happily accepts it (now, of course, if the parameters are wrong, then the program will GPF at the call "str = foo ...", and if the parameters are correct, then everything works correctly). The question is: since GPC is based on gcc, is the capacity to accept something like this present in GPC? (the question whether it should be accepted of is of course a different thing). I personally would find it very useful (not for translating c headers, but for automated parsing of DLLs and automated imports of their exported symbols), although I can hear all the cries of "Pascal is a safe language and therefore should never accept something like this". Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

5 19

Re: /usr/bin/ld: cannot find -lgcc
by Maurice Lombardi 08 Mar '05

08 Mar '05

I redirect this mail to the gpc list. It is a problem about install of gpc/grx which may interest others. There have been problems with CPP_PREDEFINES in Linux (Debian). They are worked around, but others remain ... Maurice Shutian Ma a écrit: > I used gpc -v > and got: > gpc version 20041218 > based on gcc-3.3.3 > > I added > {$define linux} > before of after > {$define LINUX_CONSOLE} > in grx.pas. > > and got: > > [root@localhost pascal]# make -f makefile.lnx > gpc --automake -O1 -Wall -o blt_test blt_test.pas > -L../lib/unix ../lib/unix/libgrx20.a -lvga -lm > /usr/bin/ld: cannot find -lgcc > collect2: ld returned 1 exit status > make: *** [blt_test] Error 1 > [root@localhost pascal]# > > Could you tell me the next step? > This time, you have a problem of installation of gpc (Pascal). You have some verson of gcc (C) installed. To know which one type gcc -v It is probably different from gcc-3.3.3 which served as backend version of gcc when compiling gpc. You need _this_ version of gcc installed because gpc looks for the version of libgcc.a with same version number as the one which served as backend to compile gpc. Fortunately two (or many) versions of gcc can coexist on the same system. they are recognized through a version number in the libraries. For example yoy have probably a directory /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/ which contains libgcc.a and executables gpc1 and gpcpp which have been installed by gpc, but not libgcc.a nor executable cc1 (as well as some other files) which should have been installed by gcc-3.3.3 To enable this to work you should install all the files that gcc-3.3.3 put in _this_ directory. You probably have similar files installed in an other directory with version number which corresponds to your main gcc version given by gcc -v. You should thus install only those files of gcc-3.3.3 in the proper lib subdirectory I am not used on how you install files in Debian (I use DJGPP or sometimes mingw32). May be untar the _binaries_ of gcc-3.3.3 in some temp directory and move the files to the right directory. Or install gcc-3.3.3: you risk to overwrite compiler driver files like /usr/local/bin/gcc.exe. In that case reinstall afterwards your main gcc version, il will overwrite anew this file, but the files contained in lib/gcc-lib/.. will not be overwritten because they are in different directories discriminated by version number. Maurice > --- Maurice Lombardi > <Maurice.Lombardi(a)ujf-grenoble.fr> wrote: > >> >>Shutian Ma a écrit: >> >>>Thank you, >>> >>>I have delete the "." , then tried: I checked >>>blt_test.pas, no similar sentence. What I should >> >>do? >> >>>------------------- >>>[shma@localhost pascal]$ locate libgrx20.a >>>/usr/local/lib/libgrx20.a >>>/home/shma/gnu_pascal/grx246/lib/unix/libgrx20.a >>>[shma@localhost pascal]$ >>>--------------------- >>> >>>[shma@localhost pascal]$ make -f makefile.lnx >>>gpc --automake -O1 -Wall -o blt_test blt_test.pas >>>-L../lib/unix ../lib/unix/libgrx20.a -lvga -lm >>>/usr/bin/ld: cannot find -lgrx20X >>>collect2: ld returned 1 exit status >>>make: *** [blt_test] Error 1 >>>[shma@localhost pascal]$ >>> >>> >>>---------------------- >>>{ Define this if you want to use the Linux console >>>version. >>> (Ignored on non-Linux systems.) } >>>{$define LINUX_CONSOLE} >>> >> >> >> >>> >>>{$gnu-pascal,I-} >>>{$ifdef __DJGPP__} >>> {$L grx20} >>>{$elif defined (__MINGW32__)} >>> {$L grx20} >>>{$elif defined (_WIN32)} >>> {$L grxW32, vfs.c, user32, gdi32} >>>{$elif defined (linux) and defined >> >>(LINUX_CONSOLE)} >> >>> {$L grx20, vga} >>>{$else} >>> {$L grx20X, X11} >>>{$endif} >>> >> >> >> >>> >>>{ Uncomment those of the following libraries that >> >>you >> >>>need } >> >>mmm. starting with gcc 3.3.x there are problems with >>CPP_PREDEFINES in gpc >>I was supposing that this causes problems only with >>DOS/Windows targets. >>But I have checked that linux is no more predefined >>with gcc-3.3.3. >>you can check your version of gpc and of its backend >>gcc by typing >>gpc -v. >>The temporary workaround is to add a line >>{$define linux} >>before of after >>{$define LINUX_CONSOLE} >>in grx.pas. >> >>Maurice >> >>-- >> Maurice Lombardi >>Laboratoire de Spectrometrie Physique, >>Universite Joseph Fourier de Grenoble, BP87 >>38402 Saint Martin d'Heres Cedex FRANCE >>Tel: 33 (0)4 76 51 47 51 >>Fax: 33 (0)4 76 63 54 95 >>mailto:Maurice.Lombardi@ujf-grenoble.fr >> >> > > -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: polytest.pas:63: error: type mismatch in argument 1 of `GetCPUTime'
by Maurice Lombardi 08 Mar '05

08 Mar '05

Shutian Ma a écrit: > Dear Maurice, > > I re-installed gpc with gcc, and I can compile some > demos, not all. You may know the following problem. > > Thank you for your help. > > Shutian > > [shma@localhost pascal]$ make -f makefile.lnx > gpc --automake -O1 -Wall -o polytest polytest.pas > -L../lib/unix ../lib/unix/libg > rx20.a -lvga -lm > polytest.pas: In procedure `SpeedTest': > polytest.pas:63: error: type mismatch in argument 1 of > `GetCPUTime' > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/units/gpc.pas:198: > error: routin > e declaration > polytest.pas:87: error: type mismatch in argument 1 of > `GetCPUTime' > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/units/gpc.pas:198: > error: routin > e declaration > polytest.pas:111: error: type mismatch in argument 1 > of `GetCPUTime' > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/units/gpc.pas:198: > error: routin > e declaration > make: *** [polytest] Error 1 > [shma@localhost pascal]$ > --- Maurice Lombardi > <Maurice.Lombardi(a)ujf-grenoble.fr> wrote: Yes. It was a change in recent versions of gpc (introduction of CInteger / CCardinal to secure interface with C programs) which has not (yet) been mirrored in this test. Apply the following diff --- polytest.pas.orig 2003-05-27 21:38:34.000000000 +0000 +++ polytest.pas 2005-03-08 11:57:56.000000000 +0000 @@ -57,7 +57,7 @@ sy : Integer = (GrSizeY - 2*hh) div 32; ii,jj : Integer; color : GrColor; - t1,t2,t3,mu1,mu2,mu3: Integer; + t1,t2,t3,mu1,mu2,mu3: CInteger; begin GrClearScreen(black); t1 := GetCPUTime(mu1); While I am here, I think to an other problems. There have been several diffs with respect to grx-2.4.6 on the gpc or grx lists pertaining to pascal, many related to changes in the syntax of the compiler, for interfaces to assembly / C modules. I attach those I have applied (in order). There are also other diffs pertaining mainly to the win32 driver, which I have not applied, nor kept track of, because I use djgpp. Some are in the grx247p1.zip prerelease. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr diff -u -r grx246.orig/configure grx246/configure --- grx246.orig/configure Wed Oct 16 22:39:58 2002 +++ grx246/configure Mon Apr 26 04:02:04 2004 @@ -6,9 +6,10 @@ # to do with it, just ignore it and follow the normal install # instructions. # -# Copyright (C) 2001-2002 Frank Heckenbach <frank(a)pascal.gnu.de> +# Copyright (C) 2001-2002,2004 Frank Heckenbach <frank(a)pascal.gnu.de> +# Peter Gerwinski <peter(a)gerwinski.de> # -# Parts copied from GCC's configure script, +# Parts copied from some version of GCC's configure script, # Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or @@ -48,6 +49,7 @@ HAVE_LIBPNG=n NEED_ZLIB=n HAVE_LIBTIFF=n +HAVE_UNIX_TOOLS=n INCLUDE_BMP_CODE=y INCLUDE_PRINTING_CODE=y INCLUDE_GPC_SUPPORT=n @@ -146,7 +148,8 @@ --silent silent operation --prefix=PREFIX install files in PREFIX [$default_prefix] --target=TARGET configure for TARGET [$default_target] - possible values: DJGPP, X11, svgalib + possible values: DJGPP, X11, svgalib, w32 + or GCC-style ("i386-mingw32") for cross-compiling --enable-jpeg include JPEG support [no] --enable-png include PNG support [no] --enable-z or use zlib [no] @@ -192,12 +195,23 @@ done case "`echo "$target" | tr A-Z a-z`" in - djgpp) cfgsection=GRXVDJ2; target_makefile=makefile.dj2;; - x | x11) cfgsection=GRXVX11; target_makefile=makefile.x11;; - svgalib) cfgsection=GRXVLNX; target_makefile=makefile.lnx;; - *) echo "$0: invalid target" >&2; exit 1;; + *djgpp*) cfgsection=GRXVDJ2; target_makefile=makefile.dj2;; + x | x11) cfgsection=GRXVX11; target_makefile=makefile.x11;; + svgalib) cfgsection=GRXVLNX; target_makefile=makefile.lnx;; + *w32 | *mingw*) cfgsection=GRXVW32; target_makefile=makefile.w32;; + *) echo "$0: invalid target" >&2; exit 1;; esac +if echo "$target" | tr A-Z a-z | grep "[a-z0-9]-[a-z0-9]" > /dev/null; then + CROSS_PLATFORM="`echo "$target" | tr A-Z a-z`-" + installdir="$prefix/$target" + # Cross-compiling is usually done from a Unix-like platform. + HAVE_UNIX_TOOLS=y +else + CROSS_PLATFORM="" + installdir="$prefix" +fi + if [ $USE_SVGALIB_DRIVER != y ] && [ $USE_FRAMEBUFFER_DRIVER != y ]; then echo "$0: either \`--enable-svgalib' or \`--enable-framebuffer' must be set" >&2 exit 1 @@ -245,19 +259,21 @@ if sed -e "/^HAVE_LIBTIFF=/s/=.*/=$HAVE_LIBTIFF/; /^HAVE_LIBJPEG=/s/=.*/=$HAVE_LIBJPEG/; /^HAVE_LIBPNG=/s/=.*/=$HAVE_LIBPNG/; + /^HAVE_UNIX_TOOLS=/s/=.*/=$HAVE_UNIX_TOOLS/; /^NEED_ZLIB=/s/=.*/=$NEED_ZLIB/; /^INCLUDE_PRINTING_CODE=/s/=.*/=$INCLUDE_PRINTING_CODE/; /^INCLUDE_BMP_CODE=/s/=.*/=$INCLUDE_BMP_CODE/; /^INCLUDE_GPC_SUPPORT=/s/=.*/=$INCLUDE_GPC_SUPPORT/; /^INCLUDE_SHARED_SUPPORT=/s/=.*/=$INCLUDE_SHARED_SUPPORT/; /^INCLUDE_BGI_SUPPORT=/s/=.*/=$INCLUDE_BGI_SUPPORT/; + /^CROSS_PLATFORM=/s/=.*/=$CROSS_PLATFORM/; /^USE_DIRECT_MOUSE_DRIVER=/s/=.*/=$USE_DIRECT_MOUSE_DRIVER/; /^USE_SVGALIB_DRIVER=/s/=.*/=$USE_SVGALIB_DRIVER/; /^USE_FRAMEBUFFER_DRIVER=/s/=.*/=$USE_FRAMEBUFFER_DRIVER/; /^SET_SUIDROOT=/s/=.*/=$SET_SUIDROOT/; /^USE_INOUTP_FRAMEDRIVERS=/s/=.*/=$USE_INOUTP_FRAMEDRIVERS/; /^ifdef $cfgsection\$/,/^endif\$/{ - /^INSTALLDIR=/s|=.*|=$prefix|; + /^INSTALLDIR=/s|=.*|=$installdir|; /^X11BASE=/s|=.*|=$x11base|; $subst_fontpath; /^X11LIBS=/s/\$/$lsocket/; diff -u -r grx246.orig/makedefs.grx grx246/makedefs.grx --- grx246.orig/makedefs.grx Wed Jul 16 04:09:42 2003 +++ grx246/makedefs.grx Mon Apr 26 03:58:39 2004 @@ -36,12 +36,19 @@ # Specify if you want to include BGI support INCLUDE_BGI_SUPPORT=y +# For cross-compiling, specify prefix for tools including the trailing dash +# (e.g. "i386-mingw32-" for using i386-mingw32-gcc instead of just gcc) +CROSS_PLATFORM="" + +# Specify if you want to use Unix tools on DOS-like platforms +HAVE_UNIX_TOOLS=n + ### SYSTEM SETTINGS ################################################## -CC = gcc -AR = ar -RANLIB = ranlib -STRIP = strip +CC = $(CROSS_PLATFORM)gcc +AR = $(CROSS_PLATFORM)ar +RANLIB = $(CROSS_PLATFORM)ranlib +STRIP = $(CROSS_PLATFORM)strip # Different systems / setups may generate .o files # this tag files will show what version is present @@ -85,7 +92,7 @@ # place libgrx20.a and libgrx20.so in lib/unix GRX_LIB_SUBDIR=unix -# Set here the default destination dir for install and uninstall targets +# Set here the destination dir for install and uninstall targets INSTALLDIR=/usr/local # Set the default GRX font path @@ -154,6 +161,9 @@ # Put libgrx20.a to lib/dj2 GRX_LIB_SUBDIR=dj2 +# Set here the destination dir for install and uninstall targets +INSTALLDIR=$(DJDIR) + # If you want to use 'upx.exe' compressor # disable the echo line and enable upx line. EXE_COMPRESS = -echo @@ -184,8 +194,8 @@ # Put libgrx20.a to lib/win32 GRX_LIB_SUBDIR=win32 -# Set here your MINGW dir for install and uninstall targets -MINGWDIR=C:\MINGW +# Set here the destination dir for install and uninstall targets +INSTALLDIR=C:\MINGW # Set the default GRX font path #GRX_DEFAULT_FONT_PATH=c:/grxfonts diff -u -r grx246.orig/pascal/bgi/makefile.dj2 grx246/pascal/bgi/makefile.dj2 --- grx246.orig/pascal/bgi/makefile.dj2 Sun Dec 23 02:29:08 2001 +++ grx246/pascal/bgi/makefile.dj2 Mon Apr 26 03:58:47 2004 @@ -32,9 +32,11 @@ $(COMPILER) $(CCOPT) -o $*.exe $*.pas $(UNITPATH) $(LIBS) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe *.gpi *.gpm +else if exist *.o del *.o if exist *.exe del *.exe if exist *.gpi del *.gpi if exist *.gpm del *.gpm - - +endif diff -u -r grx246.orig/pascal/bgi/makefile.w32 grx246/pascal/bgi/makefile.w32 --- grx246.orig/pascal/bgi/makefile.w32 Sun Dec 23 02:30:18 2001 +++ grx246/pascal/bgi/makefile.w32 Mon Apr 26 03:58:47 2004 @@ -33,9 +33,11 @@ $(COMPILER) $(CCOPT) -o $*.exe $*.pas $(UNITPATH) $(LIBS) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe *.gpi *.gpm +else if exist *.o del *.o if exist *.exe del *.exe if exist *.gpi del *.gpi if exist *.gpm del *.gpm - - +endif diff -u -r grx246.orig/pascal/makefile.dj2 grx246/pascal/makefile.dj2 --- grx246.orig/pascal/makefile.dj2 Wed Jun 11 00:21:24 2003 +++ grx246/pascal/makefile.dj2 Mon Apr 26 03:58:47 2004 @@ -35,9 +35,11 @@ $(COMPILER) $(CCOPT) -o $*.exe $*.pas $(LIBS) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe *.gpi *.gpm +else if exist *.o del *.o if exist *.exe del *.exe if exist *.gpi del *.gpi if exist *.gpm del *.gpm - - +endif diff -u -r grx246.orig/pascal/makefile.w32 grx246/pascal/makefile.w32 --- grx246.orig/pascal/makefile.w32 Wed Jun 11 00:21:24 2003 +++ grx246/pascal/makefile.w32 Mon Apr 26 03:58:47 2004 @@ -35,9 +35,11 @@ $(COMPILER) $(CCOPT) -o $*.exe $*.pas $(LIBS) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe *.gpi *.gpm +else if exist *.o del *.o if exist *.exe del *.exe if exist *.gpi del *.gpi if exist *.gpm del *.gpm - - +endif diff -u -r grx246.orig/src/makefile.dj2 grx246/src/makefile.dj2 --- grx246.orig/src/makefile.dj2 Wed Jul 31 22:34:34 2002 +++ grx246/src/makefile.dj2 Mon Apr 26 04:11:02 2004 @@ -20,8 +20,13 @@ GRX20ln = libgrx20.a GRX20ST = ../lib/$(GRX_LIB_SUBDIR)/$(GRX20ln) +ifeq ($(HAVE_UNIX_TOOLS),y) +GRX20STdos = $(GRX20ST) +INSTALLDIRdos = $(INSTALLDIR) +else GRX20STdos = $(subst /,\,$(GRX20ST)) -DJDIRdos = $(subst /,\,$(DJDIR)) +INSTALLDIRdos = $(subst /,\,$(INSTALLDIR)) +endif OX=.o OP= @@ -120,6 +125,9 @@ all: $(GRX20ST) $(UTILP) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f */*.o ../addons/*.o ../addons/*/*.o $(TAG) +else if exist bgi\*.o del bgi\*.o if exist draw\*.o del draw\*.o if exist fdrivers\*.o del fdrivers\*.o @@ -141,79 +149,153 @@ if exist ..\addons\print\*.o del ..\addons\print\*.o if exist ..\addons\bmp\*.o del ..\addons\bmp\*.o if exist $(TAG) del $(TAG) +endif cleanall: clean +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(GRX20STdos) ../bin/*.exe +else if exist $(GRX20STdos) del $(GRX20STdos) if exist ..\bin\*.exe del ..\bin\*.exe +endif install: $(GRX20ST) - copy $(GRX20STdos) $(DJDIRdos)\lib - copy ..\include\grx20.h $(DJDIRdos)\include - copy ..\include\grxkeys.h $(DJDIRdos)\include - copy ..\include\libbcc.h $(DJDIRdos)\include +ifeq ($(HAVE_UNIX_TOOLS),y) + cp $(GRX20STdos) $(INSTALLDIRdos)/lib + cp ../include/grx20.h ../include/grxkeys.h \ + ../include/libbcc.h $(INSTALLDIRdos)/include +ifeq ($(INCLUDE_PRINTING_CODE),y) + cp ../addons/print/grxprint.h $(INSTALLDIRdos)/include +endif +ifeq ($(INCLUDE_GPC_SUPPORT),y) + mkdir -p $(INSTALLDIRdos)/units + cp ../pascal/grx.pas ../pascal/bgi/graph.pas $(INSTALLDIRdos/units +endif +else + copy $(GRX20STdos) $(INSTALLDIRdos)\lib + copy ..\include\grx20.h $(INSTALLDIRdos)\include + copy ..\include\grxkeys.h $(INSTALLDIRdos)\include + copy ..\include\libbcc.h $(INSTALLDIRdos)\include ifeq ($(INCLUDE_PRINTING_CODE),y) - copy ..\addons\print\grxprint.h $(DJDIRdos)\include + copy ..\addons\print\grxprint.h $(INSTALLDIRdos)\include endif ifeq ($(INCLUDE_GPC_SUPPORT),y) - if not exist $(DJDIRdos)\units\nul mkdir $(DJDIRdos)\units - copy ..\pascal\grx.pas $(DJDIRdos)\units - copy ..\pascal\bgi\graph.pas $(DJDIRdos)\units + if not exist $(INSTALLDIRdos)\units\nul mkdir $(INSTALLDIRdos)\units + copy ..\pascal\grx.pas $(INSTALLDIRdos)\units + copy ..\pascal\bgi\graph.pas $(INSTALLDIRdos)\units +endif endif uninstall: - if exist $(DJDIRdos)\lib\$(GRX20ln) del $(DJDIRdos)\lib\$(GRX20ln) - if exist $(DJDIRdos)\include\grx20.h del $(DJDIRdos)\include\grx20.h - if exist $(DJDIRdos)\include\grxkeys.h del $(DJDIRdos)\include\grxkeys.h - if exist $(DJDIRdos)\include\libbcc.h del $(DJDIRdos)\include\libbcc.h +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(INSTALLDIRdos)/lib/$(GRX20ln) $(INSTALLDIRdos)/include/grx20.h \ + $(INSTALLDIRdos)/include/grxkeys.h $(INSTALLDIRdos)/include/libbcc.h +ifeq ($(INCLUDE_PRINTING_CODE),y) + rm -f $(INSTALLDIRdos)/include/grxprint.h +endif +ifeq ($(INCLUDE_GPC_SUPPORT),y) + rm -f $(INSTALLDIRdos)/units/grx.pas $(INSTALLDIRdos)/units/graph.pas +endif +else + if exist $(INSTALLDIRdos)\lib\$(GRX20ln) del $(INSTALLDIRdos)\lib\$(GRX20ln) + if exist $(INSTALLDIRdos)\include\grx20.h del $(INSTALLDIRdos)\include\grx20.h + if exist $(INSTALLDIRdos)\include\grxkeys.h del $(INSTALLDIRdos)\include\grxkeys.h + if exist $(INSTALLDIRdos)\include\libbcc.h del $(INSTALLDIRdos)\include\libbcc.h ifeq ($(INCLUDE_PRINTING_CODE),y) - if exist $(DJDIRdos)\include\grxprint.h del $(DJDIRdos)\include\grxprint.h + if exist $(INSTALLDIRdos)\include\grxprint.h del $(INSTALLDIRdos)\include\grxprint.h endif ifeq ($(INCLUDE_GPC_SUPPORT),y) - if exist $(DJDIRdos)\units\grx.pas del $(DJDIRdos)\units\grx.pas - if exist $(DJDIRdos)\units\graph.pas del $(DJDIRdos)\units\graph.pas + if exist $(INSTALLDIRdos)\units\grx.pas del $(INSTALLDIRdos)\units\grx.pas + if exist $(INSTALLDIRdos)\units\graph.pas del $(INSTALLDIRdos)\units\graph.pas +endif endif install-info: - copy ..\doc\grx*um.inf $(DJDIRdos)\info\grx.inf - install-info $(DJDIRdos)\info\grx.inf $(DJDIRdos)\info\dir +ifeq ($(HAVE_UNIX_TOOLS),y) + cp ../doc/grx*um.inf $(INSTALLDIRdos)/info/grx.inf + install-info $(INSTALLDIRdos)/info/grx.inf $(INSTALLDIRdos)/info/dir +else + copy ..\doc\grx*um.inf $(INSTALLDIRdos)\info\grx.inf + install-info $(INSTALLDIRdos)\info\grx.inf $(INSTALLDIRdos)\info\dir +endif uninstall-info: - if exist $(DJDIRdos)\info\grx.inf del $(DJDIRdos)\info\grx.inf - install-info -r $(DJDIRdos)\info\grx.inf $(DJDIRdos)\info\dir +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(INSTALLDIRdos)/info/grx.inf + install-info -r $(INSTALLDIRdos)/info/grx.inf $(INSTALLDIRdos)/info/dir +else + if exist $(INSTALLDIRdos)\info\grx.inf del $(INSTALLDIRdos)\info\grx.inf + install-info -r $(INSTALLDIRdos)\info\grx.inf $(INSTALLDIRdos)\info\dir +endif install-bin: $(UTILP) - copy ..\bin\bin2c.exe $(DJDIRdos)\bin - copy ..\bin\fnt2c.exe $(DJDIRdos)\bin - copy ..\bin\vesainfo.exe $(DJDIRdos)\bin - copy ..\bin\modetest.exe $(DJDIRdos)\bin +ifeq ($(HAVE_UNIX_TOOLS),y) + cp ../bin/bin2c.exe ../bin/fnt2c.exe ../bin/vesainfo.exe \ + ../bin/modetest.exe $(INSTALLDIRdos)/bin +else + copy ..\bin\bin2c.exe $(INSTALLDIRdos)\bin + copy ..\bin\fnt2c.exe $(INSTALLDIRdos)\bin + copy ..\bin\vesainfo.exe $(INSTALLDIRdos)\bin + copy ..\bin\modetest.exe $(INSTALLDIRdos)\bin +endif uninstall-bin: - if exist $(DJDIRdos)\bin\bin2c.exe del $(DJDIRdos)\bin\bin2c.exe - if exist $(DJDIRdos)\bin\fnt2c.exe del $(DJDIRdos)\bin\fnt2c.exe - if exist $(DJDIRdos)\bin\vesainfo.exe del $(DJDIRdos)\bin\vesainfo.exe - if exist $(DJDIRdos)\bin\modetest.exe del $(DJDIRdos)\bin\modetest.exe +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(INSTALLDIRdos)/bin/bin2c.exe $(INSTALLDIRdos)/bin/fnt2c.exe \ + $(INSTALLDIRdos)/bin/vesainfo.exe $(INSTALLDIRdos)/bin/modetest.exe +else + if exist $(INSTALLDIRdos)\bin\bin2c.exe del $(INSTALLDIRdos)\bin\bin2c.exe + if exist $(INSTALLDIRdos)\bin\fnt2c.exe del $(INSTALLDIRdos)\bin\fnt2c.exe + if exist $(INSTALLDIRdos)\bin\vesainfo.exe del $(INSTALLDIRdos)\bin\vesainfo.exe + if exist $(INSTALLDIRdos)\bin\modetest.exe del $(INSTALLDIRdos)\bin\modetest.exe +endif ifdef GRX_DEFAULT_FONT_PATH +ifeq ($(HAVE_UNIX_TOOLS),y) +FONTPATHdos = $(GRX_DEFAULT_FONT_PATH) +else FONTPATHdos = $(subst /,\,$(GRX_DEFAULT_FONT_PATH)) +endif install-fonts: +ifeq ($(HAVE_UNIX_TOOLS),y) + mkdir -p $(FONTPATHdos) + cp ../fonts/* $(FONTPATHdos) +else if not exist $(FONTPATHdos)\nul mkdir $(FONTPATHdos) copy ..\fonts\*.* $(FONTPATHdos) +endif uninstall-fonts: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(FONTPATHdos)/* +else del $(FONTPATHdos)\*.* endif +endif dep: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f depend.tmp +else if exist depend.tmp del depend.tmp +endif gcc -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp sed 's#^.*: $.*$\.c#\1.o: \1.c#g' <depend.tmp >depend.dj2 +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f depend.tmp +else if exist depend.tmp del depend.tmp +endif depend.b: depend.new sed "s#\.o:#.obj:#g" <depend.new >depend.b sed "s#\.o:#.asm:#g" <depend.new >>depend.b $(GRX20ST): $(TAG) $(ALL_O) +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(GRX20STdos) +else if exist $(GRX20STdos) del $(GRX20STdos) +endif $(AR) -r $(GRX20ST) $(STD_Oa) $(AR) -r $(GRX20ST) $(STD_Ob) ifeq ($(INCLUDE_BGI_SUPPORT),y) @@ -229,7 +311,11 @@ $(DOS_DJGPP_V2): $(MAKE) -f makefile.dj2 clean +ifeq ($(HAVE_UNIX_TOOLS),y) + if [ ! -r $(DOS-DJGPP_V2) ]; then rm -f $(SYSTEM_TAG_PREFIX).*; fi +else if not exist $(DOS_DJGPP_V2) del $(SYSTEM_TAG_PREFIX).* +endif echo DOS_DJGPP_V2_TARGET > $(DOS_DJGPP_V2) $(ALL_O): $(TAG) diff -u -r grx246.orig/src/makefile.w32 grx246/src/makefile.w32 --- grx246.orig/src/makefile.w32 Sat Mar 22 00:14:14 2003 +++ grx246/src/makefile.w32 Mon Apr 26 04:10:58 2004 @@ -19,7 +19,11 @@ GRX20ln = libgrx20.a GRX20ST = ../lib/$(GRX_LIB_SUBDIR)/$(GRX20ln) +ifeq ($(HAVE_UNIX_TOOLS), y) +GRX20STdos = $(GRX20ST) +else GRX20STdos = $(subst /,\,$(GRX20ST)) +endif OX=.o OP= @@ -96,6 +100,9 @@ all: $(GRX20ST) $(UTILPC) $(UTILPW) clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f */*.o ../addons/*.o ../addons/*/*.o $(TAG) +else if exist bgi\*.o del bgi\*.o if exist draw\*.o del draw\*.o if exist fdrivers\*.o del fdrivers\*.o @@ -117,69 +124,133 @@ if exist ..\addons\print\*.o del ..\addons\print\*.o if exist ..\addons\bmp\*.o del ..\addons\bmp\*.o if exist $(TAG) del $(TAG) +endif cleanall: clean +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(GRX20STdos) ../bin/*.exe +else if exist $(GRX20STdos) del $(GRX20STdos) if exist ..\bin\*.exe del ..\bin\*.exe +endif install: $(GRX20ST) - copy $(GRX20STdos) $(MINGWDIR)\lib - copy ..\include\grx20.h $(MINGWDIR)\include - copy ..\include\grxkeys.h $(MINGWDIR)\include - copy ..\include\libbcc.h $(MINGWDIR)\include +ifeq ($(HAVE_UNIX_TOOLS),y) + cp $(GRX20STdos) $(INSTALLDIR)/lib + cp ../include/grx20.h ../include/grxkeys.h \ + ../include/libbcc.h $(INSTALLDIR)/include +ifeq ($(INCLUDE_PRINTING_CODE),y) + cp ../addons/print/grxprint.h $(INSTALLDIR)/include +endif +ifeq ($(INCLUDE_GPC_SUPPORT),y) + mkdir -p $(INSTALLDIR)/units + cp ../pascal/grx.pas ../pascal/bgi/graph.pas $(INSTALLDIR)/units +endif +else + copy $(GRX20STdos) $(INSTALLDIR)\lib + copy ..\include\grx20.h $(INSTALLDIR)\include + copy ..\include\grxkeys.h $(INSTALLDIR)\include + copy ..\include\libbcc.h $(INSTALLDIR)\include ifeq ($(INCLUDE_PRINTING_CODE),y) - copy ..\addons\print\grxprint.h $(MINGWDIR)\include + copy ..\addons\print\grxprint.h $(INSTALLDIR)\include endif ifeq ($(INCLUDE_GPC_SUPPORT),y) - if not exist $(MINGWDIR)\units\nul mkdir $(MINGWDIR)\units - copy ..\pascal\grx.pas $(MINGWDIR)\units - copy ..\pascal\bgi\graph.pas $(MINGWDIR)\units + if not exist $(INSTALLDIR)\units\nul mkdir $(INSTALLDIR)\units + copy ..\pascal\grx.pas $(INSTALLDIR)\units + copy ..\pascal\bgi\graph.pas $(INSTALLDIR)\units +endif endif uninstall: - if exist $(MINGWDIR)\lib\$(GRX20ln) del $(MINGWDIR)\lib\$(GRX20ln) - if exist $(MINGWDIR)\include\grx20.h del $(MINGWDIR)\include\grx20.h - if exist $(MINGWDIR)\include\grxkeys.h del $(MINGWDIR)\include\grxkeys.h - if exist $(MINGWDIR)\include\libbcc.h del $(MINGWDIR)\include\libbcc.h +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(INSTALLDIR)/lib/$(GRX20ln) $(INSTALLDIR)/include/grx20.h \ + $(INSTALLDIR)/include/grxkeys.h $(INSTALLDIR)/include/libbcc.h ifeq ($(INCLUDE_PRINTING_CODE),y) - if exist $(MINGWDIR)\include\grxprint.h del $(MINGWDIR)\include\grxprint.h + rm -f $(INSTALLDIR)/include/grxprint.h endif ifeq ($(INCLUDE_GPC_SUPPORT),y) - if exist $(MINGWDIR)\units\grx.pas del $(MINGWDIR)\units\grx.pas - if exist $(MINGWDIR)\units\graph.pas del $(MINGWDIR)\units\graph.pas + rm -f $(INSTALLDIR)/units/grx.pas $(INSTALLDIR)/units/graph.pas +endif +else + if exist $(INSTALLDIR)\lib\$(GRX20ln) del $(INSTALLDIR)\lib\$(GRX20ln) + if exist $(INSTALLDIR)\include\grx20.h del $(INSTALLDIR)\include\grx20.h + if exist $(INSTALLDIR)\include\grxkeys.h del $(INSTALLDIR)\include\grxkeys.h + if exist $(INSTALLDIR)\include\libbcc.h del $(INSTALLDIR)\include\libbcc.h +ifeq ($(INCLUDE_PRINTING_CODE),y) + if exist $(INSTALLDIR)\include\grxprint.h del $(INSTALLDIR)\include\grxprint.h +endif +ifeq ($(INCLUDE_GPC_SUPPORT),y) + if exist $(INSTALLDIR)\units\grx.pas del $(INSTALLDIR)\units\grx.pas + if exist $(INSTALLDIR)\units\graph.pas del $(INSTALLDIR)\units\graph.pas +endif endif install-bin: $(UTILPC) $(UTILPW) - copy ..\bin\bin2c.exe $(MINGWDIR)\bin - copy ..\bin\fnt2c.exe $(MINGWDIR)\bin - copy ..\bin\modetest.exe $(MINGWDIR)\bin +ifeq ($(HAVE_UNIX_TOOLS),y) + cp ../bin/bin2c.exe ../bin/fnt2c.exe \ + ../bin/modetest.exe $(INSTALLDIR)/bin +else + copy ..\bin\bin2c.exe $(INSTALLDIR)\bin + copy ..\bin\fnt2c.exe $(INSTALLDIR)\bin + copy ..\bin\modetest.exe $(INSTALLDIR)\bin +endif uninstall-bin: - if exist $(MINGWDIR)\bin\bin2c.exe del $(MINGWDIR)\bin\bin2c.exe - if exist $(MINGWDIR)\bin\fnt2c.exe del $(MINGWDIR)\bin\fnt2c.exe - if exist $(MINGWDIR)\bin\modetest.exe del $(MINGWDIR)\bin\modetest.exe +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(INSTALLDIR)/bin/bin2c.exe $(INSTALLDIR)/bin/fnt2c.exe \ + $(INSTALLDIR)/bin/modetest.exe +else + if exist $(INSTALLDIR)\bin\bin2c.exe del $(INSTALLDIR)\bin\bin2c.exe + if exist $(INSTALLDIR)\bin\fnt2c.exe del $(INSTALLDIR)\bin\fnt2c.exe + if exist $(INSTALLDIR)\bin\modetest.exe del $(INSTALLDIR)\bin\modetest.exe +endif ifdef GRX_DEFAULT_FONT_PATH +ifeq ($(HAVE_UNIX_TOOLS),y) +FONTPATHdos = $(GRX_DEFAULT_FONT_PATH) +else FONTPATHdos = $(subst /,\,$(GRX_DEFAULT_FONT_PATH)) +endif install-fonts: +ifeq ($(HAVE_UNIX_TOOLS),y) + mkdir -p $(FONTPATHdos) + cp ../fonts/* $(FONTPATHdos) +else if not exist $(FONTPATHdos)\nul mkdir $(FONTPATHdos) copy ..\fonts\*.* $(FONTPATHdos) +endif uninstall-fonts: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(FONTPATHdos)/* +else del $(FONTPATHdos)\*.* endif +endif dep: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f depend.tmp +else if exist depend.tmp del depend.tmp +endif gcc -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp sed 's#^.*: $.*$\.c#\1.o: \1.c#g' <depend.tmp >depend.w32 +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f depend.tmp +else if exist depend.tmp del depend.tmp +endif depend.b: depend.new sed "s#\.o:#.obj:#g" <depend.new >depend.b sed "s#\.o:#.asm:#g" <depend.new >>depend.b $(GRX20ST): $(TAG) $(ALL_O) +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f $(GRX20STdos) +else if exist $(GRX20STdos) del $(GRX20STdos) +endif $(AR) -r $(GRX20ST) $(STD_Oa) $(AR) -r $(GRX20ST) $(STD_Ob) $(AR) -r $(GRX20ST) $(STD_Oc) @@ -199,7 +270,12 @@ $(WIN32_GCC_i386_STATIC): $(MAKE) -f makefile.w32 clean +ifeq ($(HAVE_UNIX_TOOLS),y) + if [ ! -r $(WIN32_GCC_i386_STATIC) ]; then \ + rm -f $(SYSTEM_TAG_PREFIX).*; fi +else if not exist $(WIN32_GCC_i386_STATIC) del $(SYSTEM_TAG_PREFIX).* +endif echo WIN32_GCC_i386_STATIC_TARGET > $(WIN32_GCC_i386_STATIC) $(ALL_O): $(TAG) diff -u -r grx246.orig/test/bgi/makefile.dj2 grx246/test/bgi/makefile.dj2 --- grx246.orig/test/bgi/makefile.dj2 Thu Jun 7 21:08:40 2001 +++ grx246/test/bgi/makefile.dj2 Mon Apr 26 03:58:47 2004 @@ -51,8 +51,12 @@ $(CC) -S $(CCOPT) $(INCDIR) $*.c clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe +else if exist *.o del *.o if exist *.exe del *.exe +endif depend.new: $(CC) -MM $(CCOPT) $(INCDIR) $(PROGS:.exe=.c) >depend.new diff -u -r grx246.orig/test/bgi/makefile.w32 grx246/test/bgi/makefile.w32 --- grx246.orig/test/bgi/makefile.w32 Sat Aug 10 00:04:46 2002 +++ grx246/test/bgi/makefile.w32 Mon Apr 26 03:58:47 2004 @@ -49,8 +49,12 @@ $(CC) -S $(CCOPT) $(INCDIR) $*.c clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe +else if exist *.o del *.o if exist *.exe del *.exe +endif #depend.new: # $(CC) -MM $(CCOPT) $(INCDIR) $(PROGS:.exe=.c) >depend.new diff -u -r grx246.orig/test/makefile.dj2 grx246/test/makefile.dj2 --- grx246.orig/test/makefile.dj2 Mon Jun 17 22:09:10 2002 +++ grx246/test/makefile.dj2 Mon Apr 26 03:58:47 2004 @@ -74,8 +74,12 @@ $(CC) -S $(CCOPT) $(INCDIR) $*.c clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe +else if exist *.o del *.o if exist *.exe del *.exe +endif depend.new: $(CC) -MM $(CCOPT) $(INCDIR) $(PROGS:.exe=.c) >depend.new diff -u -r grx246.orig/test/makefile.w32 grx246/test/makefile.w32 --- grx246.orig/test/makefile.w32 Mon Jun 17 22:08:38 2002 +++ grx246/test/makefile.w32 Mon Apr 26 03:58:47 2004 @@ -84,8 +84,12 @@ $(CC) -S $(CCOPT) $(INCDIR) $*.c clean: +ifeq ($(HAVE_UNIX_TOOLS),y) + rm -f *.o *.exe +else if exist *.o del *.o if exist *.exe del *.exe +endif depend.new: $(CC) -MM $(CCOPT) $(INCDIR) $(PROGS:.exe=.c) >depend.new --- grx246.orig/configure Sun Jun 6 21:11:25 2004 +++ grx246.new/configure Sun Jun 6 21:15:45 2004 @@ -202,15 +202,16 @@ *) echo "$0: invalid target" >&2; exit 1;; esac -if echo "$target" | tr A-Z a-z | grep "[a-z0-9]-[a-z0-9]" > /dev/null; then - CROSS_PLATFORM="`echo "$target" | tr A-Z a-z`-" - installdir="$prefix/$target" - # Cross-compiling is usually done from a Unix-like platform. - HAVE_UNIX_TOOLS=y -else - CROSS_PLATFORM="" - installdir="$prefix" -fi +case "$target" in + *[A-Za-z0-9]-[A-Za-z0-9]*|mingw32) + CROSS_PLATFORM="`echo "$target" | tr A-Z a-z`-" + installdir="$prefix/$target" + # Cross-compiling is usually done from a Unix-like platform. + HAVE_UNIX_TOOLS=y;; + *) + CROSS_PLATFORM="" + installdir="$prefix";; +esac if [ $USE_SVGALIB_DRIVER != y ] && [ $USE_FRAMEBUFFER_DRIVER != y ]; then echo "$0: either \`--enable-svgalib' or \`--enable-framebuffer' must be set" >&2 --- grx246.orig/makedefs.grx Sun Jun 6 21:11:25 2004 +++ grx246.new/makedefs.grx Sun Jun 6 21:12:54 2004 @@ -46,6 +46,7 @@ ### SYSTEM SETTINGS ################################################## CC = $(CROSS_PLATFORM)gcc +PC = $(CROSS_PLATFORM)gpc AR = $(CROSS_PLATFORM)ar RANLIB = $(CROSS_PLATFORM)ranlib STRIP = $(CROSS_PLATFORM)strip --- grx246.orig/pascal/bgi/makefile.dj2 Sun Jun 6 21:11:25 2004 +++ grx246.new/pascal/bgi/makefile.dj2 Sun Jun 6 21:13:23 2004 @@ -16,7 +16,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ allmodes.exe \ --- grx246.orig/pascal/bgi/makefile.lnx Sun Dec 23 02:32:40 2001 +++ grx246.new/pascal/bgi/makefile.lnx Sun Jun 6 21:13:28 2004 @@ -15,7 +15,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) -lvga -lm # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ allmodes \ --- grx246.orig/pascal/bgi/makefile.w32 Sun Jun 6 21:11:25 2004 +++ grx246.new/pascal/bgi/makefile.w32 Sun Jun 6 21:35:43 2004 @@ -16,7 +16,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) -mwindows -mconsole # Compiler and options on your system -COMPILER = gpc --autobuild --gpc-main=GRXMain +COMPILER = $(PC) --autobuild PROGS= \ --- grx246.orig/pascal/bgi/makefile.x11 Sun Dec 23 02:31:34 2001 +++ grx246.new/pascal/bgi/makefile.x11 Sun Jun 6 21:13:28 2004 @@ -15,7 +15,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) $(X11LIBS) -lm # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ xallmodes \ --- grx246.orig/pascal/makefile Wed Jun 11 00:21:24 2003 +++ grx246.new/pascal/makefile Sun Jun 6 21:35:33 2004 @@ -9,7 +9,7 @@ GRAPHICSLIB = -L/usr/lib # Compiler and options on your system -COMPILER = gpc --automake -Wall +COMPILER = $(PC) --automake -Wall # -------------------------------------------- # I Think, you don't need to change from here --- grx246.orig/pascal/makefile.dj2 Sun Jun 6 21:11:25 2004 +++ grx246.new/pascal/makefile.dj2 Sun Jun 6 21:13:19 2004 @@ -15,7 +15,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ --- grx246.orig/pascal/makefile.lnx Wed Jun 11 00:21:24 2003 +++ grx246.new/pascal/makefile.lnx Sun Jun 6 21:13:23 2004 @@ -14,7 +14,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) -lvga -lm # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ --- grx246.orig/pascal/makefile.w32 Sun Jun 6 21:11:25 2004 +++ grx246.new/pascal/makefile.w32 Sun Jun 6 21:35:53 2004 @@ -15,7 +15,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) -mwindows -mconsole # Compiler and options on your system -COMPILER = gpc --autobuild --gpc-main=GRXMain +COMPILER = $(PC) --autobuild PROGS= \ --- grx246.orig/pascal/makefile.x11 Wed Jun 11 00:21:24 2003 +++ grx246.new/pascal/makefile.x11 Sun Jun 6 21:13:19 2004 @@ -14,7 +14,7 @@ LIBS= $(GRXLIBPATH) $(GRXLIB) $(X11LIBS) -lm # Compiler and options on your system -COMPILER = gpc --automake +COMPILER = $(PC) --automake PROGS= \ --- grx246.orig/pascal/modetest.pas Tue May 27 21:23:20 2003 +++ grx246.new/pascal/modetest.pas Sun Jun 6 21:34:04 2004 @@ -21,7 +21,7 @@ Write (i:3); Write (f:3); Write (gvm.Mode:6); - Write (gvm.Width:5, 'x',gvm.Height:4, 'x', Ord(gvm.BPP):3); + Write (gvm.Width:5, 'x',gvm.Height:4, 'x', gvm.BPP:3); WriteLn; fivm := GrNextVideoMode(fivm) end --- grx246.orig/src/makefile.dj2 Sun Jun 6 21:11:25 2004 +++ grx246.new/src/makefile.dj2 Sun Jun 6 21:12:47 2004 @@ -278,7 +278,7 @@ else if exist depend.tmp del depend.tmp endif - gcc -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp + $(CC) -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp sed 's#^.*: $.*$\.c#\1.o: \1.c#g' <depend.tmp >depend.dj2 ifeq ($(HAVE_UNIX_TOOLS),y) rm -f depend.tmp --- grx246.orig/src/makefile.lnx Mon Jun 23 18:13:22 2003 +++ grx246.new/src/makefile.lnx Sun Jun 6 21:12:47 2004 @@ -263,7 +263,7 @@ endif dep: - gcc -MM $(CCOPT) $(INCDIR) $(O:.o=.c) \ + $(CC) -MM $(CCOPT) $(INCDIR) $(O:.o=.c) \ | sed 's#^.*: $.*$\.c#\1.o: \1.c#g' >depend.lnx $(O): %.o : %.c --- grx246.orig/src/makefile.w32 Sun Jun 6 21:11:25 2004 +++ grx246.new/src/makefile.w32 Sun Jun 6 21:12:43 2004 @@ -233,7 +233,7 @@ else if exist depend.tmp del depend.tmp endif - gcc -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp + $(CC) -MM $(CCOPT) $(INCDIR) $(ALL_O:.o=.c) >depend.tmp sed 's#^.*: $.*$\.c#\1.o: \1.c#g' <depend.tmp >depend.w32 ifeq ($(HAVE_UNIX_TOOLS),y) rm -f depend.tmp --- grx246.orig/src/makefile.x11 Mon Jun 23 18:13:22 2003 +++ grx246.new/src/makefile.x11 Sun Jun 6 21:12:43 2004 @@ -255,7 +255,7 @@ endif dep: - gcc -MM $(CCOPT) $(INCDIR) $(O:.o=.c) \ + $(CC) -MM $(CCOPT) $(INCDIR) $(O:.o=.c) \ | sed 's#^.*: $.*$\.c#\1.o: \1.c#g' >depend.x11 $(O): %.o : %.c --- grx.pas.orig Fri Apr 25 02:10:07 2003 +++ grx.pas Sun Mar 28 23:15:23 2004 @@ -188,34 +188,35 @@ type + GrVideoModePtr = ^GrVideoMode; + { The video driver descriptor structure } { struct _GR_videoDriver } + GrVideoDriverPtr = ^GrVideoDriver; GrVideoDriver = record - Name : CString; { driver name } - Adapter : Char; { adapter type } - Inherit : ^GrVideoDriver; { inherit video modes from this } - Modes : ^GrVideoMode; { table of supported modes } - NModes : Integer; { number of modes } - Detect : Pointer; - Init : Pointer; - Reset : Pointer; - SelectMode: Pointer; - DrvFlags : Integer; + Name : CString; { driver name } + Adapter : Integer; { adapter type } + Inherit : GrVideoDriverPtr; { inherit video modes from this } + Modes : GrVideoModePtr; { table of supported modes } + NModes : Integer; { number of modes } + Detect : function: Integer; + Init : function (Options: CString): Integer; + Reset : procedure; + SelectMode: function (Drv: GrVideoDriverPtr; w, h, BPP, txt: Integer; var ep: Cardinal): GrVideoModePtr; + DrvFlags : Cardinal; end; - GrVideoDriverPtr = ^GrVideoDriver; { Video driver mode descriptor structure } { struct _GR_videoMode } GrVideoMode = record - Present : Char; { is it really available? } - BPP : Char; { log2 of # of colors } - Width,Height: ShortInt; { video mode geometry } + Present : ByteBool; { is it really available? } + BPP : Byte; { log2 of # of colors } + Width,Height: ShortInt; { video mode geometry } Mode : ShortInt; { BIOS mode number (if any) } - LineOffset : Integer; { scan line length } - PrivData : Integer; { driver can use it for anything } - ExtInfo : ^GrVideoModeExt; { extra info (maybe shared) } + LineOffset : Integer; { scan line length } + PrivData : Integer; { driver can use it for anything } + ExtInfo : ^GrVideoModeExt; { extra info (maybe shared) } end; - GrVideoModePtr = ^GrVideoMode; { Video driver mode descriptor extension structure. This is a separate structure accessed via a pointer from the main mode descriptor. The @@ -223,6 +224,7 @@ extended info. } { struct _GR_videoModeExt } + Int2 = array [0 .. 1] of Integer; GrVideoModeExt = record Mode : Integer; { frame driver for this video mode } Drv : ^GrFrameDriver; { optional frame driver override } @@ -230,15 +232,26 @@ CPrec : array [1 .. 3] of ByteCard; { color component precisions } CPos : array [1 .. 3] of ByteCard; { color component bit positions } Flags : Integer; { mode flag bits; see "grdriver.h" } - Setup : Pointer; - SetVSize : Pointer; - Scroll : Pointer; - SetBank : Pointer; - SetRWBanks : Pointer; - LoadColor : Pointer; + Setup : function (var md: GrVideoMode; NoClear: Integer): Integer; + SetVSize : function (var md: GrVideoMode; w, h: Integer; var Result: GrVideoMode): Integer; + Scroll : function (var md: GrVideoMode; x, y: Integer; var Result: Int2): Integer; + SetBank : procedure (bk: Integer); + SetRWBanks : procedure (rb, wb: Integer); + LoadColor : procedure (c, r, g, b: Integer); LFB_Selector: Integer; end; + GrFrameDriverPtr = ^GrFrameDriver; + + GrFrameType = record + gf_BaseAddr : array [0 .. 3] of MemPtr; { base address of frame memory } + gf_Selector : ShortInt; { frame memory segment selector } + gf_OnScreen : ByteBool; { is it in video memory ? } + gf_MemFlags : Byte; { memory allocation flags } + gf_LineOffset: Integer; { offset to next scan line in bytes } + gf_Driver : GrFrameDriverPtr; { frame access functions } + end; + { The frame driver descriptor structure. } { struct _GR_frameDriver } @@ -249,46 +262,45 @@ Row_Align : Integer; { scan line size alignment } Num_Planes : Integer; { number of planes } Bits_Per_Pixel : Integer; { bits per pixel } - Max_Plane_Size : Integer; { maximum plane size in bytes } - Init : Pointer; - ReadPixel : Pointer; - DrawPixel : Pointer; - DrawLine : Pointer; - DrawHLine : Pointer; - DrawVLine : Pointer; - DrawBlock : Pointer; - DrawBitmap : Pointer; - DrawPattern : Pointer; - BitBlt : Pointer; - BltV2R : Pointer; - BltR2V : Pointer; - GetIndexedScanline: Pointer; - PutScanLine : Pointer; + Max_Plane_Size : MedInt; { maximum plane size in bytes } + Init : function (var md: GrVideoMode): Integer; + ReadPixel : function (var c: GrFrameType; x, y: Integer): GrColor; + DrawPixel : procedure (x, y: Integer; c: GrColor); + DrawLine : procedure (x, y, dx, dy: Integer; c: GrColor); + DrawHLine : procedure (x, y, w: Integer; c: GrColor); + DrawVLine : procedure (x, y, h: Integer; c: GrColor); + DrawBlock : procedure (x, y, w, h: Integer; c: GrColor); + DrawBitmap : procedure (x, y, w, h: Integer; BMP: MemPtr; Pitch, Start: Integer; fg, bg: GrColor); + DrawPattern : procedure (x, y, w: Integer; Patt: Byte; fg, bg: GrColor); + BitBlt : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); + BltV2R : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); + BltR2V : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); + GetIndexedScanline: function (var c: GrFrameType; x, y, w: Integer; var Index: Integer): GrColorsPtr; + PutScanLine : procedure (x, y, w: Integer; scl: GrColorsPtr; Op: GrColor); end; - GrFrameDriverPtr = ^GrFrameDriver; { driver and mode info structure } { extern const struct _GR_driverInfo } GrDriverInfoType = record - VDriver : ^GrVideoDriver; { the current video driver } - CurMode : ^GrVideoMode; { current video mode pointer } - ActMode : GrVideoMode; { copy of above, resized if virtual } - FDriver : GrFrameDriver; { frame driver for the current context } - SDriver : GrFrameDriver; { frame driver for the screen } - TDriver : GrFrameDriver; { a dummy driver for text modes } - MCode : ByteCard; { code for the current mode } - DefTW,DefTH: Integer; { default text mode size } - DefGW,DefGH: Integer; { default graphics mode size } - DefTC,DefGC: GrColor; { default text and graphics colors } - VPosX,VPosY: Integer; { current virtual viewport position } - ErrsFatal : Integer; { if set, exit upon errors } - ModeRestore: Integer; { restore startup video mode if set } - SplitBanks : Integer; { indicates separate R/W banks } - CurBank : Integer; { currently mapped bank } - MdSetHook : Pointer; { callback for mode set } - SetBank : Pointer; { banking routine } - SetRWBanks : Pointer; { split banking routine } + VDriver : GrVideoDriverPtr; { the current video driver } + CurMode : GrVideoModePtr; { current video mode pointer } + ActMode : GrVideoMode; { copy of above, resized if virtual } + FDriver : GrFrameDriver; { frame driver for the current context } + SDriver : GrFrameDriver; { frame driver for the screen } + TDriver : GrFrameDriver; { a dummy driver for text modes } + MCode : Integer; { code for the current mode } + DefTW,DefTH: Integer; { default text mode size } + DefGW,DefGH: Integer; { default graphics mode size } + DefTC,DefGC: GrColor; { default text and graphics colors } + VPosX,VPosY: Integer; { current virtual viewport position } + ErrsFatal : Integer; { if set, exit upon errors } + ModeRestore: Integer; { restore startup video mode if set } + SplitBanks : Integer; { indicates separate R/W banks } + CurBank : Integer; { currently mapped bank } + MdSetHook : procedure; { callback for mode set } + SetBank : procedure (bk: Integer); { banking routine } + SetRWBanks : procedure (rb, wb: Integer); { split banking routine } end; var @@ -351,33 +363,24 @@ ================================================================== } type - GrFrameType = record - gf_BaseAddr : array [0 .. 3] of MemPtr; { base address of frame memory } - gf_Selector : ShortInt; { frame memory segment selector } - gf_OnScreen : Char; { is it in video memory ? } - gf_MemFlags : Char; { memory allocation flags } - gf_LineOffset: Integer; { offset to next scan line in bytes } - gf_Driver : ^GrFrameDriver; { frame access functions } - end; - { struct _GR_context } + GrContextPtr = ^GrContext; GrContext = record - gc_Frame : GrFrameType; { frame buffer info } - gc_Root : ^GrContext; { context which owns frame } - gc_XMax : Integer; { max X coord (width - 1) } - gc_YMax : Integer; { max Y coord (height - 1) } - gc_XOffset : Integer; { X offset from root's base } - gc_YOffset : Integer; { Y offset from root's base } - gc_XClipLo : Integer; { low X clipping limit } - gc_YClipLo : Integer; { low Y clipping limit } - gc_XClipHi : Integer; { high X clipping limit } - gc_YClipHi : Integer; { high Y clipping limit } - gc_UsrXBase : Integer; { user window min X coordinate } - gc_UsrYBase : Integer; { user window min Y coordinate } - gc_UsrWidth : Integer; { user window width } - gc_UsrHeight: Integer; { user window height } + gc_Frame : GrFrameType; { frame buffer info } + gc_Root : GrContextPtr; { context which owns frame } + gc_XMax : Integer; { max X coord (width - 1) } + gc_YMax : Integer; { max Y coord (height - 1) } + gc_XOffset : Integer; { X offset from root's base } + gc_YOffset : Integer; { Y offset from root's base } + gc_XClipLo : Integer; { low X clipping limit } + gc_YClipLo : Integer; { low Y clipping limit } + gc_XClipHi : Integer; { high X clipping limit } + gc_YClipHi : Integer; { high Y clipping limit } + gc_UsrXBase : Integer; { user window min X coordinate } + gc_UsrYBase : Integer; { user window min Y coordinate } + gc_UsrWidth : Integer; { user window width } + gc_UsrHeight: Integer; { user window height } end; - GrContextPtr = ^GrContext; { extern const struct _GR_contextInfo } GrContextInfoType = record @@ -472,11 +475,11 @@ type { typedef struct } { framed box colors } GrFBoxColors = record - fbx_IntegerColor: Integer; - fbx_TopColor : Integer; - fbx_RightColor : Integer; - fbx_BottomColor : Integer; - fbx_LeftColor : Integer; + fbx_IntColor : GrColor; + fbx_TopColor : GrColor; + fbx_RightColor : GrColor; + fbx_BottomColor: GrColor; + fbx_LeftColor : GrColor; end; procedure GrClearScreen(bg:GrColor); asmname 'GrClearScreen'; @@ -503,7 +506,7 @@ procedure GrPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrPolygon'; procedure GrFilledConvexPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledConvexPolygon'; procedure GrFilledPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledPolygon'; -procedure GrBitBlt(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; op: GrColor); asmname 'GrBitBlt'; +procedure GrBitBlt(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; Op: GrColor); asmname 'GrBitBlt'; function GrPixel(x, y:Integer):GrColor; asmname 'GrPixel'; function GrPixelC(c: GrContextPtr; x, y: Integer): GrColor; asmname 'GrPixelC'; @@ -521,12 +524,12 @@ { (w = |x2-y1|) } { Output data is valid until next GRX call ! } -procedure GrPutScanline(x1,x2,yy: Integer;c: GrColorsPtr; op: GrColor); asmname 'GrPutScanline'; +procedure GrPutScanline(x1,x2,yy: Integer;c: GrColorsPtr; Op: GrColor); asmname 'GrPutScanline'; { Input x1: first x coordinate to be set } { x2: last x coordinate to be set } { yy: y coordinate } { c : c[0..(|x2-x1|] hold the pixel data } -{ op: Operation (GrWRITE/GrXOR/GrOR/GrAND/GrIMAGE) } +{ Op: Operation (GrWRITE/GrXOR/GrOR/GrAND/GrIMAGE) } { } { Note c[..] data must fit GrCVALUEMASK otherwise the results } { are implementation dependend. } @@ -544,7 +547,7 @@ procedure GrBoxNC(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrBoxNC'; procedure GrFilledBoxNC(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrFilledBoxNC'; procedure GrFramedBoxNC(x1, y1, x2, y2, Wdt: Integer; protected var c: GrFBoxColors); asmname 'GrFramedBoxNC'; -procedure GrBitBltNC(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; op: GrColor); asmname 'GrBitBltNC'; +procedure GrBitBltNC(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; Op: GrColor); asmname 'GrBitBltNC'; function GrPixelNC(x, y:Integer):GrColor; asmname 'GrPixelNC'; function GrPixelCNC(c: GrContextPtr; x, y: Integer): GrColor; asmname 'GrPixelCNC'; @@ -592,41 +595,40 @@ type { typedef struct _GR_fontHeader } { font descriptor } GrFontHeader = record - Name : CString; { font name } - Family : CString; { font family name } - Proportional: Char; { characters have varying width } - Scalable : Char; { derived from a scalable font } - Preloaded : Char; { set when linked Integero program } - Modified : Char; { "tweaked" font (resized, etc..) } - Width : Integer; { width (proportional=>average) } - Height : Integer; { font height } - Baseline : Integer; { baseline pixel pos (from top) } - ULPos : Integer; { underline pixel pos (from top) } - ULHeight : Integer; { underline width } - MinChar : Integer; { lowest character code in font } - NumChars : Integer; { number of characters in font } + Name : CString; { font name } + Family : CString; { font family name } + Proportional: ByteBool; { characters have varying width } + Scalable : ByteBool; { derived from a scalable font } + Preloaded : ByteBool; { set when linked Integero program } + Modified : ByteBool; { "tweaked" font (resized, etc..) } + Width : Cardinal; { width (proportional=>average) } + Height : Cardinal; { font height } + Baseline : Cardinal; { baseline pixel pos (from top) } + ULPos : Cardinal; { underline pixel pos (from top) } + ULHeight : Cardinal; { underline width } + MinChar : Cardinal; { lowest character code in font } + NumChars : Cardinal; { number of characters in font } end; { typedef struct _GR_fontChrInfo } { character descriptor } GrFontChrInfo = record - Width : Integer; { width of this character } - Offset: Integer; { offset from start of bitmap } + Width : Cardinal; { width of this character } + Offset: Cardinal; { offset from start of bitmap } end; { typedef struct _GR_font } { the complete font } - AuxoffsType = array [1 .. 7] of Integer; + AuxOffsType = array [0 .. 6] of Integer; GrFont = record h : GrFontHeader; { the font info structure } BitMap : MemPtr; { character bitmap array } AuxMap : MemPtr; { map for rotated & underline chrs } - MinWidth: Integer; { width of narrowest character } - MaxWidth: Integer; { width of widest character } - AuxSize : Integer; { allocated size of auxiliary map } - AuxNext : Integer; { next free byte in auxiliary map } - AuxOffs : ^AuxoffsType; { offsets to completed aux chars } - ChrInfo : array [1 .. 1] of GrFontChrInfo; { character info (not act. size) } + MinWidth: Cardinal; { width of narrowest character } + MaxWidth: Cardinal; { width of widest character } + AuxSize : Cardinal; { allocated size of auxiliary map } + AuxNext : Cardinal; { next free byte in auxiliary map } + AuxOffs : ^AuxOffsType; { offsets to completed aux chars } + ChrInfo : array [1 .. 1] of GrFontChrInfo; { character info (not act. size) } end; - GrFontPtr = ^GrFont; var @@ -657,11 +659,11 @@ function GrFontCharAuxBmp(var Font: GrFont; Chr, Dir, ul: Integer): MemPtr; asmname 'GrFontCharAuxBmp'; type - GrColorTableP = ^GrColor; + GrColorTableP = ^GrColors; { typedef union _GR_textColor } { text color union } GrTextColor = record - case 1..2 of + case 1 .. 2 of 1: (v: GrColor); { color value for "direct" text } 2: (p: GrColorTableP); { color table for attribute text } end; @@ -689,7 +691,7 @@ txr_LineOffset: Integer; { offset in buffer(s) between rows } txr_XPos : Integer; { upper left corner X coordinate } txr_YPos : Integer; { upper left corner Y coordinate } - txr_ChrType : Char; { character type (see above) } + txr_ChrType : ByteCard; { character type (see above) } end; function GrCharWidth(Chr: Integer; protected var Opt: GrTextOption): Integer; asmname 'GrCharWidth'; @@ -717,10 +719,10 @@ type GrLineOption = record - No_Color : GrColor; { color used to draw line } - Lno_Width : Integer; { width of the line } - Lno_PattLen: Integer; { length of the dash pattern } - Lno_DashPat: ^ByteCard; { draw/nodraw pattern } + No_Color : GrColor; { color used to draw line } + Lno_Width : Integer; { width of the line } + Lno_PattLen: Integer; { length of the dash pattern } + Lno_DashPat: MemPtr; { draw/nodraw pattern } end; procedure GrCustomLine(x1, y1, x2, y2: Integer; protected var o: GrLineOption); asmname 'GrCustomLine'; @@ -745,7 +747,7 @@ GrBitmap = record bmp_IsPixMap: Integer; { type flag for pattern union } bmp_Height : Integer; { bitmap height } - bmp_Data : ^ByteCard; { pointer to the bit pattern } + bmp_Data : MemPtr; { pointer to the bit pattern } bmp_FgColor : GrColor; { foreground color for fill } bmp_BgColor : GrColor; { background color for fill } bmp_MemFlags: Integer; { set if dynamically allocated } @@ -769,9 +771,10 @@ { typedef union _GR_pattern } GrPattern = record - gp_IsPixMap: Integer; { nonzero for pixmaps } - gp_BitMap : GrBitmap; { fill bitmap } - gp_PixMap : GrPixmap; { fill pixmap } + case 1 .. 3 of + 1: (gp_IsPixMap: Integer); { nonzero for pixmaps } + 2: (gp_BitMap : GrBitmap); { fill bitmap } + 3: (gp_PixMap : GrPixmap); { fill pixmap } end; GrPatternPtr = ^GrPattern; @@ -820,11 +823,6 @@ <e-mail> - [stenclpmd(a)ba.telecom.sk] } type - { Original GRX decl: - GrImage = GrPixmap; - GrImagePtr = ^GrImage; - Pascal isn't case sensitive so GrImage conficts with GrIMAGE above. - Since we only need GrImagePtr we take a short cut here: } GrImagePtr = ^GrPixmap; { Flags for GrImageInverse() } @@ -991,7 +989,7 @@ Buttons: Integer; { mouse button state } Key : Integer; { key code from keyboard } KBStat : Integer; { keybd status (ALT, CTRL, etc..) } - DTime : Integer; { time since last event (msec) } + DTime : MedInt; { time since last event (msec) } end; GrMouseEventPtr = ^GrMouseEvent; --- grx246/pascal/bgi/graph.pas.orig Fri Sep 17 18:57:44 2004 +++ grx246/pascal/bgi/graph.pas Fri Sep 17 19:04:19 2004 @@ -19,8 +19,7 @@ 22/02/01 patches by Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> Necessary to correct the drawpoly and fillpoly declarations. Some changes to make this file compile with more recent versions of - gpc (change in declaration of external variables, removal of now - invalid __soso__ declarations). } + gpc. } { Define this if you don't want this unit to declare a KeyPressed and a ReadKey function. } @@ -62,9 +61,14 @@ {$else} {$define varasmname external; asmname} {$endif} +{$if __GPC_RELEASE__ < 20040917} +type + CInteger = Integer; + CCardinal = Cardinal; +{$endif} type - PByte = ^Byte; + PByte = ^Byte; WrkString = String[255]; const @@ -263,26 +267,26 @@ type PaletteType = record Size : Byte; - Colors: array [0 .. MaxColors] of Byte; + Colors: array [0 .. MaxColors] of Byte end; LineSettingsType = record - LineStyle: Integer; + LineStyle: CInteger; UPattern : ShortCard; - Thickness: Integer; + Thickness: CInteger end; TextSettingsType = record - Font : Integer; - Direction: Integer; - CharSize : Integer; - Horiz : Integer; - Vert : Integer; + Font, + Direction, + CharSize, + Horiz, + Vert: CInteger end; FillSettingsType = record - Pattern: Integer; - Color : Integer; + Pattern, + Color: CInteger end; FillPatternType = array [1 .. 8] of Byte; @@ -290,17 +294,17 @@ { This definition is compatible with the grx definition `int pts[][2]' used to define polygons } PointType = record - x, y: Integer; + x, y: CInteger end; ViewPortType = record - x1, y1, x2, y2: Integer; - Clip: WordBool; + x1, y1, x2, y2: CInteger; + Clip: WordBool end; ArcCoordsType = record - x, y:Integer; - XStart, YStart, XEnd, YEnd: Integer; + x, y, + XStart, YStart, XEnd, YEnd: CInteger end; var @@ -309,105 +313,105 @@ { BGI - API definitions } -procedure DetectGraph(var GraphDriver, GraphMode: Integer); asmname 'detectgraph'; -procedure InitGraph(var GraphDriver, GraphMode: Integer; PathToDriver: CString); asmname 'initgraph'; -procedure SetGraphMode(Mode: Integer); asmname 'setgraphmode'; -function GetModeName(ModeNumber: Integer): WrkString; +procedure DetectGraph(var GraphDriver, GraphMode: CInteger); asmname 'detectgraph'; +procedure InitGraph(var GraphDriver, GraphMode: Integer; PathToDriver: CString); +procedure SetGraphMode(Mode: CInteger); asmname 'setgraphmode'; +function GetModeName(ModeNumber: CInteger): WrkString; procedure GraphDefaults; asmname 'graphdefaults'; function GetDriverName: WrkString; -function GraphErrorMsg(ErrorCode: Integer): WrkString; -function GetMaxX: Integer; asmname 'getmaxx'; -function GetMaxY: Integer; asmname 'getmaxy'; -function GetMaxColor: Integer; asmname 'getmaxcolor'; +function GraphErrorMsg(ErrorCode: CInteger): WrkString; +function GetMaxX: CInteger; asmname 'getmaxx'; +function GetMaxY: CInteger; asmname 'getmaxy'; +function GetMaxColor: CInteger; asmname 'getmaxcolor'; procedure GetViewSettings(var ViewPort: ViewPortType); asmname 'getviewsettings'; -procedure SetViewPort(Left, Top, Right, Bottom: Integer; Clip: Boolean); asmname 'setviewport'; +procedure SetViewPort(Left, Top, Right, Bottom: CInteger; Clip: Boolean); asmname 'setviewport'; procedure GetLineSettings(var LineInfo: LineSettingsType); asmname 'getlinesettings'; -procedure SetLineStyle(LineStyle: Integer; Pattern: Integer; Thickness: Integer); asmname 'setlinestyle'; +procedure SetLineStyle(LineStyle: CInteger; Pattern: CInteger; Thickness: CInteger); asmname 'setlinestyle'; procedure ClearViewPort; asmname 'clearviewport'; -function GetPixel(x,y: Integer): Integer; asmname 'getpixel'; -procedure PutPixel(x, y: Integer; Pixel: Integer); asmname 'putpixel'; -procedure Bar3D(Left, Top, Right, Bottom: Integer; Depth: Integer; TopFlag: Boolean); asmname 'bar'; -procedure Rectangle(Left, Top, Right, Bottom: Integer); asmname 'rectangle'; -procedure FillPoly(NumPoints: Word; var PolyPoints { : array of PointType }); asmname 'fillpoly'; -procedure FillEllipse(x, y: Integer; XRadius, YRadius: Integer); asmname 'fillellipse'; +function GetPixel(x,y: CInteger): CInteger; asmname 'getpixel'; +procedure PutPixel(x, y: CInteger; Pixel: CInteger); asmname 'putpixel'; +procedure Bar3D(Left, Top, Right, Bottom: CInteger; Depth: CInteger; TopFlag: Boolean); asmname 'bar'; +procedure Rectangle(Left, Top, Right, Bottom: CInteger); asmname 'rectangle'; +procedure FillPoly(NumPoints: CCardinal; var PolyPoints { : array of PointType }); asmname 'fillpoly'; +procedure FillEllipse(x, y: CInteger; XRadius, YRadius: CInteger); asmname 'fillellipse'; procedure GetArcCoords(var ArcCoords: ArcCoordsType); asmname 'getarccoords'; -procedure FloodFill(x, y: Integer; Border: Integer); asmname 'floodfill'; -procedure SetFillPattern(UPattern: FillPatternType; Color: Integer); asmname 'setfillpattern'; -procedure SetFillStyle(Pattern: Integer; Color: Integer); asmname 'setfillstyle'; -procedure GetImage(Left, Top, Right, Bottom: Integer; var BitMap); asmname 'getimage'; -procedure PutImage(Left, Top: Integer; var BitMap; Op: Integer); asmname 'putimage'; -function ImageSize(Left, Top, Right, Bottom: Integer): Integer; asmname 'imagesize'; +procedure FloodFill(x, y: CInteger; Border: CInteger); asmname 'floodfill'; +procedure SetFillPattern(UPattern: FillPatternType; Color: CInteger); asmname 'setfillpattern'; +procedure SetFillStyle(Pattern: CInteger; Color: CInteger); asmname 'setfillstyle'; +procedure GetImage(Left, Top, Right, Bottom: CInteger; var BitMap); asmname 'getimage'; +procedure PutImage(Left, Top: CInteger; var BitMap; Op: CInteger); asmname 'putimage'; +function ImageSize(Left, Top, Right, Bottom: CInteger): CInteger; asmname 'imagesize'; procedure GetTextSettings(var TextTypeInfo: TextSettingsType); asmname 'gettextsettings'; -procedure SetTextJustify(Horiz, Vert: Integer); asmname 'settextjustify'; -procedure SetTextStyle(Font, Direction: Integer; CharSize: Integer); asmname 'settextstyle'; -procedure SetRGBPalette(Color, Red, Green, Blue: Integer); asmname 'setrgbpalette'; -procedure SetUserCharSize(MultX, DivX, MultY, DivY: Integer); asmname 'setusercharsize'; -procedure SetWriteMode(Mode: Integer); asmname 'setwritemode'; +procedure SetTextJustify(Horiz, Vert: CInteger); asmname 'settextjustify'; +procedure SetTextStyle(Font, Direction: CInteger; CharSize: CInteger); asmname 'settextstyle'; +procedure SetRGBPalette(Color, Red, Green, Blue: CInteger); asmname 'setrgbpalette'; +procedure SetUserCharSize(MultX, DivX, MultY, DivY: CInteger); asmname 'setusercharsize'; +procedure SetWriteMode(Mode: CInteger); asmname 'setwritemode'; procedure OutText(TextString: CString); asmname 'outtext'; -procedure OutTextXY(x, y: Integer; TextString: CString); asmname 'outtextxy'; -function TextHeight(TextString: CString): Integer; asmname 'textheight'; -function TextWidth(TextString: CString): Integer; asmname 'textwidth'; +procedure OutTextXY(x, y: CInteger; TextString: CString); asmname 'outtextxy'; +function TextHeight(TextString: CString): CInteger; asmname 'textheight'; +function TextWidth(TextString: CString): CInteger; asmname 'textwidth'; -function RegisterBGIfont(Font: Pointer): Integer; asmname 'registerbgifont'; -function InstallUserFont(FontName: CString): Integer; asmname 'installuserfont'; +function RegisterBGIfont(Font: Pointer): CInteger; asmname 'registerbgifont'; +function InstallUserFont(FontName: CString): CInteger; asmname 'installuserfont'; -function GetPaletteSize: Integer; asmname 'getpalettesize'; +function GetPaletteSize: CInteger; asmname 'getpalettesize'; procedure GetPalette(var Palette: PaletteType); asmname 'getpalette'; -procedure SetPalette(ColorNum: Word; Color: Integer); asmname '__gr_setpalette'; +procedure SetPalette(ColorNum: CCardinal; Color: CInteger); asmname '__gr_setpalette'; procedure SetAllPalette(protected var Palette: PaletteType); asmname 'setallpalette'; procedure RestoreCrtMode; asmname '__gr_restorecrtmode'; procedure CloseGraph; asmname '__gr_closegraph'; -procedure SetColor(Color: Integer); asmname '__gr_setcolor'; -procedure SetBkColor(Color: Integer); asmname '__gr_setbkcolor'; -procedure Bar(Left, Top, Right, Bottom: Integer); asmname '__gr_bar'; -function GraphResult:Integer; asmname '__gr_graphresult'; -procedure Line(x1, y1, x2, y2: Integer); asmname '__gr_line'; -procedure MoveTo(x, y: Integer); asmname '__gr_moveto'; -procedure Arc(x, y: Integer; StAngle, EndAngle, Radius: Word); asmname '__gr_arc'; -procedure Circle(x, y: Integer; Radius: Word); asmname '__gr_circle'; +procedure SetColor(Color: CInteger); asmname '__gr_setcolor'; +procedure SetBkColor(Color: CInteger); asmname '__gr_setbkcolor'; +procedure Bar(Left, Top, Right, Bottom: CInteger); asmname '__gr_bar'; +function GraphResult:CInteger; asmname '__gr_graphresult'; +procedure Line(x1, y1, x2, y2: CInteger); asmname '__gr_line'; +procedure MoveTo(x, y: CInteger); asmname '__gr_moveto'; +procedure Arc(x, y: CInteger; StAngle, EndAngle, Radius: CCardinal); asmname '__gr_arc'; +procedure Circle(x, y: CInteger; Radius: CCardinal); asmname '__gr_circle'; procedure ClearDevice; asmname '__gr_cleardevice'; -procedure DrawPoly(NumPoints: Word; var PolyPoints { : array of PointType }); asmname '__gr_drawpoly'; -procedure Ellipse(x, y: Integer; StAngle, EndAngle: Word; XRadius, YRadius: Word); asmname '__gr_ellipse'; -procedure GetAspectRatio(var XAsp, YAsp: Integer); asmname '__gr_getaspectratio'; -function GetBkColor: Word; asmname '__gr_getbkcolor'; -function GetColor: Word; asmname '__gr_getcolor'; +procedure DrawPoly(NumPoints: CCardinal; var PolyPoints { : array of PointType }); asmname '__gr_drawpoly'; +procedure Ellipse(x, y: CInteger; StAngle, EndAngle: CCardinal; XRadius, YRadius: CCardinal); asmname '__gr_ellipse'; +procedure GetAspectRatio(var XAsp, YAsp: CInteger); asmname '__gr_getaspectratio'; +function GetBkColor: CCardinal; asmname '__gr_getbkcolor'; +function GetColor: CCardinal; asmname '__gr_getcolor'; procedure GetFillPattern(var FillPattern: FillPatternType); asmname '__gr_getfillpattern'; procedure GetFillSettings(var FillInfo: FillSettingsType); asmname '__gr_getfillsettings'; -function GetMaxMode: Integer; asmname '__gr_getmaxmode'; -function GetGraphMode: Integer; asmname '__gr_getgraphmode'; -function GetX: Integer; asmname '__gr_getx'; -function GetY: Integer; asmname '__gr_gety'; -function InstallUserDriver(const DriverName: String; AutoDetectPtr: Pointer):Integer; -procedure LineRel(dx, dy: Integer); asmname '__gr_linerel'; -procedure LineTo(x, y: Integer); asmname '__gr_lineto'; -procedure MoveRel(dx, dy: Integer); asmname '__gr_moverel'; -procedure PieSlice(x, y: Integer; StAngle, EndAngle, Radius: Word); asmname '__gr_pieslice'; -function RegisterBGIdriver(Driver: Pointer): Integer; -procedure Sector(x, y: Integer; StAngle,EndAngle, XRadius, YRadius: Word); asmname '__gr_sector'; -procedure SetAspectRatio(XAsp, YAsp: Integer); asmname '__gr_setaspectratio'; -procedure SetGraphBufSize(BufSize: Word); asmname '__gr_setgraphbufsize'; -procedure SetActivePage(Page: Word); asmname '__gr_setactivepage'; -procedure SetVisualPage(Page: Word); asmname '__gr_setvisualpage'; +function GetMaxMode: CInteger; asmname '__gr_getmaxmode'; +function GetGraphMode: CInteger; asmname '__gr_getgraphmode'; +function GetX: CInteger; asmname '__gr_getx'; +function GetY: CInteger; asmname '__gr_gety'; +function InstallUserDriver(const DriverName: String; AutoDetectPtr: Pointer):CInteger; +procedure LineRel(dx, dy: CInteger); asmname '__gr_linerel'; +procedure LineTo(x, y: CInteger); asmname '__gr_lineto'; +procedure MoveRel(dx, dy: CInteger); asmname '__gr_moverel'; +procedure PieSlice(x, y: CInteger; StAngle, EndAngle, Radius: CCardinal); asmname '__gr_pieslice'; +function RegisterBGIdriver(Driver: Pointer): CInteger; +procedure Sector(x, y: CInteger; StAngle,EndAngle, XRadius, YRadius: CCardinal); asmname '__gr_sector'; +procedure SetAspectRatio(XAsp, YAsp: CInteger); asmname '__gr_setaspectratio'; +procedure SetGraphBufSize(BufSize: CCardinal); asmname '__gr_setgraphbufsize'; +procedure SetActivePage(Page: CCardinal); asmname '__gr_setactivepage'; +procedure SetVisualPage(Page: CCardinal); asmname '__gr_setvisualpage'; procedure GetDefaultPalette(var Palette: PaletteType); -procedure GetModeRange(GraphDriver:Integer; var LoMode, HiMode:Integer); asmname '__gr_getmoderange'; +procedure GetModeRange(GraphDriver:CInteger; var LoMode, HiMode:CInteger); asmname '__gr_getmoderange'; -function Black : Integer; -function Blue : Integer; -function Green : Integer; -function Cyan : Integer; -function Red : Integer; -function Magenta : Integer; -function Brown : Integer; -function LightGray : Integer; -function DarkGray : Integer; -function LightBlue : Integer; -function LightGreen : Integer; -function LightCyan : Integer; -function LightRed : Integer; -function LightMagenta: Integer; -function Yellow : Integer; -function White : Integer; +function Black : CInteger; +function Blue : CInteger; +function Green : CInteger; +function Cyan : CInteger; +function Red : CInteger; +function Magenta : CInteger; +function Brown : CInteger; +function LightGray : CInteger; +function DarkGray : CInteger; +function LightBlue : CInteger; +function LightGreen : CInteger; +function LightCyan : CInteger; +function LightRed : CInteger; +function LightMagenta: CInteger; +function Yellow : CInteger; +function White : CInteger; { BGI - API extensions } @@ -427,43 +431,43 @@ { Translates BGI driver/mode into a driver/mode pair for this unit for usage with InitGraph / SetGraphMode } -procedure SetBGImode(var GDrv, GMode: Integer); asmname 'set_BGI_mode'; +procedure SetBGImode(var GDrv, GMode: CInteger); asmname 'set_BGI_mode'; { Determines a driver/mode pair for InitGraph that will set up a graphics mode with the desired resolution and colors } -procedure SetBGImodeWHC(var GDrv, GMode: Integer; Width, Height, Colors: Integer); asmname '__gr_set_BGI_mode_whc'; +procedure SetBGImodeWHC(var GDrv, GMode: CInteger; Width, Height, Colors: CInteger); asmname '__gr_set_BGI_mode_whc'; { enable multiple graphics pages by SetBGIModePages (2); InitGraph (gd, gm, ''); if (GraphResult = grOk) and (GetBGIModePages=2) then PlayWithPages; } -procedure SetBGIModePages(p: Integer); asmname '__gr_set_BGI_mode_pages'; -function GetBGIModePages: Integer; asmname '__gr_get_BGI_mode_pages'; +procedure SetBGIModePages(p: CInteger); asmname '__gr_set_BGI_mode_pages'; +function GetBGIModePages: CInteger; asmname '__gr_get_BGI_mode_pages'; { like GetMaxColor, GetMaxX, GetMaxY but for any available mode } -function GetModeMaxColor(Mode: Integer): Integer; asmname '__gr_getmodemaxcolor'; -function GetModeMaxX(Mode: Integer): Integer; asmname '__gr_getmodemaxx'; -function GetModeMaxY(Mode: Integer): Integer; asmname '__gr_getmodemaxy'; +function GetModeMaxColor(Mode: CInteger): CInteger; asmname '__gr_getmodemaxcolor'; +function GetModeMaxX(Mode: CInteger): CInteger; asmname '__gr_getmodemaxx'; +function GetModeMaxY(Mode: CInteger): CInteger; asmname '__gr_getmodemaxy'; { Set the actual drawing color to r/g/b. Functional in HiColor/TrueColor modes only } -procedure SetRGBColor(Red, Green, Blue: Word); asmname '__gr_setrgbcolor'; +procedure SetRGBColor(Red, Green, Blue: CCardinal); asmname '__gr_setrgbcolor'; { Returns the actual RGB palette. Functional in 256 color modes only. Won't work on Linux systems } -procedure GetRGBPalette(Color: Integer; var Red, Green, Blue: Integer); asmname '__getrgbpalette'; +procedure GetRGBPalette(Color: CInteger; var Red, Green, Blue: CInteger); asmname '__getrgbpalette'; { Transforms the predefined 16 EGA colors (RED, BLUE, MAGENTA, ...) into the correct color value for the active graphics mode } -function EGAColor(EGACol: Integer): Integer; asmname '_ega_color'; +function EGAColor(EGACol: CInteger): CInteger; asmname '_ega_color'; { Enable/disable linestyle drawing of vector fonts. Currently only functional with GRX v1.x } procedure TextLineStyle(On: Boolean); asmname '__gr_textlinestyle'; { Counterparts of SetActivePage/SetVisualPage } -function GetActivePage: Integer; asmname '__gr_getactivepage'; -function GetVisualPage: Integer; asmname '__gr_getvisualpage'; +function GetActivePage: CInteger; asmname '__gr_getactivepage'; +function GetVisualPage: CInteger; asmname '__gr_getvisualpage'; {$ifndef NO_GRAPH_KEY_FUNCTIONS} function KeyPressed: Boolean; asmname 'kbhit'; @@ -472,32 +476,43 @@ implementation -function gem(ec: Integer): CString; asmname 'grapherrormsg'; -function GraphErrorMsg(ErrorCode: Integer): WrkString; +procedure ig(var gd, gm: CInteger; PathToDriver: CString); asmname 'initgraph'; +procedure InitGraph(var GraphDriver, GraphMode: Integer; PathToDriver: CString); +var gd, gm: CInteger; +begin + gd := GraphDriver; + gm := GraphMode; + ig (gd, gm, PathToDriver); + GraphDriver := gd; + GraphMode := gm +end; + +function gem(ec: CInteger): CString; asmname 'grapherrormsg'; +function GraphErrorMsg(ErrorCode: CInteger): WrkString; begin - GraphErrorMsg := CString2String(gem(ErrorCode)); + GraphErrorMsg := CString2String (gem (ErrorCode)) end; -function gmn(mn: Integer): CString; asmname 'getmodename'; -function GetModeName(ModeNumber: Integer): WrkString; +function gmn(mn: CInteger): CString; asmname 'getmodename'; +function GetModeName(ModeNumber: CInteger): WrkString; begin - GetModeName := CString2String(gmn(ModeNumber)); + GetModeName := CString2String (gmn (ModeNumber)) end; function gdn: CString; asmname 'getdrivername'; function GetDriverName: WrkString; begin - GetDriverName := CString2String(gdn); + GetDriverName := CString2String (gdn) end; type pPT = ^PaletteType; function gdp: pPT; asmname '__gr_getdefaultpalette'; procedure GetDefaultPalette(var Palette: PaletteType); begin - Palette := gdp^; + Palette := gdp^ end; -function InstallUserDriver(const DriverName: String; AutoDetectPtr: Pointer):Integer; +function InstallUserDriver(const DriverName: String; AutoDetectPtr: Pointer):CInteger; var Dummy1: Integer; Dummy2: Pointer; @@ -507,89 +522,89 @@ InstallUserDriver := GrError end; -function RegisterBGIdriver(Driver: Pointer): Integer; +function RegisterBGIdriver(Driver: Pointer): CInteger; var Dummy: Pointer; begin Dummy := Driver; RegisterBGIdriver := GrError end; -function Black: Integer; +function Black: CInteger; begin Black := EGAColor (0) end; -function Blue: Integer; +function Blue: CInteger; begin Blue := EGAColor (1) end; -function Green: Integer; +function Green: CInteger; begin Green := EGAColor (2) end; -function Cyan: Integer; +function Cyan: CInteger; begin Cyan := EGAColor (3) end; -function Red: Integer; +function Red: CInteger; begin Red := EGAColor (4) end; -function Magenta: Integer; +function Magenta: CInteger; begin Magenta := EGAColor (5) end; -function Brown: Integer; +function Brown: CInteger; begin Brown := EGAColor (6) end; -function LightGray: Integer; +function LightGray: CInteger; begin LightGray := EGAColor (7) end; -function DarkGray: Integer; +function DarkGray: CInteger; begin DarkGray := EGAColor (8) end; -function LightBlue: Integer; +function LightBlue: CInteger; begin LightBlue := EGAColor (9) end; -function LightGreen: Integer; +function LightGreen: CInteger; begin LightGreen := EGAColor (10) end; -function LightCyan: Integer; +function LightCyan: CInteger; begin LightCyan := EGAColor (11) end; -function LightRed: Integer; +function LightRed: CInteger; begin LightRed := EGAColor (12) end; -function LightMagenta: Integer; +function LightMagenta: CInteger; begin LightMagenta := EGAColor (13) end; -function Yellow: Integer; +function Yellow: CInteger; begin Yellow := EGAColor (14) end; -function White: Integer; +function White: CInteger; begin White := EGAColor (15) end; --- grx246/pascal/grx.pas.orig Sun Mar 28 23:15:23 2004 +++ grx246/pascal/grx.pas Fri Sep 17 19:17:49 2004 @@ -52,6 +52,11 @@ {$else} {$define varasmname external; asmname} {$endif} +{$if __GPC_RELEASE__ < 20040917} +type + CInteger = Integer; + CCardinal = Cardinal; +{$endif} const MaxVarSize = MaxInt div 8; @@ -70,7 +75,7 @@ { This definition is compatible with the grx definition 'int pts[][2]' used to define polygons } PointType = record - x, y: Integer; + x, y: CInteger end; const @@ -94,9 +99,9 @@ Gr_Width_Height_Graphics = 6; { Integer w,Integer h } Gr_Biggest_Noninterlaced_Graphics = 7; Gr_Biggest_Graphics = 8; - Gr_Width_Height_Color_Graphics = 9; { Integer w,Integer h,Word nc } - Gr_Width_Height_Color_Text = 10; { Integer w,Integer h,Word nc } - Gr_Custom_Graphics = 11; { Integer w,Integer h,Word nc,Integer vx,Integer vy } + Gr_Width_Height_Color_Graphics = 9; { Integer w,Integer h,Cardinal nc } + Gr_Width_Height_Color_Text = 10; { Integer w,Integer h,Cardinal nc } + Gr_Custom_Graphics = 11; { Integer w,Integer h,Cardinal nc,Integer vx,Integer vy } { ==== equivalent modes which do not clear the video memory ==== } Gr_NC_80_25_Text = 12; Gr_NC_Default_Text = 13; @@ -107,17 +112,17 @@ Gr_NC_Width_Height_Graphics = 18; { Integer w,Integer h } Gr_NC_Biggest_Noninterlaced_Graphics = 19; Gr_NC_Biggest_Graphics = 20; - Gr_NC_Width_Height_Color_Graphics = 21; { Integer w,Integer h,Word nc } - Gr_NC_Width_Height_Color_Text = 22; { Integer w,Integer h,Word nc } - Gr_NC_Custom_Graphics = 23; { Integer w,Integer h,Word nc,Integer vx,Integer vy } + Gr_NC_Width_Height_Color_Graphics = 21; { Integer w,Integer h,Cardinal nc } + Gr_NC_Width_Height_Color_Text = 22; { Integer w,Integer h,Cardinal nc } + Gr_NC_Custom_Graphics = 23; { Integer w,Integer h,Cardinal nc,Integer vx,Integer vy } { ==== plane instead of color based modes ==== } { colors = 1 << bpp >>> resort enum for GRX3 <<< } - Gr_Width_Height_BPP_Graphics = 24; { int w,int h,int bpp } - Gr_Width_Height_BPP_Text = 25; { int w,int h,int bpp } - Gr_Custom_BPP_Graphics = 26; { int w,int h,int bpp,int vx,int vy } - Gr_NC_Width_Height_BPP_Graphics = 27; { int w,int h,int bpp } - Gr_NC_Width_Height_BPP_Text = 28; { int w,int h,int bpp } - Gr_NC_Custom_BPP_Graphics = 29; { int w,int h,int bpp,int vx,int vy } + Gr_Width_Height_BPP_Graphics = 24; { Integer w,Integer h,Integer bpp } + Gr_Width_Height_BPP_Text = 25; { Integer w,Integer h,Integer bpp } + Gr_Custom_BPP_Graphics = 26; { Integer w,Integer h,Integer bpp,Integer vx,Integer vy } + Gr_NC_Width_Height_BPP_Graphics = 27; { Integer w,Integer h,Integer bpp } + Gr_NC_Width_Height_BPP_Text = 28; { Integer w,Integer h,Integer bpp } + Gr_NC_Custom_BPP_Graphics = 29; { Integer w,Integer h,Integer bpp,Integer vx,Integer vy } { Available frame modes (video memory layouts) } @@ -195,27 +200,27 @@ GrVideoDriverPtr = ^GrVideoDriver; GrVideoDriver = record Name : CString; { driver name } - Adapter : Integer; { adapter type } + Adapter : CInteger; { adapter type } Inherit : GrVideoDriverPtr; { inherit video modes from this } Modes : GrVideoModePtr; { table of supported modes } - NModes : Integer; { number of modes } - Detect : function: Integer; - Init : function (Options: CString): Integer; + NModes : CInteger; { number of modes } + Detect : function: CInteger; + Init : function (Options: CString): CInteger; Reset : procedure; - SelectMode: function (Drv: GrVideoDriverPtr; w, h, BPP, txt: Integer; var ep: Cardinal): GrVideoModePtr; - DrvFlags : Cardinal; + SelectMode: function (Drv: GrVideoDriverPtr; w, h, BPP, txt: CInteger; var ep: CCardinal): GrVideoModePtr; + DrvFlags : CCardinal end; { Video driver mode descriptor structure } { struct _GR_videoMode } GrVideoMode = record - Present : ByteBool; { is it really available? } - BPP : Byte; { log2 of # of colors } - Width,Height: ShortInt; { video mode geometry } - Mode : ShortInt; { BIOS mode number (if any) } - LineOffset : Integer; { scan line length } - PrivData : Integer; { driver can use it for anything } - ExtInfo : ^GrVideoModeExt; { extra info (maybe shared) } + Present: ByteBool; { is it really available? } + BPP: Byte; { log2 of # of colors } + Width, Height, { video mode geometry } + Mode: ShortInt; { BIOS mode number (if any) } + LineOffset, { scan line length } + PrivData: CInteger; { driver can use it for anything } + ExtInfo: ^GrVideoModeExt { extra info (maybe shared) } end; { Video driver mode descriptor extension structure. This is a separate @@ -224,21 +229,21 @@ extended info. } { struct _GR_videoModeExt } - Int2 = array [0 .. 1] of Integer; + Int2 = array [0 .. 1] of CInteger; GrVideoModeExt = record - Mode : Integer; { frame driver for this video mode } + Mode : CInteger; { frame driver for this video mode } Drv : ^GrFrameDriver; { optional frame driver override } Frame : MemPtr; { frame buffer address } CPrec : array [1 .. 3] of ByteCard; { color component precisions } CPos : array [1 .. 3] of ByteCard; { color component bit positions } - Flags : Integer; { mode flag bits; see "grdriver.h" } - Setup : function (var md: GrVideoMode; NoClear: Integer): Integer; - SetVSize : function (var md: GrVideoMode; w, h: Integer; var Result: GrVideoMode): Integer; - Scroll : function (var md: GrVideoMode; x, y: Integer; var Result: Int2): Integer; - SetBank : procedure (bk: Integer); - SetRWBanks : procedure (rb, wb: Integer); - LoadColor : procedure (c, r, g, b: Integer); - LFB_Selector: Integer; + Flags : CInteger; { mode flag bits; see "grdriver.h" } + Setup : function (var md: GrVideoMode; NoClear: CInteger): CInteger; + SetVSize : function (var md: GrVideoMode; w, h: CInteger; var Result: GrVideoMode): CInteger; + Scroll : function (var md: GrVideoMode; x, y: CInteger; var Result: Int2): CInteger; + SetBank : procedure (bk: CInteger); + SetRWBanks : procedure (rb, wb: CInteger); + LoadColor : procedure (c, r, g, b: CInteger); + LFB_Selector: CInteger end; GrFrameDriverPtr = ^GrFrameDriver; @@ -248,59 +253,59 @@ gf_Selector : ShortInt; { frame memory segment selector } gf_OnScreen : ByteBool; { is it in video memory ? } gf_MemFlags : Byte; { memory allocation flags } - gf_LineOffset: Integer; { offset to next scan line in bytes } - gf_Driver : GrFrameDriverPtr; { frame access functions } + gf_LineOffset: CInteger; { offset to next scan line in bytes } + gf_Driver : GrFrameDriverPtr { frame access functions } end; { The frame driver descriptor structure. } { struct _GR_frameDriver } GrFrameDriver = record - Mode : Integer; { supported frame access mode } - RMode : Integer; { matching RAM frame (if video) } - Is_Video : Integer; { video RAM frame driver ? } - Row_Align : Integer; { scan line size alignment } - Num_Planes : Integer; { number of planes } - Bits_Per_Pixel : Integer; { bits per pixel } - Max_Plane_Size : MedInt; { maximum plane size in bytes } - Init : function (var md: GrVideoMode): Integer; - ReadPixel : function (var c: GrFrameType; x, y: Integer): GrColor; - DrawPixel : procedure (x, y: Integer; c: GrColor); - DrawLine : procedure (x, y, dx, dy: Integer; c: GrColor); - DrawHLine : procedure (x, y, w: Integer; c: GrColor); - DrawVLine : procedure (x, y, h: Integer; c: GrColor); - DrawBlock : procedure (x, y, w, h: Integer; c: GrColor); - DrawBitmap : procedure (x, y, w, h: Integer; BMP: MemPtr; Pitch, Start: Integer; fg, bg: GrColor); - DrawPattern : procedure (x, y, w: Integer; Patt: Byte; fg, bg: GrColor); - BitBlt : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); - BltV2R : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); - BltR2V : procedure (var Dst: GrFrameType; dx, dy: Integer; var Src: GrFrameType; x, y, w, h: Integer; Op: GrColor); - GetIndexedScanline: function (var c: GrFrameType; x, y, w: Integer; var Index: Integer): GrColorsPtr; - PutScanLine : procedure (x, y, w: Integer; scl: GrColorsPtr; Op: GrColor); + Mode, { supported frame access mode } + RMode, { matching RAM frame (if video) } + Is_Video, { video RAM frame driver ? } + Row_Align, { scan line size alignment } + Num_Planes, { number of planes } + Bits_Per_Pixel : CInteger; { bits per pixel } + Max_Plane_Size : MedInt; { maximum plane size in bytes } + Init : function (var md: GrVideoMode): CInteger; + ReadPixel : function (var c: GrFrameType; x, y: CInteger): GrColor; + DrawPixel : procedure (x, y: CInteger; c: GrColor); + DrawLine : procedure (x, y, dx, dy: CInteger; c: GrColor); + DrawHLine : procedure (x, y, w: CInteger; c: GrColor); + DrawVLine : procedure (x, y, h: CInteger; c: GrColor); + DrawBlock : procedure (x, y, w, h: CInteger; c: GrColor); + DrawBitmap : procedure (x, y, w, h: CInteger; BMP: MemPtr; Pitch, Start: CInteger; fg, bg: GrColor); + DrawPattern : procedure (x, y, w: CInteger; Patt: Byte; fg, bg: GrColor); + BitBlt : procedure (var Dst: GrFrameType; dx, dy: CInteger; var Src: GrFrameType; x, y, w, h: CInteger; Op: GrColor); + BltV2R : procedure (var Dst: GrFrameType; dx, dy: CInteger; var Src: GrFrameType; x, y, w, h: CInteger; Op: GrColor); + BltR2V : procedure (var Dst: GrFrameType; dx, dy: CInteger; var Src: GrFrameType; x, y, w, h: CInteger; Op: GrColor); + GetIndexedScanline: function (var c: GrFrameType; x, y, w: CInteger; var Index: CInteger): GrColorsPtr; + PutScanLine : procedure (x, y, w: CInteger; scl: GrColorsPtr; Op: GrColor); end; { driver and mode info structure } { extern const struct _GR_driverInfo } GrDriverInfoType = record - VDriver : GrVideoDriverPtr; { the current video driver } - CurMode : GrVideoModePtr; { current video mode pointer } - ActMode : GrVideoMode; { copy of above, resized if virtual } - FDriver : GrFrameDriver; { frame driver for the current context } - SDriver : GrFrameDriver; { frame driver for the screen } - TDriver : GrFrameDriver; { a dummy driver for text modes } - MCode : Integer; { code for the current mode } - DefTW,DefTH: Integer; { default text mode size } - DefGW,DefGH: Integer; { default graphics mode size } - DefTC,DefGC: GrColor; { default text and graphics colors } - VPosX,VPosY: Integer; { current virtual viewport position } - ErrsFatal : Integer; { if set, exit upon errors } - ModeRestore: Integer; { restore startup video mode if set } - SplitBanks : Integer; { indicates separate R/W banks } - CurBank : Integer; { currently mapped bank } - MdSetHook : procedure; { callback for mode set } - SetBank : procedure (bk: Integer); { banking routine } - SetRWBanks : procedure (rb, wb: Integer); { split banking routine } + VDriver : GrVideoDriverPtr; { the current video driver } + CurMode : GrVideoModePtr; { current video mode pointer } + ActMode : GrVideoMode; { copy of above, resized if virtual } + FDriver, { frame driver for the current context } + SDriver, { frame driver for the screen } + TDriver : GrFrameDriver; { a dummy driver for text modes } + MCode, { code for the current mode } + DefTW,DefTH, { default text mode size } + DefGW,DefGH: CInteger; { default graphics mode size } + DefTC,DefGC: GrColor; { default text and graphics colors } + VPosX,VPosY, { current virtual viewport position } + ErrsFatal, { if set, exit upon errors } + ModeRestore, { restore startup video mode if set } + SplitBanks, { indicates separate R/W banks } + CurBank : CInteger; { currently mapped bank } + MdSetHook : procedure; { callback for mode set } + SetBank : procedure (bk: CInteger); { banking routine } + SetRWBanks : procedure (rb, wb: CInteger); { split banking routine } end; var @@ -308,26 +313,26 @@ { setup stuff } -function GrSetDriver(DrvSpec: CString):Integer; asmname 'GrSetDriver'; -function GrSetMode(m, w, h, nc, vx, vy:Integer):Integer; asmname 'GrSetMode'; -function GrSetViewport(XPos, YPos: Integer):Integer; asmname 'GrSetViewport'; +function GrSetDriver(DrvSpec: CString):CInteger; asmname 'GrSetDriver'; +function GrSetMode(m, w, h, nc, vx, vy:CInteger):CInteger; asmname 'GrSetMode'; +function GrSetViewport(XPos, YPos: CInteger):CInteger; asmname 'GrSetViewport'; procedure GrSetModeHook(HookFunc:Pointer); asmname 'GrSetModeHook'; procedure GrSetModeRestore(RestoreFlag:Boolean); asmname 'GrSetModeRestore'; procedure GrSetErrorHandling(ExitIfError:Boolean); asmname 'GrSetErrorHandling'; -procedure GrSetEGAVGAmonoDrawnPlane(Plane:Integer); asmname 'GrSetEGAVGAmonoDrawnPlane'; -procedure GrSetEGAVGAmonoShownPlane(Plane:Integer); asmname 'GrSetEGAVGAmonoShownPlane'; +procedure GrSetEGAVGAmonoDrawnPlane(Plane:CInteger); asmname 'GrSetEGAVGAmonoDrawnPlane'; +procedure GrSetEGAVGAmonoShownPlane(Plane:CInteger); asmname 'GrSetEGAVGAmonoShownPlane'; -function GrGetLibraryVersion: Integer; asmname 'GrGetLibraryVersion'; -function GrGetLibrarySystem: Integer; asmname 'GrGetLibrarySystem'; +function GrGetLibraryVersion: CInteger; asmname 'GrGetLibraryVersion'; +function GrGetLibrarySystem: CInteger; asmname 'GrGetLibrarySystem'; { inquiry stuff ---- many of these can be macros } -function GrCurrentMode:Integer; asmname 'GrCurrentMode'; -function GrAdapterType:Integer; asmname 'GrAdapterType'; -function GrCurrentFrameMode:Integer; asmname 'GrCurrentFrameMode'; -function GrScreenFrameMode:Integer; asmname 'GrScreenFrameMode'; -function GrCoreFrameMode:Integer; asmname 'GrCoreFrameMode'; +function GrCurrentMode:CInteger; asmname 'GrCurrentMode'; +function GrAdapterType:CInteger; asmname 'GrAdapterType'; +function GrCurrentFrameMode:CInteger; asmname 'GrCurrentFrameMode'; +function GrScreenFrameMode:CInteger; asmname 'GrScreenFrameMode'; +function GrCoreFrameMode:CInteger; asmname 'GrCoreFrameMode'; function GrCurrentVideoDriver: GrVideoDriverPtr; asmname 'GrCurrentVideoDriver' ; function GrCurrentVideoMode:GrVideoModePtr; asmname 'GrCurrentVideoMode'; @@ -335,28 +340,28 @@ function GrCurrentFrameDriver: GrFrameDriverPtr; asmname 'GrCurrentFrameDriver'; function GrScreenFrameDriver: GrFrameDriverPtr; asmname 'GrScreenFrameDriver'; -function GrFirstVideoMode(FMode:Integer):GrVideoModePtr; asmname 'GrFirstVideoMode'; +function GrFirstVideoMode(FMode:CInteger):GrVideoModePtr; asmname 'GrFirstVideoMode'; function GrNextVideoMode(Prev:GrVideoModePtr):GrVideoModePtr; asmname 'GrNextVideoMode'; -function GrScreenX:Integer; asmname 'GrScreenX'; -function GrScreenY:Integer; asmname 'GrScreenY'; -function GrVirtualX:Integer; asmname 'GrVirtualX'; -function GrVirtualY:Integer; asmname 'GrVirtualY'; -function GrViewportX:Integer; asmname 'GrViewportX'; -function GrViewportY:Integer; asmname 'GrViewportY'; +function GrScreenX:CInteger; asmname 'GrScreenX'; +function GrScreenY:CInteger; asmname 'GrScreenY'; +function GrVirtualX:CInteger; asmname 'GrVirtualX'; +function GrVirtualY:CInteger; asmname 'GrVirtualY'; +function GrViewportX:CInteger; asmname 'GrViewportX'; +function GrViewportY:CInteger; asmname 'GrViewportY'; function GrScreenIsVirtual:Boolean; asmname 'GrScreenIsVirtual'; { RAM context geometry and memory allocation inquiry stuff } -function GrFrameNumPlanes(md:Integer):Integer; asmname 'GrFrameNumPlanes'; -function GrFrameLineOffset(md,Width:Integer):Integer; asmname 'GrFrameLineOffset'; -function GrFramePlaneSize(md,w,h:Integer):Integer; asmname 'GrFramePlaneSize'; -function GrFrameContextSize(md,w,h:Integer):Integer; asmname 'GrFrameContextSize'; - -function GrNumPlanes:Integer; asmname 'GrNumPlanes'; -function GrLineOffset(Width:Integer):Integer; asmname 'GrLineOffset'; -function GrPlaneSize(w,h:Integer):Integer; asmname 'GrPlaneSize'; -function GrContextSize(w,h:Integer):Integer; asmname 'GrContextSize'; +function GrFrameNumPlanes(md:CInteger):CInteger; asmname 'GrFrameNumPlanes'; +function GrFrameLineOffset(md,Width:CInteger):CInteger; asmname 'GrFrameLineOffset'; +function GrFramePlaneSize(md,w,h:CInteger):CInteger; asmname 'GrFramePlaneSize'; +function GrFrameContextSize(md,w,h:CInteger):CInteger; asmname 'GrFrameContextSize'; + +function GrNumPlanes:CInteger; asmname 'GrNumPlanes'; +function GrLineOffset(Width:CInteger):CInteger; asmname 'GrLineOffset'; +function GrPlaneSize(w,h:CInteger):CInteger; asmname 'GrPlaneSize'; +function GrContextSize(w,h:CInteger):CInteger; asmname 'GrContextSize'; { ================================================================== FRAME BUFFER, CONTEXT AND CLIPPING STUFF @@ -366,54 +371,54 @@ { struct _GR_context } GrContextPtr = ^GrContext; GrContext = record - gc_Frame : GrFrameType; { frame buffer info } - gc_Root : GrContextPtr; { context which owns frame } - gc_XMax : Integer; { max X coord (width - 1) } - gc_YMax : Integer; { max Y coord (height - 1) } - gc_XOffset : Integer; { X offset from root's base } - gc_YOffset : Integer; { Y offset from root's base } - gc_XClipLo : Integer; { low X clipping limit } - gc_YClipLo : Integer; { low Y clipping limit } - gc_XClipHi : Integer; { high X clipping limit } - gc_YClipHi : Integer; { high Y clipping limit } - gc_UsrXBase : Integer; { user window min X coordinate } - gc_UsrYBase : Integer; { user window min Y coordinate } - gc_UsrWidth : Integer; { user window width } - gc_UsrHeight: Integer; { user window height } + gc_Frame: GrFrameType; { frame buffer info } + gc_Root: GrContextPtr; { context which owns frame } + gc_XMax, { max X coord (width - 1) } + gc_YMax, { max Y coord (height - 1) } + gc_XOffset, { X offset from root's base } + gc_YOffset, { Y offset from root's base } + gc_XClipLo, { low X clipping limit } + gc_YClipLo, { low Y clipping limit } + gc_XClipHi, { high X clipping limit } + gc_YClipHi, { high Y clipping limit } + gc_UsrXBase, { user window min X coordinate } + gc_UsrYBase, { user window min Y coordinate } + gc_UsrWidth, { user window width } + gc_UsrHeight: CInteger { user window height } end; { extern const struct _GR_contextInfo } GrContextInfoType = record - Current: GrContext; { the current context } - Screen : GrContext; { the screen context } + Current, { the current context } + Screen: GrContext { the screen context } end; var GrContextInfo: GrContextInfoType; varasmname 'GrContextInfo'; -function GrCreateContext(w, h: Integer; Memory: MemPtr; Where: GrContextPtr): GrContextPtr; asmname 'GrCreateContext'; -function GrCreateFrameContext(md: ByteCard; w, h: Integer; Memory: MemPtr; Where: GrContextPtr): GrContextPtr; asmname 'GrCreateFrameContext'; -function GrCreateSubContext(x1, y1, x2, y2: Integer; Parent, Where: GrContextPtr): GrContextPtr; asmname 'GrCreateSubContext'; +function GrCreateContext(w, h: CInteger; Memory: MemPtr; Where: GrContextPtr): GrContextPtr; asmname 'GrCreateContext'; +function GrCreateFrameContext(md: ByteCard; w, h: CInteger; Memory: MemPtr; Where: GrContextPtr): GrContextPtr; asmname 'GrCreateFrameContext'; +function GrCreateSubContext(x1, y1, x2, y2: CInteger; Parent, Where: GrContextPtr): GrContextPtr; asmname 'GrCreateSubContext'; function GrSaveContext(Where: GrContextPtr): GrContextPtr; asmname 'GrSaveContext'; function GrCurrentContext: GrContextPtr; asmname 'GrCurrentContext'; function GrScreenContext: GrContextPtr; asmname 'GrScreenContext'; procedure GrDestroyContext(Context: GrContextPtr); asmname 'GrDestroyContext'; -procedure GrResizeSubContext(Context: GrContextPtr; x1, y1, x2, y2: Integer); asmname 'GrResizeSubContext'; +procedure GrResizeSubContext(Context: GrContextPtr; x1, y1, x2, y2: CInteger); asmname 'GrResizeSubContext'; procedure GrSetContext(Context: GrContextPtr); asmname 'GrSetContext'; -procedure GrSetClipBox(x1, y1, x2, y2:Integer); asmname 'GrSetClipBox'; -procedure GrGetClipBox(var x1p, y1p, x2p, y2p: Integer); asmname 'GrGetClipBox'; +procedure GrSetClipBox(x1, y1, x2, y2:CInteger); asmname 'GrSetClipBox'; +procedure GrGetClipBox(var x1p, y1p, x2p, y2p: CInteger); asmname 'GrGetClipBox'; procedure GrResetClipBox; asmname 'GrResetClipBox'; -function GrMaxX: Integer; asmname 'GrMaxX'; -function GrMaxY: Integer; asmname 'GrMaxY'; -function GrSizeX:Integer; asmname 'GrSizeX'; -function GrSizeY:Integer; asmname 'GrSizeY'; -function GrLowX: Integer; asmname 'GrLowX'; -function GrLowY: Integer; asmname 'GrLowY'; -function GrHighX:Integer; asmname 'GrHighX'; -function GrHighY:Integer; asmname 'GrHighY'; +function GrMaxX: CInteger; asmname 'GrMaxX'; +function GrMaxY: CInteger; asmname 'GrMaxY'; +function GrSizeX:CInteger; asmname 'GrSizeX'; +function GrSizeY:CInteger; asmname 'GrSizeY'; +function GrLowX: CInteger; asmname 'GrLowX'; +function GrLowY: CInteger; asmname 'GrLowY'; +function GrHighX:CInteger; asmname 'GrHighX'; +function GrHighY:CInteger; asmname 'GrHighY'; { ================================================================== COLOR STUFF @@ -449,71 +454,71 @@ function GrBlack:GrColor; asmname 'GrBlack'; function GrWhite:GrColor; asmname 'GrWhite'; -function GrBuildRGBcolorT(r,g,b:Integer):GrColor; asmname 'GrBuildRGBcolorT'; -function GrBuildRGBcolorR(r,g,b:Integer):GrColor; asmname 'GrBuildRGBcolorR'; -function GrRGBcolorRed(c:GrColor):Integer ; asmname 'GrRGBcolorRed'; -function GrRGBcolorGreen(c:GrColor):Integer ; asmname 'GrRGBcolorGreen'; -function GrRGBcolorBlue(c:GrColor):Integer ; asmname 'GrRGBcolorBlue'; +function GrBuildRGBcolorT(r,g,b:CInteger):GrColor; asmname 'GrBuildRGBcolorT'; +function GrBuildRGBcolorR(r,g,b:CInteger):GrColor; asmname 'GrBuildRGBcolorR'; +function GrRGBcolorRed(c:GrColor):CInteger ; asmname 'GrRGBcolorRed'; +function GrRGBcolorGreen(c:GrColor):CInteger ; asmname 'GrRGBcolorGreen'; +function GrRGBcolorBlue(c:GrColor):CInteger ; asmname 'GrRGBcolorBlue'; -function GrAllocColor(r,g,b:Integer):GrColor; asmname 'GrAllocColor'; { shared, read-only } -function GrAllocColorID(r,g,b:Integer):GrColor; asmname 'GrAllocColorID'; { potentially inlined version } +function GrAllocColor(r,g,b:CInteger):GrColor; asmname 'GrAllocColor'; { shared, read-only } +function GrAllocColorID(r,g,b:CInteger):GrColor; asmname 'GrAllocColorID'; { potentially inlined version } function GrAllocCell:GrColor; asmname 'GrAllocCell'; { unshared, read-write } function GrAllocEgaColors:GrColorsPtr; asmname 'GrAllocEgaColors'; { shared, read-only standard EGA colors } -procedure GrSetColor(c:GrColor; r,g,b:Integer); asmname 'GrSetColor'; +procedure GrSetColor(c:GrColor; r,g,b:CInteger); asmname 'GrSetColor'; procedure GrFreeColor(c:GrColor); asmname 'GrFreeColor'; procedure GrFreeCell(c:GrColor); asmname 'GrFreeCell'; -procedure GrQueryColor(c:GrColor; var r,g,b:Integer); asmname 'GrQueryColor'; -procedure GrQueryColorID(c:GrColor; var r,g,b:Integer); asmname 'GrQueryColorID'; +procedure GrQueryColor(c:GrColor; var r,g,b:CInteger); asmname 'GrQueryColor'; +procedure GrQueryColorID(c:GrColor; var r,g,b:CInteger); asmname 'GrQueryColorID'; -function GrColorSaveBufferSize:Integer ; asmname 'GrColorSaveBufferSize'; +function GrColorSaveBufferSize:CInteger ; asmname 'GrColorSaveBufferSize'; procedure GrSaveColors(Buffer:Pointer); asmname 'GrSaveColors'; procedure GrRestoreColors(Buffer:Pointer); asmname 'GrRestoreColors'; type - { typedef struct } { framed box colors } + { framed box colors } GrFBoxColors = record - fbx_IntColor : GrColor; - fbx_TopColor : GrColor; - fbx_RightColor : GrColor; - fbx_BottomColor: GrColor; - fbx_LeftColor : GrColor; + fbx_IntColor, + fbx_TopColor, + fbx_RightColor, + fbx_BottomColor, + fbx_LeftColor: GrColor end; procedure GrClearScreen(bg:GrColor); asmname 'GrClearScreen'; procedure GrClearClipBox(bg:GrColor); asmname 'GrClearClipBox'; -procedure GrPlot(x, y: Integer; c:GrColor); asmname 'GrPlot'; -procedure GrLine(x1, y1, x2, y2: Integer; c:GrColor); asmname 'GrLine'; -procedure GrHLine(x1, x2, y:Integer; c:GrColor); asmname 'GrHLine'; -procedure GrVLine(x, y1, y2: Integer; c: GrColor); asmname 'GrVLine'; -procedure GrBox(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrBox'; -procedure GrFilledBox(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrFilledBox'; -procedure GrFramedBox(x1, y1, x2, y2, Wdt: Integer; protected var c: GrFBoxColors); asmname 'GrFramedBox'; -function GrGenerateEllipse(xc, yc, xa, ya:Integer; var Points{ : array of PointType }):Integer; asmname 'GrGenerateEllipse'; -function GrGenerateEllipseArc(xc, yc, xa, ya, Start, Ende: Integer; var Points{ : array of PointType }):Integer; asmname 'GrGenerateEllipseArc'; -procedure GrLastArcCoords(var xs, ys, xe, ye, xc, yc: Integer); asmname 'GrLastArcCoords'; -procedure GrCircle(xc, yc, r: Integer; c: GrColor); asmname 'GrCircle'; -procedure GrEllipse(xc, yc, xa, ya: Integer; c: GrColor); asmname 'GrEllipse'; -procedure GrCircleArc(xc, yc, r, Start, Ende, Style: Integer; c: GrColor); asmname 'GrCircleArc'; -procedure GrEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; c: GrColor); asmname 'GrEllipseArc'; -procedure GrFilledCircle(xc, yc, r: Integer; c: GrColor); asmname 'GrFilledCircle'; -procedure GrFilledEllipse(xc, yc, xa, ya: Integer; c: GrColor); asmname 'GrFilledEllipse'; -procedure GrFilledCircleArc(xc, yc, r, Start, Ende, Style: Integer; c: GrColor); asmname 'GrFilledCircleArc'; -procedure GrFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; c: GrColor); asmname 'GrFilledEllipseArc'; -procedure GrPolyLine(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrPolyLine'; -procedure GrPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrPolygon'; -procedure GrFilledConvexPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledConvexPolygon'; -procedure GrFilledPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledPolygon'; -procedure GrBitBlt(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; Op: GrColor); asmname 'GrBitBlt'; -function GrPixel(x, y:Integer):GrColor; asmname 'GrPixel'; -function GrPixelC(c: GrContextPtr; x, y: Integer): GrColor; asmname 'GrPixelC'; +procedure GrPlot(x, y: CInteger; c:GrColor); asmname 'GrPlot'; +procedure GrLine(x1, y1, x2, y2: CInteger; c:GrColor); asmname 'GrLine'; +procedure GrHLine(x1, x2, y:CInteger; c:GrColor); asmname 'GrHLine'; +procedure GrVLine(x, y1, y2: CInteger; c: GrColor); asmname 'GrVLine'; +procedure GrBox(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrBox'; +procedure GrFilledBox(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrFilledBox'; +procedure GrFramedBox(x1, y1, x2, y2, Wdt: CInteger; protected var c: GrFBoxColors); asmname 'GrFramedBox'; +function GrGenerateEllipse(xc, yc, xa, ya:CInteger; var Points{ : array of PointType }):CInteger; asmname 'GrGenerateEllipse'; +function GrGenerateEllipseArc(xc, yc, xa, ya, Start, Ende: CInteger; var Points{ : array of PointType }):CInteger; asmname 'GrGenerateEllipseArc'; +procedure GrLastArcCoords(var xs, ys, xe, ye, xc, yc: CInteger); asmname 'GrLastArcCoords'; +procedure GrCircle(xc, yc, r: CInteger; c: GrColor); asmname 'GrCircle'; +procedure GrEllipse(xc, yc, xa, ya: CInteger; c: GrColor); asmname 'GrEllipse'; +procedure GrCircleArc(xc, yc, r, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrCircleArc'; +procedure GrEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrEllipseArc'; +procedure GrFilledCircle(xc, yc, r: CInteger; c: GrColor); asmname 'GrFilledCircle'; +procedure GrFilledEllipse(xc, yc, xa, ya: CInteger; c: GrColor); asmname 'GrFilledEllipse'; +procedure GrFilledCircleArc(xc, yc, r, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrFilledCircleArc'; +procedure GrFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrFilledEllipseArc'; +procedure GrPolyLine(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrPolyLine'; +procedure GrPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrPolygon'; +procedure GrFilledConvexPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledConvexPolygon'; +procedure GrFilledPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrFilledPolygon'; +procedure GrBitBlt(Dest: GrContextPtr; x, y: CInteger; Src: GrContextPtr; x1, y1, x2, y2: CInteger; Op: GrColor); asmname 'GrBitBlt'; +function GrPixel(x, y:CInteger):GrColor; asmname 'GrPixel'; +function GrPixelC(c: GrContextPtr; x, y: CInteger): GrColor; asmname 'GrPixelC'; -procedure GrFloodFill(x, y: Integer; Border, c: GrColor); asmname 'GrFloodFill'; +procedure GrFloodFill(x, y: CInteger; Border, c: GrColor); asmname 'GrFloodFill'; -function GrGetScanline(x1,x2,yy: Integer): GrColorsPtr; asmname 'GrGetScanline'; -function GrGetScanlineC(ctx: GrContextPtr; x1,x2,yy: Integer): GrColorsPtr; asmname 'GrGetScanlineC'; +function GrGetScanline(x1,x2,yy: CInteger): GrColorsPtr; asmname 'GrGetScanline'; +function GrGetScanlineC(ctx: GrContextPtr; x1,x2,yy: CInteger): GrColorsPtr; asmname 'GrGetScanlineC'; { Input ctx: source context, if NULL the current context is used } { x1 : first x coordinate read } { x2 : last x coordinate read } @@ -524,7 +529,7 @@ { (w = |x2-y1|) } { Output data is valid until next GRX call ! } -procedure GrPutScanline(x1,x2,yy: Integer;c: GrColorsPtr; Op: GrColor); asmname 'GrPutScanline'; +procedure GrPutScanline(x1,x2,yy: CInteger;c: GrColorsPtr; Op: GrColor); asmname 'GrPutScanline'; { Input x1: first x coordinate to be set } { x2: last x coordinate to be set } { yy: y coordinate } @@ -540,16 +545,16 @@ NON CLIPPING DRAWING PRIMITIVES ================================================================== } -procedure GrPlotNC(x, y: Integer; c: GrColor); asmname 'GrPlotNC'; -procedure GrLineNC(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrLineNC'; -procedure GrHLineNC(x1, x2, y: Integer; c: GrColor); asmname 'GrHLineNC'; -procedure GrVLineNC(x, y1, y2: Integer; c: GrColor); asmname 'GrVLineNC'; -procedure GrBoxNC(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrBoxNC'; -procedure GrFilledBoxNC(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrFilledBoxNC'; -procedure GrFramedBoxNC(x1, y1, x2, y2, Wdt: Integer; protected var c: GrFBoxColors); asmname 'GrFramedBoxNC'; -procedure GrBitBltNC(Dest: GrContextPtr; x, y: Integer; Src: GrContextPtr; x1, y1, x2, y2: Integer; Op: GrColor); asmname 'GrBitBltNC'; -function GrPixelNC(x, y:Integer):GrColor; asmname 'GrPixelNC'; -function GrPixelCNC(c: GrContextPtr; x, y: Integer): GrColor; asmname 'GrPixelCNC'; +procedure GrPlotNC(x, y: CInteger; c: GrColor); asmname 'GrPlotNC'; +procedure GrLineNC(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrLineNC'; +procedure GrHLineNC(x1, x2, y: CInteger; c: GrColor); asmname 'GrHLineNC'; +procedure GrVLineNC(x, y1, y2: CInteger; c: GrColor); asmname 'GrVLineNC'; +procedure GrBoxNC(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrBoxNC'; +procedure GrFilledBoxNC(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrFilledBoxNC'; +procedure GrFramedBoxNC(x1, y1, x2, y2, Wdt: CInteger; protected var c: GrFBoxColors); asmname 'GrFramedBoxNC'; +procedure GrBitBltNC(Dest: GrContextPtr; x, y: CInteger; Src: GrContextPtr; x1, y1, x2, y2: CInteger; Op: GrColor); asmname 'GrBitBltNC'; +function GrPixelNC(x, y:CInteger):GrColor; asmname 'GrPixelNC'; +function GrPixelCNC(c: GrContextPtr; x, y: CInteger): GrColor; asmname 'GrPixelCNC'; { ================================================================== FONTS AND TEXT PRIMITIVES @@ -593,41 +598,41 @@ { font structures } type - { typedef struct _GR_fontHeader } { font descriptor } + { font descriptor } GrFontHeader = record - Name : CString; { font name } - Family : CString; { font family name } - Proportional: ByteBool; { characters have varying width } - Scalable : ByteBool; { derived from a scalable font } - Preloaded : ByteBool; { set when linked Integero program } - Modified : ByteBool; { "tweaked" font (resized, etc..) } - Width : Cardinal; { width (proportional=>average) } - Height : Cardinal; { font height } - Baseline : Cardinal; { baseline pixel pos (from top) } - ULPos : Cardinal; { underline pixel pos (from top) } - ULHeight : Cardinal; { underline width } - MinChar : Cardinal; { lowest character code in font } - NumChars : Cardinal; { number of characters in font } + Name, { font name } + Family: CString; { font family name } + Proportional, { characters have varying width } + Scalable, { derived from a scalable font } + Preloaded, { set when linked Integero program } + Modified: ByteBool; { "tweaked" font (resized, etc..) } + Width, { width (proportional=>average) } + Height, { font height } + Baseline, { baseline pixel pos (from top) } + ULPos, { underline pixel pos (from top) } + ULHeight, { underline width } + MinChar, { lowest character code in font } + NumChars: CCardinal { number of characters in font } end; - { typedef struct _GR_fontChrInfo } { character descriptor } + { character descriptor } GrFontChrInfo = record - Width : Cardinal; { width of this character } - Offset: Cardinal; { offset from start of bitmap } + Width, { width of this character } + Offset: CCardinal { offset from start of bitmap } end; - { typedef struct _GR_font } { the complete font } - AuxOffsType = array [0 .. 6] of Integer; + { the complete font } + AuxOffsType = array [0 .. 6] of CInteger; GrFont = record - h : GrFontHeader; { the font info structure } - BitMap : MemPtr; { character bitmap array } - AuxMap : MemPtr; { map for rotated & underline chrs } - MinWidth: Cardinal; { width of narrowest character } - MaxWidth: Cardinal; { width of widest character } - AuxSize : Cardinal; { allocated size of auxiliary map } - AuxNext : Cardinal; { next free byte in auxiliary map } - AuxOffs : ^AuxOffsType; { offsets to completed aux chars } - ChrInfo : array [1 .. 1] of GrFontChrInfo; { character info (not act. size) } + h: GrFontHeader; { the font info structure } + BitMap, { character bitmap array } + AuxMap: MemPtr; { map for rotated & underline chrs } + MinWidth, { width of narrowest character } + MaxWidth, { width of widest character } + AuxSize, { allocated size of auxiliary map } + AuxNext: CCardinal; { next free byte in auxiliary map } + AuxOffs: ^AuxOffsType; { offsets to completed aux chars } + ChrInfo: array [1 .. 1] of GrFontChrInfo { character info (not act. size) } end; GrFontPtr = ^GrFont; @@ -639,74 +644,74 @@ GrDefaultFont: GrFont; varasmname 'GrFont_PC8x14'; function GrLoadFont(FontName: CString): GrFontPtr; asmname 'GrLoadFont'; -function GrLoadConvertedFont(FontName: CString; cvt, w, h, MinCh, MaxCh: Integer): GrFontPtr; asmname 'GrLoadConvertedFont'; -function GrBuildConvertedFont(protected var From: GrFont; cvt, w, h, MinCh, MaxCh: Integer): GrFontPtr; asmname 'GrBuildConvertedFont'; +function GrLoadConvertedFont(FontName: CString; cvt, w, h, MinCh, MaxCh: CInteger): GrFontPtr; asmname 'GrLoadConvertedFont'; +function GrBuildConvertedFont(protected var From: GrFont; cvt, w, h, MinCh, MaxCh: CInteger): GrFontPtr; asmname 'GrBuildConvertedFont'; procedure GrUnloadFont(var Font: GrFont); asmname 'GrUnloadFont'; procedure GrDumpFont(protected var f: GrFont; CsymbolName, FileName: CString); asmname 'GrDumpFont'; procedure GrSetFontPath(path_list: CString); asmname 'GrSetFontPath'; -function GrFontCharPresent(protected var Font: GrFont; Chr: Integer): Boolean; asmname 'GrFontCharPresent'; -function GrFontCharWidth(protected var Font: GrFont; Chr: Integer): Integer; asmname 'GrFontCharWidth'; -function GrFontCharHeight(protected var Font: GrFont; Chr: Integer): Integer; asmname 'GrFontCharHeight'; -function GrFontCharBmpRowSize(protected var Font: GrFont; Chr: Integer): Integer; asmname 'GrFontCharBmpRowSize'; -function GrFontCharBitmapSize(protected var Font: GrFont; Chr: Integer): Integer; asmname 'GrFontCharBitmapSize'; -function GrFontStringWidth(protected var Font: GrFont; Text: CString; Len, Typ_e: Integer): Integer; asmname 'GrFontStringWidth'; -function GrFontStringHeight(protected var Font: GrFont; Text: CString; Len, Typ_e: Integer): Integer; asmname 'GrFontStringHeight'; -function GrProportionalTextWidth(protected var Font: GrFont; Text: CString; Len, Typ_e: Integer): Integer; asmname 'GrProportionalTextWidth'; -function GrBuildAuxiliaryBitmap(var Font: GrFont; Chr, Dir, ul: Integer): MemPtr; asmname 'GrBuildAuxiliaryBitmap'; -function GrFontCharBitmap(protected var Font: GrFont; Chr: Integer): MemPtr; asmname 'GrFontCharBitmap'; -function GrFontCharAuxBmp(var Font: GrFont; Chr, Dir, ul: Integer): MemPtr; asmname 'GrFontCharAuxBmp'; +function GrFontCharPresent(protected var Font: GrFont; Chr: CInteger): Boolean; asmname 'GrFontCharPresent'; +function GrFontCharWidth(protected var Font: GrFont; Chr: CInteger): CInteger; asmname 'GrFontCharWidth'; +function GrFontCharHeight(protected var Font: GrFont; Chr: CInteger): CInteger; asmname 'GrFontCharHeight'; +function GrFontCharBmpRowSize(protected var Font: GrFont; Chr: CInteger): CInteger; asmname 'GrFontCharBmpRowSize'; +function GrFontCharBitmapSize(protected var Font: GrFont; Chr: CInteger): CInteger; asmname 'GrFontCharBitmapSize'; +function GrFontStringWidth(protected var Font: GrFont; Text: CString; Len, Typ_e: CInteger): CInteger; asmname 'GrFontStringWidth'; +function GrFontStringHeight(protected var Font: GrFont; Text: CString; Len, Typ_e: CInteger): CInteger; asmname 'GrFontStringHeight'; +function GrProportionalTextWidth(protected var Font: GrFont; Text: CString; Len, Typ_e: CInteger): CInteger; asmname 'GrProportionalTextWidth'; +function GrBuildAuxiliaryBitmap(var Font: GrFont; Chr, Dir, ul: CInteger): MemPtr; asmname 'GrBuildAuxiliaryBitmap'; +function GrFontCharBitmap(protected var Font: GrFont; Chr: CInteger): MemPtr; asmname 'GrFontCharBitmap'; +function GrFontCharAuxBmp(var Font: GrFont; Chr, Dir, ul: CInteger): MemPtr; asmname 'GrFontCharAuxBmp'; type GrColorTableP = ^GrColors; - { typedef union _GR_textColor } { text color union } + { text color union } GrTextColor = record case 1 .. 2 of 1: (v: GrColor); { color value for "direct" text } 2: (p: GrColorTableP); { color table for attribute text } end; - { typedef struct _GR_textOption } { text drawing option structure } + { text drawing option structure } GrTextOption = record - txo_Font : GrFontPtr; { font to be used } - txo_FgColor: GrTextColor; { foreground color } + txo_Font: GrFontPtr; { font to be used } + txo_FgColor, { foreground color } txo_BgColor: GrTextColor; { background color } - txo_ChrType: ByteCard; { character type (see above) } - txo_Direct : ByteCard; { direction (see above) } - txo_XAlign : ByteCard; { X alignment (see above) } - txo_YAlign : ByteCard; { Y alignment (see above) } + txo_ChrType, { character type (see above) } + txo_Direct, { direction (see above) } + txo_XAlign, { X alignment (see above) } + txo_YAlign: ByteCard { Y alignment (see above) } end; - { typedef struct } { fixed font text window desc. } + { fixed font text window desc. } GrTextRegion = record - txr_Font : GrTextColor; { font to be used } - txr_FgColor : GrTextColor; { foreground color } - txr_BgColor : GrTextColor; { background color } - txr_Buffer : Pointer; { pointer to text buffer } - txr_Backup : Pointer; { optional backup buffer } - txr_Width : Integer; { width of area in chars } - txr_Height : Integer; { height of area in chars } - txr_LineOffset: Integer; { offset in buffer(s) between rows } - txr_XPos : Integer; { upper left corner X coordinate } - txr_YPos : Integer; { upper left corner Y coordinate } - txr_ChrType : ByteCard; { character type (see above) } - end; - -function GrCharWidth(Chr: Integer; protected var Opt: GrTextOption): Integer; asmname 'GrCharWidth'; -function GrCharHeight(Chr: Integer; protected var Opt: GrTextOption): Integer; asmname 'GrCharHeight'; -procedure GrCharSize(Chr: Integer; protected var Opt: GrTextOption; var w, h: Integer); asmname 'GrCharSize'; -function GrStringWidth(Text: CString; Length: Integer; protected var Opt: GrTextOption): Integer; asmname 'GrStringWidth'; -function GrStringHeight(Text: CString; Length: Integer; protected var Opt: GrTextOption): Integer; asmname 'GrStringHeight'; -procedure GrStringSize(Text: CString; Length: Integer; protected var Opt: GrTextOption;var w, h: Integer); asmname 'GrStringSize'; - -procedure GrDrawChar(Chr, x, y: Integer; protected var Opt: GrTextOption); asmname 'GrDrawChar'; -procedure GrDrawString(Text: CString; Length, x, y: Integer; protected var Opt: GrTextOption); asmname 'GrDrawString'; -procedure GrTextXY(x, y: Integer; Text: CString; fg, bg: GrColor); asmname 'GrTextXY'; + txr_Font: GrFontPtr; { font to be used } + txr_FgColor, { foreground color } + txr_BgColor: GrTextColor; { background color } + txr_Buffer, { pointer to text buffer } + txr_Backup: Pointer; { optional backup buffer } + txr_Width, { width of area in chars } + txr_Height, { height of area in chars } + txr_LineOffset, { offset in buffer(s) between rows } + txr_XPos, { upper left corner X coordinate } + txr_YPos: CInteger; { upper left corner Y coordinate } + txr_ChrType: ByteCard { character type (see above) } + end; + +function GrCharWidth(Chr: CInteger; protected var Opt: GrTextOption): CInteger; asmname 'GrCharWidth'; +function GrCharHeight(Chr: CInteger; protected var Opt: GrTextOption): CInteger; asmname 'GrCharHeight'; +procedure GrCharSize(Chr: CInteger; protected var Opt: GrTextOption; var w, h: CInteger); asmname 'GrCharSize'; +function GrStringWidth(Text: CString; Length: CInteger; protected var Opt: GrTextOption): CInteger; asmname 'GrStringWidth'; +function GrStringHeight(Text: CString; Length: CInteger; protected var Opt: GrTextOption): CInteger; asmname 'GrStringHeight'; +procedure GrStringSize(Text: CString; Length: CInteger; protected var Opt: GrTextOption;var w, h: CInteger); asmname 'GrStringSize'; + +procedure GrDrawChar(Chr, x, y: CInteger; protected var Opt: GrTextOption); asmname 'GrDrawChar'; +procedure GrDrawString(Text: CString; Length, x, y: CInteger; protected var Opt: GrTextOption); asmname 'GrDrawString'; +procedure GrTextXY(x, y: CInteger; Text: CString; fg, bg: GrColor); asmname 'GrTextXY'; -procedure GrDumpChar(Chr, Col, Row: Integer; protected var r: GrTextRegion); asmname 'GrDumpChar'; -procedure GrDumpText(Col, Row, Wdt, Hgt: Integer; protected var r: GrTextRegion); asmname 'GrDumpText'; +procedure GrDumpChar(Chr, Col, Row: CInteger; protected var r: GrTextRegion); asmname 'GrDumpChar'; +procedure GrDumpText(Col, Row, Wdt, Hgt: CInteger; protected var r: GrTextRegion); asmname 'GrDumpText'; procedure GrDumpTextRegion(protected var r: GrTextRegion); asmname 'GrDumpTextRegion'; { ================================================================= @@ -719,20 +724,20 @@ type GrLineOption = record - No_Color : GrColor; { color used to draw line } - Lno_Width : Integer; { width of the line } - Lno_PattLen: Integer; { length of the dash pattern } - Lno_DashPat: MemPtr; { draw/nodraw pattern } + No_Color : GrColor; { color used to draw line } + Lno_Width, { width of the line } + Lno_PattLen: CInteger; { length of the dash pattern } + Lno_DashPat: MemPtr { draw/nodraw pattern } end; -procedure GrCustomLine(x1, y1, x2, y2: Integer; protected var o: GrLineOption); asmname 'GrCustomLine'; -procedure GrCustomBox(x1, y1, x2, y2: Integer; protected var o: GrLineOption); asmname 'GrCustomBox'; -procedure GrCustomCircle(xc, yc, r: Integer; protected var o: GrLineOption); asmname 'GrCustomCircle'; -procedure GrCustomEllipse(xc, yc, r: Integer; protected var o: GrLineOption); asmname 'GrCustomEllipse'; -procedure GrCustomCircleArc(xc, yc, r, Start, Ende, Style: Integer; protected var o: GrLineOption); asmname 'GrCustomCircleArc'; -procedure GrCustomEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; protected var o: GrLineOption); asmname 'GrCustomEllipseArc'; -procedure GrCustomPolyLine(NumPts: Integer; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrCustomPolyLine'; -procedure GrCustomPolygon(NumPts: Integer; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrCustomPolygon'; +procedure GrCustomLine(x1, y1, x2, y2: CInteger; protected var o: GrLineOption); asmname 'GrCustomLine'; +procedure GrCustomBox(x1, y1, x2, y2: CInteger; protected var o: GrLineOption); asmname 'GrCustomBox'; +procedure GrCustomCircle(xc, yc, r: CInteger; protected var o: GrLineOption); asmname 'GrCustomCircle'; +procedure GrCustomEllipse(xc, yc, r: CInteger; protected var o: GrLineOption); asmname 'GrCustomEllipse'; +procedure GrCustomCircleArc(xc, yc, r, Start, Ende, Style: CInteger; protected var o: GrLineOption); asmname 'GrCustomCircleArc'; +procedure GrCustomEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; protected var o: GrLineOption); asmname 'GrCustomEllipseArc'; +procedure GrCustomPolyLine(NumPts: CInteger; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrCustomPolyLine'; +procedure GrCustomPolygon(NumPts: CInteger; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrCustomPolygon'; { ================================================================== PATTERNED DRAWING AND FILLING PRIMITIVES @@ -743,14 +748,13 @@ height is user-defined. SET THE TYPE FLAG TO ZERO!!! } type - { typedef struct _GR_bitmap } GrBitmap = record - bmp_IsPixMap: Integer; { type flag for pattern union } - bmp_Height : Integer; { bitmap height } - bmp_Data : MemPtr; { pointer to the bit pattern } - bmp_FgColor : GrColor; { foreground color for fill } - bmp_BgColor : GrColor; { background color for fill } - bmp_MemFlags: Integer; { set if dynamically allocated } + bmp_IsPixMap, { type flag for pattern union } + bmp_Height: CInteger; { bitmap height } + bmp_Data: MemPtr; { pointer to the bit pattern } + bmp_FgColor, { foreground color for fill } + bmp_BgColor: GrColor; { background color for fill } + bmp_MemFlags: CInteger { set if dynamically allocated } end; { PIXMAP: a fill pattern stored in a layout identical to the video RAM @@ -758,21 +762,19 @@ of the library functions is used to build it. KEEP THE TYPE FLAG NONZERO!!! } - { typedef struct _GR_pixmap } GrPixmap = record - pxp_IsPixMap: Integer; { type flag for pattern union } - pxp_Width : Integer; { pixmap width (in pixels) } - pxp_Height : Integer; { pixmap height (in pixels) } - pxp_Oper : GrColor; { bitblt mode (SET, OR, XOR, AND, IMAGE) } - pxp_Source : GrFrameType; { source context for fill } + pxp_IsPixMap, { type flag for pattern union } + pxp_Width, { pixmap width (in pixels) } + pxp_Height: CInteger; { pixmap height (in pixels) } + pxp_Oper: GrColor; { bitblt mode (SET, OR, XOR, AND, IMAGE) } + pxp_Source: GrFrameType { source context for fill } end; { Fill pattern union -- can either be a bitmap or a pixmap } - { typedef union _GR_pattern } GrPattern = record case 1 .. 3 of - 1: (gp_IsPixMap: Integer); { nonzero for pixmaps } + 1: (gp_IsPixMap: CInteger); { nonzero for pixmaps } 2: (gp_BitMap : GrBitmap); { fill bitmap } 3: (gp_PixMap : GrPixmap); { fill pixmap } end; @@ -782,40 +784,40 @@ (1) fill pattern, and the (2) custom line drawing option } GrLinePattern = record - lnp_Pattern: GrPatternPtr; { fill pattern } - lnp_Option : ^GrLineOption; { width + dash pattern } + lnp_Pattern: GrPatternPtr; { fill pattern } + lnp_Option : ^GrLineOption { width + dash pattern } end; GrLinePatternPtr = GrLinePattern; -function GrBuildPixmap(protected var Pixels; w, h: Integer; protected var Colors { : array of GrColor }): GrPatternPtr; asmname 'GrBuildPixmap'; -function GrBuildPixmapFromBits(protected var Bits; w, h: Integer; fgc, bgc: GrColor): GrPatternPtr; asmname 'GrBuildPixmapFromBits'; +function GrBuildPixmap(protected var Pixels; w, h: CInteger; protected var Colors { : array of GrColor }): GrPatternPtr; asmname 'GrBuildPixmap'; +function GrBuildPixmapFromBits(protected var Bits; w, h: CInteger; fgc, bgc: GrColor): GrPatternPtr; asmname 'GrBuildPixmapFromBits'; function GrConvertToPixmap(Src: GrContextPtr): GrPatternPtr; asmname 'GrConvertToPixmap'; procedure GrDestroyPattern(p: GrPatternPtr); asmname 'GrDestroyPattern'; -procedure GrPatternedLine(x1, y1, x2, y2: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedLine'; -procedure GrPatternedBox(x1, y1, x2, y2: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedBox'; -procedure GrPatternedCircle(xc, yc, r: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedCircle'; -procedure GrPatternedEllipse(xc, yc, xa, ya: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedEllipse'; -procedure GrPatternedCircleArc(xc, yc, r, Start, Ende, Style: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedCircleArc'; -procedure GrPatternedEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; lp: GrLinePatternPtr); asmname 'GrPatternedEllipseArc'; -procedure GrPatternedPolyLine(NumPts: Integer; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrPatternedPolyLine'; -procedure GrPatternedPolygon(NumPts: Integer; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrPatternedPolygon'; - -procedure GrPatternFilledPlot(x, y: Integer; p: GrPatternPtr); asmname 'GrPatternFilledPlot'; -procedure GrPatternFilledLine(x1, y1, x2, y2: Integer; p: GrPatternPtr); asmname 'GrPatternFilledLine'; -procedure GrPatternFilledBox(x1, y1, x2, y2: Integer; p: GrPatternPtr); asmname 'GrPatternFilledBox'; -procedure GrPatternFilledCircle(xc, yc, r: Integer; p: GrPatternPtr); asmname 'GrPatternFilledCircle'; -procedure GrPatternFilledEllipse(xc, yc, xa, ya: Integer; p: GrPatternPtr); asmname 'GrPatternFilledEllipse'; -procedure GrPatternFilledCircleArc(xc, yc, r, Start, Ende, Style: Integer; p: GrPatternPtr); asmname 'GrPatternFilledCircleArc'; -procedure GrPatternFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; p: GrPatternPtr); asmname 'GrPatternFilledEllipseArc'; -procedure GrPatternFilledConvexPolygon(NumPts: Integer; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrPatternFilledConvexPolygon'; -procedure GrPatternFilledPolygon(NumPts: Integer; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrPatternFilledPolygon'; -procedure GrPatternFloodFill(x, y: Integer; Border: GrColor; p: GrPatternPtr); asmname 'GrPatternFloodFill'; - -procedure GrPatternDrawChar(Chr, x, y: Integer; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawChar'; -procedure GrPatternDrawString(Text: CString; Length, x, y: Integer; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawString'; -procedure GrPatternDrawStringExt(Text: CString; Length, x, y: Integer; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawStringExt'; +procedure GrPatternedLine(x1, y1, x2, y2: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedLine'; +procedure GrPatternedBox(x1, y1, x2, y2: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedBox'; +procedure GrPatternedCircle(xc, yc, r: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedCircle'; +procedure GrPatternedEllipse(xc, yc, xa, ya: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedEllipse'; +procedure GrPatternedCircleArc(xc, yc, r, Start, Ende, Style: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedCircleArc'; +procedure GrPatternedEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; lp: GrLinePatternPtr); asmname 'GrPatternedEllipseArc'; +procedure GrPatternedPolyLine(NumPts: CInteger; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrPatternedPolyLine'; +procedure GrPatternedPolygon(NumPts: CInteger; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrPatternedPolygon'; + +procedure GrPatternFilledPlot(x, y: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledPlot'; +procedure GrPatternFilledLine(x1, y1, x2, y2: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledLine'; +procedure GrPatternFilledBox(x1, y1, x2, y2: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledBox'; +procedure GrPatternFilledCircle(xc, yc, r: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledCircle'; +procedure GrPatternFilledEllipse(xc, yc, xa, ya: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledEllipse'; +procedure GrPatternFilledCircleArc(xc, yc, r, Start, Ende, Style: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledCircleArc'; +procedure GrPatternFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledEllipseArc'; +procedure GrPatternFilledConvexPolygon(NumPts: CInteger; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrPatternFilledConvexPolygon'; +procedure GrPatternFilledPolygon(NumPts: CInteger; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrPatternFilledPolygon'; +procedure GrPatternFloodFill(x, y: CInteger; Border: GrColor; p: GrPatternPtr); asmname 'GrPatternFloodFill'; + +procedure GrPatternDrawChar(Chr, x, y: CInteger; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawChar'; +procedure GrPatternDrawString(Text: CString; Length, x, y: CInteger; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawString'; +procedure GrPatternDrawStringExt(Text: CString; Length, x, y: CInteger; protected var Opt: GrTextOption; p: GrPatternPtr); asmname 'GrPatternDrawStringExt'; { <image.h> - Image Utility @@ -830,20 +832,20 @@ Gr_Image_Inverse_LR = 1; { inverse left right } Gr_Image_Inverse_TD = 2; { inverse top down } -function GrImageBuild(protected var Pixels; w, h: Integer; protected var Colors { : array of GrColor }): GrImagePtr; asmname 'GrImageBuild'; +function GrImageBuild(protected var Pixels; w, h: CInteger; protected var Colors { : array of GrColor }): GrImagePtr; asmname 'GrImageBuild'; procedure GrImageDestroy(i: GrImagePtr); asmname 'GrImageDestroy'; -procedure GrImageDisplay(x,y: Integer; i: GrImagePtr); asmname 'GrImageDisplay'; -procedure GrImageDisplayExt(x1,y1,x2,y2: Integer; i: GrImagePtr); asmname 'GrImageDisplayExt'; -procedure GrImageFilledBoxAlign(xo,yo,x1,y1,x2,y2: Integer; p: GrImagePtr); asmname 'GrImageFilledBoxAlign'; -procedure GrImageHLineAlign(xo,yo,x,y,Width: Integer; p: GrImagePtr); asmname 'GrImageHLineAlign'; -procedure GrImagePlotAlign(xo,yo,x,y: Integer; p: GrImagePtr); asmname 'GrImagePlotAlign'; +procedure GrImageDisplay(x,y: CInteger; i: GrImagePtr); asmname 'GrImageDisplay'; +procedure GrImageDisplayExt(x1,y1,x2,y2: CInteger; i: GrImagePtr); asmname 'GrImageDisplayExt'; +procedure GrImageFilledBoxAlign(xo,yo,x1,y1,x2,y2: CInteger; p: GrImagePtr); asmname 'GrImageFilledBoxAlign'; +procedure GrImageHLineAlign(xo,yo,x,y,Width: CInteger; p: GrImagePtr); asmname 'GrImageHLineAlign'; +procedure GrImagePlotAlign(xo,yo,x,y: CInteger; p: GrImagePtr); asmname 'GrImagePlotAlign'; -function GrImageInverse(p: GrImagePtr; Flag: Integer): GrImagePtr; asmname 'GrImageInverse'; -function GrImageStretch(p: GrImagePtr; NWidth, NHeight: Integer): GrImagePtr; asmname 'GrImageStretch'; +function GrImageInverse(p: GrImagePtr; Flag: CInteger): GrImagePtr; asmname 'GrImageInverse'; +function GrImageStretch(p: GrImagePtr; NWidth, NHeight: CInteger): GrImagePtr; asmname 'GrImageStretch'; function GrImageFromPattern(p: GrPatternPtr): GrImagePtr; asmname 'GrImageFromPattern'; function GrImageFromContext(c: GrContextPtr): GrImagePtr; asmname 'GrImageFromContext'; -function GrImageBuildUsedAsPattern(protected var Pixels; w, h: Integer; protected var Colors { : array of GrColor }): GrImagePtr; asmname 'GrImageBuildUsedAsPattern'; +function GrImageBuildUsedAsPattern(protected var Pixels; w, h: CInteger; protected var Colors { : array of GrColor }): GrImagePtr; asmname 'GrImageBuildUsedAsPattern'; function GrPatternFromImage(i: GrImagePtr): GrPatternPtr; asmname 'GrPatternFromImage'; @@ -851,91 +853,90 @@ DRAWING IN USER WINDOW COORDINATES ================================================================== } -procedure GrSetUserWindow(x1, y1, x2, y2: Integer); asmname 'GrSetUserWindow'; -procedure GrGetUserWindow(var x1, y1, x2, y2: Integer); asmname 'GrGetUserWindow'; -procedure GrGetScreenCoord(var x, y: Integer); asmname 'GrGetScreenCoord'; -procedure GrGetUserCoord(var x, y: Integer); asmname 'GrGetUserCoord'; - -procedure GrUsrPlot(x, y: Integer; c:GrColor); asmname 'GrUsrPlot'; -procedure GrUsrLine(x1, y1, x2, y2: Integer; c:GrColor); asmname 'GrUsrLine'; -procedure GrUsrHLine(x1, x2, y:Integer; c:GrColor); asmname 'GrUsrHLine'; -procedure GrUsrVLine(x, y1, y2: Integer; c: GrColor); asmname 'GrUsrVLine'; -procedure GrUsrBox(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrUsrBox'; -procedure GrUsrFilledBox(x1, y1, x2, y2: Integer; c: GrColor); asmname 'GrUsrFilledBox'; -procedure GrUsrFramedBox(x1, y1, x2, y2, Wdt: Integer; c: GrFBoxColors); asmname 'GrUsrFramedBox'; - -procedure GrUsrCircle(xc, yc, r: Integer; c: GrColor); asmname 'GrUsrCircle'; -procedure GrUsrEllipse(xc, yc, xa, ya: Integer; c: GrColor); asmname 'GrUsrEllipse'; -procedure GrUsrCircleArc(xc, yc, r, Start, Ende, Style: Integer; c: GrColor); asmname 'GrUsrCircleArc'; -procedure GrUsrEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; c: GrColor); asmname 'GrUsrEllipseArc'; -procedure GrUsrFilledCircle(xc, yc, r: Integer; c: GrColor); asmname 'GrUsrFilledCircle'; -procedure GrUsrFilledEllipse(xc, yc, xa, ya: Integer; c: GrColor); asmname 'GrUsrFilledEllipse'; -procedure GrUsrFilledCircleArc(xc, yc, r, Start, Ende, Style: Integer; c: GrColor); asmname 'GrUsrFilledCircleArc'; -procedure GrUsrFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; c: GrColor); asmname 'GrUsrFilledEllipseArc'; -procedure GrUsrPolyLine(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrPolyLine'; -procedure GrUsrPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrPolygon'; -procedure GrUsrFilledConvexPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrFilledConvexPolygon'; -procedure GrUsrFilledPolygon(NumPts: Integer; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrFilledPolygon'; -procedure GrUsrFloodFill(x, y: Integer; Border, c: GrColor); asmname 'GrUsrFloodFill'; - -function GrUsrPixel(x, y:Integer):GrColor; asmname 'GrUsrPixel'; -function GrUsrPixelC(c: GrContextPtr; x, y: Integer):GrColor; asmname 'GrUsrPixelC'; - -procedure GrUsrCustomLine(x1, y1, x2, y2: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomLine'; -procedure GrUsrCustomBox(x1, y1, x2, y2: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomBox'; -procedure GrUsrCustomCircle(xc, yc, r: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomCircle'; -procedure GrUsrCustomEllipse(xc, yc, r: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomEllipse'; -procedure GrUsrCustomCircleArc(xc, yc, r, Start, Ende, Style: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomCircleArc'; -procedure GrUsrCustomEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; protected var o: GrLineOption); asmname 'GrUsrCustomEllipseArc'; -procedure GrUsrCustomPolyLine(NumPts: Integer; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrUsrCustomPolyLine'; -procedure GrUsrCustomPolygon(NumPts: Integer; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrUsrCustomPolygon'; - -procedure GrUsrPatternedLine(x1, y1, x2, y2: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedLine'; -procedure GrUsrPatternedBox(x1, y1, x2, y2: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedBox'; -procedure GrUsrPatternedCircle(xc, yc, r: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedCircle'; -procedure GrUsrPatternedEllipse(xc, yc, xa, ya: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedEllipse'; -procedure GrUsrPatternedCircleArc(xc, yc, r, Start, Ende, Style: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedCircleArc'; -procedure GrUsrPatternedEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; lp: GrLinePatternPtr); asmname 'GrUsrPatternedEllipseArc'; -procedure GrUsrPatternedPolyLine(NumPts: Integer; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrUsrPatternedPolyLine'; -procedure GrUsrPatternedPolygon(NumPts: Integer; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrUsrPatternedPolygon'; - -procedure GrUsrPatternFilledPlot(x, y: Integer; p: GrPatternPtr); asmname 'GrPatternFilledPlot'; -procedure GrUsrPatternFilledLine(x1, y1, x2, y2: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledLine'; -procedure GrUsrPatternFilledBox(x1, y1, x2, y2: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledBox'; -procedure GrUsrPatternFilledCircle(xc, yc, r: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledCircle'; -procedure GrUsrPatternFilledEllipse(xc, yc, xa, ya: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledEllipse'; -procedure GrUsrPatternFilledCircleArc(xc, yc, r, Start, Ende, Style: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledCircleArc'; -procedure GrUsrPatternFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: Integer; p: GrPatternPtr); asmname 'GrUsrPatternFilledEllipseArc'; -procedure GrUsrPatternFilledConvexPolygon(NumPts: Integer; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrUsrPatternFilledConvexPolygon'; -procedure GrUsrPatternFilledPolygon(NumPts: Integer; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrUsrPatternFilledPolygon'; -procedure GrUsrPatternFloodFill(x, y: Integer; Border: GrColor; p: GrPatternPtr); asmname 'GrUsrPatternFloodFill'; - -procedure GrUsrDrawChar(Chr, x, y: Integer; protected var Opt: GrTextOption); asmname 'GrUsrDrawChar'; -procedure GrUsrDrawString(Text: CString; Length, x, y: Integer; protected var Opt: GrTextOption); asmname 'GrUsrDrawString'; -procedure GrUsrTextXY(x, y: Integer; Text: CString; fg, bg: Integer); asmname 'GrUsrTextXY'; +procedure GrSetUserWindow(x1, y1, x2, y2: CInteger); asmname 'GrSetUserWindow'; +procedure GrGetUserWindow(var x1, y1, x2, y2: CInteger); asmname 'GrGetUserWindow'; +procedure GrGetScreenCoord(var x, y: CInteger); asmname 'GrGetScreenCoord'; +procedure GrGetUserCoord(var x, y: CInteger); asmname 'GrGetUserCoord'; + +procedure GrUsrPlot(x, y: CInteger; c:GrColor); asmname 'GrUsrPlot'; +procedure GrUsrLine(x1, y1, x2, y2: CInteger; c:GrColor); asmname 'GrUsrLine'; +procedure GrUsrHLine(x1, x2, y:CInteger; c:GrColor); asmname 'GrUsrHLine'; +procedure GrUsrVLine(x, y1, y2: CInteger; c: GrColor); asmname 'GrUsrVLine'; +procedure GrUsrBox(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrUsrBox'; +procedure GrUsrFilledBox(x1, y1, x2, y2: CInteger; c: GrColor); asmname 'GrUsrFilledBox'; +procedure GrUsrFramedBox(x1, y1, x2, y2, Wdt: CInteger; c: GrFBoxColors); asmname 'GrUsrFramedBox'; + +procedure GrUsrCircle(xc, yc, r: CInteger; c: GrColor); asmname 'GrUsrCircle'; +procedure GrUsrEllipse(xc, yc, xa, ya: CInteger; c: GrColor); asmname 'GrUsrEllipse'; +procedure GrUsrCircleArc(xc, yc, r, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrUsrCircleArc'; +procedure GrUsrEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrUsrEllipseArc'; +procedure GrUsrFilledCircle(xc, yc, r: CInteger; c: GrColor); asmname 'GrUsrFilledCircle'; +procedure GrUsrFilledEllipse(xc, yc, xa, ya: CInteger; c: GrColor); asmname 'GrUsrFilledEllipse'; +procedure GrUsrFilledCircleArc(xc, yc, r, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrUsrFilledCircleArc'; +procedure GrUsrFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; c: GrColor); asmname 'GrUsrFilledEllipseArc'; +procedure GrUsrPolyLine(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrPolyLine'; +procedure GrUsrPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrPolygon'; +procedure GrUsrFilledConvexPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrFilledConvexPolygon'; +procedure GrUsrFilledPolygon(NumPts: CInteger; var Points{ : array of PointType }; c: GrColor); asmname 'GrUsrFilledPolygon'; +procedure GrUsrFloodFill(x, y: CInteger; Border, c: GrColor); asmname 'GrUsrFloodFill'; + +function GrUsrPixel(x, y:CInteger):GrColor; asmname 'GrUsrPixel'; +function GrUsrPixelC(c: GrContextPtr; x, y: CInteger):GrColor; asmname 'GrUsrPixelC'; + +procedure GrUsrCustomLine(x1, y1, x2, y2: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomLine'; +procedure GrUsrCustomBox(x1, y1, x2, y2: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomBox'; +procedure GrUsrCustomCircle(xc, yc, r: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomCircle'; +procedure GrUsrCustomEllipse(xc, yc, r: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomEllipse'; +procedure GrUsrCustomCircleArc(xc, yc, r, Start, Ende, Style: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomCircleArc'; +procedure GrUsrCustomEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; protected var o: GrLineOption); asmname 'GrUsrCustomEllipseArc'; +procedure GrUsrCustomPolyLine(NumPts: CInteger; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrUsrCustomPolyLine'; +procedure GrUsrCustomPolygon(NumPts: CInteger; var Points{ : array of PointType }; protected var o: GrLineOption); asmname 'GrUsrCustomPolygon'; + +procedure GrUsrPatternedLine(x1, y1, x2, y2: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedLine'; +procedure GrUsrPatternedBox(x1, y1, x2, y2: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedBox'; +procedure GrUsrPatternedCircle(xc, yc, r: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedCircle'; +procedure GrUsrPatternedEllipse(xc, yc, xa, ya: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedEllipse'; +procedure GrUsrPatternedCircleArc(xc, yc, r, Start, Ende, Style: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedCircleArc'; +procedure GrUsrPatternedEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; lp: GrLinePatternPtr); asmname 'GrUsrPatternedEllipseArc'; +procedure GrUsrPatternedPolyLine(NumPts: CInteger; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrUsrPatternedPolyLine'; +procedure GrUsrPatternedPolygon(NumPts: CInteger; var Points{ : array of PointType }; lp: GrLinePatternPtr); asmname 'GrUsrPatternedPolygon'; + +procedure GrUsrPatternFilledPlot(x, y: CInteger; p: GrPatternPtr); asmname 'GrPatternFilledPlot'; +procedure GrUsrPatternFilledLine(x1, y1, x2, y2: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledLine'; +procedure GrUsrPatternFilledBox(x1, y1, x2, y2: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledBox'; +procedure GrUsrPatternFilledCircle(xc, yc, r: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledCircle'; +procedure GrUsrPatternFilledEllipse(xc, yc, xa, ya: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledEllipse'; +procedure GrUsrPatternFilledCircleArc(xc, yc, r, Start, Ende, Style: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledCircleArc'; +procedure GrUsrPatternFilledEllipseArc(xc, yc, xa, ya, Start, Ende, Style: CInteger; p: GrPatternPtr); asmname 'GrUsrPatternFilledEllipseArc'; +procedure GrUsrPatternFilledConvexPolygon(NumPts: CInteger; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrUsrPatternFilledConvexPolygon'; +procedure GrUsrPatternFilledPolygon(NumPts: CInteger; var Points{ : array of PointType }; p: GrPatternPtr); asmname 'GrUsrPatternFilledPolygon'; +procedure GrUsrPatternFloodFill(x, y: CInteger; Border: GrColor; p: GrPatternPtr); asmname 'GrUsrPatternFloodFill'; + +procedure GrUsrDrawChar(Chr, x, y: CInteger; protected var Opt: GrTextOption); asmname 'GrUsrDrawChar'; +procedure GrUsrDrawString(Text: CString; Length, x, y: CInteger; protected var Opt: GrTextOption); asmname 'GrUsrDrawString'; +procedure GrUsrTextXY(x, y: CInteger; Text: CString; fg, bg: CInteger); asmname 'GrUsrTextXY'; { ================================================================== GRAPHICS CURSOR UTILITIES ================================================================== } type - { typedef struct _GR_cursor } GrCursor = record - Work : GrContext; { work areas (4) } - XCord,YCord: Integer; { cursor position on screen } - XSize,YSize: Integer; { cursor size } - XOffs,YOffs: Integer; { LU corner to hot point offset } - XWork,YWork: Integer; { save/work area sizes } - XWPos,YWPos: Integer; { save/work area position on screen } - Displayed : Integer; { set if displayed } + Work: GrContext; { work areas (4) } + XCord,YCord, { cursor position on screen } + XSize,YSize, { cursor size } + XOffs,YOffs, { LU corner to hot point offset } + XWork,YWork, { save/work area sizes } + XWPos,YWPos, { save/work area position on screen } + Displayed: CInteger { set if displayed } end; GrCursorPtr = ^GrCursor; -function GrBuildCursor(Pixels: Pointer; Pitch, w, h, xo, yo: Integer; protected var Colors { : array of GrColor }): GrCursorPtr; asmname 'GrBuildCursor'; +function GrBuildCursor(Pixels: Pointer; Pitch, w, h, xo, yo: CInteger; protected var Colors { : array of GrColor }): GrCursorPtr; asmname 'GrBuildCursor'; procedure GrDestroyCursor(Cursor: GrCursorPtr); asmname 'GrDestroyCursor'; procedure GrDisplayCursor(Cursor: GrCursorPtr); asmname 'GrDisplayCursor'; procedure GrEraseCursor(Cursor: GrCursorPtr); asmname 'GrEraseCursor'; -procedure GrMoveCursor(Cursor: GrCursorPtr; x, y: Integer); asmname 'GrMoveCursor'; +procedure GrMoveCursor(Cursor: GrCursorPtr; x, y: CInteger); asmname 'GrMoveCursor'; { ================================================================== MOUSE AND KEYBOARD INPUT UTILITIES @@ -982,43 +983,43 @@ Gr_M_Queue_Size = 128; { default queue size } type - { typedef struct _GR_mouseEvent } { mouse event buffer structure } + { mouse event buffer structure } GrMouseEvent = record - Flags : Integer; { event type flags (see above) } - x, y : Integer; { mouse coordinates } - Buttons: Integer; { mouse button state } - Key : Integer; { key code from keyboard } - KBStat : Integer; { keybd status (ALT, CTRL, etc..) } - DTime : MedInt; { time since last event (msec) } + Flags, { event type flags (see above) } + x, y, { mouse coordinates } + Buttons, { mouse button state } + Key, { key code from keyboard } + KBStat: CInteger; { keybd status (ALT, CTRL, etc..) } + DTime: MedInt { time since last event (msec) } end; GrMouseEventPtr = ^GrMouseEvent; function GrMouseDetect: Boolean; asmname 'GrMouseDetect'; -procedure GrMouseEventMode(Dummy: Integer); asmname 'GrMouseEventMode'; +procedure GrMouseEventMode(Dummy: CInteger); asmname 'GrMouseEventMode'; procedure GrMouseInit; asmname 'GrMouseInit'; -procedure GrMouseInitN(Queue_Size: Integer); asmname 'GrMouseInitN'; +procedure GrMouseInitN(Queue_Size: CInteger); asmname 'GrMouseInitN'; procedure GrMouseUnInit; asmname 'GrMouseUnInit'; -procedure GrMouseSetSpeed(SPMult, SPDiv: Integer); asmname 'GrMouseSetSpeed'; -procedure GrMouseSetAccel(Thresh, Accel: Integer); asmname 'GrMouseSetAccel'; -procedure GrMouseSetLimits(x1, y1, x2, y2: Integer); asmname 'GrMouseSetLimits'; -procedure GrMouseGetLimits(var x1, y1, x2, y2: Integer); asmname 'GrMouseGetLimits'; -procedure GrMouseWarp(x, y: Integer); asmname 'GrMouseWarp'; +procedure GrMouseSetSpeed(SPMult, SPDiv: CInteger); asmname 'GrMouseSetSpeed'; +procedure GrMouseSetAccel(Thresh, Accel: CInteger); asmname 'GrMouseSetAccel'; +procedure GrMouseSetLimits(x1, y1, x2, y2: CInteger); asmname 'GrMouseSetLimits'; +procedure GrMouseGetLimits(var x1, y1, x2, y2: CInteger); asmname 'GrMouseGetLimits'; +procedure GrMouseWarp(x, y: CInteger); asmname 'GrMouseWarp'; procedure GrMouseEventEnable(Enable_KB, Enable_MS: Boolean); asmname 'GrMouseEventEnable'; -procedure GrMouseGetEvent(Flags: Integer; Event: GrMouseEventPtr); asmname 'GrMouseGetEvent'; -procedure GrMouseGetEventT(Flags: Integer; Event: GrMouseEventPtr; timout_msecs: Integer); asmname 'GrMouseGetEventT'; -function GrMousePendingEvent: Integer; asmname 'GrMousePendingEvent'; +procedure GrMouseGetEvent(Flags: CInteger; Event: GrMouseEventPtr); asmname 'GrMouseGetEvent'; +procedure GrMouseGetEventT(Flags: CInteger; Event: GrMouseEventPtr; timout_msecs: CInteger); asmname 'GrMouseGetEventT'; +function GrMousePendingEvent: CInteger; asmname 'GrMousePendingEvent'; function GrMouseGetCursor: GrCursorPtr; asmname 'GrMouseGetCursor'; procedure GrMouseSetCursor(Cursor: GrCursorPtr); asmname 'GrMouseSetCursor'; procedure GrMouseSetColors(fg,bg: GrColor); asmname 'GrMouseSetColors'; -procedure GrMouseSetCursorMode(Mode: Integer; x1, y1, x2, y2: Integer; c: Integer); asmname 'GrMouseSetCursorMode'; +procedure GrMouseSetCursorMode(Mode: CInteger; x1, y1, x2, y2: CInteger; c: CInteger); asmname 'GrMouseSetCursorMode'; procedure GrMouseDisplayCursor; asmname 'GrMouseDisplayCursor'; procedure GrMouseEraseCursor; asmname 'GrMouseEraseCursor'; procedure GrMouseUpdateCursor; asmname 'GrMouseUpdateCursor'; function GrMouseCursorIsDisplayed: Boolean; asmname 'GrMouseCursorIsDisplayed'; -function GrMouseBlock(c: GrContextPtr; x1, y1, x2, y2: Integer): Integer; asmname 'GrMouseBlock'; -procedure GrMouseUnBlock(Return_Value_From_GrMouseBlock: Integer); asmname 'GrMouseUnBlock'; +function GrMouseBlock(c: GrContextPtr; x1, y1, x2, y2: CInteger): CInteger; asmname 'GrMouseBlock'; +procedure GrMouseUnBlock(Return_Value_From_GrMouseBlock: CInteger); asmname 'GrMouseUnBlock'; { ================================================================== KEYBOARD INTERFACE @@ -1338,18 +1339,18 @@ { new functions to replace the old style kbhit / getch / getkey / getxkey / getkbstat keyboard interface } -function GrKeyPressed: Integer; asmname 'GrKeyPressed'; +function GrKeyPressed: CInteger; asmname 'GrKeyPressed'; function GrKeyRead: GrKeyType; asmname 'GrKeyRead'; -function GrKeyStat: Integer; asmname 'GrKeyStat'; +function GrKeyStat: CInteger; asmname 'GrKeyStat'; { ================================================================== MISCELLANEOUS UTILITIY FUNCTIONS ================================================================== } -procedure GrResizeGrayMap (var Map; Pitch, ow, oh, nw, nh: Integer); asmname 'GrResizeGrayMap'; -function GrMatchString (Pattern, Strg: CString): Integer; asmname 'GrMatchString'; +procedure GrResizeGrayMap (var Map; Pitch, ow, oh, nw, nh: CInteger); asmname 'GrResizeGrayMap'; +function GrMatchString (Pattern, Strg: CString): CInteger; asmname 'GrMatchString'; procedure GrSetWindowTitle (Title: CString); asmname 'GrSetWindowTitle'; -procedure GrSleep (MSec: Integer); asmname 'GrSleep'; +procedure GrSleep (MSec: CInteger); asmname 'GrSleep'; { ================================================================== PNM FUNCTIONS @@ -1367,23 +1368,23 @@ { The PNM functions } -function GrSaveContextToPbm (grc: GrContextPtr; FileName, Comment: CString): Integer; asmname 'GrSaveContextToPbm'; -function GrSaveContextToPgm (grc: GrContextPtr; FileName, Comment: CString): Integer; asmname 'GrSaveContextToPgm'; -function GrSaveContextToPpm (grc: GrContextPtr; FileName, Comment: CString): Integer; asmname 'GrSaveContextToPpm'; -function GrLoadContextFromPnm (grc: GrContextPtr; FileName: CString): Integer; asmname 'GrLoadContextFromPnm'; -function GrQueryPnm (FileName: CString; var Width, Height, MaxVal: Integer): Integer; asmname 'GrQueryPnm'; -function GrLoadContextFromPnmBuffer (grc: GrContextPtr; protected var Buffer): Integer; asmname 'GrLoadContextFromPnmBuffer'; -function GrQueryPnmBuffer (protected var Buffer; var Width, Height, MaxVal: Integer): Integer; asmname 'GrQueryPnmBuffer'; +function GrSaveContextToPbm (grc: GrContextPtr; FileName, Comment: CString): CInteger; asmname 'GrSaveContextToPbm'; +function GrSaveContextToPgm (grc: GrContextPtr; FileName, Comment: CString): CInteger; asmname 'GrSaveContextToPgm'; +function GrSaveContextToPpm (grc: GrContextPtr; FileName, Comment: CString): CInteger; asmname 'GrSaveContextToPpm'; +function GrLoadContextFromPnm (grc: GrContextPtr; FileName: CString): CInteger; asmname 'GrLoadContextFromPnm'; +function GrQueryPnm (FileName: CString; var Width, Height, MaxVal: CInteger): CInteger; asmname 'GrQueryPnm'; +function GrLoadContextFromPnmBuffer (grc: GrContextPtr; protected var Buffer): CInteger; asmname 'GrLoadContextFromPnmBuffer'; +function GrQueryPnmBuffer (protected var Buffer; var Width, Height, MaxVal: CInteger): CInteger; asmname 'GrQueryPnmBuffer'; { ================================================================== ADDON FUNCTIONS these functions may not be installed or available on all systems ================================================================== } -function GrPngSupport: Integer; asmname 'GrPngSupport'; -function GrSaveContextToPng (grc: GrContextPtr; FileName: CString): Integer; asmname 'GrSaveContextToPng'; -function GrLoadContextFromPng (grc: GrContextPtr; FileName: CString; UseAlpha: Integer): Integer; asmname 'GrLoadContextFromPng'; -function GrQueryPng (FileName: CString; var Width, Height: Integer): Integer; asmname 'GrQueryPng'; +function GrPngSupport: CInteger; asmname 'GrPngSupport'; +function GrSaveContextToPng (grc: GrContextPtr; FileName: CString): CInteger; asmname 'GrSaveContextToPng'; +function GrLoadContextFromPng (grc: GrContextPtr; FileName: CString; UseAlpha: CInteger): CInteger; asmname 'GrLoadContextFromPng'; +function GrQueryPng (FileName: CString; var Width, Height: CInteger): CInteger; asmname 'GrQueryPng'; { SaveContextToTiff - Dump a context in a TIFF file @@ -1398,7 +1399,7 @@ requires tifflib by Sam Leffler (sam(a)engr.sgi.com) available at ftp://ftp.sgi.com/graphics/tiff } -function SaveContextToTiff(Cxt: GrContextPtr; TiffN: CString; Compr: Integer; DocN: CString): Integer; asmname 'SaveContextToTiff'; +function SaveContextToTiff(Cxt: GrContextPtr; TiffN: CString; Compr: CInteger; DocN: CString): CInteger; asmname 'SaveContextToTiff'; { GrSaveContextToJpeg - Dump a context in a JPEG file @@ -1412,11 +1413,11 @@ requires jpeg-6a by IJG (Independent JPEG Group) available at ftp.uu.net as graphics/jpeg/jpegsrc.v6a.tar.gz } -function GrSaveContextToJpeg(grc: GrContextPtr; FileName: CString; Accuracy: Integer): Integer; asmname 'GrSaveContextToJpeg'; -function GrSaveContextToGrayJpeg(grc: GrContextPtr; FileName: CString; Accuracy: Integer): Integer; asmname 'GrSaveContextToGrayJpeg'; -function GrJpegSupport: Integer; asmname 'GrJpegSupport'; -function GrLoadContextFromJpeg(grc: GrContextPtr; FileName: CString; Scale: Integer): Integer; asmname 'GrLoadContextFromJpeg'; -function GrQueryJpeg(FileName: CString; var Width, Height: Integer): Integer; asmname 'GrQueryJpeg'; +function GrSaveContextToJpeg(grc: GrContextPtr; FileName: CString; Accuracy: CInteger): CInteger; asmname 'GrSaveContextToJpeg'; +function GrSaveContextToGrayJpeg(grc: GrContextPtr; FileName: CString; Accuracy: CInteger): CInteger; asmname 'GrSaveContextToGrayJpeg'; +function GrJpegSupport: CInteger; asmname 'GrJpegSupport'; +function GrLoadContextFromJpeg(grc: GrContextPtr; FileName: CString; Scale: CInteger): CInteger; asmname 'GrLoadContextFromJpeg'; +function GrQueryJpeg(FileName: CString; var Width, Height: CInteger): CInteger; asmname 'GrQueryJpeg'; implementation --- grx246/pascal/bgi/graph.pas.orig Thu Sep 23 18:09:30 2004 +++ grx246/pascal/bgi/graph.pas Thu Sep 23 18:17:59 2004 @@ -18,8 +18,9 @@ 22/02/01 patches by Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> Necessary to correct the drawpoly and fillpoly declarations. - Some changes to make this file compile with more recent versions of - gpc. } + + Maurice Lombardi, Frank Heckenbach <frank(a)pascal.gnu.de>: Some changes + to make this file compile with more recent versions of GPC. } { Define this if you don't want this unit to declare a KeyPressed and a ReadKey function. } @@ -311,7 +312,7 @@ { BGI - API definitions } -procedure DetectGraph(var GraphDriver, GraphMode: CInteger); asmname 'detectgraph'; +procedure DetectGraph(var GraphDriver, GraphMode: Integer); procedure InitGraph(var GraphDriver, GraphMode: Integer; PathToDriver: CString); procedure SetGraphMode(Mode: CInteger); asmname 'setgraphmode'; function GetModeName(ModeNumber: CInteger): WrkString; @@ -371,7 +372,7 @@ procedure ClearDevice; asmname '__gr_cleardevice'; procedure DrawPoly(NumPoints: CCardinal; var PolyPoints { : array of PointType }); asmname '__gr_drawpoly'; procedure Ellipse(x, y: CInteger; StAngle, EndAngle: CCardinal; XRadius, YRadius: CCardinal); asmname '__gr_ellipse'; -procedure GetAspectRatio(var XAsp, YAsp: CInteger); asmname '__gr_getaspectratio'; +procedure GetAspectRatio(var XAsp, YAsp: Integer); function GetBkColor: CCardinal; asmname '__gr_getbkcolor'; function GetColor: CCardinal; asmname '__gr_getcolor'; procedure GetFillPattern(var FillPattern: FillPatternType); asmname '__gr_getfillpattern'; @@ -392,7 +393,7 @@ procedure SetActivePage(Page: CCardinal); asmname '__gr_setactivepage'; procedure SetVisualPage(Page: CCardinal); asmname '__gr_setvisualpage'; procedure GetDefaultPalette(var Palette: PaletteType); -procedure GetModeRange(GraphDriver:CInteger; var LoMode, HiMode:CInteger); asmname '__gr_getmoderange'; +procedure GetModeRange(GraphDriver:CInteger; var LoMode, HiMode:Integer); function Black : CInteger; function Blue : CInteger; @@ -451,8 +452,7 @@ Functional in HiColor/TrueColor modes only } procedure SetRGBColor(Red, Green, Blue: CCardinal); asmname '__gr_setrgbcolor'; -{ Returns the actual RGB palette. Functional in - 256 color modes only. Won't work on Linux systems } +{ Returns the actual RGB palette. } procedure GetRGBPalette(Color: CInteger; var Red, Green, Blue: CInteger); asmname '__getrgbpalette'; { Transforms the predefined 16 EGA colors (RED, BLUE, MAGENTA, ...) @@ -474,6 +474,17 @@ implementation +procedure dg(var GraphDriver, GraphMode: CInteger); asmname 'detectgraph'; +procedure DetectGraph(var GraphDriver, GraphMode: Integer); +var gd, gm: CInteger; +begin + gd := GraphDriver; + gm := GraphMode; + dg (gd, gm); + GraphDriver := gd; + GraphMode := gm +end; + procedure ig(var gd, gm: CInteger; PathToDriver: CString); asmname 'initgraph'; procedure InitGraph(var GraphDriver, GraphMode: Integer; PathToDriver: CString); var gd, gm: CInteger; @@ -503,11 +514,29 @@ GetDriverName := CString2String (gdn) end; +procedure gar(var XAsp, YAsp: CInteger); asmname '__gr_getaspectratio'; +procedure GetAspectRatio(var XAsp, YAsp: Integer); +var xa, ya: CInteger; +begin + gar (xa, ya); + XAsp := xa; + YAsp := ya +end; + type pPT = ^PaletteType; function gdp: pPT; asmname '__gr_getdefaultpalette'; procedure GetDefaultPalette(var Palette: PaletteType); begin Palette := gdp^ +end; + +procedure gmr(GraphDriver:CInteger; var LoMode, HiMode:CInteger); asmname '__gr_getmoderange'; +procedure GetModeRange(GraphDriver:CInteger; var LoMode, HiMode:Integer); +var lm, hm: CInteger; +begin + gmr (GraphDriver, lm, hm); + LoMode := lm; + HiMode := hm end; function InstallUserDriver(const DriverName: String; AutoDetectPtr: Pointer):CInteger; --- grx246/pascal/jpgtest.pas.orig Tue May 27 21:19:46 2003 +++ grx246/pascal/jpgtest.pas Thu Sep 23 18:05:40 2004 @@ -29,7 +29,7 @@ grc : GrContextPtr; Width, Height : Integer; s : String[81]; - w, h : Integer; + w, h : CInteger; begin GrQueryJpeg( nf,w,h ); WriteStr( s,nf,' ',w,' ',h,' Scale 1/',Scale ); --- grx246/pascal/imgview.pas.orig Thu Sep 23 18:06:15 2004 +++ grx246/pascal/imgview.pas Thu Sep 23 18:06:33 2004 @@ -49,7 +49,8 @@ var ImgFileName: TString; - ArgStart, ArgN, ImgWidth, ImgHeight, Key: Integer; + ArgStart, ArgN, Key: Integer; + ImgWidth, ImgHeight: CInteger; grc: GrContextPtr; Centered: Boolean;

1 0

Re: Porting from Dec Pascal to GPC
by djwood1＠acedial.co.uk 05 Mar '05

05 Mar '05

I produced the attached document when converting a large DEC Pascal simulation to gpc (under Linux) some years ago. We can still run our code on both VMS and gpc. I think it should help get round most issues you may come across. It leaves a fair bit of manual editing but by adopting a conversion checklist, the manual process is straightforward.

3 2

Variant records (EP)
by Frank Heckenbach 05 Mar '05

05 Mar '05

A question to the EP experts? Is the following program valid EP, and if so, what should its output be? program Foo (Output); type i23 = 2 .. 3 value 2; a = record b: Integer value 1; case c: i23 of 2: (d: Integer value 4); 3: (e: Integer value 5) end value [b: 6; case c: 3 of [e: 7]]; var v: ^a; begin New (v, 2); WriteLn (v^.b, ' ', v^.c, ' ', v^.d) end. : 6.7.5.3 Dynamic allocation procedures : : The domainÂtype of the newÂpointerÂtype denoting the type possessed by p : shall contain a typeÂidentifier, which shall denote the recordÂtype, the : bindability, and except as otherwise noted below, the initial state of the : created variable. : : The caseÂconstant c 1 shall correspond to the variantÂpart of the : fieldÂlist of the recordÂtype. For 1 < i <= n, c i shall correspond to the : variantÂpart of the fieldÂlist of the variantÂdenoter denoting the variant : specified by c i Â1. For 1 <= i <= n, the variantÂpart corresponding to c i : shall closestÂcontain a tagÂtype. For 1 <= i <= n, the initial state of the : selector of the variant corresponding (see above) with the caseÂconstant c : i shall be the state bearing the value associated (see 6.4.3.4) with the : variant corresponding (see 6.4.3.4) to the value denoted by c i . : : It shall be an error if a variant of a variantÂpart within the new variable : is active and a different variant of the variantÂpart is one of the : specified variants. : : NOTE --- 1 Since the initial state of each selector is determined by the : corresponding caseÂconstant, any corresponding tagÂfield is also attributed : the value of the caseÂconstant (see 6.4.3.4). According to the first paragraph v^.b must be 6 IIUIC (i.e., the initial state of the record, not of the field, prevails). According to paragraphs 2 and 4, v^.c must be 2 which should be quite clear. But what about v^.d? AFAICS, paragraphs 2 and 4 don't state it, so according to the first paragraph, it would have the initial state it has in the type a. But in a, the second variant is active, so field d is undefined. Does this mean that indeed v^.d is undefined after `New' (despite specifying initial values wherever possible, i.e. *omitting* the initial state of a would result in v^.d being defined)? Or did I overlook some reason it is defined (in this case, presumably, as 4)? Or is this `New' statement invalid? If anything, paragraph 3 might be a reason, but AFAICS it's meant to forbid invalid combinations of selectors in nested variant records, and doesn't apply here. The more general question is whether the initial states of the components of a structured type can have any influence when the structured type itself has a `value' specification. (Since I don't see another way how they could.) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 3

Porting from Dec Pascal to GPC
by Angelo.Fumagalli＠alcatel.it 04 Mar '05

04 Mar '05

Hi, we are going to port thousand and thousand of Dec Pascal modules to GPC in order to migrate software from VMS to Linux platform. We know that here there are the maximum experts to ask for, so we would like to ask you wich is the better model to migrate Dec environment modules maintaining the structure in terms of files and references, without having to completely change the source code, without splitting the procedure declarations and moving them in the library implementation modules. Have you some documentation which describes how to porting from Dec pascal to GPC that you could supply us? A litte DEC Pascal environment example: 1. environmet file me.pas MODULE ME; procedure p1; extern; procedure p2; extern; ....... procedure pn; extern; END. 2. library module m1.pas .. mn.pas NOTE:: typically all library modules which implement global procedures defined in the environment file me.pas are in the following format: [INHERIT('me')] MODULE m1; [global] procedure p1; begin .... end; END. 3. Program module p.pas: [INHERIT('me')] PROGRAM P; begin p1; p2; ... pn; END. Modules migration to GPC (is this one the only possible migration?): 1. library modules m1.pas .. mn.pas module m1 interface; export m1 = all; procedure p1; forward; end. module m1 implementation; procedure p1; begin ... end; end. 2. program module p.pas program p; import lbbp1: lbbp2; ... lbbpn; begin p1; p2; ... pn; end. Otherwise, it's possible to have the same DEC Pascal file/module structure? I mean only one interface module (me.pas) which is imported/used in all library and Program modules? Thank you very much in advance for your help. Kind regards. Angelo Fumagalli

3 2

c library imports revisited
by Rick Engebretson 04 Mar '05

04 Mar '05

OK, I've updated gpc and begun to probe for "clarification." I'm glad an automated c-header translator is being discussed. The fpc people have such a tool and have translated libc. A terrific pascal development. One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts. For example using the fpc unit "libc"; the libc function "close()" takes a file descriptor parameter, while the native pascal "close()" takes a file type parameter. Thus, the fpc libc "close()" is singled out and renamed in "unistdh.inc" to "__close()". (if memory serves me) Perhaps such a naming confusion can be avoided with all libc imports being named libc_name(). A libc unit for pascal is a big departure from the dos world. Other c-libs like OpenGL, etc. will follow. I really don't care about ISO-this or ISO-that. Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.

2 3

Re: (Fwd) Re: Pascal front-end integration
by Frank Heckenbach 03 Mar '05

03 Mar '05

Joseph S. Myers wrote: > On Tue, 1 Mar 2005, Prof A Olowofoyeku (The African Chief) wrote: > > Instead of starting a totally separate project, wouldn't it be better > > to coordinate your efforts with the GPC development team? > > Effective coordination will require, for a start, the GPC mailing list > to accept messages from nonsubscribers. Sorry, that's not an option because of spam. Despite the spam filters in use, currently about 5 spams per day get through and are only rejected because of the nonsubscriber block. I don't know if the GCC list has effective spam protection -- I know that other GNU lists don't (e.g., the bison lists are just kicking me out because my own spam filter bounces spam they let through) ... I'd consider this the worse alternative, given that the gpc list is mostly used by gpc users and developers, and "cross" discussions such as this one are the exception. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

a little gpc (iwidgets) notebook
by Rick Engebretson 02 Mar '05

02 Mar '05

If anybody has Iwidgets 4, they might try this script. It's just a tabbed notebook with a few other widgets added (entry fields, disjoint listbox). The point is, pascal is an organized language, and a virtual notebook might help organize development. Certainly, text processing is yet to be added. Maybe the "diff debate" could be presented on a page. #!/bin/sh #\ exec wish "$0" package require Iwidgets 4.0 # ---------------------------------------------------------------------- # create tabnotebook # ---------------------------------------------------------------------- option add *textBackground white option add *Tabnotebook.backdrop DimGray option add *Scale.width 8 . configure -background white wm title . "T-pascal" iwidgets::tabnotebook .tnb \ -width 8i \ -height 10i \ -tabpos w \ -gap 10 \ -background seashell \ -font "helvetica 14" pack .tnb \ -expand yes \ -fill both \ -padx 4 -pady 4 # create Summary CoverPage # ---------------------------------------------------------------------- set page1 [.tnb add -label "Cover Page"] # put widgets in cover page frame $page1.filler1 \ -background "" \ -height 1i \ -width 5i pack $page1.filler1 \ -fill x iwidgets::entryfield $page1.unit_name \ -labeltext "Pascal Unit Name:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_name \ -pady 5 iwidgets::entryfield $page1.unit_info \ -labeltext "Pascal Unit Info:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_info \ -pady 5 iwidgets::entryfield $page1.unit_path \ -labeltext "Pascal Unit Path:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_path \ -pady 5 frame $page1.filler2 \ -background "" \ -height 1i \ -width 5i pack $page1.filler2 \ -fill x iwidgets::entryfield $page1.c_lib_name \ -labeltext "C Library Name:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_name \ -pady 5 iwidgets::entryfield $page1.c_lib_info \ -labeltext "C Library Info:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_info \ -pady 5 iwidgets::entryfield $page1.c_lib_path \ -labeltext "C Library Path:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_path \ -pady 5 frame $page1.filler3 \ -background "" \ -height 1i \ -width 5i pack $page1.filler3 \ -fill x iwidgets::entryfield $page1.author \ -labeltext "Author:" \ -labelpos nw \ -width 40 pack $page1.author iwidgets::entryfield $page1.author_email \ -labeltext "Author E-mail:" \ -labelpos nw \ -width 40 pack $page1.author_email frame $page1.filler4 \ -background "" \ -height 1i \ -width 5i pack $page1.filler4 \ -fill x # create more pages # ---------------------------------------------------------------------- set page2 [.tnb add -label "Compile Options"] iwidgets::disjointlistbox $page2.dlb pack $page2.dlb -padx 10 -pady 10 -fill both -expand yes $page2.dlb insertlhs {{1. DOS} {2. WINDOWS} {3. LINUX} {4. OSX} {5. SOLARIS} {6. IA32} {7. IA64} {8. M68X} {9. SPARC}} set page3 [.tnb add -label "Unit .inc Files"] # Unit Constants Page #4 # ---------------------------------------------------------------------- set page4 [.tnb add -label "Unit Constants"] iwidgets::scrolledtext $page4.scr_text \ -hscrollmode dynamic \ -vscrollmode dynamic pack $page4.scr_text \ -expand yes \ -fill both # Unit Types Page #5 # ---------------------------------------------------------------------- set page5 [.tnb add -label "Unit Types"] .tnb view "Cover Page" # End ---------------------------------------------------------------

1 1

20 month snapshot diffs
by James A. Morrison 02 Mar '05

02 Mar '05

Hi, I've posted[1] a diff between December's snapshot and February's snapshot. However, the diff 850K, that seems really large for only 4 changelog entries. Is that the size of the usual diff between patches? -- Thanks, Jim http://phython.blogspot.com [1] http://www.csclub.uwaterloo.ca/~ja2morri/gpc-20041218-20050217.diff.gz

3 4

Pascal front-end integration
by James A. Morrison 02 Mar '05

02 Mar '05

Hi, I've decided I'm going to try to take the time and cleanup and update the Pascal frontend for gcc and try it get it integrated into the upstream source. I'm doing this because I wouldn't like to see GPC work with GCC 4+. I don't care at all at supporting GPC on anything less than GCC 4.1 so I've started by ripping out as much obviously compatibility code as I can and removing any traces of GPC being a separate project. So far I have only accomplished converting lang-options.h to lang.opt. I'm going to continue cleaning up the GPC code, then once I am happy with how the code looks with respect to the rest of the GCC code, I'm going to get it to compile with the current version of GCC mainline. I'm starting with the boring conflict happy whitespace changes first so the code is easier for me to read and so that I can try to get an idea what the GPC frontend is doing. My current changes are available through bazaar (an arch implementation) which people can get with: baz register-archive http://www.csclub.uwaterloo.ca/~ja2morri/arch baz get phython(a)gcc.gnu.org--pascal/gcc-pascal--mainline--0.3 Once I get the front-end to compile I'll look into creating a branch on gcc.gnu.org, but until that point it really isn't worth while. Patches are welcome, but please have your copyright assignment filed with the FSF and add a changelog entry to ChangeLog.gcc. I don't have any timeline for this work. -- Thanks, Jim http://phython.blogspot.com

3 2

Internal compiler errors
by Adriaan van Os 01 Mar '05

01 Mar '05

An Internal compiler error has been reported on the macpascal mailing list, as reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo10.pas program avo10; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( [bold, italic]); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo10.pas ../../gcc-3.4.3/gcc/p/typecheck.c:123:incomplete_type_error: failed assertion `0' avo10.pas: In main program: avo10.pas:8: error: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc343d7/lib/gcc/powerpc-apple-darwin7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 Thread model: posix gpc version 20050217, based on gcc-3.4.3 Adding a typecast triggers another error: G5:gcc/p/test] adriaan% cat avo11.pas program avo11; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( StyleParameter( [bold, italic])); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo11.pas avo11.pas: In main program: avo11.pas:8: warning: cast to type of different size avo11.pas:8: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. with backtrace: Command: gpc1 Path: /Developer/Pascal/gpc343d7/libexec/gcc/powerpc-apple-darwin7/3.4.3/gpc1 Version: ??? (???) PID: 1333 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000038 Thread 0 Crashed: 0 gpc1 0x000c66d4 get_set_constructor_bits + 0x34 (tree.c:4654) 1 gpc1 0x000c693c get_set_constructor_bytes + 0x4c (tree.c:4730) 2 gpc1 0x000e4204 const_hash_1 + 0x3b4 (varasm.c:2130) 3 gpc1 0x002f773c htab_find_slot + 0x2c (hashtab.c:560) 4 gpc1 0x000e34c8 output_constant_def + 0x38 (varasm.c:2496) 5 gpc1 0x0007d6b0 expand_expr_real + 0x3c88 (expr.c:6910) 6 gpc1 0x0007d54c expand_expr_real + 0x3b24 (expr.c:8863) 7 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 8 gpc1 0x0007a620 expand_expr_real + 0xbf8 (expr.c:6952) 9 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 10 gpc1 0x00196ac8 expand_call + 0x2760 (calls.c:793) 11 gpc1 0x0007b6a0 expand_expr_real + 0x1c78 (expr.c:7595) 12 gpc1 0x000c9ff4 expand_expr_stmt_value + 0xe0 (stmt.c:2171) 13 gpc1 0x00007e5c yyuserAction + 0x4cd8 (parse.c:4691) 14 gpc1 0x000114cc main_yyparse + 0x738 (parse.c:8136) 15 gpc1 0x000be2ec toplev_main + 0x7b8 (toplev.c:1826) 16 gpc1 0x00001ed8 _start + 0x188 (crt.c:267) 17 dyld 0x8fe1a558 _dyld_start + 0x64 Regards, Adriaan van Os

4 8

where could I get latest patches for gpc
by Igor Marnat 28 Feb '05

28 Feb '05

Hi, List! Latest version of GPC has some bugs and there are some patches available already. Does there exists any url to get these patches (or the latest one, "cumulative")? Sometimes it's not very comfortly to search them in the mailing list. Am I missed something and such a place already exists at www.gnu-pascal.de? If no, it would be nice to have such a place nearby GPC release. Regards, Igor Marnat marny(a)rambler.ru

5 6

Variant record constants
by Frank Heckenbach 27 Feb '05

27 Feb '05

I noticed that GPC allows non-constants in variant record lists which neither EP nor BP support. As it would cause additional difficulties when fixing Emil's test program and perhaps elsewhere, and I can't see much use for it, the attached patch forbids it. program fjf1028a (Output); var a: Integer value 1; type t = record case Integer of a: (b: Integer) { WRONG } end; begin end. program fjf1028b (Output); type t (a: Integer) = record case Integer of a: (b: Integer) { WRONG } end; begin end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

warning: Operand with side-effects is not evaluated.
by Igor Marnat 25 Feb '05

25 Feb '05

Hello List! I've successfully built latest version with the same results of test suite like other people already have written. Range-checking is a really cool (great thanks to developers:))! It appears now new warning that I didn't see before (warning: Operand with side-effects is not evaluated). It isn't described in the documentation. It points to strings that look like: LocalVariable := GlobalVariable mod GlobalConst; Can I do something to avoid it? What does it mean? It means that the value evaluated will not be assigned to LocalVariable? Or it means that Global variable will not change its value as a result of this activity? Best regards, Igor Marnat mailto:marny@rambler.ru

2 1

Compile prob. with gpc20050217
by Wood David 25 Feb '05

25 Feb '05

I'm getting a new compile time error (error: arithmetical overflow ) with this previously ok bit of code: FOR I := -Clutter_max_width TO Clutter_max_width DO Spectral_purity[I] := Spec_purity_level / (1 + (SQR(I) / Width_sqrd)); Spectral_purity[0] := 1; All the variables and arrays use type double, except i which is an integer. The error is reported at the last code line, but I guess it may stem from the previous line. I don't understand why gpc should report an arithmetic overflow error at compile-time. This is normally a run-time error! Any ideas? Regards David Wood The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

2 1

Test results og gpc-20041218 with gcc-3.3.5 for DJGPP
by Andris Pavenis 25 Feb '05

25 Feb '05

Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04) gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005 ========================== GPC-TEST-END Additionally I had to patch test_run to avoid DJGPP port of bash crashing (both bash-2.0.4 from v2gnu and bash-2.0.5b): --- test_run~1 2005-02-17 22:54:30.000000000 +0000 +++ test_run 2005-02-17 20:12:44.000000000 +0000 @@ -296,7 +296,8 @@ echo "failed" fi fi - return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? +true +# return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? } n=0 It is perhaps a due to some problem with DJGPP port of bash. Andris

3 7

Bug report for gpc 20050217
by Wood David 25 Feb '05

25 Feb '05

Following on from my earlier runtime arithmetical error report, see attached code. It appears that gpc20050217 doesn't like the use of a constant index in an array assignment within a procedure. It's fine when the same assignment is done with a constant index in the main program. I'm running gpc20050217 (patched with gpc.diff-uc) under gcc.3.4.2 in FC3 Linux on a P4 processor. Regards David. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

3 2

Re: Compile prob. with gpc20050217
by Wood David 24 Feb '05

24 Feb '05

Apologies for the limited code detail earlier. It appears the offending bit is the use of a constant array index. Here is a short program which reproduces the bug: PROGRAM arr_test(input,output); TYPE arrtype = ARRAY [-10..10] OF double; VAR test : arrtype; PROCEDURE init(VAR arr: arrtype); VAR i : integer; BEGIN FOR i:= -10 TO 10 DO arr[i]:= i*2.0; i:= 0; arr[i]:= 1.0; { This is OK, using i for the index } arr[0]:= 1.0; { This causes an arithmetical error at compile time } END; BEGIN init(test); END. > -----Original Message----- > From: Waldek Hebisch [mailto:hebisch@math.uni.wroc.pl] > Sent: 19 February 2005 04:50 > To: Wood David > Subject: Re: Compile prob. with gpc20050217 > > > I'm getting a new compile time error (error: arithmetical overflow ) > with > > this previously ok bit of code: > > > > > > > > FOR I := -Clutter_max_width TO Clutter_max_width DO > > > > Spectral_purity[I] := Spec_purity_level / (1 + (SQR(I) / > > Width_sqrd)); > > > > > > > > Spectral_purity[0] := 1; > > > > > > > > All the variables and arrays use type double, except i which is an > integer. > > > > The error is reported at the last code line, but I guess it may stem > from > > the previous line. > > > > I don't understand why gpc should report an arithmetic overflow error at > > compile-time. This is normally a run-time error! > > > > That is too little detail to reproduce the problem. gpc computes many > constant expressions at compile-time and signals error in case of > overflow. So in particular values of your constants are crucial. > In general you should make sure that you give a _complete_ program > which reproduces the problem. > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

1 0

Re: gpc-20050217 failing this test
by Wood David 24 Feb '05

24 Feb '05

Thanks Frank. I can confirm that this patch (gpc.diff-uc) fixed the out of range error. David. > -----Original Message----- > From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de <mailto:gpc-owner@gnu.de> ] On Behalf Of Frank > Heckenbach > Sent: 22 February 2005 15:59 > To: gpc(a)gnu.de > Subject: Re: gpc-20050217 failing this test > > Wood David wrote: > > > Here is a very short program which now fails with a value out of range > > error: > > I don't get a failure, but since the type size is near 128 KB, this > looks like the bug found by Emil Jerabek. You might want to try my > patch (gpc.diff-uc). You'll need to rebuild the RTS after applying > it. > > Frank The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

1 0

where could I get latest patches for gpc
by Igor Marnat 24 Feb '05

24 Feb '05

Hi, List! Latest version of GPC has some bugs and there are some patches available already. Does there exists any url to get these patches (or the latest one, "cumulative")? Sometimes it's not very comfortly to search them in the mailing list. Am I missed something and such a place already exists at www.gnu-pascal.de? If no, it would be nice to have such a place nearby GPC release. Regards, Igor Marnat marny(a)rambler.ru

1 0

Building on Mac OS X
by Adriaan van Os 24 Feb '05

24 Feb '05

Frank Heckenbach wrote: > - Bison (building GPC) > > Bison version 2.0 has been released. It can be obtained at > <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz>. This is now the > recommended version for all GPC compilations. Fortunately, we now > don't depend on changing alpha/beta versions of bison anymore. > Bison is required when building a minimal distribution of GPC > (which now doesn't include the Bison generated files anymore, as > it did temporarily); when building a full source distribution and > not modifying the bison input files (*.y), bison is not strictly > needed, but in case of doubt, it can't hurt to install the new > bison version. I am adding a few notes about building on Mac OS X. The following tools may be needed: - bison 2.0 a too old version is installed with XCode or OS X <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz> - sed 4.0.x a too old version is installed with XCode or OS X (I use 4.0.5, but I assume later versions work also) <ftp://ftp.gnu.org/gnu/sed/> - flex 2.5.27 a too old version is installed with XCode or OS X <http://sourceforge.net/project/showfiles.php?group_id=72099> - help2man 1.35 not installed with XCode or OS X <ftp://ftp.gnu.org/gnu/help2man/help2man-1.35.1.tar.gz> Configure these tools with --prefix=/usr, configure help2man with --prefix=/usr --enable-nls=no There is a bug in Mac OS X that causes problems when configuring flex and other tools (see e.g.<http://lists.gnu.org/archive/html/bug-coreutils/2004-08/ msg00039.html>). The system call sysctl ((int[]) {CTL_HW, HW_MACHINE_ARCH}, 2, buffer, &bufsize, 0, 0) returns a negative number, which causes the coreutils command "uname -p" to report "unknown". This confuses config.guess. To solve the flex configure problem, apply the following patch to the flex 2.5.27 sources: --- config.guess.orig Fri Feb 18 21:22:32 2005 +++ config.guess Fri Feb 18 21:25:28 2005 @@ -1098,7 +1098,7 @@ EOF echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE} exit 0 ;; *:Darwin:*:*) - echo `uname -p`-apple-darwin${UNAME_RELEASE} + echo powerpc-apple-darwin${UNAME_RELEASE} exit 0 ;; *:procnto*:*:* | *:QNX:[0123456789]*:*) UNAME_PROCESSOR=`uname -p` WIth the right tools in place, build the gpc compiler with "make bootstrap" instead of "make". This is necessary because of peculiarities of the apple-gcc system compiler. The alternative is to bootstrap an fsf-gcc compiler on your system first and then use that fsf-gcc compiler for successive builds of gpc (and other gnu packages). Then, successive builds will be faster, because a bootstrap is not needed. Regards, Adriaan van Os

8 20

gpc-20050217 failing this test
by Wood David 22 Feb '05

22 Feb '05

Here is a very short program which now fails with a value out of range error: PROGRAM dyn_arr_test(input,output); TYPE Dyn_arr2( Max_index1, Max_index2 : INTEGER ) = ARRAY [1..Max_index1, 1..Max_index2] OF single; Ptr_to_dyn_arr2 = ^Dyn_arr2; VAR test2 : Ptr_to_dyn_arr2; BEGIN new(test2, 181, 181); writeln('This works'); new(test2, 182, 182); writeln('This works'); new(test2, 183, 183); writeln('This fails'); dispose(test2); END. Turning off range-checking doesn't seem to work! $ gpc --no-range-checking -o dyn_arr_test dyn_arr_test.pas I'm aware there are problems in this area. I hope this helps. I'm using gpc-20050217 with gcc-3.4.2 under Fedora Core 3. Regards David Wood The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

3 2

How to patch (was: Cannot compile gpc-20041218 on MinGW/Windows 2000)
by Markus Gerwinski 21 Feb '05

21 Feb '05

Jan Ruzicka wrote: > b) there can be a problem with the line endings (CRLF vs CR / LF). > The file gcc.c on your system may have different line endings then the > used patch file. > The difference in line endings may prevent patch from matching the > surrounding blocks of code. > (dos2unix is your friend) The patch file really contained ^Ms. However, removing them didn't change things. I also doubt it has anything to do with the paths. What I did was this: - file to change: $MYPATH/gcc-3.2.3/gcc/gcc.c - path in the patch file: gcc/gcc/gcc.c So I did `cd $MYPATH/gcc-3.2.3' and then `patch -p1 < ../gcc.c.patch'. That should have done the trick, shouldn't it? Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 2

Re: GPC ALPHA 20050217 released
by Waldek Hebisch 21 Feb '05

21 Feb '05

I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix. In principle other platforms may be affected -- in particular the problem on Mac OSX looks related. diff -u p.orig/expressions.c p/expressions.c --- p.orig/expressions.c 2005-02-16 04:38:36.000000000 +0100 +++ p/expressions.c 2005-02-19 05:17:58.200156608 +0100 @@ -259,20 +259,23 @@ { tree cond, t; int side_effects = TREE_SIDE_EFFECTS (expr); - expr = save_expr (expr); - if (TREE_CODE (expr) == SAVE_EXPR) - TREE_SIDE_EFFECTS (expr) = side_effects; - cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, expr, min) : NULL_TREE; + tree tmpvar = make_new_variable("range_check", TREE_TYPE (expr)); + tree tv; + cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, tmpvar, min) : NULL_TREE; if (chkhi) { - tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, expr, max); + tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, tmpvar, max); cond = cond ? build_pascal_binary_op (TRUTH_ORIF_EXPR, cond, cond2) : cond2; } - t = save_expr (build (COND_EXPR, TREE_TYPE (expr), cond, build (COMPOUND_EXPR, - TREE_TYPE (expr), build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, - NULL_TREE), expr), expr)); - if (TREE_CODE (t) == SAVE_EXPR) - TREE_SIDE_EFFECTS (t) = side_effects; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), + build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, + NULL_TREE), tmpvar); + t = build (COND_EXPR, TREE_TYPE (expr), cond, t, tmpvar); + tv = build (MODIFY_EXPR, TREE_TYPE (expr), tmpvar, expr); + PASCAL_VALUE_ASSIGNED (tmpvar) = 1; + TREE_SIDE_EFFECTS (tv) = 1; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), tv, t); + TREE_SIDE_EFFECTS (t) = side_effects; return t; } } -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 12

Solved: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 21 Feb '05

21 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > > BTW: you *are* using Mingw "special" gcc sources, aren't you? > > Where can I get them? > http://prdownloads.sourceforge.net/mingw/ #-) Thank you a lot of a lot, Chief! That was it. Best, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: warning: Operand with side-effects is not evaluated.
by Igor Marnat 21 Feb '05

21 Feb '05

Hello Frank, FH> The warning is probably wrong. I hope we can fix it soon. (I'm aware Thank you for the infiormation, Regards, Igor mailto:marny@rambler.ru

1 0

GPC ALPHA 20050217 and Mingw
by Prof A Olowofoyeku (The African Chief) 20 Feb '05

20 Feb '05

> On 20 Feb 2005 at 5:38, Waldek Hebisch wrote: [...] > > Note2: The `gpc.c' file is substantially changed. It is now more > > similar to `gcc.c' from gcc-3.4.3 then to old `gpc.c'. So it may > > trigger bugs in the C compiler used to bootstrap. In which case, gcc-3.4.3 should also fail to compile. I have just built gcc-3.4.3 successfully. Also, reverting back to mingw runtime 1.x (2001) makes absolutely no difference. Neither does the gcc version used for building (I have tried 3.3.3., 3.4.2 and 3.4.3). Trying to build this snapshot with gcc-3.4.3 sources yields this error: make[1]: Entering directory `/src/gcc-3.4.3/build/libiberty' make[2]: Entering directory `/src/gcc-3.4.3/build/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/src/gcc-3.4.3/build/libiberty/testsuite' make[1]: Leaving directory `/src/gcc-3.4.3/build/libiberty' make[1]: Entering directory `/src/gcc-3.4.3/build/intl' make[1]: Leaving directory `/src/gcc-3.4.3/build/intl' Bootstrapping the compiler make[1]: Entering directory `/src/gcc-3.4.3/build/gcc' make CC="gcc.exe" libdir=/mingw/lib LANGUAGES="c " \ CFLAGS="-g " MAKEINFO="makeinfo --split-size=5000000" \ MAKEINFOFLAGS="" COVERAGE_FLAGS= \ OBJS-onestep="alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgloopanal.o cfgloopmanip.o loop-init.o loop-unswitch.o loop-unroll.o cfgrtl.o combine.o conflict.o convert.o coverage.o cse.o cselib.o dbxout.o debug.o df.o diagnostic.o dojump.o doloop.o dominance.o dwarf2asm.o dwarf2out.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o haifa-sched.o hooks.o ifcvt.o insn- attrtab.o insn-emit.o insn-modes.o insn-extract.o insn-opinit.o insn- output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o loop.o optabs.o options.o opts.o params.o postreload.o predict.o print-rtl.o print-tree.o value- prof.o profile.o ra.o ra-build.o ra-colorize.o ra-debug.o ra-rewrite.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o sreal.o stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o tracer.o tree.o tree-dump.o unroll.o varasm.o varray.o version.o vmsdbgout.o xcoffout.o alloc-pool.o et-forest.o cfghooks.o bt-load.o pretty-print.o ggc-page.o web.o i386.o winnt.o host-default.o hashtable.o tree-inline.o tree-optimize.o cgraph.o cgraphunit.o" make[2]: Entering directory `/src/gcc-3.4.3/build/gcc' make \ CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long " \ CONFIG_H="tconfig.h ../../gcc/../include/ansidecl.h ../../gcc/config/i386/xm-mingw32.h" TM_H="tm.h ../../gcc/config/i386/i386.h ../../gcc/config/i386/unix.h ../../gcc/config/i386/bsd.h ../../gcc/config/i386/gas.h ../../gcc/config/dbxcoff.h ../../gcc/config/i386/cygming.h ../../gcc/config/i386/mingw32.h ../../gcc/defaults.h insn-constants.h insn-flags.h" \ INCLUDES="-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include - I../intl" \ MAKEOVERRIDES= \ -f libgcc.mk all make[3]: Entering directory `/src/gcc-3.4.3/build/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh ../../gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi make[3]: Leaving directory `/src/gcc-3.4.3/build/gcc' gcc.exe -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes - Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -o Tcollect2.exe \ collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a ../intl/libintl.a collect2.o(.text+0x2ef): In function `handler': d:/src/gcc-3.4.3/build/gcc/../../gcc/collect2.c:427: undefined reference to `kill' collect2.o(.text+0x2c7f): In function `scan_prog_file': d:/src/gcc-3.4.3/build/gcc/../../gcc/collect2.c:2016: undefined reference to `pipe' collect2.o(.text+0x2d56):d:/src/gcc- 3.4.3/build/gcc/../../gcc/collect2.c:2039: undefined reference to `fork' make[2]: *** [collect2.exe] Error 1 make[2]: Leaving directory `/src/gcc-3.4.3/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/src/gcc-3.4.3/build/gcc' make: *** [bootstrap-lean] Error 2 Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

Re: GPC ALPHA 20050217 released
by Prof A Olowofoyeku (The African Chief) 20 Feb '05

20 Feb '05

On 20 Feb 2005 at 5:38, Waldek Hebisch wrote: > Prof A Olowofoyeku wrote: > > Unfortunately, this snapshot has serious problems under Windows > > (Mingw). xgpc.exe crashes with a GPF every time it is called. I have > > tried building it on different PCs, and I have tried different gcc > > backend sources - same result :-( > > > > FYI, I have just built 20050217-based Mingw32 compiler. I did this > using cross-compiler from Linux to Mingw32 to cross-compile native > Mingw32 compiler. I have no Windows for real test but the resulting > compiler runs under wine and I am able run (again under wine) > resulting executables (well, at least "Hello World"). > > Note: I used stock 3.2.3 sources. I have also tried this. No difference ... > Also, I used old 3.1.1 cross-compiler, mingw-runtime-19991107 and > binutils 2.13.1. These are very old (indeed, that version of the mingw-runtime is virtually obsolete). But the story might be with the Mingw runtime. The struggle continues ... Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

Re: Update for Mac OS X
by Adriaan van Os 19 Feb '05

19 Feb '05

steven.borley wrote: > Adriaan, > > I posted this (see below) to the gpc list yesterday, but it never > appeared (I don't know why), so my apologies for the direct approach. > > I was hoping you could help my in using the MacOSX update. It looks > like I have a linker problem. Possibly because you've used XCode v2.0 > tools in generating the library files?? No -- and there is no such thing like "XCode v2.0 tools". Apple's marketing department acts as if it invented the "gcc" compiler, the "as" assembler and the "ld" linker as part of XCode, but that is far from the truth. Apple's gcc compiler and as assembler are hacked versions of software of the Free Software Foundation (<http://www.gnu.org/>). And ... you must sign a non-disclosure agreement to use them, since they are part of "Tiger" - very amusing. > Is there any way around this other than recompiling from source > myself? I don't wish to use the cctools you've supplied for fear > they'll break my v1.5 XCode Tools installation. To the best of my knowledge they won't (and you can always reinstall the so-called XCode tools). > Any suggestions? Maybe I used a "too new" assembler and linker to build the binaries ? Has someone else experienced the same problem ? Did installing the latest cctools from my website solve the problem ? > Regards, > Steven > > Begin forwarded message: > >> From: steven.borley <steven.borley(a)virgin.net> >> Date: 15 February 2005 18:56:56 GMT >> To: gpc(a)gnu.de >> Subject: Re: Update for Mac OS X >> >> Adriaan, >> >> Thank you for the Mac OS X update. >> >> However, I'm having problems using it. >> >> I have upgraded from gpc332d1 to gpc343d6, upgraded GPC Interfaces to >> 1.07 (from D to E) from the microbizz site. I did not take the >> cctools as I reasoned that I have the most up-to-date version already >> from Apple (November 2004 gcc 3.3 Updater). Obviously not (see below). >> Trying to compile my simple Hello World program I get... >> >> [mirror-doors:~/src/pascal/hello] steven% gpc hello.pas >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgpc.a(error.o) r_type field of relocation entry 709 in section >> (__TEXT,__text) invalid >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgpc.a(error.o) stray relocation PPC_RELOC_PAIR entry (710) in >> section (__TEXT,__text) >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgpc.a(error.o) r_type field of relocation entry 711 in section >> (__TEXT,__text) invalid >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgpc.a(error.o) stray relocation PPC_RELOC_PAIR entry (712) in >> section (__TEXT,__text) >> >> [...snip... another 300 lines or so...] >> >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgcc.a(_moddi3.o) r_type field of relocation entry 0 in section >> (__TEXT,__eh_frame) invalid >> /usr/bin/ld: >> /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/ >> libgcc.a(_moddi3.o) stray relocation PPC_RELOC_PAIR entry (1) in >> section (__TEXT,__eh_frame) >> collect2: ld returned 1 exit status >> >> What am I doing wrong? >> >> Is this because the cctools on microbizz are actually newer than the >> official Apple release (i.e. not-pre-release). If so what do these >> newer tools do for me? I was reluctant to upgrade as Pascal is only a >> small part of my compiling work and I could find no release notes or >> mention of this update on the Apple Developer Connect site. Also, if >> these tools are from XCode 2.0 pre-release, will they break my XCode >> v1.5 installation? >> >> More info: >> >> Max OSX 10.3.8 >> >> XCode Tools v1.5 >> >> [mirror-doors:~/src/pascal/hello] steven% ld -v >> Apple Computer, Inc. version cctools-525.1.obj~8 Ah, that version is much older than the "Apple Computer, Inc. version cctools-528.5~obj" on my website. >> hello.pas contains >> program hello; >> var >> i : integer; >> begin >> for i := 1 to 5 do >> writeln('Hello, World!'); >> end. >> >> Regards, >> Steven Regards, Adriaan van Os

2 3

Update for Mac OS X
by Adriaan van Os 18 Feb '05

18 Feb '05

The gpc compiler for Mac OS X, available from <http://www.microbizz.nl/gpc.html>, has been updated. The distribution is based on gcc-3.4.3, gpc-20041218 and Waldek's patches. The downloads include separate packages for: • an installer for the compiler's binaries (for Mac OS X 10.3 and later) • sources, patches and building instructions (for Mac OS X 10.2 and later) • an updated Mac OS X assembler, linker and utilities (cctools-528.5) • updated Mac OS X Pascal Interfaces (version 1.0.7) Regards, Adriaan van Os

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 18 Feb '05

18 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > BTW: you *are* using Mingw "special" gcc sources, aren't you? Um... no? I didn't even know there are any. Up to now, compiling worked fine every time with the "normal" sources. Where can I get them? Best, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 16 Feb '05

16 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > > What is the output of "gcc -print-file-name=libmingwex.a"? > > C:\MinGW\lib\libmingwex.a. > > What now? > Your problem is baffling. The library can be found by the compiler, > and you shouldn't even need os-hacks.h. I am unable to reproduce the > problem, even with a freshly downloaded and installed Mingw release. > Perhaps you should try manually adding "-lmingwex" to the command > line ... I wasn't quite sure where in the Makefile to add it. My first shot was writing it into the needed-options file: make[1]: Entering directory `/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/utils' ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g --executable-path=. --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" ../../libgpc.a(rts.o)(.text+0x180d): In function `p_CStringReadDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1546: undefined reference to `readdir' ../../libgpc.a(rts.o)(.text+0x17f1): In function `p_CStringOpenDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1541: undefined reference to `opendir' ../../libgpc.a(rts.o)(.text+0x183c): In function `p_CStringCloseDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1552: undefined reference to `closedir' ... but without any effect. Best, Markus, off to Brussels, protesting against software patents __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 16 Feb '05

16 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1552: > > undefined reference to `closedir' make[2]: *** [binobj.exe] Error 1 > > make[1]: *** [pascal.utils] Error 2 make: *** [all-gcc] Error 2 > I remember seeing this problem before. You're nearly there :) :-) > The problem (IIRC) is solved either by having os-hacks.h > (http://www.gnu-pascal.de/contrib/chief/win32/os-hacks.h) in your > "/mingw/include" directory when configuring and building the > compiler, Well, that didn't work so far... I downloaded the file into C:\MinGW\include and ran "make clean", "make distclean" on my gcc distribution before starting again with "./configure --enable-languages=pascal". I ended up with the same error message. > or (more likely), in having libmingwex.a linked to your > program. This however should be happening automatically (i.e., > linking libmingwex.a). > > What is the output of "gcc -print-file-name=libmingwex.a"? C:\MinGW\lib\libmingwex.a. What now? Best, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 16 Feb '05

16 Feb '05

Adriaan van Os wrote: > Markus Gerwinski wrote: > > Thanks! Something seems wrong, however. Calling > > patch -p1 < ../gcc.c.patch > Did you try patch -p0 < ... ? I did. It didn't work either. However, I applied the patch manually now, and that worked. (See parallel mail.) ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Bug in function parsing?
by Markus Gerwinski 15 Feb '05

15 Feb '05

CBFalconer wrote: > Markus Gerwinski wrote: > > Of course, you also can do so by explicitly declaring `result`as a > > local variable and assigning it to getIndexOf in the end, but > > personally, I find the above way far more elegant. > Which, to me, means there are no new capabilities introduced by > this usage. I find the local variable and final assignment to be > much clearer and more elegant. All result has done is provide a > synonym for the function name, whose use in an expression will not > trigger recursion. Exactly. My issue here isn't about capability, but about readability. I usually try chosing my function names in a manner that you can use them just like verbs in normal talking. Using them as a noun when passing themselves as their own result always gave me a strange feeling, even back when I started my first steps in BP. Besides, since it can always happen that you run into that recursion at some point, I used to always declare the function's return value as a local variable whenever the function was bigger than a one-liner, even in my old BP days. This may be a matter of taste, but I was really happy when GPC gained the ability to declare them in the function implementation's header, and I'd be really, really sad to lose it again. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 3

cast increases required alignment of target type
by Adriaan van Os 15 Feb '05

15 Feb '05

Consider the followig test program: program TestCast; type BytePtr = ^Byte; IntPtr = ^Integer; var theBytePtr : BytePtr; theIntPtr: IntPtr; begin theBytePtr := nil; theIntPtr:= nil; theIntPtr:= IntPtr( theBytePtr); {testcast.pas:11: warning: cast increases required alignment of target type} BytePtr( theIntPtr) := theBytePtr; theBytePtr:= BytePtr( theIntPtr); IntPtr( theBytePtr):= theIntPtr; {testcast.pas:14: warning: cast increases required alignment of target type} end. 1. Compiling with gpc produces two warnings as indicated in the comment. The compiler warns if the "casting" pointer type (outside the parenthesis) points to a larger type than the "casted" pointer type (inside the parenthesis). Gale Paper brought to my attention that the same holds on the left side of an assignment and I am inclined to regard this as a bug - the compiler should check here for a smaller type, rather than a larger type. 2. the -Wcast-align and -Wno-cast-align command-line switches don't seem to work with gpc. Regards, Adriaan van Os

2 5

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 15 Feb '05

15 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > Differences in the sources. You might try to make the changes > manually, or someone who knows more about patch and stuff may be able > to explain the differences. Okay, I manually applied the changes now, and I'm back to the linker problems: make[2]: Entering directory `/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/utils' ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" ../../libgpc.a(rts.o)(.text+0xfdd): In function `p_CStringReadDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1546: undefined reference to `readdir' ../../libgpc.a(rts.o)(.text+0xfc1): In function `p_CStringOpenDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1541: undefined reference to `opendir' ../../libgpc.a(rts.o)(.text+0x100c): In function `p_CStringCloseDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1552: undefined reference to `closedir' make[2]: *** [binobj.exe] Error 1 make[1]: *** [pascal.utils] Error 2 make: *** [all-gcc] Error 2 I have /mingw/lib in my LIBRARY_PATH and LD_LIBRARY_PATH. What could prevent gcc from finding the libs? ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 15 Feb '05

15 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > This is an old gcc bug that has been fixed in later versions. The > attached patch should solve that problem. Thanks! Something seems wrong, however. Calling patch -p1 < ../gcc.c.patch from my gcc distribution directory leads to an error message: patching file `gcc/gcc.c' Hunk #1 FAILED at 328. Hunk #2 FAILED at 3050. Hunk #3 FAILED at 3279. Hunk #4 FAILED at 5917. 4 out of 4 hunks FAILED -- saving rejects to gcc/gcc.c.rej I don't quite understand the gcc.c.rej... it's attached. Can you tell me what I did wrong here? Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 2

gpc-20041017 released
by Frank Heckenbach 15 Feb '05

15 Feb '05

I have uploaded a new beta version of GPC to <http://www.g-n-u.de/gpc/>! Because our main server is still out of order, please note: - The new URL, as stated above. www.gnu-pascal.de still doesn't work. - There are just the "bare bones" files (full and minimal source distribution, binaries for Linux/IA32 with and without gcc). No diffs, no separate test files, no HTML pages etc. - The main directory in the full source distribution is probably different! Be careful with automatic build scripts. - The releases are signed with a new OpenPGP key. The fingerprint is given in my signature in this mail and my other mails to the gpc(a)gnu.de list for some weeks. When the main server is back again, I'll do the usual release procedures there. One major change is that the types `Integer', `Word', `Cardinal' are now equivalent to `PtrInt', `PtrWord', `PtrCard', no more (necessarily) to C's `int' and `unsigned int' types. New types `CInteger', `CWord', `CCardinal' are provided for the latter purpose. This affects C interfaces in particular. A "porting guide" is given below. If you maintain any such interfaces, be sure to read it carefully. Another major improvement is in the area of initializers, thanks to Waldek Hebisch. GPC now allows initialization of variant records (fjf259.pas, peter6.pas) and packed arrays (emil5.pas) and supports Extended Pascal's structured initializers (fjf964*.pas, fjf967*.pas, fjf968*.pas) as well as record, array and set values (constdef.pas, fjf966*.pas, fjf971*.pas). Unfortunately, we don't have very many test programs for these new features yet. If you can send us some (according to the guidelines described in the manual), this will be very welcome. Other new features: * `Discard' * new make variable `GPC_PAGESIZE' to set the page size when building the manual (PDF, PostScript, DVI) * `qualified' and import lists are no more allowed after `uses' (only after `import', as EP demands) (@) * the `GMP' unit doesn't support gmp-2.x anymore (if you used it, just upgrade to a newer GMP version) (@) * conflicts between object fields/methods and ancestor type names are detected as required by OOE (fjf945*.pas) (@) (O) * repeated function headings (in `forward' declarations and interfaces) are checked stricter: if one has a result variable, so must the other (according to the OOE draft) (@) (O) Bugfixes: * records with no fields are invalid according to EP (fjf972.pas) * `Index' and `Pos' cannot be used in constant expressions (fjf970*.pas) * the `__FILE__' and `__BASE_FILE__' macros should return full paths * `Sqr' sometimes evaluates its argument twice (fjf963.pas) * memory leak in routines with a local variable of file type that are left via `Exit' or `Return' (fjf962.pas) * using a Boolean function as a condition in a `repeat' loop doesn't work correctly (artur1*.pas) * overstrict type-checking in comparisons involving procedural types (fjf960*.pas) * `Read', `Write' etc. evaluate its arguments in the wrong order (az43*.pas) * `Read' etc. evaluate references to string parameters twice (fjf958.pas) * on targets with 16 bit `Integer' type, the `MicroSecond' field of `TimeStamp' causes a compilation error * character arrays indexed by non-integer ordinal types treated as strings cause internal compiler errors (fjf957*.pas) * `-W[no-]cast-align' does not work (fjf956*.pas) * in `FormatTime' `%Z' and `%z' unless provided by system library ignore DST * powerpc: `--strength-reduce' doesn't work with `for' loops (was kludged before, fixed in gcc-3.3.3) * AIX: `ReturnAddress' doesn't work after use of dynmamic variables (backend bug, fixed in gcc-3.3.3) * functions returning sets are called twice if range-checking is on (inga1*.pas) PORTING GUIDE FOR THE NEW C COMPATIBLE INTEGER TYPES ==================================================== In my experience, the transition goes as follows: 1. If you want your code to keep working with older GPC versions after this change, add (near the top) the following part. You can omit the types you will not need in the following. {$if __GPC_RELEASE__ < 20041017} type CInteger = Integer; CCardinal = Cardinal; CWord = Word; {$endif} 2. In all C-visible declarations, replace `Integer' with `CInteger' and `Cardinal'/`Word' with `CCardinal'/`CWord'. C-visible declarations are usually `external' declarations (routines and/or variables) in Pascal which are implemented in C, but they can also be Pascal-implemented declarations (usually with a `name' attribute) which are declared `extern' in C code. Do not forget structures that are used within such declarations, e.g. parameters of type [pointer to] a record, or procedural parameters, etc. The same goes for other languages such as C++. 3. Fix any resulting incompatibilites. (This is the nasty part.) Value parameters are usually no problem. Anything else might be a problem, e.g., reference parameters, variables, structure fields, procedural parameters' parameters (including value parameters). As long as they are used only in the implementation of a unit/module which exports a Pascal interface, necessary changes can be confined to and handled within this interfaec. Otherwise, you have the choice whether to change the interface, which will require further changes in code using the interface, or to add wrappers to keep the interface. Example: unit MyCInterface; interface uses GPC; type t = record x, y, z: Integer end; procedure a (n: Integer); external name 'a'; procedure b (var n: Integer); external name 'b'; procedure c (var r: t); external name 'c'; function d (var n: Integer): TString; implementation function cd (var n: Integer): CString; external name 'd'; function d (var n: Integer): TString; begin d := CString2String (cd (n)) end; end. Changing a to procedure a (n: CInteger); external name 'a'; is usually harmless. Changing b to procedure b (var n: CInteger); external name 'b'; is problematic, since all callers would need to change their types (which might cause further ramifications in indirectly dependent code). So it might be in order to add a wrapper, such as: procedure b (var n: Integer); [implementation] procedure cb (var n: CInteger); external name 'b'; procedure b (var n: Integer); var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } cb (n); n := cn end; Procedure c uses a record containing `Integer' fields. Here, it's a hard choice between adding a wrapper (might be expensive, as the record gets bigger, and if more routines are affected) or changing the record to: type t = record x, y, z: CInteger end; The choice might depend on how many other routines use this structure and how many of them are written in Pascal or C, and how much existing code already uses the structure and what it does with it. Function d already has a wrapper, so it's usually best to also take care of the new change there: function d (var n: Integer): TString; var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } d := CString2String (cd (n)) n := cn end; Finally, note that `Integer' might be bigger than `CInteger', especially on newer platforms (that's the reason for the whole change in the first place). So if you want to have a bigger range available, you might want to consider changing from `CInteger' etc. (`[unsigned] int' in C) to `MedInt' etc. (`[unsigned] long' in C). This, however, requires (possibly substantial) changes in the C code, and might be out of your control (when interfacing to 3rd party libraries). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

9 23

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 14 Feb '05

14 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > As you can see, "d:/mingw/lib/" and "/mingw/lib/" appear in this. They > should have appeared in Markus's list as well. So, I think all points > to a broken installation (either gcc, or Mingw, or MSYS). Okay, I tried with a complete re-install of my MinGW now, and things keep getting weirder. I'm getting the following error message: ./gcc.c: In function `process_command': ./gcc.c:3735: error: assignment of read-only location ./gcc.c:3737: error: assignment of read-only location ./gcc.c: In function `fatal': ./gcc.c:6404: warning: traditional C rejects ISO C style function definitions ./gcc.c: In function `error': ./gcc.c:6418: warning: traditional C rejects ISO C style function definitions ./gcc.c: In function `notice': ./gcc.c:6431: warning: traditional C rejects ISO C style function definitions make[1]: *** [gcc.o] Error 1 make: *** [all-gcc] Error 2 ... so there's now a syntax error within gcc itself. I also tried without --enable-language=pascal, same result. My system now consists of: - MinGW 3.2.0 - MSys 1.0.10 - gcc 3.4.2 (came with the MinGW) What now? Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

the magics of eof()
by Francesco Bonomi 13 Feb '05

13 Feb '05

Dear friends, I don't know if what I found is a bug or a correct behaviour I don't understand. The following program halts with error 'attempt ro read past end of file'; program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); f^:='x'; (*GIVES ERROR HERE*) put(f); close(f); end. If I just insert a call reading eof(f) everything seems to work: program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); if eof(f) then ; (* do nothing *) f^:='x'; put(f); close(f); end. I am puzzled! (working with gpc 20030830) Ciao, Francesco

4 8

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 11 Feb '05

11 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > > Is crt2.o anywhere in the Mingw directory tree? It should be in > > > /mingw/lib. > > It's right there. I've set LIBRARY_PATH and LD_LIBRARY_PATH both to > > point there. > Then it appears that you have a broken compiler. What is the output > of "gcc -print-search-dirs"? install: /mingw/lib/gcc-lib/mingw32/3.2.3/ programs: =C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/;/usr/lib/gcc/mingw32/3.2.3/;/usr/lib/gcc/mingw32/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/ libraries: =C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/usr/lib/gcc/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../;/lib/mingw32/3.2.3/;/lib/;/usr/lib/mingw32/3.2.3/;/usr/lib/ ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

4 3

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 11 Feb '05

11 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > Is crt2.o anywhere in the Mingw directory tree? It should be in > /mingw/lib. It's right there. I've set LIBRARY_PATH and LD_LIBRARY_PATH both to point there. Any suggestions for other environment variables I should set, maybe...? > Perhaps you should download the latest release of the Mingw runtime > from here: > http://prdownloads.sourceforge.net/mingw/?sort_by=date&sort=desc > > The actual file that you want is this: > http://prdownloads.sourceforge.net/mingw/mingw-runtime-3.7.tar.gz I'll give it a shot... Best, Markus ____________________________________________________________________ Valentinsgeschenke online einkaufen, WEB.Cent sammeln und bei ueber 300 Partnern ausgeben! http://webcentsammeln.web.de/?mc=021303

2 1

-mpowerpc64
by Adriaan van Os 11 Feb '05

11 Feb '05

Out of curiosity, I tried the testsuite with -mpowerpc64. This switch optimizes 32-bit software to use features of the 64-bit G5 powerpc chip. From the results, it looks like the back-end still needs patching before this is fully reliable (e.g. <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16026>), The test results are given below (edited somewhat for brevity). Regards, Adriaan van Os Test Run By adriaan on 2005-02-11 12:08:44 Native configuration is powerpc-apple-darwin (G5.local) gpc 20041218, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused -mpowerpc64 -mtune=G5 --longjmp-all-nonlocal-labels TEST asmnames.pas: TEST complex1.pas: failed TEST complex2.pas: failed TEST complex3.pas: failed TEST emil27d.pas: failed TEST emil3.pas: failed 5.305117410771514e-315 1.410356248685543e-314 TEST emil8.pas: failed 1 5.311465294646354e-315 0.000000000000000e+00 5.000000000000000e+00 0.000000000000000e+00 failed 2 5.323445556527719e-315 0.000000000000000e+00 2.500000000000000e+01 0.000000000000000e+00 ... TEST emil9.pas: ./emil9.pas: In main program: ./emil9.pas:113: error: insn does not satisfy its constraints: (insn/i:HI 4601 4600 4602 0 ./emil9.pas:25 (set (reg:SI 4 r4 [ X ]) (mem/f:SI (plus:SI (lo_sum:SI (reg:SI 29 r29 [2560]) (const:SI (minus:SI (symbol_ref:SI ("!D__B") [flags 0x2] <var_decl 0x40d5b580 B>) (symbol_ref:SI ("<pic base>"))))) (const_int 4 [0x4])) [0 B+0 S8 A64])) 309 {*movsi_internal1} (insn_list:REG_DEP_ANTI 4542 (insn_list:REG_DEP_OUTPUT 4568 (insn_list:REG_DEP_OUTPUT 4523 (insn_list 4566 (nil))))) (nil)) ./emil9.pas:113: internal compiler error: in reload_cse_simplify_operands, at postreload.c:391 TEST fjf303.pas: Failed TEST fjf512.pas: ./fjf512.pas: In procedure `g1': ./fjf512.pas:8: internal compiler error: in emit_move_insn, at expr.c:2812 failed *** same error for fjf558i.pas fjf558l.pas fjf558m.pas fjf558n.pas fjf558o.pas fjf558p.pas fjf559i.pas fjf559l.pas fproc.pas goto4.pas goto5.pas insan.pas knuth3.pas math.pas nlgpp.pas nlgpp2.pas nonloc2goto.pas nonloc3goto.pas nonlocgoto.pas waldek8.pas TEST fjf541b.pas: failed 1: 0.0000+0.0000i (0.0000+2.0000i) TEST fjf810.pas: ./fjf810.pas: In operator `<> (t, t)': ./fjf810.pas:6: internal compiler error: in assign_parms, at function.c:4832 failed TEST maur8.pas: failed 2 5.346144360147377e-315 4.976526179290721e+02 failed 3 2.610850128222922e-315 1.107148717794090e+00

1 0

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 11 Feb '05

11 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > You should also try setting the C_INCLUDE_PATH environment variable. I > have this in my "~/.profile" file: > > if [ $MSYSTEM == MINGW32 ]; then > export C_INCLUDE_PATH=/mingw/include > export LIBRARY_PATH=/mingw/lib > export CC=gcc.exe > export PS1='(Mingw)$PWD $' > else > export C_INCLUDE_PATH=/usr/include:/usr/gnu/include > export LIBRARY_PATH=/usr/lib:/usr/gnu/lib > export CC=i686-pc-msys-gcc.exe > export TERM=pcansi > export PS1='(MSYS)$PWD $' > fi Thank you very much -- that did the trick! :-) `make' gets a lot farther now. I'm still running into an error, though: ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" ld: cannot open crt2.o: No such file or directory Any ideas? Thanks, Markus ____________________________________________________________________ Valentinsgeschenke online einkaufen, WEB.Cent sammeln und bei ueber 300 Partnern ausgeben! http://webcentsammeln.web.de/?mc=021303

2 1

test-fjf949.pas - endless loop
by jan.ruzicka＠comcast.net 10 Feb '05

10 Feb '05

Hi list, the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop. with gdb: #0 $000025a4 in init_pascal_main_program () at fjf949.pas:4 #1 $00002614 in main (argc=1, argv=$bffff01c, envp=$bffff024) at <implicit code>:10 the line is 4 a: array [Byte] of String (2); I am running gpc on Mac OS X and it was installed through fink. There were more test failures in test suite, but this one seems to be the most critical. Jan Ruzicka PS: Disassembled portion of the code is: 0x0000253c <init_pascal_main_program+0>: mflr r0 0x00002540 <init_pascal_main_program+4>: stmw r30,-8(r1) 0x00002544 <init_pascal_main_program+8>: stw r0,8(r1) 0x00002548 <init_pascal_main_program+12>: stwu r1,-80(r1) 0x0000254c <init_pascal_main_program+16>: mr r30,r1 0x00002550 <init_pascal_main_program+20>: bcl- 20,4*cr7+so,0x2554 <init_pascal_main_program+24> 0x00002554 <init_pascal_main_program+24>: mflr r31 0x00002558 <init_pascal_main_program+28>: addis r9,r31,4 0x0000255c <init_pascal_main_program+32>: addi r9,r9,-22972 0x00002560 <init_pascal_main_program+36>: lbz r0,0(r9) 0x00002564 <init_pascal_main_program+40>: clrlwi r0,r0,24 0x00002568 <init_pascal_main_program+44>: cmpwi r0,0 0x0000256c <init_pascal_main_program+48>: bne- 0x25b8 <init_pascal_main_program+124> 0x00002570 <init_pascal_main_program+52>: addis r9,r31,4 0x00002574 <init_pascal_main_program+56>: addi r9,r9,-22972 0x00002578 <init_pascal_main_program+60>: li r0,1 0x0000257c <init_pascal_main_program+64>: stb r0,0(r9) 0x00002580 <init_pascal_main_program+68>: li r0,0 0x00002584 <init_pascal_main_program+72>: stb r0,56(r30) ;-------------------- here starts the loop 0x00002588 <init_pascal_main_program+76>: addis r9,r31,4 0x0000258c <init_pascal_main_program+80>: addi r9,r9,-26044 0x00002590 <init_pascal_main_program+84>: lbz r0,56(r30) 0x00002594 <init_pascal_main_program+88>: clrlwi r0,r0,24 0x00002598 <init_pascal_main_program+92>: mulli r0,r0,12 0x0000259c <init_pascal_main_program+96>: add r9,r0,r9 0x000025a0 <init_pascal_main_program+100>: li r0,2 0x000025a4 <init_pascal_main_program+104>: stw r0,0(r9) 0x000025a8 <init_pascal_main_program+108>: lbz r9,56(r30) 0x000025ac <init_pascal_main_program+112>: addi r0,r9,1 0x000025b0 <init_pascal_main_program+116>: stb r0,56(r30) 0x000025b4 <init_pascal_main_program+120>: b 0x2588 <init_pascal_main_program+76> ;-------------------- here ends the loop 0x000025b8 <init_pascal_main_program+124>: lwz r1,0(r1) 0x000025bc <init_pascal_main_program+128>: lwz r0,8(r1) 0x000025c0 <init_pascal_main_program+132>: mtlr r0 0x000025c4 <init_pascal_main_program+136>: lmw r30,-8(r1) 0x000025c8 <init_pascal_main_program+140>: blr

10 45

gpc & gcc-3.3.5
by Russell Whitaker 10 Feb '05

10 Feb '05

Hi Findly got around to compiling latest gpc: Using patch for 3.3.4, emit-rtl.c hunk #1 failed. Comiled using make bootstrap. test results: Unsuported: arerextest.pas # tests 4112 # expected pass 4111 # unsupported 1 Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs Configured with: ../gcc-3.3.5/configure --enable-languages=c,c++,pascal Thread model: posix gpc version 20041218, based on gcc-3.3.5 Thought you'd like to see some good news for a change. Russ

3 2

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 10 Feb '05

10 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > I have built gpc-20041218 successfully under Mingw with no > problem. Perhaps this is backend (or bison) thing? I tend to build > GPC/Mingw on a gcc-3.2.3 backend. Okay, I changed to gcc-3.2.3 now, and I'm getting the error: In file included from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/limits.h:132, from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/syslimits.h:7, from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/limits.h:11, from tsystem.h:84, from libgcc2.c:37: include/limits.h:132:75: no include path in which to find limits.h In file included from libgcc2.c:37: tsystem.h:87:18: time.h: No such file or directory Since time.h definitely exists in C:\MinGW\include, I don't see whatever could cause that error. Any ideas? Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: Cannot compile gpc-20041218 on
by Markus Gerwinski 10 Feb '05

10 Feb '05

Frank Heckenbach wrote: > Prof A Olowofoyeku (The African Chief) wrote: > > No idea. I have built gpc-20041218 successfully under Mingw with no > > problem. Perhaps this is backend (or bison) thing? I tend to build > > GPC/Mingw on a gcc-3.2.3 backend. > Which is currently recommended because of the system conditional > issues, so you (Markus) might prefer this as well. Still you might > want to report the problem, so it'll hopefully be fixed in future > GCC releases. Okay, I changed to gcc-3.2.3 (see parallel mail), and I'll report it to the GCC team. Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

1 0

Re: Bug? Delphi-style result variable
by Markus Gerwinski 10 Feb '05

10 Feb '05

Adriaan van Os wrote: > I agree with Frank that "Result" should behave as in Delphi and it does > consistently behave there the way it was designed to, As for the Delphi-style implicitly declared `Result', I completely agree with you and Frank. But we also have the ISO10206 feature of an explicitly declared result variable with a freely chosen name. _And_ until gpc-20041218, we were able to use it in a way that was IMO significantly better than defined by the standard. I think we should get back there. > although the > example shows that the whole idea of an "unnamed" Result identifier is > in itself a poorly designed language feature. Obviously, not much > thought went into it. Indeed. I suppose this is the reason -- or one reason -- why Delphi programmers usually try to avoid local sub-routines. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

1 0

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 10 Feb '05

10 Feb '05

I wrote: > In file included from intl/libgnuintl.h:22, > from intl.h:31, > from c-parse.y:40: > C:/MinGW/include/locale.h:87: parse error before "const" > > Any idea what could be wrong here? I meanwhile found out a really strange thing. The line denoted by the error message reads: _CRTIMP char* __cdecl setlocale (int, const char*); If I rename `setlocale' into e.g. `setlocale_foo', this header is compiled without complaint. Could that be due to a difference between gcc 3.3.3 (which I'm basing my gpc-build on) and the gcc 3.2.3 that came with my MinGW? Yours, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Bug? Delphi-style result variable
by Markus Gerwinski 10 Feb '05

10 Feb '05

Hi Folks, compiling the program Program Test; var x: integer; Function foo: integer; Procedure bar; begin (* bar *) result:= 7; end (* bar *); begin (* foo *) bar; end (* foo *); begin x:= foo; end. yields an error message test.pas: In procedure `bar': test.pas:14: error: invalid access to `Result' test.pas: In function `foo': test.pas:20: error: result of function not assigned Bug or feature? Yours, Markus

5 5

Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 09 Feb '05

09 Feb '05

Hi Folks! When trying to compile gpc-20041218 on a system with - Windows 2000 ver. 5.00.2195 - Service Pack 4 - MinGW 3.1.0 - MSys 1.0.9 I get the following error message during `make`: gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DCYGWIN_CROSS_DIR=\"/usr/local/i686-pc-mingw32\" -I. -I. -I. -I./. -I./config -I./../include \ -c ./c-parse.c -o c-parse.o make[1]: Leaving directory `/home/gerwinsk/mysoftware/gcc-3.3.3/gcc' In file included from intl/libgnuintl.h:22, from intl.h:31, from c-parse.y:40: C:/MinGW/include/locale.h:87: parse error before "const" Any idea what could be wrong here? Thanks in advance, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Bug? Delphi-style result variable
by Markus Gerwinski 09 Feb '05

09 Feb '05

CBFalconer wrote: > Markus Gerwinski wrote: > > Program Test; > > > > var > > x: integer; > > > > Function foo: integer; > > > > Procedure bar; > > begin (* bar *) > > result:= 7; > > end (* bar *); > > > > begin (* foo *) > > bar; > > end (* foo *); > > > > begin > > x:= foo; > > end. > > > > yields an error message > > > > test.pas: In procedure `bar': > > test.pas:14: error: invalid access to `Result' > > test.pas: In function `foo': > > test.pas:20: error: result of function not assigned > > > > Bug or feature? > > Feature. The program is flat out wrong No, it's not. Try compiling ... Function foo: integer; begin (* foo *) result:= 7; end (* foo *); ... This works. It is Delphi standard, supported by GPC since 2003. Only if you move `result ' into a local subroutine, you get an error. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

1 0

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

Hi Folks! Frank Heckenbach wrote: > Markus Gerwinski wrote: > > This results in a 'Header does not match previous definition' for function Bar. > Yes, according to the standard (*), the result variable must be > present in the original declaration as well. GPC didn't check this > before, but does now. > > (*) This is only stated in the Object-Oriented Extensions, 6.7 (d): > > : [...] and if one function definition contains a result variable > : specification, then the other also has a result variable > : specification of the same spelling. What's the point in declaring a local result variable in the unit interface?!? I mean, the code Function bar = result: integer; begin (* bar *) ... end (* bar *); is, in fact, nothing but an abbreviated way to write: Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *); So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface? I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again... Regards, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

3 3

not 0
by Adriaan van Os 08 Feb '05

08 Feb '05

GPC accepts: var i: integer value not 0; but it doesn't accept: var w: word value not 0; not.pas:4: error: constant out of range not.pas:4: error: initial value is of wrong type so, the workaround is: var w: word value not word( 0); At first sight, this looks a bit clumsy (but at second sight it may not). It gives rise to general questions about the type of constants in Pascal, e.g. * is there a difference between $FF.. and $0FF.. ? * is $FF.. signed or not ? Any comments ? Regards, Adriaan van Os

5 18

Wanted: Maintainer for my Units and Documentation
by Eike Lange 08 Feb '05

08 Feb '05

Hi Folks! I cannot maintain my units and documentation due to some personal activities any longer. It would be nice, if someone could overtake my contributions, which are * unit for mysql version 4 * unit for mysql version 3 * unit which interfaces Xlib.h * unit for zlib * PostgreSQL unit * a simple SDL unit * Program, which extracts pascal-strings and writes a ".po"-file for the use of internationalization (pas2po). (See http://www.gnu-pascal.de/contrib/eike/ ) * German documentation about GNU-Pascal (See http://www.gnu-pascal.de/~eike/ ) Eike

1 0

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

CBFalconer wrote: > My own attitude is that the use of result is pointless in the first > place. It gains nothing that I can see over the standard method > "bar := ...". In fact I like to code many things as: > > FUNCTION foo : T > > VAR > anotherTvalue : T > > BEGIN > foo := someTvalue; (* default *) > .... > IF whatever THEN foo := anotherTvalue; > .... > END; > > Please show me something that the traditional method can't do. Function getIndexOf ( aData: tDataType ) = result: integer; var data: tDataType; begin (* getIndexOf *) result:= 0; data:= someFirstDataInForExampleALinkedList; while ( data <> aData ) and ( data <> nil ) do begin data:= getNextData ( data ); inc ( result ); (* ... and this is what you definitely need a result variable for. *) end (* while *); end (* getIndexOf *); Of course, you also can do so by explicitly declaring `result`as a local variable and assigning it to getIndexOf in the end, but personally, I find the above way far more elegant. Frank: Would it cause much effort/pain to make the old syntax possible again? ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Bug in function parsing?
by Markus Gerwinski 07 Feb '05

07 Feb '05

Hi Folks! Seemingly the following code snippet cannot be compiled with the current GPC version: Unit Foo; Interface Function Bar: integer; Implementation Function Bar = result: integer; begin (* Bar *) result:= 2; end (* Bar *); end. This results in a 'Header does not match previous definition' for function Bar. Yours, Markus

2 1

segmentation fault
by willett 07 Feb '05

07 Feb '05

program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits. tested on GNU Pascal version 20030830, based on gcc-3.3.2 Willett Kempton

7 19

64 bit GPC on AIX
by Peter Keenan 06 Feb '05

06 Feb '05

I have built GPC 20041218 on GCC 3.3.4 on AIX 5.2, and thought it might be useful to document my experiences. I wanted to have the capacity to build 64 bit programs, however only 32 bit libraries are installed for GPC. Following my earlier post http://www.gnu- pascal.de/crystal/gpc/en/mail11115.html Waldek suggested trying build a 64 bit version of GCC including GPC. However having tried various strategies I was not successful in building a 64 bit only version of any version of GCC, even without GPC. So I tried to just build a 64 bit libgpc.a. I eventually achieved this export OBJECT_MODE = 64 export CFLAGS=-maix64 then run ./configure in ...gcc3.3.4/gcc/p/rts directory edit Makefile add -maix64 to CFLAGS (CFLAGS=-O2) copy libgpc.a to ...lib/gcc-lib/power..../3.3.4/ppc64 This allowed me generate 64 bit programs. My program contained a reference to the memavail function in system.pas. I had earlier had some problems with this function in 32 bit mode when it gave an error http://www.gnu-pascal.de/crystal/gpc/en/mail11086.htm In 64 bit mode the use of this function did not report an error but partly disabled the operating system, which should have been quite impossible for a normal user without root privileges! The operator had to reset the machine following this error. Programs without this function call seem to work fine.

2 1

testsuite with gp
by Adriaan van Os 05 Feb '05

05 Feb '05

Built gp-0.57 on powerpc-apple-darwin. Tried to run the testsuite with PC=gp. [G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels PC=gp rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gp" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d ./test_run: fatal: `--print-needed-options' yields: gp: internal problem: unexpected additional output of `gp -dumpmachine' Nothing was run. gp -dumpmachine on the command line displays gp help lines. I don't know if running the testsuite with gp is something that can already be done. Just reporting the results. Regards, Adriaan van Os

2 3

Re: [GPC]: daily digest (#613)
by Tom Schneider 03 Feb '05

03 Feb '05

Maurice: > Strange. > doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 > behaves as expected. Hmm. I don't understand why it would be an issue on a Sun! > All is done manually with suitable tools to binary visualize the > true content of files, no shell scripts or functions which could be > too intelligent (I have bash, no tcsh) and hide something > "unimportant", for example no linefeed or ^Z (a DOS nicety on text > files) added at the end. The script demonstrated in three ways that the files had zero length. > A side comment: to make it work I needed to compile with > gpc add the --transparent-file-name > option to gpc (otherwise the filenames are asked at the beginning of the execution) > Why did you not need it ? You are right. I use a script, gpcc, which uses that option. The files are definitely empty - there is no need for me to clear them inside the Pascal program. The script uses `echo -n ""` to make them and three different standard unix tools (ls, wc, file) say they contain zero bytes. The results were in the initial report. I have just discovered something else. Using the *same* code and the *same* input files: gpc 20040516, based on gcc-3.3.3 fails (says empty files are not eof after reset). but the older GNU Pascal version 2.1 (20020510), based on gcc-2.95.2 19991024 (release). works! (says empty files are eof after reset) Thus the behavior of GPC has changed between these two. >From my viewpoint this is an extremly serious bug because so many of my programs use the eof test. What's happening is that I'm slowly updating programs and so I didn't notice it until now. I spent all night the other day trying to figure a way to replace eof with something that worked (using eof but is still standard) but failed. If I have to use the p2c converter to work with my programs, I will be forced to abandon GPC, just as I was converting all programs to function smoothly with it ... :-( This is now true for one program. I hope that this can be solved! Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

6 11

--mac-pascal
by Adriaan van Os 02 Feb '05

02 Feb '05

Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now. The new gpc builds and passes the testsuite on powerpc-apple-darwin. A few places in the source of the gpc compiler are unclear to me. They include: 1. predef.c line 423 chk_dialect ("direct access to files without declared domain is", B_D_PASCAL); 2. predef.c line 713 flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 | CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK; 3. expressions.c line 124 chk_dialect ("string concatenation without `Concat' or `+' is", B_D_PASCAL); Regards, Adriaan van Os

6 18

GPC binding to OpenGL or Mesa
by Rick Engebretson 02 Feb '05

02 Feb '05

I'm a little confused about the GPC approach to binding to C libraries. The documentation is a little sketchy and warns that some changes might occur. Is there some clarification available ? Also, bindings of FPC to OpenGL are available, which are derived from Delphi3D. These are mostly limited to Win32.DLLs . Has anybody started a GPC to OpenGL or Mesa binding for Linux ? Might it be appropriate to simply start from the FPC template ? Thanks, Rick.

3 5

Re: EOF is not true on reset empty file
by Tom Schneider 01 Feb '05

01 Feb '05

> Date: Sat, 29 Jan 2005 14:14:18 +0100 (CET) > From: Waldek Hebisch <hebisch(a)math.uni.wroc.pl> > > You missed an important information. If I type (with `eof.pas' beeing > your file): > ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O -ftransparent-file-names -fstandard-pascal eof.pas > ./a.out > > I get: > NOT eof of namebook > NOT eof of namelist > > However, if I type: > ../gpc-3.4.3/gcc/xgpc -B../gpc-3.4.3/gcc/ -O --transparent-file-names eof.pas > ./a.out > > I get: > eof of namebook > eof of namelist > > Both with my (modified) copy of gpc-20041218 on Linux. Yes, standard requires > that you get EOF on empty file. Thanks for clarifying the standard for me. I'm using --transparent-file-names and with that get NOT eof. I hope that clarifies the issue for you. Tom

2 1

Re: EOF is not true on reset empty file
by Tom Schneider 01 Feb '05

01 Feb '05

Maurice: > Still please do the cross check. I have no Sun at hand do do it, > and may be nobody in this list has exactly the same system. > I know nothing on the inners of the Sun file system, whether > it stores somewhere the fact that this is a binary or a text file, > if the file length is obtained by looking truly to the file content, > or to some information on the length stored somewhere outside of the > file, etc. In DOS systems when running scandisk, you find sometimes > an error message like "file length as reported by the system is different > from the true file length" Ok. closetest.p: In main program: closetest.p:20: error: undeclared identifier `close' (first use in this routine) closetest.p:20: error: (Each undeclared identifier is reported only once closetest.p:20: error: for each routine it appears in.) The function 'close' is not standard Pascal. Since I'm not set up to avoid standard Pascal (and I don't think it is critical, correct me if I'm wrong please), remove those lines. A rewrite followed by a reset empties the file. ******************************************************************************** strawberry 21% more closetest.p program closetest(namebook, namelist, output); (* Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const version = 1.00; (* of closetest.p 2005 jan 31 *) var namebook, namelist: text; begin rewrite(namebook); { close(namebook); } reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook'); rewrite(namelist); { close(namelist); } reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. ******************************************************************************** NOT eof of namebook NOT eof of namelist The program failed. strawberry 15% ls -l nam* -rw------- 1 toms delila 0 Jan 31 19:40 namebook -rw------- 1 toms delila 0 Jan 31 19:40 namelist strawberry 16% wc nam* 0 0 0 namebook 0 0 0 namelist 0 0 0 total strawberry 17% file nam* namebook: empty file namelist: empty file The files made by the Pascal program are indeed empty by these three tests. Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

Re: [GPC]: daily digest (#614)
by Tom Schneider 01 Feb '05

01 Feb '05

> Date: Sat, 29 Jan 2005 04:42:00 -0600 > From: Rick Engebretson <reng(a)tcq.net> > > I think going to p2c will isolate your fine work. Thanks! However it is always good to have several different compilers around. By looking at p2c, I could see the problem in GPC and (presumably) vice versa. GPC is robust and has an active community. p2c works for standard Pascal (all I really need) but it is not active. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

EOF is not true on reset empty file
by Tom Schneider 30 Jan '05

30 Jan '05

One of my programs, which I have used with many compilers in the past, started an odd behavior as soon as I compiled with GPC. I rooted down to what the cause was and found this: EOF is not true on a reset empty file. Here is the program: ******************************************************************************** program gpcbug2005jan27(namebook, namelist, output); (* Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *) var namebook, namelist: text; begin reset(namebook); if eof(namebook) then writeln(output,'eof of namebook') else writeln(output,'NOT eof of namebook'); reset(namelist); if eof(namelist) then writeln(output,'eof of namelist') else writeln(output,'NOT eof of namelist'); end. ******************************************************************************** This is the result of running a script called mk (which displays itself): ******************************************************************************** version = 1.00 of mk 2005 Jan 27 #!/bin/tcsh -f #(ie run the tshell on this but don't read the .cshrc or .tcshrc) echo version = 1.00 of mk 2005 Jan 27 # 2005 Jan 27, 1.00: origin # show the script that does everything: cat mk echo -n "" > namebook echo -n "" > namelist echo 'file name*' file name* echo echo 'wc -l name*' wc -l name* echo echo 'ls -l name*' ls -l name* echo -------------------- compile gpcc gpcbug2005jan27.p echo -------------------- gpcbug2005jan27 file name* namebook: empty file namelist: empty file wc -l name* 0 namebook 0 namelist 0 total ls -l name* -rw------- 1 toms delila 0 Jan 27 02:25 namebook -rw------- 1 toms delila 0 Jan 27 02:25 namelist -------------------- compile version = 1.37 of gpcc 2004 Jan 11 Using /usr/local/gpc/bin/gpc instead of the one in the path gpc compiling gpcbug2005jan27.p output program name: gpcbug2005jan27 gpcbug2005jan27.p exists, so we can delete gpcbug2005jan27: REMOVING gpcbug2005jan27 version = 1.00; (* of gpcbug2005jan27.p 2005 jan 27 *) optimization: 0 --- GPC version from "gpc --version | head -1" : gpc 20040516, based on gcc-3.3.3 GPC version from "gpc | head -1" : GNU Pascal version 20040516, based on gcc-3.3.3. --- ONLY STANDARD PASCAL IS ALLOWED ------ No errors ------ No warnings ------ gpcc is done -------------------- NOT eof of namebook NOT eof of namelist ******************************************************************************** Is this standard behavior for Pascal? I thought that if you reset an file, it would be at eof. Where else could it be? Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 3

Re: EOF is not true on reset empty file
by Tom Schneider 30 Jan '05

30 Jan '05

I wrote before: > EOF is not true on a reset empty file. for GPC. gpc 20040516, based on gcc-3.3.3 I just found in the book PASCAL User Manual and Report, Fourth Edition ISO Pascal Standard, Kathleen Jensen and Niklaus Wirth 1991 page 158: "A file is called \emph{empty} if its length is zero." As you can see in the previous email, I created two empty files with echo -n "" > filename and then showed by three tests (file, ls and wc) that they were empty. In the GPC compiled program, I reset each file and then tested them and found that each was not at eof. Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

6 7

Sven nochmal(...)
by Sven SCHUBERT 21 Jan '05

21 Jan '05

aehm, hab gerade festgestellt, dass das ja eine deutsche Mailing liste ist. Wie schoen, ich spar mir die Uebersetzung in der Hoffnung, dass trotzdem die meisten wissen, worum es mir geht. Gruss, Sven. -- Sven Schubert I.T. Carlow - Software Engineering mobile: +353 85 7169848

2 1

Introduction & first question (c:
by Sven SCHUBERT 21 Jan '05

21 Jan '05

Hi all, this is me, Sven Schubert, 25 yo German and student of 'Software-Engineering' at the Institute of Technology Carlow, Ireland. My final year project is to come up with a Pascal compiler for the Parrot VM (www.parrotcode.org). While researching ways on how to do my project (i.e. write a new compiler from scratch or modifiy existing OSS-compilers to target Parrot), of course GPC was one of the open-source compilers I looked at. Now, I'm not exactly literate in compiler building and I could use some guidance regarding where to look at in GPC. Naturally, I'm looking for the Backend module of GPC, that would translate the intermediate representation into whatever its target language is. Because I guess, thats where I would have to start changing things (c: Can anyone point me, what part of the GPC source to look at? Anyone done anything similar in the past? As I'm still researching, I could use some third-party opinion on the feasability of modifying GPC instead of writing a new Pascal compiler from scratch. Any suggestions welcome. Thanks & cheers, Danke und viele Gruesse, Sven. -- Sven Schubert I.T. Carlow - Software Engineering mobile: +353 85 7169848

3 2

Mailing list problems
by Frank Heckenbach 19 Jan '05

19 Jan '05

The mailing lists have moved to a new server, and there have been some problems in the process. If you sent a mail to the list recently, and it didn't get through, please try again. Sorry for the inconvenience. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Redhat 9
by Francesco Bonomi 13 Jan '05

13 Jan '05

After installing the binaries on redhat 9, I get a long list of errors like: /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x5e3): In function `_p_UpCase': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:899: undefined reference to `__ctype_toupper' I have seen this problem often quoted in the list, but without a clear solution. My question is: Will recompliling gpc solve those issues? thanks Francesco

3 4

gpc with gcc-3.4.3
by Waldek Hebisch 12 Jan '05

12 Jan '05

I have put patches which allow compiling gpc-20041218 with gcc-3.4.3. Note that the patch also contains support for qualified identifiers and a few fixes to structured value constructors. The patch should work with all supported backends 2.8.1, 2.95.3, 3.2.3 3.3.x, 3.4.3 (for 2.8.1 you need an extra backend patch) -- it should just give you qualified identifiers support. I would recommend the patch for AMD64, since gcc-3.3 on AMD64 has a number of problems which are fixed in gcc-3.4.3. Also, the patch works around packed array problem with gcc-3.3 on AMD64 (they did not work, with the patch the main problem is fixed). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 9

Gpc and arm-elf cross compiling
by Francesco Lombardi 12 Jan '05

12 Jan '05

Hi all! I'm trying to build a cross compiler from win32-cygwin to arm-elf. I built the gcc cross compiler that works very well... Now, with the same configuration, I'm trying to build gpc compiler. The building process seems good, but if I try to compile a simple pascal code I obtain some errors: C:\cygwin\home\Mode3\Nuova cartella>arm-elf-gpc -o prova.o prova.pp /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0xed0): In function `realpath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1493: undefined reference to `getcwd' /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0x1114): In function `_p_CStringRealPath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1583: undefined reference to `getcwd' This is my configuration script: $SRCDIR/configure \ --target=arm-elf --prefix=/home/gba \ --enable-interwork --enable-multilib \ --enable-languages="pascal" \ --with-newlib --with-headers=../gcc/newlib/libc/include \ 2>&1 | tee configure_pas.log I'm using gcc 3.3.1 and gpc-20030830 patched Suggestions will be very appreciated ^_^

3 12

iwidgets for IDE
by Rick Engebretson 08 Jan '05

08 Jan '05

I'm hoping to generate interest in using iWidgets(tcl/tk) for a GPC programming IDE. The iWidgets demo "catalog" script shows off these tools nicely. A script based IDE is more flexible than a compiled IDE. An earlier mail message referred to tcl/tk, but iWidgets are high level, standardized GUI tools. Since iWidgets scripts are so completely flexible, an IDE is as much art as science. Rick

1 0

gpc-20041218 - linker problems on Smoothwall
by Prof A Olowofoyeku (The African Chief) 02 Jan '05

02 Jan '05

Hi I have built the core gcc-3.3.3 and gpc-20041218 to see whether they will run on Smoothwall (yes, I know that Smoothwal is a security appliance and you shouldn't run compilers on it, etc., etc. - but I have my own reasons). Anyway, I built the compilers on Fedora Core 1. The gcc compiler compiles and links simple programs okay. The gpc compiler working on an "hello world" program on the other hand produces this: "/usr/gnu/lib/gcc-lib/i386-redhat linux/3.3.3/libgpc.a(rts.o) (.text+0x21d1): In function `_p_CGetP wEnt': : Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/gnu/lib/gcc-lib/i386-redhat- linux/3.3.3/libgpc.a(rts.o)(.text+0x215b): In function `_p_CGetP wNam': : Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" and such other complaints about 'getpwuid' and 'setpwent'. Any simple solution? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 5

automatic CRTInit
by Francesco Bonomi 31 Dec '04

31 Dec '04

Dear all, My question is :how can I disable or delay the automatic CRTInit? What I need to do is write a program that (according to situations) writes binary data to output or open an interface (requiring CRT) The problem is that my binary data gets "filtered" somehow, and some bytes are replaced. I imagine this is because of ncurses, and reading the docs I found out that: > If you terminate the program before calling CRTInit or any routine > that causes automatic initialization, curses will never be > initialized, so e.g., the screen won't be cleared. But in effects, even without using any CRT routine, just including the crt in the uses clause will initialize ncurses. I have minimized this problem to a small program that uses the ANSI "reverse video" escape sequence Esc-[7m (I use an ansi sequence just because it's easily visible, the problem is the same with any other non-printable character). unit beforecrt; interface implementation begin write(chr(27),'[7m','BEFORE'); readln; end. program chr; uses beforecrt, crt; begin write(chr(27),'[7m','AFTER'); end. This is what happens: 1) without any clear screen, I see BEFORE in reverse 2) I press Enter 3) The screen is cleared, and "<[7m AFTER" is printed (in normal mode) The unit beforecrt is initialized before crt, so it's output is correct. The output from the main program (that gets executed after the initialization of crt) is filtered. Somehow, CRTInit is happening even if I do not use any routine of crt. How can I avoid this? Alternatively, how can I disable the ncurses at all? I have tried to use CRTSetTerminal('dumb', input, output); without any result. thanks Francesco (using gps 20040516)

2 1

gpc-20041218 released
by Frank Heckenbach 23 Dec '04

23 Dec '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de>! The main changes are fixes for 64 bit platforms that were partly broken with 20041017 (some tests still fail on these platforms, but these are mostly problems with the tests themselves), and slightly improved compatibility to Mac Pascal dialects. In detail, new features: - `Exit' with an argument (non-local exits not yet supported) (fjf988*.pas) (U) - new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M) - enable `Pointer' in `--mac-pascal' mode (Mac Pascal has a `Pointer' function which does the same as a type-cast to `Pointer'; though adding `Pointer' as a type allows more, it's backward-compatible) (M) - `&' and `|' (shortcut `and' and `or') (fjf981*.pas) (M) - `Leave' and `Cycle' (equivalent to `Break' and `Continue') (avo3.pas) (M) - optimize `WriteLn (... string_constant') and `Write (... string_constant, string_constant ...)' - `BindingType' is now a packed record as EP demands (fjf975a.pas) (E) Fixed bugs: - accessing components of a constant (EP) constructor (indexed by a constant for arrays) must yield a constant again (dave3*.pas) - GPC crashes when using two variables with identically-named fields in a single `with' statement (withbug.pas) - GPC doesn't accept `case' statements without case-list-elements (fjf982*.pas) - gcc-3.x: options are wrongly reordered (so, e.g., `--gnu-pascal -Wno-underscore' doesn't work as expected) (avo7.pas) - applying `not' to a function result in parentheses doesn't work (avo6.pas) - packed array indices containing `mod' don't work (avo4.pas) - GPC sometimes prints `???' instead of the actual file name in messages - function results (of record type) must not be allowed as `with' elements (only a warning in `--delphi' and `--mac-pascal' modes for compatibility); fields of non-lvalue `with' elements must not be lvalues either (fjf493*.pas) - value parameters of type `String' (undiscriminated) must take the capacity of the actual parameter, according to EP (waldek11*.pas) - initialized types in arrays (fjf233.pas, fjf974*.pas) - initializers are ignored in `New' and `Initialize' (fjf967[j-l].pas) - the address of global routines is not allowed in initializers (avo2*.pas) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

7 20

Software patents, please close your pages
by Eike Lange 22 Dec '04

22 Dec '04

Hi! It would be nice, if you could close your private site like this one http://www.ffii.org/ or this one http://www.gnu-pascal.de/ We are, again, demonstrating against software patents in the european union. Eike -- --**-- Webseite gesperrt --**-- http://www.gnushi.de/index.html

3 2

GCC integration?
by E. Weddington 22 Dec '04

22 Dec '04

Hello, I couldn't find the answer anywhere on the website, FAQ, or mailing list archives: Why isn't GNU Pascal integrated with the rest of GCC? and the related question: What would it take to integrate GNU Pascal with the rest of GCC? Thanks for your time. Eric

11 30

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