Gpc

gpc@gnu.de

5400 discussions

Re: What is the latest ver of gpc?...
by Frank Heckenbach 11 Nov '98

11 Nov '98

Orlando Llanes wrote: > Doh! Sorry for the typo, I downloaded 19980830 and it says that > BlockRead is undeclared :( I can't reproduce it. Can you send a test program, please? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Ellipsis formal parameter & CRT module questions...
by kc7rad＠vegasnet.net 11 Nov '98

11 Nov '98

Two quick questions... 1) According to the HTML docs, ellipsis (...) are allowed in formal parameters but the code has no way (yet) of accessing them. If I specify procedure printf(cpFmt : cstring; ...); C; in a program & use it in that program, I can pass as many actual parms as I want. If I specify this in the 'interface' section of a UNIT, I cannot pass more than one parm to the procedure without the compiler stating that I passed too many parameters. I can come up with a work-around but if this will work in the next release, I won't worry about it. 2) According to http://fjf.gnu.de/gpc-todo_6.html#SEC6 (Implemented features) there is a portable ncurses CRT unit. Is this built into the RTL (I couldn't find it on first look) or is it a seperate unit (or module)? TNX! and BTW, GREAT WORK EVERYBODY! Ken L. kc7rad(a)vegasnet.net

2 1

ncurses
by Matthew Wiggins 11 Nov '98

11 Nov '98

I was tring to use ncurses in a pascal program. and I defined a packed record of the WINDOW type, but how do I import the stdscr etc etc so I can use the functions? I guess some people have done it. I'm not sure... /Matthew Wiggins bong.triax.com

1 0

compiling with grx20 under RHIDE
by Robert P. Ewing 10 Nov '98

10 Nov '98

Hello, all. I am having trouble with compiling grx20-using programs under RHIDE. Specifically, I can't seem to compile BLT_TEST.PAS under RHIDE, even though I *can* compile it successfully from the command line. >From the command line, the program compiles with: gpc -g --automake="-g" -o blt_test.exe blt_test.pas -lgrx20 I report this with gratitude to Maurice Lombardi, who patiently walked me through the procedure and sent me several files I was missing. >From RHIDE, if the grx20.o and grx20.gpi files are present, I get: ../Pascal/blt_test.pas (3) Error: module/unit Interface 'Grx20' could not be imported. If the grx20.o and grx20.gpi files are not present, I get: ../Pascal/blt_test.pas (3) Error: module 'Grx20' could not be compiled Compiler options such as --automake="-g" and -lgrx20 have no apparent effect. I am greatly encouraged that I have gotten the program to compile, but it seems that it ought to compile under RHIDE too (that is, after all, some of the point of RHIDE!). Any suggestions? Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University

2 2

RE: Automake
by Thamm, Russell 09 Nov '98

09 Nov '98

