Gpc

gpc@gnu.de

5400 discussions

Re: Binary installation
by Peter Gerwinski 10 Nov '97

10 Nov '97

According to Tom Dye: > > [...] This code, which compiled > previously, fails now with a message that there is an undeclared > identifier `Ch' in function Isalphanum on line 17. > > ***-------------------------------------*** > module charbug interface; > [...] > function IsAlphaNum (ch : char) : boolean; > > module charbug implementation; > [...] > function IsAlphaNum; You have detected a bug in gpc-971001 which fails to attach the correct header "(ch : char) : boolean" from the interface declaration to the header in the implementation module. To work around, repeat function IsAlphaNum (ch : char) : boolean; in the implementation module; the bug will be fixed as soon as possible. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Problem
by Peter Gerwinski 10 Nov '97

10 Nov '97

According to sam.littlewood(a)quantel.com: > > Using gpc-971001, The code below fails to compile with errors ' prior > parameter's size depends on ...'': I fixed it! :-) Patch below. While the changes are small, this was hard to find. The problem is that the size of a conformant array is not even constant at run time, so the compiler produces code to calculate its size. This is the right thing to do in a function declaration but fails in an external declaration where we must prevent the compiler from trying to calculate the size of the array. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005] 8< --------------------------------------------------------------------------- --- gpc-971106/p/util.c Thu Nov 6 17:52:11 1997 +++ gpc/p/util.c Sun Nov 9 18:15:50 1997 @@ -709,8 +709,10 @@ */ int old_value = immediate_size_expand; immediate_size_expand = 0; + size_volatile++; carray = build_array_type (carray, itype); C_TYPE_VARIABLE_SIZE (carray) = 1; + size_volatile--; immediate_size_expand = old_value; } }

1 0

Weird ASM error - Scratch that...
by Orlando Llanes 09 Nov '97

09 Nov '97

I figured out what I did wrong, it was how I entered the hex numbers, sorry :( See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve/homepages/Monkey414

1 0

Weird ASM error, scratch that...
by Orlando Llanes 09 Nov '97

09 Nov '97

Sorry, I realized what I did wrong, it was the format of the hex number :( It runs fine now :} See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve/homepages/Monkey414

1 0

Weird ASM error...
by Orlando Llanes 09 Nov '97

09 Nov '97

I'm using the latest GPC Beta (971101?), and when I type in the following fragment of code: PROGRAM Foo; BEGIN asm('movl %eax, 0xa0000' ); END. it compiles fine, but when I run it, the program reports a GPF. I don't understand why it does that, I've even tried push'ing and pop'ing eax, but it still does the same thing. See ya! Orlando Llanes "Hey, we all did the drug thing, we all did the money thing, and eventually you find out that none of that stuff fixes anything, and we have nowhere else to go except to evolve spiritually and intellectually" -- Meredith Brooks "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve/homepages/Monkey414

1 0

Re: 2 suggestions about Units
by Peter Gerwinski 09 Nov '97

09 Nov '97

According to Hans Ecke: > > 1.) heredity and virtuall routines for units (yes, I mean objects!) > [...] > So what I would like to see would be: > > ///////////////////////////////////////////////// > > unit graph_fast(graph); If I understand this correctly, you mean that your unit `graph_fast' shall export everything that `graph' does but override `putpixel' and `line' with new implementations. Well, this is just overloading of procedures, nothing "virtual". (* Something like "virtual procedures" in units would be the following: Program X uses unit A and calls a procedure `foo' in A. Unit B uses unit A too and overrides `foo'. "Virtual" means that program X - which does not use B directly - in fact calls `B.foo', not `A.foo'. You do not really mean this, do you? { Well ... I just discovered: you *do* mean this. (See below.) } *) The mechanism you suggest requires qualified identifiers, so procedures with the same name can coexist in different units in the same project. This is planned for gpc-2.2. Up to then, you can get the intended effect of `Unit graph_fast ( Graph )' using the following kludge: Unit Graph_Fast; uses Graph; Procedure Fast_PutPixel ( ... ); (* Implemented below *); Procedure Fast_Line ( ... ); (* Implemented below *); Procedure Bar ( ... ); External; (* "Inherits" from `Graph' *) ... Implementation (* Implement `Fast_PutPixel' and `Fast_Line' *) end. Once qualified identifiers will exist, you can get rid of the `Fast_' name prefix. Having said that, it might be a good idea to implement your idea "Unit foo ( bar )" as a shortcut to produce the result sketched above. *Perhaps* in gpc-2.2. > procedure putpixel(x,y:integer); > begin > writeln(logfile,`Putpixel with parameters `,x,`,`,y); > inherited putpixel(x,y); > end; Okay, now you want `Graph' (or `Fast_Graph') use your overridden `PutPixel' instead of its own `PutPixel'. This can only be done with pointers, like Frank pointed out. This *is* virtuality. If you want to implement that, modify `Graph' such that `PutPixel' is a procedural variable: Var PutPixel: Procedure ( ... ); Then you must, of course, initialize it (perhaps in `InitGraph'), i.e. manually write a "constructor" for your "object". I have done this in the past (BO4), and it works in a great way. (* Since our `Graph' unit is *not* a port from Borland Pascal but was rewritten from scratch and comes with full source (C and Pascal), it is *no problem* to modify it this way. :*) To override the "virtual procedure" `PutPixel', your `Fast_Graph' unit needs to do nothing but to assign a new value to that `Putpixel' variable. You can do it with the current version of GPC (or with BP for that matter). > Maybe one could consider also Multi-heredity (is this a understandable > word?) It is, but the correct word is "multi-inheritance". With units, this would be no real problem - provided that we are not talking about virtual procedures. When it comes to virtual procedures, the same problems arise for units as for objects. Summary: The feature you are asking for does not (yet?) exist, but you can work around them relatively easily. But: If you want to have the features of objects for your library, why don't your libraries export objects instead of "ordinary" procedures? I am currently writing a library (BO5) which does it that way: All input/output is done through objects having virtual methods, so you can easily replace `PutPixel' with a different routine - and the whole library will work with this new procedure. Borland's "Graph" (BGI) API is not the ultimate way to implement a graphics library. I suggest to write the library using objects and to provide some ordinary procedures that use the objects as an interface for compatibility. > 2.) Making Libraries from units > I don't know if this task allready done. It is - for the objects. You can put them together in an `.a' file. (See the documentation of `ar' and `ranlib'.) For the interfaces (`.gpi' files) this is not possible at the moment. Your "parent unit" mechanism would provide an easy way to "concat" `.gpi' files, so the calling program only needs to use *one* unit and gets the functionality of all of them. Not a bad idea. Such a Unit BO5 ( Tools, Objects, Events, Displays, whatever ); (* "BO5" is the name of my planned ultimative library; you can substitute "EFLIB" if you prefer something already existing. ;*) Interface Implementation end. would produce one large `.gpi' file such that "uses BO5" would give all the functionality of `Tools', `Objects', etc. to the program and tell the linker to link all the files `tools.o', `objects.o', etc. (* Perhaps Borland's syntax "Library BO5" instead of "Unit BO5" would be a reasonable extension to directly produce `libbo5.a', i.e. automatically invoke `ar' and `ranlib'? *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

3 3

Re: Binary installation
by Clyde Meli 09 Nov '97

09 Nov '97

> Peter, > > Thank you for your help, first with the binary installation on RedHat 4.2 > (which failed), then with compiling gpc (which worked after an aborted > start :-) > > I now have the 971001 beta (2.7.2.3) running and compiling some simple > programs. But I still have a ways to go. This code, which compiled > previously, fails now with a message that there is an undeclared > identifier `Ch' in function Isalphanum on line 17. > I still haven't succeeded in compiling the 971001 beta (2.7.2.3) under solaris 2.5.1 as previously posted. No suggestions have been made so far. I got the same beta binary precompiled for dos and it seemed very stable to me at least. I wish I could get it to work for this week. Regards, Clyde cmeli(a)cis.um.edu.mt

1 0

Re: Binary installation
by Peter Gerwinski 09 Nov '97

09 Nov '97

According to Tom Dye: > > After using gpc for several months I upgraded to the latest > beta binary and managed to break everything. [...] My machine is running > Linux RedHat 4.2. > > [...] > > /tmp/cca02238.i:1: numeric constant with no digits This problem once occured with an old version of `libc.so'. You are possibly using `libc.so.5.3.12'. Upgrading to `libc.so.5.3.20' or above might solve your problem. Alternatively, you can compile your own GPC. That's not that hard on a Linux box: Get the GCC source `gcc-2.7.2.[1-3].tar.gz', `tar xzf' it, rename the subdirectory `gcc-2.7.2.[1-3]' to `gpc-971001', then do `tar xzf gpc-971001.tar.gz; cd gpc-971001; ./configure; make CFLAGS=-O3 LANGUAGES=pascal; make CFLAGS=-O3 LANGUAGES=pascal install'. Hope this helps (please report if it does), Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

3 4

probs compiling current beta GPC
by Clyde Meli 08 Nov '97

08 Nov '97

I don't think my previous post got through - If they did please excuse this repetition. I'm having problems compiling the beta under Solaris 2.5.1/gcc 2.7.2.3 - I had problems with gcc 2.7.2.1 also so I installed gcc 2.7.2.3. /usr/local/bin/gcc -c -DIN_GCC -DGPC -DSVR4 -O3 -I. -I.. -I. -I./.. -I./.. /config gpc-lex.c In file included from gpc-lex.c:102: hash.h:122: `AND_' undeclared here (not in a function) hash.h:122: initializer element for `wordlist[24].token' is not constant hash.h:125: `NOT_' undeclared here (not in a function) hash.h:125: initializer element for `wordlist[27].token' is not constant hash.h:126: `NIL_' undeclared here (not in a function) hash.h:126: initializer element for `wordlist[28].token' is not constant hash.h:136: `MOD_' undeclared here (not in a function) hash.h:136: initializer element for `wordlist[38].token' is not constant hash.h:153: `DIV_' undeclared here (not in a function) hash.h:153: initializer element for `wordlist[55].token' is not constant hash.h:161: `SET_' undeclared here (not in a function) hash.h:161: initializer element for `wordlist[63].token' is not constant hash.h:176: `CONST_' undeclared here (not in a function) hash.h:176: initializer element for `wordlist[78].token' is not constant make[1]: *** [gpc-lex.o] Error 1 make[1]: Leaving directory `/usr1/local/src/GNU/SOURCE/gpc-971001/p' make: *** [gpc1] Error 2 Is there a solution to compiling the beta? Regards, Clyde

1 0

Re: Paramstr(0) in ASM...
by Peter Gerwinski 07 Nov '97

07 Nov '97

According to The Kilobug Team: > > Do you know how to access the program directory (like Paramstr(0) > does) from an ASM program? If the main program has been compiled with GPC, it puts a pointer to the vector of parameters on a global variable `Gpc_argv', and `Gpc_argc' carries their number. In Pascal syntax, you can access them directly using Const many = 1024; (* or whatever *) Type ArgVector = array [ 0..many ] of CString; Var GpcArgC: asmname 'Gpc_argc' Integer; GpcArgV: asmname 'Gpc_argv' ^ArgVector; You know how to access such variables from ASM. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc