- Gpc - gnu.de

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

Re: Separate Compilation
by Peter Gerwinski 07 Nov '97

07 Nov '97

According to richard.kerry(a)quantel.com: > > Hello, > Could somebody please either : > 1. Direct me to - info -f gpc -n "Source structures" at least explains how to use Units, and in info -f gpc -n "Extensions" you can read about Modules. This second documentation is somehow outdated; many things which are mentioned as missing features are implemented meanwhile. > or : > 2. Send me - > a comprehensive explanation of separate compilation using gpc, including > examples that clearly show which bits are in different files and how the > other bits pick up their definitions. And also including any > alternate/non-standard/old-fashioned techniques that are still usable. Coming below. > I am working on a very large project, developed using Oregon Pascal. The > separate compilation is done by each module (eg fred.pas) having a header > file (eg fred.def) containing all the procedures, functions, types and > constants it wishes the rest of the world to know about. All the routines > in the header are 'external'. The modules all contain their own global > variables; if any need to share, this is done by access procedures, or > records shared via pointers. There is no > module/unit/import/export/interface/implementation system involved. The > modules are compiled individually, using #include (%include in Oregon) to You can also use (*$i Foo *) or (*$include "foo.pas" *) or (*$include <foo.pas> *). > pick up any external definitions and references required, and then linked. > I want to mechanically translate all these modules to gpc, so I'd prefer a > mechanism, if there is more than one available, that uses a structure as > similar as possible to the one we are currently using. The closest approximation to Oregon Pascal (as you describe it) which is currently possible with GNU Pascal is to use the "somewhat simpler GPC modules" described in `info -f gpc -n Extensions'. When `foo.pas' reads; Module Foo; Var x: Integer; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. Then your `foo.def' can be (* foo.def *) Var x: __external__ Integer; Procedure y; External; and $including `foo.def' into the main program and linking with `foo.o' will have the desired effect ... uh - sh** (sorry!) it does not work! :-( :-( While implementing other things I threw away this one. The reason is that this feature turned into a bug when using Extended Pascal Modules or UCSD/Borland Pascal Units. Okay, this "GPC specific module" is very close to yet another type of Module defined in the PXSC standard. The only difference is that PXSC wants the reserved word `global' in front of each declaration that is to be exported. That's certainly more reasonable than to export just everything (like GPC did until February 1997 or so). It is planned to implement these PXSC modules into GPC. So you can either wait until GPC will have PXSC modules and then use Module Foo; Global Var x: Integer; Global Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- (* foo.def *) Var x: __external__ Integer; Procedure y; External; --- Program Bar; (*$I foo.def *) ... or use UCSD/Borland-style Units Unit Foo; Interface Var x: Integer; Procedure y; Implementation Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar; uses Foo; ... or Extended Pascal Modules Module Foo Interface; Export FooStuff = ( x, y ); Var x: Integer; Procedure y; end. --- Module Foo Implementation; Procedure y; begin (* y *) writeln ( 'y' ); end (* y *); end. --- Program Bar ( Input, Output, Whatever ); Import FooStuff; ... 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: Hex output.
by Dr E. Buxbaum 07 Nov '97

07 Nov '97

> From: Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> > Subject: Re: Hex output. > To: richard.kerry(a)quantel.com, gpc(a)hut.fi > Date: Wed, 5 Nov 1997 14:46:11 +0100 (MET) > According to richard.kerry(a)quantel.com: > > > > Does gpc have a built-in mechanism for converting a number to hexadecimal, > > for use in write(ln) or just as a number to string conversion ? > > No(t yet;-). > > > Oregon Pascal uses a negative field width to denote hex output (which I > > believe is sometimes also used to denote left justification), and Vax > > Pascal has a built-in 'hex( num, width )'. > > I do not think it's good to use negative field widths for this purpose > (except, perhaps, for compatibility reasons). The Vax syntax, OTOH, > seems quite nice for me. > > Right now we are still trying to finish up gpc-2.1, but we might take > this into account for gpc-2.2. > > Hmm ... what about something like `NumBase ( base, num, width )' to > allow for arbitrary bases like in `2#101010'? May be that sort of thing should be left to libraries, rather than build into the run time system. The main advantage of the Wirth family of languages, compared to comitte languages like, say, Ada, has always been that their syntax was limited to the necessary. It is easy enough to write a little library to read and write hex numbers and to convert them to and from integers and strings. Copying any odd feature from any odd Pascal compiler out there will create something big and cumbersome, that nobody in the end will be able to handle anymore.

1 0

Paramstr(0) in ASM...
by The Kilobug Team 07 Nov '97

07 Nov '97

Hi! Do you know how to access the program directory (like Paramstr(0) does) from an ASM program? Thanx -- -= The Kilobug Team =- DOS Real&Protected mode programming. Home page: http://www.planetepc.fr/users/kilobug/ NEW site (beta, french obly): http://www.mygale.org/~kilobug/

1 0

Separate Compilation
by richard.kerry＠quantel.com 06 Nov '97

06 Nov '97

Hello, Could somebody please either : 1. Direct me to - or : 2. Send me - a comprehensive explanation of separate compilation using gpc, including examples that clearly show which bits are in different files and how the other bits pick up their definitions. And also including any alternate/non-standard/old-fashioned techniques that are still usable. I am working on a very large project, developed using Oregon Pascal. The separate compilation is done by each module (eg fred.pas) having a header file (eg fred.def) containing all the procedures, functions, types and constants it wishes the rest of the world to know about. All the routines in the header are 'external'. The modules all contain their own global variables; if any need to share, this is done by access procedures, or records shared via pointers. There is no module/unit/import/export/interface/implementation system involved. The modules are compiled individually, using #include (%include in Oregon) to pick up any external definitions and references required, and then linked. I want to mechanically translate all these modules to gpc, so I'd prefer a mechanism, if there is more than one available, that uses a structure as similar as possible to the one we are currently using. Thank you all in advance. Richard. PS. I apologize to anyone who has already seen this message. We've had an email problem and I suspect my previous attempt to send this went into hyperspace...

1 0

Re: BP PChar compatibility
by Frank Heckenbach 05 Nov '97

05 Nov '97

The African Chief wrote: > Procedure StrDispose ( Str : PChar ); > Begin > If ( Str <> Nil ) and ( Str^ <> Chr ( 0 ) ) > then begin > Free ( Str ); > Str := Nil; { doesn't seem to do anything !!!} > end; > End; {* StrDispose *} > > Obviously, the line "Str := Nil" does not actually set it > to Nil. I would have to make "Str" a VAR parameter to > do this, You seem to answer your own question here. Of course, Str, being a value parameter, will not be set to Nil, you couldn't expect this... ;-) > but I don't want to that (it will become incompatible > with BP for one). Yes, BP uses a value parameter, too, and doesn't try to set the pointer to Nil. So my question in the first place is, why do you want the pointer to be set to Nil? I think, with careful programming, you shoudln't ever access the value of a StrDispose'd pointer. (And if this could happen, setting it to Nil manually when necessary seems like a good way to solve the problem, in BP as well as in GPC.) > I have now done a hack to make sure > that "Str" points to nothing, by inserting this line; > Str^ := #0; > before the call to "Free ( Str )". Is there any reason why > I shouldn't do this? Well, it's, of course, perfectly legal to do this... but unfortunately it will not do what you expect it to do. The memory that's free'd is still undefined, whether you write something into it or not. Maybe the free() call doesn't usually overwrite the memory at once, but perhaps sometimes, e.g. when memory is returned to the system. Maybe (even probably) it behaves differently on different platforms, or with the next version of GPC, libc, the kernel or whatever, who knows? Therefore, I'd consider it bad practice to do what you intend to do, since it will tend to hide errors in the calling program, i.e. errors may not happen to show up during debugging, but will show in the delivered program, thanks to Murphy. I don't think that's what you want. I'd rather even change the routines to write *bad* values into the area so that errors will show up as early as possible. (Doing this is a bit difficult here, since you don't know the size of the memory block, so it might not be worth the effort here...) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: 2 suggestions about Units
by Frank Heckenbach 05 Nov '97

05 Nov '97

Hans Ecke wrote: > 1.) heredity and virtuall routines for units (yes, I mean objects!) I assume, you don't mean objects, but a behaviour like objects, right? > [...] > So what I would like to see would be: > > unit graph_fast(graph); I understand what you mean, but I'm not sure if it's realistic to make this feature. First of all, it would severly influence the unit concept, and I'm not sure if it couldn't even break something. Secondly, it's technically difficult. I don't know if you know about the technical details of objects (in BP or GPC), so perhaps the following might not be very meaningful to you, but anyway: a virtual method in an object is always called through a pointer which is stored in a table that every object type has (the so called VMT, virtual method table). So using virtual methods is a bit more inefficient than using normal procedures or static methods. If you want to do the same with procedures, you'd either have to use a pointer for *every* procedure (which is not tolerable in general), or you'd have to declare "virtual procedures". Well, this seems possible to do, but consider this: - Using such virtual procedures is (a little bit) inefficient, just like virtual methods. So, I guess, you would not want to use them in your super-fast graphics unit. - There is already another way to do it (which does not work for object methods), namely with procedural variables: unit graph_fast(graph); interface procedure this_putpixel(...) begin end; var putpixel:procedure(...) value this_putpixel; implementation procedure this_putpixel(...) begin end; ... unit log_graph(graph_fast); interface implementation var logfile:text; old_putpixel:procedure(...); procedure log_putpixel(x,y:integer); begin writeln(logfile,`Putpixel with parameters `,x,`,`,y); old_putpixel(x,y); end; begin old_putpixel:=putpixel; putpixel:=log_putpixel end. Basically, it does the same as a virtual procedure would do, only you have to program it explicity. (And, of course, some initalization is necessary at runtime, which isn't necessary for virtual methods...) This means, of course, that it's as inefficient as virtual methods, there's no way around it... - And, of course, there is always the option of making an object type out of the unit. This has the additional advantage of being able to have multiple instances (e.g. some virtual graphics screens, or remote screens on networked computers, or different windows in a window manager), but the additional disadvantage of requiring the implicit Self parameter which is again a little bit more inefficient. E.g., I'm planning such an approach for my Crt Replacement Tool, when I ever get to write it. Of course, for Crt-like I/O, efficiency is quite irrelevant today, for graphics, it isn't... > Maybe one could consider also Multi-heredity (is this a understandable > word?) Yes, it is. The common term is "multiple inheritance", BTW. > It would be just like Multi-heredity in C++. Well, we have discussed multiple inheritance (for objects, of course, not for units) around May-Jun, IIRC, (easy to find in the list archive by searching for this term), and we've come to the agreement (more or less ;-) that multiple inheritance implies a lof ot problems, and that most (if not all) of its goals can be reached by something called "interfaces". Interfaces were introduced in Java which builds on C++. Obviously, the Java inventors realized the problems inherent in multiple inheritance, and therefore invented this safer concept. With GPC, we want to take the short cut to the safe concept... :-) Basically, interfaces contain a list of declarations of virtual methods, but no implementations or fields. An interface can inherit from multiple interfaces, and an object type can inherit from multiple interfaces, but only from one object type. Parameters of interface type, and pointers to interface types are possible. Implementing interfaces into GPC will not be quite easy, but we have figured out most of the details by now, so there's hope that they will be realized until GPC 2.2 (no promises). > 2.) Making Libraries from units > I don't know if this task allready done. If so, ignore it. Today, units > make just object files. [...] It has been discussed, and is planned, but AFAIK, no concrete work or consideration has been done yet. BTW: I have set up a To-Do list for GPC at http://home.pages.de/~fjf/gpc-todo_toc.html There, you can see which features are planned, and which bugs are known (provided, you can decipher my sometimes quite crpytic entries... ;-) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: BP PChar compatibility
by The African Chief 05 Nov '97

05 Nov '97

On Wed, 5 Nov 1997 14:45:43 +0100 (MET) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> >> [...] Why does the following program behave differently >> under BP and GPC? >> [...] >> StrDispose(p1); >> if assigned(p1) then p2 := strnew(p1); >> Writeln(p2); {GPC writes the full string; BP writes "Fred"} > >If `StrDispose' does what the name promises, `writeln ( p2 )' should >produced *undefined* behaviour. The problem is that "StrDispose" first of all frees the memory associated with the pChar parameter, and then sets it to Nil - e.g., Procedure StrDispose ( Str : PChar ); Begin If ( Str <> Nil ) and ( Str^ <> Chr ( 0 ) ) then begin Free ( Str ); Str := Nil; { doesn't seem to do anything !!!} end; End; {* StrDispose *} Obviously, the line "Str := Nil" does not actually set it to Nil. I would have to make "Str" a VAR parameter to do this, but I don't want to that (it will become incompatible with BP for one). I have now done a hack to make sure that "Str" points to nothing, by inserting this line; Str^ := #0; before the call to "Free ( Str )". Is there any reason why I shouldn't do this? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: Hex output.
by Frank Heckenbach 05 Nov '97

05 Nov '97

richard.kerry(a)quantel.com wrote: > Does gpc have a built-in mechanism for converting a number to hexadecimal, > for use in write(ln) or just as a number to string conversion ? Not yet, AFAIK. > Oregon Pascal uses a negative field width to denote hex output (which I > believe is sometimes also used to denote left justification), Not in GPC (currently, anyway). I agree that both hex output (or more generally, output with arbitrary base) and left justification are useful features. Since I've just hacked almost all of the read and write routines, it would be no big deal to built them in the RTS, if wanted. The only question remaining is about the syntax. Obviously, not both can use negative field widths, and anyway, negative field withs are not very clear (neither to someone new, nor in comparison to other compilers that behave differently). Something that seems possible would be to use a second specifier (as real numbers have for the precision). Then, "write(42:5:16)" would produce " 2A". Now, should we use upper or lower case letters? Perhaps a compiler switch? For left justification, we could make another compiler switch, or indeed use negative field widths. The latter would make it easier to mix right and left justified output (which might be desirable). > and Vax > Pascal has a built-in 'hex( num, width )'. Such a function can, of course, be written in pure Pascal, if needed. (But it would duplicate some code that's similar in the RTS...) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

2 suggestions about Units
by Hans Ecke 05 Nov '97

05 Nov '97

Hi all! I want to (talk) about two possibilties to enhance flexibility of Units. Since I don't know EP modules (I think the syntax is to useless complicated) the following may or may not hold for EP modules. If the following is already discussed I would be happy to recieve a pointer to the result (maybe date to search in gpclist-archive) 1.) heredity and virtuall routines for units (yes, I mean objects!) Consider the following situation : You are programming the one&only fast graphics unit. It will do graphics with direct memoryaccess (you want to program only for your very own computer). So putpixel/getpixel, bar, line will be assembler routines. To get comfort(i.e. fonts) you want to use all the routines of the graph unit (Borland, port from bpcompat). Three problems: * The outtext,circel,...-routines of the graph-unit use putpixel inside (if this is true doesn't interest now). They won't use your putpixel but the original putpixel inside graph. * A program which uses your graphics unit has to include also the original graph unit in the "uses"-clause. The program isn't interested at all in the original unit, but only in your modified one, but has to include both. The program has to deal too with changed function-definitions by justifying the order of appearance in the uses-clause. * The new unit can't change types/constants and still be able to use the old ones. So what I would like to see would be: ///////////////////////////////////////////////// unit graph_fast(graph); interface ....if interface of the new unit changed, put it here implementation procedure putpixel(..) begin end; procedure line(...) begin end; ... begin inherited begin; end. ////////////////////////////////////////////////// Now a unit which does nothing new, but logs each putpixel() unit log_graph(graph_fast); interface implementation var logfile:text; procedure putpixel(x,y:integer); begin writeln(logfile,`Putpixel with parameters `,x,`,`,y); inherited putpixel(x,y); end; begin ..assigning logfile inherited begin; end. /////////////////////////////////////////////////// Main program program graph_test(input,output); uses log_graph; ....programming graphics, using fast putpixel + graph.tpu-comfort + logging facilities end. Maybe one could consider also Multi-heredity (is this a understandable word?) I mean something like this: unit graph_fast(logging,graph,print); It would be just like Multi-heredity in C++. 2.) Making Libraries from units I don't know if this task allready done. If so, ignore it. Today, units make just object files. Something like unit1; ...Some little utility functions the user don't has to interface know about implementation end. unit2 ...Your main unit. The user only has to work with this interface unit and even don't have to know the interface of uses unit1; unit1 implementation end. makes 2 object files. To compile a program using unit2 you need both. If you write units for someone else (s)he will not know about unit1 (the program only knows about unit2) and maybe will delete the file. To make it more distributable we need a mechanism to concentrate all code and interface from all the forefathers of a unit (or a subset of them) into one object (or librarie) file and have the commands for it inside the source (pascal-philosophy) I hope I was clear enough, write if not, I will correct then. Hans

1 0

BP PChar compatibility
by The African Chief 05 Nov '97

05 Nov '97

Hiya all It seems that there is a difference between the way that BP and GPC handle pChar parameters. In BP, pChars always seem to be passed by reference. In GPC, this is often the case, but is it always so? Why does the following program behave differently under BP and GPC? PROGRAM TestStr; {$ifdef ver70} USES STRINGS; {$else ver70} USES SYSTEM, STRINGS; {$X+} {$endif ver70} Var p1,p2:pchar; s:string; Begin s := 'Fred is a good boy and a good father and uncle'+#0; p1 := StrNew (@s[1]); Writeln(p1); StrDispose(p1); if assigned(p1) then p2 := strnew(p1); Writeln(p2); {GPC writes the full string; BP writes "Fred"} StrDispose(p2); StrDispose(p2); {should cause a runtime error - but doesn't under GPC} End. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro 4.01 for Win16 and Win32: http://www.simtel.net/pub/simtelnet/win3/install/chief401.zip

2 1

Re: Problem
by Peter Gerwinski 05 Nov '97

05 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 ...'': |-O Gnuuuaaaaah! 8-( This was one of the most weird errors in earlier versions of GPC, and now IT'S BACK ... =8-O > Is this a known problem, and how might I go about fixing it? Well ... it's known - and solved - for other situations such as "ordinary" undiscriminated schemata as reference parameters. I will try to fix it until the next beta ... Thanks for the report! 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: Hex output.
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to richard.kerry(a)quantel.com: > > Does gpc have a built-in mechanism for converting a number to hexadecimal, > for use in write(ln) or just as a number to string conversion ? No(t yet;-). > Oregon Pascal uses a negative field width to denote hex output (which I > believe is sometimes also used to denote left justification), and Vax > Pascal has a built-in 'hex( num, width )'. I do not think it's good to use negative field widths for this purpose (except, perhaps, for compatibility reasons). The Vax syntax, OTOH, seems quite nice for me. Right now we are still trying to finish up gpc-2.1, but we might take this into account for gpc-2.2. Hmm ... what about something like `NumBase ( base, num, width )' to allow for arbitrary bases like in `2#101010'? 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: BP PChar compatibility
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to The African Chief: > > [...] Why does the following program behave differently > under BP and GPC? > [...] > StrDispose(p1); > if assigned(p1) then p2 := strnew(p1); > Writeln(p2); {GPC writes the full string; BP writes "Fred"} If `StrDispose' does what the name promises, `writeln ( p2 )' should produced *undefined* behaviour. Since BP writes "Fred" instead of producing a runtime error, BP obviously passes `p1' by *value* just like GPC. Since `p1' is a *pointer* to the actual chars, the *string* is always passed by reference - both in BP and in GPC. > StrDispose(p2); > StrDispose(p2); {should cause a runtime error - but doesn't > under GPC} This is incorrect, indeed. After the first `Dispose', the pointer should have an undefined value, so the second `Dispose' normally should crash. But in fact is is also correct "undefined" behaviour simply to ignore the second `Dispose' ... 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

Hex output.
by richard.kerry＠quantel.com 05 Nov '97

05 Nov '97

Hello, Does gpc have a built-in mechanism for converting a number to hexadecimal, for use in write(ln) or just as a number to string conversion ? Oregon Pascal uses a negative field width to denote hex output (which I believe is sometimes also used to denote left justification), and Vax Pascal has a built-in 'hex( num, width )'. Thank you in advance .. Richard.

1 0

Problem
by sam.littlewood＠quantel.com 05 Nov '97

05 Nov '97

Using gpc-971001, The code below fails to compile with errors ' prior parameter's size depends on ...'': Is this a known problem, and how might I go about fixing it? -----8<----- program prog(input,output); var v1 : array [1..10] of integer; #if 1 procedure p1(a1 : array [lo .. hi : integer ] of integer ) ; external ; { This fails } #else procedure p1(a1 : array [lo .. hi : integer ] of integer ) ; begin end; {This works } #endif begin p1(v1); end. -----8<----- Thanks. SamL

1 0

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 05 Nov '97

05 Nov '97

Bill Currie wrote: > Actually, I meant there's no problem changing the name. That's the > advantage of a function call: the RTS implementation gets hidden > properly. It might be an advantage, but since InOutRes is documented in BP, it should be the same in GPC. Therefore, I see no problem making inline code to check InOutRes. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Re: File Handling
by chris＠bockermann.ping.de 03 Nov '97

03 Nov '97

Hello ! I'm very sorry for my last e-mail concerning this subject ! I had a little error with my mail-system > I don't speak Dutch, what do you mean bis den? :-) It has nothing to do with Dutch. It's German for 'Good bye' ! My mailer simply sent only the signature file (as you see, it is not inter- national, I'll change this) and forgot the Body of my mail. Ok, I'll try it once again : program file_test; var f : TEXT; { same as FILE OF CHAR, I think } begin assign(f,'filename'); { connect virtual f to physical file on disk } rewrite(f); { CREATE f or overwrite an old file with the same name as f } writeln(f,'This is a test-string'); { insert 'This..' in f and append CR } close(f); { write virtual f into 'filename' on disk and close file } end. If you want to access a file, which already exists use reset(f) instead of rewrite(f). Hope it is helpful... --Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

2 2

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 03 Nov '97

03 Nov '97

I found another little problem in strings.pas while testing the example program from <SIMEON.9710101739.A@@muahost.cc.keele.ac.uk>: Since StrNew uses C's strdup() which in turn uses malloc(), you can't use Freemem in StrDispose. Using free() instead works. (There may be other places where such a change is necessary.) Frank -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Re: gpc on Windows NT
by Peter Gerwinski 03 Nov '97

03 Nov '97

According to Jim Brander: > The executable gpc1.exe included in the Cygwin32 release 18 falls over > with an exception without doing anything. Its date is 19/12/96, whereas the > gcc compiler in the same release is dated 15/4/97. Does this mean that Cygnus did include a binary distribution of GPC into their CygWin32 distribution? > The source to allow recompiling and debugging gpc for NT is not included in > the Cygwin cdk source. The GPC online documentation (info -f gpc -n "Windows 95/NT") says: Windows NT and Windows 95 with cygwin32 --------------------------------------- cygwin32 is a project to make it easy to port UNIX applications to machines which run an OS which supports the Win32 API--i.e. Microsoft Windows 95 and Windows NT. Currently, cygwin32 is in beta stage; it is available from `ftp://ftp.cygnus.com/pub/gnu-win32/' Don't use gcc sources from the cygwin32 distribution. These are not just modified from FSF `gcc-2.7.2.1' to support the Windows 95/NT target, they are the "current development release", and too different from FSF GCC to be compatible with GNU Pascal, which is based on FSF sources. Instead, apply `config/cygwin32/gcc-2.7.2.1.cygwin32-beta17.diff' to FSF `gcc-2.7.2.1' to add cygwin32 platform support to GCC. The GNU pascal sources already have the cygwin32 support, so no further patching of gpc is needed Currently, cygwin32 is not self-hosting: the preferred way to build the cygwin32-gpc binary is to use a UNIX system with a cygwin32 targeting cross-compiler. *Note Crossbuilding:: > You do not provide binary for Intel-Windows NT at your ftp site. Please also try ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ Another port of GNU compilers to Windows 95/NT besides CygWin32 is in preparation: mingw32. Check out http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32.html 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: Trapping I/O runtime errors in GPC
by Frank Heckenbach 02 Nov '97

02 Nov '97

The African Chief wrote: > > Actually, that's almost exactly what my mods do. If IO checking is > > enabled ( {$I+} ), a proceedure taking no parameters is called that > > would check the InOutRes state (though I used a different name) and > > if it's set dumps a dirty message and aborts the program. > > For compatibility with BP, you would need to call the variable > "InOutRes", and it should be exported, so that programmers can > set it manually if they want (this feature of BP might be > considered to be a bug by some, but I have found great use for it > ...). I've made use of it, too. Since there's no proper way to raise an I/O error, setting InOutRes seems to next best thing to do. Therefore, we'll call it InOutRes in GPC as well. Exporting it will be no problem. One little question is its type: should it be Integer as in BP, or Integer(16) (which the BP Integer is in GPC)? I'd prefer Integer as that's more natural and easier to handle in the RTS functions written in C. I hope there aren't BP programs that rely on its exact size (e.g. by passing it VAR to a procedure expecting a 16 bit Integer). Bill Currie wrote: > Good point. If I leave the check as a function call, there's no > problem, but if I go to inline code I will use InOutRes. And as long as it's a separate RTS function, I will use InOutRes, too... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

3 2

Editing GPC-source code
by chris＠bockermann.ping.de 01 Nov '97

01 Nov '97

Hi everybody ! Sorry, if this does not really fit to Pascal-related programming, but I think it fits to GPC !? I have a question to all the people working on the improvement of GPC : I want to insert a function of my own, written in C, into GPC. In which file do I have to put it ? For example if I want to insert a function of bpcompat direct into the compiler. Is there any way to do this ? Help would be nice ... -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: Accessing command line arguments example doesn't work
by Peter Gerwinski 01 Nov '97

01 Nov '97

According to Thomas Tan: > I get wierd errors when I try to compile the command line argument example. > First it had a problem with the line (ParamStr := ";), so I changed the " to "" An empty string was meant, so the correct thing would be '', but "" works, too. > Then it said ( cmdline.pas(36) Error: undeclared identifier `Arg_num'" )about > the line > ( Success := _p_paramstr (arg_num, Str);) I don't know what's wrong. Change it to `num', then it should work. The part of the documentation you are referring to is outdated. The packages `BPcompat' and `BO5', both available from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/, contain tested, BP-compatible versions of `ParamCount' and `ParamStr'. In addition, I am currently working on making those functions built-in. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: your mail
by Peter Gerwinski 01 Nov '97

01 Nov '97

According to Peter G Purcell: > I am looking for a freeware or shareware pascal compiler. You have found one. :-) Welcome to GNU Pascal and its mailing list! To subscribe to this list, write to gpc-request(a)hut.fi. > Where might I find one, and how may I download it? You can download the official version 2.0 of the GNU Pascal compiler from ftp://kampi.hut.fi/jtv/gnu-pascal/ We also have rather stable beta versions available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ we can recommend you to try. More information, including the GNU Pascal FAQ list, can be found at http://home.pages.de/~GNU-Pascal/ 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

None
by ppurcell＠juno.com 01 Nov '97

01 Nov '97

I am looking for a freeware or shareware pascal compiler. Where might I find one, and how may I download it? Thank you for your help. Sincerely, Peter Purcell

1 0

Accessing command line arguments example doesn't work
by Thomas_Tan＠fc.choate.edu 01 Nov '97

01 Nov '97

I get wierd errors when I try to compile the command line argument example. First it had a problem with the line (ParamStr := ";), so I changed the " to " " Then it said ( cmdline.pas(36) Error: undeclared identifier `Arg_num'" )about the line ( Success := _p_paramstr (arg_num, Str);) I don't know what's wrong. Here's the text I found in the Documentation of GPC: <********** begin text here *************> Accessing command line arguments: The following module accesses the command line with ParamStr and ParamCount functions. These follow the Un*x semantics, so that arg[0] == program name, arg[1] .. arg[ParamCount-1] are the arguments. MODULE command_line interface; EXPORT cmdline = (Max_length, Arg_type, ParamStr, ParamCount); CONST Max_length = 255; { Max length of each argument. If some arg is longer, the run time system traps it. } TYPE Arg_type = String(Max_length); FUNCTION ParamCount: Integer; FUNCTION ParamStr (arg_num: integer): Arg_type; END. { command_line interface } MODULE command_line implementation; { These are in the GPC runtime library } FUNCTION _p_paramcount : Integer; C; FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; FUNCTION ParamCount; BEGIN ParamCount := _p_paramcount; END; { ParamCount } FUNCTION ParamStr; VAR Str : Arg_type; Success : Boolean; BEGIN Success := _p_paramstr (arg_num, Str); (* Should perhaps do something else on failure. * * Now it returns the empty string, which is also a valid * parameter. *) IF Success THEN ParamStr := Str else ParamStr := "; END; { ParamStr } END. { command_line implementation } { The program below, when compiled with the interface module and linked with the implementation module, accesses the command line arguments. } program zap (output); import cmdline; var counter : integer; begin writeln ('Program fetches command line arguments and outputs one per line'); writeln ('Max length of each argument is ',Max_Length:1,' characters'); for counter := 0 to ParamCount-1 do writeln ('Command line arg ',counter:1,' is "',paramstr(counter),'"'); end. <******************end text here****************> ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

