Gpc

gpc@gnu.de

5400 discussions

graphic
by Nathalie Jarosz 22 Jun '00

22 Jun '00

Hello all! I just wonder if it is possible to plot some graphs with pascal? If the answer is yes, how it works? And if not, how can I use my output files to easily generate graphs? Thanks for your help, Nathalie

3 2

beta distribution
by Nathalie Jarosz 22 Jun '00

22 Jun '00

Hello all again! Another question. I have some numerical recipies for pascal downloaded from a website but I don't have the program for a beta distribution. Is someone got it? thanks a lot in advance, Nathalie

2 1

Problem with last patch of grx23
by Maurice Lombardi 21 Jun '00

21 Jun '00

http://www.gnu.de/software/GRX/grx23.update.000520.gz 1 - it is not gzipped 2 - four hunks failed (with respect to the original grx23.zip, no update) in highlow.h grdriver.h makebase.dj and makefile.bcc two (in makebase.dj and makefile.bcc) contain "return return linefeed" instead of "return linefeed" as end of lines dtou solves that the other are cosmetic changes (some extra spaces to align consecutive lines) which seem different between your version of "original" grx23 and the one on simtelnet. The best is probably to make fresh new diffs rather than to try to modify the present diff file. 3 - more seriously, compiling tests on grx23 fails at the first file (arctest.c) for not finding GrLine. The problem seems that the src/bgi/line.c coming from bcc2grx (which is merged now) shadows in the merged library libgrx20.a the src/draw/line.c which comes from the original grx23 (and which contains the function GrLine() ). This was not a problem with the old setup where compiling with -lbcc2 -lgrx20 (for bcc2grx) or simply -lgrx20 for pure grx solved the problem. In fact looking to the output of the "ar -rv" command in the make command I see that indeed bgi/line.o is replaced (flagged r) instead of to be added (a). And the same is true for polygon.o fillpatt.o and fillpoly.o according to the same listing. Since the problem is with the filenames, not with the functions which they contain (the systematic prefix Gr in libgrx avoids that), I have renamed these four files (in src/bgi) as lineb.c polygonb.c fillpatb.c and fillpolb.c and modified accordingly src/stdobjs.mak. All compiles without problem now. All tests run perfectly except for one in bccbgi: the sierpinski test (i.e. the first floodfill test), while the snake test (the second floodfill) works. In looking to floodfill() contained in src/bgi/fldfill.c I see that you have changed the content of that function with respect to old BCC2GRX to call directly grx functions. If I restore the old content by replacing at the beginning of the floodfill() function: #if (GRX_VERSION_API-0)>=0x0225 by #if 0 everything works perfectly. I have not tried to understand further. 4 - A directory grx23/chr containing the .chr files (which are presently in src/bgi) should be included in order that the character tests work (or replace the BGI_PATH in the tests programs, but creating a chr directory analogous to the font directory seems better). 5 - I have tried the pascal tests. They work except for two problems which were already presents in previous versions of grx and bgi2grx. - pascal/bgi/demos/color.pas fails due to an invalid typecast between real and word. Replacing word() by a function realtoword() which rounds the real corrects it. - the polygon tests (DrawPoly and FillPoly) in pascal/bgi/demos/demo.pas fail due to a problem when transferring "open arrays" parameters between pascal and C for recent alphas of gpc. gpc pushes in that case an extra parameter on the stack so that "var Polypoints: array of PointType" in pascal is no more equivalent to "PointType *Polypoints" in C, because C pushes only the address of Polypoints. The trick is to use in the pascal unit an untyped variable "var Polypoints" which pushes also only the address of Polypoints on the stack. With this correction the demo program works perfectly. It is necessary to change that way pascal/bgi/bgi2grx.pas and also pascal/grx20.pas (I have no test program at hand to check in that case however). Hope this helps. -- 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

2 1

Debugging GPC compiled code with GDB
by Pierre Muller 16 Jun '00

16 Jun '00

I got the djgpp binary distribution of GPC and made some tests with my pascal aware GDB. But if I compile a simple program (similar to hello word ) and a start GDB and insert a breakpoint at main (which is what allmost vevery body would do in C, and that works as expected with Free Pascal compiled code) If I then use "run" the program stops at the end of the main code, which is rather odd! If this a known problem and is it or will it be fixed. The source code used follows I wanted to test the internal form of string to see if I could support it ! program test_gpc(input,output); type string32 = string[32]; var s1, s2 : string32; begin s1:='It '; s2:=s1+'works'; Writeln('It works'); Writeln(s2); end. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

2 1

Re: Debugging GPC compiled code with GDB
by Pierre Muller 16 Jun '00

16 Jun '00

> the program stops at the end of the main code, which is rather odd! Whoops, it seems that this was due to a problem of wrong linker or gcc version recompiling from djgpp bin dir gives something a little bit better : the main break works and the program is indeed stopped before the main procedure but nevertheless main has no line info and thus "next" command will go right to the end ! Couldn't the startup code be integerate at begin of the main code directly ? This way "next command would stop at the begin of the line s1:='It'; > program test_gpc(input,output); >type > string32 = string[32]; >var >s1, s2 : string32; >begin > s1:='It '; > s2:=s1+'works'; > Writeln('It works'); > Writeln(s2); >end. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

