Gpc November 1998

gpc@gnu.de

18 participants
47 discussions

Re: next attempts
by Maurice Lombardi 07 Nov '98

07 Nov '98

Toby Robert P. Ewing a Ã©crit: > I tried, as you suggested, doing a redir -oe -o ....... >I got nothing -- Nothing! -- in the test1.out (redirected output) >file, lots of stuff on the screen. The reason is that you must type redir -o out.lst -eo ... in that order (redir output to out.lst and then error to output) I had made the mistake in my previous mail. To compare I have done this on my system, and out.lst is attached. redir -o out.lst -eo gpc -g -v --automake="-g" -o blt_test.exe blt_test.pas -lgrx20 Notice the parameter ="-g" to automake. With no parameter I got a SIGSEGV error if the unit grx20.pas had indeed to be recompiled (probably only in that case gpc looks for parameters to automake). This seems a new bug in gpc. But I may have not noticed it before because I usually give always some parameters to automake. > > So I made notes about where the original files were, made backup > copies, and traded in your files, being sure to move specs to > c:\gpc\lib\gcc-lib\djgpp\2.81. (I put djgpp.djl in c:\gpc\lib. no djgpp.djl belongs also to c:\gpc\lib\gcc-lib\djgpp\2.81 in addition by looking to the attached out.lst I have noticed that an other file crtf.o is needed in that directory (and not contained in the djgpp binary distribution). I give it also to you in attachment. Those two files djgpp.djl and crtf.o should be included in future betas, to avoid troubles for people like you who work only in pascal (all this stuff otherwise comes with gcc). >The relevant parts are, from gpc -g -v > --automake -o blt_test.exe c:\gpc\pascal\blt_test.pas -lgrx20 are: you should first cd \gpc\pascal and then from there issue the command: the path is no more necesary > reading specs from c:\gpc\lib\gcc-lib\djgpp\2.81\specs > gpc version 19980830, based on gcc 2.8.1 > {then there's a 6-line translated command line...} > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > $DJDIR/djgpp/include > $DJDIR/lib/gcc-lib/djgpp/2.81/include > /usr/include > end of search list > c:\gpc\lib\gcc-lib\djgpp\2.81\gpc1.exe c:/gpc/tmp\ccbaaaa -quiet -dumpbase blt > _test.pas -g -version -famtmpfile=blttest.gpc -fautomake -o c:/gpc/tmp\cccaaaa > > GNU Pascal version 2.8.1 (djgpp) compiled by GNU C version 2.8.1 > c:\\gpc\\pascal\\blt_test.pas:3: module '*' could not be compiled > > where, on the last line, the * is ascii 5, the "club" from playing cards. > Well you should really compile from within the directory c:\gpc\pascal I do not like this syntax c:\\gpc\\pascal\\blt_test.pas:3, even if it is logical \ have to be escaped in unix shells: gpc obviously reads wrongly the file. Good luck -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Re: GNU Pascal: pascal library
by Frank Heckenbach 07 Nov '98

07 Nov '98

Peter Gerwinski wrote: > Be welcome! :-) But first have a look on what is already there > (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/) and what is > needed (see below for one suggestion). > > > 2) A standard (borland or watcom or something) Pascal library > > reference (or one of each type to write multiple libraries :), with > > descriptions of what each does etc. > > I have never seen a Watcom Pascal compiler. The only de-facto > standard I have seen in Pascal libraries are Borland's ones. As far as these are concerned, we now have everything of the non-object oriented units (i.e., except Turbo Vision and OWL), apart from the "Graph3" unit (primitive turtle graphics, probably not exactly in wide use ;-) and a few details. Other more or less "standard" libraries I heard of are some units by Turbo Power which seem to be some extentsions to the Borland units, and the units of Delphi. I saw the interface of Delphi's SysUtils units, and it's quite large and would require a lot of work to implement. > > Yes, I realize that this may be a huge task (how long did it take > > them to write the DJGPP2 libc? :), and that it would take a little > > while, but hey, it sounds interesting :) and you could take that little > > 'con' out of the cons section. In addition, non-C (but Pascal) > > programmers could use your compiler because you'd have a > > similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c > > reference :). > > > > NOTE: Just in case I wasn't clear, what I meant by writing a > > "standard Pascal lib" is writing the lib that is to Pascal as libc is to > > DJGPP :) > > There is no library in Pascal that corresponds to `libc'. > The closest thing is GPC's run-time library which implements > Pascal's `writeln' and such. But that one is ready and > working well. ;-) Yes, exactly. If you meant to re-implement the libc functionality in Pascal, I doubt whether that would be such a good idea. The implementation of libc, AFAIK, is quite system-specific, but its interface on the C level is rather portable, so it seems more sensible to use this interface, like the RTS does now, than to reimplement it. I recently added some functionality from the libc to GPC (e.g. some routines about file name, file name matching and globbing and getopt parameter parsing). The way I did it was to write a (thin) C layer over the libc interface if necessary to use C macros or such things, then a small Pascal layer if necessary to convert from or to Pascal strings (which are not easy to access from C code) or such stuff, and finally provide a Pascal declaration. This seems to be the best way for now. You can get the most recent GPC source distribution and see some examples of this in the rts/ directory (e.g., the unit filename.pas). However, not all the things I mentioned above are in that distribution yet, so if you want, we can provide you with the more current developer sources that contain them all. There are certainly a lot of things left in the libc and other libraries (portable ones as well as system dependent ones) that could be made available to Pascal in this way, and if that's what you like to do, you won't get out of work soon... ;-) Another (better, IMHO, but more difficult) approach would be writing a C-header-to-Pascal translator that translates a C header with all the details to Pascal in order to be used with GPC. If we had this, we could use libc and other libraries written in C directly from Pascal. This would take away not only the work of translating them and writing wrappers, but also the maintenance work and probably a lot of portability problems. However, writing such a translator is not easy. Yes, there are a number of "C to Pascal translators" available, but none of those I saw came even close to being useful for this purpose because they only provide a more or less close approximation of the C code and declarations in Pascal. But what we need here is really a 1:1 translation -- which *is* possible in GPC for almost all features of C. Peter and I have discussed this problem and came to some conclusions about how to approach it. So, if you like to try this (which wouldn't exactly be writing a library, but making available a lot of existing libraries), we can discuss with you our ideas so far. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GNU Pascal: pascal library
by Frank Heckenbach 07 Nov '98

07 Nov '98

Clyde Meli wrote: > Bpcompat already exists, and as far I am aware most of the stuff is now > incorporated in the gpc library. Ah, I have one suggestion - please > add FillChar and StrPas to the main library.... FillChar is already built into the compiler. StrPas is available under the name `CString2String' (which is more understandable than `StrPas' which tells almost nothing to me). In case you need it as `StrPas', here's the complete(!) BP compatible `Strings' unit for the next release of BPCompat (all the other CString functions are already or will then be in a RTS unit). { BP compatible strings unit. Everything else is in the RTS. Donated to the public domain. :-) } unit Strings; interface uses GPC; function StrPas (Str : CString) : TString; implementation function StrPas (Str : CString) : TString; begin StrPas := CString2String (Str) end; end. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: GNU Pascal: pascal library
by Clyde Meli 07 Nov '98