1 0

Re: File Handling
by Peter Gerwinski 01 Nov '97

01 Nov '97

According to Thomas Tan: > I need to create a new text file, put some string in it, and save it to disk. Is > this possible in GPC? With gpc-971001 you can do it just like with Borland Pascal: Program Hello; Var MyFile: Text; S: String [ 42 ]; begin S:= 'Hello, world!'; Assign ( MyFile, 'hello.dat' ); rewrite ( MyFile ); writeln ( MyFile, S ); close ( MyFile ); end. 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: Editing GPC-source code
by Peter Gerwinski 01 Nov '97

01 Nov '97

According to Christian Bockermann: > > Sorry, if this does not really fit to Pascal-related programming, but I think it > fits to GPC !? Perfectly. :) > I have a question to all the people working on the improvement of GPC : > I want to insert a function of my own, written in C, into GPC. In which > file do I have to put it ? For example if I want to insert a function > of bpcompat direct into the compiler. Is there any way to do this ? While one can easily fill books with this topic, here is a short description what to do: * Locate your file in the `rts' subdirectory of the GPC source tree. (It may be written in C, Pascal, or any other GNU language, BTW.) * Edit `rts/Makefile.in', so your file will be compiled and included into `libgpc.a', GPC's run-time library. * In `util.c', add your routine to the `KItable'. * In `parse.y', assign a token to your routine, make it `%type <ttype>', add it to `new_identifier_1', so the identifier remains redefinable, and - implement it. For this last point, look at an existing routine which is called in a similar way as yours (`Assign', for instance, is a good example). * If your implementation in `parse.y' is through `rts_proc_parlist' or similar, the actual work will be done in `build_rts_call()'. So you will have to edit `rts.c' and to add your routine to the big `switch' statement in `build_rts_call()'. Depending on what you intend to implement, this can be quite easy or a nightmare. Again, look at an existing feature that is called in a similar way as yours. * Everywhere within GPC you will have to deal with so-called "tree nodes". I have written a short introduction to those things and more - see the chapter "GPC source" of the GPC online documentation. Good luck! If you succeed or have further questions, please let us know! 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

File Handling
by Thomas_Tan＠fc.choate.edu 31 Oct '97

31 Oct '97

I need to create a new text file, put some string in it, and save it to disk. Is this possible in GPC? ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

2 1

Re: gpc beta
by Peter Gerwinski 31 Oct '97

31 Oct '97

Hi, Richard; hi, all! > I have just downloaded gpc beta for installation on a debian 1.3.1 > system. I may become the new debian gpc maintainer, within the next > month. Good to know. Thanks. I was reported (did not check by myself) that current Debian distributions of GPC suffer from the problem that the GPC run-time library, a shared library in Debian, is not symlinked correctly: The symlink libgpc.so -> libgpc.so.2 is missing in `/usr/lib'. It would be a good idea to correct this in future distributions. 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]

1 0

Re: us_Timer in TimeStamp
by Frank Heckenbach 31 Oct '97

31 Oct '97

Jesper Lund wrote: > Apart from the fact that this is DJGPP-specific, there is another caveat. > The documentation states that the use of `uclock' *may* (on some systems) > interfere with the proper working of the system time. Oh well... :-( So, perhaps it's better to use just the 1/18.2 s system clock then... > I understand the need for something like Randomize in game programming (I > guess I am thinking too much about scientific purposes). But, as Peter > pointed out, the program should only call Randomize once (at the beginning), > and rely on repeated calls to the Random function to generate a sequence of > numbers that -- for all practical purposes -- looks random. In that case, > using hours, minutes and seconds from the system time, or the Unix approach > with GetPID, should be perfectly satisfactory. > > I may be missing something (I *am* totally ignorant about game programming), > but to me the discussion about lack of randomness unless 1/100 or 1/1000 > seconds are used sounds like calling Randomize before *each* call to Random? I think so. However, 1 second may be a bit too long for short command line programs that use random (perhaps a fortune teller). A user could call the program more than once a second. (Though this doesn't seem to be a big problem.) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

gpc beta
by Lisa, Sian, Becki and Richard 31 Oct '97

31 Oct '97

I have just downloaded gpc beta for installation on a debian 1.3.1 system. I may become the new debian gpc maintainer, within the next month. Richard

1 0

Binary installation
by Tom Dye 31 Oct '97

31 Oct '97

Hello, Sorry to bother all of you with a question that is a bit off center for this list. After using gpc for several months I upgraded to the latest beta binary and managed to break everything. I don't know enough about the C compiler or Unix to puzzle this problem out for myself so I'm asking for whatever guidance you might be able to provide. My machine is running Linux RedHat 4.2. I think the problem is a temporary file that is created in the first step of the compile. My guess is that it is empty, but when everything is finished failing the file is gone so I can't have a look. I did save the output to standard error in the hope that it might mean something to someone who knows about such things. Here it is: /tmp/cca02238.i:1: numeric constant with no digits /tmp/cca02238.i:1: numeric constant with no digits /tmp/cca02238.i:1: invalid #line /tmp/cca02238.i:11: warning: missing program header /tmp/cca02238.i:11: parse error at null character If there are other diagnostics, I'll be happy to collect them and pass them along. Thanks much for your patience and help. I am loathe to embark on the project that would have me finding and installing the proper version of gcc so that I can compile gpc. Hopefully, it will be possible to get the binary version up and running. Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

Re: Problems with strings in GPC beta 971001
by Frank Heckenbach 30 Oct '97

30 Oct '97

Jesper Lund wrote: > Regarding the discussion of GPCs 3-4 different string types and the *planned* > generic string (AnyString): > > Could you use the Extended Pascal string (augmented with the extra byte to > hold the #0 char) as the generic string (AnyString), and let the compiler add > the necessary conversion code (Borland <-> EP string; Cstring <-> EP string; > array of char <-> EP string) whenever the program calls a built-in function > with a different string type than EP string? For value parameters, this seems the best solution, indeed. For constant parameters, things are even easier, because a capacity is not needed, so we only have to pass the address of the first character and the current (constant) length. However, what's problematic is var parameters. Since the procedure must be able to change their length, and that's done differently for each of the four string types (EP: setting an integer; BP: setting a byte; SP: filling with spaces; CString: setting a #0 terminator)-:, the procedure has to know the actual string type. According to my suggestion of AnyStrings, a procedure with a var AnyString parameter could do the following operations on it, which will do the right thing for the actual string type transparently to the programmer: - Length - AssignLength - Capacity - Assignment to/from other strings of any type. (This includes passing as value or const parameters.) - Passing as var parameters of AnyString (not "any string"! ;-) type - Accessing single characters with "[n]" -- where I'm not sure if the index should always start at 1, or as in the original string/array. The former would be easier to handle; for the latter, the starting index would have to be passed (internally), too. Of course, when we have AnyString, it's quite easy to convert all string parameters in the RTS functions to AnyString, so those functions will work on all string types. > P.S. Peter and Frank; you *have* convinced me that there is a need for the > Borland string type. When I wrote the message yesterday, I didn't realize > that there were so many undocumented BP features, nor the extent to which > people used them to work around limitations and inefficiencies in Borland > Pascal. Honestly, I wasn't aware of the extent until I came to GPC, though I'd been using the things in BP for years... > But you will probably have to draw a line somewhere: supporting any > undocumented feature in BP must be an implementation nightmare ... We've decided, *not* to produce a warning in "--borland-pascal" mode when the data exceed 64 KB... ;-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Does GPC have structured constants ?
by richard.kerry＠quantel.com 30 Oct '97

30 Oct '97

Does GPC have structured constants, as found in Oregon and Vax Pascal ? eg. type ThreeNumbersType = record a, b, c: integer; end{record}; const FirstConst = ThreeNumbersType( 1, 2, 3 ); SecondConst = ThreeNumbersType( 42, 64, 96 ); procedure StructuredConsts; var fred, bill: ThreeNumbersType; begin fred := FirstConst; bill := SecondConst; end; I know there's the schemas, but they change these from a constant declaration to a type or variable declaration and I'm trying to get the simplest possible (machine) translation from Oregon Pascal to GPC. Here's hoping the answer is "yes, do it like this ..." Richard

1 0

Re: Does GPC have structured constants ?
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to richard.kerry(a)quantel.com: > > Does GPC have structured constants, as found in Oregon and Vax Pascal ? Yes, do it like this: Type ThreeNumbersType = record a, b, c: integer; end (* ThreeNumbersType *); Const FirstConst: ThreeNumbersType = ( 1, 2, 3 ); SecondConst: ThreeNumbersType = ( a: 42; b: 64; c: 96 ); > Here's hoping the answer is "yes, do it like this ..." 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: Sizeof LongInt
by Peter Gerwinski 30 Oct '97

30 Oct '97

According to Jesper Lund: > > Is code written using the portable `Integer ( 64 )' as efficient as code > using the type `LongInt' (assuming that LongInt is 64-bit), or is there some > performance loss? In short: There is no performance loss. :-) In long: If `LongInt' is 64-bit, then `Integer ( 64 )' is exactly the same as `LongInt'; if, on another machine, `Integer' is 64-bit, then `Integer ( 64 )' is exactly the same as `Integer'. A loss of performance can only occur on machines without registers whose width is a divisor of 64 - which I have never seen. 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]

1 0

Re: Sizeof LongInt
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? Not guaranteed. It might be 16 on some systems. > I am asking this because writing a good pseudo-random number generator is a > lot easier (transparent) and more efficient (execution speed) if a 64-bit > Integer is available. Use `Integer ( 64 )' which is guaranteed (to the extend of the GPL;-) to have 64 bits. 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]

2 1

Re: gpc on Linux
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Tomaz kolenko: > $ gpc -v > gpc version 2.0(2.7.2.1) I meant: `gpc -v yourprogram.pas'. ;-) But never mind ... > Thank you for reply. Probably I should tell that I use Debian Linux. Yes, that's an important information. This problem already was discussed on this list in March 1997. (You can look it up from the archives which are reachable from http://home.pages.de/~GNU-Pascal/support.html.) To symlink `libgpc.so -> libgpc.so.2' in `/usr/lib' was reported to work. Hope this helps, Peter PS: Better always mail things like this through the GPC mailing list because there might be others on this list having the same problem. 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: Portable random numbers
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > > Is there a well-defined standard for the ANSI, GNU or BSD `rand' function? > If so, where can I find it? The only thing I have is the source code for > rand in my DJGPP C library. What I have seen is the source code of the BSD random number generator. It contains kind of scientific paper about why these are good random numbers. BTW, to initialize the actual random number generator - and only for this purpose -, they use yet another, very primitive random number generator which has about the same quality as that of BP ... ;-) 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: Trapping I/O runtime errors in GPC
by The African Chief 29 Oct '97

29 Oct '97

Bill Currie wrote: > > On 27 Oct 97 at 8:50, Frank Heckenbach wrote: > [...] > > - After calling an I/O function, if {$I+} is turned on, the calling > > program > > must check InOutRes. The code to be generated (perhaps you've > > already done so) would look like "if InOutRes<>0 then _p_ioerror;" > > where _p_ioerror will be a RTS function I can provide. (The check > > "if InOutRes<>0" could also be done in the function (like in BP!), > > but that's inefficient, because the function has to be called > > after each I/O operation then.) > > Actually, that's almost exactly what my mods do. If IO checking is > enabled ( {$I+} ), a proceedure taking no parameters is called that > would check the InOutRes state (though I used a different name) and > if it's set dumps a dirty message and aborts the program. For compatibility with BP, you would need to call the variable "InOutRes", and it should be exported, so that programmers can set it manually if they want (this feature of BP might be considered to be a bug by some, but I have found great use for it ...). Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

2 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 29 Oct '97

29 Oct '97

Bill Currie wrote: > > I might modify this procedure a bit to use the (current) standard > > way of handling runtime errors (_p_generic and such), but this > > shouldn't be a problem. However, if you could move the check into > > the program, this would gain some efficiency. > > Shouldn't be too difficult. I'll just have to figure out which > expression tree's I need (a call is easier to build, that's all). Yes, I guess so... BTW: When I've done all the RTS work, I'll send you a list of all the RTS functions that need checking. Or did you already figure them all out? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Portable random numbers
by Jesper Lund 29 Oct '97

29 Oct '97

Jesper Lund wrote: > >Is there a well-defined standard for the ANSI, GNU or BSD `rand' function? >If so, where can I find it? The only thing I have is the source code for >rand in my DJGPP C library. I found the code for the BSD random number function (it was in another subdirectory of /djgpp/src/ than the ANSI `rand' function). Jesper Lund

1 0

Sizeof LongInt
by Jesper Lund 29 Oct '97

29 Oct '97

Is Sizeof (LongInt) = 8 on *all* systems supported by GPC? I am asking this because writing a good pseudo-random number generator is a lot easier (transparent) and more efficient (execution speed) if a 64-bit Integer is available. Regards, Jesper Lund

1 0

Re: Portable random numbers
by Peter Gerwinski 29 Oct '97

29 Oct '97

According to Jesper Lund: > > >PROCEDURE Randomize; > >BEGIN > > SRand(GetPID); > > RandSeed:=Rand > >END; > > I don't see how this should emulate the Randomize procedure in Borland > Pascal. According the info docs for my C library, getpid returns the unique > process number for the program running on the system. If you call getpid > twice in the same program, you get the same integer. Why not compute a seed > from the system time (somehow), as Borland Pascal does? If the sysetm time is always available, I agree. OTOH, `Randomize' should never be used twice in the same program! I know someone who tried to get "even more random" numbers by calling `Randomize' before each sequence of calls to `Random', but the calculations in between were so fast that the time did not change between two `Randomize's. As a result, the random numbers were the same in all sequences - with Borland Pascal. > That is, if we need a Randomize procedure at all? My C library (DJGPP) > doesn't have such a beast. Ok, there is Borland compatibility .... > > I use random numbers a great deal in my work (statistical simulations), and > in most cases (if not all) I specify the seed myself, since this is the only > way of gettting reproducible results. [...] For scientific application I agree. For games and such, that little bit of "true random" is a must. > The following piece of code represents a widely used procedure for generating > uniform random numbers (reals between 0.0 and 1.0), but it could easily be > changed to generating integers between 0 and 2^31-1 (just modify the last > line in RanUni). If the quality of these random numbers can compete with those produced by the GNU or BSD C library, and if there are no problems with copyright, I would be happy to incorporate this code into GPC's run time library and to implement BP's `Randomize' and `Random' for GPC on top of that (perhaps with Frank's unit as a replacement for those who specify `--borland-pascal' for 100% compatibility;-). 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]

2 1

Re: us_Timer in TimeStamp
by Frank Heckenbach 29 Oct '97

29 Oct '97

Jesper Lund wrote: > > > >So, a portable way to get fractions of a second would be a fine thing > >(micro seconds will not always be possible; under Dos, e.g., the > >resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... > > > > If we forget about portability for a minute, under DOS (DJGPP) there is a > libc function, uclock (), which provides (very) high-resolution timing. Fine, I didn't know this. It would be fine if someone could extend the time data types and functions to make use of it and the functions that are available on other systems. Perhaps fields for 1/100 seconds and microseconds, along with flags that say if these values are good, so that the data types can be portable though the time functions will differ. Then a built-it Randomize could use the time stamps. For my compatibility random unit, I won't use it, but rather use a Dos call, exactly like BP. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Problems with strings in GPC beta 971001
by Frank Heckenbach 29 Oct '97

29 Oct '97

Jesper Lund wrote: > MY MISTAKE! Read[ln] work correctly and never exceeds the string capacity, > and my problems are totally UNrelated to the missing range checks in some > string expressions that I mentioned in the original post. I'm calmed! :-) > ADVICE TO GPC USERS: > > If you add #0 to a string (in order to call functions in the C library), it > is a *very* good idea to use strings whose capacity (max length) are not > divisible by 4. In that case, at least one byte is "wasted" to achieve > 4-byte alignment, and adding #0 should not overwrite other variables. I'm not sure if it's a good idea to rely on such internal things. The alignment could be different from 4 on some systems. However, we have already discussed automatically making the array bigger than the capacity by 1 for exactly this reason. I hope it's not much work, Peter, so perhaps you can do this change until the next version (whereas the automatic String-CString conversions will follow later). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Portable random numbers
by Frank Heckenbach 29 Oct '97

29 Oct '97

Peter Gerwinski wrote: > If the quality of these random numbers can compete with those produced by > the GNU or BSD C library, and if there are no problems with copyright, I > would be happy to incorporate this code into GPC's run time library and to > implement BP's `Randomize' and `Random' for GPC on top of that (perhaps > with Frank's unit as a replacement for those who specify `--borland-pascal' > for 100% compatibility;-). I'd prefer not to build in my random functions, but rather leave them in a separate unit, perhaps system whose main use will be for 100% BP compatibility, anyway -- when GPC has built-in all the other stuff. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 29 Oct '97

29 Oct '97

The African Chief wrote: > I had a problem with it in TESTMEM.PAS in the new bpcompat. > However, I have since discovered that the problem lies in mixing > the use of "ExitProc", and "AddExitProc" in the same program. Use > one or the other, and the problem disappears. Use both == > infinite loop. I see. AddExitProc is the C function atexit which I don't know much about. However, I like the simple way of adding an exit proc (rather than messing with pointer as in BP's ExitProc), so I wrote a replacement for AddExitProc in pure Pascal which is quite possible. It's included below, it can be used as a separate unit or merged into the existing units. A demo programs follows. BTW: Rather than an EP procedural parameter (as in sysutils.pas) I use a BP procedural type. One difference is that for a procedural parameter, a local procedure could be passed, which is unwanted here (since a local procedure would rely on its outer procedures to be active which is not the case during the finalization). unit aep; interface type TProc = procedure; procedure AddExitProc (Proc: TProc); implementation type PProcList = ^TProcList; TProcList = record Next: PProcList; Proc: TProc end; var ProcList: PProcList = nil; procedure AddExitProc (Proc: TProc); var Temp: PProcList; begin Temp := ProcList; New (ProcList); ProcList^.Next := Temp; ProcList^.Proc := Proc end; to end do while ProcList<>nil do begin {$W-}var Temp: PProcList;{$W+} Temp := ProcList; ProcList := ProcList^.Next; Temp^.Proc; Dispose (Temp) end; end. program x; uses aep; procedure world; begin writeln('world!') end; procedure hello; begin write('Hello ') end; begin AddExitProc(world); AddExitProc(hello) end. > > > > Assign is built-in now, so you can remove it from system.pas. > > Actually, the CygWin32 version still does not have it Strange. Actually, the built-in Assign in the RTS (rts/rts-assign.p) is written in Pascal in just the same way as in system.pas, so I think it should compile on any platform. Is this just an omission, or are there any hidden problems? Or is the CygWin version an older binary distribution? Peter, Jan-Jaap? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

gpc on Windows NT
by Jim Brander 29 Oct '97

29 Oct '97

The executable gpc1.exe included in the Cygwin32 release 18 falls over with an exception without doing anything. Its date is 19/12/96, whereas the gcc compiler in the same release is dated 15/4/97. The source to allow recompiling and debugging gpc for NT is not included in the Cygwin cdk source. You do not provide binary for Intel-Windows NT at your ftp site. There is a file explaining the problems back at Build 14 and suggesting the Cygwin sources for gcc will not be usable for compiling gpc. Can you direct me to the appropriate source, or suggest location of executables compatible with Build 18. Sorry to bother you. Thanks Jim Brander

1 0

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 28 Oct '97

28 Oct '97

Bill Currie wrote: > On 27 Oct 97 at 8:50, Frank Heckenbach wrote: > > > I think I can do the RTS part, if you send me a patch for your > > changes, along with a short description about how you did it. > > I'll have to sort though my mods to bring them up to date with the > latest beta. Fine! Don't hurry, I've got some other programming to do currently... > > - After calling an I/O function, if {$I+} is turned on, the calling > > program > > must check InOutRes. The code to be generated (perhaps you've > > already done so) would look like "if InOutRes<>0 then _p_ioerror;" > > where _p_ioerror will be a RTS function I can provide. (The check > > "if InOutRes<>0" could also be done in the function (like in BP!), > > but that's inefficient, because the function has to be called > > after each I/O operation then.) > > Actually, that's almost exactly what my mods do. If IO checking is > enabled ( {$I+} ), a proceedure taking no parameters is called that > would check the InOutRes state (though I used a different name) and > if it's set dumps a dirty message and aborts the program. I might modify this procedure a bit to use the (current) standard way of handling runtime errors (_p_generic and such), but this shouldn't be a problem. However, if you could move the check into the program, this would gain some efficiency. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: gpc on Linux
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Tomaz kolenko: > When compiling pas files with gpc I get a message: > cannot open -lgpc: No such file or directory > Version of gpc and gcc is 2.7.2.1 This looks like an installation problem. Please make sure that GPC can locate the file `libgpc.a'. It should be together with `gpc1' and `gpc-cpp' in a directory `/usr/lib/gcc-lib/i586-unknown-linux/2.7.2.1/'. Alternatively, you can keep `libgpc.a' in a directory in your library path, for example in `/usr/local/lib/'. If all this fails, please run `gpc' on your program with the `-v' option and post the output here. 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: String types in future GPC versions
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Jesper Lund: > According to myself (Peter Gerwinski): > >According to Extended Pascal, strings are written with parentheses > >("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax > >("Str255 = String [ 255 ]"). In the future we *might* change this such > >that GPC produces an Extended Pascal string (unlimited length, 8 bytes > >overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, > >1 byte overhead) with "[...]". > > Wouldn't that feature (choosing between two memory allocation/outline schemes > for strings) create a lot of problems for relatively little benefit? > > First, if I have a procedure with a var string type, > > procedure foo (var s : string) > > can I pass variables of either string type (Borland or Extended)? No, but you can pass them to Procedure Foo ( S: String ); or to Procedure Foo ( Const S: String ); > Second, a string variable in Borland Pascal does not contain information > about the maximum length (like the capacity field in GPC), so for procedures > that need this information (like Readln), the string capacity would have to > be passed as an implicit parameter (or am I missing something?). I thought about letting it overflow silently, but passing the capacity as an implicit parameter would be a good idea, indeed. > Finally, and most importantly, why is feature this needed in the first place? > [...] > > 1) A program reading string variables from a binary file created by a > Borland pascal program (.exe file). [...] I agree that this would not really be an issue. > 2) GPC "wastes" more memory than Borland Pascal [...]. This is one reason why I think that `ShortString's are desirable. The 8 bytes do certainly not matter in, say, a text processor handling strings with a typical length of 100; they do matter in a program that handles a large number of short strings with a typical length of 8. In this second case, an overhead of 8 bytes would double the needed amount of memory. But I'd like to add: 3) There are many programs written for Borland Pascal and/or Delphi waiting to be ported to GPC, many of which relying on the data format of strings in UCSD/Borland Pascal/Delphi in merely two cases: (a) explicit manipulations of `S [ 0 ]' (one may consider them broken, but they are *many*)-:, and (b) calculations of the current size as `length ( S ) + 1'. There already was a discussion about a `ShortString' type for GPC on this list in May 1997. The conclusion was to make it compatible to Borland's `String' type like other Extended Pascal compilers and Delphi do. 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]

1 0

Re: us_Timer in TimeStamp
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Kevin A. Foss: > > Well the proposal in the GPC docs also adds a TimerValid field, just > set that to False if the system doesn't support gettimeofday(), which > is already checked for in rts-time.c. Yes, that would be straightforward. Shouldn't the field better be called `us_TimerValid'? 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: rand unit (was: us_Timer in TimeStamp)
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Kevin A. Foss: > > IMHO, this code is still broken. On a non-DOS platform it tries to > pass an integer to a function expecting a cardinal and always returns a > type check error and doesn't compile. Uh - sorry! #-) GPC checks whether the return type of the function matches the expected parameter, and if that's not the case, it tries to pass the function itself as a parameter. It should check whether the return type of the function *is assignment compatible* with the type of the expected parameter ... I am noting this as a GPC bug report (kevin1.pas). However one can work around this by letting `GetPID' return a `Cardinal' instead of an `Integer' thus disallowing negative PIDs. 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: Portable random numbers
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >IMHO, this code is still broken. On a non-DOS platform it tries to > >pass an integer to a function expecting a cardinal and always returns a > >type check error and doesn't compile. Is there some advanced switch > >that should be used in situations like this to turn off type-checking > >(I've never really looked at all of the directives and didn't see where > >they were in the docs after a quick look) and the type-casting section > >is empty. > > > >The code in question: > >FUNCTION Rand:Integer; C; > >PROCEDURE SRand(Seed:Cardinal); C; > >FUNCTION GetPID:Integer; C; > > > > Regarding portability: in my DJGPP C library, there is no `srand' function, > but a `srandom' function which expects an int (=Integer) as parameter. Hold it, please! The code fragment you're quoting is inside an $ifdef. It's not used in DJGPP. Please refer to the complete unit. I posted it here recently, and I'll make it available under the following URL tomorrow or so: http://home.pages.de/~fjf/rand.pas > I don't see how this should emulate the Randomize procedure in Borland > Pascal. The DJGPP code does so, and that's all I claimed. On non-Dos systems, it's almost impossible to emulate BP's behaviour since it depends on the internal system timer format used by Dos. I now added a comment to the unit making this clear. > According the info docs for my C library, getpid returns the unique > process number for the program running on the system. If you call getpid > twice in the same program, you get the same integer. (* This can happen (with Randomize) in BP, too, if within the same 1/18.2 seconds interval. Therefore, doing so is not recommended! *) > Why not compute a seed > from the system time (somehow), as Borland Pascal does? If you tell me how to do it, I'd like to! To do it "good", we'd need more than 1 second resolution, and getting this was the original problem here... > That is, if we need a Randomize procedure at all? My C library (DJGPP) > doesn't have such a beast. Ok, there is Borland compatibility .... Well, there must be any way to seed the Random randomly... :-) Otherwise, the program would produce the same sequence of random numbers in each run. AFAIK, the usual way to do so in C under Unix is GetPID, therefore I did it like that. A better general way would be most welcome. > I use random numbers a great deal in my work (statistical simulations), and > in most cases (if not all) I specify the seed myself, since this is the only > way of gettting reproducible results. There'd be no problem doing so with my unit (though it should not be used here, because it's only for BP compatibility). OTOH, I'd guess, most game programmers wouldn't like this behaviour... ;-) > When I was programming in Turbo Pascal (the pre-GPC era), I *never* used the > Random function in the system unit because I did not have source code and > thus couldn't see how the pseudo-random sequence was generated. There are a > lot of bad (= non-random) random number generators out there! True. BTW, my unit uses the same algorithm (though, of course, completely different code) as BP (7.0 at least). Now you can check if it's a good algorithm. The main formula is: RandSeed := $8088405 * RandSeed + 1 {mod 2^32} > The following piece of code represents a widely used procedure for generating > uniform random numbers (reals between 0.0 and 1.0), but it could easily be > changed to generating integers between 0 and 2^31-1 (just modify the last > line in RanUni). > > The routine is portable to all systems with a 32-bit integer type. It does > not rely on controlled overflow which may not be portable. The technically > inclined can consult the reference given in the comments. BTW, GPC users > familiar with the book(s) `Numerical Recipes' may be interested in knowing > that the `ran04 routine in the latest (2nd) edition (C only; not Pascal) > corresponds to the algorithm below. Thanks for the code! If it's not copyrighted/patented, we can perhaps use it for a built-it Random function in GPC. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Frank Heckenbach 28 Oct '97

28 Oct '97

Kevin A. Foss wrote: > On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: > > >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > >which implements a `random' and a `randomize' function just this > >way. You can extract it from the GPC mailing list archives (see > >http://home.pages.de/~GNU-Pascal/support.html) or download it from > >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. > > IMHO, this code is still broken. True, to some extent. See my previous mail. > On a non-DOS platform it tries to > pass an integer to a function expecting a cardinal and always returns a > type check error and doesn't compile. Assigning an integer to a cardinal is *NOT* a type check error, since the different integer types are assignment compatible. It could cause a range check error -- as soon as range checking will be implemented in GPC. The fact that GPC does report an "incompatible type" here (it didn't in earlier versions, otherwise I'd have noted when I wrote the unit), is indeed a bug in GPC. I'll add it to the bugs section of the To-Do list. Thanks for the (accidental ;-) bug report! Here is a short example program for this bug. This program should compile, but currently doesn't (it works, however, when I replace the functions v and w by variables): program x; procedure a(v:integer;w:cardinal); begin writeln(v,' ',w) end; function v:cardinal; begin v:=1 end; function w:integer; begin w:=2 end; begin a(v,w) end. > Is there some advanced switch > that should be used in situations like this to turn off type-checking > (I've never really looked at all of the directives and didn't see where > they were in the docs after a quick look) and the type-casting section > is empty. Turning off type checking in general would be a bit much, but type casting is indeed the right thing to do. Type casting works like - variable type casting: TypeName ( Variable or reference expression {"lvalue"} ) - value type casting (for ordinal and real type values): TypeName ( expression ) > SRand(GetPID); So change this line to: SRand(Cardinal(GetPID)); -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: String types in future GPC versions
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >According to Extended Pascal, strings are written with parentheses > >("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax > >("Str255 = String [ 255 ]"). In the future we *might* change this such > >that GPC produces an Extended Pascal string (unlimited length, 8 bytes > >overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, > >1 byte overhead) with "[...]". > > > > Wouldn't that feature (choosing between two memory allocation/outline schemes > for strings) create a lot of problems Yes. > for relatively little benefit? I don't think so. > First, if I have a procedure with a var string type, > > procedure foo (var s : string) > > can I pass variables of either string type (Borland or Extended)? No. But we're discussing something like "AnyString" parameters for which you will be able to pass any string type. First of all, there are already now three different string types in GPC, namely the (EP) string schema, the (SP/BP) arrays of char and the "CStrings" (necessary for interfacing with C functions, esp. system functions). These string types are already handled in some places (e.g. the Read/Write functions), and will have to be handled in other places, too. So what we're talking about here is actually the introduction of a fourth string type... Since the distinction between the string types is a lot of work, and often a bit chaotic, we're looking for ways to simplify things. I hope, the AnyString parameters will be such a way. If things go as I hope, the distinction will only have to be done at a few places in the compiler rather than in each procedure operating on strings. When we aachive this for the three existing string types, adding a fourth one should not be so much work. So, we're not overly keen on doing this work, but it seems inevitable. > Second, a string variable in Borland Pascal does not contain information > about the maximum length (like the capacity field in GPC), so for procedures > that need this information (like Readln), the string capacity would have to > be passed as an implicit parameter (or am I missing something?). You're right. But it's the same for arrays of char and CStrings, where the capacity is passed separately already now. In the future, the AnyString parameters should cater for this. > Finally, and most importantly, why is feature this needed in the first place? > The Extended Pascal string concept is more powerful that the Borland one (as > it stores the string capacity in a field which my procedure `foo' can > access). However, the extra features of GPC (capacity field, and strings > larger than 255 bytes) are *extensions* compated to Borland Pascal, so any > Borland code with string manipulations should compile under GPC, and the > binary (program) should produce the same results. Not any code, unfortunately. It's not uncommon in BP to manipulate the string length by accessing "s[0]", lacking a proper way to access the length. (GPC will soon provide a better way in the form of "AssignLength", working on all string types...) (You might say that directly accessing the length should not be done in a good program, but it's necessary for efficiency, e.g. in order to append one character to a string. The proper way "s := s + ch" will produce code that copies the whole string around at least twice, in BP as well as (currently) in GPC.) Another example would be dynamically allocating strings of varying length in BP which is usually done (again, lacking a better way) with statements like: New(p,Length(s)+1); p^:=s; To make such statements work under GPC, it's important to have the exact string type as BP does. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Frank Heckenbach 28 Oct '97

28 Oct '97

Peter Gerwinski wrote: > According to Thomas Tan: > > Are you guys going to implement us_Timer field of TimeStamps soon? > > If you tell us how to do that in a portable way - at once! ;-) > > > I need a seed for a random function and this seems to be the best way to go. > > On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > which implements a `random' and a `randomize' function just this > way. Sorry, but this is probably not the best thing to look at. First of all, it's not portable (it uses the system time under DJGPP, the process ID on other systems where available, and doesn't appear to work under EMX). Then, the unit (and especially the random algorithms and data sizes) are particularly for compatibility with BP's random generator, nothing else. So, a portable way to get fractions of a second would be a fine thing (micro seconds will not always be possible; under Dos, e.g., the resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Jesper Lund 28 Oct '97

28 Oct '97

> >So, a portable way to get fractions of a second would be a fine thing >(micro seconds will not always be possible; under Dos, e.g., the >resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... > If we forget about portability for a minute, under DOS (DJGPP) there is a libc function, uclock (), which provides (very) high-resolution timing. Jesper Lund

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Kevin A. Foss 28 Oct '97

28 Oct '97

On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list >which implements a `random' and a `randomize' function just this >way. You can extract it from the GPC mailing list archives (see >http://home.pages.de/~GNU-Pascal/support.html) or download it from >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. IMHO, this code is still broken. On a non-DOS platform it tries to pass an integer to a function expecting a cardinal and always returns a type check error and doesn't compile. Is there some advanced switch that should be used in situations like this to turn off type-checking (I've never really looked at all of the directives and didn't see where they were in the docs after a quick look) and the type-casting section is empty. The code in question: FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

2 1

Re: us_Timer in TimeStamp
by Kevin A. Foss 28 Oct '97

28 Oct '97

On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: >According to Thomas Tan: >> Are you guys going to implement us_Timer field of TimeStamps soon? > >If you tell us how to do that in a portable way - at once! ;-) Well the proposal in the GPC docs also adds a TimerValid field, just set that to False if the system doesn't support gettimeofday(), which is already checked for in rts-time.c. gettimeofday() should be available for any system that supports BSD and/or glibc library calls. Other systems could provide their own calls in #ifdef blocks if they want the feature. I just don't see why 100% portability is important when you already have a field that tells the programmer if he can trust the results to be valid. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Problems with strings in GPC beta 971001
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > I have encountered a couple problems with strings in the most recent GPC beta > version. Most of the problems are due to missing range checks, e.g. when > assigning a string to a shorter string, or passing a string to a procedure > with a shorter string as formal parameter. > > 1) The program below illustrates some of these problems: Yes, this is a known bug. I think it will be solved soon. > 2) Another facet of the problem occurs when reading strings from a text file > with Read[ln] (F, stringVar). > > If you call Readln, the program will read from the file until the next CR/LF, > no matter the size (length) of stringVar, and try to copy the entire line to > the variables stringVar (which will almost surely crash the program somehow; > but not necessarily in the call to Readln. The SIGSEGV exception could come > later, and with a stack trace which makes no sense). Strange! There has always been a check for the maximum length in the read[ln] procedure. > On the other hand, Read (F, stringVar) only reads a maximum of > Length(stringVar) characters [as it should]. Even more strange, since Read and Readln are actually the same procedure (or rather function) internally. Readln (F, stringVar) first does exactly the same as Read (F, stringVar), and then a Readln (stringVar). Perhaps something was broken temporarily while I changed other things in the Read/Write procedures. OTOH, the following program works correctly (i.e. outputs only 5 characters, even if I type more than 5) on my Linux GPC (which has been modified somewhat after 971001) as well as on my DJGPP GPC (which is the original 971001 binary distribution): program x; var s:string(5); begin readln(s); writeln(s) end. Perhaps you did some other thing in your program that triggered the first bug? If not, please send me a program and sample input to show this problem. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Strings in GPC (was: GPC question)
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Jesper Lund: > > GPC is under development, and so is the documentation. Therefore, AFAIK, > there is no *complete* list of the built-in functions. The GNU Texinfo online documentation of recent beta versions of GPC contains a complete list of all built-in identifiers - most of them without explanation, sorry, but it's a start. > Regarding your second question, I think you need to define a string type, > like > > type > str255 = string [255]; Correct. If you say "Function Foo: String", GPC accepts it as a string of length 255 but warns about it (unless you are in `--borland-pascal' mode). According to Extended Pascal, strings are written with parentheses ("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax ("Str255 = String [ 255 ]"). In the future we *might* change this such that GPC produces an Extended Pascal string (unlimited length, 8 bytes overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, 1 byte overhead) with "[...]". 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]

2 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 28 Oct '97

28 Oct '97

Bill Currie wrote: > On 23 Oct 97 at 10:43, Peter Gerwinski wrote: > > > According to Jesper Lund: > > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > > > compiler directive in Borland Pascal? [...] > > > > Not yet, but it is being worked on. (Interested to take part?;-) > > Agh, does that mean I have to pull my finger out? > > I think I've got the compiler side working in an older beta, but the > rtl has to be modified to support it. I think I can do the RTS part, if you send me a patch for your changes, along with a short description about how you did it. I'd imagine I'll do it as follows: - Whenever an I/O function encounters an error condition, it sets InOutRes to the according error code (which will, of course, *not* be the same as in BP ;-), and return in a clean state. (The latter is the difficult bit; I've already done so for the Read/Write procedures, but I expect there will be more to do so that the program can continue safely.) - At the start, each I/O function checks InOutRes, and if <>0, returns immediately, doing nothing. (Like BP does.) - After calling an I/O function, if {$I+} is turned on, the calling program must check InOutRes. The code to be generated (perhaps you've already done so) would look like "if InOutRes<>0 then _p_ioerror;" where _p_ioerror will be a RTS function I can provide. (The check "if InOutRes<>0" could also be done in the function (like in BP!), but that's inefficient, because the function has to be called after each I/O operation then.) Does this seem OK to you, or to anyone else? Any comments? One question is what kind of errors is to be considered as I/O errors. E.g., overflowing the destination string length in WriteStr, if the automatic truncating of strings (an option that will be introduced soon) is turned off, is this an I/O error or rather a "generic" (string) error? Any opinions? If there are more cases of doubt, I'll ask them here, too, when I find them. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

