Gpc February 1997

gpc@gnu.de

12 participants
34 discussions

Restrictions on packed types?
by Jakob Heinemann 10 Feb '97

10 Feb '97

Hello! I read somewhere that GPC actually doesn't pack things in types which are declared as PACKED. Is this true? What about packed array's of char, i.e. non-varying strings? /Jakob :) mailto:Jakob.Heinemann@lmemw.ericsson.se

1 0

BO5, Turbo Vision, Objects
by Peter Gerwinski 09 Feb '97

09 Feb '97

Sven Hilscher wrote: > You also still working on the GPC-TurboVision ??? Yes, in some sense. I am still working on BO5. At the moment, it is the Windows platform which prevents me from going on. :-( Everything else in the low-level drivers more or less works, so I would like to start to implement the actual user interface objects. However BO5 is not intended to become a drop-in replacement for Turbo Vision (just like GPC is not intended to imitate the Borland Pascal compiler) but something more powerful. In case somebody wants to have a compatible replacement for Turbo Vision, there are (at least) two ways to get it: * There is FreeVision which comes with FPK Pascal. It should not be too difficult to port it to GPC. * Borland has released the C source of Turbo Vision (*not* the Pascal source) into the public domain. One could translate it to Pascal, imitating the functionality of the Pascal Turbo Vision. I do not recommend to patch the "real" Turbo Vision to run with GNU Pascal because it would remain under Borland's license, so we could not freely distribute it. The only thing we could do would be to distribute the patch, so every owner of a Borland Turbo Vision license could apply it. > I'm only will using the objects for this part if I > dont lose lots of speed (I think 5% it's worth). I think the loss of speed will be less than 1% due to GPC's very efficient optimization algorithms. But one should try. > BTW: GPC is'nt perfect and this will take a long time too but I like it in > spite of that. So do I. What I really like is to have the possibility to get the source of the compiler; so if nobody else is fixing some annoying bug for me, I can try myself on it. I remember several letters I have sent to Borland without getting any answer besides "your letter has arrived" ... 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: function pointers - whats wrong ???
by Peter Gerwinski 09 Feb '97

09 Feb '97

According to Sven Hilscher: > I tryed to use the famous function pointers, but I can't compile this > stuff. I tryed the example from info files - the same sh... > > [...] > > Now it's your turn ... what's wrong? GPC. :-( It's broken. But it *did* work! I'll try to fix it as soon as possible. > How I can put the stderr output in a file? I'm using DJGPP. That's in the DJGPP FAQ, section 6.9. > It's possible to speed up the standard compilation of gpc for my pentium? > What's the floating point type of gpc's complex numbers? That's in the DJGPP FAQ, chapter 7. An additional hint: Stubedit the linker (\djgpp\bin\ld.exe) to get a transfer buffer with the maximum size of 64k: G:\DJGPP\BIN> stubedit ld.exe ... Size of real-memory transfer buffer [...]: 64k According to my experience, time is wasted not in the compilation pass, but during linking. > Anybody is using my graph unit "BGI2GRX"? Und ob! Yes. For most of my friends, this was the final argument to try GPC. :-) > I'm working on a direct GRX20-Unit (contexts, mouse, ...) but I don't know > if it's needed by anybody else me. 8-) I would really prefer to work with a direct GRX20 Unit because I expect it to be more powerful than Borland's "BGI" interface. So please go on with it! :-) However I join Sven in asking: Anybody is using Objects with GPC? I am thinking about improving object functionality, but if I am the only one who uses them, it's not worth the effort because GPC's objects essentially meet my needs like they are right now. 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 - http://home.pages.de/~gnu-pascal/ [970125]

2 1

More bugs fixed --> another new alpha GPC on agnes
by Peter Gerwinski 08 Feb '97

08 Feb '97

Hello again, in case you downloaded gpc-2.0-970206.diff.gz - it is already obsolete because I went on and fixed the following bugs: * Handle `absolute' variables in "declaring statements". (GNU extension: `Var' declarations in the function body.) * String schema types now survive transport through a GPI file - even without specified length. * Now you can take the address of a function with `&' or `@', i.e., you can actually use pointers to functions. * When a Unit (or Module - not a Program!) imported an object from another Unit, the methods did not survive the transport through the GPI file. Now they do. A new diff against gpc-2.0 is on agnes, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-2.0-970207.diff.gz Sorry for the inconsistency in GPC ;-) but I promise that I will not upload the next diff tomorrow because I won't have time :-( to work on GPC for the next days. It is getting more and more stable ... (: 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: function pointers - whats wrong ???
by The African Chief 07 Feb '97

07 Feb '97

On Fri, 7 Feb 1997 16:07:07 +0100 (MET) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >However I join Sven in asking: Anybody is using Objects with GPC? > >I am thinking about improving object functionality, but if I am the >only one who uses them, it's not worth the effort because GPC's objects >essentially meet my needs like they are right now. More Borland compatibility (especially "Object Pascal" - viz., Delphi) would be good. This is a vital point because other Pascal implementations (esp. on the OS/2 platform) are already supporting (or intending to support) the Delphi extensions. I wouldn't think that it was an urgent issue, but it would be nice if it was added to GPC one day ... Best regards, The Chief Dr A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.10 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: GPC module restrictions etc
by Peter Gerwinski 07 Feb '97

07 Feb '97

According to Jakob Heinemann: > I'm looking at GPC to decide wether or not to use it to port a quit > large application from VMS to Unix. > > [...] > > According to the > documentation the GPI-mechanism is not as stable as it should be. > but what is the actual problem? > what are the limitations? > the problem of unsized strings and GPI import? (I get a warning that > there are incompatible pointers > when calling an imported function with a varying string.) > is there som work beeing done to fix it? Some constructs do not survive transport through a GPI file. The most important thing is probably the generic String Schema type (without specified length). This will be fixed next. There are also some problems concerning file and object types. As a workaround, you can (*$include *) the Interface Modules into your source (above the `Program' headline). Then you can compile the Implementation Modules separately and link everything together. This mechanism is considered stable. The GPI problem is annoying, but it is solved in theory. What remains is a bulk of work to determine which parts of which structure must be stored in the GPI file. > Other questions that I also came up with are: > Calling functions in C, is easy, just put a C; as a declaration af the > body. How about > calling functions in ADA (i.e. Gnat)? You can import any function written in any language by writing a Pascal Procedure/Function head for it. (This does survive transport through a GPI file.) The `C' keyword is named in a little misleading way. It means: "Import that function and assume that its name is in lowercase." - independent of the question what compiler produced that function. For mixed case you can use the `AsmName' directive: Type Pointer = ^Void; Function XEventsQueued ( Display: Pointer; Mode: Integer ): Integer; AsmName 'XEventsQueued'; > The other way around, other > languages calling > functions written in Pascal? No problem if the other language supports that. For example, to use a Procedure FooBar ( x: Integer; Var y: Char ); from a C program, import it as extern void Foobar ( int x, char *y ); Note that the First Letter Of The Pascal Name Is Capitalized and does not depend on how you write the name in your Pascal source. (The same holds when debugging a program written in GNU Pascal: You have to specify all symbols with one capital letter.) > The code uses lots of varying length strings written partly as schemas, > and partly as some > sort of conformant arrays in parameter lists. A piece fo code may look > like this: > > Var text_str : varying (. len .) of char ; > > procedure testproc ( str : varying (.len .) of char ); > var i : integer ; > begin > for i :=3D 1 to len do > something(i,str); > end ; > > This should translate to > > Var text_str : string; > > procedure testproc ( str : string ); > var i : integer ; > begin > for i :=3D 1 to length(str) do > something(i,str); > end ; Yes, this should work. The problem to transport a `String' through a GPI file is worked on, but for the moment you can include the Interfaces as a workaround (see above). > But how about the vax statement for issuing variable amount of > arguments? > Vax-pascal: > > procedure test_pro ( var arg1 : integer; [list] therest : integer) ; > var cnt : integer ; > begin > arg1:=3D 0 ; > for cnt :=3D 1 to argument_list_length (therest) do > arg1 :=3D arg1 + argument(therest, cnt): > end; > > Is there a construct for this in GPC? (in that case I=B4m sorry but I > haven=B4t found it in the manual) GNU Pascal has an ellipsis parameter for variable argument lists: Procedure Test_Pro ( Var arg1: Integer; ... ); but at the moment we do not provide a way to access those arguments. (However this feature is useful to work with C functions having variable argument lists.) Since VAX Pascal seems to provide such a mechanism it could be a good idea to implement that scheme into GPC, too, instead of inventing a new method to achive this functionality. It would be nice if you could tell me more about this - and perhaps about other nice features of VAX Pascal which you would like to see in GNU Pascal. It might be that they are relatively easy to implement - in that case we would probably do it, and you can save a lot of work porting your application. If all additional parameters have the same type, you can use either conformant arrays or "open arrays" (according to Borland Pascal) to pass them: Procedure Test ( Var arg1: Integer; Var therest: array of Integer ); Then you can pass any array of Integers as the actual parameter; in the function body the lower bound of the array is assumed to be zero. > I don=B4t think I'm on the subscriberlist so please post your reply > directly to me aswell. I am doing so, so you should get this mail twice if you are on the list. > (I've tried to subscribe , but I'havent hear anything...) The list is maintained manually, so delays are possible. If the delay lasts too long, please complain to gpc-request(a)hut.fi. Even if you are not on the list, you can read it via the list archives on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/, updated daily. You can also get them through the GNU Pascal WWW home page, http://home.pages.de/~GNU-Pascal/. > Thank you guys, Gnu Pascal's great, but I still miss some important > consepts from the > extended pascal definition. (Schemas and module integrity...) > Hope that all the stuff will be there some day, right now I feel it is > not so safe > that it will suit our need for this project, but perhaps in the future.. I am myself porting a large project (104 modules, 102k lines :-P) from Borland Pascal (DOS) to GNU Pascal (DOS, OS/2, UNIX, ...), so there is hope that GNU Pascal will become more reliable not too far in the future. Please be patient - or offer your help! Thanks for your interest, 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: this ** works only with simple Real ???
by Peter Gerwinski 07 Feb '97

07 Feb '97

According to Sven Hilscher: > > ["**" problem] > > Put in what you want. The result is right for Real, but for __long__ Real > it's everytime the result = 1.0. I get other results, too, but not the correct one. > I think the conversion of the exponent > from Real to __long__ Real does'nt work: Probably. At the moment, the runtime library does not support __modified__ types. It was simply luck that your program did not crash on the "writeln". To do anything besides plain addition, multiplication, ... with __long__ Reals, you have to cast them to Real at the moment. We are working on it, but this does not have the highest priority for me: On the 80x87, all calculations are done with __long__ Reals anyway, and you only lose precision when writing such a Real to memory, for example to do a "**" or a "writeln". For the moment I suggest to live with plain Reals. 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: function pointers - whats wrong ???
by David Fiddes 07 Feb '97

07 Feb '97

Hi, > I am thinking about improving object functionality, but if I am the > only one who uses them, it's not worth the effort because GPC's objects > essentially meet my needs like they are right now. The only reason I don't use GPC for "real" projects is it's lack of object compatibility with Delphi 2.0/3.0...I would have volenteered except my C isn't that great and I don't understand compilers... Dave Fiddes Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

Some bugs fixed --> new alpha GPC on agnes
by Peter Gerwinski 07 Feb '97

07 Feb '97

Hello, folks! A snapshot of my current GPC source is now available via anonymous ftp on agnes.dida.physik.uni-essen.de, directory gnu-pascal/alpha. It is a diff against gpc-2.0. Changes: * Some cosmetical changes not worth to talk about. ;-) * Patched the runtime library to allow conio operations and access to device files on the MSDOS platform. * Fixed wrong --pedantic warning for `rewrite'. * New command-line option `-dY' to dump the source to stderr. This is useful when trying to figure out *where* gpc crashed ... * Fixed a really crazy bug concerning objects. (See below.) * Handle assignment between sets of different sizes correctly. Beware: When assigning a large set to a smaller one, it is truncated without warning or runtime check. And there might still be errors in this part of the compiler. The story about the "crazy" object-related bug follows. It's hard to believe, but it's true - just check it with gpc-2.0! Program Test; Type TestObj = object FooBar: array [ 0..27 ] of Char; end (* TestObj *); Procedure Init ( x: Integer ); begin (* Init *) x:= 7; end (* Init *); begin Init ( 3 ); end. This program compiles, but it crashes at runtime. )-: Change `FooBar' to be an `array [ 0..28 ]' of Char, and it works. Note that the object is just a type declaration and everything which is really executed has nothing to do with it. I tried different upper bounds for `FooBar' from 0 to 100. The crash happens with 23..27. The solution: There was an error with variable initializers. :-)-:-(-:-)-:-(-:-)-:-(-:-)-:-(-:-)-:-(-:-)-:-(-:-)-:-(-:-)-:-(-: To understand this, one must know about the internal structure of objects in contrast to that of records. While records have just their fields, objects have an additional invisible "vmt" field which contains a pointer to the "Virtual Method Table". This table contains (a) the size of the object and (b) the addresses of all virtual methods. `TestObj' above does not have virtual methods, but it has a size - which is 32 bytes if the upper bound of `FooBar' is 23..27 - thus it needs a VMT. This VMT is an initialized variable, and the initial value of 32 for the size of the object triggered the error. Voila! It's fixed now. As a side-effect, initializers for other structured variables are more stable now, too: Var foo: record i: Integer; x: Real; end (* foo *) value ( 1; 3.1415 ); bar: array [ 1..3 ] of Char value ( 'b', 'a', r' ); Okay, so let's go on! Good night, |-) 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

this ** works only with simple Real ???
by Sven＠rufus.central.de 07 Feb '97

07 Feb '97

Hello gpc, program Test; { Shows the ** fault } var a, b : Real; c, d : __long__ Real; begin Readln(a); Readln(b); Writeln(a ** b : 20 : 10); c := a; d := b; Writeln(c ** d : 20 : 10); end. Put in what you want. The result is right for Real, but for __long__ Real it's everytime the result = 1.0. I think the conversion of the exponent from Real to __long__ Real does'nt work: c ** 0.0 = 1.0 ;-) ___, ((__ o ,____)) V E N I

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 February 1997