From gpc-request@santra.hut.fi Wed Sep 13 15:20:13 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA13823; Wed, 13 Sep 1995 15:20:12 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA11541; Wed, 13 Sep 95 15:20:01 CEST Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id PAA18619 for ; Wed, 13 Sep 1995 15:43:04 +0300 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA13628; Wed, 13 Sep 1995 14:42:54 +0200 From: Peter Gerwinski Message-Id: <9509131242.AA13628@rs1.Theo-Phys.Uni-Essen.DE> Subject: GPC for EMX, objects, gperf To: gpc@hut.fi Date: Wed, 13 Sep 1995 14:42:53 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1271 Status: RO Hello everybody. I have three questions to the mailing list. 1) I am thinking about porting GPC to the DOS / OS/2 EMX environment. Does anybody already work on that task or has even finished it? 2) I would like to know more about when there will be Object Pascal extensions in GPC, and how they will look like. (E.g. "class" instead of Borland's "object"? Does "override" mean what I know as "virtual"?) 3) While trying to implement some Borland extensions into the GPC (i.e. shl/shr operators, OOP, ...) I stumbled about the utility program "gperf". I got the source - one as stand-alone C++ source, one as part of the C++ library - but could not compile it with gcc-2.6.3 running under Linux kernel 1.2.8. Does anybody know where to get Linux binaries for gperf? So far for the moment. Thank you, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Wed Sep 13 16:35:40 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA13608; Wed, 13 Sep 1995 16:35:39 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA11686; Wed, 13 Sep 95 16:30:47 CEST Received: from pg2-srv.wam.umd.edu ([128.8.73.9]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id QAA19978 for ; Wed, 13 Sep 1995 16:42:25 +0300 Received: from rac9.wam.umd.edu (lotu@rac9.wam.umd.edu [128.8.70.8]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id JAA18077; Wed, 13 Sep 1995 09:40:29 -0400 Received: (lotu@localhost) by rac9.wam.umd.edu (8.6.10/8.6.10) id JAA08827; Wed, 13 Sep 1995 09:40:28 -0400 Date: Wed, 13 Sep 1995 09:40:26 -0400 (EDT) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: GPC for EMX, objects, gperf In-Reply-To: <9509131242.AA13628@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 13 Sep 1995, Peter Gerwinski wrote: > 1) I am thinking about porting GPC to the DOS / OS/2 EMX environment. Does > anybody already work on that task or has even finished it? I was thinking about downloading the source this weekend and try to recompile it under EMX/GCC myself. But since you want to do it, I might as well wait until you're done :-). It should be rather straight forward to recompile GPC under the EMX environment, shouldn't it? I had problems recompiling GPC under DOS and DJGPP (actually, I never did manage to recompile it under DOS but only because I switched to OS/2 and dumped DOS so I never really tried hard enough :-)), because of DOS's 8.3 filename limitation and some of the GPC source files have long filenames. Under OS/2 and HPFS this shouldn't be a problem. Isn't the makefile for GPC in "standard" UNIX make file format? You could just get GNU Make, I guess. (I use IBM's NMAKE myself, which is why I ask). So it sounds easy enough. Just recompile GCC under OS/2 so you get the object files, then recompile GPC. Hmm ... is that all there is to it? I remember somebody telling me they managed to compile GPC under EMX, but the way he described his experiences it wasn't as straight forward as I think. Is it? Am I missing something here? > 2) I would like to know more about when there will be Object Pascal extensions > in GPC, and how they will look like. (E.g. "class" instead of Borland's > "object"? Does "override" mean what I know as "virtual"?) I thought GPC is supposed to be an Extended Pascal and ISO Pascal compiler only .. i.e. it follows "official" standards. Is Object Pascal standardized? You *might* be able to consider Borland somewhat of a standard ... there are already two Pascal compilers for OS/2 that comply with the Borland "standard" .. Speed Pascal/2 and Virtual Pascal. (Also, the latest version of Speed/2, v. 1.5, is supposed to have the "Delphi extenstions", i.e. Object Pascal, in it ...). Anyhow, if you're gonna add the Object Pascal and Borland extensions yourself, that'd be pretty cool. Having a free Pascal compiler that follows 4 standards (ISO Pascal, Extended Pascal, Borland, and Object Pascal) and is portable across several platforms would be awesome. I wish I could help, but unfortunatly I don't know squat about writing compilers ... but I'd be happy to be a beta tester 'tho :-). Later ... Arcadio From jtv@kampi.hut.fi Wed Sep 13 16:51:35 1995 Received: from kampi.hut.fi by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22327; Wed, 13 Sep 1995 16:42:10 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id RAA09057; Wed, 13 Sep 1995 17:12:49 +0300 Date: Wed, 13 Sep 1995 17:12:49 +0300 (EET DST) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: Arcadio Alivio Sincero Cc: Peter Gerwinski , gpc@hut.fi Subject: Re: GPC for EMX, objects, gperf In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 13 Sep 1995, Arcadio Alivio Sincero wrote: > On Wed, 13 Sep 1995, Peter Gerwinski wrote: > > > 1) I am thinking about porting GPC to the DOS / OS/2 EMX environment. Does > > anybody already work on that task or has even finished it? > > > I was thinking about downloading the source this weekend and try > to recompile it under EMX/GCC myself. But since you want to do it, I > might as well wait until you're done :-). It should be rather straight > forward to recompile GPC under the EMX environment, shouldn't it? I had > problems recompiling GPC under DOS and DJGPP (actually, I never did manage > to recompile it under DOS but only because I switched to OS/2 and dumped > DOS so I never really tried hard enough :-)), because of DOS's 8.3 > filename limitation and some of the GPC source files have long filenames. > Under OS/2 and HPFS this shouldn't be a problem. Isn't the makefile for > GPC in "standard" UNIX make file format? You could just get GNU Make, I > guess. (I use IBM's NMAKE myself, which is why I ask). Hi folks. I think gpc has been succesfully compiled and run in both the dos and os/2 environments (although I don't even know what emx is, and I am not sure I even want to know that :-) I think I am able to get the dos binaries and start distributing them if someone would like to avoid the problems in compiling gpc under dos. Are people interested in binaries? gpc makefiles are quite standard, they should not require any specific makefile features, except the VPATH variable, which tells where the make program should look for sources. Gnu make is fine. Most other new make programs are also fine. > > 2) I would like to know more about when there will be Object Pascal extensions > > in GPC, and how they will look like. (E.g. "class" instead of Borland's > > "object"? Does "override" mean what I know as "virtual"?) GPC parser only knows the object pascal reserved words, but there is no semantics to implement the language. However, given that the Gnu C++ compiler implements very similar features, I think it is quite possible to implement the object pascal compiler with gpc as starting point. I thought of doing that once, but unfortunately (for gpc) I don't have time for it now. I know I said I would try to merge gpc to the standard distribution during the summer, but I was not able to spend time with gpc during the summer at all. Sorry for that. What I am able to do sometime in the near future is to upgrade to 2.7 gcc code, that should not be a major problem (I hope). > I thought GPC is supposed to be an Extended Pascal and ISO Pascal > compiler only .. i.e. it follows "official" standards. Is Object Pascal > standardized? You *might* be able to consider Borland somewhat of a > standard ... there are already two Pascal compilers for OS/2 that comply with > the Borland "standard" .. Speed Pascal/2 and Virtual Pascal. (Also, the > latest version of Speed/2, v. 1.5, is supposed to have the "Delphi > extenstions", i.e. Object Pascal, in it ...). I think the object pascal draft is not going to change anymore, which means it is going to be standardized some point in the (near) future. I have a copy of the last draft, and it does look very interesting. Also, I am never going to do the Borland compatibility mode myself, but I have no objections to include those changes in gpc mainline *if* someone would write them first and not just talk about it. Please do, there are many programmers out there who really seem to like borland, and it would be very useful for the project to be compatible with borland. > Anyhow, if you're gonna add the Object Pascal and Borland > extensions yourself, that'd be pretty cool. Having a free Pascal compiler > that follows 4 standards (ISO Pascal, Extended Pascal, Borland, and Object > Pascal) and is portable across several platforms would be awesome. I wish > I could help, but unfortunatly I don't know squat about writing compilers > ... but I'd be happy to be a beta tester 'tho :-). Yes, it would be cool. But also remember that gpc is not quite finished yet, it still requires lots of hacking to implement the missing features... Juki jtv@hut.fi From lotu@wam.umd.edu Wed Sep 13 17:49:40 1995 Received: from pg2-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22339; Wed, 13 Sep 1995 17:48:39 +0200 Received: from rac5.wam.umd.edu (lotu@rac5.wam.umd.edu [128.8.70.121]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id LAA01432; Wed, 13 Sep 1995 11:44:54 -0400 Received: (lotu@localhost) by rac5.wam.umd.edu (8.6.10/8.6.10) id LAA24255; Wed, 13 Sep 1995 11:44:40 -0400 Date: Wed, 13 Sep 1995 11:44:39 -0400 (EDT) From: Arcadio Alivio Sincero To: Jukka.Virtanen@hut.fi Cc: Peter Gerwinski , gpc@hut.fi Subject: Re: GPC for EMX, objects, gperf In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 13 Sep 1995, Jukka Virtanen wrote: > Hi folks. > > I think gpc has been succesfully compiled and run in both the > dos and os/2 environments (although I don't even know what emx is, > and I am not sure I even want to know that :-) > I think I am able to get the dos binaries and start distributing > them if someone would like to avoid the problems in compiling > gpc under dos. Are people interested in binaries? > gpc makefiles are quite standard, they should not require any > specific makefile features, except the VPATH variable, which tells > where the make program should look for sources. Gnu make is fine. > Most other new make programs are also fine. Personally, I wouldn't mind a set of OS/2 binaries :-). Unless recompiling GPC for OS/2 is simply a matter of running the make file through GNU Make. EMX, BTW, is one of the OS/2 GCC ports. It can also run under 32-bit extended DOS (using the VCPI standard by default 'tho), so if you recompile it for OS/2 you are also making a version for DOS as well. Convienent, 'eh? > Also, I am never going to do the Borland compatibility mode > myself, but I have no objections to include those changes in gpc > mainline *if* someone would write them first and not just talk > about it. Please do, there are many programmers out there who > really seem to like borland, and it would be very useful for the > project to be compatible with borland. I'd probably move away from the Borland "standard" if a powerful Extended Pascal or Object Pascal compiler was readily available to me. Mainly because Borland is not a "real standard". 'Tho maybe it should be because a lot of people seem to use it. > Yes, it would be cool. But also remember that gpc is not > quite finished yet, it still requires lots of hacking to implement > the missing features... What's missing still? Arcadio From gpc-request@santra.hut.fi Thu Sep 14 07:49:18 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21013; Thu, 14 Sep 1995 07:49:17 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA14019; Thu, 14 Sep 95 07:49:11 CEST Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id HAA29180 for ; Thu, 14 Sep 1995 07:49:37 +0300 Received: from hsb.nest.nl by sun4nl.NL.net with SMTP id AA02374 (5.65b/CWI-3.3); Thu, 14 Sep 1995 06:49:31 +0200 Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.6.11/8.6.11) with UUCP id GAA07473 for hut.fi!gpc; Thu, 14 Sep 1995 06:46:26 +0100 Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Thu, 14 Sep 95 05:37:17 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG2337; Thu, 14 Sep 1995 05:30:52 +0 Date: 13 Sep 95 19:37:18 +0 Message-Id: <60-60-0-0-0576b330@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: GPC for EMX, objects, gperf Status: RO Jukka Virtanen wrote in a message to Berend de Boer: JV> gpc makefiles are quite standard, they should not require JV> any specific makefile features, except the VPATH JV> variable, which tells where the make program should look JV> for sources. Gnu make is fine. Most other new make JV> programs are also fine. The problem is dos' command.com is no bourne shell... That's the hardest part. Groetjes, Berend (-: CIS: 100120,3121 email: berend@beard.nest.nl From gpc-request@santra.hut.fi Thu Sep 14 07:54:40 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22056; Thu, 14 Sep 1995 07:54:39 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA14030; Thu, 14 Sep 95 07:54:34 CEST Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id HAA29183 for ; Thu, 14 Sep 1995 07:49:47 +0300 Received: from hsb.nest.nl by sun4nl.NL.net with SMTP id AA02380 (5.65b/CWI-3.3); Thu, 14 Sep 1995 06:49:42 +0200 Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.6.11/8.6.11) with UUCP id GAA07472 for hut.fi!gpc; Thu, 14 Sep 1995 06:46:24 +0100 Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Thu, 14 Sep 95 05:37:08 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG2336; Thu, 14 Sep 1995 05:30:51 +0 Date: 13 Sep 95 19:25:32 +0 Message-Id: <60-60-0-0-057678d2@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: GPC for EMX, objects, gperf Status: RO Peter Gerwinski wrote PG> 1) I am thinking about porting GPC to the DOS / OS/2 EMX PG> environment. Does anybody already work on that task or PG> has even finished it? Yes. There is a djgpp recompile and an emx. Both should be easy, just a recompile if you have a bourne shell, else you need to create your own makefile. PG> 2) I would like to know more about when there will be PG> Object Pascal extensions in GPC, and how they will look PG> like. (E.g. "class" instead of Borland's "object"? PG> Does "override" mean what I know as "virtual"?) See the Ansi OOP draft, probably online soon (follow comp.lang.pascal.ansi-iso). Groetjes, Berend (-: CIS: 100120,3121 email: berend@beard.nest.nl From pege Fri Sep 15 15:41:17 1995 Subject: GPC for EMX works! To: gpc@hut.fi Date: Fri, 15 Sep 1995 15:41:17 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 634 Status: RO Hello, folks! I have done the patch of GPC for EMX. It was not straightforward but not more work than I had expected. I upload the binaries and the source patch to kampi.hut.fi. Have fun with it! Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From sad@utkux.utcc.utk.edu Fri Sep 15 19:17:19 1995 Received: from MARTHA.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20125; Fri, 15 Sep 1995 19:17:08 +0200 Received: by martha.utcc.utk.edu (5.x/2.7c-UTK) id AA13857; Fri, 15 Sep 1995 13:16:42 -0400 From: sad@utkux.utcc.utk.edu Message-Id: <9509151716.AA13857@martha.utcc.utk.edu> Subject: Re: GPC for EMX works! To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Fri, 15 Sep 1995 13:16:41 -0400 (EDT) In-Reply-To: <9509151341.AA23044@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Sep 15, 95 03:41:18 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, Peter, this is very good news. Thanks for the effort! I will d/l it tonight and play with it. BTW, can it peacefully coexist with g77 (the gnu fortran compiler, which changes the gcc.exe)? If not, would you care to have a chat with the porter of g77? (He also happens to be German.) Cheers again! Stefan > > Hello, folks! > > I have done the patch of GPC for EMX. It was not straightforward but not more > work than I had expected. I upload the binaries and the source patch to > kampi.hut.fi. > > Have fun with it! > > Peter From lotu@wam.umd.edu Sat Sep 16 02:48:57 1995 Received: from wor-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22353; Sat, 16 Sep 1995 02:48:31 +0200 Received: from rac9.wam.umd.edu (lotu@rac9.wam.umd.edu [128.8.70.8]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id UAA16412; Fri, 15 Sep 1995 20:47:17 -0400 Received: (lotu@localhost) by rac9.wam.umd.edu (8.6.10/8.6.10) id UAA26772; Fri, 15 Sep 1995 20:47:15 -0400 Date: Fri, 15 Sep 1995 20:47:14 -0400 (EDT) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: GPC for EMX works! In-Reply-To: <9509151341.AA23044@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Sep 1995, Peter Gerwinski wrote: > Hello, folks! > > I have done the patch of GPC for EMX. It was not straightforward but not more > work than I had expected. I upload the binaries and the source patch to > kampi.hut.fi. > Have fun with it! Where on kampi.hut.fi? Or you probably haven't done it yet when I read the message? Ok ... when you do you upload it, be sure to tell us where it is. kampi.hut.fi is in Europe and I'm in the U.S., so the connection is S-L-O-W. I'd hate having to hunt around on kampi.hut.fi ... thanks! Arcadio From jtv@kampi.hut.fi Mon Sep 18 09:06:45 1995 Received: from kampi.hut.fi by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23964; Mon, 18 Sep 1995 09:06:29 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id KAA13723; Mon, 18 Sep 1995 10:06:20 +0300 Date: Mon, 18 Sep 1995 10:06:19 +0300 (EET DST) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: GPC for EMX works! In-Reply-To: <9509151341.AA23044@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 15 Sep 1995, Peter Gerwinski wrote: > Hello, folks! > > I have done the patch of GPC for EMX. It was not straightforward but not more > work than I had expected. I upload the binaries and the source patch to > kampi.hut.fi. > > Have fun with it! > > Peter Folks, The EMX binaries made by Peter are now available in kampi.hut.fi directory jtv/gnu-pascal/EMX There is a README file, please read it. Contents of the EMX directory: -r--r--r-- 1 jtv 35231 Sep 15 16:57 tar.exe -r--r--r-- 1 jtv 167476 Sep 15 16:57 tar-os2.exe -r--r--r-- 1 jtv 5468 Sep 15 16:55 README -r--r--r-- 1 jtv 188138 Sep 15 16:54 make-gpc.zip -r--r--r-- 1 jtv 39910 Sep 15 16:53 gzip.exe -r--r--r-- 1 jtv 1005157 Sep 15 16:52 gpc-263b.zip If I understood correctly, the make-gpc.zip contains a couple of modified source files (compared to gpc-2.6.3 sources you can find from jtv/gnu-pascal/gpc-1.1-2.6.3.tar.gz) The file gpc-263b.zip contains binaries for gpc driver program, gpc1 compiler, the gpc-cccp preprocessor and the gpc library. Juki ps. I don't have any systems around with emx in it, so I am unable to verify if these programs work... From sad@utkux.utcc.utk.edu Tue Sep 19 20:18:57 1995 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA09888; Tue, 19 Sep 1995 20:18:52 +0200 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA07727; Tue, 19 Sep 1995 14:18:09 -0400 From: sad@utkux.utcc.utk.edu Message-Id: <9509191818.AA07727@utkux4.utcc.utk.edu> Subject: Re: GPC for EMX works! Announcments? To: Jukka.Virtanen@hut.fi Date: Tue, 19 Sep 1995 14:18:08 -0400 (EDT) Cc: pege@rs1.Theo-Phys.Uni-Essen.DE In-Reply-To: from "Jukka Virtanen" at Sep 18, 95 10:06:19 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Jukka and Peter, do you think (or mind) announcing this os/2 port of gpc in the appropriate news groups, like comp.os.os2.announce, comp.os.os2.programming, and comp.lang.pascal.ansi-iso? There are still rumors that there would be no os/2 port, you know, eventhough I have downloaded it already ... :-) Later. Stefan PS: I you give me the go-ahead I don't mind doing it. From lotu@wam.umd.edu Wed Sep 20 23:52:37 1995 Received: from pg2-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA14081; Wed, 20 Sep 1995 23:52:26 +0200 Received: from rac9.wam.umd.edu (lotu@rac9.wam.umd.edu [128.8.70.8]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id RAA10293; Wed, 20 Sep 1995 17:52:05 -0400 Received: (lotu@localhost) by rac9.wam.umd.edu (8.6.10/8.6.10) id RAA10722; Wed, 20 Sep 1995 17:52:04 -0400 Date: Wed, 20 Sep 1995 17:51:52 -0400 (EDT) From: Arcadio Alivio Sincero To: Jukka.Virtanen@hut.fi Cc: Peter Gerwinski , gpc@hut.fi Subject: Re: GPC for EMX works! In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 18 Sep 1995, Jukka Virtanen wrote: > > The EMX binaries made by Peter are now available > in kampi.hut.fi directory jtv/gnu-pascal/EMX I just downloaded them and tried it out. Unfortunatly, I was a little disappointed with it. The resulting object files seemed to be highly unoptimized. I compiled a simple "Hello, world" program using GPC with the "-Zomf" option to produce OS/2 .OBJ files instead of UNIX a.out. The resulting executable was 68363 bytes. I compiled a similar "Hello, world" program using GCC (a direct translation) also with the "-Zomf" option and the resulting executable file was only 21809 bytes. Is there anything I can do to fix this? I know probably the EMX translation was a "rush job", but maybe y'all can give me some pointers as to how to optimize it a bit. (Or maybe I can get somebody else if Peter is too busy ...). Also, for some reason when I use the "-O3" switch, the resulting object file actually becomes bigger! Why is that? At first when I converted the GPC.A file to OMF format, I didn't strip any debugging info or anything. The resulting executable was pretty huge (90k) for such a small program. After stripping the debug info and what not, the exe was "only" 68k ... so that helped a bit. Is there anything else I can do? At least I can use this compiler for my CMSC112 class ... "Introduction to Computer Science with Pascal" ... oohh ... tough class :-). I found out that Virtual Pascal doesn't do ISO Pascal and probably Borland is the same, so this compiler will come in handy as then I don't have to work on projects at school .. I can do it in the privacy of my room. Later ... Arcadio From jtv@kampi.hut.fi Thu Sep 21 11:31:36 1995 Received: from kampi.hut.fi by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20809; Thu, 21 Sep 1995 11:31:19 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id MAA17807; Thu, 21 Sep 1995 12:30:42 +0300 Date: Thu, 21 Sep 1995 12:30:39 +0300 (EET DST) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: sad@utkux.utcc.utk.edu Cc: Jukka.Virtanen@hut.fi, pege@rs1.Theo-Phys.Uni-Essen.DE Subject: Re: GPC for EMX works! Announcments? In-Reply-To: <9509191818.AA07727@utkux4.utcc.utk.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 19 Sep 1995 sad@utkux.utcc.utk.edu wrote: > Hi Jukka and Peter, > > do you think (or mind) announcing this os/2 port of gpc in the > appropriate news groups, like comp.os.os2.announce, > comp.os.os2.programming, and comp.lang.pascal.ansi-iso? > There are still rumors that there would be no os/2 port, you know, > eventhough I have downloaded it already ... :-) > > Later. Stefan > > PS: I you give me the go-ahead I don't mind doing it. I don't mind, I just hope it works :-) Juki From sad@utkux.utcc.utk.edu Thu Sep 21 15:04:18 1995 Received: from MARTHA.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26276; Thu, 21 Sep 1995 15:04:06 +0200 Received: by martha.utcc.utk.edu (5.x/2.7c-UTK) id AA27468; Thu, 21 Sep 1995 09:03:36 -0400 From: sad@utkux.utcc.utk.edu Message-Id: <9509211303.AA27468@martha.utcc.utk.edu> Subject: Re: GPC for EMX works! Announcments? To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Thu, 21 Sep 1995 09:03:35 -0400 (EDT) Cc: jtv@kampi.hut.fi (Jukka Virtanen) In-Reply-To: <9509211243.AA25690@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Sep 21, 95 02:43:01 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > According to sad@utkux.utcc.utk.edu: > > > > Hi Jukka and Peter, > > > > do you think (or mind) announcing this os/2 port of gpc in the > > appropriate news groups, like comp.os.os2.announce, > > comp.os.os2.programming, and comp.lang.pascal.ansi-iso? > > There are still rumors that there would be no os/2 port, you know, > > eventhough I have downloaded it already ... :-) > > > > Later. Stefan > > > > PS: I you give me the go-ahead I don't mind doing it. > > > I don't mind, I just hope it works :-) > Juki > > I don't mind either. I also only hope it works. :-> > > Peter Okay, so I take it one of you will take care of this, right? Or do you mean that neither of you does mind *me* doing it? Lemme know. Stefan :-] ---- now where is that .sig of mine?! From jtv@kampi.hut.fi Thu Sep 21 15:14:16 1995 Received: from kampi.hut.fi by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25519; Thu, 21 Sep 1995 15:14:03 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id QAA18242; Thu, 21 Sep 1995 16:13:10 +0300 Date: Thu, 21 Sep 1995 16:13:08 +0300 (EET DST) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: sad@utkux.utcc.utk.edu Cc: Peter Gerwinski Subject: Re: GPC for EMX works! Announcments? In-Reply-To: <9509211303.AA27468@martha.utcc.utk.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 21 Sep 1995 sad@utkux.utcc.utk.edu wrote: > > According to sad@utkux.utcc.utk.edu: > > > > > > Hi Jukka and Peter, > > > > > > do you think (or mind) announcing this os/2 port of gpc in the > > > appropriate news groups, like comp.os.os2.announce, > > > comp.os.os2.programming, and comp.lang.pascal.ansi-iso? > > > There are still rumors that there would be no os/2 port, you know, > > > eventhough I have downloaded it already ... :-) > > > > > > Later. Stefan > > > > > > PS: I you give me the go-ahead I don't mind doing it. > > > > > > I don't mind, I just hope it works :-) > > > Juki > > > > I don't mind either. I also only hope it works. :-> > > > > Peter > > Okay, so I take it one of you will take care of this, right? Or do you mean > that neither of you does mind *me* doing it? Lemme know. Stefan :-] If you wish to announce the availability of the EMX binaries, just go ahead. But also note that you should consider the gnu general public license and distribution of binaries. It is rather a complicated process, you should be sure that you are able to provide sources to everyone who get a copy of the binary. As the 2.6.3 sources are now available, it seems ok. But how about a year from now? I trust you keep a copy around :-) Just to be sure, please read the gnu licenses, for both the programs and the libraries. This is the reason I would not like to distribute binaries at all; but I understand that it might be complicated for some people to get the things compiled and working, sigh. Juki jtv@hut.fi From gpc-request@santra.hut.fi Sat Sep 30 00:10:11 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22474; Sat, 30 Sep 1995 00:10:10 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA12212; Sat, 30 Sep 95 01:10:07 CEST Received: from npd.ufsc.br (npd.ufsc.br [150.162.1.3]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id AAA19538 for ; Sat, 30 Sep 1995 00:55:16 +0200 Received: from venus (inf.ufsc.br [150.162.1.60]) by npd.ufsc.br (8.6.8.1/8.6.6) with SMTP id NAA53336 for ; Fri, 29 Sep 1995 13:45:41 -0500 Received: from mercurio.ufsc.br by venus (4.1/SMI-4.1) id AA11271; Fri, 29 Sep 95 13:46:10 EST Date: Fri, 29 Sep 95 13:46:10 EST From: merkle@inf.ufsc.br (Carla Merkle) Message-Id: <9509291646.AA11271@venus> To: gpc@hut.fi Status: RO subscribe gpc merkle@inf.ufsc.br From gpc-request@santra.hut.fi Fri Oct 6 13:31:53 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27192; Fri, 6 Oct 1995 13:31:52 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16363; Fri, 6 Oct 95 13:31:43 CET Received: from chx400.switch.ch (chx400.switch.ch [130.59.1.2]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id MAA12991; Fri, 6 Oct 1995 12:55:28 +0200 Received: from idiap.ch (actually maya.idiap.ch) by chx400.switch.ch with SMTP (PP); Fri, 6 Oct 1995 11:54:39 +0100 Received: from rose.idiap.ch by idiap.ch (4.1/SMI-4.1) id AA21030; Fri, 6 Oct 95 11:54:34 +0100 Date: Fri, 6 Oct 95 11:54:34 +0100 From: peter@idiap.ch (Peter Weber) Message-Id: <9510061054.AA21030@idiap.ch> To: jtv@hut.fi, peter@idiap.ch Subject: gpc Cc: gpc@hut.fi Status: RO Hi I translated a big pc-program (former Turbo-Pascal) into a gpc-program. I found some problems and have some questions! -gcc version 2.6.3 -can not make comments with included comments program test; begin { this is ok! } (* this also *) { (* you get a error*) } { { also get a error } } end. How dos it work >>EXPORT, IMPORT<gpc -c test.pas ==>test.o >gpc test.o testp.pas ==>No exported interface matching `Test' I found only one way to compile this: >gpc -include test.pas testp.pas How do you compile this? Have you implemented routines to handle the I/O Errors? (e.g. Turbo Pascal => IOResult ); ,~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. | --------,\ | | Peter Weber / / / | | IDIAP Martigny Peter@IDIAP.CH / / _/ | | TU Ilmenau Peter.Weber@E-Technik.TU-ILMENAU.DE / / | | _/ _/ | |----------------------------------------------------------------------| | http://www.idiap.ch/html/idiap-networks.html | | http://www.rz.tu-ilmenau.de/~webmast/ | | http://www.rz.tu-ilmenau.de/~hsf/hsf.html | `~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From gpc-request@santra.hut.fi Mon Oct 23 21:39:11 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26425; Mon, 23 Oct 1995 21:39:10 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA20958; Mon, 23 Oct 95 21:39:06 CET Received: from txcc.net.txcc.net (txcc.net [205.218.183.157]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id WAA29484 for ; Mon, 23 Oct 1995 22:30:21 +0200 Received: by txcc.net.txcc.net (4.1/SMI-4.1) id AA14797; Mon, 23 Oct 95 15:29:01 PDT Date: Mon, 23 Oct 95 15:29:01 PDT From: root@txcc.net (Operator) Message-Id: <9510232229.AA14797@txcc.net.txcc.net> To: gpc@hut.fi Subject: test Status: RO hello.. From gpc-request@santra.hut.fi Wed Nov 1 01:45:46 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA29401; Wed, 1 Nov 1995 01:45:45 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA22149; Wed, 1 Nov 95 01:45:40 CET Received: from info-sparc1.info.ucl.ac.be (info-sparc1.info.ucl.ac.be [130.104.2.23]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id CAA06034 for ; Wed, 1 Nov 1995 02:30:05 +0200 Received: from info.ucl.ac.be (info-gtpp1.info.ucl.ac.be [130.104.21.67]) by info-sparc1.info.ucl.ac.be (8.6.12/fg.05.10.95) with ESMTP id BAA20539 for ; Wed, 1 Nov 1995 01:36:53 +0100 Received: from localhost by info.ucl.ac.be (8.6.12/SMI-4.1 (For sendmail 8.6 FG/041095)) id BAA05296; Wed, 1 Nov 1995 01:34:23 +0100 Message-Id: <199511010034.BAA05296@info.ucl.ac.be> X-Mailer: exmh version 1.6.4 10/10/95 To: gpc@hut.fi Subject: converter bp->ep Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Nov 1995 01:34:21 +0100 From: Christophe Ponsard Status: RO I'd like to convert some of my borland pascal units in extended pascal modules (or in gpc modules). Does such a converter exist (and where) ? Otherwise I'll write one using flex & bison on a subset of the extended pascal grammar. It would be nice if I could get it (the .lex and .yacc files are not in the gpc snapshot) Is there a solution to the following constraint : the interface part of all the modules used by a program have to be included at his beginning. The solution of deducing the name of the module file from the import name (as borland do) was excluded (not portable ?) My converter would implement the solution using #include "unit.ph" directives in the main program. Each borland pascal unit would be splitted in a 'unit.pas' file (implementation) and a 'unit.ph' file (interface). --------------------------------------- PONSARD Christophe Universiti catholique de Louvain Dipartement d'inginierie informatique Bbtiment Riaumur, place Sainte Barbe 1348 Louvain-la-Neuve til. : 010/47 31 30 e-mail: chp@info.ucl.ac.be From gpc-request@santra.hut.fi Thu Nov 2 13:07:26 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA07457; Thu, 2 Nov 1995 13:07:25 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27623; Thu, 2 Nov 95 13:07:21 CET Received: from spv10.ing.uniroma1.it (spv10.ing.uniroma1.it [151.100.39.10]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id NAA06533 for ; Thu, 2 Nov 1995 13:52:53 +0200 Received: by spv10.ing.uniroma1.it (AIX 3.2/UCB 5.64/4.03) id AA16818; Thu, 2 Nov 1995 12:52:45 +0100 Date: Thu, 2 Nov 1995 12:52:45 +0100 From: i085741@spv10.ing.uniroma1.it (Mauro Ottaviani) Message-Id: <9511021152.AA16818@spv10.ing.uniroma1.it> To: gpc@hut.fi Subject: HELP ! Status: RO Hello, I have a problem using files with gpc: In Turbo Pascal I usually use the following: var f:text; begin assign(f,'filename'); reset(f); ... close(f); But this doesn't work with gpc !! I tryed: reset(f,'filename'); This time it also compiled OK, but gives a runtime error !! Please HELP me ! Best regards Mauro Ottaviani From gpc-request@santra.hut.fi Thu Nov 2 15:30:24 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA04997; Thu, 2 Nov 1995 15:30:23 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27988; Thu, 2 Nov 95 15:30:19 CET Received: from wor-srv.wam.umd.edu (wor-srv.wam.umd.edu [128.8.76.2]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id QAA09725 for ; Thu, 2 Nov 1995 16:14:22 +0200 Received: from rac1.wam.umd.edu (lotu@rac1.wam.umd.edu [128.8.70.3]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id JAA15648; Thu, 2 Nov 1995 09:14:15 -0500 Received: (lotu@localhost) by rac1.wam.umd.edu (8.6.10/8.6.10) id JAA10656; Thu, 2 Nov 1995 09:14:14 -0500 Date: Thu, 2 Nov 1995 09:14:13 -0500 (EST) From: Arcadio Alivio Sincero To: Mauro Ottaviani Cc: gpc@hut.fi Subject: Re: HELP ! In-Reply-To: <9511021152.AA16818@spv10.ing.uniroma1.it> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 2 Nov 1995, Mauro Ottaviani wrote: > Hello, > I have a problem using files with gpc: > In Turbo Pascal I usually use the following: > var > f:text; > begin > assign(f,'filename'); > reset(f); > ... > close(f); > But this doesn't work with gpc !! > I tryed: > reset(f,'filename'); > This time it also compiled OK, but gives a runtime error !! > Please HELP me ! In ISO Pascal, you have to specify any external files accessed by your program in the Program header. For example: Program Demo1 (InFile, OutFile); Var InFile, OutFile : Text; Begin Reset (InFile); Rewrite (OutFile); End {Demo1}. 'Tho ISO Pascal has no provisions for specifying a filename for the external files, most Pascal implementations allow you to do so via the Reset/Rewrite commands. GPC is one of these Pascal implementations. So, modifying the above program to open the files "INDATA" for input and "OUTDATA" for output: Program Demo2 (InFile, OutFile); Var InFile, OutFile : Text; Begin Reset (InFile, './INDATA'); Rewrite (OutFile, './OUTDATA'); End {Demo2}. In ISO Pascal, files are automatically closed when the program terminates, therefore there is no "Close" command. Some Pascal implementations, like Borland, do have a "Close" command. I don't know if GPC has one or not. Also, the files "Input" and "Output" are special files used for standard input and standard output respectivly. So to use Read/Readln and Write/Writeln to get input from the keyboard and to display something on the screen, you have to put a "Input, Output" in your program header. A little different from Borland, I know. But actually, if you think about it, it's a little better to specify what external files are used in the Program header. That way you know exactly what files are gonna be opened by just looking at the Program header. I didn't like it at first, but now I think it's not a bad idea. Arcadio From gpc-request@santra.hut.fi Thu Nov 2 18:20:35 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA04975; Thu, 2 Nov 1995 18:20:34 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28438; Thu, 2 Nov 95 18:20:31 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id TAA12448 for ; Thu, 2 Nov 1995 19:02:21 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA04944; Thu, 2 Nov 1995 18:02:12 +0100 From: Peter Gerwinski Message-Id: <9511021702.AA04944@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: HELP (files) To: gpc@hut.fi Date: Thu, 2 Nov 1995 18:02:12 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 987 Status: RO > Hello, Hello as well! > I have a problem using files with gpc: > > In Turbo Pascal I usually use the following: > > var > f:text; > > begin > assign(f,'filename'); > reset(f); > ... > close(f); > > But this doesn't work with gpc !! Look into the file borland2ep.doc by Berend de Boer which comes with GPC. There is documented how to write `assign' by yourself using GPC's `bind' procedure. This has proven to work in some cases, but not in all ... perhaps it will work when we also take into account Arcadio's hint. Good luck, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Nov 2 19:57:20 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA18132; Thu, 2 Nov 1995 19:57:19 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28614; Thu, 2 Nov 95 19:57:16 CET Received: from mail.fonorola.net (mail.fonorola.net [198.53.64.8]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id UAA14424 for ; Thu, 2 Nov 1995 20:38:03 +0200 Received: from liti.magi.com by mail.fonorola.net with SMTP (5.65/25-eef) id AA06934; Thu, 2 Nov 95 13:05:09 -0500 Received: from slavitch.loran.com (slavitch@slavitch.loran.com [204.191.52.2]) by loran.com (8.6.12/8.6.9) with ESMTP id NAA06256 for ; Thu, 2 Nov 1995 13:21:03 -0500 Received: (from slavitch@localhost) by slavitch.loran.com (8.6.12/8.6.9) id NAA02208; Thu, 2 Nov 1995 13:12:47 -0500 Date: Thu, 2 Nov 1995 13:12:47 -0500 Message-Id: <199511021812.NAA02208@slavitch.loran.com> From: Michael Slavitch To: gpc@hut.fi Subject: gpc and gcc 2.7 on Linux.... Status: RO Has anyone successfully used gpc with gcc 2.7.0? Michael From gpc-request@santra.hut.fi Mon Nov 6 18:34:56 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25872; Mon, 6 Nov 1995 18:34:55 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA12986; Mon, 6 Nov 95 18:34:46 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id TAA17753 for ; Mon, 6 Nov 1995 19:13:42 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20648; Mon, 6 Nov 1995 18:13:24 +0100 From: Peter Gerwinski Message-Id: <9511061713.AA20648@rs1.Theo-Phys.Uni-Essen.DE> Subject: Announcement: Borland extensions for GPC To: gpc@hut.fi Date: Mon, 6 Nov 1995 18:13:23 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 878 Status: RO Hello, folks! I have implemented most of the Borland extensions -- and some other stuff -- into GPC. My extensions include: - Units - Compiler directives - Bit manipulations: and, or, shl, shr - Increment, decrement, min, max - Absolute variables - Objects - User-definable operators The modified sources are available on kampi.hut.fi in the directory /gpc/turbo-alpha. I am looking forward to receive your comments. :-) Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From lotu@wam.umd.edu Tue Nov 7 16:16:55 1995 Received: from pg2-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA31344; Tue, 7 Nov 1995 16:16:39 +0100 Received: from rac1.wam.umd.edu (lotu@rac1.wam.umd.edu [128.8.70.3]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id KAA21201; Tue, 7 Nov 1995 10:16:06 -0500 Received: (lotu@localhost) by rac1.wam.umd.edu (8.6.10/8.6.10) id KAA16273; Tue, 7 Nov 1995 10:16:05 -0500 Date: Tue, 7 Nov 1995 10:16:04 -0500 (EST) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Announcement: Borland extensions for GPC In-Reply-To: <9511061713.AA20648@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 6 Nov 1995, Peter Gerwinski wrote: > I have implemented most of the Borland extensions > -- and some other stuff -- into GPC. > My extensions include: > - Units > - Compiler directives > - Bit manipulations: and, or, shl, shr > - Increment, decrement, min, max > - Absolute variables > - Objects > - User-definable operators > The modified sources are available on kampi.hut.fi > in the directory /gpc/turbo-alpha. > I am looking forward to receive your comments. :-) Awesome. Good job Peter! 'Tho I wish somebody would finish up the Extended Pascal portions of GPC. I'm trying to steer myself away for using the Borland "standard" (or non-standard ...). Well, at least now we got a "Borland" Pascal compiler for Linux (there is a Linux version, right? I've only recently switched from OS/2 to Linux ... but I'm pretty sure I saw a Linux version last time I was on kampi.hut.fi ...). Arcadio From gpc-request@santra.hut.fi Tue Nov 7 17:28:42 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27870; Tue, 7 Nov 1995 17:28:41 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16739; Tue, 7 Nov 95 17:28:17 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id SAA09140 for ; Tue, 7 Nov 1995 18:08:18 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA28752; Tue, 7 Nov 1995 17:07:06 +0100 From: Peter Gerwinski Message-Id: <9511071607.AA28752@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Announcement: Borland extensions for GPC To: lotu@wam.umd.edu, gpc@hut.fi Date: Tue, 7 Nov 1995 17:07:05 +0100 (MEZ) In-Reply-To: from "Arcadio Alivio Sincero" at Nov 7, 95 10:16:04 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1645 Status: RO According to Arcadio Alivio Sincero: > > Awesome. Good job Peter! Thank you! :-) :-) :-) > 'Tho I wish somebody would finish up the Extended Pascal portions > of GPC. I'm trying to steer myself away for using the Borland "standard" > (or non-standard ...). I think that for many applications you actually *need* the Borland "non-standard". For example, for lo-level programming you need a bitwise "and" and a bit-shift operator for integers. Moreover, I feel Borland Pascal Units to be much more comfortable than Extended Pascal Modules due to the repetition of each exported identifier in an "export" clause. However, I am willing to contribute to this "finishing up" if somebody tells me what has to be done. > Well, at least now we got a "Borland" Pascal compiler for Linux > (there is a Linux version, right? I've only recently switched from OS/2 > to Linux ... but I'm pretty sure I saw a Linux version last time I was on > kampi.hut.fi ...). I don't know of an explicit Linux version at kampi.hut.fi, but GPC compiles straightforwardly under Linux. Nevertheless, I have archives with ready-to-run binaries for EMX (DOS and OS/2) as well as for Linux. Shall I upload them? Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From sad@utkux.utcc.utk.edu Tue Nov 7 18:56:18 1995 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA28719; Tue, 7 Nov 1995 18:56:01 +0100 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA29885; Tue, 7 Nov 1995 12:54:36 -0500 From: sad@utkux.utcc.utk.edu Message-Id: <9511071754.AA29885@utkux4.utcc.utk.edu> Subject: Re: Announcement: Borland extensions for GPC To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 7 Nov 1995 12:54:35 -0500 (EST) In-Reply-To: <9511071607.AA28752@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 7, 95 05:07:05 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > According to Arcadio Alivio Sincero: > > > > Awesome. Good job Peter! > > Thank you! :-) :-) :-) > > > 'Tho I wish somebody would finish up the Extended Pascal portions > > of GPC. I'm trying to steer myself away for using the Borland "standard" > > (or non-standard ...). > > I think that for many applications you actually *need* the Borland > "non-standard". For example, for lo-level programming you need a > bitwise "and" and a bit-shift operator for integers. Moreover, I feel > Borland Pascal Units to be much more comfortable than Extended Pascal > Modules due to the repetition of each exported identifier in an > "export" clause. However, I am willing to contribute to this > "finishing up" if somebody tells me what has to be done. > > > Well, at least now we got a "Borland" Pascal compiler for Linux > > (there is a Linux version, right? I've only recently switched from OS/2 > > to Linux ... but I'm pretty sure I saw a Linux version last time I was on > > kampi.hut.fi ...). > > I don't know of an explicit Linux version at kampi.hut.fi, but GPC > compiles straightforwardly under Linux. Nevertheless, I have > archives with ready-to-run binaries for EMX (DOS and OS/2) as well > as for Linux. Shall I upload them? Yes, please! Especially the OS/2 version I am eagerly awaiting! Stefan From laa12@cc.keele.ac.uk Tue Nov 7 20:48:13 1995 Received: from gabriel.keele.ac.uk by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA31613; Tue, 7 Nov 1995 20:47:52 +0100 Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Tue, 7 Nov 1995 16:26:37 +0000 From: "A.A. Olowofoyeku" Message-Id: <27579.199511071626@potter.cc.keele.ac.uk> Subject: Re: Announcement: Borland extensions for GPC To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 7 Nov 1995 16:25:59 +0000 (GMT) In-Reply-To: <9511071607.AA28752@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 7, 95 05:07:05 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Peter Gerwinski! You wrote: > According to Arcadio Alivio Sincero: > > > > Awesome. Good job Peter! Same sentiments here. > I think that for many applications you actually *need* the Borland > "non-standard". For example, for lo-level programming you need a > bitwise "and" and a bit-shift operator for integers. Moreover, I feel > Borland Pascal Units to be much more comfortable than Extended Pascal > Modules due to the repetition of each exported identifier in an > "export" clause. I agree entirely. I also think that this "non-standard" has become a standard in its own right - as a matter of fact, even if not as a matter of law. The fact that everybody else is now trying to implement it (StonyBrook, Speed Pascal, Virtual Pascal, Cabot UCSD Pascal) means that it has come to stay, and should therefore be supported by Pascal compilers (even if only as an option available through compiler switches). > However, I am willing to contribute to this > "finishing up" if somebody tells me what has to be done. Personally, I would suggest that your efforts would better serve the Pascal community by implementing more of the Borland extensions, to achieve as much compatibility as is necessary - and somebody else can work on Extended Pascal. Specialisation in this way is very good. Eventually, GPC may become the best Pascal environment around, in the sense of supporting all the major "standards". If this were so, we could then begin to really compete with C on portability, and give C a run for its money. > I don't know of an explicit Linux version at kampi.hut.fi, but GPC > compiles straightforwardly under Linux. Nevertheless, I have > archives with ready-to-run binaries for EMX (DOS and OS/2) as well > as for Linux. Shall I upload them? Probably, yes. I would surely like to get my hands on ready-to-run binaries for DOS and OS/2 if Borland compatibility were there. Is there a Win32 version anywhere - or is there any plan for one? Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From lotu@wam.umd.edu Thu Nov 9 12:31:30 1995 Received: from wor-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25816; Thu, 9 Nov 1995 12:31:17 +0100 Received: from rac8.wam.umd.edu (lotu@rac8.wam.umd.edu [128.8.70.124]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id QAA23121; Wed, 8 Nov 1995 16:35:23 -0500 Received: (lotu@localhost) by rac8.wam.umd.edu (8.6.10/8.6.10) id QAA05043; Wed, 8 Nov 1995 16:35:18 -0500 Date: Wed, 8 Nov 1995 16:35:15 -0500 (EST) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Announcement: Borland extensions for GPC In-Reply-To: <9511071607.AA28752@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 7 Nov 1995, Peter Gerwinski wrote: > > 'Tho I wish somebody would finish up the Extended Pascal portions > > of GPC. I'm trying to steer myself away for using the Borland "standard" > > (or non-standard ...). > I think that for many applications you actually *need* the Borland > "non-standard". For example, for lo-level programming you need a > bitwise "and" and a bit-shift operator for integers. Moreover, I feel Hmm ... Extended Pascal doesn't have this then? BTW - does anybody know if the Extended Pascal specs have been posted yet? Somebody up on comp.lang.pascal.ansi-iso said he was gonna do it .. I'm wondering if he did it yet. > I don't know of an explicit Linux version at kampi.hut.fi, but GPC > compiles straightforwardly under Linux. Nevertheless, I have > archives with ready-to-run binaries for EMX (DOS and OS/2) as well > as for Linux. Shall I upload them? I'm sure a bunch of OS/2 users would thank you for it if you did upload it. I know I would. Just be sure to drop a note in the OS/2 programmer newsgroups. Arcadio From gpc-request@santra.hut.fi Thu Nov 9 19:02:48 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23143; Thu, 9 Nov 1995 19:02:47 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA24451; Thu, 9 Nov 95 19:02:44 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id TAA27243 for ; Thu, 9 Nov 1995 19:42:31 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26767; Thu, 9 Nov 1995 18:42:12 +0100 From: Peter Gerwinski Message-Id: <9511091742.AA26767@rs1.Theo-Phys.Uni-Essen.DE> Subject: Binaries and IDE for Turbo-GPC To: gpc@hut.fi Date: Thu, 9 Nov 1995 18:42:11 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1126 Status: RO Hello! I have uploaded binaries for the Turbo-GPC for EMX (i.e. DOS and OS/2) and for Linux to kampi.hut.fi and also to ftp.uni-augsburg.de. In Augsburg, they already can be downloaded immediately from /pub/incoming/gnu-pascal/turbo-alpha, but I asked them to move the tree to /pub/gnu and to set up some symbolic links. By the way: there is a Borland-style integrated development system named XWPE which is designed to run gcc, but can handle gpc, too (of course). It runs fine with X as well as with Linux in text mode. It can be downloaded (for example) from cranach.rz.tu-ilmenau.de from the directory /pub/unix/linux/distributions/DEBIAN/debian-0.93/source/devel. Have fun, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From lotu@wam.umd.edu Fri Nov 10 04:40:00 1995 Received: from wor-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA18856; Fri, 10 Nov 1995 04:39:51 +0100 Received: from rac8.wam.umd.edu (lotu@rac8.wam.umd.edu [128.8.70.124]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id WAB23089; Thu, 9 Nov 1995 22:39:35 -0500 Received: (lotu@localhost) by rac8.wam.umd.edu (8.6.10/8.6.10) id WAA04213; Thu, 9 Nov 1995 22:39:34 -0500 Date: Thu, 9 Nov 1995 22:39:28 -0500 (EST) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Binaries and IDE for Turbo-GPC In-Reply-To: <9511091742.AA26767@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 9 Nov 1995, Peter Gerwinski wrote: > I have uploaded binaries for the Turbo-GPC for EMX > (i.e. DOS and OS/2) and for Linux to kampi.hut.fi > and also to ftp.uni-augsburg.de. In Augsburg, they > already can be downloaded immediately from I was wondering, is the Linux verson you put up there compiled for ELF? I want to experience compiling GPC myself ... me being a new Linux user, it'd be a great learning experience. 'Tho I know the install notes for GPC specifically called for GCC v.2.6.3, I was wondering if it'll work with GCC v.2.7.0? If not, how can I set it up so it'll produce an ELF version of GPC? Thanks ... Arcadio From gpc-request@santra.hut.fi Fri Nov 10 12:01:44 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27274; Fri, 10 Nov 1995 12:01:43 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27052; Fri, 10 Nov 95 12:01:38 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id MAA12369 for ; Fri, 10 Nov 1995 12:49:14 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24281; Fri, 10 Nov 1995 11:48:42 +0100 From: Peter Gerwinski Message-Id: <9511101048.AA24281@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Binaries and IDE for Turbo-GPC To: lotu@wam.umd.edu, gpc@hut.fi Date: Fri, 10 Nov 1995 11:48:41 +0100 (MEZ) In-Reply-To: from "Arcadio Alivio Sincero" at Nov 9, 95 10:39:28 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1127 Status: RO According to Arcadio Alivio Sincero: > > I was wondering, is the Linux verson you put up there compiled > for ELF? No. I'm sorry, but GPC version 2.6.3 is still a.out, not ELF. > I want to experience compiling GPC myself ... me being a new > Linux user, it'd be a great learning experience. 'Tho I know the install > notes for GPC specifically called for GCC v.2.6.3, I was wondering if > it'll work with GCC v.2.7.0? If not, how can I set it up so it'll produce > an ELF version of GPC? I don't know about GPC 2.6.3 with GCC 2.7.0, but Juki recently wrote that he would upgrade GPC to 2.7.1. So just wait, and you'll get an ELF version of GPC which will produce ELF code. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From lotu@wam.umd.edu Sat Nov 11 21:34:25 1995 Received: from wor-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25918; Sat, 11 Nov 1995 21:34:16 +0100 Received: from rac5.wam.umd.edu (lotu@rac5.wam.umd.edu [128.8.70.121]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id PAA03878 for ; Sat, 11 Nov 1995 15:34:19 -0500 Received: (lotu@localhost) by rac5.wam.umd.edu (8.6.10/8.6.10) id PAA22438; Sat, 11 Nov 1995 15:34:18 -0500 Date: Sat, 11 Nov 1995 15:34:17 -0500 (EST) From: Arcadio Alivio Sincero To: Peter Gerwinski Subject: Re: Binaries and IDE for Turbo-GPC In-Reply-To: <9511091742.AA26767@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 9 Nov 1995, Peter Gerwinski wrote: > Hello! > > I have uploaded binaries for the Turbo-GPC for EMX > (i.e. DOS and OS/2) and for Linux to kampi.hut.fi > and also to ftp.uni-augsburg.de. In Augsburg, they > already can be downloaded immediately from > /pub/incoming/gnu-pascal/turbo-alpha, > but I asked them to move the tree to /pub/gnu and > to set up some symbolic links. I downloaded your version GPC-Linux instead of recompiling it myself. I got a project for my CMSC112 class due soon and I don't have time to mess around trying to figure out how to recompile GPC. 'Tho, I seem to be having some trouble. When I try to compile a test program, I get the error: ld: cannot open crt0.o: No such file or directory Here's where I have the files installed. The binary gpc is installed in /usr/bin. The binaries gpc-cpp and gpc1 are installed in the directory /usr/lib/gcc-lib/i486-linuxaout/2.6.3, however I have symbolic links in the directory /usr/local/bin named "gpc-cpp" and "gpc1" pointing to those binaries. The ar libraries libgpc.a and libgcc.a are also installed in /usr/lib/gcc-lib/i486-linuxaout/2.6.3. My system is SlackWare Linux v.3.0. The version of GCC I have installed is v.2.7.0. The source code is not installed. I do not have GCC v.2.6.3 installed in either source or compiled form. Please help. Thanks. Arcadio From gpc-request@santra.hut.fi Sun Nov 12 00:37:39 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19918; Sun, 12 Nov 1995 00:37:38 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA02494; Sun, 12 Nov 95 00:37:43 CET Received: from wor-srv.wam.umd.edu (wor-srv.wam.umd.edu [128.8.76.2]) by santra.hut.fi (8.6.11/8.6.7) with ESMTP id BAA05277 for ; Sun, 12 Nov 1995 01:23:49 +0200 Received: from rac4.wam.umd.edu (lotu@rac4.wam.umd.edu [128.8.70.120]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id SAA16514 for ; Sat, 11 Nov 1995 18:23:31 -0500 Received: (lotu@localhost) by rac4.wam.umd.edu (8.6.10/8.6.10) id SAA05245; Sat, 11 Nov 1995 18:23:30 -0500 Date: Sat, 11 Nov 1995 18:23:29 -0500 (EST) From: Arcadio Alivio Sincero To: gpc@hut.fi Subject: NEED LINUX/ELF VERSION OF GPC!! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Can somebody PLEASE make an ELF version of GPC for Linux that works with GCC v.2.7.0???? Or give me some pointers on how to do it myself???? I downloaded the Linux version of GPC that Peter Gerwinski made, but it doesn't work on my system. I'm thinking maybe because I have SlackWare 3.0/ELF installed. When I first installed GPC, the compilation process would break when it came to the linking phase. ld, the GNU Linker, would say that it's unable to find file "crt0.o". I remembered seeing that file way back in my SlackWare 2.2 days, so kicked out the old SlackWare 2.2 CD-ROM and copied a "crt0.o" into my /usr/lib directory. Now, when I try to compile and link, I just get a whole bunch of unresolved reference errors. However, GPC itself appears to compile alright (except it produces a.out object files instead of ELF). It's just when it comes time to link that it goes haywire. Please help somebody! I need this compiler soon for a school project ... Arcadio From gpc-request@santra.hut.fi Mon Nov 13 19:36:23 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25646; Mon, 13 Nov 1995 19:36:20 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA08788; Mon, 13 Nov 95 19:36:07 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.6.11/8.6.7) with SMTP id RAA27633 for ; Mon, 13 Nov 1995 17:04:48 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24863; Mon, 13 Nov 1995 16:00:06 +0100 From: Peter Gerwinski Message-Id: <9511131500.AA24863@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: NEED LINUX/ELF GPC (only a TRY to help you ...) To: lotu@wam.umd.edu (Arcadio Alivio Sincero) Date: Mon, 13 Nov 1995 16:00:05 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: from "Arcadio Alivio Sincero" at Nov 11, 95 06:23:29 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2609 Status: RO According to Arcadio Alivio Sincero: > > > Can somebody PLEASE make an ELF version of GPC for Linux that works with > GCC v.2.7.0???? Or give me some pointers on how to do it myself???? If you really want to try to implement this yourself, I suggest the following strategy: - get GCC 2.6.3 and GCC 2.7.0 source, - look, which files of the GPC 2.6.3 source are replacing GCC 2.6.3 files, and make diffs between GCC 2.6.3 and GPC 2.6.3 for them, - do the GPC changes to the GCC 2.7.0 files, - compile GCC 2.7.0 (one stage is enough), - compile GPC, now version 2.7.0, and hope the best, - send your files to Juki, because he will be interested, - send your files to me, because I am interested, too. Since I expect trouble when doing this, let us first try it in another way ... > I downloaded the Linux version of GPC that Peter Gerwinski made, but it > doesn't work on my system. I'm thinking maybe because I have SlackWare > 3.0/ELF installed. > > When I first installed GPC, the compilation process would break when it > came to the linking phase. ld, the GNU Linker, would say that it's > unable to find file "crt0.o". I remembered seeing that file way back in > my SlackWare 2.2 days, so kicked out the old SlackWare 2.2 CD-ROM and > copied a "crt0.o" into my /usr/lib directory. Now, when I try to compile > and link, I just get a whole bunch of unresolved reference errors. Which gcclib do you use? Perhaps it is already the 2.7.0 version while crt0.o and gpc expect the 2.6.3 version. I suggest to install the com- plete gcc 2.6.3 in /usr/bin and /usr/lib. (It should work with SlackWare 3.0, as I hope.) Then also install gpc 2.6.3, and they should work to- gether. > However, GPC itself appears to compile alright (except it produces a.out > object files instead of ELF). It's just when it comes time to link that > it goes haywire. This gives hope to me, that the above idea could work. > Please help somebody! I need this compiler soon for a school project ... For case of emergency I will figure out how to run GPC under EMX in the DOS emulator of Linux. This is somehow stupid, but should work. Till later, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From lotu@wam.umd.edu Tue Nov 14 00:06:01 1995 Received: from wor-srv.wam.umd.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24546; Tue, 14 Nov 1995 00:05:52 +0100 Received: from rac9.wam.umd.edu (lotu@rac9.wam.umd.edu [128.8.70.8]) by wor-srv.wam.umd.edu (8.6.10/8.6.10) with ESMTP id SAA10443; Mon, 13 Nov 1995 18:05:34 -0500 Received: (lotu@localhost) by rac9.wam.umd.edu (8.6.10/8.6.10) id SAA17365; Mon, 13 Nov 1995 18:05:28 -0500 Date: Mon, 13 Nov 1995 18:05:23 -0500 (EST) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: NEED LINUX/ELF GPC (only a TRY to help you ...) In-Reply-To: <9511131500.AA24863@rs1.Theo-Phys.Uni-Essen.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 13 Nov 1995, Peter Gerwinski wrote: > - get GCC 2.6.3 and GCC 2.7.0 source, > - look, which files of the GPC 2.6.3 source are replacing GCC 2.6.3 > files, and make diffs between GCC 2.6.3 and GPC 2.6.3 for them, > - do the GPC changes to the GCC 2.7.0 files, > - compile GCC 2.7.0 (one stage is enough), > - compile GPC, now version 2.7.0, and hope the best, > - send your files to Juki, because he will be interested, > - send your files to me, because I am interested, too. > > Since I expect trouble when doing this, let us first try it in another way ... Thanks for the play by play. This does look involved 'tho. I'll work on it next weekend. I'll just use Turbo Pascal on my DOS partition and hope when I translate it to conform to the ISO Standard, I don't make any mistakes (for my project thats due ... uhh .. man, tomorrow! Sheesh, I better get cracking ...). > Which gcclib do you use? Perhaps it is already the 2.7.0 version while > crt0.o and gpc expect the 2.6.3 version. I suggest to install the com- > plete gcc 2.6.3 in /usr/bin and /usr/lib. (It should work with SlackWare > 3.0, as I hope.) Then also install gpc 2.6.3, and they should work to- > gether. Well, I do have GCC v.2.7.0 installed, so I'm assuming the gcclib I have is 2.7.0. I have no idea because the SlackWare setup script just installed everything. Hmm ... if I install gcc 2.6.3, won't it over write 2.7.0? Can I install GCC 2.6.3 in it's own directory, say in /usr/local/bin/gcc263? That way I won't have to worry about gcc263 clashing with gcc270. > For case of emergency I will figure out how to run GPC under EMX in the > DOS emulator of Linux. This is somehow stupid, but should work. Hmm ... I was told that DOSEMU operates in a similar fashion to OS/2 VDMs. In that case, EMX won't work in DOSEMU because it uses the VPCI (or is it VCPI? I always get it confused) protected mode standard. 'Tho you can get the RSX package which will make EMX use the DPMI standard instead. I know that works in an OS/2 VDM ... Arcadio From pege Tue Nov 14 13:21:51 1995 Subject: GPC for EMX runs in Linux DOSemu :-) To: lotu@wam.umd.edu (Arcadio Alivio Sincero) Date: Tue, 14 Nov 1995 13:21:51 +0100 (MEZ) In-Reply-To: from "Arcadio Alivio Sincero" at Nov 13, 95 06:05:23 pm X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 2044 Status: RO Hello Arcadio, hello GPC-list! I have checked that the EMX (i.e. DOS and OS/2) version of GPC 2.6.3 runs fine in the DOSemu (version 0.60.3 with WinDoze hack---but probably also without it) of Linux. It is somehow stupid to emulate DOS under Linux in order to run there a program which has been ported from UNIX to DOS, but this may serve as a last resort when you have problems with Linux SlackWare 3 (ELF binary format) until GPC 2.7.x will exist. The steps to get a compiling GPC in Linux DOSemu are straightforward, nevertheless here is a short description what to do: - Install DOSemu, - get the following packets of EMX: emxrt, emxdev, gnudev, dpmigcc5, - get GPC binaries for EMX, - create a directory for EMX, install everything in that directory from Linux with unzip (this is more stable than installing it under DOSemu for example with pkunzip -d). Note that DOS is not case- sensitive, so you will have to move GPC files from EMX/BIN and EMX/LIB to emx/bin and emx/lib. - Start DOSemu and edit your AUTOEXEC.BAT: - set up a PATH to the emx/bin directory, - set up the LIBRARY_PATH environment variable to point to your emx/lib directory. - ExitEmu and restart it---now it should work. Run some tests. This sounds complicated, but if you are experienced with DOS and already have installed DOSemu and know where to get EMX (e.g. on the server ftp.uni-stuttgart.de in /pub/systems/os2/emx-0.9a or similar), the whole procedure can be done in half an hour or less. If not, it may be easier to do the port from GPC 2.6.3 to GPC 2.7.0 on your own. Good luck, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Wed Nov 22 12:49:18 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22450; Wed, 22 Nov 1995 12:49:17 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA12089; Wed, 22 Nov 95 12:49:05 CET Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id MAA28504 for ; Wed, 22 Nov 1995 12:44:33 +0200 Received: from gnuisance.cern.ch.cern.ch by dxmint.cern.ch id AA15518; Wed, 22 Nov 1995 11:44:18 +0100 Received: by gnuisance.cern.ch.cern.ch (4.1/SMI-4.0) id AA12295; Wed, 22 Nov 95 11:44:13 +0100 Date: Wed, 22 Nov 95 11:44:13 +0100 Message-Id: <9511221044.AA12295@gnuisance.cern.ch.cern.ch> From: Philippe.Defert@cern.ch To: gpc@hut.fi Subject: gcc 2.7.1 Status: RO What about gpc for gcc 2.7.1 ? Thanks for your help. -- ************************************************************************ * Philippe Defert: Computing and Networks Division * * CERN, European Laboratory for Particle Physics * ************************************************************************ * Earth mail: CERN / CN / CO | E*mail: defert@cern.ch * * CH-1211 Geneve 23. Switzerland. | defert@cernvm.bitnet * * Voice: + 41 22 7673923 | * ************************************************************************ * __ * * Un monde nouveau, tu comprends ////\ * * Rien ne sera plus jamais comme avant \\\// * * C'est la fin de l'histoire, le rouge apres le noir | | * * J.J. Goldman | | * ************************************************************************ From gpc-request@santra.hut.fi Wed Nov 22 14:21:34 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA09161; Wed, 22 Nov 1995 14:21:33 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA12368; Wed, 22 Nov 95 14:21:07 CET Received: from hpug.kaist.ac.kr (hpug.kaist.ac.kr [143.248.1.162]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id OAA01003 for ; Wed, 22 Nov 1995 14:31:27 +0200 Received: (from crisp@localhost) by hpug.kaist.ac.kr (8.6.12H1/8.6.12) id VAA03727; Wed, 22 Nov 1995 21:30:10 +0900 Date: Wed, 22 Nov 1995 21:30:10 +0900 Message-Id: <199511221230.VAA03727@hpug.kaist.ac.kr> From: Chung Jae-youn To: Philippe.Defert@cern.ch Cc: gpc@hut.fi In-Reply-To: <9511221044.AA12295@gnuisance.cern.ch.cern.ch> (Philippe.Defert@cern.ch) Subject: Re: gcc 2.7.1 Status: RO >>>>> "Philippe" == Philippe Defert writes: Philippe> What about gpc for gcc 2.7.1 ? Philippe> Thanks for your help. -- It would be a great pleasure if there is gpc for gcc 2.7.1 of course.. :) regards.. -- ---- Crisp From gpc-request@santra.hut.fi Wed Nov 22 15:24:50 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23187; Wed, 22 Nov 1995 15:24:49 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA12513; Wed, 22 Nov 95 15:24:44 CET Received: from gabriel.keele.ac.uk (gabriel.keele.ac.uk [160.5.1.248]) by santra.hut.fi (8.7.1/8.7.1) with ESMTP id PAA02227 for ; Wed, 22 Nov 1995 15:23:35 +0200 Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Wed, 22 Nov 1995 12:57:42 +0000 From: "A.A. Olowofoyeku" Message-Id: <21137.199511221257@potter.cc.keele.ac.uk> Subject: GPC for Win32 To: gpc@hut.fi Date: Wed, 22 Nov 1995 12:57:28 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, I have been reading somewhere about GCC for Win32 - has anyone done a port of GPC for the Win32 platforms? Thanks. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From gpc-request@santra.hut.fi Wed Nov 22 20:20:34 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23932; Wed, 22 Nov 1995 20:20:33 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13347; Wed, 22 Nov 95 20:20:24 CET Received: from wor-srv.wam.umd.edu (wor-srv.wam.umd.edu [128.8.76.2]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id UAA09132 for ; Wed, 22 Nov 1995 20:54:45 +0200 Received: from rac6.wam.umd.edu (lotu@rac6.wam.umd.edu [128.8.70.122]) by wor-srv.wam.umd.edu (8.6.10/8.6.10) with ESMTP id NAA24335; Wed, 22 Nov 1995 13:54:35 -0500 Received: (lotu@localhost) by rac6.wam.umd.edu (8.6.10/8.6.10) id NAA09018; Wed, 22 Nov 1995 13:54:32 -0500 Date: Wed, 22 Nov 1995 13:54:31 -0500 (EST) From: Arcadio Alivio Sincero To: Chung Jae-youn Cc: Philippe.Defert@cern.ch, gpc@hut.fi Subject: Re: gcc 2.7.1 In-Reply-To: <199511221230.VAA03727@hpug.kaist.ac.kr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 22 Nov 1995, Chung Jae-youn wrote: > Philippe> What about gpc for gcc 2.7.1 ? > Philippe> Thanks for your help. -- > It would be a great pleasure if there is gpc for gcc 2.7.1 of course.. Juki said he was gonna work on a GPC for GCC v.2.7.0. Dunno if he started yet or not. Arcadio From gpc-request@santra.hut.fi Wed Nov 22 21:04:59 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19706; Wed, 22 Nov 1995 21:04:58 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13377; Wed, 22 Nov 95 21:04:55 CET Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id VAA09745 for ; Wed, 22 Nov 1995 21:40:26 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id VAA05955; Wed, 22 Nov 1995 21:38:48 +0200 Date: Wed, 22 Nov 1995 21:38:47 +0200 (EET) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: Arcadio Alivio Sincero Cc: Chung Jae-youn , Philippe.Defert@cern.ch, gpc@hut.fi Subject: Re: gcc 2.7.1 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 22 Nov 1995, Arcadio Alivio Sincero wrote: > On Wed, 22 Nov 1995, Chung Jae-youn wrote: > > > Philippe> What about gpc for gcc 2.7.1 ? > > Philippe> Thanks for your help. -- > > It would be a great pleasure if there is gpc for gcc 2.7.1 of course.. > > > Juki said he was gonna work on a GPC for GCC v.2.7.0. Dunno if > he started yet or not. Hi folks... I did start to merge the borland mods to my gpc tree, but found out that I have to talk with Peter about some problems I encountered (my test programs broke; might be a problem with my upgrade, though). So it is probable that I will do the 2.6.3-> 2.7.1 upgrade first and fix the problems later with Peters help. I did not upgrade to 2.7.0 because 2.7.1 was coming out, and now that it has, I heard that there are still more problems with than what we knew the 2.6.3 had (at least in the rs-6000), but I guess the upgrade would be useful anyway (ELF, etc) so I try to implement it soon. Juki jtv@hut.fi From gpc-request@santra.hut.fi Wed Nov 22 21:12:56 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA29702; Wed, 22 Nov 1995 21:12:55 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13393; Wed, 22 Nov 95 21:12:54 CET Received: from dogwood1.utcc.utk.edu (DOGWOOD1.UTCC.UTK.EDU [198.78.204.31]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id VAA09907; Wed, 22 Nov 1995 21:53:31 +0200 From: sad@utkux.utcc.utk.edu Received: by dogwood1.utcc.utk.edu (5.x/2.7c-UTK) id AA16449; Wed, 22 Nov 1995 14:52:54 -0500 Message-Id: <9511221952.AA16449@dogwood1.utcc.utk.edu> Subject: Re: gcc 2.7.1 To: Jukka.Virtanen@hut.fi Date: Wed, 22 Nov 1995 14:52:53 -0500 (EST) Cc: gpc@hut.fi In-Reply-To: from "Jukka Virtanen" at Nov 22, 95 09:38:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Juki, will the Borland stuff be implemented such that one can turn it *off* with a compiler switch? (Much like the -ansi option for gcc?) I'd love to have a way to write either very clean, portable Extended Pascal code or very borlandy code ... Thanks! Stefan > > > On Wed, 22 Nov 1995, Arcadio Alivio Sincero wrote: > > > On Wed, 22 Nov 1995, Chung Jae-youn wrote: > > > > > Philippe> What about gpc for gcc 2.7.1 ? > > > Philippe> Thanks for your help. -- > > > It would be a great pleasure if there is gpc for gcc 2.7.1 of course.. > > > > > > Juki said he was gonna work on a GPC for GCC v.2.7.0. Dunno if > > he started yet or not. > > Hi folks... I did start to merge the borland mods to my gpc > tree, but found out that I have to talk with Peter about some > problems I encountered (my test programs broke; might be a problem > with my upgrade, though). So it is probable that I will do the 2.6.3-> > 2.7.1 upgrade first and fix the problems later with Peters help. > > I did not upgrade to 2.7.0 because 2.7.1 was coming out, > and now that it has, I heard that there are still more > problems with than what we knew the 2.6.3 had (at least in > the rs-6000), but I guess the upgrade would be useful > anyway (ELF, etc) so I try to implement it soon. > > Juki > jtv@hut.fi > From gpc-request@santra.hut.fi Wed Nov 22 23:30:16 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27870; Wed, 22 Nov 1995 23:30:15 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13764; Wed, 22 Nov 95 23:30:28 CET Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id WAA10229 for ; Wed, 22 Nov 1995 22:19:17 +0200 Received: (from jtv@localhost) by kampi.hut.fi (8.6.11/8.6.7) id WAA06016; Wed, 22 Nov 1995 22:19:13 +0200 Date: Wed, 22 Nov 1995 22:19:12 +0200 (EET) From: Jukka Virtanen Reply-To: Jukka.Virtanen@hut.fi To: gpc@hut.fi Subject: borland extensions In-Reply-To: <9511221952.AA16449@dogwood1.utcc.utk.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 22 Nov 1995 sad@utkux.utcc.utk.edu wrote: > Hi Juki, > > will the Borland stuff be implemented such that one can turn it *off* > with a compiler switch? (Much like the -ansi option for gcc?) > I'd love to have a way to write either very clean, portable Extended Pascal > code or very borlandy code ... > > Thanks! Stefan I think it should (and partly must) be done so. Implementing another "hybdir" language is not what I would like to see. I find that the extended pascal is a good language in itself, but I agree that there are far too many borland programs around to ignore them. (Also, the object pascal language looks nice and would be fun to support. Any volunteers? :-) Juki jtv@hut.fi From graywolf@earthlight.co.nz Thu Nov 23 02:45:14 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27772; Thu, 23 Nov 1995 02:45:13 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA14249; Thu, 23 Nov 95 02:45:16 CET Received: (from graywolf@localhost) by sol.earthlight.co.nz (8.6.9/8.6.9) id OAA23387 for pege@mail.theo-phys.uni-essen.de; Thu, 23 Nov 1995 14:42:16 +1300 From: Dave Smith Message-Id: <199511230142.OAA23387@sol.earthlight.co.nz> Subject: GPC To: pege@rt07.Theo-Phys.Uni-Essen.DE Date: Thu, 23 Nov 1995 14:42:15 +1300 (NZDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 290 Status: RO Hi, I've downloaded the GPC binaries for Ms-dos, but I don't have an emx driver. Could you please point me in the direction to obtain these drivers for dos. I've searched the web, but can only find OS2 ones :(, so your help here would be much appreciated. Cheers Dave Smith From gpc-request@santra.hut.fi Thu Nov 23 09:38:20 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27867; Thu, 23 Nov 1995 09:38:19 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA15498; Thu, 23 Nov 95 09:37:59 CET Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by santra.hut.fi (8.7.1/8.7.1) with SMTP id JAA16194 for ; Thu, 23 Nov 1995 09:55:58 +0200 Received: from hsb.nest.nl by sun4nl.NL.net with SMTP id AB08497 (5.65b/CWI-3.3); Thu, 23 Nov 1995 08:55:41 +0100 Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.6.11/8.6.11) with UUCP id IAA04441 for hut.fi!gpc; Thu, 23 Nov 1995 08:46:53 GMT Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Thu, 23 Nov 95 08:42:45 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG2426; Thu, 23 Nov 1995 05:03:04 +0100 Date: 22 Nov 95 19:37:57 +0100 Message-Id: <60-60-0-0-b36da71@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: GPC for Win32 Status: RO A.A. Olowofoyeku wrote in a message to Berend de Boer: AAO> I have been reading somewhere about GCC for Win32 - has AAO> anyone done a port of GPC for the Win32 platforms? I probably try it soon. But I think I need 2.7.x, but let's see if gpc2.6.3 works on top of gcc 2.7 Groetjes, Berend (-: CIS: 100120,3121 email: berend@beard.nest.nl From gpc-request@santra.hut.fi Thu Nov 23 16:51:07 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22476; Thu, 23 Nov 1995 16:51:06 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16577; Thu, 23 Nov 95 16:51:02 CET Received: from whidbey (whidbey.whidbey.com [204.94.52.2]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id RAA04139 for ; Thu, 23 Nov 1995 17:08:02 +0200 (EET) Received: by whidbey (5.0/SMI-SVR4) id AA15912; Thu, 23 Nov 1995 07:07:01 +0800 Message-Id: <9511231507.AA15912@whidbey> From: alland@whidbey.com (Allan Derickson) Date: Thu, 23 Nov 95 08:01:44 To: gpc@hut.fi Subject: GPC and OS/2 X-Mailer: MR/2 Internet Cruiser Edition v0.99b Status: RO Hello, I installed the version of GPC patched for emx running in OS/2. Has anyone made an OS/2 header file that works for API calls? Can someone show me a snippet of code showing how to incorporate an assembler procedure into a program? WriteStr doesn't work - "unresolved external". Writeln is sometimes called multiple times. TIA Allan D. Derickson -- Derickson Forestry Services -- Freeland, WA USA ----------------------------------------------------------- alland@whidbey.com ----------------------------------------------------------- From gpc-request@santra.hut.fi Thu Nov 23 19:25:19 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA31955; Thu, 23 Nov 1995 19:25:18 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16985; Thu, 23 Nov 95 19:25:14 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id UAA06526 for ; Thu, 23 Nov 1995 20:13:42 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25174; Thu, 23 Nov 1995 19:12:54 +0100 From: Peter Gerwinski Message-Id: <9511231812.AA25174@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: GPC To: graywolf@earthlight.co.nz (Dave Smith), gpc@hut.fi Date: Thu, 23 Nov 1995 19:12:53 +0100 (MEZ) In-Reply-To: <199511230142.OAA23387@sol.earthlight.co.nz> from "Dave Smith" at Nov 23, 95 02:42:15 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello! EMX can be downloaded for example from ftp.uni-stuttgart.de in the directory /pub/systems/os2/emx-0.9a. Independently of the directory's name, it works well with DOS. :-) Peter According to Dave Smith: > > Hi, > > I've downloaded the GPC binaries for Ms-dos, but I don't have an emx > driver. Could you please point me in the direction to obtain these > drivers for dos. I've searched the web, but can only find OS2 ones :(, > so your help here would be much appreciated. > > Cheers > Dave Smith > > -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Nov 23 19:28:09 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA02363; Thu, 23 Nov 1995 19:28:08 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16997; Thu, 23 Nov 95 19:28:06 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id UAA06505 for ; Thu, 23 Nov 1995 20:10:29 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19531; Thu, 23 Nov 1995 19:10:17 +0100 From: Peter Gerwinski Message-Id: <9511231810.AA19531@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: borland extensions To: gpc@hut.fi Date: Thu, 23 Nov 1995 19:10:16 +0100 (MEZ) In-Reply-To: from "Jukka Virtanen" at Nov 22, 95 10:19:12 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hi! An option to turn the Borland extensions off exists in some sense: Just use --pedantic, and you will get warnings for everything which is not ISO. Peter According to Jukka Virtanen: > > > On Wed, 22 Nov 1995 sad@utkux.utcc.utk.edu wrote: > > > Hi Juki, > > > > will the Borland stuff be implemented such that one can turn it *off* > > with a compiler switch? (Much like the -ansi option for gcc?) > > I'd love to have a way to write either very clean, portable Extended Pascal > > code or very borlandy code ... > > > > Thanks! Stefan > > I think it should (and partly must) be done so. > Implementing another "hybdir" language is not what I would > like to see. > > I find that the extended pascal is a good language in itself, > but I agree that there are far too many borland programs > around to ignore them. (Also, the object pascal language > looks nice and would be fun to support. Any volunteers? :-) > > Juki > jtv@hut.fi > -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Nov 23 19:32:18 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19031; Thu, 23 Nov 1995 19:32:18 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA17000; Thu, 23 Nov 95 19:32:14 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id UAA06607 for ; Thu, 23 Nov 1995 20:21:56 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24198; Thu, 23 Nov 1995 19:21:48 +0100 From: Peter Gerwinski Message-Id: <9511231821.AA24198@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: borland extensions ("PS") To: gpc@hut.fi Date: Thu, 23 Nov 1995 19:21:47 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO According to pege: >From pege Thu Nov 23 19:21:21 1995 Subject: Re: borland extensions ("PS") To: Jukka.Virtanen@hut.fi Date: Thu, 23 Nov 1995 19:21:21 +0100 (MEZ) In-Reply-To: from "Jukka Virtanen" at Nov 22, 95 10:19:12 pm X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1297 Hello again! > I find that the extended pascal is a good language in itself, > but I agree that there are far too many borland programs > around to ignore them. I think there is yet another reason: When you want to do lo-level programming in Pascal, you *need* the Borland extensions. (Or, you must write large parts in assembler, which is also non-ISO.) And there are more examples where things can easily be done with Borland Pascal but are very uncomfortable or even impossible with Extended Pascal. > (Also, the object pascal language > looks nice and would be fun to support. Any volunteers? :-) The Borland "nonstandard" supports objects, so the object pascal language already *is* implemented in some sense -- I expect that only a few names must be changed. If a volunteer wants to imple- ment Object Pascal: It won't be too much work! Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Fri Nov 24 17:38:01 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27499; Fri, 24 Nov 1995 17:38:00 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA20574; Fri, 24 Nov 95 17:37:51 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id SAA21406 for ; Fri, 24 Nov 1995 18:25:12 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA17366; Fri, 24 Nov 1995 17:24:49 +0100 From: Peter Gerwinski Message-Id: <9511241624.AA17366@rs1.Theo-Phys.Uni-Essen.DE> Subject: f2p, c2p To: gpc@hut.fi Date: Fri, 24 Nov 1995 17:24:49 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, folks! Only one small question/suggestion: Does there exist a f2p or c2p translator program which translates Fortran resp. C source to Pascal source? If not, I suggest that somebody writes it because of the following reasons: - Practical reason: It would be nice to import libraries written in C, C++ or Fortran automatically. For most purposes, it would be sufficient to have a program which ports C header files to Pascal Unit (Module) interfaces. - Psychological reason: The existence of a c2p would demonstrate that Pascal is at least as powerful as C. The existence of a p2c (which does in fact *not* support everything which is possible in Borland Pascal -- I am thinking of the Object extensions) is ac- cepted by many people as a "proof" that C would be superior to Pascal, so we should "proove" the opposite direction. :-) I am almost sure that at least the c2p program does not exist because Standard Pascal has indeed less abilities than C. However, you can do everything which is possible in C with GNU Pascal (including e.g. pointer arithmetics -- just do a type cast to Integer), so the main difficulty will be to *understand* the C source, not to translate it. C++ could be more complicated as long as GNU Pascal does not (yet) have multiple inheritance. For Fortran, I don't see any problems, since there are complex numbers in GNU (Extended) Pascal, but one should translate goto statements to structured statements wherever possible.. One idea how to write it: Just use the front-ends of the GNU compi- lers and replace the assembler back-end by a Pascal back-end. Once you have understood how the front-end passes information to the back-end, the job will be straightforward. (One could even easily generalize it to a general x2y translator ...! :-) I have not the time to do it myself :-( so I ask *you* if you are willing to do this important contribution. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From sad@utkux.utcc.utk.edu Fri Nov 24 21:57:18 1995 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25588; Fri, 24 Nov 1995 21:57:02 +0100 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA27429; Fri, 24 Nov 1995 15:52:06 -0500 From: sad@utkux.utcc.utk.edu Message-Id: <9511242052.AA27429@utkux4.utcc.utk.edu> Subject: Re: f2p, c2p To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Fri, 24 Nov 1995 15:52:05 -0500 (EST) In-Reply-To: <9511241624.AA17366@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 24, 95 05:24:49 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > Hello, folks! > > Only one small question/suggestion: Does there exist a f2p or c2p > translator program which translates Fortran resp. C source to Pascal > source? If not, I suggest that somebody writes it because of the > following reasons: Hi there! I know there exist attempts to sovle that problem out there on the net but they all are bound to be rather incomplete due to the very different nature of the languages under consideration. In fact, this kind of thing is being discussed quite often in all the involved language news groups ( comp.lang.fortran, comp.lang.c). Most of the tools I have heared of are reported to ease the transition to pascal while leaving still much manual work behind. If you think of how much of the time that you actually spend porting a code goes into which parts you will see that already things like changing the comment and declaration parts and aligning them nicely (so that further maintainance of the pascal code by a human is easily possible) are a big step. In fact, the fortran to c translator does not produce c code meant for the human reader or for further maintainance of the code in C at all. It produces code which has only the purpose to compile on a C compiler, the code is, however, next to unreadable for a C programmer (and calls many library routines to, e.g., emulate the Fortran output statements). Ihave yet to run into a code that did not compile and run. The pascal to c translator, on the other hand, produces rather reasonably readable code, which doesn't always compile though. So, there are two different approaches. For the transaltino of header files seems to exist a solution since they are highly specific; as part of the Prospero Extended Pascal for OS/2 you get (supposedly, I don't have it yet) a bunch of translated header files and a translation utility that leaves only a bit manual work to be done. > > - Practical reason: It would be nice to import libraries written > in C, C++ or Fortran automatically. For most purposes, it would > be sufficient to have a program which ports C header files to > Pascal Unit (Module) interfaces. > This one is a bit deceiving, since it in turn would lead to the conclusion that assembler or machine code is superior to C, since the translation from anything ends up in some such form. Of course, the way back is neither uniquely determined nor easily accomplished atomatically. The difference is more the high- and low-level access to a language. You always could explain Shakespeares M(a)cBeth to a five year old with rather limited vocabulary: ``Well, that guy on stage was to eager to get into power and in the end he got killed because he's the bad guy'' but try to turn that sentence into Shakespeare's language again ... See what I am saying? :-) > - Psychological reason: The existence of a c2p would demonstrate > that Pascal is at least as powerful as C. The existence of a p2c > (which does in fact *not* support everything which is possible in > Borland Pascal -- I am thinking of the Object extensions) is ac- > cepted by many people as a "proof" that C would be superior to > Pascal, so we should "proove" the opposite direction. :-) > > I am almost sure that at least the c2p program does not exist because > Standard Pascal has indeed less abilities than C. However, you can > do everything which is possible in C with GNU Pascal (including e.g. > pointer arithmetics -- just do a type cast to Integer), so the main > difficulty will be to *understand* the C source, not to translate it. > C++ could be more complicated as long as GNU Pascal does not (yet) have > multiple inheritance. For Fortran, I don't see any problems, since > there are complex numbers in GNU (Extended) Pascal, but one should > translate goto statements to structured statements wherever possible.. I really am not sure if it is so easy. Let's first look at C: All this malloc stuff, and access to the memory address that contains the pointer to a certain array element and such -- is that really easily accomplished in E.Pascal? Or, my pet grief: Command line access ... what do you do with int main(argc, *argv) { ...} or such? I think it won't be possible to achieve a completely automatic translation when you come from C code, even though it may be possible to code a solution to a give problem in both C and Pascal. (Very often you find also lots of crap coded in C just to say something the language Pascal would allow in one line, say, assignment of arrays: In c you'd have to assign array alement by array element since otherwise the pointers would be the same, while in Pascal you can do an A:=B; if they are just of compatible (or the same?) type. So, even mechanical translation may not produce very Pascalish code, as one could see from the first edition of the numerical recipes which had a very Fortanish Pascal version of each routine in the appendix ... Now Fortran: You would have to provide at leat a huge library (similar to the one that comes with f2c) for a load of intrinsic Fortran functions, input/output routines and the like, and you would have to find a way to deal with Fortran goodies like computed goto's, multiple entry points for subroutines or passing of arrays by passing the first element and the length of the array (which frequently causes trouble when the array length is different from the one passed). So, being an optimist with life experience (as some define a pessimist) I just want to be a bit cautious about too high expectatins of automated translation. I do agree, however, that it should be possible to write something that could do a significant fraction of the porting work. > > One idea how to write it: Just use the front-ends of the GNU compi- > lers and replace the assembler back-end by a Pascal back-end. Once > you have understood how the front-end passes information to the > back-end, the job will be straightforward. (One could even easily > generalize it to a general x2y translator ...! :-) Hm. So Shakespeare with the vocabulary of a five year old? Again, even if you would be able to get something in E.P. out of such a back end it would be very different from what an experienced Pascal Programmer would have written and so it would probably end up being manually converted to a more efficient, more readable, more Pascally code afterwards anyway ... I think that a good, portable compiler and a good, portable conversion aid utility are as much as we could have hoped for. BTW, one way to push E.P. would be to convince the authors of the Numerical Recipes to treat us to a new issue of their book for extended Pascal. They gave up on Pascal a while back because there was no market, as they claimed, and there are only Fortran and C versions left. An E.P. version would be really a big step, I believe. Later, gotta eat turkey now! Stefan > > I have not the time to do it myself :-( so I ask *you* if you are > willing to do this important contribution. > > Yours, > > Peter > > -------------------------------------------------------------------------------- > Dipl. Phys. Peter Gerwinski > Fachbereich Physik > Universitaet-GH Essen Phone: +49-201-183-2763 > D-45117 Essen Fax: +49-201-183-2120 > Germany e-mail: pege@mail.theo-phys.uni-essen.de > -------------------------------------------------------------------------------- > From gpc-request@santra.hut.fi Mon Nov 27 17:15:48 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA35389; Mon, 27 Nov 1995 17:15:47 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA01660; Mon, 27 Nov 95 17:15:32 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id RAA27021 for ; Mon, 27 Nov 1995 17:55:12 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26209; Mon, 27 Nov 1995 16:54:56 +0100 From: Peter Gerwinski Message-Id: <9511271554.AA26209@rs1.Theo-Phys.Uni-Essen.DE> Subject: GCC 2.7.x and GPC 2.6.3 To: gpc@hut.fi Date: Mon, 27 Nov 1995 16:54:55 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, everybody! Somehow good news: GCC 2.7.x and GPC 2.6.3 *can* peacefully coexist on the same system. You just have to make the linuxaout-libraries visible for GPC (for example with the SlackWare 3.0 directory tree, use "gpc -L /usr/i486-linuxaout/lib myfile.pas") and to replace temporarily the new library libgcc.a by the old one. Only this one -- not the elf versions, and not libc.a, etc.. The linker will complain about some entry point, but the executable will work. I suggest to use an alias or a shell script for all that. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Mon Nov 27 17:51:05 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19803; Mon, 27 Nov 1995 17:51:04 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA01790; Mon, 27 Nov 95 17:51:00 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id SAA27692 for ; Mon, 27 Nov 1995 18:23:45 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA35515; Mon, 27 Nov 1995 17:23:41 +0100 From: Peter Gerwinski Message-Id: <9511271623.AA35515@rs1.Theo-Phys.Uni-Essen.DE> Subject: Files To: gpc@hut.fi Date: Mon, 27 Nov 1995 17:23:41 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello! Now I also have problems with the binding of external files to Pascal file variables ... I tried to use Extended Pascal "binding" to assign a file variable to an external -- existing -- file. I just copied the "Assign" pro- cedure by Berend as published in borland2ep.doc. It does not always work: I often get a runtime error saying that the file did not exist. (But it exists -- I can edit it, etc..) The only solution I could figure out: Mention each file in the program's header, forget about an "Assign" procedure, just reset it. Then you are asked for the external file name. Type it in -- voila. I defined a semi-dummy "Assign" procedure which prompts "please type in )-: myfile135.dat". It could not be done with "myexecutable To: pege@rs1.Theo-Phys.Uni-Essen.DE Message-Id: <0099A079.81AB3B20.9@ST.MFFUK> Subject: Re: Files X-Charset: ASCII X-Char-Esc: 29 Status: RO Hello, > Now I also have problems with the binding of external files to > Pascal file variables ... > > I tried to use Extended Pascal "binding" to assign a file variable > Type it in -- voila. I defined a semi-dummy > "Assign" procedure which prompts "please type in )-: myfile135.dat". > It could not be done with "myexecutable must type in each filename by hand. > > What shall I do ??? I used -Grts -a file_variable:filename switch to my program, which used file file_variable (it was mentioned in program header). This worked like static assign. Try to look somewhere in docs (use grep), I found it there. I am not sure, whether some special switch should be given to the compiler. If you find any better solution, I am interested in it. Sincerely, Pavel Petrovic http://pascal.fmph.uniba.sk/~3petrovice From gpc-request@santra.hut.fi Mon Nov 27 22:04:21 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21898; Mon, 27 Nov 1995 22:04:20 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA02349; Mon, 27 Nov 95 22:04:11 CET Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id WAA31116 for ; Mon, 27 Nov 1995 22:51:30 +0200 (EET) Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id PAA07557 for ; Mon, 27 Nov 1995 15:51:18 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id PAA11076; Mon, 27 Nov 1995 15:51:12 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA02207; Mon, 27 Nov 1995 15:46:41 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BA23B1.174D@gserver.grads.vt.edu> Date: Mon, 27 Nov 1995 15:46:41 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: gpc@hut.fi Subject: bug with strings in EMX port of gpc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO the EMX port of gpc that i've been using for my students seems to have problems with strings .. it's like the bcmp routine didnt get included in libs works fine on linux and solaris i dont even remember where i downloaded the emx version. where can i find it, or better, an update? -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Mon Nov 27 23:21:37 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19649; Mon, 27 Nov 1995 23:21:37 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA02602; Mon, 27 Nov 95 23:21:31 CET Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id AAA31817 for ; Tue, 28 Nov 1995 00:02:32 +0200 (EET) Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id RAA12643 for ; Mon, 27 Nov 1995 17:02:30 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id RAA22237; Mon, 27 Nov 1995 17:02:29 -0500 Received: by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA05578; Mon, 27 Nov 1995 16:58:06 -0500 From: tdunbar@gserver.grads.vt.edu (Thomas Dunbar) Message-Id: <9511272158.AA05578@gserver.grads.vt.edu> Subject: emx libs To: gpc@hut.fi Date: Mon, 27 Nov 1995 16:58:05 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO when i compile: program t(input,output); type s1=string(10); var s:s1; begin readln(s); writeln(substr(s,2,3)); end. with gpc on solaris or linux, it compiles fine. when i compile with emxgpc, i get: ... ld -o t.exe /emx/lib/crt0.o -L/emx/lib/st -L/emx/lib C:\DOS\cce00002 -lgpc -lgcc -lc -lc_app -lc -lgcc -lemx -los2 -lemx2 rts-string.c:144 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment rts-string.c:188 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment rts-string.c:190 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment am i using the wrong emx package? (other things compile fine..just problems working with strings) where can i get libs compatible with the latest emxgpc? -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Tue Nov 28 12:44:52 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27327; Tue, 28 Nov 1995 12:44:51 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA04731; Tue, 28 Nov 95 12:44:44 CET Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id NAA07265 for ; Tue, 28 Nov 1995 13:29:15 +0200 (EET) Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by snake.hut.fi (8.7.1/8.7.1) with SMTP id GAA13064 for ; Tue, 28 Nov 1995 06:50:14 +0200 (EET) Received: from hsb.nest.nl by sun4nl.NL.net with SMTP id AA20492 (5.65b/CWI-3.3); Tue, 28 Nov 1995 05:50:11 +0100 Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.6.11/8.6.11) with UUCP id FAA02679 for hut.fi!gpc; Tue, 28 Nov 1995 05:47:47 GMT Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Tue, 28 Nov 95 05:23:07 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG2430; Tue, 28 Nov 1995 05:03:11 +0100 Date: 27 Nov 95 19:03:24 +0100 Message-Id: <2-281-527-23-b9fd551@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: Files Status: RO * Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend@beard.nest.nl From gpc-request@santra.hut.fi Tue Nov 28 13:59:20 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA33887; Tue, 28 Nov 1995 13:59:19 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA04898; Tue, 28 Nov 95 13:59:13 CET Received: from gabriel.keele.ac.uk (gabriel.keele.ac.uk [160.5.1.248]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id OAA09275 for ; Tue, 28 Nov 1995 14:47:51 +0200 (EET) Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Mon, 27 Nov 1995 11:54:20 +0000 From: "A.A. Olowofoyeku" Message-Id: <27981.199511271154@potter.cc.keele.ac.uk> Subject: Binaries for OS/2 and DOS To: gpc@hut.fi Date: Mon, 27 Nov 1995 11:54:08 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Can you please point me to the location of the OS/2 and DOS binaries (with the Borland compatibility stuff)? I presume that there is a ready-to-run package somewhere (lost most of my saved mail recently, and so I can't trace earlier posts). Do I have to download GCC as well? Thanks. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From gpc-request@santra.hut.fi Tue Nov 28 14:57:05 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA34046; Tue, 28 Nov 1995 14:57:04 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA05051; Tue, 28 Nov 95 14:56:50 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id PAA10742 for ; Tue, 28 Nov 1995 15:40:27 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA14402; Tue, 28 Nov 1995 14:38:07 +0100 From: Peter Gerwinski Message-Id: <9511281338.AA14402@rs1.Theo-Phys.Uni-Essen.DE> Subject: Files: the solution To: berend@beard.nest.nl (Berend de Boer) Date: Tue, 28 Nov 1995 14:38:06 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <2-281-527-23-b9fd551@beard.nest.nl> from "Berend de Boer" at Nov 27, 95 07:03:24 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello! I have solved the file problem. It is in fact a bug in GPC 2.6.3: The bind procedure does not add a null character to the filename string when passing it to C. But no problem: we can correct it manually. (Since often there is a null character in RAM following the string by random, the error was not always reproducible.) The following modified Assign procedure does work around the bug and has been proven to work with GPC: Procedure Assign ( Var T: Text; protected Name: String ); Var B: BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name + chr ( 0 ); (* add the null character manually *) bind ( T, B ); B:= binding ( T ); end (* Assign *); According to Berend de Boer: > > Peter Gerwinski wrote in a message to Berend de Boer: > > PG> I tried to use Extended Pascal "binding" to assign a file > PG> variable to an external -- existing -- file. I just copied > PG> the "Assign" pro- cedure by Berend as published in > PG> borland2ep.doc. It does not always work: I often get a > PG> runtime error saying that the file did not exist. > > If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? I am using Linux, OS/2 and (Novell) DOS. I have never seen a compiler for Extended Pascal ... is Prospero's one FreeWare? Where can I find it? Greetings, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Nov 28 15:00:03 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA19494; Tue, 28 Nov 1995 15:00:02 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA05068; Tue, 28 Nov 95 14:59:54 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id PAA10883 for ; Tue, 28 Nov 1995 15:46:09 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA30086; Tue, 28 Nov 1995 14:45:35 +0100 From: Peter Gerwinski Message-Id: <9511281345.AA30086@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Binaries for OS/2 and DOS To: laa12@cc.keele.ac.uk (A.A. Olowofoyeku) Date: Tue, 28 Nov 1995 14:45:34 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <27981.199511271154@potter.cc.keele.ac.uk> from "A.A. Olowofoyeku" at Nov 27, 95 11:54:08 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello! GPC binaries for OS/2 and DOS (i.e. for EMX) and for Linux can be downloaded from kampi.hut.fi directory /jtv/gnu-pascal/binary/turbo-alpha-2.6.3 and from ftp.uni-augsburg.de directory /pub/gnu/gnu-pascal/turbo-alpha Good luck, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From laa12@cc.keele.ac.uk Tue Nov 28 15:01:05 1995 Received: from gabriel.keele.ac.uk by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA04907; Tue, 28 Nov 1995 15:00:19 +0100 Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Tue, 28 Nov 1995 13:59:56 +0000 From: "A.A. Olowofoyeku" Message-Id: <22617.199511281359@potter.cc.keele.ac.uk> Subject: Re: Files: the solution To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 28 Nov 1995 13:59:42 +0000 (GMT) Cc: gpc@hut.fi In-Reply-To: <9511281338.AA14402@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 28, 95 02:38:06 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Peter Gerwinski! You wrote: > I have never seen a compiler for Extended Pascal ... is Prospero's one > FreeWare? Where can I find it? Prospero's compiler is commercial. There is one for OS/2 (which I reviewed in the May '95 edition of the Pascal Magazine) and there is one for DOS (which I have never seen). The OS/2 version is pretty good, and also supports ISO Pascal standards. I think you can get Prospero by e-mail; tpm2info@prospero.demon.co.uk Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From laa12@cc.keele.ac.uk Tue Nov 28 15:09:32 1995 Received: from gabriel.keele.ac.uk by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA33930; Tue, 28 Nov 1995 15:09:25 +0100 Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Tue, 28 Nov 1995 14:09:07 +0000 From: "A.A. Olowofoyeku" Message-Id: <24987.199511281409@potter.cc.keele.ac.uk> Subject: Re: Binaries for OS/2 and DOS To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 28 Nov 1995 14:08:57 +0000 (GMT) Cc: gpc@hut.fi In-Reply-To: <9511281345.AA30086@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 28, 95 02:45:34 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Peter Gerwinski! You wrote: > > Hello! > > GPC binaries for OS/2 and DOS (i.e. for EMX) and for Linux can be > downloaded from > > kampi.hut.fi > > directory > > /jtv/gnu-pascal/binary/turbo-alpha-2.6.3 Thanks. I did download that version, but then could not figure out how to extract it (got confused with gzip, compress, tar, and everything else and then got totally lost, because I wasn't even sure any more whether I had downloaded the correct thing or not). The readme file did not actually explain how someone from a DOS/Win/OS2 background would go about extracting the files, and perhaps a version which is compressed with PKZIP might be a good idea, since that would be accessible to practically everybody. A further question - does this require GCC to be installed? or is the package self-contained as it is? If and when I manage to get the whole thing working, I might try and put together a single ZIP file which contains everything to get working immediately (i.e., a fully "ready to run" package) for OS/2 and DOS (and eventually Win32). I think this is a desirable thing to do, if the target audience is to be widened, because nothing is more terrifying than having to compile your own compiler or other things like that (at least, to those of us weaned on DOS Turbo Pascal). Thanks! Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From laa12@cc.keele.ac.uk Tue Nov 28 15:32:16 1995 Received: from gabriel.keele.ac.uk by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA32117; Tue, 28 Nov 1995 15:32:12 +0100 Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Tue, 28 Nov 1995 14:32:00 +0000 From: "A.A. Olowofoyeku" Message-Id: <29714.199511281431@potter.cc.keele.ac.uk> Subject: Re: Prospero compiler To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 28 Nov 1995 14:31:42 +0000 (GMT) In-Reply-To: <9511281413.AA19166@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Nov 28, 95 03:13:49 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Peter Gerwinski! You wrote: > > Dear Chief, > > > Prospero's compiler is commercial. There is one for OS/2 (which I reviewed > > in the May '95 edition of the Pascal Magazine) and there is one for DOS > > (which I have never seen). The OS/2 version is pretty good, and also > > supports ISO Pascal standards. > > That's nice, but I have no money to get anything commercial in the > moment :-( I have spent all my money on Borland compiler updates. I know the feeling - and I am not happy with Borland at all. > (But nothing for Windoze! Only for (Novell) DOS.) Lucky you. I have some shareware programs (a Windows installer and uninstaller, and a command interpreter for Windows), and my users are demanding Win32 versions. MS have moved the goal posts (-->> Win32) and I have no choice other than follow, or lose my users to competitors, some of whom already have Win32 versions, while I am still waiting for Borland. > > I think you can get Prospero by e-mail; > > tpm2info@prospero.demon.co.uk > > To buy or to look at or to steal? That's an important difference for me, > especially because the only thing I would do with it would be to extract > out the Extended Pascal standard in order to get a better feeling how to > improve GPC further. Hmmmm .... I am not sure you would get anything from Prospero that you couldn't get by just reading the EP specifications, so you don't really need Prospero at all. It is not cheap either. If you are prepared to review the compiler for some computer magazine, they might send you a free review copy. They sent me one, for my review in the Pascal Magazine. -- Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief) Keele University, England (and, The Great Elephant) Email: laa12@keele.ac.uk or, chief@mep.com From tdunbar@gserver.grads.vt.edu Tue Nov 28 16:38:18 1995 Received: from quackerjack.cc.vt.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20656; Tue, 28 Nov 1995 16:37:34 +0100 Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id KAA22158 for ; Tue, 28 Nov 1995 10:36:38 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id KAA25924; Tue, 28 Nov 1995 10:36:38 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA21595; Tue, 28 Nov 1995 10:32:21 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BB2B84.478D@gserver.grads.vt.edu> Date: Tue, 28 Nov 1995 10:32:20 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Peter Gerwinski Subject: Re: Binaries for OS/2 and DOS References: <9511281345.AA30086@rs1.Theo-Phys.Uni-Essen.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Peter Gerwinski wrote: > > Hello! > > GPC binaries for OS/2 and DOS (i.e. for EMX) and for Linux can be > downloaded from > > kampi.hut.fi but what about the related EMX libs? i'm using the emxgpc from below (downloaded again yesterday) when i try to use strings it appears that somethings missing for the libs: program t(input,output); type s1=string(10); var s:s1; begin readln(s); writeln(substr(s,2,3)); end. compiles and runs fine with Linux or Solaris gpc but with dos (emxgpc) compile gives: ld -o t.exe /emx/lib/crt0.o -L/emx/lib/st -L/emx/lib C:\DOS\cce00002 -lgpc -lgcc -lc -lc_app -lc -lgcc -lemx -los2 -lemx2 rts-string.c:144 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment rts-string.c:188 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment rts-string.c:190 (/emx/lib/gpc.a(rts-string.o)): Undefined symbol ___gcc_bcmp referenced from text segment ectory > > /jtv/gnu-pascal/binary/turbo-alpha-2.6.3 > > and from > > ftp.uni-augsburg.de > > directory > > /pub/gnu/gnu-pascal/turbo-alpha > > Good luck, > > Peter > > -------------------------------------------------------------------------------- > Dipl. Phys. Peter Gerwinski > Fachbereich Physik > Universitaet-GH Essen Phone: +49-201-183-2763 > D-45117 Essen Fax: +49-201-183-2120 > Germany e-mail: pege@mail.theo-phys.uni-essen.de > -------------------------------------------------------------------------------- -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Tue Nov 28 17:27:26 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23842; Tue, 28 Nov 1995 17:27:25 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA05511; Tue, 28 Nov 95 17:27:08 CET Received: from po2.wam.umd.edu (po2.wam.umd.edu [128.8.70.134]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id RAA12955 for ; Tue, 28 Nov 1995 17:02:23 +0200 (EET) Received: from rac1.wam.umd.edu (lotu@rac1.wam.umd.edu [128.8.70.3]) by po2.wam.umd.edu (8.6.10/8.6.12) with ESMTP id KAA24069; Tue, 28 Nov 1995 10:00:18 -0500 Received: (lotu@localhost) by rac1.wam.umd.edu (8.6.10/8.6.10) id KAA19450; Tue, 28 Nov 1995 10:00:17 -0500 Date: Tue, 28 Nov 1995 10:00:17 -0500 (EST) From: Arcadio Alivio Sincero To: "A.A. Olowofoyeku" Cc: Peter Gerwinski , gpc@hut.fi Subject: Re: Binaries for OS/2 and DOS In-Reply-To: <24987.199511281409@potter.cc.keele.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 28 Nov 1995, A.A. Olowofoyeku wrote: > Hello, Peter Gerwinski! You wrote: > > Hello! > > GPC binaries for OS/2 and DOS (i.e. for EMX) and for Linux can be > > downloaded from > > kampi.hut.fi > > directory > > /jtv/gnu-pascal/binary/turbo-alpha-2.6.3 > Thanks. I did download that version, but then could not figure out how to > extract it (got confused with gzip, compress, tar, and everything else and > then got totally lost, because I wasn't even sure any more whether I had > downloaded the correct thing or not). The readme file did not actually > explain how someone from a DOS/Win/OS2 background would go about extracting > the files, and perhaps a version which is compressed with PKZIP might be a > good idea, since that would be accessible to practically everybody. > A further question - does this require GCC to be installed? or is the > package self-contained as it is? If and when I manage to get the whole thing > working, I might try and put together a single ZIP file which contains > everything to get working immediately (i.e., a fully "ready to run" package) > for OS/2 and DOS (and eventually Win32). I think this is a desirable thing > to do, if the target audience is to be widened, because nothing is more > terrifying than having to compile your own compiler or other things like > that (at least, to those of us weaned on DOS Turbo Pascal). I think Peter uploaded compiled binaries for OS/2/DOS (EMX) to ftp.uni-augsburg.de. I know he uploaded Linux binaries there and I think he said he uploaded an OS/2/DOS version as well when he announced the Linux binaries. And if he did, it's probably packed with PKZIP. At least it should be anyway :-). Tar/gzip is for Unix. ('Tho there is tar and gzip for DOS and other platforms as well, but like you said most DOS users are familiar with PKZIP). Anyhow, having said that ... you'll need at least the EMX runtime package to run the compiled GPC binaries for OS/2/DOS. There's no need to install GCC if you don't want to code in C, C++, or Objective C. But you need at least EMX v0.9a runtime. I believe the file is called EMXRT.ZIP and can be found on any hobbes mirror in the unix/emx directory. Check the index file there to see which package is the EMX runtime package. Arcadio From gpc-request@santra.hut.fi Tue Nov 28 18:15:56 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA31083; Tue, 28 Nov 1995 18:15:55 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA05673; Tue, 28 Nov 95 18:15:51 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id SAA14901 for ; Tue, 28 Nov 1995 18:43:59 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA32142; Tue, 28 Nov 1995 17:41:57 +0100 From: Peter Gerwinski Message-Id: <9511281641.AA32142@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Binaries for OS/2 and DOS To: lotu@wam.umd.edu (Arcadio Alivio Sincero) Date: Tue, 28 Nov 1995 17:41:56 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: from "Arcadio Alivio Sincero" at Nov 28, 95 10:00:17 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO According to Arcadio Alivio Sincero: > > I think Peter uploaded compiled binaries for OS/2/DOS (EMX) to > ftp.uni-augsburg.de. I know he uploaded Linux binaries there and I think > he said he uploaded an OS/2/DOS version as well when he announced the > Linux binaries. And if he did, it's probably packed with PKZIP. At > least it should be anyway :-). Tar/gzip is for Unix. ('Tho there is tar > and gzip for DOS and other platforms as well, but like you said most DOS > users are familiar with PKZIP). I did so. The EMX binaries are packed with PKZIP, the Linux binaries with tar/gzip -- just what you expect on each system. > Anyhow, having said that ... you'll need at least the EMX runtime > package to run the compiled GPC binaries for OS/2/DOS. There's no need > to install GCC if you don't want to code in C, C++, or Objective C. But > you need at least EMX v0.9a runtime. I believe the file is called > EMXRT.ZIP and can be found on any hobbes mirror in the unix/emx > directory. Check the index file there to see which package is the EMX > runtime package. You also need the EMXDEV and GNUDEV (delopment) packages, and if you are using DPMI, you will also need DPMIGCC5 from the contrib subdirectory of the normal EMX distributions. There is one, for example, on ftp.uni-stuttgart.de in the directory /pub/systems/os2/emx-0.9a (but works well with DOS -- independently of the directory's name :-). The GNUDEV package contains the C compiler (not the C++) compiler as well as some required tools and libraries. I did not check if you may delete the C compiler itself. I expect yes. Greetings, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Nov 28 21:09:45 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA17346; Tue, 28 Nov 1995 21:09:44 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA06010; Tue, 28 Nov 95 21:09:40 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id UAA17329 for ; Tue, 28 Nov 1995 20:58:02 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22821; Tue, 28 Nov 1995 19:57:36 +0100 From: Peter Gerwinski Message-Id: <9511281857.AA22821@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: emx libs -- Strings with GPC for EMX To: tdunbar@gserver.grads.vt.edu (Thomas Dunbar) Date: Tue, 28 Nov 1995 19:57:35 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <9511272158.AA05578@gserver.grads.vt.edu> from "Thomas Dunbar" at Nov 27, 95 04:58:05 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello Thomas Dunbar, hello GPC-list! I can reproduce your error concerning strings with GPC for EMX: > when i compile: > > program t(input,output); > type > s1=string(10); > var > s:s1; > begin > readln(s); > writeln(substr(s,2,3)); > end. > > with gpc on solaris or linux, it compiles fine. when i compile > with emxgpc, i get: > > ... (error messages) The error comes from a wrong cooperation between GPC and GCC: Each of both thinks that it is job of the other one to implement the function __gcc_bcmp. Perhaps a recompile of GPC for EMX would solve the problem, but here is how you can get around the error: Just write a small file gcc_bcmp.c which contains the following: /* __gcc_bcmp function */ /* Like bcmp except the sign is meaningful. Result is negative if S1 is less than S2, positive if S1 is greater, 0 if S1 and S2 are equal. */ typedef int size_t; int __gcc_bcmp (s1, s2, size) unsigned char *s1, *s2; size_t size; { while (size > 0) { unsigned char c1 = *s1++, c2 = *s2++; if (c1 != c2) return c1 - c2; size--; } return 0; } (I found it in the file libgcc2.c from the gcc-2.6.3 source.) Include it into the compile, e.g.: gpc myfile.pas gcc_bcmp.c A more elegant way would be to include the missing routine into gpc.lib for EMX. (But I don't know how to do this :-). This problem will probably be fixed in my next release of GPC-EMX binaries. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From tdunbar@gserver.grads.vt.edu Tue Nov 28 20:54:33 1995 Received: from quackerjack.cc.vt.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA30621; Tue, 28 Nov 1995 20:53:40 +0100 Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id OAA09397; Tue, 28 Nov 1995 14:53:17 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id OAA24913; Tue, 28 Nov 1995 14:50:44 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA08686; Tue, 28 Nov 1995 14:46:25 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BB6711.3B0@gserver.grads.vt.edu> Date: Tue, 28 Nov 1995 14:46:25 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Peter Gerwinski Cc: gpc@hut.fi, tdunbar@vt.edu Subject: Re: emx libs -- Strings with GPC for EMX References: <9511281857.AA22821@rs1.Theo-Phys.Uni-Essen.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Peter Gerwinski wrote: > > Hello Thomas Dunbar, hello GPC-list! > > I can reproduce your error concerning strings with GPC for EMX: > > > when i compile: > > > > program t(input,output); > > type > > s1=string(10); > > var > > s:s1; > > begin > > readln(s); > > writeln(substr(s,2,3)); > > end. > > > > with gpc on solaris or linux, it compiles fine. when i compile > > with emxgpc, i get: > > > > ... (error messages) > > The error comes from a wrong cooperation between GPC and GCC: > Each of both thinks that it is job of the other one to implement > the function __gcc_bcmp. Perhaps a recompile of GPC for EMX would > solve the problem, but here is how you can get around the error: > Just write a small file gcc_bcmp.c which contains the following: > > /* __gcc_bcmp function */ > > /* Like bcmp except the sign is meaningful. > Result is negative if S1 is less than S2, > positive if S1 is greater, 0 if S1 and S2 are equal. */ > > typedef int size_t; > > int > __gcc_bcmp (s1, s2, size) > unsigned char *s1, *s2; > size_t size; > { > while (size > 0) > { > unsigned char c1 = *s1++, c2 = *s2++; > if (c1 != c2) > return c1 - c2; > size--; > } > return 0; > } > thanks, that works (once i downloaded the dos gcc stuff) so for now, i'm just having my students (high school pascal course) use: gpc t.pas bcmp.o (they're using 4meg boxes with little free disk space :( not even room for gcc, really. what i'd really like is to have them run linux but that would be _too_ much and not enough disk free anyway...) but iguess now's as good a time as any to show them some C code, too. > (I found it in the file libgcc2.c from the gcc-2.6.3 source.) > Include it into the compile, e.g.: > > gpc myfile.pas gcc_bcmp.c > > A more elegant way would be to include the missing routine into > gpc.lib for EMX. (But I don't know how to do this :-). > > This problem will probably be fixed in my next release of GPC-EMX > binaries. thanks, thomas > > Yours, > > Peter > > -------------------------------------------------------------------------------- > Dipl. Phys. Peter Gerwinski > Fachbereich Physik > Universitaet-GH Essen Phone: +49-201-183-2763 > D-45117 Essen Fax: +49-201-183-2120 > Germany e-mail: pege@mail.theo-phys.uni-essen.de > -------------------------------------------------------------------------------- -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Wed Nov 29 21:33:34 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24290; Wed, 29 Nov 1995 21:33:33 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA10080; Wed, 29 Nov 95 21:33:29 CET Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id WAA08912 for ; Wed, 29 Nov 1995 22:14:07 +0200 (EET) Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id PAA17494; Wed, 29 Nov 1995 15:13:30 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id PAA29344; Wed, 29 Nov 1995 15:13:09 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA28743; Wed, 29 Nov 1995 15:08:37 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BCBDC5.3D25@gserver.grads.vt.edu> Date: Wed, 29 Nov 1995 15:08:37 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Peter Gerwinski Cc: gpc@hut.fi Subject: string(1) to char? References: <9511281857.AA22821@rs1.Theo-Phys.Uni-Essen.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO can one convert a string of length one into a char? ie the below wont work: program t(input,output); var ch:char; s:string(10); begin s:='teststring'; writeln(substr(s,2,1)); ch:=substr(s,2,1); writeln(ord(ch)); end. so, if one needs to get the ascii value of a particular value in a string, does one have to fall back to the std pascal of using packed array of char? thomas -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Thu Nov 30 01:56:13 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA18825; Thu, 30 Nov 1995 01:56:12 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA10697; Thu, 30 Nov 95 01:56:08 CET Received: from infosoc.com (infosoc.com [204.80.221.1]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id CAA10863 for ; Thu, 30 Nov 1995 02:39:11 +0200 (EET) Received: (ekaras@localhost) by infosoc.com (8.6.11/8.6.5) id TAA26269 for gpc@hut.fi; Wed, 29 Nov 1995 19:44:19 -0500 Date: Wed, 29 Nov 1995 19:44:19 -0500 From: Erik Karas Message-Id: <199511300044.TAA26269@infosoc.com> Apparently-To: gpc@hut.fi Status: RO Will there be a version of gpc for gcc 2.7.0? If so when? Thanks From gpc-request@santra.hut.fi Thu Nov 30 15:30:15 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21589; Thu, 30 Nov 1995 15:30:14 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13010; Thu, 30 Nov 95 15:30:05 CET Received: from si6624.bosch.de (gatekeeper.bosch.de [193.141.57.1]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id QAA23172 for ; Thu, 30 Nov 1995 16:05:30 +0200 (EET) From: kraemer@ervax1.decnet.bosch.de Received: by si6624.bosch.de (5.65/rg-150294); id AA21398; Thu, 30 Nov 95 15:05:23 +0100 Received: from ERVAX1 by si4640.si.bosch.de with DECnet id AA24458 (5.67b8+/IDA-1.5-DNgate-2.0-10 for gpc@hut.fi); Thu, 30 Nov 1995 15:12:49 GMT Date: Thu, 30 Nov 1995 15:12:48 GMT Message-Id: <199511301512.AA24458@si4640.si.bosch.de> To: gpc@hut.fi Subject: gpc - questions X-Charset: ISO_8859-1 X-Char-Esc: 29 Status: RO Robert Bosch GmbH Erbach, 30.11.95 IA1 / ESP4 Peter Kraemer-Eis Postfach 1162 D-64701 Erbach Tel.: 06062/78-463 Germany Fax.: 06062/78-771 Dear Mr. Virtanen, in our company, we have developed the software for a robot controler. Up to now, we used the National NS32000 family as target-cpu. Except of the hardware-near parts, our present software is written in NS-cross-pascal. The whole software for the robot-controler needs 2 MByte code and is split into about 200 files (modules). Now we are forced to replace the target-cpu by an intel-cpu (i486 or i586) and we hope, that most of our present software is portable to your GNU-Pascal. For a test, we have installed 'Linux SuSE August 95', which includes your GPC version 1.1 (2.6.3). First results are quite promising, but there are some questions: (1) Is there any reference manual (in addition to the GPC.GUIDE, which is too short, to work with it)? If yes, how can I get it? (2) Is there any possibility, to avoid the case-sensitivity of the names of variables/procedures? Our present software is completely written in capital letters and therefore we have problems when debugging with GDB. (3) Is there any restriction to the number of import/export of variables or procedures? (4) How can I get the source-files of your GPC? I havn't found them on the CD-Roms of 'Linux SuSE August 95'. Best regards, yours Peter Kraemer-Eis From gpc-request@santra.hut.fi Thu Nov 30 17:17:32 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA31116; Thu, 30 Nov 1995 17:17:31 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13317; Thu, 30 Nov 95 17:17:21 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id RAA25653 for ; Thu, 30 Nov 1995 17:55:32 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA05081; Thu, 30 Nov 1995 16:51:47 +0100 From: Peter Gerwinski Message-Id: <9511301551.AA05081@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: string(1) to char? To: tdunbar@gserver.grads.vt.edu (Thomas Dunbar) Date: Thu, 30 Nov 1995 16:51:47 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <30BCBDC5.3D25@gserver.grads.vt.edu> from "Thomas Dunbar" at Nov 29, 95 03:08:37 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, Thomas; hello, GPC-list! According to Thomas Dunbar: > > can one convert a string of length one into a char? > > ie the below wont work: > > program t(input,output); > var > ch:char; > s:string(10); > begin > s:='teststring'; > writeln(substr(s,2,1)); > ch:=substr(s,2,1); > writeln(ord(ch)); > end. Yes, one can. The correct assignment reads ch:= s [ 2 ]; I think, this is Standard Pascal, nothing special. At least, it is common between UCSD, Borland and GNU Pascal. In the above sense, a string actually *is* a packed array of char. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Nov 30 18:20:55 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23896; Thu, 30 Nov 1995 18:20:54 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13518; Thu, 30 Nov 95 18:20:45 CET Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by santra.hut.fi (8.7.2/8.7.2) with ESMTP id SAA26455; Thu, 30 Nov 1995 18:45:09 +0200 (EET) Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id LAA10076; Thu, 30 Nov 1995 11:45:07 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id LAA03207; Thu, 30 Nov 1995 11:45:06 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA14468; Thu, 30 Nov 1995 11:40:50 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BDDE91.4259@gserver.grads.vt.edu> Date: Thu, 30 Nov 1995 11:40:49 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Jukka.Virtanen@hut.fi Cc: gpc@hut.fi, tdunbar@vt.edu Subject: Re: string(1) to char? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Jukka Virtanen wrote: > > > > can one convert a string of length one into a char? > > > > > > ie the below wont work: > > > > > > program t(input,output); > > > var > > > ch:char; > > > s:string(10); > > > begin > > > s:='teststring'; > > > writeln(substr(s,2,1)); > > > ch:=substr(s,2,1); > > > writeln(ord(ch)); > > > end. > > > > Yes, one can. The correct assignment reads > > > > ch:= s [ 2 ]; > > > > I think, this is Standard Pascal, nothing special. At least, it is > > common between UCSD, Borland and GNU Pascal. > > In extended pascal it is also allowed to assign a string > to a char if the length of the string is 1, which is the case > here. you are welcome :) but note that i _can_ do the assignment via: readstr(substr(s,2,1),ch); > > I think you found a bug in gpc, thanks for the report :-) > > Juki > jtv@hut.fi -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From gpc-request@santra.hut.fi Thu Nov 30 18:34:06 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA33271; Thu, 30 Nov 1995 18:34:05 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13529; Thu, 30 Nov 95 18:34:01 CET Received: from sun4nl.NL.net (sun4nl.NL.net [193.78.240.1]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id TAA26933 for ; Thu, 30 Nov 1995 19:20:52 +0200 (EET) Received: from hsb.nest.nl by sun4nl.NL.net with SMTP id AA17471 (5.65b/CWI-3.3); Thu, 30 Nov 1995 18:20:47 +0100 Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.6.11/8.6.11) with UUCP id SAA00168 for hut.fi!gpc; Thu, 30 Nov 1995 18:16:31 GMT Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Thu, 30 Nov 95 18:12:48 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG2434; Thu, 30 Nov 1995 18:05:59 +0100 Date: 30 Nov 95 08:12:28 +0100 Message-Id: <60-60-0-0-bd59331@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: string(1) to char? Status: RO Thomas Dunbar wrote in a message to Berend de Boer: It works on my Prospero Extended Pascal compiler. The works maybe with gpc: TD> program t(input,output); TD> var TD> ch:char; TD> s:string(10); TD> begin TD> s:='teststring'; TD> writeln(substr(s,2,1)); ch:=substr[2]; TD> writeln(ord(ch)); TD> end. Groetjes, Berend (-: CIS: 100120,3121 email: berend@beard.nest.nl From tdunbar@gserver.grads.vt.edu Thu Nov 30 19:21:31 1995 Received: from quackerjack.cc.vt.edu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23519; Thu, 30 Nov 1995 19:20:46 +0100 Received: from holodeck.cc.vt.edu (holodeck.cc.vt.edu [128.173.16.28]) by quackerjack.cc.vt.edu (8.7.1/8.7.1) with SMTP id LAA08258 for ; Thu, 30 Nov 1995 11:16:52 -0500 (EST) Received: from gserver.grads.vt.edu by holodeck.cc.vt.edu with SMTP (8.6.12/16.2) id LAA16350; Thu, 30 Nov 1995 11:16:51 -0500 Received: from gserver.grads.vt.edu by gserver.grads.vt.edu (5.x/SMI-SVR4) id AA12982; Thu, 30 Nov 1995 11:12:36 -0500 Sender: tdunbar@gserver.grads.vt.edu Message-Id: <30BDD7F4.70BE@gserver.grads.vt.edu> Date: Thu, 30 Nov 1995 11:12:36 -0500 From: Thomas Dunbar Organization: Virginia Tech X-Mailer: Mozilla 2.0b3 (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Peter Gerwinski Subject: Re: string(1) to char? References: <9511301551.AA05081@rs1.Theo-Phys.Uni-Essen.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Peter Gerwinski wrote: > > Hello, Thomas; hello, GPC-list! > > According to Thomas Dunbar: > > > > can one convert a string of length one into a char? > > > > ie the below wont work: > > > > program t(input,output); > > var > > ch:char; > > s:string(10); > > begin > > s:='teststring'; > > writeln(substr(s,2,1)); > > ch:=substr(s,2,1); > > writeln(ord(ch)); > > end. > > Yes, one can. The correct assignment reads > > ch:= s [ 2 ]; thanks, Peter. i also find that readstr(substr(s,2,1),ch); works but the packed array way is simpler. thomas > > I think, this is Standard Pascal, nothing special. At least, it is > common between UCSD, Borland and GNU Pascal. > > In the above sense, a string actually *is* a packed array of char. > > Yours, > > Peter > > -------------------------------------------------------------------------------- > Dipl. Phys. Peter Gerwinski > Fachbereich Physik > Universitaet-GH Essen Phone: +49-201-183-2763 > D-45117 Essen Fax: +49-201-183-2120 > Germany e-mail: pege@mail.theo-phys.uni-essen.de > -------------------------------------------------------------------------------- -- Thomas Dunbar 540 231-3938 (fax 3714) http://gserver.grads.vt.edu/ From root@Grogor.org Fri Dec 1 02:44:07 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22485; Fri, 1 Dec 1995 02:44:03 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA14684; Fri, 1 Dec 95 02:43:44 CET Received: (from root@localhost) by Grogor.org (8.6.12/8.6.9) id OAA00242; Mon, 27 Nov 1995 14:58:44 -0800 Date: Mon, 27 Nov 1995 14:58:43 -0800 (PST) From: root To: pege@rt07.Theo-Phys.Uni-Essen.DE Subject: GNU Pascal Binary Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I've just installed Slackware Linux 3.0 on my system and I'm trying to install the GNU pascal compiler. Unfortunately, the only version of GCC I have is 2.7.0. I don't know where to find GCC 2.6.3 to run with GPC. Do you know where I could find this, or know where I could find a GPC compiler compatable with 2.7.0? Any help would gladly be appreciated. Thanks, Greg Sibley n9345955@cain.lake.cs.wwu.edu <== mail to this address From gpc-request@santra.hut.fi Sun Dec 3 14:45:26 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23544; Sun, 3 Dec 1995 14:45:25 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA23863; Sun, 3 Dec 95 14:45:24 CET Received: from xs1.xs4all.nl (mamoman@xs1.xs4all.nl [193.78.33.42]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id PAA25946 for ; Sun, 3 Dec 1995 15:35:45 +0200 (EET) Received: by xs1.xs4all.nl id AA15690 (5.67b/IDA-1.5 for gpc@hut.fi); Sun, 3 Dec 1995 14:35:39 +0100 Date: Sun, 3 Dec 1995 14:35:38 +0100 (MET) From: Martin Moerman To: gpc@hut.fi Cc: Martin Moerman Subject: GPC problem.. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I have a problem when using gpc.. I was a big fan of borland pascal (turbo pascal 3 to 7).. When i use gpc i can't use the command clrsrc (clear screen). Normaly in pascal i have to do (uses dos;), how can i solve this problem in gpc. ps. Is there also a manual for it (not gpc.guide).. Martin mamoman@xs4all.nl From gpc-request@santra.hut.fi Tue Dec 5 15:07:30 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23584; Tue, 5 Dec 1995 15:07:28 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA01498; Tue, 5 Dec 95 15:07:18 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.2/8.7.2) with SMTP id PAA30456 for ; Tue, 5 Dec 1995 15:29:33 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24635; Tue, 5 Dec 1995 14:16:12 +0100 From: Peter Gerwinski Message-Id: <9512051316.AA24635@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: GPC problem.. To: gpc@hut.fi Date: Tue, 5 Dec 1995 14:16:12 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO According to pege: >From pege Tue Dec 5 14:15:44 1995 Subject: Re: GPC problem.. To: mamoman@xs4all.nl (Martin Moerman) Date: Tue, 5 Dec 1995 14:15:44 +0100 (MEZ) In-Reply-To: from "Martin Moerman" at Dec 3, 95 02:35:38 pm X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1494 According to Martin Moerman: > > When i use gpc i can't use the command clrsrc (clear screen). > Normaly in pascal i have to do (uses dos;), you mean: uses crt; > how can i solve this problem > in gpc? You have to find some standard library (dependend of your operating system) which contains something equivalent to clrscr. On DOS and OS/2, look into the EMX documentation libref.doc (it is a C library, but never mind -- GPC.GUIDE explains how to use it with GPC). With Linux, write the terminal escape sequences to the screen to emulate functions of CRT -- see the etc/termcap file for details. Or you can wait a little: I am writing a system-independent replacement for crt, graph, and the whole Turbo Vision (but in graphics mode). (Some people say, there would be no need for it, but I won't stop. :-) I hope to be ready for the first release (of only the crt part) this year. > ps. Is there also a manual for it (not gpc.guide).. I am afraid, no. But read README.TURBO, there are some things documented, how GPC differs from Turbo. Bye, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From Janos.Vegh@moon.atomki.hu Wed Dec 6 09:06:42 1995 Received: from cseles.atomki.hu by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA09036; Wed, 6 Dec 1995 09:06:29 +0100 Received: from vegh_j.atomki.hu by cseles.atomki.hu via SMTP (931110.SGI/930416.SGI.AUTO) for pege@rs1.Theo-Phys.Uni-Essen.DE id AA15131; Wed, 6 Dec 95 09:04:43 +0100 Date: Wed, 6 Dec 95 09:04:43 +0100 Message-Id: <9512060804.AA15131@cseles.atomki.hu> X-Sender: vegh_j@cseles.atomki.hu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Peter Gerwinski From: Janos Vegh Subject: Re: GPC problem.. Status: RO At 02:16 PM 12/5/95 +0100, you wrote: >Or you can wait a little: I am writing a system-independent >replacement for crt, graph, and the whole Turbo Vision (but in >graphics mode). (Some people say, there would be no need for it, >but I won't stop. :-) I hope to be ready for the first release >(of only the crt part) this year. > I am happy to hear about! Dr Janos Vegh, physicist Janos.Vegh@ATOMKI.HU Institut of Nuclear Research of Vegh_J@Tigris.KLTE.HU the Hungarian Academy of Science Janos.Vegh@helka.iif.hu H-4001 Debrecen, POB 51, Hungary Tel: +36(52)417266 ext 1215 (H-4028 Debrecen, Bem ter 18/C) Fax: +36(52)413945 or 416181 From gpc-request@santra.hut.fi Tue Dec 12 15:11:25 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26239; Tue, 12 Dec 1995 15:11:24 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28637; Tue, 12 Dec 95 15:11:18 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id PAA04463 for ; Tue, 12 Dec 1995 15:48:39 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20855; Tue, 12 Dec 1995 14:48:10 +0100 From: Peter Gerwinski Message-Id: <9512121348.AA20855@rs1.Theo-Phys.Uni-Essen.DE> Subject: Dispose problem To: peter@idiap.ch (Peter Weber) Date: Tue, 12 Dec 1995 14:48:10 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <9512121207.AA02805@idiap.ch> from "Peter Weber" at Dec 12, 95 01:07:30 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, Peter, hello, gpc-list! > pcc version 2.6.3 > sparc sunos4.1.3 > > program test; > type > num_pointer = ^integer; > var > num : num_pointer; > begin > new(num); > num^ := 3; > dispose(num); > end. > > ==> gpc: Internal compiler error: program gpc1 got fatal signal 10 I can reproduce the error with EMX (not with Linux). I hope to be able to release a bug fix this week. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Dec 12 20:11:55 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27618; Tue, 12 Dec 1995 20:11:54 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA29460; Tue, 12 Dec 95 20:11:42 CET Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id UAA09928 for ; Tue, 12 Dec 1995 20:56:28 +0200 (EET) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id KAA07180; Tue, 12 Dec 1995 10:56:11 -0800 Date: Tue, 12 Dec 1995 10:56:11 -0800 From: Phil Nelson Message-Id: <199512121856.KAA07180@fawn.cs.wwu.edu> To: jtv@kampi.hut.fi Cc: gpc@hut.fi Subject: bug in records? Status: RO gpc-2.6.3/sparc I believe the following program should generate an error. (But it doesn't.) program variant(output); type myrec = record case integer of 1 : (f1:integer); 2 : (f1:real) end; begin end. -- Phil Nelson e-mail: phil@cs.wwu.edu http://www.cs.wwu.edu/~phil From pege Mon Sep 18 16:20:55 1995 Subject: Re^2: From Borland to GNU ... To: Jukka.Virtanen@hut.fi Date: Mon, 18 Sep 1995 16:20:55 +0100 (MESZ) In-Reply-To: from "Jukka Virtanen" at Sep 18, 95 05:03:59 pm X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1657 Status: RO Hello, Juki! > Also I have no knowledge of turbo pascal, so your contribution > is very important!!! My problem is that the Borland "standard" is the only standard I know. I think I will be able to implement it (within some __long__ time ...) but I can not give a warranty that ISO standard will still work. Where did you get that standard? > I have the C++ version of gperf. As far as I rememer > Doug Schmidt wrote also a C version of it, but > I don't know where it currently is. If you need > it I could try to find it. I know the place in principle, but my access to there failed. In the moment, it is not this important. I will cry for help, if it becomes. > Where did you get the EMX changes from? Are they > already in the 2.7.0 gcc release? If they are, > it makes things a lot easier. I found version 2.6.3 at ftp.uni-paderborn.de. The patched version 2.7.0 is present at ftp.uni-stuttgart.de, directory /pub/systems/os2/emx-0.9a/gcc-2.7.0. My upload: I was knocked out of the system several times. Now I had success by changing the upload names to README.new and make-gpc.zip.new. Please change them back to README and make-gpc.zip since DOS will reject filenames longer than 8.3. Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Dec 19 19:37:50 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21103; Tue, 19 Dec 1995 19:37:49 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27483; Tue, 19 Dec 95 19:37:37 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id UAA22094 for ; Tue, 19 Dec 1995 20:14:28 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26880; Tue, 19 Dec 1995 19:14:17 +0100 From: Peter Gerwinski Message-Id: <9512191814.AA26880@rs1.Theo-Phys.Uni-Essen.DE> Subject: Borland extensions: new version To: gpc@hut.fi Date: Tue, 19 Dec 1995 19:14:16 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, GPC-list! I have uploaded the 1.1 version of the Borland Extensions for GPC to kampi.hut.fi and to ftp.uni-augsburg.de. In Augsburg, it can already be downloaded from the directory /pub/gnu/gnu-pascal/turbo-alpha. The file turbo-1.1-gpc-2.6.3.tar.gz contains the new patched source, binaries for EMX and Linux have been updated. There are no new features, but some bugs have been fixed. Objects (virtual methods) are more stable now, -g should work now, etc. That's not all ... second mail follows ... Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Dec 19 19:31:28 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26986; Tue, 19 Dec 1995 19:31:27 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27480; Tue, 19 Dec 95 19:31:18 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id UAA22003 for ; Tue, 19 Dec 1995 20:15:17 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24339; Tue, 19 Dec 1995 19:15:12 +0100 From: Peter Gerwinski Message-Id: <9512191815.AA24339@rs1.Theo-Phys.Uni-Essen.DE> Subject: BO5 To: gpc@hut.fi Date: Tue, 19 Dec 1995 19:15:11 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Dec 19 19:31:17 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA15716; Tue, 19 Dec 1995 19:31:16 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27477; Tue, 19 Dec 95 19:31:03 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id UAA22086 for ; Tue, 19 Dec 1995 20:16:49 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26914; Tue, 19 Dec 1995 19:16:42 +0100 From: Peter Gerwinski Message-Id: <9512191816.AA26914@rs1.Theo-Phys.Uni-Essen.DE> Subject: BO5 To: gpc@hut.fi Date: Tue, 19 Dec 1995 19:16:41 +0100 (MEZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, world! This is an announcement of a new library for GNU Pascal: BO5 It is only a pre-alpha release (version 0.01), but it should give you - some Borland-like tools such as Assign, FillChar, ParamStr, GetEnv, Random, - direct keyboard access via KeyPressed and ReadKey function, - direct screen access with colors. You need turbo-1.1-gpc-2.6.3 (i.e. the first bug fix for the GPC with Borland extensions, released together with BO5 on 19. December 1995) to compile BO5. BO5 is intended to run on *all* platforms on which GPC runs. If not, or if you have some other comment/suggestion/bug report, please write to pege@mail.theo-phys.uni-essen.de If your comment is of general interest for all GPC users, you should better write to the gpc-list gpc@hut.fi I have uploaded BO5 to kampi.hut.fi and to ftp.uni-augsburg.de. In Augsburg, it can already be downloaded from /pub/gnu/gnu-pascal/turbo-alpha For more information, please read the files README.BO5 and README.001. Merry Christmas and a happy New Year! Yours, Peter From gpc-request@santra.hut.fi Fri Dec 22 21:31:49 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20777; Fri, 22 Dec 1995 21:31:48 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA09817; Fri, 22 Dec 95 21:31:40 CET Received: from ifmsun3.ifm.uni-hamburg.de (ifmsun3.ifm.uni-hamburg.de [134.100.80.224]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id WAA10605 for ; Fri, 22 Dec 1995 22:21:51 +0200 (EET) Received: from ifmaix7.ifm.uni-hamburg.de (ifmaix7.ifm.uni-hamburg.de [134.100.80.33]) by ifmsun3.ifm.uni-hamburg.de (8.6.12/8.6.12) with ESMTP id VAA10368 for ; Fri, 22 Dec 1995 21:21:49 +0100 From: Cesar Romani Received: (romani@localhost) by ifmaix7.ifm.uni-hamburg.de (8.7.2/8.6.12) id VAA21816 for gpc@hut.fi; Fri, 22 Dec 1995 21:21:49 +0100 Date: Fri, 22 Dec 1995 21:21:49 +0100 Message-Id: <199512222021.VAA21816@ifmaix7.ifm.uni-hamburg.de> To: gpc@hut.fi Subject: compiling gpc with gcc-2.7.2 Status: RO Is it possible to compile gpc-1.1-2.6.3 with gcc-2.7.2 ? Thanks in advance Cesar Romani Hamburg, Germany From gpc-request@santra.hut.fi Thu Dec 28 00:04:16 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21220; Thu, 28 Dec 1995 00:04:14 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28121; Thu, 28 Dec 95 00:04:04 CET Received: from txcc.net (txcc.net [205.218.183.157]) by santra.hut.fi (8.7.3/8.7.3) with ESMTP id AAA02373 for ; Thu, 28 Dec 1995 00:29:25 +0200 (EET) Received: (from cl@localhost) by txcc.net (8.7.2/8.6.9) id QAA00867; Wed, 27 Dec 1995 16:27:48 -0600 (CST) Date: Wed, 27 Dec 1995 16:27:48 -0600 (CST) From: CLink To: gpc@hut.fi Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO help From gpc-request@santra.hut.fi Thu Dec 28 01:09:14 1995 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27691; Thu, 28 Dec 1995 01:09:13 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28274; Thu, 28 Dec 95 01:09:03 CET Received: from txcc.net (txcc.net [205.218.183.157]) by santra.hut.fi (8.7.3/8.7.3) with ESMTP id BAA03298 for ; Thu, 28 Dec 1995 01:41:05 +0200 (EET) Received: (from cl@localhost) by txcc.net (8.7.2/8.6.9) id RAA01203; Wed, 27 Dec 1995 17:39:27 -0600 (CST) Date: Wed, 27 Dec 1995 17:39:27 -0600 (CST) From: CLink To: gpc@hut.fi Subject: help Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO hep From gpc-request@santra.hut.fi Wed Jan 24 06:34:12 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26190; Wed, 24 Jan 1996 06:34:11 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA14999; Wed, 24 Jan 96 06:33:58 CET Received: from csie.ntu.edu.tw (root@cslab.csie.ntu.edu.tw [140.112.30.25]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id HAA13560 for ; Wed, 24 Jan 1996 07:07:24 +0200 (EET) Received: from ntucsx.csie.ntu.edu.tw (ntucsx.csie.ntu.edu.tw [140.112.30.64]) by csie.ntu.edu.tw (8.6.11/8.6.11) with SMTP id NAA23479 for ; Wed, 24 Jan 1996 13:05:12 +0800 Date: Wed, 24 Jan 1996 13:05:12 +0800 From: b2506033 Message-Id: <199601240505.NAA23479@csie.ntu.edu.tw> Subject: [Help] gpc for dos Newsgroups: comp.lang.pascal.ansi-iso Keywords: gpc X-Newsreader: TIN [version 1.2 PL2] Apparently-To: Status: RO Hello, When compiled a small program, I got a lot of error message. I use gpc-263b got from kampi.hut.fi. Please help me. Thanks. program testgpc; var i : integer; begin i := 20; end. c_include_path=c:/emx/include; library_path=c:/emx/lib; emx=c:/emx/bin/emx.exe path=c:/dos;c:/emx/bin;......; rts-file.c: 221 c:/emx/lib/gpc.a(rts-file.o)): Undefined Symbol _write referenced from text segment ....... _read ....... _unlink ....... _fstat ....... _isatty ....... _access ....... _stat ....... _bcopy ....... ...... kampi.hut.fi:/jtv/gnu-pascal/EMX 1005157 Sep 15 16:52 gpc-263b.zip --- b2506033@csie.ntu.edu.tw Herge From gpc-request@santra.hut.fi Thu Jan 25 11:27:02 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26337; Thu, 25 Jan 1996 11:27:02 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA19870; Thu, 25 Jan 96 11:26:38 CET Received: from hsb.nest.nl (root@hsb.nest.nl [193.78.79.21]) by santra.hut.fi (8.7.3/8.7.3) with ESMTP id LAA10435 for ; Thu, 25 Jan 1996 11:56:35 +0200 (EET) Received: from nestnl.nest.nl (root@localhost) by hsb.nest.nl (8.7.3/8.6.11) with UUCP id KAA00231 for hut.fi!gpc; Thu, 25 Jan 1996 10:46:42 GMT Received: by nestnl.nest.nl (V1.17-beta/Amiga) id ; Thu, 25 Jan 96 05:51:12 +0100 Received: by beard.nest.nl (BeyondGating/0.88alpha) id BG0064; Thu, 25 Jan 1996 05:03:03 +0100 Date: 24 Jan 96 20:38:13 +0100 Message-Id: <60-60-0-0-1068ac60@beard.nest.nl> From: berend@beard.nest.nl (Berend de Boer) To: gpc@hut.fi Subject: [Help] gpc for dos Status: RO b2506033 wrote in a message to Berend de Boer: b> When compiled a small program, I got a lot of error message. How do you call your compiler? Did you include all the right libs as -Xgpc? Groetjes, Berend (-: fido: 2:281/527.23 email: berend@beard.nest.nl From gpc-request@santra.hut.fi Thu Jan 25 15:53:42 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA21640; Thu, 25 Jan 1996 15:53:41 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA20527; Thu, 25 Jan 96 15:53:08 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id QAA17924 for ; Thu, 25 Jan 1996 16:29:43 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA24091; Thu, 25 Jan 1996 15:27:26 +0100 From: Peter Gerwinski Message-Id: <9601251427.AA24091@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: [Help] gpc for dos To: b2506033@csie.ntu.edu.tw (b2506033) Date: Thu, 25 Jan 1996 15:27:25 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <199601240505.NAA23479@csie.ntu.edu.tw> from "b2506033" at Jan 24, 96 01:05:12 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello! According to b2506033: > > When compiled a small program, I got a lot of error message. I use > gpc-263b got from kampi.hut.fi. Please help me. Thanks. > b2506033@csie.ntu.edu.tw Herge Your environment variables seem to be correct, but did you install the EMXDEV package? You need at least EMXRT, EMXDEV, and GNUDEV for a working GPC compiler. If you have DPMI without VCPI, you also need DPMIGCC5 from emx/contrib. Good luck! Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Jan 25 21:03:49 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA05991; Thu, 25 Jan 1996 21:03:48 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA21665; Thu, 25 Jan 96 21:03:31 CET Received: from mail.netline.be (root@[193.75.199.3]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id VAA23500 for ; Thu, 25 Jan 1996 21:53:05 +0200 (EET) Received: from extacy (root@dialup12.liege.eunet.be [193.123.246.12]) by mail.netline.be (8.6.12/8.6.9) with SMTP id VAA16107 for ; Wed, 17 Jan 1996 21:54:12 +0200 Sender: root@mail.netline.be Message-Id: <3107DFEE.2FD51F43@netline.be> Date: Thu, 25 Jan 1996 20:54:22 +0100 From: Emmanuel Tychon Organization: NetLine, internet experts X-Mailer: Mozilla 2.0b5 (X11; I; Linux 1.2.13 i486) Mime-Version: 1.0 To: gpc@hut.fi Subject: no Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO mailing list -- ||| | Emmanuel Tychon, manu@netline.be O-O | SemaDigit: 018/458701 (Belgium Only) (_) | NetLine sprl, oOO-----OOo | Linux Team , | Linux | | \-------/ | NetLine IS your interNet partner. From gpc-request@santra.hut.fi Tue Jan 30 14:26:57 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA29956; Tue, 30 Jan 1996 14:26:54 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA11115; Tue, 30 Jan 96 14:26:31 CET Received: from theoqw4.physik.uni-ulm.de (theoqw4.physik.uni-ulm.de [134.60.10.244]) by santra.hut.fi (8.7.3/8.7.3) with ESMTP id OAA15441 for ; Tue, 30 Jan 1996 14:01:25 +0200 (EET) Message-Id: <199601301201.OAA15441@santra.hut.fi> Received: by theoqw4.physik.uni-ulm.de (1.37.109.16/16.2/V950224) id AA054973273; Tue, 30 Jan 1996 13:01:13 +0100 From: Harald Wiedemann Subject: request To: gpc@hut.fi Date: Tue, 30 Jan 96 13:01:12 MEZ Reply-To: harald.wiedemann@physik.uni-ulm.de Mailer: Elm [revision: 70.85] Status: RO I would like to participate in the gpc list. From gpc-request@santra.hut.fi Sun Feb 4 22:51:26 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20421; Sun, 4 Feb 1996 22:51:25 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA02334; Sun, 4 Feb 96 22:51:09 CET Received: from student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id XAA15126 for ; Sun, 4 Feb 1996 23:43:28 +0200 (EET) Received: from slp06164.slip.utwente.nl by student.utwente.nl with SMTP id AA05636 (5.67b/IDA-1.5 for ); Sun, 4 Feb 1996 22:43:25 +0100 Date: Sun, 4 Feb 1996 22:43:25 +0100 Message-Id: <199602042143.AA05636@student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@hut.fi From: JanJaap van der Heijden Subject: suscribe gpc Status: RO suscribe gpc -- Science is what I'm doing when I don't know what I'm doing Werner von Braun From gpc-request@santra.hut.fi Mon Feb 26 22:58:48 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA23658; Mon, 26 Feb 1996 22:58:47 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA21679; Mon, 26 Feb 96 22:58:44 CET Received: from servo.ucsd.edu (mpless@servo.ucsd.edu [132.239.50.46]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id XAA06353 for ; Mon, 26 Feb 1996 23:41:45 +0200 (EET) Received: (from mpless@localhost) by servo.ucsd.edu (8.6.12/8.6.12) id NAA14163 for gpc@hut.fi; Mon, 26 Feb 1996 13:41:43 -0800 Date: Mon, 26 Feb 1996 13:41:43 -0800 From: Marcus Pless Message-Id: <199602262141.NAA14163@servo.ucsd.edu> To: gpc@hut.fi Status: RO lists From sad@utkux.utcc.utk.edu Sun Mar 17 02:13:53 1996 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27212; Sun, 17 Mar 1996 02:13:47 +0100 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA25535; Sat, 16 Mar 1996 20:13:09 -0500 From: sad@utkux.utcc.utk.edu Message-Id: <9603170113.AA25535@utkux4.utcc.utk.edu> Subject: Q: Is there a gpc/emx for emx09b already ? To: gpc@hut.fi, pege@rs1.Theo-Phys.Uni-Essen.DE Date: Sat, 16 Mar 1996 20:13:08 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi all, hi Peter, I was wondering whether it is just me or a known (and maybe even fixed?) problem: I just finished installing emx09b on my machine to be able to run things like the latest gnuplot beta and all that stuff that gave me warnings about having to use emx09b. So, all seemed well. In fact, even g77 worked, it still does after I have installed the version that had been recompiled with emx09b. GPC doesn't like me anymore, though. It compiles, but linking doesn't seem to work, I get stuff like: rts-file.c:221 (e:/bin/emx/lib/gpc.a(rts-file.o)): Undefined symbol _write refer enced from text segment and lots of it. I then fetched a later version from ftp.uni-augsburg.de since I can't seem to get through to kampi.hut.fi tonight, and installed it: Still the same problem. I understand that emxgpc was compiled (or patched) for 2.6.3, but I was wondering whether there is any hope on the horizon for a transparent gpc under emx? Interesting enough, gpc --version reports %PROG2%, so this may serve as version indication: rwxa-- 161799 Dec 13 00:39 e:/bin/emx/bin/gpc.exe* but more interesting (and temporary relief!) is, that gpc -c test.pas gcc test.o -lgpc does produce a working executable. Any ideas, pointers, promises are most welcome! Cheers! Stefan From sad@utkux.utcc.utk.edu Sun Mar 17 02:35:29 1996 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26741; Sun, 17 Mar 1996 02:35:27 +0100 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA29352; Sat, 16 Mar 1996 20:34:55 -0500 From: sad@utkux.utcc.utk.edu Message-Id: <9603170134.AA29352@utkux4.utcc.utk.edu> Subject: 2nd attemtpt -- gpc and emx09b ? To: gpc@hut.fi Date: Sat, 16 Mar 1996 20:34:55 -0500 (EST) Cc: pege@rs1.Theo-Phys.Uni-Essen.DE, Jukka.Virtanen@hut.fi X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Sorry if this shows up twice but something bounced, so I try it again. Stefan Hi all, hi Peter, I was wondering whether it is just me or a known (and maybe even fixed?) problem: I just finished installing emx09b on my machine to be able to run things like the latest gnuplot beta and all that stuff that gave me warnings about having to use emx09b. So, all seemed well. In fact, even g77 worked, it still does after I have installed the version that had been recompiled with emx09b. GPC doesn't like me anymore, though. It compiles, but linking doesn't seem to work, I get stuff like: rts-file.c:221 (e:/bin/emx/lib/gpc.a(rts-file.o)): Undefined symbol _write refer enced from text segment and lots of it. I then fetched a later version from ftp.uni-augsburg.de since I can't seem to get through to kampi.hut.fi tonight, and installed it: Still the same problem. I understand that emxgpc was compiled (or patched) for 2.6.3, but I was wondering whether there is any hope on the horizon for a transparent gpc under emx? Interesting enough, gpc --version reports %PROG2%, so this may serve as version indication: rwxa-- 161799 Dec 13 00:39 e:/bin/emx/bin/gpc.exe* but more interesting (and temporary relief!) is, that gpc -c test.pas gcc test.o -lgpc does produce a working executable. Any ideas, pointers, promises are most welcome! Cheers! Stefan From gpc-request@santra.hut.fi Mon Mar 18 14:06:08 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA06459; Mon, 18 Mar 1996 14:06:07 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA16956; Mon, 18 Mar 96 14:05:35 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id OAA32320 for ; Mon, 18 Mar 1996 14:48:50 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA27349; Mon, 18 Mar 1996 13:48:51 +0100 From: Peter Gerwinski Message-Id: <9603181248.AA27349@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Q: Is there a gpc/emx for emx09b already ? To: sad@utkux.utcc.utk.edu Date: Mon, 18 Mar 1996 13:48:50 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: <9603170113.AA25535@utkux4.utcc.utk.edu> from "sad@utkux.utcc.utk.edu" at Mar 16, 96 08:13:08 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hi, all, hi Stefan! > GPC doesn't like me anymore, though. It compiles, but linking doesn't seem to > work, I get stuff like: > rts-file.c:221 (e:/bin/emx/lib/gpc.a(rts-file.o)): Undefined symbol _write > refer enced from text segment > and lots of it. I think I know this error ... I would guess that this comes from the fact that GPC does not only need the gpclib.a library but also gcclib.a. With Linux, I remember a similar problem arising from the installation of a new GCC-2.7.x C compiler and a conflict between a.out and elf versions of the libgcc.a library. We have solved it by installing a version of libgcc.a from GCC-2.6.3 in the lib path. > Interesting enough, gpc --version reports %PROG2%, > so this may serve as version indication: > rwxa-- 161799 Dec 13 00:39 e:/bin/emx/bin/gpc.exe* I get the same version %PROG2%. Strange. I will have to look for this error, too, but it seems to be an independend one. > but more interesting (and temporary relief!) is, that > gpc -c test.pas > gcc test.o -lgpc > does produce a working executable. Again: strange. I have one idea: Perhaps your version of gcc can produce a.out as well as elf output files, and gcc knows the option to tell the linker the difference, while gpc doesn't. Well, try to install the old C compiler; if this solves the problem I think we know the origin of the error. In case you only changed the EMX version and did not touch the C compiler, we are *really* in trouble. I think all these problems will disappear as soon as we will have a 2.7.x version of GPC. (But this is not my job. :-) Another suggestion would be to make GPC independend of the C runtime library, but include the required stuff into gpclib.a. See you, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Sun Mar 17 06:29:59 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA06229; Sun, 17 Mar 1996 06:29:58 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA11715; Sun, 17 Mar 96 06:30:12 CET Received: from sager.umd.edu (lotu@rac4.wam.umd.edu [128.8.70.120]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id HAA12193 for ; Sun, 17 Mar 1996 07:23:39 +0200 (EET) From: lotu@wam.umd.edu Received: (from cabal@localhost) by sager.umd.edu (8.6.12/8.6.9) id AAA00591; Sun, 17 Mar 1996 00:22:13 -0500 Date: Sun, 17 Mar 1996 00:22:11 -0500 (EST) X-Sender: cabal@sager.umd.edu To: gpc@hut.fi Subject: Q: How do you use UNITs in TurboGPC? Plus general comments .... Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I just downloaded the precompiled ELF binary version of "Turbo" GPC for Linux. I've been playing around with it for the past few minutes, but I can't seem to be able to figure out how to make and use Borland Pascal UNITs. To try it out, I made a simple program (test1.p) that called the procedure "Intro" which was in another unit (unit1.p). I first compiled the unit (thinking that gpc doesn't have a built-in make like BPC/TPC does) with the following command line: "gpc -c unit1.p". I then proceeded to compile and link test1.p -- but as I expected it didn't work. I get the message: "No exported interface matching 'Unit1'' "undeclared indentifier 'Intro' .....' I sort of expected this to happen 'cause how would gpc know about unit1.p? I'm obviously doing something wrong here. Can somebody please clue me in? Thanks! And on a seperate, but related note .... How goes the work on "Turbo" GPC? How about GPC in general? (as far as getting full Extended Pascal compliance is concerned). Copies of the ISO Pascal and Extended Pascal standards are available off the 'net courtesy of John Reagan, if anybody is interested. He also said that he was gonna put the new Object Pascal standard up for ftping as well ... so perhaps Object Pascal can be incorporated into GPC ... shouldn't be too hard now ... with "Borland Pascal with Objects" already in place. =============================================================================== Arcadio Alivio Sincero, Jr. Sophomore, Computer Science Major at the University of Maryland at College Park Amateur competitive bodybuilder Email: lotu@wam.umd.edu, WWW: "D.A.R.E. .... to keep cops of donuts." From gpc-request@santra.hut.fi Mon Mar 18 14:45:51 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA07013; Mon, 18 Mar 1996 14:45:50 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA17120; Mon, 18 Mar 96 14:45:14 CET Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id PAA00627 for ; Mon, 18 Mar 1996 15:14:49 +0200 (EET) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA22345; Mon, 18 Mar 1996 14:13:03 +0100 From: Peter Gerwinski Message-Id: <9603181313.AA22345@rs1.Theo-Phys.Uni-Essen.DE> Subject: Re: Q: How do you use UNITs in TurboGPC? Plus general comments .... To: lotu@wam.umd.edu Date: Mon, 18 Mar 1996 14:13:02 +0100 (MEZ) Cc: gpc@hut.fi In-Reply-To: from "lotu@wam.umd.edu" at Mar 17, 96 00:22:11 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, Arcadio, hello, GPC-list! > I just downloaded the precompiled ELF binary version of "Turbo" GPC for > Linux. I've been playing around with it for the past few minutes, but I > can't seem to be able to figure out how to make and use Borland Pascal UNITs. If you are speaking of the binaries on kampi.hut.fi or ftp.uni-augsburg.de: those are a.out binaries, no elf binaries. If you really have found elf binaries, please tell the gpc-list where you got them from! > To try it out, I made a simple program (test1.p) that called the > procedure "Intro" which was in another unit (unit1.p). I first compiled > the unit (thinking that gpc doesn't have a built-in make like BPC/TPC > does) That's correct. :-( > with the following command line: "gpc -c unit1.p". I then > proceeded to compile and link test1.p -- but as I expected it didn't > work. I get the message: > "No exported interface matching 'Unit1'' > "undeclared indentifier 'Intro' .....' Unfortunately, that's correct, too. In the moment, Extended Pascal modules and Turbo Pascal units are not yet fully implemented. It is necessary to have at least the Interface module in the same source file as the calling program (or module). I have some ideas how to fix it, but this will take some time. Up to that day, I am using the following (ugly) construction: Assume a unit (or module) being in "mymodule.pas" and the program being in "myprogram.pas". Then I include "mymodule.pas" into "myprogram.pas" using the preprocessor: (*I MyModule *) #include "mymodule.pas" Program MyProgram; Program MyProgram; or uses uses MyModule; MyModule; ... ... As long as this is necessary, Extended Pascal modules have the advantage that the interface and implementation part are in two separated source files and it is sufficient to include the interface module, while Turbo Pascal units have to be recompiled each time the program is compiled, which is of course not the purpose of the unit concept. But since I am very incontent with this situation, there is hope that I will change it not too far away in the future. > How goes the work on "Turbo" GPC? In the moment, I am working on my Ph. D. thesis, so I don't have much time for working on GPC. But I promise that I will continue this work even more intensively, once I am Ph. D. (Doctor) which will be the case somewhere in the second half of 1996. > ... He also said that he was > gonna put the new Object Pascal standard up for ftping as well ... so > perhaps Object Pascal can be incorporated into GPC ... shouldn't be too > hard now ... with "Borland Pascal with Objects" already in place. Perhaps I will have a look at it. I am going to re-implement objects in complete to make them work better with the debugger and to make them compatible to C++ classes (which is *not* the case in the moment) inclu- ding multi-inheritance, which -- as far as I know -- has never been seen in Pascal up to now. And I think about implementing more features of the Pascal-SC standard which would make GPC *very* useful for scientific applications. But there is yet another branch of the GNU Pascal project I am working on: Did you look at my BO5 library? It should be in the same directory as the turbo-alpha stuff and includes a nice README.BO5 file. (Another nice place for it would be the contrib directory.) Try it! :-) Greetings, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: pege@mail.theo-phys.uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Mon Mar 18 20:42:19 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA32384; Mon, 18 Mar 1996 20:42:18 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA18180; Mon, 18 Mar 96 20:41:57 CET Received: from utkux4.utcc.utk.edu (UTKUX4.UTCC.UTK.EDU [128.169.76.11]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id VAA18327 for ; Mon, 18 Mar 1996 21:22:12 +0200 (EET) From: sad@utkux.utcc.utk.edu Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA18796; Mon, 18 Mar 1996 14:20:34 -0500 Message-Id: <9603181920.AA18796@utkux4.utcc.utk.edu> Subject: Re: Q: Is there a gpc/emx for emx09b already ? To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Mon, 18 Mar 1996 14:20:33 -0500 (EST) Cc: gpc@hut.fi In-Reply-To: <9603181248.AA27349@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Mar 18, 96 01:48:50 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, all, hi Peter! > > GPC doesn't like me anymore, though. It compiles, but linking doesn't seem to > > work, I get stuff like: > > rts-file.c:221 (e:/bin/emx/lib/gpc.a(rts-file.o)): Undefined symbol _write > > refer enced from text segment > > and lots of it. > > I think I know this error ... > > I would guess that this comes from the fact that GPC does not only need > the gpclib.a library but also gcclib.a. With Linux, I remember a similar > problem arising from the installation of a new GCC-2.7.x C compiler and > a conflict between a.out and elf versions of the libgcc.a library. We > have solved it by installing a version of libgcc.a from GCC-2.6.3 in the > lib path. I don't find it (libgcc.a). the closest I find is gcc.lib on my gcc 2.6.3 setup at work. I am not at home right now, so I can't check. > > but more interesting (and temporary relief!) is, that > > gpc -c test.pas > > gcc test.o -lgpc > > does produce a working executable. > > Again: strange. I have one idea: Perhaps your version of gcc can produce > a.out as well as elf output files, and gcc knows the option to tell the > linker the difference, while gpc doesn't. Well, try to install the old > C compiler; if this solves the problem I think we know the origin of the > error. Well, I have indeed had success with gcc 2.6.3, but not with 2.7.2 anymore. Being completely stupid I didn't just upgrade emx rts from 09a to 09b but did the wole works (2.6.3 -> 2.7.2) assuming that's a VERY GOOD THING. Maybe it wasn't. I'll restore my 2.6.3 and just put in the nwe emxrts tonight. Or, maybe I live with the separate link step until a 2.7.2 version is out? > I think all these problems will disappear as soon as we will have a 2.7.x > version of GPC. (But this is not my job. :-) Another suggestion would be > to make GPC independend of the C runtime library, but include the required > stuff into gpclib.a. Is this how g77 does it with f2c.lib? Oh -- by the way: What's the reasone for gpc/emx being >= 3 MB as opposed to 1.7 or so it was before? Is it the turbo stuff, or is it debug info that one could safely strip out? Cheers! Stefan (also Dipl. Phys.) PS: A last one: I see mail to gpc@hut.fi bouncing all the time. You too? From sad@utkux.utcc.utk.edu Tue Mar 19 13:34:49 1996 Received: from UTKUX4.UTCC.UTK.EDU by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA30308; Tue, 19 Mar 1996 13:34:21 +0100 Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA17957; Tue, 19 Mar 1996 07:33:05 -0500 From: sad@utkux.utcc.utk.edu Message-Id: <9603191233.AA17957@utkux4.utcc.utk.edu> Subject: Re: Q: Is there a gpc/emx for emx09b / gcc 2.7.2 To: pege@rs1.Theo-Phys.Uni-Essen.DE (Peter Gerwinski) Date: Tue, 19 Mar 1996 07:33:05 -0500 (EST) Cc: gpc@hut.fi In-Reply-To: <9603191036.AA05992@rs1.Theo-Phys.Uni-Essen.DE> from "Peter Gerwinski" at Mar 19, 96 11:36:07 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > Hi again! > > > I don't find it (libgcc.a). the closest I find is gcc.lib on > > my gcc 2.6.3 setup at work. I am not at home right now, > > so I can't check. > > That's it. Since DOS restricts file names to 8 letters, emx names > libraries gcc.* rather than libgcc.*. But I thought that the suffix > would be .a, not .lib, or there are both versions, denoting different > lib file formats (perhaps elf and a.out?). Hu? libgcc.* is still well within the DOS / FAT conventions, isn't it :-) But, anyway, I have both gcc.lib and gcc.a, one (*.lib) is, as I understand it, for linking with *.obj files using link386 and -Zomf, the other one (*.a) for the traditional a.out and emx format. > > > Well, I have indeed had success with gcc 2.6.3, but not with 2.7.2 anymore. > > Being completely stupid I didn't just upgrade emx rts from 09a to 09b but > > did the wole works (2.6.3 -> 2.7.2) assuming that's a VERY GOOD THING. > > Maybe it wasn't. I'll restore my 2.6.3 and just put in the nwe emxrts > > tonight. Or, maybe I live with the separate link step until a 2.7.2 version > > is out? > > I'm afraid these two alternatives are really the only solutions. Oh. (seeking for cleenex). > Let's hope that somebody will create GPC 2.7.x soon. Yes, yes. I really would do it if I just could (where are those cleenex, again?). However, I haven't even had success compiling gcc / gpc before, so I am less than optimistic. Anybody out there who'd really know what to do? > > > > I think all these problems will disappear as soon as we will have a 2.7.x > > > version of GPC. (But this is not my job. :-) > > Well, if there is no 2.7.x in 1997, I will do the job, because I also > do not like the situation as is. But I would prefer somebody else to > do this, so I can concentrate on the Borland stuff. 1997? (Cleenex alert again!) > > > > Another suggestion would be > > > to make GPC independend of the C runtime library, but include the required > > > stuff into gpclib.a. > > > > Is this how g77 does it with f2c.lib? > > I don't know but I could imagine. Does anybody know? > > > Oh -- by the way: What's the reasone for gpc/emx being >= 3 MB as opposed to > > 1.7 or so it was before? Is it the turbo stuff, or is it debug info that one > > could safely strip out? > > I think it's debug info. If so, I will strip it out in the next release of > binaries. So, could I just run strip against the binaries and they'd still work? > > > PS: A last one: I see mail to gpc@hut.fi bouncing all the time. You too? > > So do I. Does anybody know the address? > > So long, > > Peter ========================================================================== Stefan A. Deutscher, sad@utk.edu, (001)-423-[522-7845|974-7838|574-5897] home^ UTK^ ORNL^ ========================================================================== If there is software you'd like to have in a native version, visit the: OS/2 E-mail Campaign Page http://www.andrews.edu/~boyko/email.html -------------------------------------------------------------------------- From gpc-request@santra.hut.fi Thu Mar 21 07:47:58 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA07042; Thu, 21 Mar 1996 07:47:58 +0100 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA28722; Thu, 21 Mar 96 07:48:28 CET Received: from utkux4.utcc.utk.edu (UTKUX4.UTCC.UTK.EDU [128.169.76.11]) by santra.hut.fi (8.7.3/8.7.3) with SMTP id IAA20362; Thu, 21 Mar 1996 08:35:01 +0200 (EET) From: sad@utkux.utcc.utk.edu Received: by utkux4.utcc.utk.edu (5.x/2.7c-UTK) id AA21528; Thu, 21 Mar 1996 01:33:31 -0500 Message-Id: <9603210633.AA21528@utkux4.utcc.utk.edu> Subject: Re: Q: Is there a gpc/emx for emx09b / gcc 2.7.2 To: Jukka.Virtanen@hut.fi Date: Thu, 21 Mar 1996 01:33:31 -0500 (EST) Cc: pege@rs1.Theo-Phys.Uni-Essen.DE, emx@iaehv.nl (emx-list), gpc@hut.fi In-Reply-To: from "Jukka Virtanen" at Mar 19, 96 05:20:34 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Jukka, hi Peter, hi world (in that order :->), the post by Kevin Foss from the emx mailing list got me to experiment a bit more, and as it happens, with the following explicit linker statements at least my simple `Hallo world' programme is back to life: gpc test.pas -lgpc -lc_alias So, with this the binaries of the emx/gpc built by Peter Gerwinski for/with emx09a/gcc2.6.3 can be used under emx09b/gcc2.7.2 just fine. That is a minor adjustment to a properly structured makefile and much nicer than gpc -c test.pas gcc test.o which also worked. Late night cheers! Stefan ========================================================================== Stefan A. Deutscher, sad@utk.edu, (001)-423-[522-7845|974-7838|574-5897] home^ UTK^ ORNL^ ========================================================================== If there is software you'd like to have in a native version, visit the: OS/2 E-mail Campaign Page http://www.andrews.edu/~boyko/email.html -------------------------------------------------------------------------- From gpc-request@santra.hut.fi Sat May 4 12:46:59 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA25218; Sat, 4 May 1996 12:46:58 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA27163; Sat, 4 May 96 12:46:46 CEST Received: from rs1.Theo-Phys.Uni-Essen.DE (rs1.theo-phys.uni-essen.de [132.252.254.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA14722 for ; Sat, 4 May 1996 13:32:48 +0300 (EET DST) Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA04966; Sat, 4 May 1996 12:31:14 +0200 From: Peter Gerwinski Message-Id: <9605041031.AA04966@rs1.Theo-Phys.Uni-Essen.DE> Subject: BO5 for Linux: bug report and workaround To: chourot@houka.enitiaa-nantes.fr (jean-marc chourot) Date: Sat, 4 May 1996 12:31:13 +0100 (MESZ) Cc: gpc@hut.fi In-Reply-To: <199604250950.KAA00161@houka.enitiaa-nantes.fr> from "jean-marc chourot" at Apr 25, 96 10:50:03 am X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO Hello, everybody! I was reported a bug in the BO5 screen drivers for Linux console (something like a CRT for GPC): on some machines the program stops with a runtime error "cannot access video memory", even if compiling and executing as root. To work around, use the TERMCAP version instead; the only visible differences are that you (1) have to specify the termcap library when compiling: gpc -I /usr/src/bo5 -D TERMCAP hallo.pas -ltermcap -o hallo and that (2) you have to set the CL_COLOR environment variable in order to get colors: export CL_COLOR=YES The next version will fix this bug (I will probably rewrite the Linux drivers in complete). Yours, Peter From gpc-request@santra.hut.fi Mon May 20 15:13:27 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA26704; Mon, 20 May 1996 15:13:26 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA08601; Mon, 20 May 96 15:13:20 CEST Received: from student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id PAA18426 for ; Mon, 20 May 1996 15:49:58 +0300 (EET DST) Received: from [130.89.179.49] (pc049.pczaalciv.utwente.nl) by student.utwente.nl with SMTP id AA06552 (5.67b/IDA-1.5 for ); Mon, 20 May 1996 14:49:57 +0200 Date: Mon, 20 May 96 14:55:28 CST From: "J.J. van der Heijden" Message-Id: <65578.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 X-Popmail-Charset: English To: gpc@hut.fi Subject: new binaries uploaded Status: RO Hello all, Today I uploaded a couple of new gpc-binaries to ftp://kampi.hut.fi/jtv/incoming. Hopefully, Juki will soon move them to an appropriate location. All of these are based on the public (2.6.3) snapshot of gpc. "turbo" flavours are based on Peter Gerwinski's "turbo-alpha" sources. The files are: gpc-1.1p2.linux.tar.gz turbo-1.1.linux.tar.gz Linux (ELF) gpc binary. I had to do some patching to gcc because gcc-2.6.3 ELF support was experimental and incompatible with the current (stable) state of ELF. Creates ELF executables. I think I uploaded these to sunsite.unc.edu (/pub/Linux/devel/lang/pascal) some time ago, although the "turbo" may have been version 1.0 Binaries were built on a late 1.3.x kernel and require libc-5.2.18 gpc112b.zip turbo11b.zip GPC binaries that fit into a djgpp (V2) distribution. djgpp is the "official" GCC release for MS-DOS, it should not be confused with Peter's EMX binaries, although they do roughly the same thing. Again, some patching to gcc because djgpp was v1.12 for gcc-2.6.3 and v2 for 2.7.2. gpc-1.1p2.cygwin32-beta14.zip turbo-1.1.cygwin32-beta14.zip GPC binaries that work ONLY with the current (beta14) release of the cygwin32 project. (Every new release seems to break compatibility with the previous one). The cygwin32 project is porting GNU software to Windows95 and NT (ix86 & ppc). This gpc creates PE/i386 executables. This is a work in progress: the compiler is restricted to console applications because it cannot access the Win32 API. The Win32 API requires a different way of stack management from the compiler (subroutine cleans stack), the rest of the world, including gpc, uses the C-style method (caller cleans stack). Hopefully, I can deal with this problem before gpc-1.2 is released, but I'm still interested in your experiences with this baby. More info on cygwin32 is available at: ftp://ftp.cygnus.com/pub/gnu-win32 I also have beta12 and beta13 win32 binaries around, but I don't think anybody is using b12 or 13 anymore so I didn't upload them. Last (but not least?), I have some Linux/ELF based gpc-crosscompilers They can be usefull if you want to develop from a single source tree, but support multiple target platforms. If anybody is interested in this stuff, he/she should contact me. You also need extra cross-binutils to make this work. I have linux->linuxaout, linux->djgpp & linux->win32 available. Happy hacking, J.J. van der Heijden From pege Tue Jun 4 15:50:19 1996 Subject: Units To: gpc@hut.fi Date: Tue, 4 Jun 1996 15:50:19 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1501 Status: RO Hello, everybody! A known bug in GPC is that it does not automatically read Unit (or Module) interfaces when a Unit is used (or a Module is imported). For that reason, something like gpc -c myunit.pas gpc myprog.pas myunit.o -o myprog does only work when the main program (myprog.pas) (*$includes *) or #includes the Module interface. This is bearable with Extended Pascal where you can have the interface in a separate file; with Borland style Units you include the whole Unit, so it is recompiled each time. However, there is a workaround which is just another bug in GPC:-) A Borland style Unit with an empty implementation part but declaring some procedures in the interface part is not rejected by the compiler, only by the linker. Therefore, we can use the following trick: ---- file: myprog.pas ---- (*$I MyUnit *) (* Include the *whole* file MyUnit.pas *) Program MyProg; uses MyUnit; begin Hello; end. ---- file: myunit.pas ---- Unit MyUnit; Interface Procedure Hello; Implementation (*$ifdef IMPLEMENTATION *) (* suppress re-compilation of implementation part *) Procedure Hello; begin (* Hello *) writeln ( 'Hello!' ); end (* Hello *); (*$endif *) end. Now you can compile the Unit separately with gpc -D IMPLEMENTATION -c myunit.pas and then link it when compiling the main program via gpc myprog.pas myunit.o -o myprog Okay? Try it. Good luck! Peter From gpc-request@santra.hut.fi Thu Jun 13 10:38:37 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA29670; Thu, 13 Jun 1996 10:38:36 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA22634; Thu, 13 Jun 96 10:38:27 CEST Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA10491 for ; Thu, 13 Jun 1996 11:07:25 +0300 (EET DST) Received: from student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by kampi.hut.fi (8.6.11/8.6.7) with SMTP id LAA05274 for ; Thu, 13 Jun 1996 11:07:16 +0300 Received: from slp06164.slip.utwente.nl by student.utwente.nl with SMTP id AA03036 (5.67b/IDA-1.5 for ); Thu, 13 Jun 1996 10:07:13 +0200 Date: Thu, 13 Jun 1996 10:07:13 +0200 Message-Id: <199606130807.AA03036@student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@kampi.hut.fi From: JanJaap van der Heijden Subject: Re: GNU pascal compiler uploaded Status: RO Look what I found in the mail this morning: >Date: Wed, 12 Jun 1996 22:25:39 -0400 >From: dj@delorie.com (DJ Delorie) >To: j.j.vanderheijden@student.utwente.nl >Subject: Re: GNU pascal compiler uploaded > > >I finally got around to moving the GPC files to the outgoing simtelnet >directory. They'll be in the v2gnu directory. > >-rw-r--r-- 1 dj user 291 Apr 26 08:03 gpc112b.txt >-rw-r--r-- 1 dj user 685430 May 6 07:10 gpc112b.zip >-rw-r--r-- 1 dj user 8621302 May 6 07:39 gpc112s.zip >-rw-r--r-- 1 dj user 372 Apr 26 08:06 gpt112b.txt >-rw-r--r-- 1 dj user 698287 May 6 07:41 gpt112b.zip > For those of you who don't know: this is about the DOS (djgpp) GPC. djgpp is very very popular, and Simtel must be mirrored in just about every country in the world. This must generate some interest for GPC... /janjaap -- Science is what I'm doing when I don't know what I'm doing Werner von Braun From gpc-request@santra.hut.fi Fri Jun 21 00:20:54 1996 Received: from rt07.Theo-Phys.Uni-Essen.DE by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA20369; Fri, 21 Jun 1996 00:20:53 +0200 Received: by rt07.Theo-Phys.Uni-Essen.DE (AIX 2.1 2/4.04) id AA13543; Fri, 21 Jun 96 00:20:50 CEST Received: from eeyore.lv-hrc.nevada.edu (root@eeyore.lv-hrc.nevada.edu [131.216.27.16]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA20794 for ; Fri, 21 Jun 1996 01:09:41 +0300 (EET DST) Received: from scooby.lv-hrc.nevada.edu (scooby.lv-hrc.nevada.edu [131.216.27.8]) by eeyore.lv-hrc.nevada.edu (8.6.12/8.6.9) with SMTP id PAA30374 for ; Thu, 20 Jun 1996 15:09:53 -0700 Message-Id: <199606202209.PAA30374@eeyore.lv-hrc.nevada.edu> From: "Harry W. Reed" To: "gpc@hut.fi" Date: Thu, 20 Jun 96 15:10:52 Reply-To: "Harry W. Reed" Priority: Normal X-Mailer: PMMail 1.5 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Add me to the GPC list please Status: RO Hi, Please add me to the GPC mailing list. Thanks, Harry Reed doon@hec.nevada.edu This Message Was Sent With An UNREGISTERED Version Of PMMail. Please Encourage Its Author To Register Their Copy Of PMMail. For More Information About PMMail And SouthSide Software's Other Products, Contact http://www.southsoft.com. From pege@rs1.Theo-Phys.Uni-Essen.DE Sun Jul 7 16:37:28 1996 Return-Path: pege@rs1.Theo-Phys.Uni-Essen.DE Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA15044 for ; Sun, 7 Jul 1996 16:37:27 +0200 Received: from iss_server.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA29220; Sun, 7 Jul 1996 16:37:37 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA64483; Sun, 7 Jul 1996 16:34:48 +0200 Received: from rs1.theo-phys.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46110; Sun, 7 Jul 1996 16:37:36 +0200 Received: by rs1.Theo-Phys.Uni-Essen.DE (AIX 3.2/UCB 5.64/4.03) id AA18638; Sun, 7 Jul 1996 16:38:14 +0200 From: Peter Gerwinski Message-Id: <9607071438.AA18638@rs1.Theo-Phys.Uni-Essen.DE> Subject: NewsGroup announcement (from rs1) To: peter.gerwinski@aixrs1.hrz.uni-essen.de Date: Sun, 7 Jul 1996 16:38:14 +0100 (MESZ) X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 4072 Status: RO According to Peter Gerwinski: >From gpc-request@santra.hut.fi Sun Jul 7 02:54:19 1996 From: Peter Gerwinski Message-Id: <199607070038.CAA14344@agnes.dida.physik.uni-essen.de> Subject: NewsGroup announcement To: gpc@hut.fi Date: Sun, 7 Jul 1996 02:38:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, folks! Did somebody already announce GPC 2.6.3 with Borland extensions to the NewsGroups? If not, I am planning to crosspost the following to comp.lang.pascal.misc, comp.lang.pascal.borland, and comp.lang.pascal.iso-ansi: 8<------------------------------------------------------------------------------ NewsGroups: comp.lang.pascal.misc,comp.lang.pascal.borland,comp.lang.pascal.ansi-iso Followup-To: comp.lang.pascal.misc This is the announcement of version 1.1-2.6.3 of GNU Pascal (The announcement is somehow late since the actual release was on 19. December 1995. This won't happen again with the release of the next version.) -------- GNU Pascal is, as the name says, the Pascal compiler from the GNU family. This means: - 32 bit compiler, no limits, highly optimizing - runs on most operating systems (including DOS, OS/2, Linux, or any other UNIX) - FreeWare according to the GNU General Public License - compatible to other GNU tools such as GNU C and GNU debugger The compiler accepts the following language standards: - ISO 7185 Standard Pascal - ISO 10206 Extended Pascal (90%) - Borland Pascal (80%) Some highlights: - from Extended Pascal: complex numbers, initialized variables, structured function return values, modules - from Borland Pascal: inc, dec, shl, shr, absolute variables, units, objects - GNU extensions: min, max, (PXSC-style) user-definable operators -------- The source for the ISO compiler (and more information) is available from ftp://kampi.hut.fi/jtv/gnu-pascal Additional source for Borland Pascal compatible (and other) extensions is at ftp://kampi.hut.fi/jtv/gnu-pascal/turbo-alpha Binaries for DOS and OS/2 (with the EMX extender) and for Linux (a.out) are in ftp://kampi.hut.fi/jtv/gnu-pascal/binary Binaries for DOS (with the GO32 extender) and for Linux (elf) are in ftp://kampi.hut.fi/jtv/incoming ;-) If you want to join the gpc mailing list, write to gpc-request@hut.fi. The address of the list is gpc@hut.fi. -------- Peter Gerwinski 8<------------------------------------------------------------------------------ Is this okay, or too long, or whatever? If you have any improvements, please let me know. Bug reports for my English are also most welcome. :-) Yours, Peter ******************* NEW E-MAIL ADDRESS! ******************* -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- ******************************** ACHTUNG: Neue e-mail-Adresse! Ab dem 22. Juni 1996 bitte an peter.gerwinski@uni-essen.de schreiben. ******************************** ATTENTION: New e-mail address! >From 22. June 1996 on please write to peter.gerwinski@uni-essen.de ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Sun Jul 7 19:01:19 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA16087 for ; Sun, 7 Jul 1996 19:01:18 +0200 Received: from iss_server.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48188; Sun, 7 Jul 1996 19:01:28 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA69103; Sun, 7 Jul 1996 18:58:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59954; Sun, 7 Jul 1996 19:01:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA16057 for ; Sun, 7 Jul 1996 19:51:30 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA15851 for gpc@hut.fi; Sun, 7 Jul 1996 18:50:41 +0200 From: Peter Gerwinski Message-Id: <199607071650.SAA15851@agnes.dida.physik.uni-essen.de> Subject: Programmers wanted: CRT, Graph, etc. for GNU Pascal To: gpc@hut.fi Date: Sun, 7 Jul 1996 18:50:40 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! I am in contact with Florian Klaempfl, the author of FPK Pascal, another free 32-bit Pascal compiler. Florian has got free sources for Borland compatible Units like SYSTEM, CRT, PRINTER, and GRAPH for FPK Pascal which cry for being ported to GNU Pascal. This should not be too difficult at least for the DOS platform because FPK Pascal uses the same assembler syntax as GNU Pascal, and both compilers can run with the GO32 DOS extender. (GNU Pascal for GO32 can be downloaded as ftp://kampi.hut.fi/jtv/incoming/turbo11b.zip - see the recent mail by Jan Jaap. :-) Anybody wants to do the job? Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From 100120.3121@CompuServe.COM Sat Jul 20 14:01:27 1996 Return-Path: 100120.3121@CompuServe.COM Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id OAA10198 for ; Sat, 20 Jul 1996 14:01:20 +0200 Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id IAA27862; Sat, 20 Jul 1996 08:03:05 -0400 Date: 20 Jul 96 08:00:36 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Cc: Peter Gerwinski Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal Message-ID: <960720120035_100120.3121_EHQ98-1@CompuServe.COM> Status: RO First of all, does anyone know if there is a gpc archive? I went on holiday with my computer stuck and my compuserve mailbox overflooded (it seems to have a max of 100msgs). I miss about 1 week. > Florian has got free sources > for Borland compatible Units like SYSTEM, CRT, PRINTER, and GRAPH > for FPK Pascal which cry for being ported to GNU Pascal. > This should not be too difficult at least for the DOS platform because > FPK Pascal uses the same assembler syntax as GNU Pascal, and both > compilers can run with the GO32 DOS extender. The point of having an extended pascal compiler is being portable, at least that's the goal. Assembler and Dos are not the way to go. The point of having a System, Crt, Printer of Graph unit is entirely uninteresting if it is not portable except if you want to port Dos Borland Pascal programs to Extended Pascal. Why should anyone want to do this? I assume everyone is programming for Windows 95/Windows NT or Unix. Are programmers really running Dos today?? Quite a few calls in System or Crt do simply not apply in non-Dos environments. A portable Printer library?? The calls from System that are portable can for 90% be written in plain Extended Pa From gpc-request@santra.hut.fi Mon Jul 22 20:38:06 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA11678 for ; Mon, 22 Jul 1996 20:38:06 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45060; Mon, 22 Jul 1996 20:39:02 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA100797; Mon, 22 Jul 1996 20:35:50 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31998; Mon, 22 Jul 1996 20:39:00 +0200 Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id VAA03590 for ; Mon, 22 Jul 1996 21:27:09 +0300 (EET DST) Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id OAA07810; Mon, 22 Jul 1996 14:26:13 -0400 Date: 22 Jul 96 14:24:29 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal Message-Id: <960722182429_100120.3121_EHQ85-1@CompuServe.COM> Status: RO Hay guys, Seems part of my message was lost, here the remaing part: > The calls from System that are portable can for 90% be written in plain Extended > Pa The calls from System that are portable can for 90% be written in plain Extended Pascal. We should do better by following existing standards and provide EP interfaces for that. Groetjes, Berend. (-: From gpc-request@santra.hut.fi Tue Jul 23 16:38:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA12086 for ; Tue, 23 Jul 1996 16:38:17 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83730; Tue, 23 Jul 1996 16:38:55 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA94034; Tue, 23 Jul 1996 16:35:42 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85004; Tue, 23 Jul 1996 16:38:53 +0200 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA16722 for ; Tue, 23 Jul 1996 17:21:13 +0300 (EET DST) Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by kampi.hut.fi (8.6.11/8.6.7) with SMTP id RAA04593 for ; Tue, 23 Jul 1996 17:21:05 +0300 Received: from [130.89.179.51] (pc051.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA02633 (5.67b/IDA-1.5 for ); Tue, 23 Jul 1996 16:21:03 +0200 Date: Tue, 23 Jul 96 16:28:00 CST From: "J.J. van der Heijden" Message-Id: <70632.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 X-Popmail-Charset: English To: gpc@kampi.hut.fi Subject: Re: GPC: "how to contribute" file -- job list Status: RO On Fri, 5 Jul 1996 11:01:03 +0200 (MET DST), Peter Gerwinski wrote: [snip] > > List of jobs > ------------ > [snip] > DJ version (DOS) JanJaap works I came across a new DJGPP app called "rhide" It's a Borland-clone IDE that works with djgpp (C & C++) I'll see if I can hack it to work with GPC. Would make a neat Turbo Pascal replacement ;) > > Installation instructions Larry ? > Documentation Larry ? > Larry, if you're there: I rewrote much of the installation notes. Also, I took a "Using and porting GCC" manual, did a "search GCC -- replace with GPC" action, TeXi-fied much of the existing readme's and put it all together. Let me know how to send this stuff to you. > > Run time system Juki works I have preliminary, new "autoconf" scripts for RTS. Should reduce configuration to "configure ; make". Handles all CFLAGS, platform dependant includes etc. I'll see if I can do something simular for GPC itself. Some other RTS related remarks: *) GNU is going international. How about adding localization to RTS? Won't work if you're not on un*x, but can be buildtime selectable (flag to autoconf script) *) How 'bout RTS as an ELF shared library? *) Documentation again: RTS needs documentation. I looked at the Cygnus and DJGPP C libraries and they use Texinfo fragments in the source, extract it with some utility to one big texinfo file. That way it's easy to keep documentation up to date. > Replacement for (parts of) CRT Peter beta (BO5) > Replacement for Graph Peter planned > Replacement for Turbo Vision Peter planned > Now, if somebody would port TVision to un*x (use termcap / info instead of direct screen writes) it would probably be not too much work to port this RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan of emacs) /janjaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Tue Jul 23 17:49:05 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA12198 for ; Tue, 23 Jul 1996 17:49:04 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62150; Tue, 23 Jul 1996 17:49:41 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA74454; Tue, 23 Jul 1996 17:46:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58044; Tue, 23 Jul 1996 17:49:39 +0200 Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA17522 for ; Tue, 23 Jul 1996 18:39:27 +0300 (EET DST) Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id LAA07071; Tue, 23 Jul 1996 11:38:55 -0400 Date: 23 Jul 96 11:34:22 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Cc: "\"J.J. van der Heijden\"" Subject: Re: GPC: "how to contribute" file -- job list Message-Id: <960723153421_100120.3121_EHQ58-5@CompuServe.COM> Status: RO > Now, if somebody would port TVision to un*x (use termcap / info instead of > direct screen writes) it would probably be not too much work to port this > RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan > of emacs) I would do that when the Extended Pascal port is completed and the object extensions are added (I think it's not wise to use Borland style objects). Last time I really looked at gpc (beginning 1995) it missed simply too much. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Jul 23 17:53:56 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA12218 for ; Tue, 23 Jul 1996 17:53:56 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA14892; Tue, 23 Jul 1996 17:54:33 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA78196; Tue, 23 Jul 1996 17:51:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56864; Tue, 23 Jul 1996 17:54:31 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA17468 for ; Tue, 23 Jul 1996 18:31:57 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA12136 for gpc@hut.fi; Tue, 23 Jul 1996 17:30:43 +0200 From: Peter Gerwinski Message-Id: <199607231530.RAA12136@agnes.dida.physik.uni-essen.de> Subject: The purpose of GNU Pascal To: gpc@hut.fi Date: Tue, 23 Jul 1996 17:30:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, I think it's time to discuss about the purpose of GNU Pascal as stated by Juki (jtv) in GPC.GUIDE. More concrete: I disagree with some points and I would suggest to modify them. jtv> The purpose of the GNU Pascal project is to produce a jtv> Pascal compiler (called GNU Pascal or gpc) which jtv> - may be distributed under normal GNU license conditions jtv> - can genarate code and run on any computer for which the GNU C jtv> compiler can genarate code and run. Concerning the points above, I agree in complete. jtv> - supports both the Pascal standard and the Extended Pascal jtv> standard as defined by ISO and ANSI and IEEE. jtv> (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE770X3.160-1989) It is okay and desireable to support these standards, but I wouldn't agree to obey the standards "come what may". As far as I would guess, 80% of all Pascal programmers are working with Borland Pascal or Delphi or a compatible system like Virtual Pascal, Speed Pascal, FPK Pascal, GNU Pascal or one of those ShareWare Pascal compilers written for the DOS platform. On the other side I know of only two Extended Pascal compilers: Prospero's Extended Pascal and GNU Pascal. So I call in question that Extended Pascal is more portable than Borland Pascal. Furthermore, I could not write my real-world programs just with Extended Pascal; I need, for example, bit shift operators, GetMem, FreeMem, and Objects. I think the way to go is to collect the good features of all the existing standards, ISO 7185, ISO 10206, Borland Pascal, Object Pascal, Pascal-SC, and integrate them in one powerful compiler which will set up the next standard. This is necessary, in my opinion, because *none* of the standards mentioned above is what I would call an "ideal" Pascal compiler by itself. I would be satisfied only with the *combination* of them. Apart from some bugs, the current version 1.1-2.6.3 of GNU Pascal is the best Pascal compiler I have ever seen, and we are not too far from making it even better. jtv> One reason for this is the desire to promote the use of Extended jtv> Pascal, which combines the clarity of Pascal with powerful jtv> tools (e.g. modules and string manipulation) suitable for real-life jtv> programming. Pascal was originally designed for teaching. jtv> Extended Pascal provides a smooth way to proceed to challenging jtv> programming tasks without learning a completely different language. The same holds for Borland Pascal. (In my opinion, the goals stated above are even better realized in Borland Pascal, but that's a matter of taste.) And there are other standards around, for example Pascal-SC (also named PXSC -- Pascal eXtensions for Scientific Calculations) with very useful features such as user-definable operators and procedure overloading. I would suggest to fix the goal of combining the clarity of Pascal with powerful real-life tools -- independently of a concrete standard. So my suggestion for the "Purpose" section of GPC.GUIDE would begin with: The purpose of the GNU Pascal project is to produce a Pascal compiler (called GNU Pascal or gpc) which - combines the clarity of Pascal with powerful tools suitable for real-life programming, - supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989), - supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, - may be distributed under normal GNU license conditions, - can generate code and run on any computer for which the GNU C compiler can generate code and run. Pascal was originally designed for teaching. GNU Pascal provides a smooth way to proceed to challenging programming tasks without learning a completely different language. jtv> GNU Pascal compiler is part of the GNU Compiler family jtv> combining a language independent part of the GNU Compiler with jtv> a Pascal specific front end. jtv> jtv> Other compilers of the family currently include compilers for jtv> the C, C++ and Objective C languages. Since this is true, we should compare the purpose of GNU Pascal with that of GNU C. In the section "Warning Options" of the GNU C info documentation (gcc), in the context of the "--pedantic" option which tells GCC to follow the ANSI standard as strictly as possible, we can find the following: gcc> A feature to report any failure to conform to ANSI C might be gcc> useful in some instances, but would require considerable gcc> additional work and would be quite different from `-pedantic'. We gcc> recommend, rather, that users take advantage of the extensions of gcc> GNU C and disregard the limitations of other compilers. Aside gcc> from certain supercomputers and obsolete small machines, there is gcc> less and less reason ever to use any other C compiler other than gcc> for bootstrapping GNU CC. In the same spirit I would suggest: Implement all reasonable extensions into GNU Pascal, encourage their use, and forget about the limitations of other compilers (such as UCSD or Borland Pascal) or standard definitions (such as Standard Pascal or Extended Pascal). jtv> ABOUT THE PASCAL AND EXTENDED PASCAL LANGUAGES jtv> ---------------------------------------------- jtv> jtv> [...] jtv> jtv> Extended Pascal is a standardized language which contains so jtv> significant extensions to Pascal that it is best regarded as jtv> a new language. It is currently not very well known, and computer jtv> vendors do not seem to be eager to provide compilers for it. jtv> Thus, there is social need for GNU Pascal supporting Extended jtv> Pascal. It is okay to support Extended Pascal (why not?), but in my opinion, Extended Pascal is not clear and powerful enough to serve as "the new Pascal standard", so programmers are not motivated to switch from Borland Pascal to Extended Pascal. I think, this is the reason why computer vendors do not provide Extended Pascal compilers. As far as I have understood, the committee which defined the standard knew Borland Pascal, so I simply cannot understand how they could define a standard which lacks some important features of existing compilers, for example the bit-shift operators or dynamical memory allocation with user-specified size (GetMem and FreeMem). There is social need for a *new* standard which integrates ISO 10206 Extended Pascal and other standards such as Borland Pascal and Pascal-SC. With GNU Pascal, we can *create* that new standard. For those who like standards: I suggest to implement compiler switches into GNU Pascal which force GPC to behave (inasmuch as possible) like a compiler of the specific standard, for example --standard-pascal for an ISO 7185 Standard Pascal compiler --extended-pascal for an ISO 10206 Extended Pascal compiler (which rejects Borland extensions) --borland-pascal for emulating the Borland Pascal compiler (which rejects Extended Pascal extensions) --pascal-sc for emulating a Pascal-SC compiler (not yet possible) but the default should be to accept *all* of the Pascal dialects and any combination of them, for example a Borland-style Unit which deals with Extended Pascal complex numbers and exports a Pascal-SC-style operator for matrix multiplication. (You actually can write such a thing with the current version of GNU Pascal!) jtv> Please refer to the document borland2ep.doc to find out more about jtv> the differences between Turbo Pascal and Extended Pascal. jtv> That document is written by Berend de Boer. I wrote another document about the same topic. It is somehow obsolete since GNU Pascal now understands most of the Borland Pascal language, but nevertheless you can find it at ftp://agnes.dida.physik.uni-essen.de/gpc-2.6.3/bp2ep.doc I am looking forward for reactions. Yours, Peter From gpc-request@santra.hut.fi Tue Jul 23 17:52:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA12214 for ; Tue, 23 Jul 1996 17:52:17 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56890; Tue, 23 Jul 1996 17:52:54 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA115956; Tue, 23 Jul 1996 17:49:41 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39982; Tue, 23 Jul 1996 17:52:50 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA17377 for ; Tue, 23 Jul 1996 18:31:12 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA12126 for gpc@hut.fi; Tue, 23 Jul 1996 17:29:57 +0200 From: Peter Gerwinski Message-Id: <199607231529.RAA12126@agnes.dida.physik.uni-essen.de> Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal To: gpc@hut.fi Date: Tue, 23 Jul 1996 17:29:57 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Berend de Boer wrote: > The point of having an extended pascal compiler > is being portable, at least that's the goal. I agree to the goal of being portable. But I don't think that we can reach this goal just by obeying the Extended Pascal standard. (More about this in a separate mail.) > Assembler and Dos are not the way to go. The point of having a > System, Crt, Printer of Graph unit is entirely uninteresting if it is not > portable except if you want to port Dos Borland Pascal programs to Extended > Pascal. I want to port DOS Borland programs to *GNU Pascal*, and I am sure that many people intend the same. System, Crt, Printer and Graph for GNU Pascal would be *highly interesting* for those programmers who are accustomed to Borland Pascal and think about changing to GNU Pascal (instead of changing to Delphi or C++) in the future. To have those Units on the DOS platform only would be a starting point -- portable versions would be preferred, of course. > Why should anyone want to do this? I assume everyone is programming for > Windows 95/Windows NT or Unix. Are programmers really running Dos today?? Yes, I am for example. More concrete, I am working in an OS/2 DOS box and in the Linux DOSemu (with Novell DOS 7). I do not intend to use Windows 95 or Windows NT, and it will take a long time to get my clients using UNIX (Linux). Up to that day, I will prefer writing good DOS programs to writing poor Windows programs (with a lot of special effects, but slow, uncomfortable, and unstable). In the long term, I intend to become completely platform independent with my BO5 library, i.e. my programs will run under Windows 95/NT, too, just be recompiling. But for the moment, I am stuck with DOS. > Quite a few calls in System or Crt do simply not apply in non-Dos > environments. There are really few of them, but since the source exists, I suggest that somebody ports *everything* to the DOS version of GPC, and we can make the "potentially portable" parts portable in a second stage. > A portable Printer library?? What's the problem? It would just be a Unit (Module) which "knows" the file name of the printer device for the actual operating system and opens a text file "lst", so the application program doesn't need to care about how the printer is named on the operating system. > The calls from System that are portable can for 90% be written in plain > Extended Pascal. However, it would be nice to have a compatibility Unit (Module) which simplifies the port of Borland Pascal programs to GNU Pascal. > We should do better by following existing standards and provide EP > interfaces for that. Borland's Units *are* an existing standard. There may be other standards, but I think these Units are very popular. Furthermore, we *have* the source for them, so I ask again: ******************************************************* We have free sources of Borland Units (CRT, Graph, ...) which cry for being ported to GNU Pascal. Anybody wants to do the job? ******************************************************* Greetings, Peter From gpc-request@santra.hut.fi Tue Jul 23 18:49:11 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA12325 for ; Tue, 23 Jul 1996 18:49:11 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57866; Tue, 23 Jul 1996 18:49:48 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA61010; Tue, 23 Jul 1996 18:46:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58884; Tue, 23 Jul 1996 18:49:46 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA18098 for ; Tue, 23 Jul 1996 19:35:51 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA12277 for gpc@hut.fi; Tue, 23 Jul 1996 18:34:37 +0200 From: Peter Gerwinski Message-Id: <199607231634.SAA12277@agnes.dida.physik.uni-essen.de> Subject: Turbo Vision, IDE To: gpc@hut.fi Date: Tue, 23 Jul 1996 18:34:37 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Jan Jaap van der Heijden wrote: > Now, if somebody would port TVision to un*x (use termcap / info instead of > direct screen writes) it would probably be not too much work to port this > RHIDE thing to unix. Then you have an IDE. (sorry guys, I'll never be a fan > of emacs) I am working on something similar to a port of Turbo Vision to UNIX and any other operating system I can access. The project is called BO5; version 0.0.1 was released on 19. December 1995. For more information about BO5 look at ftp://kampi.hut.fi/jtv/gnu-pascal/turbo-alpha/README.BO5. By the way: There is a Borland-style IDE for Linux called XWPE. Look at the Debian distribution of Linux in the subdirectory source/devel. Yours, Peter ******************************** ATTENTION: New e-mail address! ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Jul 23 18:47:38 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA12321 for ; Tue, 23 Jul 1996 18:47:38 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73616; Tue, 23 Jul 1996 18:48:15 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA73495; Tue, 23 Jul 1996 18:45:02 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76170; Tue, 23 Jul 1996 18:48:14 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA18092 for ; Tue, 23 Jul 1996 19:37:02 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA12286 for gpc@hut.fi; Tue, 23 Jul 1996 18:35:48 +0200 From: Peter Gerwinski Message-Id: <199607231635.SAA12286@agnes.dida.physik.uni-essen.de> Subject: Extended Pascal To: gpc@hut.fi Date: Tue, 23 Jul 1996 18:35:47 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Berend de Boer wrote: > I would do that when the Extended Pascal port is completed and the object > extensions are added (I think it's not wise to use Borland style objects). Why not? Borland style objects have some advantages with respect to those of Object Pascal (Delphi). Concerning portability, GNU Pascal itself is portable, and I don't know any Object Pascal compiler except Delphi. (I have heared about Object Pascal for the Apple Macintosh, but never seen it.) So there is no compiler around (except those of Borland) to preserve compatibility to. > Last time I really looked at gpc (beginning 1995) it missed simply too much. What is missing? If you publish a list, perhaps somebody would like to do the job of implementing it. Or do it by yourself -- it should be relatively easy since Borland style objects work in GNU Pascal. Yours, Peter ******************************** ATTENTION: New e-mail address! ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Tue Jul 23 22:22:56 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA12798 for ; Tue, 23 Jul 1996 22:22:55 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59900; Tue, 23 Jul 1996 22:23:31 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA123834; Tue, 23 Jul 1996 22:20:18 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82932; Tue, 23 Jul 1996 22:23:30 +0200 Received: from dub-img-5.compuserve.com (dub-img-5.compuserve.com [149.174.206.135]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA20114 for ; Tue, 23 Jul 1996 23:03:41 +0300 (EET DST) Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id QAA03265; Tue, 23 Jul 1996 16:02:34 -0400 Date: 23 Jul 96 16:01:00 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: Peter Gerwinski Cc: gpc Subject: Re: The purpose of GNU Pascal Message-Id: <960723200100_100120.3121_EHQ160-1@CompuServe.COM> Status: RO > Furthermore, I could not write my real-world programs > just with Extended Pascal; I need, for example, bit shift operators, GetMem, > FreeMem, and Objects. You don't need GetMem and FreeMem as I did show you :-) But you need the other two. > and integrate them in one powerful compiler which will set up the next standard. I certainly don't agree with this if the compiler does not have switches to accept only Extended Pascal or only ISO Pascal or only ... Programs conforming to the Extended Pascal will probably not only work in many different environments but also with many different compilers. I don't want to loose that feature/possibility. Extending a compiler with more features is not a problem, but IMO, one should complete the standard parts first. > It is okay to support Extended Pascal (why not?), but in my opinion, > Extended Pascal is not clear and powerful enough to serve as "the new > Pascal standard", so programmers are not motivated to switch from > Borland Pascal to Extended Pascal. I think, this is the reason why > computer vendors do not provide Extended Pascal compilers. Hmm, I don't think that Extended Pascal is not powerful enough. It's true that it does not contain everything one needs, but that's mainly due to the goal of creating a portable language. And the new object standard also rectififies some omissions. I can create everything I want in Extended Pascal programs with only a few routines accessing non-standard parts, mainly concerning bit-operators (you can do this with Extended Pascal, but it's a bit more tedious), and system call access (assembly). A compiler which accepts every Pascal standard and does everything would be nice of course. But there is quite some work to do. So I would like to add that we first focus on the ISO Pascal and Extended Pascal part. Even the ISO Pascal standard, according to Scott Moore (have email address if anyone wants it), needs much looking after. Don't overlook the Pascal standards boys (no girls here I assume). They do much more than you think, but different than Borland Pascal which has quite a C feeling and lost too much of it's real Pascal spirits. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Jul 23 22:19:42 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA12793 for ; Tue, 23 Jul 1996 22:19:42 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59716; Tue, 23 Jul 1996 22:20:17 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA60891; Tue, 23 Jul 1996 22:17:04 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50482; Tue, 23 Jul 1996 22:20:16 +0200 Received: from dub-img-5.compuserve.com (dub-img-5.compuserve.com [149.174.206.135]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA20021 for ; Tue, 23 Jul 1996 23:03:46 +0300 (EET DST) Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id QAA03302; Tue, 23 Jul 1996 16:02:40 -0400 Date: 23 Jul 96 16:01:10 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: Peter Gerwinski Cc: gpc Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal Message-Id: <960723200110_100120.3121_EHQ160-3@CompuServe.COM> Status: RO > There are really few of them, but since the source exists, I suggest > that somebody ports *everything* to the DOS version of GPC, and we can > make the "potentially portable" parts portable in a second stage. What use does it have when you already have a good Dos compiler, i.e. Borland Pascal? It fullfills all my needs for the Dos environment. Besides, what do you mean by 'porting', i.e. should do exactly the same with every quirk inherited or just similar enough? The system unit can be implemented easily, I've done already that for 90%. A few things you can't do like Inc, and some functions which have overloaded parameters (Assign, Close, ...). If similar is good enough, I suggest we define a POSIX interface first, starting from the one I wrote for Dos, and build the Dos unit on top of that. We can do the Crt unit in the same manner, building on top of the curses library. > We have free sources of Borland Units (CRT, Graph, ...) Note, you don't have the source of the Graph unit. >From my viewpoint, Borland Pascal does everything, so spending time for a Dos only solution is not a thing I want. And it is not necessary. And is gpc already for such projects? I see some problems with gpc as I know it: - no renaming, necessary to avoid clashing with c libraries. - qualifed imports available? - how to link with C libraries? You have the c; construct, but exactly how does it work? What does it do? Groetjes, Berend. From gpc-request@santra.hut.fi Wed Jul 24 10:17:41 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA13425 for ; Wed, 24 Jul 1996 10:17:41 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80486; Wed, 24 Jul 1996 10:18:06 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA59984; Wed, 24 Jul 1996 10:14:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57950; Wed, 24 Jul 1996 10:18:05 +0200 Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com [149.174.206.133]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA25970 for ; Wed, 24 Jul 1996 11:01:48 +0300 (EET DST) Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id EAA26939; Wed, 24 Jul 1996 04:01:06 -0400 Date: 24 Jul 96 04:00:13 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: Peter Gerwinski Cc: gpc Subject: Re: Extended Pascal Message-Id: <960724080012_100120.3121_EHQ37-4@CompuServe.COM> Status: RO >> Last time I really looked at gpc (beginning 1995) it missed simply too much. > What is missing? If you publish a list, perhaps somebody would like > to do the job of implementing it. OK, I hope to present a list of missing features to this list within a few days. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Jul 24 02:09:21 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA13071 for ; Wed, 24 Jul 1996 02:09:21 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76276; Wed, 24 Jul 1996 02:09:54 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA112569; Wed, 24 Jul 1996 02:06:40 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41966; Wed, 24 Jul 1996 02:09:52 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA21855 for ; Wed, 24 Jul 1996 02:53:52 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA12897; Wed, 24 Jul 1996 01:52:23 +0200 From: Peter Gerwinski Message-Id: <199607232352.BAA12897@agnes.dida.physik.uni-essen.de> Subject: Re: The purpose of GNU Pascal To: 100120.3121@compuserve.com (Berend de Boer) Date: Wed, 24 Jul 1996 01:52:23 +0200 (MET DST) Cc: gpc@hut.fi In-Reply-To: <960723200100_100120.3121_EHQ160-1@CompuServe.COM> from "Berend de Boer" at Jul 23, 96 04:01:00 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello Berend, hello GPC-list! > > Furthermore, I could not write my real-world programs > > just with Extended Pascal; I need, for example, bit shift operators, GetMem, > > FreeMem, and Objects. > > You don't need GetMem and FreeMem as I did show you :-) But you need the other > two. You can replace *some* applications of GetMem and FreeMem with Extended Pascal schema types, but this is not reasonable for *all* applications. For example in low-level programming you need to provide a buffer of a specified size in Bytes which you don't know at compile time. This *can* be done with an Extended Pascal array schema Type ByteArray ( Size: Integer ) = packed array [ 1..Size ] of __byte__ Integer; ByteArrayPtr = ^ByteArray; Var Buffer: ByteArrayPtr; n: Integer; (* Size of Buffer *) [...] (* Read or calculate n *) New ( Buffer, n ); [...] Dispose ( Buffer ); but you have to pass the address of the Buffer -- not that of the schema -- to the system call. You may be able to work around this, but using GetMem would be more appropriate in this context. However, we *have* GetMem and FreeMem (and shl and shr) in GNU Pascal, and I won't take them out again. ;-) > > and integrate them in one powerful compiler which will set up the next > > standard. > > I certainly don't agree with this if the compiler does not have switches to > accept only Extended Pascal or only ISO Pascal or only ... ... or only Borland Pascal. ;-) Okay, we can implement those switches. Actually, you already can specify --pedantic, and GPC will complain about everything which is not ISO 7185. > Programs conforming to the Extended Pascal will probably not only work in many > different environments but also with many different compilers. I don't want to > loose that feature/possibility. Nobody wants you to lose this feature. But I don't want to lose the possibilities of Borland Pascal. I will lose them if I wait for new compilers by Borland, so I react. By the way: Where are those many different Extended Pascal compilers? > Extending a compiler with more features is not a problem, but IMO, one should > complete the standard parts first. Most of the features I am speaking of *are* already implemented into GPC, so your statement is coming too late. :-) The discussion is about how to modify GPC.GUIDE in order to take the existence of the extensions into account. Who is "one"? If you want to do have the standard completed, why don't you do it yourself? However, I find the schema types interesting enough that I could do the implementation (but don't hold your breath). Concerning the rest of the standard, I don't know what is missing. Please tell me! > Hmm, I don't think that Extended Pascal is not powerful enough. It's true that > it does not contain everything one needs, but that's mainly due to the goal of > creating a portable language. I don't know the reason, but this can *not* be the reason. You don't lose portability by simply including bit-shift operators, objects, etc. into the Extended Pascal standard. But they didn't include them. No idea, why. > And the new object standard also rectififies some omissions. What are the advantages which rectify omissions? I don't see anything which rectifies *not* to have this-or-that in the standard except the lazyness of those who have to implement the standard into a compiler. > I can create everything I want in Extended Pascal programs with only a few > routines accessing non-standard parts, mainly concerning bit-operators (you can > do this with Extended Pascal, but it's a bit more tedious), and system call > access (assembly). You mean: "with Object Pascal extensions"? Otherwise there is at least one major feature missing. And what about, say, user-defined operators which are almost a *must* for scientific calculations? As an example, compare the line which applies three rotations to the matrix B B:= Rz ( phi ) * Ry ( theta ) * Rz ( - phi ) * B; (copied from one of my scientific programs) with the construct CalculateRz ( - phi, Rtemp ); MultMatrices ( B, Rtemp, B ); CalculateRy ( theta, Rtemp ); MultMatrices ( B, Rtemp, B ); CalculateRz ( phi, Rtemp ); MultMatrices ( B, Rtemp, B ); or, a little more compact, RotateZ ( B, - phi ); RotateY ( B, theta ); RotateZ ( B, phi ); The single line with matrix operators is almost the same as you would write down on a piece of paper. This is a *short* example. Imagine a program which contains a sequence of 50 such lines with and without user-defined operators. I have written such things with Borland Pascal, and I included the lines with operators as comments just to have something in the program you can still read. Now I can use operators in GNU Pascal, and my programs have become much smaller and easier to maintain. > A compiler which accepts every Pascal standard and does everything would be nice > of course. But there is quite some work to do. So I would like to add that we > first focus on the ISO Pascal and Extended Pascal part. Even the ISO Pascal > standard, according to Scott Moore (have email address if anyone wants it), > needs much looking after. I will first continue to focus on those extensions which I intend to use myself, i.e. the rest of the Borland and PXSC extensions, plus Extended Pascal schema types which are a reasonable extension (in my opinion). If somebody wants to focus on the ISO Pascal standards, I offer my help to get started with GPC-hacking. But I don't intend to spend my time with trying to satisfy standard specifications I don't realize their sense. > Don't overlook the Pascal standards boys (no girls here I assume). > They do much more than you think, What are they doing? I am sorry, but in the moment I don't see any advantage of obeying the standards; I only see that I have to give up some possibilities I am having now. I admit that there are good ideas in Extended Pascal (e.g. structured return values, complex numbers, schema types), but those Pascal standard boys did overlook the existing Borland Pascal compiler and defined a standard below the requirements of real-world programming. > but different than Borland Pascal which has quite a C > feeling and lost too much of it's real Pascal spirits. This depends entirely on the programmer. Borland took over good ideas from C, and GNU C took over good ideas from Pascal. Why not? How would you define "real Pascal spirit"? And *why* did Borland do this? Borland Pascal is based on UCSD Pascal which was a well-defined standard. But they went beyond UCSD in order to meet the requirements of real-world programming, especially low- level programming. For many years, nobody took over Borland's ideas and made a standard out of them, so it developped on an island, while the rest of the world almost forgot Pascal completely and went to C and C++. Then they defined the Extended Pascal standard. So why did they ignore Borland's ideas which already had proven their use? It would have been trivial to include, for example, bitwise AND and OR and bit-shift operators into the standard. If those who define the standard overlook my needs, I take the right to overlook their standard in the sense that I won't accept it as a restriction. Of course, I am profiting of good ideas such as structured return values, etc., but I prefer a compiler which understands *more* than just the standard. So again: What about changing the beginning of GPC.GUIDE in order to take into account that GPC has some extensions, now? I don't want to say that GPC should not become ISO-10206-compliant, but I would prefer to specify the goal to write the best possible Pascal compiler rather than obeying a specific standard. Extended Pascal may be good, but GPC will be even better. It is time to set up the next standard! Yours, Peter From gpc-request@santra.hut.fi Wed Jul 24 02:09:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA13067 for ; Wed, 24 Jul 1996 02:09:08 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79844; Wed, 24 Jul 1996 02:09:41 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA102835; Wed, 24 Jul 1996 02:06:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76254; Wed, 24 Jul 1996 02:09:39 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA21848 for ; Wed, 24 Jul 1996 02:54:22 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA12890; Wed, 24 Jul 1996 01:51:37 +0200 From: Peter Gerwinski Message-Id: <199607232351.BAA12890@agnes.dida.physik.uni-essen.de> Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal To: 100120.3121@compuserve.com (Berend de Boer) Date: Wed, 24 Jul 1996 01:51:36 +0200 (MET DST) Cc: gpc@hut.fi In-Reply-To: <960723200110_100120.3121_EHQ160-3@CompuServe.COM> from "Berend de Boer" at Jul 23, 96 04:01:10 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello Berend, hello everybody! > > There are really few of them, but since the source exists, I suggest > > that somebody ports *everything* to the DOS version of GPC, and we can > > make the "potentially portable" parts portable in a second stage. > > What use does it have when you already have a good Dos compiler, i.e. Borland > Pascal? It fullfills all my needs for the Dos environment. Not mine, and when you look into comp.lang.pascal.borland you will find a lot of Borland Pascal programmers complaining about version 7 and looking around for a version 8 which should eliminate the 64kB limit. But it is clear that Borland will *not* write this version 8, although they promised to do so a few CeBit fairs ago. Borland Pascal is a good DOS Pascal compiler, but it is not good enough at least for *my* needs in the next years. GNU Pascal *is*, and I am sure we could get a lot of Borland Pascal programmers to switch to GNU Pascal if we had CRT and Graph Units available. > Besides, what do you mean by 'porting', i.e. should do exactly the same with > every quirk inherited or just similar enough? I mean: similar enough. > The system unit can be implemented easily, I've done already that for 90%. A few > things you can't do like Inc, and some functions which have overloaded > parameters (Assign, Close, ...). Inc, dec, shl, shr, etc. *ARE* already implemented into GPC. Read the file README.TURBO. If you have a Borland "system" module, please publish it! > If similar is good enough, I suggest we define a POSIX interface first, starting > from the one I wrote for Dos, and build the Dos unit on top of that. Why not? Please do it! > We can do the Crt unit in the same manner, building on top of the curses > library. Like this (I think at least), the FPK Pascal CRT Unit I am speaking of works. > > We have free sources of Borland Units (CRT, Graph, ...) > > Note, you don't have the source of the Graph unit. ******************************************** Note, I HAVE the source of the Graph unit!!! ******************************************** I am not speaking of the Borland source (which I once bought for 600 DM -- just to see that they were sold for 50 DM one month later)-< which in fact does not include the source of Graph. Those sources are copyrighted by Borland and of no use for our FreeWare project. I am speaking of the FREEWARE sources of CRT, Graph, etc. from the FPK Pascal project! I herewith repeat: I am in contact with Florian Klaempfl, the author of FPK Pascal, another free 32-bit Pascal compiler. Florian has got free sources for Borland compatible Units like SYSTEM, CRT, PRINTER, and GRAPH for FPK Pascal which cry for being ported to GNU Pascal. So, unless Florian is lying (what I don't believe!), we *have* Graph sources available as FreeWare. > From my viewpoint, Borland Pascal does everything, so spending time for > a Dos only solution is not a thing I want. And it is not necessary. >From my viewpoint, Borland Pascal is bursting due to the 64kB limit which is still present for single variables and single code segments. Even a DOS-only solution would be very useful for a lot of Borland Pascal programmers who could smoothly switch to GNU Pascal if the Units were available. > And is gpc already for such projects? YES! Read, for example, README.TURBO. > I see some problems with gpc as I know it: > - no renaming, necessary to avoid clashing with c libraries. No problem: Use the AsmName directive. > - qualifed imports available? What's that? > - how to link with C libraries? You have the c; construct, but exactly > how does it work? What does it do? The C directive decapitalizes the name of a Procedure/Function while making it an external declaration. Like this, you can access C library functions which are in lowercase. For other functions use the AsmName directive: Function MyCFunction ( i: Integer ): Integer; AsmName 'my_C_func'; is equivalent to the C construct extern int my_C_func (int i); and therefore allows to access the C function my_C_func from Pascal. And again: Porting *existing* CRT, Graph, etc. sources to GNU Pascal. Anybody wants to do the job? Yours, Peter From 100120.3121@CompuServe.COM Wed Jul 24 10:00:31 1996 Return-Path: 100120.3121@CompuServe.COM Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com [149.174.206.133]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id KAA13401 for ; Wed, 24 Jul 1996 10:00:13 +0200 Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id EAA26923; Wed, 24 Jul 1996 04:01:04 -0400 Date: 24 Jul 96 04:00:06 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: Peter Gerwinski Cc: gpc Subject: Re: The purpose of GNU Pascal Message-ID: <960724080006_100120.3121_EHQ37-2@CompuServe.COM> Status: RO > By the way: Where are those many different Extended Pascal compilers? You have Prospero's compilers for Dos/Windows and OS/2, DEC has a Pascal compiler on VAX which implements almost all of the Extended Pascal standard. I'm not sure of the Macintosh, there is a Pascal compiler on the Mac from Warriar, but if that one implements Extended Pascal?? I'm going to research that today. > You don't lose portability by simply including bit-shift operators, objects, etc. into > the Extended Pascal standard. But they didn't include them. No idea, why. Objects are in another standard. bit-shift operators have to depend upon memory layout and byte ordering. But I agree with you that they should be available. > And what about, say, user-defined operators which are almost a *must* for scientific calculations? I completely agree with you that user-defined operators are a must in a field where those operators defined. In most other areas they are not. We can probably atttach a dozen explanations to the following construct: House := PersonA + PersonB; The example you gave had exactly one meaning clear to everyone. > But I don't intend to spend my time with trying to satisfy standard specifications I don't realize their > sense. I can quite agree with you. But don't forget: there are millions, literally millions of code written in some form of Standard Pascal out there in the world. For such people an alternative in the form of GNU Pascal could really be interesting. > How would you define "real Pascal spirit"? Let the compiler do as much as possible for you: basically that comes down to no untyped pointers. I *have* to use much more untyped pointers in Borland Pascal (in obtaining addresses from procedures, strings, etc.) than would be necessary. > Extended Pascal may be good, but GPC will be even better. It is time to set up the next standard! Completely agreed. I can accept the modifications to GPC.GUIDE you presented. Of course a compiler which accepts Borland Pascal syntax is a major advantage. Makes porting much easier. And if you really have good alternatives for Borland's standard libraries... Groetjes, Berend. From gpc-request@santra.hut.fi Wed Jul 24 10:15:44 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA13416 for ; Wed, 24 Jul 1996 10:15:43 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47088; Wed, 24 Jul 1996 10:16:09 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA125360; Wed, 24 Jul 1996 10:12:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50666; Wed, 24 Jul 1996 10:16:07 +0200 Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com [149.174.206.133]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA25949 for ; Wed, 24 Jul 1996 11:01:47 +0300 (EET DST) Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id EAA26931; Wed, 24 Jul 1996 04:01:06 -0400 Date: 24 Jul 96 04:00:10 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: Peter Gerwinski Cc: gpc Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal Message-Id: <960724080009_100120.3121_EHQ37-3@CompuServe.COM> Status: RO >> What use does it have when you already have a good Dos compiler, i.e. Borland >> Pascal? It fullfills all my needs for the Dos environment. > Not mine, and when you look into comp.lang.pascal.borland you will find Yes, I did see your problem, but I never encountered these things. My units are small, so I don't have codesegment faults, and for large arrays I have a few objects of my own which either use XMS/EMS or conv memory to present large arrays. But I see. I make a Posix interface for GPC first and present any difficulties I encounter to you so you can make the necessary changes to the compiler ok? > Note, I HAVE the source of the Graph unit!!! Ah, I now remember you saying this, but shouldn't this be: I have the source of a Graph unit? >> - qualifed imports available? > What's that? To reference a symbol from these modules you always need to add the module name as prefix. Maybe I don't need this now, I'll see. OK, I see if I can write something with gpc. I'll tackle the Posix interface and the Dos unit first. I start using djgpp's port. Which one should I take? Groetjes, Berend. From gpc-request@santra.hut.fi Wed Jul 24 17:25:12 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA13859 for ; Wed, 24 Jul 1996 17:25:11 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84782; Wed, 24 Jul 1996 17:25:31 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA86668; Wed, 24 Jul 1996 17:22:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84774; Wed, 24 Jul 1996 17:25:28 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA01524 for ; Wed, 24 Jul 1996 18:11:24 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA13810; Wed, 24 Jul 1996 17:08:15 +0200 From: Peter Gerwinski Message-Id: <199607241508.RAA13810@agnes.dida.physik.uni-essen.de> Subject: Bit shift operators, untyped pointers, Borland Pascal To: 100120.3121@compuserve.com (Berend de Boer) Date: Wed, 24 Jul 1996 17:08:15 +0200 (MET DST) Cc: gpc@hut.fi In-Reply-To: <960724080006_100120.3121_EHQ37-2@CompuServe.COM> from "Berend de Boer" at Jul 24, 96 04:00:06 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Berend de Boer wrote: > bit-shift operators have to depend upon memory > layout and byte ordering. That's not true. The bit-shift oparations are mathematically defined on the set of integer numbers and are independend from the representation of the number in memory. $900 shr 1 = $480 (or: 16#900 shr 1 = 16#480 :-) holds on any machine, independendly of the question whether the numbers are stored internally as 00 09 and 80 04 or as 09 00 and 04 80. > I can quite agree with you. But don't forget: there are millions, literally > millions of code written in some form of Standard Pascal out there in the world. > For such people an alternative in the form of GNU Pascal could really be > interesting. I would guess that even much more code has been written for Borland Pascal, and for those programmers GNU Pascal could be interesting too. However the best thing is to support both. > I *have* to use much more untyped pointers in Borland Pascal (in obtaining > addresses from procedures, strings, etc.) than would be necessary. With Borland Pascal, you can have procedural parameters, Pointers to strings, etc.. The construct @myString is a pointer to a string, no untyped pointer, when you enable the "typed @ operator" option. You don't need to use untyped pointers in Borland Pascal, except for real low-level programming. Peter From gpc-request@santra.hut.fi Wed Jul 24 17:45:03 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA13872 for ; Wed, 24 Jul 1996 17:45:03 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77290; Wed, 24 Jul 1996 17:45:22 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA62486; Wed, 24 Jul 1996 17:42:07 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66238; Wed, 24 Jul 1996 17:45:02 +0200 Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.70.135]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA01751 for ; Wed, 24 Jul 1996 18:30:04 +0300 (EET DST) Received: from rac4.wam.umd.edu (rac4.wam.umd.edu [128.8.70.104]) by po3.wam.umd.edu (8.7.5/8.7.3) with ESMTP id LAA03012; Wed, 24 Jul 1996 11:29:58 -0400 (EDT) Received: (from lotu@localhost) by rac4.wam.umd.edu (8.7.5/8.7.3) id LAA20106; Wed, 24 Jul 1996 11:29:57 -0400 (EDT) Date: Wed, 24 Jul 1996 11:29:57 -0400 (EDT) From: Arcadio Alivio Sincero To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal In-Reply-To: <199607231529.RAA12126@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hmm ... I'm started to get interested now. I *may* be interested in doing stuff for Linux (may is the operative word here 'tho, folks ... since being a student tends to eat up a lot of my time ...). Has the "Borland UNITs" problem been fixed with GPC yet? Or are we still stick with that rather nasty (IMHO of course) hack we had to do by #including the the UNIT file in any program we wished to use that unit? On Tue, 23 Jul 1996, Peter Gerwinski wrote: > would be *highly interesting* for those programmers who are accustomed > to Borland Pascal and think about changing to GNU Pascal (instead of > changing to Delphi or C++) in the future. To have those Units on the DOS > platform only would be a starting point -- portable versions would > be preferred, of course. The last time I checked out your BO5 library, Peter, any program that used your Crt unit, I think, had to be set uid on the Linux platform 'cause it did direct screen writes. Is this still true? Or did you change it to use NCurses yet? Personally I recommonend making it SLang-based rather than NCurses-based. Mainly because the SLang screen management routines are faster than NCurses. Also, SLang is also a highly portable library in in itself (with versions for DOS, OS/2, and other unices in addition to Linux). I don't recall ever seeing a DOS NCurses (Curses perhaps, but not NCurses). I've already written a Crt-like MODULE for Gardens Point Modula-2 compiler which are SLang-based. Shouldn't be too hard to convert over to GPC. That is ... if anybody is interested ... > > A portable Printer library?? > What's the problem? It would just be a Unit (Module) which "knows" the > file name of the printer device for the actual operating system and opens > a text file "lst", so the application program doesn't need to care about > how the printer is named on the operating system. Yeah .. it shouldn't be too hard to implement Printer ... it seems rather straight forward to me. > Borland's Units *are* an existing standard. There may be other standards, > but I think these Units are very popular. Furthermore, we *have* the source > for them, so I ask again: However, like the other guy said, certain things in Borland Pascal only make sense under DOS (like the Mem[] variable and ABSOLUTE variables). Of course we could just do what other Borland-Pascal like compilers for other platforms (like Virtual Pascal and Speed Pascal/2 for OS/2) do, and just ignore them. =============================================================================== Arcadio Alivio Sincero, Jr. Sophomore, Computer Science Major at the University of Maryland at College Park Amateur competitive bodybuilder Email: lotu@wam.umd.edu, WWW: "D.A.R.E. .... to keep cops off donuts." From gpc-request@santra.hut.fi Thu Jul 25 01:13:26 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA14082 for ; Thu, 25 Jul 1996 01:13:25 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA34262; Thu, 25 Jul 1996 01:13:38 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA114243; Thu, 25 Jul 1996 01:10:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72400; Thu, 25 Jul 1996 01:13:36 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA05712 for ; Thu, 25 Jul 1996 02:04:28 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA14054; Thu, 25 Jul 1996 01:03:15 +0200 From: Peter Gerwinski Message-Id: <199607242303.BAA14054@agnes.dida.physik.uni-essen.de> Subject: Re: Programmers wanted: CRT, Graph, etc. for GNU Pascal To: lotu@wam.umd.edu (Arcadio Alivio Sincero) Date: Thu, 25 Jul 1996 01:03:15 +0200 (MET DST) Cc: gpc@hut.fi In-Reply-To: from "Arcadio Alivio Sincero" at Jul 24, 96 11:29:57 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Arcadio wrote: > > Has the "Borland UNITs" problem been fixed with GPC yet? Or are we still > stick with that rather nasty (IMHO of course) hack we had to do by #including > the the UNIT file in any program we wished to use that unit? I am just working on that problem and I'm pretty sure that it will be fixed in the next release. But please be patient since it is *hard* work and... > since being a student tends to eat up a lot of my time ... :-) > The last time I checked out your BO5 library, Peter, any program > that used your Crt unit, I think, had to be set uid on the Linux platform > 'cause it did direct screen writes. Is this still true? Or did you > change it to use NCurses yet? Use -D TERMCAP instead of -D LINUX and link the -ltermcap library. export CL_COLOR=YES in order to get ANSI colors. Since I want to have BO5 being portable to *all* platforms including OS/2pm and Windoze, I want to avoid to rely on special libraries. I will probably use (S)VGALIB with Linux which is part of the operating system, but I will even try to avoid linking the termcap library in the next release since I have found computers where it is not installed (!). Since I am rewriting kind of Turbo Vision (but with graphics mode, too) I actually won't need something like ncurses. When my progress on BO5 is so slow, this has (almost) no technical reasons but it's a question of time. Currently, I am hacking around in the interior of GPC, in programs I want to sell, and in my dissertation thesis in physics. > I've already written a Crt-like MODULE for Gardens Point Modula-2 > compiler which are SLang-based. Shouldn't be too hard to convert over to > GPC. That is ... if anybody is interested ... Since my BO5 will take some time to become really useful, I think that everything which replaces CRT etc. is highly welcome by the GPC users, even if it is not portable to all platforms. But once more: I have free sources of CRT, Graph, etc. ... I don't want to port them myself because I think it is more important that I work on the compiler itself and on BO5. > Yeah .. it shouldn't be too hard to implement Printer ... it > seems rather straight forward to me. Here is the DOS version: Unit Printer; Interface uses Tools; (* we need Assign *) Var lst: Text; Implementation to begin do (* Extended Pascal initializers and finalizers *) begin Assign ( lst, 'prn' ); rewrite ( lst ); end (* to begin *) to end do close ( lst ); end. I didn't test it, but it should work. (-: Now it's your turn to make it portable. ;-) > However, like the other guy said, certain things in Borland > Pascal only make sense under DOS (like the Mem[] variable and ABSOLUTE > variables). Absolute variables *make* sense not only under DOS when you use them instead of variant records to convert data. Look into the Tools Unit from BO5 for examples. (Yes, GPC has "absolute".) Yours, Peter -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Fri Jul 26 17:31:35 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA15029 for ; Fri, 26 Jul 1996 17:31:34 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA33358; Fri, 26 Jul 1996 17:31:09 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA57898; Fri, 26 Jul 1996 17:27:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55622; Fri, 26 Jul 1996 17:31:07 +0200 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA01034 for ; Fri, 26 Jul 1996 18:11:48 +0300 (EET DST) Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by kampi.hut.fi (8.6.11/8.6.7) with SMTP id SAA06931 for ; Fri, 26 Jul 1996 18:11:46 +0300 Received: from pc036.pczaalciv.utwente.nl by driene.student.utwente.nl with SMTP id AA14766 (5.67b/IDA-1.5 for ); Fri, 26 Jul 1996 17:11:44 +0200 Date: Fri, 26 Jul 1996 17:11:44 +0200 Message-Id: <199607261511.AA14766@driene.student.utwente.nl> From: operator@civpczaal.utwente.nl (Student) To: gpc@kampi.hut.fi Subject: forwarded Usenet article Status: RO [article forwarded from Student (operator@civpczaal.utwente.nl)] Path: news.nic.utwente.nl!surfnet.nl!howland.reston.ans.net!newsfeed.internetmci.com!btnet!news.enterprise.net!usenet From: eurgain@enterprise.net (Alistair Hamilton) Newsgroups: comp.os.msdos.djgpp Subject: Re: GPC112B.ZIP & GPT112B.ZIP Date: Tue, 23 Jul 1996 23:30:15 GMT Organization: Ty Eurgain Lines: 45 Message-ID: <4t3nq5$ih8@news.enterprise.net> References: <960718165325_74617.365_EHH119-1@CompuServe.COM> NNTP-Posting-Host: max02-063.enterprise.net X-Newsreader: Forte Free Agent 1.0.82 "Troy D. Van Horn" <74617.365@CompuServe.COM> wrote: >Hi all, > I just last night discovered these files for a PASCAL compiler last night >on a simtelnet mirror, and I was wondering where I could get some documentation >on how to use either compiler? The source file is really large (>8Meg) so I >would really prefer not to download it. Where should I look for documentation >on GPC and the differences between GPC and GPT version? (I already know >PASCAL). >Thanks, Troy Van Horn 74617.365@compuserve.com >Please E-mail all replys direct to my address, Thank you. PROGRAM GetSomeHelp (Input, Output|) CONST PascalExists = TRUE; VAR CIsBetter : BOOLEAN; BEGIN WRITELN('I would really like this info too. OK, as an ex Unix/C/X nerd, I cannot dispute that C cannot be beaten (except , perhaps, by C++). However, age has revealed that Pascal really is useful sometimes! Typing B E G I N and E N D sure as hell is! (I have programmed for accountancy apps ZZZzzzz in Pascal - but better P than C in that case).'); CIsBetter := TRUE; WRITELN ('I also have the GNUPascal binaries, and am held back from using them by lack of documentation. So come on, folks! At least you might tell us to b****r off and consult another really tesious group specially for Pascal bores, but if you do, it least you might tell us waht the group is called.'); WRITELN ('Regards'); WRITELN ('Alistair') END. :-) :-) :-) From gpc-request@santra.hut.fi Fri Jul 26 19:48:49 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA15615 for ; Fri, 26 Jul 1996 19:48:49 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57974; Fri, 26 Jul 1996 19:48:22 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA89927; Fri, 26 Jul 1996 19:45:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84846; Fri, 26 Jul 1996 19:48:19 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id UAA02228 for ; Fri, 26 Jul 1996 20:37:18 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA15581 for gpc@hut.fi; Fri, 26 Jul 1996 19:36:57 +0200 From: Peter Gerwinski Message-Id: <199607261736.TAA15581@agnes.dida.physik.uni-essen.de> Subject: GNU Pascal WWW home page To: gpc@hut.fi Date: Fri, 26 Jul 1996 19:36:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, I have constructed a GNU Pascal WWW home page: http://agnes.dida.physik.uni-essen.de/~gnu-pascal Comments, suggestions, bug reports welcome. Peter From gpc-request@santra.hut.fi Mon Jul 29 13:14:22 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA17639 for ; Mon, 29 Jul 1996 13:14:21 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76760; Mon, 29 Jul 1996 13:12:56 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA65044; Mon, 29 Jul 1996 13:09:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58066; Mon, 29 Jul 1996 13:12:54 +0200 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA25491 for ; Mon, 29 Jul 1996 14:00:56 +0300 (EET DST) Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by kampi.hut.fi (8.6.11/8.6.7) with SMTP id OAA08906 for ; Mon, 29 Jul 1996 14:00:53 +0300 Received: from [130.89.179.44] (pc044.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA16875 (5.67b/IDA-1.5 for ); Mon, 29 Jul 1996 13:00:51 +0200 Date: Mon, 29 Jul 96 13:08:31 CST From: "J.J. van der Heijden" Message-Id: <59737.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 X-Popmail-Charset: English To: gpc@kampi.hut.fi Subject: Re: release? Status: RO On Sat, 27 Jul 1996 23:00:20 +0200 (MET DST, Peter Gerwinski wrote: >Hello again, > >there was a bug in my GPI stuff: File types did not >survive transport through a GPI file. I am sure this >was not the last bug, but now a very useful physics >program works, so I am optimistic. > >gpc-pg-1.2-2.7.2.tar.gz has been updated. > >Release? > I know of two good reasons not to release 2.7.2 (yet): 1) Remaining bug(s). Last time I looked, that "functions returning a string are called three times" bug was still there. That's a serious problem for anything bigger than "Hello world". Also (I mentioned before): gpc fails two of the "paranoia" Pascal compiler float tests because it loses significant digits. I'd be carefull with that physics program, Peter. 2) Almost all messages / email I read about GPC are not about "compiler bug X keeps me from using it" or "feature Y is missing" but "HOW DO I INSTALL THE THING ON MY SYSTEM ?" "Where's the docs" is a popular one too. That's why I'm busy rewriting configuration scripts using GNU autoconf and have created .bat files for the dos version. Then, building it is reduced to "configure ; make" I have it done for the RTS, am working on GPC itself now. I think it should be able to locate gcc sources and objects by itself (if they are in a reasonable location). It works great for the RTS already. Arguments in favour of release: 1) New features (These have to be mentioned in a "NEWS" file. I think we have (a) better BPascal Objects (b) Improved module support, but there must be other user-visible changes as well. 2) Releasing 2.7.2 because gcc-2.6.3 is obsolete is an argument, but I don't think we'll have to wait much longer for gcc 2.8 and from what I've seen so far, it's not radically different from gcc-2.7.x (internally). So porting gpc to 2.8 should take too long. If this thing is to be released in one or two weeks I think we should make a "release candidate" so everybody can check wether his patches are in and binaries for all platforms can be built. /janjaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Mon Jul 29 13:19:31 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA17645 for ; Mon, 29 Jul 1996 13:19:31 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40570; Mon, 29 Jul 1996 13:18:05 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA88627; Mon, 29 Jul 1996 13:14:44 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42612; Mon, 29 Jul 1996 13:18:04 +0200 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA25607 for ; Mon, 29 Jul 1996 14:02:11 +0300 (EET DST) Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by kampi.hut.fi (8.6.11/8.6.7) with SMTP id OAA08910 for ; Mon, 29 Jul 1996 14:02:09 +0300 Received: from [130.89.179.44] (pc044.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA16983 (5.67b/IDA-1.5 for ); Mon, 29 Jul 1996 13:02:08 +0200 Date: Mon, 29 Jul 96 13:09:49 CST From: "J.J. van der Heijden" Message-Id: <59807.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 X-Popmail-Charset: English To: gpc@kampi.hut.fi Subject: GPC autoconf-ed Status: RO I mentioned my rts-autoconf adventures on the mailinglist; I dumped a modified RTS (rts-autoconf.tar.gz) in my homedir on agnes.dida.... Usage is straightforward: cd to your $(gpcbin)/rts directory and run ../../$(gpcsrc)/rts/configure ; make Autoconf is the way to go for GNU software and I think GNU Pascal should use it too. This is not finished: I have to do GPC itself, plus the result of a number of tests is not yet used in the RTS makefile. But it deals with all the -DSYSV -DNO_CASECMP -DMY_VERY_WEIRD_SYSTEM flags. It can also do crosscompilation: run CC=i386-go32-gcc AR=i386-go32-ar RANLIB=i386-go32-ranlib \ ../../$(gpcsrc)/rts/configure --target=i386-go32 ; make to get a djgpp RTS (on Linux) I also added a definition in Makefile.in to build libgpc as a shared lib. A 'make libgpc.so.2.8 CFLAGS="-O2 -fPIC"' results in: lrwxrwxrwx 1 root root 13 Jul 29 02:06 /usr/lib/libgpc.so -> libgpc.so.2.8* -rwxr-xr-x 1 root root 48960 Jul 29 02:06 /usr/lib/libgpc.so.2.8* This reduces the size of executables: -rwxr-xr-x 1 janjaap users 2856 Jul 29 02:09 hello* -rw-r--r-- 1 janjaap users 63 Jul 29 02:07 hello.pas Statically linked, the minimum is ~33K. BTW: this will work only on ELF un*x systems and I have only tested it on Linux. "ldd hello" shows: libgpc.so.2.8 => /usr/lib/libgpc.so.2.8 libm.so.5 => /lib/libm.so.5.0.5 libc.so.5 => /lib/libc.so.5.2.18 I will add this as an "--enable-shared" option to "configure" As for your desire to release 2.7.2: I can have this finished by friday (I think ...), then it should be tested on a number of different platforms. I'm especially curious about BSD unix systems, because I developed this on Linux, which is essentially SysV. I created a "configure.bat" for the dos world where there's no bash. Peter, you have the same with OS/2 so maybe you can take a look at it and create something simular for the EMX thing. (I ripped of binutils and GCC to create "configure.bat") /janjaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Sun Aug 11 03:41:58 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA29770 for ; Sun, 11 Aug 1996 03:41:58 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05412; Sun, 11 Aug 1996 03:36:13 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA54596; Sun, 11 Aug 1996 03:32:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54814; Sun, 11 Aug 1996 03:36:11 +0200 Received: from zelator.berlinet.de (zelator.berlinet.de [193.100.15.1]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id EAA03800 for ; Sun, 11 Aug 1996 04:25:35 +0300 (EET DST) Received: from tbx.berlinet.de by zelator.berlinet.de with zconnect (Smail3.1.29.1 #9) id m0upPHD-000HYrC; Sun, 11 Aug 96 03:25 METDST To: gpc@hut.fi Message-Id: <6EWstjQtdAB@p-21.hsociety.berlinet.de> From: OESY@HSOCIETY.berlinet.de (Ingo Oeser) Path: tbx.berlinet.de!hsociety.berlinet.de Organization: SP/2-User Subject: HELP Date: Fri, 09 Aug 1996 12:02:00 +0100 X-Mailer: CrossPoint v3.1 X-Gateway: ZCONNECT zelator.berlinet.de [LEGO v0.12] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Zc-Post: Lindenstr. 21; Schoenberg 23923 X-Zc-Telefon: V+49-38828-24349 Lines: 9 Status: RO HELP Bye OESY -- OS/2: Never stop that feeling... Using Speed-Pascal/2 (SP/2)! Questions? PM me! ## CrossPoint v3.1 ## From gpc-request@santra.hut.fi Wed Aug 14 10:24:30 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA32247 for ; Wed, 14 Aug 1996 10:24:25 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA21706; Wed, 14 Aug 1996 10:17:30 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA84755; Wed, 14 Aug 1996 10:13:07 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46394; Wed, 14 Aug 1996 10:16:33 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA27596; Wed, 14 Aug 96 10:16:57 +0200 Received: from hil-img-4.compuserve.com (hil-img-4.compuserve.com [149.174.177.134]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA23467 for ; Wed, 14 Aug 1996 11:03:22 +0300 (EET DST) Received: by hil-img-4.compuserve.com (8.6.10/5.950515) id EAA03239; Wed, 14 Aug 1996 04:02:45 -0400 Date: 14 Aug 96 04:01:24 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: part of system.pas unit ready Message-Id: <960814080123_100120.3121_EHQ104-3@CompuServe.COM> Status: RO Hello All, I promised to create a System.pas unit, here is a large part of it (see next message). It seems to work on gnu-win32 systems (I tested it in a NT workstation). It probably also works on BSD unix systems. I used gpc 2.6.3 (which was more useful than I expected and have said so in the past )-: ), but I still encountered some strange things. So here my comments: 1. how do you use the __unsigned__ prefix? 2. Instead of using __byte__, etc. ranges should be better as Juki already suggested. 3. nil assignment to void pointer unacceptable? (var p: ^void; p := nil; ) Things I found missing: - schema types ( type t(max:integer) = array[0..max] of double; ) - function result variables ( function f(p: integer) = Result: integer; ) - pre-initialized variables - renaming in export clause I like to here comments, Berend. From gpc-request@santra.hut.fi Wed Aug 14 10:24:37 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA32251 for ; Wed, 14 Aug 1996 10:24:32 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90588; Wed, 14 Aug 1996 10:17:37 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA75032; Wed, 14 Aug 1996 10:13:14 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05194; Wed, 14 Aug 1996 10:16:45 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA27607; Wed, 14 Aug 96 10:17:11 +0200 Received: from hil-img-4.compuserve.com (hil-img-4.compuserve.com [149.174.177.134]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA22356 for ; Wed, 14 Aug 1996 11:03:12 +0300 (EET DST) Received: by hil-img-4.compuserve.com (8.6.10/5.950515) id EAA03203; Wed, 14 Aug 1996 04:02:38 -0400 Date: 14 Aug 96 04:01:06 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Program to test system.pas unit Message-Id: <960814080105_100120.3121_EHQ104-1@CompuServe.COM> Status: RO Here a small program which 'demonstrates' the use of the system.pas unit. -------------------------test.pas------------------------ #include "system.pas" program Test(Output); import System; var f: text; path: string(1024); i: integer; begin Assign(f, 'tmp.tmp'); Erase(f); writeln('IOResult = ', IOResult); Assign(f, 'q.pas.bak'); BPRename(f, 'renamed.file'); writeln('IOResult = ', IOResult); GetDir(0, path); writeln('Current dir = ', path); BPMkDir('mydir'); writeln('IOResult = ', IOResult); BPRmDir('mydir'); writeln('IOResult = ', IOResult); writeln('ParamCount = ', ParamCount); for i := 1 to ParamCount do begin writeln('parameter ', i, ' = ', ParamStr(i)); end; end. -------------------------test.pas------------------------ Groetjes, Berend. (-: From gpc-request@santra.hut.fi Wed Aug 14 10:38:06 1996 Return-Path: gpc-request@santra.hut.fi Received: from aixrs1.hrz.uni-essen.de (aixrs1.hrz.uni-essen.de [132.252.3.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA32259 for ; Wed, 14 Aug 1996 10:38:01 +0200 Received: from sp2nfs.power.uni-essen.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70724; Wed, 14 Aug 1996 10:31:06 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 3.2/UCB 5.64/4.03) id AA60945; Wed, 14 Aug 1996 10:27:01 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80688; Wed, 14 Aug 1996 10:30:41 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA27767; Wed, 14 Aug 96 10:31:05 +0200 Received: from hil-img-4.compuserve.com (hil-img-4.compuserve.com [149.174.177.134]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA23581 for ; Wed, 14 Aug 1996 11:03:10 +0300 (EET DST) Received: by hil-img-4.compuserve.com (8.6.10/5.950515) id EAA03213; Wed, 14 Aug 1996 04:02:39 -0400 Date: 14 Aug 96 04:01:18 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: System.pas module Message-Id: <960814080118_100120.3121_EHQ104-2@CompuServe.COM> Status: RO { Created: 1996-07-26 System module for emulating the Borland Pascal System unit. This one is specific for the GNU Extended Pascal implementation and provides a System.Pas interface specifically to emulate the 16-bit Borland Pascal compilers. Copyright (C) 1996 Berend de Boer This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Notes: - This one has hardcoded errorcodes!! It probably does not work on every machine. One really need to convert errno.h and stat.h first to make it portable. But I'll do that when I complete the Extended Pascal Posix interface for GNU Pascal. - assumes all Extended Pascal compilers have the local addition to provide an additional parameter to the Halt procedure. - certain procedures are almost untranslatable as Addr, Move and Str. They are therefore not translated, but require a change to the source code - there is no Assign or Close procedure for a file type variable, only for a text type variable. - Rename does not work for some reason. To do: - Append - FilePos - FileSize - Flush - Rename - Seek - Truncate $Date: 96-08-14 9:45 $ $Revision: 1 $ $Log: /Extended Pascal/Borland/GPC/system.pas $ * * 1 96-08-14 9:45 Berend * Borland Pascal's system unit for Extended Pascal, as far as applicable. } module System interface; export System = (shortint, byte, word, longint, PChar, pointer, string255, HeapError, ExitCode, PrefixSeg, Assign, BPChDir => ChDir, Close, Copy, Dec, Delete, Erase, GetDir, GetMem, Inc, IOResult, MaxAvail, MemAvail, BPMkDir => MkDir, ParamCount, ParamStr, BPRename => Rename, BPRmDir => RmDir, UpCase); type shortint = __byte__ integer; byte = __byte__ integer; word = __short__ integer; longint = integer; TChar = array[0..MaxInt] of char; PChar = TChar; pointer = void; string255= string(255); var HeapError: pointer; { Heap error function } {?ExitProc: Pointer; { Exit procedure } ExitCode: Integer; { Exit code } {?ErrorAddr: Pointer; { Runtime error address } PrefixSeg: Word; { Program segment prefix } InOutRes : integer; { I/O result buffer } procedure Assign(var t: text; protected Name: string); procedure BPChDir(protected s: string); procedure Close(var t: text); function Copy(protected s: string; Index: integer; Count: integer): string255; procedure Dec(var i: integer); procedure Delete(var s: string255; Index: integer; Count: integer); procedure Erase(var f: text); procedure GetDir(D: byte; var s: string); procedure Inc(var i : integer); function IOResult : integer; function MaxAvail: longint; function MemAvail : longint; procedure BPMkDir(protected s: string); function ParamCount: word; function ParamStr(Index: word): string255; procedure BPRename(var f: text; protected Newname: string); procedure BPRmDir(protected s: string); function UpCase(Ch: char): char; end. module System implementation; import StandardOutput; { support routines } const MaxPath = 4096; type TPath = array[0..MaxPath] of char; function StrPas(Str: PChar): String255; var i: integer; s: string255; begin i := 0; s := ''; while Str[i] <> Chr(0) do begin s := s + Str[i]; i := i + 1; end; StrPas := s; end; { StrPas } function unlink(path: __cstring__): integer; c; function chdir(path: __cstring__): integer; c; function getcwd(var buf: TPath; size: integer): PChar; c; function mkdir(path: __cstring__; mode: integer): integer; c; function _p_paramcount: integer; c; function _p_paramstr(num: integer; var str: string): Boolean; c; function rename(old: __cstring__; new: __cstring__): integer; c; function rmdir(path: __cstring__): integer; c; function MapUnixErrorToDosError(ErrorOccured: integer): integer; const EPERM = 1; { Not super-user } ENOENT = 2; { No such file or directory } EACCES = 13; { Permission denied } EBUSY = 16; { Mount device busy } EEXIST = 17; { File exists } ENOTDIR = 20; { Not a directory } ENOSPC = 28; { No space left on device } EROFS = 30; { Read only file system } EMLINK = 31; { Too many links } ENAMETOOLONG= 91; { File or path name too long } var Result: integer; UnixError: integer; begin if ErrorOccured then begin UnixError := EACCES; { should be errno... } case UnixError of ENOENT : Result := 2; ENOTDIR : Result := 3; EPERM, EACCES, EEXIST, ENOSPC, EROFS, EMLINK, ENAMETOOLONG: Result := 5; EBUSY : Result := 152; otherwise Result := UnixError; end; { case } end else begin Result := 0; end; MapUnixErrorToDosError := Result; end; { MapUnixErrorToDosError } { the system routines itself } procedure Assign; var b : BindingType; begin unbind(t); b := binding(t); b.Name := Name; bind(t, b); b := binding(t); end; procedure BPChDir(s: string); begin InOutRes := MapUnixErrorToDosError(chdir(s)); end; { ChDir } procedure Close; begin unbind(t); end; function Copy; begin if Index+Count > length(s) then Copy := SubStr(s, Index) else Copy := SubStr(s, Index, Count); end; procedure Dec; begin i := i - 1; end; procedure Delete; begin if Index = 1 then begin if 1+Count > length(s) then s := '' else s := s[1+Count..length(s)]; end else begin if Index+Count > length(s) then s := s[1..Index-1] else s := s[1..Index-1] + SubStr(s, Index+Count); end; end; procedure Erase; var bt: BindingType; begin bt := Binding(f); unbind(f); InOutRes := MapUnixErrorToDosError(unlink(bt.name)); end; procedure GetDir(D: byte; var s: string); var Buffer: TPath; pc: PChar; i: integer; begin pc := getcwd(Buffer, MaxPath); s := ''; i := 0; while pc[i] <> Chr(0) do begin s := s + pc[i]; i := i + 1; end; { call to StrPas does not work???? s := StrPas(pc);} end; { GetDir } procedure Inc; begin i := i + 1; end; function IOResult : integer; begin IOResult := InOutRes; InOutRes := 0; end; function MaxAvail; begin MaxAvail := MaxInt; end; function MemAvail; begin MemAvail := MaxInt; end; procedure BPMkDir; begin InOutRes := MapUnixErrorToDosError(mkdir(s, 8#0700)); end; { BPMkDir } function ParamCount; begin ParamCount := _p_paramcount - 1; end; { ParamCount } function ParamStr; var Str : string255; Success: Boolean; begin Success := _p_paramstr(Index, Str); if Success then ParamStr := Str else ParamStr := ''; end; { ParamStr } procedure BPRename; var bt: BindingType; begin bt := Binding(f); unbind(f); InOutRes := MapUnixErrorToDosError(rename(bt.name, Newname)); bt.Name := Newname; bind(f, bt); end; { BPRename } procedure BPRmDir; begin InOutRes := MapUnixErrorToDosError(rmdir(s)); end; { RmDir } function UpCase; begin if Ch in ['a'..'z'] then UpCase := Chr(Ord('A') + (Ord(Ch) - Ord('a'))) else UpCase := Ch; end; { we need an initialization section because gpc doesn't yet have initialized variables } to begin do begin {HeapError := nil;} InOutRes := 0; end; end. From gpc-request@santra.hut.fi Tue Aug 27 13:55:05 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA15942 for ; Tue, 27 Aug 1996 13:55:04 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45400; Tue, 27 Aug 1996 13:44:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68676; Tue, 27 Aug 1996 13:43:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA19773 for ; Tue, 27 Aug 1996 14:28:32 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA15861 for gpc@hut.fi; Tue, 27 Aug 1996 13:39:35 +0200 From: Peter Gerwinski Message-Id: <199608271139.NAA15861@agnes.dida.physik.uni-essen.de> Subject: ANNOUNCE: GPC 1.2 (2.7.2) pre-release To: gpc@hut.fi Date: Tue, 27 Aug 1996 13:39:34 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Dear readers of the GPC list, we herewith announce a pre-release of GPC version 1.2, based on GNU C 2.7.2. This is a beta test release. We ask you to try the new GPC version on as many different platforms as possible, isolate bugs, correct the documentation, etc.. Once we know it is stable enough, we will do the "official" 1.2-2.7.2 release. New features: * easier to compile and install, also for cross-compilation * Texinfo documentation * More stable (Borland-style) objects * "String" bug fixed (see the old `PROBLEMS' file) * Extended Pascal "export foo = all" extension * PXSC operator fragments (redefineable symbols) * Precompiled Module/Unit interfaces (needn't #include the interface any longer) * AutoMake facility (automatically compile Modules/Units which have been changed) Source and binaries for DJGPP, EMX, Linux, FreeBSD, and IRIX5 are available per anonymous ftp from agnes.dida.physik.uni-essen.de in the directory gpc-2.7.2 (They also will be available on kampi.hut.fi, soon.) Have fun, Jan Jaap Peter From gpc-request@santra.hut.fi Tue Aug 27 19:15:24 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA16431 for ; Tue, 27 Aug 1996 19:15:24 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46754; Tue, 27 Aug 1996 19:04:26 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65480; Tue, 27 Aug 1996 19:03:42 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA27066 for ; Tue, 27 Aug 1996 19:56:20 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA16406 for gpc@hut.fi; Tue, 27 Aug 1996 19:07:28 +0200 From: Peter Gerwinski Message-Id: <199608271707.TAA16406@agnes.dida.physik.uni-essen.de> Subject: gpc-2.7.2 on kampi.hut.fi To: gpc@hut.fi Date: Tue, 27 Aug 1996 19:07:27 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, the GPC 1.2 (2.7.2) pre-release is now available on kampi.hut.fi, too. The directory is jtv/gnu-pascal/gpc-2.7.2. Peter From gpc-request@santra.hut.fi Fri Aug 30 01:07:37 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA02928 for ; Fri, 30 Aug 1996 01:07:36 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41052; Fri, 30 Aug 1996 01:19:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42712; Fri, 30 Aug 1996 01:18:57 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA28116 for ; Fri, 30 Aug 1996 02:12:27 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA02908 for gpc@hut.fi; Fri, 30 Aug 1996 01:00:47 +0200 From: Peter Gerwinski Message-Id: <199608292300.BAA02908@agnes.dida.physik.uni-essen.de> Subject: gpc-2.7.2 for Linux-elf and Win32 To: gpc@hut.fi Date: Fri, 30 Aug 1996 01:00:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, GPC-2.7.2 pre-release binaries for Linux-elf and Win32 (with CygWin beta 14) are now available on kampi and on agnes. Peter From sad@utkux.utcc.utk.edu Fri Aug 30 01:25:24 1996 Return-Path: sad@utkux.utcc.utk.edu Received: from utkux4.utcc.utk.edu (UTKUX4.UTCC.UTK.EDU [128.169.76.11]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id BAA02939 for ; Fri, 30 Aug 1996 01:25:22 +0200 From: sad@utkux.utcc.utk.edu Received: by utkux4.utcc.utk.edu (SMI-8.6/2.7c-UTK) id TAA02460; Thu, 29 Aug 1996 19:37:02 -0400 Message-Id: <199608292337.TAA02460@utkux4.utcc.utk.edu> Subject: Re: gpc-2.7.2 for Linux-elf and Win32 To: peter@agnes.dida.physik.uni-essen.de (Peter Gerwinski) Date: Thu, 29 Aug 1996 19:37:01 -0400 (EDT) Cc: gpc@hut.fi In-Reply-To: <199608292300.BAA02908@agnes.dida.physik.uni-essen.de> from "Peter Gerwinski" at Aug 30, 96 01:00:46 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Nice! Slight typo in gpc.info 10.18 regarding functions as formal parameters. Berend reminded me of the right way to do it. Chees, Stefan > > Hello folks, > > GPC-2.7.2 pre-release binaries for Linux-elf and Win32 (with > CygWin beta 14) are now available on kampi and on agnes. > > Peter > > From gpc-request@santra.hut.fi Sat Aug 31 01:52:54 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA03745 for ; Sat, 31 Aug 1996 01:52:53 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43836; Sat, 31 Aug 1996 02:04:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35122; Sat, 31 Aug 1996 02:03:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA15171 for ; Sat, 31 Aug 1996 02:57:35 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA03684 for gpc@hut.fi; Sat, 31 Aug 1996 01:46:17 +0200 From: Peter Gerwinski Message-Id: <199608302346.BAA03684@agnes.dida.physik.uni-essen.de> Subject: Problem with constant strings in gpc 1.2(2.7.2)#7 ??? To: gpc@hut.fi Date: Sat, 31 Aug 1996 01:46:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Harry Reed: > In the users' manual chapter "About Pascal and Extended Pascal > languages" > there is a small example on how to initialize constant strings. When I > try > compiling the fragment with gpc 1.2(2.7.2)#7 I get the error messages > as showm below. Is this a valid bug or am I just doing something wrong? Extended Pascal initialized *structured* variables are not (yet) implemented into GPC, only (parts of) Borland Pascal style initializers. However some fragments of Extended Pascal initializers *do* exist in gpc-parse.y, but I don't know when they will work. Everybody be invited to help implementing this! > MyStrings : array [1..MyStringsCount] of Ident value [ Square brackets do not work. Use parantheses instead. ^ > 1:'EXPORT'; 2:'IMPLEMENTATION'; 3:'IMPORT'; You may specify Indices etc., but they are ignored completely. Even worse: Initialization of Strings does not work at all. Only "simpler" types, i.e. array/record combinations containing Integers, Reals, etc. work. This is a known bug, but I forgot to document it. Thank you for pointing me to it. > PS: Great work on GPC! Keep it up!!!! Thanks a lot. :-) :-) I will continue unless somebody makes big efforts to stop me. ;-) Peter From gpc-request@santra.hut.fi Tue Sep 3 21:49:13 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA09490 for ; Tue, 3 Sep 1996 21:49:13 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48480; Tue, 3 Sep 1996 21:59:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69050; Tue, 3 Sep 1996 21:58:50 +0200 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA27052 for ; Tue, 3 Sep 1996 22:22:55 +0300 (EET DST) Received: (from jm_black@localhost) by csunix1.lvc.edu (8.6.12/8.6.9) id PAA11796; Tue, 3 Sep 1996 15:24:29 -0400 Date: Tue, 3 Sep 1996 15:24:29 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: Compilation error Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi all. I've had this error ever since I installed gpc, and I've never figured out why. I'm not all that experienced at unix. When I try to compile anything, even the simplest program, I get: /usr/i486-linux/bin/ld: cannot open crt0.o: No such file or directory Sorry if this seems like such a stupid question. Any ideas? -john From gpc-request@santra.hut.fi Fri Sep 6 07:53:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA13323 for ; Fri, 6 Sep 1996 07:53:08 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66086; Fri, 6 Sep 1996 08:02:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68670; Wed, 28 Aug 1996 04:13:48 +0200 Received: from mercurio.uc.pt (mercurio.uc.pt [192.84.15.41]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id DAA31483 for ; Wed, 28 Aug 1996 03:25:23 +0300 (EET DST) Received: from eden.dei.uc.pt by mercurio.uc.pt (4.1/SMI-4.2) id AA10773; Wed, 28 Aug 96 01:19:30 +0200 Received: by eden.dei.uc.pt; (5.65/1.1.8.2/12Aug96-0336PM) id AA17637; Wed, 28 Aug 1996 01:19:13 +0200 Date: Wed, 28 Aug 1996 01:19:13 +0200 (MET DST) From: Patricio Domingues To: gpc@hut.fi Subject: Newbie question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi, I currently teaching Operative System to students who only know Pascal, so I'd like to know if we can use Unix System calls in pascal programs wirh GPC ? I mean stuff like 'fork()', 'exec()', etc... Thanks in advance, Patricio. From gpc-request@santra.hut.fi Fri Sep 6 07:52:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA13319 for ; Fri, 6 Sep 1996 07:52:54 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55292; Fri, 6 Sep 1996 08:02:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA33610; Wed, 28 Aug 1996 03:57:18 +0200 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id DAA30974 for ; Wed, 28 Aug 1996 03:01:14 +0300 (EET DST) Received: from mercurio.uc.pt (mercurio.uc.pt [192.84.15.41]) by snake.hut.fi (8.7.5/8.7.3) with SMTP id DAA58652 for ; Wed, 28 Aug 1996 03:01:11 +0300 Received: from eden.dei.uc.pt by mercurio.uc.pt (4.1/SMI-4.2) id AA10741; Wed, 28 Aug 96 01:03:57 +0200 Received: by eden.dei.uc.pt; (5.65/1.1.8.2/12Aug96-0336PM) id AA17622; Wed, 28 Aug 1996 01:03:35 +0200 Date: Wed, 28 Aug 1996 01:03:35 +0200 (MET DST) From: Patricio Domingues To: gpc@hut.fi Subject: Subscribe GPC's mail list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Thanks. From gpc-request@santra.hut.fi Fri Sep 6 18:59:29 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA15455 for ; Fri, 6 Sep 1996 18:59:28 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54032; Fri, 6 Sep 1996 19:08:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46884; Fri, 6 Sep 1996 19:07:52 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA23783 for ; Fri, 6 Sep 1996 19:55:13 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA15419; Fri, 6 Sep 1996 18:46:07 +0200 From: Peter Gerwinski Message-Id: <199609061646.SAA15419@agnes.dida.physik.uni-essen.de> Subject: Accessing external functions (was: Newbie question) To: patricio@eden.dei.uc.pt Date: Fri, 6 Sep 1996 18:46:06 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello Patricio, > I currently teaching Operative System to students who only know Pascal, > so I'd like to know if we can use > Unix System calls in pascal programs wirh GPC ? I mean stuff like > 'fork()', 'exec()', etc... You can access any function using the "external", "C", and "asmname" directives: Procedure fork; external; means: there is an external Procedure "Fork" (first letter uppercase), Procedure fork; C; means: there is an external Procedure "fork" (everything lowercase), and Procedure fork; asmname 'foO'; means: there is an external Procedure with the funny name "foO" (last letter is uppercase in this example) which can be accessed from Pascal via the name "fork". Good luck, Peter From gpc-request@santra.hut.fi Sat Sep 7 15:07:48 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA16449 for ; Sat, 7 Sep 1996 15:07:47 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67074; Sat, 7 Sep 1996 15:16:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA32252; Sat, 7 Sep 1996 15:15:53 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA01747 for ; Sat, 7 Sep 1996 16:08:42 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA16424 for gpc@hut.fi; Sat, 7 Sep 1996 15:00:07 +0200 From: Peter Gerwinski Message-Id: <199609071300.PAA16424@agnes.dida.physik.uni-essen.de> Subject: External, C, AsmName, ... To: gpc@hut.fi Date: Sat, 7 Sep 1996 15:00:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, (* This mail is somehow long. In short: I want to take the directives `Extern', `C', and `AsmName' *out* of GPC and extend the syntax of `External' instead. Okay? :*) as you know (?;-), we have the directives `External', `Extern' (same as `External'), `C', and `AsmName' in GPC for specifying external procedures. This is especially useful when using libraries written in C, for example: Procedure Foo; External; (* yields "Foo" *) Procedure ioCtl ( FilDes, Cmd: Integer; ... ); C; (* yields "ioctl" *) Procedure XOpenDisplay ( Name: __CString__ ); AsmName 'XOpenDisplay'; This turned out not to be enough; we need the same for variables. Actually we already have Var Foo: __external__ Integer; (* yields "foo", not "Foo"! *) but this does not cover cases where the external variable needs a name with a capital letter. As an intermediate solution, I implemented Var Foo: __asmname__ 'foO' Integer; (patched source is available on demand), but I think it is not the best way to implement these things. Now I am looking out for reasonable ideas. Does somebody know what the ISO/ANSI Standards say about this? My own thoughts follow. I would suggest to define as few directives as possible and to drop everything but `External' but extend its syntax to meet our requirements. A first approach could be Procedure foo; external; (* yields "Foo" *) Var x: Integer; external; (* yields "X" *) and Procedure foo; external 'foO'; Var x: Integer; external 'my_x'; but it would crash with Borland Pascal's use of `External' where the latter declaration would mean that Procedure foo is contained in a shared library named `foO'. Okay, so let's stay for the moment at Borland's syntax. In the same context they also define Procedure foo; external 'MySharedLib' index 42; and Procedure foo; external 'MySharedLib' name 'foO'; where `foO' would be the external name as defined in the shared library. My current idea now would be to define Procedure foo; external; (* yields "Foo" *) Var x: Integer; external; (* yields "X" *) plus Procedure foo; external name 'foO'; Var x: Integer; external name 'my_x'; to replace "AsmName 'foO'". Later we can extend this to allow a name of a shared library between `external' and `name'. Once doing this, it could also be nice to make directives out of the other C-style storage qualifiers, too. I mean I'd like to replace Var x: __static__ Integer; by x: Integer; static; y: __volatile__ Integer; by y: Integer; volatile; etc.. My plan is to do it in a way that things like Var static: Integer; would still work. I think it would *not* be a good idea to make Procedure foO; external; yield "foO", because (i) it would be difficult to implement and (ii) Pascal is a case-insensitive language, so everything outside string constants *must not* depend on casing at all. Please tell me your opinion about this. Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter From gpc-request@santra.hut.fi Sat Sep 7 22:11:42 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA16793 for ; Sat, 7 Sep 1996 22:11:42 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54722; Sat, 7 Sep 1996 22:20:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35932; Sat, 7 Sep 1996 22:19:41 +0200 Received: from hil-img-5.compuserve.com (hil-img-5.compuserve.com [149.174.177.135]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA06056 for ; Sat, 7 Sep 1996 23:03:16 +0300 (EET DST) Received: by hil-img-5.compuserve.com (8.6.10/5.950515) id QAA12028; Sat, 7 Sep 1996 16:02:44 -0400 Date: 07 Sep 96 16:01:03 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: External, C, AsmName, ... Message-Id: <960907200103_100120.3121_EHQ59-1@CompuServe.COM> Status: RO > Now I am looking out for reasonable ideas. Can we not simply see a C .h file as an interface-only module? I mean I can simply import a c .h file which gpc parses and all symbols defined in that header file are exported symbols? I don't know how far this is feasible. And it doesn't cover a.out modules creating using other languages (GNAT, ...). But it does cover the majority of cases you need externals. Groetjes, Berend. From gpc-request@santra.hut.fi Sun Sep 8 00:45:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA16931 for ; Sun, 8 Sep 1996 00:45:32 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68044; Sun, 8 Sep 1996 00:54:13 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65462; Sun, 8 Sep 1996 00:53:29 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA06887 for ; Sun, 8 Sep 1996 01:42:29 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA16885 for gpc@hut.fi; Sun, 8 Sep 1996 00:34:02 +0200 From: Peter Gerwinski Message-Id: <199609072234.AAA16885@agnes.dida.physik.uni-essen.de> Subject: Re: External, C, AsmName, ... To: gpc@hut.fi Date: Sun, 8 Sep 1996 00:34:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > Can we not simply see a C .h file as an interface-only module? I mean I can > simply import a c .h file which gpc parses and all symbols defined in that > header file are exported symbols? This would mean that GPC would have to parse C source. Remember that #include "foo.h" or (*$include "foo.h" *) just means that GPC treads the file `foo.h' just if its contents were written in our source file. A Pascal program using this mechanism would in fact look like the following: Program Test; extern int foo; extern void ioctl (int fildes, int cmd, ...); begin [...] end. You don't actually want this. ;-) > I don't know how far this is feasible. And it doesn't cover a.out modules > creating using other languages (GNAT, ...). But it does cover the majority of > cases you need externals. You can write a C header file for everything you want to import, independently of the language it was originally written in. Our point is that it must also be possible to write a *Pascal* interface for everything we want to import. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter From gpc-request@santra.hut.fi Sun Sep 8 09:58:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA17166 for ; Sun, 8 Sep 1996 09:58:32 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54620; Sun, 8 Sep 1996 10:07:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36706; Sun, 8 Sep 1996 10:06:21 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA08741 for ; Sun, 8 Sep 1996 11:01:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id JAA17145 for gpc@hut.fi; Sun, 8 Sep 1996 09:52:52 +0200 From: Peter Gerwinski Message-Id: <199609080752.JAA17145@agnes.dida.physik.uni-essen.de> Subject: Re: Compilation error To: gpc@hut.fi Date: Sun, 8 Sep 1996 09:52:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > When I try to compile anything, even the simplest program, I get: > /usr/i486-linux/bin/ld: cannot open crt0.o: No such file or directory Perhaps the versions of GCC and GPC you are using don't coincide. Please check the following: gpc -c myprogram.pas gcc myprogram.o -o myprogram i.e. compile with GPC, but link with GCC. Did you already check that crt0.o is in a directory where GPC can find it? I remember some problems when I had crt0.o in the directory /usr/lib/gcc-lib/i486-unknown-linux/2.6.3. The problems disappeared when I moved the file to /usr/lib or /usr/local/lib. Good luck, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From lotu@wam.umd.edu Sun Sep 8 18:57:31 1996 Return-Path: lotu@wam.umd.edu Received: from po2.wam.umd.edu (po2.wam.umd.edu [128.8.70.134]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id SAA17664 for ; Sun, 8 Sep 1996 18:57:29 +0200 Received: from rac9.wam.umd.edu (rac9.wam.umd.edu [128.8.70.109]) by po2.wam.umd.edu (8.7.5/8.7.3) with ESMTP id NAA09704; Sun, 8 Sep 1996 13:05:28 -0400 (EDT) Received: from localhost (lotu@localhost) by rac9.wam.umd.edu (8.7.5/8.7.3) with SMTP id NAA10508; Sun, 8 Sep 1996 13:05:26 -0400 (EDT) X-Authentication-Warning: rac9.wam.umd.edu: lotu owned process doing -bs Date: Sun, 8 Sep 1996 13:05:26 -0400 (EDT) From: Arcadio Alivio Sincero To: Peter Gerwinski cc: gpc@hut.fi Subject: Re: External, C, AsmName, ... In-Reply-To: <199609071300.PAA16424@agnes.dida.physik.uni-essen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sat, 7 Sep 1996, Peter Gerwinski wrote: > Hello folks, > > (* This mail is somehow long. In short: I want to take > the directives `Extern', `C', and `AsmName' *out* of GPC > and extend the syntax of `External' instead. Okay? :*) > I would suggest to define as few directives as possible and to > drop everything but `External' but extend its syntax to meet our > requirements. A first approach could be Good idea. Having 3 directives which basically do the same thing is pretty stupid. > My current idea now would be to define > > Procedure foo; external; (* yields "Foo" *) > > Var > x: Integer; external; (* yields "X" *) > > plus > > Procedure foo; external name 'foO'; > > Var > x: Integer; external name 'my_x'; > > to replace "AsmName 'foO'". Later we can extend this to allow a > name of a shared library between `external' and `name'. No objections to this idea from me. Anybody else? Hey ... did y'all know that a Linux version of FPKPascal (or is it just FPPascal??) is now out (currently only a.out but and ELF version is expected soon). One thing I like about FPKPascal is that it has function overloading. Any plans of adding this to GPC? This would be a nice thing to throw in, IMHO. =============================================================================== Arcadio Alivio Sincero, Jr. Sophomore, Computer Science Major at the University of Maryland at College Park Amateur competitive bodybuilder Email: lotu@wam.umd.edu, WWW: "D.A.R.E. .... to keep cops off donuts." From gpc-request@santra.hut.fi Sun Sep 8 10:44:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA17204 for ; Sun, 8 Sep 1996 10:44:17 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54712; Sun, 8 Sep 1996 10:52:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48364; Sun, 8 Sep 1996 10:52:05 +0200 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA09589 for ; Sun, 8 Sep 1996 11:46:52 +0300 (EET DST) Received: from shiloh.nimh.nih.gov (shiloh.nimh.nih.gov [156.40.186.3]) by kampi.hut.fi (8.6.11/8.6.7) with ESMTP id LAA01446 for ; Sun, 8 Sep 1996 11:46:45 +0300 Received: by shiloh.nimh.nih.gov (SMI-8.6/SMI-SVR4) id EAA14078; Sun, 8 Sep 1996 04:45:18 -0400 Date: Sun, 8 Sep 1996 04:45:18 -0400 From: brad@shiloh.nimh.nih.gov (Brad J Zoltick(RSB) 36-2A03) Message-Id: <199609080845.EAA14078@shiloh.nimh.nih.gov> To: gpc@kampi.hut.fi Subject: gpc for Solaris 2.5.1 Status: RO Hi, Is there a version of gpc built for Solaris 2.5? Or do you have any hints on getting the lastest source to compile under Solaris 2.5? Thanks Brad Zoltick NIH Email: brad@codon.nih.gov From gpc-request@santra.hut.fi Mon Sep 9 16:13:30 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA19399 for ; Mon, 9 Sep 1996 16:13:30 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57764; Mon, 9 Sep 1996 16:21:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42428; Mon, 9 Sep 1996 16:20:52 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA09387 for ; Mon, 9 Sep 1996 17:05:23 +0300 (EET DST) Received: from [130.89.179.50] (pc050.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA07686 (5.67b/IDA-1.5 for ); Mon, 9 Sep 1996 16:05:20 +0200 Date: Mon, 9 Sep 96 16:18:21 CST From: "J.J. van der Heijden" Message-Id: <70105.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: External, C, AsmName, ... Status: RO On Sun, 8 Sep 1996 00:34:02 +0200 (MET DST), Peter Gerwinski wrote: >According to Berend de Boer: >> Can we not simply see a C .h file as an interface-only module? I mean I can >> simply import a c .h file which gpc parses and all symbols defined in that >> header file are exported symbols? > >This would mean that GPC would have to parse C source. > >Remember that #include "foo.h" or (*$include "foo.h" *) just means >that GPC treads the file `foo.h' just if its contents were written >in our source file. A Pascal program using this mechanism would >in fact look like the following: > > Program Test; > > extern int foo; > > extern void ioctl (int fildes, int cmd, ...); > > begin > [...] > end. > >You don't actually want this. ;-) > No, I don't :) But it would be a good idea to write a C->pas header converter. Right now, you have to translate all headers before you can use them. janjaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Tue Sep 10 17:29:44 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA21446 for ; Tue, 10 Sep 1996 17:29:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64264; Tue, 10 Sep 1996 17:37:26 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49482; Tue, 10 Sep 1996 17:36:42 +0200 Received: from cc.cst.cmich.edu (mail.cc.cst.cmich.edu [141.209.21.37]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA16355 for ; Tue, 10 Sep 1996 18:13:10 +0300 (EET DST) Received: from cps200.cps.cmich.edu (cps200.cps.cmich.edu [141.209.20.200]) by cc.cst.cmich.edu (8.7.5/8.7.3) with SMTP id LAA17657; Tue, 10 Sep 1996 11:12:21 -0400 (EDT) Date: Tue, 10 Sep 1996 11:12:16 -0400 (EDT) From: M BAILEY X-Sender: mbailey@cps200.cps.cmich.edu To: "J.J. van der Heijden" Cc: gpc@hut.fi Subject: Re: gpc for Solaris 2.5.1 In-Reply-To: <71634.s8806144@mail.student.utwente.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO If someone sends me a merged source tree of GCC and GPC i would be happy to compile them into a finished binary product and possible build solaris pkg's out the resulting answers to that you can install them with out needing any other utilities... Matthew S. Bailey On Tue, 10 Sep 1996, J.J. van der Heijden wrote: > On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), > Peter Gerwinski wrote: > > >Hi Phil, Brad, and Jan Jaap, > > > > stor-layout & friends ARE BACK ... > > > >> I wish that was true. Here is the results on my machine. > >> maybe_find_function_data gpc-parse.o > >> [...] > >> dbxout_set_type_status gpc-decl.o > > > >I know that problem. It is a bug in make, Jan Jaap and I had > >hoped to have worked around. The problem is that there are > >language independend source files which exist in the GPC source > >as well as in the GCC source. In Makefile, look out for > >stor-layout.o, dbxout.o, ..., toplev.o. For some reason, > >they are not recompiled correctly. > > > > What happens precisely is that "make" has a VPATH: it looks for object code > in the gcc object directory too. When your gcc object directory is > identical to your gcc source directory, make thinks $gccbin/foo.o is > uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can > see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on > $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc) > > To make it more complicated, VPATH behaviour of various "make" programs > is different and some versions of GNU make have VPATH bugs. > > >To work around, you can create these *.o files and copy them > >into the gcc directory, so "make gpc" will find and use them. > > > > Use different directories for $gccsrc and $gccbin. > Or delete the ones in $gccbin to force make to rebuild them. > > /janjaap > > --- > The latest & greatest in software, hardware and manswear. > Bono Vox (U2) > From gpc-request@santra.hut.fi Tue Sep 10 17:45:28 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA21465 for ; Tue, 10 Sep 1996 17:45:27 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55466; Tue, 10 Sep 1996 17:53:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51676; Tue, 10 Sep 1996 17:52:23 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA16317 for ; Tue, 10 Sep 1996 18:39:28 +0300 (EET DST) Received: from [130.89.179.45] (pc045.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA07083 (5.67b/IDA-1.5 for ); Tue, 10 Sep 1996 17:39:27 +0200 Date: Tue, 10 Sep 96 17:52:35 CST From: "J.J. van der Heijden" Message-Id: <75252.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: gpc for Solaris 2.5.1 Status: RO On Tue, 10 Sep 1996 11:12:16 -0400 (EDT), M BAILEY wrote: > >If someone sends me a merged source tree of GCC and GPC i would be happy to >compile them into a finished binary product and possible build solaris pkg's >out the resulting answers to that you can install them with out needing any >other utilities... > If you can build a ready-to-run compiler we would be happy to distribute it. There is no merged source tree: you put gpc and gcc in their own directory. Because I have not updated the INSTALL file for a while, I shall shortly explain what to do: (I assume solaris is properly supported bu GCC) If you extract gcc-2.7.2.tar.gz and gpc-1.2-2.7.2.tar.gz from the same location, you get gcc-2.7.2 and gpc-1.2-2.7.2 subdirs, which is just fine. 1) configure and build gcc: ./configure make CFLAGS=-O2 LDFLAGS=-s LANGUAGS=c If this fails, build gcc with -O0 and build a stage2 compiler with this the stage1 gcc, then go on (this is all explained in GCC manuals) 2) configure gpc: ./configure configure should be able to find the gcc directory if it is reasonably "close". If not, run configure --help and see what options you must give it. 3) build gpc: make CFLAGS=-O2 LDFLAGS=-s Read earlier notes about what to do if VPATH troubles strike (below). BSD/SYSV signal confusion (RTS won't build) *may* be avoided by using a newer configure (message posted this list a few minutes ago) If not, I would like to know whether configure decides you have SYSV or BSD (and if you know if this is incorrect, possibly see your and . 4) A binary distribution can be created with the "make bindist" command. I'm not familiar with the habbits of solaris pkgtools, so you may have to tweak it by hand (you should know this). Hope this helps, JanJaap >Matthew S. Bailey > > >On Tue, 10 Sep 1996, J.J. van der Heijden wrote: > >> On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), >> Peter Gerwinski wrote: >> >> >Hi Phil, Brad, and Jan Jaap, >> > >> > stor-layout & friends ARE BACK ... >> > >> >> I wish that was true. Here is the results on my machine. >> >> maybe_find_function_data gpc-parse.o >> >> [...] >> >> dbxout_set_type_status gpc-decl.o >> > >> >I know that problem. It is a bug in make, Jan Jaap and I had >> >hoped to have worked around. The problem is that there are >> >language independend source files which exist in the GPC source >> >as well as in the GCC source. In Makefile, look out for >> >stor-layout.o, dbxout.o, ..., toplev.o. For some reason, >> >they are not recompiled correctly. >> > >> >> What happens precisely is that "make" has a VPATH: it looks for object code >> in the gcc object directory too. When your gcc object directory is >> identical to your gcc source directory, make thinks $gccbin/foo.o is >> uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can >> see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on >> $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc) >> >> To make it more complicated, VPATH behaviour of various "make" programs >> is different and some versions of GNU make have VPATH bugs. >> >> >To work around, you can create these *.o files and copy them >> >into the gcc directory, so "make gpc" will find and use them. >> > >> >> Use different directories for $gccsrc and $gccbin. >> Or delete the ones in $gccbin to force make to rebuild them. >> >> /janjaap >> --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Tue Sep 10 17:20:26 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA21440 for ; Tue, 10 Sep 1996 17:20:26 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46146; Tue, 10 Sep 1996 17:28:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51564; Tue, 10 Sep 1996 17:27:24 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA16546 for ; Tue, 10 Sep 1996 18:17:58 +0300 (EET DST) Received: from [130.89.179.45] (pc045.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA04645 (5.67b/IDA-1.5 for ); Tue, 10 Sep 1996 17:17:56 +0200 Date: Tue, 10 Sep 96 17:31:04 CST From: "J.J. van der Heijden" Message-Id: <74077.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: SYSV vs BSD confusion Status: RO Hello, There has been some confusion about detecting BSD style signals versus SYSV style. I have updated the configure script to be less fascist about BSD and hopefully this fixes the problems. Get it from: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/updates/ Now, hopefully, FreeBSD is considered BSD again (Peter?) I think SunOS and Solaris are BSD variants too, right? If this still doesn't work, I would like to see your and header files. The problem is that some SYSV systems #define these BSD signals but don't support them unless you link -lbsd, so I made BSD detection more strict (so strict in fact that FreeBSD was no longer considered BSD ;-) Hope this helps, JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Tue Sep 10 17:02:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA21403 for ; Tue, 10 Sep 1996 17:02:07 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51288; Tue, 10 Sep 1996 17:09:50 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28316; Tue, 10 Sep 1996 17:09:05 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA15167 for ; Tue, 10 Sep 1996 17:33:13 +0300 (EET DST) Received: from [130.89.179.45] (pc045.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA28718 (5.67b/IDA-1.5 for ); Tue, 10 Sep 1996 16:33:11 +0200 Date: Tue, 10 Sep 96 16:46:20 CST From: "J.J. van der Heijden" Message-Id: <71634.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: gpc for Solaris 2.5.1 Status: RO On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), Peter Gerwinski wrote: >Hi Phil, Brad, and Jan Jaap, > > stor-layout & friends ARE BACK ... > >> I wish that was true. Here is the results on my machine. >> maybe_find_function_data gpc-parse.o >> [...] >> dbxout_set_type_status gpc-decl.o > >I know that problem. It is a bug in make, Jan Jaap and I had >hoped to have worked around. The problem is that there are >language independend source files which exist in the GPC source >as well as in the GCC source. In Makefile, look out for >stor-layout.o, dbxout.o, ..., toplev.o. For some reason, >they are not recompiled correctly. > What happens precisely is that "make" has a VPATH: it looks for object code in the gcc object directory too. When your gcc object directory is identical to your gcc source directory, make thinks $gccbin/foo.o is uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc) To make it more complicated, VPATH behaviour of various "make" programs is different and some versions of GNU make have VPATH bugs. >To work around, you can create these *.o files and copy them >into the gcc directory, so "make gpc" will find and use them. > Use different directories for $gccsrc and $gccbin. Or delete the ones in $gccbin to force make to rebuild them. /janjaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Fri Aug 30 18:32:54 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA03451 for ; Fri, 30 Aug 1996 18:32:54 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61684; Fri, 30 Aug 1996 18:44:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87356; Fri, 30 Aug 1996 18:43:59 +0200 Received: from eeyore.lv-hrc.nevada.edu (eeyore.lv-hrc.nevada.edu [131.216.27.16]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id TAA10376 for ; Fri, 30 Aug 1996 19:33:30 +0300 (EET DST) Received: from scooby.lv-hrc.nevada.edu (scooby.lv-hrc.nevada.edu [131.216.27.8]) by eeyore.lv-hrc.nevada.edu (8.7.1/8.7.1) with SMTP id JAA14810 for ; Fri, 30 Aug 1996 09:33:22 -0700 Message-Id: <32271826.2752@hrc.nevada.edu> Date: Fri, 30 Aug 1996 09:34:46 -0700 From: Harry Reed Reply-To: doon@eeyore.lv-hrc.nevada.edu Organization: UNLV/HRC X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: Problem with constant strings in gpc 1.2(2.7.2)#7 ??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi, In the users' manual chapter "About Pascal and Extended Pascal languages" there is a small example on how to initialize constant strings. When I try compiling the fragment with gpc 1.2(2.7.2)#7 I get the error messages as showm below. Is this a valid bug or am I just doing something wrong? Cheers, Harry Reed doon@hrc.nevada.edu PS: Great work on GPC! Keep it up!!!! source program --- cut here --- 8< --- cut here --- 8< --- cut here --- program test; const MyStringsCount = 5; type Ident = string(20); var MyStrings : array [1..MyStringsCount] of Ident value [ 1:'EXPORT'; 2:'IMPLEMENTATION'; 3:'IMPORT'; 4:'INTERFACE'; 5:'MODULE']; begin end. compiler output --- cut here --- 8< --- cut here --- 8< --- cut here --- test.pas: In function `test': test.pas:9: parse error before `:' test.pas:9: Set constructor elements must be of ordinal type test.pas:9: missing comma test.pas:9: parse error before `;' test.pas:9: missing comma test.pas:9: parse error before `:' test.pas:9: Set constructor elements must be of ordinal type test.pas:9: missing comma test.pas:9: parse error before `;' test.pas:9: missing comma test.pas:9: parse error before `:' test.pas:9: Set constructor elements must be of ordinal type test.pas:9: missing comma test.pas:9: parse error before `;' test.pas:10: missing comma test.pas:10: parse error before `:' test.pas:10: Set constructor elements must be of ordinal type test.pas:10: missing comma test.pas:10: parse error before `;' test.pas:10: missing comma test.pas:10: initial value is of wrong type From gpc-request@santra.hut.fi Wed Sep 11 08:06:57 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA22299 for ; Wed, 11 Sep 1996 08:06:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51430; Wed, 11 Sep 1996 08:14:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43414; Wed, 11 Sep 1996 08:13:42 +0200 Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [149.174.217.132]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id JAA28580 for ; Wed, 11 Sep 1996 09:03:54 +0300 (EET DST) Received: by arl-img-2.compuserve.com (8.6.10/5.950515) id CAA25597; Wed, 11 Sep 1996 02:03:20 -0400 Date: 11 Sep 96 01:40:43 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: External, C, AsmName, ... Message-Id: <960911054042_100120.3121_EHQ47-10@CompuServe.COM> Status: RO > But it would be a good idea to write a C->pas header converter. Right now, > you have to translate all headers before you can use them. There is a translator for BP, mabe it's easy to adapt this one? Groetjes, Berend. From gpc-request@santra.hut.fi Wed Sep 11 22:07:19 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA23097 for ; Wed, 11 Sep 1996 22:07:19 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51154; Wed, 11 Sep 1996 22:14:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65096; Wed, 11 Sep 1996 22:13:51 +0200 Received: from hil-img-1.compuserve.com (hil-img-1.compuserve.com [149.174.177.131]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA26866 for ; Wed, 11 Sep 1996 23:03:49 +0300 (EET DST) Received: by hil-img-1.compuserve.com (8.6.10/5.950515) id QAA02548; Wed, 11 Sep 1996 16:03:16 -0400 Date: 11 Sep 96 16:01:47 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: SYSV vs BSD signal blues :-( Message-Id: <960911200147_100120.3121_EHQ78-6@CompuServe.COM> Status: RO > I think I'll just rewrite the signal related stuff in rts-rt0.c, implement > some BSD/SYSV independant routines that ONLY mask signals that are actually > present on the target system. I don't have handson experience with signals, but it seems to me that POSIX already did this. I suggest using signals according to the POSIX standard. And every unix box should come with some decent posix library these days. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Sep 11 22:06:00 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA23093 for ; Wed, 11 Sep 1996 22:06:00 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51142; Wed, 11 Sep 1996 22:13:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61440; Wed, 11 Sep 1996 22:12:33 +0200 Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA26629 for ; Wed, 11 Sep 1996 23:03:23 +0300 (EET DST) Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id QAA19660; Wed, 11 Sep 1996 16:02:51 -0400 Date: 11 Sep 96 16:01:42 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: New win32 binaries almost done. please read. Message-Id: <960911200142_100120.3121_EHQ78-5@CompuServe.COM> Status: RO > So, shall I wrap these components in a seperate ZIP (windev.zip or > whatever) and upload them too? Great idea. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Sep 11 16:13:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA22899 for ; Wed, 11 Sep 1996 16:13:08 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59772; Wed, 11 Sep 1996 16:20:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36956; Wed, 11 Sep 1996 16:19:46 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA16443 for ; Wed, 11 Sep 1996 16:47:27 +0300 (EET DST) Received: from [130.89.179.43] (pc043.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA13893 (5.67b/IDA-1.5 for ); Wed, 11 Sep 1996 15:47:26 +0200 Date: Wed, 11 Sep 96 16:00:43 CST From: "J.J. van der Heijden" Message-Id: <69142.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: New win32 binaries almost done. please read. Status: RO Hello, I'm almost done building a cygwin32-beta16 compatible GPC. It fixes a number of problems, like the hanging of GPC1 in "automake" (fork() related problems) Also, the -pipe option is now supported. The current cygwin32 b16 toolchain is a 25Meg ZIP, eating up >80Meg disk when installed. For those who only want to do Pascal, this is a complete waist because you only need binutils and some libraries from it. So, shall I wrap these components in a seperate ZIP (windev.zip or whatever) and upload them too? JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Wed Sep 11 15:51:20 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA22887 for ; Wed, 11 Sep 1996 15:51:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62500; Wed, 11 Sep 1996 15:58:43 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61344; Wed, 11 Sep 1996 15:57:58 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA16908 for ; Wed, 11 Sep 1996 16:41:38 +0300 (EET DST) Received: from [130.89.179.43] (pc043.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA13188 (5.67b/IDA-1.5 for ); Wed, 11 Sep 1996 15:41:37 +0200 Date: Wed, 11 Sep 96 15:54:54 CST From: "J.J. van der Heijden" Message-Id: <68824.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: SYSV vs BSD signal blues :-( Status: RO Hello, We've seen some signal related troubles when building the RTS lately. This is about what's happening: * GPC's RTS installs a signal handler to give pretty error messages when a signal is caught. This is ONLY implemented for BSD like systems, probably because Juki didn't have access to a SYSV style box. * SYSV and BSD differ in the number of signals and their meaning. * Some BSD boxes don't implement all signals > 16. (SIGXCPU etc.) * Some SYSV boxes implement (a range of) BSD-only signals, making it hard to dectect a true BSD box. I'm getting tired of writing ever more clever system identification routines that break on the next system I encounter. I think I'll just rewrite the signal related stuff in rts-rt0.c, implement some BSD/SYSV independant routines that ONLY mask signals that are actually present on the target system. How 'bout it? JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Wed Sep 11 10:44:45 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA22487 for ; Wed, 11 Sep 1996 10:44:45 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59130; Wed, 11 Sep 1996 10:52:13 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62842; Wed, 11 Sep 1996 10:51:28 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA20100 for ; Wed, 11 Sep 1996 11:23:34 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id KAA22457 for gpc@hut.fi; Wed, 11 Sep 1996 10:16:22 +0200 From: Peter Gerwinski Message-Id: <199609110816.KAA22457@agnes.dida.physik.uni-essen.de> Subject: Re: External, C, AsmName, ... To: gpc@hut.fi Date: Wed, 11 Sep 1996 10:16:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi everybody, According to Berend de Boer: > There is a translator for BP, mabe it's easy to adapt this one? Where is it? Since GPC is essentially BP-compatible now, perhaps we can just use it? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Sep 12 10:48:13 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA23587 for ; Thu, 12 Sep 1996 10:48:13 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44818; Thu, 12 Sep 1996 10:55:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39810; Thu, 12 Sep 1996 10:54:34 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA07645 for ; Thu, 12 Sep 1996 11:42:11 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Thu, 12 Sep 96 10:42 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v17Jr-000V8MC; Thu, 12 Sep 96 10:40 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 12 Sep 1996 10:31:20 +0200 Date: 11 Sep 1996 14:06:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6GfTfb--lJB@rufus.central.de> Subject: I don't unterstand __byte__ :-( X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi all, the following example I've used to test the __byte__ and __short__ types. There was some trouble while using the GRX20-library (I'm working on a interface-unit) with conversion of different structures. Look at my sample and say me why I can't get the correct value from Bytes. program ByteTest; const arHex : array[0..$0f] of char = '0123456789abcdef'; max = 15; type WrkStr = String(255); var a32 : array[0..max] of Integer; a16 : array[0..max] of __short__ Integer absolute a32; a8 : array[0..max] of __byte__ Integer absolute a32; a_c : array[0..max] of char absolute a32; i : Integer; function hexa(number: Integer): WrkStr; var i : Integer; s : WrkStr; begin s := ''; for i := 1 to 8 do begin s := arHex[number and $0f] + s; number := number shr 4; end; hexa := ' $'+s; end; begin for i := 0 to max do a_c[i] := chr(i); for i := 0 to max do begin write(i: 3); write(ord(a_c[i]): 5); write(a8[i]: 10); if i mod 2 = 0 then write(a16[i div 2]: 10); if i mod 4 = 0 then write(a32[i div 4]: 16); writeln; end; for i := 0 to max do begin write(i: 3); write(hexa(ord(a_c[i]))); write(hexa(a8[i])); if i mod 2 = 0 then write(hexa(a16[i div 2])); if i mod 4 = 0 then write(hexa(a32[i div 4])); writeln; end; end. I'm using the DJGPP-GPC on MS-DOS and that's the output: 0 0 34560 256 50462976 1 1 34561 2 2 34562 770 3 3 34563 4 4 34564 1284 117835012 5 5 34565 6 6 34566 1798 7 7 34567 8 8 34568 2312 185207048 9 9 34569 10 10 34570 2826 11 11 34571 12 12 34572 3340 252579084 13 13 34573 14 14 34574 3854 15 15 34575 0 $00000000 $00000000 $00000100 $03020100 1 $00000001 $00000001 2 $00000002 $00000002 $00000302 3 $00000003 $00000003 4 $00000004 $00000004 $00000504 $07060504 5 $00000005 $00000005 6 $00000006 $00000006 $00000706 7 $00000007 $00000007 8 $00000008 $00000008 $00000908 $0b0a0908 9 $00000009 $00000009 10 $0000000a $0000000a $00000b0a 11 $0000000b $0000000b 12 $0000000c $0000000c $00000d0c $0f0e0d0c 13 $0000000d $0000000d 14 $0000000e $0000000e $00000f0e 15 $0000000f $0000000f Please don't quote the whole text !!! ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Thu Sep 12 13:21:03 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA23832 for ; Thu, 12 Sep 1996 13:21:03 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53530; Thu, 12 Sep 1996 13:28:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53580; Thu, 12 Sep 1996 13:27:21 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA12440 for ; Thu, 12 Sep 1996 14:09:28 +0300 (EET DST) Received: from [130.89.179.27] (PC027.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA10500 (5.67b/IDA-1.5 for ); Thu, 12 Sep 1996 13:09:26 +0200 Date: Thu, 12 Sep 96 13:22:49 CST From: "J.J. van der Heijden" Message-Id: <60517.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: SYSV vs BSD signal blues :-( Status: RO On 11 Sep 96 16:01:47 EDT, Berend de Boer <100120.3121@CompuServe.COM> wrote: >> I think I'll just rewrite the signal related stuff in rts-rt0.c, implement >> some BSD/SYSV independant routines that ONLY mask signals that are actually >> present on the target system. > >I don't have handson experience with signals, but it seems to me that POSIX >already did this. I suggest using signals according to the POSIX standard. > >And every unix box should come with some decent posix library these days. > POSIX describes a "minimum set" of signals that must be present in a system. It's the non-POSIX, system specific signals that caused the confusion here. Of course I could just remove all non-POSIX stuff from GPC, but I don't think that's necessary. It also shouldn't be hard to implement a runtime switch to turn signal catching off altogether to enable coredumps, like somebody else suggested. JanJaap --- The latest & greatest in software, hardware and manswear. Bono Vox (U2) From gpc-request@santra.hut.fi Thu Sep 12 11:58:26 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA23722 for ; Thu, 12 Sep 1996 11:58:26 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57846; Thu, 12 Sep 1996 12:05:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53246; Thu, 12 Sep 1996 12:04:47 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id MAA10086 for ; Thu, 12 Sep 1996 12:46:56 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA23685 for gpc@hut.fi; Thu, 12 Sep 1996 11:40:08 +0200 From: Peter Gerwinski Message-Id: <199609120940.LAA23685@agnes.dida.physik.uni-essen.de> Subject: Re: I don't unterstand __byte__ :-( To: gpc@hut.fi Date: Thu, 12 Sep 1996 11:40:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi all, > const > arHex : array[0..$0f] of char > = '0123456789abcdef'; Nice that this works. I was sure it wouldn't work. ;-) > a8 : array[0..max] of __byte__ Integer absolute a32; > > write(a8[i]: 10); > 1 1 34561 > > write(hexa(a8[i])); > 1 $00000001 $00000001 Symptoms: the value of a __byte__ Integer is written correctly via the "hexa" function, it's wrong when we simply "write" it. This is due to a BUG in GPC's run tims system (RTS) which doesn't (yet) know about type modifiers like __byte__ at all. :-( For the same reason, you get run time errors when you try to writeln __longlong__ (64-bit) Integers (\approx Comp in BP) or __long__ Reals (Extended in BP). To work around, do an explicit type cast: > write ( Integer ( a8 [ i ] ) : 10 ); > 1 1 1 Bye, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Sep 17 02:15:10 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA28388 for ; Tue, 17 Sep 1996 02:15:09 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75456; Tue, 17 Sep 1996 02:20:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60378; Tue, 17 Sep 1996 02:19:49 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id DAA06469 for ; Tue, 17 Sep 1996 03:11:34 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Tue, 17 Sep 96 02:11 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v2nkx-000Yy4C; Tue, 17 Sep 96 02:11 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 17 Sep 1996 02:06:21 +0200 Date: 17 Sep 1996 02:00:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6H2bsjJ-lJB@rufus.central.de> Subject: how to write binary datas in a file X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi folks, another stupid problem: I tryed to write binary datas in a file. I can use only the "write" function - the result is all $0A will be converted into "$0D $0A" - Yes, thats the CrLf - I think it's no problem under UNIX, Linux, Ponyx, Limbux etc. :-) How can I write binary datas in a file? It must be work in MS-DOS !!! ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Wed Sep 18 18:49:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA30206 for ; Wed, 18 Sep 1996 18:49:40 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61654; Wed, 18 Sep 1996 18:54:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83370; Wed, 18 Sep 1996 18:53:42 +0200 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id TAA12598 for ; Wed, 18 Sep 1996 19:31:42 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id MAA18635 for ; Wed, 18 Sep 1996 12:34:01 -0400 Date: Wed, 18 Sep 1996 12:34:01 -0400 (EDT) From: John Michael Black Reply-To: John Michael Black To: gpc@hut.fi Subject: Which version/location Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Okay, we've upgraded to Linux 2.0 with gcc 2.7.2. We can use either ELF or a.out, (although we prefer ELF.) Which version would be best for this configuration? [At one time we had one problem with GPC lookng for "crt0.o". Our configuration doesn't even have this file, but perhaps (as Peter suggested) we had the wrong compiler version.] -john jm_black@csunix1.lvc.edu From gpc-request@santra.hut.fi Wed Sep 18 17:41:16 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA30126 for ; Wed, 18 Sep 1996 17:41:16 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66348; Wed, 18 Sep 1996 17:46:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28920; Wed, 18 Sep 1996 17:45:19 +0200 Received: from agnes.dida.physik.uni-essen.de (root@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA11347 for ; Wed, 18 Sep 1996 18:33:11 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA29146 for gpc@hut.fi; Tue, 17 Sep 1996 14:18:02 +0200 From: Peter Gerwinski Message-Id: <199609171218.OAA29146@agnes.dida.physik.uni-essen.de> Subject: Re: how to write binary datas in a file To: gpc@hut.fi Date: Tue, 17 Sep 1996 14:18:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Sven, hi everybody, > I can use only the "write" function - the result is all $0A will be > converted into "$0D $0A" - Yes, thats the CrLf - Yes, that's even true for "File of Integer"! Congratulations - you have discovered a serious bug in the Run Time Library. :-( > I think it's no problem > under UNIX, Linux, Ponyx, Limbux etc. :-) Yes, it isn't. Your diagnostics was right. > How can I write binary datas in a file? > It must be work in MS-DOS !!! I'd like to fix it as soon as possible, but I am out of time right now. :-( :-( Anybody out there to do it? The error must be in rts/rts-write.c, something with fopen() ... Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Wed Sep 18 17:28:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA30090 for ; Wed, 18 Sep 1996 17:28:33 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60046; Wed, 18 Sep 1996 17:33:23 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69694; Wed, 18 Sep 1996 17:32:36 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA28015 for ; Wed, 18 Sep 1996 11:13:37 +0300 (EET DST) Received: from [130.89.179.36] (pc036.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA14172 (5.67b/IDA-1.5 for ); Wed, 18 Sep 1996 10:13:35 +0200 Date: Wed, 18 Sep 96 10:27:42 CST From: "J.J. van der Heijden" Message-Id: <50954.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: how to write binary datas in a file Status: RO On 17 Sep 1996 02:00:00 +0200, Sven Hilscher wrote: > >Hi folks, > >another stupid problem: > >I tryed to write binary datas in a file. >I can use only the "write" function - the result is all $0A will be >converted into "$0D $0A" - Yes, thats the CrLf - I think it's no problem >under UNIX, Linux, Ponyx, Limbux etc. :-) > Yep - a bug. djgpp opens all files in textmode unless instructed otherwise, which the RTS _should_ do for all files not of type TEXT. Unfortunately, a quick fix broke the standard "Input" and "Output" so please wait a few more days 'till I have time to do this the right way. >How can I write binary datas in a file? >It must be work in MS-DOS !!! > Win32 affected too probably. Hey Peter, does OS/2 (EMX) discriminate between text and binary files like DOS, or not, like unix? JanJaap --- Someone once asked me if they could use Open Windows on a Mac. I said, "I don't know. Let's find out." I went to the Mac, opened the window and threw out the Mac. "Yep, You can use Open Windows on a Mac." bofh@RedDragon.Empire.Net (Psycho Sysadmin) From gpc-request@santra.hut.fi Thu Sep 19 13:13:28 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA31033 for ; Thu, 19 Sep 1996 13:13:28 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46270; Thu, 19 Sep 1996 13:18:00 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59468; Thu, 19 Sep 1996 13:17:11 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA15976 for ; Thu, 19 Sep 1996 13:51:10 +0300 (EET DST) Received: from slp06164.slip.utwente.nl by driene.student.utwente.nl with SMTP id AA18094 (5.67b/IDA-1.5 for ); Thu, 19 Sep 1996 12:51:07 +0200 Message-Id: <2.2.32.19960919105219.0068b5e8@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Sep 1996 12:52:19 +0200 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: how to write binary datas in a file Status: RO At 02:18 PM 9/17/96 +0200, you wrote: >Hi Sven, hi everybody, > >> I can use only the "write" function - the result is all $0A will be >> converted into "$0D $0A" - Yes, thats the CrLf - > >Yes, that's even true for "File of Integer"! Congratulations - you >have discovered a serious bug in the Run Time Library. :-( > >> I think it's no problem >> under UNIX, Linux, Ponyx, Limbux etc. :-) > >Yes, it isn't. Your diagnostics was right. > >> How can I write binary datas in a file? >> It must be work in MS-DOS !!! > >I'd like to fix it as soon as possible, but I am out of time right now. >:-( :-( > >Anybody out there to do it? The error must be in rts/rts-write.c, >something with fopen() ... > I fixed this problem with the MS-DOS files, but it broke some the "standard" files "Input" and "Output". I will think of something more elegant soon. Probably change the BSD style 'fopen()' calls to 'open()' too because then I can easily add an #ifdef MSDOS flags = flags | O_BINARY; #endif once, instead of #iddef-ing every instance of fopen which eats "r" , "w" arguments (which become "wb" etc for non-text files in dos & co.) greetings, JanJaap -- The latest & greates in software, hardware and manswear -- Bono Vox (U2) From gpc-request@santra.hut.fi Thu Sep 19 10:19:09 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA30828 for ; Thu, 19 Sep 1996 10:19:09 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54060; Thu, 19 Sep 1996 10:23:44 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43414; Thu, 19 Sep 1996 10:22:57 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA09564 for ; Thu, 19 Sep 1996 11:09:48 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id KAA30812 for gpc@hut.fi; Thu, 19 Sep 1996 10:05:33 +0200 From: Peter Gerwinski Message-Id: <199609190805.KAA30812@agnes.dida.physik.uni-essen.de> Subject: Problems with DJGPP info files To: gpc@hut.fi Date: Thu, 19 Sep 1996 10:05:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Subject: Re: gnu pascal info problems Newsgroups: comp.os.msdos.djgpp References: <323E879C.3047@blackmagic.tait.co.nz> Organization: Universitaet Essen, Germany Reply-To: peter.gerwinski@uni-essen.de Distribution: Bill Currie (billc@blackmagic.tait.co.nz) wrote: > I'm having problems getting info to browse the info files from gpc 2.7.2. > Info can't 'Top'. I've tried dtou, re-makeing the files with and without > splitting, and dtou-ing again, to no avail (trying before and after > dtou). This is a bug in the GPC info. Thank you for the report. To fix it, you can re-make the info with djgpp's "makeinfo", but you have to edit "gpc.txi" before and replace all "@include foo.texi" by "@include foo.txi". (Fortunately, the other files do not contain "@include" commands. :-) (Also posted to the GPC mailing list.) Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Fri Sep 20 20:52:49 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA00100 for ; Fri, 20 Sep 1996 20:52:48 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66338; Fri, 20 Sep 1996 20:56:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83250; Fri, 20 Sep 1996 20:56:06 +0200 Received: from scruz.net (nic.scruz.net [165.227.1.2]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id VAA30534 for ; Fri, 20 Sep 1996 21:43:53 +0300 (EET DST) Received: from adaq.adaq.com by scruz.net (8.7.3/1.34) id LAA06124; Fri, 20 Sep 1996 11:42:40 -0700 (PDT) Received: from engg2 by adaq.adaq.com id aa12565; 20 Sep 96 11:31 PDT Received: from engg3.mobinfo.com by engg2.adaq.com (4.1/SMI-4.1) id AA04448; Fri, 20 Sep 96 11:35:23 PDT Received: by engg3.mobinfo.com (SMI-8.6/SMI-SVR4) id LAA16331; Fri, 20 Sep 1996 11:43:39 -0700 Date: Fri, 20 Sep 1996 11:43:39 -0700 From: Friedrich Fahnert Message-Id: <199609201843.LAA16331@engg3.mobinfo.com> To: gpc@hut.fi Subject: gpc under SunOS or Solaris Status: RO Has anybody gotten gpc to run on sunOS or on Solaris? I managed to get version 1.2-2.7.2 compiled on both, but neither works very well. On Solaris gpc1 gets a fatal signal, and an internal compiler error, when compiling certain programs. On SunOS, it seems to compile properly, but it dumps core when linking. Is there any platform where gpc coud be considered to be stable? I'd consider getting another machine, if I could just get gpc to run correctly on it. Friedrich From gpc-request@santra.hut.fi Fri Sep 20 16:11:50 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA32665 for ; Fri, 20 Sep 1996 16:11:50 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68274; Fri, 20 Sep 1996 16:15:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63612; Fri, 20 Sep 1996 16:15:11 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA16044 for ; Fri, 20 Sep 1996 16:55:22 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 20 Sep 96 15:55 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v462X-000d57C; Fri, 20 Sep 96 15:54 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 20 Sep 1996 15:48:12 +0200 Date: 20 Sep 1996 15:45:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6HEg20PFlJB@rufus.central.de> In-Reply-To: <199609171218.OAA29146@agnes.dida.physik.uni-essen.de> Subject: Re: how to write binary datas in a file X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo peter, > > I can use only the "write" function - the result is all $0A will be > > converted into "$0D $0A" - Yes, thats the CrLf - > > Yes, that's even true for "File of Integer"! Congratulations - you > have discovered a serious bug in the Run Time Library. :-( I tryed to work around with other file functions or with GCC - but everytime the same shit - only the functions in "dos.h" seems to work correct. Look for my DosFile-unit. > > I think it's no problem > > under UNIX, Linux, Ponyx, Limbux etc. :-) > > Yes, it isn't. Your diagnostics was right. I think that's the reason why the bug is not corrected. Most GCC/GPC-user and developper IMHO are not usinging old MS-DOS. ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Fri Sep 20 15:40:58 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA32640 for ; Fri, 20 Sep 1996 15:40:57 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57474; Fri, 20 Sep 1996 15:45:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46960; Fri, 20 Sep 1996 15:44:17 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA13257 for ; Fri, 20 Sep 1996 16:01:02 +0300 (EET DST) Received: from [130.89.179.57] (pc057.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA06375 (5.67b/IDA-1.5 for ); Fri, 20 Sep 1996 15:00:50 +0200 Date: Fri, 20 Sep 96 15:15:16 CST From: "J.J. van der Heijden" Message-Id: <66663.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: dos and binary file IO: fixed Status: RO Hello folks, I fixed the problems of gpc/djgpp with binary file IO. An updated libgpc.a plus the patch can be downloaded from: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/updates/rtsdjgpp.zip The patch also applies for win32 and emx who also treat text and binary files differently, unlike unix. (I have no libgpc.a for them though). Happy hacking, JanJaap --- Someone once asked me if they could use Open Windows on a Mac. I said, "I don't know. Let's find out." I went to the Mac, opened the window and threw out the Mac. "Yep, You can use Open Windows on a Mac." bofh@RedDragon.Empire.Net (Psycho Sysadmin) From gpc-request@santra.hut.fi Wed Sep 11 19:15:58 1996 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41120; Wed, 11 Sep 1996 19:15:57 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43936; Wed, 11 Sep 1996 19:15:13 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id UAA23617 for ; Wed, 11 Sep 1996 20:04:43 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id KAA00404; Wed, 11 Sep 1996 10:05:44 -0700 Date: Wed, 11 Sep 1996 10:05:44 -0700 From: Phil Nelson Message-Id: <199609111705.KAA00404@fawn.cs.wwu.edu> To: J.J.vanderHeijden@student.utwente.nl Cc: gpc@hut.fi In-Reply-To: <68824.s8806144@mail.student.utwente.nl> (j.j.vanderheijden@student.utwente.nl) Subject: Re: SYSV vs BSD signal blues :-( Status: RO >I think I'll just rewrite the signal related stuff in rts-rt0.c, implement >some BSD/SYSV independant routines that ONLY mask signals that are actually >present on the target system. I have personally found this feature annoying. I DO want a core dump in the case of a SIGSEGV so I can see where it occured with a debugger. Should the default be not to have it and if you want it have a run time flag or a configure flag that enables by default? -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Sun Sep 22 11:42:02 1996 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA280558; Sun, 22 Sep 1996 11:42:01 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82260; Sun, 22 Sep 1996 11:41:13 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA16066 for ; Fri, 20 Sep 1996 16:55:07 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 20 Sep 96 15:55 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v462X-000ctkC; Fri, 20 Sep 96 15:54 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 20 Sep 1996 15:48:12 +0200 Date: 20 Sep 1996 15:26:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6HEg12F-lJB@rufus.central.de> Subject: some questions ... X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo gpc, Somebody have found the C2PAS converter? Why is the boolean type internal so big (Integer) ? Boolean should only use a bit - yes thats stupid, but a byte should work fast and easy !? Why crashed the compiler very often? Yes, I know syntax errors are my faults - but other compilers (you know what I mean) are not so touchy. If the compiler found a syntax fault, I think in some cases it's better to show the fault position in the line. How I can _create_ functions with free type parameters, _without get a warning_ while using with different typed variabels? working example in BP : function SendBuffer(var Buffer; BufferSize: Integer): Integer; My suggestion: function SendBuffer(var Buffer: Void; BufferSize: Integer): Integer; should not generate a warning in using of SendBuffer ... Greetings, Sven ... From gpc-request@santra.hut.fi Sun Sep 22 11:41:59 1996 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA278758; Sun, 22 Sep 1996 11:41:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82254; Sun, 22 Sep 1996 11:41:11 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA15890 for ; Fri, 20 Sep 1996 16:55:15 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 20 Sep 96 15:55 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v462X-000cxsC; Fri, 20 Sep 96 15:54 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 20 Sep 1996 15:48:12 +0200 Date: 20 Sep 1996 15:40:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6HEg1uMklJB@rufus.central.de> Subject: DosFile.pas workaround for the CrLF-bug under old DOS X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO { BP-like file operations for binary files } { simple workaround for the CRLF-bug in GCC/GPC } { Sven Hilscher - sven@rufus.central.de } unit DosFile; { version 0.01Beta } { provisional arrangement } Interface Type WrkStr = String(255); Pointer = ^void; NameT = array[1..13] of char; BinFile = record Name : NameT; Handle : Integer; BSize : Integer; end; Var IOResultTemp : Integer; procedure Assign(var F: BinFile; Name: WrkStr); procedure Reset(var F: BinFile; RecSize: Integer); procedure Rewrite(var F: BinFile; RecSize: Integer); procedure BlockWrite(var F: BinFile; var Buf: void; Count: Integer; var Result: Integer); procedure BlockRead(var F: BinFile; var Buf: Void; Count: Integer; var Result: Integer); procedure Close(var F: BinFile); function IOResult: Integer; Implementation procedure Assign(var F: BinFile; Name: WrkStr); var i : Integer; begin for i := 1 to 12 do if length(Name) >= i then F.Name[i] := Name[i] else F.Name[i] := chr(0); F.Name[13] := chr(0); F.Handle := 0; end; { functions converted from "dos.h" } function DosOpen(n: Pointer; i: Integer; h: pointer):Integer; AsmName '_dos_open'; function DosCreate(var n: NameT; i: Integer; h: pointer):Integer; AsmName '_dos_creat'; function DosClose(h: Integer): Integer; AsmName '_dos_close'; function DosWrite(h: Integer; b: Pointer; c: Integer; var r: Integer): Integer; AsmName '_dos_write'; function DosRead(h: Integer; b: Pointer; c: Integer; var r: Integer): Integer; AsmName '_dos_read'; procedure Reset(var F: BinFile; RecSize: Integer); begin if F.handle <> 0 then IOResultTemp := DosClose(F.Handle); IOResultTemp := DosOpen(@F.Name, 0, @F.Handle); F.BSize := RecSize; end; procedure Rewrite(var F: BinFile; RecSize: Integer); begin if F.Handle <> 0 then IOResultTemp := DosClose(F.Handle); IOResultTemp := DosCreate(F.Name, 0, @F.Handle); F.BSize := RecSize; end; procedure Close(var F: BinFile); begin IOResultTemp := DosClose(F.Handle); F.Handle := 0; F.BSize := 0; end; function IOResult: Integer; begin IOResult := IOResultTemp; IOResultTemp := 0; end; procedure BlockWrite(var F: BinFile; var Buf: void; Count: Integer; var Result: Integer); begin IOResultTemp := DosWrite(F.Handle, @Buf, Count * F.BSize, Result); Result := Result div F.BSize end; procedure BlockRead(var F: BinFile; var Buf: Void; Count: Integer; var Result: Integer); begin IOResultTemp := DosRead(F.Handle, @Buf, Count * F.BSize, Result); Result := Result div F.BSize end; begin IOResultTemp := 0; end. From gpc-request@santra.hut.fi Sat Sep 21 18:02:24 1996 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA278496; Sat, 21 Sep 1996 18:02:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47756; Sat, 21 Sep 1996 18:01:35 +0200 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA09974 for ; Sat, 21 Sep 1996 18:55:25 +0300 (EET DST) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by snake.hut.fi (8.7.5/8.7.3) with ESMTP id BAA54838 for ; Sat, 21 Sep 1996 01:28:43 +0300 Received: from adaq.adaq.com by scruz.net (8.7.3/1.34) id PAA27759; Fri, 20 Sep 1996 15:28:22 -0700 (PDT) Received: from engg2 by adaq.adaq.com id aa18329; 20 Sep 96 15:17 PDT Received: from engg3.mobinfo.com by engg2.adaq.com (4.1/SMI-4.1) id AA06220; Fri, 20 Sep 96 15:21:05 PDT Received: from engg3 by engg3.mobinfo.com (SMI-8.6/SMI-SVR4) id PAA21663; Fri, 20 Sep 1996 15:29:22 -0700 Sender: fritz@engg2.mobinfo.com Message-Id: <32431AC0.41F5@engg2.mobinfo.com> Date: Fri, 20 Sep 1996 15:29:20 -0700 From: Friedrich Fahnert X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: Phil Nelson Cc: gpc@hut.fi, fritz@engg2.mobinfo.com Subject: Re: gpc under SunOS or Solaris References: <199609202103.OAA08660@fawn.cs.wwu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Phil Nelson writes:
> Yes, I have gpc 1.2 (2.7.2) compiled and running under both SunOS and > Solaris. It is true that there are still some bugs in gpc that allow > gpc1 to core dump. Those should be reported. Several of my "standard" > programs compile and run with no problem. In fact, we have had > our students using gpc as their primary PASCAL compiler for a couple > of years. > I found a solution for the problem I was having under SunOS. I can get the program compiled if I specify the source files, to gpc, but not if I compile the files, and link them separately. Should this be considered to be a bug? What I did, exactly: engg2 fritz 647 ( stage2/util ) > !gp gpc cutil.p space.p -x c vcf/*.c -o space.exe space.p: In function `space': space.p:114: warning: passing arg 1 of `Ustat' makes pointer from integer without a cast 4.830u 7.280s 0:17.32 69.9% 0+252k 22+126io 15pf+0w engg2 fritz 648 ( stage2/util ) > l space.exe -rwxrwxrwx 1 fritz 92131 Sep 20 15:22 space.exe* engg2 fritz 649 ( stage2/util ) > The following dumps core: engg2 fritz 654 ( util/vcf ) > gcc -c *.c rm *.^C 0.660u 1.770s 0:04.55 53.4% 0+167k 7+21io 2pf+0w engg2 fritz 655 ( util/vcf ) > rm *.o engg2 fritz 656 ( util/vcf ) > cd .. engg2 fritz 657 ( stage2/util ) > cd vcf engg2 fritz 658 ( util/vcf ) > rm *.o rm: No match. engg2 fritz 659 ( util/vcf ) > gcc -c *.c cd .. gpc 2.640u 7.730s 0:16.79 61.7% 0+177k 13+49io 13pf+0w engg2 fritz 660 ( util/vcf ) > cd .. engg2 fritz 661 ( stage2/util ) > gpc -c space.p cutil.p space.p: In function `space': space.p:114: warning: passing arg 1 of `Ustat' makes pointer from integer without a cast gp1.080u 1.320s 0:02.73 87.9% 0+395k 6+18io 3pf+0w engg2 fritz 662 ( stage2/util ) > gpc space.o cutil.o vcf/*.o -o space.exe Segmentation fault (core dumped) engg2 fritz 663 ( stage2/util ) > From gpc-request@santra.hut.fi Sat Sep 21 17:04:19 1996 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA279440; Sat, 21 Sep 1996 17:04:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58536; Sat, 21 Sep 1996 17:03:31 +0200 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id RAA07189 for ; Sat, 21 Sep 1996 17:57:41 +0300 (EET DST) Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by snake.hut.fi (8.7.5/8.7.3) with SMTP id RAA33538 for ; Sat, 21 Sep 1996 17:01:03 +0300 Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA00578 for gpc@hut.fi; Sat, 21 Sep 1996 15:57:22 +0200 From: Peter Gerwinski Message-Id: <199609211357.PAA00578@agnes.dida.physik.uni-essen.de> Subject: gpc under SunOS or Solaris To: gpc@hut.fi Date: Sat, 21 Sep 1996 15:57:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Friedrich Fahnert: > I managed to get version 1.2-2.7.2 compiled on both, but neither works > very well. On Solaris gpc1 gets a fatal signal, and an internal > compiler error, when compiling certain programs. On SunOS, it seems > to compile properly, but it dumps core when linking. It would be nice to fix the bugs. If possible, I would like to have a minimum source which still triggers the error. Perhaps we can reproduce the error on other platforms we have access to. > Is there any platform where gpc could be considered to be stable? I tested GPC on various iX86-based platforms, so I'd consider it to be stable on DOS (DJGPP and EMX), OS/2 (EMX), Linux and FreeBSD. Good luck, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Sep 22 17:38:40 1996 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46846; Sun, 22 Sep 1996 17:38:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80202; Sun, 22 Sep 1996 17:37:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA18403 for ; Sun, 22 Sep 1996 18:13:28 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA01695 for gpc@hut.fi; Sun, 22 Sep 1996 17:10:27 +0200 From: Peter Gerwinski Message-Id: <199609221510.RAA01695@agnes.dida.physik.uni-essen.de> Subject: BUG: String schemas as function parameters To: gpc@hut.fi Date: Sun, 22 Sep 1996 17:10:26 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Subject: Re: gnu pascal unit problem Newsgroups: comp.os.msdos.djgpp References: Organization: Universitaet Essen, Germany Reply-To: peter.gerwinski@uni-essen.de Distribution: Helge Kruse (hk@bercos.de) wrote: > I downloaded the version 1.2-2.7.2 of gpc and tried a unit > sample. But the code won't work. It's so small, that Id like > to post the code here: > program p1; > (* This program does NOT work correctly with GPC 2.7.2 *) > (* compiled with 'gpc --automake p1.pas' the a.out will *) > (* be compiled. But the function u1 in the unit u1 *) > (* does not prints the parameter. *) > (* Renaming the unit, so that unit/function name differ *) > (* gives no success. *) The function u1 accepts a formal parameter of type "String". Other than in Borland Pascal, this does not default to a String of maximum length 255 but stands for a String Schema type which is something more complicated. Indeed, you discovered a bug. Thank you for the report. To work around, use Strings of known maximum length instead of generic String Schemas, i.e. Type WrkString = String ( 80 ); Function u1 ( S: WrkString ): whatever; (Also posted to the GNU Pascal mailing list.) Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Sep 22 17:27:51 1996 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA280630; Sun, 22 Sep 1996 17:27:50 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45722; Sun, 22 Sep 1996 17:27:03 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA18311 for ; Sun, 22 Sep 1996 18:05:05 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA01641 for gpc@hut.fi; Sun, 22 Sep 1996 17:01:58 +0200 From: Peter Gerwinski Message-Id: <199609221501.RAA01641@agnes.dida.physik.uni-essen.de> Subject: Re: gpc under SunOS or Solaris To: gpc@hut.fi Date: Sun, 22 Sep 1996 17:01:58 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Friedrich Fahnert: > I found a solution for the problem I was having under SunOS. I can get > the program compiled if I specify the source files, to gpc, but not if I > compile the files, and link them separately. Should this be considered > to be a bug? Yes. :-( Thank you for the report. I was reported a similar bug for Linux but could not reproduce it. Strange. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Sep 22 23:43:03 1996 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA279972; Sun, 22 Sep 1996 23:43:02 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56640; Sun, 22 Sep 1996 23:42:14 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id AAA23244 for ; Mon, 23 Sep 1996 00:18:01 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA01974 for gpc@hut.fi; Sun, 22 Sep 1996 23:15:04 +0200 From: Peter Gerwinski Message-Id: <199609222115.XAA01974@agnes.dida.physik.uni-essen.de> Subject: some questions ... To: gpc@hut.fi Date: Sun, 22 Sep 1996 23:15:04 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Sven, hi everybody, > Somebody have found the C2PAS converter? I have never seen such a thing - only the p2c. > Why is the boolean type internal so big (Integer) ? I could not reproduce this bug. Var B: Boolean; writeln ( Sizeof ( B ) ) yields 1 on my machine. > Boolean should only use a bit - yes thats stupid, It's not stupid at all. One day, GPC will actually pack `packed arrays' of Boolean or `packed records' containing Booleans and Integer subranges, then each Boolean will only get a single bit. > Why crashed the compiler very often? If we knew the answer, the compiler wouldn't crash any more, sigh. Please collect the source which makes the compiler crash, so we can correct the bug. > If the compiler found a syntax fault, I think in some cases it's better to > show the fault position in the line. I agree, but I have no idea how to implement this with a Bison parser (I am not so experienced with Bison). Somebody has? > How I can _create_ functions with free type parameters, > _without get a warning_ while using with different typed variabels? This is a bug in GPC and must be fixed. For the moment, use (*$W-*) to switch off annoying warnings, use (*$W+*) to switch them on again. By the way, Sven, your DosFile Unit does not only work around a bug, but it also implements some missing functions such as BlockRead, BlockWrite, and IOresult. Gut gemacht! :-) :-) Shall I put it into a gpc-2.7.2/contrib directory? Somebody out there willing to make it portable? It should not be too difficult to translate the DOS system calls to UNIX system calls. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Sep 23 15:38:46 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA03240 for ; Mon, 23 Sep 1996 15:38:46 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48548; Mon, 23 Sep 1996 15:41:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70586; Mon, 23 Sep 1996 15:41:00 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA31070 for ; Mon, 23 Sep 1996 16:20:37 +0300 (EET DST) Received: from slp06164.slip.utwente.nl by driene.student.utwente.nl with SMTP id AA22118 (5.67b/IDA-1.5 for ); Mon, 23 Sep 1996 15:20:34 +0200 Message-Id: <2.2.32.19960923132151.0069f868@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 15:21:51 +0200 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: DosFile.pas workaround for the CrLF-bug under old DOS Status: RO At 03:40 PM 9/20/96 +0200, you wrote: > >{ BP-like file operations for binary files } >{ simple workaround for the CRLF-bug in GCC/GPC } >{ Sven Hilscher - sven@rufus.central.de } > > I can see the use of functions with a borland-compatible syntax, like assign(), but fail to see the link with CRLF problems. I think I fixed those. var f: text is now opened in text mode. A line is terminated with CRLF in DOS, while type byte = __byte__ integer; bytefile = file of byte; var g: bytefile; is opened in binary mode and $0A is not silently converted to $0A$0D. I think this solves the problems. If you think otherwise, let me know. JanJaap -- The latest & greates in software, hardware and manswear -- Bono Vox (U2) From gpc-request@santra.hut.fi Mon Sep 23 15:34:58 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA03231 for ; Mon, 23 Sep 1996 15:34:58 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60966; Mon, 23 Sep 1996 15:38:04 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56252; Mon, 23 Sep 1996 15:37:14 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA30496 for ; Mon, 23 Sep 1996 16:13:13 +0300 (EET DST) Received: from slp06164.slip.utwente.nl by driene.student.utwente.nl with SMTP id AA21218 (5.67b/IDA-1.5 for ); Mon, 23 Sep 1996 15:13:10 +0200 Message-Id: <2.2.32.19960923131427.00695aa8@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 15:14:27 +0200 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: some questions ... Status: RO At 11:15 PM 9/22/96 +0200, you wrote: >Hi Sven, hi everybody, Hello :) > > >> Why is the boolean type internal so big (Integer) ? > >I could not reproduce this bug. Var B: Boolean; writeln ( Sizeof ( B ) ) >yields 1 on my machine. > >> Boolean should only use a bit - yes thats stupid, > This is not so stupid. A 32bit CPU accesses memory in 32bit chunks. It is possible to access a byte, but this is considerably slower. Accessing a bit would require accessing a 32bit word first, then bitshifting. All compilers make this speed v.s. memory-consumption tradeof in favor of speed, and GPC is no exception. For a 64 bit CPU, it's even worse: 63bits per boolean are "waisted". JanJaap -- The latest & greates in software, hardware and manswear -- Bono Vox (U2) From gpc-request@santra.hut.fi Mon Sep 23 15:32:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA03204 for ; Mon, 23 Sep 1996 15:32:39 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56268; Mon, 23 Sep 1996 15:35:45 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64308; Mon, 23 Sep 1996 15:34:55 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA29946 for ; Mon, 23 Sep 1996 16:08:05 +0300 (EET DST) Received: from slp06164.slip.utwente.nl by driene.student.utwente.nl with SMTP id AA20637 (5.67b/IDA-1.5 for ); Mon, 23 Sep 1996 15:08:02 +0200 Message-Id: <2.2.32.19960923130920.0069be74@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 15:09:20 +0200 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: Known GPC bugs Status: RO At 12:57 PM 9/23/96 +0200, you wrote: >Hello folks, > >I updated the "known bugs" section of the Texinfo documentation >of the (experimental) gpc-1.2-2.7.2 pre-release. The new file >"bugs.texi" can be found at > Maybe we should get one of those systems where people can file bug reports in HTML forms. I have seen these before, but can't remember ever having seen a ready-to-go distribution. Anybody got any ideas? JanJaap -- The latest & greates in software, hardware and manswear -- Bono Vox (U2) From gpc-request@santra.hut.fi Mon Sep 23 13:22:24 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA02953 for ; Mon, 23 Sep 1996 13:22:24 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51718; Mon, 23 Sep 1996 13:25:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55330; Mon, 23 Sep 1996 13:24:41 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA19948 for ; Mon, 23 Sep 1996 14:00:20 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id MAA02718; Mon, 23 Sep 1996 12:57:20 +0200 From: Peter Gerwinski Message-Id: <199609231057.MAA02718@agnes.dida.physik.uni-essen.de> Subject: Re: |||||||||| Free Pascal Compiler? |||||||||| To: lcappite@sprynet.com Date: Mon, 23 Sep 1996 12:57:19 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Louis Cappitelli: > > On 22 Sep 1996 12:02:40 GMT, in comp.lang.pascal.misc you wrote: > > >Louis Cappitelli (lcappite@sprynet.com) wrote: > >> Does anybody know if there is one for DOS or win95? I am taking a > >> course in High School that uses Turbo pascal, but because it's illegal > >> to copy software, I can't work on my program projects at home and test > >> them. Is there something like djgpp c++ compiler or something better? > > > >Get GNU Pascal. It runs on the DJGPP platform for DOS and Win95, > >on the EMX platform for DOS and OS/2 and on any other platform > >supported by the GNU compiler family (e.g. Linux, FreeBSD). > > I got a question. Does it require DJGPP? Yes, you need at least the assembler (as), the linker (ld) and some libraries (libc.a, libm.a, crt0.o, ...) to run the DJGPP version (for DOS) of the GNU Pascal compiler. The C compiler is - of course - not needed. However, djgpp is not really a big packet. You do *not* need DJGPP to run a program *compiled with* GPC. With EMX, you need the EMX development tools (except, again, the C compiler) to compile programs; to run a compiled program you also need the EMX run time system, either an extender program (for DOS) or a DLL (for OS/2). But that's not a problem since the EMX license allows you to distribute the EMX runtime system along with your program. By the way, programs compiled with Borland Pascal also need Borland's runtime system (files RTM.EXE and DPMI16BI.OVL) to run in protected mode. Fortunately, Borland allows its licensed users to distribute them along with their programs. (Also posted to the GPC mailing list.) Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Sep 23 13:22:13 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA02949 for ; Mon, 23 Sep 1996 13:22:13 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48854; Mon, 23 Sep 1996 13:25:21 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35866; Mon, 23 Sep 1996 13:24:31 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA20051 for ; Mon, 23 Sep 1996 14:00:22 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id MAA02726 for gpc@hut.fi; Mon, 23 Sep 1996 12:57:36 +0200 From: Peter Gerwinski Message-Id: <199609231057.MAA02726@agnes.dida.physik.uni-essen.de> Subject: Known GPC bugs To: gpc@hut.fi Date: Mon, 23 Sep 1996 12:57:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, I updated the "known bugs" section of the Texinfo documentation of the (experimental) gpc-1.2-2.7.2 pre-release. The new file "bugs.texi" can be found at ftp://agnes.dida.physik.uni-essen.de/home/peter/gpc-2.7.2/bugs.texi Other doc files got some minor changes, too. I included a link to the GPC documentation into the GPC home page, http://home.pages.de/~GNU-Pascal/ which is actually an alias to http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ See you, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Sep 23 20:45:24 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA03675 for ; Mon, 23 Sep 1996 20:45:23 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59476; Mon, 23 Sep 1996 20:48:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA89316; Mon, 23 Sep 1996 20:47:37 +0200 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id VAA07583 for ; Mon, 23 Sep 1996 21:39:10 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id OAA00585 for ; Mon, 23 Sep 1996 14:41:19 -0400 Date: Mon, 23 Sep 1996 14:41:19 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: Functions/strings Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I remember reading in an older version's GUIDE that functions returning strings would not work. Was this corrected with 2.7.2? -john From gpc-request@santra.hut.fi Mon Sep 23 20:18:44 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA03645 for ; Mon, 23 Sep 1996 20:18:44 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46594; Mon, 23 Sep 1996 20:21:46 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81538; Mon, 23 Sep 1996 20:20:57 +0200 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id VAA07182 for ; Mon, 23 Sep 1996 21:12:48 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id OAA00356 for ; Mon, 23 Sep 1996 14:14:56 -0400 Date: Mon, 23 Sep 1996 14:14:56 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: MAN page? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Has there ever been written a man page for the unix versions? Just basic command syntax & options would be enough to start. I'd offer to do it if I knew how. :( -john From gpc-request@santra.hut.fi Mon Sep 23 21:49:39 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03830 for ; Mon, 23 Sep 1996 21:49:38 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59516; Mon, 23 Sep 1996 21:52:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76314; Mon, 23 Sep 1996 21:51:51 +0200 Received: from scruz.net (nic.scruz.net [165.227.1.2]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id WAA08542 for ; Mon, 23 Sep 1996 22:45:40 +0300 (EET DST) Received: from adaq.adaq.com by scruz.net (8.7.3/1.34) id MAA04071; Mon, 23 Sep 1996 12:45:29 -0700 (PDT) Received: from engg2 by adaq.adaq.com id aa21844; 23 Sep 96 12:34 PDT Received: from engg3.mobinfo.com by engg2.adaq.com (4.1/SMI-4.1) id AA12547; Mon, 23 Sep 96 12:38:05 PDT Received: from engg3 by engg3.mobinfo.com (SMI-8.6/SMI-SVR4) id MAA11500; Mon, 23 Sep 1996 12:46:31 -0700 Sender: fritz@engg2.mobinfo.com Message-Id: <3246E916.6180@engg2.mobinfo.com> Date: Mon, 23 Sep 1996 12:46:30 -0700 From: Friedrich Fahnert Organization: Mobile Information Systems Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: John Michael Black , gpc@hut.fi Subject: Re: MAN page? (corrected) References: <3246E888.1242@engg2.mobinfo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Friedrich Fahnert wrote: > > John Michael Black wrote: > > > > Has there ever been written a man page for the unix versions? Just basic > > command syntax & options would be enough to start. > > > > I'd offer to do it if I knew how. :( > > > > -john > > Why? gpc normally uses texinfo to provide online help. It seems better > than man pages. It also looks better printed, and you can also use with > Web-browsers (check the FSF's homepage for this). > > If you really want a man page, there must be a program somewhere to > convert texinfo to man pages. If there isn't, I don't think writing > one would be difficult. I meant to say here, should _not_ be difficult -- \-------------------------------\ \ \ __ \ F Fahnert \ | \ > -------------------- >------| \ ______ / / --- \_____/**|_|_\____ | /fritz@adaq.adaq.com / \_______ --------- __>-} /-------------------------------/ / \_____|_____/ | * | {O} From gpc-request@santra.hut.fi Mon Sep 23 21:49:32 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03826 for ; Mon, 23 Sep 1996 21:49:31 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59502; Mon, 23 Sep 1996 21:52:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38408; Mon, 23 Sep 1996 21:51:44 +0200 Received: from scruz.net ([165.227.1.2]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id WAA08736 for ; Mon, 23 Sep 1996 22:44:41 +0300 (EET DST) Received: from adaq.adaq.com by scruz.net (8.7.3/1.34) id MAA03899; Mon, 23 Sep 1996 12:43:10 -0700 (PDT) Received: from engg2 by adaq.adaq.com id aa21791; 23 Sep 96 12:32 PDT Received: from engg3.mobinfo.com by engg2.adaq.com (4.1/SMI-4.1) id AA12517; Mon, 23 Sep 96 12:35:46 PDT Received: from engg3 by engg3.mobinfo.com (SMI-8.6/SMI-SVR4) id MAA11495; Mon, 23 Sep 1996 12:44:11 -0700 Sender: fritz@engg2.mobinfo.com Message-Id: <3246E888.1242@engg2.mobinfo.com> Date: Mon, 23 Sep 1996 12:44:08 -0700 From: Friedrich Fahnert Organization: Mobile Information Systems Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: John Michael Black Cc: gpc@hut.fi Subject: Re: MAN page? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO John Michael Black wrote: > > Has there ever been written a man page for the unix versions? Just basic > command syntax & options would be enough to start. > > I'd offer to do it if I knew how. :( > > -john Why? gpc normally uses texinfo to provide online help. It seems better than man pages. It also looks better printed, and you can also use with Web-browsers (check the FSF's homepage for this). If you really want a man page, there must be a program somewhere to convert texinfo to man pages. If there isn't, I don't think writing one would be difficult. -- \-------------------------------\ \ \ __ \ F Fahnert \ | \ > -------------------- >------| \ ______ / / --- \_____/**|_|_\____ | /fritz@adaq.adaq.com / \_______ --------- __>-} /-------------------------------/ / \_____|_____/ | * | {O} From gpc-request@santra.hut.fi Mon Sep 23 21:35:23 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03814 for ; Mon, 23 Sep 1996 21:35:23 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59408; Mon, 23 Sep 1996 21:38:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75966; Mon, 23 Sep 1996 21:37:35 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA08505 for ; Mon, 23 Sep 1996 22:27:20 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA03754 for gpc@hut.fi; Mon, 23 Sep 1996 21:24:41 +0200 From: Peter Gerwinski Message-Id: <199609231924.VAA03754@agnes.dida.physik.uni-essen.de> Subject: Functions/strings To: gpc@hut.fi Date: Mon, 23 Sep 1996 21:24:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to John Michael Black: > I remember reading in an older version's GUIDE that functions returning > strings would not work. Was this corrected with 2.7.2? Yes. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Sep 23 21:33:23 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03807 for ; Mon, 23 Sep 1996 21:33:23 +0200 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48528; Mon, 23 Sep 1996 21:36:23 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41076; Mon, 23 Sep 1996 21:35:35 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA08346 for ; Mon, 23 Sep 1996 22:26:55 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA03747 for gpc@hut.fi; Mon, 23 Sep 1996 21:24:16 +0200 From: Peter Gerwinski Message-Id: <199609231924.VAA03747@agnes.dida.physik.uni-essen.de> Subject: MAN page? To: gpc@hut.fi Date: Mon, 23 Sep 1996 21:24:16 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to John Michael Black: > Has there ever been written a man page for the unix versions? Just basic > command syntax & options would be enough to start. No. > I'd offer to do it if I knew how. :( That would be great. Unfortunately, I don't know either how to do this. Anybody here who knows? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Sep 24 15:59:36 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA04749 for ; Tue, 24 Sep 1996 15:59:35 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56996; Tue, 24 Sep 1996 16:02:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65426; Tue, 24 Sep 1996 16:01:27 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA02426 for ; Tue, 24 Sep 1996 16:28:30 +0300 (EET DST) Received: from [130.89.179.33] (pc033.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA14057 (5.67b/IDA-1.5 for ); Tue, 24 Sep 1996 15:28:19 +0200 Date: Tue, 24 Sep 96 15:43:15 CST From: "J.J. van der Heijden" Message-Id: <68188.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: gpc under SunOS or Solaris Status: RO On Sat, 21 Sep 1996 15:57:22 +0200 (MET DST, Peter Gerwinski wrote: >According to Friedrich Fahnert: >> I managed to get version 1.2-2.7.2 compiled on both, but neither works >> very well. On Solaris gpc1 gets a fatal signal, and an internal >> compiler error, when compiling certain programs. On SunOS, it seems >> to compile properly, but it dumps core when linking. > I fixed the linking problems. Yes Peter, they _were_ there :-( They just didn't show in EMX. JanJaap --- Someone once asked me if they could use Open Windows on a Mac. I said, "I don't know. Let's find out." I went to the Mac, opened the window and threw out the Mac. "Yep, You can use Open Windows on a Mac." bofh@RedDragon.Empire.Net (Psycho Sysadmin) From gpc-request@santra.hut.fi Fri Sep 27 11:27:39 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA01044 for ; Fri, 27 Sep 1996 11:27:39 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65612; Fri, 27 Sep 1996 11:43:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90894; Fri, 27 Sep 1996 11:42:24 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id MAA23254 for ; Fri, 27 Sep 1996 12:32:25 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 27 Sep 96 11:32 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0v6ZCv-000VAkC; Fri, 27 Sep 96 11:27 MET DST Received: by rufus.central.de (CrossPoint v3.1 R/C597); 27 Sep 1996 11:23:20 +0200 Date: 24 Sep 1996 10:02:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6HUlCKgVlJB@rufus.central.de> In-Reply-To: <2.2.32.19960923132151.0069f868@mail.student.utwente.nl> Subject: Re: DosFile.pas workaround for the CrLF-bug under old DOS X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo J.J.vanderHeijden, Am 23.09.96 um 15:21 sagtest Du zum Thema "Re: DosFile.pas workaround for the CrLF-bug under old DOS": > >{ BP-like file operations for binary files } > >{ simple workaround for the CRLF-bug in GCC/GPC } > >{ Sven Hilscher - sven@rufus.central.de } > > I can see the use of functions with a borland-compatible syntax, like > assign(), but fail to see the link with CRLF problems. The link with CRLF problem is: the file functions in "dos.h" don't have this problem. That's why I wrote this unit before you fixed the bug. BP-compatible syntax was the second thing ... ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Mon Sep 30 16:48:27 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA00203 for ; Mon, 30 Sep 1996 16:48:27 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61404; Mon, 30 Sep 1996 16:04:55 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71128; Mon, 30 Sep 1996 16:03:57 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA03236 for ; Mon, 30 Sep 1996 16:48:58 +0200 (EET) Received: from [130.89.179.49] (pc049.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA06262 (5.67b/IDA-1.5 for ); Mon, 30 Sep 1996 16:48:56 +0200 Date: Mon, 30 Sep 96 16:52:18 CST From: "J.J. van der Heijden" Message-Id: <71960.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: System calls Status: RO On Mon, 30 Sep 1996 02:03:07 -0400 (EDT), John Michael Black wrote: >This may sound like a dumb question. Is there a predefined routine for >executing O/S commands built into gpc? (like C's universal "system()" >routine.) If not, what would be the easiest way to go about this in unix? > >(I suppose I could use the C routine itself as an external procedure, as a >last resort...) > There's no builtin system() call because this is not part of the Pascal standard. But there is nothing to stop you from using your C-lib's system() call. In C: int system (const char *string); In Pascal: function system(s: cstring): integer; C; function system; external; (I didn't try this, but have done simular things with fork() and others in the past) Someday, we should get some units/modules to implement this ... oh, well, keep dreaming... JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Mon Sep 30 06:52:43 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id GAA03414 for ; Mon, 30 Sep 1996 06:52:42 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56208; Mon, 30 Sep 1996 07:07:17 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82344; Mon, 30 Sep 1996 07:06:27 +0100 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id IAA06868 for ; Mon, 30 Sep 1996 08:00:28 +0200 (EET) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id CAA10259 for ; Mon, 30 Sep 1996 02:03:08 -0400 Date: Mon, 30 Sep 1996 02:03:07 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: System calls Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO This may sound like a dumb question. Is there a predefined routine for executing O/S commands built into gpc? (like C's universal "system()" routine.) If not, what would be the easiest way to go about this in unix? (I suppose I could use the C routine itself as an external procedure, as a last resort...) -j From gpc-request@santra.hut.fi Tue Oct 1 15:11:42 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA01760 for ; Tue, 1 Oct 1996 15:11:42 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69372; Tue, 1 Oct 1996 14:28:02 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA18010; Tue, 1 Oct 1996 14:26:50 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA08774 for ; Tue, 1 Oct 1996 14:58:54 +0200 (EET) Received: from [130.89.179.25] (PC025.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA11054 (5.67b/IDA-1.5 for ); Tue, 1 Oct 1996 14:58:53 +0200 Date: Tue, 1 Oct 96 15:02:23 CST From: "J.J. van der Heijden" Message-Id: <65956.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: gpc under SunOS or Solaris Status: RO On Mon, 30 Sep 1996 09:38:13 -0700, Friedrich Fahnert wrote: >J.J. van der Heijden wrote: >> >> On Sat, 21 Sep 1996 15:57:22 +0200 (MET DST, >> Peter Gerwinski wrote: >> >> >According to Friedrich Fahnert: >> >> I managed to get version 1.2-2.7.2 compiled on both, but neither works >> >> very well. On Solaris gpc1 gets a fatal signal, and an internal >> >> compiler error, when compiling certain programs. On SunOS, it seems >> >> to compile properly, but it dumps core when linking. >> > >> >> I fixed the linking problems. Yes Peter, they _were_ there :-( They just >> didn't show in EMX. >> >> JanJaap >> > >Did you make some patches? How about new binaries? > > I cannot build new binaries for every platform each time I change something -- I would spend all my time building binaries. And I don't have access to a Solaris box anyway. But I can publish the patch, then you can build a new binary yourself. There are some more things that have to be done before a new "all-platform" release. Groeten, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Oct 2 16:20:12 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA02991 for ; Wed, 2 Oct 1996 16:20:12 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50714; Wed, 2 Oct 1996 15:36:19 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA25936; Wed, 2 Oct 1996 15:35:28 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA19170 for ; Wed, 2 Oct 1996 16:15:06 +0200 (EET) Received: from [130.89.179.26] (PC026.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA21516 (5.67b/IDA-1.5 for ); Wed, 2 Oct 1996 16:15:03 +0200 Date: Wed, 2 Oct 96 16:18:40 CST From: "J.J. van der Heijden" Message-Id: <70123.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: ANNOUNCE: new win32 GPC binary available. Status: RO The latest cygwin32-compatible GNU Pascal binary is now available from: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/ I keep this seperate from the main release directory because some things have to be done before the next all-platform release. Still, the win32 GPC has improved enough that I think you should all try it out. Files in this directory: gpc-960930-2.7.2.i386-cygwin32-b16.zip Sep.30 snapshot binary of cygwin32 GPC. For a cygwin32-beta16 toolchain. devtools.i386-cygwin32-b16.zip For those who only want to do Pascal, it's a waist to download a complete toolchain from ftp.cygnus.com. This archive has all the tools (as, ld, libraries) needed to complete GPC. If you already have cygwin32-beta16 installed, you don't need this. Changes ------- Since the last release (gpc-1.2-2.7.2.i386-cygwin32-b14.zip), these things have changed: * Now beta16 compatible. * Fixed internal fork() problems, now --automake works. * Pipes (`gpc -pipe ...') supported. * Binary/text file IO problem fixed. * Some new test programs. * Support for function attributes and multiple directives per function declaration. Effectively, this means this GPC can access the Win32 API and build both GUI and console applications! Thanks, Peter. See the demos in the "test\windows" subdirectory. Installation ------------ * create a subdirectory of your choice (`c:\gpcwin32') and unzip gpc-960930-2.7.2.i386-cygwin32-b16.zip and devtools.i386-cygwin32-b16.zip from there. Use a version of `unzip' that can handle long filenames, i.e. not PKunzip. * Add the directory where `gpc.exe' lives (`c:\gpcwin32\bin') to your path. * Set GCC_EXEC_PREFIX=C:\gpcwin32\lib\gcc-lib\ Beware of the trailing slash! * Set LIBRARY_PATH=c:\gpcwin32\lib;c:\gpcwin32\i386-cygwin32\lib Not yet done ------------ GPC has incomplete support for the `stabs' debugging format. This affects the win32 platform (and all ELF unices). Although you can step your program in GDB, it may lose track of where you really are, be unable to display variables etc. I'm working on this. The function attributes and asmname directives seem to get lost in the GPI mechanism, so you will have to #include `units' for now, if they define WinAPI type functions. Other problems -------------- These things often give problems: * Do NOT mix binaries from different beta's -- they are incompatible. * Be sure to have only one `cygwin.dll' in your path and it must be beta16. The symptoms of these are crashes, stack/register dumps and Windows telling you it cannot load a dll. Read the cygwin32 FAQ (http://www.cygnus.com/ or this directory) Most of the information also applies for GNU Pascal. And please, do not bother the people of the cygwin32 mailinglist if you have problems with GPC, send them to the gpc@hut.fi list instead. Have fun, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Oct 2 16:17:24 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA02986 for ; Wed, 2 Oct 1996 16:17:24 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67684; Wed, 2 Oct 1996 15:33:31 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46512; Wed, 2 Oct 1996 15:32:37 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA19814 for ; Wed, 2 Oct 1996 16:25:13 +0200 (EET) Received: from [130.89.179.26] (PC026.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA23122 (5.67b/IDA-1.5 for ); Wed, 2 Oct 1996 16:25:11 +0200 Date: Wed, 2 Oct 96 16:28:48 CST From: "J.J. van der Heijden" Message-Id: <70676.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: patch for linking-dumps-core problems Status: RO Somebody asked for it, so here it is, the patch for the `linking only dumps core' problem. It was a strcpy() with NULL source problem. Apply it, then rebuild the `gpc' driver program. Greetings, JanJaap *** gpc-1.2-2.7.2/gcc.c Tue Aug 20 21:59:57 1996 --- gpc/gcc.c Tue Sep 24 01:08:44 1996 *************** *** 4976,4980 **** putenv (obstack_finish (&collect_obstack)); ! #ifdef __EMX__ /* Substitute the basename of the first input file for %b in link_command_spec. */ --- 4978,4982 ---- putenv (obstack_finish (&collect_obstack)); ! #ifdef GPC /* Substitute the basename of the first input file for %b in link_command_spec. */ *************** *** 4992,4998 **** if (*p == '.' && p != input_basename) basename_length = p - input_basename; - #endif /* __EMX__ */ - #ifdef GPC explicit_link_files = add_automake_files (explicit_link_files); #endif /* GPC*/ --- 4994,4998 ---- --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Oct 2 23:19:32 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA03282 for ; Wed, 2 Oct 1996 23:19:31 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43366; Wed, 2 Oct 1996 22:35:31 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA104352; Wed, 2 Oct 1996 22:34:40 +0100 Received: from eos.askesis.it (root@eos.askesis.it [194.243.46.2]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id XAA28535 for ; Wed, 2 Oct 1996 23:29:30 +0200 (EET) From: premiere@askesis.it Received: from dialin-02.askesis.it (dialin-02.askesis.it [194.243.46.51]) by eos.askesis.it (8.7.5/8.7.3) with SMTP id WAA11965 for ; Wed, 2 Oct 1996 22:30:25 +0100 Date: Wed, 2 Oct 1996 22:30:25 +0100 Message-Id: <199610022130.WAA11965@eos.askesis.it> X-Sender: premiere@askesis.it (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@hut.fi Subject: Subscription to your mailing list Status: RO Hi, I'm a Student in Computer Programming at University (Milan,Italy). I,ve downloaded Gnu Pascal Compiler and I've given it to my Teacher. Their comments are Enthusiastic! Please , add my E-mail Address to your mailing list. Thanx a lot. HardPile. From gpc-request@santra.hut.fi Thu Oct 3 14:41:49 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA03754 for ; Thu, 3 Oct 1996 14:41:49 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57964; Thu, 3 Oct 1996 13:57:35 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93422; Thu, 3 Oct 1996 13:56:44 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA17859 for ; Thu, 3 Oct 1996 14:49:59 +0200 (EET) Received: from [130.89.179.41] (pc041.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA07564 (5.67b/IDA-1.5 for ); Thu, 3 Oct 1996 14:49:57 +0200 Date: Thu, 3 Oct 96 14:53:43 CST From: "J.J. van der Heijden" Message-Id: <65482.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: BUG: gpc and type modifiers. Status: RO I discovered a bug in the way GPC treats type modifiers: Consider this snippet, for a 32bit architecture: ------------------------------------------- type uint = __unsigned__ integer; { unsigned 32-bit } const c1 : uint = $7FFFFFFF ; { maxint } c2 : uint = $80000000 ; ------------------------------------------- The declaration of c2 gives this error message: `integer constant does not fit in integer type' while this faulty snippet is accepted: ------------------------------------------- type short = __short__ integer; { signed 16-bit } const c3 : short = $FFFF ; c4 : short = $00010000 ; ------------------------------------------- Although c4 gives a warning: `warning: overflow in implicit constant conversion' Obviously, GPC doesn't treat the type modifiers the right way when it evaluates whether a constant is valid or not. The same is true for __longlong__ (64bit), which cannot be initialized with a value > $7FFFFFFF. Workaround ========== With this silly trick it's still possible to assign an unsigned 32bit value: ------------------------------------------- type uint = __unsigned__ integer; { unsigned 32-bit } const c1 : uint = $7FFFFFFF + 1; ------------------------------------------- This gives again: `warning: overflow in implicit constant conversion' which can be suppressed by surrounding the declaration with {$W-} .. {$W+} JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Fri Oct 4 18:49:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA05040 for ; Fri, 4 Oct 1996 18:49:16 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55528; Fri, 4 Oct 1996 18:04:47 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82730; Fri, 4 Oct 1996 18:03:56 +0100 Received: from pianeta.newsoft.it (root@pianeta.newsoft.it [195.36.12.1]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA27719 for ; Fri, 4 Oct 1996 18:54:36 +0200 (EET) Received: from [195.36.12.53] (ppp-4.newsoft.it [195.36.12.53]) by pianeta.newsoft.it (8.6.12/8.6.9) with SMTP id SAA00366 for ; Fri, 4 Oct 1996 18:51:40 GMT Message-Id: <199610041851.SAA00366@pianeta.newsoft.it> To: GNU Pascal Mail List Subject: Double and uses... Date: Fri, 04 Oct 96 18:59:25 --0100 From: Alessandro Graizzaro X-Mailer: E-Mail Connection v2.5.03 Status: RO -- [ From: Alessandro Graizzaro * EMC.Ver #2.5.02 ] -- I'm new with gnu pascal, and with Linux too. I decided to try it, because I need a lot of memory for my computations. 1) Can anoybody of tell me how can I define DOUBLE type ? 2) Is it possible to use the USES clause as in TP ? Where to find something like CRT, GRAPH ...? From gpc-request@santra.hut.fi Fri Oct 4 22:24:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA05849 for ; Fri, 4 Oct 1996 22:24:40 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43276; Fri, 4 Oct 1996 21:40:07 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78200; Fri, 4 Oct 1996 21:39:16 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA31451 for ; Fri, 4 Oct 1996 22:31:55 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id WAA05761 for gpc@hut.fi; Fri, 4 Oct 1996 22:16:56 +0100 From: Peter Gerwinski Message-Id: <199610042116.WAA05761@agnes.dida.physik.uni-essen.de> Subject: Double and uses... To: gpc@hut.fi Date: Fri, 4 Oct 1996 22:16:55 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Alessandro Graizzaro: > I'm new with gnu pascal, and with Linux too. > I decided to try it, because I need a lot of memory for my computations. > 1) Can anoybody of tell me how can I define DOUBLE type ? "Real" *is* what you know as "Double" from Borland Pascal. Borland's 6-byte software real does not exist with GNU; "Single" is "__short__ Real", "Extended" is "__long__ Real". Known bug: you cannot writeln __short__ or __long__ Reals at the moment, but have to convert them to "ordinary" Reals, first. > 2) Is it possible to use the USES clause as in TP ? Yes. See README.TURBO for details (2.6.3 version) or the "From Borland to GNU Pascal" section of the INFO documentation of the 2.7.2-beta version. > Where to find something > like CRT, GRAPH ...? Graph is worked on for the DOS platform. For Linux, you can use the VGAlib C library with "external", "C", and "asmname" Procedures and Functions. CRT does not yet exist -- we are looking for somebody to implement it. However, have a look at BO5 (in the turbo-alpha directory). Its "Events" and "Displays" Units provide important parts of CRT's functionality. Hope this helps, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sat Oct 5 15:59:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA06509 for ; Sat, 5 Oct 1996 15:59:33 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68026; Sat, 5 Oct 1996 15:14:45 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58662; Sat, 5 Oct 1996 15:13:54 +0100 Received: from scsx01.sc.ehu.es (scsx01.sc.ehu.es [158.227.150.40]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA07770 for ; Sat, 5 Oct 1996 16:09:31 +0200 (EET) Received: from scoa00.sc.ehu.es by scsx01.sc.ehu.es (4.1/131295) id AA16462; Sat, 5 Oct 96 15:15:57 +0100 Received: by scoa00.sc.ehu.es (5.65v3.2/4.7) id AA28771; Sat, 5 Oct 1996 16:09:51 +0100 Date: Sat, 5 Oct 1996 16:09:51 +0100 (MET) From: Ikasle Kontseilua X-Sender: sixconse@scoa00 To: gpc@hut.fi Subject: subscribe sixconse@sc.ehu.es Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO subscribe sixconse@sc.ehu.es From gpc-request@santra.hut.fi Fri Oct 11 07:54:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA12284 for ; Fri, 11 Oct 1996 07:54:17 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72036; Fri, 11 Oct 1996 08:07:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55304; Fri, 11 Oct 1996 07:06:34 +0100 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id IAA07857 for ; Fri, 11 Oct 1996 08:59:36 +0300 (EET DST) Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <34169-0@relay.xlink.net>; Fri, 11 Oct 1996 06:59:17 +0000 X-Envelope: Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with ESMTP id HAA08173 for ; Fri, 11 Oct 1996 07:59:15 +0200 Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.6.12/8.6.9) with UUCP id HAA03887 for gpc@hut.fi; Fri, 11 Oct 1996 07:52:29 +0100 Received: by hit.sb.sub.de (DUUCP vom 19.09.1996) with ZConnect; 09 Oct 1996 17:11:00 +0200 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6IWqop59ykB@hit-andi.tio.hit.handshake.de> X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 19.09.1996] In-Reply-To: <58939.s8806144@mail.student.utwente.nl> Subject: Re: it's running :-) Date: 09 Oct 1996 17:11:00 +0200 To: gpc@hut.fi Status: RO Diese Nachricht antwortet auf einen Text, den j.j.vanderheijden@student.utwente.nl am Mittwoch, den 09.10.96, durch die Datennetze geschossen hat: Hallo J.J. JJvdH> There's a more subtle way to do this: Edit the "specs" file in your JJvdH> main djgpp directory. Yes, thank you. Now it works. I must include djgpp.lnk manually, though. JJvdH> >Yes: gpc foo.pas -o foo.exe 2>foo.err No, this doesn't work under Win95. I think I'll download CWSDPMI.EXE to work under DOS. JJvdH> It's AT&T syntax, not intel. Essentially, you have to read the JJvdH> arguments to an instruction in reverse. I think there was some JJvdH> explanation of this in the djgpp docs too (not sure), and there's a JJvdH> intel->at&t asm converter around somewhere (but probably won't do JJvdH> inline GPC asm). Not only in reverse. I tried "REP STOSD" and I couldn't figure out the right syntax. Can you give me any hints where to find this converter ? JJvdH> Yes, djgpp's DPMI functions are all documented in the djgpp C lib JJvdH> reference. (libc.inf) I'm not an expert in C, but I'll manage to understand it. JJvdH> Please send us any working snapshots of code, then we have JJvdH> documentation! If I'm able to get it working, you'll receive my code. Or should I send it to Peter ? JJvdH> JanJaap Bye Andreas From gpc-request@santra.hut.fi Thu Oct 10 17:48:52 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA11917 for ; Thu, 10 Oct 1996 17:48:52 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05516; Thu, 10 Oct 1996 18:02:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17106; Thu, 10 Oct 1996 16:30:26 +0100 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA23204 for ; Thu, 10 Oct 1996 18:14:02 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id LAA03196 for ; Thu, 10 Oct 1996 11:17:11 -0400 Date: Thu, 10 Oct 1996 11:17:11 -0400 (EDT) From: John Michael Black Reply-To: John Michael Black To: gpc@hut.fi Subject: getenv() Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO OK, I got the declarations to compile perfectly, but how do I use the function? It's not compatible with string types, so I can't do any assigning or string-testing. Here is how I declare the function: function getenv(s: __CString__): __CString__; C; Is there a way to assign the result into a string? -john From gpc-request@santra.hut.fi Thu Oct 10 14:02:04 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA11656 for ; Thu, 10 Oct 1996 14:02:04 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62336; Thu, 10 Oct 1996 14:15:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26230; Thu, 10 Oct 1996 13:14:36 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA14745 for ; Thu, 10 Oct 1996 14:53:13 +0300 (EET DST) Received: from [130.89.179.43] (pc043.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA13122 (5.67b/IDA-1.5 for ); Thu, 10 Oct 1996 13:53:11 +0200 Date: Thu, 10 Oct 96 13:57:49 CST From: "J.J. van der Heijden" Message-Id: <62429.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: gpc-1.2-2.7.2 Status: RO On Thu, 10 Oct 1996 12:15:33 +0200, schuh@informatik.uni-siegen.de wrote: >Hello, > >I have a Problem with the gpc-1.2-2.7.2 under Sun's SunOS 4.1.4. > >The first Problem was to compile gpc: >------------------------------------- >... >../gcc-2.7.2/obstack.o `if [ -f "../gcc-2.7.2/alloca.o" ]; then echo >"../gcc-2.7.2/alloca.o" ; else true ; fi` `if [ -f "../gcc-2.7.2/malloc.o" ]; then echo >"../gcc-2.7.2/malloc.o" ; else true ; fi` >collect2: ld returned 2 exit status >ld: Undefined symbol > _emit_string_move > _emit_string_pad > _maybe_find_function_data > _dbxout_set_type_status > _version_flag >*** Error code 1 >make: Fatal error: Command failed for target `gpc1' > > > >Now I delete > stor-layout.o dbxout.o expr.o fold-const.o optabs.o convert.o function.o toplev.o >from the gcc-source and I can build the Pascal-Compiler. > These are the symptoms of a VPATH problem of your `make' utility. You have two options: 1) ugrade to a recent version of GNU make 2) use different directories for GCC sources and object code when you build GCC > > >My second Problem ist to test the Compiler from the 'gpc/test'-directory: >-------------------------------------------------------------------------- >[schuh@pi20]test make >for x in head.pas nohead.pas cstparam.pas switches.pas bitmanip.pas incdec.pas minimax.pas mem.pas abso.pas asmnames.pas openarr.pas varrec.pas ; do \ > rm -f a.out 2>/dev/null ; \ > ../gpc -B../ -L../rts -g -O3 --automake="-g -O3 -B../" $x 2>/dev/null ; \ > echo -n "$x: " ; \ > if [ -f "a.out" ] ; then ./a.out ; else echo "failed" ; fi ; \ >done ; \ >rm myunit.o myunit.gpi a.out 2>/dev/null ; >*** Error code 1 >make: Fatal error: Command failed for target `bptest' > > >What make I wrong? >I hope that anybody can help me to fix this problem! Some more output would be nice, so we know which test(s) failed. Please add "-v" to the compiler flags in the Makefile, then rerun the tests. --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Thu Oct 10 12:28:59 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA11512 for ; Thu, 10 Oct 1996 12:28:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66344; Thu, 10 Oct 1996 12:42:26 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28410; Thu, 10 Oct 1996 11:41:33 +0100 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA10770 for ; Thu, 10 Oct 1996 13:15:40 +0300 (EET DST) From: schuh@informatik.uni-siegen.de Received: from pi1.informatik.uni-siegen.de (pi1.informatik.uni-siegen.de [141.99.200.1]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with SMTP id LAA71088 for ; Thu, 10 Oct 1996 11:15:38 +0100 Received: from pi16.informatik.uni-siegen.de by pi1.informatik.uni-siegen.de (4.1/Server-1.5/HRZ-THD) id AA11929; Thu, 10 Oct 96 12:15:37 +0200 Received: by pi16.informatik.uni-siegen.de (SMI-8.6/Forwarder-1.5/HRZ-THD) id MAA26785; Thu, 10 Oct 1996 12:15:33 +0200 Date: Thu, 10 Oct 1996 12:15:33 +0200 Message-Id: <199610101015.MAA26785@pi16.informatik.uni-siegen.de> To: gpc@hut.fi Subject: gpc-1.2-2.7.2 Cc: schuh@informatik.uni-siegen.de X-Sun-Charset: US-ASCII Status: RO Hello, I have a Problem with the gpc-1.2-2.7.2 under Sun's SunOS 4.1.4. The first Problem was to compile gpc: ------------------------------------- ... ../gcc-2.7.2/obstack.o `if [ -f "../gcc-2.7.2/alloca.o" ]; then echo "../gcc-2.7.2/alloca.o" ; else true ; fi` `if [ -f "../gcc-2.7.2/malloc.o" ]; then echo "../gcc-2.7.2/malloc.o" ; else true ; fi` collect2: ld returned 2 exit status ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' Now I delete stor-layout.o dbxout.o expr.o fold-const.o optabs.o convert.o function.o toplev.o from the gcc-source and I can build the Pascal-Compiler. My second Problem ist to test the Compiler from the 'gpc/test'-directory: -------------------------------------------------------------------------- [schuh@pi20]test make for x in head.pas nohead.pas cstparam.pas switches.pas bitmanip.pas incdec.pas minimax.pas mem.pas abso.pas asmnames.pas openarr.pas varrec.pas ; do \ rm -f a.out 2>/dev/null ; \ ../gpc -B../ -L../rts -g -O3 --automake="-g -O3 -B../" $x 2>/dev/null ; \ echo -n "$x: " ; \ if [ -f "a.out" ] ; then ./a.out ; else echo "failed" ; fi ; \ done ; \ rm myunit.o myunit.gpi a.out 2>/dev/null ; *** Error code 1 make: Fatal error: Command failed for target `bptest' What make I wrong? I hope that anybody can help me to fix this problem! bye Frank _\\|//_ (' O-O ') ---------------------------ooO-(_)-Ooo--------------------------- < email: schuh@informatik.uni-siegen.de > From gpc-request@santra.hut.fi Thu Oct 10 11:38:09 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA11484 for ; Thu, 10 Oct 1996 11:38:09 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44422; Thu, 10 Oct 1996 11:51:38 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74494; Thu, 10 Oct 1996 10:50:45 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id MAA08563 for ; Thu, 10 Oct 1996 12:25:44 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA11454 for gpc@hut.fi; Thu, 10 Oct 1996 11:12:18 +0100 From: Peter Gerwinski Message-Id: <199610101012.LAA11454@agnes.dida.physik.uni-essen.de> Subject: getting/setting environment variables To: gpc@hut.fi Date: Thu, 10 Oct 1996 11:12:18 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to John Michael Black: > Okay, here's another question. Is there a standard in Pascal that > retrieves and/or sets environment variables, like C's getenv()? If not, I > suppose I would declare and external procedure just like the others. I don't know of a de-jure Pascal standard for getenv(). Borland uses the C standard: Function GetEnv ( Index: String ): String; The "Tools" Unit of BO5 implements Borland's GetEnv by using C's one, Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 10 08:53:57 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA11326 for ; Thu, 10 Oct 1996 08:53:57 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42114; Thu, 10 Oct 1996 09:07:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA111432; Thu, 10 Oct 1996 08:06:36 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id JAA02210 for ; Thu, 10 Oct 1996 09:56:55 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id IAA11297 for gpc@hut.fi; Thu, 10 Oct 1996 08:43:54 +0100 From: Peter Gerwinski Message-Id: <199610100743.IAA11297@agnes.dida.physik.uni-essen.de> Subject: external system() call To: gpc@hut.fi Date: Thu, 10 Oct 1996 08:43:53 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to John Michael Black: > procedure system(s: string); C; Use __CString__ instead of String. String is a Schema type, __CString__ a pointer to chars. Greetings, Peter From gpc-request@santra.hut.fi Thu Oct 10 08:45:45 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA11303 for ; Thu, 10 Oct 1996 08:45:45 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52916; Thu, 10 Oct 1996 08:59:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82858; Thu, 10 Oct 1996 07:58:24 +0100 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id JAA00794 for ; Thu, 10 Oct 1996 09:45:20 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id CAA01571 for ; Thu, 10 Oct 1996 02:48:29 -0400 Date: Thu, 10 Oct 1996 02:48:29 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: getting/setting environment variables Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Okay, here's another question. Is there a standard in Pascal that retrieves and/or sets environment variables, like C's getenv()? If not, I suppose I would declare and external procedure just like the others. -john From gpc-request@santra.hut.fi Wed Oct 9 14:47:44 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA10738 for ; Wed, 9 Oct 1996 14:47:44 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67936; Wed, 9 Oct 1996 14:01:32 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99546; Wed, 9 Oct 1996 14:00:37 +0100 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id PAA12767 for ; Wed, 9 Oct 1996 15:53:51 +0300 (EET DST) Received: from alpha.hut.fi (jtv@alpha.hut.fi [130.233.224.50]) by snake.hut.fi (8.7.5/8.7.3) with SMTP id PAA31256; Wed, 9 Oct 1996 15:53:49 +0300 Date: Wed, 9 Oct 1996 15:53:50 +0300 (EET DST) From: Jukka Virtanen To: gpc@hut.fi Cc: Peter Gerwinski Subject: main program vars in stack In-Reply-To: <199610082004.VAA10029@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 8 Oct 1996, Peter Gerwinski wrote: > I don't know why the stack is used, and I will change it (and use the > data segment instead) unless somebody can tell me why the stack is > preferable for the main program. Peter, I recall that I had tough time to make non-local goto's back to the main program level work in gpc. In the beginning I made all routines in the main program level appear as global symbols, and all variables go to the data area. This worked fine, except that the goto handling routines crashed the compiler when a non-local goto back to the main program level was made. I could not make this work with the goto's like this. The solution to the goto problem was to make all routines in the main program to be nested routines inside a "global main program scope" that can be jumped into from inside. This had the unfortunate side-effect that made main program variables go into the stack, which is sort of stupid for obvious reasons. However, MODULES are not treated like this, so currently if you have a large array, you can put it in a module, and it will go to the data area. (This is because you can not jump to the modules scope, so it does not cause problems :-) If you wish you can try to force all program vars back to the global scope. This would be fine (I think it is possible, I just did not do that, sigh). Juki jtv@hut.fi From gpc-request@santra.hut.fi Wed Oct 9 12:49:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA10647 for ; Wed, 9 Oct 1996 12:49:55 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51052; Wed, 9 Oct 1996 12:03:44 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93914; Wed, 9 Oct 1996 12:02:51 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA06998 for ; Wed, 9 Oct 1996 13:49:27 +0300 (EET DST) Received: from [130.89.179.21] (pc021.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA27495 (5.67b/IDA-1.5 for ); Wed, 9 Oct 1996 12:49:24 +0200 Date: Wed, 9 Oct 96 12:53:52 CST From: "J.J. van der Heijden" Message-Id: <58939.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: it's running :-) Status: RO On Tue, 8 Oct 1996 21:04:16 +0100 (MET), Peter Gerwinski wrote: >According to Andreas Bauer: >> - I've installed GPC into H:\GPC including DJGPP and the BINUTILS, >> I think it's all v2. When running gpc.exe says: >> ld.exe: cannot open -lgpc: No such file or directory (ENOENT) >> Do i have to pass params to gpc or to set an environment-var ? > >DJGPP (including GPC) searches for libraries and such things in a >specific directory structure. Normally, an environment variable >points to the DJGPP directory, e.g. "H:\DJGPP", where there is a >configuration file for the rest of the story. If you set it up >in another directory tree structure, you have to specify library >pathes either manually (-L) or by another environment variable >which should be in the DJGPP documentation. > There's a more subtle way to do this: Edit the "specs" file in your main djgpp directory. Locate the section [gcc] and copy it into a new section [gpc] The variables in each section are passed to this program as environment variables, but they don't clutter your real environment. You have to set one env. var "DJGPP" (case sensitive if you're in win95!) to point to the directory where "specs" lives. This is all documented in the DJGPP FAQ >> - I noticed that the output of GPC can't be redirected to a file. >> Is there any posibility to write the compiler-output into a file ? > >Yes: gpc foo.pas -o foo.exe 2>foo.err > >Errors go to the "error device", therefore ">foo.err" is not sufficient. > >> - Can you tell me if it's possible to use standard x86-assembly with >> gpc? Or is there at least a complete documentation of the gnu-assembler >> anywhere ? I can hardly get used to it :( > >I have the same problem. Look into the GNU C documentation, section >"Extensions to ASM" or similar. There is a description, but I had >problems to understand it. Anybody out there who could explain >to both of us how to use that inline assembler syntax? > It's AT&T syntax, not intel. Essentially, you have to read the arguments to an instruction in reverse. I think there was some explanation of this in the djgpp docs too (not sure), and there's a intel->at&t asm converter around somewhere (but probably won't do inline GPC asm). >> - What must be done so that i can access the DPMI-interface through pascal >> without using assembly language ? > >I think you *must* use assembly language. Interrupts and such things >are not in Pascal's language standard. However it would be nice to have >a Unit with a function (written in assembler) which solves this task ... > There are a number of dpmi functions in the djgpp's C library. You _should_ be able to use these, if you declare them properly as external C style functions. These are the functions who's names start with __dpmi. I say _should_ because I have never tried this. >> Is there any docu about that topic ? > >I don't know of such a thing. There could be some hints in the DJGPP >and/or EMX documentation. > Yes, djgpp's DPMI functions are all documented in the djgpp C lib reference. (libc.inf) Please send us any working snapshots of code, then we have documentation! JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Oct 9 02:28:00 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA10286 for ; Wed, 9 Oct 1996 02:27:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67470; Wed, 9 Oct 1996 01:41:58 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82786; Wed, 9 Oct 1996 01:41:06 +0100 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id DAA22203 for ; Wed, 9 Oct 1996 03:31:31 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id UAA24060 for ; Tue, 8 Oct 1996 20:34:18 -0400 Date: Tue, 8 Oct 1996 20:34:18 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: external system() call Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Perhaps I am not familiar enough with external calls, but I cannot get the following program to do anything: -------- program test_system; procedure system(s: string); C; begin system('ls -l'); end. -------- It is not a question of writing output to the screen, because even commands like "mkdir" do nothing. Any suggestions? -john From gpc-request@santra.hut.fi Tue Oct 8 21:09:11 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA10049 for ; Tue, 8 Oct 1996 21:09:11 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65842; Tue, 8 Oct 1996 20:23:15 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA18122; Tue, 8 Oct 1996 20:22:22 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA18196 for ; Tue, 8 Oct 1996 22:17:51 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA10029 for gpc@hut.fi; Tue, 8 Oct 1996 21:04:16 +0100 From: Peter Gerwinski Message-Id: <199610082004.VAA10029@agnes.dida.physik.uni-essen.de> Subject: it's running :-) To: gpc@hut.fi Date: Tue, 8 Oct 1996 21:04:16 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Bauer: > - I've installed GPC into H:\GPC including DJGPP and the BINUTILS, > I think it's all v2. When running gpc.exe says: > ld.exe: cannot open -lgpc: No such file or directory (ENOENT) > Do i have to pass params to gpc or to set an environment-var ? DJGPP (including GPC) searches for libraries and such things in a specific directory structure. Normally, an environment variable points to the DJGPP directory, e.g. "H:\DJGPP", where there is a configuration file for the rest of the story. If you set it up in another directory tree structure, you have to specify library pathes either manually (-L) or by another environment variable which should be in the DJGPP documentation. > - I noticed that the output of GPC can't be redirected to a file. > Is there any posibility to write the compiler-output into a file ? Yes: gpc foo.pas -o foo.exe 2>foo.err Errors go to the "error device", therefore ">foo.err" is not sufficient. > - Can you tell me if it's possible to use standard x86-assembly with > gpc? Or is there at least a complete documentation of the gnu-assembler > anywhere ? I can hardly get used to it :( I have the same problem. Look into the GNU C documentation, section "Extensions to ASM" or similar. There is a description, but I had problems to understand it. Anybody out there who could explain to both of us how to use that inline assembler syntax? > - What must be done so that i can access the DPMI-interface through pascal > without using assembly language ? I think you *must* use assembly language. Interrupts and such things are not in Pascal's language standard. However it would be nice to have a Unit with a function (written in assembler) which solves this task ... > Is there any docu about that topic ? I don't know of such a thing. There could be some hints in the DJGPP and/or EMX documentation. > - I created a program accessing an "array[1..4000000] of byte". > All i got was an exception. How large must the stack be for this > application and why the stack ? I don't know why the stack is used, and I will change it (and use the data segment instead) unless somebody can tell me why the stack is preferable for the main program. However, if you put the array into a Unit (or Module), it will be accepted. Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Oct 8 19:26:14 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA09751 for ; Tue, 8 Oct 1996 19:26:13 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65470; Tue, 8 Oct 1996 18:40:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08150; Tue, 8 Oct 1996 18:39:26 +0100 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id UAA16094 for ; Tue, 8 Oct 1996 20:31:41 +0300 (EET DST) Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <41206-0@relay.xlink.net>; Tue, 8 Oct 1996 18:04:24 +0000 X-Envelope: Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with ESMTP id SAA23493 for ; Tue, 8 Oct 1996 18:29:02 +0200 Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.6.12/8.6.9) with UUCP id SAA26167 for gpc@hut.fi; Tue, 8 Oct 1996 18:26:36 +0100 Received: by hit.sb.sub.de (DUUCP vom 19.09.1996) with ZConnect; 08 Oct 1996 14:28:00 +0200 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6ISqSPIeykB@hit-andi.tio.hit.handshake.de> X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 19.09.1996] Subject: it's running :-) Date: 08 Oct 1996 14:28:00 +0200 To: gpc@hut.fi Status: RO Hi I'm a former (experienced) BP programmer and i'd like to move to GPC. Here are a few questions: - I've installed GPC into H:\GPC including DJGPP and the BINUTILS, I think it's all v2. When running gpc.exe says: ld.exe: cannot open -lgpc: No such file or directory (ENOENT) Do i have to pass params to gpc or to set an environment-var ? - I noticed that the output of GPC can't be redirected to a file. Is there any posibility to write the compiler-output into a file ? - Can you tell me if it's possible to use standard x86-assembly with gpc? Or is there at least a complete documentation of the gnu-assembler anywhere ? I can hardly get used to it :( - What must be done so that i can access the DPMI-interface through pascal without using assembly language ? Is there any docu about that topic ? - I created a program accessing an "array[1..4000000] of byte". All i got was an exception. How large must the stack be for this application and why the stack ? Thank you for any hints. Bye Andreas From gpc-request@santra.hut.fi Mon Oct 7 22:49:25 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA08638 for ; Mon, 7 Oct 1996 22:49:25 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52756; Mon, 7 Oct 1996 22:03:48 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA106976; Mon, 7 Oct 1996 22:02:56 +0100 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA07483 for ; Mon, 7 Oct 1996 23:54:22 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id NAA23986; Mon, 7 Oct 1996 13:55:31 -0700 Date: Mon, 7 Oct 1996 13:55:31 -0700 From: Phil Nelson Message-Id: <199610072055.NAA23986@fawn.cs.wwu.edu> To: J.J.vanderHeijden@student.utwente.nl Cc: gpc@hut.fi In-Reply-To: <2.2.32.19960923130920.0069be74@mail.student.utwente.nl> (message from JanJaap van der Heijden on Mon, 23 Sep 1996 15:09:20 +0200) Subject: Re: Known GPC bugs Status: RO (I tried to send this to you once before, but I think it bounced. Any way, I don't remember a reply.) >Maybe we should get one of those systems where people can file bug reports >in HTML forms. I have seen these before, but can't remember ever having seen >a ready-to-go distribution. > >Anybody got any ideas? GNU GNATS is a nice bug report system and I have a web interface to gnats. If you would like at an example bug database and the web interface to gnats, just let me know. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Mon Oct 7 11:21:53 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA08115 for ; Mon, 7 Oct 1996 11:21:52 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67374; Mon, 7 Oct 1996 10:36:26 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52200; Mon, 7 Oct 1996 10:35:34 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id LAA02573 for ; Mon, 7 Oct 1996 11:27:19 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA08093 for gpc@hut.fi; Mon, 7 Oct 1996 11:13:01 +0100 From: Peter Gerwinski Message-Id: <199610071013.LAA08093@agnes.dida.physik.uni-essen.de> Subject: OS/2 PM programs and DLL's To: gpc@hut.fi Date: Mon, 7 Oct 1996 11:13:01 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Allan Derickson: > Is it possible at this point to make OS/2 Presentation Manager programs > with GNU Pascal? Yes, just as with GNU C in the EMX environment. Look into the EMX documentation and example programs (written in C). Use the "asmname" directive to access OS/2 API functions. I will release a version of BO5 which runs with the OS/2 pm not too far in the future. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Oct 6 17:17:23 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA07438 for ; Sun, 6 Oct 1996 17:17:23 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67508; Sun, 6 Oct 1996 16:32:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28462; Sun, 6 Oct 1996 16:31:18 +0100 Received: from whidbey.whidbey.com (alland@whidbey.whidbey.com [204.94.52.2]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id RAA09104 for ; Sun, 6 Oct 1996 17:27:45 +0200 (EET) Received: (from alland@localhost) by whidbey.whidbey.com (8.7.5/8.7.3) id IAA02569; Sun, 6 Oct 1996 08:24:32 -0700 (PDT) Message-Id: <199610061524.IAA02569@whidbey.whidbey.com> From: alland@whidbey.com (Allan Derickson) Date: Sun, 06 Oct 96 08:32:32 To: gpc@hut.fi Subject: OS/2 PM programs and DLL's X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.14 (Unregistered) Status: RO Hello, Is it possible at this point to make OS/2 Presentation Manager programs with GNU Pascal? Same question with OS/2 DLL's. If so, what is the format of the code? I have been totally unsuccessful with both. Allan D. Derickson -- Derickson Forestry Services -- Freeland, WA USA ----------------------------------------------------------- alland@whidbey.com ----------------------------------------------------------- From gpc-request@santra.hut.fi Sat Oct 12 19:55:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA13425 for ; Sat, 12 Oct 1996 19:55:40 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47390; Sat, 12 Oct 1996 20:08:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA105730; Sat, 12 Oct 1996 19:07:24 +0100 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id UAA12987 for ; Sat, 12 Oct 1996 20:59:54 +0300 (EET DST) Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <14862-0@relay.xlink.net>; Sat, 12 Oct 1996 18:59:35 +0000 X-Envelope: Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with ESMTP id TAA25003 for ; Sat, 12 Oct 1996 19:59:34 +0200 Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.6.12/8.6.9) with UUCP id TAA12475 for gpc@hut.fi; Sat, 12 Oct 1996 19:51:40 +0100 Received: by hit.sb.sub.de (DUUCP vom 19.09.1996) with ZConnect; 12 Oct 1996 15:05:00 +0200 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6IhrcixPykB@hit-andi.tio.hit.handshake.de> X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 19.09.1996] In-Reply-To: <66345.s8806144@mail.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: it's running :-) Date: 12 Oct 1996 15:05:00 +0200 To: gpc@hut.fi Content-Transfer-Encoding: quoted-printable Status: RO Diese Nachricht antwortet auf einen Text, den j.j.vanderheijden@student.utwente.nl am Freitag, den 11.10.96, durch die Datennetze geschossen hat: Hallo J.J. JJvdH> >I must include djgpp.lnk manually, though. JJvdH> When I said 'specs' I meant 'djgpp.env' JJvdH> The 'specs' and 'specs.gpc' file should not be touched! I copied the [gcc] section of *djgpp.env* to [gpc]. And the linker ld cannot find something with ..._ctor_... and _dtor_. until i include djgpp.lnk manually into linking. JJvdH> This was a remark by Peter, but he was probably confusing unix and= dos. JJvdH> Not sure you can redirect stderr in DOS. Yes, i read something it's impossible in DOS. :-( JJvdH> I only heard rumours, but if you watch the djgpp newsgroup JJvdH> (comp.os.msdos.djgpp) or it's archive at http://www.delorie.com yo= u may JJvdH> find it. Maybe it's in the contrib section of the djgpp archive at JJvdH> ftp.delorie.com I'll try it. JJvdH> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D program dpmitest; JJvdH> JJvdH> It's a little C-ish style (ulong's etc) but if you look at JJvdH> from djgpp's C-lib you will see how I did it. I noticed that the GNU-integer is *not* the same as the BP-integer. :-) JJvdH> BTW optimization kill's this sample, maybe because GPC aligns the JJvdH> byte size variables in the records to 32bit boundaries for speed t= hen JJvdH> (??!) It seems that the =ABret=BB-instruction at the end of the program causes = the exception. if you use a halt() as the last command in the source-file, it will work correctly. A bug in the compiler ? JJvdH> The 'asmname' could have been just a 'C' directive, but then you w= ould JJvdH> have had functions called __dpmi_.... in your pascal program. Why not? If it is possible to disable those ugly underscore-warnings... ?! JJvdH> crazy memory issues in DOS. I'm not sure you need all this DPMI st= uff JJvdH> in the first place. Unless you want to write protected mode interr= upt JJvdH> handlers, in which case you'd better take a good look in the djgpp JJvdH> docs..... No, i'll try to write my own system-unit and I'll try to access the LFB of an VESA card. JJvdH> JanJaap Bye Andreas From gpc-request@santra.hut.fi Sat Oct 12 22:32:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA13738 for ; Sat, 12 Oct 1996 22:32:54 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85702; Sat, 12 Oct 1996 22:45:29 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78112; Sat, 12 Oct 1996 21:44:36 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA14973 for ; Sat, 12 Oct 1996 23:37:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id WAA13719 for gpc@hut.fi; Sat, 12 Oct 1996 22:25:34 +0100 From: Peter Gerwinski Message-Id: <199610122125.WAA13719@agnes.dida.physik.uni-essen.de> Subject: Re: it's running :-) To: gpc@hut.fi Date: Sat, 12 Oct 1996 22:25:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Bauer: > Diese Nachricht antwortet auf einen Text, > den j.j.vanderheijden@student.utwente.nl am Freitag, den 11.10.96, > durch die Datennetze geschossen hat: > > JJvdH> This was a remark by Peter, but he was probably confusing unix and= > dos. > JJvdH> Not sure you can redirect stderr in DOS. > Yes, i read something it's impossible in DOS. > :-( No, that was no confusion; I really meant DOS. It actually works with a DOS box in OS/2. However, it seems *not* to work with MS-DOS nor with Novell DOS. :-( In the djgpp NewsGroup somebody said there would be a recepy how to redirect stderr with DOS in the djgpp FAQ. > If it is possible to disable those ugly underscore-warnings... ?! Yes, with (*$W-*) ... (*$W+*) you can switch off/on warnings for a certain section of the code. (However I don't like __underscored_identifiers__ either. ;-) > No, i'll try to write my own system-unit and I'll try to access > the LFB of an VESA card. Did you try Berend's System unit? (And don't forget to send us your useful units so we can publish it. ;-) Bye, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From phy0a0@spf1.power.uni-essen.de Sat Oct 12 23:56:04 1996 Return-Path: phy0a0@spf1.power.uni-essen.de Received: from sp2.power.uni-essen.de (spf10.power.uni-essen.de [132.252.180.10]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA14075 for ; Sat, 12 Oct 1996 23:56:04 +0100 Received: by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49784; Sun, 13 Oct 1996 00:08:37 +0200 From: phy0a0@spf1.power.uni-essen.de (Peter Gerwinski) Message-Id: <9610122208.AA49784@sp2.power.uni-essen.de> Subject: OS/2 DLL's To: peter@agnes.dida.physik.uni-essen.de Date: Sun, 13 Oct 1996 00:08:37 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1679 Status: RO Hello, After some experimenting, I produced an OS/2 dynamic link library (DLL) with GNU Pascal that I could call from another application. Perhaps this is common knowledge but I do not see it documented anywhere. The following seems to work compiled with the latest emx distribution of GPC using "gpc -Zomf -Zdll cube.pas cube.def": unit cube; { a simple function in a DLL} interface function cubit(x:integer):integer; implementation function cubit(x:integer):integer; begin cubit := x*x*x; end; end. You have to be careful in the module definition file to list the function with only the first letter capitalized or LINK386.EXE will complain: /* module definition file for Cube dll */ LIBRARY CUBE EXPORTS Cube @1 Allan D. Derickson -- Derickson Forestry Services -- Freeland, WA USA ----------------------------------------------------------- alland@whidbey.com ----------------------------------------------------------- ******************************** ACHTUNG: Neue e-mail-Adresse! Ab dem 22. Juni 1996 bitte an peter.gerwinski@uni-essen.de schreiben. ******************************** ATTENTION: New e-mail address! >From 22. June 1996 on please write to peter.gerwinski@uni-essen.de ******************************** -------------------------------------------------------------------------------- Dipl. Phys. Peter Gerwinski Fachbereich Physik Universitaet-GH Essen Phone: +49-201-183-2763 D-45117 Essen Fax: +49-201-183-2120 Germany e-mail: peter.gerwinski@uni-essen.de -------------------------------------------------------------------------------- From gpc-request@santra.hut.fi Sun Oct 13 11:11:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA14572 for ; Sun, 13 Oct 1996 11:11:40 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA89702; Sun, 13 Oct 1996 11:24:03 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65046; Sun, 13 Oct 1996 10:23:10 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id MAA19065 for ; Sun, 13 Oct 1996 12:17:59 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA14552 for gpc@hut.fi; Sun, 13 Oct 1996 11:06:07 +0100 From: Peter Gerwinski Message-Id: <199610131006.LAA14552@agnes.dida.physik.uni-essen.de> Subject: OS/2 DLL's To: gpc@hut.fi Date: Sun, 13 Oct 1996 11:06:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > After some experimenting, I produced an OS/2 dynamic link library (DLL) > with GNU Pascal that I could call from another application. Perhaps this > is common knowledge but I do not see it documented anywhere. Thank you. I didn't know this either. I planned to implement Borland's style of creating DLLs into GPC. So with EMX, GPC will have to create a correct .def file as well. Probably somebody here knows how to compile a shared library for Linux or other UNIXes with GPC? Somebody willing to write a documentation section about this? Greetings, (-; Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Oct 14 16:42:53 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA15925 for ; Mon, 14 Oct 1996 16:42:52 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72050; Mon, 14 Oct 1996 16:54:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA111532; Mon, 14 Oct 1996 12:24:43 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA14457 for ; Mon, 14 Oct 1996 14:16:04 +0300 (EET DST) Received: from [130.89.179.22] (pc022.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA24435 (5.67b/IDA-1.5 for ); Mon, 14 Oct 1996 13:16:00 +0200 Date: Mon, 14 Oct 96 13:21:09 CST From: "J.J. van der Heijden" Message-Id: <60428.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Shared images, was: Re: OS/2 DLL's Status: RO On Sun, 13 Oct 1996 11:06:07 +0100 (MET), Peter Gerwinski wrote: >> After some experimenting, I produced an OS/2 dynamic link library (DLL) >> with GNU Pascal that I could call from another application. Perhaps this >> is common knowledge but I do not see it documented anywhere. > >Thank you. I didn't know this either. > >I planned to implement Borland's style of creating >DLLs into GPC. So with EMX, GPC will have to create >a correct .def file as well. > >Probably somebody here knows how to compile a shared >library for Linux or other UNIXes with GPC? > Shared libraries are very platform dependant. 1) Win32 and OS/2 have the .def files, and need seperate import libraries to link an app to a shared image (.dll) 2) ELF unices don't have all of the above, you just use gcc -shared -o libfoo.so.X.Y your_obj_files_here to build a shared image. ELF shared images export everything so no .def is needed. If you have a 'libfoo.so.X.Y' shared image, you link it simply with -lfoo. Several very nifty features exist, to help object oriented languages, to execute initialization code when a shared image is loaded and finalized (unloaded). Look at the sources of the Objective C base library if you want to know more. 3) Some COFF or A.OUT systems (BSD, older Linux flavours) can use shared images too, but at least Linux needed special tools to do so. The Win32 dll's must be `pure' (no global vars), but this restriction doesn't exist for ELF unix. I think you should just leave the DLL stuff as it is, enforcing a Borland PC standard would cripple the possibilities of the ELF for instance. The winapi-0.1.2.tar.gz archive in the GNU archives has a few smart `sed' scripts to generate .def files from a DLL. For cygwin32, the dlltool.exe program can build the import libraries. I have done some attempts to build the GNU Pascal RTS (libgpc.a) as a shared library. For ELF unix, this a very easy. A `hello world' program is reduced to 2K. For win32, several global variables ('input', 'output', gpc_argv and more) make this impossible. I have some plans to rework the RTS, split it in 'ISO', 'ISO extended' and add 'Borland System.tpu' to it. Purify the code. Add documentation fragments to the code, so a `chew' program can generate a rts.texi documentation file. Someday... Just my HFL 0.02, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Mon Oct 14 15:54:18 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA15899 for ; Mon, 14 Oct 1996 15:54:18 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74360; Mon, 14 Oct 1996 16:06:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71714; Fri, 20 Sep 1996 23:20:04 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id AAA03049 for ; Sat, 21 Sep 1996 00:04:03 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id OAA08660; Fri, 20 Sep 1996 14:03:45 -0700 Date: Fri, 20 Sep 1996 14:03:45 -0700 From: Phil Nelson Message-Id: <199609202103.OAA08660@fawn.cs.wwu.edu> To: fritz@engg2.mobinfo.com Cc: gpc@hut.fi In-Reply-To: <199609201843.LAA16331@engg3.mobinfo.com> (message from Friedrich Fahnert on Fri, 20 Sep 1996 11:43:39 -0700) Subject: Re: gpc under SunOS or Solaris Status: RO >I managed to get version 1.2-2.7.2 compiled on both, but neither works >very well. On Solaris gpc1 gets a fatal signal, and an internal >compiler error, when compiling certain programs. On SunOS, it seems >to compile properly, but it dumps core when linking. Yes, I have gpc 1.2 (2.7.2) compiled and running under both SunOS and Solaris. It is true that there are still some bugs in gpc that allow gpc1 to core dump. Those should be reported. Several of my "standard" programs compile and run with no problem. In fact, we have had our students using gpc as their primary PASCAL compiler for a couple of years. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Mon Oct 14 15:42:01 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA15893 for ; Mon, 14 Oct 1996 15:42:01 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74054; Mon, 14 Oct 1996 15:53:57 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50634; Wed, 11 Sep 1996 18:17:49 +0200 Received: from hil-img-3.compuserve.com (hil-img-3.compuserve.com [149.174.177.133]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA22040 for ; Wed, 11 Sep 1996 19:06:17 +0300 (EET DST) Received: by hil-img-3.compuserve.com (8.6.10/5.950515) id MAA06378; Wed, 11 Sep 1996 12:05:45 -0400 Date: 11 Sep 96 12:02:07 EDT From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: External, C, AsmName, ... Message-Id: <960911160207_100120.3121_EHQ83-1@CompuServe.COM> Status: RO > Where is it? > Since GPC is essentially BP-compatible now, perhaps we can > just use it? Good question. I'm not sure. It probably is on CompuServe. I think the author is Bob Swart. It could also be it is only for Delphi. I see if I can get some more info. Groetjes, Berend. From gpc-request@santra.hut.fi Mon Oct 14 15:41:50 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA15885 for ; Mon, 14 Oct 1996 15:41:49 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74180; Mon, 14 Oct 1996 15:53:47 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39310; Sun, 8 Sep 1996 21:14:54 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA13644 for ; Sun, 8 Sep 1996 22:04:42 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA17855; Sun, 8 Sep 1996 20:56:23 +0200 From: Peter Gerwinski Message-Id: <199609081856.UAA17855@agnes.dida.physik.uni-essen.de> Subject: Re: gpc for Solaris 2.5.1 To: brad@shiloh.nimh.nih.gov Date: Sun, 8 Sep 1996 20:56:22 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > Is there a version of gpc built for Solaris 2.5? Or do you > have any hints on getting the lastest source to compile > under Solaris 2.5? The 2.7.2-pre-release should (;-) be straightforward to compile under any system. First, compile the C compiler gcc-2.7.2 and let the object files in place. Then, unarchive gpc-1.2-2.7.2.tar.gz, cd to the gpc directory, type "./configure" and "make" -- voil`a. If you are successful, please let me know, so I can include the binaries into the distribution. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Oct 14 15:41:50 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA15889 for ; Mon, 14 Oct 1996 15:41:50 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54218; Mon, 14 Oct 1996 15:53:48 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42888; Sun, 8 Sep 1996 21:14:43 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA14980 for ; Sun, 8 Sep 1996 22:03:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA17846; Sun, 8 Sep 1996 20:55:41 +0200 From: Peter Gerwinski Message-Id: <199609081855.UAA17846@agnes.dida.physik.uni-essen.de> Subject: Re: External, C, AsmName, ... To: lotu@wam.umd.edu (Arcadio Alivio Sincero) Date: Sun, 8 Sep 1996 20:55:41 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Arcadio Alivio Sincero: > Hey ... did y'all know that a Linux version of FPKPascal (or is it > just FPPascal??) is now out (currently only a.out but and ELF version is FPKPascal. The author's name is Florian Klaempfl, therefore the FK. What the P stands for, I don't know. > expected soon). One thing I like about FPKPascal is that it has > function overloading. Any plans of adding this to GPC? This would be a > nice thing to throw in, IMHO. I have planned to add this feature together with qualified identifiers not too far in the future. Nice to see that I am not the only one who likes it. Somebody who would like to help implementing it? Or to solve some other tasks (e.g. write documentation), so I am free for it? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Oct 15 18:13:22 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA17491 for ; Tue, 15 Oct 1996 18:13:21 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71574; Tue, 15 Oct 1996 18:24:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53908; Tue, 15 Oct 1996 18:24:01 +0200 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id TAA29997 for ; Tue, 15 Oct 1996 19:06:44 +0300 (EET DST) Received: from csunix1.lvc.edu (jm_black@[207.87.98.5]) by snake.hut.fi (8.7.5/8.7.3) with ESMTP id SAA35088 for ; Tue, 15 Oct 1996 18:12:41 +0300 Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id LAA25895 for ; Tue, 15 Oct 1996 11:01:45 -0400 Date: Tue, 15 Oct 1996 11:01:44 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: getenv() and system() Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Thanks so much, JJ, for the sample code for these two functions in the FAQ. In all I thought the faq was good and informative. ---------- IMHO, I would think that the function getenv() and the procedure system() would be two widely used routines for a lot of people's programs. Instead of expecting everyone to "create" them each time, what possibility is there of including them in a standard library? I know they're not standard or extended pascal, but like I said it seems like a lot of people would need to use them. If there isn't an include for operating system functions, perhaps this could start one. For example, right now I've taken these two external makeshift routines (along with some others) and put them in a file "unix.h", so all I do is #include in programs I know will use them. (I'm considering renaming it to , since most of them could probably work on DOS as well.) I would reccommend using the literal names "getenv" and "system" since they are familiar from C. Any thoughts? -john From gpc-request@santra.hut.fi Tue Oct 15 16:01:37 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA17347 for ; Tue, 15 Oct 1996 16:01:37 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72720; Tue, 15 Oct 1996 16:13:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA15934; Tue, 15 Oct 1996 16:12:17 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA27012 for ; Tue, 15 Oct 1996 17:02:24 +0300 (EET DST) Received: from [130.89.179.21] (pc021.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA24619 (5.67b/IDA-1.5 for ); Tue, 15 Oct 1996 16:02:21 +0200 Date: Tue, 15 Oct 96 16:07:05 CST From: "J.J. van der Heijden" Message-Id: <69519.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: STABS format -- solaris users around? Status: RO Hello, I have started a project to add a "Pascal" mode to GDB. This means GDB can demangle Pascal symbols, and evaluate Pascal expressions. The debug format for most platforms is stabs, and exploit all possibilities, GPC and GDB have to support a number of Pascal specific stabs. These are rumoured to be ducumented by SUN for their SUN pascal compiler, and this document might be on the Solaris SDK CD-ROM. So, if any of you have this CD-ROM around, and could pass me this document, maybe I can follow an existing standard, instead of reinventing the wheel. I don't care about the format, I can handle most formats between raw text and PostScript. Sorry for my vagueness, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Oct 15 15:36:49 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA17326 for ; Tue, 15 Oct 1996 15:36:48 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73764; Tue, 15 Oct 1996 15:48:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62346; Tue, 15 Oct 1996 15:47:30 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA25596 for ; Tue, 15 Oct 1996 16:28:29 +0300 (EET DST) Received: from [130.89.179.21] (pc021.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA18813 (5.67b/IDA-1.5 for ); Tue, 15 Oct 1996 15:28:27 +0200 Date: Tue, 15 Oct 96 15:33:43 CST From: "J.J. van der Heijden" Message-Id: <67668.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Call for installation patches and hacks. Status: RO Hello, We are finishing up preparations for the "final" 1.2 GPC release, and now I would like to know, did any of you have to apply special hacks to get GPC up and running? Need to edit a config file, Makefile etc., add special CFLAGS? We know about the problems with stor-layout and friends (undefined symbols when linking gpc1) and BSD/SYSV confusion with signals in rts/rts-rt0.c We would like to hear about any other hacks you had to do, and this is your chance to get it fixed before the release. In the ideal world, `configure ; make' should work. I have heard people failing to build GPC on Solaris. Is this still true, and if yes, can you give me a detailed description what goes wrong? Greetings, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Oct 15 14:50:38 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA17261 for ; Tue, 15 Oct 1996 14:50:38 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73548; Tue, 15 Oct 1996 15:02:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43238; Tue, 15 Oct 1996 15:01:18 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id PAA23907 for ; Tue, 15 Oct 1996 15:43:15 +0300 (EET DST) Received: from [130.89.179.21] (pc021.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA11905 (5.67b/IDA-1.5 for ); Tue, 15 Oct 1996 14:43:13 +0200 Date: Tue, 15 Oct 96 14:48:30 CST From: "J.J. van der Heijden" Message-Id: <65197.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: proto-FAQ -- reactions please! Status: RO Hello, I gathered some of the recently asked questions, together with some usefull information from various readmes etc. and called it a 'FAQ'. It needs some expanding, especially about the differences between various dialects of the Pascal language. Also, I'm not a native english speaker so there are probably lots of errors. Any feedback is appreciated. It will be texified in the future, so it can be put on a www page. JanJaap =========================================================================== This is the GNU Pascal Frequently-Asked Questions List. Author: J.J. van der Heijden Revision: 0.1, Oct 14, 1996 1 What is GNU Pascal? 1.1 What is the current version of GNU Pascal? 1.2 Where is the GNU Pascal FTP site? WWW? 1.3 Is it compatible with Turbo Pascal (R) ? 2 Installation related questions 2.1 Which platforms are supported by GNU Pascal? 2.2 Which components, other than the GNU Pascal compiler do I need to compile Pascal source code? 2.3 Help! linking gpc1 fails: _emit_string_move undefined (and more) 2.4 When I build libgpc.a, rts-rt0.c says: SIGXCPU undefined (and more) 2.5 I do I debug my Pascal programs? 2.6 Can you recommend an IDE? 2.7 Do we have a binary for you? 3 GNU Pascal and your system libraries 3.1 How do I use from the C library? 3.2 What's this confusion about Pascal and C style strings? 3.3 Are GNU Pascal objects compatible with GNU C++ classes ? 3.4 Where are the Turbo pascal (R) replacement units? 3.5 How do I build/use a shared library? 4 GNU Pascal on the djgpp (MS-DOS) platform 4.1 If you need more information 4.2 What do I download? 4.3 How do I install the compiler? 4.4 GPC says: no DPMI 4.5 I cannot read the info pages! 4.6 I have troubles with inline assembly 4.7 Tell me how to do DPMI, BIOS and other DOS related things. 4.8 I'm accessing an "array[1..4000000] of byte" and I got an exception. 5 Getting Help 5.1 Help! the compiler crashed! 5.2 I think I found a bug -- now what? 5.3 Which newsgroup(s) are suited for GPC related problems? 5.2 How to post to the mailing list 5.3 How to become a subscriber to the mailing list 5.4 How to unsubscribe from the mailing list 6 Miscellany 6.1 I want to contribute, where do I start? 6.2 About this FAQ. 1 What is GNU Pascal? ********************* The purpose of the GNU Pascal project is to produce a Pascal compiler (called GNU Pascal or GPC) which * combines the clarity of Pascal with powerful tools suitable for real-life programming, * supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE. (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989) * supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, * may be distributed under GNU license conditions * can generate code and run on any computer for which the GNU C compiler can generate code and run. Pascal was originally designed for teaching. GNU Pascal provides a smooth way to proceed to challenging programming tasks without learning a completely different language. 1.1 What is the current version of GNU Pascal? ============================================== The last official release is GPC 1.1, based on GNU CC version 2.6.3. GPC version 1.2, based on GCC 2.7.2 is currently in beta testing. 1.2 Where is the GNU Pascal FTP site? WWW? ========================================== The master FTP site for GNU Pascal is kampi.hu.fi GNU Pascal related files can be found in: ftp://ftp.kampi.hut.fi/jtv/gnu-pascal/ This site is mirrored on: ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ The latest developer releases can be downloaded from: ftp://agnes.dida.physik.uni-essen.de/ Also, we have a homepage on the web: http://home.pages.de/~GNU-Pascal/ 1.3 Is it compatible with Turbo Pascal (R) ? ============================================ GPC is currently *not* a drop-in replacement for Borland's Turbo Pascal (R). It supports a number, but not all of the Borland extensions to the Pascal language. There is no replacement for most of the Borland runtime library functions. GNU Pascal is part of the GNU project, so portability is one of its primary goals. For this reason, non-portable features of Borland Pascal will probably not be included into GNU Pascal. More information can be found in the file "bpqstart.txt" 2 Installation related questions ******************************** This section discusses some common problems with the installation of GNU Pascal. 2.1 Which platforms are supported by GNU Pascal? ================================================ GPC uses the GCC backend, so it should run on any system that is supported by GNU CC. This includes a large variety of Unix systems, MS-DOS, OS/2 and Win32. A full list of platforms supported by GCC can be found in the file "INSTALL" of the GCC distribution. Not all of these have actually been tested, but the gpc-1.2 pre-release is know to run on these platforms: i486-linux (Linux 2.x, ELF) i486-linuxaout i486-linuxoldld i486-freebsd2.1 i386-cygwin32 (Windows95/Windows NT) i386-djgppv2 (MS-DOS) i386-emx (OS/2, MS-DOS) mips-sgi-irix5.3 >>> Ok people - send us your success stories, with canonical machine name! <<< 2.2 Which components, other than the GNU Pascal compiler do I need to compile Pascal source code? ===================================================================== A complete Pascal compiler system should at least have: * The actual compiler, GPC. * Assembler, linker, librarian and friends. * A C library. * A debugger, if you want to debug your programs. You don't need a C compiler to compile your Pascal programs, but you do need it to build the GNU Pascal compiler itself. GNU Pascal version 1.1 is based on GCC 2.6.3, GPC v1.2 is based on GCC v2.7.2 Any attempt to build GPC with the wrong version of GCC is bound to fail. For most people, the GNU binutils and GNU debugger (gdb) are a good choice, although some may prefer to use vendor specific tools. 2.3 Help! linking gpc1 fails: _emit_string_move undefined (and more) ==================================================================== If linking gpc1 bombs out with an error message that looks like this: ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' you probably suffer from a VPATH make problem. A few GPC source files have counterparts with identical name in the GCC source directory. When you have built GCC in the GCC source directory and you are not using a recent version of GNU make this problem may occur. There are three solutions: * Get a recent version of GNU make. Version 3.74 or better is known to work. * Build GCC in a seperate directory instead of using the GCC source directory. * Manually delete these files from the GCC object directory: stor-layout.o dbxout.o expr.o fold-const.o optabs.o convert.o function.o setop.o toplev.o then resume `make'. 2.4 When I build libgpc.a, rts-rt0.c says: SIGXCPU undefined (and more) ======================================================================== Compilation of the runtime system may fail in rts-rt0.c with a message simular to this: rts-rt0.c: `SIGXCPU' undeclared (first use this function) or: rts-rt0.c: storage size of `sv' isn't known rts-rt0.c: storage size of `osv' isn't known If this happens to you, you have to edit the rts/rts-config.h file and comment out the last line to: /* #undef HAVE_SIGSYS */ This will be fixed in a future release. 2.5 I do I debug my Pascal programs? ==================================== To debug your programs, (a) GNU Pascal must be able to generate executables with debug info for your platform, and (b) you must have a debugger which understands this. * If `gpc -g -o hello hello.p' says: "gpc: -g not supported for this platform", then GPC is unable to generate debug info. Usually, installing GAS instead of your system's assembler can overcome this. When you configure the GCC used for GPC, specify "--with-gnu-as", and possibly "--with-gnu-ld" and/or "--with-stabs". More information can be found in "INSTALL" file in the GNU CC source directory. * Your system's debugger may not understand the debug info generated by GNU tools. In this case, installing GDB may help. The bottom line: if you can debug GCC compiled programs, you should be able to do this with GPC too. The GNU debugger (GDB) currently does not have a "Pascal" mode, so it is unable to display certain Pascal structures etc. When debugging, please note that the Initial Letter In Each Identifier Is In Upper Case And The Rest Are In Lower Case. If you want to display variable 'foo' in the debugger, type `show Foo' or `display Foo' instead. 2.6 Can you recommend an IDE? ============================= Users of Borland Pascal may wonder if there's a replacement for the IDE (Integrated Development Environment). Here's a few suggestions: * (X)Emacs. Some people think it's the answer to the question of Life, the Universe and Everything, others decide it's uGNUsable. Available from your friendly GNU mirror. * XWPE XWPE is an immitation of the Borland IDE, so users of Borland Pascal may find it a good alternative. Although GDB is an excellent debugger, it's user interface is not very attractive. Refer to the comp.windows.x FAQ: "Where can I get an X-based debugger?" at: http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/part6/faq-doc-2.html Some usefull frontends include: XXGDB, tGDB and XWPE. see: http://www.ee.ryerson.ca:8080/~elf/xapps/Q-IV.html Very nice, but resource consuming is the Motif based DDD: http://sol.ibr.cs.tu-bs.de/softech/ddd/ 2.7 Do we have a binary for you? ================================ Currently, we have binaries for these platforms: i486-linux (ELF) i486-linuxaout i486-linuxoldld djgpp V2 (msdos) emx 0.9B (OS/2, msdos) cygwin32 beta16 (Windows95, Windows NT) mips-sgi-irix5.3 3 GNU Pascal and your system libraries ************************************** This section discusses common problems people have when they try to access their system's libraries. 3.1 How do I use from the C library? ================================================================ GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. man(3) sleep reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; function sleep(seconds: word): word; external; var result : word; begin result := sleep(10); end. --------------------------------------------------------- 3.3 What's this confusion about Pascal and C style strings? =========================================================== It is important not to confuse Pascal and C string types. * The Pascal string schema is a record: STRING = RECORD Capacity : integer; length : integer; string : packed array [ 1..Capacity ] of char; END; 'string' is not 'string(256)', unlike Turbo Pascal. The capacicty must be declared: type MyString = string(256); function MyFunction: MyString; * A C string is an array of char, terminated with a NULL char. C library functions require C, not Pascal style string arguments! Consider this code snippet to convert Pascal style strings to C style and vice versa: --------------------------------------------------------- type word = __unsigned__ integer; TString = string[256]; PChar = ^char; function StrPas(Src: PChar): TString; var S : TString; begin S := ''; if (Src <> NIL) then while ( (Src^ <> chr(0)) AND (length(S) < S.capacity)) do begin S := S + Src^; inc(Word(Src)); end; StrPas := S; end; function StrPCopy(Dest: PChar; Src: String): PChar; var c: integer; p : PChar; begin p := Dest; for c:=1 to length(Src) do begin p^ := Src[c]; inc(word(p)) end; p^ := chr(0); StrPCopy := Dest; end; --------------------------------------------------------- Then this small example will print the PATH: --------------------------------------------------------- function GetEnv(name : PChar): PChar; C; function GetEnv(name : PChar): PChar; external; var pName: PChar; begin getmem(pName, 256); pName := StrPCopy(pName, 'PATH'); writeln('PATH=', StrPas(GetEnv(pName))); freemem(pName, 256); end. --------------------------------------------------------- And this is how you access the 'system()' call in you C library: --------------------------------------------------------- program SysCall; function system(name : PChar): integer; C; function system(name : PChar): integer; external; var pName: PChar; result : integer; begin getmem(pName, 256); pName := StrPCopy(pName, 'ls -l'); result := system(pName); writeln('system() call returned : ', result); freemem(pName, 256); end. --------------------------------------------------------- 3.4 Are GNU Pascal objects compatible with GNU C++ classes ? ============================================================ No. 3.5 Where are the Turbo Pascal (R) replacement units? ===================================================== They don't exist (yet). Most of their fuctionality can easily be implemented, some things are very x86/msdos dependant and would be meaningless on any other platform. 3.6 How do I build/use a shared library? ======================================== (topic under construction) 4 GNU Pascal on the djgpp (MS-DOS) platform ******************************************* This chapter discusses some potential problems with GNU Pascal on MS-DOS, using djgpp. 4.1 If you need more information ================================ GPC/djgpp is a djgpp V2 application, and most of the djgpp documentation applies for GPC too. A great source of information is the djgpp FAQ: http://www.delorie.com/djgpp/v2faq/faq201b.zip Another place to look for DJGPP documentation is the DJGPP Knowledge Base, at this URL: http://www.delorie.com/djgpp/doc/kb/ 4.2 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/djdev200.zip (C library) v2gnu/bnu252b.zip (assembler, ....) v2gnu/gdb412b.zip (debugger) The rest is up to you; 'make' (v2gnu/mak372b.zip) can be usefull, RHIDE (an IDE with Borland-look) is nice, but still under development. Future releases of RHIDE may have better GPC support. 4.3 How do I install the compiler? ================================== If you don't have djgpp installed on your harddisk, create a directory for GNU pascal ("c:\gpc"), and unzip the archives. Make sure you preserve the directory structure (use "pkunzip -d"). Now, add the directory where gpc.exe lives ("c:\gpc\bin") to your path and set the DJGPP environment variable to point to your djgpp.env file: set DJGPP=c:\gpc\djgpp.env Specific information for low-memory conditions and mre can be found in the djgpp FAQ and documentation. 4.4 GPC says: no DPMI ===================== You don't have a DPMI server installed, and DJGPP v2 requires it to run. You can either use one of the commercial DPMI servers (e.g., run `gpc' in a DOS box under Windows) or download and install CWSDPMI (`csdpmi3b.zip') which is a free DPMI server written for DJGPP. 4.5 I cannot read the info pages! ================================= To read the info pages, you need the `info' program from txi360b.zip. At least for some of the pre-releases of gpc-1.2, the gpc.info file is invalid: it refers to the "gpc.i*" sections as "gpc.info-*". This can be fixed by loading gpc.inf in an editor and replacing "gpc.info-*" with "gpc.i*" 4.6 I have troubles with assembly code ====================================== The GNU Assembler (`as.exe'), or `gas', called by GCC accepts "AT&T" syntax which is different from "Intel" syntax. Differences are discussed in section 17.1 of the djgpp FAQ. A guide is available which was written by Brennan Mr. Wacko Underwood and describes how to use inline assembly programming with DJGPP, at this URL: http://www.rt66.com/~brennan/djgpp/djgpp_asm.html Section 17.3 of the djgpp FAQ discusses some methods to convert "Intel" syntax to "AT&T". 4.7 Tell me how to do DPMI, BIOS and other DOS related things. ============================================================== DPMI, BIOS and other functions are no different than other system functions. Refer to section 3.1 how to access your system's C-library. This small example shows how to use DPMI, copying some structures and function prototypes of : --------------------------------------------------------- program dpmitest; {$X+} type word = __unsigned__ integer; short = __short__ integer; byte = __byte__ integer; type PDpmiVersionRet = ^TDpmiVersionRet; TDpmiVersionRet = record major : byte; minor : byte; flags : short; cpu : byte; master_pic : byte; slave_pic : byte; end; type PDpmiFreeMemInfo = ^TDpmiFreeMemInfo; TDpmiFreeMemInfo = record largest_available_free_block_in_bytes : word; maximum_unlocked_page_allocation_in_pages : word; maximum_locked_page_allocation_in_pages : word; linear_address_space_size_in_pages : word; total_number_of_unlocked_pages : word; total_number_of_free_pages : word; total_number_of_physical_pages : word; free_linear_address_space_in_pages : word; size_of_paging_file_partition_in_pages : word; reserved1 : byte; reserved2 : byte; reserved3 : byte; end; function DpmiGetVersion(ret: PDpmiVersionRet): integer; asmname '__dpmi_get_version'; function DpmiGetFreeMemoryInformation(info: PDpmiFreeMemInfo): integer; asmname '__dpmi_get_free_memory_information'; function DpmiGetVersion(ret: PDpmiVersionRet): integer; external; function DpmiGetFreeMemoryInformation(info: PDpmiFreeMemInfo): integer; external; var version: TDpmiVersionRet; meminfo: TDpmiFreeMemInfo; begin DpmiGetVersion(@version); writeln('CPU type : ', version.cpu, '86'); writeln('DPMI major : ', version.major); writeln('DPMI minor : ', version.minor); DpmiGetFreeMemoryInformation(@meminfo); writeln('Free DPMI memory : ', meminfo.total_number_of_free_pages, ' pages.'); end. --------------------------------------------------------- 4.8 I'm accessing an "array[1..4000000] of byte" and I got an exception. ======================================================================== Per default, the maximum stack size of a djgpp application is 256K. If you need more, you have to adjust it with the stubedit program, i.e.: stubedit your_app.exe minstack=5000K Still, it might be a good idea to use pointers for this kind of structures. 5 Getting Help ************** This section discusses ways to get help with GNU Pascal. Please read the documentation (info files, readme's) that come with GPC, plus other docs that might help (the djgpp FAQ if you use djgpp etc.) before you send email to the maintainers or mailing list. 5.1 Help! the compiler crashed! =============================== If the compiler crashes, you have discovered a bug. A reliable compiler never crashes. To help the maintainers fix this bug, it is important that you send us a problem report. 5.2 I think I found a bug -- now what? ====================================== Bugs are best reported to the GPC mailinglist, gpc@hut.fi. That way, they always reach the maintainers. Try to give as much information as possible, plus a short code snippet that triggers the compiler bug. If you're on unix, you can find out where the compiler crashed if you enable coredumps, then load the compiler (gpc1) plus the core file in the debugger ("gdb /your_path_here/gpc1 core"), then type `backtrace' to get a stacktrace. Include this stacktrace in your bug report. 5.3 Which newsgroup(s) are suited for GPC related problems? =========================================================== There are several Pascal related newsgroups, but none is dedicated just to GNU Pascal. These may be usefull: comp.lang.pascal.ansi-iso Pascal according to ANSI and ISO standards. comp.lang.pascal.misc Pascal in general and ungrouped Pascals. 5.2 How to post to the mailing list =================================== You can send a message to the GPC mailing list by sending email to the list address as if it were a person. 5.3 How to become a subscriber to the mailing list ================================================== You can join the mailing list by sending a message to (NOT !) with your request to be added to the list. Maintenance is done by hand, so some delay is possible. 5.4 How to unsubscribe from the mailing list ============================================ To leave the mailing list, send a message to . 6 Miscellany ************ 6.1 I want to contribute, where do I start? =========================================== A list of jobs which should be done for GNU-Pascal can be found in the file `how_to_contrib.txt'. In cases where somebody is already working on a topic, the name of that person is written behind the job's description. This does not mean that you shouldn't do that but just that you should get in contact with that person if you would like to contribute to that field. 6.2 About this FAQ. ================== Maintainer: J.J. van der Heijden This is the first incarnation of the GNU Pascal FAQ list. Comments about, suggestions for, or corrections to this FAQ list are welcome. Please make sure to include in your mail the version number of the document to which your comments apply (you can find the version at the beginning of this FAQ list). Much of the info in this FAQ list was taken from the gpc mailing list traffic, so you may have (unbeknownst to you) contributed to this list. EOF --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Oct 15 23:59:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA17722 for ; Tue, 15 Oct 1996 23:59:07 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75246; Wed, 16 Oct 1996 00:10:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43738; Wed, 16 Oct 1996 00:09:42 +0200 Received: from utkux4.utcc.utk.edu (UTKUX4.UTCC.UTK.EDU [128.169.76.11]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA07953 for ; Wed, 16 Oct 1996 01:00:35 +0300 (EET DST) From: sad@utkux.utcc.utk.edu Received: by utkux4.utcc.utk.edu (SMI-8.6/2.7c-UTK) id SAA17988; Tue, 15 Oct 1996 18:00:32 -0400 Message-Id: <199610152200.SAA17988@utkux4.utcc.utk.edu> Subject: Re: proto-FAQ -- reactions please! To: peter@esmeralda.peter.gerwinski.essen.de (Peter Gerwinski) Date: Tue, 15 Oct 1996 18:00:30 -0400 (EDT) Cc: gpc@hut.fi In-Reply-To: <199610151834.TAA00212@esmeralda.peter.gerwinski.essen.de> from "Peter Gerwinski" at Oct 15, 96 07:34:06 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > Specific information for low-memory conditions and mre can be found in the > ^^^ > Typographic error: "and more". > > > 4.8 I'm accessing an "array[1..4000000] of byte" and I got an exception. > > ======================================================================== > > This is actually a but in GPC. It does occur for global variables in ^^^^ Meta typo :-) Should be 'bug', right? Kind regards! Stefan From gpc-request@santra.hut.fi Tue Oct 15 22:13:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA17669 for ; Tue, 15 Oct 1996 22:13:55 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA88520; Tue, 15 Oct 1996 22:25:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA11958; Tue, 15 Oct 1996 22:24:31 +0200 Received: from esmeralda.peter.gerwinski.essen.de (root@ascend27.extern.uni-essen.de [132.252.240.27]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA04872 for ; Tue, 15 Oct 1996 23:15:03 +0300 (EET DST) Received: (from peter@localhost) by esmeralda.peter.gerwinski.essen.de (8.6.9/8.6.9) id SAA00163 for gpc@hut.fi; Tue, 15 Oct 1996 18:56:31 +0100 From: Peter Gerwinski Message-Id: <199610151756.SAA00163@esmeralda.peter.gerwinski.essen.de> Subject: getenv() and system() To: gpc@hut.fi Date: Tue, 15 Oct 1996 18:56:31 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO According to John Michael Black: > IMHO, I would think that the function getenv() and the procedure system() > would be two widely used routines for a lot of people's programs. Instead > of expecting everyone to "create" them each time, what possibility is > there of including them in a standard library? My BO5 project is intended to become a standard library for GNU Pascal. Its Unit "Tools" already contains a Borland- compatible version of getenv(). > I know they're not > standard or extended pascal, GetEnv is in Borland's DOS Unit, so it's de-facto-standard on DOS-like platforms. Berend already ported some features of DOS to an Extended Pascal module, other things are in BO5, so it should be straightforward to write (at least parts of) a true Borland-compatible DOS Unit. > but like I said it seems like a lot of people > would need to use them. If there isn't an include for operating system > functions, perhaps this could start one. Includes are not part of ISO-Pascal, modules are. With Borland or UCSD Pascal, you can include a file via (*$I foo *) (supported by GPC, too). However in my opinion, a Module or Unit would be preferable. If somebody would like to write such a thing (or already has written), please let me know. Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Oct 15 22:12:26 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA17665 for ; Tue, 15 Oct 1996 22:12:26 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75076; Tue, 15 Oct 1996 22:23:56 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA11900; Tue, 15 Oct 1996 22:23:02 +0200 Received: from esmeralda.peter.gerwinski.essen.de (root@ascend27.extern.uni-essen.de [132.252.240.27]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id XAA04806 for ; Tue, 15 Oct 1996 23:14:53 +0300 (EET DST) Received: (from peter@localhost) by esmeralda.peter.gerwinski.essen.de (8.6.9/8.6.9) id TAA00212 for gpc@hut.fi; Tue, 15 Oct 1996 19:34:06 +0100 From: Peter Gerwinski Message-Id: <199610151834.TAA00212@esmeralda.peter.gerwinski.essen.de> Subject: Re: proto-FAQ -- reactions please! To: gpc@hut.fi Date: Tue, 15 Oct 1996 19:34:06 +0100 (MET) In-Reply-To: <65197.s8806144@mail.student.utwente.nl> from "J.J. van der Heijden" at Oct 15, 96 02:48:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO Hello Jan Jaap, hello everybody! I enjoyed reading this FAQ. (-: Let's hope that all beginners with GNU Pascal will really read it before bombarding me with e-mails. GNUd work! :) :) :) However here are some comments/suggestions/bug reports of mine. ;-) According to J.J. van der Heijden: > 1.1 What is the current version of GNU Pascal? > ============================================== > The last official release is GPC 1.1, based on GNU CC version 2.6.3. > GPC version 1.2, based on GCC 2.7.2 is currently in beta testing. Better: "based on GCC 2.6.3" to avoid confusion between GNU CC =?= GCC. > 1.2 Where is the GNU Pascal FTP site? WWW? > ========================================== > Also, we have a homepage on the web: I suggest "on the World Wide Web". > http://home.pages.de/~GNU-Pascal/ I was reported some trouble accessing it. Perhaps we should add: If this fails, try http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ > 1.3 Is it compatible with Turbo Pascal (R) ? > ============================================ > [...] For this reason, non-portable features of Borland Pascal > will probably not be included into GNU Pascal. More information can be found > in the file "bpqstart.txt" The file "bpqstart.txt" is section "Borland Pascal" of the Texinfo documentation now. > 2.6 Can you recommend an IDE? > ============================= What about RHIDE for DJGPP? > Some usefull frontends include: XXGDB, tGDB and XWPE. see: ^^^^^^^ "useful", not "usefull". ;-) > 2.7 Do we have a binary for you? > ================================ As an asked question it must read: "Do you have a binary for me?" > Currently, we have binaries for these platforms: > [...] Now there is SunOS 4.1.4, too. Thank you, Frank! > function sleep(seconds: word): word; C; > function sleep(seconds: word): word; external; This is redundant. The "C" declaration implies "external" declaration. > 3.3 What's this confusion about Pascal and C style strings? > =========================================================== > It is important not to confuse Pascal and C string types. We should mention here that we are talking about the ISO-10206 definiton of Pascal Strings which is that one used by GPC. > function GetEnv(name : PChar): PChar; C; > function GetEnv(name : PChar): PChar; external; You can and should use Function GetEnv ( Name: __CString__ ): pChar; C; instead. With this declaration, you can pass a String schema as an actual parameter. However, the return value must be a pChar. (Not absolutely sure about this ... maybe a formal pChar parameter can also have an actual String schema parameter ...) > 3.4 Are GNU Pascal objects compatible with GNU C++ classes ? > ============================================================ > No. This compatibility is planned for the far future. At the moment, Pascal objects can be accessed from standard C, however. > Specific information for low-memory conditions and mre can be found in the ^^^ Typographic error: "and more". > 4.8 I'm accessing an "array[1..4000000] of byte" and I got an exception. > ======================================================================== This is actually a but in GPC. It does occur for global variables in the main program, but not in Units or Modules. > 5.3 Which newsgroup(s) are suited for GPC related problems? > =========================================================== > comp.lang.pascal.ansi-iso Pascal according to ANSI and ISO standards. > comp.lang.pascal.misc Pascal in general and ungrouped Pascals. When we recommend comp.lang.pascal.ansi-iso, we must also mention comp.lang.pascal.borland which might be the right choice to discuss Borland compatibility problems and the DJGPP NewsGroup for problems with the DJGPP version. However I suggest to recommend only comp.lang.pascal.misc. Perhaps we should mention the GPC mailing list in this topic, too. > 5.3 How to become a subscriber to the mailing list > ================================================== I am not sure wheter this is correct English. What about "How to subscribe to the mailing list"? > 6 Miscellany > ************ The word exists, but perhaps "Miscellaneous" would be more appropriate? Native speakers! > 6.1 I want to contribute, where do I start? > =========================================== I suggest a semicolon instead of a comma. ;-) > A list of jobs which should be done for GNU-Pascal can be found in the > file `how_to_contrib.txt'. This file is section "How to Contribute" of the Texinfo documentation now. Once again: Very good work, Jan Jaap! Bye everybody, Peter From gpc-request@santra.hut.fi Tue Oct 15 18:39:28 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA17540 for ; Tue, 15 Oct 1996 18:39:28 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77010; Tue, 15 Oct 1996 18:51:01 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48364; Tue, 15 Oct 1996 18:50:07 +0200 Received: from snake.hut.fi (snake.hut.fi [193.167.6.99]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id TAA31382 for ; Tue, 15 Oct 1996 19:42:18 +0300 (EET DST) Received: from alpha.hut.fi (jtv@alpha.hut.fi [130.233.224.50]) by snake.hut.fi (8.7.5/8.7.3) with SMTP id TAA42530 for ; Tue, 15 Oct 1996 19:42:16 +0300 Date: Tue, 15 Oct 1996 19:42:19 +0300 (EET DST) From: Jukka Virtanen To: gpc@hut.fi Subject: Bug report :-) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Reported by: Juki GPC version: 1.2-2.7.2.1 Platform : Digital Alpha, DEC unix 4.0 Description: ------------ The attached program does not compile. narya gpc-1.2-2.7.2.1 58 % gpc fail.p fail.p: In function `zap': fail.p:5: parse error before `Absolute' Attached program: ----------------- program zap; var enumvar : (absolute); begin end. From gpc-request@santra.hut.fi Wed Oct 16 12:03:35 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA18562 for ; Wed, 16 Oct 1996 12:03:34 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80278; Wed, 16 Oct 1996 12:14:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA11692; Wed, 16 Oct 1996 12:13:56 +0200 Received: from server3.syd.mail.ozemail.net (server3.syd.mail.ozemail.net [203.108.7.40]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id NAA22603 for ; Wed, 16 Oct 1996 13:07:51 +0300 (EET DST) Received: from oznet02.ozemail.com.au (oznet02.ozemail.com.au [203.2.192.124]) by server3.syd.mail.ozemail.net (8.7.6/8.6.12) with ESMTP id UAA01104 for ; Wed, 16 Oct 1996 20:07:44 +1000 (EST) Received: from slsyd1p23.ozemail.com.au (slsyd1p23.ozemail.com.au [203.15.164.39]) by oznet02.ozemail.com.au (8.7.6/8.6.12) with SMTP id UAA16454 for ; Wed, 16 Oct 1996 20:07:41 +1000 (EST) Date: Wed, 16 Oct 1996 20:07:41 +1000 (EST) Message-Id: <199610161007.UAA16454@oznet02.ozemail.com.au> X-Sender: inteng@ozemail.com.au X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@hut.fi From: Jim Brander Subject: extend bug Status: RO Running gpc 2.6.3 on ELF format Linux 1.2.13 _p_extend() in rts/rts-file.c has following problem. Program is writing out 3000 line file, extending file for each line (don't grumble, it works this way). File extends OK for several hundred lines (a line or 2 each time), then the contents of the file buffer is spilled, say 20 lines written twice but mucked up on line endings, then extends OK for several hundred more lines, then does it again. The file buffer changes to a different address when spill occurs - that is, while it happens to be the same buffer address used each time, no problem. Doesn't display this behaviour on gpc 2.6.3 on Linux 1.1.59 with a.out format. Is fixed by commenting out line in rts/rts-file.c in _p_extend() int ch = getc(m_FILNUM(File)); File pointer is already pointing at end of file without this line. Regards Jim From gpc-request@santra.hut.fi Wed Oct 16 01:09:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA18001 for ; Wed, 16 Oct 1996 01:09:39 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85610; Wed, 16 Oct 1996 01:21:07 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43632; Wed, 16 Oct 1996 01:20:13 +0200 Received: from atlsyssvr.atlsysnet.com (atlsyssvr.atlsysnet.com [206.28.128.34]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA08561 for ; Wed, 16 Oct 1996 02:15:54 +0300 (EET DST) Message-Id: <199610152315.CAA08561@santra.hut.fi> Received: from async6.ts-bangor.caps.maine.edu [130.111.40.156] by atlsyssvr.atlsysnet.com (AltaVista Mail F2.0/2.0 BL22 listener) id 0000_005d_3264_140c_c48b; Tue, 15 Oct 1996 18:45:32 -0400 From: "Kevin A. Foss" To: "gpc@hut.fi" Date: Tue, 15 Oct 96 19:13:46 -0400 Reply-To: "Kevin A. Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.53 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Call for installation patches and hacks. Status: RO On Tue, 15 Oct 96 15:33:43 CST, J.J. van der Heijden wrote: >We are finishing up preparations for the "final" 1.2 GPC release, and now I >would like to know, did any of you have to apply special hacks to get GPC >up and running? Need to edit a config file, Makefile etc., add special >CFLAGS? I did have to make a couple changes to the OS/2(EMX) makefile in order to get everything working. Specifically, even though gcc_bcmp.c is copied into the RTS directory, it is never referenced in the makefile. (MakeHPFS.RTS) It was only after I tried to compile some code that apparantly needed _gcc_bcmp() that I noticed the problem. So I had to go back and edit the Makefile. Or did I do something wrong? I couldn't find any reference to gcc_bcmp.c/.o in the MakeFAT.RTS file either. I also experienced confusion over which version of Make to use. INSTALL says to use nmake, but README.EMX says to use dmake. (Sorry if this has been addressed before, I just recently joined the list..) -Kevin --- Kevin A. Foss -- kfoss@atlsysnet.com --- From gpc-request@santra.hut.fi Wed Oct 16 18:49:25 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA19171 for ; Wed, 16 Oct 1996 18:49:25 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77540; Wed, 16 Oct 1996 19:00:29 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41666; Wed, 16 Oct 1996 18:59:34 +0200 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id TAA07936 for ; Wed, 16 Oct 1996 19:51:11 +0300 (EET DST) Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <12200-0@relay.xlink.net>; Wed, 16 Oct 1996 17:50:45 +0000 X-Envelope: Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with ESMTP id SAA27773 for ; Wed, 16 Oct 1996 18:50:24 +0200 Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.6.12/8.6.9) with UUCP id SAA14138 for gpc@hut.fi; Wed, 16 Oct 1996 18:47:07 +0100 Received: by hit.sb.sub.de (DUUCP vom 19.09.1996) with ZConnect; 15 Oct 1996 16:38:00 +0200 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6Itt8yDeykB@hit-andi.tio.hit.handshake.de> X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 19.09.1996] In-Reply-To: <65197.s8806144@mail.student.utwente.nl> Subject: Re: proto-FAQ -- reactions please! Date: 15 Oct 1996 16:38:00 +0200 To: gpc@hut.fi Status: RO Diese Nachricht antwortet auf einen Text, den j.j.vanderheijden@student.utwente.nl am Dienstag, den 15.10.96, durch die Datennetze geschossen hat: Hallo J.J. JJvdH> type JJvdH> word = __unsigned__ integer; You should call it longword. I had some trouble, because I declared a word like this and i wondered that the entries after flags had some errors :) Perhaps longword... JJvdH> 4.8 I'm accessing an "array[1..4000000] of byte" and I got an JJvdH> exception. ============================================================ JJvdH> ============ Per default, the maximum stack size of a djgpp JJvdH> application is 256K. If you need more, you have to adjust it with the JJvdH> stubedit program, i.e.: JJvdH> JJvdH> stubedit your_app.exe minstack=5000K JJvdH> JJvdH> Still, it might be a good idea to use pointers for this kind of JJvdH> structures. JJvdH> AB > Or you declare your array like this: AB > AB > var bigdata:__static__ array[1..4000000] of byte; JJvdH> Please make sure to include in your mail the version number of the JJvdH> document to which your comments apply (you can find the version at the JJvdH> beginning of this FAQ list). I think v0.1, wasn't it :) Bye Andreas From gpc-request@santra.hut.fi Thu Oct 17 00:39:46 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA19450 for ; Thu, 17 Oct 1996 00:39:46 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA88768; Thu, 17 Oct 1996 00:50:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54198; Thu, 17 Oct 1996 00:49:57 +0200 Received: from agnes.dida.physik.uni-essen.de (root@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA15596 for ; Thu, 17 Oct 1996 01:43:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA19331 for gpc@hut.fi; Thu, 17 Oct 1996 00:05:21 +0100 From: Peter Gerwinski Message-Id: <199610162305.AAA19331@agnes.dida.physik.uni-essen.de> Subject: Re: Call for installation patches and hacks. To: gpc@hut.fi Date: Thu, 17 Oct 1996 00:05:21 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Kevin A. Foss: > I did have to make a couple changes to the OS/2(EMX) makefile in order to get > everything working. :-( That's strange because I made *a lot* of tests with the EMX version on FAT partitions as well as on HPFS partitions to ensure that you just type [I:\emx\gnu\gpc-272] configure (* configure.cmd *) and [I:\emx\gnu\gpc-272] make (* make.cmd - calls dmake *) and GPC compiles through (assumed that you have compiled GCC before). Are you sure that you aren't using the 2.6.3 EMX patch? (Of course. ;-) Please send me your modified Makefile. > Specifically, even though gcc_bcmp.c is copied into the > RTS directory, it is never referenced in the makefile. (MakeHPFS.RTS) You are right! =:-O > It was > only after I tried to compile some code that apparantly needed _gcc_bcmp() > that I noticed the problem. So I had to go back and edit the Makefile. > > Or did I do something wrong? I couldn't find any reference to gcc_bcmp.c/.o > in the MakeFAT.RTS file either. Again: Please send me your modified Makefile. > I also experienced confusion over which version of Make to use. INSTALL says > to use nmake, but README.EMX says to use dmake. `dmake' is correct. > (Sorry if this has been addressed before, I just recently joined the list..) No, it's a new bug. :-)-: Thank you for the report. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 17 00:56:39 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA19532 for ; Thu, 17 Oct 1996 00:56:39 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94312; Thu, 17 Oct 1996 01:07:44 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40334; Thu, 17 Oct 1996 01:06:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA15798 for ; Thu, 17 Oct 1996 02:01:03 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA19514 for gpc@hut.fi; Thu, 17 Oct 1996 00:50:31 +0100 From: Peter Gerwinski Message-Id: <199610162350.AAA19514@agnes.dida.physik.uni-essen.de> Subject: DJGPP installation problems To: gpc@hut.fi Date: Thu, 17 Oct 1996 00:50:31 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Newsgroups: comp.os.msdos.djgpp References: <01bbbab6$1e0cf340$LocalHost@default> Organization: Universitaet Essen, Germany Reply-To: peter.gerwinski@uni-essen.de Distribution: Niels Heirbaut (heirbaut@pi.net) wrote: > I don't know if this is the right group to post to (I haven't found an > alternative), so please forgive me if this post is off topic. Since this is a DJGPP-specific problem, I think this NewsGroup is appropriate. However, there is a GNU Pascal mailing list, gpc@hut.fi. To subscribe, write to gpc-request@hut.fi. (This followup is also posted to the GPC mailing list.) > I downloaded the binary files for GPC (version 2.7.2) and extracted them to > my DJGPP directory. But when I tried to compile the program hello.pas (see > below) with: C:\>gpc hello.pas -o hello.exe > > I got the next message: > C:\DJGPP\BIN/ld.exe: cannot open crt0.o: No such file or directory (ENOENT) > > I checked if crt0.o existed (it did). I also tried to put the directory > (C:\DJGPP\LIB) in my PATH-variable, but still the same response. In the > info file I read something about setting the variable GPC_EXEC_PREFIX. I > tried this (in DJGPP.ENV and AUTOEXEC.BAT) but it still didn't work. > Here are my program, my AUTOEXEC.BAT and my DJGPP.ENV files: > > [...] > > DJGPP.ENV: > > [...] > > [gcc] > COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin > LIBRARY_PATe=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/lib > > [...] > > [gpc] > GPC_EXEC_PREFIX=%/>;GPC_EXEC_PREFIX%%DJDIR%/lib >From the GPC installation instructions (you might have an older version which does not yet contain this): 8< ------------ Finally, add these lines to your \djgpp\djgpp.env file: --------- cut here ------- cut here --------- [gpc-cpp] C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/include [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib 8< ------------ Hope this helps, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 17 00:53:50 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA19527 for ; Thu, 17 Oct 1996 00:53:50 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78376; Thu, 17 Oct 1996 01:04:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40980; Thu, 17 Oct 1996 01:04:01 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA15697 for ; Thu, 17 Oct 1996 01:57:07 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA19478 for gpc@hut.fi; Thu, 17 Oct 1996 00:46:35 +0100 From: Peter Gerwinski Message-Id: <199610162346.AAA19478@agnes.dida.physik.uni-essen.de> Subject: Word and LongWord To: gpc@hut.fi Date: Thu, 17 Oct 1996 00:46:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Bauer: > JJvdH> type > JJvdH> word = __unsigned__ integer; > You should call it longword. > I had some trouble, because I declared a word like this and i wondered > that the entries after flags had some errors :) > Perhaps longword... A matter of taste and self-discipline while counting bits. ;-) I prefer "word" to stand for the "natural" unsigned integer - which has 32 bits with GNU Pascal. (But I also had trouble with this being a Borland Pascal programmer for many years ... ;-) Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 17 20:19:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA20468 for ; Thu, 17 Oct 1996 20:19:33 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91838; Thu, 17 Oct 1996 20:30:21 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58264; Thu, 17 Oct 1996 20:29:27 +0200 Received: from atlsyssvr.atlsysnet.com (atlsyssvr.atlsysnet.com [206.28.128.34]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id VAA11443 for ; Thu, 17 Oct 1996 21:23:37 +0300 (EET DST) Message-Id: <199610171823.VAA11443@santra.hut.fi> Received: from async12.ts-bangor.caps.maine.edu [130.111.40.162] by atlsyssvr.atlsysnet.com (AltaVista Mail F2.0/2.0 BL22 listener) id 0000_0058_3266_7278_4f11; Thu, 17 Oct 1996 13:52:56 -0400 From: "Kevin A. Foss" To: "gpc@hut.fi" Date: Thu, 17 Oct 96 14:21:29 -0400 Reply-To: "Kevin A. Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.53 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Call for installation patches and hacks. Status: RO On Thu, 17 Oct 96 11:47:26 CST, J.J. van der Heijden wrote: >On Thu, 17 Oct 1996 00:05:21 +0100 (MET), >Peter Gerwinski wrote: > >>According to Kevin A. Foss: >>> Specifically, even though gcc_bcmp.c is copied into the >>> RTS directory, it is never referenced in the makefile. (MakeHPFS.RTS) >> >>You are right! =:-O >> >I never understood what gcc_bcmp.[c|o] did in the RTS. It comes from >libgcc2.a which ends up in libgcc.a. Every app is linked to libgcc.a, so >why duplicate it in libgpc.a? This doesn't seem to be the case in EM's port of gcc. All that exists is the bcmp() based on the BSD implementation. There is no gcc_bcmp in any library that I can find. Peter said later: >I don't understand either, but I got error messages when trying to >compile Pascal programs without it, at least in 2.6.3. Perhaps the >problems have vanished with 2.7.2 (: should check ;). I have both 2.7.2 and 2.7.2.1 installed of EM's gcc (on different machines) and neither has gcc_bcmp in any libraries, including gcc.a. So it -should- definately complain if gcc_bcmp isn't included in gpc.a when linking. This entire discussion reminds me of my other problem about the OS/2 MakeXXX.RTS files: If you run 'make install' -- it doesn't rename libgpc.a to gpc.a when it is copied and the user has to manually rename it before he can compile anything. -Kevin --- Kevin A. Foss -- kfoss@atlsysnet.com --- From gpc-request@santra.hut.fi Thu Oct 17 13:24:53 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA20199 for ; Thu, 17 Oct 1996 13:24:52 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82348; Thu, 17 Oct 1996 13:35:47 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51650; Thu, 17 Oct 1996 13:34:52 +0200 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id OAA31962 for ; Thu, 17 Oct 1996 14:26:41 +0300 (EET DST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Thu, 17 Oct 96 13:26 MEST Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vDqUC-000Uv7C; Thu, 17 Oct 96 12:19 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 17 Oct 1996 13:20:36 +0200 Date: 17 Oct 1996 13:10:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6J37UX2FlJB@rufus.central.de> In-Reply-To: <199610151834.TAA00212@esmeralda.peter.gerwinski.essen.de> Subject: Re: proto-FAQ -- reactions please! X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo peter, Am 15.10.96 um 19:34 sagtest Du zum Thema "Re: proto-FAQ -- reactions please!": > > function GetEnv(name : PChar): PChar; C; > > function GetEnv(name : PChar): PChar; external; > > You can and should use > > Function GetEnv ( Name: __CString__ ): pChar; C; > > instead. With this declaration, you can pass a String schema as > an actual parameter. However, the return value must be a pChar. > (Not absolutely sure about this ... maybe a formal pChar parameter > can also have an actual String schema parameter ...) Would be a nice thing - but it dos'nt work ... If you call this GetEnv you get an error: "incompatible type for argument 1 of 'GetEnv'" The other way : function GetEnv(name : PChar): PChar; C; This also not work with the string-conversion from the faq ;-( Every time I get a empty string from "GetEnv". (I tried it under DOS.) ___, ((__ o ,____)) V E N I Moment please ... I think I've found a solution: Function GetEnv (var Name: __CString__ ): pChar; C; ^^^ You get a warning about incompatible pointers, but it works ... Please remove this stupid warning and I'm happy. Yes, I know - I can use {$W-}, but it's not so elegant ;-) From gpc-request@santra.hut.fi Thu Oct 17 11:58:16 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA20082 for ; Thu, 17 Oct 1996 11:58:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81686; Thu, 17 Oct 1996 12:09:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53624; Thu, 17 Oct 1996 12:08:16 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA28650 for ; Thu, 17 Oct 1996 13:01:22 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA20044 for gpc@hut.fi; Thu, 17 Oct 1996 11:51:00 +0100 From: Peter Gerwinski Message-Id: <199610171051.LAA20044@agnes.dida.physik.uni-essen.de> Subject: Re: Call for installation patches and hacks. To: gpc@hut.fi Date: Thu, 17 Oct 1996 11:51:00 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > >According to Kevin A. Foss: > >> I did have to make a couple changes to the OS/2(EMX) makefile in order to get > >> everything working. It seems to be an incompatibility between EMX 0.9b and EMX0.9c. According to J.J. van der Heijden: > I never understood what gcc_bcmp.[c|o] did in the RTS. It comes from > libgcc2.a which ends up in libgcc.a. Every app is linked to libgcc.a, so > why duplicate it in libgpc.a? I don't understand either, but I got error messages when trying to compile Pascal programs without it, at least in 2.6.3. Perhaps the problems have vanished with 2.7.2 (: should check ;). Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 17 11:39:26 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA20019 for ; Thu, 17 Oct 1996 11:39:26 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82206; Thu, 17 Oct 1996 11:50:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39842; Thu, 17 Oct 1996 11:49:27 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id MAA27831 for ; Thu, 17 Oct 1996 12:41:56 +0300 (EET DST) Received: from [130.89.179.57] (pc057.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA18885 (5.67b/IDA-1.5 for ); Thu, 17 Oct 1996 11:41:54 +0200 Date: Thu, 17 Oct 96 11:47:26 CST From: "J.J. van der Heijden" Message-Id: <55308.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: Call for installation patches and hacks. Status: RO On Thu, 17 Oct 1996 00:05:21 +0100 (MET), Peter Gerwinski wrote: >According to Kevin A. Foss: >> I did have to make a couple changes to the OS/2(EMX) makefile in order to get >> everything working. > [...] > >> Specifically, even though gcc_bcmp.c is copied into the >> RTS directory, it is never referenced in the makefile. (MakeHPFS.RTS) > >You are right! =:-O > I never understood what gcc_bcmp.[c|o] did in the RTS. It comes from libgcc2.a which ends up in libgcc.a. Every app is linked to libgcc.a, so why duplicate it in libgpc.a? JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Thu Oct 17 01:16:19 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA19568 for ; Thu, 17 Oct 1996 01:16:19 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93538; Thu, 17 Oct 1996 01:27:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50458; Thu, 17 Oct 1996 01:26:30 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA15848 for ; Thu, 17 Oct 1996 02:21:41 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id QAA00765; Wed, 16 Oct 1996 16:22:53 -0700 Date: Wed, 16 Oct 1996 16:22:53 -0700 From: Phil Nelson Message-Id: <199610162322.QAA00765@fawn.cs.wwu.edu> To: gpc@hut.fi Subject: GPC Bugs .... Status: RO Hello GPC fans, Recently a gnats database was set up for GNU Pascal. Gnats is the GNU bugtracking system. This will allow the developers of GNU Pascal follow bugs and bug fixes much better. It will also allow users of GNU Pascal to see if a bug has been reported before and/or fixed. You many both search the bug database and submit new bug reports at the URL http://fawn.cs.wwu.edu/~phil/gpc. A link to this site will be added to the GNU Pascal home page soon. (The GNU Pascal home page is http://agnes.dida.physik.uni-essen.de/~gnu-pascal.) Currently, a report of a bug to the GNU Pascal gnats site will send a message to gpc@hut.fi so we can all see which bugs have been reported. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Fri Oct 18 00:33:14 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA20798 for ; Fri, 18 Oct 1996 00:33:14 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80602; Fri, 18 Oct 1996 00:43:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA13034; Fri, 18 Oct 1996 00:43:04 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id BAA14548 for ; Fri, 18 Oct 1996 01:38:21 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA20764 for gpc@hut.fi; Fri, 18 Oct 1996 00:28:11 +0100 From: Peter Gerwinski Message-Id: <199610172328.AAA20764@agnes.dida.physik.uni-essen.de> Subject: Re: proto-FAQ -- reactions please! To: gpc@hut.fi Date: Fri, 18 Oct 1996 00:28:11 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Sven Hilscher: > Would be a nice thing - but it dos'nt work ... > If you call this GetEnv you get an error: > "incompatible type for argument 1 of 'GetEnv'" It does work with me, on Linux as well as with DJGPP. EMX compiles it without complain but doesn't read the environment variable :-( I have to investigate this ...) > The other way : > function GetEnv(name : PChar): PChar; C; > > This also not work with the string-conversion from the faq ;-( > Every time I get a empty string from "GetEnv". (I tried it under DOS.) Same as what I get with __CString__ and EMX. > Moment please ... I think I've found a solution: > > Function GetEnv (var Name: __CString__ ): pChar; C; > ^^^ > You get a warning about incompatible pointers, but it works ... > Please remove this stupid warning and I'm happy. Yes, I know - I can use > {$W-}, but it's not so elegant ;-) It's getting more and more strange ... this (with "var") should *not* work: __CString__ already denotes a pointer as required by the C library function, and with "var" you pass a pointer to that pointer ... no, the latter was wrong. Your function *expects* a pointer to the pointer, but you pass the pointer itself, so you get the warning, but you pass the correct thing. It works. ;-) However the correct thing would still be Function GetEnv ( Name: __CString__ ): pChar; C; without "var". You are using DJGPP, correct? There it worked on my computer. Try the "GetEnv" from BO5s (no apostrophy: it's a German abbreviation ;) "Tools" Unit. (Must probably isolate it because BO5 is not (yet!) ready to work with DJGPP.) It worked here also. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Fri Oct 18 10:18:31 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA21175 for ; Fri, 18 Oct 1996 10:18:30 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90634; Fri, 18 Oct 1996 10:29:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57986; Fri, 18 Oct 1996 10:28:11 +0200 Received: from gabriel.keele.ac.uk (gabriel.keele.ac.uk [160.5.1.248]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id LAA24119 for ; Fri, 18 Oct 1996 11:22:30 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel.keele.ac.uk with SMTP (PP); Fri, 18 Oct 1996 09:22:27 +0100 Received: from [0.3.13.44] by potter.cc.keele.ac.uk; Fri, 18 Oct 1996 09:22:22 +0100 From: The African Chief To: Andreas Bauer Cc: gpc@hut.fi Subject: Re: How to implement writeln() Message-Id: Date: Fri, 18 Oct 1996 09:27:15 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On 17 Oct 1996 18:08:00 +0200 Andreas Bauer wrote: >I'm currently programming a bp-like CRT unit. >But i don't know how to do writeln(), which is not limited, >neither in the number of arguments nor in the type of this. This type of thing has to be catered for internally by the compiler itself. This is how Borland does it. I don't see how you can do it without changing the internals of the compiler to handle it specifically. Warmest regards, Dr A. Olowofoyeku (The African Chief, and the Great Elephant) Senior Lecturer, School of Law, Keele University, England. Author of: Chief's Installer Pro v2.91 for Win16 and Win32. Email: laa12@cc.keele.ac.uk Home Page: http://ourworld.compuserve.com/homepages/African_Chief/ From gpc-request@santra.hut.fi Fri Oct 18 08:57:40 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA21095 for ; Fri, 18 Oct 1996 08:57:40 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85180; Fri, 18 Oct 1996 09:08:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37078; Fri, 18 Oct 1996 09:07:21 +0200 Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id KAA21403 for ; Fri, 18 Oct 1996 10:02:19 +0300 (EET DST) Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <45078-0@relay.xlink.net>; Fri, 18 Oct 1996 07:59:54 +0000 X-Envelope: Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by sbusol.rz.uni-sb.de (8.6.12/v2.0) with ESMTP id IAA03661 for ; Fri, 18 Oct 1996 08:59:53 +0200 Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.6.12/8.6.9) with UUCP id IAA22605 for gpc@hut.fi; Fri, 18 Oct 1996 08:56:09 +0100 Received: by hit.sb.sub.de (DUUCP vom 19.09.1996) with ZConnect; 17 Oct 1996 18:08:00 +0200 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6J0uJ88eykB@hit-andi.tio.hit.handshake.de> X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 19.09.1996] Subject: How to implement writeln() Date: 17 Oct 1996 18:08:00 +0200 To: gpc@hut.fi Status: RO Hi I'm currently programming a bp-like CRT unit. But i don't know how to do writeln(), which is not limited, neither in the number of arguments nor in the type of this. Bye Andreas From gpc-request@santra.hut.fi Sun Oct 20 14:47:03 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA23352 for ; Sun, 20 Oct 1996 14:47:03 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72404; Sun, 20 Oct 1996 14:56:48 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60260; Sun, 20 Oct 1996 14:55:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id PAA25589 for ; Sun, 20 Oct 1996 15:50:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA23335 for gpc@hut.fi; Sun, 20 Oct 1996 14:40:57 +0100 From: Peter Gerwinski Message-Id: <199610201340.OAA23335@agnes.dida.physik.uni-essen.de> Subject: Re: System.pas module To: gpc@hut.fi Date: Sun, 20 Oct 1996 14:40:57 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello Berend, hello everybody! The system.pas module triggers one bug in GPC concerning String schemas as parameters: > procedure GetDir(D: byte; var s: string); declares a string schema without specified length as a formal parameter. When trying to use it with an actual parameter which must have a specified length, the compiler crashes. To work around, always specify string length, e.g. procedure GetDir(D: byte; var s: string255); According to Berend de Boer: > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version. Berend, you know that the normal GNU GPL implies that a program linked with your module automatically becomes free software? If you want to enable commercial use of your module, either state explicitely that the above does *not* hold, or use the GNU LGPL (GNU Library General Public License) instead of the normal GPL. > type > shortint = __byte__ integer; > byte = __byte__ integer; That's incompatible with Borland's definition of "byte". They have byte = __unsigned__ shortint; Same holds for "word". > TChar = array[0..MaxInt] of char; > PChar = TChar; > pointer = void; It must be PChar = ^TChar; pointer = ^void; with adaptions below when "PChar" is used. On my machine, your module compiled (?!;), but "GetDir" always returned empty strings for this reason. > string255= string(255); > > var > {?ExitProc: Pointer; { Exit procedure } Can be implemented using "to end do" and GPC's pointers to procedures. > export > System = (shortint, byte, word, longint, PChar, pointer, string255, > HeapError, ExitCode, PrefixSeg, > Assign, BPChDir => ChDir, Close, Copy, Dec, Delete, Erase, > GetDir, GetMem, > Inc, IOResult, > MaxAvail, MemAvail, BPMkDir => MkDir, > ParamCount, ParamStr, > BPRename => Rename, BPRmDir => RmDir, > UpCase); "Inc", "dec", "GetMem" are in GPC (and couldn't be implemented in a module anyway) - and there is no implementation of them in the body. Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Oct 20 17:28:46 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA23415 for ; Sun, 20 Oct 1996 17:28:46 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65910; Sun, 20 Oct 1996 17:38:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA12658; Sun, 20 Oct 1996 17:37:36 +0200 Received: from mailhost.pi.net (root@mailhost.pi.net [145.220.3.9]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA26540 for ; Sun, 20 Oct 1996 18:29:18 +0300 (EET DST) Received: from default (hedr42.pi.net [145.220.220.42]) by mailhost.pi.net (8.7.5/8.7.1) with ESMTP id RAA05146 for ; Sun, 20 Oct 1996 17:29:14 +0200 (MET DST) Posted-Date: Sun, 20 Oct 1996 17:29:14 +0200 (MET DST) Message-Id: <199610201529.RAA05146@mailhost.pi.net> From: "Niels Heirbaut" To: "GPC Mailing List" Subject: Re: Trouble with GPC Date: Sun, 20 Oct 1996 17:26:58 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Hi, I want to thank everybody who has helped me getting GPC started, but another problem came up: I get the following messages when I try to compile my program: _main.c(.text+0x1a): undefined reference to `djgpp_last_ctor' _main.c(.text+0x1f): undefined reference to `djgpp_first_ctor' _main.c(.text+0x2f): undefined reference to `djgpp_first_ctor' exit.c(.text+0x29): undefined reference to `djgpp_last_dtor' exit.c(.text+0x2e): undefined reference to `djgpp_first_dtor' exit.c(.text+0x3f): undefined reference to `djgpp_first_dtor' I couldn't find any reference to these error messages in the GPC info files or DJGPP FAQ. Could some please help me (again)? here are my env.lst and messages with the -v option on: C:\>type env.lst TMP=C:\WINDOWS\TEMP winbootdir=C:\WINDOWS COMSPEC=C:\WINDOWS\COMMAND.COM PROMPT=$p$g PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\DOS;C:\DJGPP\BIN;C:\DJGPP\LIB;C:\PHOTO ;C:\PKWARE TEMP=C:\DOS DJGPP=C:\DJGPP\DJGPP.ENV windir=C:\WINDOWS BLASTER=A220 I10 D3 T4 CMDLINE=gpc -v test.pas -o test.exe C:\>gpc -v test.pas -o test.exe gpc version 1.2(2.7.2) gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=1 -D__GPC__=1 -D__GNUC_MINOR__=2(2 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) test.pas c:/djgpp/tmp\ccbaaaaa.i GNU CPP version 1.2(2.7.2) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/include /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.7.2/include /usr/include End of search list. c:/djgpp/bin\gpc1.exe c:/djgpp/tmp\ccbaaaaa.i -quiet -dumpbase test.pas -version -o c:/djgpp/tmp\cccaaaaa.s GNU Pascal version 1.2(2.7.2) (80386, BSD syntax) compiled by GNU C version 2.7.2. c:/djgpp/bin\as.exe -o c:/djgpp/tmp\ccdaaaaa.o c:/djgpp/tmp\cccaaaaa.s c:/djgpp/bin\ld.exe c:/djgpp/lib\crt0.o -Lc:/djgpp/lib c:/djgpp/tmp\ccdaaaaa.o -lgpc -lgcc -lm -lc -lgcc _main.c(.text+0x1a): undefined reference to `djgpp_last_ctor' _main.c(.text+0x1f): undefined reference to `djgpp_first_ctor' _main.c(.text+0x2f): undefined reference to `djgpp_first_ctor' exit.c(.text+0x29): undefined reference to `djgpp_last_dtor' exit.c(.text+0x2e): undefined reference to `djgpp_first_dtor' exit.c(.text+0x3f): undefined reference to `djgpp_first_dtor' I also would like to know where I could get the latest version of GPC. Mine came from ftp://kampi.hut.fi/. But there was no installation manual or DJGPP.ENV included with the binary *.ZIP file. Thanks in advance again, Niels Heirbaut From gpc-request@santra.hut.fi Sun Oct 20 19:15:22 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA23586 for ; Sun, 20 Oct 1996 19:15:22 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65986; Sun, 20 Oct 1996 19:25:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA07676; Sun, 20 Oct 1996 19:24:10 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id UAA27593 for ; Sun, 20 Oct 1996 20:18:55 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA23536 for gpc@hut.fi; Sun, 20 Oct 1996 19:09:46 +0100 From: Peter Gerwinski Message-Id: <199610201809.TAA23536@agnes.dida.physik.uni-essen.de> Subject: Main Program Name decapitalization To: gpc@hut.fi Date: Sun, 20 Oct 1996 19:09:46 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi everybody, I was reported several errors resulting from the decapitalization of the main program's name, e.g. Program Log; begin writeln ( ln ( 2.7184 ) ); end. crashed because the program's name was decapitalized, i.e. "Log" was mapped to "log" which did hide the function in libm.a ... One could think about letting the program name like it is, say "Log". But (as Juki writes in gpc-util.c :-) the standard says that the program's name has to go into a separate name space i.e. mustn't be visible inside the program's declaration part and body. I solved the problem by mapping "Name" to "program_Name" instead of "name". But this is not the end of the story. Borland Pascal defines so-called qualified identifiers: Program Foo; Function writeln: Real; begin (* writeln *) writeln:= 2.7184; end (* writeln *); begin System.writeln ( Foo.writeln ); end. So the program's name *must* go into its declaration part and body -- and we have a classical tragedy. How to proceed? I think Borland Pascal's qualified identifiers are important and must be implemented, one day. Introduce another command line switch? My own suggestion follows. ;-) We should "clean up" Pascal standards in the future by making the (existing) command line switches to force one standard: --standard-pascal --extended-pascal --borland-pascal ... Without any switch, GPC will try to support *all* standards and warn about misuse (e.g. Borland's typed constants as initialized variables). The default for this case would be to *have* qualified identifiers (i.e. "Program Log" would yield "Log", not "log" and not "program_Log"); with "--standard-pascal" or "--extended-pascal" it would separate the program's name from the rest of the world (and create "program_Log"). Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Oct 21 12:34:32 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA24125 for ; Mon, 21 Oct 1996 12:34:31 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83582; Mon, 21 Oct 1996 12:43:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63506; Mon, 21 Oct 1996 12:43:03 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id NAA10644 for ; Mon, 21 Oct 1996 13:32:30 +0300 (EET DST) Received: from [130.89.179.22] (pc022.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA17783 (5.67b/IDA-1.5 for ); Mon, 21 Oct 1996 12:32:29 +0200 Date: Mon, 21 Oct 96 12:38:32 CST From: "J.J. van der Heijden" Message-Id: <58099.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: Asmname Directive Status: RO On Sun, 20 Oct 96 22:30:09 -0400, Kevin A. Foss wrote: >Hello, > >I am having trouble getting gpc to call external function names the way I >would like. According to builtin.texi, there is a directive called 'Asmname' >which should allow for case sensitive function names. > >However when I declare: > >function WinInitialize(fsoptions : u_long) : u_long; Asmname; >[u_long is a type defined elsewhere] > >gpc responds with a parse error on the line. What is the correct format for >using the 'Asmname' directive? -- I couldn't find it mentioned anywhere else >in the docs. > >Using C or EXTERN in place of Asmname it produces calls to _wininitialize or >_Wininitialize, neither of which I want. > You must give asmname an argument -- the name you would like to have in the object code. So, if you would like to have '_MyMixedCaseName', you do: function MyMixedCaseName: integer; asmname 'MyMixedCaseName'; It also allows this: function MyOtherName: integer; asmname 'MyMixedCaseName'; Hope this helps, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Mon Oct 21 04:28:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA23854 for ; Mon, 21 Oct 1996 04:28:33 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59882; Mon, 21 Oct 1996 04:38:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62572; Mon, 21 Oct 1996 04:37:13 +0200 Received: from atlsyssvr.atlsysnet.com (atlsyssvr.atlsysnet.com [206.28.128.34]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id FAA32338 for ; Mon, 21 Oct 1996 05:32:09 +0300 (EET DST) Message-Id: <199610210232.FAA32338@santra.hut.fi> Received: from buoy11.atlsysnet.com [206.28.128.45] by atlsyssvr.atlsysnet.com (AltaVista Mail F2.0/2.0 BL22 listener) id 0000_0055_326a_e138_bd9e; Sun, 20 Oct 1996 22:34:32 -0400 From: "Kevin A. Foss" To: "GPC Mailing List" Date: Sun, 20 Oct 96 22:30:09 -0400 Reply-To: "Kevin A. Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.53 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Asmname Directive Status: RO Hello, I am having trouble getting gpc to call external function names the way I would like. According to builtin.texi, there is a directive called 'Asmname' which should allow for case sensitive function names. However when I declare: function WinInitialize(fsoptions : u_long) : u_long; Asmname; [u_long is a type defined elsewhere] gpc responds with a parse error on the line. What is the correct format for using the 'Asmname' directive? -- I couldn't find it mentioned anywhere else in the docs. Using C or EXTERN in place of Asmname it produces calls to _wininitialize or _Wininitialize, neither of which I want. -Kevin --- Kevin A. Foss -- kfoss@atlsysnet.com --- --- Kevin A. Foss -- kfoss@atlsysnet.com --- From gpc-request@santra.hut.fi Wed Oct 23 17:16:09 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA27268 for ; Wed, 23 Oct 1996 17:16:09 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69672; Wed, 23 Oct 1996 17:24:48 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40192; Wed, 23 Oct 1996 17:23:50 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id SAA26602 for ; Wed, 23 Oct 1996 18:14:31 +0300 (EET DST) Received: from [130.89.179.58] (pc058.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA16104 (5.67b/IDA-1.5 for ); Wed, 23 Oct 1996 17:14:30 +0200 Date: Wed, 23 Oct 96 17:20:50 CST From: "J.J. van der Heijden" Message-Id: <73518.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: Trouble with GPC Status: RO On Sun, 20 Oct 1996 17:26:58 +0100, Niels Heirbaut wrote: > > > >Hi, > >I want to thank everybody who has helped me getting GPC started, but >another problem came up: > >I get the following messages when I try to compile my program: > >_main.c(.text+0x1a): undefined reference to `djgpp_last_ctor' >_main.c(.text+0x1f): undefined reference to `djgpp_first_ctor' >_main.c(.text+0x2f): undefined reference to `djgpp_first_ctor' >exit.c(.text+0x29): undefined reference to `djgpp_last_dtor' >exit.c(.text+0x2e): undefined reference to `djgpp_first_dtor' >exit.c(.text+0x3f): undefined reference to `djgpp_first_dtor' > >I couldn't find any reference to these error messages in the GPC info files >or DJGPP FAQ. Could some please help me (again)? > Reread the faq. especially section 8.13 (18.3?) which is all about this problem. You have probably edited your djgpp.env file and screwed up the library path. This is my djgpp.env, which works. The sections [gpc] and [gpc-cpp] are important here. They are copied from [gcc] and [cpp] resp. Hope this helps, JanJaap ----------------- djgpp.env --------------- #= Don't edit this line unless you move djgpp.env outside #= of the djgpp installation directory. If you do move #= it, set DJDIR to the directory you installed DJGPP in. #= DJDIR=%:/>DJGPP% +USER=dosuser +TMPDIR=%TEMP% +EMU387=%DJDIR%/bin/emu387.dxe +LFN=n [bison] BISON_HAIRY=%DJDIR%/lib/bison.hai BISON_SIMPLE=%DJDIR%/lib/bison.sim [cpp] CPLUS_INCLUDE_PATH=%/>;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/lang/cxx/tvision;%DJDIR%/include;%DJDIR%/contrib/grx20/include C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/include;%DJDIR%/contrib/grx20/include OBJCPLUS_INCLUDE_PATH=%/>;OBJCPLUS_INCLUDE_PATH%%DJDIR%/include;%DJDIR%/lang/objc OBJC_INCLUDE_PATH=%/>;OBJC_INCLUDE_PATH%%DJDIR%/include;%DJDIR%/lang/objc [gcc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/lib [info] INFOPATH=%/>;INFOPATH%%DJDIR%/info [gpc-cpp] C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/lang/pascal;%DJDIR%/include;%DJDIR%/contrib/grx20/include [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/lib ------------------------------------------- --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Oct 23 08:03:03 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA26286 for ; Wed, 23 Oct 1996 08:03:03 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72438; Wed, 23 Oct 1996 08:11:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57062; Wed, 23 Oct 1996 08:08:34 +0200 Received: from csunix1.lvc.edu (jm_black@csunix1.lvc.edu [207.87.98.5]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id JAA05450 for ; Wed, 23 Oct 1996 09:00:31 +0300 (EET DST) Received: from localhost (jm_black@localhost) by csunix1.lvc.edu (8.7.5/8.7.3) with SMTP id CAA02016 for ; Wed, 23 Oct 1996 02:03:58 -0400 Date: Wed, 23 Oct 1996 02:03:57 -0400 (EDT) From: John Michael Black To: gpc@hut.fi Subject: getenv - any solutions? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO There's been a lot of getenvs going around here lately. :) Has anyone found a method that works yet? The last thing posted about it gave this: Function GetEnv ( Name: __CString__ ): PChar; C; GPC does not recognize PChar -- at least ours doesn't. This could go on for weeks.... :) -john jm_black@csunix1.lvc.edu From gpc-request@santra.hut.fi Wed Oct 23 06:33:21 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id GAA26242 for ; Wed, 23 Oct 1996 06:33:21 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81276; Wed, 23 Oct 1996 06:42:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55748; Wed, 23 Oct 1996 06:41:14 +0200 Received: from server3.syd.mail.ozemail.net (server3.syd.mail.ozemail.net [203.108.7.40]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id HAA03846 for ; Wed, 23 Oct 1996 07:31:14 +0300 (EET DST) Received: from oznet02.ozemail.com.au (oznet02.ozemail.com.au [203.2.192.124]) by server3.syd.mail.ozemail.net (8.7.6/8.6.12) with ESMTP id OAA19065 for ; Wed, 23 Oct 1996 14:31:11 +1000 (EST) Received: from slsyd1p06.ozemail.com.au (slsyd1p06.ozemail.com.au [203.15.164.22]) by oznet02.ozemail.com.au (8.7.6/8.6.12) with SMTP id OAA18478 for ; Wed, 23 Oct 1996 14:30:48 +1000 (EST) Date: Wed, 23 Oct 1996 14:30:48 +1000 (EST) Message-Id: <199610230430.OAA18478@oznet02.ozemail.com.au> X-Sender: inteng@ozemail.com.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: gpc@hut.fi From: Jim Brander Subject: 2.7.2 compiler Status: RO Ran binary distribution 2.7.2 elf format compiler on three files which compile cleanly on 2.6.3. Each time gpc1 failed with segmentation fault in comp_object_pointer_types () but with dissimilar record structures being compared.=20 Here is gdb trace of one failure - file is 20000 lines, failure at 8000= lines >er_end_main Away Away_or_both Towards_or_both Towards Direq Single_direq Makelist Makelistup Duplicate_list Duplicate_node Getnumvalue Getlists Makelistx Makesave Getxset Getxset_from_listarr Find_create_var Add_inconsistency Check_inconsistency Setfalsevar Check_where Partset Makepossle Equalxset Compare_members Compare_lists Listequality String_equality Test_equality Attach_link Patmatch Mesg Ztrim Subs2 Subs3 All_numeric Bnch Bran Create_operator New_link Cut_link Findsubhead Create_sub Buildsub Writej Plusminus Makeset Setpoints Getnum Debug_state Listkill Add_mber_to_list Solution Undoable Remove_member_from_list Add_delete_list Goal Add_data Cleaned_path Add_search Add_variable Highsearch Check_searcFirst_rec New_job_rec First New_job Remove Remove_shuffle Remove_q Remove_search Remove_data Pointing Point_link Pointed_at Setconsistentlink A_link_job Get_link Clear Remove_entry Clear_obsolete Killdata Next_job Killlist Kill_entry Kill_inference Kill_invoc Kill_branch Check_level Adush Check_path Check_out Check_any Check_zero Rate_action List_unlink Breaklink Destroy_constant_list Kill_fun2 Kill_fun3 Another Kill_externalhange_environment Clear_environment Killnet Add_clean Purge_cleanjob_of Add_match Nosearch Cleanupjobs Cleanup Cleanvar Setlinkdata Linksearch t_first_link Uke_out Check_list Link_open Path_open Deadend Reconnoitre Check_paths Contingency_plan Check_tuf Search_for_link Getrange Setvarfmlink Build_list Same_pred Side_link Funcop Symmetric Searches_in Equality Valid Find_search_in Search_in Find_info Revive Start_up_job Clean_uDo_cleaning Find_link Traverse_network Mirror_image Nan Shortnan Pushdata Find_environment Purge_search Gettrueset Unsetlist Readfilename Read_ion_list Next_nextch Getchar Skipblanks Lex_string Lex_id >Program received signal SIGSEGV, Segmentation fault. >0x8011c33 in comp_object_pointer_types (lhs=3D0x817b3e4, rhs=3D0x8590dc0)= at gpc-typeck.c:626 >626 for (r =3D rhs; r; r =3D TYPE_LANG_SPECIFIC (r)->elts [1]) >(gdb) l >621 tree lhs, rhs; >622 { >623 register tree r; >624 if (TREE_CODE (lhs) =3D=3D RECORD_TYPE >625 && TREE_CODE (rhs) =3D=3D RECORD_TYPE) >626 for (r =3D rhs; r; r =3D TYPE_LANG_SPECIFIC (r)->elts [1]) >627 { >628 if (comptypes (lhs, r)) >629 return 1; >630 } >(gdb) p r >$1 =3D (union tree_node *) 0x8590dc0 >(gdb) p rhs >$2 =3D (union tree_node *) 0x0 >(gdb) p lhs >$3 =3D (union tree_node *) 0x817b3e4 >(gdb) where >#0 0x8011c33 in comp_object_pointer_types (lhs=3D0x817b3e4, rhs=3D0x8590dc= 0) at gpc-typeck.c:626 >#1 0x8016e76 in convert_for_assignment (type=3D0x8208ac8, rhs=3D0x859b31c, errtype=3D0x0, fundecl=3D0x817b9f0, funname=3D0x8178e20, parmnum=3D1) > at gpc-typeck.c:4960 >#2 0x80139ae in convert_arguments (typelist=3D0x817b90c, values=3D0x859b2f= 4, name=3D0x8178e20, fundecl=3D0x817b9f0) at gpc-typeck.c:2359 The record being compared, and the offending function >procedure read_orion_list(fs: string300; transient: Boolean; > anchor: net_index; var ls:logstate); >label > error_exit; (* When abandoning hope *) >const > maxlevels =3D 50; (* Maximum depth of lists within lists *) > max_string =3D 63; (* maximum length identifier string *) >type > symtype =3D (uninit, curly_left, curly_right, lit_string, comma, > number, logcon, identifier, endfile, dot_dot, from_to, > maybe,ellip); > lexical_symbol =3D record > case sym: symtype of > lit_string: (str_val: string(maxstring)); > number: (val: real); > logcon: (log: logstate); > identifier: (name: string(max_string); id_type: ltype; > use: usage); > end; (* lexical_symbol *) > >var > edfile: text; (* File to read from *) > b : BindingType; > string_pp: integer; (* position in command *) > file_io: Boolean; (* Reading from file? *) > readlist_nextch: char; (* next input char *) > eoln1, > eof1: Boolean; > s1 : string300; > > s2,s3: string(maxstring); (* used for opening file *) > i, > max1: integer; > set1: listarr; > prevprevsym, > prevsym, > now_sym, > nextsym: lexical_symbol; > filebuf: string(maxlinelen); > >function next_nextch(far:integer;file_or_string:boolean): char; >(* Returns character beyond nextch *) >var ch,nnch:char; >begin > if file_or_string > then begin > if length(filebuf) < far > then nnch :=3D ' ' > else nnch :=3D filebuf[far]; > end > else begin > if string_pp+far > length(system_data.p^.command) > then nnch :=3D ' ' > else begin > ch :=3D system_data.p^.command[string_pp+far]; > if ch =3D chr(10) > then nnch :=3D ' ' > else nnch :=3D ch; > end; > end; >next_nextch :=3D nnch; >end; (* func next_nextch *) > >procedure getchar(file_or_string:boolean); >(* input is managed by this routine, and the following variables: > * file_io, edfile, system_data.p^.command, nextch, eoln1, eof1. > *) >begin >while true do begin > if file_or_string > then begin > if filebuf =3D '' > then begin > if eoln1 > then begin > if eof(edfile) > then begin eof1 :=3D true; readlist_nextch :=3D ' '; eoln1 :=3D= false; end > else begin > readln(edfile, filebuf); eoln1 :=3D false; > filebuf :=3D trim(ztrim(filebuf)); > continue; > end > end > else begin > eoln1 :=3D true; readlist_nextch :=3D ' '; > end > end > else begin (* filebuf <> '' *) > readlist_nextch :=3D filebuf[1]; > filebuf :=3D delete(filebuf, 1, 1); > end; > end > else begin > string_pp :=3D string_pp + 1; > if string_pp > length(system_data.p^.command) > then begin > readlist_nextch :=3D ' '; > if eoln1 > then begin > eoln1 :=3D false; eof1:=3D true; > end > else eoln1 :=3D true; > end > else begin > readlist_nextch :=3D system_data.p^.command[string_pp]; > if readlist_nextch =3D chr(10) > then begin > eoln1 :=3D true;readlist_nextch :=3D ' '; > end > else eoln1 :=3D false; > end; > end; > break; >end; { while true } >end; (* proc getchar *) > > procedure skipblanks; > const > blank =3D ' '; > exclam =3D '!'; > begin (* skip blanks and comments in edfile *) > while not eoln1 and_then not eof1 and_then > ((readlist_nextch =3D blank) or_else (readlist_nextch =3D exclam)) do > if readlist_nextch =3D exclam > then repeat getchar(file_io) > until eoln1 > else getchar(file_io); > end; > > procedure lex_string; > var > termch: char; > begin > with nextsym do begin > termch :=3D readlist_nextch; getchar(file_io); > sym :=3D lit_string; str_val :=3D ''; > while not eoln1 and_then (readlist_nextch <> termch) and_then > (length(str_val) < maxstring) do begin > str_val :=3D str_val + readlist_nextch; > getchar(file_io); > end; > if readlist_nextch =3D termch > then getchar(file_io) > else begin status :=3D 818; goto error_exit; (* fast escape *) end; > end > end; (* proc lex_string *) > > procedure lex_id; > const > max_name =3D 31; > var s:string(80); > begin > with nextsym do begin > name :=3D ''; > sym :=3D identifier; > use :=3D normal; > while (readlist_nextch in alphanumund) and_then > (length(name) < max_name) do begin > name :=3D name + readlist_nextch; getchar(file_io); > end; > if (readlist_nextch in ['?', '$', '%', '@']) > then begin > if length(name) < max_name > then begin > case readlist_nextch of > '?': id_type :=3D multi; > '$': id_type :=3D string_p; > '%': id_type :=3D list_p; > '@': id_type :=3D logical; > end; (* esac *) > name :=3D name + readlist_nextch; getchar(file_io); > end > else begin status :=3D 857; goto error_exit; end; > end > else id_type :=3D numeric; (* move from end of routine *) > s :=3D name; > uppercaseproc(s); > if (readlist_nextch in ['a'..'z','A'..'Z','_']) (* too long *) > or_else (s =3D 'NYK') > then begin status :=3D 862; goto error_exit; end; > if (s =3D 'TRUE') or_else (s =3D 'FALSE') or_else (s =3D 'UKE') > or_else (s =3D 'ERROR') > then begin > log :=3D logstate(index('UEFT', substr(s, 1, 1))); > sym :=3D logcon; > end; > end; (* with *) > end; (* proc lex_id *) Another trace, from compiling another file with a different record structure being compared >Starting program: /tmp/gpc1 externfunc.i > >Program received signal SIGSEGV, Segmentation fault. >0x8011c33 in comp_object_pointer_types (lhs=3D0x817ab08, rhs=3D0x817af64) > at gpc-typeck.c:626 >626 for (r =3D rhs; r; r =3D TYPE_LANG_SPECIFIC (r)->elts [1]) >(gdb) where >#0 0x8011c33 in comp_object_pointer_types (lhs=3D0x817ab08, rhs=3D0x817af6= 4) > at gpc-typeck.c:626 >#1 0x8016e76 in convert_for_assignment (type=3D0x8a060b4, rhs=3D0x8a05e54,= =20 > errtype=3D0x0, fundecl=3D0x822cd78, funname=3D0x822caa4, parmnum=3D2) > at gpc-typeck.c:4960 >#2 0x80139ae in convert_arguments (typelist=3D0x822cc80, values=3D0x8a05e4= 0,=20 > name=3D0x822caa4, fundecl=3D0x822cd78) at gpc-typeck.c:2359 >#3 0x8013244 in build_function_call (function=3D0x822cd78,= params=3D0x8a05e40) > at gpc-typeck.c:1896 >#4 0x8007223 in yyparse () at ../gpc-1.2-2.7.2/gpc-parse.y:4364 >#5 0x805ab6e in compile_file (name=3D0xbffffe61 "externfunc.i") > at ./toplev.c:2288 >#6 0x805d25d in main (argc=3D2, argv=3D0xbffffda4, envp=3D0xbffffdb0) > at ./toplev.c:3977 >#7 0x800126b in _start () >(gdb) up 1 >#1 0x8016e76 in convert_for_assignment (type=3D0x8a060b4, rhs=3D0x8a05e54,= =20 > errtype=3D0x0, fundecl=3D0x822cd78, funname=3D0x822caa4, parmnum=3D2) > at gpc-typeck.c:4960 >4960 if (TYPE_MAIN_VARIANT (ttl) =3D=3D void_type_node >(gdb) p *funname >$1 =3D {common =3D {chain =3D 0x818f334, type =3D 0x0, code =3D= IDENTIFIER_NODE,=20 > side_effects_flag =3D 0, constant_flag =3D 0, permanent_flag =3D 1,=20 > addressable_flag =3D 0, volatile_flag =3D 0, readonly_flag =3D 0,=20 > unsigned_flag =3D 0, asm_written_flag =3D 0, used_flag =3D 0,= raises_flag =3D 0,=20 > static_flag =3D 0, public_flag =3D 1, private_flag =3D 0,= protected_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0}, int_cst =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", int_cst_low =3D 13,=20 > int_cst_high =3D 136497872}, real_cst =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D 0xd, real_cst= =3D {r =3D { > 136497872, 136498552, 0}}}, string =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D 0xd,=20 > length =3D 136497872, pointer =3D 0x822cd78 " \"\b\024= \"\b\035\004\t"},=20 > complex =3D {common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D= 0xd,=20 > real =3D 0x822cad0, imag =3D 0x822cd78}, identifier =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", length =3D 13,=20 > pointer =3D 0x822cad0 "Dollarsubproc"}, decl =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b",=20 > filename =3D 0xd
, linenum =3D 136497872,=20 > size =3D 0x822cd78, uid =3D 0, mode =3D VOIDmode, external_flag =3D 0,= =20 > nonlocal_flag =3D 0, regdecl_flag =3D 0, inline_flag =3D 0,= bit_field_flag =3D 0,=20 > virtual_flag =3D 0, ignored_flag =3D 0, abstract_flag =3D 0,=20 > in_system_header_flag =3D 0, common_flag =3D 0, defer_output =3D 0,=20 > transparent_union =3D 0, static_ctor_flag =3D 0, static_dtor_flag =3D= 0,=20 > artificial_flag =3D 0, weak_flag =3D 0, lang_flag_0 =3D 0, lang_flag_1= =3D 0,=20 > lang_flag_2 =3D 0, lang_flag_3 =3D 0, lang_flag_4 =3D 0, lang_flag_5 = =3D 0,=20 > lang_flag_6 =3D 0, lang_flag_7 =3D 0, name =3D 0x0, context =3D 0x0,=20 > arguments =3D 0x0, result =3D 0x6c6c6f44, initial =3D 0x75737261,=20 > abstract_origin =3D 0x6f727062, assembler_name =3D 0x63, section_name = =3D 0x0,=20 > machine_attributes =3D 0x0, rtl =3D 0x403, frame_size =3D {i =3D 0, u = =3D 0,=20 > f =3D NOT_BUILT_IN}, saved_insns =3D {r =3D 0x817bdf4, i =3D= 135773684},=20 > vindex =3D 0x0, lang_specific =3D 0x0}, type =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", values =3D 0xd,=20 > size =3D 0x822cad0, attributes =3D 0x822cd78, uid =3D 0, precision =3D= 0 '\000',=20 > mode =3D VOIDmode, string_flag =3D 0, no_force_blk_flag =3D 0,=20 > needs_constructing_flag =3D 0, transparent_union_flag =3D 0,= packed_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0, align =3D 0,= =20 > pointer_to =3D 0x0, reference_to =3D 0x0, symtab =3D {address =3D= 1819045700,=20 > pointer =3D 0x6c6c6f44 ""}, name =3D 0x75737261, minval =3D= 0x6f727062,=20 > maxval =3D 0x63, next_variant =3D 0x0, main_variant =3D 0x0, binfo =3D= 0x403,=20 > noncopied_parts =3D 0x0, context =3D 0x817bdf4, obstack =3D 0x0,=20 > lang_specific =3D 0x0}, list =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", purpose =3D 0xd,=20 > value =3D 0x822cad0}, vec =3D {common =3D "4= \030\b\000\000\000\000\001\004\b",=20 > length =3D 13, a =3D {0x822cad0}}, exp =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", complexity =3D 13,=20 > operands =3D {0x822cad0}}, block =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", handler_block_flag =3D= 1,=20 > abstract_flag =3D 0, vars =3D 0x822cad0, type_tags =3D 0x822cd78,=20 > subblocks =3D 0x0, supercontext =3D 0x0, abstract_origin =3D 0x0,=20 > end_note =3D 0x0}} >(gdb)=20 >$2 =3D {common =3D {chain =3D 0x818f334, type =3D 0x0, code =3D= IDENTIFIER_NODE,=20 > side_effects_flag =3D 0, constant_flag =3D 0, permanent_flag =3D 1,=20 > addressable_flag =3D 0, volatile_flag =3D 0, readonly_flag =3D 0,=20 > unsigned_flag =3D 0, asm_written_flag =3D 0, used_flag =3D 0,= raises_flag =3D 0,=20 > static_flag =3D 0, public_flag =3D 1, private_flag =3D 0,= protected_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0}, int_cst =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", int_cst_low =3D 13,=20 > int_cst_high =3D 136497872}, real_cst =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D 0xd, real_cst= =3D {r =3D { > 136497872, 136498552, 0}}}, string =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D 0xd,=20 > length =3D 136497872, pointer =3D 0x822cd78 " \"\b\024= \"\b\035\004\t"},=20 > complex =3D {common =3D "4 \030\b\000\000\000\000\001\004\b", rtl =3D= 0xd,=20 > real =3D 0x822cad0, imag =3D 0x822cd78}, identifier =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", length =3D 13,=20 > pointer =3D 0x822cad0 "Dollarsubproc"}, decl =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b",=20 > filename =3D 0xd
, linenum =3D 136497872,=20 > size =3D 0x822cd78, uid =3D 0, mode =3D VOIDmode, external_flag =3D 0,= =20 > nonlocal_flag =3D 0, regdecl_flag =3D 0, inline_flag =3D 0,= bit_field_flag =3D 0,=20 > virtual_flag =3D 0, ignored_flag =3D 0, abstract_flag =3D 0,=20 > in_system_header_flag =3D 0, common_flag =3D 0, defer_output =3D 0,=20 > transparent_union =3D 0, static_ctor_flag =3D 0, static_dtor_flag =3D= 0,=20 > artificial_flag =3D 0, weak_flag =3D 0, lang_flag_0 =3D 0, lang_flag_1= =3D 0,=20 > lang_flag_2 =3D 0, lang_flag_3 =3D 0, lang_flag_4 =3D 0, lang_flag_5 = =3D 0,=20 > lang_flag_6 =3D 0, lang_flag_7 =3D 0, name =3D 0x0, context =3D 0x0,=20 > arguments =3D 0x0, result =3D 0x6c6c6f44, initial =3D 0x75737261,=20 > abstract_origin =3D 0x6f727062, assembler_name =3D 0x63, section_name = =3D 0x0,=20 > machine_attributes =3D 0x0, rtl =3D 0x403, frame_size =3D {i =3D 0, u = =3D 0,=20 > f =3D NOT_BUILT_IN}, saved_insns =3D {r =3D 0x817bdf4, i =3D= 135773684},=20 > vindex =3D 0x0, lang_specific =3D 0x0}, type =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", values =3D 0xd,=20 > size =3D 0x822cad0, attributes =3D 0x822cd78, uid =3D 0, precision =3D= 0 '\000',=20 > mode =3D VOIDmode, string_flag =3D 0, no_force_blk_flag =3D 0,=20 > needs_constructing_flag =3D 0, transparent_union_flag =3D 0,= packed_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0, align =3D 0,= =20 > pointer_to =3D 0x0, reference_to =3D 0x0, symtab =3D {address =3D= 1819045700,=20 > pointer =3D 0x6c6c6f44 ""}, name =3D 0x75737261, minval =3D= 0x6f727062,=20 > maxval =3D 0x63, next_variant =3D 0x0, main_variant =3D 0x0, binfo =3D= 0x403,=20 > noncopied_parts =3D 0x0, context =3D 0x817bdf4, obstack =3D 0x0,=20 > lang_specific =3D 0x0}, list =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", purpose =3D 0xd,=20 > value =3D 0x822cad0}, vec =3D {common =3D "4= \030\b\000\000\000\000\001\004\b",=20 > length =3D 13, a =3D {0x822cad0}}, exp =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", complexity =3D 13,=20 > operands =3D {0x822cad0}}, block =3D { > common =3D "4 \030\b\000\000\000\000\001\004\b", handler_block_flag =3D= 1,=20 > abstract_flag =3D 0, vars =3D 0x822cad0, type_tags =3D 0x822cd78,=20 > subblocks =3D 0x0, supercontext =3D 0x0, abstract_origin =3D 0x0,=20 > end_note =3D 0x0}} >(gdb) p *fundecl >$3 =3D {common =3D {chain =3D 0x822c9f0, type =3D 0x822cd14, code =3D= FUNCTION_DECL,=20 > side_effects_flag =3D 0, constant_flag =3D 0, permanent_flag =3D 1,=20 > addressable_flag =3D 0, volatile_flag =3D 0, readonly_flag =3D 0,=20 > unsigned_flag =3D 0, asm_written_flag =3D 0, used_flag =3D 1,= raises_flag =3D 0,=20 > static_flag =3D 0, public_flag =3D 1, private_flag =3D 0,= protected_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0}, int_cst =3D { > common =3D " \"\b\024 \"\b\035\004\t", int_cst_low =3D 135759440,=20 > int_cst_high =3D 8539}, real_cst =3D {common =3D " \"\b\024= \"\b\035\004\t",=20 > rtl =3D 0x8178650, real_cst =3D {r =3D {8539, 0, 2549}}}, string =3D { > common =3D " \"\b\024 \"\b\035\004\t", rtl =3D 0x8178650, length =3D= 8539,=20 > pointer =3D 0x0}, complex =3D {common =3D " \"\b\024 \"\b\035\004\t",= =20 > rtl =3D 0x8178650, real =3D 0x215b, imag =3D 0x0}, identifier =3D { > common =3D " \"\b\024 \"\b\035\004\t", length =3D 135759440,=20 > pointer =3D 0x215b
}, decl =3D { > common =3D " \"\b\024 \"\b\035\004\t",=20 > filename =3D 0x8178650 "externfunc.pas", linenum =3D 8539, size =3D= 0x0,=20 > uid =3D 2549, mode =3D QImode, external_flag =3D 1, nonlocal_flag =3D= 0,=20 > regdecl_flag =3D 0, inline_flag =3D 0, bit_field_flag =3D 0,= virtual_flag =3D 0,=20 > ignored_flag =3D 0, abstract_flag =3D 0, in_system_header_flag =3D 0,= =20 > common_flag =3D 1, defer_output =3D 0, transparent_union =3D 0,=20 > static_ctor_flag =3D 0, static_dtor_flag =3D 0, artificial_flag =3D 0,= =20 > weak_flag =3D 0, lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D= 0,=20 > lang_flag_3 =3D 0, lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 = =3D 0,=20 > lang_flag_7 =3D 0, name =3D 0x822caa4, context =3D 0x0, arguments =3D= 0x0,=20 > result =3D 0x0, initial =3D 0x0, abstract_origin =3D 0x0,=20 > assembler_name =3D 0x822cde0, section_name =3D 0x0, machine_attributes= =3D 0x0,=20 > rtl =3D 0x822ce24, frame_size =3D {i =3D 0, u =3D 0, f =3D= NOT_BUILT_IN},=20 > saved_insns =3D {r =3D 0x0, i =3D 0}, vindex =3D 0x0, lang_specific =3D= 0x89fda98},=20 > type =3D {common =3D " \"\b\024 \"\b\035\004\t", values =3D 0x8178650,= =20 > size =3D 0x215b, attributes =3D 0x0, uid =3D 2549, precision =3D 1= '\001',=20 > mode =3D QImode, string_flag =3D 0, no_force_blk_flag =3D 1,=20 > needs_constructing_flag =3D 0, transparent_union_flag =3D 0,= packed_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0, align =3D= 136497828,=20 > pointer_to =3D 0x0, reference_to =3D 0x0, symtab =3D {address =3D 0,=20 > pointer =3D 0x0}, name =3D 0x0, minval =3D 0x0, maxval =3D 0x822cde0,= =20 > next_variant =3D 0x0, main_variant =3D 0x0, binfo =3D 0x822ce24,=20 > noncopied_parts =3D 0x0, context =3D 0x0, obstack =3D 0x0,=20 > lang_specific =3D 0x89fda98}, list =3D {common =3D " \"\b\024= \"\b\035\004\t",=20 > purpose =3D 0x8178650, value =3D 0x215b}, vec =3D { > common =3D " \"\b\024 \"\b\035\004\t", length =3D 135759440, a =3D= {0x215b}},=20 > exp =3D {common =3D " \"\b\024 \"\b\035\004\t", complexity =3D= 135759440,=20 > operands =3D {0x215b}}, block =3D {common =3D " \"\b\024= \"\b\035\004\t",=20 > handler_block_flag =3D 0, abstract_flag =3D 0, vars =3D 0x215b,= type_tags =3D 0x0,=20 > subblocks =3D 0x9f5, supercontext =3D 0x20101, abstract_origin =3D= 0x822caa4,=20 > end_note =3D 0x0}} >(gdb) p *rhs >$4 =3D {common =3D {chain =3D 0x0, type =3D 0x825b390, code =3D= CONVERT_EXPR,=20 > side_effects_flag =3D 0, constant_flag =3D 0, permanent_flag =3D 1,=20 > addressable_flag =3D 0, volatile_flag =3D 0, readonly_flag =3D 0,=20 > unsigned_flag =3D 0, asm_written_flag =3D 0, used_flag =3D 0,= raises_flag =3D 0,=20 > static_flag =3D 0, public_flag =3D 0, private_flag =3D 0,= protected_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0}, int_cst =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", int_cst_low =3D 0,=20 > int_cst_high =3D 136644252}, real_cst =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", rtl =3D 0x0, real_cst = =3D {r =3D { > 136644252, 0, 135769552}}}, string =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", rtl =3D 0x0,=20 > length =3D 136644252, pointer =3D 0x0}, complex =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", rtl =3D 0x0, real =3D= 0x825069c,=20 > imag =3D 0x0}, identifier =3D {common =3D "\000\000\000\000\220= %\bi\004\000",=20 > length =3D 0, pointer =3D 0x825069c "=E1\a%\b \005%\b\"L\001"}, decl = =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", filename =3D 0x0,=20 > linenum =3D 136644252, size =3D 0x0, uid =3D 135769552, mode =3D 39,=20 > external_flag =3D 0, nonlocal_flag =3D 0, regdecl_flag =3D 1,= inline_flag =3D 0,=20 > bit_field_flag =3D 0, virtual_flag =3D 0, ignored_flag =3D 0,= abstract_flag =3D 0,=20 > in_system_header_flag =3D 0, common_flag =3D 0, defer_output =3D 0,=20 > transparent_union =3D 0, static_ctor_flag =3D 0, static_dtor_flag =3D= 0,=20 > artificial_flag =3D 0, weak_flag =3D 0, lang_flag_0 =3D 0, lang_flag_1= =3D 0,=20 > lang_flag_2 =3D 0, lang_flag_3 =3D 0, lang_flag_4 =3D 0, lang_flag_5 = =3D 0,=20 > lang_flag_6 =3D 0, lang_flag_7 =3D 0, name =3D 0x0, context =3D= 0x8a05e54,=20 > arguments =3D 0x0, result =3D 0x0, initial =3D 0x403, abstract_origin = =3D 0x0,=20 > assembler_name =3D 0x8a05e68, section_name =3D 0x0,=20 > machine_attributes =3D 0x822cd14, rtl =3D 0x440d, frame_size =3D {i =3D= 0, u =3D 0,=20 > f =3D NOT_BUILT_IN}, saved_insns =3D {r =3D 0x815aa68, i =3D= 135637608},=20 > vindex =3D 0x0, lang_specific =3D 0x906}, type =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", values =3D 0x0,=20 > size =3D 0x825069c, attributes =3D 0x0, uid =3D 135769552, precision = =3D 39 '\'',=20 > mode =3D SImode, string_flag =3D 0, no_force_blk_flag =3D 0,=20 > needs_constructing_flag =3D 0, transparent_union_flag =3D 0,= packed_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0, align =3D 0,= =20 > pointer_to =3D 0x8a05e54, reference_to =3D 0x0, symtab =3D {address =3D= 0,=20 > pointer =3D 0x0}, name =3D 0x403, minval =3D 0x0, maxval =3D= 0x8a05e68,=20 > next_variant =3D 0x0, main_variant =3D 0x822cd14, binfo =3D 0x440d,=20 > noncopied_parts =3D 0x0, context =3D 0x815aa68, obstack =3D 0x0,=20 > lang_specific =3D 0x906}, list =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", purpose =3D 0x0,=20 > value =3D 0x825069c}, vec =3D {common =3D "\000\000\000\000\220= %\bi\004\000",=20 > length =3D 0, a =3D {0x825069c}}, exp =3D { > common =3D "\000\000\000\000\220 %\bi\004\000", complexity =3D 0,= operands =3D { > 0x825069c}}, block =3D {common =3D "\000\000\000\000\220= %\bi\004\000",=20 > handler_block_flag =3D 0, abstract_flag =3D 0, vars =3D 0x825069c,=20 > type_tags =3D 0x0, subblocks =3D 0x817add0, supercontext =3D 0x427,=20 > abstract_origin =3D 0x0, end_note =3D 0x8a05e54}} >(gdb) p *lhs >(gdb)=20 >(gdb) p *type >$5 =3D {common =3D {chain =3D 0x0, type =3D 0x817ab08, code =3D= POINTER_TYPE,=20 > side_effects_flag =3D 0, constant_flag =3D 0, permanent_flag =3D 1,=20 > addressable_flag =3D 0, volatile_flag =3D 0, readonly_flag =3D 0,=20 > unsigned_flag =3D 1, asm_written_flag =3D 0, used_flag =3D 0,= raises_flag =3D 0,=20 > static_flag =3D 0, public_flag =3D 0, private_flag =3D 0,= protected_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0}, int_cst =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", int_cst_low =3D 0,=20 > int_cst_high =3D 135637608}, real_cst =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", rtl =3D 0x0, real_cst= =3D {r =3D { > 135637608, 0, 2311}}}, string =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", rtl =3D 0x0,=20 > length =3D 135637608, pointer =3D 0x0}, complex =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", rtl =3D 0x0, real =3D= 0x815aa68,=20 > imag =3D 0x0}, identifier =3D {common =3D= "\000\000\000\000\b=BD\027\b\rD\000",=20 > length =3D 0, pointer =3D 0x815aa68 ""}, decl =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", filename =3D 0x0,=20 > linenum =3D 135637608, size =3D 0x0, uid =3D 2311, mode =3D 32,= external_flag =3D 0,=20 > nonlocal_flag =3D 0, regdecl_flag =3D 1, inline_flag =3D 0,= bit_field_flag =3D 0,=20 > virtual_flag =3D 0, ignored_flag =3D 0, abstract_flag =3D 0,=20 > in_system_header_flag =3D 0, common_flag =3D 0, defer_output =3D 0,=20 > transparent_union =3D 0, static_ctor_flag =3D 0, static_dtor_flag =3D= 0,=20 > artificial_flag =3D 0, weak_flag =3D 0, lang_flag_0 =3D 0, lang_flag_1= =3D 0,=20 > lang_flag_2 =3D 0, lang_flag_3 =3D 0, lang_flag_4 =3D 0, lang_flag_5 = =3D 0,=20 > lang_flag_6 =3D 0, lang_flag_7 =3D 0, name =3D 0x20, context =3D 0x0,= =20 > arguments =3D 0x0, result =3D 0x0, initial =3D 0x0, abstract_origin =3D= 0x0,=20 > assembler_name =3D 0x0, section_name =3D 0x0, machine_attributes =3D= 0x8a060b4,=20 > rtl =3D 0x0, frame_size =3D {i =3D 0, u =3D 0, f =3D NOT_BUILT_IN},= saved_insns =3D { > r =3D 0x0, i =3D 0}, vindex =3D 0x8151654, lang_specific =3D 0x0},= type =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", values =3D 0x0,=20 > size =3D 0x815aa68, attributes =3D 0x0, uid =3D 2311, precision =3D 32= ' ',=20 > mode =3D SImode, string_flag =3D 0, no_force_blk_flag =3D 0,=20 > needs_constructing_flag =3D 0, transparent_union_flag =3D 0,= packed_flag =3D 0,=20 > lang_flag_0 =3D 0, lang_flag_1 =3D 0, lang_flag_2 =3D 0, lang_flag_3 = =3D 0,=20 > lang_flag_4 =3D 0, lang_flag_5 =3D 0, lang_flag_6 =3D 0, align =3D 32,= =20 > pointer_to =3D 0x0, reference_to =3D 0x0, symtab =3D {address =3D 0,=20 > pointer =3D 0x0}, name =3D 0x0, minval =3D 0x0, maxval =3D 0x0,=20 > next_variant =3D 0x0, main_variant =3D 0x8a060b4, binfo =3D 0x0,=20 > noncopied_parts =3D 0x0, context =3D 0x0, obstack =3D 0x8151654,=20 > lang_specific =3D 0x0}, list =3D {common =3D= "\000\000\000\000\b=BD\027\b\rD\000",=20 > purpose =3D 0x0, value =3D 0x815aa68}, vec =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", length =3D 0, a =3D= {0x815aa68}},=20 > exp =3D {common =3D "\000\000\000\000\b=BD\027\b\rD\000", complexity =3D= 0,=20 > operands =3D {0x815aa68}}, block =3D { > common =3D "\000\000\000\000\b=BD\027\b\rD\000", handler_block_flag =3D= 0,=20 > abstract_flag =3D 0, vars =3D 0x815aa68, type_tags =3D 0x0, subblocks = =3D 0x907,=20 > supercontext =3D 0x420, abstract_origin =3D 0x20, end_note =3D 0x0}} Please let me know what you would like to see in terms of output. Regards Jim From gpc-request@santra.hut.fi Wed Oct 23 01:58:13 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA26106 for ; Wed, 23 Oct 1996 01:58:12 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81158; Wed, 23 Oct 1996 02:07:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54726; Wed, 23 Oct 1996 02:06:10 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id CAA02272 for ; Wed, 23 Oct 1996 02:58:14 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA26023 for gpc@hut.fi; Wed, 23 Oct 1996 01:49:57 +0100 From: Peter Gerwinski Message-Id: <199610230049.BAA26023@agnes.dida.physik.uni-essen.de> Subject: GPC WWW home page modified To: gpc@hut.fi Date: Wed, 23 Oct 1996 01:49:57 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, friends of GNU Pascal, I did some modifications to the GNU Pascal home page, http://home.pages.de/~GNU-Pascal/ or http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ Please post your comments here; especially let me know if I missed to mention you and/or your work in the "development team" page. Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Wed Oct 23 21:33:46 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA27669 for ; Wed, 23 Oct 1996 21:33:45 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74422; Wed, 23 Oct 1996 21:42:21 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58368; Wed, 23 Oct 1996 21:41:25 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA32543 for ; Wed, 23 Oct 1996 22:28:58 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA27572 for gpc@hut.fi; Wed, 23 Oct 1996 21:20:59 +0100 From: Peter Gerwinski Message-Id: <199610232020.VAA27572@agnes.dida.physik.uni-essen.de> Subject: getenv - any solutions? To: gpc@hut.fi Date: Wed, 23 Oct 1996 21:20:59 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to John Michael Black: > There's been a lot of getenvs going around here lately. :) Has anyone > found a method that works yet? The last thing posted about it gave this: > > Function GetEnv ( Name: __CString__ ): PChar; C; > > GPC does not recognize PChar -- at least ours doesn't. You must *define* PChar first: Type PChar = ^Char; Perhaps you should try that Borland compatible GetEnv Function in the Tools Unit of BO5. See ftp://kampi.hut.fi/jtv/gnu-pascal/turbo-alpha/bo5.zip Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Wed Oct 23 21:32:52 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA27665 for ; Wed, 23 Oct 1996 21:32:52 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59300; Wed, 23 Oct 1996 21:41:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68836; Wed, 23 Oct 1996 21:40:32 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA32484 for ; Wed, 23 Oct 1996 22:28:44 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA27564 for gpc@hut.fi; Wed, 23 Oct 1996 21:20:44 +0100 From: Peter Gerwinski Message-Id: <199610232020.VAA27564@agnes.dida.physik.uni-essen.de> Subject: Re: 2.7.2 compiler To: gpc@hut.fi Date: Wed, 23 Oct 1996 21:20:44 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jim Brander: > gpc-typeck.c:626 > >626 for (r =3D rhs; r; r =3D TYPE_LANG_SPECIFIC (r)->elts [1]) > >(gdb) l > >621 tree lhs, rhs; > >622 { > >623 register tree r; > >624 if (TREE_CODE (lhs) =3D=3D RECORD_TYPE > >625 && TREE_CODE (rhs) =3D=3D RECORD_TYPE) > >626 for (r =3D rhs; r; r =3D TYPE_LANG_SPECIFIC (r)->elts [1]) > >627 { > >628 if (comptypes (lhs, r)) > >629 return 1; > >630 } Please try the following patch: replace if (TREE_CODE (lhs) == RECORD_TYPE && TREE_CODE (rhs) == RECORD_TYPE) by if (IS_OBJECT_TYPE (lhs) && IS_OBJECT_TYPE (rhs)) and let us know the result. You discovered a severe bug. Thanks. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Thu Oct 24 08:36:35 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA28149 for ; Thu, 24 Oct 1996 08:36:35 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68178; Thu, 24 Oct 1996 08:45:00 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59676; Thu, 24 Oct 1996 08:44:04 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA03080; Thu, 24 Oct 96 08:44:34 +0200 Received: from mailhost.pi.net (root@mailhost.pi.net [145.220.3.9]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id JAA06859 for ; Thu, 24 Oct 1996 09:26:34 +0300 (EET DST) Received: from default (hedr34.pi.net [145.220.220.34]) by mailhost.pi.net (8.7.5/8.7.1) with ESMTP id IAA03539 for ; Thu, 24 Oct 1996 08:26:30 +0200 (MET DST) Posted-Date: Thu, 24 Oct 1996 08:26:30 +0200 (MET DST) Message-Id: <199610240626.IAA03539@mailhost.pi.net> From: "Niels Heirbaut" To: "GPC Mailing List" Subject: No more trouble with GPC (and a solution) Date: Thu, 24 Oct 1996 08:25:26 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Hi, Hereby I would like to thank everybody who helped me getting GPC-2.7.2 started. Their hints and tips really helped me getting started. The biggest problems occured because there were no installation instructions in the binary *.ZIP file for DJGPP. People who answered my request for help pointed out to me that I had to add a few lines to DJGPP.ENV, but there was no clue about this in the files I got. It was also not until I got the source files that I found out there had to be a SPECS.GPC in my library-directory. This file was also not included in the binary distribution. So if someone would add the (revised?) installation instruction and the SPECS.GPC file to the binary *.ZIP file, or if someone could tell me how (I'm also a newbie at uploading to FTP-sites :-)) and where to upload the revised gpc272b.zip file, the problems I had will be forever in the past. Regards --- When I am grown to man's estate I shall be very proud and great. And tell the other girls and boys Not to meddle with my toys. --- Stevenson --- Niels Heirbaut ----> heirbaut@pi.net From gpc-request@santra.hut.fi Thu Oct 24 16:48:11 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA28578 for ; Thu, 24 Oct 1996 16:48:11 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75282; Thu, 24 Oct 1996 16:56:29 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70846; Thu, 24 Oct 1996 16:55:33 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA26289 for ; Thu, 24 Oct 1996 17:47:24 +0300 (EET DST) Received: from [130.89.179.47] (pc047.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA25216 (5.67b/IDA-1.5 for ); Thu, 24 Oct 1996 16:47:22 +0200 Date: Thu, 24 Oct 96 16:53:16 CST From: "J.J. van der Heijden" Message-Id: <72041.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: No more trouble with GPC (and a solution) Status: RO On Thu, 24 Oct 1996 08:25:26 +0100, Niels Heirbaut wrote: >Hi, > >Hereby I would like to thank everybody who helped me getting GPC-2.7.2 >started. Their hints and tips really helped me getting started. > [...] >So if someone would add the (revised?) installation instruction and the >SPECS.GPC file to the binary *.ZIP file, or if someone could tell me how >(I'm also a newbie at uploading to FTP-sites :-)) and where to upload the >revised gpc272b.zip file, the problems I had will be forever in the past. > All my fault :-( I'll try to be more carefull in the future. There's a "prerelease" and several snapshots floating around, so I'll try to clean up the mess a bit. Greetings, JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Thu Oct 24 16:36:37 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA28571 for ; Thu, 24 Oct 1996 16:36:37 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76232; Thu, 24 Oct 1996 16:44:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82502; Thu, 24 Oct 1996 16:43:55 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id RAA25970 for ; Thu, 24 Oct 1996 17:27:32 +0300 (EET DST) Received: from [130.89.179.47] (pc047.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA22184 (5.67b/IDA-1.5 for ); Thu, 24 Oct 1996 16:27:27 +0200 Date: Thu, 24 Oct 96 16:33:53 CST From: "J.J. van der Heijden" Message-Id: <70955.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: !Sorry -- retry : Faq v0.2 Status: RO Hello folks, Seems this crappy M$dos email proggy is not capable of attaching unix text :-( Let me try again: This is Info file FAQ, produced by Makeinfo-1.64 from the input file faq.texi. Revision 0.2 of 24 October 1996 Author: J.J. van der Heijden What is GNU Pascal? ******************* The purpose of the GNU Pascal project is to produce a Pascal compiler (called GNU Pascal or GPC) which * combines the clarity of Pascal with powerful tools suitable for real-life programming, * supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE. (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989) * supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, * may be distributed under GNU license conditions * can generate code and run on any computer for which the GNU C compiler can generate code and run. Pascal was originally designed for teaching. GNU Pascal provides a smooth way to proceed to challenging programming tasks without learning a completely different language. What is the current version of GNU Pascal? ========================================== The last official release is GPC 1.1, based on GCC version 2.6.3. GPC version 1.2, based on GCC 2.7.2 is currently in beta testing. Where is the GNU Pascal FTP site? WWW? ====================================== The master FTP site for GNU Pascal is kampi.hu.fi GNU Pascal related files can be found in: ftp://ftp.kampi.hut.fi/jtv/gnu-pascal/ This site is mirrored on: ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ The latest developer releases can be downloaded from: ftp://agnes.dida.physik.uni-essen.de/ Also, we have a homepage on the web: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ Is it compatible with Turbo Pascal (R) ? ======================================== GPC is currently *not* a drop-in replacement for Borland's Turbo Pascal (R). It supports a number, but not all of the Borland extensions to the Pascal language. There is no replacement for most of the Borland runtime library functions. GNU Pascal is part of the GNU project, so portability is one of its primary goals. For this reason, non-portable features of Borland Pascal will probably not be included into GNU Pascal. More information can be found in the section "Borland Pascal" of the GPC manual. Installation related questions ****************************** This section discusses some common problems with the installation of GNU Pascal. Which platforms are supported by GNU Pascal? ============================================ GPC uses the GCC backend, so it should run on any system that is supported by GNU CC. This includes a large variety of Unix systems, MS-DOS, OS/2 and Win32. A full list of platforms supported by GCC can be found in the file "INSTALL" of the GCC distribution. Not all of these have actually been tested, but the gpc-1.2 pre-release is know to run on these platforms: i486-linux (Linux 2.x, ELF) i486-linuxaout i486-linuxoldld i486-freebsd2.1 i386-cygwin32 (Windows95/Windows NT) i386-djgppv2 (MS-DOS) i386-emx (OS/2, MS-DOS) mips-sgi-irix5.3 >>> Ok people - send us your success stories, with canonical machine name! <<< Which components do I need to compile Pascal source code? ========================================================= A complete Pascal compiler system should at least have: * The actual compiler, GPC. * Assembler, linker, librarian and friends. * A C library. * A debugger, if you want to debug your programs. You don't need a C compiler to compile your Pascal programs, but you do need it to build the GNU Pascal compiler itself. GNU Pascal version 1.1 is based on GCC 2.6.3, GPC v1.2 is based on GCC v2.7.2 Any attempt to build GPC with the wrong version of GCC is bound to fail. For most people, the GNU binutils and GNU debugger (gdb) are a good choice, although some may prefer to use vendor specific tools. Help! linking gpc1 fails: _emit_string_move undefined (and more) ================================================================ If linking `gpc1' bombs out with an error message that looks like this: ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' you probably suffer from a VPATH make problem. A few GPC source files have counterparts with identical name in the GCC source directory. When you have built GCC in the GCC source directory and you are not using a recent version of GNU make this problem may occur. There are three solutions: * Get a recent version of GNU make. Version 3.74 or better is known to work. * Build GCC in a seperate directory instead of using the GCC source directory. * Manually delete these files from the GCC object directory: `stor-layout.o dbxout.o expr.o fold-const.o optabs.o convert.o' `function.o setop.o toplev.o' then resume `make'. When I build libgpc.a, rts-rt0.c says: SIGXCPU undefined (and more) =================================================================== Compilation of the runtime system may fail in rts-rt0.c with a message simular to this: rts-rt0.c: `SIGXCPU' undeclared (first use this function) or: rts-rt0.c: storage size of `sv' isn't known rts-rt0.c: storage size of `osv' isn't known If this happens to you, you have to edit the rts/rts-config.h file and comment out the last line to: /* #undef HAVE_SIGSYS */ This will be fixed in a future release. I'm using unix, and all my Pascal programs have linking problems. ================================================================= A number of unix configurations use their system's linker instead of GNU ld. Usually, GPC and GCC need a program called `collect2' before calling the system's `ld'. `collect2' is installed by GCC, and if you only install GPC, it will not find collect2, and use the system linker directly, which will result in various linker errors. The solution is to copy `collect2' by hand from the GCC directory to the location where `gpc1' lives. I do I debug my Pascal programs? ================================ To debug your programs, (a) GNU Pascal must be able to generate executables with debug info for your platform, and (b) you must have a debugger which understands this. * If `gpc -g -o hello hello.p' says: "gpc: -g not supported for this platform", then GPC is unable to generate debug info. Usually, installing GAS instead of your system's assembler can overcome this. When you configure the GCC used for GPC, specify "-with-gnu-as", and possibly "-with-gnu-ld" and/or "-with-stabs". More information can be found in "INSTALL" file in the GNU CC source directory. * Your system's debugger may not understand the debug info generated by GNU tools. In this case, installing GDB may help. The bottom line: if you can debug GCC compiled programs, you should be able to do this with GPC too. The GNU debugger (GDB) currently does not have a "Pascal" mode, so it is unable to display certain Pascal structures etc. When debugging, please note that the Initial Letter In Each Identifier Is In Upper Case And The Rest Are In Lower Case. If you want to display variable 'foo' in the debugger, type `show Foo' or `display Foo' instead. Can you recommend an IDE? ========================= Users of Borland Pascal may wonder if there's a replacement for the IDE (Integrated Development Environment). Here's a few suggestions: * *(X)Emacs*. Some people think it's the answer to the question of Life, the Universe and Everything, others decide it's uGNUsable. Available from your friendly GNU mirror. * *XWPE* is an immitation of the Borland IDE, so users of Borland Pascal may find it a good alternative. Although GDB is an excellent debugger, it's user interface is not very attractive. Refer to the comp.windows.x FAQ: "Where can I get an X-based debugger?" at: http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/part6/faq-doc-2.html Some useful frontends include: XXGDB, tGDB and XWPE. see: http://www.ee.ryerson.ca:8080/~elf/xapps/Q-IV.html Very nice, but resource consuming is the Motif based DDD: http://sol.ibr.cs.tu-bs.de/softech/ddd/ Do we have a binary for you? ============================ Currently, we have binaries for these platforms: i486-linux (ELF) i486-linuxaout i486-linuxoldld djgpp V2 (msdos) emx 0.9B (OS/2, msdos) cygwin32 beta16 (Windows95, Windows NT) mips-sgi-irix5.3 New binaries may have been added after the release of this FAQ. GNU Pascal and your system libraries ************************************ This section discusses common problems people have when they try to access their system's libraries. How do I use from the C library? ============================================================ GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. man(3) sleep reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; var result : word; begin result := sleep(10); end. --------------------------------------------------------- What's this confusion about Pascal and C style strings? ======================================================= It is important not to confuse Pascal and C string types. * The Pascal string schema, as defined in section 6.4.3.3.3 of the ISO-10206:1990 Extended Pascal standard, is a record: type string = record Capacity : integer; length : integer; string : packed array [ 1..Capacity ] of char; end; 'string' is not 'string(256)', unlike Turbo Pascal. The capacicty must be declared: type MyString = string(256); before it can be used, i.e.: function MyFunction: MyString; * A C string ( "char *" ) is an array of char, terminated with a NULL char. C library functions require C, not Pascal style string arguments! Consider this code snippet to convert Pascal style strings to C style and vice versa: --------------------------------------------------------- type word = __unsigned__ integer; TString = string(256); { Pascal string schema } CString = __cstring__; { C style string } { Convert a "C" string to a "Pascal" string } function StrPas(Src: CString): TString; var S : TString; begin S := ''; if (Src <> NIL) then while ( (Src^ <> chr(0)) AND (length(S) < S.capacity)) do begin S := S + Src^; inc(Word(Src)); end; StrPas := S; end; { Convert a "Pascal" string to a "C" string } function StrPCopy(Dest: CString; Src: String): CString; var c: integer; p : CString; begin p := Dest; for c:=1 to length(Src) do begin p^ := Src[c]; inc(word(p)); end; p^ := chr(0); StrPCopy := Dest; end; --------------------------------------------------------- Then this small example will print the PATH: --------------------------------------------------------- Program EnvDemo; { include the above StrPas() and StrPCopy() snippet here } { C library function prototype: char *getenv(const char *name); } function GetEnv(name : CString): CString; C; var pName: CString; begin getmem(pName, 256); pName := StrPCopy(pName, 'PATH'); writeln('Your PATH is: ', StrPas(GetEnv(pName))); freemem(pName, 256); end. --------------------------------------------------------- And this is how you access the 'system()' call in you C library: --------------------------------------------------------- program SysCall; { include the above StrPas() and StrPCopy() snippet here } function system(name : CString): integer; C; var pName: CString; result : integer; begin getmem(pName, 256); pName := StrPCopy(pName, 'ls -l'); result := system(pName); writeln('system() call returned : ', result); freemem(pName, 256); end. --------------------------------------------------------- There may be other ways to do the same thing; you could declare a type PChar instead of CString: type PChar = ^char; and replace all references to `CString' with `PChar'. Do NOT pass a "C" style string as a var-argument if the C prototype says "const char *" or you will get a coredump. You are right if you think this stuff belongs in a library, to be distributed with GPC. Have patience, or start coding! Are GNU Pascal objects compatible with GNU C++ classes ? ======================================================== No. (This may change in a future version) Where are the Turbo Pascal (R) replacement units? ================================================= They don't exist (yet). Most of their fuctionality can easily be implemented, some things are very x86/msdos dependant and would be meaningless on any other platform. How do I build/use a shared library? ==================================== (topic under construction) GNU Pascal on the djgpp (MS-DOS) platform ***************************************** This chapter discusses some potential problems with GNU Pascal on MS-DOS, using djgpp. If you need more information ============================ GPC/djgpp is a djgpp V2 application, and most of the djgpp documentation applies for GPC too. A great source of information is the djgpp FAQ: http://www.delorie.com/djgpp/v2faq/faq202b.zip Another place to look for DJGPP documentation is the DJGPP Knowledge Base, at this URL: http://www.delorie.com/djgpp/doc/kb/ 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/djdev200.zip (C library) v2gnu/bnu252b.zip (assembler, ....) v2gnu/gdb412b.zip (debugger) The rest is up to you; 'make' (v2gnu/mak372b.zip) can be useful, RHIDE (an IDE with Borland-look) is nice, but still under development. Future releases of RHIDE may have better GPC support. How do I install the compiler? ============================== If you don't have djgpp installed on your harddisk, create a directory for GNU pascal ("c:\gpc"), and unzip the archives. Make sure you preserve the directory structure (use "pkunzip -d"). Now, add the directory where gpc.exe lives ("c:\gpc\bin") to your path and set the DJGPP environment variable to point to your djgpp.env file: set DJGPP=c:\gpc\djgpp.env Then, add this to your djgpp.env file: --------------------------------------------------------- [gpc-cpp] C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/lang/pascal;%DJDIR%/include;%DJDIR%/contrib/grx20/include [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/lib --------------------------------------------------------- The binary distribution should come with a `djgpp.env' which is already modified, so you may not have to do this. Specific information for low-memory conditions and more can be found in the djgpp FAQ and documentation. GPC says: no DPMI ================= You don't have a DPMI server installed, and DJGPP v2 requires it to run. You can either use one of the commercial DPMI servers (e.g., run `gpc' in a DOS box under Windows) or download and install CWSDPMI (`csdpmi3b.zip') which is a free DPMI server written for DJGPP. I cannot read the info pages! ============================= To read the info pages, you need the `info' program from txi360b.zip. At least for some of the pre-releases of gpc-1.2, the gpc.info file is invalid: it refers to the "gpc.i*" sections as "gpc.info-*". This can be fixed by loading gpc.inf in an editor and replacing "gpc.info-*" with "gpc.i*" I have troubles with assembly code ================================== The GNU Assembler (`as.exe'), or `gas', called by GCC accepts "AT&T" syntax which is different from "Intel" syntax. Differences are discussed in section 17.1 of the djgpp FAQ. A guide is available which was written by Brennan Mr. Wacko Underwood and describes how to use inline assembly programming with DJGPP, at this URL: http://www.rt66.com/~brennan/djgpp/djgpp_asm.html Section 17.3 of the djgpp FAQ discusses some methods to convert "Intel" syntax to "AT&T". Tell me how to do DPMI, BIOS and other DOS related things. ========================================================== DPMI, BIOS and other functions are no different than other system functions. Refer to section 3.1 how to access your system's C-library. This small example shows how to use DPMI, copying some structures and function prototypes of : --------------------------------------------------------- program dpmitest; {$X+} type word = __unsigned__ integer; short = __short__ integer; byte = __byte__ integer; type PDpmiVersionRet = ^TDpmiVersionRet; TDpmiVersionRet = record major : byte; minor : byte; flags : short; cpu : byte; master_pic : byte; slave_pic : byte; end; type PDpmiFreeMemInfo = ^TDpmiFreeMemInfo; TDpmiFreeMemInfo = record largest_available_free_block_in_bytes : word; maximum_unlocked_page_allocation_in_pages : word; maximum_locked_page_allocation_in_pages : word; linear_address_space_size_in_pages : word; total_number_of_unlocked_pages : word; total_number_of_free_pages : word; total_number_of_physical_pages : word; free_linear_address_space_in_pages : word; size_of_paging_file_partition_in_pages : word; reserved1 : byte; reserved2 : byte; reserved3 : byte; end; function DpmiGetVersion(ret: PDpmiVersionRet): integer; asmname '__dpmi_get_version'; function DpmiGetFreeMemoryInformation(info: PDpmiFreeMemInfo): integer; asmname '__dpmi_get_free_memory_information'; var version: TDpmiVersionRet; meminfo: TDpmiFreeMemInfo; begin DpmiGetVersion(@version); writeln('CPU type : ', version.cpu, '86'); writeln('DPMI major : ', version.major); writeln('DPMI minor : ', version.minor); DpmiGetFreeMemoryInformation(@meminfo); writeln('Free DPMI memory : ', meminfo.total_number_of_free_pages, ' pages.'); end. --------------------------------------------------------- I'm accessing an "array[1..4000000] of byte" and I got an exception. ==================================================================== Per default, the maximum stack size of a djgpp application is 256K. If you need more, you have to adjust it with the stubedit program, i.e.: stubedit your_app.exe minstack=5000K Still, it might be a good idea to use pointers for this kind of structures, and allocate the memory at runtime. Getting Help ************ This section discusses ways to get help with GNU Pascal. Please read the documentation (info files, readme's) that come with GPC, plus other docs that might help (the djgpp FAQ if you use djgpp etc.) before you send email to the maintainers or mailing list. Help! the compiler crashed! =========================== If the compiler crashes, you have discovered a bug. A reliable compiler never crashes. To help the maintainers fix this bug, it is important that you send us a problem report. I think I found a bug - now what? ================================= Bugs are best reported to the GPC mailinglist, gpc@hut.fi. That way, they always reach the maintainers. Try to give as much information as possible, plus a short code snippet that triggers the compiler bug. If you're on unix, you can find out where the compiler crashed if you enable coredumps, then load the compiler (gpc1) plus the core file in the debugger ("gdb /your_path_here/gpc1 core"), then type `backtrace' to get a stacktrace. Include this stacktrace in your bug report. Which newsgroup(s) are suited for GPC related problems? ======================================================= There are several Pascal related newsgroups, but none is dedicated just to GNU Pascal. This one may be useful: comp.lang.pascal.misc Pascal in general and ungrouped Pascals. Pascal syntax related questions may be appropriate in: comp.lang.pascal.ansi-iso Pascal according to ANSI and ISO standards. comp.lang.pascal.borland Borland Pascal questions. How to post to the mailing list =============================== You can send a message to the GPC mailing list by sending email to the list address as if it were a person. How to become a subscriber to the mailing list ============================================== You can join the mailing list by sending a message to (NOT !) with your request to be added to the list. Maintenance is done by hand, so some delay is possible. How to unsubscribe from the mailing list ======================================== To leave the mailing list, send a message to . Miscellaneous ************* I want to contribute; where do I start? ======================================= A list of jobs which should be done for GNU-Pascal can be found in the section "How to contribute of the Texinfo deocumentation. In cases where somebody is already working on a topic, the name of that person is written behind the job's description. This does not mean that you shouldn't do that but just that you should get in contact with that person if you would like to contribute to that field. About this FAQ. =============== Maintainer: J.J. van der Heijden This is the first incarnation of the GNU Pascal FAQ list. Comments about, suggestions for, or corrections to this FAQ list are welcome. Please make sure to include in your mail the version number of the document to which your comments apply (you can find the version at the beginning of this FAQ list). Much of the info in this FAQ list was taken from the gpc mailing list traffic, so you may have (unbeknownst to you) contributed to this list. --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Thu Oct 24 15:55:54 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA28529 for ; Thu, 24 Oct 1996 15:55:54 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74094; Thu, 24 Oct 1996 16:04:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53972; Thu, 24 Oct 1996 16:03:14 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA23806 for ; Thu, 24 Oct 1996 16:42:32 +0300 (EET DST) Received: from [130.89.179.47] (pc047.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA14948 (5.67b/IDA-1.5 for ); Thu, 24 Oct 1996 15:42:22 +0200 Date: Thu, 24 Oct 96 15:48:48 CST From: "J.J. van der Heijden" Message-Id: <68491.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: FAQ v0.2 Status: RO Ok folks, I updated my first attempt at a FAQ a bit, and did some very crude Texification, so a html version exists too, which I sent to Peter for the homepages at agnes.dida.physik.uni-essen.de Let me know if you find any errors or sections that need clarification. JanJaap This is Info file FAQ, produced by Makeinfo-1.64 from the input fil faq.texi aq.texi. fo file FAQ, produced by Makeinfo-1.64 from the input file OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Revision 0.2 of 24 October 199 Revision 0.2 of 24 October 1996 Makeinfo-1.64 from the input file OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Author: J.J. van der Heijden OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & What is GNU Pascal ****************** ****************** der Heijden OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The purpose of the GNU Pascal project is to produce a Pascal compile (called GNU Pascal or GPC) whic called GNU Pascal or GPC) which project is to produce a Pascal compiler OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * combines the clarity of Pascal with powerful tools suitable fo real-life programming real-life programming, Pascal with powerful tools suitable for ler OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * supports both the Pascal standard and the Extended Pascal standar as defined by ISO, ANSI and IEEE. (ISO 7185:1990, ISO/IE 10206:1991, ANSI/IEEE 770X3.160-1989 10206:1991, ANSI/IEEE 770X3.160-1989) 7185:1990, ISO/IEC standard OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * supports other Pascal standards (UCSD Pascal, Borland Pascal Pascal-SC) in so far as this serves the goal of clarity an usability usability, in so far as this serves the goal of clarity and , dard OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * may be distributed under GNU license condition * may be distributed under GNU license conditions clarity and , dard OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * can generate code and run on any computer for which the GNU compiler can generate code and run compiler can generate code and run. puter for which the GNU C dard OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Pascal was originally designed for teaching. GNU Pascal provides smooth way to proceed to challenging programming tasks without learnin a completely different language completely different language. ing programming tasks without learning OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & What is the current version of GNU Pascal ========================================= ========================================= mming tasks without learning OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The last official release is GPC 1.1, based on GCC version 2.6.3 GPC version 1.2, based on GCC 2.7.2 is currently in beta testing PC version 1.2, based on GCC 2.7.2 is currently in beta testing. 3. ng OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Where is the GNU Pascal FTP site? WWW ===================================== ===================================== currently in beta testing. 3. ng OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The master FTP site for GNU Pascal is kampi.hu.fi GNU Pascal relate files can be found in iles can be found in: for GNU Pascal is kampi.hu.fi GNU Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & ftp://ftp.kampi.hut.fi/jtv/gnu-pascal ftp://ftp.kampi.hut.fi/jtv/gnu-pascal/ pi.hu.fi GNU Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This site is mirrored on This site is mirrored on: tv/gnu-pascal/ pi.hu.fi GNU Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & ftp://sunsite.doc.ic.ac.uk/gnu/pascal ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ pi.hu.fi GNU Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The latest developer releases can be downloaded from The latest developer releases can be downloaded from: Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & ftp://agnes.dida.physik.uni-essen.de ftp://agnes.dida.physik.uni-essen.de/ nloaded from: Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Also, we have a homepage on the web Also, we have a homepage on the web: e/ nloaded from: Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://agnes.dida.physik.uni-essen.de/~gnu-pascal http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Is it compatible with Turbo Pascal (R) ======================================= ======================================= e/~gnu-pascal/ Pascal related OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GPC is currently *not* a drop-in replacement for Borland's Turb Pascal (R). It supports a number, but not all of the Borlan extensions to the Pascal language. There is no replacement for most o the Borland runtime library functions. GNU Pascal is part of the GN project, so portability is one of its primary goals. For this reason non-portable features of Borland Pascal will probably not be include into GNU Pascal. More information can be found in the section "Borlan Pascal" of the GPC manual ascal" of the GPC manual. mation can be found in the section "Borland OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Installation related question ***************************** ***************************** on can be found in the section "Borland OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This section discusses some common problems with the installation o GNU Pascal NU Pascal. ion discusses some common problems with the installation of OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Which platforms are supported by GNU Pascal =========================================== =========================================== s with the installation of OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GPC uses the GCC backend, so it should run on any system that i supported by GNU CC. This includes a large variety of Unix systems MS-DOS, OS/2 and Win32. A full list of platforms supported by GCC ca be found in the file "INSTALL" of the GCC distribution. Not all o these have actually been tested, but the gpc-1.2 pre-release is know t run on these platforms un on these platforms: tested, but the gpc-1.2 pre-release is know to OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & i486-linux (Linux 2.x, ELF i486-linuxaou i486-linuxoldl i486-freebsd2. i386-cygwin32 (Windows95/Windows NT i386-djgppv2 (MS-DOS i386-emx (OS/2, MS-DOS mips-sgi-irix5. mips-sgi-irix5.3 (OS/2, MS-DOS) ows NT) -release is know to OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & >>> Ok people - send us your success stories, with canonical machin name! << ame! <<< people - send us your success stories, with canonical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Which components do I need to compile Pascal source code ======================================================== ======================================================== nical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & A complete Pascal compiler system should at least have A complete Pascal compiler system should at least have: ical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * The actual compiler, GPC * The actual compiler, GPC. ystem should at least have: ical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * Assembler, linker, librarian and friends * Assembler, linker, librarian and friends. least have: ical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * A C library * A C library. nker, librarian and friends. least have: ical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * A debugger, if you want to debug your programs * A debugger, if you want to debug your programs. have: ical machine OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & You don't need a C compiler to compile your Pascal programs, but yo do need it to build the GNU Pascal compiler itself. GNU Pascal versio 1.1 is based on GCC 2.6.3, GPC v1.2 is based on GCC v2.7.2 Any attemp to build GPC with the wrong version of GCC is bound to fail o build GPC with the wrong version of GCC is bound to fail. y attempt OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & For most people, the GNU binutils and GNU debugger (gdb) are a goo choice, although some may prefer to use vendor specific tools hoice, although some may prefer to use vendor specific tools. a good OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Help! linking gpc1 fails: _emit_string_move undefined (and more =============================================================== =============================================================== good OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & If linking `gpc1' bombs out with an error message that looks lik this his: linking `gpc1' bombs out with an error message that looks like d OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & ld: Undefined symbo _emit_string_mov _emit_string_pa _maybe_find_function_dat _dbxout_set_type_statu _version_fla *** Error code make: Fatal error: Command failed for target `gpc1 make: Fatal error: Command failed for target `gpc1' ks like d OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & you probably suffer from a VPATH make problem. A few GPC sourc files have counterparts with identical name in the GCC sourc directory. When you have built GCC in the GCC source directory and yo are not using a recent version of GNU make this problem may occur There are three solutions here are three solutions: ion of GNU make this problem may occur. you OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * Get a recent version of GNU make. Version 3.74 or better is know to work to work. ent version of GNU make. Version 3.74 or better is known OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * Build GCC in a seperate directory instead of using the GCC sourc directory directory. n a seperate directory instead of using the GCC source OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * Manually delete these files from the GCC object directory * Manually delete these files from the GCC object directory: source OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & `stor-layout.o dbxout.o expr.o fold-const.o optabs.o convert.o `function.o setop.o toplev.o `function.o setop.o toplev.o' fold-const.o optabs.o convert.o' e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & then resume `make' then resume `make'. toplev.o' fold-const.o optabs.o convert.o' e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & When I build libgpc.a, rts-rt0.c says: SIGXCPU undefined (and more ================================================================== ================================================================== e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Compilation of the runtime system may fail in rts-rt0.c with message simular to this essage simular to this: time system may fail in rts-rt0.c with a = e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & rts-rt0.c: `SIGXCPU' undeclared (first use this function or rts-rt0.c: storage size of `sv' isn't know rts-rt0.c: storage size of `osv' isn't know rts-rt0.c: storage size of `osv' isn't known is function) a = e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & If this happens to you, you have to edit the rts/rts-config.h fil and comment out the last line to nd comment out the last line to: e to edit the rts/rts-config.h file OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & /* #undef HAVE_SIGSYS * /* #undef HAVE_SIGSYS */ to: e to edit the rts/rts-config.h file OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This will be fixed in a future release This will be fixed in a future release. the rts/rts-config.h file OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I'm using unix, and all my Pascal programs have linking problems ================================================================ ================================================================ ile OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & A number of unix configurations use their system's linker instead o GNU ld. Usually, GPC and GCC need a program called `collect2' befor calling the system's `ld'. `collect2' is installed by GCC, and if yo only install GPC, it will not find collect2, and use the system linke directly, which will result in various linker errors. The solution i to copy `collect2' by hand from the GCC directory to the location wher `gpc1' lives gpc1' lives. ct2' by hand from the GCC directory to the location where OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I do I debug my Pascal programs =============================== =============================== he GCC directory to the location where OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & To debug your programs, (a) GNU Pascal must be able to generat executables with debug info for your platform, and (b) you must have debugger which understands this ebugger which understands this. our platform, and (b) you must have a OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * If `gpc -g -o hello hello.p' says: "gpc: -g not supported for thi platform", then GPC is unable to generate debug info. Usually installing GAS instead of your system's assembler can overcom this. When you configure the GCC used for GPC, specif "-with-gnu-as", and possibly "-with-gnu-ld" and/or "-with-stabs" More information can be found in "INSTALL" file in the GNU C source directory source directory. an be found in "INSTALL" file in the GNU CC s". OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * Your system's debugger may not understand the debug info generate by GNU tools. In this case, installing GDB may help by GNU tools. In this case, installing GDB may help. nfo generated OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The bottom line: if you can debug GCC compiled programs, you shoul be able to do this with GPC too e able to do this with GPC too. bug GCC compiled programs, you should OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The GNU debugger (GDB) currently does not have a "Pascal" mode, s it is unable to display certain Pascal structures etc. When debugging please note that the Initial Letter In Each Identifier Is In Upper Cas And The Rest Are In Lower Case. If you want to display variable 'foo in the debugger, type `show Foo' or `display Foo' instead n the debugger, type `show Foo' or `display Foo' instead. able 'foo' e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Can you recommend an IDE ======================== ======================== w Foo' or `display Foo' instead. able 'foo' e OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Users of Borland Pascal may wonder if there's a replacement for th IDE (Integrated Development Environment). Here's a few suggestions DE (Integrated Development Environment). Here's a few suggestions: he OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * *(X)Emacs*. Some people think it's the answer to the question o Life, the Universe and Everything, others decide it's uGNUsable Available from your friendly GNU mirror Available from your friendly GNU mirror. decide it's uGNUsable. OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * *XWPE* is an immitation of the Borland IDE, so users of Borlan Pascal may find it a good alternative Pascal may find it a good alternative. IDE, so users of Borland OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Although GDB is an excellent debugger, it's user interface is no very attractive. Refer to the comp.windows.x FAQ: "Where can I get a X-based debugger?" at -based debugger?" at: to the comp.windows.x FAQ: "Where can I get an OF Z tY 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/part6/faq-doc-2.htm http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Some useful frontends include: XXGDB, tGDB and XWPE. see Some useful frontends include: XXGDB, tGDB and XWPE. see: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://www.ee.ryerson.ca:8080/~elf/xapps/Q-IV.htm http://www.ee.ryerson.ca:8080/~elf/xapps/Q-IV.html see: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Very nice, but resource consuming is the Motif based DDD Very nice, but resource consuming is the Motif based DDD: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://sol.ibr.cs.tu-bs.de/softech/ddd http://sol.ibr.cs.tu-bs.de/softech/ddd/ otif based DDD: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Do we have a binary for you =========================== =========================== de/softech/ddd/ otif based DDD: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Currently, we have binaries for these platforms Currently, we have binaries for these platforms: sed DDD: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & i486-linux (ELF i486-linuxaou i486-linuxoldl djgpp V2 (msdos emx 0.9B (OS/2, msdos cygwin32 beta16 (Windows95, Windows NT mips-sgi-irix5. mips-sgi-irix5.3 (Windows95, Windows NT) ms: sed DDD: /part6/faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & New binaries may have been added after the release of this FAQ New binaries may have been added after the release of this FAQ. /faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GNU Pascal and your system librarie *********************************** *********************************** fter the release of this FAQ. /faq-doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This section discusses common problems people have when they try t access their system's libraries ccess their system's libraries. problems people have when they try to -doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How do I use from the C library =========================================================== =========================================================== ey try to -doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GNU Pascal can use every function of your C library, but it may b up to you to write declaration of an external function, before you ca use it. Consider the function `sleep'. man(3) sleep reveals se it. Consider the function `sleep'. man(3) sleep reveals: you can -doc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- NAM sleep - Sleep for the specified number of second SYNOPSI #include 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This small demo program shows how to use `sleep' in a Pascal program This small demo program shows how to use `sleep' in a Pascal program: oc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- program SleepDemo typ word = __unsigned__ integer function sleep(seconds: word): word; C va result : word begi result := sleep(10) end -------------------------------------------------------- --------------------------------------------------------- program: oc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & What's this confusion about Pascal and C style strings ====================================================== ====================================================== ------ program: oc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & It is important not to confuse Pascal and C string types It is important not to confuse Pascal and C string types. - program: oc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * The Pascal string schema, as defined in section 6.4.3.3.3 of th ISO-10206:1990 Extended Pascal standard, is a record ISO-10206:1990 Extended Pascal standard, is a record: 3.3 of the m: oc-2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & type string = recor Capacity : integer length : integer string : packed array [ 1..Capacity ] of char end end; ing : packed array [ 1..Capacity ] of char; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & 'string' is not 'string(256)', unlike Turbo Pascal. The capacict must be declared must be declared: ing(256)', unlike Turbo Pascal. The capacicty ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & typ MyString = string(256) MyString = string(256); unlike Turbo Pascal. The capacicty ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & before it can be used, i.e. before it can be used, i.e.: ; unlike Turbo Pascal. The capacicty ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & function MyFunction: MyString function MyFunction: MyString; Turbo Pascal. The capacicty ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & * A C string ( "char *" ) is an array of char, terminated with NULL char NULL char. ( "char *" ) is an array of char, terminated with a ty ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & C library functions require C, not Pascal style string arguments Consider this code snippet to convert Pascal style strings to C styl and vice versa nd vice versa: de snippet to convert Pascal style strings to C style ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- typ word = __unsigned__ integer TString = string(256); { Pascal string schema CString = __cstring__; { C style string { Convert a "C" string to a "Pascal" string function StrPas(Src: CString): TString va S : TString begi S := '' if (Src <> NIL then while ( (Src^ <> chr(0)) AND (length(S) < S.capacity)) d begi S := S + Src^ inc(Word(Src)) end StrPas := S end { Convert a "Pascal" string to a "C" string function StrPCopy(Dest: CString; Src: String): CString va c: integer p : CString begi p := Dest for c:=1 to length(Src) d begi p^ := Src[c] inc(word(p)) end p^ := chr(0) StrPCopy := Dest end -------------------------------------------------------- --------------------------------------------------------- y)) do ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Then this small example will print the PATH Then this small example will print the PATH: -------------- y)) do ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- Program EnvDemo { include the above StrPas() and StrPCopy() snippet here { C library function prototype: char *getenv(const char *name); function GetEnv(name : CString): CString; C va pName: CString begi getmem(pName, 256) pName := StrPCopy(pName, 'PATH') writeln('Your PATH is: ', StrPas(GetEnv(pName))) freemem(pName, 256) end -------------------------------------------------------- --------------------------------------------------------- ame); } ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & And this is how you access the 'system()' call in you C library And this is how you access the 'system()' call in you C library: } ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- program SysCall { include the above StrPas() and StrPCopy() snippet here function system(name : CString): integer; C va pName: CString result : integer begi getmem(pName, 256) pName := StrPCopy(pName, 'ls -l') result := system(pName) writeln('system() call returned : ', result) freemem(pName, 256) end -------------------------------------------------------- --------------------------------------------------------- ry: } ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & There may be other ways to do the same thing; you could declare type PChar instead of CString ype PChar instead of CString: o the same thing; you could declare a } ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & type PChar = ^char type PChar = ^char; ring: o the same thing; you could declare a } ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & and replace all references to `CString' with `PChar'. Do NOT pass "C" style string as a var-argument if the C prototype says "const cha *" or you will get a coredump " or you will get a coredump. ent if the C prototype says "const char ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & You are right if you think this stuff belongs in a library, to b distributed with GPC. Have patience, or start coding istributed with GPC. Have patience, or start coding! library, to be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Are GNU Pascal objects compatible with GNU C++ classes ======================================================= ======================================================= rary, to be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & No. (This may change in a future version No. (This may change in a future version) =========== rary, to be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Where are the Turbo Pascal (R) replacement units ================================================ ================================================ ====== rary, to be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & They don't exist (yet). Most of their fuctionality can easily b implemented, some things are very x86/msdos dependant and would b meaningless on any other platform eaningless on any other platform. 86/msdos dependant and would be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How do I build/use a shared library =================================== =================================== /msdos dependant and would be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & (topic under construction (topic under construction) ====== /msdos dependant and would be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GNU Pascal on the djgpp (MS-DOS) platfor **************************************** **************************************** s dependant and would be r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This chapter discusses some potential problems with GNU Pascal o MS-DOS, using djgpp S-DOS, using djgpp. sses some potential problems with GNU Pascal on r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & If you need more informatio =========================== =========================== e potential problems with GNU Pascal on r ar; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GPC/djgpp is a djgpp V2 application, and most of the djgp documentation applies for GPC too. A great source of information is th djgpp FAQ jgpp FAQ: on applies for GPC too. A great source of information is the r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://www.delorie.com/djgpp/v2faq/faq202b.zi http://www.delorie.com/djgpp/v2faq/faq202b.zip information is the r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Another place to look for DJGPP documentation is the DJGPP Knowledg Base, at this URL ase, at this URL: look for DJGPP documentation is the DJGPP Knowledge r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://www.delorie.com/djgpp/doc/kb http://www.delorie.com/djgpp/doc/kb/ tation is the DJGPP Knowledge r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & What do I download ================== ================== rie.com/djgpp/doc/kb/ tation is the DJGPP Knowledge r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & As discussed in section 2.2, other than GPC itself, you need a assembler, linker and friends, a C library and possibly a debugger >From your local djgpp mirror, you can get these as rom your local djgpp mirror, you can get these as: bly a debugger. dge r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & v2/djdev200.zip (C library v2gnu/bnu252b.zip (assembler, .... v2gnu/gdb412b.zip (debugger v2gnu/gdb412b.zip (debugger) ....) as: bly a debugger. dge r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The rest is up to you; 'make' (v2gnu/mak372b.zip) can be useful RHIDE (an IDE with Borland-look) is nice, but still under development Future releases of RHIDE may have better GPC support uture releases of RHIDE may have better GPC support. der development. r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How do I install the compiler ============================= ============================= ve better GPC support. der development. r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & If you don't have djgpp installed on your harddisk, create directory for GNU pascal ("c:\gpc"), and unzip the archives. Make sur you preserve the directory structure (use "pkunzip -d"). Now, add th directory where gpc.exe lives ("c:\gpc\bin") to your path and set th DJGPP environment variable to point to your djgpp.env file JGPP environment variable to point to your djgpp.env file: d set the r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & set DJGPP=c:\gpc\djgpp.en set DJGPP=c:\gpc\djgpp.env int to your djgpp.env file: d set the r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Then, add this to your djgpp.env file Then, add this to your djgpp.env file: r djgpp.env file: d set the r; -2.html 'J& pY L& < 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- [gpc-cpp C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/lang/pascal;%DJDIR%/include;%DJDIR%/contrib/grx20/includ [gpc COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bi LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/li -------------------------------------------------------- --------------------------------------------------------- grx20/lib e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The binary distribution should come with a `djgpp.env' which i already modified, so you may not have to do this lready modified, so you may not have to do this. pp.env' which is 0/lib e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Specific information for low-memory conditions and more can be foun in the djgpp FAQ and documentation n the djgpp FAQ and documentation. ry conditions and more can be found e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & GPC says: no DPM ================ ================ nd documentation. ry conditions and more can be found e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & You don't have a DPMI server installed, and DJGPP v2 requires it t run. You can either use one of the commercial DPMI servers (e.g., ru `gpc' in a DOS box under Windows) or download and install CWSDPM (`csdpmi3b.zip') which is a free DPMI server written for DJGPP `csdpmi3b.zip') which is a free DPMI server written for DJGPP. I run e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I cannot read the info pages ============================ ============================ ee DPMI server written for DJGPP. I run e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & To read the info pages, you need the `info' program from txi360b.zip At least for some of the pre-releases of gpc-1.2, the gpc.info file i invalid: it refers to the "gpc.i*" sections as "gpc.info-*". This can b fixed by loading gpc.inf in an editor and replacing "gpc.info-*" wit "gpc.i* gpc.i*" loading gpc.inf in an editor and replacing "gpc.info-*" with be e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I have troubles with assembly cod ================================= ================================= or and replacing "gpc.info-*" with be e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & The GNU Assembler (`as.exe'), or `gas', called by GCC accepts "AT&T syntax which is different from "Intel" syntax. Differences ar discussed in section 17.1 of the djgpp FAQ iscussed in section 17.1 of the djgpp FAQ. x. Differences are s "AT&T" e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & A guide is available which was written by Brennan Mr. Wacko Underwoo and describes how to use inline assembl programming with DJGPP, at this URL rogramming with DJGPP, at this URL: how to use inline assembly derwood e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & http://www.rt66.com/~brennan/djgpp/djgpp_asm.htm http://www.rt66.com/~brennan/djgpp/djgpp_asm.html assembly derwood e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Section 17.3 of the djgpp FAQ discusses some methods to conver "Intel" syntax to "AT&T" Intel" syntax to "AT&T". pp FAQ discusses some methods to convert rwood e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Tell me how to do DPMI, BIOS and other DOS related things ========================================================= ========================================================= convert rwood e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & DPMI, BIOS and other functions are no different than other syste functions. Refer to section 3.1 how to access your system's C-library This small example shows how to use DPMI, copying some structures an function prototypes of unction prototypes of : se DPMI, copying some structures and d e;%DJDIR%/contrib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & -------------------------------------------------------- program dpmitest {$X+ typ word = __unsigned__ integer short = __short__ integer byte = __byte__ integer typ PDpmiVersionRet = ^TDpmiVersionRet TDpmiVersionRet = recor major : byte minor : byte flags : short cpu : byte master_pic : byte slave_pic : byte end typ PDpmiFreeMemInfo = ^TDpmiFreeMemInfo TDpmiFreeMemInfo = recor largest_available_free_block_in_bytes : word maximum_unlocked_page_allocation_in_pages : word maximum_locked_page_allocation_in_pages : word linear_address_space_size_in_pages : word total_number_of_unlocked_pages : word total_number_of_free_pages : word total_number_of_physical_pages : word free_linear_address_space_in_pages : word size_of_paging_file_partition_in_pages : word reserved1 : byte reserved2 : byte reserved3 : byte end function DpmiGetVersion(ret: PDpmiVersionRet): integer asmname '__dpmi_get_version' function DpmiGetFreeMemoryInformation(info: PDpmiFreeMemInfo): integer asmname '__dpmi_get_free_memory_information' va version: TDpmiVersionRet meminfo: TDpmiFreeMemInfo begi DpmiGetVersion(@version) writeln('CPU type : ', version.cpu, '86') writeln('DPMI major : ', version.major) writeln('DPMI minor : ', version.minor) DpmiGetFreeMemoryInformation(@meminfo) writeln('Free DPMI memory : ', meminfo.total_number_of_free_pages, ' pages.') end -------------------------------------------------------- --------------------------------------------------------- ree_pages, ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I'm accessing an "array[1..4000000] of byte" and I got an exception =================================================================== =================================================================== ges, ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Per default, the maximum stack size of a djgpp application is 256K If you need more, you have to adjust it with the stubedit program, i.e. f you need more, you have to adjust it with the stubedit program, i.e.: ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & stubedit your_app.exe minstack=5000 stubedit your_app.exe minstack=5000K th the stubedit program, i.e.: ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Still, it might be a good idea to use pointers for this kind o structures, and allocate the memory at runtime tructures, and allocate the memory at runtime. s for this kind of i.e.: ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Getting Hel *********** *********** nd allocate the memory at runtime. s for this kind of i.e.: ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This section discusses ways to get help with GNU Pascal. Please rea the documentation (info files, readme's) that come with GPC, plus othe docs that might help (the djgpp FAQ if you use djgpp etc.) before yo send email to the maintainers or mailing list end email to the maintainers or mailing list. djgpp etc.) before you r ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Help! the compiler crashed ========================== ========================== s or mailing list. djgpp etc.) before you r ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & If the compiler crashes, you have discovered a bug. A reliabl compiler never crashes. To help the maintainers fix this bug, it i important that you send us a problem report mportant that you send us a problem report. rs fix this bug, it is u r ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I think I found a bug - now what ================================ ================================ em report. rs fix this bug, it is u r ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Bugs are best reported to the GPC mailinglist, gpc@hut.fi. Tha way, they always reach the maintainers. Try to give as much informatio as possible, plus a short code snippet that triggers the compiler bug If you're on unix, you can find out where the compiler crashed if yo enable coredumps, then load the compiler (gpc1) plus the core file i the debugger ("gdb /your_path_here/gpc1 core"), then type `backtrace to get a stacktrace. Include this stacktrace in your bug report o get a stacktrace. Include this stacktrace in your bug report. ace' ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Which newsgroup(s) are suited for GPC related problems ====================================================== ====================================================== report. ace' ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & There are several Pascal related newsgroups, but none is dedicate just to GNU Pascal. This one may be useful ust to GNU Pascal. This one may be useful: ps, but none is dedicated ' pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & comp.lang.pascal.misc Pascal in general and ungrouped Pascals comp.lang.pascal.misc Pascal in general and ungrouped Pascals. pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Pascal syntax related questions may be appropriate in Pascal syntax related questions may be appropriate in: ngrouped Pascals. pages.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & comp.lang.pascal.ansi-iso Pascal according to ANSI and ISO standards comp.lang.pascal.borland Borland Pascal questions comp.lang.pascal.borland Borland Pascal questions. nd ISO standards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How to post to the mailing lis ============================== ============================== Borland Pascal questions. nd ISO standards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & You can send a message to the GPC mailing list by sending email t the list address as if it were a person he list address as if it were a person. ending email to andards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How to become a subscriber to the mailing lis ============================================= ============================================= erson. ending email to andards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & You can join the mailing list by sending a message t (NOT !) with your request to be adde to the list. Maintenance is done by hand, so some delay is possible o the list. Maintenance is done by hand, so some delay is possible. ed dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & How to unsubscribe from the mailing lis ======================================= ======================================= so some delay is possible. ed dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & To leave the mailing list, send a message to To leave the mailing list, send a message to . d dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Miscellaneou ************ ************ e mailing list, send a message to . d dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & I want to contribute; where do I start ====================================== ====================================== sage to . d dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & A list of jobs which should be done for GNU-Pascal can be found i the section "How to contribute of the Texinfo deocumentation. In case where somebody is already working on a topic, the name of that perso is written behind the job's description s written behind the job's description. pic, the name of that person s dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This does not mean that you shouldn't do that but just that yo should get in contact with that person if you would like to contribut to that field o that field. ontact with that person if you would like to contribute dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & About this FAQ ============== ============== ntact with that person if you would like to contribute dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Maintainer: J.J. van der Heijde if you would like to contribute dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & This is the first incarnation of the GNU Pascal FAQ list. Comment about, suggestions for, or corrections to this FAQ list are welcome bout, suggestions for, or corrections to this FAQ list are welcome. dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Please make sure to include in your mail the version number of th document to which your comments apply (you can find the version at th beginning of this FAQ list) eginning of this FAQ list). ts apply (you can find the version at the dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & Much of the info in this FAQ list was taken from the gpc mailin list traffic, so you may have (unbeknownst to you) contributed to thi list ist. raffic, so you may have (unbeknownst to you) contributed to this dards. es.'); trib/grx20/include 'J& pYd' : 'J&J& > 'J& (J& 3 ' :8 *J& (J&J& WriteString &4 : 'J& pY ' :8 'J& p p p p p p p p p p p p p p p p p p p p & --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Thu Oct 24 15:53:13 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA28524 for ; Thu, 24 Oct 1996 15:53:12 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75226; Thu, 24 Oct 1996 16:01:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80868; Thu, 24 Oct 1996 16:00:33 +0200 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id QAA24895 for ; Thu, 24 Oct 1996 16:52:09 +0300 (EET DST) Received: from [130.89.179.47] (pc047.pczaalciv.utwente.nl) by driene.student.utwente.nl with SMTP id AA16549 (5.67b/IDA-1.5 for ); Thu, 24 Oct 1996 15:52:07 +0200 Date: Thu, 24 Oct 96 15:58:33 CST From: "J.J. van der Heijden" Message-Id: <69024.s8806144@mail.student.utwente.nl> X-Minuet-Version: Minuet1.0_Beta_16 Reply-To: X-Popmail-Charset: English To: gpc@hut.fi Subject: Re: getenv - any solutions? Status: RO On Wed, 23 Oct 1996 02:03:57 -0400 (EDT), John Michael Black wrote: >There's been a lot of getenvs going around here lately. :) Has anyone >found a method that works yet? The last thing posted about it gave this: > > Function GetEnv ( Name: __CString__ ): PChar; C; > >GPC does not recognize PChar -- at least ours doesn't. > >This could go on for weeks.... :) Naah.... Take this: (* * Demonstrate the conversion of "Pascal" string schemas to "C" style * strings and back, and calling an external "C" style function. * * J.J. van der Heijden *) Program EnvDemo; type word = __unsigned__ integer; TString = string(256); { Pascal string schema } CString = __cstring__; { C style string } { Convert a "C" string to a "Pascal" string } function StrPas(Src: CString): TString; var S : TString; begin S := ''; if (Src <> NIL) then while ( (Src^ <> chr(0)) AND (length(S) < S.capacity)) do begin S := S + Src^; inc(Word(Src)); end; StrPas := S; end; { Convert a "Pascal" string to a "C" string } function StrPCopy(Dest: CString; Src: String): CString; var c: integer; p : CString; begin p := Dest; for c:=1 to length(Src) do begin p^ := Src[c]; inc(word(p)) end; p^ := chr(0); StrPCopy := Dest; end; { C library function prototype: char *getenv(const char *name); } function GetEnv(name : CString): CString; C; var pName: CString; begin getmem(pName, 256); pName := StrPCopy(pName, 'USER'); writeln('Hello ', StrPas(GetEnv(pName)), ' !'); pName := StrPCopy(pName, 'PATH'); writeln('Your PATH is: ', StrPas(GetEnv(pName))); freemem(pName, 256); end. There are multiple ways to do this: for example, you can also declare a type PChar = ^char; and replace every instance of CString with PChar. Works great. Do not pass a CString argument as a "var" if it's declared as "const char *" in C; you will definately get a coredump. (in C too BTW) I tested this with Linux and djgpp (dos) GPC, 1.2 prerelease. The GPC-1.1 may have troubles with the function returning a TString schema. Let me know if it doesn't work for you, though I can't imagine that. JanJaap --- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Oct 29 18:08:53 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA02649 for ; Tue, 29 Oct 1996 18:08:52 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80600; Tue, 29 Oct 1996 17:15:24 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84682; Tue, 29 Oct 1996 17:14:25 +0100 Received: from igate1.hac.com (igate1.HAC.COM [192.48.33.10]) by santra.hut.fi (8.7.5/8.7.3) with ESMTP id SAA08123 for ; Tue, 29 Oct 1996 18:04:45 +0200 (EET) Received: from rf600.es.hac.com (root@[147.17.235.62]) by igate1.hac.com (8.7.6/8.7.3) with SMTP id JAA08954 for ; Tue, 29 Oct 1996 09:04:16 -0700 (PPET) Received: from X-147-17-235-66.ES.HAC.COM (zx6rr [147.17.235.66]) by rf600.es.hac.com (8.6.12/8.6.9) with SMTP id JAA00563 for ; Tue, 29 Oct 1996 09:00:38 -0800 Message-Id: <32762AF1.4B6@rf600.es.hac.com> Date: Tue, 29 Oct 1996 08:04:01 -0800 From: "Michael B. Williams" Organization: Hughes Aircraft Company X-Mailer: Mozilla 2.01 (Win16; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: /lib/libm.so.5.0.5: undefined reference to `__errno_location' Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO hi, i download this file gpc-1.1p2-linuxelf.tar.gz from some ftp site, and i'm confused. The below executable is in this file, but there is no source. -rwxr-xr-x root/root 48100 Dec 20 09:53 1995 usr/bin/gpc i get the following error on a simple pascal program. i don't know pascal so i'm assuming it right /lib/libm.so.5.0.5: undefined reference to `__errno_location' program Mytestfile (input, output); procedure HI; begin {GotoXY(1, 23);} {WRITE("Hi");} end; BEGIN { main program } HI; END. next, i then downlaod the latest and i'm still getting the same error :<. -rwxr-xr-x 1 root root 50348 Aug 28 14:15 /usr/bin/gpc* rf600:~$ gpc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs gpc version 1.2(2.7.2) rf600:~$ gpc tst.pas /lib/libm.so.5.0.5: undefined reference to `__errno_location' any and all help will be greatly appreciated michael b. williams mbw@rf600.es.hac.com From gpc-request@santra.hut.fi Tue Oct 29 22:54:57 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA02944 for ; Tue, 29 Oct 1996 22:54:57 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69728; Tue, 29 Oct 1996 22:01:24 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74310; Tue, 29 Oct 1996 22:00:26 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.7.5/8.7.3) with SMTP id WAA09504 for ; Tue, 29 Oct 1996 22:50:46 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA09237 (5.67b/IDA-1.5 for ); Tue, 29 Oct 1996 21:49:26 +0100 Message-Id: <2.2.32.19961029205057.0068db78@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Oct 1996 21:50:57 +0100 To: mbw@rf600.es.hac.com From: JanJaap van der Heijden Subject: Re: /lib/libm.so.5.0.5: undefined reference to `__errno_location' Cc: gpc@hut.fi Status: RO At 08:04 AM 10/29/96 -0800, you wrote: >hi, > >i download this file gpc-1.1p2-linuxelf.tar.gz from some ftp site, and >i'm confused. The below executable is in this file, but there is no >source. Sources, info etc.: follow the pointers at the homepage: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ > >-rwxr-xr-x root/root 48100 Dec 20 09:53 1995 usr/bin/gpc > > >i get the following error on a simple pascal program. i don't know pascal >so i'm assuming it right > >/lib/libm.so.5.0.5: undefined reference to `__errno_location' > >program Mytestfile (input, output); >procedure HI; > begin > {GotoXY(1, 23);} > {WRITE("Hi");} > end; > >BEGIN { main program } > > HI; > >END. > I would not expect to much output from this program ;-) >next, i then downlaod the latest and i'm still getting the same error :<. > >-rwxr-xr-x 1 root root 50348 Aug 28 14:15 /usr/bin/gpc* > >rf600:~$ gpc -v >Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs >gpc version 1.2(2.7.2) >rf600:~$ gpc tst.pas > /lib/libm.so.5.0.5: undefined reference to `__errno_location' > Are you sure you get an error when _compiling_ your test program, not when _running_ it ???? The GPC compiler itself does not use libm.so in any way, so this error message doesn't make any sense. But programs compiled with GPC always use libm.so > > >any and all help will be greatly appreciated > As far as I can see, (1) you don't have a GPC problem, but your version of libm and libc don't match or (2) you have a very old/new libc version which has an errno definition incompatible with the one used by the GPC precompiled binary. The 2.6.3 based GPC binary is linked against libc.so.5.0.9 (the one from Slackware 3.0) while the 2.7.2 based GPC binaries are linked against libc.so.5.2.18. I believe libm is version 5.0.5 in both cases. You can check your installed libc version: ZOO-station:~$ ldd /usr/bin/gpc libc.so.5 => /lib/libc.so.5.2.18 The dynamic loader is complaining because it cannot resolve a symbol, "__errno_location" which is indeed undefined in libm.so: ZOO-station:~$ nm /lib/libm.so.5 | grep __errno_location U __errno_location ("U" means undefined). But this symbol is defined in and should be present in libc.so: ZOO-station:~$ nm /lib/libc.so.5 | grep __errno_location 0000fe4c W __errno_location To make sure it's not GPC who's causing trouble, try compiling a small piece of C which uses libm.so, i.e.: int main(void) { printf("sine of 0 = %f\n", sin(0)); } If it's the problem described by (1) then this should produce the same sort of errors. Usually, a libc.so is backwards compatible, but if you have a libc.so < 5.0.9 it may be time to upgrade. If will not use experimental libc versions (5.3.x, 5.4.x) to produce the precompiled GPC binaries, because I don't want to force people to upgrade to these versions. If you use an experimental libc.so version, see if the errno definition in has changed since 5.2.18 (I cannot verify this -- I don't have it). If so, you may have to rebuild libgpc.a because it uses the errno definition. In the 5.2.18 it's defined like this: #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT) extern int* __errno_location __P((void)); #define errno (*__errno_location ()) #else extern int errno; #endif Hope this helps, otherwise it might be useful to see your results for the tests described above. JanJaap -- The latest & greates in software, hardware and manswear -- Bono Vox (U2) From gpc-request@santra.hut.fi Sun Nov 3 14:03:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA08033 for ; Sun, 3 Nov 1996 14:03:55 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA88140; Sun, 3 Nov 1996 13:08:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74948; Sun, 3 Nov 1996 13:07:43 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id NAA01571 for ; Sun, 3 Nov 1996 13:58:29 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA28013 (5.67b/IDA-1.5 for ); Sun, 3 Nov 1996 12:58:26 +0100 Message-Id: <2.2.32.19961103120001.00687bbc@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Nov 1996 13:00:01 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: Win95 version of GNU Pascal? Status: RO At 12:01 PM 11/2/96 -0700, you wrote: >Hi, > >I read somewhere that GNU has a Win95 version. If this is true where can I >get it? Is there anything else I need to download? > Let me just repeat the announcement: README for cygwin32 GNU Pascal ------------------------------ The latest cygwin32-compatible GNU Pascal binary is now available from: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/ I keep this seperate from the main release directory because some things have to be done before the next all-platform release. Still, the win32 GPC has improved enough that I think you should all try it out. Files in this directory: gpc-960930-2.7.2.i386-cygwin32-b16.zip Sep.30 snapshot binary of cygwin32 GPC. For a cygwin32-beta16 toolchain. gpc-961006-2.7.2.i386-cygwin32-b16.zip Oct.06 snapshot binary of cygwin32 GPC. For a cygwin32-beta16 toolchain. Essentially the same, but unstripped exe's. devtools.i386-cygwin32-b16.zip For those who only want to do Pascal, it's a waist to download a complete toolchain from ftp.cygnus.com. This archive has all the tools (as, ld, libraries) needed to complete GPC. If you already have cygwin32-beta16 installed, you don't need this. Changes ------- Since the last release (gpc-1.2-2.7.2.i386-cygwin32-b14.zip), these things have changed: * Now beta16 compatible. * Fixed internal fork() problems, now --automake works. * Pipes (`gpc -pipe ...') supported. * Binary/text file IO problem fixed. * Some new test programs. * Support for function attributes and multiple directives per function declaration. Effectively, this means this GPC can access the Win32 API and build both GUI and console applications! Thanks, Peter. See the demos in the "test\windows" subdirectory. Installation ------------ * create a subdirectory of your choice (`c:\gpcwin32') and unzip gpc-96MMDD-2.7.2.i386-cygwin32-b16.zip and devtools.i386-cygwin32-b16.zip from there. Use a version of `unzip' that can handle long filenames, i.e. not PKunzip. * Add the directory where `gpc.exe' lives (`c:\gpcwin32\bin') to your path. * Set GCC_EXEC_PREFIX=C:\gpcwin32\lib\gcc-lib\ Beware of the trailing slash! * Set LIBRARY_PATH=c:\gpcwin32\lib;c:\gpcwin32\i386-cygwin32\lib Not yet done ------------ GPC has incomplete support for the `stabs' debugging format. This affects the win32 platform (and all ELF unices). Although you can step your program in GDB, it may lose track of where you really are, be unable to display variables etc. I'm working on this. The function attributes and asmname directives seem to get lost in the GPI mechanism, so you will have to #include `units' for now, if they define WinAPI type functions. Other problems -------------- These things often give problems: * Do NOT mix binaries from different beta's -- they are incompatible. * Be sure to have only one `cygwin.dll' in your path and it must be beta16. The symptoms of these are crashes, stack/register dumps and Windows telling you it cannot load a dll. Read the cygwin32 FAQ (http://www.cygnus.com/ or this directory) Most of the information also applies for GNU Pascal. And please, do not bother the people of the cygwin32 mailinglist if you have problems with GPC, send them to the gpc@hut.fi list instead. Have fun, JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Sat Nov 2 21:08:05 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA07639 for ; Sat, 2 Nov 1996 21:08:05 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74770; Sat, 2 Nov 1996 20:13:08 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA24456; Sat, 2 Nov 1996 20:12:09 +0100 Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id VAA29381 for ; Sat, 2 Nov 1996 21:01:38 +0200 (EET) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.7.6/Unknown) with ESMTP id MAA07713 for ; Sat, 2 Nov 1996 12:01:35 -0700 (MST) Received: from ArosNet.aros.net (pm7-19.slc.aros.net [207.173.24.212]) by terra.aros.net (8.7.6/8.6.12) with SMTP id MAA14715 for ; Sat, 2 Nov 1996 12:01:34 -0700 Date: Sat, 2 Nov 1996 12:01:34 -0700 Message-Id: <199611021901.MAA14715@terra.aros.net> X-Sender: epic@aros.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@hut.fi From: Amy Williams Subject: Win95 version of GNU Pascal? Status: RO Hi, I read somewhere that GNU has a Win95 version. If this is true where can I get it? Is there anything else I need to download? TIA, Amy Williams epic@aros.net http://www.aros.net/~epic/ Finger for PGP public key. From gpc-request@santra.hut.fi Sat Nov 2 20:18:18 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA07600 for ; Sat, 2 Nov 1996 20:18:18 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74924; Sat, 2 Nov 1996 19:23:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77960; Sat, 2 Nov 1996 19:22:23 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id UAA28658 for ; Sat, 2 Nov 1996 20:17:45 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA07575 for gpc@hut.fi; Sat, 2 Nov 1996 20:13:22 +0100 From: Peter Gerwinski Message-Id: <199611021913.UAA07575@agnes.dida.physik.uni-essen.de> Subject: FreeBSD + Strings --> crash To: gpc@hut.fi Date: Sat, 2 Nov 1996 20:13:21 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, perhaps somebody can help me with a strange error which occurs when using Strings under FreeBSD. (It does not occur on DJGPP, EMX, or Linux.) The error is triggered by the program Program Crash; Type WrkString = String ( 80 ); Var S: WrkString; begin S:= 'A'; if S = 'A' then writeln ( 'Hurra!' ); end. It compiles fine, the assembly code looks nice, but it gets a signal "iot" (whatever that means) when running. The error happens in the RTS function _p_string() (see rts/rts-string.c): /* First arg is always a string or char */ if (argument_mask & P_STR_FIRST_IS_CHAR) { c1 = va_arg (p, char); s1 = &c1; len1 = 1; } else { /* It's a string */ s1 = va_arg (p, char *); len1 = va_arg (p, int); /* <------ SIGIOT */ } When examining the variables with gdb, everything looks nice, too. *p == 'A', etc. A similar error happens when running the following variant: Program Crash; uses CPtr; Var C: Char value 'A'; P: CharPtr; begin P:= @C; if P^ = 'A' then writeln ( 'Hurra!' ); end. It is essential that the type "CharPtr = ^Char" is exported by a Unit, not declared in the program. First, we get a warning about assignment of incompatible pointers for "P:= @C" which is, of course, nonsense, but I can explain it with the mechanism of forward references in pointer declarations. Again, the assembler code looks fine, but when running the program, I get a signal. :( And again, the error does not occur with DJGPP, EMX, or Linux - only with FreeBSD. DOES ANYBODY HAVE AN IDEA? Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Nov 5 13:41:22 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA10140 for ; Tue, 5 Nov 1996 13:41:21 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84754; Tue, 5 Nov 1996 12:45:27 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59434; Tue, 5 Nov 1996 12:44:25 +0100 Received: from baghira.han.de (baghira.han.de [192.109.225.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id NAA04529 for ; Tue, 5 Nov 1996 13:24:16 +0200 (EET) Received: from uzercp.zer.sub.org (root@localhost) by baghira.han.de (8.6.12-o/04-08-96/09:54:04) with BSMTP id for gpc@hut.fi; Tue, 5 Nov 1996 12:18:34 +0100 Received: by uzercp.zer.sub.org (uzcopy); Tue, 05 Nov 1996 03:03:43 CET Date: Mon, 04 Nov 1996 21:30:00 CET From: A.ECKLEDER@CHATEAU.zer.sub.org (Andreas Eckleder) Reply-To: A.ECKLEDER@CHATEAU.zer.sub.org X-Mailer: CrossPoint v3.1 Message-Id: <6KDVECg7CfB@p-andy.chateau.zer.sub.org> To: gpc@hut.fi Subject: problem with units... Organization: Z-Netz Network Area, Germany X-Gateway: Z-TRANSPARENT UU uzercp.zer.sub.org [UZERCP V4.54], ZCONNECT UU uzercp.zer.sub.org [CONNECT*UZERCP V0.95] Lines: 15 Status: RO Oh nein,eine E-Mail ....von MIR >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<; Tue, 5 Nov 1996 13:33:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74614; Tue, 5 Nov 1996 12:38:04 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49134; Tue, 5 Nov 1996 12:37:00 +0100 Received: from baghira.han.de (baghira.han.de [192.109.225.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id NAA04515 for ; Tue, 5 Nov 1996 13:25:58 +0200 (EET) Received: from uzercp.zer.sub.org (root@localhost) by baghira.han.de (8.6.12-o/04-08-96/09:54:04) with BSMTP id for gpc@hut.fi; Tue, 5 Nov 1996 12:18:32 +0100 Received: by uzercp.zer.sub.org (uzcopy); Tue, 05 Nov 1996 03:03:43 CET Date: Mon, 04 Nov 1996 20:42:00 CET From: A.ECKLEDER@CHATEAU.zer.sub.org (Andreas Eckleder) Reply-To: A.ECKLEDER@CHATEAU.zer.sub.org X-Mailer: CrossPoint v3.1 Message-Id: <6KDVD8ENCfB@p-andy.chateau.zer.sub.org> To: gpc@hut.fi Subject: getting dos memory at unit start... Organization: Z-Netz Network Area, Germany X-Gateway: Z-TRANSPARENT UU uzercp.zer.sub.org [UZERCP V4.54], ZCONNECT UU uzercp.zer.sub.org [CONNECT*UZERCP V0.95] Lines: 19 Status: RO Oh nein,eine E-Mail ....von MIR >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<; Tue, 5 Nov 1996 19:33:25 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90104; Tue, 5 Nov 1996 18:37:25 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80776; Tue, 5 Nov 1996 18:36:23 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@[132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id TAA22373 for ; Tue, 5 Nov 1996 19:26:49 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA10586 for gpc@hut.fi; Tue, 5 Nov 1996 19:23:31 +0100 From: Peter Gerwinski Message-Id: <199611051823.TAA10586@agnes.dida.physik.uni-essen.de> Subject: getting dos memory at unit start... To: gpc@hut.fi Date: Tue, 5 Nov 1996 19:23:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Eckleder: > ....i just tried to get some dos memory via dpmi in the unit start block > ( to begin do ) And what happened? > i use a function call to another unit there (linked with import) > which calls the extender function (get dos mem) then. > to specify this a little more: i do NOT want to have a selector (this is > made later),i just want to have some memory allocated for a call-buffer. > is it a problem that i call a function of another unit there?!? It should not be, but please describe more exactly what you tried and what happened. The best thing is to post the smallest extract of your code which still triggers the error. And: Which GPC version are you using? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Nov 11 13:40:01 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA17301 for ; Mon, 11 Nov 1996 13:40:01 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64726; Mon, 11 Nov 1996 12:42:38 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73770; Mon, 11 Nov 1996 12:41:35 +0100 Received: from baghira.han.de (baghira.han.de [192.109.225.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id NAA26825 for ; Mon, 11 Nov 1996 13:32:38 +0200 (EET) Received: from uzercp.zer.sub.org (root@localhost) by baghira.han.de (8.6.12-pb3/04-08-96/09:54:04) with BSMTP id for gpc@hut.fi; Mon, 11 Nov 1996 12:17:13 +0100 Received: by uzercp.zer.sub.org (uzcopy); Mon, 11 Nov 1996 03:14:20 CET Date: Sun, 10 Nov 1996 10:57:00 CET From: A.ECKLEDER@CHATEAU.zer.sub.org (Andreas Eckleder) Reply-To: A.ECKLEDER@CHATEAU.zer.sub.org X-Mailer: CrossPoint v3.1 Message-Id: <6KahrrRsCfB@p-andy.chateau.zer.sub.org> To: gpc@hut.fi Subject: vesa 2.0 linear frame buffer Organization: Z-Netz Network Area, Germany X-Gateway: Z-TRANSPARENT UU uzercp.zer.sub.org [UZERCP V4.54], ZCONNECT UU uzercp.zer.sub.org [CONNECT*UZERCP V0.95] Lines: 18 Status: RO Oh nein,eine E-Mail ....von MIR >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<; Wed, 13 Nov 1996 00:18:11 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76388; Tue, 12 Nov 1996 23:20:28 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51646; Tue, 12 Nov 1996 23:19:13 +0100 Received: from utkux4.utcc.utk.edu (UTKUX4.UTCC.UTK.EDU [128.169.76.11]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id AAA04754 for ; Wed, 13 Nov 1996 00:14:04 +0200 (EET) From: sad@utkux.utcc.utk.edu Received: by utkux4.utcc.utk.edu (SMI-8.6/2.7c-UTK) id WAA17226; Tue, 12 Nov 1996 22:11:03 GMT Message-Id: <199611122211.WAA17226@utkux4.utcc.utk.edu> Subject: [Q] latest g77 and gpc for OS/2 with emx09c ? To: emx@IAEhv.nl (emx-list) Date: Tue, 12 Nov 1996 17:11:01 -0500 (EST) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, I suppose I'll be installing emx09c + XFree soon but I also rely on gpc and g77 on OS/2, which work beautifully with emx09b so far. (Thanks to all the dudes involved, esp. EM, Peter Gerwinski, and Michael Holzapfel!) Now my question -- which and where are the latest, emx09c compiled or at least compatible/approved os/2 versions of g77-0.5.18 and gpc? URL or ftp description with file size/date information would be much appreciated. Anything else I need to know before installing (it'll probably go right on a Warp 4 system)? Cheers. Cheers! Hm, said that already .... Stefan =============================================================================== Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad@utk.edu =============================================================================== From gpc-request@santra.hut.fi Tue Nov 12 18:32:17 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA18682 for ; Tue, 12 Nov 1996 18:32:17 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74876; Tue, 12 Nov 1996 17:34:39 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20310; Tue, 12 Nov 1996 17:33:32 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id SAA11743 for ; Tue, 12 Nov 1996 18:26:24 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA17566 (5.67b/IDA-1.5 for ); Tue, 12 Nov 1996 17:26:21 +0100 Message-Id: <2.2.32.19961112162800.00677218@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 17:28:00 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: urgent: gpc-961112 bad Status: RO Hello, Sorry, somehow a buglet I thought I'd squashed has raised it's ugly head again in gpc-961112. Don't bother downloading -- it won't work. I'll remove it. JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Nov 12 15:58:16 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA18566 for ; Tue, 12 Nov 1996 15:58:15 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84614; Tue, 12 Nov 1996 15:00:40 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17772; Tue, 12 Nov 1996 14:59:09 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id PAA06107 for ; Tue, 12 Nov 1996 15:53:06 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA04533 (5.67b/IDA-1.5 for ); Tue, 12 Nov 1996 14:53:03 +0100 Message-Id: <2.2.32.19961112135441.006890e0@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 14:54:41 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: new GPC/djgpp-v2.01 binaries Status: RO Hello folks, I upgraded my djgpp setup to v2.01 and rebuilt GPC for this setup. This time I checked whether no files are missing from the binary distribution, let me know if you still have problems. FAQ and short installation instructions are included. Everything available at ftp://agnes.dida.physik.uni-essen.de/home/janjaap/djgpp/ I also uploaded a development snapshot of RHIDE which can do stepping, tracing etc. with GPC. PLEASE DO NOT DISTRIBUTE THIS FILE !!!! It's meant to be a demo of things to come, I don't do RHIDE so I can't help you if it doesn't work for you. JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Tue Nov 12 11:24:30 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA18362 for ; Tue, 12 Nov 1996 11:24:30 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86824; Tue, 12 Nov 1996 10:26:59 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67784; Tue, 12 Nov 1996 10:25:54 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id LAA27308 for ; Tue, 12 Nov 1996 11:17:07 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA22590 (5.67b/IDA-1.5 for ); Tue, 12 Nov 1996 10:17:04 +0100 Message-Id: <2.2.32.19961112091841.0068db60@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 10:18:41 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: vesa 2.0 linear frame buffer Status: RO At 10:57 AM 11/10/96 CET, you wrote: >Oh nein,eine E-Mail ....von MIR >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >has anyone tried to use the linear frame buffer provided by vesa 2.0 >drivers in gpc yet ? >i just try and try but cannot access the frame buffer memory located at >0xe0000000 (page fault). >the mode gets initialized correctly and definitely provides this frame >buffer (also switches off access mode via 0xa000 realmodesegment). >i'd be very glad if there were some example sourcecodes out there ;) > I have not tried this, but this topic is discussed frequently in the djgpp newsgroup. I suggest you search the djgpp mailinglist archives at http://www.delorie.com with keywords like "vesa" and "linear" and search game related djgpp links such as: http://www.rt66.com/~brennan/djgpp/ I know http://www.rt66.com/~brennan/djgpp/vbe.zip is a small example source of how to get at VBE 2.0 linear framebuffers, with both near and far pointers. You'll have to convert it to Pascal yourself. The VBE 2.0 spec is online at ftp://ftp.scitechsoft.com/devel/vbe20-11.exe Hope this helps, JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Wed Nov 13 02:29:34 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA19053 for ; Wed, 13 Nov 1996 02:29:34 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67364; Wed, 13 Nov 1996 01:31:49 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73496; Wed, 13 Nov 1996 01:30:46 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@[132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA23384 for ; Wed, 13 Nov 1996 02:25:18 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id CAA19001 for gpc@hut.fi; Wed, 13 Nov 1996 02:23:30 +0100 From: Peter Gerwinski Message-Id: <199611130123.CAA19001@agnes.dida.physik.uni-essen.de> Subject: [Q] latest g77 and gpc for OS/2 with emx09c ? - RE To: gpc@hut.fi Date: Wed, 13 Nov 1996 02:23:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to sad@utkux.utcc.utk.edu: > I suppose I'll be installing emx09c + XFree soon but I also rely on > gpc and g77 on OS/2, which work beautifully with emx09b so far. > (Thanks to all the dudes involved, esp. EM, Peter Gerwinski, and Michael > Holzapfel!) (-: Thank you! :-) > Now my question -- which and where are the latest, emx09c compiled > or at least compatible/approved os/2 versions of g77-0.5.18 and gpc? Try to run the gpc-1.2-2.7.2 pre-release EMX binary, compiled for emx09b, ftp://kampi.hut.fi/jtv/gnu-pascal/gpc-2.7.2/emx/gpcdev.zip, 1059 kB. I will provide an emx09c version soon. > Anything else I need to know before installing (it'll probably go right > on a Warp 4 system)? Cheers. It should install just like the other EMX binary distributions. In case you encounter any problems please let us (gpc@hut.fi) know, because we want to fix all these problems prior to the final 2.7.2 release. (* BTW: Thanks for advertising for GPC in the EMX list. ;*) Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Fri Nov 15 03:12:18 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA21999 for ; Fri, 15 Nov 1996 03:12:17 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85466; Fri, 15 Nov 1996 02:13:51 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA101280; Fri, 15 Nov 1996 02:12:48 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id DAA06454 for ; Fri, 15 Nov 1996 03:06:17 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA10392 (5.67b/IDA-1.5 for ); Fri, 15 Nov 1996 02:06:15 +0100 Message-Id: <2.2.32.19961115010757.006aadf8@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 1996 02:07:57 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: fixed: gpc/djgpp new binaries & source available Status: RO At 05:28 PM 11/12/96 +0100, you wrote: >Hello, > >Sorry, somehow a buglet I thought I'd squashed has raised it's ugly head >again in gpc-961112. Don't bother downloading -- it won't work. I'll remove it. > The new binaries plus source can be downloaded from ftp://agnes.dida.physik.uni-essen.de/home/janjaap/djgpp I included the latest rhide testrelease, which allows stepping, watching etc, this should be a big plus for all of you who are familiar with something called Turbo Pascal :-) Enjoy, janjaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Sat Nov 23 03:58:23 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA01856 for ; Sat, 23 Nov 1996 03:58:22 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA02720; Sat, 23 Nov 1996 02:57:24 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79640; Sat, 23 Nov 1996 02:56:19 +0100 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id DAA29582 for ; Sat, 23 Nov 1996 03:38:10 +0200 (EET) Received: from golden-grahams.ai.mit.edu (golden-grahams.ai.mit.edu [128.52.39.34]) by life.ai.mit.edu (8.8.2/8.8.2AI/life.ai.mit.edu:1.9) with SMTP id UAA00762 for ; Fri, 22 Nov 1996 20:38:00 -0500 (EST) Received: by golden-grahams.ai.mit.edu (8.6.12/AI-4.10) id UAA22609; Fri, 22 Nov 1996 20:37:59 -0500 Date: Fri, 22 Nov 1996 20:37:59 -0500 Message-Id: <199611230137.UAA22609@golden-grahams.ai.mit.edu> From: Bulletin Editor To: gpc@hut.fi Subject: GNU's Bulletin: GNU Pascal news item? Status: RO We could use an item on GNU Pascal for the Forthcoming GNUs column in the next bulletin. Would someone on this list care to write a short piece, or forward this request to someone who could do it? From gpc-request@santra.hut.fi Sat Nov 23 17:19:28 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA02444 for ; Sat, 23 Nov 1996 17:19:28 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63218; Sat, 23 Nov 1996 16:18:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA120950; Sat, 23 Nov 1996 16:17:13 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id RAA01250 for ; Sat, 23 Nov 1996 17:07:57 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA02397; Sat, 23 Nov 1996 17:09:46 +0100 From: Peter Gerwinski Message-Id: <199611231609.RAA02397@agnes.dida.physik.uni-essen.de> Subject: Re: GNU's Bulletin: GNU Pascal news item? To: bull-updates@gnu.ai.mit.edu, gpc@hut.fi Date: Sat, 23 Nov 1996 17:09:46 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Bulletin Editor: > We could use an item on GNU Pascal for the Forthcoming GNUs column in > the next bulletin. Would someone on this list care to write a short > piece, or forward this request to someone who could do it? I am just writing an announcement for the next official release of GNU Pascal (to be released as soon as some administrative stuff is done), so I could write that piece, too. When I have a draft, I will post it to the GPC list, so we can improve it together. Okay? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sun Dec 1 16:03:56 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA18498 for ; Sun, 1 Dec 1996 16:03:55 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90272; Sun, 1 Dec 1996 16:02:05 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45820; Sun, 1 Dec 1996 16:03:21 +0100 Received: from hermes.dur.ac.uk (hermes.dur.ac.uk [129.234.4.9]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id QAA00998 for ; Sun, 1 Dec 1996 16:57:33 +0200 (EET) Received: from gauss.durham.ac.uk by hermes.dur.ac.uk id (8.6.12/ for dur.ac.uk) with SMTP; Sun, 1 Dec 1996 14:57:31 GMT Received: from bayes.durham.ac.uk (bayes.dur) by uk.ac.durham.gauss; Sun, 1 Dec 96 14:57:31 GMT Received: by bayes.durham.ac.uk (SMI-8.6/SMI-SVR4) id OAA02598; Sun, 1 Dec 1996 14:57:31 GMT From: D.A.Wooff@durham.ac.uk (David Wooff) Message-Id: <199612011457.OAA02598@bayes.durham.ac.uk> Subject: getting environment variables To: gpc@hut.fi Date: Sun, 1 Dec 1996 14:57:30 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Greetings, fellow GPC users. Despite trying the solutions suggested in the faq (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/faq.html), I'm no nearer to getting an environment variable successfully into my program. For example, suppose I want to get the PATH environment variable into the program as a string that I can then work on? Can anyone help? I know zero C, and I prefer my pascal as plain as possible; I don't use Borland extensions. By the way - developers thank you. I've used GPC to compile the [B/D] Bayes linear statistics package. It is about 28000 lines of dense (mostly uncommented: shame on me) code, which probably exploits every nook and cranny of the pascal language (e.g. it makes heavy use of height-balanced binary trees using record variants). The same code (after minor translations) also compiles under Borland Pascal, the Berkely unix compiler, and the SUN pascal compiler. We get the same answers for all our test routines, and the graphics implementation (hooking to Tcl/Tk) also works properly. I didn't expect GPC to do it, but (although it took a lot of time rewriting the code to avoid GPC bugs, such as substr) it does work. A linux version of [B/D] will be released as soon as I can get getenv() to work! David. From gpc-request@santra.hut.fi Sun Dec 1 17:41:44 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA18893 for ; Sun, 1 Dec 1996 17:41:44 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85488; Sun, 1 Dec 1996 17:39:53 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41346; Sun, 1 Dec 1996 17:41:10 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@[132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id SAA01795 for ; Sun, 1 Dec 1996 18:36:49 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA18861; Sun, 1 Dec 1996 17:37:08 +0100 From: Peter Gerwinski Message-Id: <199612011637.RAA18861@agnes.dida.physik.uni-essen.de> Subject: Re: getting environment variables To: d.a.wooff@durham.ac.uk, gpc@hut.fi Date: Sun, 1 Dec 1996 17:37:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to David Wooff: > Greetings, fellow GPC users. Despite trying the solutions suggested in the > faq (http://agnes.dida.physik.uni-essen.de/~gnu-pascal/faq.html), I'm no > nearer to getting an environment variable successfully into my program. > For example, suppose I want to get the PATH environment variable into > the program as a string that I can then work on? That's strange. When I try the program `EnvDemo' from the FAQ, it works fine on my Linux box. (The code I used is appended below just to make sure that we are speaking about the same program.) I suggest the following strategy to hunt the bug: * Control all intermediate results, e.g. p^ in StrPCopy and Src^ in StrPas. * Use the C `puts' output routine to check C strings: Procedure Puts ( S: CString ); C; ... Puts ( pName ); Puts ( GetEnv ( pName ) ); BTW, thanks a lot for the GPC success story. Things like this encourage us to go on and fix the remaining bugs (e.g. `substr'). :-) :-) Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ 8< ---------------------------------------------------------------------------- Program EnvDemo; type word = __unsigned__ integer; TString = string(256); { Pascal string schema } CString = __cstring__; { C style string } { Convert a "C" string to a "Pascal" string } function StrPas(Src: CString): TString; var S : TString; begin S := ''; if (Src <> NIL) then while ( (Src^ <> chr(0)) AND (length(S) < S.capacity)) do begin S := S + Src^; inc(Word(Src)); end; StrPas := S; end; { Convert a "Pascal" string to a "C" string } function StrPCopy(Dest: CString; Src: String): CString; var c: integer; p : CString; begin p := Dest; for c:=1 to length(Src) do begin p^ := Src[c]; inc(word(p)); end; p^ := chr(0); StrPCopy := Dest; end; { C library function prototype: char *getenv(const char *name); } function GetEnv(name : CString): CString; C; var pName: CString; begin getmem(pName, 256); pName := StrPCopy(pName, 'PATH'); writeln('Your PATH is: ', StrPas(GetEnv(pName))); freemem(pName, 256); end. From gpc-request@santra.hut.fi Wed Dec 4 20:40:00 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA22807 for ; Wed, 4 Dec 1996 20:40:00 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82190; Wed, 4 Dec 1996 20:36:58 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99260; Wed, 4 Dec 1996 20:38:06 +0100 Received: from kampi.hut.fi (kampi.hut.fi [130.233.224.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id VAA11108 for ; Wed, 4 Dec 1996 21:31:21 +0200 (EET) Received: from goole.octacon.co.uk ([193.118.80.1]) by kampi.hut.fi (8.6.11/8.6.7) with ESMTP id VAA10322 for ; Wed, 4 Dec 1996 21:31:13 +0200 Received: from r03-47.octacon.co.uk (r03-47.octacon.co.uk [194.176.64.112]) by goole.octacon.co.uk (8.6.9/8.6.9) with SMTP id TAA13058 for ; Wed, 4 Dec 1996 19:30:42 GMT Message-Id: <199612041930.TAA13058@goole.octacon.co.uk> Comments: Authenticated sender is From: "Spansh" Organization: Spansh Productions (Ltd) To: gpc@kampi.hut.fi Date: Sat, 3 Feb 1996 19:21:09 +0000 Subject: I have a small Problem with GPC Reply-To: Gareth.Harper@Onyxnet.Co.Uk Priority: normal X-Mailer: Pegasus Mail for Windows (v2.10) Status: RO Well after being advised to download GPC as a 32bit compiler I tired I have in the last few days Downloaded these files GPC-1_1-.TAR.GZIP These had i486 somewhere I have three different versions of this file. GPC112b.ZIP This was 730k and does not seem to want to compile any of my programs giving me an error after the first line in my program. (parse error Ithink) GPC272b.ZIP a 1.0Mbyte file that I had to download twice as one of the files I downloaded was a bad zip (It was from Sunsite.Doc.Ic.AC.UK) and This gives me quite a few errors if I compile with the -c option. It says nothing just accesses the disk a lot If I use no options. Do I need any other files to be able to use GPC. I own a Pentium 60Mhzwith 8Mb ram. I currently use Turbo Pascal Verion 6.00. Could you help me out please. If it gave me errors about sytnax then I would be ok. But it does not like the type 'Word' I have a variable called Lookup which is an array of Word along with a few other variables that are words. I assume this is something I am doing wrong as Word is a basic type I would have thought. I even tried changing them to SWord (Single Word) and That did not help. I seem to remember reading somewhere that I need GCC to be able to compile with this. Is this true and Which version do I need. Thanks for any help you could give me. I hope that you can help as I would like to have a full 32bit compiler. Gareth Harper AKA $ P @ /\/ $ ]-[ ------------------------ Tel - 01642 550854 E-Mail - Gareth.Harper@Onyxnet.CO.UK Write - 16 Ganton Close, Billingham, Cleveland, TS22 5RE From gpc-request@santra.hut.fi Wed Dec 4 22:01:21 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA22943 for ; Wed, 4 Dec 1996 22:01:20 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86348; Wed, 4 Dec 1996 21:58:19 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA782468; Wed, 4 Dec 1996 21:59:33 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@[132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id WAA12514 for ; Wed, 4 Dec 1996 22:53:56 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA22912; Wed, 4 Dec 1996 21:53:26 +0100 From: Peter Gerwinski Message-Id: <199612042053.VAA22912@agnes.dida.physik.uni-essen.de> Subject: Re: I have a small Problem with GPC To: gareth.harper@onyxnet.co.uk, gpc@hut.fi Date: Wed, 4 Dec 1996 21:53:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Gareth Harper! > GPC112b.ZIP This was 730k and does not seem to want to compile any of > my programs giving me an error after the first line in my program. > (parse error Ithink) GPC112b.ZIP is a 1.1 (2.6.3) version without any Borland compatible extensions. Your program is probably correct for Turbo Pascal 6.0, but that version of GNU Pascal is a pure ISO Pascal compiler. The 1.1 (2.6.3) version *with* Borland extensions is in TURBO11b.ZIP. > GPC272b.ZIP a 1.0Mbyte file that I had to download twice as one of > the files I downloaded was a bad zip (It was from > Sunsite.Doc.Ic.AC.UK) and This gives me quite a few errors if I > compile with the -c option. It says nothing just accesses the disk a > lot If I use no options. That's interesting because GPC272b.ZIP is a *beta* version 1.2 (2.7.2) of GNU Pascal which should not be mirrored at Sunsite ... however I find it acutally more stable than GPC 1.1 (2.6.3), so it is indeed the best choice for you. ;-) > Do I need any other files to be able to use GPC. I own a Pentium > 60Mhzwith 8Mb ram. You need at least the GNU assembler and linker ... please look into the GNU Pascal FAQ http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc-faq.html for more about the DJGPP version of GNU Pascal. > I currently use Turbo Pascal Verion 6.00. Could > you help me out please. If it gave me errors about sytnax then I > would be ok. But it does not like the type 'Word' GNU Pascal is only partially Borland compatible and is *not* a drop-in replacement for Turbo (Borland) Pascal. Differences between Borland and GNU Pascal are documented in the section "From Borland Pascal to GNU Pascal" in the documentation, http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc-doc.html . Especially, GNU Pascal doesn't know `Word'. Try the following: Type (* Integer has 4 Bytes *) Word = __unsigned__ Integer; (* 4 Bytes *) ShortInt = __short__ Integer; (* 2 Bytes *) ShortWord = __unsigned__ ShortInt; (* 2 Bytes *) ByteInt = __byte__ Integer; (* 1 Byte *) Byte = __unsigned__ ByteInt; (* 1 Byte *) > [...] > > I seem to remember reading somewhere that I need GCC to be able to > compile with this. This is not the case. See the FAQ for details. Hope this helps, Peter From gpc-request@santra.hut.fi Thu Dec 12 01:14:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf1.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA01841 for ; Thu, 12 Dec 1996 01:14:55 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76290; Thu, 12 Dec 1996 00:55:56 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA530142; Thu, 12 Dec 1996 01:10:52 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@[132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA32008 for ; Thu, 12 Dec 1996 02:05:29 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA01691 for gpc@hut.fi; Thu, 12 Dec 1996 01:09:19 +0100 From: Peter Gerwinski Message-Id: <199612120009.BAA01691@agnes.dida.physik.uni-essen.de> Subject: Final prepares releasing GNU Pascal 2.0. Please check. To: gpc@hut.fi Date: Thu, 12 Dec 1996 01:09:18 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! We are now ready to release an improved version of what you know as gpc-1.2-2.7.2 as a new official version, GNU Pascal 2.0. The announcement below will go to the NewsGroups tomorrow or so. I am now setting up the directory tree on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ Please imagine it were ftp://kampi.hut.fi/jtv/gnu-pascal/ and check whether everything is set up correctly. The directory tree will be copied to kampi.hut.fi together with the announcement going to the NewsGroups. There is also a new home page which will replace the current one. You can check it now at http://agnes.dida.physik.uni-essen.de/~gnu-pascal/new/ :-) , Peter 8< --------------------------------------------------------------------------- Subject: ANNOUNCE: GNU Pascal 2.0 (2.7.2.1) Newsgroups: comp.lang.pascal.misc, comp.lang.pascal.borland, comp.lang.pascal.ansi-iso, comp.os.msdos.djgpp, gnu.announce, gnu.gcc.announce Followup-To: comp.lang.pascal.misc Summary: GNU Pascal version 2.0 (GCC 2.7.2.1) now available Keywords: GNU,Pascal,Free Software,FreeWare This is the announcement of version 2.0 of GNU Pascal corresponding to GCC version 2.7.2.1. What is GNU Pascal? =================== GNU Pascal is, as the name says, the Pascal compiler from the GNU compiler family. This means: - 32 bit compiler, no limits, highly optimizing, - runs on all operating systems supported by GCC (including DOS, Win95/NT, OS/2, Linux, FreeBSD, many other Unix dialects), - Free Software according to the GNU General Public License, - compatible to other GNU languages and tools such as GNU C and the GNU debugger. The compiler integrates the following language standards: - ISO 7185 Standard Pascal, - ISO 10206 Extended Pascal (90% implemented), - Borland Pascal (80% compatible). Some highlights: - From Extended Pascal: complex numbers, initialized variables, structured function return values, modules, - from Borland Pascal: inc, dec, shl, shr, absolute variables, units, objects, - GNU extensions: min, max, (PXSC-style) user-definable operators. Disadvantages: - Pascal support in integrated development environments (RHIDE for DOS/DJGPP, (X)WPE for Unix) is still beta, - the GNU debugger (gdb) does not yet understand Pascal syntax and types, - few standard libraries (can use C standard libraries instead), - longer compilation times than with e.g. Borland Pascal. New features in version 2.0 =========================== - Borland extensions are integrated into the main distribution line. - Easier to compile. - Texinfo online documentation (available as HTML, too). - Precompiled Module/Unit interfaces. - Automatic `make' facility. - Some bugs fixed. "Export foo = all" extension. Machine attributes. Etc. Where to obtain GNU Pascal ========================== The master ftp site for GNU Pascal is kampi.hut.fi. The source of the compiler, binary distributions for certain platforms and other GNU Pascal related files can be found in ftp://kampi.hut.fi/jtv/gnu-pascal/ . This site is mirrored on ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ . Other sources of information ============================ More about GNU Pascal can be found in our WWW home page, http://home.pages.de/~GNU-Pascal/ . If you have problems to access this, try http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ . That page contains the GNU Pascal FAQ list and an online version of the complete documentation. If you have questions or want to discuss about GNU Pascal, please join the GNU Pascal mailing list by writing to gpc-request@hut.fi . The address of the list itself is gpc@hut.fi . -------- Follow-ups will be directed to comp.lang.pascal.misc. Enjoy, The GNU Pascal Development Team Jukka Virtanen Peter Gerwinski Jan-Jaap van der Heijden From gpc-request@santra.hut.fi Fri Dec 13 01:19:55 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA04875 for ; Fri, 13 Dec 1996 01:19:55 +0100 Received: from aixrs1.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83074; Fri, 13 Dec 1996 01:16:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA775556; Fri, 13 Dec 1996 01:15:39 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA07987 for ; Fri, 13 Dec 1996 02:07:58 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA04823 for gpc@hut.fi; Fri, 13 Dec 1996 01:12:03 +0100 From: Peter Gerwinski Message-Id: <199612130012.BAA04823@agnes.dida.physik.uni-essen.de> Subject: GNU Pascal 2.0 is released To: gpc@hut.fi Date: Fri, 13 Dec 1996 01:12:02 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! GNU Pascal 2.0 is released. The source and binaries are both on kampi.hut.fi and on agnes.dida.physik.uni-essen.de. On agnes we will provide experimental versions in `beta' and `alpha' subdirectories in addition to the "official" version, that's the only difference between the stuff on both sites. The announcement will appear in the NewsGroups, soon. Enjoy, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Dec 16 03:06:19 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA10694 for ; Mon, 16 Dec 1996 03:06:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78124; Mon, 16 Dec 1996 03:01:41 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49568; Mon, 16 Dec 1996 03:01:05 +0100 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id DAA08742 for ; Mon, 16 Dec 1996 03:58:29 +0200 (EET) Received: (from gnats@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id SAA27050; Sun, 15 Dec 1996 18:00:01 -0800 Date: Sun, 15 Dec 1996 18:00:01 -0800 Message-Id: <199612160200.SAA27050@fawn.cs.wwu.edu> From: sven@sik.de Reply-To: sven@sik.de To: peter@agnes.dida.physik.uni-essen.de Cc: gnats@fawn.cs.wwu.edu, phil@cs.wwu.edu, gpc@hut.fi Subject: gpc/14: "Restricted" keyword causes fatal signal 11 Status: RO >Number: 14 >Category: gpc >Synopsis: "Restricted" keyword causes fatal signal 11 >Confidential: no >Severity: serious >Priority: medium >Responsible: peter (Peter Gerwinski) >State: open >Class: sw-bug >Submitter-Id: www >Arrival-Date: Sun Dec 15 18:00:01 1996 >Originator: Sven Engelhardt >Organization: SIK Dresden >Release: gpc-2.0-linux-i486-elf >Environment: Linux-2.0.27-Elf >Description: Compiler exits with "internal compiler error: program gpc1 got fatal signal 11" >How-To-Repeat: unit t1; interface type ty=restricted integer; var t:ty; implementation end. >Fix: >Audit-Trail: >Unformatted: From gpc-request@santra.hut.fi Mon Dec 16 02:58:59 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA10682 for ; Mon, 16 Dec 1996 02:58:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75466; Mon, 16 Dec 1996 02:54:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59540; Mon, 16 Dec 1996 02:53:46 +0100 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id DAA08556 for ; Mon, 16 Dec 1996 03:48:48 +0200 (EET) Received: (from gnats@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id RAA27024; Sun, 15 Dec 1996 17:50:02 -0800 Date: Sun, 15 Dec 1996 17:50:02 -0800 Message-Id: <199612160150.RAA27024@fawn.cs.wwu.edu> From: sven@sik.de Reply-To: sven@sik.de To: peter@agnes.dida.physik.uni-essen.de Cc: gnats@fawn.cs.wwu.edu, phil@cs.wwu.edu, gpc@hut.fi Subject: gpc/13: Exporting timestamp - Timestamp record parameter required Status: RO >Number: 13 >Category: gpc >Synopsis: Exporting timestamp - Timestamp record parameter required >Confidential: no >Severity: serious >Priority: medium >Responsible: peter (Peter Gerwinski) >State: open >Class: sw-bug >Submitter-Id: www >Arrival-Date: Sun Dec 15 17:50:00 1996 >Originator: Sven Engelhardt >Organization: SIK Dresden >Release: 2.0-linux-i486-elf >Environment: Linux 2.0.27 >Description: Any kind of timestamp-variable/-parameter can't be exported from a unit. Compiler always gives a message: "Timestamp record parameter required" >How-To-Repeat: unit t1; interface var t:timestamp; implementation end. {--------------------------------------------} program t2(input,output); uses t1; begin writeln(date(t)); end. >Fix: workaraound: define a new timestamp-type eg. ttimestamp, then define new functions bug_date, bug_time, bug_gettimestamp using an absolute variable conversion eg. type ttimestamp=timestamp; function bug_date(tt:ttimestamp):TString; var t:timestamp absolute tt; begin bug_date:=date(t); end; >Audit-Trail: >Unformatted: From gpc-request@santra.hut.fi Wed Dec 18 11:22:18 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA17451 for ; Wed, 18 Dec 1996 11:22:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73244; Wed, 18 Dec 1996 11:17:02 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55722; Wed, 18 Dec 1996 11:16:22 +0100 Received: from mail.math.TU-Berlin.DE (mail.math.TU-Berlin.DE [130.149.12.212]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id LAA15730 for ; Wed, 18 Dec 1996 11:57:21 +0200 (EET) Received: from euler (euler.math.TU-Berlin.DE) by mail.math.TU-Berlin.DE with SMTP id AA27522 (5.67b8/IDA-1.5 for ); Wed, 18 Dec 1996 10:57:20 +0100 Received: by euler id AA04062 (5.67b8/IDA-1.5 for gpc@hut.fi); Wed, 18 Dec 1996 10:57:18 +0100 From: Utz-Uwe Haus Message-Id: <199612180957.AA04062@euler> Subject: gpc v2: works on Sony newsos To: gpc@hut.fi Date: Wed, 18 Dec 1996 10:57:18 +0100 (NFT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, --- just to give a positive status report: gpc compiled without problems on a m68k-sony-newos machine. I only ran a few checks from the test/ dir, but those were okay. The compile for mips-sony-newsos is currently running. Is there any place where I can find the testsuite that is references in one of the docs? Keep up the good work, Utz From gpc-request@santra.hut.fi Wed Dec 18 10:18:33 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA17285 for ; Wed, 18 Dec 1996 10:18:32 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83846; Wed, 18 Dec 1996 10:13:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56904; Wed, 18 Dec 1996 10:12:39 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id KAA14369 for ; Wed, 18 Dec 1996 10:58:37 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA02274 (5.67b/IDA-1.5 for ); Wed, 18 Dec 1996 09:58:35 +0100 Message-Id: <2.2.32.19961218090047.00690b18@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Dec 1996 10:00:47 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: ANNOUNCE: GNU Pascal 2.0 (2.7.2.1) Status: RO >Return-Path: >Date: Tue, 17 Dec 1996 22:30:13 -0800 (PST) >To: J.J.vanderHeijden@student.utwente.nl >Newsgroups: comp.lang.pascal.misc,comp.lang.pascal.borland,comp.lang.pascal.ansi-iso,gnu .gcc.announce >Subject: Re: ANNOUNCE: GNU Pascal 2.0 (2.7.2.1) >From: samiam@pacbell.net (Scott A. Moore) >X-Newsreader: WinVN 0.99.2 >Distribution: world >Keywords: GNU,Pascal,Free Software,FreeWare >References: > >In article , J.J.vanderHeijden@student.utwente.nl says... >> >> This is the announcement of version 2.0 of >> >> GNU Pascal >> >> corresponding to GCC version 2.7.2.1. >> >> >> What is GNU Pascal? >> =================== >> >> GNU Pascal is, as the name says, the Pascal compiler from the >> GNU compiler family. This means: >> >> - 32 bit compiler, no limits, highly optimizing, >> - runs on all operating systems supported by GCC (including DOS, >> Win95/NT, OS/2, Linux, FreeBSD, many other Unix dialects), >> - Free Software according to the GNU General Public License, >> - compatible to other GNU languages and tools such as >> GNU C and the GNU debugger. >> >> The compiler integrates the following language standards: >> >> - ISO 7185 Standard Pascal, >> - ISO 10206 Extended Pascal (90% implemented), >> - Borland Pascal (80% compatible). > >I know this is going to start something of a fight, but when I last checked, >this compiler did not in fact comply with ISO 7185 (the original Pascal >standard). I know that you folks put a lot of free time into this compiler, >and that is appreciated, but I also believe that it hurts everyone and >undermines the standard to falsely claim compliance with it. > >To me, the difficulty lies in the fact that there are no real compliance >tests for standard Pascal. The BSO had a PAID one, but the problem with that >is that to validate a compiler maker's claim to obey that standard required >a >$1000 investment, hardly within the means of the average user. The only >other way such a test can work is if the originators would have taken >issue with false claims of compliance. The BSO didn't do that, and to this >day at least one "standard" pascal is shipped and advertised falsely >claiming to have passed it (Microway). > >For the obvious question, yes, I have pointed out the standards compliance >difficulties to the originators of GCC Pascal, and offered to spend my >time free of charge to help find compliance problems with the compiler >(and I still do). > >What say we get this compiler the final few steps to meet the minimum >standard, or stop claiming that it is standard. Obviously I prefer the >former. Otherwise, when the above statement (IMHO false) is published, >I feel it is my duty to provide equally public opposition. > > [sam] > > -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Fri Dec 20 01:04:08 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA20463 for ; Fri, 20 Dec 1996 01:04:07 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68700; Fri, 20 Dec 1996 00:57:25 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95386; Fri, 20 Dec 1996 00:57:43 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id BAA00692 for ; Fri, 20 Dec 1996 01:52:37 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 20 Dec 96 00:52 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vasCK-000krTC; Fri, 20 Dec 96 00:48 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 20 Dec 1996 00:43:36 +0200 Date: 20 Dec 1996 00:43:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6NCR7zRklJB@rufus.central.de> Subject: BGI2GRX - README.TXT X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO BGI2GRX ======= BGI2GRX is based on GRX and BCC2GRX and only runs by using these libraries. Pay attention to the authors copyrights. BCC2GRX is an interface library for GCC written by Helmut Schirmer which allows to access the GRX20 library by using Borland's BGI syntax. GRX20 is a useful collection of graphics functions written by Csaba A. Biegl. With BGI2GRX I give GPC users access to those functions with Gnu PASCAL. BGI2GRX was tested with: GPC 2.0 (DJGPP), GRX 2.0 (dated 04/96) and BCC2GRX 2.0 (dated 10/96) in plain DOS and in the Win 95 DOS box. GRX20 and BCC2GRX are made to compile under LINUX so I assume that BGI2GRX should compile and run flawlessly on a Linux box but haven't tested it yet. !!! CAUTION !!! --------------- For displaying text in graphics mode BCC2GRX requires you to set an environment variable "GRXFONT" which points to the path where GRX fonts are installed in. You have to set the environment variable "GRX20DRV" to use different graphics drivers. For details read the GRX documentation. I only ran GRX programs on VESA compatible graphics cards and they worked without "GRX20DRV". The graphics functions which use fill style and/or line style settings only work with their default settings. This is because the required functionality is not yet available in GRX 2.0. You can set different settings but these are simply ignored. Authors and sources of suply of GRX20 and BCC2GRX ------------------------------------------------- GRX20 : csaba@vuse.vanderbildt.edu (Csaba A. Biegl) ftp://ftp.simtel.net/pub/gnu/djgpp/ BCC2GRX : hsc@techfak.uni-kiel.de (Hartmut Schirmer) ftp://ftp.simtel.net/pub/gnu/djgpp/ http://www.techfak.uni-kiel.de/~hsc/BCC2GRX/ The demos --------- All demos (except Colors.pas) were tested with GPC as well as with Borland Pascal. Noticable are the speed differences (especially with 8 bit color depth) and the good compatibility (except FillStyle and LineStyle). I noticed that some "special" BGI drivers (e.g. VESA.BGI) swap AndPut and OrPut functionality when using PutImage. History ------- 12/96 - first release Future plans ------------ - same unit for DOS (DJGPP) and Linux (SVGALIB, X) - improve compatibility Thanks to: ---------- Hartmut Schirmer and Csaba Biegl for their help Peter Gerwinski for his patience and his short-term changes to GPC Ralf Meyer for his help on the readme translation Have fun with GPC, GRX, BCC2GRX and BGI2GRX !!! Sven Hilscher mailto: sven@rufus.central.de Any feedback is welcome (criticism, suggestions, assistance). From gpc-request@santra.hut.fi Fri Dec 20 01:04:03 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (sp2nfs.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA20459 for ; Fri, 20 Dec 1996 01:04:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69206; Fri, 20 Dec 1996 00:57:20 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80788; Fri, 20 Dec 1996 00:57:38 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id BAA00247 for ; Fri, 20 Dec 1996 01:52:34 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 20 Dec 96 00:52 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vasCK-000krRC; Fri, 20 Dec 96 00:48 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 20 Dec 1996 00:43:36 +0200 Date: 20 Dec 1996 00:43:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6NCR7jhklJB@rufus.central.de> In-Reply-To: <199612130012.BAA04823@agnes.dida.physik.uni-essen.de> Subject: Re: GNU Pascal 2.0 is released X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Look at my Christmas present for the gpc users: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bgi2grx.zip ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Sun Dec 22 20:55:52 1996 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25936 for ; Sun, 22 Dec 1996 20:55:51 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70540; Sun, 22 Dec 1996 20:48:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79360; Sun, 22 Dec 1996 20:48:35 +0100 Received: from golden.net (root@golden.org [199.166.210.2]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id VAA12670 for ; Sun, 22 Dec 1996 21:42:07 +0200 (EET) Received: from lizard (cisco3-161.golden.net [207.6.168.161]) by golden.net (8.8.2/8.6.12) with SMTP id OAA22925 for ; Sun, 22 Dec 1996 14:42:04 -0500 (EST) Message-Id: <32BDC896.701B@golden.net> Date: Sun, 22 Dec 1996 15:47:34 -0800 From: Vern McCrae Reply-To: vmst@golden.net Organization: VMS Technologfy Inc. X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: e-mail address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Vern McCrae I didn't understand your question or why the e-mail address was not provided when I logged onto your site. Here it is anyway. Vern McCrae VMS Technology Inc. Canada vmst@golden.net From gpc-request@santra.hut.fi Wed Jan 1 23:47:47 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA07174 for ; Wed, 1 Jan 1997 23:47:46 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA09436; Wed, 1 Jan 1997 23:36:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86434; Wed, 1 Jan 1997 23:36:50 +0100 Received: from venus.star.net (root@venus.star.net [199.232.114.5]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id AAA08933 for ; Thu, 2 Jan 1997 00:30:12 +0200 (EET) Received: from bev230p.star.net (bev230p.star.net [199.232.117.230]) by venus.star.net (8.7.6/8.7.3) with SMTP id RAA10076 for ; Wed, 1 Jan 1997 17:30:08 -0500 Date: Wed, 1 Jan 1997 17:30:08 -0500 Message-Id: <199701012230.RAA10076@venus.star.net> X-Sender: brin@star.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gpc@hut.fi From: Brin Subject: A couple quick questions: Books, Accessing memory and Ports Status: RO Hello everyone, Happy New Year. I realize this is a very stupid question and that it should be painfully obvious, but I cannot seem to find the answer. Basically, I recently started programming in the DJGPP enviornment and have been able to do alot the of the basic stuff, I am very familiar with Turbo Pascal. Unfortunentally, I am not familiar with the other languages that the comipler is based on (ansi, enhanced etc.) and was wondering if there are any good books/docs etc on the subject. Also, I have been trying to find out about how to write, say a byte, directly to memory or to read a byte directly from memory. ie var P : ^void; begin GetMem(P, The_Space_I_Need); . . . end. Now how do I read the and write to the memory I have allocated. In Turbo Pascal, i could use the mem[segment:offset] array, but that is not available in GNU Pascal... I also wish to be able to read and write to ports, of the material I have found, I know that the port[] array that was in Turbo Pascal is also no longer available. What can I do in its place (ie writing to SB registers and to the Palette registers) Any help on any of the above problems would be of a huge help! Thanks in advance -Brin ******************************************************************************** Brin's Humor List SUBSCRIBE!: If you're not on then get signed up! >>>>>Send an EMail to: brin@star.net<<<<< leaving the body with lots of funny comments and where you heard about us and Subscribe in the Subject. DISTRIBUTE!: Send this to all your friends, enemies, and to someone very special who you havn't seen in a long time COME AND SEE:The archives http://www.star.net/people/~brin CONTRIBUTE!: Send me funny stuff. DISCLAIMER: Please read the disclaimer at: http://www.star.net/people/~Brin/Humor/disclaim.htm **************************************************************************** From gpc-request@santra.hut.fi Fri Jan 3 01:31:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA08424 for ; Fri, 3 Jan 1997 01:31:09 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA03232; Fri, 3 Jan 1997 01:19:15 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39800; Fri, 3 Jan 1997 01:19:53 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA31203 for ; Fri, 3 Jan 1997 02:01:48 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA08435 (5.67b/IDA-1.5 for ); Fri, 3 Jan 1997 01:01:45 +0100 Message-Id: <2.2.32.19970103000415.006af0cc@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 1997 01:04:15 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: A couple quick questions: Books, Accessing memory and Ports Status: RO At 05:30 PM 1/1/97 -0500, you wrote: >Hello everyone, >Happy New Year. Greetings and best wishes from me too. I realize this is a very stupid question and that it should >be painfully obvious, but I cannot seem to find the answer. Basically, I >recently started programming in the DJGPP enviornment and have been able to >do alot the of the basic stuff, I am very familiar with Turbo Pascal. >Unfortunentally, I am not familiar with the other languages that the >comipler is based on (ansi, enhanced etc.) and was wondering if there are >any good books/docs etc on the subject. > >Also, I have been trying to find out about how to write, say a byte, >directly to memory or to read a byte directly from memory. > >ie > >var > P : ^void; > >begin > GetMem(P, The_Space_I_Need); > . > . > . >end. > > > Now how do I read the and write to the memory I have allocated. In Turbo >Pascal, i could use the mem[segment:offset] array, but that is not available >in GNU Pascal... > Ah -- you probably mean physical memory access. This is not easy to accomplish, because of the DPMI trickery required to do such things. That's not GPC's fault, it's just as hard to do in djgpp. Give me some time to hack some code together. >I also wish to be able to read and write to ports, of the material I have >found, I know that the port[] array that was in Turbo Pascal is also no >longer available. What can I do in its place (ie writing to SB registers >and to the Palette registers) A port[] array would meaningless outside the PC world, so it's not part of the ANSI standards and GPC. But djgpp's C library provides simular functionality with the inportb() and outportb() functions. These (and more) are defined in Consider this little program which accesses the PC's realtime clock via port $70 and $71. ============================================================================ program RTC; type byte = __byte__ integer; short = __short__ integer; ushort = __unsigned__ short; const RTCAdrPort = $70; RTCDtaPort = $71; Seconds = $00; Minutes = $02; Hours = $04; Day = $07; Month = $08; Year = $09; HundredYear = $32; StatusA = $0A; StatusB = $0B; StatusC = $0C; StatusD = $0D; Diagnose = $0E; { Declared in djgpp's C library, see } function inportb(port: ushort): byte; external; C; procedure outportb(port: ushort; data: ushort); external; C; { Read a value from an RTC register } function RTCRead(address: ushort): byte; begin outportb(RTCAdrPort, address); { pass RTC address } RTCRead := inportb(RTCDtaPort); { read value } end; { Write a value to an RTC register } procedure RTCWrite(address: ushort; content: byte); begin outportb(RTCAdrPort, address); { pass RTC address } outportb(RTCDtaPort, content); { write new value } end; { Read a BCD date/time memory location from RTC and convert it to binary } function RTCDT(address: ushort): byte; var value: byte; begin if (RTCRead(StatusB) and 2 = 0) { BCD or binary mode ? } then RTCDT := RTCRead(address) else begin value := RTCRead(address); RTCDT := ((value shr 4) and $0F) * 10 + (value and $0F); end; end; begin writeln('Information from the battery operated realtime clock'); writeln('----------------------------------------------------'); if RTCRead(Diagnose) and 128 = 0 then begin writeln('The clock is in ', ((RTCRead(StatusB) and 2)*6+12):2, ' hour mode'); writeln('Current time: ', RTCDT(Hours):2, ':', RTCDT(Minutes):2, ':', RTCDT(Seconds):2); writeln('Today is: ', RTCDT(Day):2, '/', RTCDT(Month):2, '/', RTCDT(HundredYear):2, RTCDT(Year):2); end else writeln(' CMOS battery dead!'); end. ============================================================================ In Turbo Pascal, RTCRead() would have been: function RTCRead(address: ushort): byte; begin Port[RTCAdrPort] := address; RTCRead := Port[RTCDtaPort]; end; > >Any help on any of the above problems would be of a huge help! > If you want to do sound programming, you may want to get the Allegro library for djgpp. Then, rewrite Allegro's C header file for GPC and you're done. That way, you don't have to program the hardware directly. JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Sun Jan 12 02:20:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA27238 for ; Sun, 12 Jan 1997 02:20:35 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70458; Sun, 12 Jan 1997 02:06:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46592; Sun, 12 Jan 1997 02:06:28 +0100 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA01166 for ; Sun, 12 Jan 1997 02:58:25 +0200 (EET) Received: (from gnats@localhost) by fawn.cs.wwu.edu (8.6.10/8.6.10) id RAA26047; Sat, 11 Jan 1997 17:00:01 -0800 Date: Sat, 11 Jan 1997 17:00:01 -0800 Message-Id: <199701120100.RAA26047@fawn.cs.wwu.edu> From: axel@moore3.cchem.berkeley.edu Reply-To: axel@moore3.cchem.berkeley.edu To: peter@agnes.dida.physik.uni-essen.de Cc: gnats@fawn.cs.wwu.edu, phil@cs.wwu.edu, gpc@hut.fi Subject: gpc/15: Emulation of Borland Pascal 'Assign' procedure does not work in separate unit Status: RO >Number: 15 >Category: gpc >Synopsis: Emulation of Borland Pascal 'Assign' procedure does not work in separate unit >Confidential: no >Severity: serious >Priority: medium >Responsible: peter (Peter Gerwinski) >State: open >Class: sw-bug >Submitter-Id: www >Arrival-Date: Sat Jan 11 17:00:00 1997 >Originator: Axel Mellinger >Organization: UC Berkeley >Release: 2.0(2.7.2.1) >Environment: Linux 2.0.20 >Description: Emulation of the Borland Pascal 'Assign' procedure (as suggested in the gpc.info) does not work if the 'Assign' procedure is put into a separate unit. Execution of the program 'test.pas' (see below) results in the error message %Gpc: Could't open bound file. Doing `unbind(F)' and a file named '\264\316\b@\264\316\b@\020' is created instead of 'test.dat'. >How-To-Repeat: (* begin 'test.pas' *) (* compile with 'gpc -o test --automake test.pas' *) program test; uses borland; var f: text; begin assign(f, 'test.dat'); rewrite(f); writeln(f, 'Success.'); close(f); end. (* end 'test.pas' *) (* begin 'borland.pas' - this goes into a separate file *) unit borland; INTERFACE procedure Assign(var t: text; protected Name: string); IMPLEMENTATION procedure Assign(var t: text; protected Name: string); var b: BindingType; begin unbind(t); b := binding(t); b.Name := Name; bind(t, b); b := binding(t); end; end. (* end 'borland.pas' *) >Fix: Above example works fine when the 'Assign' procedure is put into the main program instead of a separate unit. >Audit-Trail: >Unformatted: From gpc-request@santra.hut.fi Sun Jan 12 12:08:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA28340 for ; Sun, 12 Jan 1997 12:08:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73890; Sun, 12 Jan 1997 11:53:55 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41418; Sun, 12 Jan 1997 11:54:03 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id MAA03812 for ; Sun, 12 Jan 1997 12:49:44 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id MAA28324; Sun, 12 Jan 1997 12:03:47 +0100 From: Peter Gerwinski Message-Id: <199701121103.MAA28324@agnes.dida.physik.uni-essen.de> Subject: Re: gpc/15: Emulation of Borland Pascal 'Assign' procedure does not work in separate unit To: axel@moore3.cchem.berkeley.edu, gpc@hut.fi Date: Sun, 12 Jan 1997 12:03:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Axel! > Emulation of the Borland Pascal 'Assign' procedure (as suggested in > the gpc.info) does not work if the 'Assign' procedure is put into a > separate unit. The problem is that String types without specified length do not (yet!;-) survive the transport through a GPI file. Workaround: Use Strings with specified length: > (* begin 'borland.pas' - this goes into a separate file *) > unit borland; > > INTERFACE type mystring = string (255); procedure Assign(var t: text; protected Name: mystring); > IMPLEMENTATION procedure Assign(var t: text; protected Name: mystring); > var > b: BindingType; > begin > unbind(t); > b := binding(t); > b.Name := Name; > bind(t, b); > b := binding(t); > end; > > end. > (* end 'borland.pas' *) However, thanks a lot for the bug report. Without such reports, we would probably never be able to make GPC a stable compiler. Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Jan 14 02:17:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA31002 for ; Tue, 14 Jan 1997 02:17:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61614; Tue, 14 Jan 1997 02:02:20 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69952; Tue, 14 Jan 1997 02:02:31 +0100 Received: from golden-gate.owl.de (golden-gate.uni-paderborn.de [131.234.134.30]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id CAA19350 for ; Tue, 14 Jan 1997 02:56:27 +0200 (EET) Received: by golden-gate.owl.de (Smail3.1.28.1) from fiction with uucp id ; Tue, 14 Jan 97 01:58 MET Received: by fiction.pb.owl.de id m0vjxNB-00002PC; Tue, 14 Jan 97 02:09 MET Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id RAA27855 for gpc@hut.fi; Mon, 13 Jan 1997 17:16:23 +0100 From: Nils Bokermann Message-Id: <199701131616.RAA27855@reality.owl.de> Subject: GPC and G77 To: gpc@hut.fi Date: Mon, 13 Jan 1997 17:16:22 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello! If trying to build the gpc-2.0 with the gcc-2.7.2.1 with the GNU Fortran enabled, will not run. There are some problems with the file toplev.c. Here is a simple diff, which worked at mine. --------cut-------------- diff -rcp2N gcc-2.7.2.1/toplev.c gcc-2.7.2.1.f.1/toplev.c *** gpc-2.0/toplev.c Fri Oct 20 17:56:35 1995 --- gpc-2.0.f.1/toplev.c Mon Nov 11 15:02:33 1996 *************** int flag_unroll_loops; *** 388,391 **** --- 388,405 ---- int flag_unroll_all_loops; + /* Nonzero forces all invariant computations in loops to be moved + outside the loop. */ + + int flag_move_all_movables = 0; + + /* Nonzero forces all general induction variables in loops to be + strength reduced. */ + + int flag_reduce_all_givs = 0; + + /* Nonzero gets another run of loop_optimize performed. */ + + int flag_rerun_loop_opt = 0; + /* Nonzero for -fwritable-strings: store string constants in data segment and don't uniquize them. */ *************** struct { char *string; int *variable; in *** 542,545 **** --- 556,562 ---- {"unroll-loops", &flag_unroll_loops, 1}, {"unroll-all-loops", &flag_unroll_all_loops, 1}, + {"move-all-movables", &flag_move_all_movables, 1}, + {"reduce-all-givs", &flag_reduce_all_givs, 1}, + {"rerun-loop-opt", &flag_rerun_loop_opt, 1}, {"writable-strings", &flag_writable_strings, 1}, {"peephole", &flag_no_peephole, 0}, *************** rest_of_compilation (decl) *** 2894,2897 **** --- 2911,2916 ---- { loop_optimize (insns, loop_dump_file); + if (flag_rerun_loop_opt) + loop_optimize (insns, loop_dump_file); }); } --------------cut------------- It's from the patch which came with GNU Fortran. Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Tue Jan 14 16:04:37 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA32568 for ; Tue, 14 Jan 1997 16:04:36 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61630; Tue, 14 Jan 1997 15:49:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44246; Tue, 14 Jan 1997 15:49:21 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id QAA10877 for ; Tue, 14 Jan 1997 16:40:53 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA32538; Tue, 14 Jan 1997 15:55:20 +0100 From: Peter Gerwinski Message-Id: <199701141455.PAA32538@agnes.dida.physik.uni-essen.de> Subject: Re: GPC and G77 To: nilsb@reality.owl.de, gpc@hut.fi Date: Tue, 14 Jan 1997 15:55:20 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Nils Bokermann: > If trying to build the gpc-2.0 with the gcc-2.7.2.1 with the GNU Fortran > enabled, will not run. There are some problems with the file toplev.c. Here is > a simple diff, which worked at mine. > [...] > It's from the patch which came with GNU Fortran. Thanks for your work! I am thinking about including the patch into GPC's toplev.c since it doesn't seem to interfere with other parts of GCC, but it might be better to remain consistent with GCC-2.7.2.1 and to put the patch into the documentation. What would you suggest? Greetings, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Jan 20 01:25:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA10032 for ; Mon, 20 Jan 1997 01:25:22 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61506; Mon, 20 Jan 1997 01:08:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA733920; Mon, 20 Jan 1997 01:08:38 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id BAA06723 for ; Mon, 20 Jan 1997 01:53:13 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA09943; Mon, 20 Jan 1997 01:09:38 +0100 From: Peter Gerwinski Message-Id: <199701200009.BAA09943@agnes.dida.physik.uni-essen.de> Subject: Re: GNU Pascal, go32.h To: brin@star.net Date: Mon, 20 Jan 1997 01:09:36 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Brin: > I am trying to use the farptr.h library and the go32.h libaray. [...] > To use them I need _dos_ds, which is defined in the C library go32.h > but is not a function or a procedure, but is: #define. I tried > incluing go32.h but got errors (due to it being a C file I think). Yes. GNU Pascal does not parse C source. ;-) > How can I import _dos_ds? Only by re-writing the functionality of the macro (#define), i.e. translating it to Pascal. In this case it is access to a component of a struct (a record in Pascal): Type ByteInt = __byte__ Integer; (* 8 bit signed Integer *) Byte = __unsigned__ ByteInt; (* 8 bit unsigned Integer *) ShortInt = __short__ Integer; (* 16 bit signed Integer *) ShortWord = __unsigned__ ShortInt; (* 16 bit unsigned Integer *) (* Integer = __long__ Integer *) (* 32 bit signed Integer *) Word = __unsigned__ Integer; (* 32 bit unsigned Integer *) Go32InfoBlockRecord = record size_of_this_structure_in_bytes, linear_address_of_primary_screen, linear_address_of_secondary_screen, linear_address_of_transfer_buffer, size_of_transfer_buffer, (* >= 4k *) pid: Word; master_interrupt_controller_base, slave_interrupt_controller_base: Byte; selector_for_linear_memory: ShortWord; linear_address_of_stub_info_structure, linear_address_of_original_psp: Word; run_mode, run_mode_info: ShortWord; end (* Go32InfoBlockRecord *); Var Go32InfoBlock: asmname '_go32_info_block' Go32InfoBlockRecord; Then by typing Go32InfoBlock.selector_for_linear_memory you get the functionality of _dos_ds. Now, of course, you can define it as a macro (*$define _dos_ds Go32InfoBlock.selector_for_linear_memory *) but then the definition is case sensitive. Or: Write a C function which uses the macro, then use that function from Pascal. But that's less effective. Hope this helps, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Jan 20 01:25:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA10028 for ; Mon, 20 Jan 1997 01:25:19 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77112; Mon, 20 Jan 1997 01:08:16 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA733914; Mon, 20 Jan 1997 01:08:36 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id BAA06764 for ; Mon, 20 Jan 1997 01:53:38 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA09953; Mon, 20 Jan 1997 01:10:06 +0100 From: Peter Gerwinski Message-Id: <199701200010.BAA09953@agnes.dida.physik.uni-essen.de> Subject: Graphics in Pascal To: brin@star.net Date: Mon, 20 Jan 1997 01:10:05 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Brin wrote: > I wrote the following small program to try out some graphics > routines [...] There is already BGI2GRX, a "Graph" compatible Unit, based on GRX20 and BCC2GRX, written by Sven Hilscher. > [...] Here is the program, any idea to > what I am doing wrong! The problem is that you are confusing some sizes of data types: > {****************************************************************} > Program Mode13h; > type > {Define some 'terms'} > byte = __byte__ integer; {8 bit unsigned integer} signed > word = __unsigned__ integer; {16 bit unsigned integer} 32 > Long = __longlong__ integer; {64 bit signed integer} correct, but used in wrong context (see below) If you correct them, your program runs fine. Below are the correct sizes for Intel X86 platforms. (I am thinking about implementing the identifiers below into GPC's standard vocabulary.) Type ByteInt = __byte__ Integer; (* 8 bit signed Integer *) Byte = __unsigned__ ByteInt; (* 8 bit unsigned Integer *) ShortInt = __short__ Integer; (* 16 bit signed Integer *) ShortWord = __unsigned__ ShortInt; (* 16 bit unsigned Integer *) (* Integer = __long__ Integer *) (* 32 bit signed Integer *) Word = __unsigned Integer; (* 32 bit unsigned Integer *) LongInt = __longlong__ Integer; (* 64 bit signed Integer *) LongWord = __unsigned__ LongInt; In addition, "unsigned long" in C has 32 bits, not 64: > {routines taken from include/sys/farptr.h} > {Puts a byte} > procedure _farnspokeb(offset: Long ; value: byte);External;C; > {Gets a byte} > function _farnspeekb(offset: Long ; value: byte):byte;External;C; (* Here's ^^^^^^^^^^^ another error ;*) Procedure FarNoSelectorPokeByte ( Offset: Word; value: Byte ); AsmName '_farnspokeb'; (* ;-) *) Function FarNoSelectorPeekByte ( Offset: Word ): Byte; AsmName '_farnspeekb'; (* (-; *) Hope this helps, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Tue Jan 21 05:50:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id FAA12461 for ; Tue, 21 Jan 1997 05:50:40 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91230; Tue, 21 Jan 1997 05:33:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA746728; Tue, 21 Jan 1997 05:33:35 +0100 Received: from lhc2.nlm.nih.gov (lhc2.nlm.nih.gov [130.14.35.129]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id GAA23691 for ; Tue, 21 Jan 1997 06:23:55 +0200 (EET) Received: from billings.csb by lhc2.nlm.nih.gov (SMI-8.6/SMI-SVR4) id XAA08681; Mon, 20 Jan 1997 23:25:51 -0500 Received: by billings.csb (SMI-8.6/SMI-SVR4) id XAA04160; Mon, 20 Jan 1997 23:22:39 -0500 Date: Mon, 20 Jan 1997 23:22:39 -0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <199701210422.XAA04160@billings.csb> To: gpc@hut.fi Subject: GNU Pascal and gcc/f77 Status: RO Dear Gnu Pascal Team, First, congratulations on your great efforts in bringing Pascal into the GNU compiler family. I have just briefly tried to build your latest gpc with gcc 2.7.2 with the GNU f77 patches applied. This results in an altered version for gcc of "2.7.2.f.1" which the gpc configuration file rejects as an inappropriate version. Do you have any plans to accommodate the simultaneous installation of f77 and Pascal? Any suggested work-arounds for my situation? Thanks and Best Regards, Rick Rodgers From sad@ibm.net Tue Jan 21 14:25:13 1997 Return-Path: sad@ibm.net Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id OAA13699 for ; Tue, 21 Jan 1997 14:24:56 +0100 Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id NAA147737 for ; Tue, 21 Jan 1997 13:07:28 GMT Message-Id: <199701211307.NAA147737@smtp-gw01.ny.us.ibm.net> Received: from slip166-72-241-201.tn.us.ibm.net(166.72.241.201) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr) id sma5gkBpo; Tue Jan 21 13:07:21 1997 From: "Stefan A. Deutscher" To: "Peter Gerwinski" Date: Tue, 21 Jan 97 08:07:16 Reply-To: "Stefan A. Deutscher" Priority: Normal X-Mailer: PMMail 1.53 For OS/2 UNREGISTERED SHAREWARE MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: GPC mailing list archive Status: RO On Tue, 21 Jan 1997 14:08:21 +0100 (MET), Peter Gerwinski wrote: >Hello, everybody! > >I am thinking about setting up an archive with all postings to the >mailing list in the last two years (i.e. during the time I am on >the list). The archive could consist of some gzipped mail folders >to be downloaded from the GPC WWW home page. > >Okay? Sure! Good idea. Thanks, mate! Stefan ============================================================================ Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad@utk.edu ============================================================================ Dictated with OS/2 Warp 4 VoiceType dictation. From gpc-request@santra.hut.fi Tue Jan 21 14:20:11 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA13694 for ; Tue, 21 Jan 1997 14:20:11 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83674; Tue, 21 Jan 1997 14:02:37 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20310; Tue, 21 Jan 1997 14:02:52 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id OAA08822 for ; Tue, 21 Jan 1997 14:53:52 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA13672; Tue, 21 Jan 1997 14:09:00 +0100 From: Peter Gerwinski Message-Id: <199701211309.OAA13672@agnes.dida.physik.uni-essen.de> Subject: Re: GNU Pascal and gcc/f77 To: rodgers@nlm.nih.gov, gpc@hut.fi Date: Tue, 21 Jan 1997 14:08:59 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to R. P. C. Rodgers, M.D.: > [...] I have just briefly tried to build your latest gpc with > gcc 2.7.2 with the GNU f77 patches applied. This results in an altered > version for gcc of "2.7.2.f.1" which the gpc configuration file rejects > as an inappropriate version. Do you have any plans to accommodate the > simultaneous installation of f77 and Pascal? We are working on merging Pascal into the GCC main distribution line. Once this is complete, you can install GNU Pascal together with GCC typing a command like `make LANGUAGES="C Pascal"'. Then all GNU Pascal patches will already be in the GCC source; additional GNU f77 patches should not spoil them, so it will probably work. And in case the f77 team and others are working on similar projects, it can become `make LANGUAGES="C C++ Objective-C Pascal Fortran Ada Basic Foo Bar"', one day ... (-: > Any suggested work-arounds > for my situation? Recently, Nils Bokermann sent a diff to this list which contains the necessary changes to `toplev.c'. We will include it into the GPC supplementary distribution (i.e. FAQ, WWW home page etc.), soon. Hope this helps, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ 8< ----------------------------------------------------------------------- From: Nils Bokermann Subject: GPC and G77 To: gpc@hut.fi Date: Mon, 13 Jan 1997 17:16:22 +0100 (MET) Hello! If trying to build the gpc-2.0 with the gcc-2.7.2.1 with the GNU Fortran enabled, will not run. There are some problems with the file toplev.c. Here is a simple diff, which worked at mine. --------cut-------------- diff -rcp2N gcc-2.7.2.1/toplev.c gcc-2.7.2.1.f.1/toplev.c *** gpc-2.0/toplev.c Fri Oct 20 17:56:35 1995 --- gpc-2.0.f.1/toplev.c Mon Nov 11 15:02:33 1996 *************** int flag_unroll_loops; *** 388,391 **** --- 388,405 ---- int flag_unroll_all_loops; + /* Nonzero forces all invariant computations in loops to be moved + outside the loop. */ + + int flag_move_all_movables = 0; + + /* Nonzero forces all general induction variables in loops to be + strength reduced. */ + + int flag_reduce_all_givs = 0; + + /* Nonzero gets another run of loop_optimize performed. */ + + int flag_rerun_loop_opt = 0; + /* Nonzero for -fwritable-strings: store string constants in data segment and don't uniquize them. */ *************** struct { char *string; int *variable; in *** 542,545 **** --- 556,562 ---- {"unroll-loops", &flag_unroll_loops, 1}, {"unroll-all-loops", &flag_unroll_all_loops, 1}, + {"move-all-movables", &flag_move_all_movables, 1}, + {"reduce-all-givs", &flag_reduce_all_givs, 1}, + {"rerun-loop-opt", &flag_rerun_loop_opt, 1}, {"writable-strings", &flag_writable_strings, 1}, {"peephole", &flag_no_peephole, 0}, *************** rest_of_compilation (decl) *** 2894,2897 **** --- 2911,2916 ---- { loop_optimize (insns, loop_dump_file); + if (flag_rerun_loop_opt) + loop_optimize (insns, loop_dump_file); }); } --------------cut------------- It's from the patch which came with GNU Fortran. Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Tue Jan 21 14:18:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA13689 for ; Tue, 21 Jan 1997 14:18:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74864; Tue, 21 Jan 1997 14:00:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85984; Tue, 21 Jan 1997 14:00:45 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id OAA08611 for ; Tue, 21 Jan 1997 14:51:26 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA13654 for gpc@hut.fi; Tue, 21 Jan 1997 14:08:21 +0100 From: Peter Gerwinski Message-Id: <199701211308.OAA13654@agnes.dida.physik.uni-essen.de> Subject: GPC mailing list archive To: gpc@hut.fi Date: Tue, 21 Jan 1997 14:08:21 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! I am thinking about setting up an archive with all postings to the mailing list in the last two years (i.e. during the time I am on the list). The archive could consist of some gzipped mail folders to be downloaded from the GPC WWW home page. Okay? Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Fri Jan 24 21:03:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA06348 for ; Fri, 24 Jan 1997 21:03:49 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71524; Fri, 24 Jan 1997 20:31:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48834; Fri, 24 Jan 1997 20:32:09 +0100 Received: from snert.wash.cedar-rapids.k12.ia.us (snert.wash.cedar-rapids.k12.ia.us [205.221.77.102]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id VAA30290 for ; Fri, 24 Jan 1997 21:23:19 +0200 (EET) Received: (from lindholm@localhost) by snert.wash.cedar-rapids.k12.ia.us (8.8.4/8.7.1) id NAA19481 for gpc@hut.fi; Fri, 24 Jan 1997 13:30:12 -0600 Date: Fri, 24 Jan 1997 13:30:12 -0600 From: Stephen Lindholm Message-Id: <199701241930.NAA19481@snert.wash.cedar-rapids.k12.ia.us> To: gpc@hut.fi Subject: Apparent bug. Status: RO I believe this is a bug. I believe that this should not compile with a warning. program testfile (input, output); var test: file of integer; i: integer; begin rewrite (testfile); for i := 1 to 10 do write (testfile, i); close (testfile); end. Compiled with: gpc -Wall -ansi -pedantic --standard-pascal -o testfile testfile.p If there are any typos, it is because I rekeyed the program. They would not actually exist in the program. The compiler tells me that ISO Pascal does not allow a file name parameter to reset/rewrite. I do not believe I am passing one to rewrite. I believe the warning refers to the barbarous practice of some compilers of requiring: rewrite (testfile, 'Test'); My mistake. Those testfiles in the program proper should be test. The program name is testfile. Please let me know if I am in error or when the bug will be fixed. (I'm not yet on the mailing list, so please forward a message directly to me.) Thank you. From gpc-request@santra.hut.fi Fri Jan 24 13:34:15 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA05576 for ; Fri, 24 Jan 1997 13:34:15 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64152; Fri, 24 Jan 1997 13:01:51 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39214; Fri, 24 Jan 1997 13:02:41 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id NAA16022 for ; Fri, 24 Jan 1997 13:53:41 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA05421 for gpc@hut.fi; Fri, 24 Jan 1997 13:25:13 +0100 From: Peter Gerwinski Message-Id: <199701241225.NAA05421@agnes.dida.physik.uni-essen.de> Subject: GPC mailing list archives To: gpc@hut.fi Date: Fri, 24 Jan 1997 13:25:12 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, folks! I have the GPC mailing list archives to kampi and to agnes and set up a link to them in the GPC home page. Peter From gpc-request@santra.hut.fi Sat Jan 25 15:23:00 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA08164 for ; Sat, 25 Jan 1997 15:22:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68964; Sat, 25 Jan 1997 14:50:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69696; Sat, 25 Jan 1997 14:51:05 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id PAA07003 for ; Sat, 25 Jan 1997 15:42:16 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA07949 for gpc@hut.fi; Sat, 25 Jan 1997 15:14:05 +0100 From: Peter Gerwinski Message-Id: <199701251414.PAA07949@agnes.dida.physik.uni-essen.de> Subject: Borland compatibility package To: gpc@hut.fi Date: Sat, 25 Jan 1997 15:14:05 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! I have written a small Borland comptatibility package for GNU Pascal on the DJGPP platform. It contains my "BPcompat" Unit, renamed to "System", a (new) "CRT" Unit, and Sven's "BGI2GRX" Unit, renamed to "Graph". There is no "Printer" Unit yet because it caused unexpected problems to write one, but the patched "libgpc.a" allows you to print by assigning a file to "prn", rewriting it, etc. The package is not portable but a DOS(DJGPP)-only solution, so I do not really recommend to use it for your new projects. However it might be useful for porting existing applications. It is available in the contrib subdirectory of the GPC distribution, i.e. ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/bpcompat.zip and ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip. I am setting up a link from the GNU Pascal home page to it, too. Have fun, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sat Jan 25 17:08:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA08502 for ; Sat, 25 Jan 1997 17:08:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72408; Sat, 25 Jan 1997 16:35:35 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70634; Sat, 25 Jan 1997 16:36:27 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id RAA00727 for ; Sat, 25 Jan 1997 17:30:20 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA08416; Sat, 25 Jan 1997 17:02:03 +0100 From: Peter Gerwinski Message-Id: <199701251602.RAA08416@agnes.dida.physik.uni-essen.de> Subject: Re: Apparent bug. To: lindholm@snert.wash.cedar-rapids.k12.ia.us, gpc@hut.fi Date: Sat, 25 Jan 1997 17:02:03 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Stephen Lindholm: > I believe this is a bug. I believe that this should not compile with a > warning. The warning is a bug in "-pedantic". Nothing serious. > gpc -Wall -ansi -pedantic --standard-pascal -o testfile testfile.p > If there are any typos, it is because I rekeyed the program. They would not > actually exist in the program. The compiler tells me that ISO Pascal does not > allow a file name parameter to reset/rewrite. I do not believe I am passing > one to rewrite. I believe the warning refers to the barbarous practice of > some compilers of requiring: > > rewrite (testfile, 'Test'); It's UCSD standard, and I find it much more useful than Extended Pascal's "bind" mechanism or Standard Pascal's method to mention "Test" in the program's parameter list (which your program doesn't, by the way) - where you have to type in the file name while the program runs. What do you think to be barbarous about that? > My mistake. Those testfiles in the program proper should be test. The program > name is testfile. Yes. Next time, please correct it in the e-mail *before* you post it. The time I needed to correct your program would have been better spent on correcting the bug you are pointing me to. However, thanks for the bug report. It will be corrected in the next release. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Sat Jan 25 20:39:15 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA08697 for ; Sat, 25 Jan 1997 20:39:14 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68884; Sat, 25 Jan 1997 20:06:30 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA22192; Sat, 25 Jan 1997 20:07:22 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id VAA09546 for ; Sat, 25 Jan 1997 21:03:12 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA08677 for gpc@hut.fi; Sat, 25 Jan 1997 20:35:02 +0100 From: Peter Gerwinski Message-Id: <199701251935.UAA08677@agnes.dida.physik.uni-essen.de> Subject: GNU Bulletin notes To: gpc@hut.fi Date: Sat, 25 Jan 1997 20:35:02 +0100 (MET) Priority: Urgent X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello! Some weeks ago, we were asked to write some notes about GNU Pascal for the GNU Bulletin. I do not know whether it is too late now, but here is a draft we could submit. Please post your comments/suggestions here as soon as possible, so we might get this into the January volume of the Bulletin. Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ 8< ----------------------------------------------------------------- Forthcoming GNUs * Pascal GNU Pascal is a free 32-bit Pascal compiler. It is implemented as a Pascal front-end for GCC, the GNU compiler, thus it runs on all platforms supported by GCC and produces the same highly-optimized code. The current version 2.0 has passed all ISO 7185 level 0 conformance tests (but some problems on specific platforms where we suspect some general GCC problems), thus we consider it to be a valid level 0 Standard Pascal compiler. ISO 7185 level 1 is implemented, but not yet stable. Most of ISO 10206 Extended Pascal and Borland Pascal 7.0--including objects--is implemented plus some extensions from Pascal-SC (user-defineable operators) and native GNU extensions (e.g. min, max), but there is still a lot of work to do to fix all bugs, implement the missing features and improve the documentation. Any help is most welcome! The home ftp site of GNU Pascal is `kampi.hut.fi', directory `jtv/gnu-pascal/'. For more information, look into the inofficial `FAQ' in the `contrib' subdirectory. We also have a WWW home page `http://home.pages.de/~GNU-Pascal/' and a mailing list `gpc@hut.fi'. To get into the list, write an e-mail to `gpc-request@hut.fi'. From gpc-request@santra.hut.fi Sun Jan 26 00:20:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA08967 for ; Sun, 26 Jan 1997 00:20:45 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64202; Sat, 25 Jan 1997 23:47:56 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43412; Sat, 25 Jan 1997 23:48:49 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id AAA12355 for ; Sun, 26 Jan 1997 00:44:17 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA08936; Sun, 26 Jan 1997 00:16:07 +0100 From: Peter Gerwinski Message-Id: <199701252316.AAA08936@agnes.dida.physik.uni-essen.de> Subject: Re: Apparent bug --> fixed. To: lindholm@snert.wash.cedar-rapids.k12.ia.us, gpc@hut.fi Date: Sun, 26 Jan 1997 00:16:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Stephen Lindholm: > I believe that this should not compile with a warning. > [...] I fixed the bug. Below is the diff for gpc-parse.y. You need Bison to produce gpc-parse.c out of it and to compile GPC, but you can also ignore the warning or surround the passage it with (*$W-*) ... (*$W+*) to suppress the warning. The bug is not serious enough that we release new binaries, but it will be fixed in the next release, of course. Thanks again for the report, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ 8< --------------------------------------------------------------------- --- gpc-parse.y.old Sat Jan 25 23:18:31 1997 +++ gpc-parse.y Sat Jan 25 23:18:35 1997 @@ -3847,7 +3847,7 @@ warning ("Extended Pascal does not allow parameters to HALT"); build_rts_call (p_HALT, $2); } | rts_file_open '(' actual_parameter optional_filename r_paren_or_error - { if (pedantic && $4 != NULL_TREE) + { if (pedantic && $4 != null_pointer_node) warning ("ISO Pascal does not allow file name parameter to reset/rewrite"); build_rts_call ($1, tree_cons (NULL_TREE, $3, From gpc-request@santra.hut.fi Sun Jan 26 21:32:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA10364 for ; Sun, 26 Jan 1997 21:32:24 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08690; Sun, 26 Jan 1997 20:59:17 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45162; Sun, 26 Jan 1997 21:00:11 +0100 Received: from ns.image.dk (root@ns.image.dk [194.19.141.1]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id VAA21573 for ; Sun, 26 Jan 1997 21:54:54 +0200 (EET) Received: from hafnium.nkbj.dk (aaip45.image.dk [194.255.40.45]) by ns.image.dk (8.8.4/8.7.3) with SMTP id UAA08823 for ; Sun, 26 Jan 1997 20:51:13 +0100 Date: Sun, 26 Jan 1997 20:55:02 +0100 (MET) From: Niels Kristian Bech Jensen X-Sender: nkbj@hafnium.nkbj.dk To: gpc@hut.fi Subject: Building GNU Pascal together with GNU Fortran. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi, Here is a small patch, which makes it possible to build GPC 2.0 using a GCC 2.7.2.1, that has been build with Fortran support (tested with G77 0.5.19). This could be useful for people, who (like me) needs to have both languages at hand. It changes the GCC version to 2.7.2.1.f.1 and adds the changes made for G77 to toplev.c: diff -rcp2N gpc-2.0/Makefile.in gpc-2.0.f.1/Makefile.in *** gpc-2.0/Makefile.in Mon Nov 18 03:31:33 1996 --- gpc-2.0.f.1/Makefile.in Sun Jan 26 17:32:05 1997 *************** *** 40,44 **** # GPCVERSION = `date +%y%m%d` GPCVERSION = 2.0 ! GCCVERSION = 2.7.2.1 CROSS = @cross@ --- 40,44 ---- # GPCVERSION = `date +%y%m%d` GPCVERSION = 2.0 ! GCCVERSION = 2.7.2.1.f.1 CROSS = @cross@ diff -rcp2N gpc-2.0/toplev.c gpc-2.0.f.1/toplev.c *** gpc-2.0/toplev.c Sat Sep 21 17:50:52 1996 --- gpc-2.0.f.1/toplev.c Sun Jan 26 17:30:28 1997 *************** int flag_unroll_loops; *** 392,395 **** --- 392,409 ---- int flag_unroll_all_loops; + /* Nonzero forces all invariant computations in loops to be moved + outside the loop. */ + + int flag_move_all_movables = 0; + + /* Nonzero forces all general induction variables in loops to be + strength reduced. */ + + int flag_reduce_all_givs = 0; + + /* Nonzero gets another run of loop_optimize performed. */ + + int flag_rerun_loop_opt = 0; + /* Nonzero for -fwritable-strings: store string constants in data segment and don't uniquize them. */ *************** struct { char *string; int *variable; in *** 553,556 **** --- 567,573 ---- {"unroll-loops", &flag_unroll_loops, 1}, {"unroll-all-loops", &flag_unroll_all_loops, 1}, + {"move-all-movables", &flag_move_all_movables, 1}, + {"reduce-all-givs", &flag_reduce_all_givs, 1}, + {"rerun-loop-opt", &flag_rerun_loop_opt, 1}, {"writable-strings", &flag_writable_strings, 1}, {"peephole", &flag_no_peephole, 0}, *************** rest_of_compilation (decl) *** 2965,2968 **** --- 2982,2987 ---- { loop_optimize (insns, loop_dump_file); + if (flag_rerun_loop_opt) + loop_optimize (insns, loop_dump_file); }); } -------------------------------------------------------- Niels Kristian Bech Jensen nkbj@image.dk "Chemists never die --- they just run out of reactants!" From gpc-request@santra.hut.fi Mon Jan 27 05:43:29 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id FAA11110 for ; Mon, 27 Jan 1997 05:43:29 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64300; Mon, 27 Jan 1997 05:10:15 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36298; Mon, 27 Jan 1997 05:11:08 +0100 Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id GAA26412 for ; Mon, 27 Jan 1997 06:04:03 +0200 (EET) Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id EAA239940 for ; Mon, 27 Jan 1997 04:04:02 GMT Message-Id: <199701270404.EAA239940@smtp-gw01.ny.us.ibm.net> Received: from slip166-72-241-230.tn.us.ibm.net(166.72.241.230) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr) id sma%8gKrx; Mon Jan 27 04:03:47 1997 From: "Stefan A. Deutscher" To: "gpc List" Date: Sun, 26 Jan 97 22:53:06 Reply-To: "Stefan A. Deutscher" Priority: Normal X-Mailer: PMMail 1.53 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Again: g77 and gpc ... Status: RO Hi, I noticed that there were some problems reported building gpc on a system that had the g77 patched gcc already. I just want to install ready-to-go gpc over my gcc/g77 setup under emx09c. I noticed that that would replace gcc.a from the original emx09c/gcc distribution. Are there any negative experiences with that, or is it safe to do so? Cheers. Stefan ============================================================================ Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad@utk.edu ============================================================================ Dictated with OS/2 Warp 4 VoiceType dictation. From gpc-request@santra.hut.fi Tue Jan 28 17:26:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA14554 for ; Tue, 28 Jan 1997 17:26:50 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73772; Tue, 28 Jan 1997 16:54:23 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56940; Tue, 28 Jan 1997 16:54:04 +0100 Received: from agnes.dida.physik.uni-essen.de (root@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.2/8.8.2) with SMTP id RAA28329 for ; Tue, 28 Jan 1997 17:46:01 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA14492 for gpc@hut.fi; Tue, 28 Jan 1997 17:00:37 +0100 From: Peter Gerwinski Message-Id: <199701281600.RAA14492@agnes.dida.physik.uni-essen.de> Subject: Re: Again: g77 and gpc ... To: gpc@hut.fi Date: Tue, 28 Jan 1997 17:00:37 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > [...] I just want to install ready-to-go gpc over my > gcc/g77 setup under emx09c. I noticed that that would replace gcc.a > from the original emx09c/gcc distribution. > Are there any negative experiences with that, or is it safe to do so? It should be save because gcc.a in the gpc distribution is (or: should be) the same as gcc.a in the gcc-2.7.2.1 distribution. I recommend you to try to run gpc with gcc.a from your gcc/g77 setup first. (I do not need to mention that you should backup your gcc.a first before replacing it with gpc's one, do I? ;-) Good luck, and let us know about your experience! Yours, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Wed Jan 29 18:32:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de ([132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA16861 for ; Wed, 29 Jan 1997 18:32:42 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75024; Wed, 29 Jan 1997 17:59:33 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57594; Wed, 29 Jan 1997 17:59:16 +0100 Received: from mazur.mimuw.edu.pl (kkwapien@mazur.mimuw.edu.pl [148.81.13.97]) by santra.hut.fi (8.8.2/8.8.2) with ESMTP id SAA05644 for ; Wed, 29 Jan 1997 18:46:51 +0200 (EET) Received: from localhost (kkwapien@localhost) by mazur.mimuw.edu.pl (8.8.3/8.8.3) with SMTP id RAA22520 for ; Wed, 29 Jan 1997 17:50:23 +0100 Date: Wed, 29 Jan 1997 17:50:23 +0100 (MET) From: Krzysztof Kwapien To: gpc@hut.fi Subject: gpc linking problem Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I wrote the hello world program. begin writeln('Hello World'); end. I compiled it with gpc -o hello hello.pas and it Worked!! But when i tried to compile it with gpc -c hello.pas <- this worked gpc -o hello hello.o <- this crashed with a SIGSEGV ..... it crashed when linking. What's the problem? ( I tried the -v option, and it seems as if some of the temporary files, where not linked in ) Because RHIDE also does it in the same manner it crashes too Help: kkwapien@mimuw.edu.pl From gpc-request@santra.hut.fi Fri Jan 31 02:50:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA18990 for ; Fri, 31 Jan 1997 02:50:36 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73822; Fri, 31 Jan 1997 02:17:16 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35468; Fri, 31 Jan 1997 02:17:01 +0100 Received: from golden-gate.owl.de (golden-gate.uni-paderborn.de [131.234.134.30]) by santra.hut.fi (8.8.5/8.8.2) with SMTP id DAA22889 for ; Fri, 31 Jan 1997 03:08:13 +0200 (EET) Received: by golden-gate.owl.de (Smail3.1.28.1) from fiction with uucp id ; Fri, 31 Jan 97 02:10 MET Received: by fiction.pb.owl.de id m0vq7k7-00002eC; Fri, 31 Jan 97 02:26 MET Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id PAA32627; Thu, 30 Jan 1997 15:12:01 +0100 From: Nils Bokermann Message-Id: <199701301412.PAA32627@reality.owl.de> Subject: Re: gpc linking problem In-Reply-To: from Krzysztof Kwapien at "Jan 29, 97 05:50:23 pm" To: kkwapien@mazur.mimuw.edu.pl (Krzysztof Kwapien) Date: Thu, 30 Jan 1997 15:12:00 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > I wrote the hello world program. > begin > writeln('Hello World'); > end. > > I compiled it with > gpc -o hello hello.pas > and it Worked!! > But when i tried to compile it with > gpc -c hello.pas <- this worked > gpc -o hello hello.o <- this crashed with a SIGSEGV ..... > it crashed when linking. > What's the problem? > ( I tried the -v option, and it seems as if some of the temporary files, > where not linked in ) Is it a ld-Problem? I've just tried it, but it works very well. Here is my system-info: reality:~/pascal$ gpc -v Reading specs from /usr/lib/gcc-lib/i486-unknown-linux/2.7.2.1.f.1/specs gpc version 2.0(2.7.2.1.f.1) reality:~/pascal$ ld -v ld version 2.7 (with BFD 2.7.0.3) Ok, this is the gcc with the g77 compiler. I've sent some patches to Jan-Jaap and they will be added to the FAQ. (In fact it's only in the file toplev.c where some options were added.) Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Thu Jan 30 23:59:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA18851 for ; Thu, 30 Jan 1997 23:59:01 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73786; Thu, 30 Jan 1997 23:25:44 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76960; Thu, 30 Jan 1997 23:25:29 +0100 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by santra.hut.fi (8.8.5/8.8.2) with ESMTP id AAA21733 for ; Fri, 31 Jan 1997 00:16:25 +0200 (EET) Received: from monstro (borg.mindspring.com [204.180.128.14]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id RAA53570 for ; Thu, 30 Jan 1997 17:16:22 -0500 Message-Id: <32F11DA6.240A@mindspring.com> Date: Thu, 30 Jan 1997 17:16:06 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: need GPC Developers? X-Url: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/support.html#gpc-list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi, I'd like to see if there is anything I can do to help with GNU Pascal development. Is there a wish-list of things people want? You may want to put such a list on the Web Home page. (if it was there, I could not find it...) -- Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Fri Jan 31 17:21:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA20141 for ; Fri, 31 Jan 1997 17:21:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80438; Fri, 31 Jan 1997 16:47:44 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77458; Fri, 31 Jan 1997 16:47:29 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2) with SMTP id RAA23319 for ; Fri, 31 Jan 1997 17:32:41 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA20024; Fri, 31 Jan 1997 17:06:22 +0100 From: Peter Gerwinski Message-Id: <199701311606.RAA20024@agnes.dida.physik.uni-essen.de> Subject: Re: need GPC Developers? To: perella@mindspring.com, gpc@hut.fi Date: Fri, 31 Jan 1997 17:06:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Ronald Perrella: > I'd like to see if there is anything I can do to help > with GNU Pascal development. Is there a wish-list of > things people want? > You may want to put such a list on the Web Home page. > (if it was there, I could not find it...) There is such a wish-list in the documentation, section "How you can contribute to GNU Pascal". But you are right that it should get a more prominent place on the WWW site. Just to mention a few current problems: * Improve the documentation. I am, for example, not too content with the current order of things. It should start with something like "Introduction to GNU Pascal", then "How to compile a program", etc. * Write more example programs. * Make the "Borland compatibility package" portable. I implemented it for DJGPP, but it would be nice to have it at least for Linux, too. Also, the DOS Unit is still missing ... * Fix the bugs. (Section "Known bugs and inconveniences ..." of the documentation lists most of the bugs.) * Implement the missing parts of ISO Standard Pascal, Level 1, and of ISO Extended Pascal - or at least point out what is missing because I actually do not know and I do not find it really instructive to read the Standard Specifications. * Implement the missing parts of Borland Pascal. Implement Delphi and Pascal-SC. You see that we are in the lucky position that there are enough of open problems that you can choose that one you like best to see been solved. ;-) I suggest just to try to write some useful programs with GNU Pascal (some of which we can publish as example programs), then you will run into some bugs and inconvenicences in the compiler and/or documentation. Once you know what you think to be the most annoying problem, try to fix it - and do not forget to contact us in case you succeed or have any questions. Thanks a lot for your offer! Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Fri Jan 31 17:16:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA20121 for ; Fri, 31 Jan 1997 17:16:43 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73172; Fri, 31 Jan 1997 16:43:09 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41696; Fri, 31 Jan 1997 16:42:55 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2) with SMTP id RAA23308 for ; Fri, 31 Jan 1997 17:32:36 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA20016; Fri, 31 Jan 1997 17:06:00 +0100 From: Peter Gerwinski Message-Id: <199701311606.RAA20016@agnes.dida.physik.uni-essen.de> Subject: Re: gpc linking problem To: kkwapien@mazur.mimuw.edu.pl, gpc@hut.fi Date: Fri, 31 Jan 1997 17:06:00 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Nils Bokermann: > According to Krzysztof Kwapien: > > But when i tried to compile it with > > gpc -c hello.pas <- this worked > > gpc -o hello hello.o <- this crashed with a SIGSEGV ..... > > it crashed when linking. > > Is it a ld-Problem? I've just tried it, but it works very well. I also suspect a ld-related problem here. Try to upgrade your "binutils". Ld version 2.7 is known to work with gpc 2.0. In case this does not solve the problem, please post some information about your system here, like Nils did: > Here is my system-info: > reality:~/pascal$ gpc -v > Reading specs from /usr/lib/gcc-lib/i486-unknown-linux/2.7.2.1.f.1/specs > gpc version 2.0(2.7.2.1.f.1) > reality:~/pascal$ ld -v > ld version 2.7 (with BFD 2.7.0.3) Good luck, Peter e-mail: peter.gerwinski@uni-essen.de home address: D\"usseldorfer Str. 35, 45145 Essen, Germany WWW: http://agnes.dida.physik.uni-essen.de/~peter/ From gpc-request@santra.hut.fi Mon Feb 3 21:54:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA26848 for ; Mon, 3 Feb 1997 21:54:23 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80926; Mon, 3 Feb 1997 21:19:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97048; Mon, 3 Feb 1997 21:19:29 +0100 Received: from usr01.primenet.com (charvel@usr01.primenet.com [206.165.5.101]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id WAA15155 for ; Mon, 3 Feb 1997 22:06:57 +0200 (EET) Received: (from charvel@localhost) by usr01.primenet.com (8.8.5/8.8.5) id NAA03393 for gpc@hut.fi; Mon, 3 Feb 1997 13:06:47 -0700 (MST) From: Jim Herbert Message-Id: <199702032006.NAA03393@usr01.primenet.com> Subject: Gpc To: gpc@hut.fi Date: Mon, 3 Feb 1997 15:06:46 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO Hi, I am having trouble resolving the symbol Assign in my pascal programs. I have no problems compiling and running under Borland, but I do not have dos based machines at my disposal and would like to compile under either gpc or xlp. Is there some library i need to tell it to link? If anyone have an answer for me, would you please reply via e-mail, since I am not a subscriber of this group. Thanks, -Jim From gpc-request@santra.hut.fi Tue Feb 4 00:28:59 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA27164 for ; Tue, 4 Feb 1997 00:28:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79356; Mon, 3 Feb 1997 23:54:15 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA89452; Mon, 3 Feb 1997 23:54:06 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA18314 for ; Tue, 4 Feb 1997 00:46:21 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA27148; Tue, 4 Feb 1997 00:21:03 +0100 From: Peter Gerwinski Message-Id: <199702032321.AAA27148@agnes.dida.physik.uni-essen.de> Subject: Re: Gpc To: charvel@primenet.com, gpc@hut.fi Date: Tue, 4 Feb 1997 00:21:02 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > I have no problems compiling and running under Borland, but I do not have > dos based machines at my disposal and would like to compile under either > gpc or xlp. Xlp? Is that something we should know about? > Is there some library i need to tell it to link? GNU Pascal has no built-in Assign procedure. You can use the "BPCompat" Unit from the "contrib" subdirectory of the GPC source distribution (same as the "System" Unit from the new BPCompat package). Alternatively you can write it yourself using Extended Pascal's "bind" mechanism: Type WrkString = String ( 255 ); Procedure Assign ( Var T: Text; Name: WrkString ); Var B: BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name; bind ( T, B ); B:= binding ( T ); end (* Assign *); Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Feb 6 14:30:24 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA00310 for ; Thu, 6 Feb 1997 14:30:24 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64124; Thu, 6 Feb 1997 13:54:47 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45898; Thu, 6 Feb 1997 13:54:37 +0100 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA18319 for ; Thu, 6 Feb 1997 14:43:05 +0200 (EET) Received: from athena (athena.lmemw.ericsson.se [147.214.118.10]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id NAA20926 for ; Thu, 6 Feb 1997 13:43:02 +0100 (MET) Received: from c3po by athena (SMI-8.6/LME-DOM-2.2.3) id NAA17048; Thu, 6 Feb 1997 13:43:00 +0100 Message-Id: <32F9CFE7.5CB@lmemw.ericsson.se> Date: Thu, 06 Feb 1997 13:34:47 +0100 From: Jakob Heinemann Reply-To: Jakob.Heinemann@lmemw.ericsson.se Organization: EMW/FD/KL X-Sender: Jakob Heinemann (Unverified) X-Mailer: Mozilla 4.0b1 (WinNT; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: GPC module restrictions etc X-Priority: Normal Content-Type: multipart/alternative; boundary="----------71D9648479760" Status: RO ------------71D9648479760 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by santra.hut.fi id OAA18262 Hello! I'm looking at GPC to decide wether or not to use it to port a quit large application from VMS to Unix. The original source is written in Vax-pascal, not by me, some ten years ago. It consists of lots of compiler dependent features such as Vax-pascal 'environment' and 'inherit'-statemets that should relatively easy translate to module exports and imports of GPC, but also of. constructs that are, perhaps not that easy to translate. Currently wehave installed the 2.0 version of GPC on our Sun Solaris 5.5 machine. The size of the system, about 175 modules, som 70 klines of code, implies that the translation have to rely on safe module-import/export functionality. 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? 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)? The other way around, other languages calling functions written in Pascal? 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 ; 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) I don=B4t think I'm on the subscriberlist so please post your reply directly to me aswell. (I've tried to subscribe , but I'havent hear anything...) 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.. Bye! -- /Jakob :) mailto:Jakob.Heinemann@lmemw.ericsson.se Ericsson Saab Avionics Link=F6ping, Sweden ------------71D9648479760 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hello!
 
I'm looking at GPC to decide wether or not to use it to port a quit large application from
VMS to Unix. The original source is written in Vax-pascal, not by me,  some ten years
ago. It consists of lots of compiler dependent features such as Vax-pascal 'environment'
and 'inherit'-statemets that should relatively easy translate to module exports and imports
of GPC, but also of. constructs that are, perhaps not that easy to translate.
 
Currently wehave installed the 2.0 version of GPC on our Sun Solaris 5.5 machine.
 
The size of the system, about 175 modules, som 70 klines of code, implies that
the translation have to rely on safe module-import/export functionality. 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?
 
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)? The other way around, other languages calling
functions written in Pascal?
 
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 := 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 := 1 to length(str) do 
    something(i,str);
end ;
 
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:= 0 ;
  for cnt := 1 to argument_list_length (therest) do
    arg1 := arg1 + argument(therest, cnt):
end;
 
Is there a construct for this in GPC? (in that case I´m sorry but I haven´t found it in the manual)
 
I don´t think I'm on the subscriberlist so please post your reply directly to me aswell.
(I've tried to subscribe , but I'havent hear anything...)
 
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..
 
Bye!
-- 
/Jakob :)

mailto:Jakob.Heinemann@lmemw.ericsson.se
Ericsson Saab Avionics 
Linköping, Sweden
------------71D9648479760-- From gpc-request@santra.hut.fi Thu Feb 6 17:27:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA00440 for ; Thu, 6 Feb 1997 17:27:09 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81210; Thu, 6 Feb 1997 16:51:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96944; Thu, 6 Feb 1997 16:51:24 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA27173 for ; Thu, 6 Feb 1997 17:43:49 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Thu, 6 Feb 97 16:43 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vsVuz-000knXC; Thu, 6 Feb 97 16:39 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 06 Feb 1997 16:36:47 +0200 Date: 06 Feb 1997 16:02:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6QN0ekHVlJB@rufus.central.de> Subject: function pointers - whats wrong ??? X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO hello gpc users, 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... Look: program zap(output); type proc_ptr = ^ procedure (integer); var pvar : proc_ptr; procedure write_int(i: integer); begin writeln ('Integer: ',i:1); end; begin (* PVAR points to function WRITE_IT *) pvar := &write_int; (* Dereferencing a function pointer calls the function *) pvar^(12345); end. Output from gpc: fupotest.pas(16) Error: to few arguments to function `Write_int' fupotest.pas(16) Error: invalid lvalue in unary `&' Now it's your turn ... what's wrong? Further questions: How I can put the stderr output in a file? I'm using DJGPP. 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? Anybody is using my graph unit "BGI2GRX"? I'm working on a direct GRX20-Unit (contexts, mouse, ...) but I don't know if it's needed by anybody else me. ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Fri Feb 7 03:34:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA01004 for ; Fri, 7 Feb 1997 03:34:09 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67362; Fri, 7 Feb 1997 02:58:18 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50018; Fri, 7 Feb 1997 02:58:11 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA09417 for ; Fri, 7 Feb 1997 03:53:48 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Fri, 7 Feb 97 02:53 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vsfR4-000kNhC; Fri, 7 Feb 97 02:49 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 07 Feb 1997 02:46:53 +0200 Date: 07 Feb 1997 02:46:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6QR3CBk-lJB@rufus.central.de> Subject: this ** works only with simple Real ??? X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO 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 From gpc-request@santra.hut.fi Fri Feb 7 03:45:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA01107 for ; Fri, 7 Feb 1997 03:45:32 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71256; Fri, 7 Feb 1997 03:09:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99646; Fri, 7 Feb 1997 03:09:35 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id EAA09386 for ; Fri, 7 Feb 1997 04:04:29 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA01042 for gpc@hut.fi; Fri, 7 Feb 1997 03:40:22 +0100 From: Peter Gerwinski Message-Id: <199702070240.DAA01042@agnes.dida.physik.uni-essen.de> Subject: Some bugs fixed --> new alpha GPC on agnes To: gpc@hut.fi Date: Fri, 7 Feb 1997 03:40:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From laa12@cc.keele.ac.uk Fri Feb 7 17:06:40 1997 Return-Path: laa12@cc.keele.ac.uk Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id RAA02092 for ; Fri, 7 Feb 1997 17:06:39 +0100 Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 7 Feb 1997 15:31:27 +0000 Received: from [0.89.30.166] by potter.cc.keele.ac.uk; Fri, 7 Feb 1997 15:30:15 GMT From: The African Chief To: Peter Gerwinski cc: Sven Hilscher , gpc@hut.fi Subject: Re: function pointers - whats wrong ??? Message-ID: Date: Fri, 7 Feb 1997 15:30:11 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Fri, 7 Feb 1997 16:07:07 +0100 (MET) Peter Gerwinski 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@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri Feb 7 17:00:38 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA02077 for ; Fri, 7 Feb 1997 17:00:38 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76024; Fri, 7 Feb 1997 16:24:35 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41550; Fri, 7 Feb 1997 16:24:25 +0100 Received: from ma.hw.ac.uk (root@orkney.ma.hw.ac.uk [137.195.21.8]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id QAA02872 for ; Fri, 7 Feb 1997 16:59:57 +0200 (EET) Received: from eday.ma.hw.ac.uk by ma.hw.ac.uk (SMI-8.6/SMI-4.1) id OAA05830; Fri, 7 Feb 1997 14:59:27 GMT Message-Id: <199702071459.OAA05830@ma.hw.ac.uk> From: "David Fiddes" To: Subject: Re: function pointers - whats wrong ??? Date: Fri, 7 Feb 1997 14:59:52 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO 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@hw.ac.uk - Tel: 0131-451-3251 From gpc-request@santra.hut.fi Fri Feb 7 16:28:31 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA02038 for ; Fri, 7 Feb 1997 16:28:31 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84352; Fri, 7 Feb 1997 15:52:28 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA102692; Fri, 7 Feb 1997 15:52:08 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id QAA01672 for ; Fri, 7 Feb 1997 16:31:38 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id QAA01904; Fri, 7 Feb 1997 16:07:37 +0100 From: Peter Gerwinski Message-Id: <199702071507.QAA01904@agnes.dida.physik.uni-essen.de> Subject: Re: GPC module restrictions etc To: jakob.heinemann@lmemw.ericson.se Date: Fri, 7 Feb 1997 16:07:36 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Feb 7 16:24:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA02032 for ; Fri, 7 Feb 1997 16:24:44 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77228; Fri, 7 Feb 1997 15:48:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81588; Fri, 7 Feb 1997 15:48:32 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id QAA01674 for ; Fri, 7 Feb 1997 16:30:48 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id QAA01887; Fri, 7 Feb 1997 16:06:45 +0100 From: Peter Gerwinski Message-Id: <199702071506.QAA01887@agnes.dida.physik.uni-essen.de> Subject: Re: this ** works only with simple Real ??? To: Sven@rufus.central.de (Sven Hilscher), gpc@hut.fi Date: Fri, 7 Feb 1997 16:06:45 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Feb 7 16:23:13 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA02028 for ; Fri, 7 Feb 1997 16:23:12 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67954; Fri, 7 Feb 1997 15:47:10 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19998; Fri, 7 Feb 1997 15:47:00 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id QAA01661 for ; Fri, 7 Feb 1997 16:31:04 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id QAA01895; Fri, 7 Feb 1997 16:07:07 +0100 From: Peter Gerwinski Message-Id: <199702071507.QAA01895@agnes.dida.physik.uni-essen.de> Subject: Re: function pointers - whats wrong ??? To: Sven@rufus.central.de (Sven Hilscher), gpc@hut.fi Date: Fri, 7 Feb 1997 16:07:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Feb 8 05:12:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id FAA03060 for ; Sat, 8 Feb 1997 05:12:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71314; Sat, 8 Feb 1997 04:36:01 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48924; Sat, 8 Feb 1997 04:35:55 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id FAA17590 for ; Sat, 8 Feb 1997 05:31:02 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id FAA02980; Sat, 8 Feb 1997 05:07:20 +0100 From: Peter Gerwinski Message-Id: <199702080407.FAA02980@agnes.dida.physik.uni-essen.de> Subject: More bugs fixed --> another new alpha GPC on agnes To: gpc@hut.fi, Jakob.Heinemann@lmemw.ericsson.se Date: Sat, 8 Feb 1997 05:07:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Feb 9 15:54:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de ([132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA05279 for ; Sun, 9 Feb 1997 15:48:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82950; Sun, 9 Feb 1997 15:10:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50520; Sun, 9 Feb 1997 15:10:12 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA00317 for ; Sun, 9 Feb 1997 15:57:06 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Sun, 9 Feb 97 14:56 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vtZku-000kocC; Sun, 9 Feb 97 14:57 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 09 Feb 1997 14:27:31 +0200 Date: 09 Feb 1997 14:26:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6QZ9PnwklJB@rufus.central.de> In-Reply-To: <199702071507.QAA01895@agnes.dida.physik.uni-essen.de> Subject: Re: function pointers - whats wrong ??? X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo Peter, Am 07.02.97 um 16:07 sagtest Du zum Thema "Re: function pointers - whats wrong ???": > > 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? > > G:\DJGPP\BIN> stubedit ld.exe > ... > Size of real-memory transfer buffer [...]: 64k Yeah, it runs better. > > 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! :-) I do it. You also still working on the GPC-TurboVision ??? I try to make some GUI-Parts for my fractal program using the grx20, it would be great if we could do the tv-funcionality for text and grafix. > However I join Sven in asking: Anybody is using Objects with GPC? I'm implemented the first parts of my GUI without objects, but everybody knows that a gui is a thing should be made strictly using objects... > 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. Also I think about to implement the different fractal types and color mode types as objects. IMHO it's more easy to classify the different types and to handle the sources. I'm only will using the objects for this part if I dont lose lots of speed (I think 5% it's worth). BTW: GPC is'nt perfect and this will take a long time too but I like it in spite of that. ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Sun Feb 9 22:10:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA05756 for ; Sun, 9 Feb 1997 22:10:33 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83188; Sun, 9 Feb 1997 21:33:39 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91484; Sun, 9 Feb 1997 21:33:36 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id WAA05115 for ; Sun, 9 Feb 1997 22:26:26 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id WAA05720 for gpc@hut.fi; Sun, 9 Feb 1997 22:03:19 +0100 From: Peter Gerwinski Message-Id: <199702092103.WAA05720@agnes.dida.physik.uni-essen.de> Subject: BO5, Turbo Vision, Objects To: gpc@hut.fi Date: Sun, 9 Feb 1997 22:03:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO 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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Feb 10 13:59:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA07241 for ; Mon, 10 Feb 1997 13:59:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83842; Mon, 10 Feb 1997 13:22:11 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94176; Mon, 10 Feb 1997 13:22:08 +0100 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA27384 for ; Mon, 10 Feb 1997 14:11:56 +0200 (EET) Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id OAA70372 for ; Mon, 10 Feb 1997 14:02:40 +0200 Received: from athena (athena.lmemw.ericsson.se [147.214.118.10]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id NAA22226 for ; Mon, 10 Feb 1997 13:00:16 +0100 (MET) Received: from c3po by athena (SMI-8.6/LME-DOM-2.2.3) id MAA05698; Mon, 10 Feb 1997 12:59:52 +0100 Message-Id: <32FF0BC4.1101@lmemw.ericsson.se> Date: Mon, 10 Feb 1997 12:51:32 +0100 From: Jakob Heinemann Reply-To: Jakob.Heinemann@lmemw.ericsson.se Organization: EMW/FD/KL X-Sender: Jakob Heinemann (Unverified) X-Mailer: Mozilla 4.0b1 (WinNT; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: Restrictions on packed types? X-Priority: Normal Content-Type: multipart/alternative; boundary="----------237D6558592C2" Status: RO ------------237D6558592C2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 ------------237D6558592C2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
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
 
------------237D6558592C2-- From gpc-request@santra.hut.fi Mon Feb 10 15:25:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA07470 for ; Mon, 10 Feb 1997 15:25:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77954; Mon, 10 Feb 1997 14:48:10 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83492; Mon, 10 Feb 1997 14:48:05 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA31568 for ; Mon, 10 Feb 1997 15:40:04 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA07411; Mon, 10 Feb 1997 15:16:12 +0100 From: Peter Gerwinski Message-Id: <199702101416.PAA07411@agnes.dida.physik.uni-essen.de> Subject: Re: Restrictions on packed types? To: jakob.heinemann@lmemw.ericsson.se Date: Mon, 10 Feb 1997 15:16:12 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jakob Heinemann: > 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? It is true, but it only affects things which are smaller than one byte or structures containings things which should be aligned on a 2- or 4-byte boundary. One example: Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; Var AOC: array [ 1..100 ] of Char; PAOC: packed array [ 1..100 ] of Char; AOBoo: array [ 1..100 ] of Boolean; PAOBoo: packed array [ 1..100 ] of Boolean; AOBy: array [ 1..100 ] of Byte; PAOBy: packed array [ 1..100 ] of Byte; all have 100 bytes (while PAOBoo should have ( 100 + 7 ) div 8 bytes), and MyRec: record B: Byte; C: Char; I: Integer; end (* MyRec *); has 8 bytes, not 6. \begin{sigh} When we say that GPC "does not pack" this means about the same as what Borland means when they claim that Borland Pascal "always packs". The only difference is that Borland Pascal does not care about 32-bit alignment and thus often produces records of smaller size - at the expense of loss of speed. \end{sigh} Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Feb 15 22:25:47 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA17448 for ; Sat, 15 Feb 1997 22:25:47 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83356; Sat, 15 Feb 1997 21:46:44 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70442; Sat, 15 Feb 1997 21:46:52 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id WAA07991 for ; Sat, 15 Feb 1997 22:37:26 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id WAA17283 for gpc@hut.fi; Sat, 15 Feb 1997 22:16:19 +0100 From: Peter Gerwinski Message-Id: <199702152116.WAA17283@agnes.dida.physik.uni-essen.de> Subject: Again: new alpha GPC on agnes To: gpc@hut.fi Date: Sat, 15 Feb 1997 22:16:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, GPC testers! ;-) Here is the next alpha version of GPC. You can download it at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-2.0-970215.diff.gz Although the changes since gpc-970207 are crucial they are almost invisible. What I did was to "sort" the different language dialects and to implement options which allow a clear distinction between them. For example, GPC now defaults to allow nested comments { like this one (* you see? *) }, whereas ISO Standard allows comments starting with `(*' and ending with '}'. For example, GPC now understands Borland-style character constants like `#10' (* as an alternative to `chr ( 10 )'; the notation `^J' is *not* yet implemented *). Data type like `Word' or `Pointer' are built into GPC now, but you still cannot `writeln' them. If you specify one of `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', or `--object-pascal', nested comments are switched off by default { does anybody really use comments starting with `(*' and ending with `}'? *), and all Borland extensions (including the `#' character constants and the above data types) which contradict ISO are switched off. When you combine the above switches with `--pedantic', even those extensions which do not contradict the standard trigger warnings, with `--pedantic-errors' they trigger error messages. To make things more symmetric, `--borland-pascal' yields the opposite effect. With this switch, warnings about a missing program header or misuse of "typed constants" are omitted; together with `--pedantic' you get warnings about Extended Pascal features not in Borland Pascal, and so on. I heavily modified the parsing of String-related stuff. Now everything is prepared for the implementation of general Schema types ... Now it's your turn: I would like to know how much is broken due to the above improvements. * Please try to recompile all your GNU Pascal programs with this alpha compiler. There should be no problems. * Please try to compile your Standard Pascal programs with GPC with and without the switches `--standard-pascal' and/or `--pedantic'. There should be less problems than before, and there should be less problems with `--standard-pascal' than without. * The same for not too sophisticated Extended Pascal programs. (For example, Schema types are still not implemented.) * The same for not too sophisticated Borland Pascal programs. There should be less problems with `--borland-pascal' than without. That's it. Please post your "everything works" reports to this list. (* But bug reports are welcome, too. :*) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Feb 17 12:32:29 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA20890 for ; Mon, 17 Feb 1997 12:32:29 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87628; Mon, 17 Feb 1997 11:52:52 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA27974; Mon, 17 Feb 1997 11:53:02 +0100 Received: from mazur.mimuw.edu.pl (kkwapien@mazur.mimuw.edu.pl [148.81.13.97]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA01189 for ; Mon, 17 Feb 1997 12:32:39 +0200 (EET) Received: from localhost (kkwapien@localhost) by mazur.mimuw.edu.pl (8.8.3/8.8.3) with SMTP id LAA13063 for ; Mon, 17 Feb 1997 11:33:18 +0100 Date: Mon, 17 Feb 1997 11:33:17 +0100 (MET) From: Krzysztof Kwapien To: gpc@hut.fi Subject: Re: gpc linking problem cd. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 29 Jan 1997, Krzysztof Kwapien wrote: > I wrote the hello world program. > begin > writeln('Hello World'); > end. > > I compiled it with > gpc -o hello hello.pas > and it Worked!! > But when i tried to compile it with > gpc -c hello.pas <- this worked > gpc -o hello hello.o <- this crashed with a SIGSEGV ..... > it crashed when linking. > What's the problem? > ( I tried the -v option, and it seems as if some of the temporary files, > where not linked in ) > Because RHIDE also does it in the same manner it crashes too > Help: kkwapien@mimuw.edu.pl > > Here is the output you wanted. -----> This is from : gpc -v -o hello hello.pas Reading specs from d:/djgpp/lib\specs.gpc gpc version 1.2(2.7.2) d:/djgpp/bin\gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=1 -D__GPC__=1 -D__GNUC_MINOR__=2(2 -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 hello.pas d:/djgpp/tmp\ccbaaaaa.i GNU CPP version 1.2(2.7.2) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/djgpp/include d:/djgpp/lang/pascal /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.7.2/include /usr/include End of search list. d:/djgpp/bin\gpc1.exe d:/djgpp/tmp\ccbaaaaa.i -quiet -dumpbase hello.pas -version -o d:/djgpp/tmp\cccaaaaa.s GNU Pascal version 1.2(2.7.2) (80386, BSD syntax) compiled by GNU C version 2.7.2. hello.pas:1: warning: missing program header d:/djgpp/bin\as.exe -o d:/djgpp/tmp\ccdaaaaa.o d:/djgpp/tmp\cccaaaaa.s d:/djgpp/bin\ld.exe -o hello d:/djgpp/lib\crt0.o -Ld:/djgpp/lib d:/djgpp/tmp\ccdaaaaa.o -Tdjgpp.djl -lgcc -lgpc -lm -lc -lgcc d:/djgpp/bin\stubify.exe -v hello stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: hello -> hello.000 -> hello.exe ----> This is from gpc -v -c hello.pas Reading specs from d:/djgpp/lib\specs.gpc gpc version 1.2(2.7.2) d:/djgpp/bin\gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=1 -D__GPC__=1 -D__GNUC_MINOR__=2(2 -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 hello.pas d:/djgpp/tmp\ccbaaaaa.i GNU CPP version 1.2(2.7.2) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/djgpp/include d:/djgpp/lang/pascal /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.7.2/include /usr/include End of search list. d:/djgpp/bin\gpc1.exe d:/djgpp/tmp\ccbaaaaa.i -quiet -dumpbase hello.pas -version -o d:/djgpp/tmp\cccaaaaa.s GNU Pascal version 1.2(2.7.2) (80386, BSD syntax) compiled by GNU C version 2.7.2. hello.pas:1: warning: missing program header d:/djgpp/bin\as.exe -o hello.o d:/djgpp/tmp\cccaaaaa.s -----> This is from gpc -v -o hello hello.o Reading specs from d:/djgpp/lib\specs.gpc gpc version 1.2(2.7.2) Exiting due to signal SIGSEGV Page fault at eip=0000c928, error=0004 eax=00000000 ebx=0005debc ecx=0005debc edx=00000000 esi=fffffffc edi=00066fe8 ebp=0005dd94 esp=0005dd90 cs=00e7 ds=00ef es=00ef fs=00cf gs=00ff ss=00ef Call frame traceback EIPs: 0x0000c928 0x0000925e 0x0000a0f0 0x0000b79f From gpc-request@santra.hut.fi Mon Feb 17 18:21:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA21563 for ; Mon, 17 Feb 1997 18:21:17 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69386; Mon, 17 Feb 1997 17:41:35 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA515782; Mon, 17 Feb 1997 17:41:46 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id SAA17293 for ; Mon, 17 Feb 1997 18:31:29 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA21532; Mon, 17 Feb 1997 18:10:27 +0100 From: Peter Gerwinski Message-Id: <199702171710.SAA21532@agnes.dida.physik.uni-essen.de> Subject: Re: gpc linking problem cd. To: kkwapien@mazur.mimuw.edu.pl, gpc@hut.fi Date: Mon, 17 Feb 1997 18:10:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Krzysztof Kwapien: > Reading specs from d:/djgpp/lib\specs.gpc > gpc version 1.2(2.7.2) That's it! You are using the beta version gpc-1.2(2.7.2) of GNU Pascal which had a bug concerning linking. If you upgrade to gpc-2.0(2.7.2.1), the bug will vanish. Please download and install ftp://kampi.hut.fi/jtv/gnu-pascal/djgpp/gpc20b.zip It might be necessary to upgrade the whole DJGPP package (or at least the binutils) from v2.0 to v2.01 - which might be reasonable anyway. The current version of RHIDE for instance is much more stable than that which was available in the days of gpc-1.2(2.7.2). Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Feb 17 19:41:05 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA21673 for ; Mon, 17 Feb 1997 19:41:05 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62618; Mon, 17 Feb 1997 19:01:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46574; Mon, 17 Feb 1997 19:01:32 +0100 Received: from cinder.nationwide.com (cinder.nationwide.com [198.8.254.6]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA18100 for ; Mon, 17 Feb 1997 19:18:24 +0200 (EET) From: adamss3@nationwide.com Status: RO X400-Originator: adamss3@lms01.ent.nwie.net X400-Recipients: gpc@hut.fi X400-Mts-Identifier: [/PRMD=NATIONWIDE/ADMD=IBMX400/C=US/;0012000001019004000004] X400-Content-Type: P2-1988 (22) Message-Id: <0012000001019004000004*@MHS> To: "gpc(a)hut.fi" Date: Mon, 17 Feb 1997 12:19:36 -0500 Does anyone know how I can get my old email ID dropped off of this list? It receives internet mail, but cannot send anymore. Thanks. Steve PS - please reply to email ID From gpc-request@santra.hut.fi Tue Feb 18 17:20:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA23666 for ; Tue, 18 Feb 1997 17:20:06 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA07822; Tue, 18 Feb 1997 16:40:03 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA784790; Tue, 18 Feb 1997 16:40:15 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA24684 for ; Tue, 18 Feb 1997 17:17:40 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id QAA23632 for gpc@hut.fi; Tue, 18 Feb 1997 16:57:28 +0100 From: Peter Gerwinski Message-Id: <199702181557.QAA23632@agnes.dida.physik.uni-essen.de> Subject: Changing e-mail address in the list To: gpc@hut.fi Date: Tue, 18 Feb 1997 16:57:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to adamss3@nationwide.com: > Does anyone know how I can get my old email ID dropped off of this list? Write to gpc-request@hut.fi. Since it is a human, no program, who takes care of the list, he will understand your request. > PS - please reply to email ID The e-mail reply did not get through, sorry. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Feb 20 00:58:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA26396 for ; Thu, 20 Feb 1997 00:58:41 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71294; Thu, 20 Feb 1997 00:18:10 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58780; Thu, 20 Feb 1997 00:18:24 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA15982 for ; Thu, 20 Feb 1997 01:08:40 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA26361 for gpc@hut.fi; Thu, 20 Feb 1997 00:48:56 +0100 From: Peter Gerwinski Message-Id: <199702192348.AAA26361@agnes.dida.physik.uni-essen.de> Subject: New alpha & binaries To: gpc@hut.fi Date: Thu, 20 Feb 1997 00:48:55 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! I was asked for binaries of the GPC alpha version because some people (including myself :-) had trouble to compile it, especially on non-UNIX systems. I am now uploading binaries of the current alpha GPC for Linux (elf) and for DOS (DJGPP) to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. The "current alpha GPC" means of course gpc-970219, not the obsolete and buggy gpc-970215. ;-) Changes from gpc-970215 to gpc-970219: * Everything which treads `Char' as an ordinal type (e.g. `ord', `min', `succ', `case') works again. (It was broken in gpc-970215.) * Initialized `Char' variables work again; `array of char' variables now can be initialized with a String value. :) * Chars above chr ( 127 ) did not work in some situations, e.g. as `case' labels. Now they do. * According to Extended Pascal, you can assign String constants to Chars. The empty String yields a space character. That's it for the moment. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Feb 21 19:14:46 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA31453 for ; Fri, 21 Feb 1997 19:14:46 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82670; Fri, 21 Feb 1997 18:33:39 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30530; Fri, 21 Feb 1997 18:33:48 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA09408 for ; Fri, 21 Feb 1997 19:22:19 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA31383 for gpc@hut.fi; Fri, 21 Feb 1997 19:02:56 +0100 From: Peter Gerwinski Message-Id: <199702211802.TAA31383@agnes.dida.physik.uni-essen.de> Subject: ... and the next alpha ... To: gpc@hut.fi Date: Fri, 21 Feb 1997 19:02:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello again! The next alpha GPC is on agnes, as source (diff against gpc-970215) and binaries for DOS (DJGPP) and Linux (elf). Changes from gpc-970219 to gpc-970221: * Pointers to functions did not survive transport through a GPI file. Now they do. * Now String variables can be now can be initialized with a String value, too - and not only `array of char' variables. :) * Sets of Chars work again. (Was broken in gpc-970215.) * Extended Pascal's "Index" function works again. (Was broken in gpc-970215.) Many thanks to everybody who helped me to find all these bugs. I am especially grateful to Miklos Cserzo, Scott A. Moore, and Sven Hilscher for their short, but very useful test programs. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Feb 23 19:02:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA05371 for ; Sun, 23 Feb 1997 19:02:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77730; Sun, 23 Feb 1997 18:20:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50306; Sun, 23 Feb 1997 18:18:36 +0100 Received: from ki1.chemie.fu-berlin.de (ki1.chemie.fu-berlin.de [160.45.24.21]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA07307 for ; Sun, 23 Feb 1997 19:01:50 +0200 (EET) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from uranus.central.de (194.45.71.1) with smtp id ; Sun, 23 Feb 97 17:59 MET Received: from rufus.central.de by uranus.central.de with bsmtp (Smail3.1.28.1 #5) id m0vyhBM-000kg8C; Sun, 23 Feb 97 17:53 MET Received: by rufus.central.de (CrossPoint v3.1 R/C597); 23 Feb 1997 17:49:07 +0200 Date: 23 Feb 1997 17:47:00 +0200 From: Sven@rufus.central.de (Sven Hilscher) To: gpc@hut.fi Message-Id: <6RO12hN-lJB@rufus.central.de> Subject: constant arrays of type string X-Mailer: CrossPoint v3.1 R/C597 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hello gpc, this is from info file gpc.8 but I can't compile this, I need string array constants: program str_arr; const MyStringsCount = 5; type Ident = string(20); var MyStrings : array [1..MyStringsCount] of Ident value [ 1:'EXPORT'; 2:'IMPLEMENTATION'; 3:'IMPORT'; 4:'INTERFACE'; 5:'MODULE']; begin end. ___, ((__ o ,____)) V E N I From gpc-request@santra.hut.fi Mon Feb 24 18:24:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA08528 for ; Mon, 24 Feb 1997 18:24:01 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72762; Mon, 24 Feb 1997 17:41:56 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44654; Mon, 24 Feb 1997 17:42:04 +0100 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA13148 for ; Mon, 24 Feb 1997 18:35:18 +0200 (EET) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id IAA12568; Mon, 24 Feb 1997 08:37:06 -0800 (PST) Date: Mon, 24 Feb 1997 08:37:06 -0800 (PST) From: Phil Nelson Message-Id: <199702241637.IAA12568@fawn.cs.wwu.edu> To: beck@cs.ualberta.ca Cc: gpc@hut.fi In-Reply-To: <97Feb24.092431-0700_mst.138586-2+55@amisk.cs.ualberta.ca> (message from Bob Beck on Mon, 24 Feb 1997 09:24:22 -0700 (MST)) Subject: Re: GPC in an instructional envionment Status: RO > As GPC is starting to stablize, is anyone using it in an >instructional environment (i.e. teaching beginning programming and >data structures?) We're kind of considering it. Actually, we (Computer Science Department at Western Washington University in Bellingham, Washington (USA)) have been using gpc as our primary Pascal compiler to support our beginning programming sequence for our majors for at least 3 years. It has been quite nice. And with gpc getting more of Extended Pascal implemented, you can have the students do more with separate compilation and such. Our biggest problem here is that the book we are using has gone out of print and it was replaced with a C version. We have yet to find a book to match the book's approach and use Pascal. So our department is in the middle of the process of talking about the introductory sequence for Computer Science majors. For those who really want some sort of a programming envoronment to go with gpc and are running X, look at xwpe. (X window Programming Environment) The environment is quite similar to the Turbo-Pascal environment. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From beck@cs.ualberta.ca Mon Feb 24 18:06:24 1997 Return-Path: beck@cs.ualberta.ca Received: from amisk.cs.ualberta.ca (amisk.cs.ualberta.ca [129.128.13.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id SAA08488 for ; Mon, 24 Feb 1997 18:06:23 +0100 Received: by amisk.cs.ualberta.ca id <138586-2>; Mon, 24 Feb 1997 09:24:31 -0700 Subject: GPC in an instructional envionment From: Bob Beck To: peter@agnes.dida.physik.uni-essen.de (Peter Gerwinski) Date: Mon, 24 Feb 1997 09:24:22 -0700 (MST) Cc: gpc@hut.fi In-Reply-To: <199702211802.TAA31383@agnes.dida.physik.uni-essen.de> from "Peter Gerwinski" at Feb 21, 97 07:02:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 186 Message-Id: <97Feb24.092431-0700_mst.138586-2+55@amisk.cs.ualberta.ca> Status: RO As GPC is starting to stablize, is anyone using it in an instructional environment (i.e. teaching beginning programming and data structures?) We're kind of considering it. -Bob From gpc-request@santra.hut.fi Tue Feb 25 16:57:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA10908 for ; Tue, 25 Feb 1997 16:57:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76746; Tue, 25 Feb 1997 16:14:51 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49320; Tue, 25 Feb 1997 16:14:58 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA17121 for ; Tue, 25 Feb 1997 17:05:28 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id QAA00400 (8.7.6/7.5c-FAU); for ; Tue, 25 Feb 1997 16:05:21 +0100 (MET) Received: from eumaios by mi.uni-erlangen.de with SMTP; id QAA03069 (SMI-8.6/7.5b-FAU); Tue, 25 Feb 1997 16:02:00 +0100 From: Frank Heckenbach Message-Id: <199702251502.QAA03069@helena.mi.uni-erlangen.de> Date: Tue, 25 Feb 1997 15:01:59 GMT To: gpc@hut.fi Subject: Some bug reports Status: RO Hi everyone! I've got a number of bug reports. Perhaps some of them are already known, but I didn't find any information about them. I'm listing all the problems I encountered when I ported a BP program to gpc. The bugs were tested with 2.0, and "verified" with 970221. 1. The output of a compiler program is not redirectable (neither as stdout, nor stderr). 2. Writeln('a','':5,'b'); I think it should write "a b", but it just writes "ab". 3. My standard way for "variable size arrays" in BP doesn't work in gpc: PROGRAM t; CONST MaxVar=$FFF0; TYPE X=Integer; XArray=ARRAY[1..MaxVar DIV SizeOf(X)] OF X; {} BEGIN END. The error message for the line "{}" is: subrange bounds are not of the same type ordinal type expected It doesn't depend on the type of X, and it doesn't help to declare a constant with value MaxVar DIV SizeOf(X). 4. Problem with CONST parameters: PROGRAM x; TYPE t=ARRAY[1..1] OF Integer; PROCEDURE p(CONST c:t); BEGIN IF c[1]=0 THEN END; BEGIN END. gpc crashes with: Exiting due to signal SIGSEGV Page fault at... (I could provide all the register values if necessary.) It doesn't matter if I invoce it as gpc x.p or gpc -o x x.p or gpc -c x.p It doesn't seem to depend on the type of t (it must only be an array), and it doesn't matter if c[1] is accessed as above, or e.g. in a Write statement. 5. Initialized set variables don't seem to work: PROGRAM t; TYPE IByte=__byte__ Integer; Byte=__unsigned__ IByte; ByteSet=SET OF Byte; VAR m:ByteSet VALUE [1,2,3]; {"CONST ... = ..." gives the same result} k:Integer; {or k:Byte - the same} BEGIN { m:=[1,2,3]; ...then it works correctly } FOR k:=0 TO $FF DO IF k IN m THEN Write(Integer(k)) END. The numbers written are more or less random. 6. Last but not least: Is there anything like TP's Exit (return from current procedure/function)? I couldn't find it in the docs. Frank From gpc-request@santra.hut.fi Tue Feb 25 00:32:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA09052 for ; Tue, 25 Feb 1997 00:32:34 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72802; Mon, 24 Feb 1997 23:50:23 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42520; Mon, 24 Feb 1997 23:50:31 +0100 Received: from amisk.cs.ualberta.ca (root@amisk.cs.ualberta.ca [129.128.13.1]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA13819 for ; Mon, 24 Feb 1997 18:50:26 +0200 (EET) Received: by amisk.cs.ualberta.ca id <138725-2>; Mon, 24 Feb 1997 09:50:13 -0700 Subject: Re: GPC in an instructional envionment From: Bob Beck To: phil@cs.wwu.edu (Phil Nelson) Date: Mon, 24 Feb 1997 09:50:04 -0700 (MST) Cc: beck@cs.ualberta.ca, gpc@hut.fi In-Reply-To: <199702241637.IAA12568@fawn.cs.wwu.edu> from "Phil Nelson" at Feb 24, 97 08:37:06 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <97Feb24.095013-0700_mst.138725-2+60@amisk.cs.ualberta.ca> Status: RO One of my major concerns is textbooks. Anyone got a good reccomendation for ones that work with GPC and are likeley to stay in print? -Bob > > > > > As GPC is starting to stablize, is anyone using it in an > >instructional environment (i.e. teaching beginning programming and > >data structures?) We're kind of considering it. > > Actually, we (Computer Science Department at Western Washington > University in Bellingham, Washington (USA)) have been using gpc as our > primary Pascal compiler to support our beginning programming sequence > for our majors for at least 3 years. It has been quite nice. And > with gpc getting more of Extended Pascal implemented, you can have the > students do more with separate compilation and such. > > Our biggest problem here is that the book we are using has gone out of > print and it was replaced with a C version. We have yet to find a > book to match the book's approach and use Pascal. So our department > is in the middle of the process of talking about the introductory > sequence for Computer Science majors. > > For those who really want some sort of a programming envoronment to go > with gpc and are running X, look at xwpe. (X window Programming Environment) > The environment is quite similar to the Turbo-Pascal environment. > > -- > Phil Nelson NetBSD: http://www.netbsd.org > e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org > http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html > From gpc-request@santra.hut.fi Mon Feb 24 21:49:15 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA08870 for ; Mon, 24 Feb 1997 21:49:15 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63462; Mon, 24 Feb 1997 21:07:06 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA32676; Mon, 24 Feb 1997 21:07:15 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA18982 for ; Mon, 24 Feb 1997 21:58:02 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA08847; Mon, 24 Feb 1997 21:39:44 +0100 From: Peter Gerwinski Message-Id: <199702242039.VAA08847@agnes.dida.physik.uni-essen.de> Subject: Re: GPC in an instructional envionment To: beck@cs.ualberta.ca Date: Mon, 24 Feb 1997 21:39:43 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Phil Nelson: > > For those who really want some sort of a programming envoronment to go > with gpc and are running X, look at xwpe. (X window Programming Environment) > The environment is quite similar to the Turbo-Pascal environment. It also runs without X in an (n?)curses text environment. Those who are running DOS (or OS/2 DOS box or Linux DOSemu or similar things) we can also recommand the RHIDE which is even more similar to the Turbo-Pascal environment. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Feb 25 19:13:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA11060 for ; Tue, 25 Feb 1997 19:13:22 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82530; Tue, 25 Feb 1997 18:30:55 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48672; Tue, 25 Feb 1997 18:31:04 +0100 Received: from dub-img-4.compuserve.com (dub-img-4.compuserve.com [149.174.206.134]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA22528 for ; Tue, 25 Feb 1997 19:22:26 +0200 (EET) Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id MAA17580; Tue, 25 Feb 1997 12:02:43 -0500 Date: 25 Feb 97 12:01:08 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: Frank Heckenbach Cc: gpc Subject: Re: Some bug reports Message-Id: <970225170107_100120.3121_EHU126-1@CompuServe.COM> Status: RO > 1. The output of a compiler program is not redirectable (neither as stdout, > nor stderr). Which platform do you use? It works correctly on FreeBSD. > 2. Writeln('a','':5,'b'); > I think it should write "a b", but it just writes "ab". Correct. > 3. My standard way for "variable size arrays" in BP doesn't work in gpc: gpc doesn't have such limits, but your example should work. > 4. Problem with CONST parameters: > PROCEDURE p(CONST c:t) This is BP, try the EP standard PROCEDURE p(protected c:t) as a workaround. > 5. Initialized set variables don't seem to work: Known bug. > 6. Last but not least: > Is there anything like TP's Exit (return from current procedure/function)? A goto with an explicit label. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Feb 25 21:41:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA11382 for ; Tue, 25 Feb 1997 21:41:01 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77578; Tue, 25 Feb 1997 20:58:31 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51276; Tue, 25 Feb 1997 20:58:41 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA26144 for ; Tue, 25 Feb 1997 21:49:46 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA11294; Tue, 25 Feb 1997 21:31:50 +0100 From: Peter Gerwinski Message-Id: <199702252031.VAA11294@agnes.dida.physik.uni-essen.de> Subject: Re: Some bug reports To: heckenb@mi.uni-erlangen.de Date: Tue, 25 Feb 1997 21:31:50 +0100 (MET) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hallo, Frank; hello, everybody! According to Frank Heckenbach: > 1. > The output of a compiler program is not redirectable (neither as stdout, > nor stderr). Hmmm ... I am redirecting stderr all the time ... what OS are you using? With DJGPP and the BPcompat package, redirection is turned off when DirectVideo is `true'. (And redirection is not easy with DJGPP anyway.) It works fine on my Linux box. > 2. > Writeln('a','':5,'b'); > I think it should write "a b", but it just writes "ab". Okay. I am adding it to my bug list. Thanks. > 3. > My standard way for "variable size arrays" in BP doesn't work in gpc: > > PROGRAM t; > > CONST MaxVar=$FFF0; > > TYPE > X=Integer; > > XArray=ARRAY[1..MaxVar DIV SizeOf(X)] OF X; {} > > BEGIN > END. > > [...] Okay. I am adding it to my bug list. Thanks. :-) Workaround: GPC has no problems to deal with structures above 65520 bytes. (It has a 4GB limit instead.) So you can just write: Const MaxVar = 1000000; (* large random number *) Type X = Integer; XArray = array [ 1..MaxVar ] of X; > 4. > [...] Okay. I am ... etc. :-) > (I could provide all the register values if necessary.) That's not necessary. I have the example program, so I will be able to reproduce the bug. (I hope at least.) Also thanks for the detailed description in which situations the bug occurs. :-) > 5. (See above.:-) > 6. > Last but not least: > Is there anything like TP's Exit (return from current procedure/function)? > I couldn't find it in the docs. Return. But I am planning to support `Exit' as an alternative to it. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Feb 26 17:46:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA13230 for ; Wed, 26 Feb 1997 17:46:36 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61132; Wed, 26 Feb 1997 17:03:50 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45038; Wed, 26 Feb 1997 17:03:58 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA28779 for ; Wed, 26 Feb 1997 17:52:46 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id QAA04475 (8.7.6/7.5c-FAU); for ; Wed, 26 Feb 1997 16:52:42 +0100 (MET) Received: from skylla by mi.uni-erlangen.de with SMTP; id QAA08611 (SMI-8.6/7.5b-FAU); Wed, 26 Feb 1997 16:52:41 +0100 From: Frank Heckenbach Message-Id: <199702261552.QAA08611@helena.mi.uni-erlangen.de> Date: Wed, 26 Feb 1997 15:52:39 GMT To: gpc@hut.fi Subject: Re: Some bug reports Status: RO Peter Gerwinski wrote: 1. > > The output of a compiler program is not redirectable (neither as stdout, > > nor stderr). > > Hmmm ... I am redirecting stderr all the time ... what OS are you using? > With DJGPP and the BPcompat package, redirection is turned off when > DirectVideo is `true'. Yes, I'm using DJGPP - sorry I forgot to mention. It seems redirection is turned off by default even without the BPcompat package. This was confusing me. I don't use Crt in my program, so I didn't think of DirectVideo. Now when I copy the declaration of DirectVideo from Crt (I don't want to use the whole unit in this program), it works. I guess redirection is turned off by default because the usual output via Dos is quite slow!? > (And redirection is not easy with DJGPP anyway.) Why? The only problem I know of is that Command.Com can't redirect stdout. But that's merely a problem of Dos' shell, and is solved by the REDIR utility. Otherwise it works fine for me. Or are there any other problems? 3. > Okay. I am adding it to my bug list. Thanks. :-) > > Workaround: GPC has no problems to deal with structures above 65520 bytes. > [...] Yes, I know. Actually I'm using now: CONST MaxVar=$FFF0; TYPE XArray=ARRAY[1..MaxVar {$IFDEF TP} DIV SizeOf(X) {$ENDIF}] OF X; I'm just hoping to reduce the number of IFDEFs required to get the program working on both TP and gpc. 6. > > Is there anything like TP's Exit (return from current procedure/function)? > > I couldn't find it in the docs. > > Return. Thanks! I really could have guessed that myself... 4. Berend de Boer wrote: > > PROCEDURE p(CONST c:t) > > This is BP, try the EP standard > > PROCEDURE p(protected c:t) > > as a workaround. Yes, that works. Thanks! With the help of the preprocessor (luckily it's case-sensitve!), I can even write the following code that compiles with TP and gpc: {$DEFINE Const PROTECTED} CONST a=1; PROCEDURE p(Const c:t); 7. ...but this led me to another problem. It seems more involved (perhaps something about GPI files?). I couldn't simplify the example more than the following, especially there has to be a unit, r must be a record (at least with r=Integer the bug doesn't show), and p has to be protected: UNIT u; INTERFACE TYPE r=RECORD a:Integer END; PROCEDURE f(PROTECTED p:r); IMPLEMENTATION PROCEDURE f(PROTECTED p:r); BEGIN END; END. PROGRAM x; USES u; VAR p:r; BEGIN f(p) {} END. gpc complains about line {}: incompatible type for argument 1 of `F' Frank From gpc-request@santra.hut.fi Wed Feb 26 21:14:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA13704 for ; Wed, 26 Feb 1997 21:14:44 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66688; Wed, 26 Feb 1997 20:31:55 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38228; Wed, 26 Feb 1997 20:32:07 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA03250 for ; Wed, 26 Feb 1997 21:24:19 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA13625; Wed, 26 Feb 1997 21:06:35 +0100 From: Peter Gerwinski Message-Id: <199702262006.VAA13625@agnes.dida.physik.uni-essen.de> Subject: Re: Some bug reports To: heckenb@mi.uni-erlangen.de, gpc@hut.fi Date: Wed, 26 Feb 1997 21:06:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > Yes, I'm using DJGPP - sorry I forgot to mention. It seems redirection is > turned off by default even without the BPcompat package. This was confusing > me. I don't use Crt in my program, so I didn't think of DirectVideo. Now when > I copy the declaration of DirectVideo from Crt (I don't want to use the > whole unit in this program), it works. Sorry for that inconvenience; now `libgpc.a' will get "DirectVideo = false" by default. > I guess redirection is turned off by default because the usual output via > Dos is quite slow!? No, it was just a bug in the patched `libgpc.a'. (The unpatched version of `libgpc.a' from the gpc-2.0 distribution should work.) > > (And redirection is not easy with DJGPP anyway.) > > Why? The only problem I know of is that Command.Com can't redirect stdout. You mean: `stderr'. > But that's merely a problem of Dos' shell, and is solved by the REDIR > utility. Otherwise it works fine for me. Or are there any other problems? That's what I meant with "not easy": you need `REDIR' to redirect `stderr'. > 3. > Yes, I know. Actually I'm using now: > CONST MaxVar=$FFF0; > TYPE XArray=ARRAY[1..MaxVar {$IFDEF TP} DIV SizeOf(X) {$ENDIF}] OF X; The bug is fixed for the next alpha release. If you want the patch now, here is the diff for gpc-parse.y: if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); - if (TREE_TYPE ($1) != TREE_TYPE ($3)) + if (TREE_TYPE ($1) == TREE_TYPE ($3) + || (TREE_CODE (TREE_TYPE ($1)) == INTEGER_TYPE + && TREE_CODE (TREE_TYPE ($3)) == INTEGER_TYPE)) + $$ = build_range_type (TREE_TYPE ($1), $1, $3); + else { error ("subrange bounds are not of the same type"); $$ = error_mark_node; } - else - /* @@@ Changed in 2.4.3.1 */ - $$ = build_range_type (TREE_TYPE ($1), $1, $3); } ; > 6. > > > Is there anything like TP's Exit (return from current procedure/function)? > > > I couldn't find it in the docs. `Return'. In the alpha versions, `Exit' works, too. > 4. > {$DEFINE Const PROTECTED} > [...] > PROCEDURE p(Const c:t); That bug is fixed as well. Here is the diff for gpc-util.c: } else { + if (varparm && type != error_mark_node) + type = build_reference_type (type); + /* If this is a protected parameter, make it read-only */ if (protected) type = build_type_variant (type, 1, 0); - if (varparm && type != error_mark_node) - type = build_reference_type (type); - type = build_tree_list (NULL_TREE, type); for (link = idlist; link; link = TREE_CHAIN(link)) > 7. > ...but this led me to another problem. It seems more involved (perhaps > something about GPI files?). Yes. :-( It's a known bug in the GPI mechanism that pointer types transported through a GPI file aren't compatible with themselves. > gpc complains about > line {}: incompatible type for argument 1 of `F' To work around, patch your gpc-decl.c (or wait for the next alpha), and use `Const' :-P instead fo `Protected'. Then you will get some warnings, but the code will work. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Feb 27 01:04:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA14063 for ; Thu, 27 Feb 1997 01:04:33 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82104; Thu, 27 Feb 1997 00:21:40 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41674; Thu, 27 Feb 1997 00:21:51 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA09736 for ; Thu, 27 Feb 1997 01:15:42 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA14001 for gpc@hut.fi; Thu, 27 Feb 1997 00:58:11 +0100 From: Peter Gerwinski Message-Id: <199702262358.AAA14001@agnes.dida.physik.uni-essen.de> Subject: New Alpha To: gpc@hut.fi Date: Thu, 27 Feb 1997 00:58:10 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! The next alpha release, gpc-970226, is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. This time I also provide binaries for FreeBSD - besides binaries for DOS (DJGPP) and Linux (ELF) - because there were many modifications in GPC's Extended Pascal sections. ;-) Changes since gpc-970221: * First Delphi extension: allow an optional source file name (a String constant) with `uses': Program Foo; uses MyUnit in 'my_pretty_unit.pas'; ... * The documentation now describes how `--standard-pascal', `--extended-pascal', `--borland-pascal', etc. work. There were more changes in the documentation, especially in the "Borland Pascal" chapter. * `Absolute' now works with initialized Strings, too. (Was a well-hidden bug.) * Sets of enumeral types work again. (This was broken in gpc-970215.) * Extended Pascal Modules: Now each module "foo" produces a file "foo.gpm" (GNU Pascal Module) which contains the names of the exported Interfaces, so an Implementation Module residing in a separate file can locate the GPI files. * Do not crash when an array TYPE instead of an array is passed as a `Var' parameter ... :-) * `Const' parameters (Borland Pascal) - same as `Protected Var' parameters (Extended Pascal) - work. * Initialize arrays of Strings correctly. * Extended Pascal initializers: They do not yet work in all cases, but at least in some now. Beware: array indices and record field names are not checked at all; it is assumed that they are in order without "holes". (The same problem holds for record field names with Borland Pascal initializers.) * Initialized Sets still don't work. Sorry. * Modules (Extended Pascal) and Units (Borland Pascal) which are in the same file as the main program do not any more export everything. Now they just export the exported stuff ... well almost. Functions are still exported even if you don't want to export them, but you get a warning. Beware: Since all export is done through GPM and GPI files, this disables the workaround to put everything into one file in case the GPI mechanism fails. This means that GPI *must* become stable now ... * `--automake' won't any more enter an infinite loop when it detects that the module to be recompiled is in the current file. * Virtual Methods and Constructors now survive transport through a GPI file. * Make the option `-x pascal' work. * Subrange specifications like array indices did not work in all situation. Now they do. I'd like to thank Larry Carter, Stefan A. Deutscher, Berend de Boeur, Pat Sharp, and Frank Heckenbach for useful hints, bug reports and very helpful example programs. I am keeping all example programs in a "GPC test suite" to ensure that reported bugs won't recur and implemented new features don't break. :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Feb 27 12:40:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA15627 for ; Thu, 27 Feb 1997 12:40:42 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81000; Thu, 27 Feb 1997 11:57:39 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44974; Thu, 27 Feb 1997 11:57:52 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA24462 for ; Thu, 27 Feb 1997 12:48:44 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id MAA15547 for gpc@hut.fi; Thu, 27 Feb 1997 12:31:21 +0100 From: Peter Gerwinski Message-Id: <199702271131.MAA15547@agnes.dida.physik.uni-essen.de> Subject: First bugs in gpc-970226 ... To: gpc@hut.fi Date: Thu, 27 Feb 1997 12:31:20 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello again, sorry, but I overlooked a small, but severe bug in gpc-970226 which made in impossible to redefine built-in identifiers like "Byte" or "Assign" in Units - which is especially annoying because GPC does define, but not yet implement "Assign", so you *must* redefine it. As a side-effect, another bug vanished, too: Unexported functions were visible in the whole file. Now they have the correct scope. (: Yes, I know how this is related to redefinitions of built-in identifiers. ;) And there was another bug preventing us to initialize variables of a type which has been previously declared to be "Char" in a Unit or Module. (Weird, eh?:-) Below is the patch to make it all work; it's on agnes as well. I will upload new binaries this evening, about 23:00 MET. Till the next bug fix, Peter 8< ----------------------------------------------------------------------- --- gpc-970226/gpc-module.c Thu Feb 27 11:34:07 1997 +++ gpc/gpc-module.c Thu Feb 27 11:11:48 1997 @@ -1120,10 +1120,10 @@ store_flags (t, s); if (depth == 0) { - if (IDENTIFIER_GLOBAL_VALUE (t)) - store_tree (IDENTIFIER_GLOBAL_VALUE (t), s, depth + 1); - else if (IDENTIFIER_LOCAL_VALUE (t)) + if (IDENTIFIER_LOCAL_VALUE (t)) store_tree (IDENTIFIER_LOCAL_VALUE (t), s, depth + 1); + else if (IDENTIFIER_GLOBAL_VALUE (t)) + store_tree (IDENTIFIER_GLOBAL_VALUE (t), s, depth + 1); else store_tree (IDENTIFIER_LIMBO_VALUE (t), s, depth + 1); } @@ -1388,7 +1388,7 @@ t = get_identifier (id); load_flags (t, s); if (depth == 0) - IDENTIFIER_GLOBAL_VALUE (t) = load_tree (s, depth + 1); + IDENTIFIER_LOCAL_VALUE (t) = load_tree (s, depth + 1); break; } --- gpc-970226/gpc-typeck.c Thu Feb 27 11:34:07 1997 +++ gpc/gpc-typeck.c Thu Feb 27 11:26:33 1997 @@ -5811,6 +5811,9 @@ /* Handle scalar types, including conversions. */ if (code == INTEGER_TYPE || code == REAL_TYPE || code == POINTER_TYPE +#ifdef GPC + || code == CHAR_TYPE +#endif || code == ENUMERAL_TYPE || code == COMPLEX_TYPE) { /* Note that convert_for_assignment calls default_conversion From gpc-request@santra.hut.fi Thu Feb 27 20:12:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA16076 for ; Thu, 27 Feb 1997 20:12:41 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84656; Thu, 27 Feb 1997 19:29:32 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37452; Thu, 27 Feb 1997 19:29:45 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA11702 for ; Thu, 27 Feb 1997 20:01:16 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id TAA12036 (8.7.6/7.5c-FAU); for ; Thu, 27 Feb 1997 19:01:13 +0100 (MET) Received: from skylla by mi.uni-erlangen.de with SMTP; id SAA15563 (SMI-8.6/7.5b-FAU); Thu, 27 Feb 1997 18:57:54 +0100 From: Frank Heckenbach Message-Id: <199702271757.SAA15563@helena.mi.uni-erlangen.de> Date: Thu, 27 Feb 1997 17:57:53 GMT To: gpc@hut.fi Subject: Re: Some bug reports - and success report Status: RO > > > (And redirection is not easy with DJGPP anyway.) > > Why? The only problem I know of is that Command.Com can't redirect stdout. > You mean: `stderr'. Yes, of course. > > But that's merely a problem of Dos' shell, and is solved by the REDIR > > utility. Otherwise it works fine for me. Or are there any other problems? > That's what I meant with "not easy": you need `REDIR' to redirect `stderr'. Well, at least there is such a utility. If that was the biggest problem with Command.Com, it would be great... :-( > Yes. :-( It's a known bug in the GPI mechanism that pointer types > transported through a GPI file aren't compatible with themselves. > > To work around, patch your gpc-decl.c (or wait for the next alpha), > and use `Const' :-P instead fo `Protected'. Then you will get some > warnings, but the code will work. Just wondering - what's the difference between "Const" and "Protected" parameters? Are they only handled differently internally in the compiler, or is there any semantic difference? Another set problem is the following: PROGRAM x; TYPE IByte=__byte__ Integer; Byte=__unsigned__ IByte; TS=SET OF Byte; PROCEDURE p(s:TS); VAR k:Integer; BEGIN FOR k:=0 TO $FF DO IF k IN s THEN Write(k) END; BEGIN p([]) END. Again, more or less random values. It's probably another instance of the problem with initialized set variables - I just wanted to mention it. But after I could work around this, too, now my program compiles and runs with gpc for the first time! :-) And a whole lot faster than compiled with BP! :-) Frank From gpc-request@santra.hut.fi Fri Feb 28 00:27:30 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA16481 for ; Fri, 28 Feb 1997 00:27:30 +0100 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73906; Thu, 27 Feb 1997 23:44:16 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48748; Thu, 27 Feb 1997 23:44:28 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA17627 for ; Fri, 28 Feb 1997 00:39:32 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA16435 for gpc@hut.fi; Fri, 28 Feb 1997 00:22:19 +0100 From: Peter Gerwinski Message-Id: <199702272322.AAA16435@agnes.dida.physik.uni-essen.de> Subject: Re: Some bug reports - and success report To: gpc@hut.fi Date: Fri, 28 Feb 1997 00:22:18 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > Just wondering - what's the difference between "Const" and "Protected" > parameters? Are they only handled differently internally in the compiler, > or is there any semantic difference? `Protected' is a "modifier" which can be used with or without `Var' in formal parameters. `Const' parameters are the same as `protected Var' parameters, thus `protected Var' also yields a workaround for the "`protected' in GPI files" bug. > Another set problem is the following: > [...] > Again, more or less random values. It's probably another instance of the > problem with initialized set variables - I just wanted to mention it. I am adding this to ... you know. Thanks again! > But after I could work around this, too, now my program compiles and runs with > gpc for the first time! :-) And a whole lot faster than compiled with BP! :-) :-) :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 4 19:09:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA26989 for ; Tue, 4 Mar 1997 19:09:33 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63426; Tue, 4 Mar 1997 18:24:43 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA32104; Tue, 4 Mar 1997 18:24:29 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA32462 for ; Tue, 4 Mar 1997 19:17:39 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id SAA06385 (8.7.6/7.5c-FAU); for ; Tue, 4 Mar 1997 18:17:31 +0100 (MET) Received: from kirke by mi.uni-erlangen.de with SMTP; id SAA02401 (SMI-8.6/7.5b-FAU); Tue, 4 Mar 1997 18:17:30 +0100 From: Frank Heckenbach Message-Id: <199703041717.SAA02401@helena.mi.uni-erlangen.de> Date: Tue, 4 Mar 1997 17:17:30 GMT To: gpc@hut.fi Subject: Re: Protected parameters (Was: Some bug reports - and success report) Status: RO Peter Gerwinski wrote: > According to Frank Heckenbach: > > Just wondering - what's the difference between "Const" and "Protected" > > parameters? Are they only handled differently internally in the compiler, > > or is there any semantic difference? > > `Protected' is a "modifier" which can be used with or without `Var' > in formal parameters. `Const' parameters are the same as `protected > Var' parameters Does that mean that protected (not protected var) parameters are passed by value? Especially in the case of large structures, can this be inefficient, taking up stack space and consuming time to copy the arguments? Since protected parameters are read-only anyway, actually I see no need to distinguish between passing them by value or by reference. Of course, it would be best if the compiler could automatically choose the more efficient way of passing (i.e. small structures by value, and large ones by reference), no matter if declared as "protected", "protected var" or "const". Or does the standard prescribe something different? Also, defining "Const" as "protected Var" is not completely compatible to BP, since in BP you can pass a calculated expression, not only an "lvalue" as a const parameter. But of course, these are no urgent issues, as long as one form of protected/const parameters works at all... :-) Frank -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sat Mar 8 17:48:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA01645 for ; Sat, 8 Mar 1997 17:48:27 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90990; Sat, 8 Mar 1997 17:02:13 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72898; Sat, 8 Mar 1997 17:02:16 +0100 Received: from hil-img-2.compuserve.com (hil-img-2.compuserve.com [149.174.177.132]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA31875 for ; Sat, 8 Mar 1997 17:59:36 +0200 (EET) Received: by hil-img-2.compuserve.com (8.6.10/5.950515) id KAA08855; Sat, 8 Mar 1997 10:59:05 -0500 Date: 08 Mar 97 10:57:49 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Protected parameters, 2nd try Message-Id: <970308155748_100120.3121_EHU126-1@CompuServe.COM> Status: RO Oops, sended the msg already. Here again: >> Does that mean that protected (not protected var) parameters >> are passed by value? Especially in the case of large >> structures, can this be inefficient, taking up stack space >> and consuming time to copy the arguments? > Yes. :-( >> Or does the standard prescribe something different? > Yes. It requires that the value of the protected formal > parameter cannot change during the execution of the function, The standard doesn't define it this way. I too think that protected should be treated exactly like var parameters, or whatever is as efficient or more efficient (that's why I use const parameters for in Borland Delphi). The standard says this about protected parameters: peter is essentially correct. (and my initial sentence was incorrect) After a 2nd reading and some trying I don't see a better way to implement it. The compiler would have a really hard job to change protected to protected var when that is allowed. There is a few cases where it might be a little bit less hard. I think the case when there are no var parameters (so there is no aliasing) protected should be protected var. Groetjes, Berend. From gpc-request@santra.hut.fi Sat Mar 8 16:56:05 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA01607 for ; Sat, 8 Mar 1997 16:56:05 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86452; Sat, 8 Mar 1997 16:09:50 +0100 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59920; Sat, 8 Mar 1997 16:09:53 +0100 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA10922; Sat, 8 Mar 97 14:12:04 +0100 Received: from hil-img-4.compuserve.com (hil-img-4.compuserve.com [149.174.177.134]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA30677 for ; Sat, 8 Mar 1997 15:01:26 +0200 (EET) Received: by hil-img-4.compuserve.com (8.6.10/5.950515) id IAA09545; Sat, 8 Mar 1997 08:00:54 -0500 Date: 08 Mar 97 08:00:05 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Protected parameters Message-Id: <970308130004_100120.3121_EHU67-1@CompuServe.COM> Status: RO >> Does that mean that protected (not protected var) parameters >> are passed by value? Especially in the case of large >> structures, can this be inefficient, taking up stack space >> and consuming time to copy the arguments? > Yes. :-( >> Or does the standard prescribe something different? > Yes. It requires that the value of the protected formal > parameter cannot change during the execution of the function, The standard doesn't define it this way. I too think that protected should be treated exactly like var parameters, or whatever is as efficient or more efficient (that's why I use const parameters for in Borland Delphi). The standard says this about protected parameters: From gpc-request@santra.hut.fi Sat Mar 8 02:04:52 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA01196 for ; Sat, 8 Mar 1997 02:04:52 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87086; Sat, 8 Mar 1997 01:18:53 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59226; Sat, 8 Mar 1997 01:18:55 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA25580 for ; Sat, 8 Mar 1997 02:12:23 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA01137 for gpc@hut.fi; Sat, 8 Mar 1997 01:57:43 +0100 From: Peter Gerwinski Message-Id: <199703080057.BAA01137@agnes.dida.physik.uni-essen.de> Subject: Re: Protected parameters To: gpc@hut.fi Date: Sat, 8 Mar 1997 01:57:43 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > Does that mean that protected (not protected var) parameters are passed > by value? Especially in the case of large structures, can this be > inefficient, taking up stack space and consuming time to copy the > arguments? Yes. :-( > Since protected parameters are read-only anyway, actually I see no need > to distinguish between passing them by value or by reference. Of course, > it would be best if the compiler could automatically choose the more > efficient way of passing (i.e. small structures by value, and large ones > by reference), no matter if declared as "protected", "protected var" or > "const". I agree. But ... > Or does the standard prescribe something different? Yes. It requires that the value of the protected formal parameter cannot change during the execution of the function, so things like the following require it to pass everything by value: Var X: Something; Procedure foo ( protected a: Something; Var b: Something ); begin (* foo *) b:= SomeValue; end (* foo *); begin foo ( X, X ); end. (One might ask what purpose `protected' serves when it requires to pass everything by value anyway ... ;-) > Also, defining "Const" as "protected Var" is not completely compatible to BP, > since in BP you can pass a calculated expression, not only an "lvalue" as a > const parameter. I have planned to enable this, too. Then `Const' parameters will indeed be something different than `protected' ones. It could be a good idea to pass small things by value for `Const' parameters ... and relatively easy to implement ... Okay, I am working on it, but ... > But of course, these are no urgent issues, as long as one form of > protected/const parameters works at all... :-) ... with low priority. ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Mar 9 14:51:32 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA02673 for ; Sun, 9 Mar 1997 14:51:32 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83276; Sun, 9 Mar 1997 14:04:57 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30120; Sun, 9 Mar 1997 14:05:01 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA07913 for ; Sun, 9 Mar 1997 14:53:24 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA02601 for gpc@hut.fi; Sun, 9 Mar 1997 14:39:19 +0100 From: Peter Gerwinski Message-Id: <199703091339.OAA02601@agnes.dida.physik.uni-essen.de> Subject: Re: Protected parameters, 2nd try To: gpc@hut.fi Date: Sun, 9 Mar 1997 14:39:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > There is a few cases where it might be a little bit less hard. I think the case > when there are no var parameters (so there is no aliasing) protected should be > protected var. No chance: Var x: Integer; Procedure Bar ( protected y: Integer ); begin (* Bar *) x:= 3; end (* Bar *); ... Bar ( x ); It needn't be an explicit assignment; it might be a call to a function which makes the value of `x' change. To pass everything by value *is* the only possibility. But I will modify `Const' parameters to pass small things by value and to work with implicit temporary variables when a constant is passed as a `Const' parameter. Then it's up to the programmer to take care that the `Const' parameter doesn't change its value due to side effects. Hmmm ... how to tread `protected Var' parameters??? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 11 14:26:37 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA06931 for ; Tue, 11 Mar 1997 14:26:37 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70724; Tue, 11 Mar 1997 13:39:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55826; Tue, 11 Mar 1997 13:39:28 +0100 Received: from hil-img-2.compuserve.com (hil-img-2.compuserve.com [149.174.177.132]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA10732 for ; Tue, 11 Mar 1997 14:13:00 +0200 (EET) Received: by hil-img-2.compuserve.com (8.6.10/5.950515) id HAA09023; Tue, 11 Mar 1997 07:12:30 -0500 Date: 11 Mar 97 07:10:13 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Protected parameters, 2nd try Message-Id: <970311121012_100120.3121_EHU52-3@CompuServe.COM> Status: RO > Hmmm ... how to tread `protected Var' parameters??? Exactly like const or vice versa (like Borland does: push small bytes on the stack, pass structures as pointers). With protected var the programmer is on his own. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Mar 11 14:22:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA06902 for ; Tue, 11 Mar 1997 14:22:25 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94730; Tue, 11 Mar 1997 13:35:08 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55944; Tue, 11 Mar 1997 13:35:16 +0100 Received: from hil-img-2.compuserve.com (hil-img-2.compuserve.com [149.174.177.132]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA10667 for ; Tue, 11 Mar 1997 14:13:00 +0200 (EET) Received: by hil-img-2.compuserve.com (8.6.10/5.950515) id HAA09017; Tue, 11 Mar 1997 07:12:29 -0500 Date: 11 Mar 97 07:10:12 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Protected parameters, 2nd try Message-Id: <970311121011_100120.3121_EHU52-2@CompuServe.COM> Status: RO > would it be necessary that const parameters have > clear semantics concerning side-effects? It doesn't hurt to document them. But the standard already defines protected var as alias dependent, so you should not use that case (it's always a bug, there is no program where this feature is useful or required). I've been hurt by using Borland's const a few times myself (in a case like Peter described). BTW, const and protected var are the same. There is no difference between them. This is mainly a way of saying: this var shouldn't altered (source code as documentation) and speed up it's parameter passing. protected is: this variable shouldn't be altered, even if I make a mistake (by aliasing some things), parameter passing speed is not a problem. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Mar 11 14:21:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA06898 for ; Tue, 11 Mar 1997 14:21:03 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90490; Tue, 11 Mar 1997 13:33:47 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41106; Tue, 11 Mar 1997 13:33:54 +0100 Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [149.174.217.134]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA10703 for ; Tue, 11 Mar 1997 14:10:53 +0200 (EET) Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id HAA17683; Tue, 11 Mar 1997 07:10:22 -0500 Date: 11 Mar 97 07:10:10 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: gpc Subject: Re: Variable number of parameters Message-Id: <970311121010_100120.3121_EHU52-1@CompuServe.COM> Status: RO I think if you really want var args, function overloading, powerfull preprocessors, etc. program in C or C++. Don't fool with Pascal's identity. And I think 99.9% of what people want with varargs can be quite cleanly implemented with Borland's open array and with variant arrays (boy, I need to use them sometimes, but it's quite bad to let the customer find typechecking bugs...) Groetjes, Berend. From gpc-request@santra.hut.fi Tue Mar 11 13:35:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA06833 for ; Tue, 11 Mar 1997 13:35:35 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95164; Tue, 11 Mar 1997 12:48:20 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26398; Tue, 11 Mar 1997 12:48:27 +0100 Received: from camel6.mindspring.com (camel6.mindspring.com [204.180.128.212]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA09077 for ; Tue, 11 Mar 1997 13:37:33 +0200 (EET) Received: from monstro (mule1.mindspring.com [204.180.128.167]) by camel6.mindspring.com (8.8.5/8.8.5) with SMTP id GAA16455 for ; Tue, 11 Mar 1997 06:37:31 -0500 (EST) Message-Id: <332543D3.F69@mindspring.com> Date: Tue, 11 Mar 1997 06:36:51 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: GNU Pascal Subject: varargs in GPC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi, I thought that GPC did not support varargs. In fact, I was hoping that it would support the VAX Pascal syntax for doing so. What is the status of variable arguments for GPC? -- Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Tue Mar 11 10:03:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA06562 for ; Tue, 11 Mar 1997 10:03:55 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70836; Tue, 11 Mar 1997 09:16:43 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38292; Tue, 11 Mar 1997 09:16:50 +0100 Received: from ilex.FernUni-Hagen.de (ilex.fernuni-hagen.de [132.176.114.22]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id KAA31948 for ; Tue, 11 Mar 1997 10:12:44 +0200 (EET) Received: from prt-s5.fernuni-hagen.de by ilex.FernUni-Hagen.de with SMTP (PP); Tue, 11 Mar 1997 09:11:27 +0100 Received: from prt-s5 by prt-s5.fernuni-hagen.de (SMI-8.6/SMI-SVR4) id JAA00475; Tue, 11 Mar 1997 09:11:23 +0100 Sender: duehr@FernUni-Hagen.de Message-Id: <332513AB.7DE3@fernuni-hagen.de> Date: Tue, 11 Mar 1997 09:11:23 +0100 From: Stephan Duehr Organization: FernUni Hagen E-Technik PRT X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: GNU Pascal mailing list Subject: gpc and gcc 2.7.2.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi, I have install gcc and would like to take 2.7.2.2. I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult to make it work with 2.7.2.2? -- Stephan Duehr ---------------------------------------------- From gpc-request@santra.hut.fi Mon Mar 10 17:18:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA04948 for ; Mon, 10 Mar 1997 17:18:23 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93522; Mon, 10 Mar 1997 16:31:24 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40914; Mon, 10 Mar 1997 16:31:29 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA12469 for ; Mon, 10 Mar 1997 17:24:24 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id QAA29688 (8.7.6/7.5c-FAU); for ; Mon, 10 Mar 1997 16:23:49 +0100 (MET) Received: from skylla by mi.uni-erlangen.de with SMTP; id QAA24822 (SMI-8.6/7.5b-FAU); Mon, 10 Mar 1997 16:24:14 +0100 From: Frank Heckenbach Message-Id: <199703101524.QAA24822@helena.mi.uni-erlangen.de> Date: Mon, 10 Mar 1997 15:24:13 GMT To: gpc@hut.fi Subject: Variable number of parameters Status: RO In news:comp.lang.pascal.borland, there's just a discussion about variable number/types of procedure/function parameters going on. Since Borland Pascal doesn't support this, the discussion has moved quite a bit away from BP towards gpc. That's why I'm forwarding my posting to this list. The complete thread can be seen in the mentioned newsgroup under the same subject as this mail. Perhaps there are some more ideas about this topic in the gpc community, or even some of the things below have been implemented that I don't know about. Certainly, this would rather be a long-time project, and it's not as urgent as removing bugs and implementing some other nice features... Norsk / Hoaxers wrote (in several postings, cut together): > On Tue, 04 Mar 1997 04:46:26 GMT, rdonais@southeast.net (R.E.Donais) > wrote: > > >Since Pascal knows the file is a text file, the programmer is not required to > >perform conversions on binary values. In "C", the programmer would at some > >point have to convert the integer to string using something like itoa(). Not explicitly call itoa(), but (s)he'd have to specify the type by a format specifier ("%d") in the format string. This, of course, provides no means of type checking, and is therefore not suited for Pascal. > >I doubt that you want to write separate routines for every combination of > >variables that you plan to write to a text file. Yet, that's what you imply in > >your example. :-\ Yes, I think one has to distnguish overloading from "varargs" (allowing to pass any number and type of parameters). Many useful things can be done with overloading, but Writeln definitely needs varargs, otherwise you'd have to declare an infinite number of Writeln variants. > It was JUST an example. Allow me to give you a better one: > > Load_PcxPicture(s:String;segg,off:Word; > Load_PcxPicture(s:String;segg,off:Word;var Pal:Palettestructure); I don't think it's a good example. In this case, I would pass Pal as a pointer with NIL meaning no palette. Easy to implement and easy to call. I don't think you would write two procedures with similar functionality, so in the end, you'd probably be doing something like this, anyway. But this would be a case for default values as in C++. If you could declare something like procedure LPP(s:String;segg,off:Word;PPal:PPalettestructure value NIL); and call it with wither 3 or 4 parameters (in the former case, the 4th parameter would be implicitly NIL), that would be nice sometimes... (Yet another feature that could be desirable!) > No, i didnt miss it at all, i just found it silly actually. You see, > by implementing "variable syntax" or whatever i should call it, you > dont make it like cobol, basic, fortran or whatever, you -just- make > it more flexible. whats so friggin wrong about that? I really dont > understand whats wrong with it. I don't think there's anything wrong with it, but Borland will not do it. They've dropped TP, face it! So if you want these changes, don't look at TP, but perhaps at GNU Pascal. AFAIK, gpc already supports declaring and calling a procedure with variable arguments, like C - but only to allow calling C functions with varargs. There's not (yet) a way to implement such a procedure in Pascal, but the gpc developers are always looking to enhance the language, so if you've got some concrete ideas (or can even help to work on the compiler), you're always welcome to join the team. > Thats not what I where aiming at. You could make the product better, > and alas get more satisfied customers. That's how the gpc developers/maintainers feel too, I think. > As far as i can remember (this might be wrong) GNU pascal dont have > oop. By now, AFAIK, gpc has (nearly) the same OOP as TP, but doesn't implement the Object Pascal (not-yet-)standard. > >To each his own. If you want overloading and procedures with variable number of > >parameters, then check out languages that support them. > Belive me, I have .. But I really dont like C. Its so.. what should I > say.. pee->(wee&&) .. I just dont like it :) I don't think that's valid in C (provided there's anything that's not valid in C - not sure if there is... :-> ), but I know what you mean. I'd also prefer to have the Pascal syntax and yet many of the other features. > I think that would be a bit to much trouble really. I was just > presenting the idea to get a feeling of other people's thoughts on > the matter. If you're serious about it, join the gpc mailing list. I'll post a copy of this message to the list, since it's quite much about gpc. > Writeln, reset, and a whole bunch of others allready support it. it's > just not any way for the -user- to define procedures like that. > > and that is a shame . :) But of course, it's much more difficult to provide a way for the user to declare and implement such procedures than to just allow some specially handled procedures like Writeln. > >Works great as long as it's blindingly obvious which one is going to be > >called, but consider the following: > > > > Procedure MyProc(C: Char); > > Begin ... End; > > Procedure MyProc(S: String); > > Begin ... End; > > Begin > > MyProc('A'); > > End. > > In that example, you would use the c:char. I guess you would need a > set of rules, but these rules are allready implemented in borland > pascal, since some procedures have this. They have just stopped US > from defining such procedures. That's indeed a problem. The only predefined procedure with this particular ambiguity is (AFAICS) Write[ln], and there it doesn't matter which one is called because the result is the same. That would not be true in general if the user could define the procedures. > I see a couple of -possible- solutions to this. > > One, not very good, would be to require VAR types in function > overloading (thats what you called it, right?), like this: > function f(var nr:byte); > > This would remove the problem all together, but its not a very > flexible way of doing it. Quite restricting... I'm curious for other suggestions. If you have some, just tell us about them. There are problems with ambiguities, and they can be worse than here, as AME demonstrated. One has to find a way to cope with them (or restrict so much that no ambiguities remain). And of course, the rules should be relatively logical and comprehensible and implementable and ... :-) >As a side note: Doesn't FPK support function overloading? > > ?? It does? AME replied: > Either FPK or GNU, I can't remember which. I can't even remember if it > was fully implemented. AFAIK, gpc supports part of the PCSX (Pascal scientific extensions) standard. I don't know this standard, and haven't used these extensions, but I think there is some kind of overloading. You might want to find out if there were any ambiguity problems involved, and how they were solved. > On Wed, 05 Mar 97 07:05:42 GMT, babis@hol.gr (Babis Athineos) wrote: > > >Once upon a time a programmer made a tiny little mistake: > >instead of writing procedure Store (var S:TStream); > >he wrote........ procedure Store (var S:PStream); > >Did you see the difference? Store procedures in TV use the stream, > >not the pointer. Pascal compiler would normally find the mistake. > >But Store procedures are not called normally. You pass the address > >of the procedure in a TStreamRec structure and then a TStream.Put > >method calls the Store procedure via the address you passed. No > >type checking! So everything worked OK, except that it didn't save > >right... (I hope I remember correctly the details of the error - > >it's been some years and I don't have the time to try it again...) > > > >Did you get the point? To me the point is that the extensions, however implemented, must still allow Pascal's strong type checking. (In this example, the type checking was annulled by assembler code, type casts or (unnecessarily) untyped pointers, I'd guess from what I know about TV.) > >with variable number and type of parameters, I wouldn't normally > >use it (except maybe in cases like Writeln), but I would consider > >it useful. But if I couldn't choose (e.g. $VT-), I would say it > >is not a Pascal any more... > > I agree fully!! It's a matter of being allowed to chose! Sure. And gpc already has compiler switches to ensure that certain features are [not] used. All the extensions discussed here would be object to these (or additional) switches, too. At last, I've got some suggestions for the varargs problem, too: Apart from overloading (which I'm not talking about now), I'd suggest the following two extensions. Both of them combined would be something like "typed varargs", and allow declaring and implementing Writeln et al.: 1. Unknown number of arguments To the procedure, this would be very much like Open Arrays (cf. TP/BP 7.0). The procedure could get their number with (something like) High, and access them (e.g.) as Parameter[i]. To the caller, however, it's much easier to write than with an Open Array. Anyone who's used these WVSPrintf (or similar) things in TP knows what I mean (declaring an array, assigning the parameters to the elements of the array and then calling the procedure with the array as an argument...) Alternatively, it would suffice to allow "array expressions" like: procedure varnumargs(p:array of integer); begin ... end; var a,b,c:integer; begin varnumargs( (a,b,c,2,c-b,27) ) {^^^^^^^^^^^^^^^^ array declaration as in a "typed const"} end. Ok, one pair of brackets more, but OTOH this allows for more than one open array in the parameter list of a procedure, like: anyproc( (...,...,...),(...,...) ) Probably both ways are useful and have their place... 2. Unknown type of an argument Ok, there are untypes arguments in TP, but they don't allow for any type checking when used, so they're not suited here. Furthermore, the procedure doesn't get any information about the type, so this information would have to be passed separately (as in the printf format string in C), which is not acceptable. So the type must be passed internally, and there must be a way for the procedure to check the type, and to access the parameter as its real type. I could imagine something like the following: procedure Write(Const a); var s:String[255]; begin IFTYPE a,Boolean then if a then WriteStr('True') else WriteStr('False') {^^^^^^^^ this is legal, since a is a Boolean now} else CASETYPE a OF Char: WriteStr(a); {Now a is a Char} String: WriteStr(a); {Here, a is a String - String would include any string type, not just String[255]} LongInt: {Since any integer type in TP can be seen as a subrange of LongInt, this includes all integer types.} begin {In this block, a is an integer} if a<0 then begin WriteStr('-'); a:=-a end; ... end; Real: ...; Extended:...; ... else Error('Cannot write variables of this type!') end end; Note the IFTYPE statement. It would not just check for the type of a, but if successful, cast a into this type for the "then" block. Since the block can only be reached if the type matches, this is type-safe. Similarly the CASETYPE, only for simplified writing. (Of course, the IFTYPE above could be part of the CASETYPE, I just wanted to show both ways.) (This syntax is only tentative, it doesn't have to be called IFTYPE and CASETYPE.) Of course, the SizeOf function would work on a and return the actual size. I pointed to some possible problems with "similar" types (string types, subranges). There will be some problems (e.g. subranges with different sizes, esp. with reference parameters), but I think they can be solved. Of course, it would be nice to elimiate the "else" of the CASETYPE above, and instead cause a compiler error at any attempt to call the procedure with any type not listed in CASETYPE. This would be a behaviour like the real Write. One has to investigate if and how this is possible (considering multiple, possibly nested IFTYPEs/CASETYPEs)... Another idea is whether it is possible and/or useful to compare types of different arguments: procedure equal(const a,b); begin IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b} else Error('Comparison of different types not allowed!') {^^^ or again, rather a compiler error...} end; It also seems useful to declare local variables of the same type as an argument: procedure swap(var a,b); var temp:TYPEOF(a); begin IFTYPE a,b then begin temp:=a;a:=b;b:=temp end else Error('Swapping different types not allowed!') {see above} end; (I think, Extended Pascal (gpc???) has some kind of type inquiry, but probably only for known types. Anyway, this one could, of course, use the same syntax as EP (it's probably not the syntax above, since I don't know the EP syntax).) Concerning the implementation, I'd say that for each "vartype" parameter an additional (invisible) parameter is passed that describes the type uniquely. Since the compiler has to keep track of all the types somehow anyway, it shouldn't be hard to generate a unique number for each type. The numbers don't have to have any other meaning except being unique, since the IFTYPE/CASETYPE comparisons would be the only things they're used for. Oh, sorry... subranges might have to be considered, but that should also be feasible... The size (for SizeOf) would either be passed as another additional parameter (if used at all in the procedure), or be retrieved through a lookup table via the type number. The varying size of the arguments on the stack (in the case of value parameters) also seems to be a little problem, but I think it can be solved, too. (Perhaps with the help of the SizeOf parameter as far as necessary, or by passing temporary copies by reference...) Type inquiry would be rather easy, since the procedure would only need to know the size of the local variable which can be obtained like the SizeOf above. Many ideas... many problems... much to do... This message is distributed under the terms of the GNU General Public License. The license can be retrieved from many ftp and www sites, e.g. from: ftp://sunsite.unc.edu/pub/gnu/COPYING http://www.mi.uni-erlangen.de/~heckenb/COPYING If you can't get this file, mail me, and I'll send you a copy. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Mar 10 17:17:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA04941 for ; Mon, 10 Mar 1997 17:17:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA92620; Mon, 10 Mar 1997 16:30:03 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA34072; Mon, 10 Mar 1997 16:30:07 +0100 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA12068 for ; Mon, 10 Mar 1997 17:25:13 +0200 (EET) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id RAA121470 for ; Mon, 10 Mar 1997 17:11:00 +0200 Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id QAA29013 (8.7.6/7.5c-FAU); for ; Mon, 10 Mar 1997 16:10:29 +0100 (MET) Received: from skylla by mi.uni-erlangen.de with SMTP; id QAA24747 (SMI-8.6/7.5b-FAU); Mon, 10 Mar 1997 16:10:54 +0100 From: Frank Heckenbach Message-Id: <199703101510.QAA24747@helena.mi.uni-erlangen.de> Date: Mon, 10 Mar 1997 15:10:53 GMT To: gpc@hut.fi Subject: Some more bugs Status: RO Hi everyone! I've got a few more bugs: 1. For loops with chars don't seem to work: PROGRAM p; VAR c:Char; BEGIN c:='A'; {OK} c:='Z'; {OK} FOR c:='A' TO 'Z' DO {"incompatible types in assignment"} END. 2. Under DJGPP, program arguments don't work correctly, as the following program shows. Under Linux it seems to work ok. However, the problem seems to have something to do with Pascal, since gcc programs under DJGPP don't show the problem. {Call the compiled program as "p longparam 2 3" or similar} PROGRAM p; {From info/gpc.i7, slightly modified:} 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 _p_paramcount : Integer; C; FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; FUNCTION ParamCount: Integer; BEGIN ParamCount := _p_paramcount; END; { ParamCount } FUNCTION ParamStr (arg_num: integer): Arg_type; 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 } {} VAR a:Integer; BEGIN FOR a:=1 TO ParamCount DO Writeln(ParamStr(a)) END. The result is something like: longparam[some other chars] 2ongparam[some other chars] 3ongparam[some other chars] Obviously the length is not set correctly. Frank -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Mar 10 16:56:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA04918 for ; Mon, 10 Mar 1997 16:56:19 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91166; Mon, 10 Mar 1997 16:09:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA33960; Mon, 10 Mar 1997 16:09:26 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA11311 for ; Mon, 10 Mar 1997 17:01:58 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id QAA28710 (8.7.6/7.5c-FAU); for ; Mon, 10 Mar 1997 16:01:28 +0100 (MET) Received: from skylla by mi.uni-erlangen.de with SMTP; id QAA24689 (SMI-8.6/7.5b-FAU); Mon, 10 Mar 1997 16:01:50 +0100 From: Frank Heckenbach Message-Id: <199703101501.QAA24689@helena.mi.uni-erlangen.de> Date: Mon, 10 Mar 1997 15:01:49 GMT To: gpc@hut.fi Subject: Re: Protected parameters, 2nd try Status: RO Peter Gerwinski wrote: > [...] > It needn't be an explicit assignment; it might be a call to a function > which makes the value of `x' change. To pass everything by value *is* > the only possibility. I must admit, I didn't think of these cases. > But I will modify `Const' parameters to pass small things by value and > to work with implicit temporary variables when a constant is passed as > a `Const' parameter. You mean, for big things!? I don't think you need any temporary variables for small things that are passed by value, regardless whether a variable, constant or an evaluated expression is passed. For big things passed by reference, you need a temporary variable if a constant or expression is passed, I think. > Then it's up to the programmer to take care that > the `Const' parameter doesn't change its value due to side effects. Then it would be like Borland's. However, speaking from a purist's point of view, I can see the problem that it would be implementation-dependent whether a parameter is passed by value or by reference. This means it is "undefined" whether side-effects can happen or not. Would it be permissible (well, const parameters aren't standard anyway, I mean in the "spirit" of the standard) to leave that undefined, or would it be necessary that const parameters have clear semantics concerning side-effects? > Hmmm ... how to tread `protected Var' parameters??? As far as I understood it up to now (Berend, correct me if that's not what the standard says), "protected" only means that the compiler must make sure that the parameter isn't altered, and never changes the way of passing the parameter. That would mean: 'const' parameters would be used if the programmer is sure that there can't be any side-effects (which is true in the majority of cases, e.g. if the procedure operates only on local variables and will not be called with the same parameter twice; or e.g. if the procedure reads the value of the parameter only before it writes to any var parameters and/or global variables and/or calls any procedures/functions that do), and wants the compiler to choose the most efficient way of passing and to verify that the programmer doesn't accidentally alter the parameter. 'protected' parameters would be used if there is a danger of side-effects, and the programmer only wants to verify the parameter isn't altered, putting up with a possible inefficiency. (I think it's rare that side-effects become a problem, especially with big structures where the inefficiency would matter.) 'protected var' parameters would be used in the (very rare, IMHO) case that there could be side-effects, and the programmer *wants* these side-effects to influence the parameter. E.g., I could imagine a procedure that watches some variable for changes, but must not change the variable by itself - perhaps in a multi-threaded program where another thread could modify the variable - just fantasizing... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Tue Mar 11 23:47:47 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA07777 for ; Tue, 11 Mar 1997 23:47:47 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90442; Tue, 11 Mar 1997 23:00:21 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48508; Tue, 11 Mar 1997 23:00:29 +0100 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA31694 for ; Tue, 11 Mar 1997 23:52:54 +0200 (EET) Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by vipunen.hut.fi (8.8.5/8.8.2) with SMTP id XAA151668 for ; Tue, 11 Mar 1997 23:17:19 +0200 Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA07658 for gpc@hut.fi; Tue, 11 Mar 1997 23:04:01 +0100 From: Peter Gerwinski Message-Id: <199703112204.XAA07658@agnes.dida.physik.uni-essen.de> Subject: Variable number of parameters To: gpc@hut.fi Date: Tue, 11 Mar 1997 23:04:01 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, everybody! According to Frank Heckenbach: > In news:comp.lang.pascal.borland, there's just a discussion about > variable number/types of procedure/function parameters going on. Here are just a few remarks from me to clarify some points; right now I don't have the time to enter the discussion in comp.lang.pascal.borland. I'll join you next week (-;unless our news server is down again). > Not explicitly call itoa(), but (s)he'd have to specify the type by a format > specifier ("%d") in the format string. This, of course, provides no means of > type checking, and is therefore not suited for Pascal. I agree; however Borland has had something like this ("Form" procedure) in Turbo87 3.0 and something similar in Turbo Vision ("FormatStr" procedure), and you can call C functions like "printf" from GPC using the declaration Function Printf ( format: CString; ... ): Integer; (Yes, with three dots.) > But this would be a case for default values as in C++. If you could declare > something like > procedure LPP(s:String;segg,off:Word;PPal:PPalettestructure value NIL); > and call it with wither 3 or 4 parameters (in the former case, the 4th > parameter would be implicitly NIL), that would be nice sometimes... Yes, that would be nice . But it's work, of course. Any help welcome! > I don't think there's anything wrong with it, but Borland will not do it. > They've dropped TP, face it! So if you want these changes, don't look at > TP, but perhaps at GNU Pascal. :-) > AFAIK, gpc already supports declaring and > calling a procedure with variable arguments, like C - but only to allow > calling C functions with varargs. There's not (yet) a way to implement such > a procedure in Pascal, Correct. > but the gpc developers are always looking to enhance > the language, so if you've got some concrete ideas (or can even help to work > on the compiler), you're always welcome to join the team. Correct ** 2. :-) ;-) > > Thats not what I where aiming at. You could make the product better, > > and alas get more satisfied customers. > > That's how the gpc developers/maintainers feel too, I think. Correct, too. With the only difference that we don't get money for our work on GPC. (Instead we will get our dream compiler.:) > > As far as i can remember (this might be wrong) GNU pascal dont have > > oop. > > By now, AFAIK, gpc has (nearly) the same OOP as TP, but doesn't implement the > Object Pascal (not-yet-)standard. Correct. It has the "Borland Pascal 7.0 with Object" standard. Only the "private" directive and "dynamic methods" (Function Foo; virtual 1234;) are still missing. > > >To each his own. If you want overloading and procedures with variable number of > > >parameters, then check out languages that support them. > > Belive me, I have .. But I really dont like C. Its so.. what should I > > say.. pee->(wee&&) .. I just dont like it :) > > I don't think that's valid in C (provided there's anything that's not valid in > C - not sure if there is... :-> ), but I know what you mean. I'd also prefer > to have the Pascal syntax and yet many of the other features. I agree - including the try with C++. That's why I am working on GPC. However, function and oparator overloading are not new to Pascal. At least the PXSC standard has this feature. (You *need* it for scientific programming!) Unfortunately I have never seen a working PXSC compiler, only a book with the standard specifications ... > > I think that would be a bit to much trouble really. I was just > > presenting the idea to get a feeling of other people's thoughts on > > the matter. > > If you're serious about it, join the gpc mailing list. > I'll post a copy of this message to the list, since it's quite much about gpc. :-) > > Writeln, reset, and a whole bunch of others allready support it. it's > > just not any way for the -user- to define procedures like that. > > > > and that is a shame . :) > > But of course, it's much more difficult to provide a way for the user to > declare and implement such procedures than to just allow some specially > handled procedures like Writeln. Correct. But it seems that VAX Pascal has solved this problem. We should have a look at their solution. > > [...] > > One, not very good, would be to require VAR types in function > > overloading (thats what you called it, right?), like this: > > function f(var nr:byte); > > > > This would remove the problem all together, but its not a very > > flexible way of doing it. > > Quite restricting... But it already works, in GPC and in Borland Pascal: Use an untyped formal `Var' parameter, and use `absolute' variables to access it. (See my other mail.) > >As a side note: Doesn't FPK support function overloading? > [...] > AME replied: > > Either FPK or GNU, I can't remember which. I can't even remember if it > > was fully implemented. Implemented in FPK, planned for GNU. > AFAIK, gpc supports part of the PCSX (Pascal scientific extensions) standard. > I don't know this standard, and haven't used these extensions, but I think > there is some kind of overloading. You might want to find out if there were > any ambiguity problems involved, and how they were solved. Operator overloading is implemented in GPC; function overloading is defined in PXSC, planned for GPC. > To me the point is that the extensions, however implemented, must still allow > Pascal's strong type checking. (In this example, the type checking was > annulled by assembler code, type casts or (unnecessarily) untyped pointers, > I'd guess from what I know about TV.) Correct. In TV, they unnecessarily used untyped pointers. Correct use of a *carefully* implemented function overloading scheme would not cause this trouble. > Sure. And gpc already has compiler switches to ensure that certain features > are [not] used. All the extensions discussed here would be object to these > (or additional) switches, too. Correct. (I see there is not much need for me to join the discussion directly. ;-) > At last, I've got some suggestions for the varargs problem, too: > [...] Looks nice, but let's first see how VAX Pascal solved the problem. > Alternatively, it would suffice to allow "array expressions" like: > > procedure varnumargs(p:array of integer); begin ... end; > > var a,b,c:integer; > begin > varnumargs( (a,b,c,2,c-b,27) ) > {^^^^^^^^^^^^^^^^ array declaration as in a "typed const"} > end. This I don't understand. Parameters like "Var p: array of Integers" *do* work in GPC (note the `Var'; lower bound is set to zero, upper remains unchecked; Extended Pascal's schemas will provide a better way to achive the same functionality.) > 2. Unknown type of an argument > > Ok, there are untypes arguments in TP, but they don't allow for any type > checking when used, so they're not suited here. Furthermore, the procedure > doesn't get any information about the type, so this information would have > to be passed separately (as in the printf format string in C), which is not > acceptable. > > So the type must be passed internally, and there must be a way for the > procedure to check the type, and to access the parameter as its real type. Objects. > I could imagine something like the following: > [...] > (This syntax is only tentative, it doesn't have to be called IFTYPE and > CASETYPE.) Perhaps a good idea, but the type would have to be passed as an (implicit or explicit) additional parameter anyway, and you can do the cast using `absolute' variables - which already work. I am not sure whether it is worth the effort and the loss of compatibility to other compilers to implement `iftype' and `casetype'. > Of course, the SizeOf function would work on a and return the actual size. > [...] > One has to investigate if and how this is possible (considering multiple, > possibly nested IFTYPEs/CASETYPEs)... Much work. Probably too much, sorry ... > Another idea is whether it is possible and/or useful to compare types of > different arguments: > > procedure equal(const a,b); > begin > IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b} > else Error('Comparison of different types not allowed!') > {^^^ or again, rather a compiler error...} > end; This I don't understand. > It also seems useful to declare local variables of the same type as an > argument: > > procedure swap(var a,b); > var temp:TYPEOF(a); > begin > IFTYPE a,b then begin temp:=a;a:=b;b:=temp end > else Error('Swapping different types not allowed!') {see above} > end; > > (I think, Extended Pascal (gpc???) has some kind of type inquiry, but probably > only for known types. Anyway, this one could, of course, use the same syntax > as EP (it's probably not the syntax above, since I don't know the EP syntax).) It's Var temp: type of a; AFAIK, it works only for known types. But I'm not (yet) an EP expert. > Concerning the implementation, I'd say that for each "vartype" parameter an > additional (invisible) parameter is passed that describes the type uniquely. > Since the compiler has to keep track of all the types somehow anyway, it > shouldn't be hard to generate a unique number for each type. It *is* hard. Consider a large project with many Units/Modules which are compiled separately ... > Many ideas... many problems... much to do... Correct! > This message is distributed under the terms of the GNU General Public License. > The license can be retrieved from many ftp and www sites, e.g. from: > ftp://sunsite.unc.edu/pub/gnu/COPYING > http://www.mi.uni-erlangen.de/~heckenb/COPYING > If you can't get this file, mail me, and I'll send you a copy. :-) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 11 23:10:52 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA07731 for ; Tue, 11 Mar 1997 23:10:52 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08286; Tue, 11 Mar 1997 22:23:27 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40948; Tue, 11 Mar 1997 22:23:35 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA30836 for ; Tue, 11 Mar 1997 23:17:52 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA07673 for gpc@hut.fi; Tue, 11 Mar 1997 23:04:33 +0100 From: Peter Gerwinski Message-Id: <199703112204.XAA07673@agnes.dida.physik.uni-essen.de> Subject: Re: Variable number of parameters To: gpc@hut.fi Date: Tue, 11 Mar 1997 23:04:33 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > I think if you really want var args, function overloading, powerfull > preprocessors, etc. program in C or C++. Function overloading is in FPK Pascal and in the PXSC standard. PXSC also defines operator overloading which is supported by GPC, too. (Has anybody out there ever seen a working PXSC compiler? I know about the standard definition, but ... ???) > Don't fool with Pascal's identity. With the switch `--extended-pascal --pedantic-errors' everything which exceeds the Extended Pascal standard is reported as an error. You are never forced to use existing extensions. > And I think 99.9% of what people want with varargs can be quite cleanly > implemented with Borland's open array and with variant arrays (boy, I need to > use them sometimes, but it's quite bad to let the customer find typechecking > bugs...) Don't forget EP's Schema types. ;-) I am prepared to put them into GPC, but it will take some while, sorry. BTW, what about conformant arrays? Do they work with GPC, or are there still bugs? Somebody out there to write some documentation notes about conformant arrays to tell the poor Borland Pascal programmers (like me;) how to use them? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 11 23:09:58 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA07726 for ; Tue, 11 Mar 1997 23:09:58 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA88072; Tue, 11 Mar 1997 22:22:33 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38824; Tue, 11 Mar 1997 22:22:41 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA31020 for ; Tue, 11 Mar 1997 23:18:06 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA07682 for gpc@hut.fi; Tue, 11 Mar 1997 23:04:48 +0100 From: Peter Gerwinski Message-Id: <199703112204.XAA07682@agnes.dida.physik.uni-essen.de> Subject: Re: varargs in GPC To: gpc@hut.fi Date: Tue, 11 Mar 1997 23:04:48 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > I thought that GPC did not support varargs. In fact, I > was hoping that it would support the VAX Pascal syntax for > doing so. What is the status of variable arguments for GPC? It does support `ellipsis' parameters to call functions with varargs written in C. We have not (yet!;) implemented a portable mechanism to access them. IMHO, it would be reasonable to implement the VAX Pascal syntax into GPC rather than inventing a new method. If you tell me about the VAX Pascal syntax for accessing varargs, it will enable me to do this. BTW, there is yet another Pascal standard definition, PXSC, which supports overloading of procedures and functions. In that dialect you can, for instance, implement an exponential function for real, rational, complex numbers, quaternions and matrices, and all of them are called `exp'. This covers many applications of varargs, is implemented in FPK Pascal and is planned for GNU Pascal, too. A way to pass a constant number of arguments of variable types is to use UCSD (or Borland) Pascal's untyped `Var' parameters in combination with Borland Pascal's `absolute' clauses: Procedure Foo ( Var Bar ); Var BarChar: Char absolute bar; BarInt: Integer absolute bar; BarString: String ( 80 ) absolute bar; ... However: Please help me to with VAX Pascal vararg syntax! I don't have a VAX, and I don't have the money to buy one, so I need example programs with descriptions what they are intended to do, etc. (you know). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 11 23:09:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA07714 for ; Tue, 11 Mar 1997 23:09:18 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85748; Tue, 11 Mar 1997 22:21:53 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA34946; Tue, 11 Mar 1997 22:22:01 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.physik.uni-essen.de [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA30803 for ; Tue, 11 Mar 1997 23:17:06 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA07650 for gpc@hut.fi; Tue, 11 Mar 1997 23:03:48 +0100 From: Peter Gerwinski Message-Id: <199703112203.XAA07650@agnes.dida.physik.uni-essen.de> Subject: gpc and gcc 2.7.2.2 To: gpc@hut.fi Date: Tue, 11 Mar 1997 23:03:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Stephan Duehr: > I have install gcc and would like to take 2.7.2.2. > I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult > to make it work with 2.7.2.2? I don't know, but you can do the following: * Some of the GPC source files contain a lot of "#ifdef GPC" constructs. (Mostly gpc-*.c.) Find their GCC source counterparts. * See which of these files have changed from GCC-2.7.2.1 to GCC-2.7.2.2 and apply the changes to the GPC source files. * Compile, and keep your fingers crossed. * Send us a diff with the necessary changes, so we can upgrade GPC from GCC-2.7.2.1 to GCC-2.7.2.2. Please take the most recent (alpha) GPC source. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Mar 14 16:50:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA14222 for ; Fri, 14 Mar 1997 16:50:24 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90420; Fri, 14 Mar 1997 16:02:05 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70802; Fri, 14 Mar 1997 16:02:15 +0100 Received: from asterix.gi.utc (asterix.hds.utc.fr [193.104.177.49]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA12722 for ; Fri, 14 Mar 1997 16:54:23 +0200 (EET) Received: from pclewis.gi.utc (dlewis@pclewis.gi.utc [172.17.2.21]) by asterix.gi.utc (8.8.3/8.6.12) with SMTP id PAA06890 for ; Fri, 14 Mar 1997 15:54:59 +0100 (MET) Sender: David.Lewis@hds.utc.fr Message-Id: <332966CB.44D0C49C@utc.fr> Date: Fri, 14 Mar 1997 15:55:07 +0100 From: David Lewis X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.18 i686) Mime-Version: 1.0 To: gpc@hut.fi Subject: unable to process using elf(3E) libraries Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO I am trying to get gpc up and running on a Sun Sparc 4 running Solaris 2.4 Whatever the source I try to compile and link, I get link errors : % gpc -o hello hello.pas collect2: ld returned 1 exit status ld: fatal: file hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: File processing errors. No output written to hello % (I installed collect2 as indicated in the FAQ) Another strange thing is that I am obliged to copy a whole load of gcc objects (crt1.o; crtbegin.o; crtend.o; crti.o; crtn.o) into my current directory to avoid additional problems. Without these objects being present I get : % gpc -o hello hello.pas collect2: ld returned 1 exit status ld: fatal: file crt1.o: cannot open file; errno=2 ld: fatal: file crti.o: cannot open file; errno=2 ld: fatal: file crtbegin.o: cannot open file; errno=2 ld: fatal: file hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: file crtend.o: cannot open file; errno=2 ld: fatal: file crtn.o: cannot open file; errno=2 ld: fatal: File processing errors. No output written to hello % Is this a bug ? If not, I should be grateful if anybody could tell me where in the installation I've gone wrong. With my thanks, David Lewis Systems engineer UTC - France From gpc-request@santra.hut.fi Fri Mar 14 06:15:53 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id GAA13341 for ; Fri, 14 Mar 1997 06:15:52 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90476; Fri, 14 Mar 1997 05:27:44 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52980; Fri, 14 Mar 1997 05:27:56 +0100 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id GAA23440 for ; Fri, 14 Mar 1997 06:18:20 +0200 (EET) Received: from monstro (borg.mindspring.com [204.180.128.14]) by mule0.mindspring.com (8.8.5/8.8.4) with SMTP id XAA189294; Thu, 13 Mar 1997 23:18:15 -0500 Message-Id: <3328D15E.2E6C@mindspring.com> Date: Thu, 13 Mar 1997 23:17:34 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: GNU Pascal , Peter Gerwinski Subject: Re: varargs in GPC References: <199703112204.XAA07682@agnes.dida.physik.uni-essen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Peter Gerwinski wrote: > > > I thought that GPC did not support varargs. In fact, I > > was hoping that it would support the VAX Pascal syntax for > > doing so. What is the status of variable arguments for GPC? > > It does support `ellipsis' parameters to call functions with varargs > written in C. We have not (yet!;) implemented a portable mechanism to > access them. > > IMHO, it would be reasonable to implement the VAX Pascal syntax into GPC > rather than inventing a new method. If you tell me about the VAX Pascal > syntax for accessing varargs, it will enable me to do this. [stuff deleted] > However: Please help me to with VAX Pascal vararg syntax! I don't have > a VAX, and I don't have the money to buy one, so I need example programs > with descriptions what they are intended to do, etc. (you know). > Unfortunately, it's been about 7 years since I had access to the compiler. However, I saw a VAX Pascal book in a bookstore and I'm going to pick it up this weekend. The online help I have seen for VAX Pascal did not go into much detail on syntax. The VAX approach, as I remember it, used an array of parameters. The VAX Pascal language had two kinds of arrays: ARRAY and VARYING. The varying kind worked a bit like Turbo Pascal strings. There was a maximum size and a current length. I think the varargs mechanism was similar to the VARYING arrays. You could define strings as: TYPE string = VARYING[1..255] of CHAR; I'll get back to you on this. > Greetings, > > Peter > > Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer > peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] > maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] -- Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Thu Mar 13 20:38:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA12258 for ; Thu, 13 Mar 1997 20:38:50 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05054; Thu, 13 Mar 1997 19:50:48 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39404; Thu, 13 Mar 1997 19:50:59 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA14708 for ; Thu, 13 Mar 1997 20:43:09 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id TAA24621 (8.7.6/7.5c-FAU); for ; Thu, 13 Mar 1997 19:43:05 +0100 (MET) Received: from laertes by mi.uni-erlangen.de with SMTP; id TAA09132 (SMI-8.6/7.5b-FAU); Thu, 13 Mar 1997 19:43:03 +0100 From: Frank Heckenbach Message-Id: <199703131843.TAA09132@helena.mi.uni-erlangen.de> Date: Thu, 13 Mar 1997 18:43:02 GMT To: gpc@hut.fi Subject: Re: varargs in GPC Status: RO Peter Gerwinski wrote (in several postings): > BTW, there is yet another Pascal standard definition, PXSC, which supports > overloading of procedures and functions. In that dialect you can, for > instance, implement an exponential function for real, rational, complex > numbers, quaternions and matrices, and all of them are called `exp'. This > covers many applications of varargs, is implemented in FPK Pascal and is > planned for GNU Pascal, too. I agree that most of the time you can do with overloading instead of varargs. Varargs are really needed only very rarely, I think, e.g. in things like Read[ln] and Write[ln] and variants like ReadStr, WriteStr, ... BTW (a bit off-topic for the subject): Is there a meachnism like TP's "text file device drivers" in gpc, i.e. a means of (roughly speaking) assigning a Text "file" variable with a input/output routine, so that the main program can use Write[ln] etc. comfortably, and the routine gets the data in a raw form (a buffer and its length) (and similar for input) - so the routine would be relatively easy to implement but flexible to use? If there's not, is it realistic to hope fur such a thing in gpc? Note, I don't mean to duplicate Borland's way of doing it (which I find quite clumsy), but any way at all. It doesn't even have to be a Text variable, but if not, one would need another variant of Read[ln], Write[ln]. Such a meachnism would eleminate many of the (few) needs for varargs. I'm thinking of things like text output on a graphics screen. In TP (and also in the Graph unit of the BGI2GRX package) there's only an "OutText" procedure that takes a string. (This is reasonable since a graphics unit should not have to worry about formatting output.) If one wants to write a number, one has to manually convert it to a string before outputting. A mechanism like above could simplify this. > A way to pass a constant number of arguments of variable types is to use > UCSD (or Borland) Pascal's untyped `Var' parameters in combination with > Borland Pascal's `absolute' clauses: > > Procedure Foo ( Var Bar ); > > Var > BarChar: Char absolute bar; > BarInt: Integer absolute bar; > BarString: String ( 80 ) absolute bar; > > ... I don't like this! (Actually, I myself use type casts instead of absolute variables, but I like them just a little.) The reason is simply that Pascal's type checking is annulled. (The TV example in the other posting was a good example of what can happen...) One can use it if there's nothing better, but, IMHO, this is no real Pascal (because Pascal is strictly typed). Therefore I'd still prefer having a mechanism like the "IFTYPE" I suggested. > However: Please help me to with VAX Pascal vararg syntax! I don't have > a VAX, and I don't have the money to buy one, so I need example programs > with descriptions what they are intended to do, etc. (you know). I agree. If there's already a varargs syntax (and if it enables type checking - unlike C's varargs), gpc should try to be compatible. > Don't forget EP's Schema types. ;-) I am prepared to put them into GPC, > but it will take some while, sorry. Indeed, schema types can reduce the need for overloading, I suppose (I never used them - how should I?). BTW (maybe I'm opening up another can of worms...): Can the "parameters" (is it called that?) of a schema type only be ordinal values like array indices, or could they be types themselves? IOW: Would it be possible to implement a general list (tree, dynamic array, whatever) as a schema. As I think about it, I don't see any principal obstacle to do this, using some of the ideas I had on variable types of procedure parameters. I think this could be a *great* simplification for many programs. (Who hasn't implemented the same concepts, slightly differently, again and again?) > I agree; however Borland has had something like this ("Form" procedure) in > Turbo87 3.0 and something similar in Turbo Vision ("FormatStr" procedure), And I don't like the FormatStr procedure, because 1. of missing type security (see above, concerning absolute variables) 2. it's very clumsy to use, IMHO. (To get a formatted string, one has to declare an array, assign values to each field, and call FormatStr - all of which a C programmer can do with a single call to sprintf.) > and you can call C functions like "printf" from GPC using the declaration > > Function Printf ( format: CString; ... ): Integer; > > (Yes, with three dots.) Easier to use, but again no type checking, and besides, the point in Pascal programming isn't to call C functions... :-) > > > Thats not what I where aiming at. You could make the product better, > > > and alas get more satisfied customers. > > > > That's how the gpc developers/maintainers feel too, I think. > > Correct, too. With the only difference that we don't get money for our > work on GPC. (Instead we will get our dream compiler.:) He wasn't talking about money, but of satisfied customers. That's not the same at all - just look at M$! > Correct. It has the "Borland Pascal 7.0 with Object" standard. Only the > "private" directive If you do it, please do it not in the Borland way (private methods visible in the whole unit - or module here), but more reasonable as visible only for the declaring object type. A "protected" directive (visible to the declaring type and all sub-types of it) would be a good idea, too. Maybe one would also need something like C++'s "friend" (not sure if this is really necessary). > and "dynamic methods" (Function Foo; virtual 1234;) > are still missing. Up to now, I've seen only one use for them, namely Borland's way of implementing message/event handlers in TV/OWL. I'm not convinced that this is really a good thing (all it saves seems to be a case statement or a loop through a constant array or list) - I think it could be done better if one allowed "class" variables/constants, i.e. variables/constants that are the same for all objects of a given type. Here, the class constants would be tables or lists of the message IDs together with their handlers, and "dynamic methods" might not be needed at all. (If there are other applications to them, please tell me!) Class variables/constants, OTOH, are a feature found in several OOP languages, and have more uses. (I'd have liked to have them myself sometimes). > However, function and oparator overloading are not new to Pascal. > At least the PXSC standard has this feature. (You *need* it for > scientific programming!) I have to support this! Especially for operators. > Unfortunately I have never seen a working > PXSC compiler, only a book with the standard specifications ... That's the problem with standards, they just don't compile any program... ;-) > But it already works, in GPC and in Borland Pascal: Use an untyped > formal `Var' parameter, and use `absolute' variables to access it. > (See my other mail.) See above, why I don't like it. IMHO, a real untyped parameter (usually together with a Size value) should be used only if the type doesn't matter at all (such as raw memory copy/compare, file read/write), and not as a substitute where the language provides no way for a "correct" declaration. > > Alternatively, it would suffice to allow "array expressions" like: > > > > procedure varnumargs(p:array of integer); begin ... end; > > > > var a,b,c:integer; > > begin > > varnumargs( (a,b,c,2,c-b,27) ) > > {^^^^^^^^^^^^^^^^ array declaration as in a "typed const"} > > end. > > This I don't understand. What I meant here is a way of declaring an "array expression" (similar for records), i.e. a way of constructing an array in an expression, e.g.: var v:record s:string; a:array[1..3] of integer end; begin v:=('H.W.',(1,2,3)) end. This is not strictly related to varargs and might not be too easy to implement, but can be useful sometimes, too. I'm just collecting ideas here. > Parameters like "Var p: array of Integers" *do* > work in GPC (note the `Var'; Is there any reason why this doesn't work with value parameters? In TP, it does, AFAIR. > lower bound is set to zero, BTW: Is this reasonable? Borland does it this way, but IMHO, it would be more Pascal-ish to pass the bounds together with the parameter and... > upper remains unchecked; ...to provide something like Borland's High and Low pseudo-functions (to get the actual bounds within the procedure). High and Low should work on any array (not only open array parameters), and on ordinal types (giving the minimum and maximum value), IOW with "type a=array[r] of t;" it would hold low(a)=low(r). > Extended Pascal's schemas will provide a better way to achive > the same functionality.) Yes; and in this case perhaps also conformant arrays (I don't know them)? > > So the type must be passed internally, and there must be a way for the > > procedure to check the type, and to access the parameter as its real type. > > Objects. Yes, I was thinking of OOP, too, when I wrote it, but unless Pascal is going to be a completely OOP language in the future (which I don't think), a non-OOP way will be useful. As long as only a single parameter is concerned, you can usually achieve the same with overloading, but when more parameters can be of variable type, the number of needed overloads would increase dramatically... > > I could imagine something like the following: > > [...] > > (This syntax is only tentative, it doesn't have to be called IFTYPE and > > CASETYPE.) > > Perhaps a good idea, but the type would have to be passed as an (implicit > or explicit) additional parameter anyway, Yes, the type has to be passed, but I see no (sensible) way to use the type except to compare it to a known type (my "IFTYPE") or to another unknown type (my variant on "IFTYPE"). > and you can do the cast using > `absolute' variables - which already work. I am not sure whether it is > worth the effort and the loss of compatibility to other compilers to > implement `iftype' and `casetype'. Sure it will be a lot of work, but I think compatibility to other compilers is not the point here. There are already many extensions in gpc (e.g. parts of EP *and* TP, or gpc's own extensions), that are not supported by any other compiler. And, if we find a good mechanism, it might be part of a standard sometime... > > [About the compiler catching type errors in variable types] > > One has to investigate if and how this is possible (considering multiple, > > possibly nested IFTYPEs/CASETYPEs)... > > Much work. Probably too much, sorry ... As I think of it, probably yes, but it might be possible to specify the allowed types in the declaration, like: procedure p(v:(Integer,String,Boolean)); Then the compiler can make sure that no other types are passed. This would be similar to an overloaded procedure, but as I said above, useful if more than one parameter is involved. Of course, there could also be parameters with no type restrictions, where the procedure would implement some default behaviour for types it doesn't know, treating it as unstructured data of known length (SizeOf still works). > > Another idea is whether it is possible and/or useful to compare types of > > different arguments: > > > > procedure equal(const a,b); > > begin > > IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b} > > else Error('Comparison of different types not allowed!') > > {^^^ or again, rather a compiler error...} > > end; > > This I don't understand. What I meat is that IFTYPE could not only compare the type of one unknown parameter to a know type (e.g. Integer), but also compare the types of two unknown parameters. For procedures like (raw) compare or swap, all the procedure has to know is the size and that the types match. Revised delcaration: procedure equal(const a;const b:type of a); Why not... > AFAIK, it works only for known types. Probably, or are there any unknown types in EP at all (in parameters, schema types, whatever)? > > Concerning the implementation, I'd say that for each "vartype" parameter an > > additional (invisible) parameter is passed that describes the type uniquely. > > Since the compiler has to keep track of all the types somehow anyway, it > > shouldn't be hard to generate a unique number for each type. > > It *is* hard. Consider a large project with many Units/Modules which are > compiled separately ... No problem: Unique_Type_ID = Unique_Module_ID * C + Unique_Type_ID_Within_Module where C is larger than the biggest possible/reaonable number of types whithin a module, in the worst case $100000000, but that might be a little too much. Or: Unique_Type_ID = Module_Offset + Unique_Type_ID_Within_Module where Module_Offset of a module is calculated just before linking as the sum of the number of Type_IDs in all modules before the one considered, given any ordering of the modules. Only types that are actually used for variable type parameters, or that appear in an interface, need type IDs. Of course, any use of these IDs would have to be partially (the Unique_Module_ID/Module_Offset part) resolved at link time - I hope this is possible with the usual linkers - or if not, at run time by use of an additional variable per module that contains its Module_ID/_Offset)... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Mar 13 20:37:32 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA12254 for ; Thu, 13 Mar 1997 20:37:32 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97688; Thu, 13 Mar 1997 19:49:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59278; Thu, 13 Mar 1997 19:49:40 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA14860 for ; Thu, 13 Mar 1997 20:43:09 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id TAA24623 (8.7.6/7.5c-FAU); for ; Thu, 13 Mar 1997 19:43:06 +0100 (MET) Received: from laertes by mi.uni-erlangen.de with SMTP; id TAA09134 (SMI-8.6/7.5b-FAU); Thu, 13 Mar 1997 19:43:04 +0100 From: Frank Heckenbach Message-Id: <199703131843.TAA09134@helena.mi.uni-erlangen.de> Date: Thu, 13 Mar 1997 18:43:04 GMT To: gpc@hut.fi Subject: Re: varargs in GPC Status: RO Berend de Boer wrote: > I think if you really want var args, function overloading, powerfull > preprocessors, etc. program in C or C++. > Don't fool with Pascal's identity. I don't agree. I don't think things like varargs, overloading etc. are inconsistent with Pascal's identity if properly implemented. What is part of its identity, IMHO, is e.g. strict typing and type checking at compile time. Of course, this is an issue with varargs and overloading and is has to be carefully considered, so that all type checks can be made at compile time and no ambiguities will arise. These features can make programming easier and more comfortable (if used properly, of course), so see no reason no to have them (except not to have the time to implement them...) OTOH, preprocessors, AFAIK, are not part of any language at all, as the same preprocessor can be used for C and Pascal. However, C needs a preprocessor because certain features (constants, modularisation) are not present in the language itself. I think a (sufficiently sophisticated) Pascal should not (or at least very rarely) need a preprocessor, so in this regard I agree with you. > And I think 99.9% of what people want with varargs can be quite cleanly > implemented with Borland's open array and with variant arrays ... and with schema types when they're there. > (boy, I need to > use them sometimes, but it's quite bad to let the customer find typechecking > bugs...) I'm not completely sure what you mean here, but it sounds like a case where typing errors are not detectect at compile time but at run time. Exactly this is what I want to prevent by the mechanisms I suggested - mainly because I'm not very content with Borland's open arrays and absolute variables. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Wed Mar 12 01:15:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA07871 for ; Wed, 12 Mar 1997 01:15:16 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81760; Wed, 12 Mar 1997 00:27:49 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48024; Wed, 12 Mar 1997 00:27:58 +0100 Received: from snert.wash.cedar-rapids.k12.ia.us (snert.wash.cedar-rapids.k12.ia.us [205.221.77.102]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA00362 for ; Wed, 12 Mar 1997 01:22:38 +0200 (EET) Received: from localhost (lindholm@localhost) by snert.wash.cedar-rapids.k12.ia.us (8.8.4/8.7.1) with SMTP id RAA04648 for ; Tue, 11 Mar 1997 17:30:26 -0600 Date: Tue, 11 Mar 1997 17:30:25 -0600 (CST) From: Stephen Lindholm Reply-To: Stephen Lindholm To: gpc@hut.fi Subject: Apparent gpc bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO gpc barfs on this program. This is a small clip of a larger program, so I suppose it could be trimmed some more, but it demonstrates the problem. It tells me that the subrange bounds are not of the same type. program temp (input, output); type TLittleChar = 'A' .. 'C'; begin writeln; end. From gpc-request@santra.hut.fi Fri Mar 14 21:45:32 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA14852 for ; Fri, 14 Mar 1997 21:45:32 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86808; Fri, 14 Mar 1997 20:57:09 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20894; Fri, 14 Mar 1997 20:57:22 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA19719 for ; Fri, 14 Mar 1997 21:51:47 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA14760 for gpc@hut.fi; Fri, 14 Mar 1997 21:39:22 +0100 From: Peter Gerwinski Message-Id: <199703142039.VAA14760@agnes.dida.physik.uni-essen.de> Subject: Re: Apparent gpc bug To: gpc@hut.fi Date: Fri, 14 Mar 1997 21:39:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Stephen Lindholm: > gpc barfs on this program.[...] > > [...] > > type > TLittleChar = 'A' .. 'C'; Ah - I see. Okay, it's easy to fix: In gpc-parse.y do the following: 8< ---------------------------------------------------------------------------- gpc-parse.y gpc/gpc-parse.y --- gpc-970226/gpc-parse.y Thu Feb 27 11:34:07 1997 +++ gpc/gpc-parse.y Wed Mar 12 19:36:39 1997 @@ -1568,6 +1568,8 @@ subrange_type : constant TWODOTS expression { + $1 = string_may_be_char ($1); + $3 = string_may_be_char ($3); if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); 8< ---------------------------------------------------------------------------- The bug will be corrected in the next alpha release, too. Thanks for the report! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Mar 14 21:45:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA14848 for ; Fri, 14 Mar 1997 21:45:28 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97298; Fri, 14 Mar 1997 20:57:04 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19606; Fri, 14 Mar 1997 20:57:17 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA19029 for ; Fri, 14 Mar 1997 21:47:55 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA14703 for gpc@hut.fi; Fri, 14 Mar 1997 21:35:30 +0100 From: Peter Gerwinski Message-Id: <199703142035.VAA14703@agnes.dida.physik.uni-essen.de> Subject: Pascal's identity To: gpc@hut.fi Date: Fri, 14 Mar 1997 21:35:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, everybody! Let me just tell you my thoughts about Pascal's identity and the future of GPC. My point is: I need a working GPC as soon as possible to make a living. At the moment, I am programming mostly in Borland Pascal 7.0. But BP7 has no future outside Windows 95, so I want to switch to GPC completely. To me, features which make my programs evolve faster have highest priority. (Of course, actual bug fixes have highest priority, too.) It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself - at least concerning Pascal where very few people know the standard and even fewer are content with it. For example I continue to use BP-style Units although there are EP Modules. I find Units better. (BTW, Units have not been invented by Borland, but they are part of the UCSD Pascal standard.) OTOH, I see the advantages of Schema types, so I want to have them before I start porting my major application programs to GPC (i.e. continue with BO5). For some standard features I don't see their use, but they are hard to implement, so I assign them quite a low priority. This especially applies to some error messages required by the standard, e.g. for unresolved `case'. In case somebody else wants to take care of such things, I would be glad to help him or her to get into GPC hacking. So completing the standard/s does *not* have higher priority to me than to create GPC extensions. (However I will try to do both.) Concerning the purity of Pascal I agree that there are *some* extensions which should at least be warned about unless you explicitly enable them (with (*$X+*) - or with the command-line option "--extended-syntax"). I am speaking of those extensions which could become a trap for beginners. For example, function overloading should be disabled by default because it might confuse a beginner who does not yet know enough about parameter lists. OTOH, I don't see any need for disabling operator overloading by default because you cannot overload an operator unintentionally. For the case somebody does not like GPC to support a mixture of several Pascal dialects, there exist options which enforce a certain standard, including all misfeatures, as far as implemented. For example, the "--borland-pascal" option does not only disable EP Modules, but also the warning about assignment to typed constants. OTOH, the "--extended-pascal" option disables UCSD Units. Both options disable operator overloading. I hope this helps to clarify what direction I intend GPC to go. Suggestions are welcome; actual help to implement things is even more welcome. ;-) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Mar 14 23:24:30 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA14971 for ; Fri, 14 Mar 1997 23:24:30 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90514; Fri, 14 Mar 1997 22:36:05 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56996; Fri, 14 Mar 1997 22:36:18 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA21467; Fri, 14 Mar 1997 23:32:20 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA14953; Fri, 14 Mar 1997 23:19:58 +0100 From: Peter Gerwinski Message-Id: <199703142219.XAA14953@agnes.dida.physik.uni-essen.de> Subject: GPC for the DEC Alpha To: jtv@hut.fi (Jukka Virtanen), gpc@hut.fi Date: Fri, 14 Mar 1997 23:19:57 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi! As you know perhaps from the GPC documentation, there are some known bugs with optimization on the DEC Alpha. Up to now I was not able to hunt them, but it seems like that I will get access to an Alpha workstation till 1. November. Since I only know that these bugs exist but I don't have a single example program, I would be glad if the DEC Alpha users among you could send me their example programs which fail with high optimization levels. Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Mar 15 01:21:44 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA15130 for ; Sat, 15 Mar 1997 01:21:44 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97230; Sat, 15 Mar 1997 00:33:17 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72792; Sat, 15 Mar 1997 00:33:30 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA23033 for ; Sat, 15 Mar 1997 01:30:24 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA17811 (5.67b/IDA-1.5 for ); Sat, 15 Mar 1997 00:30:20 +0100 Message-Id: <2.2.32.19970314233008.006af960@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 1997 00:30:08 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: gpc and gcc 2.7.2.2 Status: RO At 09:11 AM 3/11/97 +0100, you wrote: >Hi, > >I have install gcc and would like to take 2.7.2.2. >I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult >to make it work with 2.7.2.2? > Quoting gcc-2.7.2.1-2.7.2.2.diff: "The reason for the 2.7.2.2 release is to add support for GNU C library version 2 on GNU/Linux systems." If you study this (small) patch, you find out that no changes have been made to the compiler internals at all, only minor changes to some config files. So, unless you have a Linux/glibc2 system, I see no need to upgrade from 2.7.2.1 to 2.7.2.2 If you have 2.7.2.2 and want to built GPC with it, just edit Makefile.in and change GCCVERSION to 2.7.2.2. It will not harm GPC since no _real_ changes to GCC were made anyway. Have fun, JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Sat Mar 15 00:25:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA15077 for ; Sat, 15 Mar 1997 00:25:06 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90470; Fri, 14 Mar 1997 23:36:40 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48176; Fri, 14 Mar 1997 23:36:53 +0100 Received: from driene.student.utwente.nl (driene.student.utwente.nl [130.89.220.2]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA22422 for ; Sat, 15 Mar 1997 00:33:10 +0200 (EET) Received: from wit381304.student.utwente.nl by driene.student.utwente.nl with SMTP id AA08452 (5.67b/IDA-1.5 for ); Fri, 14 Mar 1997 23:33:07 +0100 Message-Id: <2.2.32.19970314223254.00684838@mail.student.utwente.nl> X-Sender: s8806144@mail.student.utwente.nl X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 1997 23:32:54 +0100 To: gpc@hut.fi From: JanJaap van der Heijden Subject: Re: GPC for the DEC Alpha Status: RO At 11:19 PM 3/14/97 +0100, you wrote: >Hi! > >As you know perhaps from the GPC documentation, there are some known bugs >with optimization on the DEC Alpha. Up to now I was not able to hunt >them, but it seems like that I will get access to an Alpha workstation >till 1. November. > >Since I only know that these bugs exist but I don't have a single example >program, I would be glad if the DEC Alpha users among you could send me >their example programs which fail with high optimization levels. > I don't know much about the Alpha and GPC related bugs, but I did some work to build Redhat RPM's for GPC. As you may know, Redhat Linux is available for iX86, sparc and alpha. The GCC sources from redhat come with a number of patches to build on the alpha. Anybody who wants to build GPC for Linux/alpha will have to apply these, probably. Normally, I would not have come up with this untill it matured a bit, but since the topic of Alphas has come up: is there anybody out there running a Redhat Linux/Alpha machine who would want to test these RPM's on it? JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones From gpc-request@santra.hut.fi Sat Mar 15 21:47:07 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA16745 for ; Sat, 15 Mar 1997 21:47:07 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90558; Sat, 15 Mar 1997 20:58:22 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51436; Sat, 15 Mar 1997 20:58:37 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA32550; Sat, 15 Mar 1997 21:54:09 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA16702; Sat, 15 Mar 1997 21:42:04 +0100 From: Peter Gerwinski Message-Id: <199703152042.VAA16702@agnes.dida.physik.uni-essen.de> Subject: Re: GPC for the DEC Alpha To: gpc@hut.fi Date: Sat, 15 Mar 1997 21:42:04 +0100 (MET) Cc: jtv@hut.fi (Jukka Virtanen) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to JanJaap van der Heijden: > I don't know much about the Alpha and GPC related bugs, but I did some work > to build Redhat RPM's for GPC. RPM? What's that? > As you may know, Redhat Linux is available > for iX86, sparc and alpha. The GCC sources from redhat come with a number of > patches to build on the alpha. Anybody who wants to build GPC for > Linux/alpha will have to apply these, probably. Are these patches freely available? If so, we should point to them in the GPC documentation and README files. And in the FAQ - even more important. > Normally, I would not have > come up with this untill it matured a bit, but since the topic of Alphas has > come up: is there anybody out there running a Redhat Linux/Alpha machine who > would want to test these RPM's on it? The Alpha I have access to does not run Linux. Perhaps somebody else has a Linux/Alpha system? And I am still interested in example programs which trigger those Alpha-with-high-optimization-specific errors, you know. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Mar 17 09:54:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA19685 for ; Mon, 17 Mar 1997 09:54:57 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72434; Mon, 17 Mar 1997 09:05:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35932; Mon, 17 Mar 1997 09:05:58 +0100 Received: from sunsrv5.lrz-muenchen.de (sunsrv5.lrz-muenchen.de [129.187.13.15]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id JAA20578; Mon, 17 Mar 1997 09:56:47 +0200 (EET) Received: from haegar.physiol.med.tu-muenchen.de by sunsrv5.lrz-muenchen.de; Mon, 17 Mar 97 08:56:46 +0100 Received: (from robert@localhost) by haegar.physiol.med.tu-muenchen.de (8.8.5/8.7.3) id IAA29298; Mon, 17 Mar 1997 08:55:31 +0100 From: Robert Wilhelm Message-Id: <199703170755.IAA29298@haegar.physiol.med.tu-muenchen.de> Subject: Re: GPC for the DEC Alpha In-Reply-To: <199703152042.VAA16702@agnes.dida.physik.uni-essen.de> from Peter Gerwinski at "Mar 15, 97 09:42:04 pm" To: peter@agnes.dida.physik.uni-essen.de (Peter Gerwinski) Date: Mon, 17 Mar 1997 08:55:31 +0100 (MET) Cc: gpc@hut.fi, jtv@hut.fi X-Mailer: ELM [version 2.4ME+ PL31 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > According to JanJaap van der Heijden: > > I don't know much about the Alpha and GPC related bugs, but I did some work > > to build Redhat RPM's for GPC. > > RPM? What's that? See http://www.redhat.com/support/docs/rpm "RPM is the Red Hat Package Manager. While it does contain Red Hat in the name, it is completely intended to be an open packaging system available for anyone to use. It allows users to take source code for new software and package it into source and binary form such that binaries can be easily installed and tracked and source can be rebuilt easily. It also maintains a database of all packages and their files that can be used for verifying packages and querying for information about files and/or packages." > Are these patches freely available? If so, we should point to them in the > GPC documentation and README files. And in the FAQ - even more important. Yes, on ftp.redhat.com and Mirrors. Robert From gpc-request@santra.hut.fi Tue Mar 18 23:19:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA22684 for ; Tue, 18 Mar 1997 23:19:44 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87580; Tue, 18 Mar 1997 22:29:56 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75368; Tue, 18 Mar 1997 22:30:15 +0100 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA00838 for ; Tue, 18 Mar 1997 23:24:27 +0200 (EET) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id WAA12920 (8.7.6/7.5c-FAU); for ; Tue, 18 Mar 1997 22:24:24 +0100 (MET) Received: from laertes by mi.uni-erlangen.de with SMTP; id WAA25059 (SMI-8.6/7.5b-FAU); Tue, 18 Mar 1997 22:24:23 +0100 From: Frank Heckenbach Message-Id: <199703182124.WAA25059@helena.mi.uni-erlangen.de> Date: Tue, 18 Mar 1997 21:24:22 GMT To: gpc@hut.fi Subject: Re: Variable number of parameters Status: RO (Continuation of this thread from c.l.p.b) kblix@sn.no (Kim Robert Blix) wrote: > heckenb@mi.uni-erlangen.de (Frank Heckenbach) once said: > >> There is NO challange in locating the obstacles - they will become obvious > >> anyway. Try to find a solution instead - Its so much more rewarding. > > > >No, I don't agree. Your approach sounds much like "let's just program a few > >lines, and if it doesn't work, we'll change everything". This ad-hoc strategy > >might work for small projects, but any larger project (of which a Pascal > >compiler is most definitely one), needs some good planning and design before > >starting the actual coding. This includes identifying all the obstacles in > >advance, and finding solutions to them - first a general solution, then a > >concrete way to implement the solution, then verify that the solution really > >covers all situations... It might not be as much fun as just sitting down in > >front of the screen and typing a few lines of code, but it's the only way to > >manage the complexity of such a project. > > Yes, I agree. What I meant was that when this was first presented to the group, > a lot of people started by saying "this cant be done" and "this is not possible" > instead of "this would be hard because of that and that, but could possibly be > solved by this" .. The only constructive replays has come from you. Thanks! But don't forget that the newsgroup is about *Borland* Pascal, and most people are mainly interested in it, and speaking from this perspective. > >But again: be careful with it! C needs it because the language itself lacks > >some features like constants or modularization. However, Pascal - in a > >sufficiently sophisticated version - should not need a preprocessor at all, > >except for things like symbol-dependent compilation. IMHO, it's good style > >to avoid the preprocessor when possible. > > But It can be oooh so practical when needed. :) But there are many traps. Imagine the following: {$define sum a+b} d*sum - this will be d*a+b, i.e. (d*a)+b instead of d*(a+b) as one might expect. or: {$define square(a) a*a} (if sqr wasn't already declared) function f:real; begin {Long and complicated code} end; square(f) - you see what happens? > >> you could just check what the variable was defined as, and then handle it in the > >> appropriate way. this would go for any declared variable. In cases like this: > >> write('this is a number',51) > >> > >> you check if its a string (quoted) or a number (non-quoted). This pretty much > >> includes most cases. > > > >Not quite. Detecting the types is a bit more complex than you might imagine > >now, but it is surely possible - it's one of the important things the compile > >has to keep track of. The difficulty comes in when the compiler has to decide > >between several possible procedures/functions to call (as it can do for > >Write(ln), but is quite more involved for user-defined overloading/varargs). > > Do you have an example where the above approach would fail? You mean the rule: string if quoted, number otherwise? There are many examples: - variables: not quoted, but can be strings, numbers or anything else - function results: the same - expressions (like a+b): the same - constants: the same - ... And dont't forget that there are many other types besides strings and numbers! If you're really interested in how these things works, you'll have to find out a lot about parsing and similar things. > >I think we should carry on this discussion on the mailing list. If you follow > >up, please post there. Anyone else from this group who's interested in this > >subject can subscribe to the list or fetch the postings from its archive, > >with the URLs I posted the other day. > > Argh! :) You could have mentioned that a bit earlier in your post! :) > I'll Jump in and subscribe today. I'd assume you read the whole article before starting to reply... Besides, you could still have posted to the list instead of the newsgroup, I suppose... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Tue Mar 18 21:07:08 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA22500 for ; Tue, 18 Mar 1997 21:07:07 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86554; Tue, 18 Mar 1997 20:17:20 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69612; Tue, 18 Mar 1997 20:17:40 +0100 Received: from mta3.rocketmail.com (mta3.rocketmail.com [205.180.57.73]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA30271 for ; Tue, 18 Mar 1997 21:09:28 +0200 (EET) Received: from web4 (web4.rocketmail.com [205.180.57.78]) by mta3.rocketmail.com (8.8.5/8.6.12) with SMTP id LAA00680 for ; Tue, 18 Mar 1997 11:07:39 -0800 (PST) Message-Id: <199703181907.LAA00680@mta3.rocketmail.com> Date: Tue, 18 Mar 1997 11:09:49 -0800 (PST) From: Gareth Wilson Subject: Pascal Compiler Bug To: gpc@hut.fi Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="-2139045425-758783491-858712189=:13474" Status: RO ---2139045425-758783491-858712189=:13474 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please Read This Text File :-( _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com ---2139045425-758783491-858712189=:13474 Content-Type: text/plain; name="Bug.txt" Content-Description: Bug.txt Content-Disposition: inline; filename="Bug.txt" The following code, especially the Arrays, causes GPC1.EXE to page fault. I think this is a bug of the compiler because if I comment them out the compiler runs (complaining about invalid reference to Colours, Cmds, etc.) Type TComStr = String(8); TColStr = String(12); Const NumCmds : Byte = 12; Var Colours : Array[0..15] Of TColStr Value (0 :'BLACK'; 1 :'BLUE'; 2 :'GREEN'; 3 :'CYAN'; 4 :'RED'; 5 :'MAGENTA'; 6 :'BROWN'; 7 :'LIGHTGREY'; 8 :'DARKGREY'; 9 :'LIGHTBLUE'; 10:'LIGHTGREEN'; 11:'LIGHTCYAN'; 12:'LIGHTRED'; 13:'LIGHTMAGENTA'; 14:'YELLOW'; 15:'WHITE'); Cmds : Array[1..12] Of TComStr Value (1 :'@POS('; 2 :'@COLOUR('; 3 :'@CLS'; 4 :'@WAIT('; 5 :'@CURSON'; 6 :'@CURSOFF'; 7 :'@FILE('; 8 :'@LOAD('; 9 :'@SAVE('; 10:'@FILL('; 11:'@SLEEP('; 12:'@SOUND('); Stack trace: Exiting due to signal SIGSEGV Page fault at eip=0003bdbd, error=0004 eax=00000112 ebx=00191ecc ecx=0018db3c edx=00191e38 esi=00182dd4 edi=00000006 ebp=00182cf8 esp=00182cec program=c:/utils/djgpp/bin\gpc1.exe cs: sel=0127 base=100d0000 limit=001cffff ds: sel=012f base=100d0000 limit=001cffff es: sel=012f base=100d0000 limit=001cffff fs: sel=010f base=000165b0 limit=0000ffff gs: sel=013f base=00000000 limit=ffffffff ss: sel=012f base=100d0000 limit=001cffff Call frame traceback EIPs: 0x0003bdbd 0x0003bdee 0x0001b2a4 0x0006fdfa 0x000721e9 0x0011818e Please respond to Gareth_Wilson@RocketMail.Com. ---2139045425-758783491-858712189=:13474-- From gpc-request@santra.hut.fi Tue Mar 18 12:37:39 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA21818 for ; Tue, 18 Mar 1997 12:37:38 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA86794; Tue, 18 Mar 1997 11:48:00 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28158; Tue, 18 Mar 1997 11:48:19 +0100 Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA07709 for ; Tue, 18 Mar 1997 12:33:16 +0200 (EET) Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id FAA21574; Tue, 18 Mar 1997 05:32:44 -0500 Date: 18 Mar 97 05:31:39 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: "'gpc'" Subject: Re: Sockets Message-Id: <970318103139_100120.3121_EHU93-1@CompuServe.COM> Status: RO You wrote: >I need to use network sockets from gpc. Can I do this? How? Yes, by writing a module which links in the corresponding c routines. Groetjes, Berend. From gpc-request@santra.hut.fi Mon Mar 17 21:48:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA20433 for ; Mon, 17 Mar 1997 21:48:22 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93382; Mon, 17 Mar 1997 20:58:55 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65624; Mon, 17 Mar 1997 20:59:13 +0100 Received: from snert.wash.cedar-rapids.k12.ia.us (snert.wash.cedar-rapids.k12.ia.us [205.221.77.102]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA20119 for ; Mon, 17 Mar 1997 21:40:30 +0200 (EET) Received: (from lindholm@localhost) by snert.wash.cedar-rapids.k12.ia.us (8.8.4/8.7.1) id NAA07274 for gpc@hut.fi; Mon, 17 Mar 1997 13:48:30 -0600 Date: Mon, 17 Mar 1997 13:48:30 -0600 From: Stephen Lindholm Message-Id: <199703171948.NAA07274@snert.wash.cedar-rapids.k12.ia.us> To: gpc@hut.fi Subject: Sockets Status: RO I need to use network sockets from gpc. Can I do this? How? From gpc-request@santra.hut.fi Thu Mar 20 13:44:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA26320 for ; Thu, 20 Mar 1997 13:44:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77356; Thu, 20 Mar 1997 12:53:41 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51188; Thu, 20 Mar 1997 12:54:04 +0100 Received: from ahimsa.fsid.cvut.cz (srbt@ahimsa.fsid.cvut.cz [147.32.161.60]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA03801 for ; Thu, 20 Mar 1997 13:40:15 +0200 (EET) Received: (from srbt@localhost) by ahimsa.fsid.cvut.cz (8.8.0/8.8.0) id MAA14447 for gpc@hut.fi; Thu, 20 Mar 1997 12:40:25 +0100 Date: Thu, 20 Mar 1997 12:40:25 +0100 From: Tomas Srb Message-Id: <199703201140.MAA14447@ahimsa.fsid.cvut.cz> To: gpc@hut.fi Subject: Two bugs Status: RO { Propably any bug in gpc 2.0 (GNU Pascal) } program Bug1(Input,Output); type Str255=String(255); procedure Gogo(S:String; var SOut:Str255); begin WriteLn(' Before Error '); SOut:='aha'; { ! ?GPC runtime error: runtime error (#-1) ! } WriteLn(' After Error '); end; var S:Str255; begin S:='1234'; Gogo(S,S); end. { Bug #2 ! } program Bug2(Input,Output); type Str255=String(255); var I:Integer; function Gogo(S:String):Str255; begin WriteLn(' Gogo '); Inc(I); Gogo:=S; end; var S:Str255; begin I:=0; S:='1234'; S:=Gogo(S); { ! No one call Gogo bat three calls ! } WriteLn(I); { ! I=3 I!=0 } end. { Please send my if you know any solution srbt@fsid.cvut.cz } . From gpc-request@santra.hut.fi Thu Mar 20 14:37:13 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA26488 for ; Thu, 20 Mar 1997 14:37:12 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA98402; Thu, 20 Mar 1997 13:46:51 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA34098; Thu, 20 Mar 1997 13:47:14 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA06418 for ; Thu, 20 Mar 1997 14:36:34 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA26449; Thu, 20 Mar 1997 14:25:56 +0100 From: Peter Gerwinski Message-Id: <199703201325.OAA26449@agnes.dida.physik.uni-essen.de> Subject: Re: Pascal Compiler Bug To: gareth_wilson@rocketmail.com, gpc@hut.fi Date: Thu, 20 Mar 1997 14:25:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Gareth Wilson: > The following code, especially the Arrays, causes GPC1.EXE to page fault. I > think this is a bug of the compiler because if I comment them out the > compiler runs (complaining about invalid reference to Colours, Cmds, etc.) Yes, this was an error in GPC. It is corrected in recent Alpha versions of GPC. Look at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ However there are still known problems with initializers. For example array indices and field names are ignored in initializers; the components of a structured variable are always initialized in order. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Mar 20 14:59:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA26580 for ; Thu, 20 Mar 1997 14:59:20 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91090; Thu, 20 Mar 1997 14:08:58 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44596; Thu, 20 Mar 1997 14:09:21 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA06698 for ; Thu, 20 Mar 1997 14:57:18 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA26524; Thu, 20 Mar 1997 14:45:28 +0100 From: Peter Gerwinski Message-Id: <199703201345.OAA26524@agnes.dida.physik.uni-essen.de> Subject: Re: Two bugs To: srbt@fsid.cvut.cz (Tomas Srb), gpc@hut.fi Date: Thu, 20 Mar 1997 14:45:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Tomas Srb: > procedure Gogo(S:String; var SOut:Str255); > begin > WriteLn(' Before Error '); > SOut:='aha'; { ! ?GPC runtime error: runtime error (#-1) ! } > WriteLn(' After Error '); > end; Indeed! Thank you for the report; I will gogo and hunt this bug ... > [...] > S:=Gogo(S); { ! No one call Gogo bat three calls ! } > WriteLn(I); { ! I=3 I!=0 } That's strange because this bug was fixed *before* gpc-2.0 was released; it was present in gpc-1.2 or before. I cannot reproduce it with my current development version, so this bug should disappear when you take a current alpha version of GPC. Look at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Mar 21 23:22:59 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA29123 for ; Fri, 21 Mar 1997 23:22:59 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95092; Fri, 21 Mar 1997 22:32:09 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39682; Fri, 21 Mar 1997 22:32:33 +0100 Received: from babe.globecomm.net (babe.globecomm.net [207.51.48.8]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA08298 for ; Fri, 21 Mar 1997 23:20:09 +0200 (EET) Received: from FOO.telia.com (t4o28p24.telia.com [195.198.148.204]) by babe.globecomm.net (8.8.5/8.8.0) with ESMTP id QAA01298 for ; Fri, 21 Mar 1997 16:20:04 -0500 (EST) Message-Id: <199703212120.QAA01298@babe.globecomm.net> Reply-To: From: "Morgan Kurtto" To: Subject: Terve... Date: Fri, 21 Mar 1997 22:19:41 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by santra.hut.fi id XAA08207 Status: RO Haluaisin koittaa ohjelmointia. Onko Gnu Pascal aloittelioille? Olen kuullut ett=E4 Pascal olisi helppo kieli ja hyv=E4. Toivoisin ett=E4 saisin vastauksen. T: Morgan Kurtto Ruotsi From gpc-request@santra.hut.fi Fri Mar 21 20:10:48 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA28869 for ; Fri, 21 Mar 1997 20:10:47 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83360; Fri, 21 Mar 1997 19:20:00 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79384; Fri, 21 Mar 1997 19:20:25 +0100 Received: from gentzen.mat.uc.pt (root@gentzen.mat.uc.pt [192.138.204.161]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA32245 for ; Fri, 21 Mar 1997 20:11:03 +0200 (EET) Received: by gentzen.mat.uc.pt id m0w88mP-0000cmC (Debian /\oo/\ Smail3.1.29.1 #29.37); Fri, 21 Mar 97 18:11 WET Message-Id: Date: Fri, 21 Mar 97 18:11 WET From: Pedro Quaresma de Almeida To: gpc@hut.fi Subject: Problems with gpc Mime-Version: 1.0 (generated by tm-edit 7.93) Content-Type: text/plain; charset=US-ASCII Status: RO Hi == I have installed GNU Pascal compiler, apparently without any problem. bash# dpkg -i gpc_2.0-3.deb (Reading database ... 23654 files and directories currently installed.) Preparing to replace gpc (using gpc_2.0-3.deb) ... Unpacking replacement gpc ... Setting up gpc ... bash# dpkg -i libgpc2_2.0-3.deb (Reading database ... 23654 files and directories currently installed.) Preparing to replace libgpc2 (using libgpc2_2.0-3.deb) ... Unpacking replacement libgpc2 ... Setting up libgpc2 ... bash# ldconfig but when I try to use it ... bash$ gpc Ackerman.p ld: cannot open -lgpc: No such file or directory bash$ can you help me? Thanks. -- At\'e breve =========== Pedro Quaresma de Almeida Departamento de Matem\'atica Faculdade de Ci\^encias e Tecnologia Universidade de Coimbra P-3000 COIMBRA, PORTUGAL e-mail: pedro@mat.uc.pt url: http://www.mat.uc.pt/~pedro/ From gpc-request@santra.hut.fi Fri Mar 21 16:49:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA28611 for ; Fri, 21 Mar 1997 16:49:34 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84216; Fri, 21 Mar 1997 15:58:50 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65846; Fri, 21 Mar 1997 15:59:14 +0100 Received: from snert.wash.cedar-rapids.k12.ia.us (snert.wash.cedar-rapids.k12.ia.us [205.221.77.102]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA28223 for ; Fri, 21 Mar 1997 16:48:05 +0200 (EET) Received: (from lindholm@localhost) by snert.wash.cedar-rapids.k12.ia.us (8.8.4/8.7.1) id IAA32363 for gpc@hut.fi; Fri, 21 Mar 1997 08:56:16 -0600 Date: Fri, 21 Mar 1997 08:56:16 -0600 From: Stephen Lindholm Message-Id: <199703211456.IAA32363@snert.wash.cedar-rapids.k12.ia.us> To: gpc@hut.fi Subject: Forward decl Status: RO I seem to be having trouble with the forward attrbute for procedures. The problem is intermittant and I can't narrow it down very easily to a short test rogram. Has anyone else had this difficulty? I'll continue trying to see examtly what's wrong. (It could be a problem on my end.) From gpc-request@santra.hut.fi Tue Mar 25 05:30:29 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id FAA02004 for ; Tue, 25 Mar 1997 05:30:29 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96640; Tue, 25 Mar 1997 04:38:30 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51528; Tue, 25 Mar 1997 04:39:00 +0100 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id FAA24535 for ; Tue, 25 Mar 1997 05:31:21 +0200 (EET) Received: from monstro (borg.mindspring.com [204.180.128.14]) by mule0.mindspring.com (8.8.5/8.8.4) with SMTP id WAA141802 for ; Mon, 24 Mar 1997 22:31:10 -0500 Message-Id: <333746C9.3D3D@mindspring.com> Date: Mon, 24 Mar 1997 22:30:17 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: GNU Pascal Mailing List Subject: GPC and UNIX Curses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO HI, I have tried to interface GPC with the Curses system and I am running into a problem with names: There are two name in Curses that are different only by their capitalization. One is a variable declared as extern. The other is a function. example: /* in C */ extern int COLORS; extern int colors(); (* in Pascal *) var COLORS : integer; {can I do this???} procedure colors;c; I am trying to interface GPC to Curses but I don't know how to pull this one off. Help! -- Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Sat Mar 22 17:06:24 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA30448 for ; Sat, 22 Mar 1997 17:06:24 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72336; Sat, 22 Mar 1997 16:15:19 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70334; Sat, 22 Mar 1997 16:15:46 +0100 Received: from dub-img-4.compuserve.com (dub-img-4.compuserve.com [149.174.206.134]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA24517 for ; Sat, 22 Mar 1997 17:08:30 +0200 (EET) Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id KAA15134; Sat, 22 Mar 1997 10:07:56 -0500 Date: 22 Mar 97 10:05:58 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: "'gpc'" Subject: Re: Variable number of parameters Message-Id: <970322150557_100120.3121_EHU94-1@CompuServe.COM> Status: RO You wrote: >BTW, what about conformant arrays? Do they work with GPC, or are >there >still bugs? Somebody out there to write some documentation notes >about >conformant arrays to tell the poor Borland Pascal programmers (like >me;) >how to use them? Here a sample (gpc: Internal compiler error: program gpc1 got fatal signal 11) program TestConformantArrays; procedure Test1(var a: array[j..k: integer] of real); var i: integer; begin for i := j to k do a[i] := 0.0; end; var a1: array[0..9] of real; begin Test1(a1); end. Groetjes, Berend. From gpc-request@santra.hut.fi Fri Mar 14 06:12:13 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id GAA13336 for ; Fri, 14 Mar 1997 06:12:13 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64268; Fri, 14 Mar 1997 05:24:04 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA27254; Fri, 14 Mar 1997 05:24:16 +0100 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id GAA23225 for ; Fri, 14 Mar 1997 06:11:55 +0200 (EET) Received: from monstro (borg.mindspring.com [204.180.128.14]) by mule0.mindspring.com (8.8.5/8.8.4) with SMTP id XAA213288 for ; Thu, 13 Mar 1997 23:11:52 -0500 Message-Id: <3328CFDF.24BC@mindspring.com> Date: Thu, 13 Mar 1997 23:11:11 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: GNU Pascal Subject: Pascal's identity. References: <970311121010_100120.3121_EHU52-1@CompuServe.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Berend de Boer wrote: > > I think if you really want var args, function overloading, powerfull > preprocessors, etc. program in C or C++. > > Don't fool with Pascal's identity. As far as I am concerned, Pascal has no identity. Pascal is what developers make of it. Standard Pascal was practically useless when Borland wrote TP. They popularized it by making it competitive with the other "hot" languages at the time: Compiled Basic and C. I can understand a need for language purity. However, if Pascal does not evolve to support those constructs used by modern programmers, it will be forgotten. I don't see why Pascal could not evolve to have exceptions, coroutines, multiprocessing support, or objects/classes. Delphi has provided some of these already. Heck, C++ is evolving as we speak. Why should Pascal be the laggard? Note: Personally, I don't want to see a preprocessor in Pascal. CPP has thoroughly screwed up C/C++. The import facility is better than #include in C. Perhaps we should look more towards Java for new features rather than C++ (shudder!). [stuff deleted]> > Groetjes, > > Berend. Cheers! Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Tue Mar 25 21:46:10 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03930 for ; Tue, 25 Mar 1997 21:46:10 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96500; Tue, 25 Mar 1997 20:53:57 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26306; Tue, 25 Mar 1997 20:54:29 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA32253 for ; Tue, 25 Mar 1997 21:48:58 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA03845; Tue, 25 Mar 1997 21:40:02 +0100 From: Peter Gerwinski Message-Id: <199703252040.VAA03845@agnes.dida.physik.uni-essen.de> Subject: Problems with gpc To: gpc@hut.fi, pedro@mat.uc.pt Date: Tue, 25 Mar 1997 21:40:02 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Pedro Quaresma de Almeida: > I have installed GNU Pascal compiler, apparently without any > problem. > > bash# dpkg -i gpc_2.0-3.deb > (Reading database ... 23654 files and directories currently installed.) > Preparing to replace gpc (using gpc_2.0-3.deb) ... > Unpacking replacement gpc ... > Setting up gpc ... > > bash# dpkg -i libgpc2_2.0-3.deb > (Reading database ... 23654 files and directories currently installed.) > Preparing to replace libgpc2 (using libgpc2_2.0-3.deb) ... > Unpacking replacement libgpc2 ... > Setting up libgpc2 ... > bash# ldconfig This looks like a Debian distribution. I didn't know that there exists a Debian distribution of gpc-2.0 ... > but when I try to use it ... > > bash$ gpc Ackerman.p > ld: cannot open -lgpc: No such file or directory > bash$ Obviously, the `gpc' driver program cannot locate the library `libgpc.a'. >From the installation log I have the impression that you did not install `libgpc.a' but a file named `libgpc2.a'. Perhaps both are the same, and it suffices to link `libgpc.a' to `libgpc2.a' in your `/usr/lib/' directory or whereever you keep your libraries? In any case it should solve your problems (without warranty, of course ;-) to install an "original" binary distribution of gpc-2.0 like those on ftp://kampi.hut.fi/jtv/gnu-pascal/binary/ We provide at binaries for i586-linux (elf), i586-linuxaout, and i586-linuxoldld. The "i586" means that some optimization have been done for the Pentium; the compiler runs fine on an i486 or 80386 and can produce code for all of these processors. To install such a binary package, cd to the top directory and "tar xzf" the archive, e.g. myhost:/# tar xzf /usr/src/gpc-2.0.i586-linux.tar.gz Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 25 21:47:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03941 for ; Tue, 25 Mar 1997 21:47:03 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA98588; Tue, 25 Mar 1997 20:54:50 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51190; Tue, 25 Mar 1997 20:55:22 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA31795 for ; Tue, 25 Mar 1997 21:49:14 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA03853; Tue, 25 Mar 1997 21:40:22 +0100 From: Peter Gerwinski Message-Id: <199703252040.VAA03853@agnes.dida.physik.uni-essen.de> Subject: Terve... To: gpc@hut.fi, morgan@royal.net Date: Tue, 25 Mar 1997 21:40:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Morgan Kurtto: > Haluaisin koittaa ohjelmointia. > Onko Gnu Pascal aloittelioille? > Olen kuullut ett=E4 Pascal olisi helppo kieli ja hyv=E4. > Toivoisin ett=E4 saisin vastauksen. > T: Morgan Kurtto > Ruotsi Sorry, but I do not understand what you mean. (Which languages is this? Finnish?) For information about GNU Pascal, see our WWW home page, http://home.pages.de/~GNU-Pascal/ especially the FAQ. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Mar 25 21:47:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA03939 for ; Tue, 25 Mar 1997 21:47:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96536; Tue, 25 Mar 1997 20:54:50 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49394; Tue, 25 Mar 1997 20:55:21 +0100 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA32260 for ; Tue, 25 Mar 1997 21:50:49 +0200 (EET) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA03885 for gpc@hut.fi; Tue, 25 Mar 1997 21:41:58 +0100 From: Peter Gerwinski Message-Id: <199703252041.VAA03885@agnes.dida.physik.uni-essen.de> Subject: GPC and UNIX Curses To: gpc@hut.fi Date: Tue, 25 Mar 1997 21:41:57 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Ronald Perrella: > There are two name in Curses that are different only > by their capitalization. One is a variable declared as extern. > The other is a function. Use the `asmname' directive to access them. Their *Pascal* names must of course differ. > example: > > /* in C */ > extern int COLORS; > > extern int colors(); > > (* in Pascal *) Var ColorVar: __asmname__ 'COLORS' Integer; Function ColorFunc: Integer; asmname 'colors'; Sorry for the underscores and the different syntax for variables and functions. I already suggested to replace `asmname' with something like `external name', Var ColorVar: Integer; external name 'COLORS'; Function ColorFunc: Integer; external name 'colors'; but I did not yet work on this. (See the GPC list archives, starting with 7 Sep 1996, for a discussion about pros and contras for different ideas for the syntax for external name specification.) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From Pedro@mat.uc.pt Tue Mar 25 22:04:03 1997 Return-Path: Pedro@mat.uc.pt Received: from matuc2.mat.uc.pt (matuc2.mat.uc.pt [192.138.204.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA04000 for ; Tue, 25 Mar 1997 22:04:01 +0100 Received: by matuc2.mat.uc.pt (5.57/Ultrix3.0-C) id AA02602; Tue, 25 Mar 97 20:12:42 GMT Date: Tue, 25 Mar 97 20:12:42 GMT From: Pedro@mat.uc.pt (Pedro Quaresma) Message-Id: <9703252012.AA02602@matuc2.mat.uc.pt> Received: by centelha.mat.uc.pt.matematica (4.1/SMI-4.1) id AA01013; Tue, 25 Mar 97 20:12:39 GMT To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199703252040.VAA03845@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Tue, 25 Mar 1997 21:40:02 +0100 (MET)) Subject: Re: Problems with gpc Status: RO Peter Gerwinski =============== >This looks like a Debian distribution. I didn't know that there exists >a Debian distribution of gpc-2.0 ... Yes, it exists Package: gpc Version: 2.0-3 Priority: optional Section: devel Maintainer: Christoph Lameter Depends: libc5,gcc (>=2.7.2.1-2), gcc (<< 2.7.2.2), libgpc2 Architecture: i386 Filename: unstable/binary-i386/devel/gpc_2.0-3.deb Size: 656684 MD5sum: 6ce6be46dfc3d28eadb3c84910e879b4 Description: GNU Pascal Compiler The GNU Pascal Compiler (GPC) is part of the GNU compiler family, GNU CC or GCC. Version 2.0 of GPC corresponds to GCC version 2.7.2.1. installed-size: 1523 >Obviously, the `gpc' driver program cannot locate the library `libgpc.a'. >From the installation log I have the impression that you did not install >`libgpc.a' but a file named `libgpc2.a'. Perhaps both are the same, and >it suffices to link `libgpc.a' to `libgpc2.a' in your `/usr/lib/' directory >or whereever you keep your libraries? The instalation does not provide any "libgpc.a", only "libgpc.so.2". Can I use some switch (-static or ...) to use libgpc.so.2 instead of libgpc.a? Thank you for your help. -- At\'e breve =========== Pedro Quaresma de Almeida Departamento de Matem\'atica Faculdade de Ci\^encias e Tecnologia Universidade de Coimbra P-3000 COIMBRA, PORTUGAL e-mail: pedro@mat.uc.pt url: http://www.mat.uc.pt/~pedro/ From gpc-request@santra.hut.fi Sun Mar 30 03:46:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA11600 for ; Sun, 30 Mar 1997 03:46:23 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95052; Sun, 30 Mar 1997 01:52:42 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35398; Sun, 30 Mar 1997 01:53:20 +0100 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA10511 for ; Sun, 30 Mar 1997 02:47:21 +0200 (EET) Message-Id: <199703300047.CAA10511@santra.hut.fi> Received: (qmail 26424 invoked from smtpd); 30 Mar 1997 00:47:30 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1.sik.e) (194.162.196.18) by teamware.sik.de with SMTP; 30 Mar 1997 00:47:30 -0000 Reply-To: From: "Sven Engelhardt" To: , "Olivier Lecarme" Cc: , Subject: Re: bug in GPC 2.0 Date: Sun, 30 Mar 1997 00:01:54 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by santra.hut.fi id CAA32265 Status: RO ---------- | Von: Olivier Lecarme | An: bug-gpc@prep.ai.mit.edu | Cc: ol@clio.unice.fr; gpc-request@hut.fi | Betreff: bug in GPC 2.0 | Datum: Samstag, 29. M=E4rz 1997 21:53 |=20 | I get the following message when compiling a somewhat complicated | program (2352 lines): |=20 | gpc: Internal compiler error: program gpc1 got fatal signal 6 |=20 | What can I do? Send you the whole program would probably be useless. Ar= e | there some options I could trigger in order to get more information? |=20 | By the way, I encountered another problem with GPC: one program writes = a | file of some complicated record type; another program reads this file, | declared in exactly the same way. However, it seems that every get(file= ) | skips to the next *physical* record, instead of the next logical one. |=20 | Did anybody encounter the same problem? |=20 | --=20 | Olivier Lecarme |=20 Hi Oliver, I've had problems like your's too. (Ok, was fatal signal 11). Usually they were forced by syntactical errors or incorrectly handled keywords. (Somewhere in the documentation you can find a sentence as "a stable compiler never catches fatal signals" - these are bugs in the compiler) IMHO you should try out the latest developer alpha-release, may be its somewhat more stable, isn't it? Sven Engelhardt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sven Engelhardt http://www.sik.de se@sik.de From gpc-request@santra.hut.fi Sat Mar 29 22:14:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA11370 for ; Sat, 29 Mar 1997 22:14:02 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95088; Sat, 29 Mar 1997 21:20:26 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52288; Sat, 29 Mar 1997 21:21:04 +0100 Received: from aiguemarine.unice.fr (aiguemarine.unice.fr [192.134.39.66]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA29992 for ; Sat, 29 Mar 1997 21:57:44 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by aiguemarine.unice.fr (8.8.3/8.6.10) with SMTP id UAA14843 for gpc@hut.fi; Sat, 29 Mar 1997 20:57:42 +0100 Message-Id: <199703291957.UAA14843@aiguemarine.unice.fr> X-Authentication-Warning: aiguemarine.unice.fr: localhost [127.0.0.1] didn't use HELO protocol To: gpc@hut.fi Subject: Mail Delivery Subsystem: Returned mail: User unknown Comments: Hyperbole mail buttons accepted, v04.01. Mime-Version: 1.0 (generated by tm-edit 7.94) Content-Type: multipart/mixed; boundary="Multipart_Sat_Mar_29_20:57:35_1997-1" Content-Transfer-Encoding: 7bit Date: Sat, 29 Mar 1997 20:57:36 +0100 From: "Olivier Lecarme" Status: RO --Multipart_Sat_Mar_29_20:57:35_1997-1 Content-Type: text/plain; charset=US-ASCII Following the indications in the GPC manual, I tried sending a bug report to bug-gpc@prep.ai.mit.edu, which does not exist. As a last resort, I'm trying the GPC mailing list, hoping it exists! --Multipart_Sat_Mar_29_20:57:35_1997-1 Content-Type: message/rfc822 Return-Path: MAILER-DAEMON@aiguemarine.unice.fr Date: Sat, 29 Mar 1997 14:52:59 -0500 (EST) From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <199703291952.OAA11298@gnu-life.ai.mit.edu> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="OAA11298.859665179/gnu-life.ai.mit.edu" Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --OAA11298.859665179/gnu-life.ai.mit.edu The original message was received at Sat, 29 Mar 1997 14:52:56 -0500 (EST) from clio.unice.fr [134.59.2.190] ----- The following addresses had permanent fatal errors ----- (expanded from: ) ----- Transcript of session follows ----- ... while talking to life.ai.mit.edu.: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown --OAA11298.859665179/gnu-life.ai.mit.edu Content-Type: message/delivery-status Reporting-MTA: dns; gnu-life.ai.mit.edu Received-From-MTA: dns; clio.unice.fr Arrival-Date: Sat, 29 Mar 1997 14:52:56 -0500 (EST) Final-Recipient: rfc822; bug-gpc@gnu-life.ai.mit.edu X-Actual-Recipient: rfc822; bug-gpc@life.ai.mit.edu Action: failed Status: 5.1.1 Remote-MTA: dns; life.ai.mit.edu Diagnostic-Code: smtp; 550 ... User unknown Last-Attempt-Date: Sat, 29 Mar 1997 14:52:59 -0500 (EST) --OAA11298.859665179/gnu-life.ai.mit.edu Content-Type: message/rfc822 Return-Path: ol@clio.unice.fr Received: from clio.unice.fr by gnu-life.ai.mit.edu (8.8.5/8.6.12GNU) with ESMTP id OAA11296 for ; Sat, 29 Mar 1997 14:52:56 -0500 (EST) Received: from clio.unice.fr (localhost [127.0.0.1]) by clio.unice.fr (8.7.5/8.7.3) with ESMTP id UAA27990; Sat, 29 Mar 1997 20:53:42 GMT Message-Id: <199703292053.UAA27990@clio.unice.fr> To: bug-gpc@prep.ai.mit.edu cc: ol@clio.unice.fr, gpc-request@hut.fi Subject: bug in GPC 2.0 Mime-Version: 1.0 (generated by tm-edit 7.94) Comments: Hyperbole mail buttons accepted, v04.01. Content-Type: text/plain; charset=US-ASCII Date: Sat, 29 Mar 1997 20:53:41 +0000 From: "Olivier Lecarme" I get the following message when compiling a somewhat complicated program (2352 lines): gpc: Internal compiler error: program gpc1 got fatal signal 6 What can I do? Send you the whole program would probably be useless. Are there some options I could trigger in order to get more information? By the way, I encountered another problem with GPC: one program writes a file of some complicated record type; another program reads this file, declared in exactly the same way. However, it seems that every get(file) skips to the next *physical* record, instead of the next logical one. Did anybody encounter the same problem? -- Olivier Lecarme --OAA11298.859665179/gnu-life.ai.mit.edu-- --Multipart_Sat_Mar_29_20:57:35_1997-1-- From gpc-request@santra.hut.fi Sat Mar 29 15:26:59 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA11119 for ; Sat, 29 Mar 1997 15:26:58 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99940; Sat, 29 Mar 1997 14:33:29 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45810; Sat, 29 Mar 1997 14:34:07 +0100 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA27166 for ; Sat, 29 Mar 1997 15:10:24 +0200 (EET) Message-Id: <199703291310.PAA27166@santra.hut.fi> Received: (qmail 32285 invoked from smtpd); 29 Mar 1997 13:10:00 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1.sik.e) (194.162.196.18) by teamware.sik.de with SMTP; 29 Mar 1997 13:10:00 -0000 Reply-To: From: "Sven Engelhardt" To: Subject: Bug in GPC?! Date: Sat, 29 Mar 1997 14:08:43 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Hi all, I'm writing a somewhat larger Program accessing a mysql-Database. via a C-Library. Config: Linux 2.0.29, gpc-2.0 linux-elf latest binary release... It contains some Records with Pointers to them and an TSQL-Object. And everthing works fine and sizeof(TSQL) is 368 or so (probably correct). Now I want to insert another Object Type, say TResult. Just declared the Object Type like this: {-----------------------------} Type TResult = object k:PChar; procedure init; end; {-----------------------------} Thus some strange SIGSEGV's occur running the program. I inserted WriteLn(SizeOf(TSQL)) which now returns 1. Remember: I didn't access anything new. I really only DECLARED that new type. I tried to track down the Problem to only a few lines of code, but everything runs fine. So now i'm a little bit braindead, i didn't find not even a workaraound (Coding the same without Objects works by now, but I really want to have these objects for oversight and portability reasons) So i deleted some stuff from my prog to put it in a little Testprog, wich consists of about 200 lines. I will mail this at request, but you will need mysql to compile. nb: I 've been noticed some "fatal signals 11" in some cases of syntactic failures. (Quick responses appreciated.) Thanx in advance Sven Engelhardt From gpc-request@santra.hut.fi Fri Mar 28 19:31:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA09577 for ; Fri, 28 Mar 1997 19:31:01 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA98484; Fri, 28 Mar 1997 18:37:49 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76226; Fri, 28 Mar 1997 18:38:24 +0100 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA18349 for ; Fri, 28 Mar 1997 19:31:55 +0200 (EET) Received: (qmail 26674 invoked from smtpd); 28 Mar 1997 17:31:39 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1) (root@194.162.196.18) by teamware.sik.de with SMTP; 28 Mar 1997 17:31:39 -0000 Sender: root@santra.hut.fi Message-Id: <333C0029.7A9CE72F@sik.de> Date: Fri, 28 Mar 1997 18:30:17 +0100 From: Sven Engelhardt Organization: Nacamar Sachsen X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.0.29 i586) Mime-Version: 1.0 To: gpc@hut.fi Subject: C Header Files -> Pascal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi folks, everybody knows an easy way to turn C .h files into Pascal Declarations? Are there existing tools? Thanks in advance Sven Engelhardt From gpc-request@santra.hut.fi Wed Mar 26 16:19:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA05565 for ; Wed, 26 Mar 1997 16:19:36 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99232; Wed, 26 Mar 1997 15:27:08 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49324; Wed, 26 Mar 1997 15:27:40 +0100 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA32289 for ; Wed, 26 Mar 1997 16:15:36 +0200 (EET) Received: (from janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) id PAA02750; Wed, 26 Mar 1997 15:14:59 GMT From: Jan-Jaap van der Heijden Message-Id: <199703261514.PAA02750@wit381304.student.utwente.nl> Subject: Re: Problems with gpc To: Pedro@mat.uc.pt (Pedro Quaresma) Date: Wed, 26 Mar 1997 15:14:58 +0000 (WET) Cc: gpc@hut.fi In-Reply-To: <9703252012.AA02602@matuc2.mat.uc.pt> from "Pedro Quaresma" at Mar 25, 97 08:12:42 pm Reply-To: J.J.vanderHeijden@student.utwente.nl Content-Type: text Status: RO > Filename: unstable/binary-i386/devel/gpc_2.0-3.deb ^^^^^^^^ Thank you very much ;-) > > >Obviously, the `gpc' driver program cannot locate the library `libgpc.a'. > >From the installation log I have the impression that you did not install > >`libgpc.a' but a file named `libgpc2.a'. Perhaps both are the same, and > >it suffices to link `libgpc.a' to `libgpc2.a' in your `/usr/lib/' directory > >or whereever you keep your libraries? > > The instalation does not provide any "libgpc.a", only "libgpc.so.2". > Did you symlink libgpc.so -> libgpc.so.2 (or whatever the exact libname is) ? I played with a shared RTS library in some pre-2.0 beta's but decided not to put it in the 2.0 release because it would require libgpc.so to be distributed with all GPC compiled programs and I feared confusion. Assuming you don't have one of these beta's (they had 96XXXX version numbers), my guess is that the Debian maintainer decided to put this feature back in. Maybe you should ask him. > Can I use some switch (-static or ...) to use libgpc.so.2 instead of > libgpc.a? > No, -static would search for a (nonexisting) libgpc.a If all else fails, you may have to link /usr/lib/gcc-lib/i386-linux/2.7.2.1/libgpc.a -> /usr/lib/libgpc.so.2, but that's very cruel :-( > Thank you for your help. > Happy hacking, JanJaap From gpc-request@santra.hut.fi Mon Mar 31 19:25:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA14724 for ; Mon, 31 Mar 1997 19:25:34 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82120; Mon, 31 Mar 1997 18:31:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61330; Mon, 31 Mar 1997 18:32:01 +0200 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA21426 for ; Mon, 31 Mar 1997 19:13:18 +0300 (EET DST) Message-Id: <199703311613.TAA21426@santra.hut.fi> Received: (qmail 1395 invoked from smtpd); 31 Mar 1997 15:13:22 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1.sik.e) (194.162.196.18) by teamware.sik.de with SMTP; 31 Mar 1997 15:13:22 -0000 Reply-To: From: "Sven Engelhardt" To: "Ronald Perrella" Cc: Subject: Re: C Header Files -> Pascal Date: Mon, 31 Mar 1997 18:10:55 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by santra.hut.fi id TAA21278 Status: RO ---------- | Von: Ronald Perrella | An: gpc@hut.fi | Betreff: Re: C Header Files -> Pascal | Datum: Montag, 31. M=E4rz 1997 03:53 |=20 | Sven Engelhardt wrote: | >=20 | > Hi folks, | >=20 | > everybody knows an easy way to turn C .h files into Pascal | > Declarations? Are there existing tools? | >=20 | > Thanks in advance | >=20 | > Sven Engelhardt |=20 | Amen! That would be great! Rather than a complete converter,=20 | perhaps a program could be written that conversts 80% or so=20 | leaving just a little cleanup work behind. Any takers? I agree. Though IMHO there already exist such tools. Possibly I will do this ... (if there aren't any parser-specialist) Or may be there is a way to use C .h files directly by slightly modifiying the preprocessor. This would be a really great deal for guys like me that permanently update some library-version... nb. any way to issue linker-options (-lxxx -L) as preprocessor- directives, so one could write rater developer-friendly code. Sven Engelhardt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Laugh at your problems, all the others do so. Sven Engelhardt http://www.sik.de se@sik.de From gpc-request@santra.hut.fi Mon Mar 31 04:55:24 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA13536 for ; Mon, 31 Mar 1997 04:55:24 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99910; Mon, 31 Mar 1997 04:01:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA33116; Mon, 31 Mar 1997 04:02:02 +0200 Received: from brickbat8.mindspring.com (brickbat8.mindspring.com [207.69.200.11]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id EAA11502 for ; Mon, 31 Mar 1997 04:54:39 +0300 (EET DST) Received: from monstro (borg.mindspring.com [204.180.128.14]) by brickbat8.mindspring.com (8.8.5/8.8.5) with SMTP id UAA15697 for ; Sun, 30 Mar 1997 20:54:28 -0500 (EST) Message-Id: <333F191A.5F04@mindspring.com> Date: Sun, 30 Mar 1997 20:53:30 -0500 From: Ronald Perrella X-Mailer: Mozilla 2.02 (WinNT; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: Re: C Header Files -> Pascal References: <333C0029.7A9CE72F@sik.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Sven Engelhardt wrote: > > Hi folks, > > everybody knows an easy way to turn C .h files into Pascal > Declarations? Are there existing tools? > > Thanks in advance > > Sven Engelhardt Amen! That would be great! Rather than a complete converter, perhaps a program could be written that conversts 80% or so leaving just a little cleanup work behind. Any takers? -- Ronald Perrella perrella@mindspring.com Roswell, Georgia, USA. From gpc-request@santra.hut.fi Mon Mar 31 03:21:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA13486 for ; Mon, 31 Mar 1997 03:21:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99596; Mon, 31 Mar 1997 02:27:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76352; Mon, 31 Mar 1997 02:28:19 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA09466 for ; Mon, 31 Mar 1997 03:18:55 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA13420 for gpc@hut.fi; Mon, 31 Mar 1997 03:11:46 +0200 From: Peter Gerwinski Message-Id: <199703310111.DAA13420@agnes.dida.physik.uni-essen.de> Subject: Objects (was: Bug in GPC!?) To: gpc@hut.fi Date: Mon, 31 Mar 1997 03:11:45 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Sven Engelhardt: > [...] > Now I want to insert another Object Type, say TResult. Just declared the > Object Type like this: > [...] > Remember: I didn't access anything new. I really only DECLARED that new > type. I tried to track down the Problem to only a few lines of code, but > everything runs fine. This is probably an occurrence of the "crazy objects bug" - see my mail to this list from 7 Feb 1997, available in the GPC mailing list archive, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/gpc-list.1997.gz > So now i'm a little bit braindead, So was I when I detected that bug! :-) But don't worry, this bug is (or should be) fixed in GPC alpha versions after 7 Feb 1997. I recommend to upgrade to the most recent alpha GPC (which will become obsolete in the next days), available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ In case some other things break with the current version, please try gpc-970208; the changes from gpc-970208 to gpc-970215 were somehow risky. In any case, please report it if you encounter bugs in the current alpha GPC version. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Mar 31 03:21:37 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA13482 for ; Mon, 31 Mar 1997 03:21:37 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99334; Mon, 31 Mar 1997 02:27:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76346; Mon, 31 Mar 1997 02:28:16 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA09646 for ; Mon, 31 Mar 1997 03:19:54 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA13449 for gpc@hut.fi; Mon, 31 Mar 1997 03:12:44 +0200 From: Peter Gerwinski Message-Id: <199703310112.DAA13449@agnes.dida.physik.uni-essen.de> Subject: Re: Problems with gpc To: gpc@hut.fi Date: Mon, 31 Mar 1997 03:12:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Pedro Quaresma: > > The instalation does not provide any "libgpc.a", only "libgpc.so.2". > > Can I use some switch (-static or ...) to use libgpc.so.2 instead of > libgpc.a? I don't know. If somebody does, please post a short explanation of those `libfoo.so.42' stuff - or a pointer (URL) to such an explanation - to this list. To make your GPC work you can download one of our binary distributions - ftp://kampi.hut.fi/jtv/gnu-pascal/binary/ - and install the `libgpc.a' included there. Of course a shared library is more reasonable, but I don't know enough about them to help you with them, sorry. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Mar 31 03:21:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA13478 for ; Mon, 31 Mar 1997 03:21:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99188; Mon, 31 Mar 1997 02:27:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45612; Mon, 31 Mar 1997 02:27:59 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA09697 for ; Mon, 31 Mar 1997 03:18:42 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA13412 for gpc@hut.fi; Mon, 31 Mar 1997 03:11:32 +0200 From: Peter Gerwinski Message-Id: <199703310111.DAA13412@agnes.dida.physik.uni-essen.de> Subject: Bug report (was: Mail delivery error) To: gpc@hut.fi Date: Mon, 31 Mar 1997 03:11:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Olivier Lecarme: > Following the indications in the GPC manual, I tried sending a bug > report to bug-gpc@prep.ai.mit.edu, which does not exist. As a last > resort, I'm trying the GPC mailing list, hoping it exists! It does exist. :-) > ----- The following addresses had permanent fatal errors ----- > > (expanded from: ) In fact we have a bug reporting system: See the page "bugs" on our WWW site, http://home.pages.de/~gnu-pascal/ but actually most bug reports go through this list, so you did it right. I expect that the mail reporting system will become more useful when GPC is getting more stable and we will fine-tune the compiler. > I get the following message when compiling a somewhat complicated > program (2352 lines): > > gpc: Internal compiler error: program gpc1 got fatal signal 6 > > What can I do? Send you the whole program would probably be useless. Are > there some options I could trigger in order to get more information? Alpha versions of GPC have an option "-dY" which tells GPC to echo each source line to stderr. Then you can see where in the source GPC crashes. Another interesting option in this context is "-dy" which lets GPC output parsing debugging information. If you post the last "rule" listed there, e.g. Reducing via rule 616 (line 3782), variable_or_function_access_maybe_assignment rest_of_statement -> assignment_or_call_statement it might already tell me something about the error. (The line number refers to the GPC source file `gpc-parse.y'.) > By the way, I encountered another problem with GPC: one program writes a > file of some complicated record type; another program reads this file, > declared in exactly the same way. However, it seems that every get(file) > skips to the next *physical* record, instead of the next logical one. This I don't understand ... could you please explain what you mean by "physical" and "logical"? Perhaps it's an alignment problem? Within records, GPC aligns Integers on 4-byte boundaries, etc. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Mar 31 23:45:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA15057 for ; Mon, 31 Mar 1997 23:45:42 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99460; Mon, 31 Mar 1997 22:51:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60458; Mon, 31 Mar 1997 22:52:06 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA26558 for ; Mon, 31 Mar 1997 23:45:07 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA14991 for gpc@hut.fi; Mon, 31 Mar 1997 23:38:14 +0200 From: Peter Gerwinski Message-Id: <199703312138.XAA14991@agnes.dida.physik.uni-essen.de> Subject: Re: C Header Files -> Pascal To: gpc@hut.fi Date: Mon, 31 Mar 1997 23:38:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Sven Engelhardt: > I agree. Though IMHO there already exist such tools. Possibly > I will do this ... (if there aren't any parser-specialist) I don't know any parser-specialist. (No, I am not one either.;) I also have never seen any working converter. It would be highly welcome if you would write one! > Or may be there is a way to use C .h files directly by slightly > modifiying the preprocessor. This would be a really great deal > for guys like me that permanently update some library-version... This would mean nothing else than to build the converter program into GPC - making GPC understand C source in effect. I don't think this is a good idea. The only reasonable thing I can imagine in this context would be to write a preprocessor switch which changes the language during the compilation, e.g. Program FooBar; Var Foo: Integer; #language C int bar; void setbar (void) { bar = foo; } #language Pascal begin Foo:= 3; SetBar; end. or, when the C part is in a header file, Program FooBar; Var Foo: Integer; #language C #include "bar.h" #language Pascal begin Foo:= 3; SetBar; end. ... but such a thing would be *very* hard to write. If you really must rely on C headers which change from time to time, it is probably the most reasonable thing to write a C module which uses the header files and exports some well-defined functions. Then you can write a Unit which imports these functions as `external' functions and makes them accessible for your Pascal program. Another thing I did experiments with was a C program which includes the header files and writes out Pascal source for all constants defined in the header. But all these are kludges. The best thing still will be a converter program. What about writing it with GNU Pascal, so we will get a real-world demo program simultaneously? Happy hacking, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Mar 31 23:45:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA15027 for ; Mon, 31 Mar 1997 23:45:22 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99314; Mon, 31 Mar 1997 22:51:04 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78614; Mon, 31 Mar 1997 22:51:46 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA27163 for ; Mon, 31 Mar 1997 23:44:52 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA14983 for gpc@hut.fi; Mon, 31 Mar 1997 23:37:58 +0200 From: Peter Gerwinski Message-Id: <199703312137.XAA14983@agnes.dida.physik.uni-essen.de> Subject: Linking directives (was: C Header Files -> Pascal) To: gpc@hut.fi Date: Mon, 31 Mar 1997 23:37:58 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Sven Engelhardt: > nb. any way to issue linker-options (-lxxx -L) as preprocessor- > directives, so one could write rater developer-friendly code. This is planned. My idea was to make "(*$L foo.o *)" equivalent to a file name `foo.o' given in the command line. One could also make "(*$L /usr/lib *)" equivalent to "-L /usr/lib" because GPC can check whether the given name refers to a file or a directory. Any idea how to implement the "-lxxx" option as a compiler directive? > Laugh at your problems, all the others do so. Guter Spruch! :-(-: I will try to do so. :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From codc01@zeus.GEL.USherb.CA Tue Apr 1 00:37:28 1997 Return-Path: codc01@zeus.GEL.USherb.CA Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA15191 for ; Tue, 1 Apr 1997 00:37:26 +0200 Received: from castor.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA26810; Mon, 31 Mar 97 16:44:13 EST Received: by castor.gel.usherb.ca (SMI-8.6/SMI-SVR4) id QAA26531; Mon, 31 Mar 1997 16:44:12 -0500 Date: Mon, 31 Mar 1997 16:44:12 -0500 (EST) From: "Carl-Eric.Cod\hre" X-Sender: codc01@castor To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: C Header Files -> Pascal In-Reply-To: <199703312138.XAA14991@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 31 Mar 1997, Peter Gerwinski wrote: > According to Sven Engelhardt: > > I agree. Though IMHO there already exist such tools. Possibly > > I will do this ... (if there aren't any parser-specialist) > > I don't know any parser-specialist. (No, I am not one either.;) I also > have never seen any working converter. It would be highly welcome if > you would write one! > Greetings, Sorry to intrude, but I think Florian already started such a tool and unless I am mistaken it is available on his developer page. From gpc-request@santra.hut.fi Tue Apr 1 20:32:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA17086 for ; Tue, 1 Apr 1997 20:32:56 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99560; Tue, 1 Apr 1997 19:38:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62442; Tue, 1 Apr 1997 19:39:03 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA09903 for ; Tue, 1 Apr 1997 20:25:21 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id JAA23150; Tue, 1 Apr 1997 09:24:42 -0800 (PST) Date: Tue, 1 Apr 1997 09:24:42 -0800 (PST) From: Phil Nelson Message-Id: <199704011724.JAA23150@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199704011559.RAA16852@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Tue, 1 Apr 1997 17:59:11 +0200 (MET DST)) Subject: Re: New Alpha Status: RO Peter, Thanks MUCH for all your work on gpc. You have greatly improved the compiler!! I do have a couple of questions about the most recent alpha. > * Field widths now default to left-justified output. Did I miss a discussion on this? Doesn't this break a lot of programs? Or is this with "--borland-pascal"? > * `For' now accepts components of structured variables as control > variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". Why? -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Tue Apr 1 19:16:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA16965 for ; Tue, 1 Apr 1997 19:16:28 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57984; Tue, 1 Apr 1997 18:21:53 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75388; Tue, 1 Apr 1997 18:22:36 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA08411 for ; Tue, 1 Apr 1997 19:00:30 +0300 (EET DST) Received: from dub-img-1.compuserve.com (dub-img-1.compuserve.com [149.174.206.131]) by vipunen.hut.fi (8.8.5/8.8.2) with SMTP id RAA35894 for ; Tue, 1 Apr 1997 17:50:51 +0300 Received: by dub-img-1.compuserve.com (8.6.10/5.950515) id JAA24432; Tue, 1 Apr 1997 09:50:19 -0500 Date: 01 Apr 97 09:49:11 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: "'gpc'" Subject: Re: C Header Files -> Pascal Message-Id: <970401144911_100120.3121_EHU59-1@CompuServe.COM> Status: RO You wrote: >But all these are kludges. The best thing still will be a converter >program. What about writing it with GNU Pascal, so we will get a >real-world demo program simultaneously? When my Lex/Yacc compile I'll try to do such. Thereare some tools available but they have some drawbacks: 1. For Borland Pascal/Delphi only. 2. Parse only a subset of C header files. 3. I don't like their output. 4. Cost money. Groetjes, Berend. From gpc-request@santra.hut.fi Tue Apr 1 19:10:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA16960 for ; Tue, 1 Apr 1997 19:10:45 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58434; Tue, 1 Apr 1997 18:16:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52324; Tue, 1 Apr 1997 18:16:53 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA07826 for ; Tue, 1 Apr 1997 19:02:27 +0300 (EET DST) Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by vipunen.hut.fi (8.8.5/8.8.2) with SMTP id SAA100350 for ; Tue, 1 Apr 1997 18:05:52 +0300 Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA16852 for gpc@hut.fi; Tue, 1 Apr 1997 17:59:11 +0200 From: Peter Gerwinski Message-Id: <199704011559.RAA16852@agnes.dida.physik.uni-essen.de> Subject: New Alpha To: gpc@hut.fi Date: Tue, 1 Apr 1997 17:59:11 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, it's time again for a new GPC alpha version. Changes since gpc-970227: * Field widths now default to left-justified output. * Some bugs fixed concerning field widths. * Strings being too long for the field are now output completely if `--borland-pascal' has been specified. * `For' now accepts components of structured variables as control variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". * `--pedantic-errors' no more implies `--pedantic'. Like this, you can specify `--pedantic-errors --extended-pascal' and you will get error messages when using Borland extensions, but no warnings for ISO 7185 Standard Pascal violations (i.e. the ISO 10206 extensions). * Fixed bug concerning empty sets. * Fixed bug concerning Strings without specified capacity as value parameters. * Initialized sets now work in procedures. (They still don't work in the main program or in the top level of a Unit.)-: * Fixed bug concerning arrays as `Const' parameters. * `Char' subranges like 'A'..'Z' work again. (Was broken in gpc-970115.) * `Const' parameters of known, small size are passed by value now. In this cases, `Const' is equivalent to `protected'; otherwise `Const' is equivalent to `protected Var'. * Now you can pass constant values to `Const' or `protected Var' parameters. * In Extended Pascal Modules, the following features have been implemented: - Export and import renaming, - `protected' export, - `only' import. * Fixed some bugs in the GPI mechanism, in particular concerning pointers and `Var' parameters. * `Asm' works again. (It was broken in gpc-970115 - and it still has problems with input and output registers.)-: * Fixed a bug concerning conformant arrays. If you have programs which use conformant arrays GPC didn't compile up to now, please retry and report remaining bugs. * `New' applied to "^String" variables (i.e. pointers to String Schemas without specified capacity) works now: you call `New' with a second parameter being the desired capacity of the newly allocated String. The source - a diff against gpc-970226 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ Binaries for DOS (DJGPP), Linux (ELF), and FreeBSD will follow this evening after 21 o' clock MET (when it will be less expensive). I thank Berend de Boer for many useful bug reports and the donation of a licensed copy of the Prospero Extended Pascal compiler. I also thank Stephen Lindholm, Tomas Srb, Miklos Cserzo, and Frank Heckenbach for reporting the bugs mentioned above. (* If I forgot your name, it's a bug - please report. ;*) And I thank everybody on the GPC mailing list for fruitful discussions about the future of GPC. I hope you had a happy Eastern. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 2 00:29:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA17348 for ; Wed, 2 Apr 1997 00:29:49 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58064; Tue, 1 Apr 1997 23:35:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45708; Tue, 1 Apr 1997 23:35:53 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA15247 for ; Wed, 2 Apr 1997 00:15:11 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA17311 for gpc@hut.fi; Wed, 2 Apr 1997 00:08:37 +0200 From: Peter Gerwinski Message-Id: <199704012208.AAA17311@agnes.dida.physik.uni-essen.de> Subject: Re: C Header Files -> Pascal To: gpc@hut.fi Date: Wed, 2 Apr 1997 00:08:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > When my Lex/Yacc compile I'll try to do such. > [...] It's great that you are all planning to write the C header -> Pascal converter, but please don't forget to coordinate your work. ;-) And have a look at Florian's development first, as Carl-Eric Cod\hre reported. BTW, Carl-Eric, you didn't tell us an URL. Do you mean Florian Klaempfl's FPK Pascal page, http://home.pages.de/FPK-Pascal/ ? I think it's a good idea to coordinate with FPK-Pascal. We are both producing free software and can learn from each other; we are no competitors like e.g. Borland and Microsoft. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 2 00:28:00 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA17344 for ; Wed, 2 Apr 1997 00:28:00 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97168; Tue, 1 Apr 1997 23:33:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51236; Tue, 1 Apr 1997 23:34:03 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA15179 for ; Wed, 2 Apr 1997 00:15:36 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA17319; Wed, 2 Apr 1997 00:08:59 +0200 From: Peter Gerwinski Message-Id: <199704012208.AAA17319@agnes.dida.physik.uni-essen.de> Subject: Re: New Alpha To: phil@cs.wwu.edu, gpc@hut.fi Date: Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Phil Nelson: > Thanks MUCH for all your work on gpc. You have greatly improved the > compiler!! Thank you! :-) My next goal are Schema types ... But I am sure that there are still bugs in the new features, especially in the import mechanism. > I do have a couple of questions about the most recent alpha. > > > * Field widths now default to left-justified output. > > Did I miss a discussion on this? Doesn't this break a lot of programs? > Or is this with "--borland-pascal"? Perhaps my formulation was misleading: I mean that writeln ( 123 ); will no more yield the output _______123 (with seven blanks), but instead 123 (left-justified). To produce "_______123" you must explicitly say "writeln ( 123 : 10 );". The Standard says that these default widths are implementation-dependent. There was a short discussion about whether GPC's behavior (default width 10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. We soon agreed that it would be better to produce left-justified output when no width has been specified. Otherwise, you would have to say "writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy and misleading. We forgot to post a copy of the discussion to the list; sorry about that. In case you have some arguments to set it back to the previous state, just post it here. (These are only some constants in `rts/rts.h', so it was not much work to change. Perhaps (yet another) command-line switch would satisfy everybody?) > > * `For' now accepts components of structured variables as control > > variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". > > Why? In short: Why not? In long: Indeed, the standard only allows an entire variable in this context. Thank you for pointing me to this; I will make this extension trigger a warning if `--standard-pascal' or `--extended-pascal' has been specified. (With `--pedantic-errors', the warning will be an error message.) But Borland Pascal allows this, I got it "for free" (just changed one line in `gpc-parse.y'), so why not allow it, too? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125] From codc01@zeus.GEL.USherb.CA Wed Apr 2 00:52:18 1997 Return-Path: codc01@zeus.GEL.USherb.CA Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA17392 for ; Wed, 2 Apr 1997 00:52:17 +0200 Received: from pollux.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA14623; Tue, 1 Apr 97 16:58:26 EST Received: by pollux.gel.usherb.ca (SMI-8.6/SMI-SVR4) id QAA18406; Tue, 1 Apr 1997 16:57:33 -0500 Date: Tue, 1 Apr 1997 16:57:33 -0500 (EST) From: "Carl-Eric.Codere" X-Sender: codc01@pollux To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: C Header Files -> Pascal In-Reply-To: <199704012208.AAA17311@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 2 Apr 1997, Peter Gerwinski wrote: > And have a look at Florian's development first, as Carl-Eric Cod\hre > reported. BTW, Carl-Eric, you didn't tell us an URL. Do you mean > Florian Klaempfl's FPK Pascal page, http://home.pages.de/FPK-Pascal/ ? > Greetings, Supposedly it was the following link: http://www.rrze.uni-erlangen.de/~sz2104/fpkpas.html but I should have checked before speaking my voice! The server does not seem to respond, I will e-mail Florian about this. I heard his university was moving (no joke!), that may be the reason for the problem. If I can get a hold of the program i will put it on my web page and will let you know. > I think it's a good idea to coordinate with FPK-Pascal. We are both > producing free software and can learn from each other; we are no > competitors like e.g. Borland and Microsoft. I totally agree. We know return to our previously scheduled program From laa12@cc.keele.ac.uk Wed Apr 2 12:03:39 1997 Return-Path: laa12@cc.keele.ac.uk Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id MAA18953 for ; Wed, 2 Apr 1997 12:03:38 +0200 Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Wed, 2 Apr 1997 10:11:07 +0100 Received: from [0.13.84.58] by potter.cc.keele.ac.uk; Wed, 2 Apr 1997 10:09:10 +0100 From: The African Chief To: Peter Gerwinski cc: gpc@hut.fi Subject: Re: New Alpha Message-ID: Date: Wed, 2 Apr 1997 10:11:13 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) Peter Gerwinski wrote: [...] >(left-justified). To produce "_______123" you must explicitly say >"writeln ( 123 : 10 );". > >The Standard says that these default widths are implementation-dependent. >There was a short discussion about whether GPC's behavior (default width >10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. >We soon agreed that it would be better to produce left-justified output >when no width has been specified. Otherwise, you would have to say >"writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy >and misleading. We forgot to post a copy of the discussion to the list; >sorry about that. > >In case you have some arguments to set it back to the previous state, >just post it here. (These are only some constants in `rts/rts.h', so it >was not much work to change. Perhaps (yet another) command-line switch >would satisfy everybody?) I think this could be the way forward. Having a multitude of command line switches is very good, in that it gives the programmer more flexibility to use the compiler in the way that he/she likes, not in the way that somebody else thinks they should. However, the price of flexibility is complexity. In case you haven't done this, can you introduce a .CFG file (like with Borland) where one can put all the command line switches that they want to use? The compiler will read the .CFG file before doing anything else, and will adjust its behaviour accordingly. I personally prefer this approach to using environment variables or the such. You can make many sample .CFG files (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people can then rename to GPC.CFG or whatever. Sorry if all this already exists. I lurk in this list, because I am quite interested in GPC and its future (and its potential to release me from arbitrary decisions made by certain companies about where their compilers are going) but I am yet to fully utilise GPC myself. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Wed Apr 2 20:22:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA19789 for ; Wed, 2 Apr 1997 20:22:24 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87296; Wed, 2 Apr 1997 19:27:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60446; Wed, 2 Apr 1997 19:28:12 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA20874 for ; Wed, 2 Apr 1997 20:17:38 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA19765; Wed, 2 Apr 1997 20:11:12 +0200 From: Peter Gerwinski Message-Id: <199704021811.UAA19765@agnes.dida.physik.uni-essen.de> Subject: Command-line options and CFG file (was: New Alpha) To: laa12@cc.keele.ac.uk (Abimbola A. Olowofoyeku) Date: Wed, 2 Apr 1997 20:11:12 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to The African Chief: > [...] In case you haven't done this, can you > introduce a .CFG file (like with Borland) where one can > put all the command line switches that they want to use? I have an old version of GCC for some special hardware here (without source #@*!) which accepts a `@filename' option pointing to a file with additional options. We could, for example, do the same and make gpc @gpc.cfg read a file `gpc.cfg' in the current directory. > The compiler will read the .CFG file before doing anything > else, and will adjust its behaviour accordingly. I personally > prefer this approach to using environment variables or the > such. So do I. > You can make many sample .CFG files > (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people > can then rename to GPC.CFG or whatever. In principle this is not necessary: By default, GPC understands all of these dialects (as far as implemented) and you can specify one (or more) of `--standard-pascal', `--extended-pascal', `--borland-pascal' to restrict GPC's language to the specified dialects. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 2 22:40:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA20015 for ; Wed, 2 Apr 1997 22:40:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53612; Wed, 2 Apr 1997 21:45:21 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46268; Wed, 2 Apr 1997 21:46:06 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id WAA24110 for ; Wed, 2 Apr 1997 22:38:03 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id VAA14043; Wed, 2 Apr 1997 21:38:21 +0100 Date: Wed, 2 Apr 1997 21:38:19 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: The African Chief Cc: GPC list Subject: Re: New Alpha In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 2 Apr 1997, The African Chief wrote: > I think this could be the way forward. Having a multitude > of command line switches is very good, in that it gives > the programmer more flexibility to use the compiler in > the way that he/she likes, not in the way that somebody > else thinks they should. However, the price of flexibility > is complexity. In case you haven't done this, can you > introduce a .CFG file (like with Borland) where one can > put all the command line switches that they want to use? You can do all of this in a Makefile. > The compiler will read the .CFG file before doing anything > else, and will adjust its behaviour accordingly. I personally > prefer this approach to using environment variables or the > such. You can make many sample .CFG files > (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people > can then rename to GPC.CFG or whatever. > > Sorry if all this already exists. Environment variables are used to override default paths to libraries etc. Commandline switches are used to select compiler behaviour (optimization, debugging, dialect etc.) For unix, setting environment variables is usually not necessary because you build your own compiler with "taylormade" defaults hardcoded in the compiler binary. For MS-DOS, the compiler is often downloaded as a binary and installed in a path other than the one specified at compile time. DJGPP has an elegant solution for them: `djgpp.env'. That way, you don't have to clutter your MS-DOS environment with a lot of environment variables. Remaining are cygwin32 and OS/2 platforms. cygwin32 is still experimental, maybe they implement something like `djgpp.env'. GPC has a config file: `specs'. You can change some of GPC's behaviour here. Future versions of GPC may come with different driver binaries (`gpc', `bpc', `epc' etc.) which preset a number of switches to select a certain Pascal dialect. Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Wed Apr 2 23:21:53 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA20300 for ; Wed, 2 Apr 1997 23:21:53 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA14620; Wed, 2 Apr 1997 22:26:54 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46108; Wed, 2 Apr 1997 22:27:39 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA23956 for ; Wed, 2 Apr 1997 23:13:14 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id MAA27123; Wed, 2 Apr 1997 12:12:30 -0800 (PST) Date: Wed, 2 Apr 1997 12:12:30 -0800 (PST) From: Phil Nelson Message-Id: <199704022012.MAA27123@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199704012208.AAA17319@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Wed, 2 Apr 1997 00:08:59 +0200 (MET DST)) Subject: Re: New Alpha Status: RO >> > * Field widths now default to left-justified output. >> >> Did I miss a discussion on this? Doesn't this break a lot of programs? >> Or is this with "--borland-pascal"? > >Perhaps my formulation was misleading: I mean that > > writeln ( 123 ); > >will no more yield the output > > _______123 > >(with seven blanks), but instead > > 123 > >(left-justified). To produce "_______123" you must explicitly say >"writeln ( 123 : 10 );". > >The Standard says that these default widths are implementation-dependent. >There was a short discussion about whether GPC's behavior (default width >10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. >We soon agreed that it would be better to produce left-justified output >when no width has been specified. Otherwise, you would have to say >"writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy >and misleading. We forgot to post a copy of the discussion to the list; >sorry about that. Yes, I understood what you ment. I'm sorry that the discussion did not make it to the gpc list. Let me argue that the orignal method should be maintained, with the actual numbers being changed to larger values. First some of my background with Pascal. I had several discussions with Ted C. Park during the original work on the Pascal standard. (Yes, you will find Ted's name on page iii of the ISO 7185:1990 standard.) I have used many Pascal compilers, including Pascal 6000-3.4, Portable Pascal, VAX Pascal, OMSI Pascal, GNU Pascal and Borland Pascal. I even modified the portable Pascal compiler to generate native machine code for the HP3000. As to why the implicit field size in a "write(i)" should not be 1: A) This change breakes a lot of non-Borland Pascal programs. The point of a standard is so that programs that work under one compiler work under other compilers and that includes I/O. B) I believe that any "write(a)" with no field specification where a is a numeric type should produce output that can be read back with no loss of information. I believe that it should the case (although not stated in the standard) that the output from write(f1,a,b,c) should be able to fed to the statment read(f2,x,y,z) and have the read statement correctly assign the values to x, y, and z that were in a, b and c. (Should work for integer, real, char.) Of all the Pascal compilers I have used, only Borland did not guarantee that the above will work. (Possibly gpc with LARGE integers :) C) Notice, the way the standard is written for reals, write(f1,r1,r2,r3) will write the numbers so that read(f2,r1,r2,r3) will read the numbers back in. There may be loss of precision if the implementation-dependent number is too small, but the write and read will "communicate". (That is the first character written is always a "+" or a blank.) C) The "implementation-dependent" feature is due to the fact that some implementations have, for integers, 16 bits of representation and needs only a field size of 6 to guarantee the write/read usage. For 32 bits of representation we really need 11 to guarantee the write/read. For 64 bits, we would need 20. This is how I see it as implementation-dependent. (Yes, if they really ment this, they should have specified it.) I would have no problem with the implicit field of 1 if it was looking like a Borland compiler. Similar with the "write ('abcdefg':3)" writing "abcdefg" instead of the proper "abc". Both of the above (the changes in how write operates) are reasons I have avoided using Borland Pascal. I think that the standard mode for gpc (no special flags) should a) have a default field size that guarantees that the first character is either a "+" or a blank when writing numeric types. (Defined by the standard for real. Should have a size large enough to not loose very much precision due to write/read.) b) write ('abcdefg':3) must write exactly "abc". I have many Pascal programs that depend on both of the above features. >> > * `For' now accepts components of structured variables as control >> > variables, e.g. "for myarray [ i ]:= 1 to 100 do ...". >> >> Why? > >In short: Why not? As you note below, the standard only allows ordinal type, single variables here. It also requires the variable to be defined in the closest containing variable declaration block? Is that being enforced with array loop indexes? Also, I think it can be very confusing. Granted, it does make a few problems solved with a line or two less code. > >In long: Indeed, the standard only allows an entire variable in this >context. Thank you for pointing me to this; I will make this extension >trigger a warning if `--standard-pascal' or `--extended-pascal' has >been specified. (With `--pedantic-errors', the warning will be an >error message.) But Borland Pascal allows this, I got it "for free" >(just changed one line in `gpc-parse.y'), so why not allow it, too? I believe that it should be enabled only if '--borland-pascal' is requested. Otherwise it should be rejected. I suspect that it would require the modification/addition of only one line to the gpc-parse.y to allow 'var++' as an expression. Should we add it? NO. I'd like to have gpc avoid the "kitchen sink" syndrome. In any case, as you point out, with '--standard-pascal' it had better follow the standard. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Wed Apr 2 23:26:21 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA20313 for ; Wed, 2 Apr 1997 23:26:21 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94914; Wed, 2 Apr 1997 22:31:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77056; Wed, 2 Apr 1997 22:32:07 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA25138 for ; Wed, 2 Apr 1997 23:24:39 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id MAA27138; Wed, 2 Apr 1997 12:24:01 -0800 (PST) Date: Wed, 2 Apr 1997 12:24:01 -0800 (PST) From: Phil Nelson Message-Id: <199704022024.MAA27138@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: laa12@cc.keele.ac.uk, gpc@hut.fi In-Reply-To: <199704021811.UAA19765@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Wed, 2 Apr 1997 20:11:12 +0200 (MET DST)) Subject: Re: Command-line options and CFG file (was: New Alpha) Status: RO >In principle this is not necessary: By default, GPC understands all of >these dialects (as far as implemented) and you can specify one (or more) >of `--standard-pascal', `--extended-pascal', `--borland-pascal' to >restrict GPC's language to the specified dialects. This is good. But where they conflict, e.g. the results of write('abcdefg':3), I expect that they would follow standard-pascal or extended-pascal, not borland-pascal. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 16:24:31 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA22429 for ; Thu, 3 Apr 1997 16:24:31 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA13236; Thu, 3 Apr 1997 15:29:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA24618; Thu, 3 Apr 1997 15:30:03 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA20977 for ; Thu, 3 Apr 1997 16:23:25 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id PAA19117 (8.7.6/7.5c-FAU); for ; Thu, 3 Apr 1997 15:23:22 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id PAA17322 (SMI-8.6/7.5b-FAU); Thu, 3 Apr 1997 15:23:21 +0200 From: Frank Heckenbach Message-Id: <199704031323.PAA17322@helena.mi.uni-erlangen.de> Date: Thu, 3 Apr 1997 15:23:20 +0200 To: gpc@hut.fi Subject: Re: New Alpha Status: RO > write ('There are ', items:1, ' items') > > >Or does this "clipping" only apply to strings? > Clipping only applies to strings. I see, fine. > >But then again, how would you do "You name is Phil."? > >Do you have to "write(s:Length(s))" or such? > write ('You name is Phil.') :) Err... well, I meant 'Phil' was the value of a string variable. I thought this would be clear. > In standard Pascal there are no string schema types like extended Pascal, > but in extended Pascal "write(s)" is identical to "write(s:length(s))". Ok, then, if I got this right, you have to do write(num_var:1) and write(string_var) for output without spaces, whereas write(num_var) and write(string_var:1) both don't work this way. This seems a bit inconsistent and confusing to me. I see that your programs rely on this way, but my programs rely on BP's way, and I don't think there's anything worse with BP's way than the standard's way. So, obviously, gpc needs to support both ways. > "Strings" in standard Pascal are typically an "array [1 .. n] of char". > The programmer then needs to keep track of how many of the n characters > are valid. Then the write statement would look like "write (s:sizeofs)". This explains to me why this clipping is needed in standard Pascal. However, I really don't want to use hand-made strings in my programs, I really could stand a little more comfort... :-) -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 3 16:17:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA22417 for ; Thu, 3 Apr 1997 16:17:44 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA12322; Thu, 3 Apr 1997 15:22:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17170; Thu, 3 Apr 1997 15:23:16 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA18783 for ; Thu, 3 Apr 1997 15:42:27 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id OAA00329; Thu, 3 Apr 1997 14:42:34 +0100 Date: Thu, 3 Apr 1997 14:42:33 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: The African Chief Cc: GPC list Subject: Re: Command-line options and CFG file (was: New Alpha) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 3 Apr 1997, The African Chief wrote: > BTW: having just downloaded and installed GPC 2.0 and some of > the DJGPP stuff referred to in the docs, I still can't get anything to > compile. The place where I am stuck now when I try to compile > is this message: > > "C:\DJGPP\BIN/ld.exe: cannot open linker script file djgpp.lnk: > No such file or directory (ENOENT)" > > A search through my disk shows that no file with the .lnk extension > exists. Any clues? This is not in the FAQ! > You may be mixing a djgpp-V2.0 based GPC binary with a djgpp-V2.01 toolchain (ie: you have djdev201.zip installed). djgpp V2.01 renamed djgpp.lnk to djgpp.djl If this is so, it may help to edit `specs.gpc' and change the "link_command" to refer to `djgpp.djl' instead of `djgpp.lnk' The fancy option is of course to upgrade either gpc or djgpp. Hope this helps, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Thu Apr 3 16:13:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA22412 for ; Thu, 3 Apr 1997 16:13:32 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53614; Thu, 3 Apr 1997 15:18:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39956; Thu, 3 Apr 1997 15:19:06 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA20587 for ; Thu, 3 Apr 1997 16:13:20 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id FAA00789; Thu, 3 Apr 1997 05:12:53 -0800 (PST) Date: Thu, 3 Apr 1997 05:12:53 -0800 (PST) From: Phil Nelson Message-Id: <199704031312.FAA00789@fawn.cs.wwu.edu> To: heckenb@mi.uni-erlangen.de Cc: gpc@hut.fi In-Reply-To: <199704031249.OAA17117@helena.mi.uni-erlangen.de> (message from Frank Heckenbach on Thu, 3 Apr 1997 14:49:31 +0200) Subject: Re: New Alpha Status: RO >BTW: Phil, how do you output a number without spaces (or, let's say >with exactly one space) in standard Pascal, e.g. to write the simple line >N"There are 7 items" (with 7 being the value of a variable)? >With no (or a big) format specifier, there would be more spaces than >wanted, with a small format specifer, large numbers would be cut. write ('There are ', items:1, ' items') >Or does this "clipping" only apply to strings? Clipping only applies to strings. >But then again, how would you do "You name is Phil."? >Do you have to "write(s:Length(s))" or such? write ('You name is Phil.') :) In standard Pascal there are no string schema types like extended Pascal, but in extended Pascal "write(s)" is identical to "write(s:length(s))". "Strings" in standard Pascal are typically an "array [1 .. n] of char". The programmer then needs to keep track of how many of the n characters are valid. Then the write statement would look like "write (s:sizeofs)". -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 16:00:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA22381 for ; Thu, 3 Apr 1997 16:00:36 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17008; Thu, 3 Apr 1997 15:05:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55974; Thu, 3 Apr 1997 15:06:10 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA19924 for ; Thu, 3 Apr 1997 16:00:03 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id PAA18387 (8.7.6/7.5c-FAU); for ; Thu, 3 Apr 1997 15:00:00 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id OAA17179 (SMI-8.6/7.5b-FAU); Thu, 3 Apr 1997 14:59:59 +0200 From: Frank Heckenbach Message-Id: <199704031259.OAA17179@helena.mi.uni-erlangen.de> Date: Thu, 3 Apr 1997 14:59:58 +0200 To: gpc@hut.fi Subject: Re: C Header Files -> Pascal Status: RO Carl-Eric.Codere wrote: > Greetings, > Supposedly it was the following link: > http://www.rrze.uni-erlangen.de/~sz2104/fpkpas.html but I should have > checked before speaking my voice! The server does not seem to respond, I > will e-mail Florian about this. I heard his university was moving (no > joke!), that may be the reason for the problem. If I can get a hold of > the program i will put it on my web page and will let you know. Oops! I think I ought to know if our university was moving... :-) I guess he meant he was moving to another university, since his new mail address (from the FPK homepage) is klaempfl@haegar.cip.mw.tu-muenchen.de Well, at least currently the above URL does exist, I just checked. Indeed, there is "H2PP.ZIP" (convert C header files to pascal units) there, but I didn't try it out yet. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 3 15:49:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA22356 for ; Thu, 3 Apr 1997 15:49:39 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96700; Thu, 3 Apr 1997 14:54:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79098; Thu, 3 Apr 1997 14:55:13 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA17175 for ; Thu, 3 Apr 1997 15:49:37 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA18128 (8.7.6/7.5c-FAU); for ; Thu, 3 Apr 1997 14:49:33 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id OAA17117 (SMI-8.6/7.5b-FAU); Thu, 3 Apr 1997 14:49:32 +0200 From: Frank Heckenbach Message-Id: <199704031249.OAA17117@helena.mi.uni-erlangen.de> Date: Thu, 3 Apr 1997 14:49:31 +0200 To: gpc@hut.fi Subject: Re: New Alpha Status: RO Peter Gerwinski wrote: > > > * Field widths now default to left-justified output. > > > > Did I miss a discussion on this? Doesn't this break a lot of programs? > > Or is this with "--borland-pascal"? > > Perhaps my formulation was misleading: I mean that > > writeln ( 123 ); > > will no more yield the output > > _______123 > > (with seven blanks), but instead > > 123 > > (left-justified). To produce "_______123" you must explicitly say > "writeln ( 123 : 10 );". Perhaps you should write "field width now defaults to 0" (or 1 - what is it?). By "left justified" I would mean "123_______". Since Phil mentioned why the default was a bigger width, I now think this should be toggled by the --borland-pascal switch, and a separate switch as well. E.g., I try to make my programs not dependent on the --borland-pascal switch, but this problem (together with the "clipping" in standard Pascal) would require a lot of changes that I can't do soon... BTW: Phil, how do you output a number without spaces (or, let's say with exactly one space) in standard Pascal, e.g. to write the simple line "There are 7 items" (with 7 being the value of a variable)? With no (or a big) format specifier, there would be more spaces than wanted, with a small format specifer, large numbers would be cut. Or does this "clipping" only apply to strings? But then again, how would you do "You name is Phil."? Do you have to "write(s:Length(s))" or such? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 3 15:41:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA22351 for ; Thu, 3 Apr 1997 15:41:17 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99294; Thu, 3 Apr 1997 14:46:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63076; Thu, 3 Apr 1997 14:46:52 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA18531 for ; Thu, 3 Apr 1997 15:38:53 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA17704 (8.7.6/7.5c-FAU); for ; Thu, 3 Apr 1997 14:38:46 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id OAA17092 (SMI-8.6/7.5b-FAU); Thu, 3 Apr 1997 14:38:45 +0200 From: Frank Heckenbach Message-Id: <199704031238.OAA17092@helena.mi.uni-erlangen.de> Date: Thu, 3 Apr 1997 14:38:44 +0200 To: gpc@hut.fi Subject: Re: Linking directives (was: C Header Files -> Pascal) Status: RO Peter Gerwinski wrote: > If you really > must rely on C headers which change from time to time, ...or from system to system... > it is probably > the most reasonable thing to write a C module which uses the header > files and exports some well-defined functions. Then you can write a > Unit which imports these functions as `external' functions and makes > them accessible for your Pascal program. That's what I did. Specifically, I needed a routine to measure the CPU time. There is a C routine declared in time.h, but it uses a constant (#define) and a type (typedef). The value of the constant, and even the type (int or float) can vary on different systems, AFAIK. So the only way to use it in Pascal - without modifying the program on every system - is to write a Pascal wrapper, or is there any easier way? > Another thing I did experiments with was a C program which includes > the header files and writes out Pascal source for all constants > defined in the header. Wouldn't exactly make the program building process easier... :-| And, as I see it, there's no way to handle types defined in the C header, is there? (Well, there are not too many types in C programs, but anyway... :-) > According to Sven Engelhardt: > > nb. any way to issue linker-options (-lxxx -L) as preprocessor- > > directives, so one could write rater developer-friendly code. > > This is planned. > > My idea was to make "(*$L foo.o *)" equivalent to a file name `foo.o' > given in the command line. One could also make "(*$L /usr/lib *)" > equivalent to "-L /usr/lib" because GPC can check whether the given > name refers to a file or a directory. Something to add to this: it would be great if one could give a C file which would be compiled (if necessary) and the resulting object linked in, like {$L foo.c}. Then one could make any Pascal program with --automake, even if it uses some C files. BTW: Is it allowed with the current versions to give C files on the command line? I tried the following with the 0226 or 0227 version: gpc -o homology gettime.c sysdep.pas calc_hom.pas homology.pas With DJGPP, this works fine. But with Linux, it gives the message: In file included from /usr/include/features.h:134, from /usr/include/time.h:26, from gettime.h:4, from gettime.c:4: /usr/include/sys/cdefs.h:40: parse error However, the following works with Linux: gcc -c gettime.c gpc -o homology gettime.o sysdep.pas calc_hom.pas homology.pas Is this an installation problem on my system or a general problem? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 3 14:52:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA22264 for ; Thu, 3 Apr 1997 14:52:50 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99096; Thu, 3 Apr 1997 13:57:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79748; Thu, 3 Apr 1997 13:58:25 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA15114 for ; Thu, 3 Apr 1997 14:44:25 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Thu, 3 Apr 1997 12:45:40 +0100 Received: from [0.13.40.232] by potter.cc.keele.ac.uk; Thu, 3 Apr 1997 12:43:47 +0100 From: The African Chief To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Command-line options and CFG file (was: New Alpha) Message-Id: Date: Thu, 3 Apr 1997 12:45:39 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Wed, 2 Apr 1997 20:11:12 +0200 (MET DST) Peter Gerwinski wrote: >According to The African Chief: >> [...] In case you haven't done this, can you >> introduce a .CFG file (like with Borland) where one can >> put all the command line switches that they want to use? > >I have an old version of GCC for some special hardware here (without >source #@*!) which accepts a `@filename' option pointing to a file with >additional options. We could, for example, do the same and make > > gpc @gpc.cfg > >read a file `gpc.cfg' in the current directory. Yes, that would be nice. But why not just let it look for a 'gpc.cfg' file automatically? It could then take whatever it finds there as command line parameters (in addition to any other ones passed at the command line itself). There could also be provision for making comments in the .cfg file). I apprecite that looking for, and reading a .cfg file automatically may be strange to those not coming from a BP or DOS background, so I don't think that this is a wish that requires too nuch attention. >> You can make many sample .CFG files >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people >> can then rename to GPC.CFG or whatever. > >In principle this is not necessary: By default, GPC understands all of >these dialects (as far as implemented) and you can specify one (or more) >of `--standard-pascal', `--extended-pascal', `--borland-pascal' to >restrict GPC's language to the specified dialects. Ok. BTW: having just downloaded and installed GPC 2.0 and some of the DJGPP stuff referred to in the docs, I still can't get anything to compile. The place where I am stuck now when I try to compile is this message: "C:\DJGPP\BIN/ld.exe: cannot open linker script file djgpp.lnk: No such file or directory (ENOENT)" A search through my disk shows that no file with the .lnk extension exists. Any clues? This is not in the FAQ! Thanks. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Thu Apr 3 19:54:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA22780 for ; Thu, 3 Apr 1997 19:54:06 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA14640; Thu, 3 Apr 1997 18:58:50 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55242; Thu, 3 Apr 1997 18:59:36 +0200 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA18718 for ; Thu, 3 Apr 1997 19:54:09 +0300 (EET DST) Received: (qmail 21910 invoked from smtpd); 3 Apr 1997 15:53:48 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1) (root@194.162.196.18) by teamware.sik.de with SMTP; 3 Apr 1997 15:53:47 -0000 Sender: root@santra.hut.fi Message-Id: <3343E042.1C5B384B@sik.de> Date: Thu, 03 Apr 1997 18:52:18 +0200 From: Sven Engelhardt Organization: Nacamar Sachsen X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.0.29 i586) Mime-Version: 1.0 To: Phil Nelson Cc: gpc@hut.fi Subject: Standard Compatibility [was: Re: New Alpha] References: <199704031453.GAA00880@fawn.cs.wwu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Phil Nelson wrote: > > >So, obviously, gpc needs to support both ways. > Yes, I agree. When the --borland_pascal switch is set, it should look > like Borland Pascal! Hi Phil and the Rest of the world ... Although gpc ain't a commercial product it should be build on wide acceptance. (Where else shall all the really good gpc-programs come from?) In past nobody was interested in any pascal-standards but Borland. Borland-Pascal IMHO is the standard-pascal anyway. The probably are hundreds of Borland-Pascal-Users on one or two other-semi-standard-pascal-with-some-extensions-users. Until raising version 2.0 (the star) gpc wasn't alive. It really seemed to be a rather dead language. For now it will not live from the euphorie of the 'main' developers but more from many contributions from many programmers all over the world. Sure, the only one concurrent platform is gnu C, but gnu C lives from that contributions too. Why is linux that much popular. gpc really shall default to borland/turbo-pascal behaviour. You could implement reading ~/.gpcrc to change that. (For ease this could be done with a shell script) The cause ain't 'standard' performance, as thousands of dos-pascal-programs will be ported to linux. However, this may be a little bit visionary. But we should NOT artificially complicate changes to gnu pascal. (Vice versa case is an interesting question to discuss too.) > >However, I really don't want to use hand-made strings in my programs, > >I really could stand a little more comfort... :-) > Yup! And others (including me) agree. Hense Extended Pascal! :) I agree too, but why should {-------------snip-------------} i:=7; writeln("i=",i); {-------------snip-------------} give somthing like "i= 7 ?" (Please don't ask (me) why not.) nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about implementing sysvars IntegerTotalWidth and the like with values defaulting to the Turbo Pascal settings (i.e. 0, with special behaviour: no cutting of strings.), then you will have a powerful facility to print tables from scratch. Formatted as you wan't from clear, readable and confusenessless code like write('i=',i:whatever^.thisconfusingwidthofintegers.be); > -- > Phil Nelson NetBSD: http://www.netbsd.org > e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org > http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html regards, sven ================================================================== Sven Engelhardt http://www.sax.net/ mailto:se@sik.de From gpc-request@santra.hut.fi Thu Apr 3 17:53:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA22611 for ; Thu, 3 Apr 1997 17:53:12 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80392; Thu, 3 Apr 1997 16:57:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47238; Thu, 3 Apr 1997 16:58:42 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA24306 for ; Thu, 3 Apr 1997 17:54:02 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id GAA00880; Thu, 3 Apr 1997 06:53:34 -0800 (PST) Date: Thu, 3 Apr 1997 06:53:34 -0800 (PST) From: Phil Nelson Message-Id: <199704031453.GAA00880@fawn.cs.wwu.edu> To: heckenb@mi.uni-erlangen.de Cc: gpc@hut.fi In-Reply-To: <199704031323.PAA17322@helena.mi.uni-erlangen.de> (message from Frank Heckenbach on Thu, 3 Apr 1997 15:23:20 +0200) Subject: Re: New Alpha Status: RO >So, obviously, gpc needs to support both ways. Yes, I agree. When the --borland_pascal switch is set, it should look like Borland Pascal! >However, I really don't want to use hand-made strings in my programs, >I really could stand a little more comfort... :-) Yup! And others (including me) agree. Hense Extended Pascal! :) -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 21:55:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA22958 for ; Thu, 3 Apr 1997 21:55:01 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA11958; Thu, 3 Apr 1997 20:59:44 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74276; Thu, 3 Apr 1997 21:00:30 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA30971 for ; Thu, 3 Apr 1997 21:55:21 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id KAA01265; Thu, 3 Apr 1997 10:54:59 -0800 (PST) Date: Thu, 3 Apr 1997 10:54:59 -0800 (PST) From: Phil Nelson Message-Id: <199704031854.KAA01265@fawn.cs.wwu.edu> To: gpc@hut.fi Subject: [sad@utkux.utcc.utk.edu: Re: Standard Compatibility [was: Re: New Alpha]] Status: RO From: sad@utkux.utcc.utk.edu Subject: Re: Standard Compatibility [was: Re: New Alpha] To: phil@cs.wwu.edu (Phil Nelson) Date: Thu, 3 Apr 1997 13:51:03 -0500 (EST) In-Reply-To: <199704031835.KAA01150@fawn.cs.wwu.edu> from "Phil Nelson" at Apr 3, 97 10:35:05 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > It should not be arbitrary! It should be large enough so MAXINT will > have at least one blank in the field. So in this case, gpc should have > the numbers depend on the MACHINE data type. Choose something like > the number of digits in MAXINT + 1 to be the default integer field size. Agreed, this is nice for number crunching (much like Fortran handles generic write(6,*)) and hence I'd prefer it to default to that. It is not so nice when you want to do fancy stringish output stuff, so I'd think there should be an option (compiler or even better, runtime) to switch to left justified output where so desired. Cheers. Stefan ======================================================================== Stefan A. Deutscher | (+1-423-) voice fax The University of Tennessee, Knoxville | UTK : 974-7838 974-7843 Department of Physics and Astronomy | ORNL : 574-5897 574-1118 401, A. H. Nielsen Building | home : 522-7845 522-7845 Knoxville, T.N. 37996-1200, USA | email: sad@utk.edu ======================================================================== From gpc-request@santra.hut.fi Thu Apr 3 21:33:32 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA22935 for ; Thu, 3 Apr 1997 21:33:32 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76702; Thu, 3 Apr 1997 20:38:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76578; Thu, 3 Apr 1997 20:39:01 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA30813 for ; Thu, 3 Apr 1997 21:35:54 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id KAA01150; Thu, 3 Apr 1997 10:35:05 -0800 (PST) Date: Thu, 3 Apr 1997 10:35:05 -0800 (PST) From: Phil Nelson Message-Id: <199704031835.KAA01150@fawn.cs.wwu.edu> To: sven@sik.de Cc: gpc@hut.fi In-Reply-To: <3343F368.6FD8DAFD@sik.de> (message from Sven Engelhardt on Thu, 03 Apr 1997 20:14:00 +0200) Subject: Re: Standard Compatibility [was: Re: New Alpha] Status: RO >> And to ask a furthur question, why should >> {-------------snip--------------} >> for i := 1 to 5 do write(a[i]); >> writeln; >> {-------------snip--------------} >> produce output for which you can not distinguish the elements of a? >> >... > >We are talking about the default behaviour. i.e. the parameter next to >double-dot is missing. And we are talking abount write(integer), aren't >we? Sorry, I was not clear. a would be an integer array. So yes, I was talking about write(integer). Which would default to write (integer:1) for Borland and write(integer:10) (or some other number) for "traditional" Pascals. So in the above example if a had the values 15, 23, 3, 42, 5, under Borland your output would be "15233425" and you would have no clue as to what the actual values in the array a really were. >You are right, but declaring Default-TotalWidth(integer)=0 (or 1) >conforms >to 6.10.3.3, the output will be a left aligned number, so we can beat >"quasi" borland-compatibility and your need of standard-conformance. True. The default of 1 does follow the standard here as written. This one place where I feel the standard was not specific enough. I believe that the above code should produce output where you can distinguish the elements of array a when a contains either integers or reals. To do this, the standard field width MUST be implementation dependent due to the number of digits in the maximum integer. >Once again: WHY NOT, why should it be defined to 5, 8, 10 or whatever >value you want? from 6.10.3.1 "the default values shall be It should not be arbitrary! It should be large enough so MAXINT will have at least one blank in the field. So in this case, gpc should have the numbers depend on the MACHINE data type. Choose something like the number of digits in MAXINT + 1 to be the default integer field size. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 21:13:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA22898 for ; Thu, 3 Apr 1997 21:13:44 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57904; Thu, 3 Apr 1997 20:18:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56552; Thu, 3 Apr 1997 20:19:14 +0200 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA30146 for ; Thu, 3 Apr 1997 21:15:33 +0300 (EET DST) Received: (qmail 24829 invoked from smtpd); 3 Apr 1997 17:15:31 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1) (root@194.162.196.18) by teamware.sik.de with SMTP; 3 Apr 1997 17:15:31 -0000 Sender: root@santra.hut.fi Message-Id: <3343F368.6FD8DAFD@sik.de> Date: Thu, 03 Apr 1997 20:14:00 +0200 From: Sven Engelhardt Organization: Nacamar Sachsen X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.0.29 i586) Mime-Version: 1.0 To: Phil Nelson Cc: gpc@hut.fi Subject: Re: Standard Compatibility [was: Re: New Alpha] References: <199704031719.JAA01030@fawn.cs.wwu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Phil Nelson wrote: > > >Although gpc ain't a commercial product it should be build on wide > >acceptance. > > I agree. > > >In past nobody was interested in any pascal-standards but Borland. > I disagree. Borland did not write ISO 7185 and 10206. If they did, > those standards would look a lot different. Units would be part of > the standard, which they are not. > > >Borland-Pascal IMHO is the standard-pascal anyway. > I disagree. I didn't mean Borland wrote that standards - sorry for the inexactitude - but Heimsoeth made the first real working and usable compiler for dos platfrom (which had an overwhelming piece of market of about 85% of personal computers that day). Computers and therefore they established a "quasi"-pascal-standard. That IS and WILL BE my opinion and reason because doesn't release Quick-Pascal any- or Visiual-Pascal furthermore. (Congratulations Borland) > >gpc really shall default to borland/turbo-pascal behaviour. You could > I disagree. Clearly from context: not for standardization reasons; but for reasons of portability. > I did like the suggestion that gpc could be started from several links, > gpc (ie. ISO standard Pascal/ISO Extended Pascal) and bpc (Borland Pascal). > I do believe that gpc should support(emulate) Borland Pascal to support > Borland Pascal users. But gpc should not standardly be Borland. gpc ain't borland pascal guy, but remember: people use borland, borland is habitual, schools teach borland. > >give somthing like > > > >"i= 7 ?" > > Because that is how a majority of Pascal compilers do it. But the majority is using borland and therefore this behaviour IS NOT USUAL for the majority of programmers, source-code-programs etc.pp. Maybe it is for YOU and YOUR compiler. > And to ask a furthur question, why should > {-------------snip--------------} > for i := 1 to 5 do write(a[i]); > writeln; > {-------------snip--------------} > produce output for which you can not distinguish the elements of a? > > >nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about > Are your sure about this? Full Extended Pascal? From my exprience, We are talking about the default behaviour. i.e. the parameter next to double-dot is missing. And we are talking abount write(integer), aren't we? Cutting strings is a completely different case, because 'write(s:x)' with length(s)>x does really make sense only if the string is cutted. > it violates 6.10.3.6. (and 6.9.3.6 in ISO 7185.) If there is a way > to make it not violate the above quoted paragraphs, I'd really like > to know how. You are right, but declaring Default-TotalWidth(integer)=0 (or 1) conforms to 6.10.3.3, the output will be a left aligned number, so we can beat "quasi" borland-compatibility and your need of standard-conformance. Once again: WHY NOT, why should it be defined to 5, 8, 10 or whatever value you want? from 6.10.3.1 "the default values shall be implementation- defined", perhaps gpc will be an implementation on it's own. Not conforming to Borland, USCD, IBM-Pascal or whatsoever. > -- > Phil Nelson NetBSD: http://www.netbsd.org > e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org > http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html ================================================================= Sven Engelhardt http://www.sax.net/ mailto:se@sik.de From gpc-request@santra.hut.fi Thu Apr 3 20:49:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA22860 for ; Thu, 3 Apr 1997 20:49:45 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA11560; Thu, 3 Apr 1997 19:54:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58112; Thu, 3 Apr 1997 19:55:14 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA29984 for ; Thu, 3 Apr 1997 20:52:03 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id JAA01067; Thu, 3 Apr 1997 09:51:31 -0800 (PST) Date: Thu, 3 Apr 1997 09:51:31 -0800 (PST) From: Phil Nelson Message-Id: <199704031751.JAA01067@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199704031755.TAA22794@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Thu, 3 Apr 1997 19:55:14 +0200 (MET DST)) Subject: Re: New Alpha Status: RO > (*** Does anybody know how UCSD behaves here? I don't want to dig > out my old Apple //e in order to check this. ***) Yes, it clips strings and it has a 10 for the default field size. Borland is the only Pascal compiler that I have used or heard of that does not clip strings and uses 1 as the default field size. Does someone know of another one (besides gpc)? >The above does not clarify how GPC's default behaviour should be. It should be ISO Pascal with the de-facto-standard field widths. >IMHO Borland's method is more logical than what most Standard Pascal >compilers do. It may be more logical, but we didn't design the language. >However the only true contradiction between Borland and >ISO in this context is string clipping which only occurs in very rare >cases (at least in my programs). It happens in quite a few places in my programs. In fact, it breaks one of my standard teaching examples to show students the power of Pascal. (Write a program to print a right triangle of stars (*).) >Thus I could live with string clipping >being "on" by default. Concerning field widths, it does not contradict >ISO Standard to follow Borland, so we should do that. (Remember that >`--borland-pascal' turns string clipping off and that `--standard-pascal' >makes GPC behave like other Standard Pascal compilers.) I can not live with either being the standard behavior. If you do make Borland behavior standard, at least make it a configure option to not make Borland behavior standard so I don't have to maintain local changes to gpc to get what I really want. Similarly, if you choose to make Standard Pascal the default behavior, have a configure option to choose Borland for those who want it. Better yet, make gpc change depending on whether it is run as gpc (Standard Pascal) or bpc (Borland Pascal). > * When an Integer value is being output with a field width of zero, > output is suppressed. Is this ISO Standard (doesn't seem so), > or a bug? This is not conforming and needs to be changed. It should be the same as 1. > * When a Real value is being output with a too narrow field width, > other compilers bother to make the output as short as possible. > Should GPC do the same? It should follow 6.9.3.4.1 (ISO 7185) which says: if TotalWidth >= ExpDigits + 6 then ActWidth := TotalWidth else ActWidth := ExpDigits + 6; where ActWidth is the actual number of characters written, yeilding the format SV.V+EE where is S is - or blank, V.V is the number, EE is the exponent. (+ could be -). > * All Pascal compilers I have access to have the "feature" that it is > impossible to output a positive Real value without at least one > leading blank. This is annoying in some situations, so what about > an additional switch, e.g. `--no-real-blank', to disable it > optionally? (Better suggestions for the names of all compiler > switches are welcome!) Yes, they are following the standard. I have no problem with the switch as long as it is not standardly on. Is it possible we should ask Juki what the standard behavior should be? Borland vs Standard? -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 20:20:59 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA22831 for ; Thu, 3 Apr 1997 20:20:59 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83982; Thu, 3 Apr 1997 19:25:43 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40092; Thu, 3 Apr 1997 19:26:29 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA29442 for ; Thu, 3 Apr 1997 20:20:35 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id JAA01030; Thu, 3 Apr 1997 09:19:45 -0800 (PST) Date: Thu, 3 Apr 1997 09:19:45 -0800 (PST) From: Phil Nelson Message-Id: <199704031719.JAA01030@fawn.cs.wwu.edu> To: sven@sik.de Cc: gpc@hut.fi In-Reply-To: <3343E042.1C5B384B@sik.de> (message from Sven Engelhardt on Thu, 03 Apr 1997 18:52:18 +0200) Subject: Re: Standard Compatibility [was: Re: New Alpha] Status: RO >Although gpc ain't a commercial product it should be build on wide >acceptance. I agree. >In past nobody was interested in any pascal-standards but Borland. I disagree. Borland did not write ISO 7185 and 10206. If they did, those standards would look a lot different. Units would be part of the standard, which they are not. >Borland-Pascal IMHO is the standard-pascal anyway. I disagree. >gpc really shall default to borland/turbo-pascal behaviour. You could I disagree. I did like the suggestion that gpc could be started from several links, gpc (ie. ISO standard Pascal/ISO Extended Pascal) and bpc (Borland Pascal). I do believe that gpc should support(emulate) Borland Pascal to support Borland Pascal users. But gpc should not standardly be Borland. >I agree too, but why should >{-------------snip-------------} >i:=7; >writeln("i=",i); >{-------------snip-------------} >give somthing like > >"i= 7 ?" Because that is how a majority of Pascal compilers do it. And to ask a furthur question, why should {-------------snip--------------} for i := 1 to 5 do write(a[i]); writeln; {-------------snip--------------} produce output for which you can not distinguish the elements of a? >nb. The Borland Pascal behaviour conforms to ISO 10206 too. How about Are your sure about this? Full Extended Pascal? From my exprience, it violates 6.10.3.6. (and 6.9.3.6 in ISO 7185.) If there is a way to make it not violate the above quoted paragraphs, I'd really like to know how. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Thu Apr 3 20:06:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA22810 for ; Thu, 3 Apr 1997 20:06:17 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55602; Thu, 3 Apr 1997 19:11:02 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58150; Thu, 3 Apr 1997 19:11:47 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA28400 for ; Thu, 3 Apr 1997 20:01:23 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA22794 for gpc@hut.fi; Thu, 3 Apr 1997 19:55:14 +0200 From: Peter Gerwinski Message-Id: <199704031755.TAA22794@agnes.dida.physik.uni-essen.de> Subject: Re: New Alpha To: gpc@hut.fi Date: Thu, 3 Apr 1997 19:55:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach answering to a mail by Phil Nelson: > Ok, then, if I got this right, you have to do > write(num_var:1) and write(string_var) > for output without spaces, whereas > write(num_var) and write(string_var:1) > both don't work this way. > > This seems a bit inconsistent and confusing to me. To me, too. That's why I prefer Borland's way to default to a width of 0 (or 1 in the above example) if nothing was specified (which does not contradict the standard, BTW), and to treat string values just like all the other ones, i.e. without clipping. > I see that your programs rely on this way, but my programs rely on BP's > way, and I don't think there's anything worse with BP's way than the > standard's way. So, obviously, gpc needs to support both ways. So it's okay that "gpc --borland-pascal" does switch off string clipping, while "gpc --standard-pascal" or "gpc --extended-pascal" turns it on. There must also be a pair of separate switches, e.g. "--clip-strings" and "--no-clip-strings", to make this decision independent of the selected Pascal dialect. (*** Does anybody know how UCSD behaves here? I don't want to dig out my old Apple //e in order to check this. ***) Now what about default field widths? The ISO Standard allows this to be implementation-dependent. If we just take Borland's method it still complies to the standard, so there is no a-priori reason to make this change at all. However it seems to be a de-facto-standard that ISO Pascal compilers have default field widths that are wide enough to ensure that numeric values are always output with leading spaces. Thus `--standard-pascal' and `--extended-pascal' should imply such wide field widths. Of course there must be a separate switch for them, for example "gpc --field-widths=12,24,6" (for Integer, Real, Boolean values). The above does not clarify how GPC's default behaviour should be. IMHO Borland's method is more logical than what most Standard Pascal compilers do. However the only true contradiction between Borland and ISO in this context is string clipping which only occurs in very rare cases (at least in my programs). Thus I could live with string clipping being "on" by default. Concerning field widths, it does not contradict ISO Standard to follow Borland, so we should do that. (Remember that `--borland-pascal' turns string clipping off and that `--standard-pascal' makes GPC behave like other Standard Pascal compilers.) BTW, there are some other strange things in GPC's interpretation of field widths: * When an Integer value is being output with a field width of zero, output is suppressed. Is this ISO Standard (doesn't seem so), or a bug? * When a Real value is being output with a too narrow field width, other compilers bother to make the output as short as possible. Should GPC do the same? * All Pascal compilers I have access to have the "feature" that it is impossible to output a positive Real value without at least one leading blank. This is annoying in some situations, so what about an additional switch, e.g. `--no-real-blank', to disable it optionally? (Better suggestions for the names of all compiler switches are welcome!) That's it for the moment. Sqr ( BTW ), this switcherism makes it more and more necessary to let GPC read in a configuration file, or to use `make' to keep all these switches in a Makefile, or to use RHIDE which provides a menu for them. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 03:54:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA23323 for ; Fri, 4 Apr 1997 03:54:25 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA15020; Fri, 4 Apr 1997 02:59:01 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82270; Fri, 4 Apr 1997 02:59:48 +0200 Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA04792 for ; Fri, 4 Apr 1997 03:53:36 +0300 (EET DST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.5/8.8.5) with SMTP id CAA25252; Fri, 4 Apr 1997 02:53:29 +0200 (MET DST) Received: by fiction.pb.owl.de id m0wCxF3-00002eC; Fri, 4 Apr 97 02:52 MET DST Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id IAA01255; Thu, 3 Apr 1997 08:46:55 +0200 From: Nils Bokermann Message-Id: <199704030646.IAA01255@reality.owl.de> Subject: Feature-Control (Was: Re: New Alpha) In-Reply-To: from The African Chief at "Apr 2, 97 10:11:13 am" To: laa12@cc.keele.ac.uk (The African Chief) Date: Thu, 3 Apr 1997 08:46:55 +0200 (MET DST) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > On Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) Peter Gerwinski > wrote: [...] > >In case you have some arguments to set it back to the previous state, > >just post it here. (These are only some constants in `rts/rts.h', so it > >was not much work to change. Perhaps (yet another) command-line switch > >would satisfy everybody?) > > I think this could be the way forward. Having a multitude > of command line switches is very good, in that it gives > the programmer more flexibility to use the compiler in > the way that he/she likes, not in the way that somebody > else thinks they should. However, the price of flexibility > is complexity. In case you haven't done this, can you > introduce a .CFG file (like with Borland) where one can > put all the command line switches that they want to use? > The compiler will read the .CFG file before doing anything > else, and will adjust its behaviour accordingly. I personally > prefer this approach to using environment variables or the > such. You can make many sample .CFG files > (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people > can then rename to GPC.CFG or whatever. Oh, No! Please don't. Why don't we handle this like it is used in the common place way at unixish Systems: Take a Makefile and put a line PFLAGS (is this right?) in it. There you have all your flags, you think you need. Let's say there is a PBORLANDFLAGS=--borland-pascal --what-in-hell-else-is-needed-for-borland and a PMYFLAGS=--left-justified --enable-foo-warnings. Then you can put them together to the archive your program comes with and nobody needs to edit the GPC.CFG. What one might do is put sample Makerules-file(s) to the GPC distribution. Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Fri Apr 4 03:47:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA23311 for ; Fri, 4 Apr 1997 03:47:04 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA14770; Fri, 4 Apr 1997 02:51:41 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82390; Fri, 4 Apr 1997 02:52:27 +0200 Received: from mint.mint.net (root@mint.mint.net [204.254.98.16]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA04788 for ; Fri, 4 Apr 1997 03:45:44 +0300 (EET DST) Received: from dialup-b-8.mint.net (dialup-b-8.mint.net [206.139.113.28]) by mint.mint.net (8.8.5/8.8.5) with SMTP id TAA07028 for ; Thu, 3 Apr 1997 19:45:40 -0500 Message-Id: <199704040045.TAA07028@mint.mint.net> From: "Kevin A. Foss" To: "GPC Mailing List" Date: Thu, 03 Apr 97 19:42:57 -0500 Reply-To: "Kevin Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.9 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Standard Compatibility [was: Re: New Alpha] Status: RO On Thu, 03 Apr 1997 18:52:18 +0200, Sven Engelhardt wrote: >gpc really shall default to borland/turbo-pascal behaviour. You could >implement reading ~/.gpcrc to change that. (For ease this could be done >with a shell script) The cause ain't 'standard' performance, as >thousands >of dos-pascal-programs will be ported to linux. I have to admit I'm in favor of defaulting to ISO standard behavior, but that is just my personal preference. I'm mainly concerned with the last comment... is it true that 'thousands of dos-pascal-programs' will be ported to linux'? I don't see a majority of the DOS-based TP programs being all that useful, or all that many TP programmers perceiving a need to port their software to gpc. Granted there was a lot of good software written with TP and which should be ported, but I think your numbers are over stated. The comment also begs the question. is gpc's role to provide a facility for porting 10 year old DOS programs or for the creation of new programs? I would think primarily the latter and that decisions on gpc's defaults should serve that end. -Kevin -- Kevin A. Foss --- kfoss@mint.net -- From gpc-request@santra.hut.fi Fri Apr 4 05:05:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id FAA23444 for ; Fri, 4 Apr 1997 05:05:33 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA12504; Fri, 4 Apr 1997 04:10:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58124; Fri, 4 Apr 1997 04:10:55 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id FAA05633; Fri, 4 Apr 1997 05:07:01 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id FAA23430; Fri, 4 Apr 1997 05:01:07 +0200 From: Peter Gerwinski Message-Id: <199704040301.FAA23430@agnes.dida.physik.uni-essen.de> Subject: Standard Compatibility (was: New Alpha) To: phil@cs.wwu.edu Date: Fri, 4 Apr 1997 05:01:06 +0200 (MET DST) Cc: gpc@hut.fi, jtv@hut.fi (Jukka Virtanen) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Phil Nelson: > According to myself (Peter Gerwinski): > > (*** Does anybody know how UCSD behaves here? I don't want to dig > > out my old Apple //e in order to check this. ***) > Yes, it clips strings and it has a 10 for the default field size. Meanwhile I digged out my UCSD Pascal *documentation*, and it says that UCSD Pascal has a default width of 1, but it clips strings. I did not verify this on the Apple //e, but if the default width would have been something different from 1, I would remember it now. > Borland is the only Pascal compiler that I have used or heard of that does > not clip strings and uses 1 as the default field size. Does someone > know of another one (besides gpc)? Yes, almost every Pascal compiler I know for the PC. I checked it for FPK Pascal and Virtual Pascal: Both have a default width of 1 and don't clip strings. I cannot check it now, but I am sure that Speed Pascal, MS Quick Pascal, and TMT Pascal behave in the same way. Anyway, we should count programmers and source lines, not compilers. AFAIK Borland Pascal has more users than all other existing Pascal compilers together. This does, of course, not mean that Borland's way is the best one, but it means that we must not ignore Borland Pascal. > >The above does not clarify how GPC's default behaviour should be. > It should be ISO Pascal with the de-facto-standard field widths. Why? > >IMHO Borland's method is more logical than what most Standard Pascal > >compilers do. > It may be more logical, but we didn't design the language. We *are* designing a language. I already wrote some weeks ago: It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself. [...] The current design of GPC is to integrate the good features from the many existing Pascal standards, and you can restrict GPC to these standards using compiler switches: --standard-pascal-level-0 Should work --standard-pascal Do conformant arrays work now? --extended-pascal Not yet fully implemented --object-pascal Just started --ucsd-pascal Almost complete --borland-pascal Almost complete --delphi Just started --pascal-sc Just started The default should be the most powerful easy-to-use and easy-to-understand compiler which can be constructed out of these standards plus GNU extensions. This is in the spirit of GCC; `info gcc invoking "warning options"' says: We recommend [...] that users take advantage of the extensions of GNU C and disregard the limitations of other compilers. Aside from certain supercomputers and obsolete small machines, there is less and less reason ever to use any other C compiler other than for bootstrapping GNU CC. If it is possible to have something better (in this case: more logical) than most Standard Pascal compilers, this better solution should be the default, and there must be a compiler switch to emulate those other compilers. And, anyway, we are talking about a default width of 1, not about string clipping, so this would not even violate the ISO Standard. > [...] > I can not live with either being the standard behavior. If you do make > Borland behavior standard, at least make it a configure option to not > make Borland behavior standard so I don't have to maintain local changes > to gpc to get what I really want. Similarly, if you choose to make > Standard Pascal the default behavior, have a configure option to choose > Borland for those who want it. Better yet, make gpc change depending > on whether it is run as gpc (Standard Pascal) or bpc (Borland Pascal). I never intended to make GPC's standard behaviour to emulate Borland Pascal, but I also don't intend to restrict GPC by default to the ISO Standard. GPC shall be something superior to both Borland Pascal and ISO Pascal. It is a very good idea to make GPC's behaviour depending on the name it is invoked with. What about the following: pc ISO 7185 Standard Pascal compiler epc ISO 10206 Extended Pascal compiler bpc Borland Pascal compatible compiler ... (other de-jure or de-facto standards) gpc Integrate all good features (not the misfeatures) of these standards in one compiler. People who need compatibility to other ISO Extended Pascal compilers will invoke GPC as `epc' and will not notice any Borlandish behaviour. (If they do, the may report it as a bug.) Vice versa, those who want a "32-bit Borland Pascal" will call GPC as `bpc'. Those who call GPC as `gpc' will profit from both (and more) dialects. One typical example is to allow components of structured variables as `for' loop control variables (according to Borland). This is a harmless extension to the ISO Standard - nobody will use this unintentionally -, so `gpc' will accept it. (`epc' will not.) Now we can combine this with Extended Pascal's set member iteration (to be implemented soon): for i [ k ] in [ 2, 3, 5, 7, 11 ] do ... I intend, for example, to combine Extended Pascal's schema types with Borland Pascal's object types. > > * When an Integer value is being output with a field width of zero, > > output is suppressed. Is this ISO Standard (doesn't seem so), > > or a bug? > > This is not conforming and needs to be changed. It should be the same as 1. Okay, I will be happy to change this. > > * When a Real value is being output with a too narrow field width, > > other compilers bother to make the output as short as possible. > > Should GPC do the same? > > It should follow 6.9.3.4.1 (ISO 7185) [...] Okay, I'll take care of that. (Although I wouldn't mind if somebody else would hack the runtime library for such things, so I can face schema types instead ...) > > [blank in front of Reals] > > Yes, they are following the standard. I have no problem with the switch > as long as it is not standardly on. Okay. It will be "off" by default. > Is it possible we should ask Juki what the standard behavior should be? > Borland vs Standard? Since Juki is on this list, he should read all this. Hey, Juki, what's your point of view? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 08:16:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id IAA24278 for ; Fri, 4 Apr 1997 08:16:39 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA15516; Fri, 4 Apr 1997 07:21:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31314; Fri, 4 Apr 1997 07:22:02 +0200 Received: from mail.castrop-rauxel.netsurf.de (root@[194.64.248.1]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id IAA07751 for ; Fri, 4 Apr 1997 08:10:56 +0300 (EET DST) Received: from kalwa1 (isdn68.Castrop-Rauxel.NetSurf.DE [194.64.248.104]) by mail.castrop-rauxel.netsurf.de (8.8.5/INS-G1.3.3) with SMTP id HAA00548 for ; Fri, 4 Apr 1997 07:10:44 +0200 (MET DST) Received: by kalwa1 with Microsoft Mail id <01BC40C7.4D670D00@kalwa1>; Fri, 4 Apr 1997 07:10:40 +-200 Message-Id: <01BC40C7.4D670D00@kalwa1> From: Achim Kalwa To: "'gpc@hut.fi'" Subject: GPC for HP3000 Date: Fri, 4 Apr 1997 07:09:38 +-200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status: RO Hello out there! I'm looking for GPC ported to HP3000 systems (PA-RISC cpu). At the = office, i have access to two HP3000 machines, but no developer tools. As = I'm pascal programmer, i would like to have a compiler on that = machine(s). But prior to buying the HP pascal compiler, it would be nice = to see if my ideas would work and to get a feeling for the performance. Did someone the port successfully and has a binary "distribution"? Or = are there other "free" Pascal compilers fpr HP3000? Thanks in advance Achim achim.kalwa@do.netsurf.de From gpc-request@santra.hut.fi Fri Apr 4 13:42:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA24636 for ; Fri, 4 Apr 1997 13:42:04 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94732; Fri, 4 Apr 1997 12:46:33 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36480; Fri, 4 Apr 1997 12:47:21 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA22043 for ; Fri, 4 Apr 1997 13:43:27 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id MAA07137 (8.7.6/7.5c-FAU); for ; Fri, 4 Apr 1997 12:43:23 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id MAA21882 (SMI-8.6/7.5b-FAU); Fri, 4 Apr 1997 12:43:22 +0200 From: Frank Heckenbach Message-Id: <199704041043.MAA21882@helena.mi.uni-erlangen.de> Date: Fri, 4 Apr 1997 12:43:21 +0200 To: gpc@hut.fi Subject: Re: Standard Compatibility [was: Re: New Alpha] Status: RO Trying to sum up the points of this discussion and adding some of my opinions: - Both formatting ways have their place. Though programmers are used to one of them, I guess in most programs, you'll find places where one way will be easier to use, and others where the other way will be preferable. - In gpc, the switches --standard-pascal/--extended-pascal or --borland-pascal should choose the according defaults. - Additionally, switches like --[no-]clip-strings, --default-width=..., --[no-]real-blank change the defaults in these regards. - There should also be compiler options like {$CLIP+/-}, {$DEFWIDTH 12}, {$REALBLANK+/-} (?). This will be necessary if BP-ish and SP-ish programmers work together on a project, and want to build their program with --automake. And it can be convenient for a single programmer to change it for different procedures (see above). - The default behaviour without any switches or options can be like standard Pascal in this regard. (I'm saying this although I'm coming from BP.) Sven, those BP programmers who want to change smoothly to gpc will use --borland-pascal anyway, so there should be no problems with this one. - A way to read in configuration files (like "gpc @gpc.cfg") seems good (in addition to environment variables and command line options). Even if gpc doesn't read in a config file by default, it should be no problem to set an alias accordingly (BTW, even modern DOSes support something like alias in the form of DosKey...) - Putting those flags in a makefile is also an option, but only if one is to use makefiles at all. Personally, I don't like makefiles, and I think Pascal programs don't need makefiles, since all the dependencies between modules are there in the code (unlike C). Therefore, I'd like to be able to compile any Pascal program with simply "gpc --automake progname.pas". Any compiler options should be in the source (at least there should be a way to do so). BTW (not quite to this topic): Is there any reason why the default output file is called "a.out" (or "a.exe" with DOS) - other than historical reasons? Wouldn't it make more sense to default to the base filename of the main program, in order to save programmers from typing "gpc -o x x.pas"? - Naming the program gpc, spc, epc and bpc seems like a sensible way for Un*x, but on systems that don't support either hard or symbolic links (aka DOS), it would mean 4 separate binaries - probably not a good solution there (although those DOS users who want to do only Borland style could rename gpc.exe to bpc.exe). So this could be one, but not the only, way to choose the defaults. Note: there would be a difference between gpc (GNU Pascal with all the extensions) and spc (standard Pascal only), perhaps not in the question of output formatting, but in other regards. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Fri Apr 4 13:15:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA24600 for ; Fri, 4 Apr 1997 13:15:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84196; Fri, 4 Apr 1997 12:20:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26438; Fri, 4 Apr 1997 12:21:00 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA20543 for ; Fri, 4 Apr 1997 13:13:10 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 4 Apr 1997 11:14:34 +0100 Received: from [0.29.135.36] by potter.cc.keele.ac.uk; Fri, 4 Apr 1997 11:13:03 +0100 From: The African Chief To: Nils Bokermann Cc: gpc Subject: Feature-Control (Was: Re: New Alpha) Message-Id: Date: Fri, 4 Apr 1997 11:15:26 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Thu, 3 Apr 1997 08:46:55 +0200 (MET DST) Nils Bokermann wrote: [...] >>In case you haven't done this, can you >> introduce a .CFG file (like with Borland) where one can >> put all the command line switches that they want to use? >> The compiler will read the .CFG file before doing anything >> else, and will adjust its behaviour accordingly. I personally >> prefer this approach to using environment variables or the >> such. You can make many sample .CFG files >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people >> can then rename to GPC.CFG or whatever. > >Oh, No! Please don't. >Why don't we handle this like it is used in the common place way at unixish >Systems: Take a Makefile and put a line PFLAGS (is this right?) in it. There >you have all your flags, you think you need. Let's say there is a >PBORLANDFLAGS=--borland-pascal --what-in-hell-else-is-needed-for-borland >and a PMYFLAGS=--left-justified --enable-foo-warnings. >Then you can put them together to the archive your program comes with and >nobody needs to edit the GPC.CFG. > >What one might do is put sample Makerules-file(s) to the GPC distribution. Makefiles are probably wonderful. However, I don't know much about them - and I am sure that many people from a BP or Delphi background are in the same boat. I am puzzled however as to what is so bad about using a .CFG file. Can you please say what your objection is? I have seen the Makefiles that come with GPC and GCC, and, frankly speaking, a lot of the contents are like Swahili to me (meaning something which people think I ought to understand, but which I most certainly do not understand). CFG files that contain only command line switches (just as you would pass them at the command line) are simple enough for anyone to use. Makefiles seem to involve learning yet another scripting language. While this may be familiar to unix people (and I have used them before - long ago, when programming for OS/2 with GCC) a lot of Pascal programmers from non-unix and non-C backgrounds wouldn't want to touch them with a barge pole - and I am one of them! Surely, GPC could cater for everybody? (or, at least, meet them half-way). Any comments? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri Apr 4 16:19:49 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA24829 for ; Fri, 4 Apr 1997 16:19:49 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60234; Fri, 4 Apr 1997 15:24:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40084; Fri, 4 Apr 1997 15:25:03 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA29656 for ; Fri, 4 Apr 1997 16:19:08 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 4 Apr 1997 14:20:33 +0100 Received: from [0.66.213.126] by potter.cc.keele.ac.uk; Fri, 4 Apr 1997 14:18:58 +0100 From: The African Chief To: GPC list Subject: Objects and GPC Message-Id: Date: Fri, 4 Apr 1997 14:20:56 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Hiya! Using the latest GPC alpha (9704), I find that I cannot import objects from a unit. I originally had the source for TObject (below) in a unit, and used the unit in this program (test.pas). I had compile errors all the time. Then, I put the object's source into test.pas itself, and it compiled. But when I tried to create a descendant object (NewObj), as seen in the source below, again, I had compile errors - complaining about the "initializer element" for some of the methods not being "constant". Can anyone tell why this source does not compile, even with the -borland-pascal flag? It compiles and runs okay with BP7 and BPW. Thanks! { ---- cut -----} Program Test; {$define debug} Type pObject = ^TObject; ChildPtr = pObject; TObject = Object Parent : pObject; Child : ChildPtr; Name : String[255]; Handle : integer; { BP } Constructor Init; Destructor Done;virtual; { Delphi } Procedure Free;virtual; {calls Destroy} Destructor Destroy;virtual; Constructor Create (aOwner : pObject); End; { TObject } Constructor TObject.Init; Begin Parent := Nil; End; { TObject.Init } {////////////} Constructor TObject.Create; Begin Parent := aOwner; End; { TObject.Create } {////////////} Destructor TObject.Done; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Done } {////////////} Destructor TObject.Destroy; Begin Handle := 0; Name := ''; Parent := Nil; End; { TObject.Destroy } {////////////} Procedure TObject.Free; Begin {$ifdef debug}Writeln ('Free!');{$endif debug} Dispose (pObject (@Self), Destroy); End; { TObject.Free } {////////////} Type PNewObj = ^NewObj; NewObj = Object (TObject) Constructor Create (aOwner:PObject); End; { NewObj } Constructor NewObj.Create; Begin Inherited Create (aOwner); Name := 'Object Number 2 is a Child!'; Handle := -40; End; { NewObj.Create } { Program() } Var ThisObj : TObject; Begin Writeln ('Hello World!'); ThisObj.Init; With ThisObj do begin Handle := -1; Name := 'Object Number 1'; Child := New (PNewObj, Create (@ThisObj) ); Writeln ('My handle = ', Handle); Writeln ('My name = ', Name); Writeln ('Child handle = ', Child^.Handle); Writeln ('Child name = ', Child^.Name); Writeln ('Child PARENT handle = ', Child^.Parent^.Handle); Child^.Free; Done; end; { With Ob^ } Writeln ('Hello World Number 2 !!'); End { Program() }. { --- end cut ---} Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri Apr 4 14:22:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA24724 for ; Fri, 4 Apr 1997 14:22:26 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96610; Fri, 4 Apr 1997 13:26:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78822; Fri, 4 Apr 1997 13:27:42 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA23580 for ; Fri, 4 Apr 1997 14:23:01 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id NAA00329 for ; Fri, 4 Apr 1997 13:23:06 +0100 Date: Fri, 4 Apr 1997 13:23:05 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: Re: Standard Compatibility [was: Re: New Alpha] In-Reply-To: <199704041043.MAA21882@helena.mi.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 4 Apr 1997, Frank Heckenbach wrote: > > - A way to read in configuration files (like "gpc @gpc.cfg") seems good (in > addition to environment variables and command line options). Even if gpc > doesn't read in a config file by default, it should be no problem to set > an alias accordingly (BTW, even modern DOSes support something like alias > in the form of DosKey...) > Let me remind you that: 1) A config file already exists and it is called `specs' (`specs.gpc' if you're using the djgpp version). It is shared among all members of the GNU compiler family. Introducing a second, gpc specific config file doesn't make sence IMHO. 2) GPC doesn't have to be modified to implement the @file trick. This is a DOS "feature" to overcome DOS commandline-length limitations. If you want a certain behaviour than: ------------- begin bpc.cfg -------------- --automake --borland-pascal --my-wild-language-switch --------------- end bpc.cfg -------------- and: ------------- begin bpc.bat -------------- @echo off gpc @c:\djgpp\bin\bpc.cfg %1 %2 %3 %4 %5 %6 %7 %8 %9 --------------- end bpc.bat -------------- This will do just what you want. Usually you would put the long-name options which select the dialect in the CFG file (you want these always on/off) and set optimization (-On) and debugging (-gn) from the command line. 3) If you are a delphi/tp user and want point-and-click userfriendlyness, I suggest you install RHIDE. Will look very familiar. Can even write one of those dreaded makefiles for you ;-) > - Putting those flags in a makefile is also an option, but only if one > is to use makefiles at all. Personally, I don't like makefiles, and I > think Pascal programs don't need makefiles, since all the dependencies > between modules are there in the code (unlike C). Therefore, I'd like > to be able to compile any Pascal program with simply > "gpc --automake progname.pas". Any compiler options should be in the > source (at least there should be a way to do so). > Answered above (I hope) > BTW (not quite to this topic): Is there any reason why the default > output file is called "a.out" (or "a.exe" with DOS) - other than > historical reasons? Wouldn't it make more sense to default to the > base filename of the main program, in order to save programmers from > typing "gpc -o x x.pas"? > Besides hisotorical reasons, it is ofen used in automated testsuites (in a unix environment) where the compiler is run on a large set of source files. > - Naming the program gpc, spc, epc and bpc seems like a sensible way for > Un*x, but on systems that don't support either hard or symbolic links > (aka DOS), it would mean 4 separate binaries - probably not a good solution > there (although those DOS users who want to do only Borland style could > rename gpc.exe to bpc.exe). So this could be one, but not the only, way to > choose the defaults. > I'm currently experimenting with a seperate compiler pre-driver (like g++ and f77) which can set the language switches when invoked as `bpc' or `gpc' etc. It's about 15K which is small compared to the 1.5M of gpc1, even if you install it 4 times because your OS lacks symlinks. just my HFL 0.02, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Fri Apr 4 17:05:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA24901 for ; Fri, 4 Apr 1997 17:05:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99048; Fri, 4 Apr 1997 16:10:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA27870; Fri, 4 Apr 1997 16:10:57 +0200 Received: from snert.wash.cedar-rapids.k12.ia.us (lindholm@snert.wash.cedar-rapids.k12.ia.us [205.221.77.102]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA31243 for ; Fri, 4 Apr 1997 17:04:16 +0300 (EET DST) Received: (from lindholm@localhost) by snert.wash.cedar-rapids.k12.ia.us (8.8.4/8.8.4) id IAA28491 for gpc@hut.fi; Fri, 4 Apr 1997 08:07:41 -0600 Date: Fri, 4 Apr 1997 08:07:41 -0600 From: Stephen Lindholm Message-Id: <199704041407.IAA28491@snert.wash.cedar-rapids.k12.ia.us> To: gpc@hut.fi Subject: Two bugs Status: RO These two should not compile, and indeed, do not compile under other compilers. program temp; var a = 1 .. 2; type b: a; begin if 1 then b := 0; end. 1 is not a boolean, yet it is accepted as boolean. b is initialized to an out-of-bounds value. From gpc-request@santra.hut.fi Fri Apr 4 17:36:54 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA24943 for ; Fri, 4 Apr 1997 17:36:53 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100136; Fri, 4 Apr 1997 16:41:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA25130; Fri, 4 Apr 1997 16:42:06 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA32047 for ; Fri, 4 Apr 1997 17:35:27 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id QAA05653; Fri, 4 Apr 1997 16:35:32 +0100 Date: Fri, 4 Apr 1997 16:35:30 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Achim Kalwa Cc: GPC list Subject: Re: GPC for HP3000 In-Reply-To: <01BC40C7.4D670D00@kalwa1> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 4 Apr 1997, Achim Kalwa wrote: > Hello out there! > > I'm looking for GPC ported to HP3000 systems (PA-RISC cpu). At the office, i have access to two HP3000 machines, but no developer tools. As I'm pascal programmer, i would like to have a compiler on that machine(s). But prior to buying the HP pascal compiler, it would be nice to see if my ideas would work and to get a feeling for the performance. > Did someone the port successfully and has a binary "distribution"? Or are there other "free" Pascal compilers fpr HP3000? > I haven't heard of anybody using GPC on a HP3000. Maybe you can find a GCC binary at the HP-UX Porting & Archive Centre [hpux.csc.liv.ac.uk] You could use that to bootstrap your own GCC (and GPC) You must have the C libraries and header files to do this. Unfortunately these are often part of some "development package" which also includes the compiler itself... If you have the libraries & headers, but can't find a GCC binary, it is still possible to bootstrap from a different machine, but that's a non-trivial exercise. Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Fri Apr 4 18:07:47 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA24988 for ; Fri, 4 Apr 1997 18:07:47 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82894; Fri, 4 Apr 1997 17:12:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47394; Fri, 4 Apr 1997 17:12:59 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA01068 for ; Fri, 4 Apr 1997 18:06:37 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 4 Apr 1997 16:07:58 +0100 Received: from [0.6.184.20] by potter.cc.keele.ac.uk; Fri, 4 Apr 1997 16:06:25 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: Small success! Message-Id: Date: Fri, 4 Apr 1997 16:08:24 +0000 (GMT) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Ahem ... I have now discovered the reason why I could not import my object from a unit (there was no .o file!). Using "--automake" ensures that the .o file is created, and the object imports okay. However, the problem still exists with creating a descendant object. I can now (magically) create one (if the parent object is in a unit), however, if I try to create a new constructor, any call (inside the new constructor) to the ancestor constructor (e.g.., "Inherited Init") causes a GPF ! The parent object is now in a unit, but the descendant object is in the main program. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri Apr 4 20:20:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25237 for ; Fri, 4 Apr 1997 20:20:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA99112; Fri, 4 Apr 1997 19:24:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74948; Fri, 4 Apr 1997 19:25:25 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA05661 for ; Fri, 4 Apr 1997 20:19:28 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id JAA08171; Fri, 4 Apr 1997 09:19:10 -0800 (PST) Date: Fri, 4 Apr 1997 09:19:10 -0800 (PST) From: Phil Nelson Message-Id: <199704041719.JAA08171@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199704041803.UAA25178@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Fri, 4 Apr 1997 20:03:08 +0200 (MET DST)) Subject: Re: Standard Compatibility: my plans Status: RO >Here are my plans for GPC's default `write'/`writeln' behaviour: Thank you for telling of your plans. I do like them. > * I will try to make it possible to pass these command-line options > as compiler directives, e.g. (*$field-widths=12,24,6*). Having this, I do like this. Thank you! -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Fri Apr 4 20:12:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25227 for ; Fri, 4 Apr 1997 20:12:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76674; Fri, 4 Apr 1997 19:17:03 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60802; Fri, 4 Apr 1997 19:17:50 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA04856 for ; Fri, 4 Apr 1997 20:08:21 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA25161; Fri, 4 Apr 1997 20:02:38 +0200 From: Peter Gerwinski Message-Id: <199704041802.UAA25161@agnes.dida.physik.uni-essen.de> Subject: Re: Objects and GPC To: laa12@cc.keele.ac.uk (Abimbola A. Olowofoyeku) Date: Fri, 4 Apr 1997 20:02:38 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi everybody, hi African Chief! It seems that I am no more the only one who uses Objects. :-) According to The African Chief: > Using the latest GPC alpha (9704), I find that I cannot > import objects from a unit. I originally had the source > for TObject (below) in a unit, and used the unit in > this program (test.pas). I had compile errors all > the time. That's strange because when I put TObject below in a separate Unit everything compiles fine. However the resulting code is buggy. :-( I will investigate this. Did you recompile the Unit? The GPI file format changes with every new alpha GPC. > Then, I put the object's source into test.pas > itself, and it compiled. But when I tried to create > a descendant object (NewObj), as seen in the > source below, again, I had compile errors - > complaining about the "initializer element" for > some of the methods not being "constant". I see. You have detected a bug ... even two bugs. Thanks for reporting them! > Can anyone tell why this source does not compile, > even with the -borland-pascal flag? The `--borland-pascal' switch has no effect on this. You do not need to enable Objects, but vice versa, if you specify one of `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', or `--ucsd-pascal', you *disable* OOP. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 20:11:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25223 for ; Fri, 4 Apr 1997 20:11:42 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100336; Fri, 4 Apr 1997 19:16:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42816; Fri, 4 Apr 1997 19:16:50 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA05187 for ; Fri, 4 Apr 1997 20:09:23 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA25194 for gpc@hut.fi; Fri, 4 Apr 1997 20:03:36 +0200 From: Peter Gerwinski Message-Id: <199704041803.UAA25194@agnes.dida.physik.uni-essen.de> Subject: GPC's default behaviour (was: Standard Compatibility) To: gpc@hut.fi Date: Fri, 4 Apr 1997 20:03:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > - The default behaviour without any switches or options can be like standard > Pascal in this regard. (I'm saying this although I'm coming from BP.) > Sven, those BP programmers who want to change smoothly to gpc will use > --borland-pascal anyway, so there should be no problems with this one. Here I disagree. (Details below.) (I am also coming from BP, but I am disappointed about Borland, so I consider myself to be more-or-less neutral. ;-) > - A way to read in configuration files (like "gpc @gpc.cfg") seems good (in > addition to environment variables and command line options). Even if gpc > doesn't read in a config file by default, it should be no problem to set > an alias accordingly (BTW, even modern DOSes support something like alias > in the form of DosKey...) I agree, even though there is `specs.gpc'. However there are technical problems to implement "gpc @gpc.cfg" in a clean way, so let's first see whether we can do some magic with `specs.gpc' and such. > [...] > Note: there would be a difference between gpc (GNU Pascal with all the > extensions) and spc (standard Pascal only), perhaps not in the question > of output formatting, but in other regards. Yes. We would end up with several different compilers - which are in fact all the same with different (implicit) command-line options. However I guess that nobody will use anything besides `gpc', the default GNU Pascal compiler: * Those who vote for more Borland Pascal support in GPC don't really want an emulation of Borland Pascal 7.0. They are looking out for something like a BP 8.0, a "natural" successor of BP 7.0. Since Borland clients are used to new features appearing with each release, they won't restrict themselves to `--borland-pascal'. Instead, they want to have GPC's default behaviour to be Borlandish enough to feel at home. * As far as I could see from this discussion, those who favor ISO Pascal (in particular: ISO 10206 Extended Pascal) do not want either to have just ISO, but they want to have a compiler which adds "natural" extensions to the ISO Standard. So they will also call GPC as `gpc', not as `epc', and want to have GPC's default behaviour similar enough to other ISO compilers to feel at home. The only solution is to make GPC a chameleon: The default behaviour must be acceptable by both sides, and there must be compiler switches to tune GPC to make everybody feel at home. As far as I have learned during my work on GPC, Borland Pascal and Extended Pascal can peacefully coexist - much better than you would expect when trying to compile a BP program with EP or vice versa. Most differences are missing features of one compiler in the other one. For example, BP does not have `Complex' while EP does not have `Word'. Okay, it's no problem to have both data types in one compiler. In fact this "field width" story is the first case where we have an actual contradiction. The most funny thing is that BP does not contradict to the ISO Standard but to some de-facto standard among ISO Pascal compilers. Whenever I will encounter such a contradiction I will * introduce a new command-line switch (because there will be programs relying on a specific behaviour of the compiler) and * make the "best" solution GPC's default behaviour. What "best" means must be discussed on this list. I do *not* automatically consider ISO compliance to be "best" (because the ISO Standard is the official standard, accepted by many companies which provide compilers for it); *nor* do I automatically consider Borland compatibility to be "best" (because BP is the world-wide de-facto Pascal standard on the PC which is in turn the de-facto standard for computers). Both standards must be checked whether they "combine the clarity of Pascal with powerful tools suitable for real-life programming" as stated in the GPC documentation to be the purpose of GNU Pascal. In cases where it is not clear which way is better, ISO will be favorized. I am glad that up to now there was no decision "against" ISO. Thanks to all of you for your help to find out what is "best" (or at least "not too bad") in the case of field widths. If there are no strong objections against my plan, I would like to close that discussion now and to implement all those nice switches I have promised in my other mail. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 20:10:58 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25219 for ; Fri, 4 Apr 1997 20:10:58 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100660; Fri, 4 Apr 1997 19:15:21 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44804; Fri, 4 Apr 1997 19:16:08 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA04165 for ; Fri, 4 Apr 1997 20:08:39 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA25170 for gpc@hut.fi; Fri, 4 Apr 1997 20:02:52 +0200 From: Peter Gerwinski Message-Id: <199704041802.UAA25170@agnes.dida.physik.uni-essen.de> Subject: Configuration files (was: Standard compatibility) To: gpc@hut.fi Date: Fri, 4 Apr 1997 20:02:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > [...] > > 1) A config file already exists and it is called `specs' (`specs.gpc' if > you're using the djgpp version). It is shared among all members of the GNU > compiler family. Introducing a second, gpc specific config file doesn't > make sence IMHO. I agree in principle, but I just had a look at that `specs' file. It seems to be written in some alien dialect for me, and the info documentation does not say anything about its format. If there is an easy way to put GPC options into this `specs' file we should document is. This would cover some applications of a `gpc.cfg' file, but not all: `specs' is a global configuration file while `gpc.cfg' would be local. > 2) GPC doesn't have to be modified to implement the @file trick. This is > a DOS "feature" to overcome DOS commandline-length limitations. > > [...] Yes, but this does not work on non-DOS platforms. I didn't find it in the GPC source, so it seems that we cannot enable it for other platforms (assuming for the moment that we want to do that). > 3) If you are a delphi/tp user and want point-and-click userfriendlyness, > I suggest you install RHIDE. Will look very familiar. Can even write one > of those dreaded makefiles for you ;-) I agree. The RHIDE can provide menus for all command-line options. > > - Putting those flags in a makefile is also an option, but only if one > > is to use makefiles at all. Personally, I don't like makefiles, and I > > think Pascal programs don't need makefiles, since all the dependencies > > between modules are there in the code (unlike C). Therefore, I'd like > > to be able to compile any Pascal program with simply > > "gpc --automake progname.pas". Any compiler options should be in the > > source (at least there should be a way to do so). > > Answered above (I hope) However I have planned to make it possible to put all compiler options (including `--automake' :) into the source, so you will be able to compile any Pascal program just with "gpc progname.pas". > > BTW (not quite to this topic): Is there any reason why the default > > output file is called "a.out" (or "a.exe" with DOS) - other than > > historical reasons? Wouldn't it make more sense to default to the > > base filename of the main program, in order to save programmers from > > typing "gpc -o x x.pas"? > > Besides hisotorical reasons, it is ofen used in automated testsuites > (in a unix environment) where the compiler is run on a large set of source > files. EMX defaults to compile `x.pas' to `x.exe'. RHIDE does "gpc -o x.exe x.pas" automatically. On my Linux box, I use a shell script gpc --some-options --automake="--some-more-options" -o $1 $1.pas -lmylibs which does both: specify the name of the executable and pass all options to the compiler. > I'm currently experimenting with a seperate compiler pre-driver (like g++ > and f77) which can set the language switches when invoked as `bpc' or > `gpc' etc. It's about 15K which is small compared to the 1.5M of gpc1, > even if you install it 4 times because your OS lacks symlinks. In fact DJGPP supports symbolic links on DOS. But anyway, Jan-Jaap's solution will - hopefully - eliminate a lot of trouble. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 20:10:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25215 for ; Fri, 4 Apr 1997 20:10:45 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58020; Fri, 4 Apr 1997 19:15:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA71922; Fri, 4 Apr 1997 19:15:56 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA04801 for ; Fri, 4 Apr 1997 20:08:49 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA25178 for gpc@hut.fi; Fri, 4 Apr 1997 20:03:08 +0200 From: Peter Gerwinski Message-Id: <199704041803.UAA25178@agnes.dida.physik.uni-essen.de> Subject: Standard Compatibility: my plans To: gpc@hut.fi Date: Fri, 4 Apr 1997 20:03:08 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi, everybody! Here are my plans for GPC's default `write'/`writeln' behaviour: * I will fix that bug which suppresses output when the field width is 0. * String clipping will be ON by default, thus GPC will follow ISO and UCSD, not Borland. It can be switched OFF either with `--borland-pascal' or `--delphi', or with a separate switch `--no-clip-strings'. * Field widths are 0 by default. This does comply to the ISO Standard Specifications AND corresponds to the behaviour of UCSD Pascal, Borland Pascal, and other PC Pascal compilers. This default can be changed using `--field-widths=12,24,6' (for Integer, Real, Boolean fields) which can be given either when compiling a Pascal source file ("locally") or when configuring GPC (making the default widths "global" for a site). * Although default field widths of 0 are correct by ISO, there seems to be a de-facto standard among ISO Pascal compilers that field widths must ensure at least one blank in front of Integers and Reals. For this reason, `--standard-pascal' and `--extended-pascal' will imply default field widths which will make GPC behave like other ISO Pascal compilers. * If `--field-widths' is given without arguments, it will make the field widths big enough to ensure at least one blank in front of numeric values. * I will try to make it possible to pass these command-line options as compiler directives, e.g. (*$field-widths=12,24,6*). Having this, you can write programs which will behave independently of command-line options given to the compiler. This possibility will also cover most applications of a "GPC configuration file". Okay, this will take some time to finish. I hope that everybody can live with this. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 4 20:10:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25211 for ; Fri, 4 Apr 1997 20:10:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95752; Fri, 4 Apr 1997 19:14:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26592; Fri, 4 Apr 1997 19:15:25 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA04946 for ; Fri, 4 Apr 1997 20:09:02 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA25186 for gpc@hut.fi; Fri, 4 Apr 1997 20:03:21 +0200 From: Peter Gerwinski Message-Id: <199704041803.UAA25186@agnes.dida.physik.uni-essen.de> Subject: Relevance of Borland Pascal (was: Standard compatibility) To: gpc@hut.fi Date: Fri, 4 Apr 1997 20:03:21 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Kevin A. Foss: > > I have to admit I'm in favor of defaulting to ISO standard behavior, but > that is just my personal preference. I'm mainly concerned with the last > comment... is it true that 'thousands of dos-pascal-programs' will be > ported to linux'? Yes. There is an incredible number of Borland Pascal programmers out there. Just watch news://comp.lang.pascal.*: most questions, even those posted to comp.lang.pascal.ansi-iso, concern Borland Pascal. Some of them (~50%???) happily change to Delphi and move to Windows 95 without ever looking out of the (MS-) Window. Some others (which I would consider the best ones;) want to try Linux and are looking out for a Pascal compiler. > I don't see a majority of the DOS-based TP programs > being all that useful, Of course not all of that is useful, but enough to make it worth the effort. In addition: think of games. Not useful, but they can make Linux more attractive. Many games are written in Borland Pascal for DOS. I have heared of game authors who would be happy to have a 32-bit Pascal for DOS. If they see that there is a compiler which supports Linux as well, they will give Linux a try. > or all that many TP programmers perceiving a need to > port their software to gpc. Granted there was a lot of good software > written with TP and which should be ported, but I think your numbers are > over stated. I think these numbers are realistic. (Just what I guess from conversation with other programmers.) > The comment also begs the question. is gpc's role to provide a facility for > porting 10 year old DOS programs or for the creation of new programs? I > would think primarily the latter and that decisions on gpc's defaults > should serve that end. GPC is for the creation of new programs. It should provide facilities to port existing programs (all those --command-line-switches), but this should not become our primary goal. This also guided my decision in favour of a default field width of 0: Most programs written today don't sequentially read in columns of numbers, process them and put out some other columns of numbers. Today's programs process strings and interact with the user; most numbers appear in sentences like Frank's "There are 7 items." Thus GPC's default behaviour should support the latter one; those of us who need the first one (including myself, sometimes) are experienced enough to change GPC's default by configuration, a command-line switch, or even an explicit field width specification. For programs intended to be portable the latter method is the most secure one anyway. Greetings, Peter From gpc-request@santra.hut.fi Sat Apr 5 03:50:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA25655 for ; Sat, 5 Apr 1997 03:50:41 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA98846; Sat, 5 Apr 1997 02:54:56 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56702; Sat, 5 Apr 1997 02:55:45 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA12987 for ; Sat, 5 Apr 1997 03:50:58 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id CAA13723; Sat, 5 Apr 1997 02:37:24 +0100 Date: Sat, 5 Apr 1997 02:37:24 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Nils Bokermann Cc: Sven Engelhardt , gpc Subject: Re: Standard Compatibility [was: Re: New Alpha] In-Reply-To: <199704040631.IAA02706@reality.owl.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 4 Apr 1997, Nils Bokermann wrote: > Hi! > > I don't like the idea of a local (user) configuration file as GPC.CFG or > ..gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ../configure --try-to-be-a-borland-compiler or > ../configure --use-standard-pascal. > Oh no! This is a support nightmare. Imagine people complaining "my gpc does XYZ when I feed it this ABC source!". Then we would have to find out _what_ GPC they have in first place. The confusion caused by rapidly changing GPC revsions and a number of different platform specific problems is enough, IMHO. Unless yet another option were added which would dump all options passed at build time, and _everybody_ would faithfully mention this in bugreports.... Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Sat Apr 5 02:58:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA25611 for ; Sat, 5 Apr 1997 02:58:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100138; Sat, 5 Apr 1997 02:02:56 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42244; Sat, 5 Apr 1997 02:03:44 +0200 Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA11474 for ; Sat, 5 Apr 1997 02:58:45 +0300 (EET DST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.5/8.8.5) with SMTP id BAA05877; Sat, 5 Apr 1997 01:58:40 +0200 (MET DST) Received: by fiction.pb.owl.de id m0wDIs0-00002eC; Sat, 5 Apr 97 01:58 MET DST Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id IAA02706; Fri, 4 Apr 1997 08:31:52 +0200 From: Nils Bokermann Message-Id: <199704040631.IAA02706@reality.owl.de> Subject: Re: Standard Compatibility [was: Re: New Alpha] In-Reply-To: <3343E042.1C5B384B@sik.de> from Sven Engelhardt at "Apr 3, 97 06:52:18 pm" To: sven@sik.de (Sven Engelhardt) Date: Fri, 4 Apr 1997 08:31:51 +0200 (MET DST) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > Phil Nelson wrote: > > > > >So, obviously, gpc needs to support both ways. > > Yes, I agree. When the --borland_pascal switch is set, it should look > > like Borland Pascal! > > Hi Phil and the Rest of the world ... > > Although gpc ain't a commercial product it should be build on wide > acceptance. > (Where else shall all the really good gpc-programs come from?) > In past nobody was interested in any pascal-standards but Borland. > Borland-Pascal IMHO is the standard-pascal anyway. > The probably are hundreds of Borland-Pascal-Users on one or two > other-semi-standard-pascal-with-some-extensions-users. I agree. [...] > gpc really shall default to borland/turbo-pascal behaviour. You could > implement reading ~/.gpcrc to change that. (For ease this could be done > with a shell script) The cause ain't 'standard' performance, as > thousands > of dos-pascal-programs will be ported to linux. However, this may be a > little bit visionary. But we should NOT artificially complicate changes > to gnu pascal. (Vice versa case is an interesting question to discuss > too.) Hi! I don't like the idea of a local (user) configuration file as GPC.CFG or .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler which is a borland like compiler for standard, might there be a compile-time switch? Let's consider something like ./configure --try-to-be-a-borland-compiler or ./configure --use-standard-pascal. Tsch"u"s, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Sat Apr 5 02:35:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA25599 for ; Sat, 5 Apr 1997 02:35:22 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA95828; Sat, 5 Apr 1997 01:39:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55404; Sat, 5 Apr 1997 01:40:27 +0200 Received: from mailhub.aros.net (mailhub.aros.net [207.173.16.17]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA12193 for ; Sat, 5 Apr 1997 02:31:06 +0300 (EET DST) Received: from terra.aros.net (terra.aros.net [207.173.16.10]) by mailhub.aros.net (8.8.5/Unknown) with ESMTP id QAA07731 for ; Fri, 4 Apr 1997 16:30:36 -0700 (MST) Received: from amy (myaddress@dm2-25.slc.aros.net [207.173.25.74]) by terra.aros.net (8.8.5/8.6.12) with SMTP id QAA18429 for ; Fri, 4 Apr 1997 16:30:16 -0700 Message-Id: <1.5.4.32.19970404232837.0067e9dc@aros.net> X-Sender: epic@aros.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 1997 16:28:37 -0700 To: gpc@hut.fi From: Amy Williams Subject: Unsubscribing Status: RO Hi, I've lost the info for unsubscribing, please let me know how to do so. TIA, Amy Williams epic@aros.net http://amys.base.org From gpc-request@santra.hut.fi Fri Apr 4 22:25:52 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA25435 for ; Fri, 4 Apr 1997 22:25:52 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100752; Fri, 4 Apr 1997 21:30:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48516; Fri, 4 Apr 1997 21:31:01 +0200 Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id WAA07979 for ; Fri, 4 Apr 1997 22:25:48 +0300 (EET DST) Received: from spectro.ujf-grenoble.fr (spectro.ujf-grenoble.fr [193.54.234.59]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id VAA11354 for ; Fri, 4 Apr 1997 21:25:47 +0200 (MET DST) Received: from knautie (knautie.ujf-grenoble.fr [193.54.234.27]) by spectro.ujf-grenoble.fr (8.7.6/8.6.9) with SMTP id VAA13953 for ; Fri, 4 Apr 1997 21:32:24 +0200 (METDST) Message-Id: <3345E39A.5016@spectro.ujf-grenoble.fr> Date: Fri, 04 Apr 1997 21:31:06 -0800 From: Maurice Lombardi Reply-To: Maurice.Lombardi@ujf-grenoble.fr Organization: CNRS - Universite Joseph Fourier Grenoble I X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: identifier prefixing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO I am moving from Borland Pascal (which I have used for years) to GNU pascal (DJGPP port) because I have no more hope that they will improve their DOS compiler (to 32bits, optimisation). Many things work fine. I found only one annoying problem: the inexistence of prefixing of identifiers (e.g. unit1.proc1) to avoid name conflicts. This is a very useful feature because it makes units of different origins truly independants. It also allows to redefine locally names of procedure to extend some properties (I used it extensively to redefine procedures of the graph unit to incorporate simultaneous PostScript copy of screen functions: this allows to have either fast, screen only drawing, or slower, with PostScript copy, programs without changing a single line of code of the main program). Do you plan to do this soon, later or never, so that I can make a decision whether I need to rewrite the whole stuff with non conflicting names or wait until you have done it (I am not in a hurry, I can use for some time the Borland compiler). Many thanks anyway for your work: I am no more afraid that Pascal will disappear from the surface of earth due to the financial problems of Borland. -- Maurice Lombardi Maurice.Lombardi@ujf-grenoble.fr Laboratoire de Spectrometrie Physique | Universite Joseph Fourier de Grenoble BP 87 | tel: (33) 04 76 51 47 51 38402 Saint Martin d'Heres Cedex FRANCE | fax: (33) 04 76 51 45 44 From gpc-request@santra.hut.fi Fri Apr 4 21:41:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA25359 for ; Fri, 4 Apr 1997 21:41:05 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82742; Fri, 4 Apr 1997 20:45:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44612; Fri, 4 Apr 1997 20:46:15 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id VAA07527 for ; Fri, 4 Apr 1997 21:40:08 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id UAA12117; Fri, 4 Apr 1997 20:40:23 +0100 Date: Fri, 4 Apr 1997 20:40:22 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Configuration files (was: Standard compatibility) In-Reply-To: <199704041802.UAA25170@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 4 Apr 1997, Peter Gerwinski wrote: > According to Jan-Jaap van der Heijden: > > > > [...] > > > > > 2) GPC doesn't have to be modified to implement the @file trick. This is > > a DOS "feature" to overcome DOS commandline-length limitations. > > > > [...] > > Yes, but this does not work on non-DOS platforms. Hah! , how 'bout this: ------------- ~/.gpcrc ------------------- --borland-pascal --automake ----------------- end --------------------- and: ------------- /usr/bin/bpc ---------------- #! /bin/sh if [ -f ~/.gpcrc ] ; then CFG=`cat ~/.gpcrc` ; fi gpc $CFG $* ------------------ end --------------------- The rest is up to your imagination. Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Sat Apr 5 14:42:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA26779 for ; Sat, 5 Apr 1997 14:42:28 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA102838; Sat, 5 Apr 1997 13:46:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA27310; Sat, 5 Apr 1997 13:47:24 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA18349 for ; Sat, 5 Apr 1997 14:43:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA26721; Sat, 5 Apr 1997 14:37:42 +0200 From: Peter Gerwinski Message-Id: <199704051237.OAA26721@agnes.dida.physik.uni-essen.de> Subject: Re: identifier prefixing To: maurice.lombardi@ujf-grenoble.fr Date: Sat, 5 Apr 1997 14:37:41 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Maurice Lombardi: > > I found only one annoying problem: the inexistence of prefixing of > identifiers (e.g. unit1.proc1) to avoid name conflicts. This is called "qualified identifiers", and it is planned to be implemented soon (together with Extended Pascal's `qualified' Module import and overloading of Procedures/Functions). > It also allows to redefine locally names of procedure to extend > some properties To work around: With GNU Pascal, you can have the source code of everything. It is no problem to rename the routines of Sven's "original" Graph Unit to something like "Graph_InitGraph" (thus emulating the dot by using an underscore) - or to build that additional functionality directly into the Unit you want to improve. > (I used it extensively to redefine procedures > of the graph unit to incorporate simultaneous PostScript copy of screen > functions: this allows to have either fast, screen > only drawing, or slower, with PostScript copy, programs without changing > a single line of code of the main program). Sounds great! How about adding this to the GNU Pascal "contrib" directory? I am sure there are many people (including myself) who would greatly appreciate such a "PostScript Graph Unit". > Do you plan to do this soon, later or never, so that I can make > a decision whether I need to rewrite the whole stuff with non > conflicting names or wait until you have done it (I am not in a hurry, > I can use for some time the Borland compiler). I hope that I can finish this in 1997. > Many thanks anyway for your work: I am no more afraid that > Pascal will disappear from the surface of earth due to the financial > problems of Borland. Thank you! :-) I am doing my best, and so do many people in this list. If you want to join our attempts - for example by contributing useful libraries -, be welcome! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 5 14:42:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA26778 for ; Sat, 5 Apr 1997 14:42:28 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82104; Sat, 5 Apr 1997 13:46:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76714; Sat, 5 Apr 1997 13:47:24 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA16775 for ; Sat, 5 Apr 1997 14:42:46 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA26712; Sat, 5 Apr 1997 14:37:17 +0200 From: Peter Gerwinski Message-Id: <199704051237.OAA26712@agnes.dida.physik.uni-essen.de> Subject: Compile-time switches (was: Standard Compatibility) To: nils@reality.owl.de Date: Sat, 5 Apr 1997 14:37:17 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Nils Bokermann: > > [...] > > I don't like the idea of a local (user) configuration file as GPC.CFG or > .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ./configure --try-to-be-a-borland-compiler or > ./configure --use-standard-pascal. What's wrong about symbolic links `spc', `epc', `bpc' to `gpc' which make GPC strictly comply to Standard Pascal, Extended Pascal, or Borlnand Pascal (by passing the run-time parameters `--standard-pascal' etc.)? A compile-time switch would cause *much* more trouble than that. As I wrote earlier, I have the impression that most people do neither want a strinct ISO Pascal compiler nor a perfect Borland Pascal emulator, but they want an improved compiler with many extensions, BASED ON THEIR FAVOURITE COMPILER. This is * impossible, * but reality. Up to now, the default field width is the only case where Borland and ISO (more exactly: a de-facto standard based on ISO) really contradict. In all other cases Borland Pascal and ISO Pascal can peacefully coexist in one and the same compiler - which has of course to identify the dialect from the context. ONLY such cases with a REAL contradiction can, IMHO, justify a compile-time switch. And even here I am not sure ... Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 5 14:42:25 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA26773 for ; Sat, 5 Apr 1997 14:42:25 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA102830; Sat, 5 Apr 1997 13:46:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76708; Sat, 5 Apr 1997 13:47:21 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA17679 for ; Sat, 5 Apr 1997 14:43:44 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA26730; Sat, 5 Apr 1997 14:38:11 +0200 From: Peter Gerwinski Message-Id: <199704051238.OAA26730@agnes.dida.physik.uni-essen.de> Subject: Re: Unsubscribing To: epic@aros.net Date: Sat, 5 Apr 1997 14:38:11 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Amy Williams: > > I've lost the info for unsubscribing, please let me know how to do so. >From the GPC FAQ: How to post to the mailing list You can send a message to the GPC mailing list by sending email to the list address as if it were a person. How to become a subscriber to the mailing list You can join the mailing list by sending a message to (NOT !) with your request to be added to the list. Maintenance is done by hand, so some delay is possible. How to unsubscribe from the mailing list To leave the mailing list, send a message to . Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 5 19:50:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA27404 for ; Sat, 5 Apr 1997 19:50:22 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76790; Sat, 5 Apr 1997 18:54:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42366; Sat, 5 Apr 1997 18:55:16 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA21208 for ; Sat, 5 Apr 1997 19:51:34 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id SAA04045 (8.7.6/7.5c-FAU); for ; Sat, 5 Apr 1997 18:51:30 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id SAA25746 (SMI-8.6/7.5b-FAU); Sat, 5 Apr 1997 18:51:28 +0200 From: Frank Heckenbach Message-Id: <199704051651.SAA25746@helena.mi.uni-erlangen.de> Date: Sat, 5 Apr 1997 18:51:28 +0200 To: gpc@hut.fi Subject: Re: Configuration files (was: Standard compatibility) Status: RO Peter Gerwinski wrote: > However I have planned to make it possible to put all compiler options > (including `--automake' :) into the source, so you will be able to > compile any Pascal program just with "gpc progname.pas". That would be great! Putting "--automake" into the source seemed strange to me at first sight, but when I think about it, it can be useful for distributing programs. Does this also include the "-o ..." option? In this case, this "problem" would also be solved by putting "{$o destname}" into the main program. BTW: Are compiler options case sensitive? Otherwise there would be a possible confusion with BP's "{$O filename}" for overlays. I also suggest a compiler switch that will always choose the base filename as the destination filename, unless an explicit "-o ..." option is given. Then I could put this switch into a global configuration file/specs/whatever and wouldn't usually have to worry about "-o ..." options. > * I will try to make it possible to pass these command-line options > as compiler directives, e.g. (*$field-widths=12,24,6*). In such a way that they can be changed at any point in the source, like in this (extreme and not very sensible) example: write({$field-widths=0,0,0}a,{$field-widths}b) Perhaps also "--no-field-widths", equivalent to "--field-widths=0,0,0"? The "-O" (optimization) switches could also be useful in the source, like: [some non-time-critical code] {$O2} [very time-critical code] {$O0} [some non-time-critical code] This example also shows that it can be desirable to "push" and "pop" options. It would be better to write e.g. (tentative syntax): [some non-time-critical code] {$BEGIN}{$O2} [very time-critical code] {$END} [some non-time-critical code] Then, after the "{$END}", the options would be like they were before the "{$BEGIN}", and if "-O2" was given from the command line, it would still be on in the last part of the code. In fact, this is a missing feature of BP, and is often solved by workarounds like: {$IFOPT R+}{$DEFINE R}{$ENDIF}{$R-} [...] {$IFDEF R}{$R+}{$ENDIF} This works for a switch with only 2 possible values ({$R+} and {$R-}), but for siwtches like {$field-width=x,y,z}, it's not possible to do it like that, and it's not very nice anyway... So, pushing and popping options would really be a plus. > In fact DJGPP supports symbolic links on DOS. Really? I didn't find an "ln" command on my system. I installed just the necessary DJGPP stuff, do I need some more packages for symlinks? And do symlinks also work for executables, or only for files accessed from within DJGPP programs? Anyway, I don't think this would be a good solution for DOS systems, but as many of you have shown, there are enough ways to supply default switches on any system, with or without an IDE... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sat Apr 5 23:12:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA27589 for ; Sat, 5 Apr 1997 23:12:02 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA102972; Sat, 5 Apr 1997 22:16:04 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40156; Sat, 5 Apr 1997 22:16:53 +0200 Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [149.174.217.134]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA07784 for ; Sat, 5 Apr 1997 23:07:14 +0300 (EET DST) Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id PAA10616; Sat, 5 Apr 1997 15:06:42 -0500 Date: 05 Apr 97 15:05:12 EST From: Berend de Boer <100120.3121@CompuServe.COM> To: "'gpc'" Subject: Re: Standard Compatibility [was: Re: New Alpha] Message-Id: <970405200512_100120.3121_EHU86-2@CompuServe.COM> Status: RO You wrote: >> Because that is how a majority of Pascal compilers do it. > >But the majority is using borland and therefore this behaviour IS >NOT >USUAL for the majority of programmers, source-code-programs etc.pp. >Maybe it is for YOU and YOUR compiler. The majority of Pascal programmers use a Borland product, nobody disagrees about that. However, the majority of programmers are they using Borland or did they use Borland. Wil they prefer Borland compatibility? I don't. gpc isn't developed for the dos platform. Borland excellently fills that need. I want gpc to create truly platform independent programs for my unix machine. Groetjes, Berend. (-: From gpc-request@santra.hut.fi Sun Apr 6 01:31:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA27823 for ; Sun, 6 Apr 1997 01:31:22 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA97350; Sun, 6 Apr 1997 00:35:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40122; Sun, 6 Apr 1997 00:36:12 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA24338 for ; Sun, 6 Apr 1997 01:32:31 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA27775 for gpc@hut.fi; Sun, 6 Apr 1997 01:27:12 +0200 From: Peter Gerwinski Message-Id: <199704052327.BAA27775@agnes.dida.physik.uni-essen.de> Subject: Re: Configuration files (was: Standard compatibility) To: gpc@hut.fi Date: Sun, 6 Apr 1997 01:27:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Does this also include the "-o ..." option? In this case, this "problem" > would also be solved by putting "{$o destname}" into the main program. That's problematic because the `-o' option is handled by the `gpc' driver program, not by the `gpc-cpp' preprocessor or the `gpc1' compiler which read the source. > BTW: Are compiler options case sensitive? Otherwise there would be a possible > confusion with BP's "{$O filename}" for overlays. GPC's compiler options are not intended to be compatible to Borland Pascal's ones (except perhaps the most "basic" ones like $R, $I, $S which are compatible between UCSD and Borland). These options are too system-specific; especially the "overlay" option makes no sense for GPC. But an `o' option (output file name) would crash with `O' (optimization), so these options should be replaced by long names, e.g. (*$output-file-name *) and (*$optimize *). > I also suggest a compiler switch that will always choose the base filename as > the destination filename, unless an explicit "-o ..." option is given. > Then I could put this switch into a global configuration file/specs/whatever > and wouldn't usually have to worry about "-o ..." options. Here I agree. BTW, EMX derives the name of the output file name from that of the first input file name. > In such a way that they can be changed at any point in the source, like in > this (extreme and not very sensible) example: > write({$field-widths=0,0,0}a,{$field-widths}b) This requires additional work due to the method how field widths are handled by the run time system. It would be easier to make the default field widths variables accessible to your program, e.g. if you write Var DefaultIntegerWidth: asmname 'default_int_width' Integer; DefaultRealWidth: asmname 'default_real_width' Integer; DefaultBooleanWidth: asmname 'default_bool_width' Integer; Then you can save their values in local variables and restore them later ... > Perhaps also "--no-field-widths", equivalent to "--field-widths=0,0,0"? Perhaps ... :-/ > The "-O" (optimization) switches could also be useful in the source, like: > > [some non-time-critical code] > > {$O2} > > [very time-critical code] > > {$O0} > > [some non-time-critical code] (* Why don't you want to compile your whole program with -O2? I would not release an unoptimized program as "production version". (I have been doing this long enough with BP now ...) *) > This example also shows that it can be desirable to "push" and "pop" options. > It would be better to write e.g. (tentative syntax): > > [...] > > Then, after the "{$END}", the options would be like they were before the > "{$BEGIN}", and if "-O2" was given from the command line, it would still > be on in the last part of the code. This would be relatively hard to implement. I will not do that in the near future, but I wouldn't mind if somebody else would take care of that. ;-) But we must ensure that this will not break existing features of the preprocessor. Also remember that (*$foo*) can also be written as #foo ... > In fact, this is a missing feature of BP, and is often solved by workarounds > like: > > {$IFOPT R+}{$DEFINE R}{$ENDIF}{$R-} > [...] > {$IFDEF R}{$R+}{$ENDIF} > > This works for a switch with only 2 possible values ({$R+} and {$R-}), but for > siwtches like {$field-width=x,y,z}, it's not possible to do it like that, and > it's not very nice anyway... > So, pushing and popping options would really be a plus. I agree, but see above. > > In fact DJGPP supports symbolic links on DOS. > > Really? I didn't find an "ln" command on my system. Install GNU fileutils 3.13 or later. See the DJGPP FAQ, chapter 22, for more about symbolic links under DOS. > I installed just the > necessary DJGPP stuff, do I need some more packages for symlinks? And do > symlinks also work for executables, or only for files accessed from within > DJGPP programs? Vice versa, they seem to work *only* for executables ... (?) > Anyway, I don't think this would be a good solution for > DOS systems, Why not? It works well for other DJGPP programs. > but as many of you have shown, there are enough ways to supply > default switches on any system, with or without an IDE... Correct. However we must carry those options too far: even experienced users will not like to deal with hundreds of command-line options ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Apr 6 01:31:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA27818 for ; Sun, 6 Apr 1997 01:31:17 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA108096; Sun, 6 Apr 1997 00:35:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68276; Sun, 6 Apr 1997 00:36:07 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA23636 for ; Sun, 6 Apr 1997 01:32:47 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA27784 for gpc@hut.fi; Sun, 6 Apr 1997 01:27:28 +0200 From: Peter Gerwinski Message-Id: <199704052327.BAA27784@agnes.dida.physik.uni-essen.de> Subject: Re: Standard Compatibility [was: Re: New Alpha] To: gpc@hut.fi Date: Sun, 6 Apr 1997 01:27:28 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > > [...] > > gpc isn't developed for the dos platform. GPC has been developped for *all* platforms including DOS. :-) > Borland excellently fills that need. No. Borland *did* excellently fill that need, but there has been no progress in Borland Pascal since BP 7.0 appeared in 1992 - 5 years ago. Borland does not support the DOS platform any more so there *is* need for a better Pascal compiler for DOS which allows to orientate towards Linux, OS/2 and other systems as alternatives to Windows 95. > I want gpc to create truly platform independent programs > for my unix machine. Here we agree completely. (-: Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Mar 26 17:46:49 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA05882 for ; Wed, 26 Mar 1997 17:46:49 +0100 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA93722; Wed, 26 Mar 1997 16:54:19 +0100 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59812; Wed, 26 Mar 1997 16:54:52 +0100 Received: from matuc2.mat.uc.pt (matuc2.mat.uc.pt [192.138.204.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA03452 for ; Wed, 26 Mar 1997 17:37:27 +0200 (EET) Received: by matuc2.mat.uc.pt (5.57/Ultrix3.0-C) id AA06396; Wed, 26 Mar 97 15:36:15 GMT Date: Wed, 26 Mar 97 15:36:15 GMT From: Pedro@mat.uc.pt (Pedro Quaresma) Message-Id: <9703261536.AA06396@matuc2.mat.uc.pt> Received: by centelha.mat.uc.pt.matematica (4.1/SMI-4.1) id AA01070; Wed, 26 Mar 97 15:36:12 GMT To: J.J.vanderHeijden@student.utwente.nl Cc: gpc@hut.fi In-Reply-To: <199703261514.PAA02750@wit381304.student.utwente.nl> (message from Jan-Jaap van der Heijden on Wed, 26 Mar 1997 15:14:58 +0000 (WET)) Subject: Re: Problems with gpc Status: RO Jan-Jaap van der Heijden ======================== >Did you symlink libgpc.so -> libgpc.so.2 (or whatever the exact libname is) ? No I did not, because de instalation did the following symlink libgpc.so.2 -> libgpc.so.2.8 (the actual lib). But... The symlink libgpc.so -> libgpc.so.2 it is the correct setting. Now all is working well. Thank you again for your help. -- At\'e breve =========== Pedro Quaresma de Almeida Departamento de Matem\'atica Faculdade de Ci\^encias e Tecnologia Universidade de Coimbra P-3000 COIMBRA, PORTUGAL e-mail: pedro@mat.uc.pt url: http://www.mat.uc.pt/~pedro/ From gpc-request@santra.hut.fi Sun Apr 6 04:58:39 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA27987 for ; Sun, 6 Apr 1997 04:58:39 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA108074; Sun, 6 Apr 1997 04:02:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76568; Sun, 6 Apr 1997 04:03:27 +0200 Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id FAA25840 for ; Sun, 6 Apr 1997 05:00:01 +0300 (EET DST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.5/8.8.5) with SMTP id DAA18923; Sun, 6 Apr 1997 03:59:56 +0200 (MET DST) Received: by fiction.pb.owl.de id m0wDhEZ-00002fC; Sun, 6 Apr 97 03:59 MET DST Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id LAA00143; Sat, 5 Apr 1997 11:48:21 GMT From: Nils Bokermann Message-Id: <199704051148.LAA00143@reality.owl.de> Subject: Re: Feature-Control (Was: Re: New Alpha) In-Reply-To: from The African Chief at "Apr 4, 97 11:15:26 am" To: laa12@cc.keele.ac.uk (The African Chief) Date: Sat, 5 Apr 1997 11:48:20 +0000 (GMT) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > On Thu, 3 Apr 1997 08:46:55 +0200 (MET DST) Nils Bokermann > wrote: > [...] > >>In case you haven't done this, can you > >> introduce a .CFG file (like with Borland) where one can > >> put all the command line switches that they want to use? > >> The compiler will read the .CFG file before doing anything > >> else, and will adjust its behaviour accordingly. I personally > >> prefer this approach to using environment variables or the > >> such. You can make many sample .CFG files > >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people > >> can then rename to GPC.CFG or whatever. > > > >Oh, No! Please don't. > >Why don't we handle this like it is used in the common place way at unixish > >Systems: Take a Makefile and put a line PFLAGS (is this right?) in it. There > >you have all your flags, you think you need. Let's say there is a [Makefiles...] > > Makefiles are probably wonderful. However, I don't know > much about them - and I am sure that many people from a BP > or Delphi background are in the same boat. I am puzzled > however as to what is so bad about using a .CFG file. Can > you please say what your objection is? > [...] > > Any comments? Ok, I can imagine that Makefiles are a bit complicatet... As there a _too_ many programs which put there .foobar-File to my home-directory I don't like the *.CFG or .foobarrc idea. If gpc whould be as kind as it should, there should be a system-wide rc-file (That's ok to me) and there _might_ be a users rc-file. But the user has to make it _manually_. But GPC should _not_ rely on the system-wide rc-file, so that I (for my system) can remove it an GPC does run. The system-wide file should IMHO also be installed manually (By the Sysadmin of course). What about that way? Tsch"u"s, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Sun Apr 6 04:58:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA27983 for ; Sun, 6 Apr 1997 04:58:27 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82884; Sun, 6 Apr 1997 04:02:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA22286; Sun, 6 Apr 1997 04:03:15 +0200 Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id EAA24591 for ; Sun, 6 Apr 1997 04:59:56 +0300 (EET DST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.5/8.8.5) with SMTP id DAA18919; Sun, 6 Apr 1997 03:59:54 +0200 (MET DST) Received: by fiction.pb.owl.de id m0wDhEY-00002eC; Sun, 6 Apr 97 03:59 MET DST Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id LAA32060; Sat, 5 Apr 1997 11:38:20 GMT From: Nils Bokermann Message-Id: <199704051138.LAA32060@reality.owl.de> Subject: Re: Standard Compatibility [was: Re: New Alpha] In-Reply-To: <199704041043.MAA21882@helena.mi.uni-erlangen.de> from Frank Heckenbach at "Apr 4, 97 12:43:21 pm" To: heckenb@mi.uni-erlangen.de (Frank Heckenbach) Date: Sat, 5 Apr 1997 11:38:19 +0000 (GMT) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > - Naming the program gpc, spc, epc and bpc seems like a sensible way for > Un*x, but on systems that don't support either hard or symbolic links > (aka DOS), it would mean 4 separate binaries - probably not a good solution > there (although those DOS users who want to do only Borland style could > rename gpc.exe to bpc.exe). So this could be one, but not the only, way to > choose the defaults. Isn't there a way by making *.BAT-Files in dos? That is something like a shell-script, isn't it? Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Sun Apr 6 04:11:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA27953 for ; Sun, 6 Apr 1997 04:11:34 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA105490; Sun, 6 Apr 1997 03:15:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69698; Sun, 6 Apr 1997 03:16:22 +0200 Received: from idecnet.com (root@idecnet.com [194.179.48.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id EAA20403 for ; Sun, 6 Apr 1997 04:12:23 +0300 (EET DST) Received: from MicroMAT (rvr@sun.idecnet.com [194.179.48.66]) by idecnet.com (8.7.5/8.6.9) with SMTP id CAA27798 for ; Sun, 6 Apr 1997 02:12:09 +0100 Date: Sun, 6 Apr 1997 02:16:13 +0000 (GMT) From: "Victor R. Ruiz" X-Sender: rvr@MicroMAT To: gpc@hut.fi Subject: Re: Standard Compatibility [was: Re: New Alpha] In-Reply-To: <199704052327.BAA27784@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 6 Apr 1997, Peter Gerwinski wrote: Hi: > > gpc isn't developed for the dos platform. > GPC has been developped for *all* platforms including DOS. :-) > > Borland excellently fills that need. > > I want gpc to create truly platform independent programs > > for my unix machine. I'm a developer moving from Turbo Pascal to Delphi. I think the main goal of a pascal compiler for non-DOS is to port some of the hughe amount of software that is "out-there". Think about the ten of thousands of programmers that you could say "hey, why you don't get your programms and recompile it for Linux?". ISO standards are very well, but the meter is an international unit of mesure not followed in US and UK and it seems there is no problem about that. My wish is to have an option in gpc that, with the proper units, could compile directly my tens of TP programs. Of course, I'm not expecting the other Pascal versions should disappear!! I think if I have to rebuild the source, better on java; maybe that's not your case but mine. Happy typing! :) (And sorry about my poor english) --------------------------------------------- Victor R. Ruiz rvr@idecnet.com Agrupacion Astronomica de Gran Canaria Sociedad de Meteoros y Cometas de Espa~a http://ccdis.dis.ulpgc.es:8086/AAGC/aagc.html --------------------------------------------- From gpc-request@santra.hut.fi Mon Apr 7 00:46:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA29427 for ; Mon, 7 Apr 1997 00:46:08 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA105698; Sun, 6 Apr 1997 23:49:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19876; Sun, 6 Apr 1997 23:50:41 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA08843 for ; Mon, 7 Apr 1997 00:45:17 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA29404; Mon, 7 Apr 1997 00:40:09 +0200 From: Peter Gerwinski Message-Id: <199704062240.AAA29404@agnes.dida.physik.uni-essen.de> Subject: DOS batch files (was: Standard Compatibility) To: nilsb@reality.owl.de, gpc@hut.fi Date: Mon, 7 Apr 1997 00:40:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Nils Bokermann wrote: > > Isn't there a way by making *.BAT-Files in dos? That is something like a > shell-script, isn't it? Yes. bpc.bat: @gpc -g -O2 --borland-pascal --automake="-g -O2 --borland-pascal" %1.pas -o %1.exe %2 %3 %4 %5 %6 %7 %8 %9 The `@' means "don't echo this command to the screen". AFAIK, there are no `\' signs in DOS to break long lines. The "%2 %3 %4 ..." are there to pass additional command-line parameters given to `bpc.bat' to `gpc'. Problem with such batch files: These will easily bump against the 128-character limitation of command-lines under DOS ... :-( Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Apr 7 03:00:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA29584 for ; Mon, 7 Apr 1997 03:00:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96690; Mon, 7 Apr 1997 02:03:53 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56384; Mon, 7 Apr 1997 02:04:45 +0200 Received: from teamware.sik.de (qmailr@teamware.sik.de [194.162.196.1]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA11880 for ; Mon, 7 Apr 1997 02:59:52 +0300 (EET DST) Received: (qmail 16214 invoked from smtpd); 7 Apr 1997 00:00:22 -0000 Received: from sven1.intern.dd.sik.de (HELO sven1) (root@194.162.196.18) by teamware.sik.de with SMTP; 7 Apr 1997 00:00:22 -0000 Sender: root@santra.hut.fi Message-Id: <334838A2.5287C0BD@sik.de> Date: Mon, 07 Apr 1997 01:58:26 +0200 From: Sven Engelhardt Organization: Nacamar Sachsen X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.0.29 i586) Mime-Version: 1.0 To: gpc@hut.fi Subject: [BUG] GPC - a char killer? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hallo dear Hackers, hi Peter, I found a bug in GPC (my version: 970401/linux/i586)? I wrote the following little program: { -- the buggy program - see below ----------------} {Warning getchar may be implemented as a macro to getc(stdin), so this may be, this will not work for you } program test1(input,output); function getchar:integer; C; var k:integer; begin k:=getchar; while (k<>-1) do begin writeln(k); k:=getchar; end; end. {--- The same as C-Source -- works ok. ---} #include void main() { int k; k=getchar; while (k!=-1) { printf("%i\n",k); k=getchar; } } { --------------------------------------- } Ok. Compiling test1.pas - no errors. Running test1 Enter an 'N' press return you will see '78 10' - thats right. Now the following: echo "N">data test1 ; Mon, 7 Apr 1997 03:39:07 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100336; Mon, 7 Apr 1997 02:42:45 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72222; Mon, 7 Apr 1997 02:43:36 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA12520 for ; Mon, 7 Apr 1997 03:40:08 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA29631 for gpc@hut.fi; Mon, 7 Apr 1997 03:35:10 +0200 From: Peter Gerwinski Message-Id: <199704070135.DAA29631@agnes.dida.physik.uni-essen.de> Subject: How should a make-time field width option look like? To: gpc@hut.fi Date: Mon, 7 Apr 1997 03:35:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello everybody, I just had a look at the GPC configuration scripts and makefiles in order to implement the compile-time `--field-widths' option. It makes trouble. * GPC's configuration scripts are written using `autoconf'. I have no idea how to implement such an option there. But even if I had, it would disappear again when GPC will be integrated into the main distribution line of the GNU compiler. * It is easier to implement an option to `make' rather than to `configure': With small changes to `rts/rts.h' I can provide the following: make CFLAGS="-O2 -D INT_OUT_WIDTH=12 -D REAL_OUT_WIDTH=24" install Alternatively, you can edit the Makefile to pass these definitions. Would this be enough? It doesn't look too nice for me. And: This might also cause trouble when GPC will be integrated into the GCC main distribution line because the other compilers will see those `-D's, too: make LANGUAGES="c,c++,pascal" \ CFLAGS="-O2 -D INT_OUT_WIDTH=12 -D REAL_OUT_WIDTH=24" install * We already had some discussions about configuration files. I am just adding a "*gpc1:" line to the `specs' file Jan-Jaap wrote about. Below the "*gpc1:" there are two empty lines. Whatever you write there will be passed to the GNU Pascal compiler as additional command-line options, for instance *gpc1: -ffield-widths=10,25,7 Note that `--foo' switches are not supported; you have to specify them as `-ffoo'. Similarly, `--pedantic' must be `-pedantic' (*not* `-fpedantic'). The default contents of this `specs' line can be specified at make-time either using make CFLAGS="-O2 -D GPC1_SPEC=\\\"--field-widths=10,25,7\\\"" install or by editing the Makefile. But when looking at those triple backslashes it seems more comfortable for me to edit `specs' after having installed GPC. The run-time `--field-widths' switch ("run-time" means: when you compile a program by running GPC), in contrast, does not seem to cause major problems. There will be no variables like "default_int_width" like I wrote about on 5 Apr. Such variables would require the compiler switch (*$field-widths*) to produce executable code - which is not its purpose. But the switch will act as a local switch (as promised). Please let me know your suggestions about that global compile-time configuration problem. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Apr 7 15:45:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA30957 for ; Mon, 7 Apr 1997 15:45:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100732; Mon, 7 Apr 1997 14:48:44 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA53398; Mon, 7 Apr 1997 14:49:33 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA12453 for ; Mon, 7 Apr 1997 15:44:00 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA27020 (8.7.6/7.5c-FAU); for ; Mon, 7 Apr 1997 14:43:48 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id OAA00948 (SMI-8.6/7.5b-FAU); Mon, 7 Apr 1997 14:43:47 +0200 From: Frank Heckenbach Message-Id: <199704071243.OAA00948@helena.mi.uni-erlangen.de> Date: Mon, 7 Apr 1997 14:43:46 +0200 To: gpc@hut.fi Subject: Re: Standard Compatibility [was: Re: New Alpha] Status: RO Nils Bokermann wrote: > I don't like the idea of a local (user) configuration file as GPC.CFG or > .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ./configure --try-to-be-a-borland-compiler or > ./configure --use-standard-pascal. I think, hardcoded options would be about the worst solution. Besides the reasons given by Jan-Jaap and Peter, consider compilers on multi-user systems. If e.g. in a school or university, different teachers used different language standards, their classes would need different compilers... :-( Personally, I think options that describe the source (e.g. language dialect, extended syntax, field widths) should be put into the source. Other people don't seem to like this idea, but anyway, there will be enough ways by using config files, aliases, scripts and/or environment variables, that should all be possible (more or less easy) on any system. > > - Naming the program gpc, spc, epc and bpc seems like a sensible way for > > Un*x, but on systems that don't support either hard or symbolic links > > (aka DOS), it would mean 4 separate binaries - probably not a good solution > > there (although those DOS users who want to do only Borland style could > > rename gpc.exe to bpc.exe). So this could be one, but not the only, way to > > choose the defaults. > > Isn't there a way by making *.BAT-Files in dos? That is something like a > shell-script, isn't it? Yes, that's right. Also, modern DOSes have something like aliases. Though they're not the same as symlinks, they can be used for this purpose. > Ok, I can imagine that Makefiles are a bit complicatet... And (hopefully) unnecessary for Pascal... :-) > As there a _too_ many programs which put there .foobar-File to my > home-directory I don't like the *.CFG or .foobarrc idea. If gpc whould be as > kind as it should, there should be a system-wide rc-file (That's ok to me) and > there _might_ be a users rc-file. But the user has to make it _manually_. I agree. I also don't like yet another config file in the home directory. > But GPC should _not_ rely on the system-wide rc-file, so that I (for my system) > can remove it an GPC does run. > > The system-wide file should IMHO also be installed manually (By the Sysadmin of > course). Also agreed, since on big sites, a global config file wouldn't make much sense anyway, since different users would want different preferences. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Apr 7 15:29:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA30916 for ; Mon, 7 Apr 1997 15:29:06 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100264; Mon, 7 Apr 1997 14:32:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82242; Mon, 7 Apr 1997 14:33:28 +0200 Received: from concave.cs.wits.ac.za (concave.cs.wits.ac.za [146.141.27.66]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA10650 for ; Mon, 7 Apr 1997 15:24:52 +0300 (EET DST) Received: from voyager.cs.wits.ac.za by concave.cs.wits.ac.za via ESMTP (8.8.3/940406.SGI) for <@concave.cs.wits.ac.za:gpc@hut.fi> id OAA01734; Mon, 7 Apr 1997 14:20:52 +0200 (SAT) Received: from localhost by voyager.cs.wits.ac.za via SMTP (8.8.3/940406.SGI) for id OAA11138; Mon, 7 Apr 1997 14:20:49 +0200 (SAT) Date: Mon, 7 Apr 1997 14:20:49 +0200 (SAT) From: Berend De Schouwer To: gpc@hut.fi Subject: Binary files. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi Sorry if this was handled in a FAQ, but I haven't found it. I'd like to read bytes from a file, so I looked at some of the examples. I found an assign(file of byte...). Cool. It doesn't seem to work to great tho... How big does it read? Are you sure its just 1 byte? How big is a byte anyway? Looking at the examples and the info file, I get confused. Is an integer 16bit or 32bit? What happens with type byte=0..255; I tried defining them like in the info file (using __short__, etc.) but it doesn't compile. When I use the example's stuff it does compile. Hmmm... I am converting some stuff from borland, and some from fpk, so I would like to know how to get 8, 16 and 32 bit signed and unsinged integers. I don't mind doing a search/replace on the source, but I do need to know how big each thing is. AND how to apply them properly to files ;) Cheers Berend. From gpc-request@santra.hut.fi Mon Apr 7 12:10:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA30700 for ; Mon, 7 Apr 1997 12:10:11 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82102; Mon, 7 Apr 1997 11:13:45 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36406; Mon, 7 Apr 1997 11:14:37 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA29667 for ; Mon, 7 Apr 1997 12:07:55 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id LAA00323 for ; Mon, 7 Apr 1997 11:08:09 +0100 Date: Mon, 7 Apr 1997 11:08:08 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: DejaGnu anybody? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello all, I've inserted hooks in the GPC Makefiles for a DejaGnu based compiler testsuite, like other GNU software (gcc, gdb etc.) has. The testsuite itself has to be written though. It would have to cover all language constructions (which are expected to pass) and a number of tests which the compiler should reject (because they are invalid Pascal). There's just one problem: I have never set up an autmated testsuite and I have virtually no experience with DejaGnu. So: Is there anybody out there who has worked with dejagnu and can give me some help? Also, how do I set up such a testsuite? Take the ISO spec and start writing small programs for every paragraph of chapter 6 in the ref? Right now I have one program that passes ("Hello world") and one broken program which fails (as expected) ... Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Mon Apr 7 12:03:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA30676 for ; Mon, 7 Apr 1997 12:03:15 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA108176; Mon, 7 Apr 1997 11:06:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70176; Mon, 7 Apr 1997 11:07:41 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id LAA29110 for ; Mon, 7 Apr 1997 11:59:01 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id KAA00287; Mon, 7 Apr 1997 10:59:09 +0100 Date: Mon, 7 Apr 1997 10:59:08 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: How should a make-time field width option look like? In-Reply-To: <199704070135.DAA29631@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 7 Apr 1997, Peter Gerwinski wrote: > Hello everybody, > > I just had a look at the GPC configuration scripts and makefiles > in order to implement the compile-time `--field-widths' option. > > It makes trouble. > > * GPC's configuration scripts are written using `autoconf'. > I have no idea how to implement such an option there. But even if I'll check this out. So, you want to add optional switches "INT_OUT_WIDTH" and "REAL_OUT_WIDTH", right? Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming] From gpc-request@santra.hut.fi Mon Apr 7 10:09:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA30535 for ; Mon, 7 Apr 1997 10:09:49 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82742; Mon, 7 Apr 1997 09:13:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76388; Mon, 7 Apr 1997 09:14:12 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id KAA21012 for ; Mon, 7 Apr 1997 10:03:16 +0300 (EET DST) Received: from alpha.hut.fi (jtv@alpha.hut.fi [130.233.224.50]) by vipunen.hut.fi (8.8.5/8.8.2) with SMTP id KAA138876; Mon, 7 Apr 1997 10:03:11 +0300 Date: Mon, 7 Apr 1997 10:03:11 +0300 (EET DST) From: Jukka Virtanen To: Amy Williams Cc: gpc@hut.fi Subject: Re: Unsubscribing In-Reply-To: <1.5.4.32.19970404232837.0067e9dc@aros.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 4 Apr 1997, Amy Williams wrote: > Hi, > > I've lost the info for unsubscribing, please let me know how to do so. > I removed you from the list. Juki jtv@hut.fi From gpc-request@santra.hut.fi Mon Apr 7 15:56:58 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA30995 for ; Mon, 7 Apr 1997 15:56:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA107762; Mon, 7 Apr 1997 15:00:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73040; Mon, 7 Apr 1997 15:01:19 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA11054 for ; Mon, 7 Apr 1997 15:44:22 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA27030 (8.7.6/7.5c-FAU); for ; Mon, 7 Apr 1997 14:44:10 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id OAA00951 (SMI-8.6/7.5b-FAU); Mon, 7 Apr 1997 14:44:09 +0200 From: Frank Heckenbach Message-Id: <199704071244.OAA00951@helena.mi.uni-erlangen.de> Date: Mon, 7 Apr 1997 14:44:07 +0200 To: gpc@hut.fi Subject: Re: Configuration files (was: Standard compatibility) Status: RO Peter Gerwinski wrote: > > Does this also include the "-o ..." option? In this case, this "problem" > > would also be solved by putting "{$o destname}" into the main program. > > That's problematic because the `-o' option is handled by the `gpc' driver > program, not by the `gpc-cpp' preprocessor or the `gpc1' compiler which > read the source. So, if it get this right, one needs a way to pass data (in this case, strings) back from a child process to the parent process. I don't know very much about the available means of process communication, but isn't there any (portable) way to do so? Perhaps a temp file, or can it be done easier? > > BTW: Are compiler options case sensitive? Otherwise there would be a possible > > confusion with BP's "{$O filename}" for overlays. > > GPC's compiler options are not intended to be compatible to Borland > Pascal's ones (except perhaps the most "basic" ones like $R, $I, $S > which are compatible between UCSD and Borland). These options are > too system-specific; especially the "overlay" option makes no sense > for GPC. I didn't expect them to be compatible. Of course, that wouldn't make much sense. But it might be better to avoid name clashes, so that ported BP programs woudln't accidentally acces gpc options (e.g. a BP program foo that declares an overlay {$O bar} should not be compiled to bar with gpc (if {$O ...} would be implemented). > But an `o' option (output file name) would crash with `O' > (optimization), so these options should be replaced by long names, > e.g. (*$output-file-name *) and (*$optimize *). If every option (except those like $R,$I,$S,$Q(?) that would be the same like BP's) would be at least 2 letters, this would avoid name clashes. > Here I agree. BTW, EMX derives the name of the output file name from > that of the first input file name. Fine for EMX users... BTW: The first input file name sounds a bit strange to me. Rather, it should be the main program, I think. But it's probably not so easy to implement. > > In such a way that they can be changed at any point in the source, like in > > this (extreme and not very sensible) example: > > write({$field-widths=0,0,0}a,{$field-widths}b) > > This requires additional work due to the method how field widths are > handled by the run time system. It would be easier to make the default > field widths variables accessible to your program, e.g. if you write > > Var > DefaultIntegerWidth: asmname 'default_int_width' Integer; > DefaultRealWidth: asmname 'default_real_width' Integer; > DefaultBooleanWidth: asmname 'default_bool_width' Integer; > > Then you can save their values in local variables and restore them > later ... I don't know how field widths are handled, but I would suppose (and I think that's how BP does it) that the compiler would pass the given field width, or if omitted, the (current) default field width to the write routine. >From this, I would think that default fields widths don't need to be runtime variables, only internal variables of the compiler. > (* Why don't you want to compile your whole program with -O2? Because it's quite slow! Sorry to say that, but gpc is not so fast that I can neglect this issue completely, being a poor 486 user... > I would not release an unoptimized program as "production version". No, but I'm writing programs mostly for my own use, that I have to compile often (and therefore fast), and that have to run fast (but this always concerns only quite small portions os the code). In 5-10 years, this will not be an issue any more, but for now... Anyway, this was only an example, compiler options in the source and local options would be a plus anyway. > > This example also shows that it can be desirable to "push" and "pop" options. > > It would be better to write e.g. (tentative syntax): > > [...] > This would be relatively hard to implement. I will not do that in > the near future, but I wouldn't mind if somebody else would take care > of that. ;-) But we must ensure that this will not break existing > features of the preprocessor. Also remember that (*$foo*) can also be > written as #foo ... I'm not sure what this has got to do with it. Anyway, I think the biggest problem would be to collect all the options into one record (which might be quite hard if they're scattered among many modules now). Then, pushing and popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > I installed just the > > necessary DJGPP stuff, do I need some more packages for symlinks? And do > > symlinks also work for executables, or only for files accessed from within > > DJGPP programs? > > Vice versa, they seem to work *only* for executables ... (?) Oh, I see, you mean the stubs. I thought you were talking about "real" symlinks, like e.g. symlinks with Linux' UMSDOS file system that don't really fit to DOS. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Apr 7 17:19:46 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA31211 for ; Mon, 7 Apr 1997 17:19:46 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA100154; Mon, 7 Apr 1997 16:23:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43922; Mon, 7 Apr 1997 16:24:06 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA18102 for ; Mon, 7 Apr 1997 17:12:45 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA31165; Mon, 7 Apr 1997 17:06:36 +0200 From: Peter Gerwinski Message-Id: <199704071506.RAA31165@agnes.dida.physik.uni-essen.de> Subject: Re: Binary files. To: bdeschou@voyager.cs.wits.ac.za Date: Mon, 7 Apr 1997 17:06:36 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend De Schouwer: > > I'd like to read bytes from a file, so I looked at some of the examples. > I found an assign(file of byte...). Cool. It doesn't seem to > work to great tho... How big does it read? Are you sure its just 1 byte? Yes. See below for an example program which I just tested to work - with the alpha version gpc-970401. > How big is a byte anyway? 8 bits. :-) > Looking at the examples and the info file, > I get confused. Is an integer 16bit or 32bit? 32. > What happens with > type byte=0..255; It will take 4 bytes. :-( Sorry - this is a known bug. > I tried defining them like in the info file (using > __short__, etc.) but it doesn't compile. When I use the example's stuff > it does compile. See below for something which does compile. > Hmmm... I am converting some stuff from borland, and some from fpk, > so I would like to know how to get 8, 16 and 32 bit signed and unsinged > integers. I don't mind doing a search/replace on the source, but I do > need to know how big each thing is. The alpha version gpc-970401 has the following built-in types: Byte unsigned 8 bits ByteInt signed 8 bits ShortWord unsigned 16 bits ShortInt signed 16 bits Word unsigned 32 bits Integer signed 32 bits LongWord unsigned 64 bits LongInt signed 64 bits Single = ShortReal 32 Bits Double = Real 64 Bits Extended = LongReal 80 Bits on the PC, maybe 128 elsewhere However there is one known problem with these types: You cannot `write' or `writeln' them to text file. (Binary files are okay.) If you writeln ( a [ 7 ] ); with `a' being an array of bytes, you might get some very strange result because `writeln' outputs the integer consisting of `a [ 7 ]' and the following three bytes. To work around, cast these types to their base type: writeln ( Integer ( a [ 7 ] ) ); (The same holds for an `Extended' which you must cast to `Real' in order to `writeln' it.) > AND how to apply them properly to files ;) I hope the example below helps you. If you want to upgrade to gpc-970401, the URL is ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- test.pas ------------------------------------------------------------- {OK} (* This program will read its own source and output 'OK'. *) Program Test; Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; ByteFile = file of Byte; Var F: ByteFile; C: Char; Procedure Assign ( Var T: ByteFile; Name: String ); Var B: BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name; bind ( T, B ); B:= binding ( T ); end (* Assign *); begin Assign ( F, 'test.pas' ); reset ( F ); read ( F, C ); read ( F, C ); write ( C ); read ( F, C ); writeln ( C ); close ( F ); end. From gpc-request@santra.hut.fi Mon Apr 7 19:16:46 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA31563 for ; Mon, 7 Apr 1997 19:16:46 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85132; Mon, 7 Apr 1997 18:20:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64280; Mon, 7 Apr 1997 18:21:05 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA23697 for ; Mon, 7 Apr 1997 19:14:10 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA31526 for gpc@hut.fi; Mon, 7 Apr 1997 19:09:22 +0200 From: Peter Gerwinski Message-Id: <199704071709.TAA31526@agnes.dida.physik.uni-essen.de> Subject: Re: Configuration files (was: Standard compatibility) To: gpc@hut.fi Date: Mon, 7 Apr 1997 19:09:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > So, if it get this right, one needs a way to pass data (in this case, strings) > back from a child process to the parent process. I don't know very much about > the available means of process communication, but isn't there any (portable) > way to do so? Perhaps a temp file, or can it be done easier? I am already doing this (in a portable way) for the AutoMake mechanism. There is an "internal" option `--amtmpfile=cc123456.gpc' which passes the name of a file containing the names of the `.o' files to be linked to the `gpc' driver program. > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > BP's) would be at least 2 letters, this would avoid name clashes. Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as a quick way to disable/enable warnings locally. (Sometimes one may want to ignore a certain warning.) To have only (*$no-warnings*) ... (*$warnings*) would be a little drawback ... At least I will make GPC warn about incompatible compiler switches when invoked with `--borland-pascal'. (It already does with `--pedantic.) > BTW: The first input file name sounds a bit strange to me. Rather, it should > be the main program, I think. But it's probably not so easy to implement. That's the reason. This is handled by the `gcc' driver program which does not read the source. But we might be able to solve this with the `--amtmpfile' mechanism ... > I don't know how field widths are handled, but I would suppose (and I think > that's how BP does it) that the compiler would pass the given field width, > or if omitted, the (current) default field width to the write routine. They are handled differently in gpc-970401, but I just wanted to change GPC to use the method above. > [...] > > Anyway, this was only an example, compiler options in the source and local > options would be a plus anyway. I agree. I will look at this. (* I should set up a list of things I wanted to look at. A *long* list. ;*) > I'm not sure what this has got to do with it. Anyway, I think the biggest > problem would be to collect all the options into one record (which might be > quite hard if they're scattered among many modules now). Then, pushing and > popping would reduce to storing/restoring this record to/from a (LIFO) stack. Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an overview. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Apr 8 16:01:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA01016 for ; Tue, 8 Apr 1997 16:01:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA106006; Tue, 8 Apr 1997 15:04:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA18798; Tue, 8 Apr 1997 15:05:46 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA32404 for ; Tue, 8 Apr 1997 15:52:48 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id OAA02178 for ; Tue, 8 Apr 1997 14:53:08 +0100 Date: Tue, 8 Apr 1997 14:53:06 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: GPC fails set comprare Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello, Consider this little program: -------------------------------------------------------------- program main(input,output); var o, z: set of 1..15; begin o := [1]; z := []; if o < z then writeln('o < z'); if o <= z then writeln('o <= z'); if o = z then writeln('o = z'); if o <> z then writeln('o <> z'); if o >= z then writeln('o >= z'); if o > z then writeln('o > z'); if z < o then writeln('z < o'); if z <= o then writeln('z <= o'); if z = o then writeln('z = o'); if z <> o then writeln('z <> o'); if z >= o then writeln('z >= o'); if z > o then writeln('z > o'); if o < o then writeln('o < o'); if o <= o then writeln('o <= o'); if o = o then writeln('o = o'); if o <> o then writeln('o <> o'); if o >= o then writeln('o >= o'); if o > o then writeln('o > o'); if z < z then writeln('z < z'); if z <= z then writeln('z <= z'); if z = z then writeln('z = z'); if z <> z then writeln('z <> z'); if z >= z then writeln('z >= z'); if z > z then writeln('z > z'); end. -------------------------------------------------------------- GPC fails to compile this: t19.p: In function Program_Main': t19.p:7: invalid operands to binary < t19.p:17: invalid operands to binary > t19.p:19: invalid operands to binary < t19.p:29: invalid operands to binary > t19.p:31: invalid operands to binary < t19.p:41: invalid operands to binary > t19.p:43: invalid operands to binary < t19.p:53: invalid operands to binary > ISO 7185 sec. 6.7.1 suggests that this should work. The correct output should be: o <> z o >= z o > z z < o z <= o z <> o o <= o o = o o >= o z <= z z = z z >= z Greetings, JanJaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum From gpc-request@santra.hut.fi Tue Apr 8 19:08:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA01166 for ; Tue, 8 Apr 1997 19:08:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA89970; Tue, 8 Apr 1997 18:11:25 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79458; Tue, 8 Apr 1997 18:12:20 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA20727 for ; Tue, 8 Apr 1997 19:04:45 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Tue, 8 Apr 1997 17:06:11 +0100 Received: from [0.92.146.162] by potter.cc.keele.ac.uk; Tue, 8 Apr 1997 17:04:35 +0100 From: The African Chief To: gpc@hut.fi Subject: BP compatibility Message-Id: Date: Tue, 8 Apr 1997 17:06:51 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Hi all! Here are some more suggestions on Borland compatibility. The following code does not compile in GPC; Program Blah; type pChar = CString; { or ^Char} Procedure DoThis(aThis : pChar); Begin {blah, blah}; End; Begin DoThis ('This is the day!'); End. The compiler does not accept the parameter as being valid (you have to declare a pChar variable and all). This code would compile under Borland. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Wed Apr 9 16:33:48 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA03122 for ; Wed, 9 Apr 1997 16:33:48 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA105922; Wed, 9 Apr 1997 15:36:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67690; Wed, 9 Apr 1997 15:37:22 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA31313 for ; Wed, 9 Apr 1997 16:24:15 +0300 (EET DST) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id PAA96002 for ; Wed, 9 Apr 1997 15:38:01 +0300 Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA14009 (8.7.6/7.5c-FAU); for ; Wed, 9 Apr 1997 14:37:57 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id OAA00807 (SMI-8.6/7.5b-FAU); Wed, 9 Apr 1997 14:37:56 +0200 From: Frank Heckenbach Message-Id: <199704091237.OAA00807@helena.mi.uni-erlangen.de> Date: Wed, 9 Apr 1997 14:37:55 +0200 To: gpc@hut.fi Subject: Re: Configuration files (was: Standard compatibility) Status: RO Peter Gerwinski wrote: > I am already doing this (in a portable way) for the AutoMake mechanism. > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > the name of a file containing the names of the `.o' files to be linked > to the `gpc' driver program. Sounds good! Is this a way to use compiler options (like -o, -l, .o files, .c files) in the source? > > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > > BP's) would be at least 2 letters, this would avoid name clashes. > > Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as > a quick way to disable/enable warnings locally. (Sometimes one may > want to ignore a certain warning.) To have only (*$no-warnings*) > ... (*$warnings*) would be a little drawback ... No objections from me. BP doesn't have a $W option (except Windoze stack frame for Windoze platform, but I don't care very much about that), and $W for warnings sounds general enough to justify a one-letter switch. > > I'm not sure what this has got to do with it. Anyway, I think the biggest > > problem would be to collect all the options into one record (which might be > > quite hard if they're scattered among many modules now). Then, pushing and > > popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an > overview. Seems like a lot of work... :-( -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 10 01:26:52 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA03811 for ; Thu, 10 Apr 1997 01:26:51 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA107232; Thu, 10 Apr 1997 00:29:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31168; Thu, 10 Apr 1997 00:30:27 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA27037 for ; Thu, 10 Apr 1997 01:26:36 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA03781 for gpc@hut.fi; Thu, 10 Apr 1997 01:22:32 +0200 From: Peter Gerwinski Message-Id: <199704092322.BAA03781@agnes.dida.physik.uni-essen.de> Subject: Compiler switches (was: Configuration files) To: gpc@hut.fi Date: Thu, 10 Apr 1997 01:22:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > Peter Gerwinski wrote: > > I am already doing this (in a portable way) for the AutoMake mechanism. > > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > > the name of a file containing the names of the `.o' files to be linked > > to the `gpc' driver program. > Sounds good! Is this a way to use compiler options (like -o, -l, .o files, > .c files) in the source? Yes, in principle. `.o' files *are* already passed that way. There might be some technical problems when generalizing this, but we will see ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 11 17:43:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA07724 for ; Fri, 11 Apr 1997 17:43:03 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA120766; Fri, 11 Apr 1997 16:45:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17214; Fri, 11 Apr 1997 16:46:07 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA15319 for ; Fri, 11 Apr 1997 17:36:40 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA07673 for gpc@hut.fi; Fri, 11 Apr 1997 17:33:07 +0200 From: Peter Gerwinski Message-Id: <199704111533.RAA07673@agnes.dida.physik.uni-essen.de> Subject: Re: [BUG] GPC - a char killer? To: gpc@hut.fi Date: Fri, 11 Apr 1997 17:33:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Sven Engelhardt: The compiled program "eats up" the first char if standard input is not a terminal. This is because when `Input' is `reset' at startup, the first char is read in to `Input's file buffer variable. If you would `read' the char rather than `getchar'ring it, you would get it. To work around, use the `eoln' function to check whether a char has been read in like this: > program test1(input,output); > > function getchar:integer; C; > > var k:integer; > > begin if not eoln ( Input ) then k:= ord ( Input^ ) else > k:=getchar; > while (k<>-1) do > begin > writeln(k); > k:=getchar; > end; > end. To fix this bug (?) it would be necessary to rewrite parts of the RTS, but I am not sure whether we should do that because I can imagine that GPC's behaviour is as the ISO Standard requires. (But I am not in the position to judge that. ;-) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 12 14:03:10 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA10961 for ; Sat, 12 Apr 1997 14:03:09 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA124252; Sat, 12 Apr 1997 13:04:57 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84408; Sat, 12 Apr 1997 13:05:57 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA02226 for ; Sat, 12 Apr 1997 13:49:52 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id MAA00358; Sat, 12 Apr 1997 12:50:06 +0100 Date: Sat, 12 Apr 1997 12:50:03 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Alan Bailey Cc: gpc@hut.fi Subject: Re: setting up gpc In-Reply-To: <334EBDC3.6164@mw.sisna.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 11 Apr 1997, Alan Bailey wrote: > I've recently downloaded gpc (dos-djgpp) and tried running it. I used > the sample hello world program included. I first tried doing this: > > gpc.exe hello.pas > > But it said it oculdn't open ld.exe or something > "c:/djgpp/bin\ld.exe: cannot open -lgpc: No such file or directory > (ENOENT)" > Note the slashes ^ > They are just fine, that's just djgpp's unix roots showing. > I'm assuming this is the executable you use, but I tried gpc1.exe: > > gpc1.exe hello.pas > > This worked fine, and the output was hello.s, an assembly file. > > that's the current situation, I have a djgpp dir and a gpc dir on my > computer, both with the included binaries and documentations. > This (a djgpp dir and a seperate gpc dir) seems to be the problem here. GPC should be installed in the djgpp directory. What happens now is that the djgpp linker (ld.exe) can't find GPC libraries. > So what's wrong, am I missing a parameter running gpc.exe, or do I need > an assembler after gpc1.exe? > No, `gpc hello.pas' should work. If you want different output than `a.out' or `a.exe' then try: `gpc hello.pas -o hello.exe' > > Mail privately or to the list... Or both ;-) /janjaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum From gpc-request@santra.hut.fi Sat Apr 12 00:39:11 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA09762 for ; Sat, 12 Apr 1997 00:39:10 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA138684; Fri, 11 Apr 1997 23:41:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA91784; Fri, 11 Apr 1997 23:42:07 +0200 Received: from ns2.sisna.com ([206.31.20.1]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA28604 for ; Sat, 12 Apr 1997 00:36:55 +0300 (EET DST) To: gpc@hut.fi Received: from LOCALNAME by ns2.sisna.com Fri Apr 11 16:36:40 1997 Message-Id: <334EBDC3.6164@mw.sisna.com> Date: Fri, 11 Apr 1997 15:40:03 -0700 From: Alan Bailey Reply-To: bailala@mw.sisna.com Organization: --- X-Mailer: Mozilla 3.01 (Win16; I) Mime-Version: 1.0 Subject: setting up gpc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO I've recently downloaded gpc (dos-djgpp) and tried running it. I used the sample hello world program included. I first tried doing this: gpc.exe hello.pas But it said it oculdn't open ld.exe or something "c:/djgpp/bin\ld.exe: cannot open -lgpc: No such file or directory (ENOENT)" Note the slashes ^ I'm assuming this is the executable you use, but I tried gpc1.exe: gpc1.exe hello.pas This worked fine, and the output was hello.s, an assembly file. that's the current situation, I have a djgpp dir and a gpc dir on my computer, both with the included binaries and documentations. So what's wrong, am I missing a parameter running gpc.exe, or do I need an assembler after gpc1.exe? Mail privately or to the list... -- Compliments of: _-_-_-_-_-_-_-_ Alan Bailey mailto:bailala@mw.sisna.com IRC: Abalone Web: http://www.mw.sisna.com/users/bailala/ From gpc-request@santra.hut.fi Sun Apr 13 00:58:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA11742 for ; Sun, 13 Apr 1997 00:58:01 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA125152; Sat, 12 Apr 1997 23:59:38 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA39240; Sun, 13 Apr 1997 00:00:40 +0200 Received: from dub-img-1.compuserve.com (dub-img-1.compuserve.com [149.174.206.131]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA08781 for ; Sun, 13 Apr 1997 00:55:55 +0300 (EET DST) Received: by dub-img-1.compuserve.com (8.6.10/5.950515) id RAA00914; Sat, 12 Apr 1997 17:55:24 -0400 Date: Sat, 12 Apr 1997 17:54:35 -0400 From: Berend de Boer Subject: New Alpha: compiler directives To: "'gpc'" Message-Id: <199704121754_MC2-142A-50D0@compuserve.com> Status: RO You wrote: > (* It seems that GPC will get more options than any other existing Pascal compiler ... :*) Absolutely true :-) But I'm not sure if I like this, but I hasten to add that I don't see a better way. My concern is the following: I've a team of programmers building an extended pascal program. How can I be sure that they don't use some gpc feature? I have the -extended-pascal directive to check if it's Extended Pascal, but how can I check if they use some compiler directive in the source to force the compiler doing something?? This particular directive very probably isn't supported by another Extended Pascal compiler, so I would like to automatically detect and forbid it's use. Let's add another compiler directive to disable compiler directives? :-) Or better maybe: using an ISO form of pascal like standard-pascal or extended-pascal, compiler directives are turned off by default and you explicitly have to enable them? This makes it easier by just compiling the source to see if it is portable. Groetjes, Berend. From gpc-request@santra.hut.fi Sun Apr 13 00:57:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA11738 for ; Sun, 13 Apr 1997 00:57:39 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA125008; Sat, 12 Apr 1997 23:59:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31788; Sun, 13 Apr 1997 00:00:15 +0200 Received: from dub-img-6.compuserve.com (dub-img-6.compuserve.com [149.174.206.136]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA08827 for ; Sun, 13 Apr 1997 00:55:52 +0300 (EET DST) Received: by dub-img-6.compuserve.com (8.6.10/5.950515) id RAA11963; Sat, 12 Apr 1997 17:55:17 -0400 Date: Sat, 12 Apr 1997 17:54:31 -0400 From: Berend de Boer Subject: Re: New Alpha To: "'gpc'" Message-Id: <199704121754_MC2-142A-50CF@compuserve.com> Status: RO You wrote: > * If statements and such now default to short-circuit operations. > This can still be switched to complete evaluation using > `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With > `--standard-pascal' etc., the default becomes complete evaluation > and can be switched to short circuit using `--short-circuit', > (*$B-*), or (*$short-circuit*). > > (It is done this way because the cases where a program relies >on > complete evaluation of Boolean expressions are very rare; functions > with side effects should not occur in such situations anyway because > you cannot rely on the order of evaluation. OTOH, there are *many* > programs which rely on short circuit evaluation.) I like to add that Extended Pascal has the or_else and and_then to force short circuit evalutation. A quite clean solution IMHO. Groetjes, Berend. From gpc-request@santra.hut.fi Sat Apr 12 18:34:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA11346 for ; Sat, 12 Apr 1997 18:34:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA123836; Sat, 12 Apr 1997 17:36:26 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA35814; Sat, 12 Apr 1997 17:37:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id SAA05492 for ; Sat, 12 Apr 1997 18:22:28 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA11316 for gpc@hut.fi; Sat, 12 Apr 1997 18:19:15 +0200 From: Peter Gerwinski Message-Id: <199704121619.SAA11316@agnes.dida.physik.uni-essen.de> Subject: New Alpha To: gpc@hut.fi Date: Sat, 12 Apr 1997 18:19:15 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello folks, here is the next GPC alpha version. It implements most of the field-width options recently discussed, fixes some bugs, etc. In detail: Changes since gpc-970401: * Field widths still default to 0, i.e. no blank is output in front of Integer, Boolean, or negative Real values; one blank is output in front of positive Real values according to ISO. A new option `--field-widths=II,RR,BB' changes the default field widths to the numbers `II' for Integers, `RR' for Reals, and `BB' for Booleans. The arguments may be omitted in whole or in part. Just `--field-widths' yields `--field-widths=11,23,6' which ensures that at least one blank is output in front of positive numbers. `--no-field-widths' means `--field-widths=0,0,0'. The dialect options `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', and `--object-pascal' imply `--field-widths'. * A new command line option `--no-real-blank' switches the blank in front of positive Reals off; `--real-blank' switches it on again. This is useful together with compiler directives in the source (*$see-below *). * To specify default field widths, the strings written for "True" and "False" and similar things while compiling GPC, you can #define the symbols in gpc-defs.h and rts/rts.h, e.g. make CFLAGS="-O2 -DINT_OUT_WIDTH=8 -DFALSE_str=\"FOO\"" A more comfortable solution is being worked on. * String clipping can be switched off with `--no-clip-strings' or on with `--clip-strings'. The default is "on" unless `--borland-pascal' or `--delphi' has been specified. * The GNU compiler's global configuration file `specs' (or `specs.gpc' with DJGPP) now contains a line `*gpc1:' after which you can put your site-wide default switches, e.g. *gpc1: -fextended-pascal -ffield-widths -fno-clip-strings Note that `specs' does not want `--foo' but `-ffoo'. * All command-line `--foobar' flags now can be given as compiler directives. One example: (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*). This is case-insensitive except inside the " ... ". Language dialect switches like `extended-pascal' do not enable or disable keywords, so they do not *exactly* mean the same as if they were given in the command-line. For instance with (*$extended-pascal*), `uses' triggers a warning (but still works), whereas with `--extended-pascal' GPC does not know `uses' at all. * `For' control variables are checked now: With `--standard-pascal' etc. GPC warns about structured variables and variables not in the nearest enclosing declaration scope; with `--borland-pascal' etc. structured variables and global variables are okay, but local variables must still be declared in the nearest scope. Without a dialect switch, GPC only warns if we are `--pedantic'. * Bug fixed: A field width of zero does no longer suppress output (except for Strings where ISO requires it (which can be overridden with `--no-clip-strings' - see above)). * Bug fixed: Writing out Chars no more crashes on FreeBSD. * Bug fixed: Char operators, e.g. comparision, work now. * Bug fixed: RTL dump generation (with option `-dr'; for debugging purposed) works now. * Bug fixed: String value parameters, Conformant arrays (Standard Pascal) and open array parameters (Borland Pascal) are passed correctly now. (Now it is taken into account that their size isn't known.) * GPC now warns about usage of conformant arrays if invoked with `--standard-pascal-level-0', `--borland-pascal', or `--delphi'. * Bug fixed concerning Objects: The implicit `Self' parameter is passed correctly now when calling inherited methods. * Arrays can be initialized with not-absolutly-constant values now. * In ASM statements, tabs and newlines are now inserted automatically between different lines. It was not good that one had to write '... \n\t' in Pascal programs. (It's still allowed with (*$E+*), but you are not *required* to use it in ASM statements any more.) * Bug fixed: Input and output parameter specifications in ASM statements may consist of a single character now. * If statements and such now default to short-circuit operations. This can still be switched to complete evaluation using `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With `--standard-pascal' etc., the default becomes complete evaluation and can be switched to short circuit using `--short-circuit', (*$B-*), or (*$short-circuit*). (It is done this way because the cases where a program relies on complete evaluation of Boolean expressions are very rare; functions with side effects should not occur in such situations anyway because you cannot rely on the order of evaluation. OTOH, there are *many* programs which rely on short circuit evaluation.) * Bugs fixed: GPC now better distinguishes between Integer numbers and Boolean values and also knows about the difference between the pointer value `Nil' and the number `0'. * Bug fixed: Set comparision with `<' and '>' works now. * Arrays of Chars now can be initialized by String constants even without `packed'. With `--standard-pascal' etc., a warning is given. * Bug fixed: Types declared equivalent to `CString' now work like `CString'. In particular, String constants can be given to parameters of such a type. * Like in Borland Pascal, `PChar' is now implemented as an alternative to `CString' as a built-in identifier which can be redefined without warning (just like `CString'). This is switched off with `--standard-pascal' etc. * With (*$X+*) or when GPC is invoked with `--extended-syntax', `CString' (or `PChar') variables can be initialized with String constants, and they can be indexed like other Strings, but starting with 0 instead of 1. This is not affected by the dialect options since ISO Pascal does not define `CString' or `PChar', and Borland Pascal also requires (*$X+*) to allow the above. (And it makes not much sense to combine (*$X+*) with dialect options other than `--borland-pascal' anyway.) Extensions of this type must be explicitly switched on because they conflict with Pascal's type-checking rules, so don't expect the above to become GPC's default behaviour. (This is a different situation than the definition of the data type `CString' itself because `CString' is just a redefinable built-in name for "^Char", but it is a type conflict to index a pointer variable.) * When I wanted to implement an option to enable pointer arithmetics I encountered that it already worked by default due to a bug. :-) Now pointer arithmetics works only with (*$X+*) or `--extended-syntax'. (Like `CString' indexing, this is too dangerous to stay GPC's default behaviour, but it must be explicitly enabled.) * GPC now checks whether the `for' variable is of ordinal type. With (*$X+*) or `--extended-syntax', pointer variables are okay, too. * Set member iteration ("for i in [ 2, 3, 5, 7 ] do ...") is now implemented into GPC. The source - a diff against gpc-970401 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. I thank everybody who reported these bugs, in particular Phil Nelson, Frank Heckenbach, Stephen Lindholm, Abimbola A. Olowofoyeku, and Jan-Jaap van der Heijden. (Again I hope that I didn't forget your contribution.) Jan-Jaap furthermore contributed very useful ideas - besides his own work on GPC. I also thank everybody who took part in the discussion about GPC's default behaviour and helped to clarify what the standard specifications say and what they don't, what is reasonable behaviour of a compiler and what isn't. (* It seems that GPC will get more options than any other existing Pascal compiler ... :*) My special thank goes to Larry Carter for the donation of a licensed copy of Delphi, and to Nick Burrett who did not only report the bug about RTL dump generation, but also fixed it and sent me the patch. Ah - is somebody out there willing to document all this? I wrote several announcements of this type since gpc-2.0, and right now they are the only existing documentation for the new features in GPC. Thanks in advance for your help! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Apr 13 04:55:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA12054 for ; Sun, 13 Apr 1997 04:55:56 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA125044; Sun, 13 Apr 1997 03:57:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73398; Sun, 13 Apr 1997 03:58:29 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id EAA10214 for ; Sun, 13 Apr 1997 04:53:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id EAA12025 for gpc@hut.fi; Sun, 13 Apr 1997 04:50:07 +0200 From: Peter Gerwinski Message-Id: <199704130250.EAA12025@agnes.dida.physik.uni-essen.de> Subject: Re: New Alpha: compiler directives To: gpc@hut.fi Date: Sun, 13 Apr 1997 04:50:06 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > > [...] using an ISO form of pascal like standard-pascal or > extended-pascal, compiler directives are turned off by default and you > explicitly have to enable them? This is the case in some sense: You get warnings when you use compiler directives together with `--standard-pascal', `--extended-pascal', or `--object-pascal'. Use `--pedantic-errors' to turn these warnings into error messages. > My concern is the following: I've a team of programmers building an > extended pascal program. How can I be sure that they don't use some gpc > feature? I have the -extended-pascal directive to check if it's Extended > Pascal, but how can I check if they use some compiler directive in the > source to force the compiler doing something?? How can you check whether they really use the `--extended-pascal' switch? You have to stand behind them and watch what commands they type to compile. What about just saying them that they must not use compiler directives? BTW, the `--pedantic' switch is intended to check whether some code is *completely* portable. With `--pedantic', you get warnings about everything for which a Pascal compiler is known not to accept it. (* Read: You get warnings about just *everything*. :*) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Apr 14 01:40:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA13856 for ; Mon, 14 Apr 1997 01:40:50 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA123634; Mon, 14 Apr 1997 00:42:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA89016; Mon, 14 Apr 1997 00:43:08 +0200 Received: from wit381304.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA25208 for ; Mon, 14 Apr 1997 01:33:22 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id AAA00638 for ; Mon, 14 Apr 1997 00:33:43 +0100 Date: Mon, 14 Apr 1997 00:33:42 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: GPC alpha 970412 win32 binary (cygwin32 b17.1) available. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello, The latest GNU Pascal alpha release is now available for the win32 platform at: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/ Files in this directory: gpc-970412.i486-cygwin32-b17.1.zip Apr.12 snapshot binary of cygwin32 GPC. For a cygwin32-beta17.1 toolchain. devtools.i486-cygwin32-b17.1.zip For those who only want to do Pascal, it's a waist to download a complete toolchain from ftp.cygnus.com. This archive has all the tools (as, ld, libraries) needed to complete GPC. I also included some other tools (rcl etc.) and documentation in .hlp format. If you already have cygwin32-beta17.1 installed, you don't need this. Installation ------------ * create a subdirectory of your choice (`c:\gpcwin32') and unzip gpc-970412.i486-cygwin32-b17.1.zip and devtools.i486-cygwin32-b17.1.zip from there. Use a version of `unzip' that can handle long filenames, i.e. not PKunzip. * Add the directory where `gpc.exe' lives (`c:\gpcwin32\bin') to your path. * Set GCC_EXEC_PREFIX=C:\gpcwin32\lib\gcc-lib\ Beware of the trailing slash! * Set LIBRARY_PATH=c:\gpcwin32\lib;c:\gpcwin32\i386-cygwin32\lib Common problems --------------- These things often give problems: * Do NOT mix binaries from different beta's -- they are incompatible. * Be sure to have only one `cygwin.dll' in your path and it must be beta17.1 The symptoms of these are crashes, stack/register dumps and Windows telling you it cannot load a dll. Read the cygwin32 FAQ (http://www.cygnus.com/ or this directory) Most of the information also applies for GNU Pascal. And please, do not bother the people of the cygwin32 mailinglist if you have problems with GPC, send them to the gpc@hut.fi list instead. Have fun, JanJaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum From gpc-request@santra.hut.fi Wed Apr 16 01:05:44 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA19009 for ; Wed, 16 Apr 1997 01:05:44 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA137748; Wed, 16 Apr 1997 00:06:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51910; Wed, 16 Apr 1997 00:07:24 +0200 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA16925 for ; Wed, 16 Apr 1997 00:59:16 +0300 (EET DST) Received: from default (dy1-09.van.tvs.net [204.244.156.18]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id OAA28724 for ; Tue, 15 Apr 1997 14:53:32 -0700 (PDT) Message-Id: <3.0.1.32.19970415145826.00684a14@cybermail.net> X-Sender: s_c@cybermail.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 15 Apr 1997 14:58:26 -0700 To: gpc@hut.fi From: skye Subject: BP RTL Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO I was wondering if anyone has put together a lib for BP compatibility. A most-commonly-used-functions one? Something? I'm new to GPC and would like to use it for my lessons as well as encorage my students to use it. I've already got them using DJGPP for C/C++. Thanks, -SC From gpc-request@santra.hut.fi Tue Apr 15 19:24:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA18610 for ; Tue, 15 Apr 1997 19:24:26 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA141304; Tue, 15 Apr 1997 18:25:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30954; Tue, 15 Apr 1997 18:26:12 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA07634 for ; Tue, 15 Apr 1997 19:03:37 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Tue, 15 Apr 1997 17:04:43 +0100 Received: from [0.10.131.204] by potter.cc.keele.ac.uk; Tue, 15 Apr 1997 17:02:35 +0100 From: The African Chief To: David Fiddes Cc: gpc@hut.fi Subject: Re: New Alpha Message-Id: Date: Tue, 15 Apr 1997 17:05:17 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Tue, 15 Apr 1997 16:29:10 +0100 David Fiddes wrote: >>I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that >it >>does is to parse the command line, parse the source file to see whether >>it is a unit/module or a program (and pass the necessary "-o" or "-c" >>switch accordingly, read a file called "GPCC.CFG", add any switches >found >>in it to the list of parameters obtained from the command line, and then, >>run "GPC" with the whole list of parameters. >> >I thought that gpc was similar to gcc(I'm not that familiar with gpc -- it >won't build with the cygnus source tree I use)..isn't gpc.exe like gcc.exe >in that it's just a shell for ccp.exe and cc1.exe, as.exe, ld.exe >,etc,etc. I presume that GPC is a shell to GPC1, or GPC-CPP, or, to both of them. I am operating from the point of view of someone from a BP background, who does not understand MAKE files or such, but who is comfortable with the idea of a .CFG file that contains all the parameters you wish to always pass (splitting infinitives here?) to a command line compiler. GPCC (the name is insignificant - perhaps it should be GPCS - for "GPC shell") simply provides this facility. It also served the purpose of presenting me with an opportunity to write GPC implementations of many Borland Pascal runtime library functions. This should increase GPC's "Borland" compatibility. >It would be just as easy to write a whole new gnubpc.exe shell...? It would >be cleaner perhaps... This is really what I am trying to do - but I don't want to make it just a Borland extension shell, so it is just a program that reads a file, parses the command line, and sends everything to GPC.EXE. The implementations of Borland RTL functions are in UNITs, which will be usable by everybody (I hope). Presumably, somebody someday will convert the UNITs to EP modules. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue Apr 15 18:34:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA18583 for ; Tue, 15 Apr 1997 18:34:21 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA124044; Tue, 15 Apr 1997 17:35:01 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA32802; Tue, 15 Apr 1997 17:36:07 +0200 Received: from ma.hw.ac.uk (root@[137.195.21.8]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id SAA05990 for ; Tue, 15 Apr 1997 18:29:56 +0300 (EET DST) Received: from eday.ma.hw.ac.uk by ma.hw.ac.uk (SMI-8.6/SMI-4.1) id QAA19313; Tue, 15 Apr 1997 16:29:11 +0100 Message-Id: <199704151529.QAA19313@ma.hw.ac.uk> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "David Fiddes" To: Subject: Re: New Alpha Date: Tue, 15 Apr 1997 16:29:10 +0100 X-Priority: 3 X-Msmail-Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Status: RO >I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that it >does is to parse the command line, parse the source file to see whether >it is a unit/module or a program (and pass the necessary "-o" or "-c" >switch accordingly, read a file called "GPCC.CFG", add any switches found >in it to the list of parameters obtained from the command line, and then, >run "GPC" with the whole list of parameters. > I thought that gpc was similar to gcc(I'm not that familiar with gpc -- it won't build with the cygnus source tree I use)..isn't gpc.exe like gcc.exe in that it's just a shell for ccp.exe and cc1.exe, as.exe, ld.exe ,etc,etc. It would be just as easy to write a whole new gnubpc.exe shell...? It would be cleaner perhaps... Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes@hw.ac.uk - Tel: 0131-451-3251 From gpc-request@santra.hut.fi Tue Apr 15 17:16:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA18388 for ; Tue, 15 Apr 1997 17:16:04 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA144084; Tue, 15 Apr 1997 16:16:46 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49994; Tue, 15 Apr 1997 16:17:52 +0200 Received: from wit381304.student.utwente.nl (janjaap@[130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA03123 for ; Tue, 15 Apr 1997 17:03:04 +0300 (EET DST) Received: from localhost (janjaap@localhost) by wit381304.student.utwente.nl (8.8.5/8.8.5) with SMTP id QAA00489; Tue, 15 Apr 1997 16:03:19 +0100 Date: Tue, 15 Apr 1997 16:03:17 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Frank Heckenbach Cc: gpc@hut.fi Subject: Re: Main distribution line (Was: How should ...) In-Reply-To: <199704151245.OAA21380@helena.mi.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 15 Apr 1997, Frank Heckenbach wrote: > > This goes back a few days... > > Peter Gerwinski wrote: > > > * GPC's configuration scripts are written using `autoconf'. > > I have no idea how to implement such an option there. But even if > > I had, it would disappear again when GPC will be integrated into > > the main distribution line of the GNU compiler. > > Does this mean that gpc will then distributed widely and will be present on > many (or most) systems? Not automatically. Peter was referring to my work to change to GPC distribution to a model simular to g77 (GNU Fortran). GPC will live in a subdirectory of the main GCC distribution (like g++, objc an g77) and can then be built using `make LANGUAGES="pascal"'. This fase is mostly completed. The benefits of this distribution model are: 1. Less problems configuring GPC for some unix platforms, because GCC does that for us. 2. Easier porting to new versions of GCC (I had little trouble porting GPC to pentium-GCC or a cygnus CDK for instance) (Yes -- then you have a true pentium-optimizing GPC) The next step would be to convince the GNU's to distribute GPC _with_ GCC, but I would not expect that to happen in the near future. > Now I had to make a version of my program in C > because almost nobody had gpc installed - any hope that this situation will > change? And are there any plans when this will happen - when gpc supports the > standard(s) completely? I think you would have to show the importance of Pascal for project GNU to archieve this. A large GPC user community, assurance that GPC development will continue over a long period to come, support for existing standards and proven stability over a wide variety of platforms would probably be another requirement. I think we should get more attention of GNU enthousiasts first (be present on alpha.gnu.mit.edu, maybe a small README in the main GNU distribution sites, get into the GNU bulletin (if you look *real* good in the jan '97 issue, you can find a note saying a new release of gpc after some years of stagnation was made, but I think we deserve some more attention than this) Anybody got some ideas? JanJaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum From gpc-request@santra.hut.fi Tue Apr 15 17:15:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA18382 for ; Tue, 15 Apr 1997 17:15:17 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA143988; Tue, 15 Apr 1997 16:15:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA29154; Tue, 15 Apr 1997 16:17:05 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA03308 for ; Tue, 15 Apr 1997 17:10:55 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Tue, 15 Apr 1997 15:11:58 +0100 Received: from [0.16.34.30] by potter.cc.keele.ac.uk; Tue, 15 Apr 1997 15:09:55 +0100 From: The African Chief To: Frank Heckenbach Cc: gpc@hut.fi Subject: Re: New Alpha Message-Id: Date: Sun, 7 Jul 1996 15:12:35 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Tue, 15 Apr 1997 14:45:40 +0200 Frank Heckenbach wrote: [..] > >A minor "problem": If I compile a program with such a compiler switch with TP, >TP complains about an "Invalid compiler directive". Is there a way (perhaps >a simpler way than conditional defines) to supply the options so that gpc >will recognize them and TP will ignore them? I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that it does is to parse the command line, parse the source file to see whether it is a unit/module or a program (and pass the necessary "-o" or "-c" switch accordingly, read a file called "GPCC.CFG", add any switches found in it to the list of parameters obtained from the command line, and then, run "GPC" with the whole list of parameters. I have had to write a number of "Borland" functions and procedures for GPC to make this program compile and work okay under GPC as well. The program can now be compiled under BP or GPC and works equally well under both. These (with full source code) will be released as soon as I am finished with what I am doing, as part of my contribution to GPC. Is anybody interested in all this? My current GPCC.CFG looks like this (lines beginning with a semi-colon are treated as comments and are ignored by GPCC); ; ---------------------------- GPCC.CFG begins -------------------------- ; full optimization; 486 optimized -O3 -m486 ; strip the symbol table -s ; "make" units --automake="-O3 --automake" ; use extended syntax --extended-syntax ; pack (align) all records --pack-struct ; ---------------------- GPCC.CFG ends --------------------------- I intend to make a number of template GPCC.CFG file (e.g., for EP, ISO, etc.) before releasing the stuff. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue Apr 15 15:56:55 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA18274 for ; Tue, 15 Apr 1997 15:56:54 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA133834; Tue, 15 Apr 1997 14:57:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62666; Tue, 15 Apr 1997 14:58:43 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA30934 for ; Tue, 15 Apr 1997 15:45:48 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA12197 (8.7.6/7.5c-FAU); for ; Tue, 15 Apr 1997 14:45:44 +0200 (MET DST) Received: from telemachos by mi.uni-erlangen.de with SMTP; id OAA21374 (SMI-8.6/7.5b-FAU); Tue, 15 Apr 1997 14:45:41 +0200 From: Frank Heckenbach Message-Id: <199704151245.OAA21374@helena.mi.uni-erlangen.de> Date: Tue, 15 Apr 1997 14:45:40 +0200 To: gpc@hut.fi Subject: Re: New Alpha Status: RO Peter Gerwinski wrote: > * The GNU compiler's global configuration file `specs' (or `specs.gpc' > with DJGPP) now contains a line `*gpc1:' after which you can put > your site-wide default switches, e.g. > > *gpc1: > -fextended-pascal -ffield-widths -fno-clip-strings > Note that `specs' does not want `--foo' but `-ffoo'. BTW: You recently said that one has to use '-pedantic', not '-fpedantic' in specs. Is there a general rule when to use '-f...' and when simply '-...'? > * All command-line `--foobar' flags now can be given as compiler > directives. One example: > > (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*). Just to make sure: 'AutoMake="--foo"' means that '--foo' is used for the compilation of the units involved and the program itself, while 'AutoMake, --foo' would apply '--foo' only to the program. Is that right? A minor "problem": If I compile a program with such a compiler switch with TP, TP complains about an "Invalid compiler directive". Is there a way (perhaps a simpler way than conditional defines) to supply the options so that gpc will recognize them and TP will ignore them? What about compiler options for "-o foo", "foo.o" and/or "bar.c"? Are you working on them, or are they too difficult to implement? BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? I asked about this already in my mail about "Re: Linking directives..." on 3 Apr, but unfortunately got no replies. And another contribution to the GPC test suite... :-| The following program and unit cause the latest gpc to fail with SIGSEGV. It worked with a previous version of gpc: PROGRAM x; USES y; VAR v:t; BEGIN q(v) {or p(v) - both cause SIGSEGV} END. UNIT Y; INTERFACE TYPE t=ARRAY[0..1] OF Integer; PROCEDURE p(VAR v:t); PROCEDURE q(CONST v:t); IMPLEMENTATION PROCEDURE p(VAR v:t); BEGIN END; PROCEDURE q(CONST v:t); BEGIN END; END. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Tue Apr 15 15:53:53 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA18269 for ; Tue, 15 Apr 1997 15:53:53 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08920; Tue, 15 Apr 1997 14:54:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42480; Tue, 15 Apr 1997 14:55:42 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA32155 for ; Tue, 15 Apr 1997 15:46:05 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA12212 (8.7.6/7.5c-FAU); for ; Tue, 15 Apr 1997 14:45:59 +0200 (MET DST) Received: from telemachos by mi.uni-erlangen.de with SMTP; id OAA21380 (SMI-8.6/7.5b-FAU); Tue, 15 Apr 1997 14:45:58 +0200 From: Frank Heckenbach Message-Id: <199704151245.OAA21380@helena.mi.uni-erlangen.de> Date: Tue, 15 Apr 1997 14:45:56 +0200 To: gpc@hut.fi Subject: Main distribution line (Was: How should ...) Status: RO This goes back a few days... Peter Gerwinski wrote: > * GPC's configuration scripts are written using `autoconf'. > I have no idea how to implement such an option there. But even if > I had, it would disappear again when GPC will be integrated into > the main distribution line of the GNU compiler. Does this mean that gpc will then distributed widely and will be present on many (or most) systems? Now I had to make a version of my program in C because almost nobody had gpc installed - any hope that this situation will change? And are there any plans when this will happen - when gpc supports the standard(s) completely? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Tue Apr 15 15:52:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA18265 for ; Tue, 15 Apr 1997 15:52:56 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA139584; Tue, 15 Apr 1997 14:53:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37816; Tue, 15 Apr 1997 14:54:40 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA32150 for ; Tue, 15 Apr 1997 15:45:56 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA12207 (8.7.6/7.5c-FAU); for ; Tue, 15 Apr 1997 14:45:51 +0200 (MET DST) Received: from telemachos by mi.uni-erlangen.de with SMTP; id OAA21377 (SMI-8.6/7.5b-FAU); Tue, 15 Apr 1997 14:45:50 +0200 From: Frank Heckenbach Message-Id: <199704151245.OAA21377@helena.mi.uni-erlangen.de> Date: Tue, 15 Apr 1997 14:45:49 +0200 To: gpc@hut.fi Subject: Boolean operators (Was: Re: New Alpha) Status: RO Berend de Boer wrote: > > * If statements and such now default to short-circuit operations. > > This can still be switched to complete evaluation using > > `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With > > `--standard-pascal' etc., the default becomes complete evaluation > > and can be switched to short circuit using `--short-circuit', > > (*$B-*), or (*$short-circuit*). > > > > (It is done this way because the cases where a program relies > >on > > complete evaluation of Boolean expressions are very rare; functions > > with side effects should not occur in such situations anyway because > > you cannot rely on the order of evaluation. OTOH, there are *many* > > programs which rely on short circuit evaluation.) > > I like to add that Extended Pascal has the or_else and and_then to force > short circuit evalutation. > > A quite clean solution IMHO. Indeed, I think this is good if one uses complete evaluation by default. However, I prefer to have short circuit evaluation by default. So what about similar operators to force complete evaluation - it would seem cleaner to me than using {$B+} ... {$B-}? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Wed Apr 16 17:14:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA20937 for ; Wed, 16 Apr 1997 17:14:33 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA125556; Wed, 16 Apr 1997 16:14:54 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64352; Wed, 16 Apr 1997 16:16:01 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA12272 for ; Wed, 16 Apr 1997 17:04:51 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Wed, 16 Apr 1997 09:59:36 +0100 Received: from [0.5.138.212] by potter.cc.keele.ac.uk; Wed, 16 Apr 1997 09:57:54 +0100 From: The African Chief To: skye Cc: gpc@hut.fi Subject: Re: BP RTL Message-Id: Date: Wed, 16 Apr 1997 10:00:38 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Tue, 15 Apr 1997 14:58:26 -0700 skye wrote: >I was wondering if anyone has put together a lib for BP compatibility. A >most-commonly-used-functions one? Something? I'm new to GPC and would like >to use it for my lessons as well as encorage my students to use it. I've >already got them using DJGPP for C/C++. Peter already has a BPCOMPAT package which implements some of the Borland RTL routines. I myself am implementing some more. Some of this has involved importing some functions from the C library. I am also producing Pascal UNITs for many of the C headers (io.h, stdio.h, stdlib.h, ctype.h, dos.h, dir.h, etc). When all this is finished, it will be released to the GPC community. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Thu Apr 17 00:07:21 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21533 for ; Thu, 17 Apr 1997 00:07:21 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA119528; Wed, 16 Apr 1997 23:07:35 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36060; Wed, 16 Apr 1997 23:08:43 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA24631 for ; Wed, 16 Apr 1997 23:45:47 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA21423 for gpc@hut.fi; Wed, 16 Apr 1997 23:43:54 +0200 From: Peter Gerwinski Message-Id: <199704162143.XAA21423@agnes.dida.physik.uni-essen.de> Subject: Re: New Alpha To: gpc@hut.fi Date: Wed, 16 Apr 1997 23:43:54 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > BTW: You recently said that one has to use '-pedantic', not '-fpedantic' > in specs. Is there a general rule when to use '-f...' and when simply '-...'? AFAIK, the GNU compiler originally accepted only `-ffoo-bar' flags. (The `-f' stands for "flag".) Nowadays, just `--' is okay as an alternative for `-f'. (Note that these long options start with two dashes, not just one.) The `specs' file only understands the old syntax. `--pedantic' is an exception, because it is originally `-pedantic' (with one dash), not `-fpedantic' (i.e. no "flag" in this sense). To get all options, read the (loooooooooooong) section "Invoking GPC" from the info documentation, and pick up the flags not explained there from my "New Alpha" announcements. In the worst case, look at the GPC source file `gpc-options.h' for a list of all `--' (or `-f') options, and see `gpc-decl.c' for what they do. > Just to make sure: 'AutoMake="--foo"' means that '--foo' is used for the > compilation of the units involved and the program itself, while > 'AutoMake, --foo' would apply '--foo' only to the program. Is that right? Almost. Within the directive, `--' (in fact: `-f') is automatically prefixed, so don't give it explicitly. (*$AutoMake="--foo"*) correct; gives `--foo' to the compilation of Units (*$AutoMake="foo"*) wrong; gives `foo' to the compilation of Units (which is nonsense) (*$AutoMake,foo*) correct; gives `--foo' to the current compilation (*$AutoMake,--foo*) wrong; gives `----foo' (in fact: `-f--foo') to the current compilation. > A minor "problem": If I compile a program with such a compiler switch with TP, > TP complains about an "Invalid compiler directive". Is there a way [...] > to supply the options so that gpc will recognize them and TP will ignore > them? Yes, conditional defines. GPC pre-defines the symbol "__GPC__": (*$ifdef __GPC__ *) (* GNU Pascal switches *) (*$no-field-widths *) (*$AutoMake="--foo --bar"*) (*$N+*) (* Nested comments *) (*$E-*) (* No C-style char escapes *) (*$else *) (* Borland Pascal switches *) (*$M 65536 *) (* Stack size *) (*$N+*) (* Numeric coprocessor on *) (*$E-*) (* Don't link the Emulator *) (*$endif *) (* Switches for both compilers *) (*$B-*) (* Short-circuit Boolean operators *) > (perhaps a simpler way than conditional defines) What would you consider "simpler" than this? ;-) > What about compiler options for "-o foo", "foo.o" and/or "bar.c"? Are you > working on them, or are they too difficult to implement? Working on them. I don't expect much trouble from (*$L foo.o *) and (*$L bar.c *), but I am not so sure about "-o foo" ... > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > I asked about this already in my mail about "Re: Linking directives..." on > 3 Apr, but unfortunately got no replies. Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my Linux box, too. (You wrote that it didn't work on yours; perhaps this bug is fixed now?) > And another contribution to the GPC test suite... :-| > > The following program and unit cause the latest gpc to fail with SIGSEGV. > It worked with a previous version of gpc [...] I can reproduce the error. Okay, it will be fixed in the next Alpha. (I hope at least.;) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Apr 17 00:07:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21529 for ; Thu, 17 Apr 1997 00:07:00 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA129138; Wed, 16 Apr 1997 23:07:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36034; Wed, 16 Apr 1997 23:08:22 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA25874 for ; Wed, 16 Apr 1997 23:47:16 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA21448; Wed, 16 Apr 1997 23:45:26 +0200 From: Peter Gerwinski Message-Id: <199704162145.XAA21448@agnes.dida.physik.uni-essen.de> Subject: Re: BP RTL To: gpc@hut.fi, s_c@iname.com Date: Wed, 16 Apr 1997 23:45:26 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to skye: > I was wondering if anyone has put together a lib for BP compatibility. Try the "BPcompat" package, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Apr 17 00:06:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21524 for ; Thu, 17 Apr 1997 00:06:34 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA119458; Wed, 16 Apr 1997 23:06:48 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36002; Wed, 16 Apr 1997 23:07:56 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA20714 for ; Wed, 16 Apr 1997 23:44:27 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA21407 for gpc@hut.fi; Wed, 16 Apr 1997 23:42:36 +0200 From: Peter Gerwinski Message-Id: <199704162142.XAA21407@agnes.dida.physik.uni-essen.de> Subject: Boolean operators (Was: Re: New Alpha) To: gpc@hut.fi Date: Wed, 16 Apr 1997 23:42:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Indeed, I think this is good if one uses complete evaluation by default. > However, I prefer to have short circuit evaluation by default. > So what about similar operators to force complete evaluation - it would seem > cleaner to me than using {$B+} ... {$B-}? ISO Pascal's short circuit operators are "and_then" and "or_else"; GPC also allows "and then" and "or else". Perhaps "or_then" and "and_else" would be their natural counterparts? BTW, can anybody tell me a case where complete evaluation is desirable? IMHO, no reasonable Pascal program should use functions with side-effects in `if' conditions containing `and' because you can never know in which order they are evaluated (except with short-circuit operators, but here we are again). ... Ahhh! 8-) PS: ISO 10206, 6.8.3.1 says: NOTE - This means, for example, that the operands [of ordinary `or' and `and'] may be evaluated in textual order, or in reverse order, or in parallel, or they may not both be evaluated. This means that short circuit operators being the default does not break ISO conformance. Fine. :-) AND it means that if you want to produce portable code you cannot rely on complete evaluation, so be careful. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Apr 17 01:00:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA21621 for ; Thu, 17 Apr 1997 01:00:05 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA120896; Thu, 17 Apr 1997 00:00:18 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA03868; Thu, 17 Apr 1997 00:01:26 +0200 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA25847 for ; Thu, 17 Apr 1997 00:39:01 +0300 (EET DST) Received: from default (dy2-34.van.tvs.net [204.244.156.91]) by mercury.uniserve.com (8.8.2/8.8.2) with SMTP id OAA27553 for ; Wed, 16 Apr 1997 14:33:10 -0700 (PDT) Message-Id: <3.0.1.32.19970416143814.0069cf0c@cybermail.net> X-Sender: s_c@cybermail.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 16 Apr 1997 14:38:14 -0700 To: gpc@hut.fi From: skye Subject: Re: BP RTL In-Reply-To: <199704162145.XAA21448@agnes.dida.physik.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO At 11:45 PM 4/16/97 +0200, you wrote: >According to skye: >> I was wondering if anyone has put together a lib for BP compatibility. [From Peter] >Try the "BPcompat" package, available at > > ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/ > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ > >Hope this helps, > > Peter > [From The Chief] >Peter already has a BPCOMPAT package which implements some of >the Borland RTL routines. I myself am implementing some more. Some >of this has involved importing some functions from the C library. I am >also producing Pascal UNITs for many of the C headers (io.h, stdio.h, >stdlib.h, ctype.h, dos.h, dir.h, etc). When all this is finished, it will be >released to the GPC community. > >Best regards, The Chief Thanks to both of you. I don't know how I missed it. =] -SC From gpc-request@santra.hut.fi Thu Apr 17 11:21:05 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA23052 for ; Thu, 17 Apr 1997 11:21:04 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA111186; Thu, 17 Apr 1997 10:21:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08642; Thu, 17 Apr 1997 10:22:19 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id LAA06524 for ; Thu, 17 Apr 1997 11:17:06 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA23031 for gpc@hut.fi; Thu, 17 Apr 1997 11:15:23 +0200 From: Peter Gerwinski Message-Id: <199704170915.LAA23031@agnes.dida.physik.uni-essen.de> Subject: New Alpha: libgpc.a for DJGPP To: gpc@hut.fi Date: Thu, 17 Apr 1997 11:15:23 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, the runtime library in the DJGPP binary distribution of the last Alpha GPC was bogus. Even `hello.pas' did not work. Sorry for that ... #-) (But the source is okay!) I am updating `gpc-970412.i386-djgppv201.zip' on agnes. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri Apr 18 03:52:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA24851 for ; Fri, 18 Apr 1997 03:52:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA158954; Fri, 18 Apr 1997 02:52:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51548; Fri, 18 Apr 1997 02:53:40 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.1.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA05751 for ; Fri, 18 Apr 1997 03:45:00 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id CAA07930 (8.7.6/7.5c-FAU); for ; Fri, 18 Apr 1997 02:44:56 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id CAA04688 (SMI-8.6/7.5b-FAU); Fri, 18 Apr 1997 02:44:55 +0200 From: Frank Heckenbach Message-Id: <199704180044.CAA04688@helena.mi.uni-erlangen.de> Date: Fri, 18 Apr 1997 02:44:53 +0200 To: gpc@hut.fi Subject: Re: New Alpha Status: RO Peter Gerwinski wrote: > Yes, conditional defines. GPC pre-defines the symbol "__GPC__": > > (*$ifdef __GPC__ *) > (* GNU Pascal switches *) >[...] > (*$else *) > (* Borland Pascal switches *) >[...] > (*$endif *) > > What would you consider "simpler" than this? ;-) OK, if "__GPC__" is predefined, this is viable. I didn't know about this, I tried just "GPC"... > > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > > I asked about this already in my mail about "Re: Linking directives..." on > > 3 Apr, but unfortunately got no replies. > > Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my > Linux box, too. (You wrote that it didn't work on yours; perhaps this > bug is fixed now?) No, it seems to be an installation problem. Up to now, I could trace it down to the fact that "-D__GNUC_MINOR__=0(2" is passed to cpp if called via gpc, instead of "-D__GNUC_MINOR__=7" with gcc. I'm not sure yet why this is so, does it have anything to do with "gpc version 2.0(2.7.2.1)"? ^^^ -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sat Apr 19 02:24:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA26962 for ; Sat, 19 Apr 1997 02:24:42 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA152288; Sat, 19 Apr 1997 01:24:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60890; Sat, 19 Apr 1997 01:25:23 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA14386 for ; Sat, 19 Apr 1997 02:20:44 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id BAA06742 for ; Sat, 19 Apr 1997 01:21:25 +0100 Date: Sat, 19 Apr 1997 01:21:24 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: Re: New Alpha In-Reply-To: <199704180044.CAA04688@helena.mi.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 18 Apr 1997, Frank Heckenbach wrote: > > Peter Gerwinski wrote: > > > Yes, conditional defines. GPC pre-defines the symbol "__GPC__": > > > > (*$ifdef __GPC__ *) > > (* GNU Pascal switches *) > >[...] > > (*$else *) > > (* Borland Pascal switches *) > >[...] > > (*$endif *) > > > > What would you consider "simpler" than this? ;-) > > OK, if "__GPC__" is predefined, this is viable. I didn't know about this, > I tried just "GPC"... > There's more (try `gpc -v' or read the specs file) The underscores are required by POSIX specifications > No, it seems to be an installation problem. > Up to now, I could trace it down to the fact that "-D__GNUC_MINOR__=0(2" is > passed to cpp if called via gpc, instead of "-D__GNUC_MINOR__=7" with gcc. > I'm not sure yet why this is so, does it have anything to do with > "gpc version 2.0(2.7.2.1)"? > ^^^ That's a bug. (thanks for finding it ;-) --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum From gpc-request@santra.hut.fi Sun Apr 20 23:28:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA31170 for ; Sun, 20 Apr 1997 23:28:27 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA136434; Sun, 20 Apr 1997 22:27:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68318; Sun, 20 Apr 1997 22:28:33 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA06056 for ; Sun, 20 Apr 1997 23:22:23 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA31152 for gpc@hut.fi; Sun, 20 Apr 1997 23:21:49 +0200 From: Peter Gerwinski Message-Id: <199704202121.XAA31152@agnes.dida.physik.uni-essen.de> Subject: New Alpha To: gpc@hut.fi Date: Sun, 20 Apr 1997 23:21:49 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello! Here again is a new GPC alpha version. Changes since gpc-970412: General news: * `Packed' works. A "packed array [ 1..8 ] of Boolean" now occupies one byte instead of 8 like before (or like with Borland Pascal which claims to pack all arrays automatically). Also, the type packed record a: Boolean; b: 0..3; c: -3..3; end; now also has just one byte (instead of 3). :-) As a result, the built-in procedures `pack' and `unpack' are probably broken. Since I have no experience with these procedures, please send me some test programs which do exactly "writeln ( 'OK' )" if everything works, or else "writeln ( 'failed' )" (or crash or don't compile) if not. Thanks in advance. * GPC now has yet another new option `--debug-tree="Foo"' which is useful for debugging GPC itself. I use it to look at GPC's internal information about a variable `foo' during compilation by inserting (*$debug-tree="Foo"*) into the Pascal source. * Implemented more warnings about unrecognized compiler directives or combinations which make no sense. Bug fixes: * Comparisions of ordinal types as `if' conditions work again (was broken in gpc-970412). * `Const' or `protected Var' parameters which are transported through GPI files do not spoil type declarations any more. * Assignment to char type subranges work again. (Was broken, probably in gpc-970215.) * The `write' and `writeln' procedures applied to subranges (e.g. `Char' subranges, `Byte' variables, etc.) work now. Borland Pascal: * Untyped parameters now can be passed as parameters to subsequent functions which also want untyped parameters. Extended Pascal: * GPC now warns about `or else' and `and then', which are GPC extensions, when `--extended-pascal' is given. (ISO Pascal wants `or_else' and `and_then'.) * Assignments := (allowed in EP, not in BP) now work in parameter passing, too. (This means they should work in all situations now.) With `--borland-pascal', a warning is given. * Modules: Exported ranges work. * I herewith present first results from the Schema Project. (-: The following schemata work now: Type MySubrange ( LastChar: Char ) = 'A'..LastChar; MyArray ( n: Integer ) = array [ 1..n ] of Real; (Not yet implemented: `New', `Dispose', and parameter passing with undiscriminated schemata. And probably more.) If you want to contribute to this part of GPC, please test these types of schemata in as many contexts as possible. It is impossible for myself to try this out with all underlying data types, in the context of assignments, other expressions, parameter passing, etc. The source - a diff against gpc-970412 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Thanks to Abimbola A. Olowofoyeku, Frank Heckenbach, Berend de Boer, and Sven Hilscher for finding the bugs. Again: Is anybody interested to help to document all this? For example, to write a list of Extended Pascal [Borland Pascal] features which work [do not yet work] in GPC which replace the somehow outdated chapter "Extensions", "Extended Pascal", and "Borland Pascal" in the on-line manual? Or to complete and improve the description of the compiler option in chapter "Invoking GPC"? Finally I have one more question: Let's assume the Schema Project to be done. How much compatibility to Extended Pascal and to Borland Pascal can we claim then? In case it is EP > 90% I would like to enter beta test stage and to prepare for the release of gpc-2.1. If not, I would like to know which parts of EP should be implemented to achive > 90% compatibility. (* This condition arises from former announcements where I misunderstood some notes in the GPC source and already claimed 90%. )-: Instead of decreasing this number in future releases I want to improve GPC and announce at least 91% - which must be justified then. We aim the possibility to have 100% EP with `--extended-pascal' anyway. {I aim the 100% only with the switch, because - for instance - this nested comment would be an error in Extended Pascal.;-} *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 23 15:51:59 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA06030 for ; Wed, 23 Apr 1997 15:51:59 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA148748; Wed, 23 Apr 1997 14:49:57 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65242; Wed, 23 Apr 1997 14:51:14 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA10064 for ; Wed, 23 Apr 1997 15:40:54 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA19424 (8.7.6/7.5c-FAU); for ; Wed, 23 Apr 1997 14:40:40 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id OAA27629 (SMI-8.6/7.5b-FAU); Wed, 23 Apr 1997 14:40:39 +0200 From: Frank Heckenbach Message-Id: <199704231240.OAA27629@helena.mi.uni-erlangen.de> Date: Wed, 23 Apr 1997 14:40:38 +0200 To: gpc@hut.fi Subject: Re: New Alpha Status: RO First of all: Thanks for implementing all the new features and removing many bugs! I like especially the packed arrays and records and the write(ln) with subranges! :-) Most of the bugs I reported in the last few months seem to have gone. However, the following still doesn't work (if it's already/still on the bug list, please ignore): PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} {The same with "var ...=...", ok with "var ... value ..."} BEGIN END. Then, a very small problem: I have a Pascal program (let's say foo.pas) that uses some units. I've put the following line into it: {$IFDEF __GPC__}{$automake="-O3"}{$ENDIF} It also needs some C functions contained in bar.c . If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). In the latter situation also the file foo.gpc is left. It's no real problem since the first version works, but I just want to make sure if this is supposed behaviour (for any reason) or a little bug. BTW, the problem in Linux that I described is still there, but I solved it (temporarily) by moving cpp to cpp_ and putting the following script as cpp: #!/bin/sh /usr/lib/gcc-lib/i486-linux/2.7.2.1/cpp_ $* -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 Probably not a very elegant solution, but it seems to work for now... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu Apr 24 00:04:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA06913 for ; Thu, 24 Apr 1997 00:04:09 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA150842; Wed, 23 Apr 1997 23:01:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47854; Wed, 23 Apr 1997 23:03:19 +0200 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA27071 for ; Wed, 23 Apr 1997 23:58:27 +0300 (EET DST) Received: from athena (athena.lmemw.ericsson.se [147.214.118.10]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id WAA12584; Wed, 23 Apr 1997 22:58:26 +0200 (MET DST) Received: from c3po by athena (SMI-8.6/LME-DOM-2.2.3) id WAA28072; Wed, 23 Apr 1997 22:58:25 +0200 Message-Id: <335E759A.134C@ericsson.com> Date: Wed, 23 Apr 1997 22:48:26 +0200 From: Jakob Heinemann Reply-To: Jakob.Heinemann@ericsson.com Organization: Ericsson Saab Avionics AB X-Mailer: Mozilla 3.01Gold (WinNT; I) Mime-Version: 1.0 To: Peter Gerwinski Cc: gpc@hut.fi Subject: Const conflict. Was: Re: New Alpha References: <199704231949.VAA06696@agnes.dida.physik.uni-essen.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Status: RO Peter Gerwinski wrote: > = > According to Frank Heckenbach: > > [...] > > However, the following still doesn't work (if it's already/still on t= he bug > > list, please ignore): > > > > PROGRAM x; > > CONST n:1..16=3D6; {"subrange bounds are not of the same type"} > > BEGIN > > END. > = > Is this really a bug??? Extended Pascal allows expressions as the uppe= r > bound of a subrange. In this case, the expresson "16 =3D 6" (with the > Boolean value "false") is the upper bound - which is indeed not of the > same type as the lower bound "1". Its not that easy to tell what your code means, not even for people, = Franks intention is easily interpreted in the way Peter does and then = of course its obvious that the compiler should protest. Thinking of extended Pascals expression evaluation its a matter of = operator precedence. Which comes first .. or =3D in a constant declaration. = = I Suppose Frank intended to have a specific value of a subrange as a constant, but really this is not a good code example, for making good = use of constants in a program you should make an explicit type declaration, and though I have not tried it this should work: PROGRAM x; TYPE short_range_type =3D 1..16; (* here some integer maths could be = = applied on the bounds *) CONST somewhere_in_between_c : short_range_type =3D 6; VAR a_value : short_range_type; BEGIN a_value :=3D 4; if a_value < somewhere_in_between_c (* comparison with values of same type*) = then writeln('Yeah this is working'); END. /Jakob :) Longtimepascalhackerthatnowadayshackalotada. Ericsson Saab Avionics AB, Link=F6ping, Sweden. = mailto:Jakob.Heinemann@ericsson.com From gpc-request@santra.hut.fi Wed Apr 23 22:19:08 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA06726 for ; Wed, 23 Apr 1997 22:19:08 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA135922; Wed, 23 Apr 1997 21:16:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66988; Wed, 23 Apr 1997 21:18:19 +0200 Received: from fawn.cs.wwu.edu (fawn.cs.wwu.EDU [140.160.140.171]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id WAA23774 for ; Wed, 23 Apr 1997 22:13:58 +0300 (EET DST) Received: (from phil@localhost) by fawn.cs.wwu.edu (8.7.5/8.7.3) id MAA21351; Wed, 23 Apr 1997 12:11:36 -0700 (PDT) Date: Wed, 23 Apr 1997 12:11:36 -0700 (PDT) From: Phil Nelson Message-Id: <199704231911.MAA21351@fawn.cs.wwu.edu> To: peter@agnes.dida.physik.uni-essen.de Cc: gpc@hut.fi In-Reply-To: <199704231949.VAA06696@agnes.dida.physik.uni-essen.de> (message from Peter Gerwinski on Wed, 23 Apr 1997 21:49:06 +0200 (MET DST)) Subject: Re: New Alpha Status: RO >> CONST n:1..16=6; {"subrange bounds are not of the same type"} >... >This is a known shift/reduce conflict in the parser. In principle it >should be possible to tell bison to shift it rather than to reduce it - Actually, bison (and yacc) automatically do a shift for a shift/reduce conflict. That is why the error. It shifts the = on the parse stack to get a handle of E=E and that is considered the upper bound. What you want here is to force the reduce, so the 16 is reduced to an expression and the = remains as part of the "const x = value;" By forcing the reduce then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; So I would say that you do want to force the reduce and make equals have to be parenthesized to get comparison. To get it, you need a fake precedence and use the "%prec" construct on the proper rule in the grammar. If you can't figure it out, I'll get a copy of the alpha and try to get a patch to you. -- Phil Nelson NetBSD: http://www.netbsd.org e-mail: phil@cs.wwu.edu LPF: http://www.lpf.org http://www.cs.wwu.edu/~phil !gifs: http://www.lpf.org/Patent/Gif/Gif.html From gpc-request@santra.hut.fi Wed Apr 23 21:52:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA06711 for ; Wed, 23 Apr 1997 21:52:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA123288; Wed, 23 Apr 1997 20:50:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19604; Wed, 23 Apr 1997 20:51:31 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA24205 for ; Wed, 23 Apr 1997 21:48:43 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA06696 for gpc@hut.fi; Wed, 23 Apr 1997 21:49:06 +0200 From: Peter Gerwinski Message-Id: <199704231949.VAA06696@agnes.dida.physik.uni-essen.de> Subject: Re: New Alpha To: gpc@hut.fi Date: Wed, 23 Apr 1997 21:49:06 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > [...] > However, the following still doesn't work (if it's already/still on the bug > list, please ignore): > > PROGRAM x; > CONST n:1..16=6; {"subrange bounds are not of the same type"} > BEGIN > END. Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1". This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this. > {The same with "var ...=...", ok with "var ... value ..."} Strange. On my box, it works with `value'. > Then, a very small problem: > > I have a Pascal program (let's say foo.pas) that uses some units. > [...] > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-) > In the latter situation also the file foo.gpc is left. That's indeed a bug. Thanks for the report. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu Apr 24 16:24:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA09021 for ; Thu, 24 Apr 1997 16:24:32 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05072; Thu, 24 Apr 1997 15:23:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28848; Thu, 24 Apr 1997 15:23:30 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA22264 for ; Thu, 24 Apr 1997 16:11:26 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id PAA07536 for ; Thu, 24 Apr 1997 15:12:02 +0100 Date: Thu, 24 Apr 1997 15:12:01 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: BP style objects: errors. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello, Using gpc to compile (some parts of) Borland's objects unit, I noticed this (so far): 1) References to an incomplete type are not accepted. In the code below, CopyFrom uses a variable S of type TStream, while TStream is not yet finished: type PStream = ^TStream; TStream = object(TObject) Status: Integer; ErrorInfo: Integer; constructor Init; procedure CopyFrom(var S: TStream; Count: Longint); ... BP accepts this, gpc barfs: "type name expected, identifier `Tstream' given" 2) Something simular appens in the implementation part: procedure TStream.Error(Code, Info: Integer); type TErrorProc = procedure(var S: TStream); begin Status := Code; ErrorInfo := Info; if StreamError <> nil then TErrorProc(StreamError)(Self); end; This results in an error: objects.pas: In function `Tstream_Error': objects.pas:141: `object' type definition only allowed at top level objects.pas:141: parse error before `Procedure' objects.pas:142: pointer domain type `Terrorproc' undefined objects.pas:145: undeclared identifier `Terrorproc' (first use this function) objects.pas:145: (Each undeclared identifier is reported only once objects.pas:145: for each function it appears in.) objects.pas:145: parse error before `(' objects.pas:145: missing semicolon objects.pas:145: missing semicolon 3) Obviously, `self' is treated different too... All of this with the latest-but-one alpha release, in BP mode with extended syntax. BTW: of course, what I was trying out, was how much trouble it would be to port TVision to GPC. Seems we have a long way to go.... Greetings, JanJaap -- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Thu Apr 24 16:01:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA08976 for ; Thu, 24 Apr 1997 16:01:16 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74432; Thu, 24 Apr 1997 15:00:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA29838; Thu, 24 Apr 1997 15:00:13 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA21296 for ; Thu, 24 Apr 1997 15:49:13 +0300 (EET DST) Received: from alpha.hut.fi (jtv@alpha.hut.fi [130.233.224.50]) by vipunen.hut.fi (8.8.5/8.8.2) with SMTP id PAA112842 for ; Thu, 24 Apr 1997 15:49:12 +0300 Date: Thu, 24 Apr 1997 15:49:12 +0300 (EET DST) From: Jukka Virtanen Reply-To: Jukka Virtanen To: gpc@hut.fi Subject: Re: Const conflict. Was: Re: New Alpha In-Reply-To: <335E759A.134C@ericsson.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 23 Apr 1997, Jakob Heinemann wrote: > Peter Gerwinski wrote: > > > > According to Frank Heckenbach: > > > [...] > > > However, the following still doesn't work (if it's already/still on the bug > > > list, please ignore): > > > > > > PROGRAM x; > > > CONST n:1..16=6; {"subrange bounds are not of the same type"} > > > BEGIN > > > END. > > > > Is this really a bug??? Extended Pascal allows expressions as the upper > > bound of a subrange. In this case, the expresson "16 = 6" (with the > > Boolean value "false") is the upper bound - which is indeed not of the > > same type as the lower bound "1". Hi folks... I think the way to solve this is to implement some context sensitivity to the parser, but even that does not solve all problems, if not introduce new ones :-) This is kind of hard to do in the LALR(1) parsers like yacc and bison, and did not figure out any easy way to do it so I decided to do it "later". Anyway, it is not possible to automatically decide that constructs like the following are invalid, like can be seen from the pascal boolean subrange variable declaration: foo : false .. 16=16; If the decicion of the parse tree is based on the fact that the resulting program would otherwise be syntactically incorrect, the parsing could be done more cleverly, which is required in the following: foo_error : 1 .. 16 = 15; Then it remains the problem how to interpret the following: foo_problem : false .. true = false; Because that can be interpreted either as an initialized or uninitialized subrange. Extended pascal does require that both bounds of a subrange can be arbitrary expressions. In GPC (as far as I recall) only the lower bound can be an expression, the upper bound needs to be constant, because I could not find any easy way to prevent the massive amounts of conflicts, no matter how I tried. Anyone who really knows how to hack parsers interested in this one? Juki jtv@hut.fi From gpc-request@santra.hut.fi Thu Apr 24 15:28:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA08929 for ; Thu, 24 Apr 1997 15:28:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84012; Thu, 24 Apr 1997 14:27:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA25320; Thu, 24 Apr 1997 14:27:10 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA19356 for ; Thu, 24 Apr 1997 15:20:19 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA16628 (8.7.6/7.5c-FAU); for ; Thu, 24 Apr 1997 14:20:03 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id OAA02155 (SMI-8.6/7.5b-FAU); Thu, 24 Apr 1997 14:20:01 +0200 From: Frank Heckenbach Message-Id: <199704241220.OAA02155@helena.mi.uni-erlangen.de> Date: Thu, 24 Apr 1997 14:20:00 +0200 To: gpc@hut.fi Subject: Re: Const conflict. Was: Re: New Alpha Status: RO Peter Gerwinski wrote: > > {The same with "var ...=...", ok with "var ... value ..."} > > Strange. On my box, it works with `value'. Yes, I meant it's ok with "value". Perhaps I was unclear. > > I have a Pascal program (let's say foo.pas) that uses some units. > > [...] > > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). > > I think that's intended: The GNU linker is a one-pass linker which needs > the "lowest" unit in the most right position of the command line. > (I think. I don't really know.;-) I don't think that's the problem. I tried invocing ld manually, and it worked whether bar.o was put before or after the Pascal .o's. However, I noticed that the "automade" unit's .o files were not passed to ld in the latter case: In the first case, gpc issued "ld ... some.o units.o foo.o bar.o ...", in the latter case, it was just "ld ... bar.o foo.o ..." (where foo.o and bar.o were actually temp file names containing the compiled code from foo.pas and bar.c, of course). So, probably this has got something to do with the left over .gpc file... Jakob Heinemann wrote: > > > PROGRAM x; > > > CONST n:1..16=6; {"subrange bounds are not of the same type"} > > > BEGIN > > > END. > > > Is this really a bug??? Extended Pascal allows expressions as the upper > > bound of a subrange. In this case, the expresson "16 = 6" (with the > > Boolean value "false") is the upper bound - which is indeed not of the > > same type as the lower bound "1". Sorry, I didn't see the other possible interpretation when I reported the problem. Actually, BTW, there is a bug in BP - it doesn't even accept the following... ;-) const x:false..(2=3)=false; > I Suppose Frank intended to have a specific value of a subrange as a > constant, but really this is not a good code example, for making good > use of constants in a program you should make an explicit type > declaration, > and though I have not tried it this should work: Thanks for the hint, that's what I'm doing now. It solves the "bug". Phil Nelson wrote: > By forcing the reduce > then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax > error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; > So I would say that you do want to force the reduce and make equals have to be > parenthesized to get comparison. I thought so, too, but then I realized that this might break some Extended Pascal code: var n:false..1=2; would be valid in EP, but cause an error with the above modification. var n:false..false=false; would declare "n:false..true" uninitialized in EP, but "n:false..false value false" with the modification. While it doesn't seem to do any harm that the variable is initialized, it would make a difference that the range is limited, and a statement like "n:=true" would fail (with some kind of range checking)... Sure, such things are not likely to occur in any real program, but perhaps in some test suites (and if not, they might have to be added to the test suites to claim really 100.00000% compatibility some time)... So, I guess, to remain compatible, the modification can be effective only with "--borland-pascal", or at least not with "--extended-pascal". But I don't know if it's possible to modify the parsing rules depending on switches. If not, I suggest to leave it as it is, and to issue a warning whenever such a thing is encountered, regardless of the switches, since it can be avoided in any case, as was shown, by parentheses or by an explicit type declaration (perhaps the text of the warning should also contain the solutions to avoid confusing people (like me) who encounter it for the first time). -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sat Apr 26 00:34:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA11559 for ; Sat, 26 Apr 1997 00:34:43 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51402; Fri, 25 Apr 1997 23:33:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52032; Fri, 25 Apr 1997 23:33:11 +0200 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA02727 for ; Sat, 26 Apr 1997 00:27:04 +0300 (EET DST) Received: from default (dy2-07.van.tvs.net [204.244.156.64]) by mercury.uniserve.com (8.8.2/8.8.5) with SMTP id OAA27505 for ; Fri, 25 Apr 1997 14:26:57 -0700 (PDT) Message-Id: <3.0.1.32.19970425142508.00691550@cybermail.net> X-Sender: s_c@cybermail.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 25 Apr 1997 14:25:08 -0700 To: gpc@hut.fi From: skye Subject: errors when passing pointers from a unit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO I don't realy understand this. I'm new to Pascal tho I've programmed in C for quite some time. I have a unit that dose some _basic_ mode 13h graphics stuff. In it is an off-screen buffer created my allocating a type defined as: type mode13VideoBuffer = array[1..64000] of char; var gBuffer"^mode13VideoBuffer; I have 2 procedures that set up the video mode (by calling some external C functions) and allocate this buffer. procedure InitGraphics; begin {set video mode and other initalization stuff} new(gBuffer); end; procedure TextMode; begin {reset the display and clean up video stuff} dispose(gBuffer); end; All my graphic functions draw to this buffer. To get it to the screen I have a procedre that calls an external C function: procedure gUpdate; begin screenblit( gBuffer); end; It is in this C function that I crash. Here's the screenblit function: //uses libc.a functions void screenblit( unsigned char* buf) { short video = __dpmi_segment_to_descriptor(0xa000); movedata(_my_ds(), (int)buf, video, 0, 320*200); } This only crashes when I pass it a pointer from my unit. I can do the exact same allocation from the main program file and it will work OK. Am I getting confused on how pointers work in C and how they work in Pascal (I thought that they were pretty much the same except for type checking and "true" dynamic allocation)? This how I compile and link: I create a lib from the compiled .o files from my units. I then compile my test program linking in the lib: gpc -g -o gtest.exe gtest.pas -lglib ^^^^ This is my lib NOTE: I can get this system to work in C by replicating the units in .h and .c files and linking the object files on the commanline. HELP? -SC From gpc-request@santra.hut.fi Thu Apr 24 03:35:08 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA07126 for ; Thu, 24 Apr 1997 03:35:08 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA135878; Thu, 24 Apr 1997 02:32:54 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49434; Thu, 24 Apr 1997 02:34:14 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA30045 for ; Thu, 24 Apr 1997 03:30:02 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id CAA02887 for ; Thu, 24 Apr 1997 02:30:38 +0100 Date: Thu, 24 Apr 1997 02:30:36 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: BP Turbo Vision sources Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello, I collected this discussion from comp.os.msdos.programmer.turbvision. Somebody claims to have gotten permission from Borland to release the BP Tvision sources to the public "as long as they are not sold". GNU Pascal is definately the "not for money" category so this may be interesting to us. Having Turbo Vision available would make it much easier to write attractive applications, at least for the djgpp/dos port of GPC. But I do think we should wait and see what happens next.... Greetings, JanJaap ========================================================================== Subject: TV Pascal sources ? From: marco@pool.informatik.rwth-aachen.de (Marco Schmidt) Date: 1997/03/29 Message-Id: <333d55d9.15365994@news.rwth-aachen.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Hi, are there any Turbo Vision Pascal sources available as it is the case for C / C++ ? Thanks in advance, Marco -- Marco Schmidt - Student of Computer Science, Aachen, Germany mailto:marco@pool.informatik.rwth-aachen.de http://www.geocities.com/SiliconValley/Lakes/6686 PGP public key available on my web page - key fingerprint : 78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 ========================================================================= Subject: Re: TV Pascal sources . From: sukud@pncl.co.uk (sukud) Date: 1997/04/01 Message-Id: <5hq8mp$81f@soap.uunet.pipex.com> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] article <333d55d9.15365994@news.rwth-aachen.de>, marco@pool.informatik.rwth-aachen.de says... > >Hi, > >are there any Turbo Vision Pascal sources available as it is the case >for C / C++ ? > >Thanks in advance, >Marco >-- >Marco Schmidt - Student of Computer Science, Aachen, Germany >mailto:marco@pool.informatik.rwth-aachen.de >http://www.geocities.com/SiliconValley/Lakes/6686 >PGP public key available on my web page - key fingerprint : >78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 Yes there are. I think you can get them perhaps through your local Borland branch. But when I was traing to get source code for Delhi, the staff behaind the phone was confused when I sad source code of delhi component and was not able to help me. Having source code can be very usefull. For instance just for look, or for making some private part of objict not private, because I neet it. In my case I wanted to change object Tview and with it all his descendats. I wanted make there somethink like object inspector in Delphi, but more stupid. Petr Soukup sukud@pncl.co.uk ========================================================================= Subject: Re: Turbo Vision source code. From: "Wellige" Date: 1997/01/10 Message-Id: <01bbfef7$a07dd940$bd9562c1@itk_ms_wellige.itk.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Miguel Angelo Henley wrote... > I'm looking for turbo vision source code for turbo pascal. > Where can I find it ? TV source code comes with BP7. As far as I know is the TV Pascal code not free as the C code already is. So I would be suprised if there is a chance to download it. Regards, Tom. -- Tom Wellige wellige@itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: sl65r@cc.usu.edu (Paul Hepworth) Date: 1997/04/17 Message-Id: <1997Apr17.190452.97084@cc.usu.edu> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] > I've already posted a request for source to this ng, but nobody knew > .. though I got some mails of people who'd like to have the source > code themselves. Sorry, nothing found so far. BP7 came with the source code to pascal TV. I think TP6 did as well, but I'm not positive (I gave away my tp6). I have the sources from BP7, but I haven't read whether Borland has given them to the public domain along with the c++ version or not. If they have, I can make the sources available from my web page. Anyone have a .borland.com URL that shows the public domaining of TV? ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" Date: 1997/04/18 Message-Id: <5j75uj$53o@news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Paul, >BP7 came with the source code to pascal TV. I think TP6 did as well, but >I'm not positive (I gave away my tp6). I have the sources from BP7, but >I haven't read whether Borland has given them to the public domain along >with the c++ version or not. If they have, I can make the sources available >from my web page. Anyone have a .borland.com URL that shows the public >domaining of TV? A few weeks ago I spoke to someone from Borland Germany and he told me that the sources are free as long as they are not sold. It's definatley allowed to publish them e.g. on the Web. Sincerely, Tom -- Tom Wellige wellige@itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: Re: TV Pascal Source From: u6ed4@wvnvm.wvnet.edu (Cyber-Babushka) Date: 1997/04/18 Message-Id: Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] On Fri, 18 Apr 1997, Wellige wrote: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. In that case, if someone would please send me the Pascal sources, I would be happy to put them on the TVPlus web site as a courtesy. Would someone on the newsgroup please forward this request to the mailing list? My posts never make it through. I think I was put on review or something for posting the pointer to the FAQ too many times without changing it. Problem is, there's no listowner to take me off review, and I've written to the sysop without getting an answer. bonni http://wvnvm.wvnet.edu/~u6ed4/bonni.html C++ Turbo Vision archive: http://brooks.wvn.wvnet.edu/tvhome __ __ IC | XC | bonni mierzejewska "The Lone Quilter" ---+--- | u6ed4@wvnvm.wvnet.edu NI | KA | Kelly's Creek Homestead, Maidsville, WV ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: codc01@gel.usherb.ca (Carl Eric Codere) Date: 1997/04/18 Message-Id: Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] In article <5j75uj$53o@news.Dortmund.Germany.EU.net> "Wellige" writes: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. Are you sure about this? There has been no official word on this from Borland USA, do you know where I can get more information, since each time I e-mail Borland, I do not get any reply! Carl Eric Codere (aka The Black One) Pascal and asm programming http://www-edu.gel.usherb.ca/codc01 ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" Date: 1997/04/21 Message-Id: <5jf56a$77m@news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Carl, >Are you sure about this? There has been no official word on this from Borland >USA, do you know where I can get more information, since each time I e-mail >Borland, I do not get any reply! Thats what the guy from Borland Germany told me: it's ok for Borland to post them in newsgroups when explaining something. So it will be also ok to make them somewhere accessable on the net so one don't have to resend them everytime in a newsgroup. Sincerely, Tom -- Tom Wellige wellige@itk.de http://www.kst.dit.ie/people/twellige -- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Wed Apr 23 21:51:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA06706 for ; Wed, 23 Apr 1997 21:51:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA151032; Wed, 23 Apr 1997 20:49:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19590; Wed, 23 Apr 1997 20:51:09 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA24392 for ; Wed, 23 Apr 1997 21:47:15 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA06650 for gpc@hut.fi; Wed, 23 Apr 1997 21:47:38 +0200 From: Peter Gerwinski Message-Id: <199704231947.VAA06650@agnes.dida.physik.uni-essen.de> Subject: New Alpha: EMX run time library broken? To: gpc@hut.fi Date: Wed, 23 Apr 1997 21:47:37 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, I was reported that the EMX run time library of the latest alpha GPC (gpc-970420) is broken: Not even `hello.pas' can be linked. Since I cannot reproduce the error on my own system (I can link even more complicated EMX programs here ... :-) I ask whether somebody else has observed the same problem. Perhaps there is a bug which only shows up in some configurations ... Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 26 16:03:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13203 for ; Sat, 26 Apr 1997 16:03:50 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51058; Sat, 26 Apr 1997 15:02:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59650; Sat, 26 Apr 1997 15:02:10 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA10951 for ; Sat, 26 Apr 1997 15:55:35 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA13069 for gpc@hut.fi; Sat, 26 Apr 1997 15:56:50 +0200 From: Peter Gerwinski Message-Id: <199704261356.PAA13069@agnes.dida.physik.uni-essen.de> Subject: Re: errors when passing pointers from a unit To: gpc@hut.fi Date: Sat, 26 Apr 1997 15:56:49 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to skye: > > var > gBuffer"^mode13VideoBuffer; You mean: gBuffer: ^mode13VideoBuffer;-). > [...] > All my graphic functions draw to this buffer. To get it to the screen I > have a procedre that calls an external C function: > procedure gUpdate; > begin > screenblit( gBuffer); > end; How is this C function declared in the Pascal program? As "Procedure ScreenBlit ( gBuffer: Pointer ); C;"? Then it should work. > [...] > This only crashes when I pass it a pointer from my unit. I can do the exact > same allocation from the main program file and it will work OK. This I don't understand. You mean that you are using a statically allocated video buffer in the Pascal program and passing a pointer to it to the C program? The following should work: Program Whatever; Type mode13VideoBuffer = array [ 1 .. 320 * 200 ] of Byte; mode13VideoBufferPtr = ^mode13VideoBuffer; Var gBuffer: mode13VideoBuffer; (* NOT a pointer to it *) Procedure ScreenBlit ( Buffer: mode13VideoBufferPtr ); C; begin ScreenBlit ( @gBuffer ); end. > Am I getting confused on how pointers work in C and how they work in Pascal > (I thought that they were pretty much the same except for type checking Yes, they are. > and "true" dynamic allocation)? What's that? What's "false" with `New' and `GetMem'? :-) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 26 16:03:24 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13196 for ; Sat, 26 Apr 1997 16:03:24 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75618; Sat, 26 Apr 1997 15:02:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58616; Sat, 26 Apr 1997 15:01:43 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA10293 for ; Sat, 26 Apr 1997 15:56:48 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA13123 for gpc@hut.fi; Sat, 26 Apr 1997 15:58:04 +0200 From: Peter Gerwinski Message-Id: <199704261358.PAA13123@agnes.dida.physik.uni-essen.de> Subject: Re: BP Turbo Vision sources To: gpc@hut.fi Date: Sat, 26 Apr 1997 15:58:04 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > I collected this discussion from comp.os.msdos.programmer.turbvision. > Somebody claims to have gotten permission from Borland to release the BP > Tvision sources to the public "as long as they are not sold". GNU Pascal > is definately the "not for money" category so this may be interesting to > us. Not so definitely. The GPL allows to sell copies of GPC as long as the clients get all rights the vendor had. > Having Turbo Vision available would make it much easier to write > attractive applications, at least for the djgpp/dos port of GPC. Really. We must not distribute Turbo Vision "as part of GPC" because this would restrict distribution of GPC, but it can be in the "contrib" subdirectory. > But I do think we should wait and see what happens next.... I agree. Some official notes from Borland would be good. (The telephone call somebody in a NewsGroup spoke about would not be accepted as a proof in a lawsuit.) (* And GPC cannot compile Turbo Vision anyway at the moment. *) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 26 16:02:32 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13182 for ; Sat, 26 Apr 1997 16:02:32 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48192; Sat, 26 Apr 1997 15:01:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62182; Sat, 26 Apr 1997 15:00:52 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA11122 for ; Sat, 26 Apr 1997 15:57:15 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA13141 for gpc@hut.fi; Sat, 26 Apr 1997 15:58:31 +0200 From: Peter Gerwinski Message-Id: <199704261358.PAA13141@agnes.dida.physik.uni-essen.de> Subject: Combining C and Pascal source. (Was: Const conflict.) To: gpc@hut.fi Date: Sat, 26 Apr 1997 15:58:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Frank Heckenbach wrote: > > > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > > > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). > > [...] > I don't think that's the problem. I tried invocing ld manually, and it worked > whether bar.o was put before or after the Pascal .o's. > [...] > So, probably this has got something to do with the left over .gpc file... 1. I cannot reproduce this error. :-( On my system, "gpc foo.pas bar.c" and "gpc bar.c foo.pas" both work fine - on DJGPP as well as on Linux. This will be hard to fix. 2. I think I have found the problem: :-) The `gpc' driver program assumes that the first input file is a Pascal source when doing `--automake'. I fixed this in `gcc.c'; please retry with the next Alpha GPC. (A diff for `gcc.c' is appended below.) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- --- gpc-970420/gcc.c Fri Apr 18 12:46:41 1997 +++ gpc/gcc.c Sat Apr 26 10:56:14 1997 @@ -4994,25 +4994,36 @@ obstack_grow (&collect_obstack, "\0", 1); putenv (obstack_finish (&collect_obstack)); #ifdef GPC - /* Substitute the basename of the first input file for %b in - link_command_spec. */ + /* Substitute the basename of the first Pascal + * input file for %b in link_command_spec. + */ + i = 0; + while (i < n_infiles + && infiles[i].language + && strcmp (infiles[i].language, "p") != 0 + && strcmp (infiles[i].language, "pas") != 0) + {fprintf (stderr, "%d\n", i); i++;} + if (i < n_infiles) + { + input_basename = infiles[i].name; + for (p = input_basename; *p; p++) + if (*p == '/') + input_basename = p + 1; - input_basename = infiles[0].name; - for (p = input_basename; *p; p++) - if (*p == '/') - input_basename = p + 1; + /* Find a suffix starting with the last period, + * and set basename_length to exclude that suffix. + */ + basename_length = strlen (input_basename); + p = input_basename + basename_length; + while (p != input_basename && *p != '.') + p--; + if (*p == '.' && p != input_basename) + basename_length = p - input_basename; - /* Find a suffix starting with the last period, - and set basename_length to exclude that suffix. */ - basename_length = strlen (input_basename); - p = input_basename + basename_length; - while (p != input_basename && *p != '.') --p; - if (*p == '.' && p != input_basename) - basename_length = p - input_basename; - - explicit_link_files = add_automake_files (explicit_link_files); + explicit_link_files = add_automake_files (explicit_link_files); + } #endif /* GPC*/ value = do_spec (link_command_spec); if (value < 0) From gpc-request@santra.hut.fi Sat Apr 26 16:02:28 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13177 for ; Sat, 26 Apr 1997 16:02:28 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37946; Sat, 26 Apr 1997 15:01:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58588; Sat, 26 Apr 1997 15:00:47 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA11307; Sat, 26 Apr 1997 15:57:02 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA13132; Sat, 26 Apr 1997 15:58:18 +0200 From: Peter Gerwinski Message-Id: <199704261358.PAA13132@agnes.dida.physik.uni-essen.de> Subject: Re: Const conflict. To: gpc@hut.fi, jtv@hut.fi (Jukka Virtanen) Date: Sat, 26 Apr 1997 15:58:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jukka Virtanen: > > [Making the parser more clever ...] > > Then it remains the problem how to interpret the following: > > foo_problem : false .. true = false; > > Because that can be interpreted either as an initialized > or uninitialized subrange. If I were a Pascal compiler, I would read this as an initialized variable. OTOH, a true Extended Pascal compiler *must* read this as a subrange. I think it is save to exclude comparisions with `=' from the expressions valid for the upper bound. The reason for allowing expressions here is to have things like `+', `*', parentheses, etc. in the upper bound; subranges of the Boolean type are exotic enougth that we can immolate them. (Hmm ... somebody might need something like Var Foo: 1 .. 4 + ord ( bar = 3 ) + MyFunc ( A = B ); so I will switch on the `=' again in parentheses and such.) > Extended pascal does require that both bounds of > a subrange can be arbitrary expressions. In GPC (as far > as I recall) only the lower bound can be an expression, > the upper bound needs to be constant, [...] Vice versa. > Anyone who really knows how to hack parsers interested > in this one? I join Juki in asking this question. I think I can fool GPC not to recognize the `=' in upper bound expressions (unless, of course, `--extended-pascal' is on), but I have no idea what to do with the lower bound. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat Apr 26 16:02:07 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13172 for ; Sat, 26 Apr 1997 16:02:06 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37930; Sat, 26 Apr 1997 15:00:47 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62412; Sat, 26 Apr 1997 15:00:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA02191 for ; Sat, 26 Apr 1997 15:56:38 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id PAA13114 for gpc@hut.fi; Sat, 26 Apr 1997 15:57:54 +0200 From: Peter Gerwinski Message-Id: <199704261357.PAA13114@agnes.dida.physik.uni-essen.de> Subject: Re: BP style objects: errors. To: gpc@hut.fi Date: Sat, 26 Apr 1997 15:57:54 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > 1) References to an incomplete type are not accepted. [...] That's a new bug. I will have a look at it. > 2) Something simular appens in the implementation part: > > [...] > > TErrorProc = procedure(var S: TStream); GPC does not (yet;) have BP's "procedural variables". It has *pointers* to procedures instead. The above can be translated to TErrorProc = ^Procedure ( ????????? TStream ); - ah, sorry! `Var' parameters don't work in this context! Bug!!! Okay, I will see how difficult it is to implement BP's procedural types ... > 3) Obviously, `self' is treated different too... This I don't understand. > All of this with the latest-but-one alpha release, in BP mode with > extended syntax. It should not be necessary to run GPC in BP mode. `--borland-pascal' does not switch ON anything; it only switches OFF the Extended Pascal extensions. And vice versa. I suggest to write all new source for GPC's default mode and to use `--borland-pascal' (or `--extended-pascal' for that matter) just for testing or when worrying about compatibility to Borland (respectively Extended) Pascal. (*$X+, M Extended Syntax is a different thing because it really switches ON some "dangerous" features of GPC. *) > BTW: of course, what I was trying out, was how much trouble it would be to > port TVision to GPC. Seems we have a long way to go.... We will see. (* But anyway I aim to write something *better* ... ;*) > With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. [...] But there may be some people whose programs rely on flying pigs. I am prepared to implement yet another option `--flying-pigs' for such purposes ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Apr 27 09:14:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA15080 for ; Sun, 27 Apr 1997 09:14:04 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44102; Sun, 27 Apr 1997 08:12:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA42060; Sun, 27 Apr 1997 08:12:14 +0200 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id JAA17613 for ; Sun, 27 Apr 1997 09:08:32 +0300 (EET DST) Received: from default (dy2-27.van.tvs.net [204.244.156.84]) by mercury.uniserve.com (8.8.2/8.8.5) with SMTP id XAA14717 for ; Sat, 26 Apr 1997 23:08:18 -0700 (PDT) Message-Id: <3.0.1.32.19970426230636.0069a93c@cybermail.net> X-Sender: s_c@cybermail.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 26 Apr 1997 23:06:36 -0700 To: gpc@hut.fi From: skye Subject: Re: errors when passing pointers from a unit In-Reply-To: <199704261356.PAA13069@agnes.dida.physik.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO At 03:56 PM 4/26/97 +0200, you wrote: >According to skye: >> >> var >> gBuffer"^mode13VideoBuffer; > >You mean: gBuffer: ^mode13VideoBuffer;-). yah,... right >This I don't understand. You mean that you are using a statically >allocated video buffer in the Pascal program and passing a pointer to >it to the C program? The following should work: > > Program Whatever; > > Type > mode13VideoBuffer = array [ 1 .. 320 * 200 ] of Byte; > mode13VideoBufferPtr = ^mode13VideoBuffer; > > Var > gBuffer: mode13VideoBuffer; (* NOT a pointer to it *) > > Procedure ScreenBlit ( Buffer: mode13VideoBufferPtr ); C; > > begin > ScreenBlit ( @gBuffer ); > end. > Yes, I can get that to work but what still fails is when gBuffer is allocated using new(): var gBuffer:^mode13VideoBuffer; (* IS a pointer *) ....... new(gBuffer); ....... ScreenBlit( gBuffer); (* crashes in the movedata() from the std C lib *) ....... dispose(gBuffer); ....... end. Now I'm not too sure how memory allocation works under pascal. Is this right? I don't have many examples to got from and they all work something like this. would this be the same as this in C: char* gBuffer; gBuffer = malloc(320*200); free(gBuffer); >What's "false" with `New' and `GetMem'? :-) now I haven't seen GetMem before. The examples I'm using just use the method i've shown above. Does GetMem work like malloc() where I can specify the amount at runtime? (this would be nice). Also, isn't there a limit to the amount of static variable memory I can use (DS)? I don't want to have to fidle with my compiler options to increase it. If I have a static array that is 64k there is potental for probles way down the road, esp. if I have other large static structres. Sorry about the basic Pascal questions. It is strange switching from C/C++ to Pascal without documentation. I keep trying to do something one way and find out after much frustration that is done another in Pascal. I have only a few Pascal DOCS I have found online and they all use TP. Are there any using GPC? >Hope this helps, > > Peter Very much, thanks. -Skye From gpc-request@santra.hut.fi Sun Apr 27 06:57:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id GAA14955 for ; Sun, 27 Apr 1997 06:57:22 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50958; Sun, 27 Apr 1997 05:55:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43518; Sun, 27 Apr 1997 05:55:34 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id GAA17545 for ; Sun, 27 Apr 1997 06:49:43 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id FAA06298 (8.7.6/7.5c-FAU); for ; Sun, 27 Apr 1997 05:49:40 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id FAA12142 (SMI-8.6/7.5b-FAU); Sun, 27 Apr 1997 05:49:39 +0200 From: Frank Heckenbach Message-Id: <199704270349.FAA12142@helena.mi.uni-erlangen.de> Date: Sun, 27 Apr 1997 05:49:38 +0200 To: gpc@hut.fi Subject: Modifying string length? Status: RO Hi everybody! Is there a way to change a string's length directly? "s.length:=..." doesn't work, neither (obviously) "length(s):=...". But I think it's necessary in order to implement some low-level string manipulation routines efficiently. BTW: Are the TP string routines (e.g. Insert, Delete) already ported to gpc? -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.]@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sun Apr 27 17:38:46 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA15526 for ; Sun, 27 Apr 1997 17:38:46 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46272; Sun, 27 Apr 1997 16:37:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30972; Sun, 27 Apr 1997 16:36:49 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA22817 for ; Sun, 27 Apr 1997 17:33:14 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA15498 for gpc@hut.fi; Sun, 27 Apr 1997 17:34:47 +0200 From: Peter Gerwinski Message-Id: <199704271534.RAA15498@agnes.dida.physik.uni-essen.de> Subject: CStrings To: gpc@hut.fi Date: Sun, 27 Apr 1997 17:34:47 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, I encountered some problems with Procedures accepting `CString' parameters. When passing a string constant to such a parameter, GPC does *not* automatically add a "chr ( 0 )" terminator. Should it do? And if so, in which cases? We always can explicitly write "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let things like they are ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun Apr 27 20:39:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA15767 for ; Sun, 27 Apr 1997 20:39:19 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44936; Sun, 27 Apr 1997 19:37:40 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51362; Sun, 27 Apr 1997 19:37:18 +0200 Received: from mint.mint.net (root@mint.mint.net [204.254.98.16]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA22385 for ; Sun, 27 Apr 1997 20:34:23 +0300 (EET DST) Received: from dialup-b-15.mint.net (dialup-b-15.mint.net [206.139.113.35]) by mint.mint.net (8.8.5/8.8.5) with SMTP id NAA06555 for ; Sun, 27 Apr 1997 13:34:16 -0400 Message-Id: <199704271734.NAA06555@mint.mint.net> From: "Kevin A. Foss" To: "GPC Mailing List" Date: Sun, 27 Apr 97 13:29:16 -0400 Reply-To: "Kevin Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.9 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: New Alpha: EMX run time library broken? Status: RO On Wed, 23 Apr 1997 21:47:37 +0200 (MET DST), Peter Gerwinski wrote: >I was reported that the EMX run time library of the latest alpha GPC >(gpc-970420) is broken: Not even `hello.pas' can be linked. > >Since I cannot reproduce the error on my own system (I can link even >more complicated EMX programs here ... :-) I ask whether somebody else >has observed the same problem. Perhaps there is a bug which only shows >up in some configurations ... Well I was the one who reported the above problem to Peter and after messing around for 5 days trying to apply the patches, compile it myself, using gdb to trace the source, I have found the problem: I'm a moron. I found I had an older version of the gpc executables in my path before the newer versions, but I was putting the library in the correct place. [For various reasons, I don't like putting anything except the EMX distribution in the \EMX directory tree.] So when I tried to compile hello.pas, the old 2.0 executables were trying to use the new runtime library from the latest alpha and things didn't go well. So, my apologies to Peter and to anyone else who might have wasted time looking for a fix to this problem. -Kevin -- Kevin A. Foss --- kfoss@mint.net -- From gpc-request@santra.hut.fi Sun Apr 27 20:10:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA15754 for ; Sun, 27 Apr 1997 20:10:57 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46310; Sun, 27 Apr 1997 19:09:18 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30758; Sun, 27 Apr 1997 19:08:57 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA24871 for ; Sun, 27 Apr 1997 20:05:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA15735 for gpc@hut.fi; Sun, 27 Apr 1997 20:06:45 +0200 From: Peter Gerwinski Message-Id: <199704271806.UAA15735@agnes.dida.physik.uni-essen.de> Subject: passing pointers, GPC documentation To: gpc@hut.fi Date: Sun, 27 Apr 1997 20:06:45 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to skye: > > Yes, I can get that to work but what still fails is when gBuffer is > allocated using new(): > [...] > ScreenBlit( gBuffer); (* crashes in the movedata() from the std C lib *) Again: How did you declare the "ScreenBlit" procedure? > Now I'm not too sure how memory allocation works under pascal. Is this > right? I don't have many examples to got from and they all work something > like this. would this be the same as this in C: > > char* gBuffer; > gBuffer = malloc(320*200); > free(gBuffer); Yes. > now I haven't seen GetMem before. The examples I'm using just use the > method i've shown above. Does GetMem work like malloc() where I can specify > the amount at runtime? (this would be nice). Yes. `GetMem' is a Borland Pascal extension: GetMem ( gBuffer, 320 * 200 ); FreeMem ( gBuffer, 320 * 200 ); GPC also allows the following: gBuffer:= GetMem ( 320 * 200 ); FreeMem ( gBuffer ); (* 2. parameter is optional in GPC *) > Also, isn't there a limit to the amount of static variable memory I can use > (DS)? No. > I don't want to have to fidle with my compiler options to increase > it. If I have a static array that is 64k there is potental for probles way > down the road, esp. if I have other large static structres. Feel free to allocate static structures of 1MB or above. This is one reason why I am using GPC rather than BP for scientific programs. (-: > Sorry about the basic Pascal questions. It is strange switching from C/C++ > to Pascal without documentation. I keep trying to do something one way and > find out after much frustration that is done another in Pascal. I have only > a few Pascal DOCS I have found online and they all use TP. Are there any > using GPC? AFAIK, the only existing GPC documentation is our info documentation and the GPC FAQ. You can find both in your GPC distribution, or online at http://home.pages.de/~GNU-Pascal/gpc-doc.html http://home.pages.de/~GNU-Pascal/gpc-faq.html If anybody wants to help to create more documentation, I suggest the following: Collect all this information from this list, e.g. the `GetMem' stuff above, put it into a reasonable structure, and add it to the GNU Texinfo documentation. If you have any questions, be sure that I will help you. Like this, the reference will be made available as on-line help, e.g. with Ctrl+F1 when using the RHIDE. I am starting to do this *now* by writing something about Integer types. It is appended below, so you have an example what I am speaking of and would like to recieve. If you have more ideas, e.g. to write something about `writeln', just do it and post it here! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- @node Integer @subsection Integer @cindex Integer types GNU Pascal supports the following Integer types: @table @samp @item ByteInt signed 8-bit integer type, @samp{-128..128} @item Byte unsigned 8-bit integer type, @samp{0..255} @item ShortInt signed 16-bit integer type, @samp{-32768..32767} @item ShortWord unsigned 16-bit integer type, @samp{0..65535} @item Integer signed 32-bit integer type, @samp{-2147483648..2147483647} @item Word unsigned 32-bit integer type, @samp{0..4294967295} @item LongInt signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807} @item LongWord unsigned 64-bit integer type, @samp{0..18446744073709551615} @end table ISO Pascal defines only @samp{Integer}; the other types are GNU extensions. Some of these types (@samp{Byte}, @samp{ShortInt}, @samp{Word}, and @samp{LongInt}) are available in Borland Pascal, too, but have a different size there. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. On the i386 processor family, operations with @samp{Integer} usually work faster than operations with shorter integer types like @samp{ShortInt} or @samp{ByteInt}. @strong{Known bug:} At the moment, GPC's run time library is not able to @samp{write} or @samp{writeln} integer types longer than @samp{Integer}. @c ---------------------------------------------------------------------------- @node LongInt @subsection LongInt @samp{LongInt} is GPC's signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807}. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. @xref{Integer} @xref{LongWord} @xref{Comp} @c ---------------------------------------------------------------------------- @node LongWord @subsection LongWord @samp{ByteInt} is GPC's unsigned unsigned 64-bit integer type, @samp{0..18446744073709551615}. @xref{Integer} @xref{LongInt} @c ============================================================================ From gpc-request@santra.hut.fi Sun Apr 27 20:10:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA15750 for ; Sun, 27 Apr 1997 20:10:56 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47578; Sun, 27 Apr 1997 19:09:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30752; Sun, 27 Apr 1997 19:08:55 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA23216 for ; Sun, 27 Apr 1997 20:04:59 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id UAA15726 for gpc@hut.fi; Sun, 27 Apr 1997 20:06:35 +0200 From: Peter Gerwinski Message-Id: <199704271806.UAA15726@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Sun, 27 Apr 1997 20:06:34 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Is there a way to change a string's length directly? AFAIK, there isn't. Use the `SubStr' function (like BP's `copy' function) to shorten a string, and the `+' operator to make it longer. And of course you can take a pointer to the string, cast it to a pointer to a record the fields of which you can manipulate like you wish ... > BTW: Are the TP string routines (e.g. Insert, Delete) already ported to gpc? The African Chief is working on this. (-: It will probably be released soon. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Apr 28 13:23:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA17694 for ; Mon, 28 Apr 1997 13:23:16 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA80732; Mon, 28 Apr 1997 12:21:24 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31070; Mon, 28 Apr 1997 12:21:02 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA12406 for ; Mon, 28 Apr 1997 13:13:10 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Mon, 28 Apr 1997 11:14:22 +0100 Received: from [0.16.144.0] by potter.cc.keele.ac.uk; Mon, 28 Apr 1997 11:12:10 +0100 From: The African Chief To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: CStrings Message-Id: Date: Mon, 28 Apr 1997 11:15:50 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Sun, 27 Apr 1997 17:34:47 +0200 (MET DST) Peter Gerwinski wrote: >Hello, > >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. > >Should it do? I personally think so. >And if so, in which cases? "In all cases", I would venture to say. > We always can explicitly write "foo ( 'bar'#0 );" instead >of just "foo ( 'bar' );", so I tend to let things like they are ... The string constant parameter is something that thinks it is (or is pretending to be) a CString. Since CStrings end with a Chr(0), it is probably best to make the string constant do so automatically - otherwise, its pretensions would be found out very quickly. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Mon Apr 28 02:46:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA16410 for ; Mon, 28 Apr 1997 02:46:25 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55206; Mon, 28 Apr 1997 01:44:40 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50578; Mon, 28 Apr 1997 01:44:19 +0200 Received: from mail.osn.de (ns.osn.de [194.77.92.17]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA28976 for ; Mon, 28 Apr 1997 02:40:14 +0300 (EET DST) Received: from news.osn.de (news.osn.de [194.77.92.26]) by mail.osn.de (8.8.2/8.7.3) with ESMTP id BAA19287 for ; Mon, 28 Apr 1997 01:40:07 +0200 (MET DST) Received: (from uucp@localhost) by news.osn.de (8.8.4/8.8.4) id BAA05402 for hut.fi!gpc; Mon, 28 Apr 1997 01:39:27 +0200 (MET DST) >>Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wLbbK-000ohgC; Sun, 27 Apr 97 23:35 MEST Received: from cl.sub.de by news.osn.de; Mon, 28 Apr 1997 01:39 MET Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wLbbK-000ohgC; Sun, 27 Apr 97 23:35 MEST Received: by link-n.cl.sub.de (UUCPfZ V5.75 U005) via ZConnect; 27 Apr 97 22:09:04 +0200 Date: 25 Apr 97 18:27:00 +0100 From: C.WENDT@CHATEAU.cl.sub.de (Christian Wendt) Subject: Legal Change in GPC ? To: gpc@hut.fi Message-Id: <6VZk7FfrRMB@p-wendt.chateau.cl.sub.de> X-Mailer: CrossPoint v3.11 X-Gateway: ZCONNECT UH link-n.cl.sub.de [UUCPfZ V5.75 U005] Content-Type: text Status: RO Am 25.04.97 konnte ich meine Finger einfach nicht von der Tastatur fernhalten... Folgendes kam dabei heraus: Hallo! I wondered how to implement the ability to change colours and write text to Standard output - but I think it's nearly impossible to do this within a Unit - the C - Textcolor doesn't work with the fprintf function that is used in the RTS... I wondered wether it would be legal (in sense of portability and compability...) to change the RTS : Textcolor works if you check wether the file passed to writeln is Stdout - when it is you use cprintf (or putch instead of fwrite). The question is - would it be legal to do such - you could put in a variable (smth like "GPC_ConsoleOutput") to switch in on/off ? Chris --- HomeBox : Chateau - 08677 911940(V.34) 911941(ISDN) ## CrossPoint v3.11 ## From gpc-request@santra.hut.fi Mon Apr 28 19:15:21 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA18280 for ; Mon, 28 Apr 1997 19:15:21 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87048; Mon, 28 Apr 1997 18:13:23 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36496; Mon, 28 Apr 1997 18:13:02 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA28943 for ; Mon, 28 Apr 1997 19:03:47 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id SAA00663 (8.7.6/7.5c-FAU); for ; Mon, 28 Apr 1997 18:03:37 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id SAA16666 (SMI-8.6/7.5b-FAU); Mon, 28 Apr 1997 18:03:36 +0200 From: Frank Heckenbach Message-Id: <199704281603.SAA16666@helena.mi.uni-erlangen.de> Date: Mon, 28 Apr 1997 18:03:35 +0200 To: gpc@hut.fi Subject: Re: CStrings Status: RO Peter Gerwinski wrote: > I encountered some problems with Procedures accepting `CString' > parameters. When passing a string constant to such a parameter, GPC > does *not* automatically add a "chr ( 0 )" terminator. > > Should it do? And if so, in which cases? We always can explicitly write > "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let > things like they are ... I think it should automatically add a #0 terminator. After all, a "CString" without terminator is somewhat undefined. In which cases? I think always when a string constant is given where a "CString" value is expected, whether for a parameter, or a variable initializer. E.g. the following should work as expected: var numbers:array[1..3] of cstring value (1:'one';2:'two';3:'three'); or in BP syntax: const numbers:array[1..3] of pchar=('one','two','three'); Many of my programs rely on this. -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.]@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Apr 28 19:14:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA18275 for ; Mon, 28 Apr 1997 19:14:19 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59346; Mon, 28 Apr 1997 18:12:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72804; Mon, 28 Apr 1997 18:12:01 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA29085 for ; Mon, 28 Apr 1997 19:03:45 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id SAA00668 (8.7.6/7.5c-FAU); for ; Mon, 28 Apr 1997 18:03:42 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id SAA16669 (SMI-8.6/7.5b-FAU); Mon, 28 Apr 1997 18:03:41 +0200 From: Frank Heckenbach Message-Id: <199704281603.SAA16669@helena.mi.uni-erlangen.de> Date: Mon, 28 Apr 1997 18:03:40 +0200 To: gpc@hut.fi Subject: Peter Gerwinski wrote: Status: RO > > Is there a way to change a string's length directly? > > AFAIK, there isn't. Use the `SubStr' function (like BP's `copy' function) > to shorten a string, and the `+' operator to make it longer. Well, the problem is, I said "efficiently". I don't assume, gpc would optimize statements like s:=s+'a' where s is a (possibly quite long) string, so I'd have O(n) where actually O(1) is possible. E.g. the examples from the documentation about converting CStrings to Pascal strings append char by char in a loop -- O(n^2) instead of O(n). I don't think that should be left as it is. > And of course you can take a pointer to the string, cast it to a pointer > to a record the fields of which you can manipulate like you wish ... I'd have to do it like this if there's no other way... But shouldn't it be possible to access the fields of the "string record" in a direct way? Perhaps in the course of the schema project? (Are you planning to make strings regular schema types then -- regular except for the extended syntax that allows s[n]?) -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.]@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon Apr 28 17:07:27 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA18078 for ; Mon, 28 Apr 1997 17:07:26 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45168; Mon, 28 Apr 1997 16:05:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36956; Mon, 28 Apr 1997 16:05:05 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id QAA24016 for ; Mon, 28 Apr 1997 16:52:33 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id QAA18030; Mon, 28 Apr 1997 16:54:20 +0200 From: Peter Gerwinski Message-Id: <199704281454.QAA18030@agnes.dida.physik.uni-essen.de> Subject: Re: Legal Change in GPC ? To: c.wendt@CHATEAU.cl.sub.de, gpc@hut.fi Date: Mon, 28 Apr 1997 16:54:20 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Christian Wendt: > > I wondered how to implement the ability to change colours and write text > to Standard output - but I think it's nearly impossible to do this within > a Unit - the C - Textcolor doesn't work with the fprintf function that is > used in the RTS... Nevertheless I did this. :-) Please have a look at the BPcompat package, available in the `contrib' subdirectory of the GPC distribution. > I wondered wether it would be legal (in sense of > portability and compability...) to change the RTS : Textcolor works if you > check wether the file passed to writeln is Stdout - when it is you use > cprintf (or putch instead of fwrite). You are right that this is a problem we must think about. In this case I think it increases portability and compatibility to do the changes because otherwise it is impossible to get colors under DOS whereas you can have them with Linux or any other system which provides colors as terminal escape sequences, e.g. according to ANSI. > The question is - would it be legal to do such - you could put in a > variable (smth like "GPC_ConsoleOutput") to switch in on/off ? In the BPcompat package or in newer Alpha releases of GPC, this variable exists and is called `p_directvideo', available as `DirectVideo' if you do `uses CRT'. If it is `true', `writeln' is performed through `cprintf', otherwise through `printf'. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon Apr 28 21:12:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA18600 for ; Mon, 28 Apr 1997 21:12:34 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17870; Mon, 28 Apr 1997 20:10:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57974; Mon, 28 Apr 1997 20:10:13 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id VAA32570 for ; Mon, 28 Apr 1997 21:03:17 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id VAA18538 for gpc@hut.fi; Mon, 28 Apr 1997 21:05:13 +0200 From: Peter Gerwinski Message-Id: <199704281905.VAA18538@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Mon, 28 Apr 1997 21:05:12 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Well, the problem is, I said "efficiently". > I don't assume, gpc would optimize statements like > s:=s+'a' > where s is a (possibly quite long) string, so I'd have O(n) where actually > O(1) is possible. I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' and look at `foo.s' ... > E.g. the examples from the documentation about converting > CStrings to Pascal strings append char by char in a loop -- O(n^2) instead > of O(n). I don't think that should be left as it is. You mean the routines in the FAQ? I think they are O(n) because "S:= S + Src^" is inlined and optimized. But of course, feel free to improve those routines and send the result to Jan-Jaap ... ;-) > I'd have to do it like this if there's no other way... > But shouldn't it be possible to access the fields of the "string record" in > a direct way? Perhaps in the course of the schema project? It would not be too difficult to make "MyStr.length" and "MyStr.String" accessible "record fields" of strings. Would it be desireable? I am not sure how this fits into the standard ... Another thing *is* planned: A new data type `ShortString' (or `ShortStr'?) which will be the UCSD/Borland version of Strings. In many contexts, they are better than Extended Pascal string schemata because they have only 1 byte overhead instead of 8. (But this will be a lot of work. Anybody interested to help here???) > (Are you planning > to make strings regular schema types then -- regular except for the extended > syntax that allows s[n]?) No. They are exceptions in yet another way because they have the implicit read-only "length" field. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue Apr 29 16:56:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA20993 for ; Tue, 29 Apr 1997 16:56:26 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05642; Tue, 29 Apr 1997 15:54:15 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA25438; Tue, 29 Apr 1997 15:53:52 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA30255 for ; Tue, 29 Apr 1997 16:32:25 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Tue, 29 Apr 1997 14:33:42 +0100 Received: from [0.25.151.154] by potter.cc.keele.ac.uk; Tue, 29 Apr 1997 14:31:20 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: Modifying string length? Message-Id: Date: Tue, 29 Apr 1997 14:35:06 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Tue, 29 Apr 1997 12:53:53 +0200 Frank Heckenbach wrote: [...] >> It would not be too difficult to make "MyStr.length" and "MyStr.String" >> accessible "record fields" of strings. Would it be desireable? > >Yes! (At least length; the String part is accessible anyway with s[n].) > >> I am >> not sure how this fits into the standard ... > >I'm not, either. If it conflicts, it should be disabled with >"--extended-pascal", I suppose. It should be disabled, with "-borlland-pascal" as well. >> Another thing *is* planned: A new data type `ShortString' (or >> `ShortStr'?) which will be the UCSD/Borland version of Strings. In many >> contexts, they are better than Extended Pascal string schemata because >> they have only 1 byte overhead instead of 8. (But this will be a lot >> of work. Anybody interested to help here???) > >What about another type with a 2 byte length field (2 instead of 8 bytes >overhead)? Will this be BP compatible? >255 chars max length are sometimes not enough. But you can use normal GPC strings for that. >BTW: I heard >Delphi has some kind of long strings. Anyone knows what they are? Only available with 32-bit versions of Delphi. Sort of dynamically allocated strings. Delphi does all the background work itself (allocating, freeing, sizing, resizing, etc). I think they can be up to 2GB in size. Need to be used with care, because all sorts of things can go wrong if you treat them like normal strings. "Almost" compatible with pChars. You can do something like "PChar (MyLongString)" to pass a long string as a parameter to a function that requires a pChar parameter. When used as parameters or function results in a DLL, all programs that use that DLL must use Delphi's memory manager DLL as well. Personally, I wouldn't touch them with a barge pole. I would rather use a pChar, if that is what I want, or a normal string, if that is what I want - and I prefer to allocate and free memory for data structures myself. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue Apr 29 14:16:30 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA20372 for ; Tue, 29 Apr 1997 14:16:29 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60742; Tue, 29 Apr 1997 13:14:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA24862; Tue, 29 Apr 1997 13:13:52 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA22132 for ; Tue, 29 Apr 1997 13:53:59 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id MAA21536 (8.7.6/7.5c-FAU); for ; Tue, 29 Apr 1997 12:53:55 +0200 (MET DST) Received: from charybdis by mi.uni-erlangen.de with SMTP; id MAA20241 (SMI-8.6/7.5b-FAU); Tue, 29 Apr 1997 12:53:54 +0200 From: Frank Heckenbach Message-Id: <199704291053.MAA20241@helena.mi.uni-erlangen.de> Date: Tue, 29 Apr 1997 12:53:53 +0200 To: gpc@hut.fi Subject: Re: Modifying string length? Status: RO > I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' > and look at `foo.s' ... Fine! I'll take a look at it. > It would not be too difficult to make "MyStr.length" and "MyStr.String" > accessible "record fields" of strings. Would it be desireable? Yes! (At least length; the String part is accessible anyway with s[n].) > I am > not sure how this fits into the standard ... I'm not, either. If it conflicts, it should be disabled with "--extended-pascal", I suppose. > Another thing *is* planned: A new data type `ShortString' (or > `ShortStr'?) which will be the UCSD/Borland version of Strings. In many > contexts, they are better than Extended Pascal string schemata because > they have only 1 byte overhead instead of 8. (But this will be a lot > of work. Anybody interested to help here???) What about another type with a 2 byte length field (2 instead of 8 bytes overhead)? 255 chars max length are sometimes not enough. BTW: I heard Delphi has some kind of long strings. Anyone knows what they are? > > (Are you planning > > to make strings regular schema types then -- regular except for the extended > > syntax that allows s[n]?) > > No. They are exceptions in yet another way because they have the > implicit read-only "length" field. That's what I meant. If length was made accessible in a normal way, it would not be an exception. -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.]@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Wed Apr 30 00:47:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21869 for ; Wed, 30 Apr 1997 00:47:40 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83384; Tue, 29 Apr 1997 23:45:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64464; Tue, 29 Apr 1997 23:45:06 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA03683 for ; Wed, 30 Apr 1997 00:39:46 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA21829 for gpc@hut.fi; Wed, 30 Apr 1997 00:41:52 +0200 From: Peter Gerwinski Message-Id: <199704292241.AAA21829@agnes.dida.physik.uni-essen.de> Subject: What is standard, and what isn't? To: gpc@hut.fi Date: Wed, 30 Apr 1997 00:41:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, perhaps somebody can help to clarify the following two questions: 1) Is the comparision with `=' or `<>' of structured variables okay in ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared must be compatible. If not, this might be a reasonable extension (already offered by some compilers, *not* including Borland Pascal;). 2) In GPC strings, the schema discriminant "Capacity" is accessible as a "record field" of the string. Is this okay by ISO 10206, and should it be done for other schemata this way, too? And how to tread the "length" field of a string? ISO 10206 6.4.3.3 does not say anything about that. I could imagine the string schema type to be something similar to Type String ( Capacity: Integer ) = record length: Integer; String: packed array [ 1..Capacity ] of Char; end (* String *); except that the "String" field is automatically dereferenced. Thanks for your help, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 00:47:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21864 for ; Wed, 30 Apr 1997 00:47:22 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA109730; Tue, 29 Apr 1997 23:45:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30904; Tue, 29 Apr 1997 23:44:48 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA07026 for ; Wed, 30 Apr 1997 00:39:46 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA21823 for gpc@hut.fi; Wed, 30 Apr 1997 00:41:36 +0200 From: Peter Gerwinski Message-Id: <199704292241.AAA21823@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Wed, 30 Apr 1997 00:41:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > > > No. They are exceptions in yet another way because they have the > > implicit read-only "length" field. > > That's what I meant. If length was made accessible in a normal way, it > would not be an exception. Being an array schema, the presence of the implicit "length" field would make the string an exception. Being a record schema, the implicit dereference of the "string" field when indexing the string makes it an exception. No way out. (However see my other mail.) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 00:46:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21860 for ; Wed, 30 Apr 1997 00:46:06 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA109688; Tue, 29 Apr 1997 23:43:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30792; Tue, 29 Apr 1997 23:43:31 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA06469 for ; Wed, 30 Apr 1997 00:38:56 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA21806 for gpc@hut.fi; Wed, 30 Apr 1997 00:41:07 +0200 From: Peter Gerwinski Message-Id: <199704292241.AAA21806@agnes.dida.physik.uni-essen.de> Subject: Short strings (Was: Modifying string length?) To: gpc@hut.fi Date: Wed, 30 Apr 1997 00:41:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to The African Chief: > According to Frank Heckenbach: > >255 chars max length are sometimes not enough. > But you can use normal GPC strings for that. Just my point: For applications where you need looooong strings, GPC's <=2GB strings with 8 bytes of overhead are perfect. In those cases where you must save space, 255 characters are fine - and they are compatible to UCSD and Borland Pascal. Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' instead of `LongInteger' I would vote for `ShortStr'; OTOH, Prospero's Extended Pascal compiler (PEP) has `ShortString' for this ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 00:59:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA21924 for ; Wed, 30 Apr 1997 00:59:33 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA109728; Tue, 29 Apr 1997 23:57:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30926; Tue, 29 Apr 1997 23:56:58 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA06740 for ; Wed, 30 Apr 1997 00:51:32 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id AAA21908 for gpc@hut.fi; Wed, 30 Apr 1997 00:53:42 +0200 From: Peter Gerwinski Message-Id: <199704292253.AAA21908@agnes.dida.physik.uni-essen.de> Subject: Re^3: Legal Change in GPC ? To: gpc@hut.fi Date: Wed, 30 Apr 1997 00:53:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Christian Wendt: > :-) I do the work and get common to the RTS C source (which is very vell > readable!) - and then learn all the work has been done... Oh - sorry! Since an improved BPcompat package for DOS (DJGPP) will be released soon, what about facing Linux instead? Sven's BGI2GRX (Graph) Unit runs under Linux, but we have no CRT yet ... > PG>available in the `contrib' subdirectory of the GPC distribution. > BPCompat.pas is in my contrib subdirectory... but only "highlevel" > functions... The same stuff as in Borland's CRT, isn't it? > not "impossible"- you only got to reinvent the wheel and write to > $b80000... _big_ loss in portability & comfort (no easy to call writeln. Nevertheless this will remain my preferred method in BO5. The fastest thing you can imagine on the DOS platform. > BTW - is there a way to make a procedure to have a variable count of > parameters? (as writeln) - e.g. would it be possible to define to "C" > printf procedure within pascal ?) Yes and no: You can define a "Procedure Foo ( a, b: Integer; ... );" with a triple dot indicating a variable number of subsequent arguments, but I have not yet found out how to access them ... > But i think that even there it would be quite more comfortable to use > Textcolor instead of write(chr(27)+'[5;33m'); or such... Of course. But a CRT Unit could use these sequences to access the terminal in a portable way. > exactly what I had in mind... don't kill it from the alphas :-) Don't worry. If things develop as I hope, we will enter beta stage soon ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 01:51:53 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA22039 for ; Wed, 30 Apr 1997 01:51:52 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79250; Wed, 30 Apr 1997 00:49:38 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40782; Wed, 30 Apr 1997 00:49:17 +0200 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA07700 for ; Wed, 30 Apr 1997 01:44:55 +0300 (EET DST) Received: from default (van0318.tvs.net [204.191.197.88]) by mercury.uniserve.com with SMTP id PAA29889 for ; Tue, 29 Apr 1997 15:44:23 -0700 (PDT) Message-Id: <3.0.1.32.19970429154410.00694e5c@cybermail.net> X-Sender: s_c@cybermail.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 29 Apr 1997 15:44:10 -0700 To: gpc@hut.fi From: skye Subject: exit; ???? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Is Exit not included in GPC? i.e. program test; procedure t1(a:integer); begin writeln('hello1'); if a = 1 then exit; writeln('hello2'); end; begin writeln('hello'); t1(1); t1(0); writeln('hello3'); end. should produce: hello hello1 hello1 hello2 hello3 but I get Undefined Indentifier 'Exit' I tried using return; and that works. I posted this question to the comp.lang.pascal NG and had someone from Borland tell me that Exit should do the trick (I didn't say I wasn't using TP tho). Is exit a Borland thing? -SC From gpc-request@santra.hut.fi Wed Apr 30 02:00:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA22091 for ; Wed, 30 Apr 1997 02:00:45 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA82882; Wed, 30 Apr 1997 00:58:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68188; Wed, 30 Apr 1997 00:58:09 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA03745 for ; Wed, 30 Apr 1997 01:54:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA22080 for gpc@hut.fi; Wed, 30 Apr 1997 01:57:04 +0200 From: Peter Gerwinski Message-Id: <199704292357.BAA22080@agnes.dida.physik.uni-essen.de> Subject: Re: exit; ???? To: gpc@hut.fi Date: Wed, 30 Apr 1997 01:57:04 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to skye: > > Is Exit not included in GPC? i.e. > [...] > I tried using return; and that works. GPC 2.0 only has `return'; newer alpha versions also have `exit'. > I posted this question to the comp.lang.pascal NG and had someone from > Borland tell me that Exit should do the trick (I didn't say I wasn't using > TP tho). :-) > Is exit a Borland thing? It's an UCSD extension. Borland Pascal is based a lot on UCSD Pascal (Units, Strings, Exit, ...). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 11:37:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA24071 for ; Wed, 30 Apr 1997 11:37:34 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA103508; Wed, 30 Apr 1997 10:35:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76890; Wed, 30 Apr 1997 10:34:51 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id LAA18351 for ; Wed, 30 Apr 1997 11:30:09 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Wed, 30 Apr 1997 09:31:44 +0100 Received: from [0.8.203.134] by potter.cc.keele.ac.uk; Wed, 30 Apr 1997 09:30:00 +0100 From: The African Chief To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Short strings (Was: Modifying string length?) Message-Id: Date: Wed, 30 Apr 1997 09:34:11 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Wed, 30 Apr 1997 00:41:07 +0200 (MET DST) Peter Gerwinski wrote: >According to The African Chief: >> According to Frank Heckenbach: >> >255 chars max length are sometimes not enough. >> But you can use normal GPC strings for that. > >Just my point: For applications where you need looooong strings, GPC's ><=2GB strings with 8 bytes of overhead are perfect. In those cases >where you must save space, 255 characters are fine - and they are >compatible to UCSD and Borland Pascal. > >Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' >instead of `LongInteger' I would vote for `ShortStr'; OTOH, Prospero's >Extended Pascal compiler (PEP) has `ShortString' for this ... Delphi also has "ShortString" - so perhaps we should use that. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Wed Apr 30 10:28:08 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA23914 for ; Wed, 30 Apr 1997 10:28:08 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA18668; Wed, 30 Apr 1997 09:25:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31518; Wed, 30 Apr 1997 09:25:28 +0200 Received: from hil-img-10.compuserve.com (hil-img-10.compuserve.com [149.174.177.140]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id KAA15221 for ; Wed, 30 Apr 1997 10:21:09 +0300 (EET DST) Received: by hil-img-10.compuserve.com (8.6.10/5.950515) id DAA21028; Wed, 30 Apr 1997 03:20:38 -0400 Date: Wed, 30 Apr 1997 03:19:22 -0400 From: Berend de Boer Subject: Re: Short strings (Was: Modifying string length?) To: "'gpc'" Message-Id: <199704300318_MC2-15AF-EFB0@compuserve.com> Status: RO You wrote: >Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' Borland uses ShortString in Delphi so I go for ShortString. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Apr 30 10:28:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA23909 for ; Wed, 30 Apr 1997 10:28:01 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA106208; Wed, 30 Apr 1997 09:25:41 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31510; Wed, 30 Apr 1997 09:25:21 +0200 Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com [149.174.177.136]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id KAA15641 for ; Wed, 30 Apr 1997 10:21:37 +0300 (EET DST) Received: by hil-img-6.compuserve.com (8.6.10/5.950515) id DAA19661; Wed, 30 Apr 1997 03:21:06 -0400 Date: Wed, 30 Apr 1997 03:19:28 -0400 From: Berend de Boer Subject: Re: What is standard, and what isn't? To: "'gpc'" Message-Id: <199704300320_MC2-15AF-EFB2@compuserve.com> Status: RO Peter Gerwinski wrote: >1) Is the comparision with `=' or `<>' of structured variables okay in > ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared > must be compatible. No, see the table in 6.8.3.5. And I see quite some problems in implementing this correctly. A simple byte compare won't do except in the most easiest of cases. If you want something 'difficult' to do , implement integer and string value arrays :-) >2) In GPC strings, the schema discriminant "Capacity" is accessible > as a "record field" of the string. Is this okay by ISO 10206, > and should it be done for other schemata this way, too? Certainly: see the examples in 6.8.4 And how >to > tread the "length" field of a string? ISO 10206 6.4.3.3 does not > say anything about that. I could imagine the string schema type >to > be something similar to > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity ] of Char; > end (* String *); > > except that the "String" field is automatically dereferenced. I think one implements it as: Type String ( Capacity: Integer ) = record length: Integer; String: packed array [ 1..Capacity+SizeOf(Char) ] of Char; end (* String *); +1 to allow for a trailing zero (or zero's in case of Unicode...). However length is not specified in the standard, so it should not be accessible with Extended Pascal. You can always use length(MyStr) to achieve the same functionality. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Apr 30 09:09:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA23168 for ; Wed, 30 Apr 1997 09:09:13 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56146; Wed, 30 Apr 1997 08:06:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA65392; Wed, 30 Apr 1997 08:06:35 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id IAA07806 for ; Wed, 30 Apr 1997 08:58:31 +0300 (EET DST) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id IAA155202 for ; Wed, 30 Apr 1997 08:31:33 +0300 Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id CAA11599 (8.7.6/7.5c-FAU); for ; Wed, 30 Apr 1997 02:52:47 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id CAA22889 (SMI-8.6/7.5b-FAU); Wed, 30 Apr 1997 02:52:46 +0200 From: Frank Heckenbach Message-Id: <199704300052.CAA22889@helena.mi.uni-erlangen.de> Date: Wed, 30 Apr 1997 02:52:45 +0200 To: gpc@hut.fi Subject: Re: Modifying string length? Status: RO > I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' > and look at `foo.s' ... Hmmm... well, I could not see the effect. I wrote the following test program: program x; var s:string[10000]; begin s:=''; s:=s+'a' end. I compiled it with "-O3 -S". The resulting code contained two calls to _memcpy. Another test program that appended characters in a loop obviously ran in O(n^2). Am I missing something? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From berend@compuserve.com Mon Apr 28 12:32:23 1997 Return-Path: berend@compuserve.com Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [149.174.217.132]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with ESMTP id MAA17629 for ; Mon, 28 Apr 1997 12:32:18 +0200 Received: by arl-img-2.compuserve.com (8.6.10/5.950515) id FAA02995; Mon, 28 Apr 1997 05:30:26 -0400 Date: Mon, 28 Apr 1997 05:29:34 -0400 From: Berend de Boer Subject: Re: CStrings To: "'Peter Gerwinski'" Message-ID: <199704280528_MC2-1584-8733@compuserve.com> Status: RO You wrote: >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. I think it should. Much less confusing, probably more portable and in Extended Pascal #0 is not recognized, so means a few characters more typing pain. Another solution, whith less performance impact would be to always add a chr(0) to a string constant at compile time. I think I favor this approach. The length returned should be the length minus chr(0) but the chr(0) should be there. Groetjes, Berend. From gpc-request@santra.hut.fi Wed Apr 30 13:15:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA24283 for ; Wed, 30 Apr 1997 13:15:34 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85956; Wed, 30 Apr 1997 12:13:13 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30846; Wed, 30 Apr 1997 12:12:52 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id NAA22778 for ; Wed, 30 Apr 1997 13:06:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA24232 for gpc@hut.fi; Wed, 30 Apr 1997 13:09:09 +0200 From: Peter Gerwinski Message-Id: <199704301109.NAA24232@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi (GPC mailing list) Date: Wed, 30 Apr 1997 13:09:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Hmmm... well, I could not see the effect. I wrote the following test program: > [...] > I compiled it with "-O3 -S". The resulting code contained two calls to > _memcpy. [...] Ah - I was wrong, sorry. The string addition is optimized, but it is done on a temporary variable, and the assignment to that guy is *not* optimized. Maybe this can be changed ... I will have a look at that. (But not now.) (* By the way: Good news for all friends of schemata! They might be finished (except, of course, bugs) this week ... *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 13:14:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA24272 for ; Wed, 30 Apr 1997 13:14:49 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA85856; Wed, 30 Apr 1997 12:12:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78358; Wed, 30 Apr 1997 12:12:04 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id NAA07199 for ; Wed, 30 Apr 1997 13:07:13 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA24240 for gpc@hut.fi; Wed, 30 Apr 1997 13:09:32 +0200 From: Peter Gerwinski Message-Id: <199704301109.NAA24240@agnes.dida.physik.uni-essen.de> Subject: Re: What is standard, and what isn't? To: gpc@hut.fi Date: Wed, 30 Apr 1997 13:09:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend de Boer: > If you want something 'difficult' to do , implement integer and string > value arrays :-) Not too difficult: Integer arrays can be treated by a simple byte compare; for string arrays the compiler must generate a loop. This can be done for records, too: The compiler can do a loop through the fields of the record. (User programs cannot do that. :-P) > Certainly: see the examples in 6.8.4 Thanks a lot! I didn't find that. Why wasn't there a single word about this in 6.4.7, 6.4.8??? > I think one implements it as: > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity+SizeOf(Char) ] of Char; > end (* String *); It's "1..Capacity + 1". (Increasing the index by one adds one char.) (And it's still an exception since you write "MyStr [ i ]", not "MyStr.String [ i ]".) > However length is not specified in the standard, so it should not be > accessible with Extended Pascal. You can always use length(MyStr) to > achieve the same functionality. What about the following: * Default mode (and Extended Pascal mode): The length field cannot be accessed (except with "length ( MyStr )".) * With extended syntax (*$X+*): The length field can be read- and write-accessed. Okay like that? Or perhaps better to have it in default mode, too, and to switch it OFF in Extended Pascal mode? I think it's best as above because you should assign a new length to a string only if you know exactly what you are doing. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed Apr 30 20:44:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id UAA25198 for ; Wed, 30 Apr 1997 20:44:01 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08540; Wed, 30 Apr 1997 19:41:33 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA30664; Wed, 30 Apr 1997 19:41:12 +0200 Received: from arl-img-1.compuserve.com (arl-img-1.compuserve.com [149.174.217.131]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA00369 for ; Wed, 30 Apr 1997 20:35:54 +0300 (EET DST) Received: by arl-img-1.compuserve.com (8.6.10/5.950515) id NAA16542; Wed, 30 Apr 1997 13:35:23 -0400 Date: Wed, 30 Apr 1997 13:34:05 -0400 From: Berend de Boer Subject: Re: What is standard, and what isn't? To: "'gpc'" Message-Id: <199704301333_MC2-15B3-625B@compuserve.com> Status: RO Peter Gerwinski wrote: >Not too difficult: Integer arrays can be treated by a simple byte >compare; for string arrays the compiler must generate a loop. I thought that was a lot of work, but it seems I was wrong :-) >> Certainly: see the examples in 6.8.4 > >Thanks a lot! I didn't find that. Why wasn't there a single word >about >this in 6.4.7, 6.4.8??? No idea. Just like a lot of other topics treatment is fairly sparse. We need to have everything in one place. Maybe I should write an Extended Pascal programmers book :-) >What about the following: > > * Default mode (and Extended Pascal mode): The length field cannot > be accessed (except with "length ( MyStr )".) > > * With extended syntax (*$X+*): The length field can be read- and > write-accessed. I don't care, because I don't see the need for accessing the length field directory, as long as it is not available in Extended Pascal mode :-) Groetjes, Berend. From gpc-request@santra.hut.fi Wed Apr 30 17:33:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA24866 for ; Wed, 30 Apr 1997 17:33:36 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77572; Wed, 30 Apr 1997 16:31:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62850; Wed, 30 Apr 1997 16:30:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id RAA29564 for ; Wed, 30 Apr 1997 17:26:05 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id RAA24835 for gpc@hut.fi; Wed, 30 Apr 1997 17:28:27 +0200 From: Peter Gerwinski Message-Id: <199704301528.RAA24835@agnes.dida.physik.uni-essen.de> Subject: Re: Short strings (Was: Modifying string length?) To: gpc@hut.fi Date: Wed, 30 Apr 1997 17:28:27 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Stephen Lindholm: > [`ShortStr' or `ShortString'?] > How about supporting both? Since PEP and Delphi agree that this is called `ShortString', I conclude that we should use that, too. However it will take some time until it will be implemented: All string types must be compatible with each other in assignments, comparisions, etc., and all string routines will have to accept all sorts of strings. (Well ... at least some of them will accept all sorts; others might be okay to support EP's long strings only.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer Reply e-mail to "uni-essen" http://home.pages.de/~peter.gerwinski/ [970201] instead of "NO-SPAM-PLEASE". maintainer GNU Pascal [970412] kampi.hut.fi/gpc Sorry for the inconvenience. http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 1 04:02:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA25748 for ; Thu, 1 May 1997 04:02:57 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA21606; Thu, 1 May 1997 03:00:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41444; Thu, 1 May 1997 03:00:02 +0200 Received: from mail1.sn.no (0@mail1.sn.no [194.143.8.8]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA18212 for ; Thu, 1 May 1997 03:51:13 +0300 (EET DST) Received: from mail2.sn.no (0@mail2.sn.no [194.143.8.114]) by mail1.sn.no (8.7.5/8.7.3/on4) with ESMTP id for ; Thu, 1 May 1997 02:51:06 +0200 (MET DST) Received: from norsk (norsk@aksess-gw2-9.ppp.sn.no [194.143.7.106]) by mail2.sn.no (8.8.4/8.8.4/1.5) with SMTP id for ; Thu, 1 May 1997 02:50:28 +0200 (MET DST) Message-Id: <199705010050.CAA27737@mail2.sn.no> Comments: Authenticated sender is From: "Kim Robert Blix" To: gpc@hut.fi Date: Thu, 1 May 1997 02:35:11 +0000 Subject: ShortStr Priority: normal In-Reply-To: <3.0.1.32.19970429154410.00694e5c@cybermail.net> X-Mailer: Pegasus Mail for Win32 (v2.52) Status: RO When it comes to compability on the issue of strings, would'nt it be natural to call the short string version just "string" and the long one "longstr", instead of the other way around? This means Programs originally made for Borland will run just fine, (since borland (and i belive) the rest) have 255 byte strings) and will compile more like they where intended to do. Seems logical to me :) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kim Robert Blix ( kblix@sn.no & http://home.sn.no/~kblix ) "How do you shoot the devil in the back?" "What if you miss?" -Verbal Kint =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From gpc-request@santra.hut.fi Thu May 1 11:43:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA26788 for ; Thu, 1 May 1997 11:43:18 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20030; Thu, 1 May 1997 10:40:40 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37178; Thu, 1 May 1997 10:40:20 +0200 Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id LAA07172 for ; Thu, 1 May 1997 11:35:53 +0300 (EET DST) Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id EAA08394; Thu, 1 May 1997 04:35:22 -0400 Date: Thu, 1 May 1997 04:34:20 -0400 From: Berend de Boer Subject: Re: ShortStr To: "'gpc'" Message-Id: <199705010433_MC2-15BC-A24@compuserve.com> Status: RO "Kim Robert Blix" wrote: >When it comes to compability on the issue of strings, would'nt it be >natural to call the short string version just "string" and the long >one "longstr", instead of the other way around? I think natural should mean the one with the least restrictions. Integers are 32-bit, not 16-bit, strings are unlimited, instead of limited, etc, etc. And this is more compatible with Delphi 2. Groetjes, Berend. From gpc-request@santra.hut.fi Thu May 1 11:33:31 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA26777 for ; Thu, 1 May 1997 11:33:31 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA109102; Thu, 1 May 1997 10:30:53 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63018; Thu, 1 May 1997 10:30:32 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id LAA06350 for ; Thu, 1 May 1997 11:22:12 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id KAA01579 (8.7.6/7.5c-FAU); for ; Thu, 1 May 1997 10:22:09 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id EAA29018 (SMI-8.6/7.5b-FAU); Thu, 1 May 1997 04:12:48 +0200 From: Frank Heckenbach Message-Id: <199705010212.EAA29018@helena.mi.uni-erlangen.de> Date: Thu, 1 May 1997 04:12:47 +0200 To: gpc@hut.fi Subject: Re: Modifying string length? Status: RO The African Chief wrote: > >> It would not be too difficult to make "MyStr.length" and "MyStr.String" > >> accessible "record fields" of strings. Would it be desireable? > > > >Yes! (At least length; the String part is accessible anyway with s[n].) > > > >> I am > >> not sure how this fits into the standard ... > > > >I'm not, either. If it conflicts, it should be disabled with > >"--extended-pascal", I suppose. > > It should be disabled, with "-borlland-pascal" as well. But how would you translate references to s[0] in BP then? I know, there shouldn't be any in most programs, but sometimes it can be useful, e.g. for efficiency. But it's ok for me if it's only enabled with {$X+}, see below. Peter Gerwinski wrote: > 2) In GPC strings, the schema discriminant "Capacity" is accessible > as a "record field" of the string. Is this okay by ISO 10206, > and should it be done for other schemata this way, too? And how to > tread the "length" field of a string? ISO 10206 6.4.3.3 does not > say anything about that. I could imagine the string schema type to > be something similar to > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity ] of Char; > end (* String *); > > except that the "String" field is automatically dereferenced. Oh - I thought a string was like this already. (My previous mails were based on this assumption.) I think I read this somewhere, but don't remember where. But, a *packed* array? If I remember correctly, it's not possible to get an address of a component of a packed record/array (because they could possibly not start on a byte boundary) (but when trying it, I encountered some problems, see below). If this is so (and won't be changed so that it is possible to get an address of those components that actually start on a byte boundary), I'd vote for an un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at least with Linux), an un-packed array of char is exactly as big as a packed one. Is this not always so? > It's "1..Capacity + 1". (Increasing the index by one adds one char.) > > +1 to allow for a trailing zero (or zero's in case of Unicode...). Does this mean strings will always have an additional trailing #0? Do the string routines currently support this (i.e. automatically add a #0 at the end; but they should not recognize #0 as a terminator, but only rely on the length field)? That would be good, because it simplifies converting a string into a CString a lot (just "CString(@s[1])", right?). > What about the following: > > * Default mode (and Extended Pascal mode): The length field cannot > be accessed (except with "length ( MyStr )".) > > * With extended syntax (*$X+*): The length field can be read- and > write-accessed. > > Okay like that? Or perhaps better to have it in default mode, too, > and to switch it OFF in Extended Pascal mode? I think it's best as > above because you should assign a new length to a string only if you > know exactly what you are doing. Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off around code that needs it, and be safe from accidents elsewhere). It would be even better than BP (where accidental writes to s[0] are not even detected by range checking). :-) BTW: Should the field be called "length" like the function length? It might give conflicts with "with" statements ("with" works with schemata, doesn't it?) as in: with dest_str do begin length:=length(src_str); ... end; Perhaps something like str_length or such? > (* By the way: Good news for all friends of schemata! They might be > finished (except, of course, bugs) this week ... *) What? The bugs will not be finished? What an omission! ;-) As I said above, I had some problems with the new packed arrays. I tried the following: program t; var q:packed array [1..10] of boolean; y:^boolean; begin y:=@q[3] end. and it compiled (though I think it shouldn't), giving quite a strange result in y. Then I did: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@q[i] end. gpc said "invalid lvalue in unary &". Though this shoudln't compile, this error message seems strange to me. I'd have expected "Attempt to take address of bit-field structure member", as with packed records. Next I tried: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@(q[i]) end. The result was: "parse error before '('" and some more error messages. (The same with an un-packed array here.) Should the "()" be allowed here (though not required)? FWIW, TP5.5 doesn't allow them, BP7.0 does... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu May 1 07:40:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA26608 for ; Thu, 1 May 1997 07:40:41 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94444; Thu, 1 May 1997 06:38:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74894; Thu, 1 May 1997 06:37:46 +0200 Received: from mail.osn.de (ns.osn.de [194.77.92.17]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id HAA04966 for ; Thu, 1 May 1997 07:32:37 +0300 (EET DST) Received: from news.osn.de (news.osn.de [194.77.92.26]) by mail.osn.de (8.8.2/8.7.3) with ESMTP id GAA24796 for ; Thu, 1 May 1997 06:32:27 +0200 (MET DST) Received: (from uucp@localhost) by news.osn.de (8.8.4/8.8.4) id GAA17997 for HUT.FI!GPC; Thu, 1 May 1997 06:31:41 +0200 (MET DST) >>Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wMj0N-000oUvC; Thu, 1 May 97 01:41 MEST Received: from cl.sub.de by news.osn.de; Thu, 1 May 1997 06:31 MET Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wMj0N-000oUvC; Thu, 1 May 97 01:41 MEST Received: by link-n.cl.sub.de (UUCPfZ V5.75 U005) via ZConnect; 1 May 97 00:11:57 +0200 Date: 30 Apr 97 19:20:00 +0100 From: A.ECKLEDER@CHATEAU.cl.sub.de (Andreas Eckleder) Subject: problem with gpclib.a (alpha-version)... To: GPC@HUT.FI Message-Id: <6VsMAFz7CfB@p-andy.chateau.cl.sub.de> X-Mailer: CrossPoint v3.1 X-Gateway: ZCONNECT UH link-n.cl.sub.de [UUCPfZ V5.75 U005] Content-Type: text Status: RO A.Eckleder@chateau.cl.sub.de / oh no,some e-mail ... by ME!!! To: GPC@HUT.FI (Gpc) ---------------------------------------------------------------------- ...i've got some problem with the library file of the actual (?!?) alphaversion of gnu-pascal... obviousely there's some problem in string-management (gpc2.0 libs do well) here's some sample code: type normstr=string[255]; {also tested with different string lengths} function strng(z:real):normStr; {convert number to string} var s:normstr; k:byte; neg:boolean; begin k:=0; while (z<>int(z)) and (k<5) do begin z:=z*10; inc (k); end; s:='';if z<0 then neg:=true else neg:=false; z:=int(abs(z)); if z=0 then s:='0'; while z>0 do begin s:=chr(trunc(z-int(z/10)*10)+48)+s; z:=int(z/10); end; if k>0 then s:=copy(s,1,length(s)-k)+'.'+copy(s,length(s)-k+1,k); if neg then s:='-'+s; strng:=s; end; as far as i could analyse the problem,the error occurs within the s:=chr(trunc(z-int(z/10)*10)+48)+s; expression. i know that this is not very optimized code,but it normally works fine though. the other problem i realized with this alpha-version is that i couldn't manage to use the inline assembler. i only only got a message telling me function asm() not beeing existent. because of this strong behavior i use the gpc2.0 compiler with the alpha- libraries...perhaps THIS is the reason why the function above doesn't work, but i am not quite sure about that... andy /------------------- A.ECKLEDER@CHATEAU.CL.SUB.DE --------------------\ Who is 'General Failure' - And why is he reading my harddisk ? \------------------ Andreas Eckleder@2:2480/816.32 -------------------/ ## CrossPoint v3.1 ## From gpc-request@santra.hut.fi Thu May 1 12:54:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA26898 for ; Thu, 1 May 1997 12:54:42 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37620; Thu, 1 May 1997 11:52:03 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA28872; Thu, 1 May 1997 11:51:43 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA07069 for ; Thu, 1 May 1997 12:47:13 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Thu, 1 May 1997 10:48:32 +0100 Received: from [0.22.74.174] by potter.cc.keele.ac.uk; Thu, 1 May 1997 10:46:17 +0100 From: The African Chief To: Frank Heckenbach Cc: gpc@hut.fi Subject: Re: Modifying string length? Message-Id: Date: Thu, 1 May 1997 10:50:32 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Thu, 1 May 1997 04:12:47 +0200 Frank Heckenbach wrote: > >The African Chief wrote: > >> >> It would not be too difficult to make "MyStr.length" and "MyStr.String" >> >> accessible "record fields" of strings. Would it be desireable? >> > >> >Yes! (At least length; the String part is accessible anyway with s[n].) >> > >> >> I am >> >> not sure how this fits into the standard ... >> > >> >I'm not, either. If it conflicts, it should be disabled with >> >"--extended-pascal", I suppose. >> >> It should be disabled, with "-borlland-pascal" as well. > >But how would you translate references to s[0] in BP then? I know, there >shouldn't be any in most programs, but sometimes it can be useful, e.g. for >efficiency. But it's ok for me if it's only enabled with {$X+}, see below. "s[0] := ..." is okay. I do that myself sometimes (but only to set the length to zero). What I was referring to was something like; "length(s) := ...." or "s.length := ..." - which shouldn't compile (if at all), when using "--borland-pascal". >Does this mean strings will always have an additional trailing #0? Do the >string routines currently support this (i.e. automatically add a #0 at the >end; but they should not recognize #0 as a terminator, but only rely on the >length field)? That would be good, because it simplifies converting a string >into a CString a lot (just "CString(@s[1])", right?). Delphi 2 does this with long strings (I think). If we are going to do it, perhaps it should only be done for long strings as well? However, what happens when you want to add a string to the end of it? Check this example, and look at the ouput under Borland; program Fred; var s,s1:string[40]; begin s := 'Fred Smith'+#0; s1 := s + 'is okay'; writeln ( s1 ); {prints "Fred Smith is okay" - where did the space before "okay" come from? I didn't want or put it there - viz; problem with trailing "#0"} end. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Thu May 1 12:42:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA26890 for ; Thu, 1 May 1997 12:42:18 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA21664; Thu, 1 May 1997 11:39:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47782; Thu, 1 May 1997 11:39:19 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA07609 for ; Thu, 1 May 1997 12:35:04 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Thu, 1 May 1997 10:36:14 +0100 Received: from [0.10.233.232] by potter.cc.keele.ac.uk; Thu, 1 May 1997 10:33:50 +0100 From: The African Chief To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: ShortStr Message-Id: Date: Thu, 1 May 1997 10:38:06 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Thu, 1 May 1997 12:29:09 +0200 (MET DST) Peter Gerwinski wrote: > finally introduce more options >`--short-strings' and `--long-strings' to change these defaults? I think this is the key! Introduce a "--short-strings" ( or "{$H-}" ) or whatever, to turn off the default (which should be long strings - because it ensures more compatibility with EP and Delphi 2). I believe that Delphi 2 automatically terminates long strings with a "Chr(0)". Perhaps we should do this as well? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Thu May 1 12:37:10 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA26880 for ; Thu, 1 May 1997 12:37:10 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19970; Thu, 1 May 1997 11:34:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63188; Thu, 1 May 1997 11:34:11 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA07097 for ; Thu, 1 May 1997 12:26:33 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id MAA26864 for gpc@hut.fi; Thu, 1 May 1997 12:29:09 +0200 From: Peter Gerwinski Message-Id: <199705011029.MAA26864@agnes.dida.physik.uni-essen.de> Subject: Re: ShortStr To: gpc@hut.fi Date: Thu, 1 May 1997 12:29:09 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Kim Robert Blix: > > When it comes to compability on the issue of strings, would'nt it be > natural to call the short string version just "string" and the long > one "longstr", instead of the other way around? This would break compatibility to the Extended Pascal standard. But it could be reasonable to do it like you wrote in `--ucsd-pascal' and `--borland-pascal' mode. What about the following: Make `LongString' denote Extended Pascal string schemata, and `ShortString' denote UCSD/Borland Pascal strings; let `String' be the same as `LongString' in default mode but the same as `ShortString' in Borland Pascal mode; finally introduce more options `--short-strings' and `--long-strings' to change these defaults? Another idea, perhaps even better: let "String ( 255 )" or "LongString ( 255 )" denote an Extended Pascal (long) string, but "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short) string? Like this, both Extended Pascal and Borland Pascal programs will just compile. Needless to say that `--extended-pascal' will switch off "String [ 255 ]" and `--borland-pascal' will switch off "String ( 255 )" ... Anyway, this is a long-term plan. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 1 13:08:42 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA26962 for ; Thu, 1 May 1997 13:08:42 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA94440; Thu, 1 May 1997 12:06:03 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48876; Thu, 1 May 1997 12:05:42 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA07362 for ; Thu, 1 May 1997 12:58:19 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA26935 for gpc@hut.fi; Thu, 1 May 1997 13:00:56 +0200 From: Peter Gerwinski Message-Id: <199705011100.NAA26935@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Thu, 1 May 1997 13:00:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > But how would you translate references to s[0] in BP then? I know, there > shouldn't be any in most programs, but sometimes it can be useful, e.g. for > efficiency. But it's ok for me if it's only enabled with {$X+}, see below. That's one reason why `StortString's should be implemented - which will have "s[0]". But this job doesn't have high priority for me ... > But, a *packed* array? If I remember correctly, it's not possible to get an > address of a component of a packed record/array (because they could possibly > not start on a byte boundary) (but when trying it, I encountered some > problems, see below). Actually, packed arrays of chars are the same as non-packed arrays. Right now, GPC does not check whether you take the address of a packed array member, so it works with packed arrays of chars, and produces nonsense with Booleans (see below). > If this is so (and won't be changed so that it is possible to get an address > of those components that actually start on a byte boundary), I'd vote for an > un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at > least with Linux), an un-packed array of char is exactly as big as a packed > one. Is this not always so? Extended Pascal requires "packed" here. > Does this mean strings will always have an additional trailing #0? Do the > string routines currently support this (i.e. automatically add a #0 at the > end; but they should not recognize #0 as a terminator, but only rely on the > length field)? That would be good, because it simplifies converting a string > into a CString a lot (just "CString(@s[1])", right?). It's not like that, but perhaps it *should* be like that ... > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off > around code that needs it, and be safe from accidents elsewhere). It would be > even better than BP (where accidental writes to s[0] are not even detected > by range checking). :-) As long as GPC has no range checking at all ... \begin{sigh} Following the tradition of a large well-known software company, I could now advertise for GPC by announcing that GPC's range checking, once it will be implemented, will be *much* better than that of Borland Pascal. Although I am sure that this will be true, I don't want to join this vaporware marketing method. \end{sigh} > BTW: Should the field be called "length" like the function length? It might > give conflicts with "with" statements ("with" works with schemata, doesn't > it?) as in: (It does. I thought it would not do.) You are right. It must be renamed then. > Perhaps something like str_length or such? "CurrentLength"? > As I said above, I had some problems with the new packed arrays. I tried the > following: Ah - the first bugs with packed arrays. I will look at them, thanks. What about this: With (*$X+*), addresses of packed array members are only rejected if they don't lie on a byte boundary, and otherwise they work? > Should the "()" be allowed here [after `@'] (though not required)? > FWIW, TP5.5 doesn't allow them, BP7.0 does... I will have a look at that, too. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 1 13:05:41 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA26957 for ; Thu, 1 May 1997 13:05:41 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66134; Thu, 1 May 1997 12:03:02 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48712; Thu, 1 May 1997 12:02:41 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA07437 for ; Thu, 1 May 1997 12:58:37 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA26943 for gpc@hut.fi; Thu, 1 May 1997 13:01:14 +0200 From: Peter Gerwinski Message-Id: <199705011101.NAA26943@agnes.dida.physik.uni-essen.de> Subject: problem with gpclib.a (alpha-version)... To: gpc@hut.fi Date: Thu, 1 May 1997 13:01:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Eckleder: > > ...i've got some problem with the library file of the actual (?!?) > alphaversion of gnu-pascal... (* Du meinst: "current" version? ;*) Obviously not - see below. > [...] > > the other problem i realized with this alpha-version is that i couldn't > manage to use the inline assembler. > i only only got a message telling me function asm() not beeing existent. This was a but in some old alpha versions of GPC which is fixed now. The current version is gpc-970420 (see my signature). BTW, the GPI file format changes with (almost) each version, so please recompile your units after upgrading. > because of this strong behavior i use the gpc2.0 compiler with the alpha- > libraries...perhaps THIS is the reason why the function above doesn't > work, > but i am not quite sure about that... (* That's what alpha versions are for: To find all bugs before releasing it to the public. :*) Please try again with gpc-970420 - or with gpc-9705?? ... perhaps this weekend ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 1 19:45:54 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA27334 for ; Thu, 1 May 1997 19:45:54 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66118; Thu, 1 May 1997 18:43:08 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67008; Thu, 1 May 1997 18:42:48 +0200 Received: from mail.osn.de (ns.osn.de [194.77.92.17]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA12157 for ; Thu, 1 May 1997 19:37:29 +0300 (EET DST) Received: from news.osn.de (news.osn.de [194.77.92.26]) by mail.osn.de (8.8.2/8.7.3) with ESMTP id SAA08996 for ; Thu, 1 May 1997 18:37:17 +0200 (MET DST) Received: (from uucp@localhost) by news.osn.de (8.8.4/8.8.4) id SAA01323 for hut.fi!gpc; Thu, 1 May 1997 18:36:26 +0200 (MET DST) >>Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wMxAF-000ocIC; Thu, 1 May 97 16:48 MEST Received: from cl.sub.de by news.osn.de; Thu, 1 May 1997 18:36 MET Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wMxAF-000ocIC; Thu, 1 May 97 16:48 MEST Received: by link-n.cl.sub.de (UUCPfZ V5.75 U005) via ZConnect; 1 May 97 13:46:43 +0200 Date: 30 Apr 97 21:07:00 +0100 From: C.WENDT@CHATEAU.cl.sub.de (Christian Wendt) Subject: Re^4: Legal Change in GPC ? To: gpc@hut.fi Message-Id: <6Vs-mGZMRMB@p-wendt.chateau.cl.sub.de> In-Reply-To: <199704292253.AAA21908@agnes.dida.physik.uni-essen.de> X-Mailer: CrossPoint v3.11 X-Gateway: ZCONNECT UH link-n.cl.sub.de [UUCPfZ V5.75 U005] Content-Type: text Status: RO PG>According to Christian Wendt: PG>> :-) I do the work and get common to the RTS C source (which is very vell PG>> readable!) - and then learn all the work has been done... PG>Oh - sorry! Since an improved BPcompat package for DOS (DJGPP) will PG>be released soon, what about facing Linux instead? Sven's BGI2GRX PG>(Graph) Unit runs under Linux, but we have no CRT yet ... Hmm. CRT like in TP/BP ? prhps... at the moment i first would have to look PG>> PG>available in the `contrib' subdirectory of the GPC distribution. PG>> BPCompat.pas is in my contrib subdirectory... but only "highlevel" PG>> functions... PG>The same stuff as in Borland's CRT, isn't it? Hmm. no - several stuff. move; declaration of byte... paramstr,paramcount (the date is 27.10.96) - seems to be an extract of tools/system.pas of BO5 PG>> not "impossible"- you only got to reinvent the wheel and write to PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln. PG>Nevertheless this will remain my preferred method in BO5. The fastest PG>thing you can imagine on the DOS platform. hmm. is the type of "file" specified in the ISO /Extended? would it be possible to define it similar to TP/BP? there's a list of procedures inwith the file "record" - they specify the functions to init/flush/writebuffer/readbuffer (theoretical you could do the same with an object...) PG>> BTW - is there a way to make a procedure to have a variable count of PG>> parameters? (as writeln) - e.g. would it be possible to define to "C" PG>> printf procedure within pascal ?) PG>Yes and no: You can define a "Procedure Foo ( a, b: Integer; ... );" as in the C Header files... PG>with a triple dot indicating a variable number of subsequent arguments, PG>but I have not yet found out how to access them ... Hmm. would be very interesting how to implement it- could be quite useful... PG>> But i think that even there it would be quite more comfortable to use PG>> Textcolor instead of write(chr(27)+'[5;33m'); or such... PG>Of course. But a CRT Unit could use these sequences to access the PG>terminal in a portable way. Yes... transparent for the programmer... PG>> exactly what I had in mind... don't kill it from the alphas :-) PG>Don't worry. If things develop as I hope, we will enter beta stage PG>soon ... so don't remove it from the betas, too %-) PG>Greetings, PG> Peter Chris --- HomeBox : Chateau - +49(0)8677 911940(V.34) 911941(ISDN) ## CrossPoint v3.11 ## From gpc-request@santra.hut.fi Thu May 1 17:49:01 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA27226 for ; Thu, 1 May 1997 17:49:01 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA07232; Thu, 1 May 1997 16:46:17 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63168; Thu, 1 May 1997 16:45:57 +0200 Received: from hs-gate.handshake.de (root@hs-gate.handshake.de [193.141.176.10]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA10114 for ; Thu, 1 May 1997 17:40:04 +0300 (EET DST) Received: from hit.sb.sub.de (dbox@localhost) by hs-gate.handshake.de (8.8.5/8.8.5) with UUCP id QAA20385 for gpc@hut.fi; Thu, 1 May 1997 16:30:54 +0200 Received: by hit.sb.sub.de (DUUCP vom 22.03.1997) with ZConnect; 01 May 1997 00:00:00 +0000 From: andi.tio@hit.handshake.de (Andreas Bauer) Message-Id: <6W2Y5GEeykB@hit-andi.tio.hit.handshake.de> Organization: Handshake Saarbruecken X-Gateway: ZCONNECT UR hit.sb.sub.de [DUUCP BETA vom 22.03.1997] Subject: stdin/stdout Date: 01 May 1997 00:00:00 +0000 To: gpc@hut.fi Status: RO Hello, can you please explain me how to use the stdin/stdout with gpc? The compiler does not seem to know these. I tried to declare some functions from libc, but it didn't work, too. Here's my code: ---------------------- program passtrough; function fopen(name:pChar; mode:integer):integer; asmname 'open'; function fclose(handle:integer):integer; asmname 'close'; function fread(handle:integer; VAR Buffer; length:integer):integer; asmname 'read'; function fwrite(handle:integer; VAR Buffer; length:integer):integer; asmname 'write'; CONST O_RDONLY = 00; O_WRONLY = 01; O_RDWR = 02; O_CREAT = 0100; O_EXCL = 0200; O_NOCTTY = 0400; O_TRUNC = 01000; O_APPEND = 02000; O_NONBLOCK = 04000; O_NDELAY = O_NONBLOCK; O_SYNC = 010000; var fin,fout:integer; buffer:array[1..1024] of byte; bytesread:integer; begin fin := fopen('/dev/stdin',O_RDONLY); fout:= fopen('/dev/stdout',O_WRONLY); repeat bytesread:=fread(fin,buffer,1024); if bytesread=-1 then begin writeln('read error'); Halt; end; if fwrite(fout,buffer,bytesread)=-1 then begin writeln('write error'); Halt; end; until bytesread<>1024; fclose(fin); fclose(fout); end. ---------------------- It *does* work when stdin/stdout are connected to the terminal, but when using pipes it seems not to work. Any suggestions? Bye Andreas From gpc-request@santra.hut.fi Thu May 1 16:06:11 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA27123 for ; Thu, 1 May 1997 16:06:11 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45148; Thu, 1 May 1997 15:03:29 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50026; Thu, 1 May 1997 15:03:08 +0200 Received: from iol-mail.iol.it (iol-mail.iol.it [194.20.24.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA08964 for ; Thu, 1 May 1997 15:57:45 +0300 (EET DST) Received: from cristian (mi8-max-ip-184.iunet.it [195.45.4.184]) by iol-mail.iol.it (8.8.3/8.6.12) with ESMTP id OAA32266 for ; Thu, 1 May 1997 14:57:37 +0200 Message-Id: <199705011257.OAA32266@iol-mail.iol.it> From: "Cristian Sala" To: Subject: Please delete me from your mailing list Date: Mon, 28 Apr 1997 16:11:40 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Status: RO Please cancel my registration to your mailing list tank you Cristian Sala From gpc-request@santra.hut.fi Thu May 1 14:22:49 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA27051 for ; Thu, 1 May 1997 14:22:48 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96076; Thu, 1 May 1997 13:20:07 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77830; Thu, 1 May 1997 13:19:47 +0200 Received: from gabriel.keele.ac.uk (aurora.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA08574 for ; Thu, 1 May 1997 14:12:02 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Thu, 1 May 1997 12:13:17 +0100 Received: from [0.8.155.172] by potter.cc.keele.ac.uk; Thu, 1 May 1997 12:10:50 +0100 From: The African Chief To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Modifying string length? Message-Id: Date: Thu, 1 May 1997 12:14:42 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Thu, 1 May 1997 13:40:14 +0200 (MET DST) Peter Gerwinski wrote: >According to The African Chief: >> >> However, what happens when you want to add a string to >> the end of it? Check this example, and look at the ouput >> under Borland; >> >> program Fred; >> var >> s,s1:string[40]; >> begin >> s := 'Fred Smith'+#0; >> s1 := s + 'is okay'; >> writeln ( s1 ); >> {prints "Fred Smith is okay" - where did the space before "okay" >> come from? I didn't want or put it there - viz; problem with trailing "#0"} >> end. > >It's no space; it's a #0, as you requested. Yes. >The above is an *explicit* trailing #0. It is part of the string and >must not vanish when adding another string. True. >The *implicit* trailing #0 to be appended for CString compatibility >*will* vanish; however the program above will still produce the same >result. That is okay then. I just thought that the point needed to be made, that there could be a problem with a trailing #0. If the compiler makes the ones that it adds to vanish away, the problem disappears. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Thu May 1 13:45:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA27024 for ; Thu, 1 May 1997 13:45:40 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA58090; Thu, 1 May 1997 12:43:00 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56446; Thu, 1 May 1997 12:42:40 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id NAA07734 for ; Thu, 1 May 1997 13:37:36 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA27010 for gpc@hut.fi; Thu, 1 May 1997 13:40:14 +0200 From: Peter Gerwinski Message-Id: <199705011140.NAA27010@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Thu, 1 May 1997 13:40:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to The African Chief: > > However, what happens when you want to add a string to > the end of it? Check this example, and look at the ouput > under Borland; > > program Fred; > var > s,s1:string[40]; > begin > s := 'Fred Smith'+#0; > s1 := s + 'is okay'; > writeln ( s1 ); > {prints "Fred Smith is okay" - where did the space before "okay" > come from? I didn't want or put it there - viz; problem with trailing "#0"} > end. It's no space; it's a #0, as you requested. The above is an *explicit* trailing #0. It is part of the string and must not vanish when adding another string. The *implicit* trailing #0 to be appended for CString compatibility *will* vanish; however the program above will still produce the same result. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 1 23:55:55 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA27612 for ; Thu, 1 May 1997 23:55:55 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45066; Thu, 1 May 1997 22:53:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77810; Thu, 1 May 1997 22:52:45 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA11841 for ; Thu, 1 May 1997 23:43:29 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id WAA11632 (8.7.6/7.5c-FAU); for ; Thu, 1 May 1997 22:43:26 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id WAA01490 (SMI-8.6/7.5b-FAU); Thu, 1 May 1997 22:43:24 +0200 From: Frank Heckenbach Message-Id: <199705012043.WAA01490@helena.mi.uni-erlangen.de> Date: Thu, 1 May 1997 22:43:22 +0200 To: gpc@hut.fi Subject: Re: Modifying string length? Status: RO The African Chief wrote: > >But how would you translate references to s[0] in BP then? I know, there > >shouldn't be any in most programs, but sometimes it can be useful, e.g. for > >efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > "s[0] := ..." is okay. But you couldn't do that with long strings since their length isn't stored in [0], but in .length. So there are cases where write access to .length is needed, that's what I meant. > I do that myself sometimes (but only to set the length to zero). s:='' should do the same. (BP optmizes this to just setting the length to 0, I hope gpc does as well.) > "length(s) := ...." > or "s.length := ..." > > - which shouldn't compile (if at all), when using "--borland-pascal". I think it should (at least with {$X+} or such), because it's the only way to translate some kinds of procedures -- unless one wants to limit such procedures to borland-like short strings. > >Does this mean strings will always have an additional trailing #0? Do the > >string routines currently support this (i.e. automatically add a #0 at the > >end; but they should not recognize #0 as a terminator, but only rely on the > >length field)? That would be good, because it simplifies converting a string > >into a CString a lot (just "CString(@s[1])", right?). > > Delphi 2 does this with long strings (I think). If we are going to do it, > perhaps it should only be done for long strings as well? > > However, what happens when you want to add a string to > the end of it? Check this example, and look at the ouput > under Borland; > > program Fred; > var > s,s1:string[40]; > begin > s := 'Fred Smith'+#0; > s1 := s + 'is okay'; > writeln ( s1 ); > {prints "Fred Smith is okay" - where did the space before "okay" > come from? I didn't want or put it there - viz; problem with trailing "#0"} > end. As Peter has already pointed out, an implicit #0 would not behave like this. I suppose this would be achieved by having the length not include the #0. So the internal representation of 'foo' would be something like: Long string: Capacity:...; Length: 3; string: ('f','o','o',#0,...) Short string: (#3,'f','o','o',#0,...) The question is, should the #0 be added for short strings as well? If Length=Capacity, it's impossible, but otherwise??? BTW: Your example raises the "problem" that if you have a string with one or more #0 in it, and convert it to a CString, the CString will be shorter than expected. But I think there's nothing to be done about it. If one wants to convert a string to a CString, one just must not put any #0 in it... Peter Gerwinski wrote: > > But how would you translate references to s[0] in BP then? I know, there > > shouldn't be any in most programs, but sometimes it can be useful, e.g. for > > efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > That's one reason why `StortString's should be implemented - which will > have "s[0]". But this job doesn't have high priority for me ... As I said above, it would (currently) suffice for me if "s[0]:=..." could be translated to "s.CurrentLength:=..." for long strings. But at the moment, it can't be translated at all. The BP syntax "s[0]" is, IMHO, not very good, so it should not be supported (emulated) for long strings. > > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off > > around code that needs it, and be safe from accidents elsewhere). It would be > > even better than BP (where accidental writes to s[0] are not even detected > > by range checking). :-) > > As long as GPC has no range checking at all ... I know... Currently the length could probably be changed by writing to s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| BTW: Does the standard require range checking (or does it say anything about it at all)? > "CurrentLength"? Why not. > What about this: With (*$X+*), addresses of packed array members are > only rejected if they don't lie on a byte boundary, and otherwise they > work? And with {$X-} they don't work at all, you mean? Seems ok. And the same for packed records? > Another idea, perhaps even better: let "String ( 255 )" or > "LongString ( 255 )" denote an Extended Pascal (long) string, but > "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short) > string? Like this, both Extended Pascal and Borland Pascal programs > will just compile. Needless to say that `--extended-pascal' will > switch off "String [ 255 ]" and `--borland-pascal' will switch off > "String ( 255 )" ... Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) BTW: String[n] with n>255 wouldn't work at all then? Seems ok to me. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Fri May 2 03:07:23 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA28016 for ; Fri, 2 May 1997 03:07:23 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA05708; Fri, 2 May 1997 02:04:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37104; Fri, 2 May 1997 02:04:10 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA16892 for ; Fri, 2 May 1997 02:59:15 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA27986 for gpc@hut.fi; Fri, 2 May 1997 03:02:05 +0200 From: Peter Gerwinski Message-Id: <199705020102.DAA27986@agnes.dida.physik.uni-essen.de> Subject: Re: stdin/stdout To: gpc@hut.fi Date: Fri, 2 May 1997 03:02:05 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Andreas Bauer: > > can you please explain me how to use the stdin/stdout with gpc? > The compiler does not seem to know these. The "legal" way is to use ordinary `read', `readln', `write', and `writeln' operations. Note that `read' returns a space at the end of a line, not a chr ( 10 ) or chr ( 13 ), and that `eoln ( Input )' is `true' instead. > It *does* work when stdin/stdout are connected to the terminal, but > when using pipes it seems not to work. It should work except that the first char is "eaten" by the GPC RTL. See the thread "[BUG] GPC - a char killer?" on 7. and 11. April in this list for reasons and a workaround. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 2 03:03:48 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA28011 for ; Fri, 2 May 1997 03:03:48 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96192; Fri, 2 May 1997 02:00:55 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56750; Fri, 2 May 1997 02:00:35 +0200 Received: from jehova.owl.de (jehova.owl.de [194.121.202.132]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA17557 for ; Fri, 2 May 1997 02:55:39 +0300 (EET DST) Received: from fiction.pb.owl.de (root@fiction.pb.owl.de [193.174.12.5]) by jehova.owl.de (8.8.5/8.8.5) with SMTP id BAA25649; Fri, 2 May 1997 01:55:32 +0200 (MET DST) Received: by fiction.pb.owl.de id m0wN5so-00002fC; Fri, 2 May 97 02:07 MET DST Received: (from nilsb@localhost) by reality.owl.de (8.7.5/8.7.3) id MAA01708; Thu, 1 May 1997 12:49:31 GMT From: Nils Bokermann Message-Id: <199705011249.MAA01708@reality.owl.de> Subject: Re: What is standard, and what isn't? In-Reply-To: <199704292241.AAA21829@agnes.dida.physik.uni-essen.de> from Peter Gerwinski at "Apr 30, 97 00:41:52 am" To: peter@agnes.dida.physik.uni-essen.de (Peter Gerwinski) Date: Thu, 1 May 1997 12:49:31 +0000 (GMT) Cc: gpc@hut.fi (gpc) X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > > 1) Is the comparision with `=' or `<>' of structured variables okay in > ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared > must be compatible. > > If not, this might be a reasonable extension (already offered by > some compilers, *not* including Borland Pascal;). I don't know what is okay in ISO Pascal :-(. But I do have a simple question. How do you want to compare structured variables? Compare member by member? I knew a very fine programming language (ELAN) in which it was possible to define your own operator (`=', `<>' or whatever you wanted). Is it possible to have this as an extension to Pascal? Bye, Nils -- Nils Bokermann Johanneswerkstr. 90 Phone: +49 521 891279 33613 Bielefeld FAX: +49 521 550116 Germany "Wir wollen die Natur nicht erhalten -- Wir wollen nur ihre Dynamik nicht st"oren." _______________________________________________________________________________ From gpc-request@santra.hut.fi Fri May 2 03:10:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA28022 for ; Fri, 2 May 1997 03:10:02 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83384; Fri, 2 May 1997 02:07:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37018; Fri, 2 May 1997 02:06:50 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA17453 for ; Fri, 2 May 1997 02:59:02 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA27978 for gpc@hut.fi; Fri, 2 May 1997 03:01:52 +0200 From: Peter Gerwinski Message-Id: <199705020101.DAA27978@agnes.dida.physik.uni-essen.de> Subject: Re^5: Legal Change in GPC ? To: gpc@hut.fi Date: Fri, 2 May 1997 03:01:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Christian Wendt: > > PG>The same stuff as in Borland's CRT, isn't it? > Hmm. no - several stuff. > move; > declaration of byte... > paramstr,paramcount > (the date is 27.10.96) - seems to be an extract of tools/system.pas of BO5 We are speaking of different Units: You mean `bpcompat.pas' while I am speaking of `bpcompat.zip' which contains `system.pas', `crt.pas', etc. > hmm. is the type of "file" specified in the ISO /Extended? You mean the internal structure of the `file' type? No. > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) It's defined in a quite different way. The record contains a lot of interesting information about the file, but no `hooks'. The actual input/output is done via `ordinary' functions written in C. But be invited to implement those `hooks' in the GPC RTS. > PG>Of course. But a CRT Unit could use these sequences to access the > PG>terminal in a portable way. > Yes... transparent for the programmer... Everything is transparent for the programmer since you have the source code of everything. :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat May 3 02:56:10 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA30160 for ; Sat, 3 May 1997 02:56:10 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79222; Sat, 3 May 1997 01:52:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA32036; Sat, 3 May 1997 01:52:38 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA10199 for ; Sat, 3 May 1997 02:45:23 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id BAA22167 (8.7.6/7.5c-FAU); for ; Sat, 3 May 1997 01:45:19 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id BAA06576 (SMI-8.6/7.5b-FAU); Sat, 3 May 1997 01:45:18 +0200 From: Frank Heckenbach Message-Id: <199705022345.BAA06576@helena.mi.uni-erlangen.de> Date: Sat, 3 May 1997 01:45:17 +0200 To: gpc@hut.fi Subject: Re: Modifying string length? Status: RO Peter Gerwinski wrote: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > > I hope gpc does as well.) > > It does. (But better check it, too - I already was wrong once with > statements of this type.;-) Yes, it does. I checked it. It even does "s:='...'" where '...' is a constant string with length<=14 without any loops or calls. > > I think it should (at least with {$X+} or such), because it's the only way > > to translate some kinds of procedures -- unless one wants to limit such > > procedures to borland-like short strings. > > Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". ^^^^^^ ...or rather CurrentLength, as you said before. Then perhaps it would be useful to allow the same syntax also for ShortStrings (additionally), just as if ShortString[n] was declared as: record case boolean of false:(CurrentLength:byte); true:(string:array[0..n] of char); end; Also, it could be good to provide a (read-only) "pseudo field" Capacity. (BTW: LongStrings' Capacity is always read-only, isn't it?) BP 7.0 allows this via High(s) -- is something like BP's High and Low functions (to give the lower and upper bounds of arrays and subrange types) present or planned for gpc? Then the compiler could just translate "s.Capacity" to "High(s)" in the case of ShortStrings. These two things would make ShortStrings more similar to (and often exchangeable with) LongStrings, without giving up BP compatibility. > > The question is, should the #0 be added for short strings as well? > > If Length=Capacity, it's impossible, but otherwise??? > > We could increase the space allocated for a short string by 1, but this > would break compatibility to UCSD and Borland Pascal. So better ignore > this and live with "String [ 255 ]" having only a capacity of 254 in fact. No, I guess this could break some programs, too. BTW: The problem is also there for Length=Capacity<=255: either we'd have Sizeof(String[n])=n+2 or (Capacity of String[n])=n-1 -- both could lead to problems. So, perhaps better forget about the #0 with ShortStrings, and add it when converting to other strings... > > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) > > I would not call this "non-standard" since this - like many other things, > e.g. Units - was not invented by Borland but by UCSD. But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't really matter to me. -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Fri May 2 14:48:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA29399 for ; Fri, 2 May 1997 14:48:49 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA40770; Fri, 2 May 1997 13:45:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78542; Fri, 2 May 1997 12:53:05 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA28800 for ; Fri, 2 May 1997 13:45:11 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id MAA10466 (8.7.6/7.5c-FAU); for ; Fri, 2 May 1997 12:45:06 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id MAA04338 (SMI-8.6/7.5b-FAU); Fri, 2 May 1997 12:45:04 +0200 From: Frank Heckenbach Message-Id: <199705021045.MAA04338@helena.mi.uni-erlangen.de> Date: Fri, 2 May 1997 12:45:03 +0200 To: gpc@hut.fi Subject: Re: Legal Change in GPC ? Status: RO Christian Wendt wrote: > PG>> not "impossible"- you only got to reinvent the wheel and write to > PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln. > PG>Nevertheless this will remain my preferred method in BO5. The fastest > PG>thing you can imagine on the DOS platform. > hmm. is the type of "file" specified in the ISO /Extended? > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text", not for typed are untyped files (though there's actually no reason why it shoudln't apply to them, too, except that BP's doesn't). Indeed, I'd like to have something like this in gpc, too. I'm not at all familiar with the internals of "Text" files (or other files) in gpc. (ISTR, it has something to do with "bindable" variables, but I don't know much about those, either.) First a short explanation for those not familiar with BP: Basically, TFDDs allow the programmer to assign procedures with the following semantics to a "Text" variable to be used instead of file I/O: Open: Input: File mode (Reset / Rewrite / Extend (aka Append)) Read: Input: Buffer size Output: Actual size read (<= Buffer size); the value 0 signals an EOF -- but perhaps it would be better to have a separate EOF function (e.g. for things like serial ports that may have no data at one time, but get some data later). Data that were read (in the buffer) Write: Input: Data in buffer Size Flush: (the same as Write, except that it should additionally "physically flush the file", as far as that makes sense -- I can't remember any examples where this did anything different than Write) Close: - All procedures also have an "error code" as Output to signal un-/successful completion of the operation. The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local to the file to distinguish different "instances" of files assigned to a particular TFDD. (Here we see the similarities to objects...) The big advantage is that one can do a Write[ln]/Read[ln] with all its possibilites and have the data automatically "piped" to certain routines. Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing the string to the routines, but (a) it's not completely as easy (2 statements instead of one), (b) managing the "local data" would require additional effort everywhere this is used, (c) it's not TP compatible..., (d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can be passed to any procedure that wants a "Text" file). The particular syntax (and other things) BP uses for this is, IMHO, not very nice (it was introduced after the "good days" of Borland, but before the introduction of OOP, which could have simplified things), so I don't vote for copying BP's mechanism. But any way to do such things would be good. In fact, many of my units use TFDDs, and I can't see a "good" way of porting programs that use them to gpc (only perhaps with heavy use of the preprocessor, but I'd not like to do it like that). I'd not complain at all if it was done with OOP (i.e. "Text" would be an object type, the "procedure" above would be methods, the local data would be the fields of the object), the main thing is that the object could be used in simple Read[ln]/Write[ln] statements. Any chances to do something like this with reasonable effort? -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Fri May 2 14:46:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA29395 for ; Fri, 2 May 1997 14:46:12 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60574; Fri, 2 May 1997 13:43:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45714; Fri, 2 May 1997 13:42:52 +0200 Received: from mail.osn.de (ns.osn.de [194.77.92.17]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id OAA29463 for ; Fri, 2 May 1997 14:27:28 +0300 (EET DST) Received: from news.osn.de (news.osn.de [194.77.92.26]) by mail.osn.de (8.8.2/8.7.3) with ESMTP id NAA06588 for ; Fri, 2 May 1997 13:27:12 +0200 (MET DST) Received: (from uucp@localhost) by news.osn.de (8.8.4/8.8.4) id NAA21553 for hut.fi!gpc; Fri, 2 May 1997 13:26:28 +0200 (MET DST) >>Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wNEsY-000oTOC; Fri, 2 May 97 11:43 MEST Received: from cl.sub.de by news.osn.de; Fri, 2 May 1997 13:26 MET Received: from link-n.cl.sub.de by cl.sub.de with uucp (Linux Smail3.1.28.1 #14) id m0wNEsY-000oTOC; Fri, 2 May 97 11:43 MEST Received: by link-n.cl.sub.de (UUCPfZ V5.75 U005) via ZConnect; 2 May 97 11:27:54 +0200 Date: 1 May 97 22:56:00 +0100 From: A.ECKLEDER@CHATEAU.cl.sub.de (Andreas Eckleder) Subject: Re: problem with gpclib.a (alpha-version)... To: gpc@hut.fi Message-Id: <6W3OshBsCfB@p-andy.chateau.cl.sub.de> In-Reply-To: <199705011101.NAA26943@agnes.dida.physik.uni-essen.de> X-Mailer: CrossPoint v3.1 X-Gateway: ZCONNECT UH link-n.cl.sub.de [UUCPfZ V5.75 U005] Content-Type: text Status: RO /-------------------- A.ECKLEDER@CHATEAU.CL.SUB.DE ----------------------\ p> This was a but in some old alpha versions of GPC which is fixed now. p> The current version is gpc-970420 (see my signature). ups...i just realized that what i got yesterday was really a DAMN old version ;-) (smth. about feb. of this year i guess) i'm just downloading gpc-970420 right now... another problem i had: i was trying to recompile gnu-pascal (both the compiler and the executable) but make only told me "couldn't create target ..\gcc-2171" or smth. like that. i think all env-vars are set correctly and a version of gcc incl. sourcecode is available in ..\gcc-2171. so: what packages could be missing...what would i have to add? andy /------------------- A.ECKLEDER@CHATEAU.CL.SUB.DE --------------------\ Who is 'General Failure' - And why is he reading my harddisk ? \------------------ Andreas Eckleder@2:2480/816.32 -------------------/ ## CrossPoint v3.1 ## From gpc-request@santra.hut.fi Fri May 2 13:54:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA29353 for ; Fri, 2 May 1997 13:54:11 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA115986; Fri, 2 May 1997 12:51:12 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA69348; Fri, 2 May 1997 12:50:50 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA28675 for ; Fri, 2 May 1997 13:45:11 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id MAA10467 (8.7.6/7.5c-FAU); for ; Fri, 2 May 1997 12:45:06 +0200 (MET DST) Received: from skylla by mi.uni-erlangen.de with SMTP; id MAA04337 (SMI-8.6/7.5b-FAU); Fri, 2 May 1997 12:45:04 +0200 From: Frank Heckenbach Message-Id: <199705021045.MAA04337@helena.mi.uni-erlangen.de> Date: Fri, 2 May 1997 12:45:03 +0200 To: gpc@hut.fi Subject: Portability questions (Arrays) Status: RO Hi everyone! Two questions about portability of properties of arrays: Let's assume a:array[x..y] of t (not a packed array). 1. Is it safe to assume -- for all platforms, including possible future ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? 2. Is it safe to assume that Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? (Is it generally allowed to cast a pointer into an integer, in the first place?) -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Fri May 2 03:32:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA28107 for ; Fri, 2 May 1997 03:32:45 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63220; Fri, 2 May 1997 02:29:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50354; Fri, 2 May 1997 02:29:32 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA16964 for ; Fri, 2 May 1997 03:23:55 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA28088; Fri, 2 May 1997 03:26:42 +0200 From: Peter Gerwinski Message-Id: <199705020126.DAA28088@agnes.dida.physik.uni-essen.de> Subject: Re: What is standard, and what isn't? To: nilsb@reality.owl.de, gpc@hut.fi Date: Fri, 2 May 1997 03:26:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Nils Bokermann: > How do you want to compare structured variables? Compare member by > member? Yes. Except with types where we know that a simple byte compare is sufficient. > I knew a very fine programming language (ELAN) in which it was possible > to define your own operator (`=', `<>' or whatever you wanted). Is it > possible to have this as an extension to Pascal? It's a PXSC extension which is already in GPC: Operator = ( x, y: MyType ) result: Boolean; begin (* MyType = MyType *) result:= ( x.foo = y.foo ) and ( x.bar = y.bar ) or whatever; end (* MyType = MyType *); Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 2 03:32:24 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA28103 for ; Fri, 2 May 1997 03:32:23 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA63208; Fri, 2 May 1997 02:29:31 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45980; Fri, 2 May 1997 02:29:11 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id DAA17759 for ; Fri, 2 May 1997 03:23:32 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id DAA28080 for gpc@hut.fi; Fri, 2 May 1997 03:26:21 +0200 From: Peter Gerwinski Message-Id: <199705020126.DAA28080@agnes.dida.physik.uni-essen.de> Subject: Re: Modifying string length? To: gpc@hut.fi Date: Fri, 2 May 1997 03:26:20 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > I hope gpc does as well.) It does. (But better check it, too - I already was wrong once with statements of this type.;-) > I think it should (at least with {$X+} or such), because it's the only way > to translate some kinds of procedures -- unless one wants to limit such > procedures to borland-like short strings. Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". > The question is, should the #0 be added for short strings as well? > If Length=Capacity, it's impossible, but otherwise??? We could increase the space allocated for a short string by 1, but this would break compatibility to UCSD and Borland Pascal. So better ignore this and live with "String [ 255 ]" having only a capacity of 254 in fact. > Currently the length could probably be changed by writing to > s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| No. This will only work for lenghts below 256 and on big-endian machines. Better cast the String to a record (read: cast a pointer to the String to a pointer to a record). > BTW: Does the standard require range checking (or does it say anything about > it at all)? Yes, AFAIK. > And with {$X-} they don't work at all, you mean? Seems ok. > And the same for packed records? Yes. > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) I would not call this "non-standard" since this - like many other things, e.g. Units - was not invented by Borland but by UCSD. > BTW: String[n] with n>255 wouldn't work at all then? Yes. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat May 3 23:35:36 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA32554 for ; Sat, 3 May 1997 23:35:36 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66090; Sat, 3 May 1997 22:32:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA36252; Sat, 3 May 1997 22:31:50 +0200 Received: from berlin.shuttle.de (berlin.shuttle.de [194.95.246.252]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA19341 for ; Sat, 3 May 1997 23:21:37 +0300 (EET DST) Received: from herbie (p59.b.shuttle.de [194.95.246.59]) by berlin.shuttle.de (8.8.5/8.7.1) with SMTP id WAA26669 for ; Sat, 3 May 1997 22:21:35 +0200 (MET DST) Message-Id: <336B9E53.5573@ck.b.shuttle.de> Date: Sat, 03 May 1997 22:21:39 +0200 From: Herbert Voss Reply-To: Herbert.Voss@ck.b.shuttle.de Organization: Canisius-Kolleg X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: gpc@hut.fi Subject: ClrScr Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hello, how can I clear the screen under gpc? Just like Borlands ClrScr. Thanks Herbert From gpc-request@santra.hut.fi Sat May 3 23:55:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA32702 for ; Sat, 3 May 1997 23:55:33 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81660; Sat, 3 May 1997 22:52:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60634; Sat, 3 May 1997 22:51:46 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA20002 for ; Sat, 3 May 1997 23:42:00 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA32645 for gpc@hut.fi; Sat, 3 May 1997 23:45:24 +0200 From: Peter Gerwinski Message-Id: <199705032145.XAA32645@agnes.dida.physik.uni-essen.de> Subject: BP-style ^X character constants To: gpc@hut.fi Date: Sat, 3 May 1997 23:45:24 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, I proudly announce that the next alpha version of GPC will understand BP-style character constants: ^A means chr ( 1 ) i.e. Ctrl+A, etc. Thanks to GPC's context-sensitive lexical analyzer, they work even better than in BP. GPC just compiled Type X = ^Y; (* Forward pointer reference *) Y = array [ ^A..^Z ] of ^Z; (* An array of pointers to Z *) Z = ^A..^Z; (* Subrange chr(1)..chr(26) *) Now try to compile this with Borland Pascal 7.0 ... ;-) Hooray, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat May 3 23:55:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA32698 for ; Sat, 3 May 1997 23:55:18 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA66274; Sat, 3 May 1997 22:51:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72130; Sat, 3 May 1997 22:51:32 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA19318 for ; Sat, 3 May 1997 23:41:31 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA32628 for gpc@hut.fi; Sat, 3 May 1997 23:44:55 +0200 From: Peter Gerwinski Message-Id: <199705032144.XAA32628@agnes.dida.physik.uni-essen.de> Subject: TFDDs - customizing `writeln' (Was: Legal Change in GPC ?) To: gpc@hut.fi Date: Sat, 3 May 1997 23:44:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Indeed, I'd like to have something like this in gpc, too. I'm not at all > familiar with the internals of "Text" files (or other files) in gpc. > (ISTR, it has something to do with "bindable" variables, but I don't know > much about those, either.) > > [...] > > The particular syntax (and other things) BP uses for this is, IMHO, not very > nice (it was introduced after the "good days" of Borland, but before the > introduction of OOP, which could have simplified things), so I don't vote > for copying BP's mechanism. But any way to do such things would be good. If somebody who knows C wants to implement this for GPC, here are some ideas: GPC's run time system (RTS) defines a function `_p_write' which is responsible for all output to text files. The C source is in `rts/rts-write.c'. I already modified this function to call `cprintf' instead of `printf' on the DOS platform if the variable `_p_directvideo' has a nonzero value. This is done through some preprocessor macros PRINTF1, ... PRINTF4, CFWRITE and serves the purpose to make a `CRT' Unit for DOS possible. If you replace my macro calls by a call to `sprintf' followed by an indirect call to an output function, we've got it. (Note that Pascal allows `chr ( 0 )' characters in Strings.) Happy hacking, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat May 3 23:54:44 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA32693 for ; Sat, 3 May 1997 23:54:44 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81616; Sat, 3 May 1997 22:51:18 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60774; Sat, 3 May 1997 22:50:58 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA17862 for ; Sat, 3 May 1997 23:41:21 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA32620 for gpc@hut.fi; Sat, 3 May 1997 23:44:44 +0200 From: Peter Gerwinski Message-Id: <199705032144.XAA32620@agnes.dida.physik.uni-essen.de> Subject: Re: Portability questions (Arrays) To: gpc@hut.fi Date: Sat, 3 May 1997 23:44:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > 1. Is it safe to assume -- for all platforms, including possible future > ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? I first thought that this would not be the case due to alignment problems, but ...: That's *exactly* the way how GPC calculates the size of an array. Why is this so, e.g. with an array of something which has 3 bytes? Program Test; Type r = packed record x: ShortWord; y: Byte; end (* r *); Var x: packed array [ 1..1000 ] of r; begin writeln ( SizeOf ( x ) ); writeln ( SizeOf ( x [ 1 ] ) ); end. The output is 4000 and ... 4. To avoid alignment problems in an "array of r", the record `r' has size 4, not 3. I conclude that the assumption is safe. > 2. Is it safe to assume that > Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? Yes, for the same reason. If the "natural" size of `t' would cause alignment problems, `t' is blown up by GPC. > (Is it generally allowed to cast a pointer into an integer, > in the first place?) I think so. The GNU coding standard says about GCC's (and thus GPC's) behaviour: You can assume that all pointers have the same format, regardless of the type they point to, and that this is really an integer. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sat May 3 23:54:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA32688 for ; Sat, 3 May 1997 23:54:25 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81604; Sat, 3 May 1997 22:50:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA29536; Sat, 3 May 1997 22:50:39 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA19730 for ; Sat, 3 May 1997 23:41:47 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA32637 for gpc@hut.fi; Sat, 3 May 1997 23:45:11 +0200 From: Peter Gerwinski Message-Id: <199705032145.XAA32637@agnes.dida.physik.uni-essen.de> Subject: Short Strings, Schema discriminants, UCSD Pascal (Was: Modifying string length?) To: gpc@hut.fi Date: Sat, 3 May 1997 23:45:10 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > [...] Then perhaps it would be > useful to allow the same syntax also for ShortStrings (additionally), just > as if ShortString[n] was declared as: > > record > case boolean of > false:(CurrentLength:byte); > true:(string:array[0..n] of char); > end; > > Also, it could be good to provide a (read-only) "pseudo field" Capacity. > [...] > These two things would make ShortStrings more similar to (and often > exchangeable with) LongStrings, without giving up BP compatibility. Good ideas, but a lot of work ... > (BTW: LongStrings' Capacity is always read-only, isn't it?) It is not. Probably it should be - somebody knows? And for other schema discriminants? > BP 7.0 allows this via High(s) -- is something like BP's High and Low > functions (to give the lower and upper bounds of arrays and subrange types) > present or planned for gpc? [...] Yes. > [...] So, perhaps better forget about the #0 with ShortStrings, and add > it when converting to other strings... I think that's the way to go. > But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't > really matter to me. UCSD Pascal was developed at the University of California San Diego (UCSD), not by a company, that's why I consider it as a well-defined standard, although no ISO standard. I have read about a company "SofTech" distributing UCSD Pascal, and I got mine from Apple as "Apple Pascal". If somebody has some more exact information, I would be glad to know. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun May 4 01:56:48 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA00090 for ; Sun, 4 May 1997 01:56:48 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA81498; Sun, 4 May 1997 00:53:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44310; Sun, 4 May 1997 00:52:59 +0200 Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com [149.174.177.136]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id BAA20492 for ; Sun, 4 May 1997 01:47:44 +0300 (EET DST) Received: by hil-img-6.compuserve.com (8.6.10/5.950515) id SAA19391; Sat, 3 May 1997 18:47:09 -0400 Date: Sat, 3 May 1997 18:28:47 -0400 From: Berend de Boer Subject: Re: Portability questions (Arrays) To: "'gpc'" Message-Id: <199705031845_MC2-15E2-3185@compuserve.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Status: RO Frank Heckenbach wrote: >Two questions about portability of properties of arrays: >1. Is it safe to assume -- for all platforms, including possible future > ones -- that SizeOf(a) =3D ((Ord(y)-Ord(x)+1) * SizeOf(t)? No. > 2. Is it safe to assume that > Integer(@a[p])-Integer(@a[q]) =3D (p-q) * SizeOf(t)? No. > (Is it generally allowed to cast a pointer into an integer, > in the first place?) No. Groetjes, Berend. From gpc-request@santra.hut.fi Sun May 4 00:51:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA00034 for ; Sun, 4 May 1997 00:51:06 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19486; Sat, 3 May 1997 23:47:38 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72086; Sat, 3 May 1997 23:47:18 +0200 Received: from mint.mint.net (root@mint.mint.net [204.254.98.16]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA18613 for ; Sun, 4 May 1997 00:42:23 +0300 (EET DST) Received: from dialup-b-11.mint.net (dialup-b-11.mint.net [206.139.113.31]) by mint.mint.net (8.8.5/8.8.5) with SMTP id RAA19860 for ; Sat, 3 May 1997 17:42:16 -0400 Message-Id: <199705032142.RAA19860@mint.mint.net> From: "Kevin A. Foss" To: "GPC Mailing List" Date: Sat, 03 May 97 17:37:19 -0400 Reply-To: "Kevin Foss" Priority: Normal X-Mailer: Kevin Foss's Registered PMMail 1.9 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: page procedure bug? Status: RO Hello, The discussion of 'clrscr' caused me to look into GPC's support of the page procedure. [On all of the Pascal variants I've used in the past -- I've never used any Borland variant -- 'page' would effectively clear the screen.] While GPC on the other hand seems to follow the standard literally and output just a FF (ASCII 12). No problem there, but the problem is that GPC gives a parse error if use just 'page' but accepts 'page(output)'. My reading of the standard is that page with no parameters should assume standard output, at least if output is explicitly declared in the program heading. (ISO 7185 6.9.5) E.g. this program should compile: program pagetest(output); begin page; end. -Kevin -- Kevin A. Foss --- kfoss@mint.net -- From gpc-request@santra.hut.fi Sun May 4 00:04:13 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA32755 for ; Sun, 4 May 1997 00:04:12 +0200 Received: from mail.hrz.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA87256; Sat, 3 May 1997 23:00:46 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA64268; Sat, 3 May 1997 23:00:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA19565 for ; Sat, 3 May 1997 23:54:36 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA32739; Sat, 3 May 1997 23:57:58 +0200 From: Peter Gerwinski Message-Id: <199705032157.XAA32739@agnes.dida.physik.uni-essen.de> Subject: Re: ClrScr To: herbert.voss@ck.b.shuttle.de, gpc@hut.fi Date: Sat, 3 May 1997 23:57:58 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Herbert Voss: > > how can I clear the screen under gpc? Just like > Borlands ClrScr. On the DOS/DJGPP platform, use `ClrScr' from the `CRT' Unit of the "BPcompat" package, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/bpcompat.zip ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip You can also try the portable `BO5' library, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/bo5/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bo5/ `BO5' has a `Displays' Unit which implements a `ClearScreen' procedure which does essentially the same as `ClrScr'. We are still looking for somebody who wants to implement a portable, Borland-compatible `CRT'. (But our `Graph' Unit, "BGI2GRX", works on Linux at least.:) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Tue May 6 09:42:54 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA06750 for ; Tue, 6 May 1997 09:42:54 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA37728; Tue, 6 May 1997 08:38:44 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA48832; Tue, 6 May 1997 08:38:24 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA18435; Tue, 6 May 97 08:39:27 +0200 Received: from dub-img-6.compuserve.com ([149.174.206.136]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id JAA10056 for ; Tue, 6 May 1997 09:23:52 +0300 (EET DST) Received: by dub-img-6.compuserve.com (8.6.10/5.950515) id CAA27618; Tue, 6 May 1997 02:23:20 -0400 Date: Tue, 6 May 1997 02:22:21 -0400 From: Walter Schaufelberger Subject: Cancel from the List To: all Message-Id: <199705060221_MC2-1605-B223@compuserve.com> Status: RO Please delete me from the gpc member list. The user for this compuserve adress has changed and im not interested in gpc W. Schufelberger From gpc-request@santra.hut.fi Mon May 5 21:04:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id VAA05138 for ; Mon, 5 May 1997 21:04:12 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA44290; Mon, 5 May 1997 20:00:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67390; Mon, 5 May 1997 19:59:50 +0200 Received: from gabriel.keele.ac.uk ([160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id UAA01449 for ; Mon, 5 May 1997 20:52:04 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Sun, 4 May 1997 12:36:03 +0100 From: "A.A. Olowofoyeku" Message-Id: <20074.199705041134@potter.cc.keele.ac.uk> Subject: Re: Short Strings, Schema discriminants, UCSD Pascal (Was: Modifying string length?) To: peter@agnes.dida.physik.uni-essen.de (Peter Gerwinski) Date: Sun, 4 May 1997 12:34:17 +0100 (BST) Cc: gpc@hut.fi In-Reply-To: <199705032145.XAA32637@agnes.dida.physik.uni-essen.de> from "Peter Gerwinski" at May 3, 97 11:45:10 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, Peter Gerwinski! You wrote: > > According to Frank Heckenbach: > > But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't > > really matter to me. > > UCSD Pascal was developed at the University of California San Diego > (UCSD), not by a company, that's why I consider it as a well-defined > standard, although no ISO standard. I have read about a company "SofTech" > distributing UCSD Pascal, and I got mine from Apple as "Apple Pascal". > If somebody has some more exact information, I would be glad to know. Cabot software sells "Cabot UCSD Pascal" - which is available for Dos, OS/2, various unix platforms, and (I think) Win32. It produces portable p-code as well. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12@cc.keele.ac.uk) Author of: Chief's Installer Pro v3.50 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ From gpc-request@santra.hut.fi Thu May 8 12:42:49 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA13135 for ; Thu, 8 May 1997 12:42:48 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA84688; Thu, 8 May 1997 11:37:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49082; Thu, 8 May 1997 11:37:39 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA00901 for ; Thu, 8 May 1997 12:30:37 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id LAA00381 for ; Thu, 8 May 1997 11:31:26 +0100 Date: Thu, 8 May 1997 11:31:25 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: Re: TFDDs - customizing `writeln' (Was: Legal Change in GPC ?) In-Reply-To: <199705080011.CAA26572@helena.mi.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 8 May 1997, Frank Heckenbach wrote: > > Peter Gerwinski wrote: > > > If somebody who knows C wants to implement this for GPC, here are > > some ideas: > > > We are still looking for somebody who wants to implement a portable, > > Borland-compatible `CRT'. (But our `Graph' Unit, "BGI2GRX", works on > > Linux at least.:) > > I'd have some ideas for both, I only need one thing: time... -- perhaps > in late summer/autumn, let's wait and see... -- unless someone wants to > do it earlier. (Actually, I'd probably need some help on portability > questions and other things, we'll see...) I did some work for a UNIX based CRT unit some time ago. However, if you want to do this good (portable), you have to implement both termcap and terminfo support. I took the easy way out and used the 'slang' library (The 'Midnight Commander' uses it). This is overkill. But for me, spare time is limited too, I'm currently finishing up the integration of GPC in the GCC sources and then I'd like to move on to an automated GPC compiler test suite. But "later in the year", some "portability help" should definately possible :-) Greetings, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Thu May 8 03:31:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA11902 for ; Thu, 8 May 1997 03:31:50 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA120038; Thu, 8 May 1997 02:27:04 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA34978; Thu, 8 May 1997 02:26:45 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA02933 for ; Thu, 8 May 1997 03:11:08 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id CAA17494 (8.7.6/7.5c-FAU); for ; Thu, 8 May 1997 02:11:05 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id CAA26571 (SMI-8.6/7.5b-FAU); Thu, 8 May 1997 02:11:00 +0200 From: Frank Heckenbach Message-Id: <199705080011.CAA26571@helena.mi.uni-erlangen.de> Date: Thu, 8 May 1997 02:10:58 +0200 To: gpc@hut.fi Subject: Re: Portability questions (Arrays) Status: RO Now, after Peter's and Berend's answers I'm a bit confused... Could someone clear things up for me, please? Note, I'm talking about gpc, not about other compilers or about the standard. Peter Gerwinski wrote: > Why is this so, e.g. with an array of something which has 3 bytes? > > > Program Test; > > Type > r = packed record > x: ShortWord; > y: Byte; > end (* r *); > > Var > x: packed array [ 1..1000 ] of r; > > begin > writeln ( SizeOf ( x ) ); > writeln ( SizeOf ( x [ 1 ] ) ); > end. > > > The output is 4000 and ... 4. To avoid alignment problems in an "array > of r", the record `r' has size 4, not 3. BTW: Does this mean if you have var a:r; b:byte; then 1 byte after a will be "wasted" though b could fit into it? It has to be so if sizeof(a)=4, if someone does "move(...,a,sizeof(a))". -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu May 8 03:30:44 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA11898 for ; Thu, 8 May 1997 03:30:44 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79306; Thu, 8 May 1997 02:25:59 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45192; Thu, 8 May 1997 02:25:40 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA02130 for ; Thu, 8 May 1997 03:11:09 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id CAA17489 (8.7.6/7.5c-FAU); for ; Thu, 8 May 1997 02:11:04 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id CAA26572 (SMI-8.6/7.5b-FAU); Thu, 8 May 1997 02:11:00 +0200 From: Frank Heckenbach Message-Id: <199705080011.CAA26572@helena.mi.uni-erlangen.de> Date: Thu, 8 May 1997 02:10:59 +0200 To: gpc@hut.fi Subject: Re: TFDDs - customizing `writeln' (Was: Legal Change in GPC ?) Status: RO Peter Gerwinski wrote: > If somebody who knows C wants to implement this for GPC, here are > some ideas: > We are still looking for somebody who wants to implement a portable, > Borland-compatible `CRT'. (But our `Graph' Unit, "BGI2GRX", works on > Linux at least.:) I'd have some ideas for both, I only need one thing: time... -- perhaps in late summer/autumn, let's wait and see... -- unless someone wants to do it earlier. (Actually, I'd probably need some help on portability questions and other things, we'll see...) -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu May 8 03:28:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id DAA11893 for ; Thu, 8 May 1997 03:28:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79234; Thu, 8 May 1997 02:23:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA62276; Thu, 8 May 1997 02:23:15 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA02539 for ; Thu, 8 May 1997 03:11:08 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id CAA17493 (8.7.6/7.5c-FAU); for ; Thu, 8 May 1997 02:11:05 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id CAA26568 (SMI-8.6/7.5b-FAU); Thu, 8 May 1997 02:10:59 +0200 From: Frank Heckenbach Message-Id: <199705080010.CAA26568@helena.mi.uni-erlangen.de> Date: Thu, 8 May 1997 02:10:58 +0200 To: gpc@hut.fi Subject: Short Strings, Schema discriminants, UCSD Pascal (Was: Modifying string length?) Status: RO Peter Gerwinski wrote: > > BP 7.0 allows this via High(s) -- is something like BP's High and Low > > functions (to give the lower and upper bounds of arrays and subrange types) > > present or planned for gpc? [...] > > Yes. Planned, this is? Doesn't seem to be present (or different names?). -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Thu May 8 15:15:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA13383 for ; Thu, 8 May 1997 15:15:04 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA13682; Thu, 8 May 1997 14:10:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52388; Thu, 8 May 1997 14:09:52 +0200 Received: from agnes.dida.physik.uni-essen.de (agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA07978 for ; Thu, 8 May 1997 14:38:17 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA13341 for gpc@hut.fi; Thu, 8 May 1997 14:40:07 +0200 From: Peter Gerwinski Message-Id: <199705081240.OAA13341@agnes.dida.physik.uni-essen.de> Subject: Re: Portability questions (Arrays) To: gpc@hut.fi Date: Thu, 8 May 1997 14:40:06 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > [...] > then 1 byte after a will be "wasted" though b could fit into it? It has to be > so if sizeof(a)=4, if someone does "move(...,a,sizeof(a))". Exactly. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 8 15:14:09 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA13377 for ; Thu, 8 May 1997 15:14:09 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68848; Thu, 8 May 1997 14:09:16 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59768; Thu, 8 May 1997 14:08:57 +0200 Received: from agnes.dida.physik.uni-essen.de (agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA07417 for ; Thu, 8 May 1997 14:37:39 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA13335 for gpc@hut.fi; Thu, 8 May 1997 14:39:30 +0200 From: Peter Gerwinski Message-Id: <199705081239.OAA13335@agnes.dida.physik.uni-essen.de> Subject: Re: Short Strings, Schema discriminants, UCSD Pascal To: gpc@hut.fi Date: Thu, 8 May 1997 14:39:30 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > > [...] present or planned for gpc? [...] > > Yes. > Planned, this is? Doesn't seem to be present (or different names?). Planned. Sorry, I unconsciously made a typical mathematician's mistake ... :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 9 09:10:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA15238 for ; Fri, 9 May 1997 09:10:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA103834; Fri, 9 May 1997 08:05:33 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50578; Fri, 9 May 1997 08:05:14 +0200 Received: from spaceman.cs.wits.ac.za (berend@spaceman.cs.wits.ac.za [146.141.27.178]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id IAA22807 for ; Fri, 9 May 1997 08:52:46 +0300 (EET DST) Received: from localhost (berend@localhost) by spaceman.cs.wits.ac.za (8.8.4/8.8.4) with SMTP id HAA28645 for ; Fri, 9 May 1997 07:53:59 -0200 Date: Fri, 9 May 1997 07:53:58 -0200 (GMT+2) From: Berend De Schouwer To: gpc mailing list Subject: Installed Alpha 04/20 - Can't link Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi I believe this was mentioned before... I installed alpha 4/20 (without making a backup, tch..) on djgpp v2 I can compile and get .o files, but the linking stage doesn't find djgpp.lnk (I assume gpc does "ld @djgpp.lnk") at some stage. I don't mind typing this myself, but I haven't got a sample .lnk file to work with (silly me ;). Any help will be appreciated. Cheers Berend De Schouwer P.S. gcc works fine. From gpc-request@santra.hut.fi Fri May 9 11:33:20 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA15737 for ; Fri, 9 May 1997 11:33:20 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA98750; Fri, 9 May 1997 11:33:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA83938; Fri, 9 May 1997 11:33:01 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA31786 for ; Fri, 9 May 1997 12:22:47 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id LAA00387; Fri, 9 May 1997 11:23:36 +0100 Date: Fri, 9 May 1997 11:23:35 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Cc: Peter Gerwinski Subject: Re: Installed Alpha 04/20 - Can't link In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 9 May 1997, Berend De Schouwer wrote: > Hi > > I believe this was mentioned before... > > I installed alpha 4/20 (without making a backup, tch..) on djgpp v2 > I can compile and get .o files, but the linking stage doesn't > find djgpp.lnk (I assume gpc does "ld @djgpp.lnk") at some stage. > > I don't mind typing this myself, but I haven't got a sample .lnk > file to work with (silly me ;). > I too think we have seen this error before. Maybe it's FAQ-able. djgpp v2.0 uses the linker script 'djgpp.lnk' (in the djgpp 'lib' dir). djgpp v2.01 uses 'djgpp.djl' for this purpose. So, either Peter (who built this GPC binary) is using djgpp v2.0 and you have v2.01, or vice versa. I haven't seen this error with djgpp v2.01, but I always build my own compiler binaries. BTW: 'djgpp.djl' and 'djgpp.lnk' are different files so renaming isn't going to work. To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I assume you are indeed using v2.0. In that case you'd better upgrade to 2.01 to stop this confusion. Hope this helps, JanJaap CC: Peter Gerwinski --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Sat May 10 23:29:29 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA18562 for ; Sat, 10 May 1997 23:29:28 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20008; Sat, 10 May 1997 23:28:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA61688; Sat, 10 May 1997 23:28:39 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA28749 for ; Sun, 11 May 1997 00:20:27 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA18548 for gpc@hut.fi; Sat, 10 May 1997 23:20:51 +0200 From: Peter Gerwinski Message-Id: <199705102120.XAA18548@agnes.dida.physik.uni-essen.de> Subject: New Alpha: gpc-970510 To: gpc@hut.fi Date: Sat, 10 May 1997 23:20:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello! Here again is a new GPC alpha version. Changes since gpc-970420: General news: * `Absolute' now works in declaring statements, too. (Declaring statements are variable declarations in a function's statement part, a GPC extension. `Absolute' variables are a Borland extension supported by GPC.) * Initialization with `=' now has priority with respect to comparision. (Comparisions usually don't occur in initializers.) This means that BP-style typed constants now work as expected. In `--extended-pascal' mode, initialization with `=' is turned OFF, and comparision in initializers works like before. * Added/corrected some dialect-specific warnings. * With `--automake', non-Pascal input files may now occur before the first Pascal input file. * First fragments of a reference manual exist now: GPC's online Texinfo documentation now contains more-ore-less complete information about Integer types - sorted alphabetically from `Byte' to `Word'. * The alpha version number, "970510" for this release, is now output instead of "2.0" when `gpc' is invoked with the `-v' option. I hope this does not break anything ... Bug fixes: * `Page' now can be called with zero or one parameter. * Removed some wrong warnings from `-Wall'. * Parameter lists of methods now may contain a reference to the object they are methods of: MyObject = object Procedure Foo ( Var Bar: MyObject ); end (* MyObject *); * Units exporting different parts of the same object hierarchy work now. You still get a warning, but code works. (When a derived object is exported, complete information about the parent is exported, too. When two Units exported the same parent like this, GPC complained about incompatible definitions of the same identifier.) * Errorneous parent types in object declarations no more crash GPC. * Borland-style #27 character constants now work as the first thing in a line, too. (This bug usually showed up in `case' statements.) Borland Pascal: * Procedural variables work. They can be written like in Borland Pascal, or with the type names only. The same holds for pointers to functions. * ^A .. ^Z character constants work. (Even better than with BP itself.;) * The "link directive" (*$L foo.o *) or (*$L /usr/lib/libfoo.a *) works. As a GPC extension, you also can specify (*$L foo.pas *) or (*$L foo.c *): With `--automake', GPC compiles the specified source if necessary and links the object code. Without `--automake', GPC still links the `.o' file corresponding to the given source name. * `SizeOf' applied to object variables works now. The size is read at run time from the VMT. The object must be initialized. * `TypeOf' applied to object variables works now, too. As a GPC extension, you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax is ON (*$X+*). Extended Pascal: * Schemata work. (-: Well ... my tiny test programs work. This involves parameter passing and `new'ing pointers to undiscriminated Schemata. However I am not very experienced with Schemata, so I cannot give any warranty for them. (Which does not mean that I would give any other warranty, either expressed or implied, ... you know.;) Please help me to test them! I took special care that the String parameter stuff did not break due to the implementation of Schemata. (Read: Passing of String parameters might be broken now; please check.;-) One nice thing: `SizeOf' works with Strings and Schemata. When `p' is a pointer to a String or Schema, `SizeOf ( p^ )' looks into the String or Schema pointed to and determines the correct size at run time. The source - a diff against gpc-970420 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Thanks to Abimbola A. Olowofoyeku, Frank Heckenbach, Jan-Jaap van der Heijden, Kevin A. Foss, and Markus Gerwinski for finding the bugs. And again: Is anybody interested to help to document all this? For example, to write a list of Extended Pascal [Borland Pascal] features which work [do not yet work] in GPC which replace the somehow outdated chapter "Extensions", "Extended Pascal", and "Borland Pascal" in the on-line manual? Or to complete and improve the description of the compiler options in the chapter "Invoking GPC"? If you do something in this direction, just post it here. Greetings, Peter Peter Gerwinski [670510], Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun May 11 11:54:30 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA19788 for ; Sun, 11 May 1997 11:54:29 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA103800; Sun, 11 May 1997 11:53:50 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50938; Sun, 11 May 1997 11:53:32 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id MAA01446 for ; Sun, 11 May 1997 12:47:24 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id LAA19720 for gpc@hut.fi; Sun, 11 May 1997 11:48:00 +0200 From: Peter Gerwinski Message-Id: <199705110948.LAA19720@agnes.dida.physik.uni-essen.de> Subject: Re: Installed Alpha 04/20 - Can't link To: gpc@hut.fi Date: Sun, 11 May 1997 11:48:00 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > assume you are indeed using v2.0. In that case you'd better upgrade to > 2.01 to stop this confusion. I was sure that I am using v2.01, but I re-installed my `djdev201.zip' and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) be v2.01. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed May 14 11:35:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id LAA27545 for ; Wed, 14 May 1997 11:35:55 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA117076; Wed, 14 May 1997 11:34:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA88036; Wed, 14 May 1997 11:34:02 +0200 Received: from spaceman.cs.wits.ac.za (berend@spaceman.cs.wits.ac.za [146.141.27.178]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA01727 for ; Wed, 14 May 1997 12:19:31 +0300 (EET DST) Received: from localhost (berend@localhost) by spaceman.cs.wits.ac.za (8.8.4/8.8.4) with SMTP id LAA17893; Wed, 14 May 1997 11:17:10 -0200 Date: Wed, 14 May 1997 11:17:09 -0200 (GMT+2) From: Berend De Schouwer To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: Installed Alpha 04/20 - Can't link In-Reply-To: <199705110948.LAA19720@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 11 May 1997, Peter Gerwinski wrote: > According to Jan-Jaap van der Heijden: > > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > > assume you are indeed using v2.0. In that case you'd better upgrade to > > 2.01 to stop this confusion. > > I was sure that I am using v2.01, but I re-installed my `djdev201.zip' > and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) > be v2.01. Well, gpc alpha 05/10 still says "ld: can't find djgpp.lnk" BUT, "gpc -v" says "2.0(2.7.2.1)" and not an alpha version number. Did I install it right? I think so. gpc2.0 (non alpha) used to work fine. "gcc -v" reports 2.7.2.1 and works. (compiles hello.c ;) /djgpp/manifest has djdev201.mft, so I think I have djgpp v2.01. I only started using djgpp after 2.01 came out. Is there any other way to find out? (yes, seems like a newbie question ;) I checked my path, and djgpp's ld.exe seems to be the one that gets executed (I also have fpk-pascal, which has an older version). Is there any way I can check version numbers (compared to what?) of these? Can I do something like "gpc --"keep all temporary files" and examine those? What would I be looking for?? I tried both command line, and rhide. I (currently) don't have the disk space to install the source tree, and the files created while compiling. so I can't check that. On a side note: gpc.inf doesn't work (no top node) But gpc.inf and gpc.i1 both reference and contain a top node. I can't see why "info --file gpc.inf" complains... gcc.inf/gcc.i1 look the same (at least in structure) and work. > Greetings, > > Peter > > Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer > peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] > maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] > Cheers Berend De Schouwer. From gpc-request@santra.hut.fi Wed May 14 13:10:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA27732 for ; Wed, 14 May 1997 13:10:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47454; Wed, 14 May 1997 13:08:36 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA72240; Wed, 14 May 1997 13:08:01 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA06463 for ; Wed, 14 May 1997 13:47:03 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id MAA05543; Wed, 14 May 1997 12:47:10 +0100 Date: Wed, 14 May 1997 12:47:09 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: Berend De Schouwer Cc: Peter Gerwinski , gpc@hut.fi Subject: Re: Installed Alpha 04/20 - Can't link In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 14 May 1997, Berend De Schouwer wrote: > > > On Sun, 11 May 1997, Peter Gerwinski wrote: > > > According to Jan-Jaap van der Heijden: > > > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > > > assume you are indeed using v2.0. In that case you'd better upgrade to > > > 2.01 to stop this confusion. > > > > I was sure that I am using v2.01, but I re-installed my `djdev201.zip' > > and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) > > be v2.01. > > Well, gpc alpha 05/10 still says "ld: can't find djgpp.lnk" I found the error: it's in LIB/SPECS.GPC This file has somehow survived from djgpp-2.0 days and thus references "djgpp.lnk" instead of "djgpp.djl", whether you use djgpp v2.01 or not. The link_command should look like: *link_command: %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \ %{r} %{s} %{t} %{u*} %{x} %{z}\ %{!A:%{!nostartfiles:%{!nostdlib:%S}}} %{static:}\ %{L*} %D %{T*} %o -Tdjgpp.djl\ %{!nostdlib:-lgcc -lgpc -lm %L -lgcc %{!A:%E}}}}}}} %{!c:%{!M:%{!MM:%{!E:%{!S:stubify %{v} %{o*:%*} %{!o*:a.out}}}}}} You're in trouble if you see: *link_command: %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \ %{r} %{s} %{t} %{u*} %{x} %{z}\ %{!A:%{!nostartfiles:%{!nostdlib:%S}}} %{static:}\ %{L*} %D %{T*} %o -Tdjgpp.lnk\ %{!nostdlib:-lgcc -lgpc -lm %L -lgcc %{!A:%E}}}}}}} %{!c:%{!M:%{!MM:%{!E:%{!S:stubify %{v} %{o*:%*} %{!o*:a.out}}}}}} To solve this, you can either use the "specs.gpc" from gpc-2.0 (which worked a.f.a.i.k.) or save and uudecode this: begin 644 specs.gpc M*F%S;3H-"@T*#0HJ87-M7V9I;F%L.@T*#0H-"BIC<'`Z#0HE>W!OR%-.B5[(4U-.B5[(44Z)7LA4SIL9"`E;"`E6"`E>V\J?2`E>T%]("5[ M9'T@)7ME*GT@)7MM?2`E>TY]("5[;GT@7`T*"25[W1]("5[ M=2I]("5[>'T@)7MZ?5P-"@DE>R%!.B5[(6YOR%N;W-T M9&QI8CHE4WU]?2`E>W-T871I8SI]7`T*"25[3"I]("5$("5[5"I]("5O("U4 M9&IG<'`N9&IL7`T*"25[(6YOR%!.B5%?7U]?7U]?0T*)7LA8SHE>R%-.B5[(4U-.B5[(44Z)7LA M4SIS='5B:69Y("5[=GT@)7MO*CHE*GT@)7LA;RHZ82YO=71]?7U]?7T@#0H- M"BIL:6(Z#0HM;&,-"@T**G-T87)T9FEL93H-"B5[<&V9U;G-I9VYE M9"UC:&%R.BU$7U]#2$%27U5.4TE'3D5$7U]]#0H-"BIP > On a side note: > gpc.inf doesn't work (no top node) > But gpc.inf and gpc.i1 both reference and contain a top node. I > can't see why "info --file gpc.inf" complains... > > gcc.inf/gcc.i1 look the same (at least in structure) and work. > I'm not an expert in info files, but isn't the top-node the entry for a program in the "dir" file? In that case, try adding GPC, locate the GCC entry: * GCC: (gcc.inf). The GNU C, C++, and Objective-C Compiler And add GPC somewhere, like this: * GPC: (gpc.inf). The GNU Pascal Compiler Hope this helps, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Wed May 14 23:30:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA28840 for ; Wed, 14 May 1997 23:30:18 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA41194; Wed, 14 May 1997 23:28:32 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA03804; Wed, 14 May 1997 23:28:14 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id AAA26399 for ; Thu, 15 May 1997 00:20:09 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id XAA28808; Wed, 14 May 1997 23:21:35 +0200 From: Peter Gerwinski Message-Id: <199705142121.XAA28808@agnes.dida.physik.uni-essen.de> Subject: Re: Installed Alpha 04/20 - Can't link To: berend@spaceman.cs.wits.ac.za, gpc@hut.fi Date: Wed, 14 May 1997 23:21:35 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Berend De Schouwer: > On Sun, 11 May 1997, Peter Gerwinski wrote: > > I was sure that I am using v2.01, but I re-installed my `djdev201.zip' > > and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) > > be v2.01. > > BUT, "gpc -v" says "2.0(2.7.2.1)" and not an alpha version number. > Did I install it right? I think so. Yes, you did. I forgot to set up the alpha version number for djgpp (where it must be done manually.) > gpc2.0 (non alpha) used to work fine. (* GPC 2.0 was compiled by Jan-Jaap, I think. ;*) > Well, gpc alpha 05/10 still says "ld: can't find djgpp.lnk" At least I can reproduce the error now by renaming "djgpp.lnk". As a workaround, I am posting my "djgpp.lnk" below; I will try to figure out what is going on here ... > "gcc -v" reports 2.7.2.1 and works. (compiles hello.c ;) > /djgpp/manifest has djdev201.mft, so I think I have djgpp v2.01. Same holds for my system. > I only started using djgpp after 2.01 came out. Is there any > other way to find out? (yes, seems like a newbie question ;) I join you in this question. > I checked my path, and djgpp's ld.exe seems to be the one that gets > executed (I also have fpk-pascal, which has an older version). > Is there any way I can check version numbers (compared to what?) of these? My BinUtils are 2.5.2 while README.1ST says that 2.7 is the current version for V2. Perhaps this is the problem? > On a side note: > gpc.inf doesn't work (no top node) > But gpc.inf and gpc.i1 both reference and contain a top node. I > can't see why "info --file gpc.inf" complains... > > gcc.inf/gcc.i1 look the same (at least in structure) and work. Something strange happened to the GPC documentation in that binary distribution, sorry. I recompiled the info documentation on my system, and now it's fine. I will correct this error when I will upload a new binary DJGPP distribution once I will have solved that linking problem ... According to Jan-Jaap van der Heijden: > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > assume you are indeed using v2.0. In that case you'd better upgrade to > 2.01 to stop this confusion. I believed I did, but obviously I didn't do it right. Some hints what I should do or check? Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- \djgpp\lib\djgpp.lnk ------------------------------------------------- OUTPUT_FORMAT("coff-go32") ENTRY(start) SECTIONS { .text 0x1000+SIZEOF_HEADERS : { *(.text) etext = . ; _etext = .; . = ALIGN(0x200); } .data ALIGN(0x200) : { djgpp_first_ctor = . ; *(.ctor) djgpp_last_ctor = . ; djgpp_first_dtor = . ; *(.dtor) djgpp_last_dtor = . ; *(.data) edata = . ; _edata = .; . = ALIGN(0x200); } .bss SIZEOF(.data) + ADDR(.data) : { *(.bss) *(COMMON) end = . ; _end = .; . = ALIGN(0x200); } } From gpc-request@santra.hut.fi Thu May 15 00:29:30 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA28971 for ; Thu, 15 May 1997 00:29:29 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA115384; Thu, 15 May 1997 00:27:42 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75166; Thu, 15 May 1997 00:27:25 +0200 Received: from localhost.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA27255 for ; Thu, 15 May 1997 01:21:36 +0300 (EET DST) Received: from localhost (janjaap@localhost) by localhost.student.utwente.nl (8.8.5/8.8.5) with SMTP id AAA04528 for ; Thu, 15 May 1997 00:22:41 +0100 Date: Thu, 15 May 1997 00:22:40 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: Re: Installed Alpha 04/20 - Can't link In-Reply-To: <199705142121.XAA28808@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 14 May 1997, Peter Gerwinski wrote: > According to Berend De Schouwer: > > On Sun, 11 May 1997, Peter Gerwinski wrote: > > > I was sure that I am using v2.01, but I re-installed my `djdev201.zip' > > > and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) > > > be v2.01. > > [...] > > Well, gpc alpha 05/10 still says "ld: can't find djgpp.lnk" > > At least I can reproduce the error now by renaming "djgpp.lnk". > As a workaround, I am posting my "djgpp.lnk" below; I will try > to figure out what is going on here ... > > > "gcc -v" reports 2.7.2.1 and works. (compiles hello.c ;) > > /djgpp/manifest has djdev201.mft, so I think I have djgpp v2.01. > > Same holds for my system. > > > I only started using djgpp after 2.01 came out. Is there any > > other way to find out? (yes, seems like a newbie question ;) > > I join you in this question. > The minimum V2.01 system is: * djdev201 * gcc2721 * bnu27 (I'm not sure running bnu252 or gcc272 is fatal) >From V2 to V2.01, "djgpp.lnk" was renamed to "djgpp.djl" gcc.exe reads rules from "specs" which was adapted to mention "djgpp.djl" instead of "djgpp.lnk" Unfortunately, GPC (gpc.exe) reads it's rules from "specs.gpc", which, in Peter's alpha DJ binaries, still referred to "djgpp.lnk" Since Peter probably installed djdev201 over djdev200, he probably has both "djgpp.lnk" and "djgpp.djl", hence didn't notice the problem. So, please do _NOT_ rename your djgpp.djl to djgpp.lnk, this only prolongs the confusion. Edit "specs.gpc" to make GPC use djgpp.djl. Get rid of "djgpp.lnk" Hope this thread is finished now... JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Thu May 15 01:22:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA29195 for ; Thu, 15 May 1997 01:22:21 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA115362; Thu, 15 May 1997 01:20:33 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA52922; Thu, 15 May 1997 01:20:15 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA28120 for ; Thu, 15 May 1997 02:12:59 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA29109 for gpc@hut.fi; Thu, 15 May 1997 01:14:44 +0200 From: Peter Gerwinski Message-Id: <199705142314.BAA29109@agnes.dida.physik.uni-essen.de> Subject: New gpc-970510 for DJGPP (Was: Installed Alpha 04/20 - Can't link) To: gpc@hut.fi Date: Thu, 15 May 1997 01:14:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > Unfortunately, GPC (gpc.exe) reads it's rules from "specs.gpc", which, in > Peter's alpha DJ binaries, still referred to "djgpp.lnk" I am uploading a new binary distribution for DJGPP which has Jan-Jaap's `specs.gpc' and simultaneously fixes the bug in the info documentation. (But it still versions to 2.0, not to 970610 as promised, because I was too lazy to recompile GPC.) > Since Peter probably installed djdev201 over djdev200, he probably has > both "djgpp.lnk" and "djgpp.djl", hence didn't notice the problem. Correct. But now I will remove `djgpp.lnk'. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 15 07:10:38 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA30238 for ; Thu, 15 May 1997 07:10:38 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA17412; Thu, 15 May 1997 07:08:49 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA73958; Thu, 15 May 1997 07:08:32 +0200 Received: from mail.castrop-rauxel.netsurf.de (root@Mail.Castrop-Rauxel.NetSurf.de [194.64.248.1]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id HAA30298 for ; Thu, 15 May 1997 07:57:33 +0300 (EET DST) Received: from kalwa1 (isdn64.Castrop-Rauxel.NetSurf.DE [194.64.248.100]) by mail.castrop-rauxel.netsurf.de (8.8.5/INS-G1.3.3) with SMTP id GAA23646 for ; Thu, 15 May 1997 06:57:25 +0200 (MET DST) Received: by kalwa1 with Microsoft Mail id <01BC60FD.4006A160@kalwa1>; Thu, 15 May 1997 06:57:27 +-200 Message-Id: <01BC60FD.4006A160@kalwa1> From: Achim Kalwa To: "'gpc@hut.fi'" Subject: Re: gpc.inf doesn't work [Was: Installed Alpha 04/20 - Can't link] Date: Thu, 15 May 1997 06:56:52 +-200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: RO Hello! On Thu, 15 Mai 1997, Peter Gerwinski wrote: >According to Berend De Schouwer: [...] >> On a side note: >> gpc.inf doesn't work (no top node) >> But gpc.inf and gpc.i1 both reference and contain a top node. I >> can't see why "info --file gpc.inf" complains... >> >> gcc.inf/gcc.i1 look the same (at least in structure) and work. > >Something strange happened to the GPC documentation in that binary >distribution, sorry. I recompiled the info documentation on my system, >and now it's fine. I will correct this error when I will upload a new >binary DJGPP distribution once I will have solved that linking problem ... I have similar problems with the gpc-info files (gpc 950510) on my linux machine (2.0.29): "info gpc" says: "no manual entry for gpc" "info --file gpc.info" works fine. CU Achim From gpc-request@santra.hut.fi Thu May 15 10:00:52 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA30572 for ; Thu, 15 May 1997 10:00:52 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA121252; Thu, 15 May 1997 09:59:00 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26508; Thu, 15 May 1997 09:58:43 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id KAA03958 for ; Thu, 15 May 1997 10:41:24 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id JAA30525 for gpc@hut.fi; Thu, 15 May 1997 09:43:14 +0200 From: Peter Gerwinski Message-Id: <199705150743.JAA30525@agnes.dida.physik.uni-essen.de> Subject: Re: gpc.inf doesn't work [Was: Installed Alpha 04/20 - Can't link] To: gpc@hut.fi Date: Thu, 15 May 1997 09:43:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Achim Kalwa: > I have similar problems with the gpc-info files (gpc 950510) on my linux machine (2.0.29): > "info gpc" says: "no manual entry for gpc" > "info --file gpc.info" works fine. That's because the `dir' file in the info directory doesn't have an entry about gpc. You can insert it manually by editing `/usr/info/dir', e.g. by inserting a line * GPC: (gpc). Informations about the GNU Pascal compiler In principle we could include an updated `dir' into the GPC distribution, but this might make other programs barf, so we don't do it. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Thu May 15 17:33:34 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA31263 for ; Thu, 15 May 1997 17:33:33 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA101804; Thu, 15 May 1997 17:31:34 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA26242; Thu, 15 May 1997 17:31:17 +0200 Received: from ulam.fis.unico.it (ulam.fis.unico.it [131.175.56.103]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA23318 for ; Thu, 15 May 1997 18:23:58 +0300 (EET DST) Received: from arnold.fis.unico.it (arnold [131.175.56.105]) by ulam.fis.unico.it (8.8.5/8.7.3) with SMTP id RAA00300; Thu, 15 May 1997 17:23:28 +0200 (MET DST) Received: from localhost by arnold.fis.unico.it (SMI-8.6/SMI-SVR4) id RAA01540; Thu, 15 May 1997 17:23:28 +0200 Date: Thu, 15 May 1997 17:23:27 +0200 (MET DST) From: Vadim Aleksandrovich Denisyuk Reply-To: Vadim Aleksandrovich Denisyuk To: gpc@hut.fi Cc: Peter Gerwinski Subject: Linking errors (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO This is a list of the unreferenced symbols I obtain linking the GPC V2.0-alpha970510 against GCC 2.7.2.2.f.2 I suspect most, if not all, of these errors are caused by the modifications caused by G77 0.5.20. I had a less serious version of this problem with GPC 2.0, GCC 2.7.2.1 and G77 0.5.18. That was related to new gcc optimization options introduced by G77, and unrecognized by the GPC front-end, and was easy to overcome. This one, at first glance, looks fare more serious. ============================================================================ Undefined first referenced symbol in file reg_known_equiv_p ../gcc-2.7.2.2/sched.o size_volatile gpc-util.o maybe_find_function_data gpc-parse.o emit_string_move gpc-util.o read_dependence ../gcc-2.7.2.2/sched.o record_base_value ../gcc-2.7.2.2/loop.o output_dependence ../gcc-2.7.2.2/sched.o version_flag gpc-module.o true_dependence ../gcc-2.7.2.2/cse.o anti_dependence ../gcc-2.7.2.2/sched.o reg_known_value ../gcc-2.7.2.2/sched.o emit_string_pad gpc-util.o init_alias_analysis ../gcc-2.7.2.2/cse.o dbxout_set_type_status gpc-decl.o ld: fatal: Symbol referencing errors. No output written to gpc1 *** Error code 1 make: Fatal error: Command failed for target `gpc1' ============================================================================= Yours, Vadim Denisyuk P.S. Peter tvoy ruskiy is very GOOD From gpc-request@santra.hut.fi Thu May 15 16:24:46 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA31165 for ; Thu, 15 May 1997 16:24:46 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA121882; Thu, 15 May 1997 16:22:48 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA67866; Thu, 15 May 1997 16:22:31 +0200 Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id RAA20542 for ; Thu, 15 May 1997 17:10:20 +0300 (EET DST) Received: from spectro.ujf-grenoble.fr (spectro.ujf-grenoble.fr [193.54.234.59]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id QAA22404 for ; Thu, 15 May 1997 16:10:15 +0200 (MET DST) Received: from [193.54.234.27] (knautie.ujf-grenoble.fr [193.54.234.27]) by spectro.ujf-grenoble.fr (8.7.6/8.6.9) with SMTP id PAA02064 for ; Thu, 15 May 1997 15:57:12 +0200 (METDST) X-Nupop-Charset: English Date: Thu, 15 May 1997 15:53:28 +0100 (MET) From: "Maurice Lombardi" Sender: Maurice.LOMBARDI@ujf-grenoble.fr Message-Id: <57241.lombardi@spectro.ujf-grenoble.fr> To: gpc@hut.fi Subject: New Alpha: gpc-970510 Status: RO I have downloaded the yesterday evening (14/05/97 23:..) modified version of alpha gpc-970510 for DJGPP v2.1 (zip file). The link problem is solved but the standalone info problem remains. I can read (gpc)Top with Rhide 1.2 but the standalone info barks no Top node. Looking to what could be anomalous in gpc.inf I have found they the last line of this file End Tag Table is repeated twice. I have used a UNIX-format editor to eliminate the second spurious line. With this modification standalone info (as well as with Rhide 1.2) no more complains. I cannot understand why. For the origin of this spurious duplication I have an hint: When Rhide finds an .inf file in DOS format (return/ line feed), it sometimes barks: File in Dos Format, and translate it into Unix format (linefeed alone). I have done the following when trying to understand the problem: I have translated gpc.inf (and gpc.i?) into DOS format, started Rhide which have barked, and have found when exiting that the files where again in Unix format, but with the last line repeated three times !!! I cannot understand the logic of that, because my gcc.inf are in DOS format and Rhide does not complain, and for exemple gpc.inf (now after the last modification), bison.inf and others are in unix format: only Robert can say what he does exactly to recognize the format and to change it. Hoping that it will help. Maurice Lombardi | Laboratoire de Spectrometrie Physique | Maurice.Lombardi@ujf-grenoble.fr Universite Joseph Fourier de Grenoble | tel: (33) (0)4 76 51 47 51 BP 87 | fax: (33) (0)4 76 51 45 44 38402 Saint Martin d'Heres Cedex FRANCE | From gpc-request@santra.hut.fi Thu May 15 22:16:00 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA31653 for ; Thu, 15 May 1997 22:15:59 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70292; Thu, 15 May 1997 22:13:56 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA74136; Thu, 15 May 1997 22:13:39 +0200 Received: from public.ndh.com (public.ndh.com [194.97.97.10]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id XAA29970 for ; Thu, 15 May 1997 23:08:34 +0300 (EET DST) Received: (from tribal@localhost) by public.ndh.com (8.8.0/8.6.9) id WAA27185; Thu, 15 May 1997 22:08:12 +0200 (MET DST) >>Received: by tribal.line.org (AnUUCP/UUSamm 1.703 BETA (11.5.97)); Thu, 15 May 1997 22:05:12 +0200 Message-Id: <6Wt-ddZbRMB@p-wendt.chateau.LiNe.OrG> From: C.WENDT@CHATEAU.line.org (Christian Wendt) Received: from tribal.line.org by public.ndh.com; Thu, 15 May 1997 22:08 MET Received: by tribal.line.org (AnUUCP/UUSamm 1.703 BETA (11.5.97)); Thu, 15 May 1997 22:05:12 +0200 Received: by tribal.line.org; Thu, 15 May 1997 19:08:18 +0200 Date: Wed, 14 May 1997 22:33:00 +0200 Subject: Re: gpc.inf doesn't work (was:Installed Alpha 04/20 - Can't link) X-Gateway: ZCONNECT tribal.line.org [AnUUCP/UUSamm 1.703 BETA (11.5.97)] X-Mailer: CrossPoint v3.11 In-Reply-To: To: gpc@hut.fi, berend@spaceman.cs.wits.ac.za Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 Status: RO BDS>gpc.inf doesn't work (no top node) BDS>But gpc.inf and gpc.i1 both reference and contain a top node. I BDS>can't see why "info --file gpc.inf" complains... BDS> BDS>gcc.inf/gcc.i1 look the same (at least in structure) and work. it's some problem with structure - i bet the makeinfo version (top of dokument - this file is produced by ... or smth. like that) differs. if that's the case - try to get an newer version of the info programm... that's been the solution to the problem on my system. BDS>Cheers BDS>Berend De Schouwer. Chris --- HomeBox : Chateau - +49(0)8677 911940(V.34) 911941(ISDN) *! New Address - C.Wendt@chateau.line.org !* ## CrossPoint v3.11 ## From gpc-request@santra.hut.fi Thu May 15 23:06:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id XAA31738 for ; Thu, 15 May 1997 23:06:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA135788; Thu, 15 May 1997 23:04:52 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75394; Thu, 15 May 1997 23:04:35 +0200 Received: from ca04.cad.ornl.gov (ca04.cad.ornl.gov [128.219.155.3]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id AAA30606 for ; Fri, 16 May 1997 00:00:46 +0300 (EET DST) Received: from [128.219.149.237] (gsmpmac.cad.ornl.gov [128.219.149.237]) by ca04.cad.ornl.gov (8.7.6/8.7.3) with ESMTP id RAA30178 for ; Thu, 15 May 1997 17:00:42 -0400 X-Sender: gsm@ca04.cad.ornl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 1997 17:04:51 -0400 To: gpc@hut.fi From: "Gregory S. McNeilly" Subject: GNU Pascal for MachTen Status: RO Hello - Has anyone ported GNU Pascal to MachTen? (MachTen is the Unix system operating with the MacOS on PowerMacs.) Please reply directly to me. Thanks for any information. Greg McNeilly ------------------- Gregory S. McNeilly ( gsm@ornl.gov ) ,---. Oak Ridge National Laboratory o \ POB 2008 <=====< >=====> Oak Ridge, TN 37831-6418 o / (423)574-5446 (FAX)574-0625 \___/ ------------------- http://casa.cad.ornl.gov/~gsm/ From gpc-request@santra.hut.fi Fri May 16 01:09:15 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA31966 for ; Fri, 16 May 1997 01:09:15 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA96604; Fri, 16 May 1997 01:07:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA50438; Fri, 16 May 1997 01:06:51 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA31505 for ; Fri, 16 May 1997 02:00:34 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA31944; Fri, 16 May 1997 01:02:34 +0200 From: Peter Gerwinski Message-Id: <199705152302.BAA31944@agnes.dida.physik.uni-essen.de> Subject: Re: Linking errors To: denisyuk@fis.unico.it, gpc@hut.fi Date: Fri, 16 May 1997 01:02:34 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Vadim Aleksandrovich Denisyuk: > > This is a list of the unreferenced symbols I obtain linking the GPC > V2.0-alpha970510 against GCC 2.7.2.2.f.2 > [...] > emit_string_move gpc-util.o This is probably a "vpath" problem. The GPC FAQ says: 8< ---- begin (* FAQ *) ------------------------------------------------ Help! linking `gpc1' fails: `_emit_string_move' undefined (and more) If linking `gpc1' bombs out with an error message that looks like this: ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' you probably suffer from a VPATH make problem. A few GPC source files have counterparts with identical name in the GCC source directory. When you have built GCC in the GCC source directory and you are not using a recent version of GNU make this problem may occur. There are three solutions: 1. Get a recent version of GNU make. Version 3.74 or better is known to work. 2. Build GCC in a seperate directory instead of using the GCC source directory. 3. Manually delete these files from the GCC object directory: `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. 8< ---- end (* FAQ *) -------------------------------------------------- > P.S. Peter tvoy ruskiy is very GOOD Spasibo, :-) no ya znayu chto mnye nado uprazhnyat'cya ... Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 16 09:41:33 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id JAA00568 for ; Fri, 16 May 1997 09:41:33 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA153962; Fri, 16 May 1997 09:39:22 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45876; Fri, 16 May 1997 09:39:05 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id KAA05992 for ; Fri, 16 May 1997 10:32:53 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id JAA00508 for gpc@hut.fi; Fri, 16 May 1997 09:35:01 +0200 From: Peter Gerwinski Message-Id: <199705160735.JAA00508@agnes.dida.physik.uni-essen.de> Subject: gpc-970510: source uploaded To: gpc@hut.fi Date: Fri, 16 May 1997 09:35:00 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello, I was reported problems dealing with the many patches for the GPC alpha source, so I uploaded the source tree of gpc-970510 as a `.tar.gz' archive to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. (Anyway I hope that we can enter beta stage soon.:) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 16 14:34:22 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA01210 for ; Fri, 16 May 1997 14:34:21 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA122926; Fri, 16 May 1997 14:32:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA54280; Fri, 16 May 1997 14:31:44 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA18722 for ; Fri, 16 May 1997 15:06:58 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id OAA00431; Fri, 16 May 1997 14:07:27 +0100 Date: Fri, 16 May 1997 14:07:26 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: "Gregory S. McNeilly" Cc: gpc@hut.fi Subject: Re: GNU Pascal for MachTen In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 15 May 1997, Gregory S. McNeilly wrote: > > Hello - > > Has anyone ported GNU Pascal to MachTen? > > (MachTen is the Unix system operating with the MacOS on PowerMacs.) > > Please reply directly to me. > This might be of interest to the rest, so I'll cc to the GPC list. I have not heard of anybody running GPC on MachTen, so I guess finding a compiler binary isn't going to work. Basically, if you want to build GPC for a given target, there are two requirements: 1) Your platform must be supported by GCC. 2) You must have a compiler capable of building GCC. ad 1: I'm not so sure. I know there (was?) is some Mac / 68k stuff around, I know Cygnus supports PPC/WinNT and MPW. I attached the mpw-README, so see if that's what you have. You can always run `config.guess' from the GCC directory and see if it recognizes your hardware/OS. ad 2: This may sound trivial, but building GCC has proven to be an excelent way to reveal bug and/or limitations in many commercial compilers. You also need a C library, assembler, linker etc. and some tools (lex, yacc, sed) If what you have is MPW, then you must build GPC using the Cygnus GCC sources, not FSF. Currently, this is far from trivial :-( Since the cygnus sources are under development (they show what gcc 2.8 will look like), GPC must be adapted to work with them. But, since we still plan to have GPC when GCC 2.8 comes, I'm already working on this (already built some true pentium optimizing GPC's) :-) Greetings, JanJaap --------------------------- mpw-README --------------------------------- This is basic information about the Macintosh(tm) MPW(tm) port of the GNU tools. The information below applies to both native and cross compilers. (Please note that there are two versions of this file; "mpw-README" is the source form, and "Read Me for MPW" is the distribution form. "Read Me for MPW" has 8-bit chars such as \Option-d embedded in it.) INSTALLING GNU TOOLS * System Requirements To use these tools, you will need a Mac with a 68020 or better or else any PowerMac, System 7.1 or later, and MPW 3.3 or 3.4. You will *not* need any other MPW compiler unless you want to rebuild from sources, nor even any include files, unless you are building actual Mac applications. For PowerMac native you will need PPCLink, however; also the executables are PowerPC-only. * Automated Installation The simplest way to install GNU tools is to run the Install script. The script will copy things to where you want to keep them, will build a UserStartup file with settings corresponding to where things were copied, and offer to put that UserStartup file in your MPW folder. The Install script does not alter anything in the System Folder, and it does not take any action without confirmation. The Install script will be at the top level of the binary distribution, or at the top level of the object directory if rebuilding from source. (The sources include a file called "mpw-install" at the top level, but it is the source to the Install script and cannot be run directly.) * Manual Installation If you don't want to run the Install script, you can do installation manually; this section describes the steps involved. The GNU tools can go in any directory that is in your {Commands} list. We generally put all the tools somewhere like {Boot}Cygnus:latest:bin, and then add to a UserStartup file: set Commands "{Boot}Cygnus:latest:bin:,{Commands}" However, the cpp and cc1 programs of GCC are not normally stored here. Instead, they will be in a "lib" directory that is alongside "bin", and organized by target and version underneath, with names like :lib:gcc-lib::cygnus-: If you build and install everything yourself according to the build instructions below, then you will not have any problems. However, you may discover that GCC seems unable to find the right cpp and cc1; usually this will be because directory names have changed. (Even renaming your hard disk will make this happen.) In such cases, you have several choices. One is just to add this directory to {Commands}, but then you will not be able to get any other cpp or cc1, such as those used by a different target or version. Another way is to rename your disk and directories to match the prefix used when the tools were compiled. Finally, you can set the variable GCC_EXEC_PREFIX to point to the library directory: set GCC_EXEC_PREFIX MyDisk:Stuff:lib:gcc-lib: export GCC_EXEC_PREFIX You may also want to edit MPW's HEXA 128 resource. When GCC is built using a native GCC, it is compiled to use a special stack allocator function alloca(). While this is very efficient, it means that GCC will need considerable stack space to run, especially when compiling large programs with optimization turned on. You give MPW more stack by editing the HEXA 128 resource of the MPW Shell. A value of "0008 0000" gives 512K of stack size, which is usually sufficient. USING GNU TOOLS * Using Native PowerMac GCC Using a native PowerMac GCC to produce MPW tools or MacOS applications is more complicated than just "gC foo.c", although no more complicated than with other Mac compilers. To build a native PowerMac MPW tool, use this sequence, where hello.c is the usual "hello world" program, and genericcfrg.r is the Rez file with the code fragment resource: gC -I{CIncludes} -fno-builtin -Dpascal= -c -g hello.c PPCLink hello.o -o hello \Option-d "{PPCLibraries}"StdCRuntime.o \Option-d "{SharedLibraries}"InterfaceLib \Option-d "{SharedLibraries}"StdCLib \Option-d "{PPCLibraries}"PPCToolLibs.o \Option-d "{PPCLibraries}"PPCCRuntime.o \Option-d "{GCCPPCLibraries}"libgcc.xcoff rez -d APPNAME='"'hello'"' GenericCFRG.r -o hello setfile -t 'MPST' -c 'MPS ' hello The same sequence works to build a MacOS application, but you set the file type to 'APPL' and don't link in PPCToolLibs.o. For further details on using MPW to build Mac applications, see the general MPW documentation. Recent versions of PPCLink have an option to generate the code fragment resource and automatically set creator and file type; here is what GenericCFRG.r should look like if you have an older PPCLink or are using GNU ld: #include "CodeFragmentTypes.r" resource 'cfrg' (0) { { kPowerPC, kFullLib, kNoVersionNum,kNoVersionNum, 0,0, kIsApp,kOnDiskFlat,kZeroOffset,kWholeFork, APPNAME // must be defined on Rez command line with -d option } }; In general this port of GCC supports the same option syntax and behavior as its Unix counterpart. It also has similar compilation rules, so it will run the assembler on .s files and so forth. The GCC manual includes full information on the available options. One option that may be especially useful is "-v", which shows you what tools and options are being used; unlike most Mac C compilers, GCC directs assembly and linking in addition to compilation. MPW GCC does feature two extensions to the option syntax; '-d macro=name' works just as '-Dmacro=name' does in Unix, and '-i directory' works the same as '-Idirectory'. MPW GCC supports the usual Pascal-style strings and alignment pragmas. To find standard include files you can set the variable GCCIncludes: set GCCIncludes MyDisk:MyIncludes: export GCCIncludes GCCIncludes is similar to MPW's CIncludes or CW's MWCIncludes. In order to use MPW's usual include files, just say: set GCCIncludes "{CIncludes}" export GCCIncludes * Using GCC as a Cross-Compiler If you have a cross-compiler, and you have all of the correct target-side crt0 and libraries available, then to compile and link a file "foo.c", you can say just gC foo.c The output file will be an MPW binary file named "a.out"; the format of the contents will depend on which target is in use, so for instance a MIPS-targeting GCC will produce ECOFF or ELF executables. Note that using MPW include files with a cross-compiler is somewhat dangerous. * Using the Assembler and Friends The assembler ("as") and linker ("ld") are faithful ports of their Unix counterparts. Similarly, the binutils "ar", "cplusfilt", "nm", "objcopy", "objdump", "ranlib", "size", "strings", and "strip" are all like they are under Unix. (Note that "cplusfilt" is usually called "c++filt" under Unix.) * Using GDB There are two flavors of GDB. "gdb" is an MPW tool that works very much like it does in Unix; put a command into the MPW worksheet and type the key to send it to GDB. While "gdb" is running, you cannot do anything else in MPW, although you can switch to other Mac applications and use them. "SiowGDB" is also a Mac application, but it is GDB using the SIOW package to provide console emulation. Commands are exactly as for the MPW tool, but since this is its own application, you can switch between it and MPW. BUILDING GNU TOOLS This port of the GNU tools uses a configure script similar to that used for GNU tools under Unix, but rewritten for MPW. As with Unix configuration, there is an "object" directory that may be different from the "source" directory. In the example commands below, we will assume that we are currently in the object directory, and that the source directory is "{Boot}Cygnus:src:". * Requirements for Building In addition to the sources, you will need a set of tools that the configure and build scripts assume to be available. These tools (and their versions, if relevant) are as follows: byacc tool flex (2.3.7) tool (and Flex.skel file) forward-include script MoveIfChange script mpw-touch script mpw-true script NewFolderRecursive script null-command script open-brace script sed (1.13) tool tr-7to8 script true script The scripts are in the sources, under utils:mpw:. You must arrange to get the other tools yourself (they are readily available from the "usual" net sites, and are also on many CDROMS). In addition, there will usually be a set of these available at ftp.cygnus.com, in pub/mac. You may put the build tools in your usual Tools or Scripts directories, or keep them in a separate directories. We prefer to make a directory called "buildtools" and we put this in one of our UserStartup files: set Commands "{Boot}Cygnus:buildtools:,{Commands}" Flex uses an environment variable FLEX_SKELETON to locate its skeleton file, so you need to do something like this, preferably in a UserStartup: Set FLEX_SKELETON "{Boot}"Cygnus:buildtools:Flex.skel Export FLEX_SKELETON * Configuring Before you can build anything, you must configure. You do this by creating an directory where object files will be stored, setdirectory to that directory and do a configure command: {Boot}Cygnus:src:mpw-configure --target --cc --srcdir {Boot}Cygnus:src: --prefix If the source directory is not in your {Commands} list, then you must supply a full pathname to mpw-configure, since mpw-configure invokes itself after switching into each subdirectory. Using a relative pathname, even something like ':mpw-configure', will therefore not work. must be a known target. Valid ones include "m68k-apple-macos", "powerpc-apple-macos", "i386-unknown-go32", "mips-idt-ecoff", and "sh-hitachi-hms". Not all target types are accepted for all of the tools yet. must be the name of the compiler to use. It defaults to "mpwc". (m68k) mpwc MPW C sc68k Symantec C mwc68k Metrowerks C (Codewarrior) gcc68k GCC (powerpc) ppcc PPCC mrc Macintosh on RisC (Mister C, aka(?) Frankenstein) scppc Symantec C mwcppc Metrowerks C (Codewarrior) gccppc GCC Not all compilers will compile all tools equally well! For m68k Macs, MPW C has the best record so far (it has problems, but they can be worked around), while for PowerMacs, CodeWarrior is the only compiler that has successfully compiled everything into running code. is the path that "gcc" will prepend when looking for tools to execute. GCC_EXEC_PREFIX overrides this value, so you need not include it if you plan to use GCC_EXEC_PREFIX. As an example, here is the configure line that you could use to build native PowerMac GCC: "{Boot}"Cygnus:src:mpw-configure --cc mwcppc --target powerpc-apple-macos --srcdir "{Boot}"Cygnus:src: --prefix "{Boot}"GNUTools: * Building If you use CodeWarrior, you *must* first set MWCIncludes to {CIncludes}. This is because you will be building MPW tools, and their standard I/O works by making references to data that is part of the MPW Shell, which means that the code must be compiled and linked with macros that refer to that data, and those macros are in {CIncludes}, not the default {MWCIncludes}. Without this change, you will encounter problems compiling libiberty/mpw.c, but tweaking that file only masks the real problem, and does not fix it. The command mpw-build will build everything. Building will take over an hour on a Quadra 800 or PowerMac 8100/110, longer if the sources are on a shared volume. You may see some warnings; these are mostly likely benign, typically disagreements about declarations of library and system functions. * Installing To install the just-built tools, use the command mpw-build install This part of the installation procedure just copies files to the location specified at configure time by , and, in some cases, renames them from temporary internal names to their usual names. This install process is *not* the same as what the Install script does; Install can copy tools from the installation location chosen at configuration time to a user-chosen place, and sets up a UserStartup file. Note that while the Install script is optional, the install build action performs some tasks would be very hard to replicate manually, so you should always do it before using the tools. * Known Problems With Using Various Compilers to Build Most versions of MPW C have problems with compiling GNU software. MPW C 3.2.x has preprocessing bugs that render it incapable of compiling the BFD library, so it can't be used at all for building BFD. MPW C 3.3, 3.3.1, and 3.3.2 will spontaneously claim to have found errors in the source code, but in fact the code is perfectly fine. If this happens, just set the working directory back to the top-level objdir (where the configure command above was performed), and type "mpw-build all" again. If it goes on through the supposed error, then you got one of the spurious errors. A full build may require a number of these restarts. MPW C 3.3.3 seems to work OK, at least with the aid of a number of workarounds that are in the sources (look for #ifdef MPW_C). Versions of MPW Make earlier than 4.0d2 have exhibited bizarre behavior, failure to substitute variables and the like. Metrowerks CW6 PPC linker (MWLinkPPC) seems to do bad things with memory if the "Modern Memory Manager" is turned on (in the Memory control panel), but works OK if it is turned off. Metrowerks CW6 loses bigtime compiling opcodes:ppc-opc.c, which has some deeply nested macros. (CW7 is OK.) There is a way to patch the file, by substituting constant values. If you need to do this, contact shebs@cygnus.com for details. is missing from {CIncludes} in the MPW version that comes with CW7. You can just copy the one in CW7's {MWCIncludes}. CW8 and later have changes to headers and such that will require changes to the source in order to be able to use them to rebuild. KNOWN BUGS The declarations for memcpy and memcmp in some versions of header files may conflict with GCC's builtin definition. Either use -fno-builtin or ignore the warnings. This is not a bug, but - watch out for cr/nl translation! For instance, if config/mpw-mh-mpw is not properly translated because it has been copied or updated separately, then everything will almost build, but you will get puzzling error messages from make or the compiler. '/' or ' ' embedded in any device, directory, or file name may or may not work. objcopy -O srec foo.o makes random output filenames. Mac-x-mips requires -mgas but Unix hosts don't. GDB will frequently require a '/' on the front of a device name in order to recognize it as an absolute rather than a relative pathname. GDB doesn't seem to use the printer port correctly, although it tries. The cursor doesn't always spin as much as it should. To get elaborate statistics and warnings about spin rates, add this to UserStartup: set MEASURE_SPIN all export MEASURE_SPIN --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Sun May 18 02:28:06 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA04729 for ; Sun, 18 May 1997 02:28:05 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20824; Sun, 18 May 1997 02:25:20 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA43604; Sun, 18 May 1997 02:25:03 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id CAA10854 for ; Sun, 18 May 1997 02:16:47 +0300 (EET DST) Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id BAA117764 for ; Sun, 18 May 1997 01:55:01 +0300 Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Sat, 17 May 1997 23:56:44 +0100 From: "A.A. Olowofoyeku" Message-Id: <7882.199705172254@potter.cc.keele.ac.uk> Subject: BPCOMPAT - New "Borland" compatible UNITs for GPC !!! To: gpc@hut.fi Date: Sat, 17 May 1997 23:54:55 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi GPC folks! This is to announce the release of BPCOMPAT v 1.0, which has now been uploaded to agnes (in the "contrib" directory). If you are looking for greater Borland Pascal compatibility and/or you are looking for a big function library for GPC, you please download this package. You can get a copy from; ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip This package serves a number of functions; 1. To provide UNITS for GPC in order to improve is compatibility with Borland Pascal. This package provides the following units for Borland Pascal ("BP") and Delphi compatibility; SYSTEM.PAS - BP compatible "SYSTEM" unit CRT.PAS - BP compatible CRT unit DOS.PAS - BP compatible DOS unit OBJECTS.PAS - BP compatible OBJECTS unit STRINGS.PAS - BP compatible STRINGS unit SYSUTILS.PAS - DELPHI compatible SYSUTILS unit GPCTYPES.PAS - various type definitions XSYSTEM.PAS - extra vital system stuff - not in BP GPCUTIL.PAS - Chief's Utilites unit - needed by some units NOTE: some of the BP and Delphi compatible units contain missing features, some things are quite different from the BP equivalents, and some of the routines do not work well. Differences are clearly marked in the source code, and those routines that do not work well are also clearly marked. 2. To provide a library of useful routines for GPC - some of them take the form of UNITs which import various routines from the C library - i.e., they are import units for various ".H" files in the C library. The routines which are not imported C functions are contained in GPCUTIL.PAS. Some of them provide compatibility with TurboPower Software's "Turbo Professional" library. Some of the functions in the converted C headers will not work properly - if you can make them work, fine. If not, please don't mail me - I can't make them work either. 3. To provide a shell program ("GPCC") for the GPC compiler. GPCC will accept parameters from the command line, and will also read parameters from an ascii file GPCC.CFG. All these will be passed on to the GPC compiler. GPCC also will detect whether the source file is a UNIT or a PROGRAM, and will pass extra parameters to the GPC compiler as required. GPCC is tailored to work a bit similarly to the Borland command line compiler (TPC or BPC). These are the import UNITs for various C header files; BIOS.PAS CONIO.PAS CTYPE.PAS DIR.PAS DOSH.PAS DPMI.PAS ERRORNO.PAS FCNTL.PAS IO.PAS PC.PAS PROCESS.PAS STATS.PAS STDIO.PAS STDLIB.PAS STRINGH.PAS SYS.PAS TIME.PAS UNISTD.PAS VALUES.PAS IMPROVEMENTS ------------ It is my hope that someone (or some people) will take this on from here, and improve on this package. Some of the functions could be written more efficiently. My main concern has been to provide working and reliable implementations of various parts of the BP runtime library - not to implement the functions in the most efficient way. It is also my hope that the package will be ported to other platforms. The current one has only been tested under DOS (DJGPP - but it should also be okay for EMX). However, I made sure that the SYSTEM.PAS unit uses only portable functions from the C library - so that should be easy to port to Linux and other Unix platforms. The DOS and CRT units are not portable to unix as they are. It would be nice if someone could port them to unix. If you can improve on the efficiency, and/or if you can implement some of the missing (or unreliable) routines, and/or if you can port these UNITs to other platforms, please feel free to do so!!! All I ask is this. Please, let this work be done in a coordinated fashion; a. If anyone is working on anything, please let me know *exactly* what you are doing or proposing to do, so that there will be no duplication of efforts; b. Please follow the conventions in the existing code, for comments, spacing, and so on; c. Please mark clearly any changes that you have made to my code, or to Peter's code; d. If you are working on the SYSTEM unit, please ensure that what you are doing it portable (e.g., by using only C functions that are portable across DOS, OS/2, Unix, etc.); e. When uploading your work, please upload everything in one package (.zip file), and put a version number on it. f. Please inform Peter and me when you are ready to upload a new version. 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! Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12@cc.keele.ac.uk) Author of: Chief's Installer Pro v3.50 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ From gpc-request@santra.hut.fi Sun May 18 15:29:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA05957 for ; Sun, 18 May 1997 15:29:03 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA20856; Sun, 18 May 1997 15:26:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA76904; Sun, 18 May 1997 15:25:52 +0200 Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA15124 for ; Sun, 18 May 1997 15:21:07 +0300 (EET DST) Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by vipunen.hut.fi (8.8.5/8.8.2) with ESMTP id OAA70628 for ; Sun, 18 May 1997 14:42:10 +0300 Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id NAA04695 for ; Sun, 18 May 1997 13:43:11 +0100 Date: Sun, 18 May 1997 13:43:09 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: alpha-970510: array problem. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO GPC alpha-970510 fails to compile this code: ----------------------------- program ArrayTest(output); type node = 0..4500; A = array[node] of integer; var N1 : A; N2 : ^A; begin writeln('OK'); end. ----------------------------- It barfs on the "var N2: ^A;" declaration. This used to work with previous releases of GPC. I can find no paragraph in the spec where it says that this declaration is valid, but I believe it is. Anyway, it BP likes it, and now `gpc -fborland-pascal' doesn't :-( BTW: This is the first bug detected by the automated compiler suite I'm writing, so I guess this proves the value of having such a thing. JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Sun May 18 18:21:16 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA06342 for ; Sun, 18 May 1997 18:21:16 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA132054; Sun, 18 May 1997 18:18:19 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA90736; Sun, 18 May 1997 18:18:03 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id TAA17566 for ; Sun, 18 May 1997 19:11:34 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id SAA06320 for gpc@hut.fi; Sun, 18 May 1997 18:14:29 +0200 From: Peter Gerwinski Message-Id: <199705181614.SAA06320@agnes.dida.physik.uni-essen.de> Subject: Re: alpha-970510: array problem. To: gpc@hut.fi Date: Sun, 18 May 1997 18:14:29 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > It barfs on the "var N2: ^A;" declaration. The reason is that GPC believes that the `^A' is Ctrl+A. I will fix that, thanks. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun May 18 19:34:40 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id TAA06472 for ; Sun, 18 May 1997 19:34:40 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA118598; Sun, 18 May 1997 19:31:42 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA31830; Sun, 18 May 1997 19:31:25 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id UAA18773 for ; Sun, 18 May 1997 20:26:44 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id TAA06458 for gpc@hut.fi; Sun, 18 May 1997 19:29:40 +0200 From: Peter Gerwinski Message-Id: <199705181729.TAA06458@agnes.dida.physik.uni-essen.de> Subject: Re: alpha-970510: array problem. To: gpc@hut.fi Date: Sun, 18 May 1997 19:29:39 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Jan-Jaap van der Heijden: > > It barfs on the "var N2: ^A;" declaration. The problem is solved. It was a trivial error. (-: If all bugs were like this ... :) To correct it, just add one line to `gpc-parse.y'. The diff is below. Thanks again, Jan-Jaap! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- --- gpc-parse.y Mon May 12 09:13:03 1997 +++ gpc-parse.y.new Sun May 18 17:36:34 1997 @@ -2533,6 +2533,7 @@ if (! flag_what_pascal || (flag_what_pascal & B_D_PASCAL)) lex_const_equal = 1; $$ = lex_caret; + lex_caret = 1; } ':' optional_qualifier_list type_denoter absolute_or_value_specification From gpc-request@santra.hut.fi Mon May 19 17:17:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA08261 for ; Mon, 19 May 1997 17:17:18 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA09178; Mon, 19 May 1997 17:14:05 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA23494; Mon, 19 May 1997 17:13:48 +0200 Received: from sv2.ictp.trieste.it (sv2.ictp.trieste.it [140.105.16.62]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA15792 for ; Mon, 19 May 1997 18:06:20 +0300 (EET DST) Received: from blueroom-5 (denisyuk@blueroom-5 [140.105.17.6]) by sv2.ictp.trieste.it (8.8.5/8.8.5) with SMTP id RAA11208; Mon, 19 May 1997 17:03:54 +0200 (MET DST) Date: Mon, 19 May 1997 17:03:45 +0200 (MET DST) From: DENISYUK VEDIM A X-Sender: denisyuk@blueroom-5 To: gpc@hut.fi Cc: peter@agnes.dida.physik.uni-essen.de Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi guys, Did somebody have experience to install g77 and gpc together (the newest versions?)? If it is you can you read the set of messages below with me and my system administrator to help us. Yous, Vadim ---------- Forwarded message ---------- Date: Mon, 19 May 1997 10:47:30 +0200 (MET DST) From: fB To: Vadim Aleksandrovich Denisyuk Subject: Re: Linking errors (fwd) Peter wrote: > 1. Get a recent version of GNU make. Version 3.74 or better is known > to work. > 2. Build GCC in a seperate directory instead of using the GCC source > directory. > 3. Manually delete these files from the GCC object directory: > `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' > `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. This was in the FAQ. Still I have: Undefined first referenced symbol in file reg_known_equiv_p ../gcc-2.7.2.2/sched.o read_dependence ../gcc-2.7.2.2/sched.o record_base_value ../gcc-2.7.2.2/loop.o output_dependence ../gcc-2.7.2.2/sched.o true_dependence ../gcc-2.7.2.2/cse.o anti_dependence ../gcc-2.7.2.2/sched.o flag_alias_check ../gcc-2.7.2.2/calls.o reg_known_value ../gcc-2.7.2.2/sched.o init_alias_analysis ../gcc-2.7.2.2/cse.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o ld: fatal: Symbol referencing errors. No output written to gpc1 *** Error code 1 make: Fatal error: Command failed for target `gpc1' Most of these are defined in ../gcc-2.7.2.2/alias.o, so linking with that one (which _might_ be dangerous) gives: Undefined first referenced symbol in file flag_alias_check ../gcc-2.7.2.2/calls.o flag_argument_noalias ../gcc-2.7.2.2/alias.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o these I can deal with. While I am pretty sure I can now produce an executable, you should carefully test it, as I did undocumented things to get it to work. fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) From: fB To: Vadim Denisyuk Subject: GPC compiled, but it does not work. Apparently, the new version of GPC does not interact well with the Solaris linker/loader. This might be due to the modifications I introduced in order to compile it with G77, though[1]. The error I get while compiling the hello.pas test is: ========================================================================= % gpc test/standard_pascal/hello.pas ld: fatal: file test/standard_pascal/hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: File processing errors. No output written to a.out ========================================================================= So it seems like gpc passes the wrong arguments to ld, something which did not happen with the previous version. Indeed g77 and gcc work perfectly with the Solaris-provided ld. On second thought... it seems like gpc passes everything unchanged to ld, without even attempting to compile anything. Indeed: ========================================================================= % ./gpc -c test/standard_pascal/hello.pas gpc: test/standard_pascal/hello.pas: linker input file unused since linking not done ========================================================================= So I probably messed up the command parser somewhere (see note). I'd install gpc in a completely separate directory with it's own straightforward version of gcc, but I already tried to do this with the previous version and, alas, g77 was (rather mysteriously) broken. I might real soon now experiment a little with doing this again in my copious free time. BTW, in the meanwhile I updated GCC/G77 to version 2.7.2.2.f.2 on all machines, and left 2.7.2.1 installed so that the old version of gpc still works. This _seems_ not to cause any problem right now. [1] This essentially reduces to linking gpc1 with ../gcc-2.7.2.2/alias.o and introducing the G77-specific options in toplev.c. I also had to explicitly #define some constants in a couple of places, though. As I could not be bothered to read and understand the source I obviously don't know what it's going on. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:43:56 +0200 (MET DST) From: fB To: Vadim Denisyuk Subject: Before you ask... I have done this (from the FAQ): A number of Unix configurations use their system's linker instead of GNU `ld'. Usually, GPC and GCC need a program called `collect2' before calling the system's `ld'. `collect2' is installed by GCC, and if you only install GPC, it will not find `collect2', and use the system linker directly, which will result in various linker errors. The solution is to copy `collect2' by hand from the GCC directory to the location where `gpc1' lives. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 16:32:57 +0200 (MET DST) From: fB To: Vadim Aleksandrovich Denisyuk Subject: Re: Before you ask... The new gpc compiles, but does not work. Seems like in order to make it to compile I screwed up the command parser. Sorry, but I exactly remade everything I made last time to compile V2.0 and it did not work anymore. Since I have one Pascal user and about thirty Fortran users, I'd rather break Pascal than Fortran. I will try again to check what the problem is, but I think that simply GPC is not yet able to peacefully coexist with G77. -- fB From gpc-request@santra.hut.fi Mon May 19 14:26:50 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA08115 for ; Mon, 19 May 1997 14:26:49 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19928; Mon, 19 May 1997 14:23:38 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38894; Mon, 19 May 1997 14:23:22 +0200 Received: from zoo-station.student.utwente.nl (janjaap@wit381304.student.utwente.nl [130.89.232.234]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA09079 for ; Mon, 19 May 1997 15:09:55 +0300 (EET DST) Received: from localhost (janjaap@localhost) by zoo-station.student.utwente.nl (8.8.5/8.8.5) with SMTP id OAA01100 for ; Mon, 19 May 1997 14:10:59 +0100 Date: Mon, 19 May 1997 14:10:58 +0100 (WET DST) From: Jan-Jaap van der Heijden Reply-To: Jan-Jaap van der Heijden To: GPC list Subject: New, experimental GPC version (pentium-gpc) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hello all, I have something for the daring folks among you: a GPC, based on the latest Cygnus CDK snapshot. For those of you who don't know, the Cygnus snapshots are GCC development releases, so you could consider this to be a pre-2.8 GCC. I used GPC-alpha 970510. I tested it on linux and SGI irix and had no problems with it (yet). Now, GPC alpha releases are usually quite reliable, but this is a major change in code, so you could consider this _REALLY ALPHA_ ;-) It can do some cool things like pentium(pro) optimizations. I would love to hear from somebody who does lots of floating point on a pentium(pro) whether it's really is faster. Binaries for pentiumpro-intel-linux (RedHat 4.1) and mips-sgi-irix6.2 are available. The mips binary is not targeting 64bits because of the immaturity of mips64 support in GCC. The linux binary installs in /opt/cdkgpc-i970518. You can move it around, just make sure you don't install it over your existing GCC. URL: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygnus-970507 Apart from numerous "easy fixes" and manual patching, these changes were necessary because of changes in GCC internals: gpc-decl.c: build_complex(): extra argument. setop.c: clear_storage(): New last argument. Probably clear blocksize. set to 1. Not most efficient, but works. gpc-cccp.c: quick hacks to add: int c89 UCHAR is_space Known bugs: (1) "automake" is completely broken. Still looking for a fancy solution that enables us to share the `gcc' driver with GCC. (2) Some files not modified but reused from 2.7.2.x: gpc-cccp.c, gpc-lex.c Todo: All cygwin32 related patches were removed from GPC and must be put back in. Must check for cygwin32-beta18 compatibility. *maybe* do a djgpp version. BTW: I don't plan to maintain a seperate Cygnus CDK GPC source tree. You could consider this a techdemo: the effort and results will pay off once GCC 2.8 is released, because porting GPC will be much easier then. Happy hacking! JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925. From gpc-request@santra.hut.fi Wed May 21 01:34:10 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA11265 for ; Wed, 21 May 1997 01:34:10 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19516; Wed, 21 May 1997 01:30:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38966; Wed, 21 May 1997 01:30:14 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA30192 for ; Wed, 21 May 1997 02:22:05 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA11239; Wed, 21 May 1997 01:25:40 +0200 From: Peter Gerwinski Message-Id: <199705202325.BAA11239@agnes.dida.physik.uni-essen.de> Subject: GPC and G77 (was without subject)-; To: denisyuk@ictp.trieste.it Date: Wed, 21 May 1997 01:25:39 +0200 (MET DST) Cc: gpc@hut.fi X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO DENISYUK VEDIM A wrote: > ---------- Forwarded message ---------- > Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) > From: fB > To: Vadim Denisyuk > Subject: GPC compiled, but it does not work. > [...] > ========================================================================= > % ./gpc -c test/standard_pascal/hello.pas > gpc: test/standard_pascal/hello.pas: linker input file unused since > linking not done > ========================================================================= > So I probably messed up the command parser somewhere (see note). You are using the wrong `gpc' driver program: It does not recognize Pascal source files and thinks they are for the linker. To fix this, make sure that the correct `gcc.o' is linked to produce the `gpc' driver program. It's the same problem as with `stor-layout.o' etc., and the solution is the same, too (see my previous mail). Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed May 21 16:06:35 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id QAA13325 for ; Wed, 21 May 1997 16:06:35 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA124776; Wed, 21 May 1997 16:02:45 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60894; Wed, 21 May 1997 16:02:29 +0200 Received: from ulam.fis.unico.it (ulam.fis.unico.it [131.175.56.103]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id QAA21905 for ; Wed, 21 May 1997 16:54:10 +0300 (EET DST) Received: from arnold.fis.unico.it (arnold [131.175.56.105]) by ulam.fis.unico.it (8.8.5/8.7.3) with SMTP id PAA24590; Wed, 21 May 1997 15:53:44 +0200 (MET DST) Received: from localhost by arnold.fis.unico.it (SMI-8.6/SMI-SVR4) id PAA21806; Wed, 21 May 1997 15:53:44 +0200 Date: Wed, 21 May 1997 15:53:43 +0200 (MET DST) From: Vadim Aleksandrovich Denisyuk To: gpc@hut.fi Cc: Peter Gerwinski Subject: GPC ok (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO GPC works. Thanks Go...Peter ---------- Forwarded message ---------- Date: Wed, 21 May 1997 15:41:16 +0200 (MET DST) From: Super-User To: Vadim Denisyuk Subject: GPC ok Ok, I finally succeeded in correctly compiling the new GPC. Amazingly, it works, thanks to the last suggestion. From gpc-request@santra.hut.fi Thu May 22 22:45:17 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA17117 for ; Thu, 22 May 1997 22:45:17 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA139620; Thu, 22 May 1997 22:41:06 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47164; Thu, 22 May 1997 22:40:51 +0200 Received: from hoover.gilbarco.com (hoover.gilbarco.com [199.221.73.2]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA00976 for ; Thu, 22 May 1997 23:21:58 +0300 (EET DST) Received: by hoover.gilbarco.com id AA27215 (InterLock SMTP Gateway 3.0 for gpc@hut.fi); Thu, 22 May 1997 16:21:55 -0400 Message-Id: <199705222021.AA27215@hoover.gilbarco.com> Received: by hoover.gilbarco.com (Internal Mail Agent-2); Thu, 22 May 1997 16:21:55 -0400 Received: by hoover.gilbarco.com (Internal Mail Agent-1); Thu, 22 May 1997 16:21:55 -0400 From: Phil Robertson To: gpc@hut.fi Subject: GPC Question (or bug) X-Mailer: ScoMail 3.0.Ca Mime-Version: 1.0 Date: Thu, 22 May 1997 16:20:54 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Status: RO I've ran into a problem compiling separate UNITS using "borland-pascal" style syntax. Essentially individual elements in an ENUM declared in an INTERFACE are not "recognized" by gpc-2.0: testunit1.pas: UNIT TestUnit1; INTERFACE TYPE Wood = (Oak, Pine, Beech, Teak); Fruit = (Apples, Peaches, Lemons); CONST Oranges = Teak; PROCEDURE CheckFruit ( FruitType : Fruit ); IMPLEMENTATION PROCEDURE CheckFruit ( FruitType : Fruit ); BEGIN CASE FruitType OF Apples : Writeln ('Apples'); Peaches : Writeln ('Peaches'); Lemons : Writeln ('Lemons'); END; END; END. compiles with no errors. testunit2.pas: UNIT TestUnit2; INTERFACE USES TestUnit1; PROCEDURE UseFruit; IMPLEMENTATION PROCEDURE UseFruit; BEGIN CheckFruit (Apples); CheckFruit (Peaches); CheckFruit (Lemons); CheckFruit (Oranges); END; END. yields: testunit2.pas: In function `Usefruit': testunit2.pas:13: undeclared identifier `Apples' (first use this function) testunit2.pas:13: (Each undeclared identifier is reported only once testunit2.pas:13: for each function it appears in.) testunit2.pas:14: undeclared identifier `Peaches' (first use this function) testunit2.pas:15: undeclared identifier `Lemons' (first use this function) It's interesting that "Oranges" is recognized since it is a const. I assume no "type cast" error is reported since full pascal type/range checking is not as yet implemented. Does anyone know of a fix or work-around for this? We're trying to port some code still in production and are stuck with a 10 year old compiler from Silicon Valley Software (now defunct). Thanks; Phil ------------------------------------------------------------------------- Philip A. Robertson Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 ------------------------------------------------------------------------- From gpc-request@santra.hut.fi Fri May 23 12:27:05 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA18780 for ; Fri, 23 May 1997 12:27:05 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA103104; Fri, 23 May 1997 12:22:46 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70644; Fri, 23 May 1997 12:22:30 +0200 Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id NAA16715 for ; Fri, 23 May 1997 13:16:28 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 23 May 1997 11:18:07 +0100 Received: from [0.41.132.192] by potter.cc.keele.ac.uk; Fri, 23 May 1997 11:16:14 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: bpcompat-1.0.zip Message-Id: Date: Fri, 23 May 1997 11:20:08 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Thu, 22 May 1997 20:12:09 -0400 (EDT) Pierre Phaneuf wrote: >I just checked out the new bpcompat sources... Did anyone actually *USED* >the OBJECTS.PAS unit??? Yes - see; TESTOBJ.PAS TESTCOLL.PAS TESTSTRM.PAS >More specifically, the TStream Put and Get methods? Yes - see; TESTSTRM.PAS > They are obviously broken... They worked okay in my tests. See the procedure "TestPut" in TESTSTRM.PAS. Can you post a copy of the code that is broken? BTW: it is stated clearly that TStream and some of the other objects are not complete - so, if anyone wants to implement the missing bits, please feel free to do so! >Ok, so those are difficult parts, but still... What I need is two things: >a way to tell what is the real type of an object like the typeof() >function (didn't check if it was there), and a way to construct an object >of an type as returned by typeof(). It isn't there - but you could write it :-). We would greatly welcome all contributions to the bpcompat package! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri May 23 02:18:12 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA17415 for ; Fri, 23 May 1997 02:18:12 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46504; Fri, 23 May 1997 02:13:58 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47206; Fri, 23 May 1997 02:13:43 +0200 Received: from server.gulliver.qc.ca (pp@55-085.hy.cgocable.ca [205.237.55.85]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA02823 for ; Fri, 23 May 1997 03:10:01 +0300 (EET DST) Received: from localhost (pp@localhost) by server.gulliver.qc.ca (8.8.5/8.8.5) with SMTP id UAA21493 for ; Thu, 22 May 1997 20:12:09 -0400 Date: Thu, 22 May 1997 20:12:09 -0400 (EDT) From: Pierre Phaneuf To: gpc@hut.fi Subject: bpcompat-1.0.zip Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I just checked out the new bpcompat sources... Did anyone actually *USED* the OBJECTS.PAS unit??? More specifically, the TStream Put and Get methods? They are obviously broken... Ok, so those are difficult parts, but still... What I need is two things: a way to tell what is the real type of an object like the typeof() function (didn't check if it was there), and a way to construct an object of an type as returned by typeof(). Something that would enable me to do something so that new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init and returns a pointer to the newly created object would be just *perfect*. Pierre Phaneuf From gpc-request@santra.hut.fi Fri May 23 01:44:55 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA17390 for ; Fri, 23 May 1997 01:44:55 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA116512; Fri, 23 May 1997 01:40:42 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA29408; Fri, 23 May 1997 01:40:26 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id CAA02411 for ; Fri, 23 May 1997 02:35:06 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id BAA17363; Fri, 23 May 1997 01:39:14 +0200 From: Peter Gerwinski Message-Id: <199705222339.BAA17363@agnes.dida.physik.uni-essen.de> Subject: Re: GPC Question (or bug) To: phil_robertson@gilbarco.com, gpc@hut.fi Date: Fri, 23 May 1997 01:39:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Phil Robertson: > > I've ran into a problem compiling separate UNITS using > "borland-pascal" style syntax. Essentially individual > elements in an ENUM declared in an INTERFACE are not > "recognized" by gpc-2.0: I could reproduce this bug - and fix it. The next alpha release of GPC - perhaps this weekend ... or maybe we should start to call it a "beta" release ... - will compile your programs correctly. > I assume no "type cast" error is reported since full > pascal type/range checking is not as yet implemented. Indeed. I fixed this, too. Thanks for reporting these bugs, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Fri May 23 18:18:04 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA19586 for ; Fri, 23 May 1997 18:18:03 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA55206; Fri, 23 May 1997 18:13:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA79336; Fri, 23 May 1997 18:13:24 +0200 Received: from 55-174.hy.cgocable.ca (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id TAA28173 for ; Fri, 23 May 1997 19:05:08 +0300 (EET DST) Received: from localhost (pp@localhost) by 55-174.hy.cgocable.ca (8.8.5/8.8.5) with SMTP id MAA23929; Fri, 23 May 1997 12:01:54 -0400 Date: Fri, 23 May 1997 12:01:53 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: Peter Gerwinski Cc: gpc@hut.fi Subject: Re: bpcompat-1.0.zip In-Reply-To: <199705231232.OAA19059@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 23 May 1997, Peter Gerwinski wrote: > >From the announcement of gpc-970510: > > * `TypeOf' applied to object variables works now, too. As a GPC extension, > you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax > is ON (*$X+*). > > This means that, with (*$X+*), you can explicitly assign a `TypeOf' to > an object. I implemented this extension just for the purpose to write the > `tStream.Get' method. (In BP, this is achieved with assembler, but we want > to have it portable for GPC.) I actually had it done without assembler in BP in a compatible manner (in my own version of the stream system), but still incompatible. > > Something that would enable me to do something so that > > new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init > > and returns a pointer to the newly created object would be just *perfect*. > > Please add it to `objects.pas'! My suggestion: > > 1) Write a `RegisterType' function, so you can read the `ObjType' out of > the stream and look up its `VmtLink'. > > 2) Replace the `New' in `tStream.Get' by a `GetMem' with the Size read off > the VMT (a Word variable at the very beginning of the VMT). Ah, I didn't knew the size was at the beginning of the VMT... But this isn't quite the Right Way (if the VMT format changes for whatever reason), no? > 3) Explicitly assign `VmtLink' to `TypeOf ( the new object )'. > > 4) Call the object's `Load' constructor. This could cause problems. How shall I call the Load constructor? function CreateObject(VMTLink: pointer; S: PStream): PObject; var P: PObject; Size: ^word; begin Size:=VMTLink; getmem(P, Size^); TypeOf(P):=VMTLink; P^.Load(S); end; This wouldn't work (in BP at least), since this will call TObject's Load constructor and it will reset the type of the object to TObject, whatever has been set with TypeOf(). On the other hand, if I call it using a pointer to the Load constructor (so that I get the right constructor), I don't even have to set the TypeOf() of the object, since it is set by the constructor itself (like in BP), but I have to do the method call by hand, just like the assembler part in the Borland OBJECTS.PAS or my no-assembler solution (which looked like the following and is just as dependent on compilers internals). type TLoadConstructor = function(S: PStream; VMTOffset: word; ASelf: pointer): pointer; (I'm not quite that sure about the parameter order, it is important) Then I called the constructor like this: P:=TLoadConstructor(LoadPtr^)(S, ofs(VMTLink), nil); The "nil" for self causes the constructor to allocate the right amount of memory for the object before calling the constructor. The pointer to the object instance is returned by the function. Note that this produces almost the same code (in BP) as a new() function call, but this is extremely dependent on the compilers internals! I guess that we cannot extend new() so that passing it a VMT pointer would make it instantiate the correct object type and call the right constructor, but how does it work when it gets PObject as a first parameter? Maybe some meta-function that returns the type itself? ;-) What do you think? "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Fri May 23 18:02:54 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id SAA19556 for ; Fri, 23 May 1997 18:02:54 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA154286; Fri, 23 May 1997 17:58:30 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA56504; Fri, 23 May 1997 17:58:15 +0200 Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA27683 for ; Fri, 23 May 1997 18:52:27 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Fri, 23 May 1997 16:53:36 +0100 Received: from [0.21.52.102] by potter.cc.keele.ac.uk; Fri, 23 May 1997 16:51:45 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: bpcompat-1.0.zip Message-Id: Date: Fri, 23 May 1997 16:55:13 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Fri, 23 May 1997 10:57:29 -0400 (EDT) Pierre Phaneuf wrote: >> They worked okay in my tests. See the procedure "TestPut" in >> TESTSTRM.PAS. Can you post a copy of the code that is broken? > >The problem is that TStream.Put simply write off the image of the object >without any type information. [...] Yes, that is correct. >> BTW: it is stated clearly that TStream and some of the other >> objects are not complete - so, if anyone wants to implement >> the missing bits, please feel free to do so! > >Of course! Peter says the features needed to implement the TStream object >correctly is now in GPC, so I'll get the latest version and work on this! That would be great. Here is an excerpt from my announcement, concerning improvements on the package; [------------------ cut -------------------] Please, let this work be done in a coordinated fashion; a. If anyone is working on anything, please let me know *exactly* what you are doing or proposing to do, so that there will be no duplication of efforts; b. Please follow the conventions in the existing code, for comments, spacing, and so on; c. Please mark clearly any changes that you have made to my code, or to Peter's code; d. If you are working on the SYSTEM unit, please ensure that what you are doing it portable (e.g., by using only C functions that are portable across DOS, OS/2, Unix, etc.); e. When uploading your work, please upload everything in one package (.zip file), and put a version number on it. f. Please inform Peter and me when you are ready to upload a new version. [------------------ end cut -------------------] >> It isn't there - but you could write it :-). We would greatly welcome >> all contributions to the bpcompat package! > >I send you the update! Shouldn't take more than a few days (download and >install the newest GPC and do the changes)... That would be excellent! What platform are you using (DJGPP, EMX, etc ...)? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Fri May 23 17:11:14 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id RAA19507 for ; Fri, 23 May 1997 17:11:14 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19974; Fri, 23 May 1997 17:06:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA75566; Fri, 23 May 1997 17:06:36 +0200 Received: from 55-174.hy.cgocable.ca (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id SAA26997 for ; Fri, 23 May 1997 18:00:38 +0300 (EET DST) Received: from localhost (pp@localhost) by 55-174.hy.cgocable.ca (8.8.5/8.8.5) with SMTP id KAA22243 for ; Fri, 23 May 1997 10:57:30 -0400 Date: Fri, 23 May 1997 10:57:29 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: bpcompat-1.0.zip In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 23 May 1997, The African Chief wrote: > > They are obviously broken... > > They worked okay in my tests. See the procedure "TestPut" in > TESTSTRM.PAS. Can you post a copy of the code that is broken? The problem is that TStream.Put simply write off the image of the object without any type information. So if you Put a TCollection, the object you'll read with Get won't be necessarily a TCollection. If GPC works like TP, it has the type of the object in the 2 or 4 first bytes of the object, but this is compile-dependent. If you add a class or add methods in another class, the type bytes on the streams won't match those in the executable and the file will be useless. > BTW: it is stated clearly that TStream and some of the other > objects are not complete - so, if anyone wants to implement > the missing bits, please feel free to do so! Of course! Peter says the features needed to implement the TStream object correctly is now in GPC, so I'll get the latest version and work on this! > It isn't there - but you could write it :-). We would greatly welcome > all contributions to the bpcompat package! I send you the update! Shouldn't take more than a few days (download and install the newest GPC and do the changes)... Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Fri May 23 14:42:49 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id OAA19159 for ; Fri, 23 May 1997 14:42:48 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA117518; Fri, 23 May 1997 14:38:27 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60400; Fri, 23 May 1997 14:38:12 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id PAA20736 for ; Fri, 23 May 1997 15:28:48 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id OAA19059; Fri, 23 May 1997 14:32:55 +0200 From: Peter Gerwinski Message-Id: <199705231232.OAA19059@agnes.dida.physik.uni-essen.de> Subject: Re: bpcompat-1.0.zip To: pp@gulliver.qc.ca, gpc@hut.fi Date: Fri, 23 May 1997 14:32:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Pierre Phaneuf: > > I just checked out the new bpcompat sources... Did anyone actually *USED* > the OBJECTS.PAS unit??? More specifically, the TStream Put and Get > methods? They are obviously broken... This is a very first release, and the `tStream' object is marked as "{ !!! not complete !!! }". Now you know what was meant with the statement "and some of the routines do not work well" in the announcement. > Ok, so those are difficult parts, but still... What I need is two things: > a way to tell what is the real type of an object like the typeof() > function (didn't check if it was there), It is there since gpc-970510 (see the announcement). > and a way to construct an object > of an type as returned by typeof(). >From the announcement of gpc-970510: * `TypeOf' applied to object variables works now, too. As a GPC extension, you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax is ON (*$X+*). This means that, with (*$X+*), you can explicitly assign a `TypeOf' to an object. I implemented this extension just for the purpose to write the `tStream.Get' method. (In BP, this is achieved with assembler, but we want to have it portable for GPC.) > Something that would enable me to do something so that > new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init > and returns a pointer to the newly created object would be just *perfect*. Please add it to `objects.pas'! My suggestion: 1) Write a `RegisterType' function, so you can read the `ObjType' out of the stream and look up its `VmtLink'. 2) Replace the `New' in `tStream.Get' by a `GetMem' with the Size read off the VMT (a Word variable at the very beginning of the VMT). 3) Explicitly assign `VmtLink' to `TypeOf ( the new object )'. 4) Call the object's `Load' constructor. Please join us in improving GPC! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Sun May 25 07:52:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA22753 for ; Sun, 25 May 1997 07:52:55 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA47804; Sun, 25 May 1997 07:48:02 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA60682; Sun, 25 May 1997 07:47:47 +0200 Received: from 55-174.hy.cgocable.ca (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id IAA09934 for ; Sun, 25 May 1997 08:41:04 +0300 (EET DST) Received: from localhost (pp@localhost) by 55-174.hy.cgocable.ca (8.8.5/8.8.5) with SMTP id BAA15432 for ; Sun, 25 May 1997 01:37:38 -0400 Date: Sun, 25 May 1997 01:37:37 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: bpcompat-1.0.zip In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 23 May 1997, The African Chief wrote: > a. If anyone is working on anything, please let me know *exactly* > what you are doing or proposing to do, so that there will be no > duplication of efforts; Ok, so I'll be modifying the Put and Get methods of TStream, and adding a class registry. (probably will be very simple) > >I send you the update! Shouldn't take more than a few days (download and > >install the newest GPC and do the changes)... > > That would be excellent! What platform are you using (DJGPP, EMX, etc ...)? Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27... Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Sun May 25 04:14:03 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id EAA21921 for ; Sun, 25 May 1997 04:14:03 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA77542; Sun, 25 May 1997 04:09:10 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA59480; Sun, 25 May 1997 04:08:55 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id FAA11970 for ; Sun, 25 May 1997 05:03:55 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id EAA22198 (8.7.6/7.5c-FAU); for ; Sun, 25 May 1997 04:03:53 +0200 (MET DST) Received: from laertes by mi.uni-erlangen.de with SMTP; id EAA03365 (SMI-8.6/7.5b-FAU); Sun, 25 May 1997 04:03:52 +0200 From: Frank Heckenbach Message-Id: <199705250203.EAA03365@helena.mi.uni-erlangen.de> Date: Sun, 25 May 1997 04:03:51 +0200 To: gpc@hut.fi Subject: OOP (Was: bpcompat-1.0.zip) Status: RO Pierre Phaneuf wrote: > Ah, I didn't knew the size was at the beginning of the VMT... But this > isn't quite the Right Way (if the VMT format changes for whatever reason), > no? Though the VMT format might not be likely to change, perhaps it would be better to have a built-in function of the compiler to return the object size of a given VMT link (should be easy to implement). > > 4) Call the object's `Load' constructor. > > This could cause problems. How shall I call the Load constructor? > > function CreateObject(VMTLink: pointer; S: PStream): PObject; > var > P: PObject; > Size: ^word; > begin > Size:=VMTLink; > getmem(P, Size^); > TypeOf(P):=VMTLink; > P^.Load(S); > end; > > This wouldn't work (in BP at least), since this will call TObject's Load > constructor and it will reset the type of the object to TObject, whatever > has been set with TypeOf(). Couldn't "Load" be a virtual method instead of a constructor (perhaps a Boolean function that returns if it didn't fail)? I'm not sure if a constructor does anything special besides setting the VMT link which has been done here anyway, so if it does more, this suggestion might not be possible. But if it's possible, you also wouldn't have to register the Load constructor (neither Store, of course), so the registration could also be simplified to something like RegisterType(ObjType, VMTLink:Word); and the programs that use this function don't have to declare a "StreamRec" manually, which would be another simplification. And it would be even better if the compiler could do this automatically, i.e. each object type could (optionally) declare an "ObjType" value, and the compiler would provide functions to get the ObjType from a VMT link and vice versa. Thinking about how to implement this, I realize this is basically the same as object constants -- something that's missing in BP and I could've used sometimes. This could be a useful extension to BP's objects. (The constants and their values would be inherited if not redeclared, just like virtual methods.) "ObjType" could then be a normal object constant with only 2 differences: the compiler should make sure that no two types within a program have the same ObjType (especially, that no type accidentally inherits its parent's value!), and there must be a special function to get the VMT link from an ObjType. And while I'm at it, class variables would also be nice, i.e. variables that exist only once for all instances of an object type (aka class). Again, I had some situations where I liked to have them. (For variables, there is a difference between object and class variables, for constants this difference doesn't matter.) Just some ideas... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Sun May 25 22:11:43 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id WAA23621 for ; Sun, 25 May 1997 22:11:43 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA22774; Sun, 25 May 1997 22:06:37 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA51040; Sun, 25 May 1997 22:06:23 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id XAA20599 for ; Sun, 25 May 1997 23:01:20 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id WAA23566 for gpc@hut.fi; Sun, 25 May 1997 22:06:23 +0200 From: Peter Gerwinski Message-Id: <199705252006.WAA23566@agnes.dida.physik.uni-essen.de> Subject: Re: OOP (Was: bpcompat-1.0.zip) To: gpc@hut.fi Date: Sun, 25 May 1997 22:06:23 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Frank Heckenbach: > > Though the VMT format might not be likely to change, perhaps it would be > better to have a built-in function of the compiler to return the object > size of a given VMT link (should be easy to implement). It's easy to implement as a function: Let `pObject' be a pointer to the parent object `tObject'of all `Stream'able objects, then (*$X+*) (* For hackers, only *) Function ObjectSizeInBytes ( VmtLink: Pointer ): Word; Var O: tObject; begin TypeOf ( O ):= VmtLink; (* Initialize it manually *) ObjectSizeInBytes:= SizeOf ( O ); end. According to Pierre Phaneuf: > > This wouldn't work (in BP at least), since this will call TObject's Load > constructor and it will reset the type of the object to TObject, whatever > has been set with TypeOf(). In GNU Pascal, initialization takes place outside the constructor as some additional inline code. (I am not 100% sure that this will not change.) But you are right - this does not work in the current GPC either. But I can modify GPC such that constructors only initialize an object if it has not been initialized previously. Then it will work, since assignment to `TypeOf ( something )' *is* (manual) initialization. According to Frank Heckenbach: > > Couldn't "Load" be a virtual method instead of a constructor (perhaps a > Boolean function that returns if it didn't fail)? Yes. IMHO, it could be in BP as well. > But if it's possible, you also wouldn't have to register the Load constructor > (neither Store, of course), so the registration could also be simplified to > something like > RegisterType(ObjType, VMTLink:Word); > and the programs that use this function don't have to declare a "StreamRec" > manually, which would be another simplification. Exactly. For compatibility's sake, somebody should implement the "StreamRec" stuff, too, but it can be done in an easier way. > And it would be even better if the compiler could do this automatically, > i.e. each object type could (optionally) declare an "ObjType" value, and > the compiler would provide functions to get the ObjType from a VMT link > and vice versa. Sounds nice, but how to find a unique number for each object? Derive it from the name? Then what about storing the name of the object itself in the Stream? > Thinking about how to implement this, I realize this is basically the same > as object constants -- something that's missing in BP and I could've used > sometimes. This could be a useful extension to BP's objects. (The constants > and their values would be inherited if not redeclared, just like virtual > methods.) And they would be stored in the VMT. Sounds reasonable. And the compiler could (optionally?) provide an automatic "name" object constant and/or a unique number ... > [...] > > Just some ideas... Sounds good, but I think the "stabilization" of gpc-2.1 has higher priority. But this might be of interest for gpc-2.2 ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Mon May 26 07:16:19 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id HAA25083 for ; Mon, 26 May 1997 07:16:19 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA153184; Mon, 26 May 1997 07:11:07 +0200 Received: from deneb.dfn.de by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA68038; Mon, 26 May 1997 07:10:53 +0200 Received: from santra.hut.fi by deneb.dfn.de (4.1/SMI-4.2) id AA01066; Mon, 26 May 97 04:18:03 +0200 Received: from dilu.ml.org (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id FAA20947 for ; Mon, 26 May 1997 05:09:50 +0300 (EET DST) Received: from localhost (pp@localhost) by dilu.ml.org (8.8.5/8.8.5) with SMTP id WAA14232 for ; Sun, 25 May 1997 22:06:41 -0400 Date: Sun, 25 May 1997 22:06:41 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: OOP (Was: bpcompat-1.0.zip) In-Reply-To: <199705252006.WAA23566@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 25 May 1997, Peter Gerwinski wrote: > > This wouldn't work (in BP at least), since this will call TObject's Load > > constructor and it will reset the type of the object to TObject, whatever > > has been set with TypeOf(). > > In GNU Pascal, initialization takes place outside the constructor as some > additional inline code. (I am not 100% sure that this will not change.) That's the problem (that you're not sure it will not change). BTW, the constructor *is* the logical place do to such a thing... > But you are right - this does not work in the current GPC either. > But I can modify GPC such that constructors only initialize an object > if it has not been initialized previously. Then it will work, since > assignment to `TypeOf ( something )' *is* (manual) initialization. But how do you check if an object is initialized or not? I don't think this is the best way either, unless you can devise a *sure* way to check out if the object is initialized. > > Couldn't "Load" be a virtual method instead of a constructor (perhaps a > > Boolean function that returns if it didn't fail)? > > Yes. IMHO, it could be in BP as well. It could be in GPC, but is this a BP compatibility unit or not? ;-) In BP it cannot. It *must* be a constructor, because this is relied upon by TStream.Get to initialize the object VMT link correctly and allocate the correct amount of memory. > Exactly. For compatibility's sake, somebody should implement the > "StreamRec" stuff, too, but it can be done in an easier way. I am doing a BP compatible StreamRec facility for the BPCOMPAT package. > > And it would be even better if the compiler could do this automatically, > > i.e. each object type could (optionally) declare an "ObjType" value, and > > the compiler would provide functions to get the ObjType from a VMT link > > and vice versa. > > Sounds nice, but how to find a unique number for each object? Derive it > from the name? Then what about storing the name of the object itself > in the Stream? Are we looking for BP compatibility or not? BTW, I *am* also developing a class library made just for GPC using all the new features and fixing many of the problems with the BP OBJECTS.PAS and the TurboVision libraries. It would be nice to have RTL functions to get an object name and parent, a bit like Delphi can give you the class name of an object. A separate function would be better (probably something accepting a VMT pointer (as returned by TypeOf() ) as a parameter), since it wouldn't "use up" a method name. Would be important to put the names of the classes apart from the symbol table, since the program has to work even if it is stripped! And also not put all the symbols in every programs, just those that use the "ClassName()" function, optimizing those using constants as their parameter and so on... > And they would be stored in the VMT. Sounds reasonable. And the compiler > could (optionally?) provide an automatic "name" object constant and/or a > unique number ... A unique number is a bad idea and shouldn't be used. They can change and invalidate a file containing streamed objects from compile to compile. The name isn't also a good idea for a stream (for example, you can lose the TStrMaker/TStrList functionality). But the name could be useful for other things... The way I see it, the best way is to make a legal way to directly call a specific class constructor. Like the "typed new()" function (passing an object type as the first parameter) does, but being able to put a variable there. Maybe a GPC-specific new() function? With another name of course to avoid incompatibilities... Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Tue May 27 12:13:45 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id MAA29107 for ; Tue, 27 May 1997 12:13:45 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA112796; Tue, 27 May 1997 12:08:11 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA49926; Tue, 27 May 1997 12:07:56 +0200 Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id MAA00311 for ; Tue, 27 May 1997 12:52:17 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Tue, 27 May 1997 10:22:29 +0100 Received: from [0.35.109.146] by potter.cc.keele.ac.uk; Tue, 27 May 1997 10:20:36 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: OOP Message-Id: Date: Tue, 27 May 1997 10:24:16 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Mon, 26 May 1997 20:09:51 -0400 (EDT) Pierre Phaneuf wrote: >On Mon, 26 May 1997, Frank Heckenbach wrote: > >> Bottom line: I don't think it can be done all automatically, but it can be >> done much more comfortably to the programmer than in TV. > >I agree with you. I am in effect creating a better way to do it, but it >will NOT be in BPCOMPAT. I'm a proficient user of TV, and I'll try to have >the object parts of the BPCOMPAT package as compatible with it as >possible... It *will* be in a GPC-specific class library of mine I'll >contribute to the GPC team "When It's Ready (TM)", of course! ;-) It would be nice if your classlib could build on the object heirarchy in BPCOMPAT, instead of introducing a completely new one (at least, if all your main "PierreObject" is a descendant of TObject). This would ensure some continuity. You could amend TObject if necessary, so that it would meet your needs as the ultimate ancestor of your own objects. All that is necessary is to ensure that programs written to use TObject as it currently is (which would be very few indeed) are not broken, which will be a trivial thing to do. Also, when implementing your new TV stuff, it would be nice to make it more friendly. I find Borland's TV quite incomprehensible - it is as if it wasn't made by the same company that made OWL (which I find to be easier to deal with). But perhaps it is because I lost patience with TV very quickly. [...] >> > We are in part. The primary goal of GPC is to produce the best Pascal >> > compiler the world has ever seen. >> >> I agree with Peter. I, FWIW, didn't use TV -- partly because some parts >> of it (including class registration) were, IMHO, badly implemented. >> If gpc's TV would be the same, I probably wouldn't use it, either. > >Yes, I agree, but let's keep in mind what we're looking to fix in this >thread is the BPCOMPAT package, which will have to look like BP libraries >are, at least on the outside. I think that this is crux of the matter. We are trying to produce a package that will allow GPC to compile BP programs (i.e., the external interface is similar to that of BP). We are not concerned to ensure that the internal implementation is identical to that of BP (unwanted side effects aside). We are also not concerned to ensure that the code will compile under BP itself. Much of the current BPCOMPAT will not compile under BP, because of the use of functions from the C library, and the use of EP initialization and finalization stuff. So, please let us not hamstring ourselves by trying only to write code that will also compile under BP. Eventually, BP will go the way of the dodo - GPC is the way forward! > BTW, what didn't you like exactly with TV? Personally, it seemed too tedious to write any useful code. Felt like it was a classlib written by a sadist or a masochist, or both ;-). However, some people feel that way about OWL too - and I personally prefer OWL to TV or even to Delphi's VCL. >As for the class registration, what I didn't like was that it used the >data segment, which isn't a very clean hack IMHO... Apart from that, it's >ok by me (the class registration system!). The Free method is one of the >purest evils in there. :-) (and it is in the BPCOMPAT package!) Well, Free() was included just because Borland included it (i.e., "external" compatibility). >> So we may need both: a "100% BP compatible" unit for quick changes, and >> a "better" gpc unit to which programs can be converted afterwards, and >> which new programs can use from the beginning. Actually, I think, the >> changes needed for BP programs shouldn't be too big: make the "Load" >> constructor virtual (if we do it this way), declare the "ObjID" constant, >> and remove the registration stuff. Could even be simplified with some >> "IFDEF"s and clever use of the preprocessor, I guess. > >I'm developing something here for a "GPC enhanced" class library, I'll >keep you posted! That would be great. Which objects are you thinking of including? Are you tailoring it after [a] TV (eek!!); [b] OWL (:-)); [b] VCL ( !!); [d] OPRO (;-/); [e] something else ? >"The use of COBOL cripples the mind; its teaching should, therefore, be >regarded as a criminal offense." - Edsger W. Dijkstra. Except it can save the world from the Year 2000 fiasco! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue May 27 10:43:26 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA28907 for ; Tue, 27 May 1997 10:43:26 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA19986; Tue, 27 May 1997 10:37:53 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA38288; Tue, 27 May 1997 10:37:31 +0200 Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id LAA30672 for ; Tue, 27 May 1997 11:29:00 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Mon, 26 May 1997 14:27:55 +0100 Received: from [0.22.190.188] by potter.cc.keele.ac.uk; Mon, 26 May 1997 14:26:02 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: OOP Message-Id: Date: Mon, 26 May 1997 14:29:38 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO Hi all, I have been following the discussion on Objects with interest. I would just like to note a number of things; The TObject type as I implemented it in OBJECTS.PAS has a number of fields; "Parent" and "Child" (each declared as a "pObject") "Handle" and "SelfID" (each declared as an Integer) "Name" (declared as a String[64]) "SelfPtr" (private field declared as a "pObject") At the moment, "Parent" and "Child" do nothing, and "Handle" is for projected future use (for handles to windowed objects - Win32, etc). "SelfID" is an integer which holds a unique numeric ID for each living TObject descendant. Can we make TObject automatically become the ancestor of each Object type (i.e., any object which is just defined as "Object")?; if so, is this desirable?; if so, can this solve any of the current problems with Streams and stuff? I would have thought that some of the fields declared in TObject could be put to better use than I have done so far - and that more fields could be added to TObject, to cater for other things (i.e., if TObject will become the ultimate ancestor of all Object types). Any views? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue May 27 10:43:02 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id KAA28903 for ; Tue, 27 May 1997 10:43:02 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA78836; Tue, 27 May 1997 10:37:28 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA57676; Tue, 27 May 1997 10:37:12 +0200 Received: from gabriel.cc.keele.ac.uk (gabriel.cc.keele.ac.uk [160.5.20.2]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id LAA30019 for ; Tue, 27 May 1997 11:28:57 +0300 (EET DST) Received: from potter.cc.keele.ac.uk by gabriel with SMTP (PP); Mon, 26 May 1997 14:08:25 +0100 Received: from [0.4.213.88] by potter.cc.keele.ac.uk; Mon, 26 May 1997 14:06:28 +0100 From: The African Chief To: gpc@hut.fi Subject: Re: bpcompat-1.0.zip Message-Id: Date: Mon, 26 May 1997 14:10:04 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Windows X-Authentication: none Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO On Sun, 25 May 1997 01:37:37 -0400 (EDT) Pierre Phaneuf wrote: >On Fri, 23 May 1997, The African Chief wrote: > >> a. If anyone is working on anything, please let me know *exactly* >> what you are doing or proposing to do, so that there will be no >> duplication of efforts; > >Ok, so I'll be modifying the Put and Get methods of TStream, and adding a >class registry. (probably will be very simple) Ok - thanks. I will note that. >> >I send you the update! Shouldn't take more than a few days (download and >> >install the newest GPC and do the changes)... >> >> That would be excellent! What platform are you using (DJGPP, EMX, etc ...)? > >Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27... Can you please tell me which (if any) of the UNITS currently compiles (without any change to the sources) under Linux? It is good to note these things in future releases. Thanks. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk From gpc-request@santra.hut.fi Tue May 27 02:31:39 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id CAA27650 for ; Tue, 27 May 1997 02:31:38 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA139640; Tue, 27 May 1997 02:26:09 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45808; Tue, 27 May 1997 02:25:54 +0200 Received: from dilu.ml.org (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id DAA21037 for ; Tue, 27 May 1997 03:12:58 +0300 (EET DST) Received: from localhost (pp@localhost) by dilu.ml.org (8.8.5/8.8.5) with SMTP id UAA15304 for ; Mon, 26 May 1997 20:09:51 -0400 Date: Mon, 26 May 1997 20:09:51 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: OOP In-Reply-To: <199705261248.OAA08126@helena.mi.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 26 May 1997, Frank Heckenbach wrote: > Bottom line: I don't think it can be done all automatically, but it can be > done much more comfortably to the programmer than in TV. I agree with you. I am in effect creating a better way to do it, but it will NOT be in BPCOMPAT. I'm a proficient user of TV, and I'll try to have the object parts of the BPCOMPAT package as compatible with it as possible... It *will* be in a GPC-specific class library of mine I'll contribute to the GPC team "When It's Ready (TM)", of course! ;-) > type MyObject(TObject) > Const ObjID:Word = MyBaseID+42; > ... > End; > > or ... why not also > > Const ObjID:Word = Inherited ObjID+1; > > (Though the simple "+1" might not be good, as it can easily lead to > conflicts - but perhaps something similar.) > > Concerning the numbering convention, I'd also suggest something "better" than > TV's way, perhaps an ID consisting of 4 parts (perhaps 16 bits for each part, > this would leave room for a growing number of programs for some time (well - > at least as long as 640 KB are enough for everybody... ;-), and the whole > thing would be 64 bits (longlongint?)): > > 1. "unique" programmer ID > 2. ID for a "category" of types (graphical objects, mathematical objects, > dialog elements, ...) - unique only for the programmer > 3. ID for a certain type within a category > 4. "version number" for the type (i.e., if the fields or their semantics > change, the version number will be changed, too, so that old objects in > streams can be recognized) All this is not really needed in a system similar to TV, since you can register the objects yourself in case of conflict, resolving them to your liking. Though it is a nice idea to have a programmer/vendor part... A call to a unit-specific RegisterType procedure could look like this: RegisterObjects(1), the 1 being a value selected by the application programmer to prevent conflicts with another unit. How about a dword, with the first 16 bits for the unit ID and the last 16 bits for the object ID itself within the unit. Gives you 64K units in a single program with 64K objects per unit... Should be quite enough! :-) The version number isn't a good idea though... The idea with the object ID is to spawn the correct object to load the object from the stream. The correct way to put versioning in your streamable classes is to have a version number stored at the beginning of your object by your Store method, and have your Load method have a 'case' statement that loads the object correctly according to the various versions. > As I said above, I wouldn't like this. But it could be an idea to have > ObjID be a string instead of a numerical value. But I'm not sure if it's > worth the additional work required... Not really IMHO... I agree with you on this subject... > Perhaps it's easier to let "ClassName" be a normal object constant (if > they'll be implemented). Then the programmer could decide which names to > include in the program and how to call them (e.g. the actual identifier > might be "TSomething", but for the ClassName it might be preferable to > have just "Something"). The idea with having a separate ClassName() function is to let you have a ClassName method, variable or constant without losing the functionality. > > The way I see it, the best way is to make a legal way to directly call a > > specific class constructor. Like the "typed new()" function (passing an > > object type as the first parameter) does, but being able to put a variable > > there. Maybe a GPC-specific new() function? With another name of course to > > avoid incompatibilities... > > This would require something like "virtual constructors", wouldn't it? > I.e., the constructors would have to have the same parameters in all > classes, and their addresses would be stored in the VMT. Doesn't seem > impossible, perhaps it's the most logical thing to do. No... You know that New() works either this way: New(P, Init), where P is a typed pointer (of an object type that has a Init constructor, of course!), where P will be changed to point to the new instance or set as nil if the object didn't construct correctly. The other way is as a function that work like this: P:=New(PObject, Init), which will construct a TObject and return the instance pointer (or nil). It isn't a virtual constructor, you simply choose which object to construct. > > We are in part. The primary goal of GPC is to produce the best Pascal > > compiler the world has ever seen. > > I agree with Peter. I, FWIW, didn't use TV -- partly because some parts > of it (including class registration) were, IMHO, badly implemented. > If gpc's TV would be the same, I probably wouldn't use it, either. Yes, I agree, but let's keep in mind what we're looking to fix in this thread is the BPCOMPAT package, which will have to look like BP libraries are, at least on the outside. BTW, what didn't you like exactly with TV? As for the class registration, what I didn't like was that it used the data segment, which isn't a very clean hack IMHO... Apart from that, it's ok by me (the class registration system!). The Free method is one of the purest evils in there. :-) (and it is in the BPCOMPAT package!) > So we may need both: a "100% BP compatible" unit for quick changes, and > a "better" gpc unit to which programs can be converted afterwards, and > which new programs can use from the beginning. Actually, I think, the > changes needed for BP programs shouldn't be too big: make the "Load" > constructor virtual (if we do it this way), declare the "ObjID" constant, > and remove the registration stuff. Could even be simplified with some > "IFDEF"s and clever use of the preprocessor, I guess. I'm developing something here for a "GPC enhanced" class library, I'll keep you posted! Up to now, no compiler changes or new features are needed, except for a clean way to spawn an object from its VMT link. I started developing it with BP so I knew exactly how to do it (it is portable, if you don't count the heck of limitations induced by BP (collections are limited to about 16K elements with BP, where they are "big enough" with GPC) ). I "faked" the 'typed New()' code using Turbo Debugger to learn how it worked... > A "Parent" field in the VMT seems quite useful to me. Also, a list of the > childs (this would require a "FirstChild", and a "Sibling" field in each > VMT). And perhaps they could be accessed through the VmtRec as well as > as normal object constants... At least Parent would be useful. Note that my class library registration system has a field for the parent object and can walk the registration list to find its childs. Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Tue May 27 00:53:18 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id AAA27553 for ; Tue, 27 May 1997 00:53:18 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA118222; Tue, 27 May 1997 00:47:51 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA46632; Tue, 27 May 1997 00:47:36 +0200 Received: from dilu.ml.org (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA20812 for ; Tue, 27 May 1997 01:42:30 +0300 (EET DST) Received: from localhost (pp@localhost) by dilu.ml.org (8.8.5/8.8.5) with SMTP id SAA13022 for ; Mon, 26 May 1997 18:39:22 -0400 Date: Mon, 26 May 1997 18:39:22 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: OOP (Was: bpcompat-1.0.zip) In-Reply-To: <199705261107.NAA25864@agnes.dida.physik.uni-essen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 26 May 1997, Peter Gerwinski wrote: > I agree, but not every constructor call does actually initialize an > object. Since it is difficult to be sure whether an object already is > initialized or not, we have to decide about this when the constructor > is *called*. For this reason, it happened to be easier to do the > initialization outside the constructor's body. Yes, you're right, the constructor calls that comes from calling the inherited constructor must not initialize the object... In BP, the two hidden parameters to constructors are the instance pointer (the Self parameter) and the VMT offset of the object that is being constructed. If the VMT offset given is the same as the called constructor, then it is the first constructor called and the object is initialized. If the VMT parameter isn't the same as the called constructor, it is because it is being called from within another constructor and hence the object is already initialized. This is actually easy! ;-) > Look whether the VMT field contains a nonzero value. To be absolutely > sure, we can even check whether the pointer really points to a VMT: The > first Word pointed to must be a positive Integer (the size of the object), > the second one its negative (which is included for purposes like this > one). Problem: This will only work if the object was pre-initialized > to have a zero VMT field. This can be achieved with `New', but not with > `GetMem', so you have still to be careful when implementing streams. Here. A check in the constructor would not be reliable, since the memory could have been allocated with GetMem (and we have *no* mean to check this out) and the VMT field is filled with random bytes in that case, which could very well be an actual valid VMT pointer (with *some* luck, if the area of memory has already been allocated to another object, the chances are high that there is a valid VMT pointer there!). > > In BP it cannot. It *must* be a constructor, because this is relied upon > > by TStream.Get to initialize the object VMT link correctly and allocate > > the correct amount of memory. > > It could be in BP too, if we changed the `tStream' object. Just do > everything, the constructor would normally do, by hand. We cannot change BP! I mean, the idea of the BPCOMPAT package is to be compatible with BP, not make BP GPC compatible! :-) > > I am doing a BP compatible StreamRec facility for the BPCOMPAT package. > > Great! }:-=)= (* This shall be a smiling Gnu. :*) This one is going to be a cheap clone 100% compatible (well, compatible interface). But there will be a "good" one made just for GPC soon... > > Are we looking for BP compatibility or not? > > We are in part. The primary goal of GPC is to produce the best Pascal > compiler the world has ever seen. (See the Info documentation for > details.) BP compatibility is desireable because (ii) BP is not too > bad and (i) many BP programmers will try GPC only if they can use their > existing programs without any change. I meant in the BPCOMPAT... ;-) > > BTW, I *am* also developing a > > class library made just for GPC using all the new features and fixing many > > of the problems with the BP OBJECTS.PAS and the TurboVision libraries. > > :-) Hence, I am not putting a lot of effort to enhance BPCOMPAT units, only fixing them so they work correctly. > > It would be nice to have RTL functions to get an object name and parent, > > a bit like Delphi can give you the class name of an object. > > How does Delphi do this? (Sorry for the stupid question, but my > experience with Delphi is very limited, primarily because I cannot stand > the mouse-only "user interface".) Delphi does this by having methods in *every* objects that are provided by the compiler that returns the name of the objects and their parent. > What about making the structure of the VMT record visible for the program? > For instance a built-in > > Type > VmtRec = record > Size, NegSize: Integer; > VirtualMethod: array [ 0..1 ] of Pointer; > end (* VmtRec *); > > Where the `1' above stands for the unknown number of methods in a VMT. > > (* I thought about changing the VMT to a schema type > > Type > VmtRec ( n: Integer ) = record > Size, NegSize: Integer; > VirtualMethod: array [ 1..n ] of Pointer; > end (* VmtRec *); > > which would place `n' as an additional field at the very beginning of > each VMT. But it's probably better to let `Size' stay the first field and > to save the additional storage for the number of methods in the object. *) This doesn't give much information about the object apart from its size and the number of methods and where they are... What we'd need is something like from which class is another class derived from, its name, and so on... > > And also not put all the symbols in every programs, just those that use > > the "ClassName()" function, > > Difficult. Hmm... Is it possible to have a function automatically generated by the compiler before going to the optimizing stage? It would contain a table translating VMT pointers into strings of the classes name and would be optimized out of the program by the optimizer if unused, right? > > A unique number is a bad idea and shouldn't be used. They can change and > > invalidate a file containing streamed objects from compile to compile. > > That's what I meant with the "how to choose" problem. When deriving it > from the name in an unambiguous way, it would work. But how would that > "unambiguous way" look like? A CRTC check sum? (I don't really know > what that is ...;) CRC (Cyclic Redundancy Check) you must mean. It is an error detection scheme too often used as a hash key generator (which it isn't, it collides a bit too often). > > The way I see it, the best way is to make a legal way to directly call a > > specific class constructor. Like the "typed new()" function (passing an > > object type as the first parameter) does, but being able to put a variable > > there. Maybe a GPC-specific new() function? > > `New' already is as GPC-specific as it could be ... > > > With another name of course to > > avoid incompatibilities... > > I will think about that and let you know if I have an idea. What I mean is (for example) a NewObject() function that would work just like New(), but instead of a typed pointer or an object type itself, it would take a VMT pointer as the first parameter. It would make the construction of an object from a stream as simple as calling "Get:=NewObject(TStreamRec.VMTLink, Load(@Self));" at the end of the TStream.Get method. BTW, how does New() work when it is passed an object type (say, PObject) as the first parameter? Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. From gpc-request@santra.hut.fi Mon May 26 15:19:58 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id PAA26597 for ; Mon, 26 May 1997 15:19:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA08970; Mon, 26 May 1997 15:14:39 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA12792; Mon, 26 May 1997 15:14:24 +0200 Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id PAA08399 for ; Mon, 26 May 1997 15:48:30 +0300 (EET DST) Received: from helena.mi.uni-erlangen.de (helena.mi.uni-erlangen.de [131.188.103.20]) by uni-erlangen.de with SMTP id OAA04054 (8.7.6/7.5c-FAU); for ; Mon, 26 May 1997 14:48:24 +0200 (MET DST) Received: from nausikaa by mi.uni-erlangen.de with SMTP; id OAA08126 (SMI-8.6/7.5b-FAU); Mon, 26 May 1997 14:48:22 +0200 From: Frank Heckenbach Message-Id: <199705261248.OAA08126@helena.mi.uni-erlangen.de> Date: Mon, 26 May 1997 14:48:21 +0200 To: gpc@hut.fi Subject: Re: OOP Status: RO Peter Gerwinski wrote: > > Couldn't "Load" be a virtual method instead of a constructor (perhaps a > > Boolean function that returns if it didn't fail)? > > Yes. IMHO, it could be in BP as well. I never used TV, but I'd think so, too. > > And it would be even better if the compiler could do this automatically, > > i.e. each object type could (optionally) declare an "ObjType" value, and > > the compiler would provide functions to get the ObjType from a VMT link > > and vice versa. > > Sounds nice, but how to find a unique number for each object? Derive it > from the name? I don't think it's possible (or sensible) that the compiler derives it automatically. I thought about this problem several times, but didn't find a "good" solution. The name? It can change (if you change your naming conventions, or just don't like the name you chose), and it's against the "rule" that the identifiers should not influence the compiled code (I'm not sure if this is actually a rule in the Pascal syntax, but anyway I personally like it this way). Also, there are other questions involved. If the code of the object type changes, should it get a new ID or not? I think, only the programmer can decide this. If all the object's fields and their semantics stay the same, the ObjID can usually stay the same. Also, of course, if the object is in the developing/debugging process. But if the "interface" of an object in a published program changes, the ID should change as well, to avoid compatibility problems with older stream files. Bottom line: I don't think it can be done all automatically, but it can be done much more comfortably to the programmer than in TV. What I meant was that the programmer declares the ID, like type MyObject(TObject) Const ObjID:Word = MyBaseID+42; ... End; or ... why not also Const ObjID:Word = Inherited ObjID+1; (Though the simple "+1" might not be good, as it can easily lead to conflicts - but perhaps something similar.) Concerning the numbering convention, I'd also suggest something "better" than TV's way, perhaps an ID consisting of 4 parts (perhaps 16 bits for each part, this would leave room for a growing number of programs for some time (well - at least as long as 640 KB are enough for everybody... ;-), and the whole thing would be 64 bits (longlongint?)): 1. "unique" programmer ID 2. ID for a "category" of types (graphical objects, mathematical objects, dialog elements, ...) - unique only for the programmer 3. ID for a certain type within a category 4. "version number" for the type (i.e., if the fields or their semantics change, the version number will be changed, too, so that old objects in streams can be recognized) > Then what about storing the name of the object itself > in the Stream? As I said above, I wouldn't like this. But it could be an idea to have ObjID be a string instead of a numerical value. But I'm not sure if it's worth the additional work required... > > Thinking about how to implement this, I realize this is basically the same > > as object constants -- something that's missing in BP and I could've used > > sometimes. This could be a useful extension to BP's objects. (The constants > > and their values would be inherited if not redeclared, just like virtual > > methods.) > > And they would be stored in the VMT. Sounds reasonable. Exactly. They would need to be _typed_ constants then, wouldn't they? (But there's no problem about it, except that the programmer has to type a little bit more...) Just an addition to the class variables (this might complicate matters a bit more, though): The question is, should the variables be shared with child types or duplicated? I think there could be applications for both. To make clear what I mean, an example: Type "a" declares a class variable "v". Type "b(a)" doesn't redeclare "v", so it uses the same variable as "a". Type "c(a)" redeclares "v", so it gets a variable of its own (of course, it must be of the same type as "a.v", but it could have a different initializer). Does this seem reasonable? To implement this, there must be a pointer to the actual variable in the VMT (which would point to the same variable for "a" and "b", and to a different variable for "c"). > Sounds good, but I think the "stabilization" of gpc-2.1 has higher > priority. But this might be of interest for gpc-2.2 ... I (at least) am not in a hurry (now)... ;-) Pierre Phaneuf wrote: > And also not put all the symbols in every programs, just those that use > the "ClassName()" function, optimizing those using constants as their > parameter and so on... Perhaps it's easier to let "ClassName" be a normal object constant (if they'll be implemented). Then the programmer could decide which names to include in the program and how to call them (e.g. the actual identifier might be "TSomething", but for the ClassName it might be preferable to have just "Something"). > The way I see it, the best way is to make a legal way to directly call a > specific class constructor. Like the "typed new()" function (passing an > object type as the first parameter) does, but being able to put a variable > there. Maybe a GPC-specific new() function? With another name of course to > avoid incompatibilities... This would require something like "virtual constructors", wouldn't it? I.e., the constructors would have to have the same parameters in all classes, and their addresses would be stored in the VMT. Doesn't seem impossible, perhaps it's the most logical thing to do. Peter Gerwinski wrote: > Look whether the VMT field contains a nonzero value. To be absolutely > sure, we can even check whether the pointer really points to a VMT: The > first Word pointed to must be a positive Integer (the size of the object), > the second one its negative (which is included for purposes like this > one). Problem: This will only work if the object was pre-initialized > to have a zero VMT field. This can be achieved with `New', but not with > `GetMem', so you have still to be careful when implementing streams. And what about non-dynamic objects (i.e. in the global data or the local data of a procedure)? They're not often used as it seems, but AFAIK it's legal to do so -- and I do sometimes. In order to rely on this method, the compiler would have to initialize their VMT fields to 0, even if the variable is "uninitialized". Then we could be sure in all cases but GetMem, and since GetMem is a "dirty trick", it's the programmer's responsibility to set the VMT to 0 (or whatever) after GetMem'ming. > > Are we looking for BP compatibility or not? > > We are in part. The primary goal of GPC is to produce the best Pascal > compiler the world has ever seen. I agree with Peter. I, FWIW, didn't use TV -- partly because some parts of it (including class registration) were, IMHO, badly implemented. If gpc's TV would be the same, I probably wouldn't use it, either. > (See the Info documentation for > details.) BP compatibility is desireable because (ii) BP is not too > bad and (i) many BP programmers will try GPC only if they can use their > existing programs without any change. So we may need both: a "100% BP compatible" unit for quick changes, and a "better" gpc unit to which programs can be converted afterwards, and which new programs can use from the beginning. Actually, I think, the changes needed for BP programs shouldn't be too big: make the "Load" constructor virtual (if we do it this way), declare the "ObjID" constant, and remove the registration stuff. Could even be simplified with some "IFDEF"s and clever use of the preprocessor, I guess. > How does Delphi do this? (Sorry for the stupid question, but my > experience with Delphi is very limited, primarily because I cannot stand > the mouse-only "user interface".) Argh! Mouse-only for a programmers' tool??? Lucky me that I didn't buy it! > What about making the structure of the VMT record visible for the program? > For instance a built-in > > Type > VmtRec = record > Size, NegSize: Integer; > VirtualMethod: array [ 0..1 ] of Pointer; > end (* VmtRec *); > > Where the `1' above stands for the unknown number of methods in a VMT. Then it should be "0..0" or "1..1", but I prefer the following. > (* I thought about changing the VMT to a schema type > > Type > VmtRec ( n: Integer ) = record > Size, NegSize: Integer; > VirtualMethod: array [ 1..n ] of Pointer; > end (* VmtRec *); > > which would place `n' as an additional field at the very beginning of > each VMT. But it's probably better to let `Size' stay the first field and > to save the additional storage for the number of methods in the object. *) I think it's worth the 4 bytes to have a cleaner structure and not introduce new "dirty tricks" -- just my experience from the way Borland messed up their objects. It also wouldn't be the best promotion for schema types, if this build-in structure, where schema types seem natural, didn't use them. OTOH, the introduction of object constants would break this structure anyway, since the VMT wouldn't contain only pointers then. So perhaps only declare Type VmtRec = record Size, NegSize: Integer; MethodsAndConstants: Void; end (* VmtRec *); and leave all access to "MethodsAndConstants" to the programmer's responsibility (though I don't see any need for this at all -- I think anything can be achieved by assigning the VMT offset to an object, and accessing its fields/methods by normal means). (BTW: Is "Void" a valid declaration of size 0? Otherwise perhaps "record end", this is allowed at least in BP.) A "Parent" field in the VMT seems quite useful to me. Also, a list of the childs (this would require a "FirstChild", and a "Sibling" field in each VMT). And perhaps they could be accessed through the VmtRec as well as as normal object constants... -- Frank Heckenbach, Erlangen, Germany heckenb@mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm From gpc-request@santra.hut.fi Mon May 26 13:23:57 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id NAA25922 for ; Mon, 26 May 1997 13:23:57 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA149070; Mon, 26 May 1997 13:18:40 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA45284; Mon, 26 May 1997 13:18:25 +0200 Received: from agnes.dida.physik.uni-essen.de (peter@agnes.Dida.Physik.Uni-Essen.DE [132.252.78.226]) by santra.hut.fi (8.8.5/8.8.2z) with SMTP id OAA04127 for ; Mon, 26 May 1997 14:02:43 +0300 (EET DST) Received: (from peter@localhost) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) id NAA25864 for gpc@hut.fi; Mon, 26 May 1997 13:07:54 +0200 From: Peter Gerwinski Message-Id: <199705261107.NAA25864@agnes.dida.physik.uni-essen.de> Subject: Re: OOP (Was: bpcompat-1.0.zip) To: gpc@hut.fi Date: Mon, 26 May 1997 13:07:52 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO According to Pierre Phaneuf: > > That's the problem (that you're not sure it will not change). BTW, the > constructor *is* the logical place do to such a thing... I agree, but not every constructor call does actually initialize an object. Since it is difficult to be sure whether an object already is initialized or not, we have to decide about this when the constructor is *called*. For this reason, it happened to be easier to do the initialization outside the constructor's body. If we find a method to be *sure* if the object is initialized, I can change constructors to do initialization in the body. Anyway, this does not matter unless you do tricks like `GetMem'ming an object. > But how do you check if an object is initialized or not? Look whether the VMT field contains a nonzero value. To be absolutely sure, we can even check whether the pointer really points to a VMT: The first Word pointed to must be a positive Integer (the size of the object), the second one its negative (which is included for purposes like this one). Problem: This will only work if the object was pre-initialized to have a zero VMT field. This can be achieved with `New', but not with `GetMem', so you have still to be careful when implementing streams. > I don't think > this is the best way either, unless you can devise a *sure* way to check > out if the object is initialized. What else would you propose? > In BP it cannot. It *must* be a constructor, because this is relied upon > by TStream.Get to initialize the object VMT link correctly and allocate > the correct amount of memory. It could be in BP too, if we changed the `tStream' object. Just do everything, the constructor would normally do, by hand. > I am doing a BP compatible StreamRec facility for the BPCOMPAT package. Great! }:-=)= (* This shall be a smiling Gnu. :*) > Are we looking for BP compatibility or not? We are in part. The primary goal of GPC is to produce the best Pascal compiler the world has ever seen. (See the Info documentation for details.) BP compatibility is desireable because (ii) BP is not too bad and (i) many BP programmers will try GPC only if they can use their existing programs without any change. > BTW, I *am* also developing a > class library made just for GPC using all the new features and fixing many > of the problems with the BP OBJECTS.PAS and the TurboVision libraries. :-) > It would be nice to have RTL functions to get an object name and parent, > a bit like Delphi can give you the class name of an object. How does Delphi do this? (Sorry for the stupid question, but my experience with Delphi is very limited, primarily because I cannot stand the mouse-only "user interface".) > A separate > function would be better (probably something accepting a VMT pointer (as > returned by TypeOf() ) as a parameter), since it wouldn't "use up" a > method name. What about making the structure of the VMT record visible for the program? For instance a built-in Type VmtRec = record Size, NegSize: Integer; VirtualMethod: array [ 0..1 ] of Pointer; end (* VmtRec *); Where the `1' above stands for the unknown number of methods in a VMT. (* I thought about changing the VMT to a schema type Type VmtRec ( n: Integer ) = record Size, NegSize: Integer; VirtualMethod: array [ 1..n ] of Pointer; end (* VmtRec *); which would place `n' as an additional field at the very beginning of each VMT. But it's probably better to let `Size' stay the first field and to save the additional storage for the number of methods in the object. *) > And also not put all the symbols in every programs, just those that use > the "ClassName()" function, Difficult. > optimizing those using constants as their parameter Easier. > and so on... Most difficult. > A unique number is a bad idea and shouldn't be used. They can change and > invalidate a file containing streamed objects from compile to compile. That's what I meant with the "how to choose" problem. When deriving it from the name in an unambiguous way, it would work. But how would that "unambiguous way" look like? A CRTC check sum? (I don't really know what that is ...;) > The way I see it, the best way is to make a legal way to directly call a > specific class constructor. Like the "typed new()" function (passing an > object type as the first parameter) does, but being able to put a variable > there. Maybe a GPC-specific new() function? `New' already is as GPC-specific as it could be ... > With another name of course to > avoid incompatibilities... I will think about that and let you know if I have an idea. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] From gpc-request@santra.hut.fi Wed May 28 01:08:56 1997 Return-Path: gpc-request@santra.hut.fi Received: from sp2.power.uni-essen.de (spf101.power.uni-essen.de [132.252.180.1]) by agnes.dida.physik.uni-essen.de (8.6.11/8.6.9) with SMTP id BAA31092 for ; Wed, 28 May 1997 01:08:55 +0200 Received: from mail.uni-essen.de by sp2.power.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70182; Wed, 28 May 1997 01:03:14 +0200 Received: from santra.hut.fi by aixrs1.hrz.uni-essen.de (AIX 4.1/UCB 5.64/4.03) id AA70642; Wed, 28 May 1997 01:02:59 +0200 Received: from dilu.ml.org (pp@55-174.hy.cgocable.ca [205.237.55.174]) by santra.hut.fi (8.8.5/8.8.2z) with ESMTP id BAA14110 for ; Wed, 28 May 1997 01:52:41 +0300 (EET DST) Received: from localhost (pp@localhost) by dilu.ml.org (8.8.5/8.8.5) with SMTP id SAA20312 for ; Tue, 27 May 1997 18:49:33 -0400 Date: Tue, 27 May 1997 18:49:32 -0400 (EDT) From: Pierre Phaneuf Reply-To: pierre@tycho.com To: GNU Pascal Mailing List Subject: Re: bpcompat-1.0.zip In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-305287625-1543056963-864773372=:11773" Status: RO This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---305287625-1543056963-864773372=:11773 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 26 May 1997, The African Chief wrote: > >Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27... > > Can you please tell me which (if any) of the UNITS currently compiles > (without any change to the sources) under Linux? It is good to note > these things in future releases. Thanks. Attached to this e-mail is the output of compiling each .pas files one after the others. Here's the bash script I used to do it. --- cut here for i in ./*.pas ; do gpc -Wall --automake $i done --- cut here Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. ---305287625-1543056963-864773372=:11773 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=bpcompat-output Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Z3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgUGF0aGxvY2F0ZSc6DQpncGN1dGls Lm8oLnRleHQrMHgxZDBiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2Vh cmNocGF0aCcNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYEludDJwY2hhcic6 DQpncGN1dGlsLm8oLnRleHQrMHgyYjAwKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgaXRvYScNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYENvcHlmaWxl JzoNCmdwY3V0aWwubygudGV4dCsweDJlNDcpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBnZXRmdGltZScNCmdwY3V0aWwubygudGV4dCsweDMwMTkpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCmdwY3V0aWwubzog SW4gZnVuY3Rpb24gYENvcHlmaWxlZXgnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4 MzIxYSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0KZ3Bj dXRpbC5vKC50ZXh0KzB4MzRhOSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YHNldGZ0aW1lJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgV3JpdGVwY2hh cic6DQpncGN1dGlsLm8oLnRleHQrMHgzNTBiKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgY3B1dHMnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBXcml0 ZXN0cmluZyc6DQpncGN1dGlsLm8oLnRleHQrMHgzNTQxKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgY3B1dHMnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9w X2ZpbmRmaXJzdCc6DQpkb3MubygudGV4dCsweDU2ZCk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZmluZGZpcnN0Jw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9maW5kbmV4dCc6DQpkb3MubygudGV4dCsweDVlMSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQpkb3MubzogSW4g ZnVuY3Rpb24gYEdldGNicmVhayc6DQpkb3MubygudGV4dCsweDZhNCk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGNicmsnDQpkb3MubzogSW4gZnVu Y3Rpb24gYFNldGNicmVhayc6DQpkb3MubygudGV4dCsweDZkMyk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNldGNicmsnDQpkb3MubzogSW4gZnVuY3Rp b24gYEZpbGVzcGxpdCc6DQpkb3MubygudGV4dCsweGM3YSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGZuc3BsaXQnDQpkb3MubzogSW4gZnVuY3Rpb24g YEdldGN1cmRpcic6DQpkb3MubygudGV4dCsweGQxZSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQyZSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsw eGQzZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3Mu bygudGV4dCsweGQ3ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRp c2snDQpkb3MubzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQpkb3MubygudGV4 dCsweGRjYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpk b3MubzogSW4gZnVuY3Rpb24gYERpc2tmcmVlJzoNCmRvcy5vKC50ZXh0KzB4 ZWRmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYERpc2tzaXplJzoNCmRvcy5vKC50ZXh0KzB4ZjNm KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX2dldGRhdGUnOg0KZG9zLm8oLnRleHQrMHhmOGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRhdGUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYF9wX2dldHRpbWUnOg0KZG9zLm8oLnRleHQrMHhm Y2IpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldHRpbWUnDQpk b3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGRhdGUnOg0KZG9zLm8oLnRleHQr MHgxMDFmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGF0ZScNCmRv cy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0dGltZSc6DQpkb3MubygudGV4dCsw eDEwNTMpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldHRpbWUn DQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2dldGZ0aW1lJzoNCmRvcy5vKC50 ZXh0KzB4MTA3ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1l Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmdGltZSc6DQpkb3Mubygu dGV4dCsweDEwOWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGlt ZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZmF0dHInOg0KZG9zLm8o LnRleHQrMHgxMWUwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19n ZXRmaWxlYXR0cicNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZmF0dHIn Og0KZG9zLm8oLnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Rvc19zZXRmaWxlYXR0cicNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBg SW50MnBjaGFyJzoNCnN5c3RlbS5vKC50ZXh0KzB4YmQwKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgaXRvYScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBg TWVtYXZhaWwnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNGRiKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9mcmVlX21lbW9yeV9pbmZvcm1h dGlvbicNCnN5c3RlbS5vKC50ZXh0KzB4MjRlNyk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9fZHBtaV9nZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86IElu IGZ1bmN0aW9uIGBNYXhhdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI1MGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVt b3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTE3KTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpz eXN0ZW0ubzogSW4gZnVuY3Rpb24gYFNldGZtb2RlJzoNCnN5c3RlbS5vKC50 ZXh0KzB4MjUzZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScN CnN5c3RlbS5vKC50ZXh0KzB4MjU1MSk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9mbW9kZScNCnN5c3RlbS5vKC50ZXh0KzB4MjU2Mik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlv biBgR2V0Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTg3KTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBjb25zdHJ1Y3Rvcl8zMic6DQpzeXN0ZW0ubygudGV4dCsweDI5ZTIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQovdXNyL2xpYi9j cnQxLm86IEluIGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0MS5v KC50ZXh0KzB4NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWluJw0K L3Vzci9saWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91c3Iv bGliL2NydDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgbWFpbicNCi91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24gYF9zdGFy dCc6DQovdXNyL2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYG1haW4nDQovdG1wL2NjYTE5MzUwMS5vOiBJbiBmdW5j dGlvbiBgTm9zb3VuZCc6DQovdG1wL2NjYTE5MzUwMS5vKC50ZXh0KzB4MTYp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzb3VuZCcNCi90bXAvY2NhMTkz NTAxLm86IEluIGZ1bmN0aW9uIGBCbG9ja2N1cnNvcic6DQovdG1wL2NjYTE5 MzUwMS5vKC50ZXh0KzB4MzYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf c2V0Y3Vyc29ydHlwZScNCi90bXAvY2NhMTkzNTAxLm86IEluIGZ1bmN0aW9u IGBGYXRjdXJzb3InOg0KL3RtcC9jY2ExOTM1MDEubygudGV4dCsweDU2KTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX3NldGN1cnNvcnR5cGUnDQovdG1w L2NjYTE5MzUwMS5vOiBJbiBmdW5jdGlvbiBgTm9ybWFsY3Vyc29yJzoNCi90 bXAvY2NhMTkzNTAxLm8oLnRleHQrMHg3Nik6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9zZXRjdXJzb3J0eXBlJw0KL3RtcC9jY2ExOTM1MDEubzogSW4g ZnVuY3Rpb24gYEhpZGRlbmN1cnNvcic6DQovdG1wL2NjYTE5MzUwMS5vKC50 ZXh0KzB4OTYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vyc29y dHlwZScNCi90bXAvY2NhMTkzNTAxLm86IEluIGZ1bmN0aW9uIGBDdXJzb3In Og0KL3RtcC9jY2ExOTM1MDEubygudGV4dCsweGI4KTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgX3NldGN1cnNvcnR5cGUnDQovdXNyL2xpYi9jcnQxLm86 IEluIGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0MS5vKC50ZXh0 KzB4NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWluJw0KL3Vzci9s aWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91c3IvbGliL2Ny dDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgbWFp bicNCi91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24gYF9zdGFydCc6DQov dXNyL2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYG1haW4nDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYEludDJwY2hh cic6DQpzeXN0ZW0ubygudGV4dCsweGJkMCk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYGl0b2EnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1lbWF2YWls JzoNCnN5c3RlbS5vKC50ZXh0KzB4MjRkYik6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpz eXN0ZW0ubygudGV4dCsweDI0ZTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlv biBgTWF4YXZhaWwnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTBiKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9mcmVlX21lbW9yeV9pbmZv cm1hdGlvbicNCnN5c3RlbS5vKC50ZXh0KzB4MjUxNyk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86 IEluIGZ1bmN0aW9uIGBTZXRmbW9kZSc6DQpzeXN0ZW0ubygudGV4dCsweDI1 M2UpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0u bygudGV4dCsweDI1NTEpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1v ZGUnDQpzeXN0ZW0ubygudGV4dCsweDI1NjIpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYEdldGZt b2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjU4Nyk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgY29u c3RydWN0b3JfMzInOg0Kc3lzdGVtLm8oLnRleHQrMHgyOWUyKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0KL3RtcC9jY2ExOTM2NzEubzog SW4gZnVuY3Rpb24gYF9wX2ZpbmRmaXJzdCc6DQovdG1wL2NjYTE5MzY3MS5v KC50ZXh0KzB4NTZkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19m aW5kZmlyc3QnDQovdG1wL2NjYTE5MzY3MS5vOiBJbiBmdW5jdGlvbiBgX3Bf ZmluZG5leHQnOg0KL3RtcC9jY2ExOTM2NzEubygudGV4dCsweDVlMSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQovdG1wL2Nj YTE5MzY3MS5vOiBJbiBmdW5jdGlvbiBgR2V0Y2JyZWFrJzoNCi90bXAvY2Nh MTkzNjcxLm8oLnRleHQrMHg2YTQpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBnZXRjYnJrJw0KL3RtcC9jY2ExOTM2NzEubzogSW4gZnVuY3Rpb24gYFNl dGNicmVhayc6DQovdG1wL2NjYTE5MzY3MS5vKC50ZXh0KzB4NmQzKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0Y2JyaycNCi90bXAvY2NhMTkzNjcx Lm86IEluIGZ1bmN0aW9uIGBGaWxlc3BsaXQnOg0KL3RtcC9jY2ExOTM2NzEu bygudGV4dCsweGM3YSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGZuc3Bs aXQnDQovdG1wL2NjYTE5MzY3MS5vOiBJbiBmdW5jdGlvbiBgR2V0Y3VyZGly JzoNCi90bXAvY2NhMTkzNjcxLm8oLnRleHQrMHhkMWUpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBnZXRkaXNrJw0KL3RtcC9jY2ExOTM2NzEubygudGV4 dCsweGQyZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQov dG1wL2NjYTE5MzY3MS5vKC50ZXh0KzB4ZDNkKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgc2V0ZGlzaycNCi90bXAvY2NhMTkzNjcxLm8oLnRleHQrMHhk N2QpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkaXNrJw0KL3RtcC9j Y2ExOTM2NzEubzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQovdG1wL2NjYTE5 MzY3MS5vKC50ZXh0KzB4ZGNiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg Z2V0ZGlzaycNCi90bXAvY2NhMTkzNjcxLm86IEluIGZ1bmN0aW9uIGBEaXNr ZnJlZSc6DQovdG1wL2NjYTE5MzY3MS5vKC50ZXh0KzB4ZWRmKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQovdG1wL2NjYTE5MzY3MS5v OiBJbiBmdW5jdGlvbiBgRGlza3NpemUnOg0KL3RtcC9jY2ExOTM2NzEubygu dGV4dCsweGYzZik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRmcmVl Jw0KL3RtcC9jY2ExOTM2NzEubzogSW4gZnVuY3Rpb24gYF9wX2dldGRhdGUn Og0KL3RtcC9jY2ExOTM2NzEubygudGV4dCsweGY4Yik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZGF0ZScNCi90bXAvY2NhMTkzNjcxLm86 IEluIGZ1bmN0aW9uIGBfcF9nZXR0aW1lJzoNCi90bXAvY2NhMTkzNjcxLm8o LnRleHQrMHhmY2IpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dl dHRpbWUnDQovdG1wL2NjYTE5MzY3MS5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0 ZGF0ZSc6DQovdG1wL2NjYTE5MzY3MS5vKC50ZXh0KzB4MTAxZik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNldGRhdGUnDQovdG1wL2NjYTE5MzY3MS5v OiBJbiBmdW5jdGlvbiBgX3Bfc2V0dGltZSc6DQovdG1wL2NjYTE5MzY3MS5v KC50ZXh0KzB4MTA1Myk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nf c2V0dGltZScNCi90bXAvY2NhMTkzNjcxLm86IEluIGZ1bmN0aW9uIGBfcF9n ZXRmdGltZSc6DQovdG1wL2NjYTE5MzY3MS5vKC50ZXh0KzB4MTA3ZSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0KL3RtcC9jY2ExOTM2 NzEubzogSW4gZnVuY3Rpb24gYF9wX3NldGZ0aW1lJzoNCi90bXAvY2NhMTkz NjcxLm8oLnRleHQrMHgxMDllKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg c2V0ZnRpbWUnDQovdG1wL2NjYTE5MzY3MS5vOiBJbiBmdW5jdGlvbiBgX3Bf Z2V0ZmF0dHInOg0KL3RtcC9jY2ExOTM2NzEubygudGV4dCsweDExZTApOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGZpbGVhdHRyJw0KL3Rt cC9jY2ExOTM2NzEubzogSW4gZnVuY3Rpb24gYF9wX3NldGZhdHRyJzoNCi90 bXAvY2NhMTkzNjcxLm8oLnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX2Rvc19zZXRmaWxlYXR0cicNCi91c3IvbGliL2NydDEubzog SW4gZnVuY3Rpb24gYF9zdGFydCc6DQovdXNyL2xpYi9jcnQxLm8oLnRleHQr MHg1Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1haW4nDQovdXNyL2xp Yi9jcnQxLm86IEluIGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0 MS5vKC50ZXh0KzB4NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWlu Jw0KL3Vzci9saWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91 c3IvbGliL2NydDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgbWFpbicNCi91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24gYF9z dGFydCc6DQovdXNyL2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYG1haW4nDQpkb3MubzogSW4gZnVuY3Rpb24gYF9w X2ZpbmRmaXJzdCc6DQpkb3MubygudGV4dCsweDU2ZCk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZmluZGZpcnN0Jw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9maW5kbmV4dCc6DQpkb3MubygudGV4dCsweDVlMSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQpkb3MubzogSW4g ZnVuY3Rpb24gYEdldGNicmVhayc6DQpkb3MubygudGV4dCsweDZhNCk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGNicmsnDQpkb3MubzogSW4gZnVu Y3Rpb24gYFNldGNicmVhayc6DQpkb3MubygudGV4dCsweDZkMyk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNldGNicmsnDQpkb3MubzogSW4gZnVuY3Rp b24gYEZpbGVzcGxpdCc6DQpkb3MubygudGV4dCsweGM3YSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGZuc3BsaXQnDQpkb3MubzogSW4gZnVuY3Rpb24g YEdldGN1cmRpcic6DQpkb3MubygudGV4dCsweGQxZSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQyZSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsw eGQzZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3Mu bygudGV4dCsweGQ3ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRp c2snDQpkb3MubzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQpkb3MubygudGV4 dCsweGRjYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpk b3MubzogSW4gZnVuY3Rpb24gYERpc2tmcmVlJzoNCmRvcy5vKC50ZXh0KzB4 ZWRmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYERpc2tzaXplJzoNCmRvcy5vKC50ZXh0KzB4ZjNm KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX2dldGRhdGUnOg0KZG9zLm8oLnRleHQrMHhmOGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRhdGUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYF9wX2dldHRpbWUnOg0KZG9zLm8oLnRleHQrMHhm Y2IpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldHRpbWUnDQpk b3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGRhdGUnOg0KZG9zLm8oLnRleHQr MHgxMDFmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGF0ZScNCmRv cy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0dGltZSc6DQpkb3MubygudGV4dCsw eDEwNTMpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldHRpbWUn DQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2dldGZ0aW1lJzoNCmRvcy5vKC50 ZXh0KzB4MTA3ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1l Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmdGltZSc6DQpkb3Mubygu dGV4dCsweDEwOWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGlt ZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZmF0dHInOg0KZG9zLm8o LnRleHQrMHgxMWUwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19n ZXRmaWxlYXR0cicNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZmF0dHIn Og0KZG9zLm8oLnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Rvc19zZXRmaWxlYXR0cicNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24g YFBhdGhsb2NhdGUnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MWQwYik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNlYXJjaHBhdGgnDQpncGN1dGlsLm86IElu IGZ1bmN0aW9uIGBJbnQycGNoYXInOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MmIw MCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGl0b2EnDQpncGN1dGlsLm86 IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZSc6DQpncGN1dGlsLm8oLnRleHQrMHgy ZTQ3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpncGN1 dGlsLm8oLnRleHQrMHgzMDE5KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg c2V0ZnRpbWUnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZWV4 JzoNCmdwY3V0aWwubygudGV4dCsweDMyMWEpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBnZXRmdGltZScNCmdwY3V0aWwubygudGV4dCsweDM0YTkpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCmdwY3V0aWwubzog SW4gZnVuY3Rpb24gYFdyaXRlcGNoYXInOg0KZ3BjdXRpbC5vKC50ZXh0KzB4 MzUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNwdXRzJw0KZ3BjdXRp bC5vOiBJbiBmdW5jdGlvbiBgV3JpdGVzdHJpbmcnOg0KZ3BjdXRpbC5vKC50 ZXh0KzB4MzU0MSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNwdXRzJw0K c3lzdGVtLm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8o LnRleHQrMHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0K c3lzdGVtLm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygu dGV4dCsweDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlf Z2V0X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQr MHgyNGU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9w YWdlX3NpemUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoN CnN5c3RlbS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0 ZW0ubygudGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf X2RwbWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBg U2V0Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUx KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8o LnRleHQrMHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2Rl Jw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0u bygudGV4dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1v ZGUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoN CnN5c3RlbS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9mbW9kZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZmluZGZpcnN0 JzoNCmRvcy5vKC50ZXh0KzB4NTZkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Rvc19maW5kZmlyc3QnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2Zp bmRuZXh0JzoNCmRvcy5vKC50ZXh0KzB4NWUxKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX2Rvc19maW5kbmV4dCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBg R2V0Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmE0KTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgZ2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgU2V0 Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmQzKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgc2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgRmlsZXNw bGl0JzoNCmRvcy5vKC50ZXh0KzB4YzdhKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgZm5zcGxpdCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0Y3VyZGly JzoNCmRvcy5vKC50ZXh0KzB4ZDFlKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgZ2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDJlKTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDNkKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4 ZDdkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5v OiBJbiBmdW5jdGlvbiBgR2V0ZGlyJzoNCmRvcy5vKC50ZXh0KzB4ZGNiKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vOiBJbiBm dW5jdGlvbiBgRGlza2ZyZWUnOg0KZG9zLm8oLnRleHQrMHhlZGYpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5j dGlvbiBgRGlza3NpemUnOg0KZG9zLm8oLnRleHQrMHhmM2YpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgX3BfZ2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweGY4Yik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZGF0ZScNCmRvcy5vOiBJbiBmdW5j dGlvbiBgX3BfZ2V0dGltZSc6DQpkb3MubygudGV4dCsweGZjYik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0dGltZScNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3Bfc2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweDEwMWYpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkYXRlJw0KZG9zLm86IEluIGZ1 bmN0aW9uIGBfcF9zZXR0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA1Myk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nfc2V0dGltZScNCmRvcy5vOiBJ biBmdW5jdGlvbiBgX3BfZ2V0ZnRpbWUnOg0KZG9zLm8oLnRleHQrMHgxMDdl KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX3NldGZ0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA5 ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KZG9zLm86 IEluIGZ1bmN0aW9uIGBfcF9nZXRmYXR0cic6DQpkb3MubygudGV4dCsweDEx ZTApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGZpbGVhdHRy Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmYXR0cic6DQpkb3Mubygu dGV4dCsweDEzMzApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3Nl dGZpbGVhdHRyJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgUGF0aGxvY2F0 ZSc6DQpncGN1dGlsLm8oLnRleHQrMHgxZDBiKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgc2VhcmNocGF0aCcNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24g YEludDJwY2hhcic6DQpncGN1dGlsLm8oLnRleHQrMHgyYjAwKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgaXRvYScNCmdwY3V0aWwubzogSW4gZnVuY3Rp b24gYENvcHlmaWxlJzoNCmdwY3V0aWwubygudGV4dCsweDJlNDcpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRmdGltZScNCmdwY3V0aWwubygudGV4 dCsweDMwMTkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScN CmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYENvcHlmaWxlZXgnOg0KZ3BjdXRp bC5vKC50ZXh0KzB4MzIxYSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdl dGZ0aW1lJw0KZ3BjdXRpbC5vKC50ZXh0KzB4MzRhOSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlv biBgV3JpdGVwY2hhcic6DQpncGN1dGlsLm8oLnRleHQrMHgzNTBiKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgY3B1dHMnDQpncGN1dGlsLm86IEluIGZ1 bmN0aW9uIGBXcml0ZXN0cmluZyc6DQpncGN1dGlsLm8oLnRleHQrMHgzNTQx KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgY3B1dHMnDQpzeXN0ZW0ubzog SW4gZnVuY3Rpb24gYEludDJwY2hhcic6DQpzeXN0ZW0ubygudGV4dCsweGJk MCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGl0b2EnDQpzeXN0ZW0ubzog SW4gZnVuY3Rpb24gYE1lbWF2YWlsJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjRk Yik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9t ZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygudGV4dCsweDI0ZTcpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6ZScN CnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgTWF4YXZhaWwnOg0Kc3lzdGVtLm8o LnRleHQrMHgyNTBiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1p X2dldF9mcmVlX21lbW9yeV9pbmZvcm1hdGlvbicNCnN5c3RlbS5vKC50ZXh0 KzB4MjUxNyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRf cGFnZV9zaXplJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBTZXRmbW9kZSc6 DQpzeXN0ZW0ubygudGV4dCsweDI1M2UpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBfZm1vZGUnDQpzeXN0ZW0ubygudGV4dCsweDI1NTEpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0ubygudGV4dCsweDI1 NjIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0u bzogSW4gZnVuY3Rpb24gYEdldGZtb2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4 MjU4Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3Rl bS5vOiBJbiBmdW5jdGlvbiBgY29uc3RydWN0b3JfMzInOg0Kc3lzdGVtLm8o LnRleHQrMHgyOWUyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2Rl Jw0KL3Vzci9saWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91 c3IvbGliL2NydDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgbWFpbicNCi91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24gYF9z dGFydCc6DQovdXNyL2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYG1haW4nDQpkb3MubzogSW4gZnVuY3Rpb24gYF9w X2ZpbmRmaXJzdCc6DQpkb3MubygudGV4dCsweDU2ZCk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZmluZGZpcnN0Jw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9maW5kbmV4dCc6DQpkb3MubygudGV4dCsweDVlMSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQpkb3MubzogSW4g ZnVuY3Rpb24gYEdldGNicmVhayc6DQpkb3MubygudGV4dCsweDZhNCk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGNicmsnDQpkb3MubzogSW4gZnVu Y3Rpb24gYFNldGNicmVhayc6DQpkb3MubygudGV4dCsweDZkMyk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNldGNicmsnDQpkb3MubzogSW4gZnVuY3Rp b24gYEZpbGVzcGxpdCc6DQpkb3MubygudGV4dCsweGM3YSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGZuc3BsaXQnDQpkb3MubzogSW4gZnVuY3Rpb24g YEdldGN1cmRpcic6DQpkb3MubygudGV4dCsweGQxZSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQyZSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsw eGQzZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3Mu bygudGV4dCsweGQ3ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRp c2snDQpkb3MubzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQpkb3MubygudGV4 dCsweGRjYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpk b3MubzogSW4gZnVuY3Rpb24gYERpc2tmcmVlJzoNCmRvcy5vKC50ZXh0KzB4 ZWRmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYERpc2tzaXplJzoNCmRvcy5vKC50ZXh0KzB4ZjNm KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX2dldGRhdGUnOg0KZG9zLm8oLnRleHQrMHhmOGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRhdGUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYF9wX2dldHRpbWUnOg0KZG9zLm8oLnRleHQrMHhm Y2IpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldHRpbWUnDQpk b3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGRhdGUnOg0KZG9zLm8oLnRleHQr MHgxMDFmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGF0ZScNCmRv cy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0dGltZSc6DQpkb3MubygudGV4dCsw eDEwNTMpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldHRpbWUn DQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2dldGZ0aW1lJzoNCmRvcy5vKC50 ZXh0KzB4MTA3ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1l Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmdGltZSc6DQpkb3Mubygu dGV4dCsweDEwOWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGlt ZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZmF0dHInOg0KZG9zLm8o LnRleHQrMHgxMWUwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19n ZXRmaWxlYXR0cicNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZmF0dHIn Og0KZG9zLm8oLnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Rvc19zZXRmaWxlYXR0cicNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBg SW50MnBjaGFyJzoNCnN5c3RlbS5vKC50ZXh0KzB4YmQwKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgaXRvYScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBg TWVtYXZhaWwnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNGRiKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9mcmVlX21lbW9yeV9pbmZvcm1h dGlvbicNCnN5c3RlbS5vKC50ZXh0KzB4MjRlNyk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9fZHBtaV9nZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86IElu IGZ1bmN0aW9uIGBNYXhhdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI1MGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVt b3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTE3KTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpz eXN0ZW0ubzogSW4gZnVuY3Rpb24gYFNldGZtb2RlJzoNCnN5c3RlbS5vKC50 ZXh0KzB4MjUzZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScN CnN5c3RlbS5vKC50ZXh0KzB4MjU1MSk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9mbW9kZScNCnN5c3RlbS5vKC50ZXh0KzB4MjU2Mik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlv biBgR2V0Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTg3KTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBjb25zdHJ1Y3Rvcl8zMic6DQpzeXN0ZW0ubygudGV4dCsweDI5ZTIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQovdG1wL2NjYTE5 NTE3MS5vOiBJbiBmdW5jdGlvbiBgUGF0aGxvY2F0ZSc6DQovdG1wL2NjYTE5 NTE3MS5vKC50ZXh0KzB4MWQwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YHNlYXJjaHBhdGgnDQovdG1wL2NjYTE5NTE3MS5vOiBJbiBmdW5jdGlvbiBg SW50MnBjaGFyJzoNCi90bXAvY2NhMTk1MTcxLm8oLnRleHQrMHgyYjAwKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgaXRvYScNCi90bXAvY2NhMTk1MTcx Lm86IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZSc6DQovdG1wL2NjYTE5NTE3MS5v KC50ZXh0KzB4MmU0Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0 aW1lJw0KL3RtcC9jY2ExOTUxNzEubygudGV4dCsweDMwMTkpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCi90bXAvY2NhMTk1MTcxLm86 IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZWV4JzoNCi90bXAvY2NhMTk1MTcxLm8o LnRleHQrMHgzMjFhKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRp bWUnDQovdG1wL2NjYTE5NTE3MS5vKC50ZXh0KzB4MzRhOSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KL3RtcC9jY2ExOTUxNzEubzog SW4gZnVuY3Rpb24gYFdyaXRlcGNoYXInOg0KL3RtcC9jY2ExOTUxNzEubygu dGV4dCsweDM1MGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjcHV0cycN Ci90bXAvY2NhMTk1MTcxLm86IEluIGZ1bmN0aW9uIGBXcml0ZXN0cmluZyc6 DQovdG1wL2NjYTE5NTE3MS5vKC50ZXh0KzB4MzU0MSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGNwdXRzJw0KL3Vzci9saWIvY3J0MS5vOiBJbiBmdW5j dGlvbiBgX3N0YXJ0JzoNCi91c3IvbGliL2NydDEubygudGV4dCsweDU3KTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgbWFpbicNCmNydC5vKC5kYXRhKzB4 MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYENoZWNrYnJlYWsnDQouL2Ny dC5vKC5kYXRhKzB4MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0KY3J0Lm8oLmRh dGErMHgxKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgQ2hlY2tlb2YnDQou L2NydC5vKC5kYXRhKzB4MSk6IGZpcnN0IGRlZmluZWQgaGVyZQ0KY3J0Lm8o LmRhdGErMHgyKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgQ2hlY2tzbm93 Jw0KLi9jcnQubyguZGF0YSsweDIpOiBmaXJzdCBkZWZpbmVkIGhlcmUNCmNy dC5vOiBJbiBmdW5jdGlvbiBgQXNzaWduY3J0JzoNCmNydC5vKC50ZXh0KzB4 MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYEFzc2lnbmNydCcNCi4vY3J0 Lm8oLnRleHQrMHgwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpjcnQubzogSW4g ZnVuY3Rpb24gYE5vc291bmQnOg0KY3J0Lm8oLnRleHQrMHgxMCk6IG11bHRp cGxlIGRlZmluaXRpb24gb2YgYE5vc291bmQnDQouL2NydC5vKC50ZXh0KzB4 MTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCmNydC5vOiBJbiBmdW5jdGlvbiBg QmxvY2tjdXJzb3InOg0KY3J0Lm8oLnRleHQrMHgzMCk6IG11bHRpcGxlIGRl ZmluaXRpb24gb2YgYEJsb2NrY3Vyc29yJw0KLi9jcnQubygudGV4dCsweDMw KTogZmlyc3QgZGVmaW5lZCBoZXJlDQpjcnQubzogSW4gZnVuY3Rpb24gYEZh dGN1cnNvcic6DQpjcnQubygudGV4dCsweDUwKTogbXVsdGlwbGUgZGVmaW5p dGlvbiBvZiBgRmF0Y3Vyc29yJw0KLi9jcnQubygudGV4dCsweDUwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpjcnQubzogSW4gZnVuY3Rpb24gYE5vcm1hbGN1 cnNvcic6DQpjcnQubygudGV4dCsweDcwKTogbXVsdGlwbGUgZGVmaW5pdGlv biBvZiBgTm9ybWFsY3Vyc29yJw0KLi9jcnQubygudGV4dCsweDcwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpjcnQubzogSW4gZnVuY3Rpb24gYEhpZGRlbmN1 cnNvcic6DQpjcnQubygudGV4dCsweDkwKTogbXVsdGlwbGUgZGVmaW5pdGlv biBvZiBgSGlkZGVuY3Vyc29yJw0KLi9jcnQubygudGV4dCsweDkwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpjcnQubzogSW4gZnVuY3Rpb24gYEN1cnNvcic6 DQpjcnQubygudGV4dCsweGIwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBg Q3Vyc29yJw0KLi9jcnQubygudGV4dCsweGIwKTogZmlyc3QgZGVmaW5lZCBo ZXJlDQpjcnQubzogSW4gZnVuY3Rpb24gYGluaXRfQ3J0JzoNCmNydC5vKC50 ZXh0KzB4ZDApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBpbml0X0NydCcN Ci4vY3J0Lm8oLnRleHQrMHhkMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0KL3Vz ci9saWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91c3IvbGli L2NydDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg bWFpbicNCi4vY3J0Lm86IEluIGZ1bmN0aW9uIGBOb3NvdW5kJzoNCi4vY3J0 Lm8oLnRleHQrMHgxNik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNvdW5k Jw0KLi9jcnQubzogSW4gZnVuY3Rpb24gYEJsb2NrY3Vyc29yJzoNCi4vY3J0 Lm8oLnRleHQrMHgzNik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9zZXRj dXJzb3J0eXBlJw0KLi9jcnQubzogSW4gZnVuY3Rpb24gYEZhdGN1cnNvcic6 DQouL2NydC5vKC50ZXh0KzB4NTYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBfc2V0Y3Vyc29ydHlwZScNCi4vY3J0Lm86IEluIGZ1bmN0aW9uIGBOb3Jt YWxjdXJzb3InOg0KLi9jcnQubygudGV4dCsweDc2KTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgX3NldGN1cnNvcnR5cGUnDQouL2NydC5vOiBJbiBmdW5j dGlvbiBgSGlkZGVuY3Vyc29yJzoNCi4vY3J0Lm8oLnRleHQrMHg5Nik6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9zZXRjdXJzb3J0eXBlJw0KLi9jcnQu bzogSW4gZnVuY3Rpb24gYEN1cnNvcic6DQouL2NydC5vKC50ZXh0KzB4Yjgp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlwZScNCmNy dC5vOiBJbiBmdW5jdGlvbiBgTm9zb3VuZCc6DQpjcnQubygudGV4dCsweDE2 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc291bmQnDQpjcnQubzogSW4g ZnVuY3Rpb24gYEJsb2NrY3Vyc29yJzoNCmNydC5vKC50ZXh0KzB4MzYpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlwZScNCmNydC5v OiBJbiBmdW5jdGlvbiBgRmF0Y3Vyc29yJzoNCmNydC5vKC50ZXh0KzB4NTYp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlwZScNCmNy dC5vOiBJbiBmdW5jdGlvbiBgTm9ybWFsY3Vyc29yJzoNCmNydC5vKC50ZXh0 KzB4NzYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlw ZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgSGlkZGVuY3Vyc29yJzoNCmNydC5v KC50ZXh0KzB4OTYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vy c29ydHlwZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgQ3Vyc29yJzoNCmNydC5v KC50ZXh0KzB4YjgpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0Y3Vy c29ydHlwZScNCi90bXAvY2NhMTk1NjMxLm86IEluIGZ1bmN0aW9uIGBGbHVz aGtiZCc6DQovdG1wL2NjYTE5NTYzMS5vKC50ZXh0KzB4ZSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9jb25pb19rYmhpdCcNCi90bXAvY2NhMTk1NjMx Lm86IEluIGZ1bmN0aW9uIGBHZXRrZXknOg0KL3RtcC9jY2ExOTU2MzEubygu dGV4dCsweGMxKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0Y2gnDQov dG1wL2NjYTE5NTYzMS5vKC50ZXh0KzB4ZDUpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBnZXRjaCcNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgSW50MnBj aGFyJzoNCnN5c3RlbS5vKC50ZXh0KzB4YmQwKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgaXRvYScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgTWVtYXZh aWwnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNGRiKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX19kcG1pX2dldF9mcmVlX21lbW9yeV9pbmZvcm1hdGlvbicN CnN5c3RlbS5vKC50ZXh0KzB4MjRlNyk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9fZHBtaV9nZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBNYXhhdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI1MGIpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2lu Zm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTE3KTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0u bzogSW4gZnVuY3Rpb24gYFNldGZtb2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4 MjUzZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3Rl bS5vKC50ZXh0KzB4MjU1MSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9m bW9kZScNCnN5c3RlbS5vKC50ZXh0KzB4MjU2Mik6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgR2V0 Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTg3KTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBj b25zdHJ1Y3Rvcl8zMic6DQpzeXN0ZW0ubygudGV4dCsweDI5ZTIpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQovdXNyL2xpYi9jcnQxLm86 IEluIGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0MS5vKC50ZXh0 KzB4NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWluJw0Kc3lzdGVt Lm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRleHQr MHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lzdGVt Lm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsw eDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2Zy ZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNGU3 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3Np emUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5c3Rl bS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9f ZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygu dGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlf Z2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgU2V0Zm1v ZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUxKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQr MHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lz dGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0ubygudGV4 dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpz eXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoNCnN5c3Rl bS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9m bW9kZScNCi90bXAvY2NhMTk1ODMxLm86IEluIGZ1bmN0aW9uIGBUc3RyY29s bGVjdGlvbl9MZXNzJzoNCi90bXAvY2NhMTk1ODMxLm8oLnRleHQrMHgyOWU5 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc3RyaWNtcCcNCi90bXAvY2Nh MTk1ODMxLm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9HcmVhdGVy JzoNCi90bXAvY2NhMTk1ODMxLm8oLnRleHQrMHgyYTQ5KTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgc3RyaWNtcCcNCi90bXAvY2NhMTk1ODMxLm86IElu IGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9FcXVhbCc6DQovdG1wL2NjYTE5 NTgzMS5vKC50ZXh0KzB4MmFhOSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YHN0cmljbXAnDQovdXNyL2xpYi9jcnQxLm86IEluIGZ1bmN0aW9uIGBfc3Rh cnQnOg0KL3Vzci9saWIvY3J0MS5vKC50ZXh0KzB4NTcpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBtYWluJw0KL3Vzci9saWIvY3J0MS5vOiBJbiBmdW5j dGlvbiBgX3N0YXJ0JzoNCi91c3IvbGliL2NydDEubygudGV4dCsweDU3KTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgbWFpbicNCi91c3IvbGliL2NydDEu bzogSW4gZnVuY3Rpb24gYF9zdGFydCc6DQovdXNyL2xpYi9jcnQxLm8oLnRl eHQrMHg1Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYG1haW4nDQovdXNy L2xpYi9jcnQxLm86IEluIGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIv Y3J0MS5vKC50ZXh0KzB4NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBt YWluJw0KL3Vzci9saWIvY3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoN Ci91c3IvbGliL2NydDEubygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgbWFpbicNCi91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24g YF9zdGFydCc6DQovdXNyL2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYG1haW4nDQovdXNyL2xpYi9jcnQxLm86IElu IGZ1bmN0aW9uIGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0MS5vKC50ZXh0KzB4 NTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBtYWluJw0KL3Vzci9saWIv Y3J0MS5vOiBJbiBmdW5jdGlvbiBgX3N0YXJ0JzoNCi91c3IvbGliL2NydDEu bygudGV4dCsweDU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgbWFpbicN Ci91c3IvbGliL2NydDEubzogSW4gZnVuY3Rpb24gYF9zdGFydCc6DQovdXNy L2xpYi9jcnQxLm8oLnRleHQrMHg1Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYG1haW4nDQovdG1wL2NjYTE5NjU4MS5vOiBJbiBmdW5jdGlvbiBgSW50 MnBjaGFyJzoNCi90bXAvY2NhMTk2NTgxLm8oLnRleHQrMHhiZDApOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0KL3RtcC9jY2ExOTY1ODEubzog SW4gZnVuY3Rpb24gYE1lbWF2YWlsJzoNCi90bXAvY2NhMTk2NTgxLm8oLnRl eHQrMHgyNGRiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dl dF9mcmVlX21lbW9yeV9pbmZvcm1hdGlvbicNCi90bXAvY2NhMTk2NTgxLm8o LnRleHQrMHgyNGU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1p X2dldF9wYWdlX3NpemUnDQovdG1wL2NjYTE5NjU4MS5vOiBJbiBmdW5jdGlv biBgTWF4YXZhaWwnOg0KL3RtcC9jY2ExOTY1ODEubygudGV4dCsweDI1MGIp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVt b3J5X2luZm9ybWF0aW9uJw0KL3RtcC9jY2ExOTY1ODEubygudGV4dCsweDI1 MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X3BhZ2Vf c2l6ZScNCi90bXAvY2NhMTk2NTgxLm86IEluIGZ1bmN0aW9uIGBTZXRmbW9k ZSc6DQovdG1wL2NjYTE5NjU4MS5vKC50ZXh0KzB4MjUzZSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCi90bXAvY2NhMTk2NTgxLm8oLnRl eHQrMHgyNTUxKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0K L3RtcC9jY2ExOTY1ODEubygudGV4dCsweDI1NjIpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfZm1vZGUnDQovdG1wL2NjYTE5NjU4MS5vOiBJbiBmdW5j dGlvbiBgR2V0Zm1vZGUnOg0KL3RtcC9jY2ExOTY1ODEubygudGV4dCsweDI1 ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQovdG1wL2Nj YTE5NjU4MS5vOiBJbiBmdW5jdGlvbiBgY29uc3RydWN0b3JfMzInOg0KL3Rt cC9jY2ExOTY1ODEubygudGV4dCsweDI5ZTIpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZm1vZGUnDQovdXNyL2xpYi9jcnQxLm86IEluIGZ1bmN0aW9u IGBfc3RhcnQnOg0KL3Vzci9saWIvY3J0MS5vKC50ZXh0KzB4NTcpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBtYWluJw0KZG9zLm86IEluIGZ1bmN0aW9u IGBfcF9maW5kZmlyc3QnOg0KZG9zLm8oLnRleHQrMHg1NmQpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2ZpbmRmaXJzdCcNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3BfZmluZG5leHQnOg0KZG9zLm8oLnRleHQrMHg1ZTEpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2ZpbmRuZXh0Jw0KZG9zLm86 IEluIGZ1bmN0aW9uIGBHZXRjYnJlYWsnOg0KZG9zLm8oLnRleHQrMHg2YTQp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRjYnJrJw0KZG9zLm86IElu IGZ1bmN0aW9uIGBTZXRjYnJlYWsnOg0KZG9zLm8oLnRleHQrMHg2ZDMpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRjYnJrJw0KZG9zLm86IEluIGZ1 bmN0aW9uIGBGaWxlc3BsaXQnOg0KZG9zLm8oLnRleHQrMHhjN2EpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBmbnNwbGl0Jw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBHZXRjdXJkaXInOg0KZG9zLm8oLnRleHQrMHhkMWUpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBnZXRkaXNrJw0KZG9zLm8oLnRleHQrMHhkMmUp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkaXNrJw0KZG9zLm8oLnRl eHQrMHhkM2QpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkaXNrJw0K ZG9zLm8oLnRleHQrMHhkN2QpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBz ZXRkaXNrJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBHZXRkaXInOg0KZG9zLm8o LnRleHQrMHhkY2IpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkaXNr Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBEaXNrZnJlZSc6DQpkb3MubygudGV4 dCsweGVkZik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRmcmVlJw0K ZG9zLm86IEluIGZ1bmN0aW9uIGBEaXNrc2l6ZSc6DQpkb3MubygudGV4dCsw eGYzZik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRmcmVlJw0KZG9z Lm86IEluIGZ1bmN0aW9uIGBfcF9nZXRkYXRlJzoNCmRvcy5vKC50ZXh0KzB4 ZjhiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19nZXRkYXRlJw0K ZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9nZXR0aW1lJzoNCmRvcy5vKC50ZXh0 KzB4ZmNiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19nZXR0aW1l Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRkYXRlJzoNCmRvcy5vKC50 ZXh0KzB4MTAxZik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRhdGUn DQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX3NldHRpbWUnOg0KZG9zLm8oLnRl eHQrMHgxMDUzKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19zZXR0 aW1lJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9nZXRmdGltZSc6DQpkb3Mu bygudGV4dCsweDEwN2UpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRm dGltZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZnRpbWUnOg0KZG9z Lm8oLnRleHQrMHgxMDllKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0 ZnRpbWUnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2dldGZhdHRyJzoNCmRv cy5vKC50ZXh0KzB4MTFlMCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9k b3NfZ2V0ZmlsZWF0dHInDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGZh dHRyJzoNCmRvcy5vKC50ZXh0KzB4MTMzMCk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9kb3Nfc2V0ZmlsZWF0dHInDQpncGN1dGlsLm86IEluIGZ1bmN0 aW9uIGBQYXRobG9jYXRlJzoNCmdwY3V0aWwubygudGV4dCsweDFkMGIpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZWFyY2hwYXRoJw0KZ3BjdXRpbC5v OiBJbiBmdW5jdGlvbiBgSW50MnBjaGFyJzoNCmdwY3V0aWwubygudGV4dCsw eDJiMDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0KZ3BjdXRp bC5vOiBJbiBmdW5jdGlvbiBgQ29weWZpbGUnOg0KZ3BjdXRpbC5vKC50ZXh0 KzB4MmU0Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0K Z3BjdXRpbC5vKC50ZXh0KzB4MzAxOSk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYHNldGZ0aW1lJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgQ29weWZp bGVleCc6DQpncGN1dGlsLm8oLnRleHQrMHgzMjFhKTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpncGN1dGlsLm8oLnRleHQrMHgzNGE5 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZnRpbWUnDQpncGN1dGls Lm86IEluIGZ1bmN0aW9uIGBXcml0ZXBjaGFyJzoNCmdwY3V0aWwubygudGV4 dCsweDM1MGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjcHV0cycNCmdw Y3V0aWwubzogSW4gZnVuY3Rpb24gYFdyaXRlc3RyaW5nJzoNCmdwY3V0aWwu bygudGV4dCsweDM1NDEpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjcHV0 cycNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgSW50MnBjaGFyJzoNCnN5c3Rl bS5vKC50ZXh0KzB4YmQwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgaXRv YScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgTWVtYXZhaWwnOg0Kc3lzdGVt Lm8oLnRleHQrMHgyNGRiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19k cG1pX2dldF9mcmVlX21lbW9yeV9pbmZvcm1hdGlvbicNCnN5c3RlbS5vKC50 ZXh0KzB4MjRlNyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9n ZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBNYXhhdmFp bCc6DQpzeXN0ZW0ubygudGV4dCsweDI1MGIpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0K c3lzdGVtLm8oLnRleHQrMHgyNTE3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rp b24gYFNldGZtb2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjUzZSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vKC50ZXh0KzB4 MjU1MSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3Rl bS5vKC50ZXh0KzB4MjU2Mik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9m bW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgR2V0Zm1vZGUnOg0Kc3lz dGVtLm8oLnRleHQrMHgyNTg3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg X2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBjb25zdHJ1Y3Rvcl8z Mic6DQpzeXN0ZW0ubygudGV4dCsweDI5ZTIpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZm1vZGUnDQovdG1wL2NjYTE5NjY1MS5vOiBJbiBmdW5jdGlv biBgRmlsZW9wZW4nOg0KL3RtcC9jY2ExOTY2NTEubygudGV4dCsweDE0OCk6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9vcGVuJw0KL3RtcC9jY2ExOTY2 NTEubzogSW4gZnVuY3Rpb24gYEZpbGVnZXRhdHRyJzoNCi90bXAvY2NhMTk2 NjUxLm8oLnRleHQrMHgzMjUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf ZG9zX2dldGZpbGVhdHRyJw0KL3RtcC9jY2ExOTY2NTEubzogSW4gZnVuY3Rp b24gYEZpbGVzZXRhdHRyJzoNCi90bXAvY2NhMTk2NjUxLm8oLnRleHQrMHgz NjgpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldGZpbGVhdHRy Jw0KLi90ZXN0LnBhczogSW4gZnVuY3Rpb24gYHByb2dyYW1fVGVzdCc6DQou L3Rlc3QucGFzOjMwOiB3YXJuaW5nOiB1bnVzZWQgdmFyaWFibGUgYFBhdGhz ZXBhcmF0b3InDQouL3Rlc3QucGFzOjMwOiB3YXJuaW5nOiB1bnVzZWQgdmFy aWFibGUgYEZtb2RlJw0KLi90ZXN0LnBhczozMDogd2FybmluZzogdW51c2Vk IHZhcmlhYmxlIGBFcnJvcm51bScNCi4vdGVzdC5wYXM6MzA6IHdhcm5pbmc6 IHVudXNlZCB2YXJpYWJsZSBgSGVhcHB0cicNCi4vdGVzdC5wYXM6MzA6IHdh cm5pbmc6IHVudXNlZCB2YXJpYWJsZSBgSGVhcG9yZycNCi4vdGVzdC5wYXM6 MzA6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSBgSGVhcGVycm9yJw0KLi90 ZXN0LnBhczozMDogd2FybmluZzogdW51c2VkIHZhcmlhYmxlIGBIZWFwZW5k Jw0KLi90ZXN0LnBhczozMDogd2FybmluZzogdW51c2VkIHZhcmlhYmxlIGBG cmVlbGlzdCcNCi4vdGVzdC5wYXM6MzA6IHdhcm5pbmc6IHVudXNlZCB2YXJp YWJsZSBgRXJyb3JhZGRyJw0KLi90ZXN0LnBhczozMDogd2FybmluZzogdW51 c2VkIHZhcmlhYmxlIGBFeGl0Y29kZScNCi4vdGVzdC5wYXM6MzA6IHdhcm5p bmc6IHVudXNlZCB2YXJpYWJsZSBgQ21kbGluZScNCi4vdGVzdC5wYXM6MzA6 IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSBgRmlsZW1vZGUnDQouL3Rlc3Qu cGFzOjMwOiB3YXJuaW5nOiB1bnVzZWQgdmFyaWFibGUgYElub3V0cmVzJw0K Li90ZXN0LnBhczozMDogd2FybmluZzogdW51c2VkIHZhcmlhYmxlIGBFeGl0 cHJvYycNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgSW50MnBjaGFyJzoNCnN5 c3RlbS5vKC50ZXh0KzB4YmQwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg aXRvYScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgTWVtYXZhaWwnOg0Kc3lz dGVtLm8oLnRleHQrMHgyNGRiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg X19kcG1pX2dldF9mcmVlX21lbW9yeV9pbmZvcm1hdGlvbicNCnN5c3RlbS5v KC50ZXh0KzB4MjRlNyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBt aV9nZXRfcGFnZV9zaXplJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBNYXhh dmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI1MGIpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9u Jw0Kc3lzdGVtLm8oLnRleHQrMHgyNTE3KTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0ubzogSW4gZnVu Y3Rpb24gYFNldGZtb2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjUzZSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vKC50ZXh0 KzB4MjU1MSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5 c3RlbS5vKC50ZXh0KzB4MjU2Mik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YF9mbW9kZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgR2V0Zm1vZGUnOg0K c3lzdGVtLm8oLnRleHQrMHgyNTg3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBjb25zdHJ1Y3Rv cl8zMic6DQpzeXN0ZW0ubygudGV4dCsweDI5ZTIpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfZm1vZGUnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2Zp bmRmaXJzdCc6DQpkb3MubygudGV4dCsweDU2ZCk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9kb3NfZmluZGZpcnN0Jw0KZG9zLm86IEluIGZ1bmN0aW9u IGBfcF9maW5kbmV4dCc6DQpkb3MubygudGV4dCsweDVlMSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQpkb3MubzogSW4gZnVu Y3Rpb24gYEdldGNicmVhayc6DQpkb3MubygudGV4dCsweDZhNCk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYGdldGNicmsnDQpkb3MubzogSW4gZnVuY3Rp b24gYFNldGNicmVhayc6DQpkb3MubygudGV4dCsweDZkMyk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYHNldGNicmsnDQpkb3MubzogSW4gZnVuY3Rpb24g YEZpbGVzcGxpdCc6DQpkb3MubygudGV4dCsweGM3YSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGZuc3BsaXQnDQpkb3MubzogSW4gZnVuY3Rpb24gYEdl dGN1cmRpcic6DQpkb3MubygudGV4dCsweGQxZSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQyZSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQz ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3Mubygu dGV4dCsweGQ3ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2sn DQpkb3MubzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQpkb3MubygudGV4dCsw eGRjYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3Mu bzogSW4gZnVuY3Rpb24gYERpc2tmcmVlJzoNCmRvcy5vKC50ZXh0KzB4ZWRm KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYERpc2tzaXplJzoNCmRvcy5vKC50ZXh0KzB4ZjNmKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX2dldGRhdGUnOg0KZG9zLm8oLnRleHQrMHhmOGIpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRhdGUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX2dldHRpbWUnOg0KZG9zLm8oLnRleHQrMHhmY2Ip OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldHRpbWUnDQpkb3Mu bzogSW4gZnVuY3Rpb24gYF9wX3NldGRhdGUnOg0KZG9zLm8oLnRleHQrMHgx MDFmKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGF0ZScNCmRvcy5v OiBJbiBmdW5jdGlvbiBgX3Bfc2V0dGltZSc6DQpkb3MubygudGV4dCsweDEw NTMpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldHRpbWUnDQpk b3MubzogSW4gZnVuY3Rpb24gYF9wX2dldGZ0aW1lJzoNCmRvcy5vKC50ZXh0 KzB4MTA3ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0K ZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmdGltZSc6DQpkb3MubygudGV4 dCsweDEwOWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScN CmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZmF0dHInOg0KZG9zLm8oLnRl eHQrMHgxMWUwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19nZXRm aWxlYXR0cicNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZmF0dHInOg0K ZG9zLm8oLnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg X2Rvc19zZXRmaWxlYXR0cicNCi90bXAvY2NhMTk3MTkxLm86IEluIGZ1bmN0 aW9uIGBwcm9ncmFtX1Rlc3QnOg0KL3RtcC9jY2ExOTcxOTEubygudGV4dCsw eDU0Yik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHN0cnVwcicNCi90bXAv Y2NhMTk3MTkxLm8oLnRleHQrMHg1YmYpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBzdHJsd3InDQpvYmplY3RzLm8oLmRhdGErMHgwKTogbXVsdGlwbGUg ZGVmaW5pdGlvbiBvZiBgdm10X1RvYmplY3QnDQouL29iamVjdHMubyguZGF0 YSsweDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVu Y3Rpb24gYFRvYmplY3RfRnJlZSc6DQpvYmplY3RzLm8oLnRleHQrMHg3NDAp OiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUb2JqZWN0X0ZyZWUnDQouL29i amVjdHMubygudGV4dCsweDc0MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2Jq ZWN0cy5vOiBJbiBmdW5jdGlvbiBgVG9iamVjdF9Eb25lJzoNCm9iamVjdHMu bygudGV4dCsweDY4MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRvYmpl Y3RfRG9uZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4NjgwKTogZmlyc3QgZGVm aW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUb2JqZWN0X0Rl c3Ryb3knOg0Kb2JqZWN0cy5vKC50ZXh0KzB4NmUwKTogbXVsdGlwbGUgZGVm aW5pdGlvbiBvZiBgVG9iamVjdF9EZXN0cm95Jw0KLi9vYmplY3RzLm8oLnRl eHQrMHg2ZTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubyguZGF0 YSsweDE0KTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgdm10X1RzdHJlYW0n DQouL29iamVjdHMubyguZGF0YSsweDE0KTogZmlyc3QgZGVmaW5lZCBoZXJl DQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyZWFtX1B1dCc6DQpvYmpl Y3RzLm8oLnRleHQrMHg3YzApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBU c3RyZWFtX1B1dCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4N2MwKTogZmlyc3Qg ZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyZWFt X0dldCc6DQpvYmplY3RzLm8oLnRleHQrMHg4MzApOiBtdWx0aXBsZSBkZWZp bml0aW9uIG9mIGBUc3RyZWFtX0dldCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4 ODMwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0 aW9uIGBUc3RyZWFtX0dldHNpemUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4OGQw KTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVHN0cmVhbV9HZXRzaXplJw0K Li9vYmplY3RzLm8oLnRleHQrMHg4ZDApOiBmaXJzdCBkZWZpbmVkIGhlcmUN Cm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJlYW1fR2V0cG9zJzoNCm9i amVjdHMubygudGV4dCsweDhmMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2Yg YFRzdHJlYW1fR2V0cG9zJw0KLi9vYmplY3RzLm8oLnRleHQrMHg4ZjApOiBm aXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRz dHJlYW1fRXJyb3InOg0Kb2JqZWN0cy5vKC50ZXh0KzB4OTEwKTogbXVsdGlw bGUgZGVmaW5pdGlvbiBvZiBgVHN0cmVhbV9FcnJvcicNCi4vb2JqZWN0cy5v KC50ZXh0KzB4OTEwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86 IEluIGZ1bmN0aW9uIGBUc3RyZWFtX0ZsdXNoJzoNCm9iamVjdHMubygudGV4 dCsweDk0MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJlYW1fRmx1 c2gnDQouL29iamVjdHMubygudGV4dCsweDk0MCk6IGZpcnN0IGRlZmluZWQg aGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmVhbV9SZWFkJzoN Cm9iamVjdHMubygudGV4dCsweDk1MCk6IG11bHRpcGxlIGRlZmluaXRpb24g b2YgYFRzdHJlYW1fUmVhZCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4OTUwKTog Zmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBU c3RyZWFtX1dyaXRlJzoNCm9iamVjdHMubygudGV4dCsweDk3MCk6IG11bHRp cGxlIGRlZmluaXRpb24gb2YgYFRzdHJlYW1fV3JpdGUnDQouL29iamVjdHMu bygudGV4dCsweDk3MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5v OiBJbiBmdW5jdGlvbiBgVHN0cmVhbV9SZXNldCc6DQpvYmplY3RzLm8oLnRl eHQrMHg5OTApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUc3RyZWFtX1Jl c2V0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHg5OTApOiBmaXJzdCBkZWZpbmVk IGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJlYW1fU2Vlayc6 DQpvYmplY3RzLm8oLnRleHQrMHg5YzApOiBtdWx0aXBsZSBkZWZpbml0aW9u IG9mIGBUc3RyZWFtX1NlZWsnDQouL29iamVjdHMubygudGV4dCsweDljMCk6 IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBg VHN0cmVhbV9UcnVuY2F0ZSc6DQpvYmplY3RzLm8oLnRleHQrMHg5ZDApOiBt dWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUc3RyZWFtX1RydW5jYXRlJw0KLi9v YmplY3RzLm8oLnRleHQrMHg5ZDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9i amVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJlYW1fU3RycmVhZCc6DQpvYmpl Y3RzLm8oLnRleHQrMHg5ZTApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBU c3RyZWFtX1N0cnJlYWQnDQouL29iamVjdHMubygudGV4dCsweDllMCk6IGZp cnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0 cmVhbV9TdHJ3cml0ZSc6DQpvYmplY3RzLm8oLnRleHQrMHhhODApOiBtdWx0 aXBsZSBkZWZpbml0aW9uIG9mIGBUc3RyZWFtX1N0cndyaXRlJw0KLi9vYmpl Y3RzLm8oLnRleHQrMHhhODApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVj dHMubzogSW4gZnVuY3Rpb24gYFRzdHJlYW1fUmVhZHN0cic6DQpvYmplY3Rz Lm8oLnRleHQrMHhhZjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUc3Ry ZWFtX1JlYWRzdHInDQouL29iamVjdHMubygudGV4dCsweGFmMCk6IGZpcnN0 IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmVh bV9Xcml0ZXN0cic6DQpvYmplY3RzLm8oLnRleHQrMHhiODApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBUc3RyZWFtX1dyaXRlc3RyJw0KLi9vYmplY3Rz Lm8oLnRleHQrMHhiODApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYFRzdHJlYW1fQ29weWZyb20nOg0Kb2JqZWN0cy5v KC50ZXh0KzB4YzIwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVHN0cmVh bV9Db3B5ZnJvbScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4YzIwKTogZmlyc3Qg ZGVmaW5lZCBoZXJlDQpvYmplY3RzLm8oLmRhdGErMHg2OCk6IG11bHRpcGxl IGRlZmluaXRpb24gb2YgYHZtdF9UZG9zc3RyZWFtJw0KLi9vYmplY3RzLm8o LmRhdGErMHg2OCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGRvc3N0cmVhbV9Eb25lJzoNCm9iamVjdHMubygudGV4 dCsweGQ3MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRkb3NzdHJlYW1f RG9uZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4ZDcwKTogZmlyc3QgZGVmaW5l ZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUZG9zc3RyZWFtX0dl dHNpemUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4ZTgwKTogbXVsdGlwbGUgZGVm aW5pdGlvbiBvZiBgVGRvc3N0cmVhbV9HZXRzaXplJw0KLi9vYmplY3RzLm8o LnRleHQrMHhlODApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzog SW4gZnVuY3Rpb24gYFRkb3NzdHJlYW1fR2V0cG9zJzoNCm9iamVjdHMubygu dGV4dCsweGRiMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRkb3NzdHJl YW1fR2V0cG9zJw0KLi9vYmplY3RzLm8oLnRleHQrMHhkYjApOiBmaXJzdCBk ZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRkb3NzdHJl YW1fUmVhZCc6DQpvYmplY3RzLm8oLnRleHQrMHhmNTApOiBtdWx0aXBsZSBk ZWZpbml0aW9uIG9mIGBUZG9zc3RyZWFtX1JlYWQnDQouL29iamVjdHMubygu dGV4dCsweGY1MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGRvc3N0cmVhbV9Xcml0ZSc6DQpvYmplY3RzLm8oLnRl eHQrMHhmYjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUZG9zc3RyZWFt X1dyaXRlJw0KLi9vYmplY3RzLm8oLnRleHQrMHhmYjApOiBmaXJzdCBkZWZp bmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRkb3NzdHJlYW1f U2Vlayc6DQpvYmplY3RzLm8oLnRleHQrMHgxMDIwKTogbXVsdGlwbGUgZGVm aW5pdGlvbiBvZiBgVGRvc3N0cmVhbV9TZWVrJw0KLi9vYmplY3RzLm8oLnRl eHQrMHgxMDIwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IElu IGZ1bmN0aW9uIGBUZG9zc3RyZWFtX1RydW5jYXRlJzoNCm9iamVjdHMubygu dGV4dCsweDEwNzApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUZG9zc3Ry ZWFtX1RydW5jYXRlJw0KLi9vYmplY3RzLm8oLnRleHQrMHgxMDcwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm8oLmRhdGErMHhiYyk6IG11bHRp cGxlIGRlZmluaXRpb24gb2YgYHZtdF9UYnVmc3RyZWFtJw0KLi9vYmplY3Rz Lm8oLmRhdGErMHhiYyk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5v OiBJbiBmdW5jdGlvbiBgVGJ1ZnN0cmVhbV9Eb25lJzoNCm9iamVjdHMubygu dGV4dCsweDExYTApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUYnVmc3Ry ZWFtX0RvbmUnDQouL29iamVjdHMubygudGV4dCsweDExYTApOiBmaXJzdCBk ZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRidWZzdHJl YW1fR2V0c2l6ZSc6DQpvYmplY3RzLm8oLnRleHQrMHgxMjMwKTogbXVsdGlw bGUgZGVmaW5pdGlvbiBvZiBgVGJ1ZnN0cmVhbV9HZXRzaXplJw0KLi9vYmpl Y3RzLm8oLnRleHQrMHgxMjMwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmpl Y3RzLm86IEluIGZ1bmN0aW9uIGBUYnVmc3RyZWFtX0dldHBvcyc6DQpvYmpl Y3RzLm8oLnRleHQrMHgxMWYwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBg VGJ1ZnN0cmVhbV9HZXRwb3MnDQouL29iamVjdHMubygudGV4dCsweDExZjAp OiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24g YFRidWZzdHJlYW1fUmVhZCc6DQpvYmplY3RzLm8oLnRleHQrMHgxMjcwKTog bXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGJ1ZnN0cmVhbV9SZWFkJw0KLi9v YmplY3RzLm8oLnRleHQrMHgxMjcwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpv YmplY3RzLm86IEluIGZ1bmN0aW9uIGBUYnVmc3RyZWFtX1dyaXRlJzoNCm9i amVjdHMubygudGV4dCsweDEyYTApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9m IGBUYnVmc3RyZWFtX1dyaXRlJw0KLi9vYmplY3RzLm8oLnRleHQrMHgxMmEw KTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9u IGBUYnVmc3RyZWFtX1NlZWsnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MTJkMCk6 IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRidWZzdHJlYW1fU2VlaycNCi4v b2JqZWN0cy5vKC50ZXh0KzB4MTJkMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0K b2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGJ1ZnN0cmVhbV9UcnVuY2F0ZSc6 DQpvYmplY3RzLm8oLnRleHQrMHgxMzAwKTogbXVsdGlwbGUgZGVmaW5pdGlv biBvZiBgVGJ1ZnN0cmVhbV9UcnVuY2F0ZScNCi4vb2JqZWN0cy5vKC50ZXh0 KzB4MTMwMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vKC5kYXRh KzB4MTEwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgdm10X1Rjb2xsZWN0 aW9uJw0KLi9vYmplY3RzLm8oLmRhdGErMHgxMTApOiBmaXJzdCBkZWZpbmVk IGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0Rv bmUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MTgyMCk6IG11bHRpcGxlIGRlZmlu aXRpb24gb2YgYFRjb2xsZWN0aW9uX0RvbmUnDQouL29iamVjdHMubygudGV4 dCsweDE4MjApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4g ZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0Rlc3Ryb3knOg0Kb2JqZWN0cy5vKC50 ZXh0KzB4MTdlMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0 aW9uX0Rlc3Ryb3knDQouL29iamVjdHMubygudGV4dCsweDE3ZTApOiBmaXJz dCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xs ZWN0aW9uX0NvdW50JzoNCm9iamVjdHMubygudGV4dCsweDE4NjApOiBtdWx0 aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9Db3VudCcNCi4vb2Jq ZWN0cy5vKC50ZXh0KzB4MTg2MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2Jq ZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fSW5zZXJ0JzoNCm9i amVjdHMubygudGV4dCsweDE5NTApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9m IGBUY29sbGVjdGlvbl9JbnNlcnQnDQouL29iamVjdHMubygudGV4dCsweDE5 NTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rp b24gYFRjb2xsZWN0aW9uX0F0ZGVsZXRlJzoNCm9iamVjdHMubygudGV4dCsw eDFmZjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9B dGRlbGV0ZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MWZmMCk6IGZpcnN0IGRl ZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rp b25fQXRmcmVlJzoNCm9iamVjdHMubygudGV4dCsweDIwODApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9BdGZyZWUnDQouL29iamVj dHMubygudGV4dCsweDIwODApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVj dHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0RlbGV0ZSc6DQpvYmpl Y3RzLm8oLnRleHQrMHgyM2IwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBg VGNvbGxlY3Rpb25fRGVsZXRlJw0KLi9vYmplY3RzLm8oLnRleHQrMHgyM2Iw KTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9u IGBUY29sbGVjdGlvbl9GcmVlbWUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MjQw MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0aW9uX0ZyZWVt ZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MjQwMCk6IGZpcnN0IGRlZmluZWQg aGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fRGVs ZXRlYWxsJzoNCm9iamVjdHMubygudGV4dCsweDI1MDApOiBtdWx0aXBsZSBk ZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9EZWxldGVhbGwnDQouL29iamVj dHMubygudGV4dCsweDI1MDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVj dHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0NsZWFyJzoNCm9iamVj dHMubygudGV4dCsweDI1NzApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBU Y29sbGVjdGlvbl9DbGVhcicNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MjU3MCk6 IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBg VGNvbGxlY3Rpb25fUmVtb3ZlaXRlbSc6DQpvYmplY3RzLm8oLnRleHQrMHgx ZGYwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGNvbGxlY3Rpb25fUmVt b3ZlaXRlbScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MWRmMCk6IGZpcnN0IGRl ZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rp b25fSW5kZXhvZic6DQpvYmplY3RzLm8oLnRleHQrMHgyNDQwKTogbXVsdGlw bGUgZGVmaW5pdGlvbiBvZiBgVGNvbGxlY3Rpb25fSW5kZXhvZicNCi4vb2Jq ZWN0cy5vKC50ZXh0KzB4MjQ0MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2Jq ZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fQXRpbnNlcnQnOg0K b2JqZWN0cy5vKC50ZXh0KzB4MWExMCk6IG11bHRpcGxlIGRlZmluaXRpb24g b2YgYFRjb2xsZWN0aW9uX0F0aW5zZXJ0Jw0KLi9vYmplY3RzLm8oLnRleHQr MHgxYTEwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1 bmN0aW9uIGBUY29sbGVjdGlvbl9BdCc6DQpvYmplY3RzLm8oLnRleHQrMHgx YTkwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGNvbGxlY3Rpb25fQXQn DQouL29iamVjdHMubygudGV4dCsweDFhOTApOiBmaXJzdCBkZWZpbmVkIGhl cmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX1NlYXJj aCc6DQpvYmplY3RzLm8oLnRleHQrMHgyMGMwKTogbXVsdGlwbGUgZGVmaW5p dGlvbiBvZiBgVGNvbGxlY3Rpb25fU2VhcmNoJw0KLi9vYmplY3RzLm8oLnRl eHQrMHgyMGMwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IElu IGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9MZXNzJzoNCm9iamVjdHMubygudGV4 dCsweDFhZjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlv bl9MZXNzJw0KLi9vYmplY3RzLm8oLnRleHQrMHgxYWYwKTogZmlyc3QgZGVm aW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlv bl9HcmVhdGVyJzoNCm9iamVjdHMubygudGV4dCsweDFiMjApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9HcmVhdGVyJw0KLi9vYmpl Y3RzLm8oLnRleHQrMHgxYjIwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmpl Y3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9FcXVhbCc6DQpvYmpl Y3RzLm8oLnRleHQrMHgxYjUwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBg VGNvbGxlY3Rpb25fRXF1YWwnDQouL29iamVjdHMubygudGV4dCsweDFiNTAp OiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24g YFRjb2xsZWN0aW9uX0NvbXBhcmUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MWI4 MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0aW9uX0NvbXBh cmUnDQouL29iamVjdHMubygudGV4dCsweDFiODApOiBmaXJzdCBkZWZpbmVk IGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX051 bGxpZnknOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MWU2MCk6IG11bHRpcGxlIGRl ZmluaXRpb24gb2YgYFRjb2xsZWN0aW9uX051bGxpZnknDQouL29iamVjdHMu bygudGV4dCsweDFlNjApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX1NvcnRhbGwnOg0Kb2JqZWN0 cy5vKC50ZXh0KzB4MjExMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRj b2xsZWN0aW9uX1NvcnRhbGwnDQouL29iamVjdHMubygudGV4dCsweDIxMTAp OiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24g YFRjb2xsZWN0aW9uX1NvcnQnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MjE0MCk6 IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0aW9uX1NvcnQnDQou L29iamVjdHMubygudGV4dCsweDIxNDApOiBmaXJzdCBkZWZpbmVkIGhlcmUN Cm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0F0Y2hhbmdl JzoNCm9iamVjdHMubygudGV4dCsweDFmODApOiBtdWx0aXBsZSBkZWZpbml0 aW9uIG9mIGBUY29sbGVjdGlvbl9BdGNoYW5nZScNCi4vb2JqZWN0cy5vKC50 ZXh0KzB4MWY4MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fQXRwdXQnOg0Kb2JqZWN0cy5vKC50 ZXh0KzB4MWVkMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0 aW9uX0F0cHV0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgxZWQwKTogZmlyc3Qg ZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVj dGlvbl9Gb3JlYWNoJzoNCm9iamVjdHMubygudGV4dCsweDIxNzApOiBtdWx0 aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9Gb3JlYWNoJw0KLi9v YmplY3RzLm8oLnRleHQrMHgyMTcwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpv YmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9GaXJzdHRoYXQn Og0Kb2JqZWN0cy5vKC50ZXh0KzB4MjIxMCk6IG11bHRpcGxlIGRlZmluaXRp b24gb2YgYFRjb2xsZWN0aW9uX0ZpcnN0dGhhdCcNCi4vb2JqZWN0cy5vKC50 ZXh0KzB4MjIxMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fTGFzdHRoYXQnOg0Kb2JqZWN0cy5v KC50ZXh0KzB4MjJlMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xs ZWN0aW9uX0xhc3R0aGF0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgyMmUwKTog Zmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBU Y29sbGVjdGlvbl9TZXRsaW1pdCc6DQpvYmplY3RzLm8oLnRleHQrMHgyNjEw KTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGNvbGxlY3Rpb25fU2V0bGlt aXQnDQouL29iamVjdHMubygudGV4dCsweDI2MTApOiBmaXJzdCBkZWZpbmVk IGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0Vy cm9yJzoNCm9iamVjdHMubygudGV4dCsweDI1ZDApOiBtdWx0aXBsZSBkZWZp bml0aW9uIG9mIGBUY29sbGVjdGlvbl9FcnJvcicNCi4vb2JqZWN0cy5vKC50 ZXh0KzB4MjVkMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fRnJlZWl0ZW0nOg0Kb2JqZWN0cy5v KC50ZXh0KzB4MjZiMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xs ZWN0aW9uX0ZyZWVpdGVtJw0KLi9vYmplY3RzLm8oLnRleHQrMHgyNmIwKTog Zmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBU Y29sbGVjdGlvbl9HZXRpdGVtJzoNCm9iamVjdHMubygudGV4dCsweDI2ZjAp OiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9HZXRpdGVt Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgyNmYwKTogZmlyc3QgZGVmaW5lZCBo ZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9QdXRp dGVtJzoNCm9iamVjdHMubygudGV4dCsweDI3MjApOiBtdWx0aXBsZSBkZWZp bml0aW9uIG9mIGBUY29sbGVjdGlvbl9QdXRpdGVtJw0KLi9vYmplY3RzLm8o LnRleHQrMHgyNzIwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm8o LmRhdGErMHgxOWMpOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGB2bXRfVHNv cnRlZGNvbGxlY3Rpb24nDQouL29iamVjdHMubyguZGF0YSsweDE5Yyk6IGZp cnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vKC5kYXRhKzB4MjI4KTogbXVs dGlwbGUgZGVmaW5pdGlvbiBvZiBgdm10X1RzdHJjb2xsZWN0aW9uJw0KLi9v YmplY3RzLm8oLmRhdGErMHgyMjgpOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9i amVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX0RvbmUnOg0K b2JqZWN0cy5vKC50ZXh0KzB4MmYxMCk6IG11bHRpcGxlIGRlZmluaXRpb24g b2YgYFRzdHJjb2xsZWN0aW9uX0RvbmUnDQouL29iamVjdHMubygudGV4dCsw eDJmMTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVu Y3Rpb24gYFRzdHJjb2xsZWN0aW9uX0Rlc3Ryb3knOg0Kb2JqZWN0cy5vKC50 ZXh0KzB4MmVhMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xs ZWN0aW9uX0Rlc3Ryb3knDQouL29iamVjdHMubygudGV4dCsweDJlYTApOiBm aXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRz dHJjb2xsZWN0aW9uX1JlbW92ZWl0ZW0nOg0Kb2JqZWN0cy5vKC50ZXh0KzB4 MmUzMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xsZWN0aW9u X1JlbW92ZWl0ZW0nDQouL29iamVjdHMubygudGV4dCsweDJlMzApOiBmaXJz dCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJj b2xsZWN0aW9uX0xlc3MnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MjliMCk6IG11 bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xsZWN0aW9uX0xlc3MnDQou L29iamVjdHMubygudGV4dCsweDI5YjApOiBmaXJzdCBkZWZpbmVkIGhlcmUN Cm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX0dyZWF0 ZXInOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MmExMCk6IG11bHRpcGxlIGRlZmlu aXRpb24gb2YgYFRzdHJjb2xsZWN0aW9uX0dyZWF0ZXInDQouL29iamVjdHMu bygudGV4dCsweDJhMTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX0VxdWFsJzoNCm9iamVj dHMubygudGV4dCsweDJhNzApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBU c3RyY29sbGVjdGlvbl9FcXVhbCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MmE3 MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlv biBgVHN0cmNvbGxlY3Rpb25fRnJlZWl0ZW0nOg0Kb2JqZWN0cy5vKC50ZXh0 KzB4MmY4MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xsZWN0 aW9uX0ZyZWVpdGVtJw0KLi9vYmplY3RzLm8oLnRleHQrMHgyZjgwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3Ry Y29sbGVjdGlvbl9HZXRpdGVtJzoNCm9iamVjdHMubygudGV4dCsweDJmYTAp OiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUc3RyY29sbGVjdGlvbl9HZXRp dGVtJw0KLi9vYmplY3RzLm8oLnRleHQrMHgyZmEwKTogZmlyc3QgZGVmaW5l ZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlv bl9QdXRpdGVtJzoNCm9iamVjdHMubygudGV4dCsweDJmZDApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBUc3RyY29sbGVjdGlvbl9QdXRpdGVtJw0KLi9v YmplY3RzLm8oLnRleHQrMHgyZmQwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpv YmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9BZGQnOg0K b2JqZWN0cy5vKC50ZXh0KzB4MmNhMCk6IG11bHRpcGxlIGRlZmluaXRpb24g b2YgYFRzdHJjb2xsZWN0aW9uX0FkZCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4 MmNhMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5j dGlvbiBgVHN0cmNvbGxlY3Rpb25fUmVwbGFjZSc6DQpvYmplY3RzLm8oLnRl eHQrMHgyYWQwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVHN0cmNvbGxl Y3Rpb25fUmVwbGFjZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MmFkMCk6IGZp cnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0 cmNvbGxlY3Rpb25fQWRkcGNoYXInOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MmRk MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xsZWN0aW9uX0Fk ZHBjaGFyJw0KLi9vYmplY3RzLm8oLnRleHQrMHgyZGQwKTogZmlyc3QgZGVm aW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVj dGlvbl9SZXBsYWNlcGNoYXInOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MmMxMCk6 IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzdHJjb2xsZWN0aW9uX1JlcGxh Y2VwY2hhcicNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MmMxMCk6IGZpcnN0IGRl ZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmNvbGxl Y3Rpb25fU3RyaW5ncyc6DQpvYmplY3RzLm8oLnRleHQrMHgzMDAwKTogbXVs dGlwbGUgZGVmaW5pdGlvbiBvZiBgVHN0cmNvbGxlY3Rpb25fU3RyaW5ncycN Ci4vb2JqZWN0cy5vKC50ZXh0KzB4MzAwMCk6IGZpcnN0IGRlZmluZWQgaGVy ZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmNvbGxlY3Rpb25fUGNo YXJzJzoNCm9iamVjdHMubygudGV4dCsweDMxMDApOiBtdWx0aXBsZSBkZWZp bml0aW9uIG9mIGBUc3RyY29sbGVjdGlvbl9QY2hhcnMnDQouL29iamVjdHMu bygudGV4dCsweDMxMDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX1JlYWRmcm9tZmlsZSc6 DQpvYmplY3RzLm8oLnRleHQrMHgzMTkwKTogbXVsdGlwbGUgZGVmaW5pdGlv biBvZiBgVHN0cmNvbGxlY3Rpb25fUmVhZGZyb21maWxlJw0KLi9vYmplY3Rz Lm8oLnRleHQrMHgzMTkwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3Rz Lm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9Xcml0ZXRvZmlsZSc6 DQpvYmplY3RzLm8oLnRleHQrMHgzM2EwKTogbXVsdGlwbGUgZGVmaW5pdGlv biBvZiBgVHN0cmNvbGxlY3Rpb25fV3JpdGV0b2ZpbGUnDQouL29iamVjdHMu bygudGV4dCsweDMzYTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYEFic3RyYWN0JzoNCm9iamVjdHMubygudGV4dCsw eDApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBBYnN0cmFjdCcNCi4vb2Jq ZWN0cy5vKC50ZXh0KzB4MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0 cy5vOiBJbiBmdW5jdGlvbiBgVG9iamVjdF9DcmVhdGUnOg0Kb2JqZWN0cy5v KC50ZXh0KzB4NWQwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVG9iamVj dF9DcmVhdGUnDQouL29iamVjdHMubygudGV4dCsweDVkMCk6IGZpcnN0IGRl ZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgSW5zdGFuY2Vm cm9taGFuZGxlJzoNCm9iamVjdHMubygudGV4dCsweDRiMCk6IG11bHRpcGxl IGRlZmluaXRpb24gb2YgYEluc3RhbmNlZnJvbWhhbmRsZScNCi4vb2JqZWN0 cy5vKC50ZXh0KzB4NGIwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3Rz Lm86IEluIGZ1bmN0aW9uIGBJbnN0YW5jZWZyb21zZWxmaWQnOg0Kb2JqZWN0 cy5vKC50ZXh0KzB4NGUwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgSW5z dGFuY2Vmcm9tc2VsZmlkJw0KLi9vYmplY3RzLm8oLnRleHQrMHg0ZTApOiBm aXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRv YmplY3RfTG9hZCc6DQpvYmplY3RzLm8oLnRleHQrMHg1MTApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBUb2JqZWN0X0xvYWQnDQouL29iamVjdHMubygu dGV4dCsweDUxMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVG9iamVjdF9Jbml0JzoNCm9iamVjdHMubygudGV4dCsw eDUyMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRvYmplY3RfSW5pdCcN Ci4vb2JqZWN0cy5vKC50ZXh0KzB4NTIwKTogZmlyc3QgZGVmaW5lZCBoZXJl DQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUZG9zc3RyZWFtX0luaXQnOg0K b2JqZWN0cy5vKC50ZXh0KzB4Y2EwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBv ZiBgVGRvc3N0cmVhbV9Jbml0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHhjYTAp OiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24g YFRidWZzdHJlYW1fSW5pdCc6DQpvYmplY3RzLm8oLnRleHQrMHgxMTEwKTog bXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGJ1ZnN0cmVhbV9Jbml0Jw0KLi9v YmplY3RzLm8oLnRleHQrMHgxMTEwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpv YmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9Jbml0JzoNCm9i amVjdHMubygudGV4dCsweDE2MDApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9m IGBUY29sbGVjdGlvbl9Jbml0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgxNjAw KTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9u IGBUY29sbGVjdGlvbl9NdWx0aSc6DQpvYmplY3RzLm8oLnRleHQrMHgxODgw KTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGNvbGxlY3Rpb25fTXVsdGkn DQouL29iamVjdHMubygudGV4dCsweDE4ODApOiBmaXJzdCBkZWZpbmVkIGhl cmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRjb2xsZWN0aW9uX0NyZWF0 ZSc6DQpvYmplY3RzLm8oLnRleHQrMHgxNmYwKTogbXVsdGlwbGUgZGVmaW5p dGlvbiBvZiBgVGNvbGxlY3Rpb25fQ3JlYXRlJw0KLi9vYmplY3RzLm8oLnRl eHQrMHgxNmYwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IElu IGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9VbnNhZmV0b3Byb2NlZWQnOg0Kb2Jq ZWN0cy5vKC50ZXh0KzB4MThjMCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2Yg YFRjb2xsZWN0aW9uX1Vuc2FmZXRvcHJvY2VlZCcNCi4vb2JqZWN0cy5vKC50 ZXh0KzB4MThjMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJ biBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fUHVsbHVwbGlzdCc6DQpvYmplY3Rz Lm8oLnRleHQrMHgxYzMwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgVGNv bGxlY3Rpb25fUHVsbHVwbGlzdCcNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MWMz MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlv biBgVGNvbGxlY3Rpb25fUHVzaGRvd25saXN0JzoNCm9iamVjdHMubygudGV4 dCsweDFkMjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlv bl9QdXNoZG93bmxpc3QnDQouL29iamVjdHMubygudGV4dCsweDFkMjApOiBm aXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRj b2xsZWN0aW9uX0xpbWl0JzoNCm9iamVjdHMubygudGV4dCsweDI1YTApOiBt dWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUY29sbGVjdGlvbl9MaW1pdCcNCi4v b2JqZWN0cy5vKC50ZXh0KzB4MjVhMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0K b2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVGNvbGxlY3Rpb25fUGFjayc6DQpv YmplY3RzLm8oLnRleHQrMHgyNWMwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBv ZiBgVGNvbGxlY3Rpb25fUGFjaycNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MjVj MCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlv biBgVGNvbGxlY3Rpb25fU3RvcmUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4Mjc1 MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRjb2xsZWN0aW9uX1N0b3Jl Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgyNzUwKTogZmlyc3QgZGVmaW5lZCBo ZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUY29sbGVjdGlvbl9Mb2Fk JzoNCm9iamVjdHMubygudGV4dCsweDI3ZjApOiBtdWx0aXBsZSBkZWZpbml0 aW9uIG9mIGBUY29sbGVjdGlvbl9Mb2FkJw0KLi9vYmplY3RzLm8oLnRleHQr MHgyN2YwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1 bmN0aW9uIGBUc29ydGVkY29sbGVjdGlvbl9Jbml0JzoNCm9iamVjdHMubygu dGV4dCsweDI4ZjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBUc29ydGVk Y29sbGVjdGlvbl9Jbml0Jw0KLi9vYmplY3RzLm8oLnRleHQrMHgyOGYwKTog Zmlyc3QgZGVmaW5lZCBoZXJlDQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBU c29ydGVkY29sbGVjdGlvbl9DcmVhdGUnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4 Mjk1MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYFRzb3J0ZWRjb2xsZWN0 aW9uX0NyZWF0ZScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4Mjk1MCk6IGZpcnN0 IGRlZmluZWQgaGVyZQ0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgY29uc3Ry dWN0b3JfMTU0JzoNCm9iamVjdHMubygudGV4dCsweDM1MTApOiBtdWx0aXBs ZSBkZWZpbml0aW9uIG9mIGBjb25zdHJ1Y3Rvcl8xNTQnDQouL29iamVjdHMu bygudGV4dCsweDM1MTApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCm9iamVjdHMu bzogSW4gZnVuY3Rpb24gYGRlc3RydWN0b3JfMTU1JzoNCm9iamVjdHMubygu dGV4dCsweDM1NzApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBkZXN0cnVj dG9yXzE1NScNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MzU3MCk6IGZpcnN0IGRl ZmluZWQgaGVyZQ0KLi9vYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyY29s bGVjdGlvbl9MZXNzJzoNCi4vb2JqZWN0cy5vKC50ZXh0KzB4MjllOSk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYHN0cmljbXAnDQouL29iamVjdHMubzog SW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX0dyZWF0ZXInOg0KLi9vYmpl Y3RzLm8oLnRleHQrMHgyYTQ5KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg c3RyaWNtcCcNCi4vb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmNvbGxl Y3Rpb25fRXF1YWwnOg0KLi9vYmplY3RzLm8oLnRleHQrMHgyYWE5KTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgc3RyaWNtcCcNCm9iamVjdHMubzogSW4g ZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9uX0xlc3MnOg0Kb2JqZWN0cy5vKC50 ZXh0KzB4MjllOSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHN0cmljbXAn DQpvYmplY3RzLm86IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9HcmVh dGVyJzoNCm9iamVjdHMubygudGV4dCsweDJhNDkpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBzdHJpY21wJw0Kb2JqZWN0cy5vKC50ZXh0KzB4MmFhOSk6 IG1vcmUgdW5kZWZpbmVkIHJlZmVyZW5jZXMgdG8gYHN0cmljbXAnIGZvbGxv dw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVt Lm8oLnRleHQrMHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9h Jw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0u bygudGV4dCsweDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2Rw bWlfZ2V0X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRl eHQrMHgyNGU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dl dF9wYWdlX3NpemUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWls JzoNCnN5c3RlbS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpz eXN0ZW0ubygudGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlv biBgU2V0Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgy NTUxKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVt Lm8oLnRleHQrMHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Zt b2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0 ZW0ubygudGV4dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf Zm1vZGUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMy JzoNCnN5c3RlbS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9mbW9kZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgTm9zb3VuZCc6 DQpjcnQubygudGV4dCsweDE2KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg c291bmQnDQpjcnQubzogSW4gZnVuY3Rpb24gYEJsb2NrY3Vyc29yJzoNCmNy dC5vKC50ZXh0KzB4MzYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfc2V0 Y3Vyc29ydHlwZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgRmF0Y3Vyc29yJzoN CmNydC5vKC50ZXh0KzB4NTYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf c2V0Y3Vyc29ydHlwZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgTm9ybWFsY3Vy c29yJzoNCmNydC5vKC50ZXh0KzB4NzYpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBfc2V0Y3Vyc29ydHlwZScNCmNydC5vOiBJbiBmdW5jdGlvbiBgSGlk ZGVuY3Vyc29yJzoNCmNydC5vKC50ZXh0KzB4OTYpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlwZScNCmNydC5vOiBJbiBmdW5jdGlv biBgQ3Vyc29yJzoNCmNydC5vKC50ZXh0KzB4YjgpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfc2V0Y3Vyc29ydHlwZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgX3BfZmluZGZpcnN0JzoNCmRvcy5vKC50ZXh0KzB4NTZkKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Rvc19maW5kZmlyc3QnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX2ZpbmRuZXh0JzoNCmRvcy5vKC50ZXh0KzB4NWUxKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19maW5kbmV4dCcNCmRvcy5v OiBJbiBmdW5jdGlvbiBgR2V0Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmE0 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0Y2JyaycNCmRvcy5vOiBJ biBmdW5jdGlvbiBgU2V0Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmQzKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0Y2JyaycNCmRvcy5vOiBJbiBm dW5jdGlvbiBgRmlsZXNwbGl0JzoNCmRvcy5vKC50ZXh0KzB4YzdhKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgZm5zcGxpdCcNCmRvcy5vOiBJbiBmdW5j dGlvbiBgR2V0Y3VyZGlyJzoNCmRvcy5vKC50ZXh0KzB4ZDFlKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDJl KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vKC50 ZXh0KzB4ZDNkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycN CmRvcy5vKC50ZXh0KzB4ZDdkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg c2V0ZGlzaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0ZGlyJzoNCmRvcy5v KC50ZXh0KzB4ZGNiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlz aycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgRGlza2ZyZWUnOg0KZG9zLm8oLnRl eHQrMHhlZGYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScN CmRvcy5vOiBJbiBmdW5jdGlvbiBgRGlza3NpemUnOg0KZG9zLm8oLnRleHQr MHhmM2YpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRv cy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZGF0ZSc6DQpkb3MubygudGV4dCsw eGY4Yik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZGF0ZScN CmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0dGltZSc6DQpkb3MubygudGV4 dCsweGZjYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0dGlt ZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZGF0ZSc6DQpkb3Mubygu dGV4dCsweDEwMWYpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkYXRl Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXR0aW1lJzoNCmRvcy5vKC50 ZXh0KzB4MTA1Myk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nfc2V0 dGltZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZnRpbWUnOg0KZG9z Lm8oLnRleHQrMHgxMDdlKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0 ZnRpbWUnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGZ0aW1lJzoNCmRv cy5vKC50ZXh0KzB4MTA5ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNl dGZ0aW1lJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9nZXRmYXR0cic6DQpk b3MubygudGV4dCsweDExZTApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf ZG9zX2dldGZpbGVhdHRyJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRm YXR0cic6DQpkb3MubygudGV4dCsweDEzMzApOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZG9zX3NldGZpbGVhdHRyJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRleHQrMHhiZDApOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI0ZGIpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2lu Zm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNGU3KTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0u bzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5c3RlbS5vKC50ZXh0KzB4 MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJl ZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygudGV4dCsweDI1MTcp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6 ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgU2V0Zm1vZGUnOg0Kc3lzdGVt Lm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Zt b2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUxKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTYyKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1 bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0ubygudGV4dCsweDI1ODcpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0ubzogSW4g ZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoNCnN5c3RlbS5vKC50ZXh0KzB4 MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCmdwY3V0 aWwubzogSW4gZnVuY3Rpb24gYFBhdGhsb2NhdGUnOg0KZ3BjdXRpbC5vKC50 ZXh0KzB4MWQwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNlYXJjaHBh dGgnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0KZ3Bj dXRpbC5vKC50ZXh0KzB4MmIwMCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YGl0b2EnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZSc6DQpn cGN1dGlsLm8oLnRleHQrMHgyZTQ3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgZ2V0ZnRpbWUnDQpncGN1dGlsLm8oLnRleHQrMHgzMDE5KTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgc2V0ZnRpbWUnDQpncGN1dGlsLm86IEluIGZ1 bmN0aW9uIGBDb3B5ZmlsZWV4JzoNCmdwY3V0aWwubygudGV4dCsweDMyMWEp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRmdGltZScNCmdwY3V0aWwu bygudGV4dCsweDM0YTkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRm dGltZScNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYFdyaXRlcGNoYXInOg0K Z3BjdXRpbC5vKC50ZXh0KzB4MzUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYGNwdXRzJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgV3JpdGVzdHJp bmcnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MzU0MSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYGNwdXRzJw0KL3RtcC9jY2ExOTgwMTEubzogSW4gZnVuY3Rp b24gYHByb2dyYW1fVGVzdGNydCc6DQovdG1wL2NjYTE5ODAxMS5vKC50ZXh0 KzB4MmUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGB0ZXh0Y29sb3InDQov dG1wL2NjYTE5ODAxMS5vKC50ZXh0KzB4MzgpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGB0ZXh0YmFja2dyb3VuZCcNCi90bXAvY2NhMTk4MDExLm8oLnRl eHQrMHhkNik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGNoJw0KL3Rt cC9jY2ExOTgwMTEubygudGV4dCsweDIzOCk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYHN0cnVwcicNCi90bXAvY2NhMTk4MDExLm8oLnRleHQrMHgyYmUp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfY29uaW9fa2JoaXQnDQovdG1w L2NjYTE5ODAxMS5vKC50ZXh0KzB4MmU5KTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgZGVsYXknDQovdG1wL2NjYTE5ODAxMS5vKC50ZXh0KzB4MzVjKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0Y2gnDQpncGN1dGlsLm86IElu IGZ1bmN0aW9uIGBQYXRobG9jYXRlJzoNCmdwY3V0aWwubygudGV4dCsweDFk MGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZWFyY2hwYXRoJw0KZ3Bj dXRpbC5vOiBJbiBmdW5jdGlvbiBgSW50MnBjaGFyJzoNCmdwY3V0aWwubygu dGV4dCsweDJiMDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0K Z3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgQ29weWZpbGUnOg0KZ3BjdXRpbC5v KC50ZXh0KzB4MmU0Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0 aW1lJw0KZ3BjdXRpbC5vKC50ZXh0KzB4MzAxOSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYHNldGZ0aW1lJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBg Q29weWZpbGVleCc6DQpncGN1dGlsLm8oLnRleHQrMHgzMjFhKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpncGN1dGlsLm8oLnRleHQr MHgzNGE5KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZnRpbWUnDQpn cGN1dGlsLm86IEluIGZ1bmN0aW9uIGBXcml0ZXBjaGFyJzoNCmdwY3V0aWwu bygudGV4dCsweDM1MGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjcHV0 cycNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYFdyaXRlc3RyaW5nJzoNCmdw Y3V0aWwubygudGV4dCsweDM1NDEpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBjcHV0cycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZmluZGZpcnN0JzoN CmRvcy5vKC50ZXh0KzB4NTZkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg X2Rvc19maW5kZmlyc3QnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2ZpbmRu ZXh0JzoNCmRvcy5vKC50ZXh0KzB4NWUxKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgX2Rvc19maW5kbmV4dCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0 Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmE0KTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgZ2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgU2V0Y2Jy ZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmQzKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgc2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgRmlsZXNwbGl0 JzoNCmRvcy5vKC50ZXh0KzB4YzdhKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgZm5zcGxpdCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0Y3VyZGlyJzoN CmRvcy5vKC50ZXh0KzB4ZDFlKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg Z2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDJlKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDNkKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDdk KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5vOiBJ biBmdW5jdGlvbiBgR2V0ZGlyJzoNCmRvcy5vKC50ZXh0KzB4ZGNiKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vOiBJbiBmdW5j dGlvbiBgRGlza2ZyZWUnOg0KZG9zLm8oLnRleHQrMHhlZGYpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgRGlza3NpemUnOg0KZG9zLm8oLnRleHQrMHhmM2YpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBg X3BfZ2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweGY4Yik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZGF0ZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgX3BfZ2V0dGltZSc6DQpkb3MubygudGV4dCsweGZjYik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0dGltZScNCmRvcy5vOiBJbiBmdW5j dGlvbiBgX3Bfc2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweDEwMWYpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkYXRlJw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9zZXR0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA1Myk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nfc2V0dGltZScNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3BfZ2V0ZnRpbWUnOg0KZG9zLm8oLnRleHQrMHgxMDdlKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX3NldGZ0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA5ZSk6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KZG9zLm86IElu IGZ1bmN0aW9uIGBfcF9nZXRmYXR0cic6DQpkb3MubygudGV4dCsweDExZTAp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGZpbGVhdHRyJw0K ZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmYXR0cic6DQpkb3MubygudGV4 dCsweDEzMzApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldGZp bGVhdHRyJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0K c3lzdGVtLm8oLnRleHQrMHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBpdG9hJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpz eXN0ZW0ubygudGV4dCsweDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVt Lm8oLnRleHQrMHgyNGU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19k cG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1h eGF2YWlsJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRp b24nDQpzeXN0ZW0ubygudGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBm dW5jdGlvbiBgU2V0Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRl eHQrMHgyNTUxKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0K c3lzdGVtLm8oLnRleHQrMHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgX2Ztb2RlJw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6 DQpzeXN0ZW0ubygudGV4dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBfZm1vZGUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVj dG9yXzMyJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9mbW9kZScNCi90bXAvY2NhMTk4NTAxLm86IEluIGZ1 bmN0aW9uIGBwcm9ncmFtX1Rlc3Rkb3MnOg0KL3RtcC9jY2ExOTg1MDEubygu dGV4dCsweDNlMSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRhdGUn DQovdG1wL2NjYTE5ODUwMS5vKC50ZXh0KzB4NDZlKTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgZ2V0dGltZScNCi90bXAvY2NhMTk4NTAxLm8oLnRleHQr MHg1MWEpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRpc2tm cmVlJw0KL3RtcC9jY2ExOTg1MDEubygudGV4dCsweDVkYSk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGdldGRmcmVlJw0KL3RtcC9jY2ExOTkyNTEubzog SW4gZnVuY3Rpb24gYHByb2dyYW1fRHBtaXRlc3QnOg0KL3RtcC9jY2ExOTky NTEubygudGV4dCsweDkxKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19k cG1pX2dldF92ZXJzaW9uJw0KL3RtcC9jY2ExOTkyNTEubygudGV4dCsweDEx Yik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfcGFnZV9z aXplJw0KL3RtcC9jY2ExOTkyNTEubygudGV4dCsweDE1Nyk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3Jt YXRpb24nDQpzeXN1dGlscy5vOiBJbiBmdW5jdGlvbiBgUmVuYW1lZmlsZSc6 DQpzeXN1dGlscy5vKC50ZXh0KzB4MCk6IG11bHRpcGxlIGRlZmluaXRpb24g b2YgYFJlbmFtZWZpbGUnDQouL3N5c3V0aWxzLm8oLnRleHQrMHgwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpzeXN1dGlscy5vOiBJbiBmdW5jdGlvbiBgRGVs ZXRlZmlsZSc6DQpzeXN1dGlscy5vKC50ZXh0KzB4NjApOiBtdWx0aXBsZSBk ZWZpbml0aW9uIG9mIGBEZWxldGVmaWxlJw0KLi9zeXN1dGlscy5vKC50ZXh0 KzB4NjApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCnN5c3V0aWxzLm86IEluIGZ1 bmN0aW9uIGBGaWxlY3JlYXRlJzoNCnN5c3V0aWxzLm8oLnRleHQrMHhhMCk6 IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYEZpbGVjcmVhdGUnDQouL3N5c3V0 aWxzLm8oLnRleHQrMHhhMCk6IGZpcnN0IGRlZmluZWQgaGVyZQ0Kc3lzdXRp bHMubzogSW4gZnVuY3Rpb24gYEZpbGVvcGVuJzoNCnN5c3V0aWxzLm8oLnRl eHQrMHgxMjApOiBtdWx0aXBsZSBkZWZpbml0aW9uIG9mIGBGaWxlb3BlbicN Ci4vc3lzdXRpbHMubygudGV4dCsweDEyMCk6IGZpcnN0IGRlZmluZWQgaGVy ZQ0Kc3lzdXRpbHMubzogSW4gZnVuY3Rpb24gYFVwcGVyY2FzZSc6DQpzeXN1 dGlscy5vKC50ZXh0KzB4MTYwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBg VXBwZXJjYXNlJw0KLi9zeXN1dGlscy5vKC50ZXh0KzB4MTYwKTogZmlyc3Qg ZGVmaW5lZCBoZXJlDQpzeXN1dGlscy5vOiBJbiBmdW5jdGlvbiBgTG93ZXJj YXNlJzoNCnN5c3V0aWxzLm8oLnRleHQrMHgyMzApOiBtdWx0aXBsZSBkZWZp bml0aW9uIG9mIGBMb3dlcmNhc2UnDQouL3N5c3V0aWxzLm8oLnRleHQrMHgy MzApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCnN5c3V0aWxzLm86IEluIGZ1bmN0 aW9uIGBGaWxlZ2V0YXR0cic6DQpzeXN1dGlscy5vKC50ZXh0KzB4MzAwKTog bXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgRmlsZWdldGF0dHInDQouL3N5c3V0 aWxzLm8oLnRleHQrMHgzMDApOiBmaXJzdCBkZWZpbmVkIGhlcmUNCnN5c3V0 aWxzLm86IEluIGZ1bmN0aW9uIGBGaWxlc2V0YXR0cic6DQpzeXN1dGlscy5v KC50ZXh0KzB4MzQwKTogbXVsdGlwbGUgZGVmaW5pdGlvbiBvZiBgRmlsZXNl dGF0dHInDQouL3N5c3V0aWxzLm8oLnRleHQrMHgzNDApOiBmaXJzdCBkZWZp bmVkIGhlcmUNCnN5c3V0aWxzLm86IEluIGZ1bmN0aW9uIGBGaWxlYWdlJzoN CnN5c3V0aWxzLm8oLnRleHQrMHgzODApOiBtdWx0aXBsZSBkZWZpbml0aW9u IG9mIGBGaWxlYWdlJw0KLi9zeXN1dGlscy5vKC50ZXh0KzB4MzgwKTogZmly c3QgZGVmaW5lZCBoZXJlDQpzeXN1dGlscy5vOiBJbiBmdW5jdGlvbiBgRmls ZWdldGRhdGUnOg0Kc3lzdXRpbHMubygudGV4dCsweDQwMCk6IG11bHRpcGxl IGRlZmluaXRpb24gb2YgYEZpbGVnZXRkYXRlJw0KLi9zeXN1dGlscy5vKC50 ZXh0KzB4NDAwKTogZmlyc3QgZGVmaW5lZCBoZXJlDQpzeXN1dGlscy5vOiBJ biBmdW5jdGlvbiBgRmlsZXNldGRhdGUnOg0Kc3lzdXRpbHMubygudGV4dCsw eDQ0MCk6IG11bHRpcGxlIGRlZmluaXRpb24gb2YgYEZpbGVzZXRkYXRlJw0K Li9zeXN1dGlscy5vKC50ZXh0KzB4NDQwKTogZmlyc3QgZGVmaW5lZCBoZXJl DQouL3N5c3V0aWxzLm86IEluIGZ1bmN0aW9uIGBGaWxlb3Blbic6DQouL3N5 c3V0aWxzLm8oLnRleHQrMHgxNDgpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBfb3BlbicNCi4vc3lzdXRpbHMubzogSW4gZnVuY3Rpb24gYEZpbGVnZXRh dHRyJzoNCi4vc3lzdXRpbHMubygudGV4dCsweDMyNSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZmlsZWF0dHInDQouL3N5c3V0aWxzLm86 IEluIGZ1bmN0aW9uIGBGaWxlc2V0YXR0cic6DQouL3N5c3V0aWxzLm8oLnRl eHQrMHgzNjgpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldGZp bGVhdHRyJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9maW5kZmlyc3QnOg0K ZG9zLm8oLnRleHQrMHg1NmQpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBf ZG9zX2ZpbmRmaXJzdCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZmluZG5l eHQnOg0KZG9zLm8oLnRleHQrMHg1ZTEpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBfZG9zX2ZpbmRuZXh0Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBHZXRj YnJlYWsnOg0KZG9zLm8oLnRleHQrMHg2YTQpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBnZXRjYnJrJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBTZXRjYnJl YWsnOg0KZG9zLm8oLnRleHQrMHg2ZDMpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBzZXRjYnJrJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBGaWxlc3BsaXQn Og0KZG9zLm8oLnRleHQrMHhjN2EpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBmbnNwbGl0Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBHZXRjdXJkaXInOg0K ZG9zLm8oLnRleHQrMHhkMWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBn ZXRkaXNrJw0KZG9zLm8oLnRleHQrMHhkMmUpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBnZXRkaXNrJw0KZG9zLm8oLnRleHQrMHhkM2QpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBzZXRkaXNrJw0KZG9zLm8oLnRleHQrMHhkN2Qp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkaXNrJw0KZG9zLm86IElu IGZ1bmN0aW9uIGBHZXRkaXInOg0KZG9zLm8oLnRleHQrMHhkY2IpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRkaXNrJw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBEaXNrZnJlZSc6DQpkb3MubygudGV4dCsweGVkZik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGdldGRmcmVlJw0KZG9zLm86IEluIGZ1bmN0aW9u IGBEaXNrc2l6ZSc6DQpkb3MubygudGV4dCsweGYzZik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGRmcmVlJw0KZG9zLm86IEluIGZ1bmN0aW9uIGBf cF9nZXRkYXRlJzoNCmRvcy5vKC50ZXh0KzB4ZjhiKTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgX2Rvc19nZXRkYXRlJw0KZG9zLm86IEluIGZ1bmN0aW9u IGBfcF9nZXR0aW1lJzoNCmRvcy5vKC50ZXh0KzB4ZmNiKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX2Rvc19nZXR0aW1lJw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9zZXRkYXRlJzoNCmRvcy5vKC50ZXh0KzB4MTAxZik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYHNldGRhdGUnDQpkb3MubzogSW4gZnVuY3Rp b24gYF9wX3NldHRpbWUnOg0KZG9zLm8oLnRleHQrMHgxMDUzKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Rvc19zZXR0aW1lJw0KZG9zLm86IEluIGZ1 bmN0aW9uIGBfcF9nZXRmdGltZSc6DQpkb3MubygudGV4dCsweDEwN2UpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBnZXRmdGltZScNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3Bfc2V0ZnRpbWUnOg0KZG9zLm8oLnRleHQrMHgxMDllKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZnRpbWUnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX2dldGZhdHRyJzoNCmRvcy5vKC50ZXh0KzB4MTFlMCk6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZmlsZWF0dHInDQpk b3MubzogSW4gZnVuY3Rpb24gYF9wX3NldGZhdHRyJzoNCmRvcy5vKC50ZXh0 KzB4MTMzMCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nfc2V0Zmls ZWF0dHInDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBQYXRobG9jYXRlJzoN CmdwY3V0aWwubygudGV4dCsweDFkMGIpOiB1bmRlZmluZWQgcmVmZXJlbmNl IHRvIGBzZWFyY2hwYXRoJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgSW50 MnBjaGFyJzoNCmdwY3V0aWwubygudGV4dCsweDJiMDApOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBpdG9hJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBg Q29weWZpbGUnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MmU0Nyk6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0KZ3BjdXRpbC5vKC50ZXh0KzB4 MzAxOSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KZ3Bj dXRpbC5vOiBJbiBmdW5jdGlvbiBgQ29weWZpbGVleCc6DQpncGN1dGlsLm8o LnRleHQrMHgzMjFhKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRp bWUnDQpncGN1dGlsLm8oLnRleHQrMHgzNGE5KTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgc2V0ZnRpbWUnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBX cml0ZXBjaGFyJzoNCmdwY3V0aWwubygudGV4dCsweDM1MGIpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBjcHV0cycNCmdwY3V0aWwubzogSW4gZnVuY3Rp b24gYFdyaXRlc3RyaW5nJzoNCmdwY3V0aWwubygudGV4dCsweDM1NDEpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjcHV0cycNCnN5c3V0aWxzLm86IElu IGZ1bmN0aW9uIGBGaWxlb3Blbic6DQpzeXN1dGlscy5vKC50ZXh0KzB4MTQ4 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX29wZW4nDQpzeXN1dGlscy5v OiBJbiBmdW5jdGlvbiBgRmlsZWdldGF0dHInOg0Kc3lzdXRpbHMubygudGV4 dCsweDMyNSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0Zmls ZWF0dHInDQpzeXN1dGlscy5vOiBJbiBmdW5jdGlvbiBgRmlsZXNldGF0dHIn Og0Kc3lzdXRpbHMubygudGV4dCsweDM2OCk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYF9kb3Nfc2V0ZmlsZWF0dHInDQpzeXN0ZW0ubzogSW4gZnVuY3Rp b24gYEludDJwY2hhcic6DQpzeXN0ZW0ubygudGV4dCsweGJkMCk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYGl0b2EnDQpzeXN0ZW0ubzogSW4gZnVuY3Rp b24gYE1lbWF2YWlsJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjRkYik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5m b3JtYXRpb24nDQpzeXN0ZW0ubygudGV4dCsweDI0ZTcpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5v OiBJbiBmdW5jdGlvbiBgTWF4YXZhaWwnOg0Kc3lzdGVtLm8oLnRleHQrMHgy NTBiKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9mcmVl X21lbW9yeV9pbmZvcm1hdGlvbicNCnN5c3RlbS5vKC50ZXh0KzB4MjUxNyk6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfcGFnZV9zaXpl Jw0Kc3lzdGVtLm86IEluIGZ1bmN0aW9uIGBTZXRmbW9kZSc6DQpzeXN0ZW0u bygudGV4dCsweDI1M2UpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1v ZGUnDQpzeXN0ZW0ubygudGV4dCsweDI1NTEpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0ubygudGV4dCsweDI1NjIpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0ZW0ubzogSW4gZnVu Y3Rpb24gYEdldGZtb2RlJzoNCnN5c3RlbS5vKC50ZXh0KzB4MjU4Nyk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9kZScNCnN5c3RlbS5vOiBJbiBm dW5jdGlvbiBgY29uc3RydWN0b3JfMzInOg0Kc3lzdGVtLm8oLnRleHQrMHgy OWUyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVt Lm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRleHQr MHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lzdGVt Lm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsw eDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2Zy ZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNGU3 KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3Np emUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5c3Rl bS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9f ZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygu dGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlf Z2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgU2V0Zm1v ZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUxKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQr MHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lz dGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0ubygudGV4 dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpz eXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoNCnN5c3Rl bS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9m bW9kZScNCm9iamVjdHMubzogSW4gZnVuY3Rpb24gYFRzdHJjb2xsZWN0aW9u X0xlc3MnOg0Kb2JqZWN0cy5vKC50ZXh0KzB4MjllOSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYHN0cmljbXAnDQpvYmplY3RzLm86IEluIGZ1bmN0aW9u IGBUc3RyY29sbGVjdGlvbl9HcmVhdGVyJzoNCm9iamVjdHMubygudGV4dCsw eDJhNDkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzdHJpY21wJw0Kb2Jq ZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmNvbGxlY3Rpb25fRXF1YWwnOg0K b2JqZWN0cy5vKC50ZXh0KzB4MmFhOSk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYHN0cmljbXAnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2ZpbmRmaXJz dCc6DQpkb3MubygudGV4dCsweDU2ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYF9kb3NfZmluZGZpcnN0Jw0KZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9m aW5kbmV4dCc6DQpkb3MubygudGV4dCsweDVlMSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYF9kb3NfZmluZG5leHQnDQpkb3MubzogSW4gZnVuY3Rpb24g YEdldGNicmVhayc6DQpkb3MubygudGV4dCsweDZhNCk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGNicmsnDQpkb3MubzogSW4gZnVuY3Rpb24gYFNl dGNicmVhayc6DQpkb3MubygudGV4dCsweDZkMyk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYHNldGNicmsnDQpkb3MubzogSW4gZnVuY3Rpb24gYEZpbGVz cGxpdCc6DQpkb3MubygudGV4dCsweGM3YSk6IHVuZGVmaW5lZCByZWZlcmVu Y2UgdG8gYGZuc3BsaXQnDQpkb3MubzogSW4gZnVuY3Rpb24gYEdldGN1cmRp cic6DQpkb3MubygudGV4dCsweGQxZSk6IHVuZGVmaW5lZCByZWZlcmVuY2Ug dG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQyZSk6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubygudGV4dCsweGQzZCk6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3MubygudGV4dCsw eGQ3ZCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGRpc2snDQpkb3Mu bzogSW4gZnVuY3Rpb24gYEdldGRpcic6DQpkb3MubygudGV4dCsweGRjYik6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGRpc2snDQpkb3MubzogSW4g ZnVuY3Rpb24gYERpc2tmcmVlJzoNCmRvcy5vKC50ZXh0KzB4ZWRmKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3MubzogSW4gZnVu Y3Rpb24gYERpc2tzaXplJzoNCmRvcy5vKC50ZXh0KzB4ZjNmKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGZyZWUnDQpkb3MubzogSW4gZnVuY3Rp b24gYF9wX2dldGRhdGUnOg0KZG9zLm8oLnRleHQrMHhmOGIpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGRhdGUnDQpkb3MubzogSW4gZnVu Y3Rpb24gYF9wX2dldHRpbWUnOg0KZG9zLm8oLnRleHQrMHhmY2IpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldHRpbWUnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX3NldGRhdGUnOg0KZG9zLm8oLnRleHQrMHgxMDFmKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGF0ZScNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3Bfc2V0dGltZSc6DQpkb3MubygudGV4dCsweDEwNTMpOiB1 bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldHRpbWUnDQpkb3Mubzog SW4gZnVuY3Rpb24gYF9wX2dldGZ0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA3 ZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0aW1lJw0KZG9zLm86 IEluIGZ1bmN0aW9uIGBfcF9zZXRmdGltZSc6DQpkb3MubygudGV4dCsweDEw OWUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCmRvcy5v OiBJbiBmdW5jdGlvbiBgX3BfZ2V0ZmF0dHInOg0KZG9zLm8oLnRleHQrMHgx MWUwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19nZXRmaWxlYXR0 cicNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3Bfc2V0ZmF0dHInOg0KZG9zLm8o LnRleHQrMHgxMzMwKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Rvc19z ZXRmaWxlYXR0cicNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYFBhdGhsb2Nh dGUnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MWQwYik6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYHNlYXJjaHBhdGgnDQpncGN1dGlsLm86IEluIGZ1bmN0aW9u IGBJbnQycGNoYXInOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MmIwMCk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYGl0b2EnDQpncGN1dGlsLm86IEluIGZ1bmN0 aW9uIGBDb3B5ZmlsZSc6DQpncGN1dGlsLm8oLnRleHQrMHgyZTQ3KTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpncGN1dGlsLm8oLnRl eHQrMHgzMDE5KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZnRpbWUn DQpncGN1dGlsLm86IEluIGZ1bmN0aW9uIGBDb3B5ZmlsZWV4JzoNCmdwY3V0 aWwubygudGV4dCsweDMyMWEpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBn ZXRmdGltZScNCmdwY3V0aWwubygudGV4dCsweDM0YTkpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCmdwY3V0aWwubzogSW4gZnVuY3Rp b24gYFdyaXRlcGNoYXInOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MzUwYik6IHVu ZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNwdXRzJw0KZ3BjdXRpbC5vOiBJbiBm dW5jdGlvbiBgV3JpdGVzdHJpbmcnOg0KZ3BjdXRpbC5vKC50ZXh0KzB4MzU0 MSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNwdXRzJw0Kc3lzdGVtLm86 IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRleHQrMHhi ZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lzdGVtLm86 IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI0 ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVf bWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNGU3KTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUn DQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5c3RlbS5v KC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBt aV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygudGV4 dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0 X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgU2V0Zm1vZGUn Og0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUxKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgy NTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVt Lm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0ubygudGV4dCsw eDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUnDQpzeXN0 ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoNCnN5c3RlbS5v KC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9mbW9k ZScNCi90bXAvY2NhMjAwMjYxLm86IEluIGZ1bmN0aW9uIGBwcm9ncmFtX1Rl c3RzdHInOg0KL3RtcC9jY2EyMDAyNjEubygudGV4dCsweDUwYSk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9fZmlsZV9leGlzdHMnDQpvYmplY3RzLm86 IEluIGZ1bmN0aW9uIGBUc3RyY29sbGVjdGlvbl9MZXNzJzoNCm9iamVjdHMu bygudGV4dCsweDI5ZTkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzdHJp Y21wJw0Kb2JqZWN0cy5vOiBJbiBmdW5jdGlvbiBgVHN0cmNvbGxlY3Rpb25f R3JlYXRlcic6DQpvYmplY3RzLm8oLnRleHQrMHgyYTQ5KTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgc3RyaWNtcCcNCm9iamVjdHMubzogSW4gZnVuY3Rp b24gYFRzdHJjb2xsZWN0aW9uX0VxdWFsJzoNCm9iamVjdHMubygudGV4dCsw eDJhYTkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzdHJpY21wJw0Kc3lz dGVtLm86IEluIGZ1bmN0aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRl eHQrMHhiZDApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lz dGVtLm86IEluIGZ1bmN0aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4 dCsweDI0ZGIpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0 X2ZyZWVfbWVtb3J5X2luZm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgy NGU3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdl X3NpemUnDQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5 c3RlbS5vKC50ZXh0KzB4MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YF9fZHBtaV9nZXRfZnJlZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0u bygudGV4dCsweDI1MTcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2Rw bWlfZ2V0X3BhZ2Vfc2l6ZScNCnN5c3RlbS5vOiBJbiBmdW5jdGlvbiBgU2V0 Zm1vZGUnOg0Kc3lzdGVtLm8oLnRleHQrMHgyNTNlKTogdW5kZWZpbmVkIHJl ZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRleHQrMHgyNTUxKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0Kc3lzdGVtLm8oLnRl eHQrMHgyNTYyKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgX2Ztb2RlJw0K c3lzdGVtLm86IEluIGZ1bmN0aW9uIGBHZXRmbW9kZSc6DQpzeXN0ZW0ubygu dGV4dCsweDI1ODcpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZm1vZGUn DQpzeXN0ZW0ubzogSW4gZnVuY3Rpb24gYGNvbnN0cnVjdG9yXzMyJzoNCnN5 c3RlbS5vKC50ZXh0KzB4MjllMik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8g YF9mbW9kZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBgX3BfZmluZGZpcnN0JzoN CmRvcy5vKC50ZXh0KzB4NTZkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg X2Rvc19maW5kZmlyc3QnDQpkb3MubzogSW4gZnVuY3Rpb24gYF9wX2ZpbmRu ZXh0JzoNCmRvcy5vKC50ZXh0KzB4NWUxKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgX2Rvc19maW5kbmV4dCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0 Y2JyZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmE0KTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgZ2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgU2V0Y2Jy ZWFrJzoNCmRvcy5vKC50ZXh0KzB4NmQzKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgc2V0Y2JyaycNCmRvcy5vOiBJbiBmdW5jdGlvbiBgRmlsZXNwbGl0 JzoNCmRvcy5vKC50ZXh0KzB4YzdhKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgZm5zcGxpdCcNCmRvcy5vOiBJbiBmdW5jdGlvbiBgR2V0Y3VyZGlyJzoN CmRvcy5vKC50ZXh0KzB4ZDFlKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBg Z2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDJlKTogdW5kZWZpbmVkIHJlZmVy ZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDNkKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5vKC50ZXh0KzB4ZDdk KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgc2V0ZGlzaycNCmRvcy5vOiBJ biBmdW5jdGlvbiBgR2V0ZGlyJzoNCmRvcy5vKC50ZXh0KzB4ZGNiKTogdW5k ZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZGlzaycNCmRvcy5vOiBJbiBmdW5j dGlvbiBgRGlza2ZyZWUnOg0KZG9zLm8oLnRleHQrMHhlZGYpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgRGlza3NpemUnOg0KZG9zLm8oLnRleHQrMHhmM2YpOiB1bmRlZmluZWQg cmVmZXJlbmNlIHRvIGBnZXRkZnJlZScNCmRvcy5vOiBJbiBmdW5jdGlvbiBg X3BfZ2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweGY4Yik6IHVuZGVmaW5lZCBy ZWZlcmVuY2UgdG8gYF9kb3NfZ2V0ZGF0ZScNCmRvcy5vOiBJbiBmdW5jdGlv biBgX3BfZ2V0dGltZSc6DQpkb3MubygudGV4dCsweGZjYik6IHVuZGVmaW5l ZCByZWZlcmVuY2UgdG8gYF9kb3NfZ2V0dGltZScNCmRvcy5vOiBJbiBmdW5j dGlvbiBgX3Bfc2V0ZGF0ZSc6DQpkb3MubygudGV4dCsweDEwMWYpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRkYXRlJw0KZG9zLm86IEluIGZ1bmN0 aW9uIGBfcF9zZXR0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA1Myk6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYF9kb3Nfc2V0dGltZScNCmRvcy5vOiBJbiBm dW5jdGlvbiBgX3BfZ2V0ZnRpbWUnOg0KZG9zLm8oLnRleHQrMHgxMDdlKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgZ2V0ZnRpbWUnDQpkb3MubzogSW4g ZnVuY3Rpb24gYF9wX3NldGZ0aW1lJzoNCmRvcy5vKC50ZXh0KzB4MTA5ZSk6 IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHNldGZ0aW1lJw0KZG9zLm86IElu IGZ1bmN0aW9uIGBfcF9nZXRmYXR0cic6DQpkb3MubygudGV4dCsweDExZTAp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGZpbGVhdHRyJw0K ZG9zLm86IEluIGZ1bmN0aW9uIGBfcF9zZXRmYXR0cic6DQpkb3MubygudGV4 dCsweDEzMzApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX3NldGZp bGVhdHRyJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBgUGF0aGxvY2F0ZSc6 DQpncGN1dGlsLm8oLnRleHQrMHgxZDBiKTogdW5kZWZpbmVkIHJlZmVyZW5j ZSB0byBgc2VhcmNocGF0aCcNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24gYElu dDJwY2hhcic6DQpncGN1dGlsLm8oLnRleHQrMHgyYjAwKTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgaXRvYScNCmdwY3V0aWwubzogSW4gZnVuY3Rpb24g YENvcHlmaWxlJzoNCmdwY3V0aWwubygudGV4dCsweDJlNDcpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBnZXRmdGltZScNCmdwY3V0aWwubygudGV4dCsw eDMwMTkpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzZXRmdGltZScNCmdw Y3V0aWwubzogSW4gZnVuY3Rpb24gYENvcHlmaWxlZXgnOg0KZ3BjdXRpbC5v KC50ZXh0KzB4MzIxYSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldGZ0 aW1lJw0KZ3BjdXRpbC5vKC50ZXh0KzB4MzRhOSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYHNldGZ0aW1lJw0KZ3BjdXRpbC5vOiBJbiBmdW5jdGlvbiBg V3JpdGVwY2hhcic6DQpncGN1dGlsLm8oLnRleHQrMHgzNTBiKTogdW5kZWZp bmVkIHJlZmVyZW5jZSB0byBgY3B1dHMnDQpncGN1dGlsLm86IEluIGZ1bmN0 aW9uIGBXcml0ZXN0cmluZyc6DQpncGN1dGlsLm8oLnRleHQrMHgzNTQxKTog dW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgY3B1dHMnDQpzeXN1dGlscy5vOiBJ biBmdW5jdGlvbiBgRmlsZW9wZW4nOg0Kc3lzdXRpbHMubygudGV4dCsweDE0 OCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9vcGVuJw0Kc3lzdXRpbHMu bzogSW4gZnVuY3Rpb24gYEZpbGVnZXRhdHRyJzoNCnN5c3V0aWxzLm8oLnRl eHQrMHgzMjUpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfZG9zX2dldGZp bGVhdHRyJw0Kc3lzdXRpbHMubzogSW4gZnVuY3Rpb24gYEZpbGVzZXRhdHRy JzoNCnN5c3V0aWxzLm8oLnRleHQrMHgzNjgpOiB1bmRlZmluZWQgcmVmZXJl bmNlIHRvIGBfZG9zX3NldGZpbGVhdHRyJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBJbnQycGNoYXInOg0Kc3lzdGVtLm8oLnRleHQrMHhiZDApOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBpdG9hJw0Kc3lzdGVtLm86IEluIGZ1bmN0 aW9uIGBNZW1hdmFpbCc6DQpzeXN0ZW0ubygudGV4dCsweDI0ZGIpOiB1bmRl ZmluZWQgcmVmZXJlbmNlIHRvIGBfX2RwbWlfZ2V0X2ZyZWVfbWVtb3J5X2lu Zm9ybWF0aW9uJw0Kc3lzdGVtLm8oLnRleHQrMHgyNGU3KTogdW5kZWZpbmVk IHJlZmVyZW5jZSB0byBgX19kcG1pX2dldF9wYWdlX3NpemUnDQpzeXN0ZW0u bzogSW4gZnVuY3Rpb24gYE1heGF2YWlsJzoNCnN5c3RlbS5vKC50ZXh0KzB4 MjUwYik6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9fZHBtaV9nZXRfZnJl ZV9tZW1vcnlfaW5mb3JtYXRpb24nDQpzeXN0ZW0ubygudGV4dCsweDI1MTcp OiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBfX2Rw