07 Nov '98

> An interesting project...Well anyways, I'm a programmer that knows > cross-processor asm, C, C++, VC++, VB, Basic (eww), Euphoria (the > predecessor to C (and Pascal?)), and am learning Pascal. > Anyways, I noticed how GNU Pascal is lacking a standard Pascallian > library, and am interested in writing it. I would do so in DGJPP C (not > C++: too hard to interface with pascal (i think)), NASM assembly, and > possibly something else...however, I would need a few things first: > 1) your approval > 2) A standard (borland or watcom or something) Pascal library > reference (or one of each type to write multiple libraries :), with > descriptions of what each does etc. Bpcompat already exists, and as far I am aware most of the stuff is now incorporated in the gpc library. Ah, I have one suggestion - please add FillChar and StrPas to the main library.... > 3) A knowledge of how GNU Pascal calling convention works: (it should > interface nicely with DJGPP-C type, right?), offsets that function > paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), > etc. Did you look at the info file documentation? > If given the above, I would write a full-featured library for use > with GNU Pascal (or, at least, get pretty darn close :) that would be > almost 100% compatible with normal Pascal libraries, and I would also > maintain it, too :) > Yes, I realize that this may be a huge task (how long did it take > them to write the DJGPP2 libc? :), and that it would take a little > while, but hey, it sounds interesting :) and you could take that little > 'con' out of the cons section. In addition, non-C (but Pascal) > programmers could use your compiler because you'd have a > similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c > reference :). I use GNU PASCAL under unix and think that portability is a major asset of this compiler (and the fact it runs under solaris unix too!). What is needed is Pascal units with declarations translating the C include file definitions of system structures and the like. The problem is when we do them they are system specific (platform and OS) e.g. sockets programming under Solaris. Regards, Clyde

1 0

GNU Pascal: pascal library
by Iron Helix 07 Nov '98

07 Nov '98