gpc on Linux
by tomko＠tt62.ntfmim.uni-lj.si 27 Oct '97

27 Oct '97

When compiling pas files with gpc I get a message: cannot open -lgpc: No such file or directory Version of gpc and gcc is 2.7.2.1 Can somebody help? T.Kolenko

1 0

Re: Re: Need help.......
by OHMH＠nets.com.jo 27 Oct '97

27 Oct '97

Ron Perrella,perrella(a)mindspring.com,Internet writes: > * > * And how to access the program parameters from an ASM program. > > Thanx for your help > Hi I don't know what you mean by parameters but if you mean procedure and function parameters then read this if you mean command line then this will not the answer : - Procedure Putpix ( x , y : word ; c : byte ); Assembler ; Asm Push x Push y Push c . . . . End; That was on Borland Pascal , but on Gnu I don't know how asm look like but I think it will be better because 386 instruction support ; but in pure X86 assembler you must use registers , Good luck .

1 0

Re: us_Timer in TimeStamp
by Peter Gerwinski 27 Oct '97

27 Oct '97

According to Thomas Tan: > Are you guys going to implement us_Timer field of TimeStamps soon? If you tell us how to do that in a portable way - at once! ;-) > I need a seed for a random function and this seems to be the best way to go. On 21 September, Frank Heckenbach posted a Unit `Rand' to this list which implements a `random' and a `randomize' function just this way. You can extract it from the GPC mailing list archives (see http://home.pages.de/~GNU-Pascal/support.html) or download it from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. 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: Error in Beta version (100197)
by Frank Heckenbach 27 Oct '97

27 Oct '97

Thomas Tan wrote: > I get the following error when I try to compile this program in GPC beta > (100197) for DJ > Compiling: assign7Sort.pas > gpi-hash.c(321) Error: failed assertion `ss.key == -DEBUG_HASH_KEY' > Abort! At the moment I'm only guessing, but I got the same error messages when I was trying to use a unit compiled with an older GPC version. The .gpi files (precompiled unit interfaces) are not compatible between different GPC versions, and unfortunately (currently), GPC does not warn about this problem, but cause this error message. So just recompile everything, and it ought to work. (However, when recompiling system, you might encounter another problem causing a segmentation fault in GPC. If so, you can temporarily solve it by commenting out the initialization code related to CmdLine and PPJunk.) > This is a bug report for RHIDE Version 1.4 (Sep 30 1997 23:06:59) > I am running MS-DOS 7.10 (Windows 95) BTW: AFAIK, this bug report form is to be used for bugs in RHIDE itself, not for bugs in a compiler (GPC) that are not related to RHIDE... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Error in Beta version (100197)
by Thomas_Tan＠fc.choate.edu 27 Oct '97

27 Oct '97

I get the following error when I try to compile this program in GPC beta (100197) for DJ Compiling: assign7Sort.pas gpi-hash.c(321) Error: failed assertion `ss.key == -DEBUG_HASH_KEY' Abort! This program compiled fine under the 2.0 verison of GPC, this program does use BPcompat. The source of this program is attached to this message (open it in Rhide if you want to "see" the line breaks) and I also attached the output of the bug-report-generator from Rhide. Good thing I backed up my GPC 2.0 before I installed the beta version :-) I hope you can find out what's wrong. Thanks, Tom ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492 begin 0666 assign7Sort.pas M<')O9W)A;2!T:6UE=&5S="AI;G!U="QO=71P=70I.R!U<V5S('-Y<W1E;3L- M"F-O;G-T($U!6"`](#4P.PT*#0IT>7!E#0H@4&AR87-E5%E012`](&%R<F%Y M(%LQ+BY-05A=(&]F(&EN=&5G97([#0H-"E-O<G1S(#T@;V)J96-T#0H@("`@ M(&-O;G-T<G5C=&]R($EN:70[#0H@("`@('!R;V-E9'5R92!$;U-O<G0H=F%R M($1A=&$Z4&AR87-E5%E012D[('9I<G1U86P[#0H@("`@('!R;V-E9'5R92!4 M96QL3F%M93MV:7)T=6%L.PT*96YD.PT*#0I"=6)3;W)T(#T@;V)J96-T*%-O M<G1S*0T*("`@("!C;VYS=')U8W1O<B!);FET.PT*("`@("!P<F]C961U<F4@ M1&]3;W)T*'9A<B!$871A.E!H<F%S95194$4I.R!V:7)T=6%L.PT*("`@("!P M<F]C961U<F4@5&5L;$YA;64[=FER='5A;#L-"F5N9#L-"DEN<U-O<G0@/2!O M8FIE8W0H4V]R=',I#0H@("`@(&-O;G-T<G5C=&]R($EN:70[#0H@("`@('!R M;V-E9'5R92!$;U-O<G0H=F%R($1A=&$Z4&AR87-E5%E012D[('9I<G1U86P[ M#0H@("`@('!R;V-E9'5R92!496QL3F%M93MV:7)T=6%L.PT*96YD.PT*4V5L M4V]R="`](&]B:F5C="`H4V]R=',I#0H@("`@(&-O;G-T<G5C=&]R($EN:70[ M#0H@("`@('!R;V-E9'5R92!$;U-O<G0H=F%R($1A=&$Z4&AR87-E5%E012D[ M('9I<G1U86P[#0H@("`@('!R;V-E9'5R92!496QL3F%M93MV:7)T=6%L.PT* M96YD.PT*('!3;W)T<R`](%Y3;W)T<SL-"B!P0G5B4V]R="`](%Y"=6)3;W)T M.PT*('!396Q3;W)T(#T@7E-E;%-O<G0[#0H@<$EN<U-O<G0@/2!>26YS4V]R M=#L-"@T*#0I605(@5&EM94]F4W1A<G1I;F<Z(&EN=&5G97([#0IA0G5B4V]R M=#IP0G5B4V]R=#L-"F%396Q3;W)T.G!396Q3;W)T.PT*84EN<U-O<G0Z<$EN M<U-O<G0[#0H-"F9U;F-T:6]N(%1I8VM#;W5N=#II;G1E9V5R.PT*=F%R(&1T M.E1I;653=&%M<#L-"F)E9VEN#0H@("`@($=E=%1I;653=&%M<"AD="D[#0H@ M("`@(%1I8VM#;W5N="`Z/2`H9'0N:&]U<BHS-C`P("L@9'0N;6EN=71E*C8P M("L@9'0N<V5C;VYD*3L-"F5N9#L-"@T*#0I[#0IQ=6%S:5-O<G0Z(')E='5R M;G,@86X@87)R87D@;V8@:6YT96=E<G,@;V8@<VEZ92!L:6UI="!I;B!W:&EC M:"!A;B!I;G1E<G9A;"!O9B!N=6UB97)S#0IA<F4@<F%N9&]M+B`@92YG+B!I M9B!L:6UI="!W97)E(#$P,"!A;F0@:6YT97)V86P@=V5R92`Q,"P@=&AE(&9I M<G-T(#$P(&5N=')I97,-"G=O=6QD(&)E(')A;F1O;2`C)W,@8F5T=V5E;B`Q M(&%N9"`Q,#L@=&AE('-E8V]N9"!I;G1E<G9A;"!W;W5L9"!B92!R86YD;VT@ M(R=S#0IB971W965N(#$Q(&%N9"`R,"P@971C+BXN#0I);G!U=#H@('-E960@ M("`@("`@("`@("!I;G1E9V5R("`@("`@("`@<V5E9"!T;R!S=&%R="!R86YD M;VT@9V5N97)A=&]R#0IL:6UI="`@("`@("`@("`@:6YT96=E<B`@("`@("`@ M('-I>F4@;V8@87)R87D-"FEN=&5R=F%L("`@("`@("!I;G1E9V5R("`@("`@ M("`@=VAA="!I;G1E<G9A;"!R86YG92!I<PT*4F5T=7)N<SH@26YT07)Y("`@ M("`@("`@=&AE('%U87-I+7-O<G1E9"!A<G)A>7T-"@T*9G5N8W1I;VX@<75A M<VE3;W)T*'9A<B!S965D.FEN=&5G97([(&EN=&5R=F%L.FEN=&5G97([(&QI M;6ET.FEN=&5G97(I.E!H<F%S95194$4[#0IV87(@(')A;F0L:2QJ+&EN9&5X M.FEN=&5G97([(&%R>3I0:')A<V5465!%.V)E9VEN(&EN9&5X.CTQ.PT*9F]R M(&D@.CT@,2!T;R`H;&EM:70@9&EV(&EN=&5R=F%L*2!D;R!B96=I;@T*("`@ M(&9O<B!J(#H](#$@=&\@:6YT97)V86P@9&\@8F5G:6X-"B`@("`@($EN:712 M86YD;VTH<V5E9"D[#0H@("`@("!R86YD(#H](%)A;F1);G0H:6YT97)V86PI M.PT*("`@("`@87)Y6VEN9&5X73H]*"AI+3$I*FEN=&5R=F%L*2`K(')A;F0[ M#0H-"B`@("`(a)(&EN9&5X.CUI;F1E>"LQ.PT*("`@("`(a)96YD.PT*("`@("`@ M96YD.PT*("`@("`@<75A<VE3;W)T.CUA<GD[#0H@("`@("!E;F0[#0H-"B`@ M("`@('!R;V-E9'5R92!1=6%S:5)A;F1O;5-O<G0H=F%R($$Z(%!H<F%S9519 M4$4I.PT*=F%R(&DL:BQK.FEN=&5G97([#0I"96=I;@T*>PEF;W(@:2`Z/2`Q M('1O($U!6"!D;PT*"0E!6VE=(#H](%)A;F1);G0H,3`P,#`I.R!]#0H-"B`@ M('MC87-E($U!6"!O9@T*("`@-3`Z("!B96=I;GT-"B`@("`@("`@("`@("!J M(#H](#`[#0H@("`@("`@("`@("`@9F]R(&D@.CT@,2!T;R`U(&1O(&)E9VEN M#0H@("`@("`@("`@("`@("`@(&9O<B!K(#H]("AI*C$P("TY*2!T;R`H:2HQ M,"D@9&\@8F5G:6X-"B`@("`@("`@("`@("`@("`@("`@($EN:71286YD;VTH M5&EC:T-O=6YT*3L-"B`@("`@("`@("`@("`@("`@("`@($%;:UT@.CT@4F%N M9$EN="@Q,#`P*2`K(&H[#0H@("`@("`@("`@("`@("`@(&5N9#L-"B`@("`@ M("`@("`@("!J(#H](&H(a)*R`Q,#`P.PT*("`@("`@("`@("`@(&5N9#L-"@T* M96YD.PT*#0H-"G!R;V-E9'5R92!286YD;VU$871A*'9A<B!!.B!0:')A<V54 M65!%*3L-"G9A<B!I.FEN=&5G97([#0I"96=I;@T*"69O<B!I(#H](#$@=&\@ M34%8(&1O#0H)"4%;:5T@.CT@4F%N9$EN="@Q,#`P,"D[#0H-"D5.1#L-"@T* M>RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*DEM<&QE;65N=&%T:6]N(&]F(%-O<G0@ M3V)J96-T<RHJ*BHJ*BHJ*BHJ*BHJ*BHJ?0T*#0IC;VYS=')U8W1O<B!3;W)T M<RY);FET.PT*8F5G:6X-"F5N9#L-"F-O;G-T<G5C=&]R($)U8E-O<G0N26YI M=#L-"F)E9VEN#0IE;F0[#0IC;VYS=')U8W1O<B!396Q3;W)T+DEN:70[#0IB M96=I;(a)T*96YD.PT*8V]N<W1R=6-T;W(@26YS4V]R="Y);FET.PT*8F5G:6X- M"F5N9#L-"@T*<')O8V5D=7)E(%-O<G1S+E1E;&Q.86UE.PT*8F5G:6X-"G=R M:71E*"=3;W)T<R!496QL($YA;64@0V%L;&5D+"!"040G*3L-"F5N9#L-"@T* M<')O8V5D=7)E($)U8E-O<G0N5&5L;$YA;64[#0IB96=I;@T*=W)I=&4H)T)U M8F)L92!3;W)T)RD[#0IE;F0[#0H-"G!R;V-E9'5R92!396Q3;W)T+E1E;&Q. M86UE.PT*8F5G:6X-"G=R:71E*"=396QE8W1I;VX@4V]R="<I.PT*96YD.PT* M#0IP<F]C961U<F4@26YS4V]R="Y496QL3F%M93L-"F)E9VEN#0IW<FET92@G M26YS97)T(%-O<G0G*3L-"F5N9#L-"@T*<')O8V5D=7)E(%-O<G1S+D1O4V]R M="`H=F%R($1A=&$Z4&AR87-E5%E012D[#0IB96=I;@T*=W)I=&5L;B@G4V]R M=',@4V]R="!C86QL960L($)!1$0G*3L-"F5N9#L-"@T*<')O8V5D=7)E(%-E M;%-O<G0N1&]3;W)T("AV87(@1&%T83H@(%!H<F%S95194$4I.PT*("![57-E M<R!T:&4@<V5L96-T:6]N('-O<G0@86QG;W)I=&AM('1O(&]R9&5R(&%N(&%R M<F%Y(&]F(&-H87)A8W1E<G,N?0T*#0H@('9A<B!&:7)S="P@0W5R<F5N="P@ M3&%R9V5S="P@0V]M<&%R:7-O;G,L(%-W87!S.B`@:6YT96=E<CL-"B`@("`@ M(%1E;7`Z("!I;G1E9V5R.PT*#0H@(&)E9VEN#0H@("`@0V]M<&%R:7-O;G,@ M.CT@,#L-"B`@("!3=V%P<R`Z/2`P.PT*("`@(&9O<B!&:7)S="`Z/2`Q('1O M($U!6"`M(#$@9&\@8F5G:6X-"B`@("`@($QA<F=E<W0@.CT@1FER<W0[#0H@ M("`@("!F;W(@0W5R<F5N="`Z/2!&:7)S="`K(#$@=&\@34%8(&1O(&)E9VEN M#0H@("`@("`@('M$;VXG="!B;W1H97(@8V]M<&%R:6YG('1H92!F:7)S="!C M;VUP;VYE;G0@=&\@:71S96QF+GT-"B`@("`@("`@0V]M<&%R:7-O;G,@.CT@ M0V]M<&%R:7-O;G,@*R`Q.PT*("`@("`@("!I9B!$871A(%M#=7)R96YT72`^ M($1A=&$@6TQA<F=E<W1=('1H96X@8F5G:6X-"B`@("`@("`@("!,87)G97-T M(#H]($-U<G)E;G0-"B`@("`@("`@96YD#0H@("`@("!E;F0[("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M('M#=7)R96YT(&9O<GT-"B`@("`@('M0;W-T8V]N9&ET:6]N.B`@3&%R9V5S M="!S=6)S8W)I<'1S('1H92!L87)G97-T(&ET96T@9G)O;2!&:7)S="`N+B!- M05@N?0T*("`@("`@:68@3&%R9V5S="`\/B!&:7)S="!T:&5N(&)E9VEN("`@ M("`@("`@("`@("`@("![5V4@:&%V92!T;R!M86ME(&$@<W=A<"Y]#0H@("`@ M("`@(%-W87!S(#H](%-W87!S("L@,3L-"B`@("`@("`@5&5M<"`Z/2!$871A M(%M,87)G97-T73L-"B`@("`@("`@1&%T82!;3&%R9V5S=%T@.CT@1&%T82!; M1FER<W1=.R`@("`@("`@("`@("`@("`@("`@("`@>TUA:V4@=&AE('-W87`N M?0T*("`@("`@("!$871A(%M&:7)S=%T@.CT@5&5M<`T*("`@("`@96YD("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("![:69]#0H@("`@("![4&]S=&-O;F1I=&EO;CH@ M(#$@=&AR;W5G:"!&:7)S="!S=6)S8W)I<'0@=&AE(&%R<F%Y)W,@;&%R9V5S M="!V86QU97,N?0T*("`@(&5N9#L@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@('M&:7)S="!F;W)] M#0H@('L@('=R:71E("A#;VUP87)I<V]N<R`Z(#$I.R`@('=R:71E("@G(&-O M;7!A<FES;VYS+"`G*3L-"B`@("!W<FET92`H4W=A<',@.B`Q*3L@("!W<FET M96QN("@G('-W87!S+B<I("`@?0T*("!E;F0[("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M('M396QE8W1]#0H-"G!R;V-E9'5R92!);G-3;W)T+D1O4V]R="AV87(@1&%T M83H@(%!H<F%S95194$4I.PT*("![57-E<R!T:&4@:6YS97)T:6]N('-O<G0@ M86QG;W)I=&AM('1O(&]R9&5R(&%N(&%R<F%Y(&]F(&-H87)A8W1E<G,N?0T* M#0H@('9A<B!.97=E<W0L($-U<G)E;G0L($-O;7!A<FES;VYS+"!3=V%P<SH@ M(&EN=&5G97([#0H@("`@("!.97=)=&5M.B`@:6YT96=E<CL-"B`@("`@(%-E M96MI;F<Z("!B;V]L96%N.PT*#0H@(&)E9VEN#0H@("`@0V]M<&%R:7-O;G,@ M.CT@,#L-"B`@("!3=V%P<R`Z/2`P.PT*("`@("`@("!F;W(@3F5W97-T(#H] M(#(@=&\@34%8(&1O(&)E9VEN#0H@("`@("`@("`@4V5E:VEN9R`Z/2!44E5% M.PT*("`@("`@("`@($-U<G)E;G0@.CT@3F5W97-T.PT*("`@("`@("`@($YE M=TET96T@.CT@1&%T82!;3F5W97-T73L-"B`@("`@("`@("!W:&EL92!3965K M:6YG(&1O(&)E9VEN#0H@("`@("`@("`@("!#;VUP87)I<V]N<R`Z/2!#;VUP M87)I<V]N<R`K(#$[#0H@("`@("`@("`@("!I9B`H1&%T82!;0W5R<F5N="`M M(#%=(#P@3F5W271E;2D@=&AE;B!B96=I;@T*("`@("`@("`@("`@("!$871A M(%M#=7)R96YT72`Z/2!$871A(%M#=7)R96YT("T@,5T[("`@>U-L:61E(&$@ M=F%L=64@=&\@=&AE(')I9VAT+GT-"B`@("`@("`@("`@("`@4W=A<',@.CT@ M4W=A<',(a)*R`Q.PT*("`@("`@("`@("`@("!#=7)R96YT(#H]($-U<G)E;G0@ M+2`Q.PT*("`@("`@("`@("`@("!3965K:6YG(#H]($-U<G)E;G0@/B`Q#0H@ M("`@("`@("`@("!E;F0-"B`@("`@("`@("`@(&5L<V4@8F5G:6X@4V5E:VEN M9R`Z/2!&04Q312!E;F0[("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M>VEF?0T*("`@("`@("`@(&5N9#L@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("![=VAI;&5]#0H@("`@ M("`@("`@>U!O<W1C;VYD:71I;VXZ("!.97=)=&5M(&)E;&]N9W,@:6X@1&%T M82!;0W5R<F5N=%TN?0T*("`@("`@("`@($1A=&$@6T-U<G)E;G1=(#H]($YE M=TET96T-"B`@("`@("`@96YD.R`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@('M.97=E<W0@9F]R?0T*("`@ M("`@("!W<FET92`H0V]M<&%R:7-O;G,@.B`Q*3L@("!W<FET92`H)R!C;VUP M87)I<V]N<RP@)RD[#0H@("`@("`@('=R:71E("A3=V%P<R`Z(#$I.R`@('=R M:71E;&X@*"<@<W=A<',N)RD-"B`@("`@(&5N9#L@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("![ M26YS97)T?0T*#0H-"@T*<')O8V5D=7)E($)U8E-O<G0N1&]3;W)T("AV87(@ M1&%T83H@(%!H<F%S95194$4I.PT*("![57-E<R!T:&4@8G5B8FQE('-O<G0@ M86QG;W)I=&AM('1O(&]R9&5R(&%N(&%R<F%Y(&]F(&-H87)A8W1E<G,N?0T* M#0H@('9A<B!,87-T+"!#=7)R96YT+"!#;VUP87)I<V]N<RP@4W=A<',Z("!I M;G1E9V5R.PT*("`@("`@5&5M<#H@(&EN=&5G97([#0H-"B`@8F5G:6X-"B`@ M("!#;VUP87)I<V]N<R`Z/2`P.PT*("`@(%-W87!S(#H](#`[#0H@("`@9F]R M($QA<W0@.CT@34%8(&1O=VYT;R`R(&1O(&)E9VEN#0H@("`@("!F;W(@0W5R M<F5N="`Z/2`Q('1O($QA<W0@+2`Q(&1O(&)E9VEN#0H@("`@("`@($-O;7!A M<FES;VYS(#H]($-O;7!A<FES;VYS("L@,3L-"B`@("`@("`@:68@1&%T82!; M0W5R<F5N=%T@/"!$871A(%M#=7)R96YT*S%=('1H96X@8F5G:6X-"B`@("`@ M("`@("!3=V%P<R`Z/2!3=V%P<R`K(#$[#0H@("`@("`@("`@5&5M<"`Z/2!$ M871A(%M#=7)R96YT73L-"B`@("`@("`@("!$871A(%M#=7)R96YT72`Z/2!$ M871A(%M#=7)R96YT("L@,5T[#0H@("`@("`@("`@1&%T82!;0W5R<F5N="`K M(#%=(#H](%1E;7`-"B`@("`@("`@96YD("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@>VEF M?0T*("`@("`@96YD("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("![0W5R<F5N="!F;W)]#0H@("`@("![ M4&]S=&-O;F1I=&EO;CH@($-O;7!O;F5N=',@3&%S="!T:')O=6=H('1H92!E M;F0@;V8@=&AE(&%R<F%Y(&%R92!O<F1E<F5D+GT-"B`@("!E;F0[("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@>TQA<W0@9F]R?0T*("`@>R!W<FET92`H0V]M<&%R:7-O;G,@ M.B`Q*3L@("!W<FET92`H)R!C;VUP87)I<V]N<RP@)RD[#0H@("`@=W)I=&4@ M*%-W87!S(#H@,2D[("`@=W)I=&5L;B`H)R!S=V%P<RXG*7T-"B`@96YD.R`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("![0G5B8FQE?0T*#0IF=6YC=&EO;B!,:6YE87)3 M96%R8V@H=F%R($$Z(%!H<F%S95194$4[('1O1FEN9#II;G1E9V5R*3II;G1E M9V5R.PT*=F%R(&DL<&]S:71I;VXZ:6YT96=E<CL@9F]U;F0Z8F]O;&5A;CL- M"F)E9VEN#0H):2`Z/2`Q.PT*"69O=6YD(#H](&9A;'-E.PT*"7!O<VET:6]N M(#H]("TQ.PT*"7=H:6QE("A-05@@/CT@:2D@86YD("AF;W5N9"`](&9A;'-E M*2!D;R`-"@EB96=I;@T*"0EI9B!!6VE=(#T@=&]&:6YD('1H96X@#0H)"6)E M9VEN#0H)"0EF;W5N9"`Z/2!T<G5E.PT*"0D)<&]S:71I;VX@.CT@:3L-"@D) M96YD.PT*"65N9#L-"@D-"@E,:6YE87)396%R8V@@.CT@<&]S:71I;VX[#0H) M"0T*#0IE;F0[#0H-"F9U;F-T:6]N($)I;F%R>5-E87)C:"`H1&%T83H@(%!H M<F%S95194$4[=&]396%R8V@Z:6YT96=E<BDZ:6YT96=E<CL-"B`@>T)I;F%R M>2!S96%R8V@@9F]R($QE='1E<BX@(%)E='5R;G,@4&]S:71I;VX@/2`M,2!I M9B!N;W0@9F]U;F0N?0T*("!V87(@36ED9&QE+"!,;W=E<BP@57!P97(L('!O M<VET:6]N.B`@:6YT96=E<CL-"@T*("!B96=I;@T*("`@($QO=V5R(#H](#$[ M#0H@("`@57!P97(@.CT@34%8.PT*("`@(')E<&5A=`T*("`@("`@36ED9&QE M(#H]("A,;W=E<B`K(%5P<&5R*2!D:78@,CL-"B`@("`@(&EF('1O4V5A<F-H M(#P@1&%T82!;36ED9&QE70T*("`@("`@("!T:&5N(%5P<&5R(#H]($UI9&1L M92`M(#$-"B`@("`@("`@96QS92!,;W=E<B`Z/2!-:61D;&4@*R`Q#0H@("`@ M=6YT:6P@*$1A=&$@6TUI9&1L95T@/2!T;U-E87)C:"D@;W(@*$QO=V5R(#X@ M57!P97(I.PT*("`@('M0;W-T8V]N9&ET:6]N.B`@268@1&%T82!;36ED9&QE M72!I<VXG="!,971T97(L(&YO(&-O;7!O;F5N="!I<RY]#0H@("`@:68@1&%T M82!;36ED9&QE72`]('1O4V5A<F-H#0H@("`@("!T:&5N(%!O<VET:6]N(#H] M($UI9&1L90T*("`@("`@96QS92!0;W-I=&EO;B`Z/2`M,3L-"B`@("`@(`T* M("`@("!":6YA<GE396%R8V@@.CT@4&]S:71I;VX[#0H@(&5N9#L@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@>T)I;F%R>7T-"@T*#0I04D]#14154D4@4W1A<G14:6UE M.R`-"D)%1TE.(`T*("!4:6UE3V93=&%R=&EN9R`Z/2!4:6-K0V]U;G0[(`T* M14Y$.PT*#0I04D]#14154D4@1'5M;7E"=6)B;&53;W)T*'9A<B!$871A.B!0 M:')A<V5465!%*3L-"D)%1TE.#0I%3D0[#0H-"@T*#0I&54Y#5$E/3B!496QL M5&EM93H@:6YT96=E<CL-"E9!4B!&:6YI<VA4:6UE.B!I;G1E9V5R.R`-"D)% M1TE.(`T*($9I;FES:%1I;64@.CT@5&EC:T-O=6YT.PT*(%1E;&Q4:6UE(#H] M($9I;FES:%1I;64@+2!4:6UE3V93=&%R=&EN9SL-"D5.1#L-"@T*#0I04D]# M14154D4@1&]3;6%L;%)A;F1O;5-O<G0H=F%R('1H95-O<G0Z<%-O<G1S.R!V M87(@03I0:')A<V5465!%*3L-"G9A<B!P+$]V97)(96%D=&]T86Q4:6UE+&]V M97)H96%D+'1O=&%L5&EM93II;G1E9V5R.PT*($-O=6YT.FEN=&5G97([(`T* M#0H@8F5G:6X-"@D)4W1A<G14:6UE.PT*"0E&3U(@0V]U;G0@.CT@,2!43R`Q M,#`@1$\-"@D)0D5'24X-"B`@("`@("`@('`@.CT@5&EC:T-O=6YT.PT*"0D@ M("!!(#H]("!Q=6%S:5-O<G0H<"P@,3`L($U!6"D[#0H@"0D)"41U;6UY0G5B M8FQE4V]R="A!*3L-"@D)14Y$.PT*"4]V97)H96%D(#H](%1E;&Q4:6UE.PT* M#0H)4W1A<G14:6UE.PT*"49/4B!#;W5N="`Z/2`Q(%1/(#$P,"!$3PT*"0E" M14=)3@T*("`@("`@<"`Z/2!4:6-K0V]U;G0[#0H)"4$@.CT@('%U87-I4V]R M="AP+#$P+$U!6"D[.PT*(`E["69O<B!#;W5N="`Z/2`Q('1O($U!6"!D;PT* M(`D)"7=R:71E;&XH05M#;W5N=%TI.R`@?0T*#0H@"0D)=&AE4V]R=%XN1&]3 M;W)T*$$I.PT*(`D)"2`)>PEF;W(@0V]U;G0@.CT@,2!T;R!-05@@9&\-"B`) M"0EW<FET96QN*$%;0V]U;G1=*3L@?0T*"0E%3D0[#0H)=&]T86Q4:6UE.CT@ M5&5L;%1I;64[#0IW<FET92@G270@=&]O:R`G+'1O=&%L5&EM92PG('-E8V]N M9',@=&\@)RD[#0IT:&53;W)T7BY496QL3F%M93L-"G=R:71E;&XH)R`G+"!- M05@L("<@4D%.1$]-(&1A=&%S)RD[#0IE;F0[#0H-"G!R;V-E9'5R92!);FET M:6%L:7IE.PT*8F5G:6X-"B`@("`@;F5W*&%"=6)3;W)T*3L-"B`@("`@;F5W M*&%396Q3;W)T*3L-"B`@("`@;F5W*&%);G-3;W)T*3L-"@T*("`@("!A0G5B M4V]R=%XN26YI=#L-"B`@("`@85-E;%-O<G1>+DEN:70[#0H@("`@(&%);G-3 M;W)T7BY);FET.PT*96YD.PT*#0IP<F]C961U<F4@1FEN86QI>F4[#0IB96=I M;@T*("`@("!D:7-P;W-E*&%"=6)3;W)T*3L-"B`@("`@9&ES<&]S92AA4V5L M4V]R="D[#0H@("`@(&1I<W!O<V4H84EN<U-O<G0I.PT*96YD.PT*#0IV87(@ M;7E!<G)A>3H@4&AR87-E5%E013L-"FDZ:6YT96=E<CL-"F)E9VEN#0H@("`@ M26YI=&EA;&EZ93L-"B`@("!F;W(@:2`Z/2`Q('1O(#,@9&\-"B`@("`@("`@ M1&]3;6%L;%)A;F1O;5-O<G0H84)U8E-O<G0@+&UY07)R87DI.PT*#0H@("`@ M9F]R(&D@.CT@,2!T;R`S(&1O#0H@("`@("`@($1O4VUA;&Q286YD;VU3;W)T M*&%396Q3;W)T("QM>4%R<F%Y*3L-"@T*("`@(&9O<B!I(#H](#$@=&\@,R!D M;PT*("`@("`@("!$;U-M86QL4F%N9&]M4V]R="AA26YS4V]R="`L;7E!<G)A M>2D[#0H@("`@('L-"B`@("!1=6%S:5)A;F1O;5-O<G0H;7E!<G)A>2D[#0H- M"B`@("!F;W(@:2`Z/2`Q('1O($U!6"!D;PT*("`@("`@("!I9B!I(&UO9"`Y M(#T@,"!T:&5N#0H@("`@("`@(&)E9VEN#0H@("`@("`@("`@("`@=W)I=&5L M;CL-"B`@("`@("`@("`@("!W<FET92AM>4%R<F%Y6VE=.C8I.PT*("`@("`@ M("!E;F0-"B`@("`@("`@96QS92!B96=I;@T*("`@("`@("`@("`@=W)I=&4H M;7E!<G)A>5MI73HV*3L-"B`@("`@("`(a)96YD.PT*("`@("`@?0T*("`@($9I M;F%L:7IE.PT*("`@>R!$;U)E9W5L87)3;W)T*&UY07)R87DI.R!]#0H-"F5N (9"X-"@T*#0H ` end This is a bug report for RHIDE Version 1.4 (Sep 30 1997 23:06:59) I am running MS-DOS 7.10 (Windows 95) Important environment variables: PATH=C:\WIN95;C:\WIN95\COMMAND;D:\TMTPL\BIN;D:\GPC\BIN;C:\JDK11~1.3\BIN;C:\UTILS DJGPP=D:\GPC\DJGPP.ENV LFN=y INFOPATH=d:/gpc/info;d:/gpc/gnu/emacs/info;d:/gpc/info;d:/gpc/gnu/emacs/info LOCALEDIR= LANGUAGE= SHELL= COMSPEC=C:\WIN95\COMMAND.COM DJSYSFLAGS= Here is the output from a sample compilation and link for C executing: echo "int main(){return 0;}" | redir -eo gcc -Xlinker -v -Wa,-v -v -o /dev/null -x c - Reading specs from d:/gpc/lib\specs gcc version 2.7.2.1 d:/gpc/bin\cpp.exe -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 - d:/gpc/tmp/RHgaaaaa\ccbaaaaa GNU CPP version 2.7.2.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/gpc/include d:/gpc/contrib/grx20/include d:/gpc/contrib/grx22/include /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.7.2.1/include /usr/include End of search list. d:/gpc/bin\cc1.exe d:/gpc/tmp/RHgaaaaa\ccbaaaaa -quiet -dumpbase -.c -version -o d:/gpc/tmp/RHgaaaaa\cccaaaaa GNU C version 2.7.2.1 (80386, BSD syntax) compiled by GNU C version 2.7.2.1. d:/gpc/bin\as.exe -v -o d:/gpc/tmp/RHgaaaaa\ccdaaaaa d:/gpc/tmp/RHgaaaaa\cccaaaaa GNU assembler version 2.8.1 (i386-pc-msdosdjgpp) d:/gpc/bin\ld.exe -o /dev/null d:/gpc/lib\crt0.o -Ld:/gpc/lib -Ld:/gpc/contrib/grx22/lib -v d:/gpc/tmp/RHgaaaaa\ccdaaaaa -Tdjgpp.djl -lgcc -lc -lgcc GNU ld version 2.8.1 (with BFD 2.8.1) d:/gpc/bin\stubify.exe -v /dev/null Warning: input file is not COFF or stubbed COFF .exe: No such file or directory (ENOENT) stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie End of the sample Here is the output from a sample compilation and link for C++ executing: echo "int main(){return 0;}" | redir -eo gcc -Xlinker -v -Wa,-v -v -o /dev/null -x c++ - Reading specs from d:/gpc/lib\specs gcc version 2.7.2.1 d:/gpc/bin\cpp.exe -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 - d:/gpc/tmp/RHgaaaaa\ccbaaaaa GNU CPP version 2.7.2.1 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/gpc/lang/cxx d:/gpc/include d:/gpc/contrib/grx20/include d:/gpc/contrib/grx22/include /usr/local/lib/g++-include /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.7.2.1/include /usr/include End of search list. d:/gpc/bin\cc1plus.exe d:/gpc/tmp/RHgaaaaa\ccbaaaaa -quiet -dumpbase -.cc -version -o d:/gpc/tmp/RHgaaaaa\cccaaaaa GNU C++ version 2.7.2.1 (80386, BSD syntax) compiled by GNU C version 2.7.2.1. d:/gpc/bin\as.exe -v -o d:/gpc/tmp/RHgaaaaa\ccdaaaaa d:/gpc/tmp/RHgaaaaa\cccaaaaa GNU assembler version 2.8.1 (i386-pc-msdosdjgpp) d:/gpc/bin\ld.exe -o /dev/null d:/gpc/lib\crt0.o -Ld:/gpc/lib -Ld:/gpc/contrib/grx22/lib -v d:/gpc/tmp/RHgaaaaa\ccdaaaaa -Tdjgpp.djl -lgcc -lc -lgcc GNU ld version 2.8.1 (with BFD 2.8.1) d:/gpc/bin\stubify.exe -v /dev/null Warning: input file is not COFF or stubbed COFF .exe: No such file or directory (ENOENT) stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie End of the sample My problem is the following: ============================

1 0

Need help.......
by The Kilobug Team 27 Oct '97

27 Oct '97

Hi! I'm trying to make a DOS "shell", to improve the limited COMMAND.COM function. In order to reduce memory usage, I need help... Does one of you: * Know a Pascal or C compiler which can make COM programs, * Know how to execute programs from an ASM program, * And how to access the program parameters from an ASM program. Thanx for your help -- -= The Kilobug Team =- DOS Real&Protected mode programming. Home page: http://www.planetepc.fr/users/kilobug/ NEW site (beta, french obly): http://www.mygale.org/~kilobug/

2 1

us_Timer in TimeStamp
by Thomas_Tan＠fc.choate.edu 26 Oct '97

26 Oct '97

Are you guys going to implement us_Timer field of TimeStamps soon? I need a seed for a random function and this seems to be the best way to go. ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

1 0

Re: EFLIB strategy and encouragement
by Peter Gerwinski 26 Oct '97

26 Oct '97

Hi, Johan; hi, everybody! According to Johan Larsson: > > EFLIB is licensed under a GNU compatible license which is not ready. Didn't you write in your last mail that you want to charge for commercial use of EFLIB? If so, the license would *not* be GNU compatible because it is an essential component of the GNU GPL and the GNU LGPL that there is no distinction between commercial and non-commercial use of a program or a library. 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

EFLIB strategy and encouragement
by Johan Larsson 26 Oct '97

26 Oct '97

* The EFLIB project have changed strategy: we now aim to establish a standard template library for every Pascal programmer. Hello all, * Introduction EFLIB is a free object-oriented library aiming to become an open standard for all Pascal programming languages. EFLIB includes data structures packaged in classic ADT's, data streams, filtering and conversion, text processing, mathematics (including matrices, complex numbers and vectors). A cross-platform GUI is planned for EFLIB. EFLIB is licensed under a GNU compatible license which is not ready. Therefore, the source code is not released to the public at this time. * Try it You can go to http://ftp.sunet.se/EFLIB/ to download EFLIB or read any of the on-line material. * Get involved We'd love to see you getting involved in the EFLIB project! EFLIB need help from expert programmers on any Pascal platform such as FPK Pascal, GNU Pascal or Borland Delphi. The prototyping language is Borland Pascal, but efforts are made to make the source code very independent of the PL dialect. * More information Check out the Home of EFLIB, especially the on-line documentations and the specification PostScript documents at http://ftp.sunet.se/EFLIB/Manual/Documents/Specifications/. * Mailing lists You can subscribe to any of the EFLIB mailing lists (eflib-users(a)ts.umu.se, eflib-developers(a)ts.umu.se). Read the how-to at http://ftp.sunet.se/EFLIB/Lists/. * Response If you decide to get involved in the free GNU-licensed Pascal standard known as EFLIB, you are encouraged to write an e-mail to EFLIB(a)ts.umu.se or jola(a)ts.umu.se and give a some brief information about yourself. We'll discuss the details with you. Best Regards, Johan Larsson EFLIB Project Manager http://www.ts.umu.se/~jola/ jola(a)ts.umu.se

1 0

Re: Objects question
by Peter Gerwinski 25 Oct '97

25 Oct '97

According to Thomas Tan: > When I took a look at objects.pas in the \test\borland_\ directory (a copy > below), a few questions raise to mind. > [...] > Program Objects;(* Bug fixed: objects only worked in units, not in programs. > *)Type ParentPtr = ^ParentObj; ChildPtr = ^ChildObj;ParentObj = object > Constructor Init; Destructor Fini; Procedure O; c: Char; [...] To me, too. Either your mailer's text editor or your "FirstClass SMTP/NNTP GateWay" or something else has eaten up all line breaks in the source. Or is this just a joke? > 1. Does the character c have to be desposed in the destructor? Of course, not. Only *pointer* variables have to be disposed in the destructor. This is the same with GPC as with BP. > If so, is char > (0) a null character? It is, although this has nothing to do with `Dispose'. > 2. If there are variables (character, arrays ,strings, etc) in a function in > an object, do they have to be manually deleted? Only if they are pointers. > If so, how would I erase each one of them? A modified version of the `objects.pas' test program follows below. Please note that this is a test program which has the only purpose of testing whether the OOP mechanisms in GPC work correctly. For demo programs you can see section "OOP" in the GPC Texinfo online documentation (`info -f gpc -n OOP'). It's not too detailed, but it documents how GPC's OOP differs from that of BP. Since these differences are rather small, any book about "OOP with BP" can help you with GPC, too. > 3. Is there such a thing as a pointer to a function? Yes: Type ProcPtr = ^Procedure; FuncPtr = ^Function ( x: Real ): Real; If you omit the `^', you have BP's "procedural variables" which work in GPC, too. (* Here and in my other mails, I am referring to recent beta versions of GPC, not to the hopelessly outdated gpc-2.0 from December 1996. ;*) 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] 8< -------------------------------------------------------------------------- Program Objects; Type StringPtr = ^String; ParentPtr = ^ParentObj; ChildPtr = ^ChildObj; ParentObj = object S: StringPtr; Constructor Init ( Const SomeString: String ); Destructor Fini; Procedure O; c: Char; (* GNU extension: mixing of fields and methods *) Procedure K; virtual; end (* ParentObj *); ChildObj = object ( ParentObj ) Procedure O; Procedure K; virtual; end (* ChildObj *); Var MyObject: ParentPtr; Constructor ParentObj.Init ( Const SomeString: String ); begin (* ParentObj.Init *) New ( S, length ( SomeString ) ); S^:= SomeString; c:= 'K'; end (* ParentObj.Init *); Destructor ParentObj.Fini; begin (* ParentObj.Fini *) Dispose ( S ); end (* ParentObj.Fini *); Procedure ParentObj.O; begin (* ParentObj.O *) write ( 'O' ); end (* ParentObj.O *); Procedure ParentObj.K; begin (* ParentObj.K *) write ( 'y' ); end (* ParentObj.K *); Procedure ChildObj.O; begin (* ChildObj.O *) write ( 'x' ); end (* ChildObj.O *); Procedure ChildObj.K; begin (* ChildObj.K *) inherited K; writeln ( chr ( 8 ) + c ); end (* ChildObj.K *); begin MyObject:= New ( ChildPtr, Init ( 'Hello, world!' ) ); with MyObject^ do begin O; K; writeln ( S^ ); end (* with *); Dispose ( MyObject, Fini ); end. (* The output should be: *) (* OK *) (* Hello, world! *)

1 0

Re: Questing on String
by Peter Gerwinski 25 Oct '97

25 Oct '97

Hello, Thomas; hello, everybody! According to Thomas Tan: > > How does writeln(astring) work, I am not sure whether I understand your question ... To use `writeln', just do writeln ( MyIntegerValue : 6, MyRealValue : 10 : 4, MyStringValue : 7 ); to get 42 3.1415 Hallo! or writeln ( 'Answer = ', MyIntegerValue ); to get Answer = 42 If you want to know how `writeln' works internally, please look at the GPC source, file `rts.c', and in the subdirectory `rts' at the files `rts-write.c' and `rts-wrtinc.c'. If you have more questions about that, please post them on this list. > is the string null terminating? No, but GPC has an additional string type `CString' (or `PChar' for BP compatibility) which *is* null-terminated. If you have, for example, a null-terminated string you want to pass to an external function that wants to have such a string as a parameter (this holds for many external functions written in C), you can use `CString' as follows: Program Environment; (*$X+*) (* Enable "extended syntax" if you want to use `CString' *) Function SetEnv ( Name, Value: CString; overwrite: Integer ): Integer; C; Function GetEnv ( Name: CString ): CString; C; Var S: CString; begin SetEnv ( 'TEST_ENV', 'OK', 1 ); S:= GetEnv ( 'TEST_ENV' ); writeln ( S ); end. > If so, what is the character of null? Not too surprisingly, it is `chr ( 0 )' or `#0'. :-) For `CString'. GPC's native `String' is *not* null-terminated. And to answer your implicit question about GPC string internals: GPC's native `String' is a special case of a "schema type". It looks like a record internally: Type String ( n: Integer ) = record Capacity, length: Integer; (* 8 bytes *) data: packed array [ 1..n ] of Char; (* n bytes *) end (* String *); (* Remark: The above is a perfectly valid type declaration in GNU Pascal or any other compiler that supports Extended Pascal's schema types. It is, however, not identically the same as GPC's `String' since the built-in string functions only work on the built-in string type, but it has the same structure in memory. *) When you declare a string variable with "Var Foo: String ( 42 )" (* Now you see where the round parentheses come from. ;*), the "record field" `Capacity' gets the value 42 assigned, while `length' and `data' remain undefined until you assign a value to the string. You can access a string's capacity with `Foo.capacity' just like a record field. For dynamical allocation of strings, you can define "Type StringPtr = ^String" *without* a specified capacity and then give it when `New'ing the variable. Program Test; Type StringPtr = ^String; Var Foo: StringPtr; begin New ( Foo, 1042 ); (* allocate a String of maximum length 1042 *) Foo^:= 'Hello, world!'; writeln ( Foo^.Capacity ); (* yields "1024" *) writeln ( Foo^ ); (* yields "Hello, world!" *) Dispose ( Foo ); end. In addition to these features of Extended Pascal, GPC supports the following extensions: Type StringPtr = ^String; Var Foo: StringPtr; Foo:= @'Hello, world!'; (* let `Foo' point to a string constant *) Foo:= New ( StringPtr, 42 ); (* let `New' act as a function *) If you want to contribute to the GNU Pascal project, feel free to improve the existing documentation by adding the things I wrote above (and more;-). If you do so, please do not forget to post to this list what you are doing so you can coordinate with others who are currently working on the same field. 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

Objects question
by Thomas_Tan＠fc.choate.edu 25 Oct '97

25 Oct '97

When I took a look at objects.pas in the \test\borland_\ directory (a copy below), a few questions raise to mind. 1. Does the character c have to be desposed in the destructor? If so, is char (0) a null character? 2. If there are variables (character, arrays ,strings, etc) in a function in an object, do they have to be manually deleted? If so, how would I erase each one of them? 3. Is there such a thing as a pointer to a function? Thanks Tom Program Objects;(* Bug fixed: objects only worked in units, not in programs. *)Type ParentPtr = ^ParentObj; ChildPtr = ^ChildObj;ParentObj = object Constructor Init; Destructor Fini; Procedure O; c: Char; (* GNU extension: mixing of fields and methods *) Procedure K; virtual;end (* ParentObj *);ChildObj = object ( ParentObj ) (* Bug fixed: no dummy variable needed here. *) Procedure O; Procedure K; virtual;end (* ChildObj *);Var MyObject: ParentPtr;Constructor ParentObj.Init;begin (* ParentObj.Init *) c:= 'K';end (* ParentObj.Init *);Destructor ParentObj.Fini;begin (* ParentObj.Fini *) c:= chr ( 0 );end (* ParentObj.Fini *);Procedure ParentObj.O;begin (* ParentObj.O *) write ( 'O' );end (* ParentObj.O *);Procedure ParentObj.K;begin (* ParentObj.K *) write ( 'y' );end (* ParentObj.K *);Procedure ChildObj.O;begin (* ChildObj.O *) write ( 'x' );end (* ChildObj.O *);Procedure ChildObj.K;begin (* ChildObj.K *) inherited K; writeln ( chr ( 8 ) + c );end (* ChildObj.K *);begin MyObject:= New ( ChildPtr, Init ); with MyObject^ do begin O; K; end (* with *); Dispose ( MyObject, Fini );end. ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

1 0

Questing on String
by Thomas_Tan＠fc.choate.edu 24 Oct '97

24 Oct '97

How does writeln(astring) work, is the string null terminating? If so, what is the character of null? ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

1 0

Re: GPC question
by Jesper Lund 24 Oct '97

24 Oct '97

Tom: >Thank you again. Is there a list of all the built-in functions somewhere(as well >as all the interfaces)? One more thing, I cannot pass a string[255] variable to >a function or return a string[255] from a function. Is this a bug? >Thanks again. >Tom > First of all: please post general questions about GPC to the GPC list <gpc(a)hut.fi>, and not to me directly. GPC is under development, and so is the documentation. Therefore, AFAIK, there is no *complete* list of the built-in functions. However, GPC is reasonably compatible with Borland Pascal, and the degree of compatibility is increasing day by day, as new versions are released. BTW, do you use the last beta release, dates Oct 1, 1997? If not, get it from the GPC homepage. Regarding your second question, I think you need to define a string type, like type str255 = string [255]; function Foo : str255; begin Foo = 'Foo'; end; This should work. Note that 'string' has a different meaning in GPC than in Borland Pascal. To avoid unexpected effects, use strings of fixed size, such as my str255 -- or study the GPC documentation about "variable length strings". Best wishes, Jesper Lund

1 0

GPC question
by Thomas_Tan＠fc.choate.edu 24 Oct '97

24 Oct '97

Hi, I am looking for a function which returns the current time or date, is there one built in, if so, what do I put after the USES? Tom ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

2 1

Bug report
by The African Chief 24 Oct '97

24 Oct '97

Hi all, I have found a bug in the new beta. If you export a function in one unit, and then in another unit that uses that first unit, you have the same function (but only in the implementation section), you get a compiler error. This result; [----] two.pas:9: warning: static declaration for `Positive' follows non-static two.pas: In function `Positive': two.pas:10: undeclared identifier `I' (first use this function) two.pas:10: (Each undeclared identifier is reported only once two.pas:10: for each function it appears in.) [----] is produced by these two units; unit one; interface function positive(var i:integer):boolean; implementation function positive(var i:integer):boolean; begin positive := i > 0; end; end. {//} unit two; interface uses one; function negative(var i:integer):boolean; function neutral(var i:integer):boolean; implementation function positive(var i:integer):boolean; begin positive := i > 0; end; function neutral(var i:integer):boolean; begin neutral := i = 0; end; function negative(var i:integer):boolean; begin negative := i < 0; end; end. {////} Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

1 0

Re: Pointer arithmetics, automatic `uses'
by Peter Gerwinski 24 Oct '97

24 Oct '97

According to The African Chief: > > This is getting very interesting :-) We now have many different > versions of FillChar! Which should I use? One that works, and among those the fastest one. > > BTW, pointer arithmetics ... should GPC allow constructions like > > > > (*$X+*) > > > > Var > > p, q: ^Char; > > > > p:= q + 42; > > > > or only > > > > p:= succ ( q, 42 ); ? > > > > Personally, I would prefer to allow only the second (Pointer being an > > ordinal type) and to consider the first (Pointer + Integer) an error, > > but it's technically easier to allow both, so I ask before I remove a > > bug somebody might consider a feature. ;-) > > Personally, I would keep both. I am not in favour of imposing > restrictions on programmers, unless it is for their own good! I > suppose we could assume that anyone who wants to use the first > permutation knows what he/she is doing. One "pro" for keeping both is that "Pointer - Pointer" yields an Integer, so "Pointer + Integer" should work too and act as a reverse of the first. > PS: - another point entirely; is there a switch that will enable > a particular unit (in this case SYSTEM.PAS) to be used > automatically, without putting it manually in the USES clause of > every source file? I am looking for something like > > "--auto-use=xxx.pas,yyy.pas,f:\gpc\zzz.pas", > > which I can then use from the command line, or put into to > GPCC.CFG file. This is planned, and `--auto-use=...' is a good suggestion for the name. Okay with everybody? (Or perhaps `--auto-uses=...'? Or just `--uses=...'?) 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]

2 1

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 24 Oct '97

24 Oct '97

The African Chief wrote: > > For the other type declarations, I suggest you use the more modern GPC integer > > types (as invented some months ago), rather than the old style __modifiers__. > > (Also for real types.) > > Frankly, I am totally lost as far as that is concerned. Is there > any authoritative list of all the numerical types? I assume Peter's description in the announcement of GPC-970624 in <199706250026.CAA18851(a)agnes.dida.physik.uni-essen.de> can be considered authoritative: --- BEGIN QUOTE --- * GPC has new integer types now. Below is a table with their sizes in bits and their equivalents in (GNU) C. The size is the same for all platforms I have access to, but I am not sure whether this will always and everywhere be the case. However, compatibility to GNU C is guaranteed to work to the extend of the GNU GPL. ;-) The `*Int' types are signed (integer), the `*Card' types unsigned (cardinal numbers). The `*Word' types are unsigned, too, but should be thought of having undefined sign; they are intended to be used where signedness does not matter. Bits Signed Unsigned undefined (GNU) C equivalent 8 ByteInt ByteCard Byte [signed|unsigned] char 16 ShortInt ShortCard ShortWord short [unsigned] int 32 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord long [unsigned] int 64 LongInt LongCard LongWord long long [unsigned] int 64 LongestInt LongestCard LongestWord long long [unsigned] int In addition, you can define the number of bits for `Integer', `Cardinal', and `Word' types by putting it in parentheses, Type Int16 = Integer ( 16 ); (* 16 bits *) Unsigned17 = Cardinal ( 17 ); (* 17 bits; stored in 32 bits *) (* except when in packed arrays *) (* and records (or on machines *) (* with 17-bit registers:-). *) Answer = Word ( 42 ); (* Stored in 64 bits *) The size is rounded up to the next unit the machine can access, usually a power of 2 with 8 bits being the smallest possible size. * Subrange types can be packed now: Type Foo: -12..127; (* Takes 4 bytes (fast access) *) Bar: packed -12..127; (* Takes 1 byte (saves memory) *) --- END QUOTE --- So I suppose, for "portable" BP compatibility, the "(n)" variants are best suited: type ShortInt = Integer (8); Byte = Cardinal (8); Word = Cardinal (16); LongInt = Integer (32); Comp = Integer (64); Integer = Integer (16); const MaxInt = $7FFF; {@@ better: High(Integer) as soon as High will be built-in} MaxLongInt = $7FFFFFFF; {@@ High(LongInt)} For the C integers, you can use the table above (e.g. "long = MedInt"). Single, Double and Extended are built-in already. Real can be left as it is (which is either Single or Double, dependent on a swicth, IIRC), or generally defined to Double, I don't know -- it's not 100% the same as in BP, anyway... Pointer is also built-in, BTW. > > Procedures assgined to procedural variables can be in the main program now, > > so you can remove this comment for ExitProc. > > I am still having some problems with this. Can you show us an example where this is a problem, so it can be fixed? Another detail concerning ExitProc: There is a little difference between how BP's and GPC's system.pas handle them. BP sets them to NIL before calling an ExitProc. The effect is, when an exit proc "forgets" to assign the next one to ExitProc, the chain will abort rather than infinitely calling the same exit proc. I think the following would be 100% compatible: to end do begin var Tmp: Pointer; while ExitProc<>nil do begin InOutRes := 0; Tmp := ExitProc; ExitProc := NIL; PProcedure (Tmp)^ end end; The following program demonstrates the effect: program x; {$ifdef __GPC__}uses system;{$else}{$f+}{$endif} var Next1, Next2: Pointer; procedure e1; begin ExitProc:=Next1; Writeln('ExitProc1') end; procedure e2; begin (* ExitProc:=Next2; *) Writeln('ExitProc2') end; begin Next1 := ExitProc; ExitProc := @e1; Next2 := ExitProc; ExitProc := @e2; end. > > Assign is built-in now, so you can remove it from system.pas. > > Done. Does it now cater for all file types? Currently only Text files and typed files (which are the same internally in GPC). Untyped files are very different (as declared in system.pas), a fact I'm not very happy with. I think, they will be changed to be like typed files, but probably not until GPC 2.1... > Basically, DOS is a beast of a unit to implement - especially the > Findxxx functions. There are still problems with a "DIR" listing > using these functions if there are .EXE files in the list. There > are all sorts of other problems as well. I don't think it will > ever be portable. I have given up on the DOS unit. If someone > else wants to do it, please feel free! I see the problems. I suppose, *if* we can make a C header to Pascal translator (which is a very difficult task), we can make use of some (hopefully portable) C system functions to emulate most of Dos (though this will probably require some amount of additional Pascal code)... I think this is a task to face after 2.1... > > Unit Printer: > > > > can be written now (at least for DJGPP). > > Done! BTW: Do you close the printer file it in a "to end do" statement? BP, AFAIK, doesn't do so, but it's better to do. > Ok - thanks. I note Frank's comments - and so I will leave "Val" > alone. > Frank - will your "Val" procedure deal with reals as well? Yes, there are different versions for the 10 basic integer types and the 3 real types (shortreal, real, longreal), which will all be "overloaded" to the name "Val". Integer subranges should also work then, bit fields (fields of packed records/arrays that are not complete bytes) might not work until some time later... > Yes, it is. This is how it is implemented in "AddNull", which was > in the strings unit before, but I have now moved it into the > system unit, since the system unit also uses that functionality. > > Any thoughts on whether the system unit should now export this > AddNull function so that it can be available globally? This would > introduce something which is not in the BP system unit. I'm not sure if it should, since something like this will be built-in later, so programs shouldn't rely on the version in system.pas. Besides, I think, the name "AddNull" could be unclear or ambiguous (though I doubt someone would write a procedure of this name operating on numbers... ;-). I'd rather call it something like "Str2CString" or so... > PS: - another point entirely; is there a switch that will enable > a particular unit (in this case SYSTEM.PAS) to be used > automatically, without putting it manually in the USES clause of > every source file? I am looking for something like > > "--auto-use=xxx.pas,yyy.pas,f:\gpc\zzz.pas", > > which I can then use from the command line, or put into to > GPCC.CFG file. I agree, I'd also like to have this -- especially for the system unit. It's planned to make this, perhaps even until 2.1. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Error while compiling simple Pascal-Program
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Christian Bockermann: > > I have installed version 2.3 of the gnu assembler (gas) but now I get an > error when compiling my pograms. I wrote a little test program like this : > > program test; > var ch : char; > begin > ch:='x'; > writeln(ch); > end. This program compiles well on my box. (Uh - I hate non-reproducable errors!)-: I am using version 2.8.1 of the GNU assembler. Maybe that's the problem? If you upgrade and the error is still there, it could be a good idea to run `gpc' with the options `-v --automake=-v'. 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

Integer types (was: BPCOMPAT v1.10 -released!)
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to The African Chief: > > > For the other type declarations, I suggest you use the more modern GPC integer > > types (as invented some months ago), rather than the old style __modifiers__. > > (Also for real types.) > > Frankly, I am totally lost as far as that is concerned. Is there > any authoritative list of all the numerical types? It's in the GPC info documentation, section "Integer types", and there is also an Info node for each type. 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: Trapping I/O runtime errors in GPC
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Bill Currie: > On 23 Oct 97 at 10:43, Peter Gerwinski wrote: > > According to Jesper Lund: > > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > > > compiler directive in Borland Pascal? [...] > > > > Not yet, but it is being worked on. (Interested to take part?;-) > > Agh, does that mean I have to pull my finger out? Of course not. I was referring to your work, and I simply wanted to attract co-workers to your project. (-; > I think I've got the compiler side working in an older beta, but the > rtl has to be modified to support it. > > Problem is, {$I-} could be even longer yet because I'm changing jobs > (cities too) soon and I don't know how long I'll be off the net > (going off shortly before 17 Nov) > > I should at least be able to get some patches relative to the latest > beta (I think I still have to download it) before then. This would mean that it would be in the next beta and in gpc-2.1 - which would be a good thing. Thanks in advance, 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: BPCOMPAT v1.10 -released!
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to The African Chief: > > Any thoughts on whether the system unit should now export this > AddNull function so that it can be available globally? This would > introduce something which is not in the BP system unit. I would suggest to export it on request if an "extensions too" switch has been (*$define*)d. 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]

1 0

Re: Trapping I/O runtime errors in GPC
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Jesper Lund: > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > compiler directive in Borland Pascal? [...] Not yet, but it is being worked on. (Interested to take part?;-) > [...] to emulate the Borland 'Val' procedure. `Val' is being worked on as well. 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]

2 1

Error while compiling simple Pascal-Program
by chris＠bockermann.ping.de 23 Oct '97

23 Oct '97

Hello all there ! I have installed version 2.3 of the gnu assembler (gas) but now I get an error when compiling my pograms. I wrote a little test program like this : program test; var ch : char; begin ch:='x'; writeln(ch); end. and the error I get is : chris@bockermann:/home/chris/programs/pascal/test-prgs > gpc --automake test.p /tmp/cca00462.s: Assembler messages: /tmp/cca00462.s:4: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:5: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:6: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:7: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:8: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:9: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:10: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:11: Error: Rest of line ignored. First ignored character is `,'./tmp/cca00462.s:14: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:37: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:50: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:58: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:61: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:73: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:78: Error: Alignment too large: 15. assumed. Does anybody know, what's wrong ? -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Pointer arithmetics (was: BPCOMPAT v1.10 -released!)
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Frank Heckenbach: > Until a (more optimized) version > of them will be built in, here are some replacements (a bit slower, but > should be portable and generate no warnings): [...] Pointer arithmetics is portable and can be used here to speed it up: Procedure FillChar ( Var Dest: Void; Count: Integer; C: Char ); Var DestArray: tCharArray absolute Dest; z: ^Char; begin (* FillChar *) for z:= @DestArray [ 0 ] to @DestArray [ Count - 1 ] do z^:= C; end (* FillChar *); (Similar for `move'.) BTW, pointer arithmetics ... should GPC allow constructions like (*$X+*) Var p, q: ^Char; p:= q + 42; or only p:= succ ( q, 42 ); ? Personally, I would prefer to allow only the second (Pointer being an ordinal type) and to consider the first (Pointer + Integer) an error, but it's technically easier to allow both, so I ask before I remove a bug somebody might consider a feature. ;-) 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]

2 1

BPCOMPAT v1.10 -released!
by The African Chief 23 Oct '97

23 Oct '97

Hi all I have just uploaded BPCOMPAT v1.10 to agnes (in the contrib directory). You can download it as; ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip and ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.txt This version contains some bug fixes, and some stuff to improve portability (especially of the SYSTEM unit). Users of Linux and unix systems should find that the SYSTEM unit will now compile ("__UNIX__" is now predefined for Linux, Solaris, and FreeBSD - other unix users will need to define it manually). There are probably still some remaining bugs, and the package is still not a complete replacement for the BP RTL. However, things are improving. The ZIP file has been restructured (with a directory tree) so that the files are easier to locate and manage. The package needs improvement, and all contributions are welcome! BUGS ---- If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix. Happy coding! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

2 2

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 23 Oct '97

23 Oct '97

Some minor comments: Unit system: The type declarations (especially string=bpstring with -D_Borland_Pascal_ should be in system.pas itself (or $included) rather than in a separate unit (gpctypes.pas) so that programs that use only system will see them. My suggestion: remove the "{$W-}". Doing so will reveal a little bug in BinEof (a "=" used instead of ":="), and a lot of problem in FillChar and Move (which are not really portable, anyway). Until a (more optimized) version of them will be built in, here are some replacements (a bit slower, but should be portable and generate no warnings): Procedure FillChar ( Var Dest : Void; Count : Integer; C : Char ); Var z:Integer; begin for z:=0 to Count-1 do TCharArray(Dest)[z] := C end; Procedure Move ( Var Source, Dest : Void; Count : Integer ); Const PtrBitSize = BitSizeOf(Pointer); Type PtrCard = Cardinal(PtrBitSize); Var z:Integer; begin { Avoid overwriting of overlapping memory areas } if PtrCard (@Source) > PtrCard (@Dest) then for z:=0 to Count-1 do TCharArray(Dest)[z] := TCharArray(Source)[z] else for z:=Count-1 downto 0 do TCharArray(Dest)[z] := TCharArray(Source)[z] end; To make it work, you have to remove the (now obsolete) declaration of Cardinal (and perferably ByteInt and Byte as well) from gpctypes.pas. For the other type declarations, I suggest you use the more modern GPC integer types (as invented some months ago), rather than the old style __modifiers__. (Also for real types.) With -D_Borland_16_Bit_, also redeclare Integer to be a 16 bit type, otherwise it'll probably confuse some BP programs. A test program for FillChar and Move: program x; uses system; var a:array[1..20] of char; b:integer; begin a:='foo'; fillchar(a[3],10,'x'); writeln(a); move(a[1],a[10],5); writeln(a); move(a[10],a[2],3); writeln(a) end. The correct output is: foxxxxxxxxxx foxxxxxxxfoxxx ffoxxxxxxfoxxx Procedures assgined to procedural variables can be in the main program now, so you can remove this comment for ExitProc. I think it's not a good idea to declare BP variables like ErrorAddr that are not implemented in GPC. I'd prefer a compile time error when porting a BP program using them rather than possible unexpected problems at runtime. Assign is built-in now, so you can remove it from system.pas. Str, Val, Insert and Delete will be soon... :-), perhaps also Pos, Copy, ParamCount, ParamStr, Int and Frac. Unit Dos: SearchRec, FindFirst, FindNext and GetEnv are not really BP compatible (also note the difference between SearchRec and TSearchRec in BP). SwapVectors should be declared as an empty procedure. Unit Printer: can be written now (at least for DJGPP). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 23 Oct '97

23 Oct '97

Jesper Lund wrote: > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > compiler directive in Borland Pascal? Right now, the program > > var > x : real; > > begin > Readln (x); > end. > > abort with a run-time error if the user enters something that is not a > number. The same applies to ReadStr, BTW, so unless there is such a switch > (hidden) in GPC, we have to call C functions like 'sscanf' or 'atof' to > emulate the Borland 'Val' procedure. There will be a built-in Val procedure in the next beta! :-) > However, ReadStr + trapping runtime I/O > errors would be simpler, IMHO. AFAIK, Bill is working on the {$I+-} switch. (Bill, if you're reading this: The places to trap this particular error are the calls to _p_generic() in rts/rts-rdinc.c -- if you haven't done so already.) >From another mail: > I haven't found any bugs, but I have a suggestion which -- IMHO -- would > improve ValReal (the same applies to ValInteger, etc). Not necessary any more. I just completed the RTS part of the Val procedure, and Peter will build it into GPC. > [code snipped] > > COMMENTS: > > 1) The C library function converting the null-terminated string into a double > checks for errors itself (sscanf returns 0 if the string cannot be converted > to a double; meaning 0 values read from the string), so there is no need to > parse the string (to find the position where the error occurs), unless there > is an error in the string. BTW, this speedup is not possible with atof > because atof returns 0.0 if the string cannot be converted to a double. > That's why I use sscanf instead (sscanf is ANSI C, and must be in any C > library, so no concerns about portability between Linux, DJGPP, etc). > > As an aside, the string '1.1e3', is now converted to 1100.0, which is the > correct behavior. The code checking for errors should really be rewritten to > handle this. For example, the error position for '1.0ef3' is not at position > 4, but the 'f' at position 5. Adding 'e' to the list of admissible chars > would improve things a bit, but still not totally correct. In the built-in version (to come), I hope I've made all the checks at the right places. When it's released, please do as extensive tests as you can, and report any bugs you might find. > 2) The formal parameter S is declared as a string[255], instead of the schema > type 'string' (which has a different meaning than in Borland Pascal, where it > means string[255]). As you add a #0 to the string variable 's', it should be > large enough not to overflow (length gets out of range). > > I don't think the original version would work if called with a string > constant, because S would be a string with the same length as the string > constant, and adding #0 would (should) cause an exception. Yes, we discussed this topic recently. We plan to build in some functions for converting Pascal strings into CStrings easily. > 3) Unless GPC is really good at optimizing string expressions, the "hack" > > s[Length(s)+1] := chr ( 0 ) > > is faster than adding chr(0) to the string variable. Yes, it's faster. GPC is not that good yet, but I hope we'll make it that good (but not until version 2.1)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Trapping I/O runtime errors in GPC
by Jesper Lund 22 Oct '97

22 Oct '97

Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} compiler directive in Borland Pascal? Right now, the program var x : real; begin Readln (x); end. abort with a run-time error if the user enters something that is not a number. The same applies to ReadStr, BTW, so unless there is such a switch (hidden) in GPC, we have to call C functions like 'sscanf' or 'atof' to emulate the Borland 'Val' procedure. However, ReadStr + trapping runtime I/O errors would be simpler, IMHO. Jesper Lund

1 0

Re: floating point constants
by Peter Gerwinski 22 Oct '97

22 Oct '97

According to The African Chief: > > > > GPC doesn't like the spaces between e and +. Use > > > > 1.79e+308 > > > > instead of > > > > 1.79e + 308 > > You were right. How odd! > > > (I am not sure what the official Pascal standard says about this; > > Me neither. Me neither. It's impossible to understand them, as usual, but I have the impression that they do not want blanks in numbers. PEP does not accept it, so at least the standard does not requiire it. > > Borland Pascal accepts the spaces). > > Then perhaps GPC also should ? I don't think so since I consider this a bug in BP, not a feature. Other opinions? 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]

