- Gpc - gnu.de

Re: also Pre compiled version
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to Omar Abu Al-Haija: > I get precompiled version , Djgpp from gnu pascal , > I try to compile a file , it give me an error message : - > > Gpc.exe : installation problem , cannot exec 'as': No such file or directory > ( Enoent ) . > > [...] > > Ps I had no dpmi loader , and no gnu assembler , or debugger . You need the DJGPP development tools. The GNU Pascal FAQ list says: 8< ---- GPC FAQ ------------------------------------------------------- [22]What do I download? As discussed in section 2.2, other than GPC itself, you need an assembler, linker and friends, a C library and possibly a debugger. From your local djgpp mirror, you can get these as: v2/djdev201.zip (C library) v2gnu/bnu270b.zip (assembler, ....) v2gnu/gdb416b.zip (debugger) The rest is up to you; `make' (v2gnu/mak375b.zip) can be useful, The latest RHIDE test release (an IDE with Borland-look) has support for GNU Pascal, and can be downloaded from: http://www.tu-chemnitz.de/~rho/rhidetest.html 8< -------------------------------------------------------------------- Remarks: * `rhidetest.html' is now `rhide.html'. * You can download this from any SimTel mirror. One is ftp://ftp.ruhr-uni-bochum.de/pub/simtelnet/gnu/djgpp/, but you will probably find one closer to your place. 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: complex numbers
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to fulvio ciriaco: > I notice that complex and real numbers cannot be mixed > in mathematical expressions. > The standard tells nothing, to my knowledge, about real > being converted automatically to complex, but most > compilers of other languages do exactly that. > I think the following expressions would be not only more > confortable but also more efficient than the equivalent > explicit conversion, since one cannot directly access to > the real and imaginary fields of complex records: [...] I agree in complete. I will see how difficult it is to implement these features. If they don't make too much trouble they might be in the next beta. 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: Gpc not accepting non-standard (?) systax.
by Frank Heckenbach 21 Oct '97

21 Oct '97

