Gpc November 1998

gpc@gnu.de

18 participants
47 discussions

Re: odd bug with constants
by Frank Heckenbach 11 Nov '98

11 Nov '98

Robert P. Ewing wrote: > I've been moving an old program over to GPC, and ran across > the following. Apparently the '**' operator works fine on > variables, but it crashes if I put a hard-coded numerical > value in for the base. The old y^x = exp(y ln x) > workaround from Turbo seems to work fine. I don't know whether > this is a new or a known bug. This seems to be a bug in how the arguments to some operations on LongReal's (aka Extended) are passed, and real constants are assumed Extended by default. I added it to the bug list. Thanks for the report. > I note that if I write 'real(10.0)' rather than '10.0', the > program runs just fine... This would indeed be a useful workaround for now. (But AFAIR, TP doesn't like this -- if that's of any concern to you...) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

odd bug with constants
by Robert P. Ewing 11 Nov '98

11 Nov '98

Hi, all. I've been moving an old program over to GPC, and ran across the following. Apparently the '**' operator works fine on variables, but it crashes if I put a hard-coded numerical value in for the base. The old y^x = exp(y ln x) workaround from Turbo seems to work fine. I don't know whether this is a new or a known bug. Toby Ewing ewing(a)iastate.edu 515/294-7856 http://www.agron.iastate.edu/soilphysics/ewing.html Soil Scientist, Iowa State University --------------------------------------------------- program StarStar(input, output); var y : real; x : real value 10.0; begin writeln('via exp(x ln y):'); {all these are fine} y := 5.557; write('variables, y > 0 '); writeln('exp(y ln x) = ', exp(y * ln(x))); y := -5.557; write('variables, y < 0 '); writeln('exp(y ln x) = ', exp(y * ln(x))); y := 5.557; write('constants, y > 0 '); writeln('exp(y ln x) = ', exp(y * ln(10.0))); y := -5.557; write('constants, y < 0 '); writeln('exp(y ln x) = ', exp(y * ln(10.0))); readln; writeln('via y ** x:'); {now for problems} y := 5.557; write('variables, y > 0 '); writeln(' x ** y = ', (x ** y)); y := -5.557; write('variables, y < 0 '); writeln(' x ** y = ', (x ** y)); y := 5.557; write('constants, y > 0 '); writeln(' x ** y = ', (10.0 ** y)); { <--- crashes here } y := -5.557; write('constants, y < 0 '); writeln(' x ** y = ', (10.0 ** y)); { <-- or, if you prefer, here } end. I note that if I write 'real(10.0)' rather than '10.0', the program runs just fine...

1 0

Re: ncurses
by Frank Heckenbach 11 Nov '98

11 Nov '98

Matthew Wiggins wrote: > 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? The simple answer is var StdScr : asmname 'stdscr' WINDOW; but please read on... > I guess some people have done it. I'm not sure... Yes, I've done it (when writing a BP compatible CRT unit), and the way I did it was via a C layer. So I made a file crtc.c which #include's <ncurses.h> and defines some routines on top of that. These routines are declared as "C;" in crt.pas (the Pascal unit). Some other routines in crt.pas are implemented in Pascal, but they only call the routines from crtc.c, not directly those from ncurses. The reason why I did it this way is because that guarantees some portability. E.g., the WINDOW type might change in different releases of ncurses, or in different curses libraries. -- In fact, there is a library called PDCurses which is widely ncurses compatible, but, not surprisingly, the internal structure of its WINDOW type is quite different. In the CRT unit, however, I can just drop in PDCurses for ncurses, and it works, because the only routines that need to know about the internals (and if only about the size of the WINDOW type) are written in C and can read the ncurses.h header. Of course, the better solution, as I pointed out in some other mails to this list, would be an automatic C header to Pascal translator which is quite a difficult thing to write. Anyone wants to try? -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Ellipsis formal parameter & CRT module questions...
by Frank Heckenbach 11 Nov '98

11 Nov '98

kc7rad(a)vegasnet.net wrote: > 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)? It hasn't been published yet, but will be soon... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

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

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