An interesting project...Well anyways, I'm a programmer that knows cross-processor asm, C, C++, VC++, VB, Basic (eww), Euphoria (the predecessor to C (and Pascal?)), and am learning Pascal. Anyways, I noticed how GNU Pascal is lacking a standard Pascallian library, and am interested in writing it. I would do so in DGJPP C (not C++: too hard to interface with pascal (i think)), NASM assembly, and possibly something else...however, I would need a few things first: 1) your approval 2) A standard (borland or watcom or something) Pascal library reference (or one of each type to write multiple libraries :), with descriptions of what each does etc. 3) A knowledge of how GNU Pascal calling convention works: (it should interface nicely with DJGPP-C type, right?), offsets that function paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), etc. 4) A quick reference of GNU Pascal supported pointer types (far, near, huge), supported data types, how structures are setup 5) A reference of how the filetypes in the libraries are setup If given the above, I would write a full-featured library for use with GNU Pascal (or, at least, get pretty darn close :) that would be almost 100% compatible with normal Pascal libraries, and I would also maintain it, too :) Yes, I realize that this may be a huge task (how long did it take them to write the DJGPP2 libc? :), and that it would take a little while, but hey, it sounds interesting :) and you could take that little 'con' out of the cons section. In addition, non-C (but Pascal) programmers could use your compiler because you'd have a similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c reference :). NOTE: Just in case I wasn't clear, what I meant by writing a "standard Pascal lib" is writing the lib that is to Pascal as libc is to DJGPP :) Oh, and on the side, wouldn't it be an interesting thing to write a GNU Basic compiler that was _FAST_, had unsigned numbers, had more needed functions that aren't able to be made/used (i.e. an 'asm'-like command ;), used pointers, and some more stuff like being almost completely compatible with existing QBASIC programs and compiler-commands (i.e. '#include') and some more stuff? If you guys would want to do the lex. analyzer/compiler/etc. part, I'd write the library that would be the _FAST_ version of the normal BASIC lib...we could help BASIC programmers out there do alot better :) even tho it still wouldn't be as good as C... Anyways, thanx for your time. -Iron Helix ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: Automake
by Frank Heckenbach 06 Nov '98

06 Nov '98

Peter Gerwinski wrote: > > A library for gpi's would be nice? > > Any suggestion how this could be implemented? I suppose it could be done with `ar', just like with object libraries. However, I'm not sure if this will be really very important, once GPC has better automake and doesn't try to recompile unnecessarily. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 binary for DJGPP
by Frank Heckenbach 06 Nov '98

06 Nov '98

Hi, folks! A binary distribution of gpc-19980830 for DJGPP has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-19980830.i386-djgppv201.zip Greetings, Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Automake
by Thamm, Russell 06 Nov '98

06 Nov '98

I am having so much trouble with automake that I am considering abandoning GPC altogether. Everytime that I add a few more modules to my program, I have to spend several hours reorganizing units in order to get the program to compile. The only solution seems to be to combine all units into one giant unit. This is not really satisfactory. I keep running out of virtual memory on a machine with 256 MBytes of memory. My concern is that eventually my program will grow to a point where I won't be able to compile it at all. Or that compilation takes so long that development becomes impossible. Currently, the code only implements part of the GUI. Using a makefile is much better. I am not absolutely sure how to express the dependencies. Make seems to have no concept of a compilation producing more than one output file. I can get RHIDE to bypass automake by not specifying a primary file and adding all source files to the project. But Rhide apparently ignores the Uses clauses when determining dependencies and I ca't work out how to use user-defined dependencies with it. Does anyone know how I can use Rhide and avoid automake? Alternatively, is there some other solutions - A library for gpi's would be nice? Any options to indicate to automake that certain units don't need to be checked? I suspect that if automake kept track of the units not requiring compilation, things might improve.things. That is, the first time it checks grx20.pas, it should note that no recompilation is required rather than rechecking the same file many times. I'd be grateful for any advice. Russell Thamm

2 1

Another enumeration question
by Jo Dillon 05 Nov '98

05 Nov '98

Ok, I got it wrong with my previous question about enumerations, but what about this: (file babyunit2) unit babyunit2; interface type MyType = (a,b,c); implementation end. (file babyunit) unit babyunit; interface uses babyunit2; procedure printmytype(b : mytype); implementation procedure printmytype(b : mytype); begin writeln(ord(b)); end; end. (file baby) program baby; uses babyunit,babyunit2; var x : mytype; begin for x:=a to c do printmytype(x); end. [root@twentyfour aargh]# gpc -g -c -w babyunit2.pas [root@twentyfour aargh]# gpc -g -c -w babyunit.pas [root@twentyfour aargh]# gpc baby.pas babyunit2.o babyunit.o -o baby baby.pas: In function `program_Baby': baby.pas:19: incompatible type for argument 1 of `Printmytype' However, when I combine all three files like this: program baby; type MyType = (a,b,c); procedure printmytype(b : mytype); begin writeln(ord(b)); end; var x : mytype; begin for x:=a to c do printmytype(x); end. Everything works fine. Surely this has to be a compiler problem? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 3

Re: Another enumeration question
by Frank Heckenbach 05 Nov '98

05 Nov '98

Jo Dillon wrote: > Ok, I got it wrong with my previous question about enumerations, > but what about this: > > (file babyunit2) > [...] Yes, this seems to be the same bug as in russell2.pas, but I added your program to the test suite, anyway. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc November 1998