richard.kerry(a)quantel.com wrote: > Thank you for your help with the C/external problem, I've removed > 'external' and that part is now happy. Fine! :-) > Regarding the second problem, concerning a structured constant, or at least > what seems to be the gpc technique to achieve the effect of a structured > constant : > > The full chain of defs is as follows : > > const > mArgName = 16; > > type > ArgType = (OutputFileArg, InputFileArg, OptionsArg); > ArgClass = (StringArg, FileArg, NullArg); > ArgStatus = (RequiredArg, OptionalArg); > > ArgName = packed array[1..mArgName] of char; > iArgName = 0..mArgName; > > ArgDef = record > name: record > txt: ArgName; > amin: iArgName; > len: iArgName; > end; > pos: integer; > status: ArgStatus; > aclass: ArgClass; > end; > > ArgDefTable = array[ArgType] of ArgDef; > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > (('Output_File ', 1, 11), 2, OptionalArg, FileArg), > ... ); > > var > kludge : ArgDefs ; > I hope this is sufficient for you to sort out my problem. It compiled > successfully under gpc-970824 but fails under 971001. I think this is a form of the known problem. I'm surprised it did compile under gpc-970824 (I don't have this version here to check). Anyway, what you could do (until this problem is solved which might take some time) is to declare the constant values not with the type but rather with the variable(s). Though structured constants do not yet work completely like ISO requires, I guess your example should work. Try something like: [types until ArgDefTable, no type ArgDefs] var kludge : ArgDefTable value (...); Of course, if you have multiple such variables, you have to do this multiple times, which is not so nice. There could be a possible "dirty" solution using the preprocessor, something like: {$define ArgDefs ArgDefTable value (...)} var klugde : ArgDefs; -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Gpc not accepting non-standard (?) systax.
by richard.kerry＠quantel.com 20 Oct '97

20 Oct '97

heckenb(a)mi.uni-erlangen.de on 20/10/97 15:14:59 To: gpc(a)hut.fi cc: (bcc: Richard Kerry/Quantel Research) Subject: Re: Gpc not accepting non-standard (?) systax. richard.kerry(a)quantel.com wrote: > The 'C' directive on external procedures. > > FUNCTION _p_paramcount : Integer; C; > EXTERNAL ; > FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; > EXTERNAL ; > > It says : > : parse error before `External' The "C" directive implies "external". Earlier GPCs have accepted the above, the newer versions don't anymore. Just using "C" should do what you want. (Apart from this, there are still plans to make a more consistent syntax for C/External/AsmName... sometime...) > If I comment these out it fails on a structured constant definition using > 'value'. > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > etc... > > It says : > : parse error before `Value' > : invalid schema discriminants > > If I comment out 'value' it says > : parse error before `,' > : missing expression > : discriminated type is not a schema or string > : parse error before `,' > > Is there some configuration I need to do to make these work ? Or have I > found a bug ? If ArgDefTable is an array or record (or a combination of these), this is a known problem (since I don't know if this is required by the standard, I'm not sure if it's a bug or just a missing feature ;-). It's listed in my To-Do list at http://www.mi.uni-erlangen.de/~heckenb/gpc-todo_toc.html in the section "Records/arrays". If, however, a schema type is involved (the error messages say something about these), it might help to see the declaration of ArgDefTable. Did you perhaps use "string" without a maximum length? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm Thank you for your help with the C/external problem, I've removed 'external' and that part is now happy. Regarding the second problem, concerning a structured constant, or at least what seems to be the gpc technique to achieve the effect of a structured constant : The full chain of defs is as follows : const mArgName = 16; type ArgType = (OutputFileArg, InputFileArg, OptionsArg); ArgClass = (StringArg, FileArg, NullArg); ArgStatus = (RequiredArg, OptionalArg); ArgName = packed array[1..mArgName] of char; iArgName = 0..mArgName; ArgDef = record name: record txt: ArgName; amin: iArgName; len: iArgName; end; pos: integer; status: ArgStatus; aclass: ArgClass; end; ArgDefTable = array[ArgType] of ArgDef; type ArgDefs = ArgDefTable value ( ((' ', 1, 0), 0, OptionalArg, NullArg), (('Output_File ', 1, 11), 2, OptionalArg, FileArg), ... ); var kludge : ArgDefs ; I hope this is sufficient for you to sort out my problem. It compiled successfully under gpc-970824 but fails under 971001. Thank You, Richard Kerry.

1 0

Re: Gpc not accepting non-standard (?) systax.
by Frank Heckenbach 20 Oct '97

20 Oct '97

richard.kerry(a)quantel.com wrote: > The 'C' directive on external procedures. > > FUNCTION _p_paramcount : Integer; C; > EXTERNAL ; > FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; > EXTERNAL ; > > It says : > : parse error before `External' The "C" directive implies "external". Earlier GPCs have accepted the above, the newer versions don't anymore. Just using "C" should do what you want. (Apart from this, there are still plans to make a more consistent syntax for C/External/AsmName... sometime...) > If I comment these out it fails on a structured constant definition using > 'value'. > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > etc... > > It says : > : parse error before `Value' > : invalid schema discriminants > > If I comment out 'value' it says > : parse error before `,' > : missing expression > : discriminated type is not a schema or string > : parse error before `,' > > Is there some configuration I need to do to make these work ? Or have I > found a bug ? If ArgDefTable is an array or record (or a combination of these), this is a known problem (since I don't know if this is required by the standard, I'm not sure if it's a bug or just a missing feature ;-). It's listed in my To-Do list at http://www.mi.uni-erlangen.de/~heckenb/gpc-todo_toc.html in the section "Records/arrays". If, however, a schema type is involved (the error messages say something about these), it might help to see the declaration of ArgDefTable. Did you perhaps use "string" without a maximum length? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Gpc not accepting non-standard (?) systax.
by richard.kerry＠quantel.com 20 Oct '97

20 Oct '97

I have just :- 1. Moved to a newly set up, tidy, Linux machine (i586-pc-linux). 2. Built a Linux native gpc-971001 for the first time. (970824 didn't build as it required a pre-existing gpc which I had on my old, untidy, machine but don't have on the new one) I find :- When I try to compile a program that compiled sucessfully under 970824 on the old machine it now fails to compile. It is complaining about some features that I know aren't new and I thought were standard gpc. The 'C' directive on external procedures. FUNCTION _p_paramcount : Integer; C; EXTERNAL ; FUNCTION _p_paramstr (num: Integer; VAR str: String): Boolean; C; EXTERNAL ; It says : : parse error before `External' If I comment these out it fails on a structured constant definition using 'value'. type ArgDefs = ArgDefTable value ( ((' ', 1, 0), 0, OptionalArg, NullArg), etc... It says : : parse error before `Value' : invalid schema discriminants If I comment out 'value' it says : parse error before `,' : missing expression : discriminated type is not a schema or string : parse error before `,' Is there some configuration I need to do to make these work ? Or have I found a bug ? Yours in anticipation, Richard Kerry.

1 0

also Pre compiled version
by OHMH＠nets.com.jo 18 Oct '97

18 Oct '97

I get precompiled version , Djgpp from gnu pascal , I try to compile a file , it give me an error message : - Gpc.exe : installation problem , cannot exec 'as': No such file or directory ( Enoent ) . I have set the the place where is dgjpp.env is . is this mean I haven't get all the files , as I think , I had the files : djgpp.env <bin> gpc1.exe gpc.exe <doc> <info> <lib> libgpc.a libgcc.a specs.gpc <manifest> gpc20.mft gpc20.ver <test> If i need to add more files to put me in the right way , could you please tell me where I could find those files exactly and their names , ftp would be more useful www for me , because I don't have full internet just email , if any body could lead me to compile any simple file like begin write(' Hello '); end. I will be thankful . Ps I had no dpmi loader , and no gnu assembler , or debugger . Sorry for my bad english .

1 0

complex numbers
by system＠petrella.cfilm.ba.cnr.it 17 Oct '97

17 Oct '97

I notice that complex and real numbers cannot be mixed in mathematical expressions. The standard tells nothing, to my knowledge, about real being converted automatically to complex, but most compilers of other languages do exactly that. I think the following expressions would be not only more confortable but also more efficient than the equivalent explicit conversion, since one cannot directly access to the real and imaginary fields of complex records: complex=real complex*/real complex+-real I also imagine such operations are supported by pxsc so it would be a step forward compatibility. I wish to express my greetings for developers' work, attested by the continuous improvement of the features of gpc. Best wishes Fulvio Ciriaco.

1 0

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

15 Oct '97

According to Maurice Lombardi: > According to myself (Peter Gerwinski): > > `cd' to `\djgpp\gnu\gpc\p' and do `make ../xgpc', `make ../gpc1', > > `make ../gpc-cpp', and `make ../libgpc.a' from there. > > rather cd \djgpp\gnu\gcc-2721\p Of course. #-) Sorry. > make finds no rule to build ../xgpc there (they are in make-lan.in) > > but it works by issuing make xgpc in the parent directory > > \djgpp\gnu\gcc-2721 (the rule is indeed in the generated makefile) > > > > make gpc1 in this parent directory does not work (there is a rule but it > > does not find a file) > > [...] Obviously, the configuration stuff for DJGPP is completely broken. :-( Since I am busy with other things right now, I would be really happy if somebody else could have a look at that. (I am not an expert in configuration of C sources anyway.;-) Normally (i.e. on UNIX), configuration is done by running a `configure' shell script in the `p' directory. The `configure' script has in turn been produced by `autoconf' from a `configure.in' source file. The goal of all this is to produce a `Makefile' from `Makefile.in' and `gpc-config.h' from `gpc-config.in'. If you produce `Makefile' and `gpc-config.in' manually and let `configur.bat' copy them from `config/msdos' to the right places, it would be fine. (* Jan-Jaap, is this the clean way for DJGPP configuration? *) Personally, I would prefer to have `configur.bat' in the `p' subdirectory rather than in `config/msdos'; in fact I do not know which place is the "clean" one for this file according to GNU conventions. 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

Multidimensional conformant arrays
by Frank Heckenbach 15 Oct '97

15 Oct '97

I think I found a bug with conformant arrays. Are conformant arrays supposed to work in multiple dimensions at all? If so, the following program gives the wrong result "3 2 1 2" instead of "1 2 3 4"; if not, it doesn't generate a necessary error message... program x; procedure p(var a:array[b..c:integer;d..e:integer] of integer); begin writeln(b,' ',c,' ',d,' ',e) end; var a:array[1..2,3..4] of integer; begin p(a) end. The corresponding program using a schema type works. BTW: Wouldn't it seem reasonable to allow the "with" statement also for schema types, as in the following example: program x; type t(a:integer)=array[1..a] of integer; procedure p(var v:t); begin with v do writeln(a) end; begin end. And one little detail: The next program gives the error message x.p:6: request for member `X' in something not x.p:6: a record, schema or object which is not completely correct since v is a schema, but x is not a field of v. program x; type t(a:integer)=array[1..a] of integer; procedure p(var v:t); begin writeln(v.x) end; begin end. Greetings, Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0