Gpc

gpc@gnu.de

5400 discussions

Re: pre compiled version
by Peter Gerwinski 15 Oct '97

15 Oct '97

According to Omar Abu Al-Haija: > Please Could any body tell me were I could find a precompiled version of > gnupascal , At any SimTel mirror, download `gpc20b.zip' from the DJGPP distribution. The same is available as a file `gpc-2.0.i386-djgppv201.zip' at ftp://kampi.hut.fi/jtv/gnu-pascal/binary/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/binary/ If you want to try out our recent beta versions, look at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ > plus any IDE to use with , I had IBM compatible computer , and most of my > work is under dos operating > system , [...] We recommend RHIDE. Get it from http://www.tu-chemnitz.de/~rho/rhide.html Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: bugs?
by Frank Heckenbach 15 Oct '97

15 Oct '97

fulvio ciriaco wrote: > Hallo! > I think I discovered two bugs. > I am using gpc-970714 beta version,on digital alpha > unix. > The first is very strange: > var i:integer; > read(f,i); > reads 110 in i if the file f begin with > 10 > but correctly reads 10 if f contains > <space>10 > The second is schematized in the following > PROCEDURE readdata; > VAR > f : bindable text; > c : BindingType; > i : integer; > BEGIN > WRITELN('dammi il file di input'); > READLN(c.name); > bind(f,c); > SeekRead(f,0); > END; > PROCEDURE printdata; > VAR > f : bindable text; > c : BindingType; > i : integer; > BEGIN > WRITELN('dammi il file di output'); > READLN(c.name); > bind(f,c); > SeekWrite(f,0); > END; > > f I believe should be local to readdata and printdata, > but calling printdata after readdata gives the error > ?Gpc: Object (0x11ffffba8) already bound to `inizia' > where inizia is the input file name. The reason for this problem is the list Bound_objects in the RTS which stores the addresses of all bound files with their names. The two files in the two procedures incidentally get the same address, so the RTS "thinks" they're the same. I don't know much about bindings and so, but I think it would be better to store the binding information only in the Text variables themselves, not (additionally) in a global list. So I'm asking the long-time GPC developers: is there any reason against removing the list, and Bound_free_list as well? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

bugs?
by system＠petrella.cfilm.ba.cnr.it 14 Oct '97

14 Oct '97

Hallo! I think I discovered two bugs. I am using gpc-970714 beta version,on digital alpha unix. The first is very strange: var i:integer; read(f,i); reads 110 in i if the file f begin with 10 but correctly reads 10 if f contains <space>10 The second is schematized in the following PROCEDURE readdata; VAR f : bindable text; c : BindingType; i : integer; BEGIN WRITELN('dammi il file di input'); READLN(c.name); bind(f,c); SeekRead(f,0); END; PROCEDURE printdata; VAR f : bindable text; c : BindingType; i : integer; BEGIN WRITELN('dammi il file di output'); READLN(c.name); bind(f,c); SeekWrite(f,0); END; f I believe should be local to readdata and printdata, but calling printdata after readdata gives the error ?Gpc: Object (0x11ffffba8) already bound to `inizia' where inizia is the input file name. unbind(f) eliminates the error message. I hope I were of any help Fulvio Ciriaco

1 0

pre compiled version
by OHMH＠nets.com.jo 14 Oct '97

14 Oct '97

Hi all Please Could any body tell me were I could find a precompiled version of gnupascal , plus any IDE to use with , I had IBM compatible computer , and most of my work is under dos operating system , I work on Borland Pascal v 7.0 . Thanks any way . Yours : Omer , Ohmh(a)nets.com.jo

1 0

