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 …
[View More]: 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]
[View Less]
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 …
[View More]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;
}
}
[View Less]
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
<__. \/\&…
[View More]gt;
/ \
____________|___\______ http://ourworld.compuserve/homepages/Monkey414
[View Less]
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
…
[View More] <__. \/\>
/ \
____________|___\______ http://ourworld.compuserve/homepages/Monkey414
[View Less]
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
…
[View More]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
[View Less]
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".
(* …
[View More]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]
[View Less]
> 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 …
[View More]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
[View Less]
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 …
[View More]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]
[View Less]
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
…
[View More]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
[View Less]
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: …
[View More]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]
[View Less]