2 1

Problems with strings in GPC beta 971001
by Jesper Lund 22 Oct '97

22 Oct '97

I have encountered a couple problems with strings in the most recent GPC beta version. Most of the problems are due to missing range checks, e.g. when assigning a string to a shorter string, or passing a string to a procedure with a shorter string as formal parameter. 1) The program below illustrates some of these problems: program Test5; var s1 : string [500]; s2 : string [10]; type str5 = string [5]; procedure p1 (s : str5); begin Writeln (s.capacity, ' ', Length (s)); end; begin s1 := 'This is a relatively long string'; s2 := s1; { Copies all of s1 to s2; not just the first 10 characters } p1 (s1); { Passes all of s1 to procedure p1 } p1 (s2); end. Before exiting with a SIGSEGV exception (under DJGPP), the program prints 5 32 5 32 2) Another facet of the problem occurs when reading strings from a text file with Read[ln] (F, stringVar). If you call Readln, the program will read from the file until the next CR/LF, no matter the size (length) of stringVar, and try to copy the entire line to the variables stringVar (which will almost surely crash the program somehow; but not necessarily in the call to Readln. The SIGSEGV exception could come later, and with a stack trace which makes no sense). On the other hand, Read (F, stringVar) only reads a maximum of Length(stringVar) characters [as it should]. Jesper Lund