Thanks Peter, This weekend I wrote a quick and dirty program to produce a makefile from the USES clauses in the main pascal program and all the used files. It doesn't support included files. I then define the environment variable: RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=make -f$(subst .exe,.mk,$(OUTFILE)) This seems to work pretty well despite the fact that RHIDE maintains its own list of dependencies. Following is a sample makefile produced by the command: mkdep demo ticks.o lgrx20 %.o %.gpi: %.pas gpc -g -c $< all::demo.exe DEPS_demo=colors.gpi objects.gpi cydriver.gpi cyviews.gpi cybutton.gpi windows.gpi plots.gpi axes.gpi graph.gpi arrplot.gpi evedisp.gpi DEPS_colors= DEPS_objects=colors.gpi DEPS_cydriver=colors.gpi objects.gpi DEPS_cyviews=objects.gpi colors.gpi cydriver.gpi DEPS_cybutton=objects.gpi colors.gpi cydriver.gpi cyviews.gpi DEPS_windows=objects.gpi cydriver.gpi cyviews.gpi colors.gpi cybutton.gpi DEPS_plots=colors.gpi coords.gpi clip.gpi objects.gpi cyviews.gpi DEPS_axes=colors.gpi coords.gpi objects.gpi plots.gpi DEPS_graph=objects.gpi plots.gpi axes.gpi DEPS_arrplot=colors.gpi rfarray.gpi objects.gpi cydriver.gpi plots.gpi axes.gpi DEPS_evedisp=colors.gpi objects.gpi cydriver.gpi cyviews.gpi DEPS_coords= DEPS_clip= DEPS_rfarray=colors.gpi objects.gpi coords.gpi plots.gpi axes.gpi OBJS=colors.o objects.o cydriver.o cyviews.o cybutton.o windows.o plots.o axes.o graph.o arrplot.o evedisp.o coords.o clip.o rfarray.o ticks.o demo.o:demo.pas $(DEPS_demo) colors.o colors.gpi:colors.pas $(DEPS_colors) objects.o objects.gpi:objects.pas $(DEPS_objects) cydriver.o cydriver.gpi:cydriver.pas $(DEPS_cydriver) cyviews.o cyviews.gpi:cyviews.pas $(DEPS_cyviews) cybutton.o cybutton.gpi:cybutton.pas $(DEPS_cybutton) windows.o windows.gpi:windows.pas $(DEPS_windows) plots.o plots.gpi:plots.pas $(DEPS_plots) axes.o axes.gpi:axes.pas $(DEPS_axes) graph.o graph.gpi:graph.pas $(DEPS_graph) arrplot.o arrplot.gpi:arrplot.pas $(DEPS_arrplot) evedisp.o evedisp.gpi:evedisp.pas $(DEPS_evedisp) coords.o coords.gpi:coords.pas $(DEPS_coords) clip.o clip.gpi:clip.pas $(DEPS_clip) rfarray.o rfarray.gpi:rfarray.pas $(DEPS_rfarray) demo.exe: demo.o $(OBJS) gpc -odemo.exe -g demo.o $(OBJS) -lgrx20 Russell > -----Original Message----- > From: Peter Gerwinski [SMTP:peter@gerwinski.de] > Sent: Friday, November 06, 1998 10:24 PM > To: Thamm, Russell > Cc: gpc(a)hut.fi > Subject: Re: Automake > > Thamm, Russell wrote: > > I am having so much trouble with automake that I am considering > abandoning > > GPC > > altogether. > > [...] > > :-( > > > I keep running out of virtual memory on a machine with 256 MBytes of > memory. > > This looks like a circular dependency between some units. > > > Using a makefile is much better. > > Our current project (together with the related issue of > re-writing the GPI mechanism) is to re-implement the AutoMake > mechanism using `make'. > > > I am not absolutely sure how to express the > > dependencies. > > To get the (*$include ... *) dependencies, run `gpc -M foo.pas'. > It will produce a rule > > foo.o: foo.pas foobar.incl foobaz.incl > > you only need to extend by adding the gpi files of the units > used by this one and the action `gpc -c $(PFLAGS) foo.pas'. > The result will look like the following: > > foo.o: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > > Make seems to have no concept of a compilation producing more than one > > output file. > > If you duplicate the rule above for the GPI file, > > foo.o: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > foo.gpi: foo.pas foobar.incl foobaz.incl bar.gpi: > gpc -c $(PFLAGS) foo.pas > > then `make' will nevertheless compile `foo.pas' only once (at > least according to my tests with GNU make:-). > > > 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. > > What about producing a Makefile with RHIDE and adding the > `uses' dependencies manually? > > > A library for gpi's would be nice? > > Any suggestion how this could be implemented? > > > Any options to indicate to automake that certain units don't need to > be > > checked? > > Nope. But if AutoMake does not see the source, it will not try > to recompile. > > > 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. > > Indeed. That's one reason why we think that `make' should be > invoked instead of `gpc1' duplicating the features of `make'. > > Greetings, > > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980830 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

What is the latest ver of gpc?...
by Orlando Llanes 08 Nov '98

08 Nov '98

Is it 19980803? The reason I ask is because I had to do the seasonal reformatting of the drive, reinstalled GPC, and now it's telling me that BlockRead is undeclared :( See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc