Gpc November 2002

gpc@gnu.de

33 participants
48 discussions

Re: Conformant array curiosity
by Wood David 24 Mar '03

24 Mar '03

Frank, Thanks for your reply. I've managed to cut down the module to this very short module so I just get two errors, both - prior parameter's size depends on 'A': MODULE Test interface; export Test=(Test_proc); PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); END. MODULE Test implementation; PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. The errors correspond to each assignment although the error line is the declaration. Sure enough, converting this to a unit fixes the problem: UNIT Test; Interface PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); Implementation PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. Is the module syntax illegal or is it a bug? If it is a bug, at least you can take comfort in knowing it can kill the DEC Pascal compiler too! Regards David Wood, QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 2

New alpha
by Frank Heckenbach 14 Dec '02

14 Dec '02

Hi, I've uploaded a new alpha version. Most importantly, thanks to Waldek stabs debugging should now work (at least under Linux, haven't tested on other platforms yet). Also, coff debugging (DJGPP) might work ... Furthermore, the license of the documentation has changed to the GNU Free Documentation License (the counterpart of the GPL for manuals etc.). Thanks to Eike for doing the formalities. Besides, some changes according to recent bug reports and more cleanups have been made. The two makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 15

Delphi compatibility
by Prof. A Olowofoyeku (The African Chief) 12 Dec '02

12 Dec '02

Hi all Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar; You can call them like this; i := foo; // GPC expects this bar; // -- ditto -- j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto -- I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC. Any comments? Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

13 33

Re: Type extension
by Frank Heckenbach 11 Dec '02

11 Dec '02

Frank D. Engel wrote (by private mail, but from the content I suppose it was meant for the list; excuse me if I'm wrong): > How about addition, since in 'subclassing' we would be adding fields: > > TYPE > base = NIL + RECORD > i : INTEGER; > j : INTEGER > END; > > child = base + RECORD > x : REAL; > y : REAL > END; > > otherchild = base + NIL; > > hotdog = NIL + (x : INTEGER; y : REAL); > > cheesedog = hotdog + (t, q : CHAR); > > > Or something similar (prob. the first three preferred; the latter two > are a wild shortcut idea). At first sight, it's certainly a little strange ... BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges). The situation would be a little different from records -- you could assign a value of a small type to a larger one, not vice versa. You wouldn't need `is' and `as', simple comparisons and assignments will do. I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ... Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

5 7

Hewlett Packard Pascal compatibility
by John W. Hardy 06 Dec '02

06 Dec '02

A friend of mine wrote an extensive CAD program using HP-Pascal back in the mid 1980s. The program was used exclusively on HP workstations. HP had two variations of Pascal. One was a standalone operating environment, the other worked under HPUX. The CAD program was developed under the workstation version. My friend would like to move this program to the PC world. One approach is "P2C" which converts HP-Pascal code to C. I just discovered GPC and would like to know if it is fairly compatible with HP-Pascal. I'm sure there would be a ton of rewriting that would be necessary whether the P2C or GPC approach is taken, but I would like to get a general idea of GPC compatibility. Thank you very much. John Hardy

6 9

Re: Delphi compatibility
by Prof. A Olowofoyeku (The African Chief) 05 Dec '02

05 Dec '02

On 24 Nov 2002, 13:02:36 Martin Liddle wrote: >>On that question the silence of other members of this list has been >>deafening. I can only assume that this is because no-one else is >>interested in Delphi compatibility. If so, then it renders any >>debate moot. If not, then it would be good to hear what others >>think. > >This is free software. The people doing the work are free to do >whatever they want. That is merely to state the obvious - but it is a sad day when this is considered an appropriate response to a question about whether and to what extent a certain feature should be added to GNU software. I didn't think that GNU was about the dictatorship of the maintainers. I doubt that Frank himself would consider the statement: "I do the work, so I can do anything I please" to be sound reasoning or an appropriate response. >Personally I have been happy with Frank's priorities. So have I - and so have (one must assume) most people on this list. That does not dispense with the need sometimes to discuss (and agree or disagree on) important issues. If an issue is important to one person, then it is important and discussion thereon should not be stifled because it irritates, bores, or disinterests others. >I'd much sooner he spent his time working on the compiler than >engage in endless debates on this list. No-one wants to engage in endless debates - and there comes a time when any particular debate must end, and I was the one who brought that one to an end (since it started with a question that I raised). One major difference between liberal and autocratic societies lies in the free flow of information and ideas in the former - even ideas that might be controversial or unpopular. The day that legitimate discussion on difficult or controversial questions becomes stifled or unwanted on this list is the day that I will say goodbye. >For the record, Delphi compatibility would be of some minor interest >to us. This is what I was asking about. And this is the response that answers that question. It is clear that there is little desire here for Delphi compatibility. So be it. At least we now have a clear idea on how people feel about it (presumably those who are silent are not interested). So we can forget about Delphi compatibility, and life can go on. Frank, you're now officially "off the hook", and you can concentrate your efforts on features that people do want ;-). I guess this also signals doom for my "Delphi compatibility" units, which can perhaps quietly disappear. This is not necessarily a bad thing, because I have long been dubious as to whether anyone other than me is using them. I still intend of course to continue to develop them for my own purposes, so those who are interested in them will be able to get updates. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

3 4

Definition files for KATE
by Silvio a Beccara 04 Dec '02

04 Dec '02

Hi all, I use Kate (for KDE) to edit GPC programs. Since not all of the keywords of GPC are listed in the definition file for colour evidentiation for Pascal, I was wondering whether someone has written a complete definition file for GPC. Thanks, best wishes Silvio a Beccara - University of Trento, Italy

3 2

text variable interface problem with gpc-20021111
by Martin G C Davies 30 Nov '02

30 Nov '02

Hi, Testing gpc-20021111 I have hit a problem trying to remove duplicate variables. I've produced a cut-down example and the two sources are:- mgcd_module.pas =============== module mgcd_module interface; export mgcd_module = all; var statfile : text; end. module mgcd_module implementation; end. mgcd_program.pas ================ program mgcd_program; import mgcd_module; #if __GPC_RELEASE__ < 20021111 var statfile : text; #endif begin rewrite(statfile, 'mgcd.statfile'); writeln(statfile, 'some stats'); end. I build and run with the command sequence:- gpc -c mgcd_module.pas gpc -c mgcd_program.pas gpc mgcd_program.o mgcd_module.o a.out and I get a core dump with gpc-20021111. I used to get a core dump with earlier versions until I used the kludge of the duplicate variable - but this is now illegal. The underlying problem appears to be something to do with file data structures not being initialized. Thus the above works with:- gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 2.1 (20020510), based on gcc-2.8.1 but fails with:- gpc -v Reading specs from /ClearCase_01/mgcd/gcc-3.1.1_gpc-20021111_install.dir/lib/gcc-lib/sparc-sun- solaris2.6/3.1.1/specs Configured with: /ClearCase_01/mgcd/gcc-3.1.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.1.1 _gpc-20021111_install.dir : (reconfigured) /ClearCase_01/mgcd/gcc-3.1.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.1.1 _gpc-20021111_install.dir Thread model: posix gpc version 20021111, based on gcc-3.1.1 Hopefully someone can tell me how I can solve/workaround this problem. Martin G C Davies

3 2

gpc-20021128, gcc-3.2.1
by Russell Whitaker 29 Nov '02

29 Nov '02

Hi Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/specs Configured with: ../gcc-3.2.1/configure --enable-languages=pascal Thread model: posix gpc version 20021128, based on gcc-3.2.1 1. applied patch manually ( as usual ): ok 2. gpc check with -g 72 fail 3. gpc check with -gstabs 0 fail Russ

1 0

Re: Type extension
by Adriaan van Os 27 Nov '02

27 Nov '02

> Seriously, what would be the benefit of adding it? Compatibility for > some existing code, or the guarantee that such records will not > contain any methods, or anything else? Nothing more than a clarification (not wanting OOP methods, but the type extension only) > I currently don't see an easy way out. Unless someone has a > suggestion, I think that kills it (i.e., there must be a syntactic > difference between "inheritable" and normal records). You are right, there must be a be a syntactic difference between "inheritable" and normal records. So, what about: T = EXTENSIBLE RECORD x, y: INTEGER END T0 = RECORD (T) z: REAL END T1 = RECORD (T) w: LONGREAL END Regards, Adriaan van Os

2 1

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 November 2002