Built-in string functions (was: New GPC beta: gpc-971001)
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Frank Heckenbach: > > It could also be a switch. But wouldn't it be "cleaner" to write it as a > function? "CStrFunc (Str2CStr (StrVar))" or so... Ah - you are referring to parameter passing. Yes, this will be built-in, so you can just write "CStrFunc ( StrVar )". > > What functions do you mean? Built-in replacements for BP's functions from > > the `Strings' Unit? > > Of course, they could be external functions as well. It's no problem to > implement them in Pascal. But I think in the long run, all such standard > functions will be built-in. You are right that it would be easy to provide these functions as built-in features once we have solved this problem for parameter passing. Since there already is a de-facto standard in BP how to name these functions we should use that. Everything okay, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Problem building New GPC beta: gpc-971001 for DJGPP v2.1
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Maurice Lombardi: > > I have tried to build gpc-971001 from the zip sources for DJGPP v2.01 > I use plain DOS with or without bash shell: > > -unzip fresh new gcc-2721 in directory %DJDIR%\gnu\ > -unzip gpc sources to %DJDIR%, then put the p\ tree as subdirectory > of gcc-2721 > > then follow instructions contained in p\config\msdos\readme2.dj. > > It builds gcc, but then stops without building gpc ? Strange. :-( Anyway, when you have reached this step, the following is known to work: `cd' to `\djgpp\gnu\gpc\p' and do `make ../xgpc', `make ../gpc1', `make ../gpc-cpp', and `make ../libgpc.a' from there. This builds the respective `.exe' files, although we do *not* specify the extension `.exe'. After that, move the `.exe's to `\djgpp\bin', and `libgpc.a' to '\djgpp\lib' to install. > Other problems found: > > 1- the p\config\msdos\configur.bat must be in dos format > (return-linefeed) to run in plain dos [...]. Fixed. > 2- there is a problem with backward slashes \ in the makefile in lines > like > ./bi-arity < $(srcdir)\bytecode.def >tmp-bc-arity.h > (three times). Seems to come from the application of > gnu\gcc-2721\config\msdos\top.sed and is already present in the > compilation of gcc alone. I have filed a bug report to dj delorie, > and fixed it manually after running configure go32 which produces this > makefile. So there is nothing we could do about that ... may I ask you to document it in `README2.DJ'? > 3- [`.gdbinit' vs. `_gdbinit'] Okay. It will be fixed in the next `.zip' release. Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: Strings and PChars
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > Now, that is the interesting bit. Both permutations give a wrong result > in BP (DOS real mode and DOS DPMI), but give correct results in > BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? Not really. Since they're relying on more or less undefined things (such as the contents of the stack area next to some parameter), the behaviour can easily be different on different platforms. It could even be different on the same platform (e.g. in Dos when loaded at different addresses -- or under a debugger). That's the kind of bugs that's hard to track. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: New GPC beta: gpc-971001
by Frank Heckenbach 13 Oct '97

13 Oct '97

Peter Gerwinski wrote: > > - One that always makes a copy on the stack and copies the string into it. > > That's the secure way, but inefficient with very long strings. > > Concerning CStrings? You mean a switch? It could also be a switch. But wouldn't it be "cleaner" to write it as a function? "CStrFunc (Str2CStr (StrVar))" or so... > > - One that allocates the memory on the heap. This is needed when the > > resulting CString is to be used outside of the current scope (when it's > > not only passed to a function). > > > > - One that copies the string in a buffer allocated by the programmer (this > > is perhaps only for compatibility with BP's StrPCopy). > > What functions do you mean? Built-in replacements for BP's functions from > the `Strings' Unit? Of course, they could be external functions as well. It's no problem to implement them in Pascal. But I think in the long run, all such standard functions will be built-in. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by The African Chief 13 Oct '97

13 Oct '97

On Mon, 13 Oct 1997 02:36:00 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >> >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); >> > >> >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" >> >to do? AFAICS, it copies a string into itself!? >> >> More or less. Since it is already itself, nothing really should happen, >> but the side effect is that it provides the input for StrNew to work with, > >You could just write "Str2pChar := StrNew ( @s[1] );" True. >which gives the same (wrong) result in BP. Now, that is the interesting bit. Both permutations give a wrong result in BP (DOS real mode and DOS DPMI), but give correct results in BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > No, it shouldn't. Maybe we are at cross purposes here. My original > meaning was: if I write "str1 := str2", that is precisely what I should > get - no more, no less. I should get in "str1" the exact number of > characters that are in "str2", in the exact order - no more, no less. > If an optimiser gives me that, I don't really care what else it does ... Exactly. The number of characters is given in the length. Anything beyond the length (such as the #0 terminator in your first version) is undefined. > Okay, I understand that now ;-). However, this solution will not > work if there is a maximum length for the string, and the string > that is passed to the function has already reached that length. True. For (long) string, we can solve this by implicitly making the schema bigger by 1 char than declared, but for short strings, this is not possible without breaking BP compatibility, so we need to copy them. (OTOH, it's not so bad there, since they can be only 255 chars long, so there isn't too much overhead.) > >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); > > > >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" > >to do? AFAICS, it copies a string into itself!? > > More or less. Since it is already itself, nothing really should happen, > but the side effect is that it provides the input for StrNew to work with, You could just write "Str2pChar := StrNew ( @s[1] );" which gives the same (wrong) result in BP. > >OTOH, if you're using the strings unit anyway, is there anything wrong with > >StrPCopy? > > If I used this routine in the system unit, I would not be using the > strings unit there - but I can import "strcpy" from the C library, > and call it "StrCopy". Perhaps something like (NOT tested): Function Str2pChar ( s : String ) p : pChar; begin GetMem (p, Length(s) + 1); Move (s[1], p^, Length(s)); p[Length(s)] := #0 end; -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

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