1 0

Re: Uses in implementation part of an unit
by Peter Gerwinski 22 Oct '97

22 Oct '97

According to Jesper Lund: > GPC does NOT allow "uses" in the implementation section of a unit. [...] Fixed: 8< ---- diff for parse.y ---------------------------------------------------- @@ -6123,6 +6136,7 @@ ; unit_implementation: + import_part /* This may be empty */ any_declaration_part optional_init_and_final_part ; 8< -------------------------------------------------------------------------- ... but the Automake mechanism does not handle this correctly. To work around, compile one of the units manually before automaking the program. I will try to fix this for the next beta. > In most (Borland-style) programs, moving "uses b" to the interface part (an > obvious workaround; or *solution* if the current GPC behavior is a feature > and not a bug) should not make a difference, but I imagine that there could > be a few exceptions. Yes - not only a few ones. You cite it: > The Turbo Pascal 7.0 manual says about this: > "[...] It also enables you to construct > mutually dependent units." 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]

1 0

Uses in implementation part of an unit
by Jesper Lund 22 Oct '97

22 Oct '97

GPC does NOT allow "uses" in the implementation section of a unit. That is, the following piece of code cannot compile. unit a; interface <something> implementation uses b; <something> begin end. In most (Borland-style) programs, moving "uses b" to the interface part (an obvious workaround; or *solution* if the current GPC behavior is a feature and not a bug) should not make a difference, but I imagine that there could be a few exceptions. The Turbo Pascal 7.0 manual says about this: "A uses clause in the implementation section allows you to further hide the inner details of a unit, because units used in the implementation section aren't visible to users of the unit. It also enables you to construct mutually dependent units." Jesper Lund

1 0

Rewrite/Reset with filename as second parameter
by Jesper Lund 22 Oct '97

22 Oct '97

Should GPC allow passing the filename to Rewrite/Reset as the second parameter, rather than calling Assign prior to the call to Rewrite/Reset? (several Pascal compilers outside the Borland family have this feature). Currrently, the the program below compiles correctly, but at run-time it stops with the error message ?GPC runtime error: (gpc-rts) Internal file namei wrong (#700) program Test; var F : Text; begin Rewrite (F, 'test.out'); Writeln (F, 'This is a test ....'); Close (F); end. Jesper Lund

1 0

floating point constants
by The African Chief 22 Oct '97

22 Oct '97

Hi all, Why do these lines not compile? Const MAXDOUBLE = 1.79769313486231570e + 308; Const MINDOUBLE = 2.22507385850720140e - 308; Const MAXFLOAT = 3.40282346638528860e + 38; Const MINFLOAT = 1.17549435082228750e - 38; Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

3 2

Re: Gpc not accepting non-standard (?) systax.
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to richard.kerry(a)quantel.com: > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > (('Output_File ', 1, 11), 2, OptionalArg, FileArg), > ... ); According to gpc-971001: > test.pas:28: parse error before `Value' > test.pas:29: invalid schema discriminants Uh - sorry, gpc-971001 does not recognize `value' in this context any more. This is connected with the requirement that "value" must be a redefinable identifier according to ISO-7185 Standard Pascal - which was not the case in earlier versions of GPC. A fix follows below. (Due to other changes, the new line numbers are in fact not correct, but `patch' won't care.;-) 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] 8< --------------------------------------------------------------------------- --- gpc-971001/p/parse.y Wed Oct 1 23:32:34 1997 +++ gpc/p/parse.y Tue Oct 21 23:57:02 1997 @@ -1473,12 +1475,15 @@ { if (! flag_what_pascal || (flag_what_pascal & B_D_PASCAL)) lex_const_equal = 1; + enable_keyword ("Value"); } type_denoter absolute_or_value_specification { tree d, init = $8; tree type = TREE_VALUE ($7); + disable_keyword ("Value"); + immediate_size_expand = $<itype>4; lex_caret = $3;

1 0

Re: also Pre compiled version
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to Omar Abu Al-Haija: > I get precompiled version , Djgpp from gnu pascal , > I try to compile a file , it give me an error message : - > > Gpc.exe : installation problem , cannot exec 'as': No such file or directory > ( Enoent ) . > > [...] > > Ps I had no dpmi loader , and no gnu assembler , or debugger . You need the DJGPP development tools. The GNU Pascal FAQ list says: 8< ---- GPC FAQ ------------------------------------------------------- [22]What do I download? As discussed in section 2.2, other than GPC itself, you need an assembler, linker and friends, a C library and possibly a debugger. From your local djgpp mirror, you can get these as: v2/djdev201.zip (C library) v2gnu/bnu270b.zip (assembler, ....) v2gnu/gdb416b.zip (debugger) The rest is up to you; `make' (v2gnu/mak375b.zip) can be useful, The latest RHIDE test release (an IDE with Borland-look) has support for GNU Pascal, and can be downloaded from: http://www.tu-chemnitz.de/~rho/rhidetest.html 8< -------------------------------------------------------------------- Remarks: * `rhidetest.html' is now `rhide.html'. * You can download this from any SimTel mirror. One is ftp://ftp.ruhr-uni-bochum.de/pub/simtelnet/gnu/djgpp/, but you will probably find one closer to your place. 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: complex numbers
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to fulvio ciriaco: > I notice that complex and real numbers cannot be mixed > in mathematical expressions. > The standard tells nothing, to my knowledge, about real > being converted automatically to complex, but most > compilers of other languages do exactly that. > I think the following expressions would be not only more > confortable but also more efficient than the equivalent > explicit conversion, since one cannot directly access to > the real and imaginary fields of complex records: [...] I agree in complete. I will see how difficult it is to implement these features. If they don't make too much trouble they might be in the next beta. 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: Gpc not accepting non-standard (?) systax.
by Frank Heckenbach 21 Oct '97

21 Oct '97