1 0

None
by FSR SoWi 16 Jun '00

16 Jun '00

unsubscribe gpc

1 0

Solaris 7 Sparc binaries of GPC
by Anuradha 15 Jun '00

15 Jun '00

Hello, When we use this zip file from the directory you specified.We are not able to understand it. For eg.,It says, "From a directory of your choice (e.g.@: @file{/usr/local/src}), unpack the GNU CC and GNU Pascal source distributions. This will create separate subdirectories for GCC and GPC." Where are the source distrinbutions then? Thanks and regards, Anuradha > Subject: Solaris 7 Sparc binaries of GPC > From: mariusz(a)math.uwb.edu.pl > To: NAGARAJ.BATNI/OU=DCCH1(a)bt0200.net.alcatel.be > > Nagaraj Batni wrote: > > > > Hello , > > > > We tried downloading the package from the site you had mentioned > > Nice to know that my packages are usefull. Thanks. > > > But when i unzip it with gunzip it gives a error message saying "invalid > > compressed data--format voilated".gtar is not working in my system. > > Solaris 7 comes with unzip, so I put this package into zip archive. > It is available at: > > > ftp://mizar.uwb.edu.pl/pub/misc/solaris7/sparc/gpc-2.1-19991030-Solaris7-sparc.pkg.zip > > Hope you will get it working > > -- > . > Mariusz Zynel > > Institute of Mathematics | phone: +48 (85) 745 75 52 > University of Bialystok | > Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl > 15-267 Bialystok | > Poland | http://math.uwb.edu.pl/~mariusz/

2 1

None
by FSR SoWi 15 Jun '00

15 Jun '00

unsubscribe

1 0

Re: [Fwd: Re: Absolute in Pascal]
by Frank Heckenbach 15 Jun '00

15 Jun '00

Maurice Lombardi wrote: > 1 - djgpp is a linear frame 32 bits system. It does not know about Segment:Offset addresses. > > 2 - djgpp is a protected mode system libe BP (not TP): The address even in BP would be Selector:Offset instead of > Segment:Offset. You would need to replace Const BiosSeg=$40 by Const BiosSeg=seg0040 (BP takes care to put the correct > selector instead of $40 in seg0040). > > 3 - there are a lot of functions to address physical memory in the djgpp's libc: look at _dpmi... functions by info > libc. > But probably the simplest would be to look to _far* functions (_farpeekb etc...) to peek/poke values at such addresses > with a minimum effort. You just have to declare these functions in your pascal program with asmname to make them known, > e.g. > > function farpeekb(selector:ShortWord; offset:MedWord): byte; asmname "_farpeekb"; > > please read carefully the explanation in the _far* section of the info libc on how to use these functions (get > selectors...) Besides, if you want to get the screen size, you can use `ScreenSize' in the CRT unit. For other things where you need to access BIOS variables in TP, there are also Pascal routines available in GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

[Fwd: Re: Absolute in Pascal]
by Maurice Lombardi 15 Jun '00

15 Jun '00

-------- Original Message -------- Objet: Re: Absolute in Pascal Date: Thu, 15 Jun 2000 12:33:10 +0200 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: Penza Kenneth at MITTS <kenneth.penza(a)magnet.mt> RÃ©fÃ©rences: <JA8AAAAABE1ZiAABYQABlXwdgctU(a)magnet.mt> Penza Kenneth at MITTS a Ã©crit : > > I am tring to compile a unit that defines some bios variable which does compile > under TP 7.0. However when I use gpc I get the following messages. > > bios.pas:18: warning: variables at absolute adresses may cause problems > bios.pas:18: missing semicolon > bios.pas:18: parse error before `:' > > Part of the coding is as follows. > INTERFACE > CONST BiosSeg = $40; > > VAR > ScrnCols : BYTE ABSOLUTE BiosSeg :$4a; 1 - djgpp is a linear frame 32 bits system. It does not know about Segment:Offset addresses. 2 - djgpp is a protected mode system libe BP (not TP): The address even in BP would be Selector:Offset instead of Segment:Offset. You would need to replace Const BiosSeg=$40 by Const BiosSeg=seg0040 (BP takes care to put the correct selector instead of $40 in seg0040). 3 - there are a lot of functions to address physical memory in the djgpp's libc: look at _dpmi... functions by info libc. But probably the simplest would be to look to _far* functions (_farpeekb etc...) to peek/poke values at such addresses with a minimum effort. You just have to declare these functions in your pascal program with asmname to make them known, e.g. function farpeekb(selector:ShortWord; offset:MedWord): byte; asmname "_farpeekb"; please read carefully the explanation in the _far* section of the info libc on how to use these functions (get selectors...) Hope this helps -- 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

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