- Gpc - gnu.de

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 24 Jun '05

24 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 17 Jun '05

17 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 16 Jun '05

16 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