richard.kerry(a)quantel.com wrote: > Thank you for your help with the C/external problem, I've removed > 'external' and that part is now happy. Fine! :-) > Regarding the second problem, concerning a structured constant, or at least > what seems to be the gpc technique to achieve the effect of a structured > constant : > > The full chain of defs is as follows : > > const > mArgName = 16; > > type > ArgType = (OutputFileArg, InputFileArg, OptionsArg); > ArgClass = (StringArg, FileArg, NullArg); > ArgStatus = (RequiredArg, OptionalArg); > > ArgName = packed array[1..mArgName] of char; > iArgName = 0..mArgName; > > ArgDef = record > name: record > txt: ArgName; > amin: iArgName; > len: iArgName; > end; > pos: integer; > status: ArgStatus; > aclass: ArgClass; > end; > > ArgDefTable = array[ArgType] of ArgDef; > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > (('Output_File ', 1, 11), 2, OptionalArg, FileArg), > ... ); > > var > kludge : ArgDefs ; > I hope this is sufficient for you to sort out my problem. It compiled > successfully under gpc-970824 but fails under 971001. I think this is a form of the known problem. I'm surprised it did compile under gpc-970824 (I don't have this version here to check). Anyway, what you could do (until this problem is solved which might take some time) is to declare the constant values not with the type but rather with the variable(s). Though structured constants do not yet work completely like ISO requires, I guess your example should work. Try something like: [types until ArgDefTable, no type ArgDefs] var kludge : ArgDefTable value (...); Of course, if you have multiple such variables, you have to do this multiple times, which is not so nice. There could be a possible "dirty" solution using the preprocessor, something like: {$define ArgDefs ArgDefTable value (...)} var klugde : ArgDefs; -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Gpc not accepting non-standard (?) systax.
by richard.kerry＠quantel.com 20 Oct '97

20 Oct '97

heckenb(a)mi.uni-erlangen.de on 20/10/97 15:14:59 To: gpc(a)hut.fi cc: (bcc: Richard Kerry/Quantel Research) Subject: Re: Gpc not accepting non-standard (?) systax. richard.kerry(a)quantel.com wrote: > The 'C' directive on external procedures. > > FUNCTION _p_paramcount : Integer; C; > EXTERNAL ; > FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; > EXTERNAL ; > > It says : > : parse error before `External' The "C" directive implies "external". Earlier GPCs have accepted the above, the newer versions don't anymore. Just using "C" should do what you want. (Apart from this, there are still plans to make a more consistent syntax for C/External/AsmName... sometime...) > If I comment these out it fails on a structured constant definition using > 'value'. > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > etc... > > It says : > : parse error before `Value' > : invalid schema discriminants > > If I comment out 'value' it says > : parse error before `,' > : missing expression > : discriminated type is not a schema or string > : parse error before `,' > > Is there some configuration I need to do to make these work ? Or have I > found a bug ? If ArgDefTable is an array or record (or a combination of these), this is a known problem (since I don't know if this is required by the standard, I'm not sure if it's a bug or just a missing feature ;-). It's listed in my To-Do list at http://www.mi.uni-erlangen.de/~heckenb/gpc-todo_toc.html in the section "Records/arrays". If, however, a schema type is involved (the error messages say something about these), it might help to see the declaration of ArgDefTable. Did you perhaps use "string" without a maximum length? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm Thank you for your help with the C/external problem, I've removed 'external' and that part is now happy. Regarding the second problem, concerning a structured constant, or at least what seems to be the gpc technique to achieve the effect of a structured constant : The full chain of defs is as follows : const mArgName = 16; type ArgType = (OutputFileArg, InputFileArg, OptionsArg); ArgClass = (StringArg, FileArg, NullArg); ArgStatus = (RequiredArg, OptionalArg); ArgName = packed array[1..mArgName] of char; iArgName = 0..mArgName; ArgDef = record name: record txt: ArgName; amin: iArgName; len: iArgName; end; pos: integer; status: ArgStatus; aclass: ArgClass; end; ArgDefTable = array[ArgType] of ArgDef; type ArgDefs = ArgDefTable value ( ((' ', 1, 0), 0, OptionalArg, NullArg), (('Output_File ', 1, 11), 2, OptionalArg, FileArg), ... ); var kludge : ArgDefs ; I hope this is sufficient for you to sort out my problem. It compiled successfully under gpc-970824 but fails under 971001. Thank You, Richard Kerry.

1 0

Re: Gpc not accepting non-standard (?) systax.
by Frank Heckenbach 20 Oct '97

20 Oct '97

richard.kerry(a)quantel.com wrote: > The 'C' directive on external procedures. > > FUNCTION _p_paramcount : Integer; C; > EXTERNAL ; > FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; > EXTERNAL ; > > It says : > : parse error before `External' The "C" directive implies "external". Earlier GPCs have accepted the above, the newer versions don't anymore. Just using "C" should do what you want. (Apart from this, there are still plans to make a more consistent syntax for C/External/AsmName... sometime...) > If I comment these out it fails on a structured constant definition using > 'value'. > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > etc... > > It says : > : parse error before `Value' > : invalid schema discriminants > > If I comment out 'value' it says > : parse error before `,' > : missing expression > : discriminated type is not a schema or string > : parse error before `,' > > Is there some configuration I need to do to make these work ? Or have I > found a bug ? If ArgDefTable is an array or record (or a combination of these), this is a known problem (since I don't know if this is required by the standard, I'm not sure if it's a bug or just a missing feature ;-). It's listed in my To-Do list at http://www.mi.uni-erlangen.de/~heckenb/gpc-todo_toc.html in the section "Records/arrays". If, however, a schema type is involved (the error messages say something about these), it might help to see the declaration of ArgDefTable. Did you perhaps use "string" without a maximum length? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Gpc not accepting non-standard (?) systax.
by richard.kerry＠quantel.com 20 Oct '97

20 Oct '97

I have just :- 1. Moved to a newly set up, tidy, Linux machine (i586-pc-linux). 2. Built a Linux native gpc-971001 for the first time. (970824 didn't build as it required a pre-existing gpc which I had on my old, untidy, machine but don't have on the new one) I find :- When I try to compile a program that compiled sucessfully under 970824 on the old machine it now fails to compile. It is complaining about some features that I know aren't new and I thought were standard gpc. The 'C' directive on external procedures. FUNCTION _p_paramcount : Integer; C; EXTERNAL ; FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; EXTERNAL ; It says : : parse error before `External' If I comment these out it fails on a structured constant definition using 'value'. type ArgDefs = ArgDefTable value ( ((' ', 1, 0), 0, OptionalArg, NullArg), etc... It says : : parse error before `Value' : invalid schema discriminants If I comment out 'value' it says : parse error before `,' : missing expression : discriminated type is not a schema or string : parse error before `,' Is there some configuration I need to do to make these work ? Or have I found a bug ? Yours in anticipation, Richard Kerry.

1 0

also Pre compiled version
by OHMH＠nets.com.jo 18 Oct '97

18 Oct '97

I get precompiled version , Djgpp from gnu pascal , I try to compile a file , it give me an error message : - Gpc.exe : installation problem , cannot exec 'as': No such file or directory ( Enoent ) . I have set the the place where is dgjpp.env is . is this mean I haven't get all the files , as I think , I had the files : djgpp.env <bin> gpc1.exe gpc.exe <doc> <info> <lib> libgpc.a libgcc.a specs.gpc <manifest> gpc20.mft gpc20.ver <test> If i need to add more files to put me in the right way , could you please tell me where I could find those files exactly and their names , ftp would be more useful www for me , because I don't have full internet just email , if any body could lead me to compile any simple file like begin write(' Hello '); end. I will be thankful . Ps I had no dpmi loader , and no gnu assembler , or debugger . Sorry for my bad english .

1 0

complex numbers
by system＠petrella.cfilm.ba.cnr.it 17 Oct '97

17 Oct '97

I notice that complex and real numbers cannot be mixed in mathematical expressions. The standard tells nothing, to my knowledge, about real being converted automatically to complex, but most compilers of other languages do exactly that. I think the following expressions would be not only more confortable but also more efficient than the equivalent explicit conversion, since one cannot directly access to the real and imaginary fields of complex records: complex=real complex*/real complex+-real I also imagine such operations are supported by pxsc so it would be a step forward compatibility. I wish to express my greetings for developers' work, attested by the continuous improvement of the features of gpc. Best wishes Fulvio Ciriaco.

1 0

Re: Problem building New GPC beta: gpc-971001 for DJGPP v2.1
by Peter Gerwinski 15 Oct '97

15 Oct '97

According to Maurice Lombardi: > According to myself (Peter Gerwinski): > > `cd' to `\djgpp\gnu\gpc\p' and do `make ../xgpc', `make ../gpc1', > > `make ../gpc-cpp', and `make ../libgpc.a' from there. > > rather cd \djgpp\gnu\gcc-2721\p Of course. #-) Sorry. > make finds no rule to build ../xgpc there (they are in make-lan.in) > > but it works by issuing make xgpc in the parent directory > > \djgpp\gnu\gcc-2721 (the rule is indeed in the generated makefile) > > > > make gpc1 in this parent directory does not work (there is a rule but it > > does not find a file) > > [...] Obviously, the configuration stuff for DJGPP is completely broken. :-( Since I am busy with other things right now, I would be really happy if somebody else could have a look at that. (I am not an expert in configuration of C sources anyway.;-) Normally (i.e. on UNIX), configuration is done by running a `configure' shell script in the `p' directory. The `configure' script has in turn been produced by `autoconf' from a `configure.in' source file. The goal of all this is to produce a `Makefile' from `Makefile.in' and `gpc-config.h' from `gpc-config.in'. If you produce `Makefile' and `gpc-config.in' manually and let `configur.bat' copy them from `config/msdos' to the right places, it would be fine. (* Jan-Jaap, is this the clean way for DJGPP configuration? *) Personally, I would prefer to have `configur.bat' in the `p' subdirectory rather than in `config/msdos'; in fact I do not know which place is the "clean" one for this file according to GNU conventions. 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]

2 1

Multidimensional conformant arrays
by Frank Heckenbach 15 Oct '97

15 Oct '97

I think I found a bug with conformant arrays. Are conformant arrays supposed to work in multiple dimensions at all? If so, the following program gives the wrong result "3 2 1 2" instead of "1 2 3 4"; if not, it doesn't generate a necessary error message... program x; procedure p(var a:array[b..c:integer;d..e:integer] of integer); begin writeln(b,' ',c,' ',d,' ',e) end; var a:array[1..2,3..4] of integer; begin p(a) end. The corresponding program using a schema type works. BTW: Wouldn't it seem reasonable to allow the "with" statement also for schema types, as in the following example: program x; type t(a:integer)=array[1..a] of integer; procedure p(var v:t); begin with v do writeln(a) end; begin end. And one little detail: The next program gives the error message x.p:6: request for member `X' in something not x.p:6: a record, schema or object which is not completely correct since v is a schema, but x is not a field of v. program x; type t(a:integer)=array[1..a] of integer; procedure p(var v:t); begin writeln(v.x) end; begin end. Greetings, Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: pre compiled version
by Peter Gerwinski 15 Oct '97

15 Oct '97

According to Omar Abu Al-Haija: > Please Could any body tell me were I could find a precompiled version of > gnupascal , At any SimTel mirror, download `gpc20b.zip' from the DJGPP distribution. The same is available as a file `gpc-2.0.i386-djgppv201.zip' at ftp://kampi.hut.fi/jtv/gnu-pascal/binary/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/binary/ If you want to try out our recent beta versions, look at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ > plus any IDE to use with , I had IBM compatible computer , and most of my > work is under dos operating > system , [...] We recommend RHIDE. Get it from http://www.tu-chemnitz.de/~rho/rhide.html 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: bugs?
by Frank Heckenbach 15 Oct '97

15 Oct '97

fulvio ciriaco wrote: > Hallo! > I think I discovered two bugs. > I am using gpc-970714 beta version,on digital alpha > unix. > The first is very strange: > var i:integer; > read(f,i); > reads 110 in i if the file f begin with > 10 > but correctly reads 10 if f contains > <space>10 > The second is schematized in the following > PROCEDURE readdata; > VAR > f : bindable text; > c : BindingType; > i : integer; > BEGIN > WRITELN('dammi il file di input'); > READLN(c.name); > bind(f,c); > SeekRead(f,0); > END; > PROCEDURE printdata; > VAR > f : bindable text; > c : BindingType; > i : integer; > BEGIN > WRITELN('dammi il file di output'); > READLN(c.name); > bind(f,c); > SeekWrite(f,0); > END; > > f I believe should be local to readdata and printdata, > but calling printdata after readdata gives the error > ?Gpc: Object (0x11ffffba8) already bound to `inizia' > where inizia is the input file name. The reason for this problem is the list Bound_objects in the RTS which stores the addresses of all bound files with their names. The two files in the two procedures incidentally get the same address, so the RTS "thinks" they're the same. I don't know much about bindings and so, but I think it would be better to store the binding information only in the Text variables themselves, not (additionally) in a global list. So I'm asking the long-time GPC developers: is there any reason against removing the list, and Bound_free_list as well? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

bugs?
by system＠petrella.cfilm.ba.cnr.it 14 Oct '97

14 Oct '97

Hallo! I think I discovered two bugs. I am using gpc-970714 beta version,on digital alpha unix. The first is very strange: var i:integer; read(f,i); reads 110 in i if the file f begin with 10 but correctly reads 10 if f contains <space>10 The second is schematized in the following PROCEDURE readdata; VAR f : bindable text; c : BindingType; i : integer; BEGIN WRITELN('dammi il file di input'); READLN(c.name); bind(f,c); SeekRead(f,0); END; PROCEDURE printdata; VAR f : bindable text; c : BindingType; i : integer; BEGIN WRITELN('dammi il file di output'); READLN(c.name); bind(f,c); SeekWrite(f,0); END; f I believe should be local to readdata and printdata, but calling printdata after readdata gives the error ?Gpc: Object (0x11ffffba8) already bound to `inizia' where inizia is the input file name. unbind(f) eliminates the error message. I hope I were of any help Fulvio Ciriaco

1 0

pre compiled version
by OHMH＠nets.com.jo 14 Oct '97

14 Oct '97

Hi all Please Could any body tell me were I could find a precompiled version of gnupascal , plus any IDE to use with , I had IBM compatible computer , and most of my work is under dos operating system , I work on Borland Pascal v 7.0 . Thanks any way . Yours : Omer , Ohmh(a)nets.com.jo

1 0

Built-in string functions (was: New GPC beta: gpc-971001)
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Frank Heckenbach: > > It could also be a switch. But wouldn't it be "cleaner" to write it as a > function? "CStrFunc (Str2CStr (StrVar))" or so... Ah - you are referring to parameter passing. Yes, this will be built-in, so you can just write "CStrFunc ( StrVar )". > > What functions do you mean? Built-in replacements for BP's functions from > > the `Strings' Unit? > > Of course, they could be external functions as well. It's no problem to > implement them in Pascal. But I think in the long run, all such standard > functions will be built-in. You are right that it would be easy to provide these functions as built-in features once we have solved this problem for parameter passing. Since there already is a de-facto standard in BP how to name these functions we should use that. Everything okay, 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 building New GPC beta: gpc-971001 for DJGPP v2.1
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Maurice Lombardi: > > I have tried to build gpc-971001 from the zip sources for DJGPP v2.01 > I use plain DOS with or without bash shell: > > -unzip fresh new gcc-2721 in directory %DJDIR%\gnu\ > -unzip gpc sources to %DJDIR%, then put the p\ tree as subdirectory > of gcc-2721 > > then follow instructions contained in p\config\msdos\readme2.dj. > > It builds gcc, but then stops without building gpc ? Strange. :-( Anyway, when you have reached this step, the following is known to work: `cd' to `\djgpp\gnu\gpc\p' and do `make ../xgpc', `make ../gpc1', `make ../gpc-cpp', and `make ../libgpc.a' from there. This builds the respective `.exe' files, although we do *not* specify the extension `.exe'. After that, move the `.exe's to `\djgpp\bin', and `libgpc.a' to '\djgpp\lib' to install. > Other problems found: > > 1- the p\config\msdos\configur.bat must be in dos format > (return-linefeed) to run in plain dos [...]. Fixed. > 2- there is a problem with backward slashes \ in the makefile in lines > like > ./bi-arity < $(srcdir)\bytecode.def >tmp-bc-arity.h > (three times). Seems to come from the application of > gnu\gcc-2721\config\msdos\top.sed and is already present in the > compilation of gcc alone. I have filed a bug report to dj delorie, > and fixed it manually after running configure go32 which produces this > makefile. So there is nothing we could do about that ... may I ask you to document it in `README2.DJ'? > 3- [`.gdbinit' vs. `_gdbinit'] Okay. It will be fixed in the next `.zip' release. Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: Strings and PChars
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > Now, that is the interesting bit. Both permutations give a wrong result > in BP (DOS real mode and DOS DPMI), but give correct results in > BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? Not really. Since they're relying on more or less undefined things (such as the contents of the stack area next to some parameter), the behaviour can easily be different on different platforms. It could even be different on the same platform (e.g. in Dos when loaded at different addresses -- or under a debugger). That's the kind of bugs that's hard to track. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: New GPC beta: gpc-971001
by Frank Heckenbach 13 Oct '97

13 Oct '97

Peter Gerwinski wrote: > > - One that always makes a copy on the stack and copies the string into it. > > That's the secure way, but inefficient with very long strings. > > Concerning CStrings? You mean a switch? It could also be a switch. But wouldn't it be "cleaner" to write it as a function? "CStrFunc (Str2CStr (StrVar))" or so... > > - One that allocates the memory on the heap. This is needed when the > > resulting CString is to be used outside of the current scope (when it's > > not only passed to a function). > > > > - One that copies the string in a buffer allocated by the programmer (this > > is perhaps only for compatibility with BP's StrPCopy). > > What functions do you mean? Built-in replacements for BP's functions from > the `Strings' Unit? Of course, they could be external functions as well. It's no problem to implement them in Pascal. But I think in the long run, all such standard functions will be built-in. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by The African Chief 13 Oct '97

13 Oct '97

On Mon, 13 Oct 1997 02:36:00 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >> >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); >> > >> >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" >> >to do? AFAICS, it copies a string into itself!? >> >> More or less. Since it is already itself, nothing really should happen, >> but the side effect is that it provides the input for StrNew to work with, > >You could just write "Str2pChar := StrNew ( @s[1] );" True. >which gives the same (wrong) result in BP. Now, that is the interesting bit. Both permutations give a wrong result in BP (DOS real mode and DOS DPMI), but give correct results in BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > No, it shouldn't. Maybe we are at cross purposes here. My original > meaning was: if I write "str1 := str2", that is precisely what I should > get - no more, no less. I should get in "str1" the exact number of > characters that are in "str2", in the exact order - no more, no less. > If an optimiser gives me that, I don't really care what else it does ... Exactly. The number of characters is given in the length. Anything beyond the length (such as the #0 terminator in your first version) is undefined. > Okay, I understand that now ;-). However, this solution will not > work if there is a maximum length for the string, and the string > that is passed to the function has already reached that length. True. For (long) string, we can solve this by implicitly making the schema bigger by 1 char than declared, but for short strings, this is not possible without breaking BP compatibility, so we need to copy them. (OTOH, it's not so bad there, since they can be only 255 chars long, so there isn't too much overhead.) > >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); > > > >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" > >to do? AFAICS, it copies a string into itself!? > > More or less. Since it is already itself, nothing really should happen, > but the side effect is that it provides the input for StrNew to work with, You could just write "Str2pChar := StrNew ( @s[1] );" which gives the same (wrong) result in BP. > >OTOH, if you're using the strings unit anyway, is there anything wrong with > >StrPCopy? > > If I used this routine in the system unit, I would not be using the > strings unit there - but I can import "strcpy" from the C library, > and call it "StrCopy". Perhaps something like (NOT tested): Function Str2pChar ( s : String ) p : pChar; begin GetMem (p, Length(s) + 1); Move (s[1], p^, Length(s)); p[Length(s)] := #0 end; -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Writeln and longint
by Frank Heckenbach 13 Oct '97

13 Oct '97

I wrote: > Kevin A. Foss wrote: > > > Hello, > > In my process of getting gpc to compile under OS/2, I've been > > trying some example code and Peter recommended trying stuff like > > writing longints to see if the new features in 971001 were working. > > Well, I tried the following: > > -=-=-=-=- > > program testlongint(output); > > > > Var > > i : longint; > > > > begin > > i := 1; > > writeln(i); > > end. > > =-=-=-=-= > > It compiles fine, but for output I get simply: > > > > [C:\kevin\pascal\gpc-test]longint > > qd > > I'll see what I can do about it. In the worst case, I'll have to > rewrite the output of integers completely which I planned to do > (later) anyway... OK, that's what I did now. I re-wrote the outputting of integers and reals in Pascal now. So this program should work with the next GPC version. However, especially the writing of reals has many special cases, so there may be some bugs left. So please, everyone who's interested in this, write some test programs, and submit them (!) -- preferably with (what you think are) "special cases". It's better if the author doesn't do this himself because he'll usually have handled those special cases that he thinks about... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

subscription
by Peter W. Schnoor 12 Oct '97

12 Oct '97

subscribe gpc pwsch(a)nephro.uni-kiel.de

1 0

Re: New GPC beta: gpc-971001
by Peter Gerwinski 12 Oct '97

12 Oct '97

According to Frank Heckenbach: > > (* Peter, was this what we intended to do, or did I confuse anything? ;*) I am not sure. ;-) > Actually, for sometime later we have planned to build the following functions > into the compiler: > > - One that just appends the #0 and returns the addres of the first character > of the string (solves problem 2; not 3; problem 1 will be solved by making > strings internally bigger than declared by 1 char). For short strings (when > they will be introduced), this function will make a temporary copy on the > stack (because they must be BP compatible so there will not always be space > for the #0 in the string). Yup. > - One that always makes a copy on the stack and copies the string into it. > That's the secure way, but inefficient with very long strings. Concerning CStrings? You mean a switch? > - One that allocates the memory on the heap. This is needed when the > resulting CString is to be used outside of the current scope (when it's > not only passed to a function). > > - One that copies the string in a buffer allocated by the programmer (this > is perhaps only for compatibility with BP's StrPCopy). What functions do you mean? Built-in replacements for BP's functions from the `Strings' Unit? 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: New GPC beta: gpc-971001
by The African Chief 11 Oct '97

11 Oct '97

On Sat, 11 Oct 1997 01:23:15 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: [...] >> >AFAIK, since the characters after Length(x) in a string are undefined.) >> >> Which is why you should only copy to length(s). > >You probably should, but (AFAIK) you don't have to. Agreed. >> If I do "str1 := str2" , I do not expect an optimiser to make it into; >> "str1 := str2 + any junk after the length of str2, up till str2.capacity". > >Not "str2 + any junk", it's still only "str2", according to the definition >of (this kind of) strings. Generally, a string always contains "junk" after >the length till the capacity, and you shouldn't rely on anything about this >junk. No, you shouldn't. >(E.g., I recently modified the WriteStr procedure so that it will >not fill a (normal) string with spaces, #0's or whatever as it did before. >Only arrays of char are padded with spaces, unless treated as CStrings. >I don't think such a change should matter to any "good" program.) No, it shouldn't. Maybe we are at cross purposes here. My original meaning was: if I write "str1 := str2", that is precisely what I should get - no more, no less. I should get in "str1" the exact number of characters that are in "str2", in the exact order - no more, no less. If an optimiser gives me that, I don't really care what else it does ... >> >A possible "fix" for the second problem (not the first one, though the >> >appearance of the problem will be different then) would be >> >"s[Length(s)+1]:=#0" (also, it's much more efficient). >> >> I am not sure how this solves the problem. > >When you explicitly write a #0 into the "junk" area, you can be sure that >it will be there (because you don't use any string functions, such as >assignments between strings). And it's more efficient because you don't >have to copy the contents of the string (twice) and don't need any temp >variables. Therefore, you don't have to limit the length of the string >(in system.pas it's limited to 255 chars). Okay, I understand that now ;-). However, this solution will not work if there is a maximum length for the string, and the string that is passed to the function has already reached that length. >> program x; >> >> uses >> strings; >> >> Function Str2pChar ( s : String ) : pChar; >> Begin >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); > >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" >to do? AFAICS, it copies a string into itself!? More or less. Since it is already itself, nothing really should happen, but the side effect is that it provides the input for StrNew to work with, and it also saves on using another temporary variable. Perhaps this is a misguided saving? >OTOH, if you're using the strings unit anyway, is there anything wrong with >StrPCopy? If I used this routine in the system unit, I would not be using the strings unit there - but I can import "strcpy" from the C library, and call it "StrCopy". Even if I wanted to use StrpCopy, I would still need 2 variables - and you would also need more code. But if I used this in the system unit, I would not need >> const >> s:string=' '+ >> ' '+ >> ' '+ >> ' '+ >> ' '#13#10'This program is OK.'; >> >> t:string=#8#8#8#8' wrong, sorry.'#0; >> >> var >> p:pchar; >> begin >> p:=str2pchar(s); >> writeln(p); >> StrDispose(p); { need to dispose of the memory! } >> end. > >This program does not work correctly in my BP. It works correctly under my BP (BPW) and also under GPC. >It might seem to work for you because you pass s by value now, >so now there will not be t after s in memory (on the stack), but >something else. Okay. I will do more tests then! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

SV: EFLIB port to GNU Pascal and FPK Pascal.
by Johan Larsson 11 Oct '97

11 Oct '97

The African Chief wrote: > GPC is in dire need of a complete class library. So, I would be > interested in doing some of the work for porting this to GPC, > if others would also contribute. Any other takers? The library > is big, but many hands make the work lighter. This would also > give us the chance to ferret out any remaining "issues" as far > as BP compatibility is concerned! Sounds good! Those that are interested could take a look at the 5th prototypes source code when released and then send me some reflections. I suggest that the 6th prototype is finished before the porting actually begins. There are certain interface issues to be resolved first. The specification of EFLIB prototype 6 has been sketeched. It's available at http://ftp.sunet.se/EFLIB/Manual/Specifications/ for download as PostScript, PDF and DOC files. A new TPH help file can now be downloaded at http://ftp.sunet.se/EFLIB/Download/. Contact me personally, or write to eflib-developers(a)ts.umu.se (mailing l ist). I welcome everyone to subscribe to the EFLIB mailing lists and to direct questions and make suggestions here, since many people will read the messages. Subscription information is available at http://ftp.sunet.se/EFLIB/Support/, among other places. Best Regards, Johan Larsson E-MAIL jola(a)ts.umu.se HOME http://www.ts.umu.se/~jola/ Also, REMEMBER to check out http://ftp.sunet.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

New GPC beta: gpc-971001
by Peter Gerwinski 11 Oct '97

11 Oct '97

Hello everybody! A new beta version of GNU Pascal is being uploaded to Agnes: gpc-971001. This is merely a bug fixing release, but there are some now features, too - most of them intended to achieve better compatibility to other compilers. The GNU Pascal development team welcomes two new members: Bill Currie implemented some new built-in functions, and Frank Heckenbach improved the run-time system to deal with non-standard situations. Bug fixes and new compatibility features ======================================== GPI mechanism: * The installation problem caused by a variable `_end' is gone. * Function attributes and schemata containing expressions now survive transport through a GPI file. * Open files now survive transport through a GPI file. Now you can write BP's `Printer' unit in the canonical way. * Some crashes observed with GPI files on Windows 95 should not occur any more. * Pointers should no more lose compatibility to themselves when imported from more than one GPI file. (E.g. when importing objects with the same parent type from different units, you don't get a superfluous warning any more. * Some errors that only occured when a virtual method having an undiscriminated string parameter was transported through a GPI file have vanished. * The temporary `.gpc' file should now be deleted after compilation in all cases. Procedural parameters, variables, and pointers: * Problems with procedures and functions that were called when they should be passed as a parameter or taken the address - or vice versa - should have disappeared now. * Procedures and functions declared in the main program now can be safely assigned to a procedural variable or pointer. * GPC now checks for the erronous assignment of a procedure to a pointer to a procedure. Assign the address instead. * When `foo' is a procedural variable (= reference to a procedure), `@foo' yields a pointer to the procedure, and `@@foo' the address of the procedural variable itself (like in Borland Pascal). Range checking: * In most situations where constant value are involved (assingment of a constant expression to a variable, initialization, ...) GPC now performes range checking. This holds for ordinal values and strings. * Arithmetics with integer constants should no more overflow if intermediate results do not fit in `Integer'. The result is then range-checked. Standard Pascal: * GPC now passes (again) all level 0 PVS conformance tests. Some things are still broken with high optimization levels on the DEC Alpha. For gpc-2.1, we plan to have them fixed and to have level 1 passed as well. * Non-local `goto' targetting the main program works again. (It was broken in some unofficial intermediate releases due to some other improvements.) * Using global variables as `for'-loop control variables in the main program works again. (This was also broken in some unofficial intermediate releases due to some other improvements.) * Comments starting with `{' and ending with '*)' or vice versa still work. (They were also broken ... see above.) * The function `arctan' works again. (It was ... well, you know.) * The transfer procedures `pack' and `unpacked' work again. (They were broken (for obvious reasons) when packed arrays were introduced.) * Non-trivial expressions involving components of packed arrays work now. * Type checking of sets has been improved. * Set expressions ("set constructors") should work in all cases now. * Comparisons of sets of different size (including the empty set) work now. * Subranges are now compatible to their parent type. * Comparisions between char constants are no more warned about in `--standard-pascal' mode. * Parameters of `read' now may be components of packed arrays and records as long as they are aligned on a byte boundary. * Missing program parameters are warned about in `--standard-pascal' mode. This warning does *no more* turn into an error with `--pedantic-errors' because it is valid in ISO Pascal (while useless) to write a program without any input and output. * Tag fields of variant records now can be initialized in `New': Type FooPtr = ^FooRec; FooRec = record case Bar: Boolean of true: ( a: Integer ); false: ( b: Char ); end (* FooRec *); Var p: FooPtr; New ( p, true ); (* Assigns `p^.Bar:= true' *) Extended Pascal: * Undiscriminated strings and schemata passed as function parameters should now work in all cases. * In a schema type declaration, the discriminants now may be part of expressions. Borland Pascal: * GPC now has a built-in `Assign' procedure. * In units and with `external' and `forward' procedures and functions, GPC now checks that the parameter lists match (if the second one exists). * Some bugs with `#$42' char constants (when they appeared in sequence or at the beginning of a line) are fixed now. * GPC now allows to put a variable to specified address with `absolute': "Var foo: Integer absolute 42;". This is only useful on systems without virtual memory - *not* with DOS (DJGPP or EMX). Outside $X+ mode, you get a warning about this use of `absolute'. (Note that GPC uses a flat memory model and thus does *not* define BP's "Var foo: Integer absolute $40:$42;".) * Assignments between object variables are now complained about. GNU extensions: * New built-in types: `MedReal' and `LongestReal'. * `New' with schema pointers now can be called analogously to `New' with object pointers: Type MySchema ( n: Integer ) = array [ 1..n ] of Byte; MySchemaPtr = ^MySchema; Var p: MySchemaPtr; p:= New ( MySchemaPtr, 42 ); * `__volatile__' variables no more become `__external__' automatically. * Machine attributes now also work for variables, not only functions. * Function attributes now can have more than one argument. * The run-time system (RTS) now can handle most non-standard types such as long integers. * Fixed strings ([packed] array of Char) with a lower bound different from 1 are now handled correctly. * `ReadStr' can read from a `CString' (= `PChar') now. * `CString' variables now can be initialized with constants. * Now you can initialize a pointer to a string with a constant: "Var p: ^String value @'Hello, world!';". * Type casts from pointers to integers and between integers of different size and signedness work now. * Taking the address of something not aligned on a byte boundary is now warned about. * A new function `GetFile ( Const F: any File ): Pointer' now returns a pointer to the C `FILE' structure inside a Pascal `File' variable. * Declaring statements are now warned about unless compiling with $X+. * The expression after `absolute' can be an arbitrary expression now: "Var foo: Integer absolute bar^ [ i ].baz;". You can use this to define shortcuts (like macros in C) - use with care. Outside $X+ mode you get a warning if the expression does not reduce to a constant address. * `Inline' now works like promised in the documentation, and it is redefinable. (`__Inline__' still works.) Miscellaneous: * Console I/O under DJGPP now works correctly with certain control characters. * Linking `.a' files with the (*$L /usr/lib/libfoo.a *) directive works now. * Some problems with certain built-in functions (`sqr', `pred', `succ', `min', `max') when applied to integer constants have vanished. * `--pedantic-errors' now has again the same meaning as in GCC. Use `-Werrors' to turn warnings into errors. * If `gpc --automake' is invoked to compile other languages than Pascal, it no more crashes. * The source fo the GNU Pascal compiler itself has been cleaned up significantly. Read and enjoy! Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/, files gpc-971001.tar.gz and gpc-971001.zip, together with binaries for DOS (DJGPP), and Linux (ELF). Binaries for DOS and OS/2 (EMX) and FreeBSD will follow as soon as possible. In order to prepare for the release of gpc-2.1, binaries are moved to a subdirectory `binary' of `beta', and some other things are being set up, so don't be confused if some files aren't located any more where they were on the day before. Acknowledgement =============== I have lost overview, but the GNU Pascal development team thanks everybody who helped us by contributing useful code and ideas and reporting bugs. Thanks to all of you! Please go on finding all bugs in gpc-971001! I may have overlooked some you already reported. (If so, please remind me by e-mail.;-) Once GPC is clean, we can release version 2.1 - and face neat new features (e.g. qualified import and identifiers, classes, interfaces, procedure overloading, ...) for 2.2! :) Greetings, The GNU Pascal Development Team

3 4

Re: New GPC beta: gpc-971001
by Frank Heckenbach 10 Oct '97

10 Oct '97

The African Chief wrote: > >Secondly, you copy back the old value of s back afterwards. This only works > >because GPC copies only Length(x) characters. If this behaviour would be > >changed to copy more characters (of course not more than x.Capacity), your > >code would break. (Such a change might be done for efficiency, e.g. by > >rounding up to a multiple of 4, and though I don't think it's likely to > >be changed, the change would be valid, > > I disagree that it would be valid. > > >AFAIK, since the characters after Length(x) in a string are undefined.) > > Which is why you should only copy to length(s). You probably should, but (AFAIK) you don't have to. > If I do "str1 := str2" , I do not expect an optimiser to make it into; > "str1 := str2 + any junk after the length of str2, up till str2.capacity". Not "str2 + any junk", it's still only "str2", according to the definition of (this kind of) strings. Generally, a string always contains "junk" after the length till the capacity, and you shouldn't rely on anything about this junk. (E.g., I recently modified the WriteStr procedure so that it will not fill a (normal) string with spaces, #0's or whatever as it did before. Only arrays of char are padded with spaces, unless treated as CStrings. I don't think such a change should matter to any "good" program.) > >A possible "fix" for the second problem (not the first one, though the > >appearance of the problem will be different then) would be > >"s[Length(s)+1]:=#0" (also, it's much more efficient). > > I am not sure how this solves the problem. When you explicitly write a #0 into the "junk" area, you can be sure that it will be there (because you don't use any string functions, such as assignments between strings). And it's more efficient because you don't have to copy the contents of the string (twice) and don't need any temp variables. Therefore, you don't have to limit the length of the string (in system.pas it's limited to 255 chars). > That will be good. The compiler can better cater for some things. However, > I have a version of Str2pChar which deals with this bug, but it would require > the user to dispose of memory afterwards - which means it cannot be used > in an expression (which is what I want it for). I have added this version to > system.pas, but commented it out. I have also noted the "full length string bug" > in the sources. This is the fixed version, which seems to work okay. Any > comments? Allocating memory and copying the string seems to be the only way possible in Pascal code that really solves all problems. (Including a third one, namely that the resulting CString isn't influenced by modifications of the Pascal string, as one would expect from a function result. However, I guess this is seldom a real problem because of the way the function is used usually.) Actually, for sometime later we have planned to build the following functions into the compiler: - One that just appends the #0 and returns the addres of the first character of the string (solves problem 2; not 3; problem 1 will be solved by making strings internally bigger than declared by 1 char). For short strings (when they will be introduced), this function will make a temporary copy on the stack (because they must be BP compatible so there will not always be space for the #0 in the string). - One that always makes a copy on the stack and copies the string into it. That's the secure way, but inefficient with very long strings. - One that allocates the memory on the heap. This is needed when the resulting CString is to be used outside of the current scope (when it's not only passed to a function). - One that copies the string in a buffer allocated by the programmer (this is perhaps only for compatibility with BP's StrPCopy). (* Peter, was this what we intended to do, or did I confuse anything? ;*) > program x; > > uses > strings; > > Function Str2pChar ( s : String ) : pChar; > Begin > Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" to do? AFAICS, it copies a string into itself!? I assume it's meant to add a #0 terminator, but I fail to see how it would do this (unless there is already a #0 somewhere)... OTOH, if you're using the strings unit anyway, is there anything wrong with StrPCopy? > End; {* str2pChar *} > > const > s:string=' '+ > ' '+ > ' '+ > ' '+ > ' '#13#10'This program is OK.'; > > t:string=#8#8#8#8' wrong, sorry.'#0; > > var > p:pchar; > begin > p:=str2pchar(s); > writeln(p); > StrDispose(p); { need to dispose of the memory! } > end. This program does not work correctly in my BP. It might seem to work for you because you pass s by value now, so now there will not be t after s in memory (on the stack), but something else. > BTW: > "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile > under GPC ! Peter Gerwinski wrote: > It does under my version of gpc-971001, under DJGPP as well as > under Linux. On mine, it works, too, but only once! The program: program x; const t1:string(255)=#8#8#8#8' wrong, sorry.'#0; const t2:string(255)=#8#8#8#8' wrong, sorry.'#0; begin end. gives the error: y.p:3: numeric constant contains digits beyond the radix ^ for the second(!) declaration. Now, that's strange... Anyway, it seems to be realted to the problem reported in <6dRwLb2VlJB(a)rufus.central.de>. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: String constants #f#0#0'bar'
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to The African Chief: > > This program; > [...] > produces this output from "redir"; > [...] > aka.pas:21: numeric constant contains digits beyond the radix Fixed. Thanks for the report. :-), 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: String constants #f#0#0'bar' (was: New GPC beta: gpc-971001)
by The African Chief 10 Oct '97

10 Oct '97

On Fri, 10 Oct 1997 10:33:35 +0200 (MEST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> BTW: >> "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile >> under GPC ! > >It does under my version of gpc-971001, under DJGPP as well as >under Linux. This program; Program aka; uses gpctypes, system, strings; {$X+} Function sspChar ( s1 : String ) : pChar; Begin sspChar := StrNew ( StrCopy ( @s1 [1], @s1[1] ) ); End; {* sspChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8' wrong, sorry.'#0; var p:pchar; begin p:=sspChar(s); writeln(p); StrDispose(p); end. produces this output from "redir"; Reading specs from c:/djgpp/lib\specs gpc version 971001(2.7.2.1) c:/gpc/bin\gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 aka.pas c:/temp\ccbaaaaa GNU CPP version [unknown] (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/gpc/include c:/gpc/lang/pascal /include /include /usr/include End of search list. c:/gpc/bin\gpc1.exe c:/temp\ccbaaaaa -quiet -dumpbase aka.pas -version -famtmpfile=aka.gpc -fautomake=--automake -fpack-struct -o c:/temp\cccaaaaa GNU Pascal version [unknown] (80386, BSD syntax) compiled by GNU C version 2.7.2.1. GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M gpctypes.pas -o gpctypes.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M system.pas -o system.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M gpctypes.pas -o gpctypes.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -c strings.pas aka.pas:21: numeric constant contains digits beyond the radix Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

EMX binaries on Agnes
by Peter Gerwinski 10 Oct '97

10 Oct '97

Hello! The EMX binaries for gpc-971001 are on Agnes, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-971001.i386-emx09c.zip Thanks to Kevin A. Foss for compiling them. :-) I also included the updated `libgpc.a' into gpc-971001.i386-djgppv201.zip. 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]

1 0

Re: New GPC beta: gpc-971001
by The African Chief 10 Oct '97

10 Oct '97

On Fri, 10 Oct 1997 00:21:00 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> However, I fail to see the problem with Str2pChar. It works correctly in >> all my tests (at least, under BP7, BPW, Delphi 1 and Delphi 2). > >...which is a nice example for the fact that testing alone doesn't prove >correctness... ;-) You are right here! > >First of all, there is a problem if s has full length, and "s+Chr(0)" would >overflow s. Currently this is not noted (a bug in GPC), but when the bug is >fixed, it will either trigger a runtime error or cut the result, i.e. not >append the #0. True :-( > >In BP (which doesn't have this bug and always cuts strings), the routine >indeed behaves wrong is this situation. See the following program: > >program x; > >Function Str2pChar ( Var s : String ) : pChar; >Var >x : String; >Begin > x := s; > s := s + Chr ( 0 ); > Str2pChar := @s [1]; > s := x; >End; {* str2pChar *} > >const > s:string=' '+ > ' '+ > ' '+ > ' '+ > ' '#13#10'This program is OK.'; > t:string=#8#8#8#8'wrong, sorry.'#0; > >var p:pchar; > >begin > p:=str2pchar(s); > writeln(p); >end. Yes, the program shows the bug :-( > >Secondly, you copy back the old value of s back afterwards. This only works >because GPC copies only Length(x) characters. If this behaviour would be >changed to copy more characters (of course not more than x.Capacity), your >code would break. (Such a change might be done for efficiency, e.g. by >rounding up to a multiple of 4, and though I don't think it's likely to >be changed, the change would be valid, I disagree that it would be valid. >AFAIK, since the characters after Length(x) in a string are undefined.) Which is why you should only copy to length(s). If I do "str1 := str2" , I do not expect an optimiser to make it into; "str1 := str2 + any junk after the length of str2, up till str2.capacity". > >A possible "fix" for the second problem (not the first one, though the >appearance of the problem will be different then) would be >"s[Length(s)+1]:=#0" (also, it's much more efficient). I am not sure how this solves the problem. >But don't worry too much about these functions. Sooner or later, such >functionality will be built-in into GPC... That will be good. The compiler can better cater for some things. However, I have a version of Str2pChar which deals with this bug, but it would require the user to dispose of memory afterwards - which means it cannot be used in an expression (which is what I want it for). I have added this version to system.pas, but commented it out. I have also noted the "full length string bug" in the sources. This is the fixed version, which seems to work okay. Any comments? program x; uses strings; Function Str2pChar ( s : String ) : pChar; Begin Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); End; {* str2pChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8' wrong, sorry.'#0; var p:pchar; begin p:=str2pchar(s); writeln(p); StrDispose(p); { need to dispose of the memory! } end. BTW: "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile under GPC ! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

String constants #f#0#0'bar' (was: New GPC beta: gpc-971001)
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to The African Chief: > BTW: > "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile > under GPC ! It does under my version of gpc-971001, under DJGPP as well as under Linux. 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: Another compiler error ...
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to Christian Bockermann: > > chris@bockermann:/home/chris/programs/pascal/indent > gpc --automake wort.p > module.c:1334: failed assertion `0' > [...] This is a problem with the GPI format. It should vanish if you remove all `.gpi' files and then try again. The GPI file format changes with each version of GPC. I hope that we will be able to fix this somewhere in gpc-2.2. If the problem does *not* vanish when you rebuild all `.gpi' files, you have discovered a bug in GPC. In that case, please report it here. 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: New GPC beta: gpc-971001
by Frank Heckenbach 09 Oct '97

09 Oct '97

The African Chief wrote: > However, I fail to see the problem with Str2pChar. It works correctly in > all my tests (at least, under BP7, BPW, Delphi 1 and Delphi 2). ...which is a nice example for the fact that testing alone doesn't prove correctness... ;-) First of all, there is a problem if s has full length, and "s+Chr(0)" would overflow s. Currently this is not noted (a bug in GPC), but when the bug is fixed, it will either trigger a runtime error or cut the result, i.e. not append the #0. In BP (which doesn't have this bug and always cuts strings), the routine indeed behaves wrong is this situation. See the following program: program x; Function Str2pChar ( Var s : String ) : pChar; Var x : String; Begin x := s; s := s + Chr ( 0 ); Str2pChar := @s [1]; s := x; End; {* str2pChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8'wrong, sorry.'#0; var p:pchar; begin p:=str2pchar(s); writeln(p); end. Secondly, you copy back the old value of s back afterwards. This only works because GPC copies only Length(x) characters. If this behaviour would be changed to copy more characters (of course not more than x.Capacity), your code would break. (Such a change might be done for efficiency, e.g. by rounding up to a multiple of 4, and though I don't think it's likely to be changed, the change would be valid, AFAIK, since the characters after Length(x) in a string are undefined.) A possible "fix" for the second problem (not the first one, though the appearance of the problem will be different then) would be "s[Length(s)+1]:=#0" (also, it's much more efficient). But don't worry too much about these functions. Sooner or later, such functionality will be built-in into GPC... Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Another compiler error ...
by chris＠bockermann.ping.de 09 Oct '97

09 Oct '97

Hello everybody ! As I slowly make my program work, another compiler error appearce on my screen : chris@bockermann:/home/chris/programs/pascal/indent > gpc --automake wort.p module.c:1334: failed assertion `0' gpc: Internal compiler error: program gpc1 got fatal signal 6 gpc1: gpc exited with status 1 gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' gpc: Internal compiler error: program gpc1 got fatal signal 6 Does anybody know what that means ? Thanks a lot, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: Writeln and longint
by Frank Heckenbach 09 Oct '97

09 Oct '97

Kevin A. Foss wrote: > Hello, > In my process of getting gpc to compile under OS/2, I've been > trying some example code and Peter recommended trying stuff like > writing longints to see if the new features in 971001 were working. > Well, I tried the following: > -=-=-=-=- > program testlongint(output); > > Var > i : longint; > > begin > i := 1; > writeln(i); > end. > =-=-=-=-= > It compiles fine, but for output I get simply: > > [C:\kevin\pascal\gpc-test]longint > qd > > Any ideas as to what might be going wrong? From looking through the > new RTS code, 'qd' is the format that is used for longints, > (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it > isn't a standard printf() style format (AFAIK) and I don't see code to > parse 'q' in vasprintf.c either -- which I believe is the function that > eventually gets called. I feared this would cause problems somewhere... obviously there isn't a portable way to write "long long"s in C. :-( I'll see what I can do about it. In the worst case, I'll have to rewrite the output of integers completely which I planned to do (later) anyway... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: "Segment fault" error :-(
by Frank Heckenbach 09 Oct '97

09 Oct '97

Christian Bockermann wrote: > (By the way, if you have suggestions for a better style of programming > this copy-function, please let me know, I'm already learning ... :-) In this case, there is quite an easy option: you can use EP(Extended Pascal)'s SubStr function. Incidentally, I just wrote a Copy function on Monday, including some checks for strange situations. Here it is (as in your example, TStr can be any string[n], but not string): function Copy(const s:String;Index,Count:Integer):TStr; begin if Index<1 then begin Dec(Count,1-Index); Index:=1 end; if (Index>Length(s)) or (Count<=0) then Copy:='' else if Index+Count-1>Length(s) then Copy:=SubStr(s,Index,Length(s)-Index+1) else Copy:=SubStr(s,Index,Count) end; Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Writeln and longint
by Peter Gerwinski 09 Oct '97

09 Oct '97

According to Kevin A. Foss: > In my process of getting gpc to compile under OS/2, I've been > trying some example code and Peter recommended trying stuff like > writing longints to see if the new features in 971001 were working. > Well, I tried the following: > [...] > It compiles fine, but for output I get simply: > > [C:\kevin\pascal\gpc-test]longint > qd Ah! The occurrence of this error means that you successfully installed gpc-971001 including the new RTS. :-)-: > Any ideas as to what might be going wrong? From looking through the > new RTS code, 'qd' is the format that is used for longints, > (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it > isn't a standard printf() style format (AFAIK) As far as I can look up from the Linux on-line C documentation, `qd' is a standard format. Some C compilers comply to this standard, while others use `lld' or `Ld' for putting out `long long int'. GCC should support all of these variants, so I wonder what is going wrong on EMX. The same problem holds, BTW, for the DEC Alpha. :-( If anybody knows a portable way to output `long long in' in C, please let us know, so we can improve GPC's RTS. (I know, I am asking this question to the wrong mailing list ...) 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: New GPC beta: gpc-971001
by The African Chief 09 Oct '97

09 Oct '97

On Wed, 8 Oct 1997 20:19:36 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Maurice Lombardi wrote: > >> There is another error in this initialization part (which presumably has >> nothing to do with the crash of the compiler). >> The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer >> of pChar type, Then Dispose'd. So the memory to which CmdLine points is >> reputted into the heap, and can be overwrited by subsequent instructions >> in the main program. Fixed! > >Unfortunately, there are similar bugs (at least) in the functions Str2PChar >(in System.pas) and Int2PChar (GPCUtil.pas). I hope they will be fixed in >the next release. I can see the problemwith Int2pChar (I have fixed it now, by copying the string to the result ( with "StrNew()" ) instead of just assigning it (the user has to free the memory afterwards - with "StrDispose()"). However, I fail to see the problem with Str2pChar. It works correctly in all my tests (at least, under BP7, BPW, Delphi 1 and Delphi 2). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Writeln and longint
by Kevin A. Foss 09 Oct '97

09 Oct '97

Hello, In my process of getting gpc to compile under OS/2, I've been trying some example code and Peter recommended trying stuff like writing longints to see if the new features in 971001 were working. Well, I tried the following: -=-=-=-=- program testlongint(output); Var i : longint; begin i := 1; writeln(i); end. =-=-=-=-= It compiles fine, but for output I get simply: [C:\kevin\pascal\gpc-test]longint qd Any ideas as to what might be going wrong? From looking through the new RTS code, 'qd' is the format that is used for longints, (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it isn't a standard printf() style format (AFAIK) and I don't see code to parse 'q' in vasprintf.c either -- which I believe is the function that eventually gets called. But I imagine I just have some problem somewhere in my port... so any ideas what would cause this? -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Problems with file-handling an new GPC Beta
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Jesper Lund: > > You need to close the file before calling reset. If you add > > close(f) > > just before > > reset(f) > > your program works fine. Whether this is a *feature* or a *bug* depends on > the definitions of reset/rewrite in the (various) Pascal standard(s). [...] I agree. However when we want to claim some compatibility to Borland Pascal, GPC must also support this feature/bug. So I must consider this failure a bug in GPC. Thanks, Christian, for finding it out! :-) 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: "Segment fault" error :-(
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Christian Bockermann: > chris@bockermann:/home/chris/programs/pascal/indent > a.out > Segmentation fault This means that you have written to some memory where you were not allowed to write to. In this case it means that you have filled the string beyond its capacity. Let's see why: > program test; > > type tstr = string[30]; > > var s_test : tstr; > > function copy (s : tstr; p1 : integer; p2 : integer ) : tstr; (* Here you can save some typing by writing "p1, p2: Integer". *) > var > i : integer; > buf : tstr; > begin > for i:=p1 to p2 do What you mean is: "for i:= p1 to p2 + p1 do". > buf[i]:=s[i]; > copy:=buf; Here is the problem: You have assigned some characters to the string, but not a length. Now, "copy:= buf" assigns a string of *random* length to the variable `buf' with a capacity of 30 which causes the crash. > end; > > begin > s_test:='Dies ist ein Test-string'; > writeln(copy(s_test,5,4)); > end. To solve the problem you can either directly assign a length to the string - which is currently only possible by using some more-or-less dirty tricks - or you do it this way: buf:= ''; for i:= p1 to p1 + p2 do buf:= buf + s [ i ]; copy:= buf; BTW (= by the way), your procedure does not check whether `p1 + p2' or even `p1' is in the range of the string `S'. > (By the way, if you have suggestions for a better style of programming > this copy-function, please let me know, I'm already learning ... :-) You mean: You are *still* learning. :-) No problem with this - your style is very good. I have seen a much worse programming style from people who consider themselves "computer freaks". (I may say it here because noone of them is on this list (hopefully).;-) Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Problems Building Latest GPC Beta
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Phil Robertson: > Has anyone seen or have any ideas about this problem with > building the latest Beta: > [...] > include/string.h:127: conflicting types for `perror' > include/errno.h:54: previous declaration of `perror' This looks like broken system header files for me. Sorry, but I have no better suggestion than to look into those header files and see why the declarations conflict. Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: New GPC beta: gpc-971001
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Maurice Lombardi: > > There is another error in this initialization part (which presumably has > nothing to do with the crash of the compiler). > The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer > of pChar type, Then Dispose'd. So the memory to which CmdLine points is > reputted into the heap, and can be overwrited by subsequent instructions > in the main program. This is an error in `system.pas', not in GPC, so I can relax. :-) (* But it's easy to fix: Just remove the line `Dispose ( ppJunk )'. *) 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

"Segment fault" error :-(
by chris＠bockermann.ping.de 08 Oct '97

08 Oct '97

Hello again ! My problems with file handling are all solved - thanks a lot, but as I continue working on my program I get another error message. I wrote an extract from my program, which causes the error : program test; type tstr = string[30]; var s_test : tstr; function copy (s : tstr; p1 : integer; p2 : integer ) : tstr; var i : integer; buf : tstr; begin for i:=p1 to p2 do buf[i]:=s[i]; copy:=buf; end; begin s_test:='Dies ist ein Test-string'; writeln(copy(s_test,5,4)); end. I just wanted to implement the string-function "copy" from Borland Pascal to use it on my Linux-System. The error messages I get is : chris@bockermann:/home/chris/programs/pascal/indent > a.out Segmentation fault Does anybody know this problem ? (By the way, if you have suggestions for a better style of programming this copy-function, please let me know, I'm already learning ... :-) Thanks, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: New GPC beta: gpc-971001
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Maurice Lombardi: > > - The test\extended\time.pas works OK with the bash shell, but is broken > with ordinary command.com DOS shell (or Win3.11 DOS box): [...] I cannot reproduce this. :-( > - more important: when trying to compile the unit System.pas contained > in BPcompat 1.0 I get a SIGSEGV error, [...] Frank has tracked down this error to the following: : : unit system; : interface : implementation : : var junk:integer; : : to begin do : for junk := 1 to 1 do; : : end. (Vielen Dank, Frank!) ... so I will be able to hunt it now. :-) 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]

2 1

Re: New GPC beta: gpc-971001
by Frank Heckenbach 08 Oct '97

08 Oct '97

Maurice Lombardi wrote: > There is another error in this initialization part (which presumably has > nothing to do with the crash of the compiler). > The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer > of pChar type, Then Dispose'd. So the memory to which CmdLine points is > reputted into the heap, and can be overwrited by subsequent instructions > in the main program. Unfortunately, there are similar bugs (at least) in the functions Str2PChar (in System.pas) and Int2PChar (GPCUtil.pas). I hope they will be fixed in the next release. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: GUIs for GPC
by Frank Heckenbach 08 Oct '97

08 Oct '97

The African Chief wrote: > >Is this system-dependent stuff for Linux free software? > >If so, where can I get it? > > I believe (I may be wrong) - that the complete Turbo Vision > port for DJGPP is supplied as part of the RHIDE sources. > So, all you may need to download is rhide14s.zip Yes, seems to be there, thanks! Perhaps this helps to make some system dependent stuff portable, at least to Linux. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Problems with file-handling an new GPC Beta
by chris＠bockermann.ping.de 08 Oct '97

08 Oct '97

Hello all there ! To test the new Beta-Version of GPC I wrote a little program like this : program test; var i : integer; f : FILE of integer; begin assign(f,'./test.dat'); rewrite(f); for i:=1 to 10 do write(f,i); reset(f); while not (eof(f)) do begin read(f,i); writeln(i); end; close(f); end. When compiling there's no error or anything and it compiles quite nice, but when running my program I get a message like this : chris@bockermann:/home/chris/programs/pascal > ./test ?Gpc: `Reset', SeekUpdate' or `SeekRead' to nonexistent internal file `F' What did I do wrong ? Can anybody help me ? Thanks a lot ! Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

3 2

Re: New GPC beta: gpc-971001
by The African Chief 08 Oct '97

08 Oct '97

On Wed, 08 Oct 1997 11:58:25 -0700 Maurice Lombardi <Maurice.LOMBARDI(a)ujf-grenoble.fr> wrote: >Peter Gerwinski wrote: >> Frank has tracked down this error to the following: >> : >> : unit system; >> : interface >> : implementation >> : >> : var junk:integer; >> : >> : to begin do >> : for junk := 1 to 1 do; >> : >> : end. > >There is another error in this initialization part (which presumably has >nothing to do with the crash of the compiler). >The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer >of pChar type, Then Dispose'd. So the memory to which CmdLine points is >reputted into the heap, and can be overwrited by subsequent instructions >in the main program. Oops! I will correct this in the next release of bpcompat, either by disposing of ppJunk in the finalisation part of the unit, or by doing something else! Thanks for the report! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: EFLIB port to GNU Pascal and FPK Pascal.
by The African Chief 08 Oct '97

08 Oct '97

On Tue, 7 Oct 1997 09:18:54 +0200 Johan Larsson <jola(a)ts.umu.se> wrote: >Hi everybody, > > >I have written an OO framework for Borland Pascal. The framework includes >classic data structures, math and soon a complete component-based GUI with >an event-driven machinery similar to the Java PL. The framework, EFLIB, is >written in about 30,000 lines of commented and readable source code. I have >made a lot of efforts to make my framework easy to use and modify. > >I believe porting is not a too difficult task if the target platform is >close to Borland Pascal in standard syntax (like GNU, Delphi and FPK). > >I am looking for people interersted in porting the framework to other >Pascal platforms. The framework is called EFLIB. It is free --- or rather, >the soon-to-come release 3 will be free and include the full source code >for non-commercial use. A license will soon be ready. [....] GPC is in dire need of a complete class library. So, I would be interested in doing some of the work for porting this to GPC, if others would also contribute. Any other takers? The library is big, but many hands make the work lighter. This would also give us the chance to ferret out any remaining "issues" as far as BP compatibility is concerned! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: Compiling gpc-971001with EMX
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Kevin A. Foss: > > [...] Is it safe to use the GPC-CONF.H from the msdos > directory when compiling? or should I try to generate my own > gpc-config.h file? The latter one; but `gpc-conf.h' from `MSDOS' is certainly a good starting point. If you succeed to compile gpc-971001 for EMX I would be glad if you send your changes to me, upload a binary distribution to ftp://agnes.dida.physik.uni-essen.de/incoming and let me know that it is there, so I can move it in place. Unfortunately, I am a little short of time at the moment, ... Thanks in advance, 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

Standard Template Library for Pascal
by Johan Larsson 07 Oct '97

07 Oct '97

Is there an interest in a cross platform STL for Pascal with the following features ... - strings including parsing, searching, positioning etc. - pattern matching (?) - math; matrixes, vectors, complex numbers, integers, reals, polynomials (?) and expressions - streams & filter from scratch to KMP-searching, conversion filters, compression, encryption - GUI (?); componets, generic design, event classes; not ready yet - classic data structures; everything from linear lists, arrays, growing virtual arrays, hash tables of different kinds, (binary) (search) trees, stacks, queues, priority queues, composite ADT class, sorted lists; special plug-in class mechanism with most common sort algorithms; element classes for strings, generic contents, classes etc; element compare plug-in classes that override default behaviors; iterator classes for all data structures; well designed class hierarchy; modular design. I've got it all in an OO design and am looking for porters. I call the f ramework EFLIB as in "Extended Function Library". Runtime files are available in the current prototype release - source code soon released to the public. Best Regards, Johan Larsson E-MAIL jola(a)ts.umu.se HOME http://ftp.sunet.se/EFLIB/ Also, REMEMBER to check out http://www.ts.umu.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

Problems Building Latest GPC Beta
by Phil Robertson 07 Oct '97

07 Oct '97

Has anyone seen or have any ideas about this problem with building the latest Beta: stage1/xgcc -Bstage1/ -c -DIN_GCC -DGPC -g -O2 -I. -I.. -I. -I./. . -I./../config gpc-common.c In file included from include/string.h:48, from gpc-defs.h:64, from gpc-common.c:32: include/memory.h:70: warning: conflicting types for built-in function `memcpy' include/memory.h:78: warning: conflicting types for built-in function `memcmp' In file included from gpc-defs.h:64, from gpc-common.c:32: include/string.h:111: warning: conflicting types for built-in function `strcpy' include/string.h:115: warning: conflicting types for built-in function `strcmp' include/string.h:127: conflicting types for `perror' include/errno.h:54: previous declaration of `perror' *** Error code 1 *** Error code 1 I an running "gpc-971001" and "gcc-2.7.2.1" on a SCO UNIX machine ( i486-unknown-sco3.2v4.2 ). I did not have any problems building the last beta release (July Version). These errors are seen during the stage 1 build after successfully running: patch ... ./configure make LANGUAGES=c Thanks; Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

Re: GUIs for GPC
by The African Chief 07 Oct '97

07 Oct '97

On Tue, 7 Oct 1997 16:19:16 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Peter Gerwinski wrote: > >> *And* it will be easy to port the whole thing to Linux because we can >> "steal" the system-dependent stuff from C-TV for Linux. :-) > >Is this system-dependent stuff for Linux free software? >If so, where can I get it? I believe (I may be wrong) - that the complete Turbo Vision port for DJGPP is supplied as part of the RHIDE sources. So, all you may need to download is rhide14s.zip Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: GUIs for GPC
by Frank Heckenbach 07 Oct '97

07 Oct '97

Peter Gerwinski wrote: > *And* it will be easy to port the whole thing to Linux because we can > "steal" the system-dependent stuff from C-TV for Linux. :-) Is this system-dependent stuff for Linux free software? If so, where can I get it? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: 'CASE' bug!
by Peter Gerwinski 07 Oct '97

07 Oct '97

According to Kevin A. Foss: > EP does have an 'otherwise' > feature and my reading of 10206:6.9.3.5 is that like BP's "else" usage, > "otherwise" doesn't require a begin/end for statement sequences either. I agree about how you read ISO-10206:6.9.3.5. It is like BP, just with `otherwise' instead of `else'. Without a `:' after `otherwise'. So GNU Pascal was wrong here from the very beginning. Unless there are other compilers to keep compatibility with, I will change that. 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]

2 1

Re: Handling files in GPC (with Linux)
by The African Chief 07 Oct '97

07 Oct '97

On Tue, 7 Oct 1997 00:46:49 +0200 (MEST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to Christian Bockermann: > >> Does anyone know what to do ? I just downloaded the bpcompat-packet but >> the files don't compile under Linux. (I'm trying to get some of the units into >> a Linux-version) > >That's a good thing! :-) Agreed. > >The problems you are having when compiling these Units under Linux >come from the missing DPMI stuff and other DOS specifica. Under Linux, >you have to use library functions and/or system calls instead. I am working on an update to bpcompat (soon to be ready), which should compiler under Linux. The current version should compile of you define "__UNIX__" at the beginning of SYSTEM.PAS. This is one of the main things in the update - it will define "__UNIX__" automatically, for Linux, and SVR4. I am compiling a "DEFINES.TXT" to record all the predefined things in various ports of GPC (generated by the GPC compiler for that platform). At the moment, I have the defines to DJGPP, EMX, CYGWIN32, Linux (Elf), Solaris, and Digitsl Alpha. If you have any more, please send them to me. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

EFLIB port to GNU Pascal and FPK Pascal.
by Johan Larsson 07 Oct '97

07 Oct '97

Hi everybody, I have written an OO framework for Borland Pascal. The framework includes classic data structures, math and soon a complete component-based GUI with an event-driven machinery similar to the Java PL. The framework, EFLIB, is written in about 30,000 lines of commented and readable source code. I have made a lot of efforts to make my framework easy to use and modify. I believe porting is not a too difficult task if the target platform is close to Borland Pascal in standard syntax (like GNU, Delphi and FPK). I am looking for people interersted in porting the framework to other Pascal platforms. The framework is called EFLIB. It is free --- or rather, the soon-to-come release 3 will be free and include the full source code for non-commercial use. A license will soon be ready. If this sounds interesting, please feel free to contact me and give me your opinions. I also encourage you to browse to the following URLs to learn a little more about EFLIB and the ideas behind the project: - http://ftp.sunet.se/EFLIB/Features/News/ Newest happenings in EFLIB. - http://ftp.sunet.se/EFLIB/Features/Cool/ Coolest things in EFLIB. - http://www.ts.umu.se/~jola/EFLIB/Manual/Guide/ The User's Guide for prototype 5. - http://www.ts.umu.se/~jola/EFLIB/Developers/ Platform ports, friendly environments, etc. - http://www.ts.umu.se/~jola/EFLIB/Users/ Mailing list, etc. - ftp://ftp.sunet.se/pub/lang/EFLIB/ FTP for files to download (go to prototypes). Best Regards, Johan Larsson E-MAIL jola(a)ts.umu.se HOME http://www.ts.umu.se/~jola/ Also, REMEMBER to check out http://www.ts.umu.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

Re: Handling files in GPC (with Linux)
by Peter Gerwinski 06 Oct '97

06 Oct '97

According to Christian Bockermann: > > I've a little problem. I want to open an ASCII-file in one of my programs > and then edit it. Of course, I did this with TP under MS-DOS, but I don't > have any plan how this works in Linux ?! Almost like with TP. `Append' becomes `Extend', and with anything older than gpc-971001 you need the `Assign' procedure from the BPcompat package. But then it should be the same: Var Z: String ( 1024 ); Assign ( MyFile, 'foo.bar' ); reset ( MyFile ); while not eof ( MyFile ) do readln ( MyFile, Z ); close ( MyFile ); > Does anyone know what to do ? I just downloaded the bpcompat-packet but > the files don't compile under Linux. (I'm trying to get some of the units into > a Linux-version) That's a good thing! :-) The problems you are having when compiling these Units under Linux come from the missing DPMI stuff and other DOS specifica. Under Linux, you have to use library functions and/or system calls instead. Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Beta gpc1001 & RedHat 4.1 Incompatibility
by Ken Linder (KC7RAD) 06 Oct '97

06 Oct '97

Hi again all, Just FYI for you RedHat 4.1 users, GPC still does not play well with that version of RedHat. I hope to know more when I get the most recent ver of RedHat here. Thanks & keep up the GREAT work!! Ken L.

2 1

Question/suggestion for GNU Pascal! (fwd)
by Jan-Jaap van der Heijden 06 Oct '97

06 Oct '97

---------- Forwarded message ---------- Date: Mon, 06 Oct 1997 20:09:48 +0100 From: Johan <u31102265(a)d1o25.telia.com> To: j.j.vanderheijden(a)student.utwente.nl Subject: Question/suggestion for GNU Pascal! Hello! I did not know where to send this. There were so many authors. Maybe you can forward this to the right person(s), unless you are the right one. I am a quite experienced computer programmer, used to both unix and msdos/windos. Still I found the installation documentation very troblesome to read, and not to say perform. (I am talking about the MS-DOS/Windows version. I will manage it, but it will take a lot of unneccesary time, if everyone have to find out themselfs. Why cant there be an automated installation program for the basic functionality in GNU pascal. A one command, and all is installed and ready to run way. That would be the best, but second best, a step by step description, for what to do, if you have to install all from scratch, like this: 1: Download theese files: <insert the needed files here> 2: Expand the files to theese directorys. 3: Start the compiler by: make ... 4: Finished. //Johan

1 0

send pgp-key
by OHMH＠nets.com.jo 06 Oct '97

06 Oct '97

send pgp-key

1 0

gpc problem
by wojciech rolecki 06 Oct '97

06 Oct '97

i've compiled my pascal source file, it is linked to normal ELF executable, but when i'm trying to execute it, everything goes kablooie: [;)] bash: ./something: No such file or directory i was trying to strace it (to see what's going on), but strace gives similiar output: strace: exec: No such file or directory what's going on? -- brat analbert

1 0

Handling files in GPC (with Linux)
by chris＠bockermann.ping.de 06 Oct '97

06 Oct '97

Hello everyone ! I've a little problem. I want to open an ASCII-file in one of my programs and then edit it. Of course, I did this with TP under MS-DOS, but I don't have any plan how this works in Linux ?! Does anyone know what to do ? I just downloaded the bpcompat-packet but the files don't compile under Linux. (I'm trying to get some of the units into a Linux-version) So if someone has a good idea, please help ! Thanks a lot, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: New GPC beta: gpc-971001 (timestamp problem)
by Jesper Lund 06 Oct '97

06 Oct '97

Peter: >> OK, though (no corruption). The problem does occur with version 5.12, or ^^^^ not >> with PKunzip. Moreover, the timestamp problem only affects certain files >Perhaps that's because I zipped these files under Linux with `zip' rather >than under DOS with `pkzip'. I will have a look at that. > Sorry, as you can see, I forgot a "not" before unzip version 5.12 and pkunzip. These programs work (with the correct timestamp), whereas later versions of unzip do not, including the currect version, 5.31. Jesper

1 0

Re: New GPC beta (NO problems with incompatible pointers)
by Jesper Lund 06 Oct '97

06 Oct '97

Peter: >> With the 971001 version, I still get the "incompatible pointer type" that was >> supposed to be fixed (minor problem, of course), > >Strange. I have tried this new GPC on all the test programs I had received >from you, and everything went through. Could you please send me a fresh >program that triggers the error? > I am sorry for posting INCORRECT information to you and the list. The "incompatible pointers" problem has indeed been fixed (thanks) in the new version. However, in the midst of my confusion about the broken GPC library (and the timestamp problem which led me to believe for a while that I had downloaded an old version), I simply failed to notice that I was actually using incompatible pointers (abusing Pascal and treating it as C), so the warnings were perfectly in order for that program! The program in my original bug report compiled OK under the new beta (DJGPP). Thus, now the feature works, but the bug has been fixed. Jesper Lund

1 0

Re: 'CASE' bug!
by Kevin A. Foss 06 Oct '97

06 Oct '97

On Mon, 6 Oct 1997 00:27:19 +0200, Frank Heckenbach wrote: > >Bernhard Tschirren wrote: [...] >> Var >> I : Integer; >> Begin >> Case I Of >> 1: WriteLn('One'); >> 2: WriteLn('Two'); >> Else WriteLn('Big'); >> >> WriteLn('BUG!'); >> End; >> End. > > SP and EP (AFAIK) don't use "else" but >"otherwise" in a "case" statement, so they don't apply here. Actually SP doesn't have an else/otherwise/default/whatever you want to call it technique for case statements. EP does have an 'otherwise' feature and my reading of 10206:6.9.3.5 is that like BP's "else" usage, "otherwise" doesn't require a begin/end for statement sequences either. Or can someone tell if I am reading it wrong? (Note especially, the first example) >(If GPC behaves wrong with "otherwise", that's another thing, I don't know.) Ironically, gpc doesn't compile it with an "otherwise" in there (at least with 970714) -- which *would* be a bug (IMO), but I don't think that is at all what the original poster was getting at. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: GUIs for GPC
by Peter Gerwinski 06 Oct '97

06 Oct '97

According to The African Chief: > I understand that RHIDE was written > in C/C++, with a port of Turbo Vision to DJGPP. If this is correct, It is. Borland doesn't allow free distribution of C-TV, but everybody is allowed to download it directly from Borland. Unfortunately, this does *not* hold for Pascal-TV, AFAIK. :-( > is there > a GPC port of Turbo Vision, or is one being worked on? Can the C version > somehow be used with GPC? Certainly it can, but one must re-write each method of each object to call a C++ method with a rather cryptic AsmName. It will be much easier to port the Pascal TV to GPC. Having that, we can distribute a `diff', so all owners of Borland's TV can patch their source to work with GPC. While I am not an expert on this, I don't think that this violates Borland's copyright. *And* it will be easy to port the whole thing to Linux because we can "steal" the system-dependent stuff from C-TV for Linux. :-) > Is there a GUI library that is suitable for use > with GPC? I am working on one. Planned completion: End of 1996. Estimated completion: Well ... ??? :-( 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]

1 0

Re: 'CASE' bug!
by Peter Gerwinski 06 Oct '97

06 Oct '97

According to Bernhard Tschirren: > > Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous > 'CASE' bug. Have a go at compiling the sample program below: > > > Var > I : Integer; > Begin > Case I Of > 1: WriteLn('One'); > 2: WriteLn('Two'); > Else WriteLn('Big'); > > WriteLn('BUG!'); > End; > End. Yes, it writes "Big BUG!" to the screen - at least if I assign a value not in [ 1, 2 ] to I. What's wrong about that? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: 'CASE' bug!
by Frank Heckenbach 05 Oct '97

05 Oct '97

Bernhard Tschirren wrote: > Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous > 'CASE' bug. Have a go at compiling the sample program below: > > > Var > I : Integer; > Begin > Case I Of > 1: WriteLn('One'); > 2: WriteLn('Two'); > Else WriteLn('Big'); > > WriteLn('BUG!'); > End; > End. > > > Now how did that bug get there :) Cya L8r What bug, please? According to BP, the "else" of a case doesn't require "begin" and "end" for multiple statements, and that's how GPC behaves. I think it is OK, since the "else" part is always terminated by the "case"'s "end", so it's clear how far the else extends, even without another "begin" and "end". SP and EP (AFAIK) don't use "else" but "otherwise" in a "case" statement, so they don't apply here. (If GPC behaves wrong with "otherwise", that's another thing, I don't know.) Or do you mean anything different? (I was guessing the above from your indentation since you didn't state the problem.) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

GPC WWW site updated
by Peter Gerwinski 05 Oct '97

05 Oct '97

Hi, everybody! (* The dial-in connections to the Uni Essen work again; you can expect your mail to me answered soon ... *) I updated the GNU Pascal WWW home site a little and included links to Lluis' HTML version of the mailing list archives and to Frank's To-Do list. Please check whether everything there is correct and/or you like it. (-: Yours, 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

'CASE' bug!
by Bernhard Tschirren 05 Oct '97

05 Oct '97

Hmm, it seems that GPC (971001-DJGPP) is plagued by TurboPascal's famous 'CASE' bug. Have a go at compiling the sample program below: Var I : Integer; Begin Case I Of 1: WriteLn('One'); 2: WriteLn('Two'); Else WriteLn('Big'); WriteLn('BUG!'); End; End. Now how did that bug get there :) Cya L8r ________________________ e-mail: bernie(a)icenet.com.au | _) | | ptschirrenb(a)cc.curtin.edu.au |___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

'GOTO' bug!
by Bernhard Tschirren 05 Oct '97

05 Oct '97

The new GPC BETA (971001) for DJGPP has fixed a lot of bugs. Great work!! Unfortunately, I found a new bug which only affects badly written programs (So why did I find it ?!?!? :). 'GOTO' used in a unit crashes the compiler with a SIGSEGV. Take a look at the code below: Unit Goto_U; Interface Implementation Procedure BugProcedure; Label BugLabel; Begin {$M BEFORE} Goto BugLabel; {$M AFTER} BugLabel: End; End. Cya L8r ________________________ e-mail: bernie(a)icenet.com.au | _) | | ptschirrenb(a)cc.curtin.edu.au |___)ernhard |_|schirren tschirre(a)cs.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: gpc-971001 DJGPP version: mathematical functions
by Anja Drewitz 03 Oct '97

03 Oct '97

Hello, Maurice Lombardi (Maurice.LOMBARDI(a)ujf-grenoble.fr) wrote: > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/libgpc.a.gz > > > Cannot download this file from Netscape. Going to that directory through > http, the file libgpc.a.gz is seen in the listing of the directory, > but Netscape says he cannot find it when I click on it (but it is able > to download other files) ??? It was my error, sorry. I forget to set the attribute 'readable to all'. Now you should be able to download it. Thanks a lot for the report, Anja (: blushing :) Dipl.-Phys. Anja Drewitz, Uni Essen, Germany

1 0

gpc-971001 DJGPP version: mathematical functions
by Anja Drewitz 03 Oct '97

03 Oct '97

>From Peter (the dial-in connections in the Uni Essen are down)-: Hello! The run-tine library in the binary distribution of gpc-971001 for DJGPP is broken and does lack some mathematical functions. (Thanks, Jesper, for the report!:) To correct it, please download and install ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/libgpc.a.gz Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GPC To-Do list
by Frank Heckenbach 03 Oct '97

03 Oct '97

Hi everybody, I've set up a To-Do list for GPC. It contains all bugs known to me as well as wanted features. The bug list currently corresponds to the current beta version (gpc-971001). Most of the entries in the list come from discussions and bug reports on this mailing list. The main purposes of the list are for the developers to keep track of what's left to be done, and for everyone to be able to check if a certain bug is already known, or a certain feature has already been suggested. Some of the entries are written in quite a cryptic way, sorry. I hope this will change a bit in the future. The To-Do list can be found in several formats at the following URLs: HTML: http://home.pages.de/~fjf/gpc-todo_toc.html Info: http://home.pages.de/~fjf/gpc-todo.info Texinfo (gzipped): http://home.pages.de/~fjf/gpc-todo.texi.gz The list will be constantly updated (usually once in a few days). I won't post announcements here when this happens. Greetings, Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

GUIs for GPC
by The African Chief 03 Oct '97

03 Oct '97

Hi all! This is a red-eyed Chief, taking a break from baby-sitting (;-Z A quick question. This is relevant to all our previous discussions about class libraries and all. I understand that RHIDE was written in C/C++, with a port of Turbo Vision to DJGPP. If this is correct, is there a GPC port of Turbo Vision, or is one being worked on? Can the C version somehow be used with GPC? Is there a GUI library that is suitable for use with GPC? Thanks all! PS: I am trying to construct a GPC link on my homepage. It is still at a very early stage, and I have already noticed one error. Please pay a visit, and give me your comments and suggestions. The URL is; http://ourworld.compuserve.com/homepages/African_Chief/gpc.htm Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Compiling gpc-971001with EMX
by Kevin A. Foss 02 Oct '97

02 Oct '97

On Wed, 1 Oct 1997 23:50:19 +0200 (MEST), Peter Gerwinski wrote: >Where to get it >=============== > >The source is being uploaded to > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/, > >files > > gpc-971001.tar.gz and > gpc-971001.zip, > >together with binaries for DOS (DJGPP), and Linux (ELF). Binaries for >DOS and OS/2 (EMX) and FreeBSD will follow as soon as possible. Well in my anxiousness to try out the new version of GPC I downloaded the source and followed the compilation instructions for EMX, however I get this error: gcc -c -DIN_GCC -DGPC -O2 -I. -I.. -I. -I./.. -I./../config gpc-comm.c In file included from gpc-comm.c:32: gpc-defs.h:38: gpc-config.h: No such file or directory dmake: Error code 1, while making 'gpc-comm.o' which looks right as there is no GPC-CONF.H file in the EMX subdirectory. Is it safe to use the GPC-CONF.H from the msdos directory when compiling? or should I try to generate my own gpc-config.h file? -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

subscribe
by Mike Neuhaus 01 Oct '97

01 Oct '97

subscribe

1 0

Re: gpc + gcc 2.7.2.3
by Peter Gerwinski 01 Oct '97

01 Oct '97

According to John Gotts: > > I patched the latest beta version of gpc, using gpc-970714-970812.diff.gz. > > There were a few rejects: > > p/doc/automake.texi.rej.rej > p/doc/gpi.texi.rej.rej > p/doc/how_to_contrib.texi.rej.rej > p/doc/intro.texi.rej.rej > p/Make-lang.in.rej > p/gpi-hash.c.rej > stor-layout.c.rej Strange. I didn't observe such things when I tested this `diff' ... but never mind: A new beta version of GPC is just being uploaded to agnes.dida.physik.uni-essen.de. > In any case, I'm going to try to merge g77 0.5.21 and the latest version of > gpc with gcc 2.7.2.3. (gcc 2.7.2.3.f.1.p.1?). Has anyone attempted such an > endeavor? This has been reported to work. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

gpc + gcc 2.7.2.3
by John Gotts 01 Oct '97

01 Oct '97

I patched the latest beta version of gpc, using gpc-970714-970812.diff.gz. There were a few rejects: p/doc/automake.texi.rej.rej p/doc/gpi.texi.rej.rej p/doc/how_to_contrib.texi.rej.rej p/doc/intro.texi.rej.rej p/Make-lang.in.rej p/gpi-hash.c.rej stor-layout.c.rej I'm particularly concerned about the last reject since it doesn't seem to fit anywhere. In any case, I'm going to try to merge g77 0.5.21 and the latest version of gpc with gcc 2.7.2.3. (gcc 2.7.2.3.f.1.p.1?). Has anyone attempted such an endeavor? [Please cc: me. I'm not on the mailing list.] -- John GOTTS <jgotts(a)engin.umich.edu> http://www-personal.engin.umich.edu/~jgotts

1 0

Re: Random access database
by Peter Gerwinski 28 Sep '97

28 Sep '97

According to Pismo: > > I learned Pascal on VAX-Pascal (DEC VAX-VMS systems), and did allot > of programming with Turbo in the 3.x to 5.5 days. Now I have a > Linux system with GPC and want to write some database stuff using > random access. My recent return to Pascal leaves me wanting to know > how to do this with GPC compared to Turbo? If you keep the whole database in memory, it's about the same as in Turbo Pascal: Use an array, an array of poiners, a linked list, a tree, or whatever. If your structure involves an array, GPC's "array schema" (according to ISO Extended Pascal) could be of interest for you: Type Foo ( n: Integer ) = array [ 1..n ] of Integer; FooPtr = ^Foo; Var f: FooPtr; i: Integer; ... New ( f, 42 ); for i:= 1 to f^.n do f^ [ i ]:= i mod 137; Dispose ( f ); GPC does not have a 64k limit, so you don't need to worry about, say, an array of pointers which is limited to 16380 pointers in Turbo Pascal. If you want to keep the data on disk, the following "dictionary" will be useful for you: Turbo Pascal GNU Pascal Assign See, for instance, the BPcompat package in ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib (The next beta will have a built-in `Assign'.) reset (read-only) reset reset (read/write) update rewrite rewrite append extend Seek SeekRead SeekWrite SeekUpdate close close Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

a bug
by Thomas_Tan＠fc.choate.edu 27 Sep '97

27 Sep '97

THe GNU pascal compiler refuses to compile the gpc.exe, I use WIN95. Can't you guys just PLEASE compile the darn thing(with the executable) in MSDOS and put it on a ftp page?? ------------------------------------------------------ This message sent using the FirstClass SMTP/NNTP Gateway. From: Choate Rosemary Hall 333 Christian St. Wallingford, CT. 06492

3 2

Random access database
by Pismo 27 Sep '97

27 Sep '97

I learned Pascal on VAX-Pascal (DEC VAX-VMS systems), and did allot of programming with Turbo in the 3.x to 5.5 days. Now I have a Linux system with GPC and want to write some database stuff using random access. My recent return to Pascal leaves me wanting to know how to do this with GPC compared to Turbo? pismo(a)mclv.net

1 0

Re: a bug
by Peter Gerwinski 26 Sep '97

26 Sep '97

According to Thomas Tan: > > THe GNU pascal compiler refuses to compile the gpc.exe, I use WIN95. Can't you > guys just PLEASE compile the darn thing(with the executable) in MSDOS and put > it on a ftp page?? What are you trying? Compile GPC with itself? It's written in C. I only can guess that the above is your polite way to ask for a binary distribution that runs under MS-DOS. Please read our FAQ list at http://home.pages.de/~gnu-pascal/gpc-faq.html There you can read that you can get a binary distribution ftp://kampi.hut.fi/jtv/gnu-pasal/binary/gpc-2.0.i386-djgppv201.zip (official version 2.0) or ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ beta/binary/gpc-970714.i386-djgppv201.zip (beta version) for MS-DOS. The official version is also available from any SimTel mirror at the same place where you got the rest of DJGPP, subdirectory `v2gnu', file `gpc20b.zip'. You also might want to have a look at the CygWin version - see the online documentation http://agnes.dida.physik.uni-essen.de/gnu-pascal/gpc-doc.html chapter "Installation" for details. Sincerely, Peter Gerwinski Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GPC Mail Lists in HTML
by Peter Gerwinski 25 Sep '97

25 Sep '97

Hello, everybody. Hello, Lluis. Welcome to the GPC mailing list! According to Lluis de Yzaguirre: > [...] > We have a Sun SparcStation with SunOS 2.4; gpc is installed and works, > at least to compile "hello, world!"; but I will need help about system > calls, curses, file system, and so on. This is the right place to ask. > [GPC mailing list archives in HTML ...] > http://www.iula.upf.es/altres/pub/gpc/list2html/gpclist.htm Thanks a lot. This list looks very reasonable. When I will make over the GPC web site for the next time, I will set up a link. Here are some comments: * What about also listing it in time order? * Since there are programs scanning the WWW for "mailto:" URLs to send some crap there, maybe it's better not to put the e-mail address of each author under the article? I don't know ... * You probably know that the mailing list archives on Agnes are updated daily by a cron script. Are you doing the same? Best wishes, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GPC Mail Lists in HTML
by Lluis de Yzaguirre 25 Sep '97

25 Sep '97

"Hello, world!" was the output of my first Pascal program; let me begin my way in this list with the same words. With this mail I will like to present the conversion to HTML of the list files, but I'll introduce my self. INTRODUCTION I'm a linguist working on "lingware" (Natural Language processing software) for the Catalan language (about 8 million speakers) at University "Pompeu Fabra" in Barcelona. I'm "pascaler" since 1982 (with Turbo-Pascal 2 for CP/M in an Apple II); I have lots of routines in Pascal [e.g. for generation all of the verbal forms in Catalan]: it means that I'm prisoner of my work, because migrating to a newer language implies to translate thousands of code lines; in addition, I like Pascal, so I'm not impatient to change it. At the moment, I use both Think P for Macintosh and Turbo P 7 (I develop in Mac and translate to TP7 for the windoides in my team); now it's time to go to Unix, because of some collaborators outside of our Institute. We have a Sun SparcStation with SunOS 2.4; gpc is installed and works, at least to compile "hello, world!"; but I will need help about system calls, curses, file system, and so on. GPC HTML LIST I don't like to abuse of your help, so the first thing is to read all the past mails. I found that ASCII reading is very annoying, so I wrote a conversion program and I'm studing all your q&a to the list. The conversion is already done and I think it could be useful for other "pascalers", so I put it to general disposition in my Web server as my first contribution to the GPC list. The URL is: http://www.iula.upf.es/altres/pub/gpc/list2html/gpclist.htm I'll apreciate comments (things to be improved, about the interest or nonsense of this work...) MAKING IT MORE EFFICIENT The avantage of the HTML version of the past lists is that you download every time only one message and you can print it if necessary very quickly. If you often access, I suggest to do as follows: 1.- Open one of the index files (v.g. "1997 by subject"). 2.- Save it "as source", i.e. as HTML file, with the name you like. 3.- Because of the line <BASE URL="http://www.iula.upf.es/altres/pub/gpc/list2html/"> in the file, you can open it as local file but with remote links. 4.- If it doesn't work, let me know. -- +-------------------------------------------------------------------+ ! Lluis de Yzaguirre i Maura | Rambla, 30 | tel. 34(3)542.23.32 ! ! Institut Universitari de | E-08071 | fax 34(3)542.23.21 ! ! Linguistica Aplicada | Barcelona | E-Mail de_yza(a)upf.es ! ! Universitat "Pompeu FABRA" | Catalonia | http://www.iula.upf.es ! +-------------------------------------------------------------------+

1 0

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

23 Sep '97

On Tue, 23 Sep 1997 22:52:30 +0200 (MEST), Peter Gerwinski wrote: >According to Kevin A. Foss: >> >> If all you need is system time, why do you go through all of the >> DPMI/int calls/&c, instead of just using extended Pascal's timestamp >> routines. > >These only have a resolution of one second which probably is >not "random" enough for this purpose. The 1/100s when a program >was started is almost a true random number; if we use the second >in the minute it might be too regular. Well then, let's add a 100ths count to timestamp... :) Seriously, is anyone doing any work on adding the proposed extensions to timestamp mentioned in the docs? An implemented us_Timer field would be random enough, I'd think. Of course, I already see this becoming a chicken-and-the-egg problem, because I don't know of a portable way to get system time readings of less than a second. But I would guess that all platforms offer the information in some form or another, and we could populate rts-time.c with a bunch of #ifdefs. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Windows NT
by Tom Dye 23 Sep '97

23 Sep '97

Hello, The boss is setting up Windows NT and I'll need to have gpc to compile code written on my Linux box. I looked through the documentation but couldn't figure out for myself which binary to grab. Can someone help me out? Thanks, Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

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