- Gpc - gnu.de

GPC REF: do (2)
by Miklos Cserzo 12 Jun '98

12 Jun '98

Hi Folks, how about the second version? I think it would be practical to use consistent abbreviations in the documentation for the different dialects: SP= ISO Standard Pascal, EP=ISO Extended Pascal, BP= Borland Pascal, GNU. miklos _______________________ here_it_goes _____________ do DESCRIPTION: The "do" reserved word is used in combination with other Pascal key-words in many ways. Due to its diverse functionality no explanation is given here to avoid confusion. See the relevant reference sections for description and examples: for, while, with, to begin, to end. STANDARDS: SP, EP, BP, GNU. SEE ALSO: for, while, with, to begin, to end.

3 2

UNSUBCRIBE
by Geoffrey Arnold 12 Jun '98

12 Jun '98

PLEASE UNSUBCRIBE ME FROM THIS MAILING LIST ----------Geoffrey Arnold--------- ------garnold(a)cyberdrive.net------ http://www.cyberdrive.net/~garnold

1 0

Re: Semi-low level question...
by Frank Heckenbach 10 Jun '98

10 Jun '98

Orlando Llanes wrote: > Frank: > Sorry 'bout my rambling :} What I want to do is to reference all the > variables declared in an object via the stack. > > Peter: > I did dump a -S, but the problem is that the prolog code sets a couple > of registers to the address of the Self parameter, then later on in my > routine, when I try to access the variable, it points to an invalid > location in memory, because the register that was set with the address is > now pointing into space (my routine modifies all of the registers). I think all you have to do is declare those registers as clobbered. You can also specify input and output registers to you r assembler code, so you don't have to worry about whether it's stored on the stack or in some registers by the compiler. The compiler will put it into those registers where you want it. The exact syntax is described in the GPC assembler tutorial (I think the file name is gpcasm.txt, in some directory on Agnes). Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc doesn't compile with egcs-19980608; patch appended
by Matthias Klose 09 Jun '98

09 Jun '98

gcc -DIN_GCC -DGPC -DEGCS -DHAIFA -s -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `case "gcc" in "cc") if [ x != x ]; then echo ../; else true; fi ;; esac` `if [ x != x ]; then echo ../; else true; fi` toplev.o: In function `main': toplev.o(.text+0x33b4): undefined reference to `lang_init_options' make[3]: *** [../gpc1] Error 1 *** gpc-lang.c.orig Tue Jun 9 15:47:29 1998 --- gpc-lang.c Tue Jun 9 15:48:00 1998 *************** *** 35,40 **** --- 35,45 ---- } void + lang_init_options () + { + } + + void lang_init () { #ifdef GPC

1 0

Semi-low level question...
by Orlando Llanes 09 Jun '98

09 Jun '98

Is there a way to specify to GPC, or for GPC to specify to AS, to reference Object fields (variables) using the stack rather than registers? The reason I ask is because my libs won't work as intended when variables are referenced via clobbered registers. I'm weary of making these variables globals because I intend to make them thread safe (somehow) eventually and owuld like each instance to have its own copy of the variables. Thanks in advance! 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: GPC REFERENCE
by richard.kerry＠quantel.com 08 Jun '98

08 Jun '98

Should the info attempt to be a Pascal language tutor ? ie. Should it cover FOR, WHILE, REPEAT etc. Surely most people coming to GPC will do so knowing Pascal from elsewhere. Since the world at large seems to prefer C (or Cobol), it seems to me that we don't need to worry too much about explaining the standard contructs as only those who have already chosen Pascal will be interested in GPC. If we do want to include standard constructs, we might derive our explanations from one of a number of existing books eg. Programming in Pascal, by Peter Grogono. (Addison-Wesley 0-201-12070-4). This book explains the FOR loop by its equivalent code using WHILE. I know this is copyright, but it (or similar) should give an idea how to explain these basic constructs. I think LALR(1) is the algorithm used for parsing. The syntax definition language is Backup-Naur Form, known as BNF. The Grogono book I mentioned doesn't use it, it uses syntax diagrams instead, but I'm sure someone can provide BNF for GPC. Whatever goes in should certainly be checked for English grammar and usage by a native speaker, or one of the German members of the list, who seem to write extremely good English. Regards, Richard.

5 5

Re: Semi-low level question...
by Frank Heckenbach 08 Jun '98

08 Jun '98

Orlando Llanes wrote: > Is there a way to specify to GPC, or for GPC to specify to AS, to > reference Object fields (variables) using the stack rather than registers? > The reason I ask is because my libs won't work as intended when variables > are referenced via clobbered registers. I'm weary of making these > variables globals because I intend to make them thread safe (somehow) > eventually and owuld like each instance to have its own copy of the > variables. Thanks in advance! I'm not sure I really understand your problem. Do your routines rely on no registers being clobbered by other routines? I don't think you could ever rely on this, because registers are used for other purposes, too. Perhaps declaring the variables "volatile" might help, but actually I don't think so. I don't think "volatile" is needed unless the variables are used in different threads at the same time or modified by hardware interrupts or such things. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

GRX graphics library v2.3 available
by Hartmut Schirmer 08 Jun '98

08 Jun '98

Hi, I uploaded GRX v2.3 on ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk (Mirrors see http://www.simtel.net/simtel.net/mirrors.html) and on the GRX pages at http://www.techfak.uni-kiel.de/~hsc/GRX/ What's GRX ---------- GRX is a low level graphics library designed for general purpose 2D graphics. It's designed to be portable (ANSI-C) and effective. In addition to the ANSI-C API it's possible to call GRX from other languages, an interface to GNU-Pascal comes with GRX. GRX is under the LGPL. Check out doc/copying.cb for details. Currently GRX is known to work on DOS systems (GCC+DJGPP, Borland C++, Watcom C++ 32bit) Linux systems (svgalib and X11) Unix systems (Sun, DEC, HP with X11R5 or newer) What's new in this release -------------------------- -- Thomas Hahn ported GRX to DEC alpha systems -- Ulrich Leodolter contributed his latest X11 driver. Several X11 problems (readpixel, color handling in pseudo color mode) are now. Additionally GRX will run on X11R5 systems now. -- Vincenzo Morello contributed the addons/ctx2jpeg source -- Andris Pavenis contributed the memory driver and the addons/print sources -- Gary Sands ported GRX to Watcom C++ (32bit, V11.0, other versions may work) -- Michal Stencl contributed the image handling code and the addons/bmp sources -- code portability has be greatly enlarged. GRX should be easily portable to new compilers now. -- BCC port should now work on _all_ Borland 16bit compilers (Tested with BCC 2.0, 3.1 and 4.52) -- GRX will work on big endian systems (sparc, AIX systems) -- GRX has 64bit support -- GRX uses a more flexible scheme for temporary memory allocation now. Depending system and the SMALL_STACK switch either alloca or malloc will be used. GRX allocates an internal buffer for blit blits, scanline return, etc now -- GRX supports a platform independant keyboard interface -- Nearly all frame drivers have be optimized for performance -- On Linux systems GRX can be build as shared lib -- New GRX functions: GrFloodFill GrGetScanline GrGetScanlineC GrPutScanline GrGetLibraryVersion GrGetLibrarySystem GrAllocEgaColors GrImage.... I wish to thank all of you for your continuing contributions to GRX. If you look at the list above, without your help this release would not have been possible. A special thank to Andris and Gary for testing nearly every new beta release, your feedback was extremely helpful! What's missing -------------- The GRX documentation is somewhat outdated. Other minor problems have been reported. Check out the GRX pages at http://www.techfak.uni-kiel.de/~hsc/GRX/ for more details. Hartmut Schirmer -- Hartmut Schirmer | Phone: +49-431-77572-709 FAX:-703 Automatisierungs- & Regelungstech. | hsc(a)techfak.uni-kiel.de Technische Fakult"at, | http://www.techfak.uni-kiel.de/~hsc Kaiserstr. 2, 24143 Kiel, Germany | PGP key via WWW, Key ID:6D84AEC1

1 0

UCE: PC-to-UNIX Connectivity Software
by info＠xlink.com 05 Jun '98

05 Jun '98

************************************************* Come see why Fortune 1000 Companies choose XLink for their PC-to-UNIX integration needs! ************************************************* We know you're busy so we'll be brief. :) XLink Technology, Inc. provides total networking software solutions for now and to the future Visit XLink Technology, Inc. @ http://www.xlink.com if you need help with the following... Total PC-to-UNIX integration software for the Windows Platforms: - NFS Client/Server - X-Windows - LPD/LPR - Terminal Emulation - All windows platforms - and more! Visit http://www.xlink.com for a FREE demo and more details! Thank you for your time. This is a one time mailing.

1 0

GPC REFERENCE: for
by Miklos Cserzo 04 Jun '98

04 Jun '98

for SYNTAX: for iteration_variable := initial_value to final_value do statement or for iteration_variable := initial_value downto final_value do statement DESCRIPTION: "for" is reserved word in all Pascal standards. It is used for introducing iterative loops during the execution. At the start of the loop the control variable set to the initial value then incremented by 1 after each execution step of the body of the "do" statement. The control variable should be an integer type. When the value of the control variable equals to the final value the execution continues at the next statement after the body of the "do". If the initial value and the final value are equal the loop executed ones. If the initial value higher than the final value the body of the "do" statement not executed. In the second form of the command the control variable decremented by 1 in each cycle. The relation of the initial and final values are reversed accordingly. The body of the "do" statement can contain other "for" cycles resulting nested loops. It is an error to set the value of the loop-control variable inside the loop. The code that violate that rule will compile and run - if there are no other errors - but the result will be unpredictable. After the execution of the loop the value of the control variable is undefined. A proper code should not relay on that value. STANDARDS: All EXAMPLE: var i,j,k:integer; vec:array[1..10] of integer; cube:array[1..10.1..10.1..10] of real; ... for i:= 1 to 10 do begin write('element [',i,']:? '); { prompt for the next value } readln(vec[i]); { read it } end; .... for i:= 1 to 10 do { load data from "infile" } for j:= 1 to 10 do begin for k:= 1 to 10 do read(infile,cube[i,j,k]); readln(infile); { next line } end; close(infile); SEE ALSO: do, while, repeat ________________________________ Comment this please. miklos

4 4

gcc-2.8.1 and gpc
by Mehul Sanghvi 04 Jun '98

04 Jun '98

'allo, Does GPC work with GCC 2.8.1 or do I still have to use GCC-2.7.2.1 for it ? Thanks, mehul -- Mehul Sanghvi email: <mehul(a)ziplink.net> wwweb: <http://www.ziplink.net/users/mehul/> Windows 95: n. Computing software with a graphical shell and 32 bit extensions for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.

2 2

Re: GPC REFERENCES: do
by Nick Burrett 04 Jun '98

04 Jun '98

On 3 Jun 98 at 11:34, Miklos Cserzo wrote: > do > > SYNTAX: > for iteration_variable := initial_value to final_value do statement > > or > for iteration_variable := initial_value downto final_value do statement > > or > > while boolean_expression do statement > > or > > with list_element[,...] do statement > If we are going to supply syntax to Pascal constructs then I suggest that they are suppled as proper grammar i.e. the LALR(1) format. Nick.

3 3

GPC REFERENCE: until
by Miklos Cserzo 03 Jun '98

03 Jun '98

until SYNTAX: repeat statement1; statement2; .... until boolean_expression; DESCRIPTION: The "until" keyword is used exclusively in combination with "repeat" keyword in all Pascal standards. See the reference page for "repeat" for the details. STANDARDS: All EXAMPLE: SEE ALSO: repeat

2 1

Re: GPC REFERENCE: begin
by Frank Heckenbach 03 Jun '98

03 Jun '98

> > DESCRIPTION: "begin" is word-symbol (reserved word) in all Pascal ^a > > standards. "begin" with its enclosing "end" groups together the statements Is "enclosing" the right word? English is not my native language, but I'd think the statements between "begin" and "end" are "enclosed", not the "end" itself. > > Wherever the Pascal syntax requires one statement "begin" ... > > "one single"? > > > "end" constructions can be used. Perhaps a small example here (a "for" or "while" loop)? > > "begin end;".) The execution part of a program block syntactically is a > > single statement therefore should be enclosed into a "begin ... end." > > construction. Perhaps clarify that it *must* be enclosed. Otherwise, someone might get the idea that the following would be valid: program foo; writeln('Hello, world.'). > This holds for the (optional) initialization part of Units as well. Don't forget to mention in the "Standards" section that this is a BP (or already UCSD?) extension, in contrast to "to begin/end do" which are EP. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

Re: GPC REFERENCES: do
by Frank Heckenbach 03 Jun '98

03 Jun '98

Miklos Cserzo wrote: > The later form is for easy access of fields of record or schema type > variables. or object type -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Re: GPC REFERENCE: repeat
by Frank Heckenbach 03 Jun '98

03 Jun '98

Miklos Cserzo wrote: > "repeat" is reserved word in all Pascal dialects for creating loops in the ^a > program execution. The statements after the "repeat" executed ^are > sequentially. When the "until" statement reached the execution continues ^is > with the next statement if the boolean expression evaluates "true". If it > is "false" the execution continues at the next statement after the ^^^^first(?) > starting "repeat" of the loop and the enclosed statements will be executed > again. > > The statements in the loop will be executed at least once. If the > expression in the "until" statement always "false" the execution falls ^is > into infinite loop. ^an > It is allowed the create nested "repeat - until" loops where the closest ^^^to > .... > repeat { echo the input from "infile" to "outfile" } > readln(infile,buffer); > writeln(outfile,buffer); > until eof(infile); > close(infile); close(outfile); > .... IMHO a bad example for repeat, better suited for a while loop, since infile can be empty. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Re: GPC REFERENCE: for
by Kevin A. Foss 03 Jun '98

03 Jun '98

On Wed, 3 Jun 1998 18:54:27 +0200 (MEST), Peter Gerwinski wrote: >According to Miklos Cserzo: >> After the execution of the loop the value of the control variable is >> undefined. > >While this is stated in ISO-10206 I have seen some ISO-7185 test programs >that require the value to be <final_value>. Somebody knows definitly? ISO 7185:6.8.3.9 says that it should be undefined, unless the loop is exited via a goto. (This same discussion came up recently on c.l.p.ansi-iso, so I'm fairly sure of this... don't have the standard in front of me right as I write this :) ) >> A proper code should not relay on that value. I agree with this, so I'm interested to hear about the test programs you have that rely on post loop values of the control variable. Perhaps this is something that wasn't enforced in early Pascal implementations and later was codified in the standard. >(You see: The "Standards" section is taking over ... ;-) > >(You also see why I am so slow in writing documentation. ;-)-: I think this might be the best benefit of the current process of having everyone post their entries to the list. Partially so others can comment on other standards that the author of each section might not be familiar with, and partially so the developers can comment on any extra GPC-specific features that might also be available. -Kevin -- Kevin A. Foss -- kfoss(a)mint.net

1 0

Subject: Re: GPC REFERENCES: do
by Frank Heckenbach 03 Jun '98

03 Jun '98

(* The subject line is misleading now since this will be in the "to begin"/ "to end" sections, but I kept it anyway. *) > to begin do statement; > or ^ Better mention it with or without this one? > to end do statement; In this case, I'd say, with the semicolon, since the semicolon is necessary because of the "to begin do". In other cases, like the various loops, there should be -- strictly speaking -- no semicolon at the end, because it's not required by the loop, and actually doesn't have to be there (e.g. before an "end" or an "else" that belongs to a "case"), and sometimes even must not be there (before an "else" that belongs to an "if"). -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Subject: Re: GPC REFERENCE: for
by Frank Heckenbach 03 Jun '98

03 Jun '98

Just some spelling corrections and such... > variable set to the initial value then incremented by 1 after each ^is > loop executed ones. If the initial value higher than the final value the ^s ^^^^once ^is > body of the "do" statement not executed. ^is > In the second form of the command the control variable decremented by 1 in ^is > inside the loop. The code that violate that rule will compile and run - if ^^^() ^s > After the execution of the loop the value of the control variable is > undefined. A proper code should not relay on that value. ^^^^^rely -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

GPC REFERENCE: begin
by Miklos Cserzo 03 Jun '98

03 Jun '98

begin SYNTAX: begin statement1; statement2; .... end; DESCRIPTION: "begin" is word-symbol (reserved word) in all Pascal standards. "begin" with its enclosing "end" groups together the statements between them so they are treated as one single statement during the execution. Wherever the Pascal syntax requires one statement "begin" ... "end" constructions can be used. (It is allowed to use empty statement: "begin end;".) The execution part of a program block syntactically is a single statement therefore should be enclosed into a "begin ... end." construction. This apply to the execution part of procedures and functions as well. It is a syntax error having a "begin" without an enclosing "end". STANDARDS: all EXAMPLE: var ok:boolean; ... if not ok then begin writeln('Error occurred, execution aborted.'); halt; end; SEE ALSO: end, for, while, do _________________________ Comment this please. miklos

2 1

GPC REFERENCES: do
by Miklos Cserzo 03 Jun '98

03 Jun '98

do SYNTAX: for iteration_variable := initial_value to final_value do statement or for iteration_variable := initial_value downto final_value do statement or while boolean_expression do statement or with list_element[,...] do statement DESCRIPTION: "do" is a reserved word in all Pascal standards. It is used for constructing loops during the execution with "for" and "while" statements. The statement following the "do" - the body of the "do" statement - will be executed in cycles according to the controlling iteration variable or boolean expression respectively. Often several simple statements grouped together in a compound-statement as the body of the cycle ("begin statement1; statement2;.... end;"). The later form is for easy access of fields of record or schema type variables. The references in the body of the "do" statement will access the corresponding fields directly in the listed record or schema identifiers. ***** it is rather cryptic. I hardly ever use this feature. correct this section ***** STANDARDS: All. EXAMPLE: See the section of the reference under "for", "while" and "with" for the examples. SEE ALSO: for, while, with ____________________________________ I am waiting for comments. miklos

2 1

Re: GPC REFERENCES: do
by Miklos Cserzo 03 Jun '98

03 Jun '98

On Wed, 3 Jun 1998, Nick Burrett wrote: > If we are going to supply syntax to Pascal constructs then I suggest > that they are suppled as proper grammar i.e. the LALR(1) format. Can you point me to good description? My searches on the net did not bring up anything useful. miklos

1 0

GPC REFERENCE: repeat
by Miklos Cserzo 03 Jun '98

03 Jun '98

repeat SYNTAX: repeat statement1; statement2; ... until boolean_expression; DESCRIPTION: "repeat" is reserved word in all Pascal dialects for creating loops in the program execution. The statements after the "repeat" executed sequentially. When the "until" statement reached the execution continues with the next statement if the boolean expression evaluates "true". If it is "false" the execution continues at the next statement after the starting "repeat" of the loop and the enclosed statements will be executed again. The statements in the loop will be executed at least once. If the expression in the "until" statement always "false" the execution falls into infinite loop. It is allowed the create nested "repeat - until" loops where the closest appearance of the keywords will define the individual loops. It is a syntax error if the number of "repeat"-s and "until"-s are different in a program block. STANDARDS: All EXAMPLE: .... repeat { echo the input from "infile" to "outfile" } readln(infile,buffer); writeln(outfile,buffer); until eof(infile); close(infile); close(outfile); .... This code is equivalent to the following: label 10; ... 10 readln(infile,buffer); writeln(outfile,buffer); if not eof(infile) then goto 10; close(infile); close(outfile); ... SEE ALSO: for, while, do _________________________________ Comment this please. miklos

1 0

Let's write the GPC reference together! (was: gpc-980511 build bug)
by Peter Gerwinski 03 Jun '98

03 Jun '98

Hi, everybody! Miklos Cserzo wrote: > > Before the official release we should do something about the documentation. > It is really poor. Some 160 pages are missing from the language reference. > That is definitely too much writing for a single person but with a joint > effort it should not be a problem. How about to post the missing sections > of the reference to the list? I consider this a VERY GOOD idea! While some nice people are already working on improving the documentation, a joint effort will certainly yield a faster and better result. Of course, such a project must be coordinated; otherwise we will end up with a lot of incompatible fragments. Here are my thoughts about how to do that: * Everyone is encouraged to write or improve sections of the GPC reference, `reference.texi'. The article should be mailed to this list with a subject like GPC REFERENCE: abs It must contain a complete section of `reference.texi' in the standardized format (GNU Texinfo) *including* the separator lines beginning with `@c'. I will post a real-world example in a few minutes. For a description of the GNU Texinfo format, type `info -f texinfo'. * When replying and improving the text, always include a complete snippet as described above without leading `> ' or such. This is to simplify integration into the file `reference.texi'. * Spelling corrections are welcome. And now for some guidelines how the documentation should look like: * Be exact. Examples must work. * Really explain it. "Help" screens like "Use the `Procedure' keyword to declare a procedure" do not help anyone. *Nothing* is self-evident. * Give examples. Besides a tiny easy-to-understand example there should always be a real-world example that helps to avoid pitfalls. (See `info -f gpc -n and' for an example: The first `if' is the easy example, while the `else if' describes a common pitfall. Maybe it would be even better to separate them ...) * Use cross references. When a cross reference appears in the help text, it is usually desirable to repeat it in the `See also' subsection. * Be technical, not personal. For example, I do not like `goto', and I never use it in my programs, but if I explain it, this does not matter. If there are some *technical* drawbacks using `goto' I can mention them, but a sentence telling "better don't use `goto'" causes nothing but confusion. * Read the tips in `info -f texinfo -n Tips'. Comments? An example of what I mean will follow in a few minutes. Also, I am uploading the file `reference.texi' to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/reference.texi so you do not need to download the whole GPC source just to get your hands on that single file. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/

2 5

Re: GPC MANUAL: Schemata, Pointer arithmetics
by Frank Heckenbach 03 Jun '98

03 Jun '98

Peter Gerwinski wrote: > here are three new sections for the "programmer's guide to GPC" (see > `info -f gpc -n programming'). Comments/improvements/etc. welcome. OK, here they are. :-) > @node Schemata > [...] > Schemata are types that depend on a variable, called ``discriminant''. <nitpick> There can be more than one discriminant. </nitpick> > @node Pointer arithmetics > [...] > @smallexample > Var > A: array [ 1..7 ] of Char; > p, q: ^Char; > i: Integer; > > [...] > > for p:= @@A [ 1 ] to @@A [ 7 ] do > p^:= 'x'; > > q:= @@A [ 3 ]; > while p > q do This is a bad example, IMHO, since p is defined as being undefined after a for loop, AFAIK -- even if it might actually have the correct value here. > begin > p^:= 'y'; > dec ( p ); > end (* while *); > > i:= q - p; This would, after the above while loop, always be 0, and is therefore not very instructive, I think. > @node Type casts This section does not clearly draw the distinction between value type casting and variable type casting. So I'll try to write an improvement of this section (it got a little bit longer ;-): @c ============================================================================ @node Type casts @section Type Casts @cindex type casts In some cases, especially when interfacing with other languages, Pascal's strong typing can be an obstacle. To temporarily circumvent this, GPC (and other Pascal compilers) defines explicit ``type casts''. There are two kinds of type casts, value type casts and variable type casts. Value type casts To convert a value of one data type into another type, you can use the target type like the name of a function that is called. The value to be converted can be a variable or an expression. An example: @smallexample Var Ch: Char; i: Integer; [...] i := Integer (Ch); @end smallexample Another, more complicated, example: @smallexample Type CharPtr = ^Char; CharArray = array [ 0..99 ] of Char; CharArrayPtr = ^CharArray; Var Foo1, Foo2: CharPtr; Bar: CharArrayPtr; [...] @{$X+@} @{ We need extended syntax in order to use ``Succ'' on a pointer @} Foo1 := CharPtr ( Bar ); Foo2 := CharPtr ( Succ ( Bar ) ); @end smallexample However, because of risks involved with type casts, explained below, you should try to avoid type casts whenever possible -- and it should be possible in most cases. For instance, the first example above could use the built-in function ``Ord'' instead of the type cast: @smallexample i := Ord (Ch); @end smallexample The assignments in the second example could be written in the following way without any type casts: @smallexample Foo1 := @@Bar^ [ 0 ]; Foo2 := @@Bar^ [ 1 ]; @end smallexample Value type casting only works between certain types: either between different ordinal types (including integer types), or between different real types, or between different pointer types. In each case, the actual value, i.e. the ordinal or numeric value or the address pointed to, respectively, is preserved in the cast. Note: It is also possible to cast from an integer into a real type. This is a consequence of the fact that integer values are generally automatically converted to real values when needed. Note: In the case of pointers, a warning is issued if the dereferenced target type requires a bigger alignment than the dereferenced source type (see @ref{alignment}). Variable type casts It is also possible to temporarily change the type of a variable, without converting its contents in any way. This is called variable type casting. The syntax is the same as for value type casting. This can be confusing, as the example below shows. The type-casted variable is still the same variable (memory location) as the original one, just with a different type. Outside of the type cast, the variable keeps its original type. There are some important differences between value and variable type casting: - Variable type casting only works on variables, not on expressions. - The result of a variable type casting is still a variable. Especially, it can be used on the left side of an assignment (as a so-called ``lvalue''), or passed by reference to a procedure. - No values are converted. The contents of the variable, seen as a raw bit pattern, are just interpreted according to the new type. In many cases, this does not make a big difference, e.g. the same ordinal values of different ordinal types have the same bit pattern (provided, the types have the same size), and similarly for different pointer types. However, there are cases where it does make a difference, most notably the completely different internal representation of integer and real types. This is demonstrated in the following example, admittedly a very constructed example, by using an integer and a real type of the same size and trying to cast between them. - Because bit patterns are just interpreted differently, the source and target type must have the same size. If this is not the case, GPC will give a warning. (@@error? see below) - Beware: Variable type casts might have unexpected effects on different platforms since you cannot rely on a specific way the data is stored (e.g. see @ref{endianness}). @smallexample program TypeCastingTraps; { Declare a real type and an integer type of the same size, and some variables of these types we will need. } Type RealType = ShortReal; IntegerType = Integer ( BitSizeOf ( RealType ) ); Var i, i1, i2, i3, i4, i5: IntegerType; r, r1, r2, r3, r4: RealType; begin @{ First part: Casting integer into real types. @} @{ Start with some integer value @} i := 42; @{ First attempt to cast. Here, an lvalue is casted, so this must be a variable type cast. Therefore, the bit pattern of the value of i is transferred unchanged into r1 which results in a silly value of r1. @} IntegerType (r1) := i; @{ Second try. Here we cast an expression -- though a trivial one --, rather than a variable. So this can only be a value type cast. Therefore, the numeric value is preserved, i.e. r2 = 42.0 . @} r2 := RealType (i+0); @{ Third way. In this last example, a variable is casted, and the result is used as an expression, not as an lvalue. So this could be either a value or variable type cast. However, there is a rule that value type casting is preferred if possible. So r3 will contain the correct numeric value, too. @} r3 := RealType (i); @{ Of course, you do not need any casts at all here. A simple assignment will work because of the automatic conversion from integer to real types. So r4 will also get the correct result. @} r4 := i; @{ Now the more difficult part: Casting real into integer types. @} @{ Start with some real value. @} r := 41.9; @{ Like the first attempt above, this one does a variable type cast, preserving bit patterns, and leaving a silly value in i1. @} RealType (i1) := r; @{ The second try from above does not work, because an expression of type real is to be casted into an integer which is not allowed. @} @{ i2 := IntegerType (r+0); @} @{ Third way. This looks just like the third way in the first part which was a value type cast. But -- surprise! Since value type casting is not possible from real into integer, this really does a variable type casting, and the value of i3 is silly again! This difference in behaviour shows some of the hidden traps in type casting. @} i3 := IntegerType (r); @{ As often, it is possible to avoid type casts altogether and convert real types into integers easily by other means, i.e. by using the built-in functions ``Round'' or ``Trunc'', depending on the mode of rounding one wants. @} i4 := Round (r); @{ 42 @} i5 := Trunc (r); @{ 41 @} end. @end smallexample When dealing with objects (see @ref{OOP}), it is often necessary---and safe---to cast a pointer to an object into a pointer to a more specialized (derived) object. In future releases, GPC will provide an operator @samp{as} for a safer approach to this problem. See also: @ref{absolute}, @ref{alignment}, @ref{endianness}, @ref{OOP}, @ref{Ord}, @ref{Chr}, @ref{Round}, @ref{Trunc}. @c ============================================================================ Some notes: - My texi skills are quite limited. In particular I think I should - highlight the headings "value"- and "variable type casting" - mark the "Note:"'s specially and - format the enumeration better than with "-"'s, but I wanted to get this out tonight, so I didn't look up how to do it. - When writing this, I strongly thought there should be a way to mark certain sections as "advanced" and "very advanced"... :-) - I'm not completely sure about the kind of types between which value type casting works, with "works" in the sense of (either or all): supported by BP, supported by GPC currently, should be supported by GPC. This is left to be checked and corrected if necessary. - Unfortunately, GPC does not behave completely like I described it :-(, but I think wrongly so. In particular, for the line "RealType (i1) := r;", it does a value type cast which is IMHO wrong since it is an lvalue. So I consider it a bug in GPC, tested by the following program, very similar to the one above, without comments: program frank170; Type RealType = ShortReal; IntegerType = Integer ( BitSizeOf ( RealType ) ); Var r, r1, r2, r3, r4: RealType; i, i1, i2, i3, i4, i5: IntegerType; begin i := 42; IntegerType (r1) := i; r2 := RealType (i+0); r3 := RealType (i); r4 := i; r := 41.9; RealType (i1) := r; i3 := IntegerType (r); i4 := Round (r); { 42 } i5 := Trunc (r); { 41 } if (r1<>42) and (r2=42) and (r3=42) and (r4=42) and (i1<>41) and (i1<>42) and (i3<>41) and (i3<>42) and (i4=42) and (i5=41) then writeln('OK') else writeln('Failed') end. - I think, GPC should give an error, not just a warning, when casting between types of different size -- at least in {$x-} mode. With extended syntax active (or some other switch), a warning still seems appropriate. Of course: Comments/improvements/etc. welcome! Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Re: GPC test suite (was: egcs-19980517 and gpc-980511)
by mrs＠wrs.com 02 Jun '98

02 Jun '98

> From: Peter Gerwinski <peter(a)gerwinski.de> > Date: Tue, 2 Jun 1998 10:44:24 +0200 (MEST) > Yes: The program contains a comment of the form > (* FLAG --extended-pascal --pedantic -Werror *) > which carries the flags that must be passed to the call to `gpc' > for that the test makes sense. Gee, this exactly mirrors the g++ testsuite. We spell it: // Special g++ Options: -pedantic -Werror

1 0

gpc-bug
by Matthias Klose 02 Jun '98

02 Jun '98

A user reported this bug with gpc-980511, built with the egcs-19980525 snapshot on a Debian/Linux 2.0 system: % cat typrat.pas Unit typrat ; INTERFACE Type TRATIONNEL = Record num : integer ; den : integer ; end ; IMPLEMENTATION END. % cat meo_rat.pas unit meo_rat ; INTERFACE uses typrat in 'typrat.pas'; procedure AffichRat(a : Trationnel) ; IMPLEMENTATION procedure AffichRat(a : Trationnel) ; begin end ; END. % gpc -c typrat.pas % gpc -c meo_rat.pas gpc: Internal compiler error: program gpc1 got fatal signal 11 I hope that this is enough information to reproduce the bug. If not, please ask.

2 1

GPC REFERENCE: ParamCount...
by Orlando Llanes 02 Jun '98

02 Jun '98

Is there a way to retrieve the number of parameters using GPC? 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

3 6

GPC REFERENCE: abs
by Peter Gerwinski 02 Jun '98

02 Jun '98

Hi! This is an example entry for how I think our joined effort to complete the GPC reference could work. The section I am posting is already in existence (`abs'): @c ---------------------------------------------------------------------------- @node abs @unnumberedsec abs @cindex abs @unnumberedsubsec Syntax @smallexample Function abs ( i: @var{integer type} ): @var{integer type}; @end smallexample or @smallexample Function abs ( x: @var{real type} ): @var{real type}; @end smallexample or @smallexample Function abs ( z: @var{complex type} ): @var{real type}; @end smallexample @unnumberedsubsec Description Returns the absolute value of the argument: @smallexample Function abs ( x: @var{some type} ): @var{some type}; begin (* abs *) if x < 0 then abs:= -x else abs:= x; end (* abs *); @end smallexample @unnumberedsubsec Standards The function @samp{abs} is defined in ISO-7185 Standard Pascal; its application to complex values is defined in ISO-10206 Extended Pascal. @unnumberedsubsec Example @smallexample Program TestAbs; Var i1: Complex; begin writeln ( abs ( 42 ) ); (* 42 *); writeln ( abs ( -42 ) ); (* 42 *); writeln ( abs ( -12.1 : 0 : 1 ) ); (* 12.1 *); i1:= cmplx ( 1, 1 ); (* 1 + i *) writeln ( abs ( i1 ) : 0 : 10 ); (* yields 1.4142135624, i.e. sqrt ( 2 ) *) end. @end smallexample @unnumberedsubsec See also @ref{sqr}. @c ---------------------------------------------------------------------------- If you follow-up to this mail and modify the section, please include a complete copy without leading "> " or such in order to make it easier for me to integrate the modified copy into `reference.texi'. Peter PS: I just was pointed to some errors in the above, so you can expect my own follow-up to this in a few minutes. :-) -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/

3 4

Re: egcs-19980517 and gpc-980511
by mrs＠wrs.com 02 Jun '98

02 Jun '98

> From: Matthias Klose <Matthias.Klose(a)cs.tu-berlin.de> > Date: Fri, 22 May 1998 04:43:56 +0200 (MET DST) > To: egcs(a)cygnus.com, gpc(a)hut.fi > After patching the gpc-980511 drop in for egcs, I got a working > egcs-gpc compiler. Some problems remain: > - the gpc testsuite fails with dejagnu-971222, it runs ok with dejagnu-1.3 1.3 is horribly old, and I don't recommend you use it. dejagnu needs a new FSF release to incorporate all the latest good bits that people have put into it. All the people that use dejagnu, use newer snapshots. Please consider upgrading to dejagnu-971222.

3 7

None
by hantschr＠hantsch.co.at 02 Jun '98

02 Jun '98

--note----------------------------------------------------------------- Username: [rainer] Use the above line in your e-Mail body to reach me in our company. You may use [rainer] at the beginning of the SUBJECT line (with higher priority) instead. -- This will allow us "Automatic Mail Forwarding". Our human "postmaster" may be reached with [rainer]. DO NOT USE OTHER FILE-ENCODING THAN UUENCODE, IT CANNOT BE PROCESSED!!! --note----------------------------------------------------------------- Received: from Hantsch-Message_Server by hantsch.co.at with WordPerfect_Office; Tue, 02 Jun 1998 08:43:34 +0100 Message-Id: <s573bb36.001(a)hantsch.co.at> X-Mailer: WordPerfect Office 4.0 Date: Tue, 02 Jun 1998 08:42:31 +0100 From: hantschr(a)hantsch.co.at To: gpc(a)hut.fi Subject: FPK-Area: Where? Item Type: Note ** PRIVATE ** Hello to everybody! Please, be so kind and let me know if there exists a special area (like this GPC area) for FPK users. I would like to subcribe to it but I couldn't locate one! Thanks in advance, Rainer Hantsch ---------------------------------------------------------------------- | Office address: | You may reach us by: | |--------------------------|-------------------------------------------| | ING. RAINER HANTSCH | Phone : +43 1 7988538 0 | | Khunngasse 21/1 | Fax : +43 1 7988538 18 | | A-1030 Wien/Vienna | BBS : +43 1 7988538 17 | | | e-Mail: hantschr(a)hantsch.co.at | | *** A U S T R I A *** | www : http://members.eunet.at/hantschr/ | ----------------------------------------------------------------------

2 1

GPC MANUAL: Schemata, Pointer arithmetics
by Peter Gerwinski 01 Jun '98

01 Jun '98

Hello, folks! here are three new sections for the "programmer's guide to GPC" (see `info -f gpc -n programming'). Comments/improvements/etc. welcome. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/ @c ============================================================================ @node Schemata @section Schema Types @cindex schemata @cindex types, schema Schemata are types that depend on a variable, called ``discriminant''. They are an ISO-10206 Extended Pascal extension. @smallexample Type RealArray ( n: Integer ) = array [ 1..n ] of Real; @end smallexample The type @samp{RealArray} in this example is called a Schema with the discriminant @samp{n}. To declare a variable of such a type, write @cindex Foo @smallexample Var Foo: RealArray ( 42 ); @end smallexample Schema-typed variables ``know'' about their discriminants. They can be accessed just like record fields: @smallexample writeln ( Foo.n ); (* yields 42 *) @end smallexample While types of variables must always have specified discriminants (which may be other variables), @emph{pointers} to schema variables may be without a discriminant: @cindex Bar @smallexample Type RealArrayPtr = ^RealArray; Var Bar: RealArrayPtr; @end smallexample When applying @samp{New} to such a pointer, you must specify the intended value of the discriminant as a parameter: @smallexample New ( Bar, 137 ); @end smallexample As a GNU extension, the above can also be written as @smallexample Bar:= New ( RealArrayPtr, 137 ); @end smallexample Schemata are not limited to arrays. They can be of any type that normally requires constant values in its definition, for instance subrange types, or records containing arrays etc. (Sets do not yet work.) To finish this section, here is a somewhat exotic example: @smallexample Type ColorType = ( red, green, blue ); ColoredInteger ( Color: ColorType ) = Integer; @end smallexample A @samp{ColoredInteger} behaves just like an ordinary integer, but it has an additional property @samp{Color} which can be accessed like a record field. @smallexample Var Foo: ColoredInteger ( green ); [...] Foo:= 7; if Foo.Color = red then inc ( Foo, 2 ) else Foo:= Foo div 3; @end smallexample @c ============================================================================ @node Pointer arithmetics @section Pointer Arithmetics @cindex pointer arithmetics GPC allows to increment, decrement, compare, and subtract pointers or to use them in @samp{for} loops just like the C language. @smallexample Var A: array [ 1..7 ] of Char; p, q: ^Char; i: Integer; [...] for p:= @@A [ 1 ] to @@A [ 7 ] do p^:= 'x'; q:= @@A [ 3 ]; while p > q do begin p^:= 'y'; dec ( p ); end (* while *); i:= q - p; @end smallexample Incrementing a pointer by one means to increment the address it contains by the size of the variable it is pointing to. For typeless pointers (@samp{Pointer}), the address is incremented by one instead. Similar things hold when decrementing a pointer. Subtracting two pointers yields the number of variables pointed to between both pointers, i.e.@: the difference of the addresses divided by the size of the variables pointed to. The pointers must be of the same type. @c ============================================================================ @node Type casts @section Type Casts @cindex type casts In some cases, especially when interfacing with other languages, Pascal's strong typing can be an obstacle. To temporarily circumvent this, GPC (and other Pascal compilers) defines explicit ``type casts''. To convert a value of one data type to another type, use the target type as a ``function'': @cindex Foo @cindex Bar @smallexample Type CharPtr = ^Char; CharArray = array [ 0..99 ] of Char; CharArrayPtr = ^CharArray; Var Foo: CharPtr; Bar: CharArrayPtr; [...] Foo:= CharPtr ( Bar ); @end smallexample Beware: Explicit type casts might have unexpected effects on different platforms since you cannot rely on a specific way the data is stored. If it is possible to avoid type casts (which holds for most cases), you should do that. For instance in the example above, you can make @samp{Foo} point to the first char in the array @samp{Bar^}: @smallexample Foo:= @@Bar^ [ 0 ]; @end smallexample When dealing with objects (see @ref{OOP}), it is often necessary---and safe---to cast a pointer to an object to a pointer of a ``bigger'' (derivated) object. In future releases, GPC will provide an operator @samp{as} for a safer approach to this problem. See also: @ref{absolute}. @c ============================================================================

1 0

GPC REFERENCE: SetLength
by Peter Gerwinski 01 Jun '98

01 Jun '98

Hello, folks! Here is a sketch for a `SetLength' reference section. Dose somebody know whether this > @samp{SetLength} is a Borland Delphi 1.0 extension. is really true? Yours, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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/ @c ---------------------------------------------------------------------------- @node SetLength @unnumberedsec SetLength @cindex SetLength @unnumberedsubsec Syntax @smallexample Procedure SetLength ( Var S: String; NewLength: Integer ); @end smallexample @unnumberedsubsec Description @samp{SetLength} explicitly assigns a new length @samp{NewLength} to the string parameter @code{S}. The contents of the string is @emph{not} changed; if the operation increases the length of the string, the characters appended at the end are @emph{undefined}. If you want to use @samp{SetLength}, please enable ``extended syntax'' (@samp{--extended-syntax} or @samp{(*$X+*)}). @unnumberedsubsec Standards @samp{SetLength} is a Borland Delphi 1.0 extension. @unnumberedsubsec Example @example Program TestSetLength; (*$X+*) (* Enable "dangerous" features *) Var S: String ( 26 ); begin S:= 'Hello, world!'; SetLength ( S, length ( 'Hello' ) ); writeln ( S ); (* 'Hello' *) SetLength ( S, 26 ); writeln ( S ); (* 'Hello, world!(%$@Â§"!"Â§$Â§"$' *) (* undefined characters ^^^^^^^^^^^^^ *) SetLength ( S, 42 ); (* The overflow is *not* (yet) detected *) writeln ( S ); (* This might cause a runtime error. *) end. @end example @unnumberedsubsec See also @ref{@ref{length}, @ref{String}, @ref{SetType}. @c ----------------------------------------------------------------------------

3 3

[Off-topic?] Req: Code snippet...
by Orlando Llanes 31 May '98

31 May '98

Hey all! Hopefully I'm not out of place by asking so, but here goes anyway. I'm looking for a snippet of *working* Pascal code using Tim Kientzle's algorithm for Approximate Inverse Color Mapping. If nobody has this, does someone out there at least have a snippet of code that uses Inverse Color Mapping in Pascal to reduce a 24-bit image to an 8-bit image? Thanks in advance! 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

1 0

crtf.o
by Bendersky 31 May '98

31 May '98

Hi, I've just upgraded to the last alpha. When trying to compile a program I got this: ****************************** C:\UTILS\GPC\Ariel\Mandel>...\bin\gpc -v --automake=-v mandel1.pas Reading specs from c:/utils/gpc/lib/specs gpc driver version 2.81 executing gpc version 2.8.1 c:/utils/gpc/bin/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MI NOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR __=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 -D__BITS _LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 mande l1.pas c:/utils/gpc/tmp/ccbywrgj GNU CPP version 2.81 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/utils/gpc/include c:/utils/gpc/lang/pascal c:/utils/gpc/contrib/grx22/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.81/include $DJDIR/include End of search list. c:/utils/gpc/bin/gpc1.exe c:/utils/gpc/tmp/ccbywrgj -quiet -dumpbase mandel1.pa s -version -famtmpfile=mandel1.gpc -fautomake=-v -o c:/utils/gpc/tmp/cccywrgj GNU Pascal version 2.81 (djgpp) compiled by GNU C version 2.8.1. c:/utils/gpc/bin/as.exe -o c:/utils/gpc/tmp/ccdywrgj c:/utils/gpc/tmp/cccywrgj c:/utils/gpc/bin/ld.exe crtf.o c:/utils/gpc/lib/crt0.o -Lc:/utils/gpc/lib -Lc:/ utils/gpc/contrib/grx22/lib -Lc:/utils/gpc/lib/gcc-lib/djgpp/2.81 -Lc:/utils/gpc /lib c:/utils/gpc/tmp/ccdywrgj -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/utils/gpc/bin/ld.exe: cannot open crtf.o: No such file or directory (ENOENT) ************************************ I've already compiled the grx20, and that program used to work with gpc 2.0 Also, when trying to compile it under rhide I always get (with every program)" cannot open crtf.o: No such file or directory (ENOENT)" Why is that? Am I doing something wrong? Thanks, Ariel --- Ariel Bendersky bender(a)einstein.com.ar

2 7

Mailing list addition
by Richard Earl Green 30 May '98

30 May '98

Please add me to your mailing list addition. You may have me at 'pslmsngr(a)ix.netcom.com'; please remove this as this is nolonger an open account. My current e-mail account is 'pslmsngr(a)inr.net'. Thanks. Richard Green.

1 0

Re: Executing external programs
by Frank Heckenbach 28 May '98

28 May '98

Geoffrey Arnold wrote: > I have GPC version 2.0 compiled for a 486 running linux. > > How do I execute a external shell script from a pascal program? You can use the system(3) function from libc. The first program passes a Pascal string to a CString parameter which is only supported by very recent (alpha) GPC versions. The second program does the conversion explicitly, and therefore works with older GPC versions as well. I'm not sure if it works with 2.0 since I don't have that here for testing. Anyway, it might be a good idea to get a newer version, which, though alpha, is already more stable than 2.0 was. program Exec_Demo; function System (cmd: CString): Integer; C; var s: String (1000); i: Integer; begin Write ('Enter a system command: '); Readln (s); i := System (s); Writeln ('The returned status of the executed command was ', i, '.') end. program Exec_Demo; function System (cmd: CString): Integer; C; function Str2CStrRO (var s: String): CString; begin s[Length(s)+1] := #0; Str2CStrRo := @s[1] end; var s: String (1000); i: Integer; begin Write ('Enter a system command: '); Readln (s); i := System (Str2CStrRO (s)); Writeln ('The returned status of the executed command was ', i, '.') end. Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

gpc-980511 build bug
by Klaus Espenlaub 28 May '98

28 May '98

Hi! just subscribed, so for now it's probably the best solution to send me a direct carbon copy, too. I downloaded gpc-980511.tar.gz, integrated it into gcc-2.8.1, ran configure and "make LANGUAGES=pascal", as suggested by the docs. The make run didn't manage to compile the runtime library, because it uses the --automake option. It tries to compile some dependent modules, but fails, because there is no executable on the system called gpc yet: ./../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../../config rts-move.p gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 make[1]: *** [rts-move.o] Error 1 make[1]: Leaving directory `/scratch/s_kespen/gcc-2.8.1/p/rts' make: *** [libgpc.a] Error 2 I worked around by just doing a "make install", giving me a half-working installed gpc. I reran the gpc build, this time with success. So currently if you start from scratch, you need good two runs to get gpc working. This isn't the ideal situation, but changing it would require a few substantial changes all over the place. You need some means of passing the name of the compiler driver down to the compiler. Then it would be easy to change the code in module.c to accommodate for the different location and name of xgpc. Generally it shouldn't be necessary for gpc to be in the PATH. There's no reason why /some/path/to/my/private/gpc should fail, while just gpc works. There has to be some means of keeping -B and -V options given to gpc initially, too. Otherwise it can be painful to use an different gpc version or a cross-compiler, like in this case a not installed compiler version. Anyway, to summarise all this - building gpc doesn't work correctly even if you have gpc installed previously. As long as some older gpc version is potentially used to compile some parts of the RTS, it's wrong. Older gpc versions may have bugs that are already fixed in the current release - this way they can pop up once more. The automake feature is quite useful as it is, but it needs to be polished a bit to make it robust enough for heavy duty work. Klaus

3 2

Executing external programs
by Geoffrey Arnold 27 May '98

27 May '98

I have GPC version 2.0 compiled for a 486 running linux. How do I execute a external shell script from a pascal program? ----------Geoffrey Arnold--------- ------garnold(a)cyberdrive.net------ http://www.cyberdrive.net/~garnold

1 0

Re: RECORD bug?...
by Frank Heckenbach 23 May '98

23 May '98

Orlando Llanes wrote: > Well, I got GPC to run, but I still have the (null) record field error > :( As it turns out, I forgot to upload one of the files. I'm uploading the > one I forgot, if you need the rest, let me know and I'll e-mail them. > This file I'm sending is the one that caused the error, but the > Integer(32) declaration (as opposed to just plain Integer) seems to be the > root of the problem. Thanks in advance! I just reduced your files to the minimum showing the bug and put them in "test suite format" (sorry for the "abuse" of your identifiers ;-). Strangely, it does not depend on using Integer(32) or plain Integer -- it even shows the bug with a string type. But the record is necessary. Well, this bug seems to be a bit volatile, but since it takes two units to trigger it, it reminds me a bit of another bug I found some time ago that's listed as "pointer types do not properly survive transport through two interfaces" in the To-Do list. So hopefully it's not a new bug after all. But I listed your message there so it will be checked when the bug will be fixed. Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach UNIT Orlando1a; INTERFACE TYPE TWorldXY = String(2); TClipRect = RECORD MinX : TWorldXY; END; IMPLEMENTATION END. UNIT orlando1b; INTERFACE USES orlando1a; PROCEDURE PutImg( zClipRect : TClipRect ); IMPLEMENTATION PROCEDURE PutImg( zClipRect : TClipRect ); BEGIN Writeln (zClipRect.MinX) END; END. PROGRAM Orlando1; USES Orlando1a, Orlando1b; VAR ScrClip : TClipRect; BEGIN ScrClip.MinX := 'OK'; PutImg( ScrClip); END.

1 0

Re: asm...
by Peter Gerwinski 23 May '98

23 May '98

According to Orlando Llanes: > > Is it wrong to say that asm is not portable? Not wrong. Perhaps unprecise: While `asm' itself is understood by GPC on all platforms, everything you can write *into* the `asm' statement is highly dependent on the platform. > I ask because of the > cross-compiling GPC/DJGPPs. Good luck! Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

egcs-19980517 and gpc-980511
by Matthias Klose 22 May '98

22 May '98

After patching the gpc-980511 drop in for egcs, I got a working egcs-gpc compiler. Some problems remain: - the gpc testsuite is installed in gcc/p . It uses it's own site.exp - the gpc testsuite fails with dejagnu-971222, it runs ok with dejagnu-1.3 The patches are appended at the end of the mail. === gpc tests === Running target unix Using /usr/bin/../share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/bin/../share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/testsuite/config/unix.exp as tool-and-target-specific interface file. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/testsuite/gpc.iso-7185/compile/compile.exp ... called "gpc_init" with too many arguments while executing "${tool}_init $test_file_name" (procedure "runtest" line 19) invoked from within "runtest $test_name" ("foreach" body line 40) invoked from within "foreach test_name [lsort [find ${dir} *.exp]] { if { ${test_name} == "" } { continue } # Ignore this one if asked to. if { ${ignore..." ("foreach" body line 3) invoked from within "foreach dir "${test_top_dirs}" { if { ${dir} != ${srcdir} } { foreach test_name [lsort [find ${dir} *.exp]] { if { ${test_name} == "" } { ..." ("foreach" body line 77) invoked from within "foreach pass $multipass { # multipass_name is set for `record_test' to use (see framework.exp). if { [lindex $pass 0] != "" } { set multipass_n..." ("foreach" body line 26) invoked from within "foreach current_target $target_list { verbose "target is $current_target"; set current_target_name $current_target; set tlist [split $curr..." (file "/usr/bin/../share/dejagnu/runtest.exp" line 1550) make[3]: *** [check-gpc] Error 1 make[3]: Leaving directory `/mnt/tmp/packages/egcs-snapshot/egcs-snapshot-199805 17/builddir/gcc/p' make[2]: *** [check-gpc] Error 2 make[2]: Target `check' not remade because of errors. Warning summary: There are 1553 warnings in stage3 of this bootstrap. Number of warnings per file: 380 ../../../gcc/p/gpc-common.c 135 ../../../gcc/p/../fold-const.c 56 insn-recog.c 39 ../../gcc/dwarf2out.c 34 ../../gcc/toplev.c 34 ../../../gcc/p/../toplev.c 33 ../../gcc/config/i386/i386.c 33 ../../../gcc/p/gpc-cccp.c 30 ../../gcc/p/gpc.c 29 ../../gcc/cccp.c 28 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-string.c 27 ../../../gcc/p/gpc-decl.c 22 ../../gcc/dwarfout.c 21 ../../gcc/reload1.c 21 ../../gcc/final.c 20 ../../gcc/combine.c 18 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-move.p 18 ../../gcc/toplev.h 18 ../../../gcc/p/gpc-lex.c 17 ../../gcc/objc/objc-act.c 16 ../../../gcc/p/gpc-lang.c 14 cxxmain.c 14 ../../gcc/varasm.c 14 ../../gcc/cplus-dem.c 14 ../../../gcc/p/gpc-typeck.c 12 ../../gcc/objc/archive.c 11 ../../gcc/cse.c 11 ../../gcc/alias.c 11 ../../../gcc/cp/lex.c 10 ../../gcc/stor-layout.c 10 ../../../gcc/p/../stor-layout.c 9 ../../gcc/stmt.c 9 ../../gcc/global.c 9 ../../gcc/fold-const.c 9 ../../gcc/expmed.c 9 ../../../gcc/p/../expr.c 9 ../../../gcc/cp/pt.c 8 g77.c 8 g++.c 8 ../../gcc/reload.c 8 ../../gcc/real.c 8 ../../gcc/gcc.c 8 ../../gcc/expr.c 8 ../../gcc/enquire.c 8 ../../gcc/c-lex.c 7 ../../gcc/tlink.c 7 ../../gcc/regclass.c 7 ../../gcc/pexecute.c 7 ../../gcc/crtstuff.c 7 ../../../gcc/cp/decl2.c 6 insn-output.c 6 ../../gcc/tree.c 6 ../../gcc/protoize.c 6 ../../gcc/genattrtab.c 6 ../../gcc/collect2.c 6 ../../../gcc/p/../tree.c 6 ../../../gcc/cp/decl.c 5 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-rdsub.c 5 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/choose-temp.c 5 ../../gcc/optabs.c 5 ../../gcc/local-alloc.c 5 ../../gcc/flow.c 5 ../../gcc/dbxout.c 5 ../../../gcc/p/util.c 5 ../../../gcc/p/../optabs.c 5 ../../../gcc/p/../dbxout.c 4 parse.y 4 insn-emit.c 4 cexp.y 4 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-wrtinc.c 4 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-block.c 4 ../../gcc/unroll.c 4 ../../gcc/regmove.c 4 ../../gcc/reg-stack.c 4 ../../gcc/objc/sarray.c 4 ../../gcc/jump.c 4 ../../gcc/integrate.c 4 ../../gcc/haifa-sched.c 4 ../../gcc/function.c 4 ../../gcc/calls.c 4 ../../gcc/c-decl.c 4 ../../../gcc/p/../function.c 4 ../../../gcc/cp/hash.h 3 insn-peep.c 3 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-numtodec.p 3 ../../gcc/objc/init.c 3 ../../gcc/objc/Object.m 3 ../../gcc/loop.c 3 ../../gcc/genrecog.c 3 ../../gcc/genopinit.c 3 ../../gcc/gcov-io.h 3 ../../gcc/c-gperf.h 3 ../../../gcc/p/gpc-convert.c 3 ../../../gcc/cp/cvt.c 2 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-str.p 2 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-setup.c 2 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-read.c 2 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-file.c 2 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-error.c 2 ../../gcc/stupid.c 2 ../../gcc/print-rtl.c 2 ../../gcc/objc/selector.c 2 ../../gcc/explow.c 2 ../../gcc/caller-save.c 2 ../../gcc/bitmap.c 2 ../../../gcc/p/types.c 2 ../../../gcc/p/hash.h 2 ../../../gcc/cp/tree.c 2 ../../../gcc/cp/spew.c 2 ../../../gcc/cp/method.c 2 ../../../gcc/cp/init.c 2 ../../../gcc/cp/expr.c 2 ../../../gcc/cp/except.c 2 ../../../gcc/cp/errfn.c 2 ../../../gcc/cp/call.c 1 insn-extract.c 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-write.c 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-random.c 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-misc.c 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-intfrac.p 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-heap.c 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-base.p 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-assign.p 1 /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/gpc.pas 1 ../../gcc/recog.c 1 ../../gcc/p/version.c 1 ../../gcc/objc/thr-posix.c 1 ../../gcc/objc/nil_method.c 1 ../../gcc/hash.c 1 ../../gcc/f/com.c 1 ../../gcc/except.c 1 ../../gcc/c-common.c 1 ../../../gcc/cp/typeck.c 1 ../../../gcc/cp/search.c 1 ../../../gcc/cp/class.c Number of warning types: 487 enumeration value `???' not handled in switch 241 comparison between signed and unsigned 234 unused parameter `???' 191 implicit declaration of function `???' 96 `???' might be used uninitialized in this function 60 unused variable `???' 44 no previous prototype for `???' 35 `???' defined but not used 23 variable `???' might be clobbered by `longjmp' or `vfork' 21 ??? format, ??? arg (arg ???) 18 label `???' defined but not used 16 cast increases required alignment of target type 14 array subscript has type `char' 14 `???' declared inside parameter list 12 suggest explicit braces to avoid ambiguous `else' 9 unsigned value < 0 is always 0 7 suggest parentheses around assignment used as truth value 7 suggest parentheses around && within || 7 argument `???' might be clobbered by `longjmp' or `vfork' 2 zero-length format string 2 which is probably not what you want. 2 passing arg 1 of `???' from incompatible pointer type 2 its scope is only this definition or declaration, 2 empty body in an if-statement 1 unknown escape sequence `???' 1 this function may return with or without a value 1 pointer of type `???' used in arithmetic 1 passing arg 1 of `???' discards `???' from pointer target type 1 missing braces around initializer for `???' 1 `return' with no value, in function returning non-void 1 `???' was used with no prototype before its definition Native configuration is i486-pc-linux-gnu === libio tests === === libio Summary === # of expected passes 40 === libstdc++ tests === === libstdc++ Summary === # of expected passes 30 Host is i686-pc-linux-gnu === gpc tests === Host is i686-pc-linux-gnu === gcc tests === FAIL: gcc.c-torture/execute/980505-1.c execution, -O2 FAIL: gcc.c-torture/execute/980505-1.c execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gcc.c-torture/execute/980505-1.c execution, -O2 -g FAIL: gcc.c-torture/execute/980505-1.c execution, -Os FAIL: gcc.dg/980502-1.c (test for excess errors) FAIL: gcc.dg/clobbers.c execution test === gcc Summary === # of expected passes 7215 # of unexpected failures 6 # of expected failures 7 # of unsupported tests 10 /mnt/tmp/packages/egcs-snapshot/egcs-snapshot-19980517/builddir/gcc/xgcc version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental) Host is i686-pc-linux-gnu === g++ tests === FAIL: g++.brendan/crash30.C (test for excess errors) FAIL: g++.jason/template31.C (test for excess errors) FAIL: g++.law/inline1.C (test for excess errors) FAIL: g++.law/operators27.C (test for excess errors) FAIL: g++.other/redecl1.C (test for excess errors) FAIL: g++.other/using2.C conflict (test for errors, line 9) FAIL: g++.other/using2.C (test for excess errors) FAIL: g++.pt/ttp19.C (test for excess errors) FAIL: g++.pt/ttp40.C (test for excess errors) === g++ Summary === # of expected passes 3869 # of unexpected failures 9 # of expected failures 72 # of untested testcases 11 /mnt/tmp/packages/egcs-snapshot/egcs-snapshot-19980517/builddir/gcc/testsuite/../xgcc version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental) Host is i686-pc-linux-gnu === g77 tests === FAIL: g77.f-torture/compile/970125-0.f, -O1 FAIL: g77.f-torture/compile/970125-0.f, -O2 FAIL: g77.f-torture/compile/970125-0.f, -O2 -fomit-frame-pointer -finline-functions FAIL: g77.f-torture/compile/970125-0.f, -Os FAIL: g77.f-torture/compile/980424-0.f, -O1 FAIL: g77.f-torture/compile/980424-0.f, -O2 FAIL: g77.f-torture/compile/980424-0.f, -O2 -fomit-frame-pointer -finline-functions FAIL: g77.f-torture/compile/980424-0.f, -Os === g77 Summary === # of expected passes 214 # of unexpected failures 8 /mnt/tmp/packages/egcs-snapshot/egcs-snapshot-19980517/builddir/gcc/g77 version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental) configure flags: --host=i486-linux --prefix=/usr/lib/egcs-ss --enable-threads --enable-shared --enable-haifa --norecursion *** gcc/p/ChangeLog~ Mon May 11 19:26:48 1998 --- gcc/p/ChangeLog Fri May 22 01:23:23 1998 *************** *** 1,3 **** --- 1,30 ---- + Thu 21 May 1998 17:50 Matthias Klose <doko(a)cs.tu-berlin.de> + + * diffs/gcc-egcs-2.91.28.diff: add check-gpc to gcc/Makefile.in + check target. + + * gpc.c (main): correctly set the language dialect, if the driver is + called with an `x' as prefix. + + set two environment variables (AUTOMAKE_GPC, AUTOMAKE_EXEC_PREFIX) + to correctly (???) call the driver for the automake feature. + Sure, that's a hack ... + + * module.c (module_must_be_recompiled): get the name of the gpc + and the exec prefix used from the environment, if set + (AUTOMAKE_GPC, AUTOMAKE_EXEC_PREFIX). + + * Makefile.in (gpc-config.h): search configure in $(srcdir) + added SCHED_CFLAGS to FLAGS_TO_PASS. + + * Make-lang.in: added p/rts/emath-stamp to GPCSTAGESTUFF. + add RANLIB and RANLIB_TEST to RTS_FLAGS_TO_PASS (@RANLIB_TEST@ + is replaced by egcs configure with empty string. + added SCHED_CFLAGS to GPC_FLAGS_TO_PASS. + (p/version.o): remember date and time of the first + build and use it for later stages, else `make compare' fails. + (pascal.distclean): remove p/gpc_date and p/gpc_time + Mon 11 May 1998 18:21 Peter Gerwinski <peter(a)gerwinski.de> * Make-lang.in: updated version number to 980511. :-I *** gcc/p/diffs/gcc-egcs-2.91.28.diff~ Sun May 10 10:54:25 1998 --- gcc/p/diffs/gcc-egcs-2.91.28.diff Thu May 21 17:05:38 1998 *************** *** 969,971 **** --- 969,1004 ---- for (vals = TREE_OPERAND (init, 1); vals != NULL_TREE; vals = TREE_CHAIN (vals)) { + *** gcc-egcs/Makefile.in~ Thu May 14 16:09:31 1998 + --- gcc-egcs/Makefile.in Thu May 21 14:00:31 1998 + *************** + *** 2495,2501 **** + -e '1,/^## All variables above are.*##/ d' >> site.exp + -@rm -f ./tmp? + + ! CHECK_TARGETS = check-gcc check-g++ check-g77 + + check: $(CHECK_TARGETS) + + --- 2495,2501 ---- + -e '1,/^## All variables above are.*##/ d' >> site.exp + -@rm -f ./tmp? + + ! CHECK_TARGETS = check-gcc check-g++ check-g77 check-gpc + + check: $(CHECK_TARGETS) + + *************** + *** 2537,2542 **** + --- 2537,2547 ---- + TCL_LIBRARY=$${srcdir}/../tcl/library ; \ + export TCL_LIBRARY ; fi ; \ + $(RUNTEST) --tool g77 $(RUNTESTFLAGS) + + + + check-gpc: + + if [ -d p ]; then \ + + cd p && $(MAKE) check-gpc; \ + + fi + + # These exist for maintenance purposes. + *** gcc/p/module.c~ Thu Apr 30 13:13:26 1998 --- gcc/p/module.c Thu May 21 13:41:23 1998 *************** *** 669,681 **** *p = 0; strcat (dep_filename, ".d"); gpc_name = "gpc"; ! gpc_args = xmalloc (255); /* calculate this */ if (automake_gpc_options) ! sprintf (gpc_args, "--automake=\"%s\" %s ", ! automake_gpc_options, automake_gpc_options); else ! sprintf (gpc_args, "--automake "); if (automake_temp_filename) sprintf (gpc_args + strlen (gpc_args), "--amtmpfile=%s ", automake_temp_filename); --- 669,687 ---- *p = 0; strcat (dep_filename, ".d"); + if (getenv("AUTOMAKE_GPC")) + gpc_name = getenv("AUTOMAKE_GPC"); + else gpc_name = "gpc"; ! gpc_args = xmalloc (512); /* calculate this */ ! gpc_args[0] = '\0'; ! if (getenv("AUTOMAKE_EXEC_PREFIX")) ! sprintf (gpc_args, "-B%s ", getenv("AUTOMAKE_EXEC_PREFIX")); if (automake_gpc_options) ! sprintf (gpc_args, "%s--automake=\"%s\" %s ", ! gpc_args, automake_gpc_options, automake_gpc_options); else ! sprintf (gpc_args, "%s--automake ", gpc_args); if (automake_temp_filename) sprintf (gpc_args + strlen (gpc_args), "--amtmpfile=%s ", automake_temp_filename); *** gcc/p/gpc.c~ Tue Apr 7 11:33:31 1998 --- gcc/p/gpc.c Thu May 21 13:36:07 1998 *************** *** 4623,4632 **** --- 4623,4660 ---- struct user_specs *uptr; #ifdef GPC + char *buf = xmalloc(strlen(argv[0])+30); + sprintf(buf, "AUTOMAKE_GPC=%s", argv[0]); + putenv(buf); + free(buf); + + p = NULL; + for (i=1; i < argc; i++) { + p = argv[i]; + if (p[0] == '-' && p[1] == 'B') { + if (p[2]) + p = &p[2]; + else if (i + 1 < argc) + p = argv[i+1]; + else + p = NULL; + break; + } + } + if (p) { + char *buf = xmalloc(strlen(p)+30); + sprintf(buf, "AUTOMAKE_EXEC_PREFIX=%s", p); + putenv(buf); + free(buf); + } + /* If we're called as gpc (or i386-aout-gpc), link in libgpc as well. */ p = argv[0] + strlen (argv[0]); while (p != argv[0] && p[-1] != '-' && p[-1] != '/' && p[-1] != DIR_SEPARATOR) --p; + /* If called as x??, remove the x */ + if (p[0] == 'x') + p++; dialectname = p; if (strcmp (dialectname, "gpc") == 0) *** gcc/p/Make-lang.in~ Mon May 11 16:33:55 1998 --- gcc/p/Make-lang.in Fri May 22 01:15:37 1998 *************** *** 57,64 **** --- 57,67 ---- "MAKEINFOFLAGS=$(MAKEINFOFLAGS)" \ "MAYBE_TARGET_DEFAULT=$(MAYBE_TARGET_DEFAULT)" \ "MAYBE_USE_COLLECT2=$(MAYBE_USE_COLLECT2)" \ + "RANLIB=$(RANLIB)" \ + "RANLIB_TEST=$(RANLIB_TEST)" \ "RANLIB_FOR_TARGET=$(RANLIB_FOR_TARGET)" \ "RANLIB_TEST_FOR_TARGET=$(RANLIB_TEST_FOR_TARGET)" \ + "SCHED_CFLAGS=$(SCHED_CFLAGS)" \ "SHELL=$(SHELL)" \ "bindir=$(bindir)" \ "exec_prefix=$(exec_prefix)" \ *************** *** 86,91 **** --- 89,96 ---- CFLAGS="$(CFLAGS)" \ X_CFLAGS="$(X_CFLAGS)" \ LDFLAGS="$(LDFLAGS)" \ + RANLIB="$(RANLIB)" \ + RANLIB_TEST="$(RANLIB_TEST)" \ RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \ RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \ SHELL="$(SHELL)" *************** *** 191,198 **** $(DRIVER_DEFINES) \ -c `echo $(srcdir)/p/gpc.c | sed 's,^\./,,'` -o $@ ! p/version.o: $(srcdir)/p/version.c config.status $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ -DGCC_VERSION="\"$(version)\"" \ -DGCC_VERSION_STRING="\"$(version)\"" \ -DGPC_VERSION="\"$(gpc_version)\"" \ --- 196,211 ---- $(DRIVER_DEFINES) \ -c `echo $(srcdir)/p/gpc.c | sed 's,^\./,,'` -o $@ ! p/gpc_date: ! date '+%h %e %Y' > $@ ! ! p/gpc_time: ! date '+%H:%M:%S' > $@ ! ! p/version.o: p/gpc_date p/gpc_time $(srcdir)/p/version.c config.status $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ + -DGPC_TIME="\"`cat p/gpc_time`\"" \ + -DGPC_DATE="\"`cat p/gpc_date`\"" \ -DGCC_VERSION="\"$(version)\"" \ -DGCC_VERSION_STRING="\"$(version)\"" \ -DGPC_VERSION="\"$(gpc_version)\"" \ *************** *** 452,457 **** --- 465,471 ---- -rm -f p/config.cache p/config.log p/config.status -rm -f p/testsuite/gpc.log p/testsuite/gpc.sum -rm -f p/parse.output + -rm -f p/gpc_date p/gpc_time # like gcc's extraclean, which does clean p/ for us, but not p/rts. pascal.extraclean: -rm -f p/*/=* p/*/"#"* p/*/*~* *************** *** 471,477 **** RTSSTAGESTUFF = p/rts/*$(objext) p/rts/config.cache p/rts/config.log \ p/rts/config.status p/rts/Makefile p/rts/math-stamp p/rts/zmath-stamp \ ! p/rts/rts-config.h pascal.stage1: -if [ -d stage1/p/rts ] ; then true ; else mkdir stage1/p/rts ; fi --- 485,491 ---- RTSSTAGESTUFF = p/rts/*$(objext) p/rts/config.cache p/rts/config.log \ p/rts/config.status p/rts/Makefile p/rts/math-stamp p/rts/zmath-stamp \ ! p/rts/rts-config.h p/rts/emath-stamp pascal.stage1: -if [ -d stage1/p/rts ] ; then true ; else mkdir stage1/p/rts ; fi *** gcc/p/Makefile.in~ Wed May 20 17:55:50 1998 --- gcc/p/Makefile.in Fri May 22 01:13:15 1998 *************** *** 129,135 **** INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC # This is the variable actually used when we compile. ! ALL_CFLAGS = $(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS) # Likewise. ALL_CPPFLAGS = $(CPPFLAGS) $(X_CPPFLAGS) $(T_CPPFLAGS) --- 129,136 ---- INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC # This is the variable actually used when we compile. ! ALL_CFLAGS = $(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS) \ ! $(SCHED_CFLAGS) # Likewise. ALL_CPPFLAGS = $(CPPFLAGS) $(X_CPPFLAGS) $(T_CPPFLAGS) *************** *** 176,181 **** --- 177,183 ---- "MAKEINFOFLAGS=$(MAKEINFOFLAGS)" \ "RANLIB=$(RANLIB)" \ "RANLIB_TEST=$(RANLIB_TEST)" \ + "SCHED_CFLAGS=$(SCHED_CFLAGS)" \ "SHELL=$(SHELL)" \ "exec_prefix=$(exec_prefix)" \ "prefix=$(prefix)" \

1 0

Re: RECORD bug?...
by Orlando Llanes 21 May '98

21 May '98

Well, I got GPC to run, but I still have the (null) record field error :( As it turns out, I forgot to upload one of the files. I'm uploading the one I forgot, if you need the rest, let me know and I'll e-mail them. This file I'm sending is the one that caused the error, but the Integer(32) declaration (as opposed to just plain Integer) seems to be the root of the problem. Thanks in advance! 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 PROGRAM Test256; USES EDDef, EDGr256; CONST ScrClip : TClipRect = (0, 0, 319, 199); VAR ScrDrv : TGraph256; BEGIN IF ScrDrv.SetMode( m320x200x256 ) THEN; ScrDrv.PutImg( ScrClip, 20, 20, ScrClip ); ReadLn; IF ScrDrv.SetMode( mOSDefault ) THEN; END.

2 1

Change of e-mail address
by pslmsngr＠ix.netcom.com 21 May '98

21 May '98

I have changed my e-mail address. Please update. I was at "pslmsngr(a)ix.netcom.com"; but will now be at "pslmsngr(a)inr.net". Thanks, Richard Green

1 0

New DJGPP binary for gpc-980511 (2. try)
by Peter Gerwinski 21 May '98

21 May '98

Hello, folks! I wrote: > I have uploaded a new binary distribution archive for > gpc-980511 on the DJGPP platform. Those who have observed > "Abort!"s and crashes should retry with this one. I had forgotten to update `gpc.exe' in that archive. Currently uploading again a new version. Sorry for the confusion, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

RECORD bug?...
by Orlando Llanes 21 May '98

21 May '98

Is there a known bug when using declarations such as Integer(32) with types? I ask because I was working on my MM Libs, and I got a (null) record error when GPC compiled my test program. What I'm doing is defining a type, then defining another type using that declaration, then using the 2nd declaration to define a parameter in a procedure. Confused? I attatched the necessary source files to reproduce the error. I don't see any reason why it would do that since what I'm doing is valid. I traced the error down to the Integer(32) declaration in EDDEF.PAS, when I use Integer alone it works fine. What could be causing the error? I'm using GPC v971001 (2.7.2.1) which leads me to another problem I'm having.. I sent an e-mail, but I didn't see it come back to me, so I think it may have been lost. I downloaded PGCC 2.9.0.something and installed the latest GPC (980511?), and the PGCC works properly, but GPC crashes despite my setting the stack up as high as 4MB with Stubedit. I'm running Windows '98 (legit Beta, not pirated), but had the same problem with Windows '95 (dunno about DOS 6.x/Win 3.x, I don't use them for compiling). Is there any reason why it might be crashing? Thanks in advance! 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 UNIT EDDef; { } { Epic Delusions MM Libs: Definitions v0.5 } { Copyright 1998 Orlando Llanes aka WundrDawg } { } { Disclaimer: } { The author will not be held responsible for any } { damages that may occur despite great care taken to } { ensure that the EDMM Libs and Utilities are bug free. } { } { License: } { The Epic Delusions Multimedia Libraries and Utilities } { are released as Copyrighted Freeware. This means that } { you may use the libraries, in whole or in part, for use } { in free or commercial productions so long as the } { copyright notice is intact. However, the EDMM Libs and } { Utilities may NOT be used for pornographic productions. } { } { Contacting: } { WWW -> http://www.geocities.com/SiliconValley/Lab/4677 } { E-Mail -> a010111t(a)bc.seflin.org } { -- or -- } { ollanes(a)planetall.com } { } { Bug Reports: } { In the event that a bug shows up, check the FAQ and/or } { the known bugs list. If you do not find a solution in } { either, write a description of the error, and if } { possible, a snippet of the code that caused the error } { and send it using one of the methods listed in the } { "Contacting:" section. } { } { Known Bugs: } { } { History: } { 05/18/98 v0.5 Started Coding } { } { "Common" Interface } INTERFACE TYPE { Compiler specific definitions } EDBool = Boolean; EDChar8 = Char; {$IFDEF __GPC__} EDInt8 = Integer(8); EDUInt8 = Cardinal(8); EDInt16 = Integer(16); EDUInt16 = Cardinal(16); EDInt32 = Integer(32); EDUInt32 = Cardinal(32); {$ENDIF} {$IFDEF VER70} Borland Pascal 7 is not supported at this time {$ENDIF} {$IFDEF MWERKS} CodeWarrior is not supported at this time {$ENDIF} TPixel = EDUInt32; TWorldXY = Integer(32); TClipRect = RECORD MinX, MinY, MaxX, MaxY : TWorldXY; END; CONST { Currently, BIOS and VBE modes } m320x200x256 = $13; mOSDefault = $03; IMPLEMENTATION END. UNIT EDGraph; { } { Epic Delusions MM Libs: Graphics "Drivers" v0.5 } { Copyright 1998 Orlando Llanes aka WundrDawg } { Defines a base object to define a "common" interface } { } { Disclaimer: } { The author will not be held responsible for any } { damages that may occur despite great care taken to } { ensure that the EDMM Libs and Utilities are bug free. } { } { License: } { The Epic Delusions Multimedia Libraries and Utilities } { are released as Copyrighted Freeware. This means that } { you may use the libraries, in whole or in part, for use } { in free or commercial productions so long as the } { copyright notice is intact. However, the EDMM Libs and } { Utilities may NOT be used for pornographic productions. } { } { Contacting: } { WWW -> http://www.geocities.com/SiliconValley/Lab/4677 } { E-Mail -> a010111t(a)bc.seflin.org } { -- or -- } { ollanes(a)planetall.com } { } { Bug Reports: } { In the event that a bug shows up, check the FAQ and/or } { the known bugs list. If you do not find a solution in } { either, write a description of the error, and if } { possible, a snippet of the code that caused the error } { and send it using one of the methods listed in the } { "Contacting:" section. } { } { Known Bugs: } { } { History: } { 05/18/98 v0.5 Started Coding } { } { GPC/DJGPP Interface } INTERFACE USES EDDef; TYPE TGraphBase = OBJECT FUNCTION SetMode( zMode : EDUInt16 ): EDBool; PROCEDURE PutImg( zClipRect : TClipRect; zX, zY : TWorldXY; VAR zImg ); END; IMPLEMENTATION FUNCTION TGraphBase.SetMode( zMode : EDUInt16 ) IsValidMode: EDBool; BEGIN IsValidMode := FALSE; END; PROCEDURE TGraphBase.PutImg( zClipRect : TClipRect; zX, zY : TWorldXY; VAR zImg ); BEGIN END; END. UNIT EDGr256; { } { Epic Delusions MM Libs: 256 Color Graphics v0.5 } { Copyright 1998 Orlando Llanes aka WundrDawg } { Routines for 256 color index video modes } { } { Disclaimer: } { The author will not be held responsible for any } { damages that may occur despite great care taken to } { ensure that the EDMM Libs and Utilities are bug free. } { } { License: } { The Epic Delusions Multimedia Libraries and Utilities } { are released as Copyrighted Freeware. This means that } { you may use the libraries, in whole or in part, for use } { in free or commercial productions so long as the } { copyright notice is intact. However, the EDMM Libs and } { Utilities may NOT be used for pornographic productions. } { } { Contacting: } { WWW -> http://www.geocities.com/SiliconValley/Lab/4677 } { E-Mail -> a010111t(a)bc.seflin.org } { ollanes(a)planetall.com } { } { Bug Reports: } { In the event that a bug shows up, check the FAQ and/or } { the known bugs list. If you do not find a solution in } { either, write a description of the error, and if } { possible, a snippet of the code that caused the error } { and send it using one of the methods listed in the } { "Contacting:" section. } { } { Known Bugs: } { } { History: } { 05/19/98 v0.5 Started Coding } { } { GPC/DJGPP Interface } INTERFACE USES EDDef, EDGraph; TYPE TGraph256 = OBJECT( TGraphBase ) FUNCTION SetMode( zMode : EDUInt16 ): EDBool; PROCEDURE PutImg( zClipRect : TClipRect; zX, zY : TWorldXY; VAR zImg ); END; IMPLEMENTATION FUNCTION TGraph256.SetMode( zMode : EDUInt16 ) IsValidMode: EDBool; BEGIN IF (zMode = m320x200x256) OR (zMode = mOSDefault) THEN BEGIN asm ( "movw %0, %%ax int $0x10" : : "g" (zMode) ); IsValidMode := TRUE; END; END; PROCEDURE TGraph256.PutImg( zClipRect : TClipRect; zX, zY : TWorldXY; VAR zImg ); VAR Foo : TWorldXY; BEGIN Foo := zClipRect.MinX; END; END.

2 1

New DJGPP binary for gpc-980511
by Peter Gerwinski 20 May '98

20 May '98

Hello, folks! I have uploaded a new binary distribution archive for gpc-980511 on the DJGPP platform. Those who have observed "Abort!"s and crashes should retry with this one. The difference lies in the version of the C library I linked the compiler against. Also, the new version is stubedited to have 2MB of stack instead of 256kB which is not sufficient for importing large units such as GRX. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

gpc-980511.tar.gz
by Matthias Klose 20 May '98

20 May '98

I am trying to compile gpc-980511 for egcs-19980517. Some problems: - The configure file cannot be found, when building in another directory. A patch is appended. - I get an internal compiler error when building the pascal runtime; the platform is a Debian GNU/Linux 2.0 (glibc2). I am not on the gpc mailing list. Matthias /usr/local/packages/egcs-snapshot/egcs-snapshot-19980517/gcc/p/rts/rts-intfrac.p :72: warning: no previous prototype for `__init_Rts_intfrac' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -O2 -DEGCS -I. -I../.. -I/usr/local/packages/egcs-s napshot/egcs-snapshot-19980517/gcc/p/rts/../.. -I/usr/local/packages/egcs-snapsh ot/egcs-snapshot-19980517/gcc/p/rts/../../config /usr/local/packages/egcs-snapsh ot/egcs-snapshot-19980517/gcc/p/rts/rts-move.p gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 ../../../gcc/p/gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 make[2]: *** [rts-move.o] Error 1 make[2]: Leaving directory `/mnt/tmp/packages/egcs-snapshot/egcs-snapshot-199805 17/builddir/gcc/p/rts' make[1]: *** [libgpc.a] Error 2 make[1]: Leaving directory `/mnt/tmp/packages/egcs-snapshot/egcs-snapshot-199805 17/builddir/gcc' make: *** [all-gcc] Error 2 *** gpc/p/Makefile.in Sun May 10 12:27:57 1998 --- gcc/p/Makefile.in Wed May 20 17:55:50 1998 *************** *** 250,257 **** native: ../gpc1 ../gpc-cpp # Pascal-specific configuration. ! gpc-config.h: configure ! ./configure # Compiling object files from source files. --- 250,257 ---- native: ../gpc1 ../gpc-cpp # Pascal-specific configuration. ! gpc-config.h: $(srcdir)/configure ! $(srcdir)/configure # Compiling object files from source files.

2 1

Re: Can't build GNU Pascal alpha gpc-980511 Cross Compiler
by Gerry Dubois 19 May '98

19 May '98

Peter's suggestion got me over the first hurdle. Unfortunately I have run into another stumbling block. I now get the following error message >gcc -DCROSS_COMPILE -DIN_GCC -g -DHAVE_CONFIG_H -o xgpc p/gpc.o prefix.o p/version.o \ > choose-temp.o pexecute.o obstack.o ` case "gcc" in "cc") echo "" ;; esac ` >cd p; make "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ar" "BISON=bison" "BISONFLAGS=" "CC=gcc" "CFLAGS=-g" "CLIB=" "GCC_FOR_TARGET=./xgcc -B./" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=/usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ranlib ]" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "objext=.o" "exec_prefix=/usr/local/gnu/palm_pascal" "prefix=/usr/local/gnu/palm_pascal" "tooldir=/usr/local/gnu/palm_pascal/m68k-palmos-coff" "bindir=/usr/local/gnu/palm_pascal/bin" "libsubdir=/usr/local/gnu/palm_pascal/lib/gcc-lib/m68k-palmos-coff/2.8.1" "CROSS=-DCROSS_COMPILE" "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ar" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g" "X_CFLAGS=" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "MAYBE_TARGET_DEFAULT=" "MAYBE_USE_COLLECT2=" "RANLIB_FOR_TARGET=/usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/local/gnu/palm_pascal/m68k-palmos-coff/bin/ranlib ]" "SHELL=/bin/sh" "bindir=/usr/local/gnu/palm_pascal/bin" "exec_prefix=/usr/local/gnu/palm_pascal" "gxx_include_dir=/usr/local/gnu/palm_pascal/include/g++" "includedir=/usr/local/include" "libsubdir=/usr/local/gnu/palm_pascal/lib/gcc-lib/m68k-palmos-coff/2.8.1" "prefix=/usr/local/gnu/palm_pascal" "target_alias=m68k-palmos-coff" "tooldir=/usr/local/gnu/palm_pascal/m68k-palmos-coff" "gpc_version=980511" "rts_version=2.8" "version=2.8.1" ../gpc1 >make[1]: Entering directory `/usr/src/palm_pascal/gpc-980511/p' >make[1]: *** No rule to make target `../stamp-objlist', needed by `stamp-gbe'. Stop. >make[1]: Leaving directory `/usr/src/palm_pascal/gpc-980511/p' >make: *** [gpc1] Error 2 >www:/usr/src/palm_pascal/gcc-2.8.1 $ > Can anybody help me out here. Thanks in advance. - Gerry

1 0

Re: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 18 May '98

18 May '98

> According to Paul Doerwald: > > > > Try 'touch'ing parse.c and parse.y, so that the two of them both get > > recompiled. Maybe that will help. > > Indeed: `parse.c' and `parse.h' in `gpc-980511.tar.gz' are broken. > Sorry for that. I am uploading a fixed archive now which differs > from the previous one in that it expands to a subdirectory `gpc' > rather than `gpc-980511'. (I hope this will not do any harm.;-) > Now I did as you suggested yesterday and deleted the *.gpi files also. I got an interesting error about a pascal file in the p/rts subdirectory. This is the output: ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing -prototypes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU /gcc-2.8.1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-move.p rts-move.p:33: no exported interface matching `Rts_base' rts-move.p: In function `Merge': rts-move.p:53: undeclared identifier `Words_big_endian' (first use this function ) rts-move.p:53: (Each undeclared identifier is reported only once rts-move.p:53: for each function it appears in.) rts-move.p:54: condition must be of Boolean type rts-move.p: In function `Moveleft': rts-move.p:89: undeclared identifier `Need_word_alignment' (first use this funct ion) rts-move.p:89: condition must be of Boolean type rts-move.p:94: warning: cast increases required alignment of target type rts-move.p:95: warning: cast increases required alignment of target type rts-move.p:99: warning: cast increases required alignment of target type rts-move.p:100: warning: cast increases required alignment of target type rts-move.p:102: warning: cast increases required alignment of target type rts-move.p:103: warning: cast increases required alignment of target type rts-move.p:106: warning: cast increases required alignment of target type rts-move.p:123: warning: cast increases required alignment of target type It seems that rts_base.p didn't get compiled. So I manually typed the lengthy command line above but compiled rts_base.p instead. I got this message: rts-base.p:56: warning: no previous prototype for `__init_Rts_base' but it seems to have compiled the unit. Then I retried to compile the other file, rts-move.p (manually at this stage again) Then it gave me the same automake error again as before: gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 Ok, I'm putting a copy of xgpc linked as gpc... Another make LANGUAGES="pascal" There are a number of warnings (do you need them?), but mainly there is this error: gpc: installation problem, cannot exec `gpc-cpp': No such file or directory However compilation is proceeding still... Other warnings about type mismatch in implicit declaration for built-in functions sqrtl,sinl, cosl in rts-emath.c. I'll post later with the results - it's still proceeding right now as I type. Regards, Clyde Meli

3 3

Re: Readln bug and other stuff
by Frank Heckenbach 18 May '98

18 May '98

Dr A Olowofoyeku (The African Chief) wrote: > Your program works okay - and, you will be happy to hear, I have > found the cause of the bug. It was caused by this statement in the > initialization section of SYSTEM.PAS; > > FMode := L_Binary; > > I have now removed it. That's fine! One bug less! :-) > Now, this takes me to another point. I need to remove the statement > in SYSTEM.PAS that redefines "String" as "bpString" if > "_Borland_Pascal_" is defined. This would of course change the > definition of all those functions in the unit that either take > "String" as parameters, or that return type "String". The question > is, what should I change them to? Since this is a bpCompat unit, I > could change all of them to "bpString" (or "ShortString", which is > currently defined as "bpString"), or I could just leave them as > "String", which might mean warnings, etc., and the compiler > defaulting to a 255 character length. What do people think? A new > version of bpCompat is imminent, and I need to resolve this issue. Well, first of all, string parameters (value, var and const) are OK and should work. (Internally not exactly the same as in BP, but a (well-written) Pascal procedure shouldn't notice the difference.) So the problem concerns only strings as function results and possibly pointer types to strings. In this case, MHO is to change them to bpString because I know that you'll keep an eye on the library, and change them back to String when this will be supported. For other programs, the programmers must decide for themselves whether to use a fixed size string if they're ready to change it back when possible, or to use String and stand some warnings in the meantime. (Of course, warnings can be turned off globally, but as I said on another occasion, I don't like this idea very much.) Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Readln bug and other stuff
by Dr A Olowofoyeku (The African Chief) 18 May '98

18 May '98

From: Self <Single-user mode> To: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> Subject: Readln bug and other stuff Reply-to: laa12(a)keele.ac.uk Date: Mon, 18 May 1998 10:48:37 > From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> > Date: Sun, 17 May 1998 21:42:20 +0200 > To: gpc(a)hut.fi > Subject: Re: New GNU Pascal alpha gpc-980511 > > BTW: Frank and Peter - the "Readln" bug still exists under DJGPP. > > > > This is my workaround; > > Readln ( MyText, s ); > > i := length ( s ); > > if s [ i ] = #13 then Delete ( s, i, 1); > > > > I am not sure whether the fact that "s" contains the #13 character at > > the end of it is a GPC problem, or a DJGPP problem. > > Strange -- I can't see this bug! I got the binary distribution > of gpc-980511 (*) for DJGPP, and tested the following program. > > (*) The files are dated 11 May -- though GPC gives 2.8.1 as its version > number (under Linux as well). Is this correct, Peter? > > program Chief23; [....] Your program works okay - and, you will be happy to hear, I have found the cause of the bug. It was caused by this statement in the initialization section of SYSTEM.PAS; FMode := L_Binary; I have now removed it. Now, this takes me to another point. I need to remove the statement in SYSTEM.PAS that redefines "String" as "bpString" if "_Borland_Pascal_" is defined. This would of course change the definition of all those functions in the unit that either take "String" as parameters, or that return type "String". The question is, what should I change them to? Since this is a bpCompat unit, I could change all of them to "bpString" (or "ShortString", which is currently defined as "bpString"), or I could just leave them as "String", which might mean warnings, etc., and the compiler defaulting to a 255 character length. What do people think? A new version of bpCompat is imminent, and I need to resolve this issue. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro 4.25 for Win16 and Win32: ftp://ftp.simtel.net/pub/simtelnet/win3/install/chief425.zip

1 0

Re: New GNU Pascal alpha gpc-980511
by Frank Heckenbach 18 May '98

18 May '98

> BTW: Frank and Peter - the "Readln" bug still exists under DJGPP. > > This is my workaround; > Readln ( MyText, s ); > i := length ( s ); > if s [ i ] = #13 then Delete ( s, i, 1); > > I am not sure whether the fact that "s" contains the #13 character at > the end of it is a GPC problem, or a DJGPP problem. Strange -- I can't see this bug! I got the binary distribution of gpc-980511 (*) for DJGPP, and tested the following program. (*) The files are dated 11 May -- though GPC gives 2.8.1 as its version number (under Linux as well). Is this correct, Peter? program Chief23; var t:text; s:string(42); begin rewrite(t,'test.dat'); writeln(t,'OK'); reset(t); readln(t,s); if length(s)=2 then writeln(s) else writeln('Failed: ',length(s),' ',s); close(t) end. It writes "OK", though test.dat clearly contains a #13 before the #10. So, if this bug still shows on your system, it must depend on the presence of DosEmu (but why should it?), the version of DJGPP or the phase of the moon. Can anyone else reproduce it? Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Peter Gerwinski 17 May '98

17 May '98

Hello, everybody! A new alpha version of the GNU Pascal compiler (GPC) is being uploaded to the usual place, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ . News: This version compiles with gcc-2.8.0, gcc-2.8.1, or egcs-19980508 (2.91.28). Compiling with EGCS requires a definition `-DEGCS' given to `make', like the following: make LANGUAGES=pascal CFLAGS="-g -O6 -DEGCS" install This will be automated in the future. Together with the source, I am uploading binaries for Linux (gcc-2.8.1 and egcs-19980508) and DOS (DJGPP). Enjoy - and send your test reports to the GPC mailing list <gpc(a)hut.fi>, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 PGP: see homepage - 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/

7 12

Re: Can't build GNU Pascal alpha gpc-980511 Cross Compiler
by Peter Gerwinski 17 May '98

17 May '98

According to Gerry Dubois: > > [...] > Right, I'm using the 2.8.1 gcc source tree to compile against. I'm using > gcc 2.7.2.1 to compile the cross compiler and gpc. Do you mean to imply I > need to use a gcc-2.8.1 native compiler to compile the gpc source? No. gcc-2.7.2.1 should work fine. The *source* must be 2.8.x or EGCS. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 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

Winapi
by Southpaw 15 May '98

15 May '98

Thank you for the help on Prefixseg. But now I have come across another problem. The compile cannot find winapi.pas or winapi.ppu in my directories and therefore will not finish compiling my program. Can anyone tell me where I can get this? Sorry if this is too much of a simple question but I am new to GNU Pascal. Antonio Hernandez please reply to: southpaw(a)ecs.fullerton.edu

2 1

More about rts
by Miklos Cserzo 14 May '98

14 May '98

Muchachos, additional remarks to my previous message: if I build the kit without optimization the "make" will fail at the rts: ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/local/src/gcc-2.8.1/p/rts/../.. -I/usr/local/src/gcc-2.8.1/p/rts/../../config rts-base.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' xgpc: Internal compiler error: program gpc1 got fatal signal 11 make[1]: *** [rts-base.o] Error 1 make[1]: Leaving directory `/usr/local/src/gcc-2.8.1/p/rts' make:*** [libgpc.a] Error 2 Miklos Cserzo University of Birmingham c/o School of Biochemistry MRC - Bioinformatics Project Tel: +44-121-414-4090 Schools of Biochemistry, Biology and Medicine Fax: +44-121-414-3982 Edgbaston, Birmingham B15 2TT E-mail: miklos(a)bip.bham.ac.uk United Kingdom

1 0

Re: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class
by Frank Heckenbach 14 May '98

14 May '98

Dr A Olowofoyeku (The African Chief) wrote: > > > There is a program called hlp2rtf and another one called hlp2doc, > > > which convert help files to rich text format, and Word for Windows > > > format respectively. You probably want the first one. > > > > Well, both seem to be Windoze specific formats, too. On my system > > I found a SGML to RTF converter, but nothing to convert RTS into > > something or view RTF. So again, is there something to view or > > convert DOC or RTF into something standard? > > A lot of wordprocessors can read and write to the RTF format. I > believe that Wordperfect (from v5.0 onwards) for DOS (and unix?) can > read that format - so can Wordstar 2000 for DOS, etc. There must be > unix/linux and/or OS/2 programs out there that can read the RTF > format - or am I wrong? I don't know. I don't usually use such things as word processors, so I have none installed. But I'll try to get those programs you mentioned. (Or do they run only on Windoze? In this case, would you please run them and send me the converted files, if their license permits?) > BTW: RTF is basically ascii text with zillions of formatting codes. OK, then I can probably parse it in my mind if all else fails. Andreas Prucha [helicon] wrote: > Aem, what is standard? A format that's well-defined and for which implementations are freely available and not restricted to any particular OS or hardware. -- IOW, about anything that't not from M$ & co., usually... > And please don't forget that the document format must > be able to handle graphics since all the syntax-diagrams in the helpfile are > graphics. Perhaps HTML might do the job? There are many such standard formats available like HTML with JPEG or some other graphics format, DVI, Postscript, TeX with EPS, or maybe even PDF, all of which should be available on most decent systems. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

Re: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class
by Kevin A. Foss 13 May '98

13 May '98

On Wed, 13 May 1998 13:28:19 +0200, Frank Heckenbach wrote: >Well, both seem to be Windoze specific formats, too. On my system >I found a SGML to RTF converter, but nothing to convert RTS into >something or view RTF. So again, is there something to view or >convert DOC or RTF into something standard? Well I don't think RTF is Windows specific, I've seen it used quite a bit on Mac and NeXT machines. (I think NeXTMail may even be standardized on it.) It is one of the more portable markup languages around in that a lot of software does cope with it. If you use TeX/LaTeX, any CPAN site should have an RTF converter to those formats. The following site has a converter for RTF-> HTML: http://www.sunpack.com/RTF/latest/ There are both Linux and DOS binaries along with a lot of other operating systems. In my opinion it's best to convert a markup languages to another markup language but I think there is a library of public domain C code to strip RTF codes (of course I can't remember where it was now. :) Hope some of this helps, -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Re: Re[5]: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 13 May '98

13 May '98

> According to Clyde Meli: > > > > I changed it to indicate 2.8.1 which is the gcc I'm using. And I got a > > different error now... > > ... it seems to be the reason. Strange. I will investigate that. > > > gpc1: installation problem, cannot exec `gpc': No such file or directory > > gpc1: gpc exited with status 255 > > Grmblpfl ... some stupid bug in the automake mechanism. Please > copy or link your `xgpc' to `gpc' in a directory in your path to > work around. Will do so... thanks.. > > > gpi-hash.c:329: failed assertion `rp == 0' > > That's an incompatibility in different versions of the GPI file > format. Deleting all `.gpi' files should help. > > (If somebody wonders why I was so quiet during the last days: > Due to the hot weather in Germany (--> hardware failures) I have > been offline for about 30 hours and now I have about 300k of new > email.) It's hot here in Malta this week also, but apparently it won't last long :)

1 0

PreFixSeg Problem
by Southpaw 13 May '98

13 May '98

Greetings! I am trying to compile a previous turbo pascal program into GPC. In that programm I used the PreFixSeg variable. I keep getting an error from GPC on this variable. Is there a GPC equivalent or a way to get around this? Thank you in advance for any help on this matter. Antonio Hernandez southpaw(a)ecs.fullerton.edu

2 1

Re: Re[2]: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 13 May '98

13 May '98

> > > I did try it and had problems again as I said in my other post. > > > I suspect bison might be the culprit - it seems I cannot find the required > > version (I can only find 1.25). > > Well, I had exactly this problem the other day, and when I changed parse.y, > and then changed it back, everything worked, and Peter said that it was the > fault of an out-of-date file that now bison was forced to recompile (or > something like that). > > Try 'touch'ing parse.c and parse.y, so that the two of them both get > recompiled. Maybe that will help. I did do that, and it seems that the compilation is proceeding now.... It did proceed further, but it failed with a different error now: This is the output. make[1]: Entering directory `/export/home/local/src/GNU/gcc-2.8.1/p/rts' echo 'VARLIST="PROG1"' > gnuvers.conf echo 'PROG1='2.8 >> gnuvers.conf sh /export/home/local/src/GNU/gcc-2.8.1/p/rts/gnuvers.sh gnuvers.conf /export/ho me/local/src/GNU/gcc-2.8.1/p/rts/rts-version.in rm -f gnuvers.conf mv version.c rts-version.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-version.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-write.c rts-write.c:69: warning: no previous prototype for `_p_write' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-read.c rts-read.c:69: warning: no previous prototype for `_p_read' rts-read.c:152: warning: `_p_GetByt' was used with no prototype before its defin ition ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-block.c rts-block.c:33: warning: no previous prototype for `_p_blockread' rts-block.c:67: warning: no previous prototype for `_p_blockwrite' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-file.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-random.c rts-random.c:85: warning: no previous prototype for `_p_truncate' rts-random.c: In function `_p_seekall': rts-random.c:143: warning: suggest explicit braces to avoid ambiguous `else' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-heap.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-setup.c rts-setup.c:28: warning: no previous prototype for `_p_setup' rts-setup.c:33: warning: no previous prototype for `_p_final' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-rt0.c rts-rt0.c: In function `_p_initialize': rts-rt0.c:216: warning: implicit declaration of function `index' rts-rt0.c:241: warning: implicit declaration of function `setlinebuf' rts-rt0.c: In function `_p_makename': rts-rt0.c:402: warning: int format, pid_t arg (arg 4) ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config choose-temp.c choose-temp.c: In function `try': choose-temp.c:88: warning: implicit declaration of function `access' choose-temp.c: At top level: choose-temp.c:100: warning: no previous prototype for `choose_temp_base' choose-temp.c: In function `choose_temp_base': choose-temp.c:108: warning: implicit declaration of function `getenv' choose-temp.c:129: warning: implicit declaration of function `malloc' choose-temp.c:144: warning: implicit declaration of function `mktemp' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-error.c rts-error.c:171: warning: no previous prototype for `malloc_warning' rts-error.c:257: warning: no previous prototype for `_p_error' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-times.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-misc.c rts-misc.c:89: warning: no previous prototype for `_p_collect' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-set.c ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-string.c rts-string.c:193: warning: no previous prototype for `_p_string' rts-string.c:396: warning: no previous prototype for `_p_writestr' rts-wrtinc.c: In function `_p_writestr': In file included from rts-string.c:450: rts-wrtinc.c:78: warning: implicit declaration of function `bcopy' rts-string.c: At top level: rts-string.c:509: warning: no previous prototype for `_p_readstr' rts-string.c:614: warning: no previous prototype for `_p_val_byteint_check' rts-string.c:615: warning: no previous prototype for `_p_val_shortint_check' rts-string.c:616: warning: no previous prototype for `_p_val_integer_check' rts-string.c:617: warning: no previous prototype for `_p_val_medint_check' rts-string.c:618: warning: no previous prototype for `_p_val_longint_check' rts-string.c:619: warning: no previous prototype for `_p_val_bytecard_check' rts-string.c:620: warning: no previous prototype for `_p_val_shortcard_check' rts-string.c:621: warning: no previous prototype for `_p_val_cardinal_check' rts-string.c:622: warning: no previous prototype for `_p_val_medcard_check' rts-string.c:623: warning: no previous prototype for `_p_val_longcard_check' rts-string.c:624: warning: no previous prototype for `_p_val_byteint_nocheck' rts-string.c:625: warning: no previous prototype for `_p_val_shortint_nocheck' rts-string.c:626: warning: no previous prototype for `_p_val_integer_nocheck' rts-string.c:627: warning: no previous prototype for `_p_val_medint_nocheck' rts-string.c:628: warning: no previous prototype for `_p_val_longint_nocheck' rts-string.c:629: warning: no previous prototype for `_p_val_bytecard_nocheck' rts-string.c:630: warning: no previous prototype for `_p_val_shortcard_nocheck' rts-string.c:631: warning: no previous prototype for `_p_val_cardinal_nocheck' rts-string.c:632: warning: no previous prototype for `_p_val_medcard_nocheck' rts-string.c:633: warning: no previous prototype for `_p_val_longcard_nocheck' rts-string.c:662: warning: no previous prototype for `_p_val_shortreal' rts-string.c:663: warning: no previous prototype for `_p_val_real' rts-string.c:664: warning: no previous prototype for `_p_val_longreal' ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-bind.c rts-bind.c: In function `_p_bind': rts-bind.c:212: warning: implicit declaration of function `rindex' rts-bind.c:212: warning: assignment makes pointer from integer without a cast rts-bind.c:247: warning: implicit declaration of function `bcopy' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-bas e.p rts-base.p:28: warning: missing program header rts-base.p:28: no exported interface matching `Rts_base' rts-base.p:30: parse error before `Interface' rts-base.p:34: no exported interface matching `Interface' rts-base.p:34: warning: missing comma rts-base.p:34: parse error before `Const' rts-base.p:36: no exported interface matching `Bits_big_endian' rts-base.p:36: warning: missing comma rts-base.p:36: parse error before `=' rts-base.p:39: no exported interface matching `True' rts-base.p:39: warning: missing comma rts-base.p:41: parse error before `Bytes_big_endian' rts-base.p:41: no exported interface matching `Bytes_big_endian' rts-base.p:41: warning: missing comma rts-base.p:41: parse error before `=' rts-base.p:44: no exported interface matching `True' rts-base.p:44: warning: missing comma rts-base.p:46: parse error before `Words_big_endian' rts-base.p:46: no exported interface matching `Words_big_endian' rts-base.p:46: warning: missing comma rts-base.p:46: parse error before `=' rts-base.p:49: no exported interface matching `True' rts-base.p:49: warning: missing comma rts-base.p:51: parse error before `Need_word_alignment' rts-base.p:51: no exported interface matching `Need_word_alignment' rts-base.p:51: warning: missing comma rts-base.p:51: parse error before `=' rts-base.p:52: no exported interface matching `False' rts-base.p:52: warning: missing comma rts-base.p:54: parse error before `Implementation' rts-base.p:56: no exported interface matching `Implementation' rts-base.p:56: warning: missing comma rts-base.p:56: parse error before `End' make[1]: *** [rts-base.o] Error 1 make[1]: Leaving directory `/export/home/local/src/GNU/gcc-2.8.1/p/rts' make: *** [libgpc.a] Error 2 Regards, Clyde Meli

2 1

Re: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 13 May '98

13 May '98

> According to Clyde Meli: > > > > I had problems compiling an earlier beta under solaris 2.5.1 and left it at > > that when all the suggestions failed. I kept the release version (2.0) instead. > > But I might try again with this newer alpha at least on another machine. > > I just checked: The problems you had with the last beta were related to > a broken `parse.h' and perhaps `parse.c'. This should be corrected in the > current alpha release. (If not, I am promising now to correct the source > distribution.;-) IMHO it's a good time now to retry. > > Peter I did try it and had problems again as I said in my other post. I suspect bison might be the culprit - it seems I cannot find the required version (I can only find 1.25). I'm open to suggestions.. Regards, Clyde

3 2

Re: Re[4]: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 13 May '98

13 May '98

> > > I did do that, and it seems that the compilation is proceeding now.... > > > It did proceed further, but it failed with a different error now: > > Well, the other thing Peter suggested to me was this: > > in version.c, make this change: > > char *version_string = "2.8.0" > > or 2.8.1, depending on what you're using. This took away all my problems with > the rts files. Of course, bear in mind that I don't actually know what's > going on, and these are just a couple things that kludged my system into > working. > > | clavicle(a)niagara.com "The LORD is my strength and my > | www.niagara.com/~clavicle song; he has become my salvation." > | Exodus 15:2b > I changed it to indicate 2.8.1 which is the gcc I'm using. And I got a different error now... This is the output, if anyone is interested :) Thanks again for all the hints ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissi ng-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/.. /.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-version.c ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-bas e.p rts-base.p:56: warning: no previous prototype for `__init_Rts_base' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-ass ign.p rts-assign.p:44: warning: no previous prototype for `__init_Rts_assign' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-str .p rts-str.p: In function `Insert': rts-str.p:107: warning: passing arg 1 of `Insert_f' discards `const' from pointe r target type rts-str.p: At top level: rts-str.p:135: warning: no previous prototype for `__init_Rts_str' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-num todec.p rts-numtodec.p:250: warning: no previous prototype for `__init_Rts_numtodec' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-int frac.p rts-intfrac.p:72: warning: no previous prototype for `__init_Rts_intfrac' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy pes -Wmissing-declarations -g -I. -I../.. -I/export/home/local/src/GNU/gcc-2.8 .1/p/rts/../.. -I/export/home/local/src/GNU/gcc-2.8.1/p/rts/../../config rts-mov e.p gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 make[1]: *** [rts-move.o] Error 1 make[1]: Leaving directory `/export/home/local/src/GNU/gcc-2.8.1/p/rts' make: *** [libgpc.a] Error 2 Regards, Clyde Meli

2 1

Re: New GNU Pascal alpha gpc-980511 works with egcs-19980508
by Clyde Meli 13 May '98

13 May '98

> Hello, everybody! > > A new alpha version of the GNU Pascal compiler (GPC) is being uploaded > to the usual place, > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ . > > News: This version compiles with gcc-2.8.0, gcc-2.8.1, or > egcs-19980508 (2.91.28). Compiling with EGCS requires a definition I had problems compiling an earlier beta under solaris 2.5.1 and left it at that when all the suggestions failed. I kept the release version (2.0) instead. But I might try again with this newer alpha at least on another machine. Regards, Clyde Meli http://www.cis.um.edu.mt/staff/cmeli -- my home page http://www.maltanetworkresources.com -- Maltese (true) search engine+Directory

2 1

Re: New GNU Pascal alpha gpc-980511
by Clyde Meli 13 May '98

13 May '98

I've downloaded the alpha gpc-980511 and attempted compilation (yes I did download and correctly install gcc 2.8.1 as required). It seems that when I do "make LANGUAGES="pascal" " the installation is attempting to use bison even when it is not necessary. And it seems bison is doing something incorrect as the compilation ends with: gcc -c -DIN_GCC -DGPC -DSVR4 -g -Wall -I. -I.. -I. -I./.. -I./../config ob jects.c gcc -c -DIN_GCC -DGPC -DSVR4 -g -Wall \ -I. -I.. -I. -I./.. -I./../config \ `echo ./parse.c | sed 's,^\./,,'` parse.y: In function `yyparse': parse.y:2706: invalid lvalue in assignment parse.y:2738: invalid lvalue in assignment parse.y:5840: too many arguments to function `build_pascal_pointer_reference' parse.y:5842: too many arguments to function `build_pascal_pointer_reference' make[1]: *** [parse.o] Error 1 make[1]: Leaving directory `/export/home/local/src/GNU/gcc-2.8.1/p' make: *** [gpc1] Error 2 The version I have is bison-1.25.tar.gz - dated 1996. In the faq a reference is made that bison must be dated at least 1998 if used. But I cannot find a more up-to-date bison anywhere. >From where can it be obtained? Otherwise it seems that the beta won't compile for me at least, under solaris 2.5.1/sparc. Is there any way around this problem, so I can compile gpc as with version 2.0 (release) ? Thanks in advance for any hints anyone might have, Clyde Meli http://www.maltanetworkresources.com -- WWW directory/search engine for the Maltese web

1 0

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class
by Andreas Prucha [helicon] 13 May '98

13 May '98

Hi, Aem, what is standard? And please don't forget that the document format must be able to handle graphics since all the syntax-diagrams in the helpfile are graphics. Perhaps HTML might do the job? Andreas

1 0

Re: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class
by Frank Heckenbach 13 May '98

13 May '98

Dr A Olowofoyeku (The African Chief) wrote: > > Thanks, I've fetched a copy. BTW, does anybody know a utility to > > convert this .hlp file into something "readable" (i.e. some > > standard format)? > > There is a program called hlp2rtf and another one called hlp2doc, > which convert help files to rich text format, and Word for Windows > format respectively. You probably want the first one. Well, both seem to be Windoze specific formats, too. On my system I found a SGML to RTF converter, but nothing to convert RTS into something or view RTF. So again, is there something to view or convert DOC or RTF into something standard? -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

None
by hantschr＠hantsch.co.at 12 May '98

12 May '98

--note----------------------------------------------------------------- Username: [rainer] Use the above line in your e-Mail body to reach me in our company. You may use [rainer] at the beginning of the SUBJECT line (with higher priority) instead. -- This will allow us "Automatic Mail Forwarding". Our human "postmaster" may be reached with [rainer]. DO NOT USE OTHER FILE-ENCODING THAN UUENCODE, IT CANNOT BE PROCESSED!!! --note----------------------------------------------------------------- Received: from Hantsch-Message_Server by hantsch.co.at with WordPerfect_Office; Tue, 12 May 1998 08:50:03 +0100 Message-Id: <s5580d3b.001(a)hantsch.co.at> X-Mailer: WordPerfect Office 4.0 Date: Tue, 12 May 1998 08:49:28 +0100 From: hantschr(a)hantsch.co.at To: gpc(a)hut.fi Subject: GPC -- Compatibility with TP/BP ???? Item Type: Note ** High Priority ** Hello, Peter Gerwinski, hello there! A few days ago I bought the latest version of S.u.S.E Linux 5.2. Included was (again) GPC. As an old TurboPascal programmer I was interested in what might have changed in GPC since SuSE 5.1 from Nov.97, but there seems nothing to have changed. In the meantime I was also in direct touch with some professional software developers and they all told me the same: GPC IS CURRENTLY NOT USABLE FOR PROFESSIONAL USE, BECAUSE: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o First I must say that the GPC developers do a great job, but in fact, the final product is currently not really usable. o It is VERY incompatible with TP/BP, making it very hard to work with it. Too much workarounds are currently required. o It seems to be very buggy. Therefore I would never use it for professional development. I hope this will change soon. o It is not documented. -- Ouch! EVERY software has a manual. Especially a compiler should have one because of its complexity! I get the impression tha GPC is extended too quickly. Too many people add features instead of making GPC stable and adding the still missing but often required TP commands. Of course, this is my personal impression, but reading all that stuff inside this group and several other newsgroups, I read some words too often: DEBUGGER, TROUBLES, HOW DO I..., etc. A stable working compiler doesn't really need a debugger! It has to cover the OS so well that only logically mistakes can happen, but never an error caused by the compiler! In my long time of programming with TP/BP (I started on CP/M with TP 3) I never used a debugger and my programs still work stable! The compiler MUST WORK absolutely error free! I suggest that you add the basic TP/BP commands FIRST and make GPC running stable to get out of ALPHA, BETA-1, BETA-2,..., BETA-infinity. THEN, after finishing the above, you will have a stable platform which is really USABLE and it will be the right time to add new features. What am I missing? ------------------ It starts with simple file I/O commands! assign(), reset(), rewrite(), ... Some "hackers" place then crazy calls to functions of a "C" library, out from GPC. I also received such suggestions in the past. The result? I am calling from a _undocumented_ Pascal Compiler a function inside a _undocumented_ C library. -- ??! 8-((( I also search for a simple command reference, where every procedure/function is listed with calling convention, etc. It is really hard to write any program (except "Hello world...") without knowing supported functions/procedures! Would be great if somebody could tell me where I can find a USABLE Pascal compiler for Linux. It should be TP/BP compatible as much as possible. Thanks in advance, Rainer Hantsch ---------------------------------------------------------------------- | Office address: | You may reach us by: | |--------------------------|-------------------------------------------| | ING. RAINER HANTSCH | Phone : +43 1 7988538 0 | | Khunngasse 21/1 | Fax : +43 1 7988538 18 | | A-1030 Wien/Vienna | BBS : +43 1 7988538 17 | | | e-Mail: hantschr(a)hantsch.co.at | | *** A U S T R I A *** | www : http://members.eunet.at/hantschr/ | ----------------------------------------------------------------------

3 2

using GNU Pascal
by Clyde Meli 12 May '98

12 May '98

> Subject: GPC -- Compatibility with TP/BP ???? > > Item Type: Note > > ** High Priority ** > Hello, Peter Gerwinski, > Would be great if somebody could tell me where I can find a USABLE > Pascal compiler for Linux. It should be TP/BP compatible as much as > possible. > > > Thanks in advance, > > Rainer Hantsch > > I think GNU PASCAL is very usable. It can be used for sockets programming under solaris for instance (that's what my students use it for). I just wrote a web robot using GNU Pascal. True, I don't do any socket calls to retrieve the html pages, instead I shell to the wget program, and my robot or spider takes care of the higher level information. I am using it for resource discovery of new Maltese web pages. I am using GNU Pascal 2.0 (release version) so I don't have the Copy function for instance. But there is Substr instead. Once I get a newer version of GNU installed I will be able to switch to the Copy function etc. And I hope to submit the socket unit (tested under solaris only) to the GNU developers if they would like to have it for the distribution. Regards, Clyde Meli http://www.cis.um.edu.mt/staff/cmeli -- My home page http://www.maltanetworkresources.com -- Maltese (true) search engine+Directory

1 0

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Frank Heckenbach 11 May '98

11 May '98

Andreas Prucha wrote: > I wrote: > >You asked if there is an description of Delphi/OP. I think there is an > helpfile > >available on www.interprise.com (I'll look if I can find it). > > And here you get it: > > ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Thanks, I've fetched a copy. BTW, does anybody know a utility to convert this .hlp file into something "readable" (i.e. some standard format)? -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Achim Kalwa 11 May '98

11 May '98

Frank Heckenbach wrote: > > Is there a way to get the exception that was caught into a > variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); > Frank, your "fantasy" syntax is right. In Delphi: try { do something that might raise an exception } except on Foo : Exception DO ShowMessage(Foo.Message) end Where "Foo" is an instance of the Exception class. There is no need to declare "Foo" as a variable first. Achim

1 0

Delphi properties (was Reformatted: EFLIB as class library for O
by The African Chief (Dr A Olowofoyeku) 10 May '98

10 May '98

Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote; >Thanks Andreas, Chief and the others for your explanations. >I've copied your message's IDs into the To-Do-List so that I and >others can easily find the messages when it's time to implement >these fatures. >I've got a few little questions left (for now :-): >Concerning properties: I assume you cannot pass property fields as >var parameters, right? Correct. If you try it, you get a "Constant object cannot be passed as var parameter" error message. However, you can pass a property as a value and "Const" parameter. >> try >> // code U try to execute >> except >> On EMyException do xxxx; // Do special exception handling here >>On EAnotherException do xxxx; // What you want else raise; // let > > the standard exception handler do the thing > >end; > >Is there a way to get the exception that was caught into a >variable or so? Something like (fantasy syntax): > > On Foo : EAnotherException do Something.With (Foo.ErrDevice); I have no idea. I don't use exceptions at all. >> And can for type-conversion easyly >> typecased with PChar: >> >> Procedure MyProc (xxx: PChar); > > > >var mystring: String; > > > >MyProc (PChar(MyString)); > >The most recent GPC versions can do this, but without the explicit >type cast, like "MyProc (MyString);". The explicit type cast gives a >warning, and not the intended result. Should GPC learn such type >casts between values of different string types, too? (Peter?) (Since >it seems to be necessary for Delphi compatibility, I suppose the >answer will be yes.) It will be good if GPC will accept the explicit type cast as well as do the implicit one. But note that this should only be done with long strings (at least, that is what Delphi does). With short strings, people should do their own conversion (I think - is there any reason why this should be supported with short strings other than to make life easier for programmers?). Best regards, The Chief ----------------------- Dr Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro v4.25 for Win16 and Win32 Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief

1 0

Re: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Frank Heckenbach 10 May '98

10 May '98

Thanks Andreas, Chief and the others for your explanations. I've copied your message's IDs into the To-Do-List so that I and others can easily find the messages when it's time to implement these fatures. I've got a few little questions left (for now :-): Concerning properties: I assume you cannot pass property fields as var parameters, right? (Otherwise, this would greatly complicate the var parameter mechanism, even in programs that don't use properties at all.) > try > // code U try to execute > except > On EMyException do xxxx; // Do special exception handling here > On EAnotherException do xxxx; // What you want > else raise; // let the standard exception handler do the thing > end; Is there a way to get the exception that was caught into a variable or so? Something like (fantasy syntax): On Foo : EAnotherException do Something.With (Foo.ErrDevice); > And yes. Delphi's implementation is /great/ even the new referece counted > string types make live much easier. They can save more than > 255, This, of course, is true for GPC's strings, too. :-) > are dynamically allocated and referece-counted. Dynamical strings are not yet implemented, but are planned, anyway, in GPC (though they don't seem to be exactly the same as in Delphi). > And can for type-conversion easyly > typecased with PChar: > > Procedure MyProc (xxx: PChar); > > var mystring: String; > > MyProc (PChar(MyString)); The most recent GPC versions can do this, but without the explicit type cast, like "MyProc (MyString);". The explicit type cast gives a warning, and not the intended result. Should GPC learn such type casts between values of different string types, too? (Peter?) (Since it seems to be necessary for Delphi compatibility, I suppose the answer will be yes.) > - Interfaces (not really necessary but nice) Yes, we planned interfaces, too. (I know them from Java and from the OOE draft, I suppose they're similar in Delphi, are they?) However, the internals turned out to be quite difficult. So if someone knows about the internals of how Delphi handles interfaces, especially how it builds the VMTs of classes that inherit from/implement multiple interfaces, any information is welcome! > You asked if there is an description of Delphi/OP. I think there is an helpfile > available on www.interprise.com (I'll look if I can find it). But I doubt that > it is possible to implement it compatible w/o having a look at Delphi itself. > But I hope that I could explain some basic things. This might be useful for a "clean-room reimplementation"... Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

RE: Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Andreas Prucha [helicon] 09 May '98

09 May '98

Hi, I wrote: >You asked if there is an description of Delphi/OP. I think there is an helpfile >available on www.interprise.com (I'll look if I can find it). And here you get it: ftp://ftp.inprise.com/pub/delphi/techpubs/delphi2/obpascal.zip Andreas

1 0

Re[3]: troubles compiling gpc
by Peter Gerwinski 09 May '98

09 May '98

According to Paul Doerwald: > > I changed char *version_string = "2.8.0", compiled, and everything works > nicely now. [...] :-) > Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/specs > gpc driver version 980420(2.8.0) executing gpc version 2.8.0 > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Di586 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -D__i586__ -Asystem(unix) -Acpu(i386) -Amachine(i386) hello.pas /tmp/cca08525.i > GNU CPP version 980420(2.8.0) (i386 GNU/Linux with ELF) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/i586-pc-linux-gnulibc1/include > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/include > /usr/include > End of search list. > /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.0/gpc1 /tmp/cca08525.i -quiet -dumpbase hello.pas -version -famtmpfile=hello.gpc -o /tmp/cca08525.s > GNU Pascal version 980420(2.8.0) (i586-pc-linux-gnulibc1) compiled by GNU C version 2.8.0. > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: numeric constant with no digits > /tmp/cca08525.i:1: invalid #line > /tmp/cca08525.i:2: warning: missing program header > /tmp/cca08525.i:2: parse error at null character I cannot locate the problem from this. Since you reported that everything works now with the "version_string" change, I suspect that the problem leading to this was fixed somewhere after gpc-980420. Well, we will see after the next alpha release. > What I did was change 5987 to TREE_OPERAND (target), and when bison > complained, I changed it *back* to TREE_OPERAND (target,1), and everything > worked. ?? Now I understand: You had a correct version of `parse.y', but a wrong one of `parse.c'. After your changes, bison updated `parse.c', and everything was fine. :-) > Thank you, though, for helping me get gpc to compile. Now I can actually do > some programming (now that summer is here and school is over, and I have > *time* to program! :-) You lucky one! ;-) If you are ambitious, what about porting CRT to Linux? Many people would appreciate that. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 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

troubles compiling gpc
by Paul Doerwald 09 May '98

09 May '98

This seems an unlikely problem, but I'm actually confounded by it: I can't compile GPC. I've tried a number of different combinations, and it always fails with an abort, a core dump, and an Error 2 on rts-base.p. If I run the xgpc I have on a hello world program, it fails with a core dump. I'd tell you about what version this happened on, but as ftp logs to agnes.dida... will reveal, I have downloaded and tried countless combinations including: gcc 2.8.1 with gpc 980501 gcc 2.8.0 with gpc 980501 gcc 2.8.0 with gpc 980401, and then diffed with 980405 I also downloaded the binary for 980420, and even that came back with numerous errors on a hello-world compile. I'm running a plain Red Hat Linux 5.0 system (glibc2?) on a 486-DX50. The binary for 980420 came in a package with i586 in it, but I don't imagine that should make any difference... I've followed the instructions in the readme in /gnu-pascal/alpha on agnes, but it constantly fails. Here's the errors for a hello world program using the binary for 980420: pollux:~>gpc hello.pas /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: numeric constant with no digits /tmp/cca08381.i:1: invalid #line /tmp/cca08381.i:2: warning: missing program header /tmp/cca08381.i:2: parse error at null character The source for the program: program hello; begin writeln ('hello, world!'); end. I don't see a problem... The error I'm getting with 980405 and 2.8.0 is this: make[1]: Entering directory `/usr/src/gcc-2.8.0/p/rts' ../..xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/src/gcc-2.8.0/p/rts/../.. -I/usr/src/gcc-2.8.0/p/rts/../../config rts-base.p make[1]: *** [rts-base.o] Aborted (core dumped) make[1]: leaving directory `/usr/src/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 This happens all the time. Once, the compile failed on parse.y, complaining about too many parameters in a function that ended up not existing on either line pointed to by the compiler, but about 10 lines lower down. I changed it, changed it back, and compiled, and it worked... ??? I have in the past successfully compiled gpc-2.0 on a RedHat Linux 4.1 machine Thanks for your help! At this point, I'd be happy with a working binary for my machine attached to a message (compiling on a 486 is SLOOOOW!) | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | Exodus 15:2b

2 1

Re: [rainer] Re: GPC for LINUX
by FPL 09 May '98

09 May '98

Peter wrote > sqr(BTW), right now I am porting a project of 150000 lines from > BP to GPC - not by just recompiling, but it makes progress as > expected. Gee! What is it about? 150000 pascal source code? Also, the rhide url and the old GPC info moping about the lack of borland pascal likewise IDE make me ask this question: what's better than emacs, using pascal mode, for writting pascal? Don't you think Borland ide is just ugly, unusable, unefficient, vomitting? Never understood why you made such a mess about it. Also, the assign example given by rainer seems not to be the better one. When I started using GPC, it was not provided, but one could find a (working) substitutes given in the info. IMHO, the actual problem of using GPC for a user who is not maintening and trakcing the GPC bugs is that he is so sure all his problem are coming from the compiler and not from himself or his debugger! AFAIK, there is no one bug of mine I haven't made GPC responsible for it. It eventually appears that it is never GPC but either gdb or the user who is wrong, but one can't go through his human nature (my experience learnt me GPC is in fact much more reliable that one could expect from a beta version, so with time the effect is dissipating slowly). F.P.L

2 1

Re: Another more striking example
by Peter Gerwinski 08 May '98

08 May '98

According to FPL: > > I think this program is a better example of what the problem is. > It is not as artificial as the prior one, and can be executed > without gdb so that one can see the problem may lie somewhere else that > in debugging informations. > > program loop2(input, output); > var > i, j : integer; > > begin > j:=0; > repeat > for i:=0 to 10 do > if (i div 2)=0 then > begin > write('*'); > j:=j+1; > end; > writeln; > until j=10; > end. > > Do you agree the output should be a rectangular array of 5 stars by ten, No. For each run of the `repeat' loop, only one star (for i = 0) is printed. Perhaps you mean `if i mod 2 = 0'? > Well, what *I* get when running the output code is ... correct. ;-) > Also, I have (in the other program) some file of text type ever opened, > and I have noticed in applying your advice that GPC complains it cannot > write on the default output device (the screen) because of my opened > file. Just a writeln('*') and *not* a writeln(f, '*') wille make it say > > ?GPC runtime error: File is not open for writing (#9) This sounds strange and *maybe* indicates a bug. How did you open the file? The following should work: Assign ( MyFile, 'filename.txt' ); rewrite ( MyFile ); writeln ( 'Hello?' ); writeln ( MyFile, 'Hello!' ); close ( MyFile ); Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980420 PGP: see homepage - 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/

2 4

Delphis Object Pascal (was: RE: Reformatted: EFLIB as class library for Object-Pascal (fwd))
by Andreas Prucha [helicon] 08 May '98

08 May '98

Hi, >- Properties: I have them listed in my To-Do-list > (http://fjf.gnu.de/gpc-todo_toc.html), but I personally don't know > too much about them. Are they a Delphi extension? If so, are there > any documents available to describe them, or otherwise, could some > Delphi user put together a list of features required that could be > used as a "standard" that GPC, and perhaps FPK, can implement? Well, they look like fields, feel like fields, but aren't fields. Properties are declared: Property <name> : <type> read <howtoget> write <howtoset>; Proprties can read/write directly to a field or use get/set methods: Type TMyClass = Class (TObject) private FValue : Integer; public property Value : Integer Read FValue Write FValue; end; using the object it can easily be accessed like a field: MyObject.Value := 256; x := MyObject.Value; Data is still encapsuated. It's easy to change the implementation. Let's assume that Value may not be > 255. Type TMyClass = Class (TObject) private FValue : Integer; Procedure SetValue (Value: Integer); public property Value : Integer Read FValue Write SetValue; end; Procedure TMyClass.SetValue (Value: Integer); begin If Value > 255 then Raise Exception.Create ('Value may not be > 255'); FValue := Value; end; If the user now does MyObject.Value := 256; the assignment will fail with an exception. >- Classes: At http://pascal-central.com/OOE-stds.html, there is a > draft for an ANSI Object Pascal standard. AFAIH, Delphi's > implementation is quite close to this standard. One of the plans > for GPC is to implement this standard draft without dropping the > BP object model that is already implemented, in the hope that > there won't be great conflicts between the two. They are quite close. The look the same at the first glance, but they are not compatible. For example, Delphi does not know Class-/Kinds/. Classes are always declared the same way: TNewClass = Class (TDerivedFrom); Encapsulation is done quite the same way as in BP: TNewClass = Class (TObject) private // May not be accessed from outside (also not in subclasses) protected // May not be accessed from outside, but subclasses cann access public // May be accessed from outside published // A IDE-thing. should be handled the same way as "public" end; Othere than the Ansi-Draft in Delphi not each method is virtual. Delphi supports "Virtual" and "Dynamic". Procedure x; Virtual; Procedure y; Dynamic; "override" is used to override the method; Procedure x; override; Create is the standard-constructor and destroy the standard-destructor. Objects are always on heap and the pointer is automatically dereferenced. Objects are initialized the following way: MyObject := TMyClass.Create; and freed with MyObject.Free; Since they are automatically dereferenced it is not necessary to say MyObject^.Free; One of Delphis's bith strengths are the runtime-type-informations. Delphi introduces "is" and "as". "is" checks wheter the object is this or an subclass: If TMyObject is TMyClass then do ...; If TMyObject is a object with type TMyClass or a object of a subclass of TMyClass then the expression is true. "as" is used for typeconversion: try x := (MyObject as TMyClass).Value; except x := 0; end; If the typeconversion to MyClass is not possible (not (MyObject is TMyClass)) as raises an exception. There is much more to say about Delphis Class-Model, but these are the basics. In Delphi both models live together. The old model can be still used, but it is not possible to use the new model to subclass from an old-model-type object. But this is not necessary since in Delphi each class uses the new model. >- Exception handling: I myself would like to use it (for OOP as well > as non-OOP programs), so I'd be willing to put some effort into > implementing it when I have the time (later this year, hopefully). > However, as with properties, I'm lacking a (pseudo-)standard. > I do know the Java exception handling, and I think it's not too bad > and could be implemented similarly in Pascal. OTOH, I read that the > latest GCC version (on which GPC is based) has introduced exception > handling, so it might be easier to implement this if we can reuse Exception handling - really nice thing in Delphi. An exception is fired with raise. The information about the exception is stored in an object. The basic-exception-class is "Exception" raise Exception.Create ('This was wrong'); To use store additional data (e.g. and errorcode) exception can be easily subclassed: EMyException = Class (exception) private FErrorCode: Integer; public Constructor Create (Errorcode: Integer); property Errorcode : Integer Read FErrorcode; end; Constructor EMyException.Create (Errorcode: Integer); begin FErrorCode := Errorcode; Inherited Create ('Error '+IntToStr(Errorcode)); end; Exceptions are catched the following way: try // code U try to execute except // handle the exception end; Since exceptions are classes the different types of exceptions can be handled in "except" try // code U try to execute except On EMyException do xxxx; // Do special exception handling here On EAnotherException do xxxx; // What you want else raise; // let the standard exception handler do the thing end; "finally" is used to assure that some piece of code is always executed: try // code U want to execute finally // Do it also if code fails end; This is very usable to assure that resources are freed: MyObject := TMyClass.Create; try x := MyObject.value / 0; // Ooops /0 exception here! finally MyObject.Free; // But the object will be freed. end; > that code. OTTH, if there already is an implementation in a Pascal > dialect (Delphi?), and it's suitable, it would be a good idea to be > compatible to this. So again, could someone make a list of required > features (perhaps with some sample code)? I totally agree. IMO GCC should be compatible with Delphis Object Pascal, since OP is the real standard (1000000+ sold copies of Delphi) and not only a paper-standard. But you guys do it for free, so everything is fine, but Delphi/OP compatiblity would be /great/. If people come to Linux they could easily reuse existing Delphi/OP-code. And yes. Delphi's implementation is /great/ even the new referece counted string types make live much easier. They can save more than > 255, are dynamically allocated and referece-counted. And can for type-conversion easyly typecased with PChar: Procedure MyProc (xxx: PChar); var mystring: String; MyProc (PChar(MyString)); This type of string was introduced with Delphi 2. There are much more things in Delphi/OP which make live easier. The big advantages I see at the moment: - New class model with RTTI, Properties - Exception Handling - AnsiString and WideString (8bit and 16bit-char strings with > 255 chars, String is an AnsiString) - - Interfaces (not really necessary but nice) You asked if there is an description of Delphi/OP. I think there is an helpfile available on www.interprise.com (I'll look if I can find it). But I doubt that it is possible to implement it compatible w/o having a look at Delphi itself. But I hope that I could explain some basic things. And thank you guys for supporting (Object) Pascal. Andreas

2 1

None
by hantschr＠hantsch.co.at 08 May '98

08 May '98

--note----------------------------------------------------------------- Username: [rainer] Use the above line in your e-Mail body to reach me in our company. You may use [rainer] at the beginning of the SUBJECT line (with higher priority) instead. -- This will allow us "Automatic Mail Forwarding". Our human "postmaster" may be reached with [rainer]. DO NOT USE OTHER FILE-ENCODING THAN UUENCODE, IT CANNOT BE PROCESSED!!! --note----------------------------------------------------------------- Received: from Hantsch-Message_Server by hantsch.co.at with WordPerfect_Office; Fri, 08 May 1998 08:55:30 +0100 Message-Id: <s552c882.001(a)hantsch.co.at> X-Mailer: WordPerfect Office 4.0 Date: Fri, 08 May 1998 08:54:16 +0100 From: hantschr(a)hantsch.co.at To: gpc(a)hut.fi Subject: GPC for LINUX Item Type: Note Hello, there! Some months ago I tried GPC, which came with my SuSE 5.1 distribution, but I could not use it. The reason: ----------- GPC DIDN'T ALLOW THE SIMPLEST TURBOPASCAL COMMANDS, f.e. assign(). This and the missing documentation made it nearely impossible to write programs which do more than printing "Hello world..." to the Screen. So I stopped with it immediately because I didn't want to waste time. __________________ Now I definitely have to develop some smaller applications/tools for my Linux server (now SuSE Linux 5.2) and so I am again in the same situation of searching for a *WORKING* compiler. I have heared from a compiler which is VERY similar to TurboPascal and also includes an IDE. I guess, this is NOT GPC - am I right? Anyway, I hope that GPC has also changed very much and become usable. Has it meanwhile become much more compatible to Turbo-/Borland Pascal? I would like to be able to compile DOS programs with a minimum of changes with GPC. Please be so kind and leave me some information. Thanks in advance, Rainer Hantsch (hantschr(a)hantsch.co.at) ---------------------------------------------------------------------- | Office address: | You may reach us by: | |--------------------------|-------------------------------------------| | ING. RAINER HANTSCH | Phone : +43 1 7988538 0 | | Khunngasse 21/1 | Fax : +43 1 7988538 18 | | A-1030 Wien/Vienna | BBS : +43 1 7988538 17 | | | e-Mail: hantschr(a)hantsch.co.at | | *** A U S T R I A *** | www : http://members.eunet.at/hantschr/ | ----------------------------------------------------------------------

2 1

Re: Another more striking example
by Kevin A. Foss 08 May '98

08 May '98

On Thu, 07 May 1998 23:12:03 +0200, FPL wrote: >program loop2(input, output); >var > i, j : integer; > >begin > j:=0; > repeat > for i:=0 to 10 do > if (i div 2)=0 then > begin > write('*'); > j:=j+1; > end; > writeln; > until j=10; >end. > >Do you agree the output should be a rectangular array of 5 stars by ten, >namely, something like No. Note that for i from 0 to 10 "i div 2" will only equal 0 when i = 0 and when i = 1, otherwise, 2 will go into i at least once. This is what I get for output: ** ** ** ** ** Which is correct, as you increment j everytime you print a star. Putting in a write(j); before you increment j may help you understand what is going on. If you want 10 rows then you need to increment j outside of the 'if' block, which is probably most easily done by just removing the begin/end pair. [...] if (i div 2) then write('*'); j := j + 1 writeln; [...] If you want 5 stars across, then make i go from 1 to 10 and change the test to (i mod 2). hope this helps, -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

4 3

Re: Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Frank Heckenbach 07 May '98

07 May '98

Johan Larsson wrote: > I am the author of EFLIB, a free object-oriented extension for > Object-Pascal which currently is evolving but will be released in a brand > new version soon. Our software gets more and more mature for every day. We > now want to make EFLIB a standard template library for both of your > languages: GNU Pascal and FPK Pascal, and we want to support CORBA, X11, > Windows NT and even Motif. Also, we want to keep the project close to the > state of art in computer science. We want to incorporate only modern > algorithms, modern solutions and - most importantly - only modern > approaches to software reuse: the design patterns. > > EFLIB is free software (http://www.csd.uu.se/projects/EFLIB/Support/FAQ/). > We believe that a free mind "is-a" creative mind. However, EFLIB will also > be wrapped and sold in a commercial CDROM kit. We believe that free > software can indeed be commercial software as well (as do Richard Stallman > for that matter). To warrant the freedom of distribution and use, we use a > GNU LGPL-compatible license agreement (currently being completed by a > Swedish lawyer). I appreciate that it will be free software. However, due to the recent creation of the NPL, MPL and other more or less compatible free licenses, I'm a bit wary that it will really be a GPC compatible license. I looked at the license mentioned above, but I'm not a lawyer :-), therefore I'd like to see an official statement confirming the possibility to combine it with GPL/LGPL licensed software (i.e. to use and distribute without conflicting with either of the licenses). I hope this will be possible. > We think EFLIB will prove to be a great value for the future of > Object-Pascal. We believe that the next step of programming will be an > increased level of abstraction due to the introduction of design patterns > and other higher-level entities of software design. We also believe in > modelling and tool support for software design. We want to combine all of > these things in EFLIB. We are also considering integrating modern > technologies such as CORBA and Motif support. The trend goes to language > and platform independence and universal modelling and reuse, and that's > exactly what EFLIB is all about. GPC is also about platform idependence and easy to integrate with other languages, so this could be a good combination. :-) > I am, as the project leader of EFLIB, confident that EFLIB will fit actual > needs as an official standardized class library for FPK Pascal and GNU > Pascal, and partially for Borland Delphi 3. However, to reach this goal I > will need collaboration from all of you. Many people have already reacted > positively to EFLIB in the FPK and GNU domain. First of all, we need > developers who can help us with the actual coding and testing, and give us > response to the specifications. We need experienced CORBA / ORB / DCOM > developers. We need experts on design patterns and reuse, and experienced > developers in X11, Motif and Windows NT. We also need some changes in the > GNU and FPK Pascal standards: full support for properties, class model and > exception handling. It could well be time for a precise standard to settle > between GNU and FPK. These things are actually planned for GPC: - Properties: I have them listed in my To-Do-list (http://fjf.gnu.de/gpc-todo_toc.html), but I personally don't know too much about them. Are they a Delphi extension? If so, are there any documents available to describe them, or otherwise, could some Delphi user put together a list of features required that could be used as a "standard" that GPC, and perhaps FPK, can implement? - Classes: At http://pascal-central.com/OOE-stds.html, there is a draft for an ANSI Object Pascal standard. AFAIH, Delphi's implementation is quite close to this standard. One of the plans for GPC is to implement this standard draft without dropping the BP object model that is already implemented, in the hope that there won't be great conflicts between the two. - Exception handling: I myself would like to use it (for OOP as well as non-OOP programs), so I'd be willing to put some effort into implementing it when I have the time (later this year, hopefully). However, as with properties, I'm lacking a (pseudo-)standard. I do know the Java exception handling, and I think it's not too bad and could be implemented similarly in Pascal. OTOH, I read that the latest GCC version (on which GPC is based) has introduced exception handling, so it might be easier to implement this if we can reuse that code. OTTH, if there already is an implementation in a Pascal dialect (Delphi?), and it's suitable, it would be a good idea to be compatible to this. So again, could someone make a list of required features (perhaps with some sample code)? -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

4 3

Another more striking example
by FPL 07 May '98

07 May '98

Peter, list, I think this program is a better example of what the problem is. It is not as artificial as the prior one, and can be executed without gdb so that one can see the problem may lie somewhere else that in debugging informations. program loop2(input, output); var i, j : integer; begin j:=0; repeat for i:=0 to 10 do if (i div 2)=0 then begin write('*'); j:=j+1; end; writeln; until j=10; end. Do you agree the output should be a rectangular array of 5 stars by ten, namely, something like ****** ****** ****** ****** ****** ****** ****** ****** ****** ****** ? Well, what *I* get when running the output code is * * * * * * * * * * Is it the same with you? (You just cannot imagine how scared I am that *my* and only mine GPC version, poorly installed, is bugging this way). Also, I have (in the other program) some file of text type ever opened, and I have noticed in applying your advice that GPC complains it cannot write on the default output device (the screen) because of my opened file. Just a writeln('*') and *not* a writeln(f, '*') wille make it say ?GPC runtime error: File is not open for writing (#9) Cheers. F.P.L

1 0

Is it a bug?
by FPL 07 May '98

07 May '98

I have a piece of code that does not follow my understanding of pascal. As I don't want to bother you in reading long code, here is a tiny model, that (mis)behave the same. 1=1 and 1=2 are to avoid discussing "when it does occur" or "once it stopped". I just don't know wether it is a bug or an error of mine. 1 program model(input, output); 2 var 3 i : integer; 4 5 begin 6 repeat 7 for i:=1 to 10 do 8 if 1=1 then 9 writeln('*'); 10 until 1=2; 11 end. As I understand it, once reached line 7 (the 'for' loop), the following instruction ('if then') is executed ten times, so the output consists in a row of ten stars as the 1=1 is always true. Then the 'repeat until' loop is executed, forever since 1 never equals 2. It is not obvious the programme does not work if one executes it, but the debugger will betray another behaviour (if you change something in the structure, it is not certain it will still "not work"). Once reached the 'for' statement, only one star is printed then the pointer directely jumps on repeat, not printing ten stars in a row, just one. Nothing is changed in 'begin end;' insertion in the code. If it is some kind of bug, I theoretically use last GPC beta version. Cheers. F.P.L

2 3

Re: How it is compilated?
by richard.kerry＠quantel.com 07 May '98

07 May '98

It has to call(a) twice. There may be something else being done in call(), globals read/altered, files used, hardware accessed etc. VAX Pascal has a directive, called something like 'deterministic', which means that a routine, when called with the same parameters, will return the same result and not affect anything else. The alternatives are a scheme like this, or the compiler analyzes the routine and determines whether it is deterministic or has any side effects. I'm sure our compiler writing friends would be happy to spend a very large amount of time writing this. This is related to the reason why short-circuit evaluation should not be done unless requested. Some other bit of program may rely on all the components being evaluated if they are functions. Regards. Richard.

1 0

How it is compilated?
by FPL 07 May '98

07 May '98

Hi Peter, Hugh Chief, Howdy the list. I think one good reason why peoples interested in programming should know a bit about compilers is that they hence have an idea how to write their code so that the compilated version of it won't be too bad. I know damn shit about compilers, but there is this situation I am always perplex about when facing it. Suppose "call" is a big complicated function, say, a theta(2**n) one, really the big one. How will GPC translate the following line into machine code? if call(a)=1 or call(a)=2 then ... Will it call two times the function? Or will it by itself do the simplification? Should we by ourselves complicate our way of writting code in defining another variable to store in advance the result of call(a)? Cheers (and thanks Peter for your proposal of implementing set of records, I use something near it, it works fine). F.P.L

2 1

set of record
by FPL 06 May '98

06 May '98

Hi the list, This appear not to be a GPC relevant question, sorry. Cannot we define set of record? type cellule = record x, y : integer; age : integer; end; population = set of cellule; This does not compilate, is it a language non sens?

2 1

Initialisation while declaration
by FPL 05 May '98

05 May '98

Hi the list, Does GPC support a feature kindwise those of C compiler that is to define the content of something while you declare it? I mean, assume I want to define one integer then to set it to naught, C allow me to replace int c; c=0 with int c=0; Is GPC can do the same than elder brother gcc? If it can, is it a GPC feature or is it Borland compatible? And how to do it to initialise each field of a record? See ya! Fabrice Llaussy "Rune's Rule: If you don't care where you are, you ain't lost." "Look out fo' flyeeng feet" O__/ \ laussy(a)nat.fr \/|_____. - O <__.\/\> / / \ __________|___\______ http://ourworld.compuserve.com/homepages/BigApe323

5 4

Reformatted: EFLIB as class library for Object-Pascal (fwd)
by Johan Larsson 04 May '98

04 May '98

Some people have complaint about the lack of line terminators in my proposal message (attached). I therefore resend it as requested. A aplogize for any discomfort I may have caused you. The message can also be read on WWW: http://www.acc.umu.se/EFLIB/Lists/EFLIB-Developers/9805/0000.html Regards, Johan Larsson ---------- Forwarded message ---------- Date: Sun, 3 May 1998 12:25:30 +0200 From: Johan Larsson <jola(a)csd.uu.se> Dear Developers of GNU Pascal and FPK Pascal. I am the author of EFLIB, a free object-oriented extension for Object-Pascal which currently is evolving but will be released in a brand new version soon. Our software gets more and more mature for every day. We now want to make EFLIB a standard template library for both of your languages: GNU Pascal and FPK Pascal, and we want to support CORBA, X11, Windows NT and even Motif. Also, we want to keep the project close to the state of art in computer science. We want to incorporate only modern algorithms, modern solutions and - most importantly - only modern approaches to software reuse: the design patterns. EFLIB is free software (http://www.csd.uu.se/projects/EFLIB/Support/FAQ/). We believe that a free mind "is-a" creative mind. However, EFLIB will also be wrapped and sold in a commercial CDROM kit. We believe that free software can indeed be commercial software as well (as do Richard Stallman for that matter). To warrant the freedom of distribution and use, we use a GNU LGPL-compatible license agreement (currently being completed by a Swedish lawyer). EFLIB is primarily a free scientific software and secondly a basis for research on software reuse, object-orientation and modern algorithms. We believe that this treble nature of EFLIB is one of its greatest strengths. We think EFLIB will prove to be a great value for the future of Object-Pascal. We believe that the next step of programming will be an increased level of abstraction due to the introduction of design patterns and other higher-level entities of software design. We also believe in modelling and tool support for software design. We want to combine all of these things in EFLIB. We are also considering integrating modern technologies such as CORBA and Motif support. The trend goes to language and platform independence and universal modelling and reuse, and that's exactly what EFLIB is all about. I am, as the project leader of EFLIB, confident that EFLIB will fit actual needs as an official standardized class library for FPK Pascal and GNU Pascal, and partially for Borland Delphi 3. However, to reach this goal I will need collaboration from all of you. Many people have already reacted positively to EFLIB in the FPK and GNU domain. First of all, we need developers who can help us with the actual coding and testing, and give us response to the specifications. We need experienced CORBA / ORB / DCOM developers. We need experts on design patterns and reuse, and experienced developers in X11, Motif and Windows NT. We also need some changes in the GNU and FPK Pascal standards: full support for properties, class model and exception handling. It could well be time for a precise standard to settle between GNU and FPK. Some links to the project: http://www.csd.uu.se/projects/EFLIB/ http://www.csd.uu.se/projects/EFLIB/Documentation/Documents/Specifications/ http://www.csd.uu.se/projects/EFLIB/Developing/ ftp://ftp.sunet.se/pub/lang/EFLIB/ ftp://ftp.csd.uu.se/users/jola/EFLIB/ Best Regards, Johan Larsson URL: http://www.csd.uu.se/~jola/ MAIL: jola(a)csd.uu.se Also, REMEMBER to check out EFLIB, the free object-oriented framework for EVERY Pascal programmer, at http://ftp.sunet.se/EFLIB/. Simply SOPHISTICATED!

1 0

OOP, Pas <-> C++ and ASM OO...
by Orlando Llanes 03 May '98

03 May '98

I know it's been asked before, but I ask again because maybe the answer will be different this time. How can I code an external assembly routine as an object method? And is it possible to declare a C++ object and import it into Pascal or vice-versa without having to re-write the code? 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 3

ESP (Was: OOP, Pas <-> C++ and ASM OO...)
by Frank Heckenbach 03 May '98

03 May '98

Orlando Llanes wrote: > Thank you!!! 8~) The dream of OOP <sniffle, wiping tear from eye> is > once again reality =B) BTW, I found that external assembly routines (I'm > using NASM) allow one to use the EBP register as long as its value is > preserved at the start of the routine and restored at the end. To > reference the values on the stack, I used [ESP+8] for the first parameter, > [ESP+n] for the next ones. BTW, the compiler can access the values on the stack via ESP, too, if you give it the --omit-frame-pointer option. I'm not sure why this is not the default (at least when optimization is turned on), but the GCC developers surely have their reasons... -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

2 1

invalid type code 19
by FPL 03 May '98

03 May '98

Hi list, (gdb) whatis Prioritee_trouvee type = <invalid type code 19> 183$ gpc --version 971001(2.7.2.1) Prioritee_trouvee (found_priority) is defined as a Boolean. If evaluated, gdb will give it a value of 8, and this invalid type code 19! What's 19 for GPC? Also, how many Peter Gerwinsky are there over there? I just cannot believe they are only one always behind the computer solving all those problems, answering all those questions, all the time, all the time! Can we copy them as part of the GNU project? (no offense of course) Cheers. F.P.L

2 1

EFLIB as class library for Object-Pascal
by Johan Larsson 03 May '98

03 May '98

Dear Developers of GNU Pascal and FPK Pascal. I am the author of EFLIB, a free object-oriented extension for Object-Pascal which currently is evolving but will be released in a brand new version soon. Our software gets more and more mature for every day. We now want to make EFLIB a standard template library for both of your languages: GNU Pascal and FPK Pascal, and we want to support CORBA, X11, Windows NT and even Motif. Also, we want to keep the project close to the state of art in computer science. We want to incorporate only modern algorithms, modern solutions and - most importantly - only modern approaches to software reuse: the design patterns. EFLIB is free software (http://www.csd.uu.se/projects/EFLIB/Support/FAQ/). We believe that a free mind "is-a" creative mind. However, EFLIB will also be wrapped and sold in a commercial CDROM kit. We believe that free software can indeed be commercial software as well (as do Richard Stallman for that matter). To warrant the freedom of distribution and use, we use a GNU LGPL-compatible license agreement (currently being completed by a Swedish lawyer). EFLIB is primarily a free scientific software and secondly a basis for research on software reuse, object-orientation and modern algorithms. We believe that this treble nature of EFLIB is one of its greatest strengths. We think EFLIB will prove to be a great value for the future of Object-Pascal. We believe that the next step of programming will be an increased level of abstraction due to the introduction of design patterns and other higher-level entities of software design. We also believe in modelling and tool support for software design. We want to combine all of these things in EFLIB. We are also considering integrating modern technologies such as CORBA and Motif support. The trend goes to language and platform independence and universal modelling and reuse, and that's exactly what EFLIB is all about. I am, as the project leader of EFLIB, confident that EFLIB will fit actual needs as an official standardized class library for FPK Pascal and GNU Pascal, and partially for Borland Delphi 3. However, to reach this goal I will need collaboration from all of you. Many people have already reacted positively to EFLIB in the FPK and GNU domain. First of all, we need developers who can help us with the actual coding and testing, and give us response to the specifications. We need experienced CORBA / ORB / DCOM developers. We need experts on design patterns and reuse, and experienced developers in X11, Motif and Windows NT. We also need some changes in the GNU and FPK Pascal standards: full support for properties, class model and exception handling. It could well be time for a precise standard to settle between GNU and FPK. Some links to the project: http://www.csd.uu.se/projects/EFLIB/ http://www.csd.uu.se/projects/EFLIB/Documentation/Documents/Specifications/ http://www.csd.uu.se/projects/EFLIB/Developing/ ftp://ftp.sunet.se/pub/lang/EFLIB/ ftp://ftp.csd.uu.se/users/jola/EFLIB/ Best Regards, Johan Larsson URL: http://www.csd.uu.se/~jola/ MAIL: jola(a)csd.uu.se Also, REMEMBER to check out EFLIB, the free object-oriented framework for EVERY Pascal programmer, at http://ftp.sunet.se/EFLIB/. Simply SOPHISTICATED!

1 0

RE: Useless evaluation
by Andreas Prucha [helicon] 03 May '98

03 May '98

Hi, I'm just playing around with GPC, so I can't say much about GPC yet, but... >I know for having read it somewhere that, as does gcc, GPC stops >evaluating as soon as it knows what is the result. For example, >evaluating for A and B, with A set to 0, it does not evaluate B for it >knows it does not worth doing it. ****snip**** >One may object that it does not change anything but efficiency. I have >conversely some code that will work if only the first part is evaluated >but will bug if the second is (that is quite curious. Don't worry. It >works with GPC, will it too with borland?) Delphi supports shortcircuit-evaluation, too. And I think so does BP... lets have a look... yes, BP supports it, too. Shortcircuit evaluation is default in both, Delphi (Object Pascal) and Borland Pacal. The compiler directive $B or $BOOLEVAL can be used to switch it on or off. Andreas

1 0

Useless evaluation
by FPL 02 May '98

02 May '98

Hi the list, I know for having read it somewhere that, as does gcc, GPC stops evaluating as soon as it knows what is the result. For example, evaluating for A and B, with A set to 0, it does not evaluate B for it knows it does not worth doing it. I don't know if this is due to the fact that, at a certain scale, GPC is mixed up with gcc, and here is my question: Is it a particularity of gcc (injected in GPC) or is it something true for all compilers. At least, can one code with this feature in the back of the mind without fear of borland unportability. One may object that it does not change anything but efficiency. I have conversely some code that will work if only the first part is evaluated but will bug if the second is (that is quite curious. Don't worry. It works with GPC, will it too with borland?) Cheers.

2 1

Symlinking is not enough
by Peter Gerwinski 02 May '98

02 May '98

Hi, everyone! I just experienced that GNU `make' distinguishes whether the `p' subdirectory has been symlinked or physically moved to the GCC source directory. Maybe other programs do the same. All those who have problems with some files not being found should retry with `mv gpc/p gcc/' instead of `ln -s "../gpc/p/" gcc/p'. Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980410 PGP: see homepage - 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

gpc 2.xx patch probs | Solaris 2.6
by Evan Cooch 01 May '98

01 May '98

Greetings - On the recommendation of Frank Heckenbach, who has been trying to help me, I'm posting a note on this maillist to see if I can resolved what should be a simple problem. Please cc replies to me directly, since I'm not currently subscribed to the list. I am running an ultraSPARC Sun with Solaris 2.6, and the latest Solaris 2.6 binary of the patch utility. I'm trying to install gpc-980401 on my machine, and implement the various "diffs" (patches). I have gcc-2.8.1 already installed. Here is what I've tried. - created a new directory - unpacked the GCC-2.8.1 and then GPC-980401 archives - ln -s "../gpc-980401/p" gcc-2.8.1 (the quotes being necessary to prevent ".." from being expanded by tcsh in my case) - cd gcc-2.8.1 - gunzip -c ../gpc-980401-980405.diff.gz | patch -p1 It is in the last step that I have the problems. When I execute this command, my system respinds with: Looks like a unified context diff. File to patch: In other words, it sits there and asks me for the name of the file I want to patch. Its supposed to get this from the diff file directly - but it clearly ins't working. I've tried all the permutations of the "-pxx" option for patch, and I can't find any clue from the man pages what I should be doing differently. Any suggestions? Thanks very much in advance. Again, if you send a copy of your reply to me directly, I'd appreciate it. Evan Cooch Department of Biological Sciences Simon Fraser University cooch(a)fraser.sfu.ca

2 1

Is gcc bad?
by FPL 01 May '98

01 May '98

My version of gcc is 2.7.2. Is it a bad version to compilate gpc-971001? Or am I just downloading on an out of date server (agnes?) AND_, DIV_ and all the family is well defined in parse.y. How should it be different? What's wrong? Am I?

2 1

IT WORKS!
by FPL 01 May '98

01 May '98

No. It was a joke. Where does this error comes from? make[1]: Entering directory `/scratch/install/gcc-2.7.2.1/p' cc -c -DIN_GCC -DGPC -g -I. -I.. -I. -I./.. -I./../config gpc-lex.c In file included from gpc-lex.c:102: hash.h:122: `AND_' undeclared here (not in a function) hash.h:122: initializer element for `wordlist[24].token' is not constant hash.h:125: `NOT_' undeclared here (not in a function) hash.h:125: initializer element for `wordlist[27].token' is not constant hash.h:126: `NIL_' undeclared here (not in a function) hash.h:126: initializer element for `wordlist[28].token' is not constant hash.h:136: `MOD_' undeclared here (not in a function) hash.h:136: initializer element for `wordlist[38].token' is not constant hash.h:153: `DIV_' undeclared here (not in a function) hash.h:153: initializer element for `wordlist[55].token' is not constant hash.h:161: `SET_' undeclared here (not in a function) hash.h:161: initializer element for `wordlist[63].token' is not constant hash.h:176: `CONST_' undeclared here (not in a function) hash.h:176: initializer element for `wordlist[78].token' is not constant make[1]: *** [gpc-lex.o] Error 1 make[1]: Leaving directory `/scratch/install/gcc-2.7.2.1/p' make: *** [gpc1] Error 2 Cheers.

2 2

Re: Compiling problems when installing gpc-980420
by Igor Perisic 30 Apr '98

30 Apr '98

Hi Nick, I checked the core file that I found in p/rts where the compiling stoped. And here is what I get using the bt or backtrace command on the core file: (gdb) core-file core Core was generated by `gpc1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/shlib/libc.so...(no debugging symbols found)...done. warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x12021105c This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. #0 0x12021105c in ?? () (gdb) bt #0 0x12021105c in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x1202261c8 Now the problem is that DEC doesn't deliver a "debugger" material for free so I am using gdb (I don't have the license for DEC's dbx). In my signal.h file 11 is segmentation fault as is also shown above. I have no idea what this heurisitic-fence-post is so I'll try to play with it. Thanks for the help though. I looked at using glibc... instead of libc but got this ugly message ;-) loading cache ./config.cache checking host system type... alpha-dec-osf4.0 *** The GNU C library is currently not available for this platform. *** So far nobody cared to port it and if there is no volunteer it *** might never happen. So, if you have interest to see glibc on *** this platform visit As you see I don't really want to go down that road for now... Hope the small bt can help though... Igor

1 0

Re: Compiling problems when installing gpc-980420
by Igor Perisic 30 Apr '98

30 Apr '98

Sorry Peter, I tried your fix up but I still end at the same place with exactly the same error message. What does that error 11 stand for? I checked gcc (version 2.8.1) and it was working fine so the "error" shouldn't come from there. I tried your fix up starting from the begining, that is deleting all the *.o files and reruning the make command. Thanks for your help .... Igor

2 1

Compiling problems when installing gpc-980420
by Igor Perisic 30 Apr '98

30 Apr '98

Hi all, I've been talking with Peter for a while now about my problems with installing gpc on my machine. After trying to put the 2.0 version, he "persuaded" me to look at the alpha version of 2.1 (which is supposed to be already more stable). I am running Digital Unix 4.0D on a Dec Alpha machine. I reinstalled gcc-2.8.1 in order to be able to build gpc-980420 (the latest version that is available). I edited the p/diffs/gcc-2.8.1.diffs to point to gcc-2.8.1 instead of gcc-2.8.0 and I edited a couple of lines in config-lang.in for the test about the version of gcc to require 2.8.1 instead of 2.8.0. Patched all the patches, installed the source at the correct place typed ./configure then cd p and ./configure (then edited a line in config.cache as it seemed to still want to use cc-E as the preprocessor to switch it to gcc -E) reruned ./configure and then launched make LANGUAGES=pascal in the source (gcc-2.8.1) directory. I get stuck at the compiling of rts-base.p and here is my error message. I included some previous lines since I get something weird with rts-string.c (which is compiled two steps before the rts-base.p): error> rts-string.c:632: warning: no previous prototype for `_p_val_medcard_nocheck' error> rts-string.c:633: warning: no previous prototype for `_p_val_longcard_nocheck' error> rts-string.c:662: warning: no previous prototype for `_p_val_shortreal' error> rts-string.c:663: warning: no previous prototype for `_p_val_real' error> rts-string.c:664: warning: no previous prototype for `_p_val_longreal' error> ../../xgcc -B../../ -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../../config rts-bind.c error> ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../../config rts-base.p error> xgpc: Internal compiler error: program gpc1 got fatal signal 11 error> *** Exit 1 error> Stop. error> *** Exit 1 error> Stop. Using Peter's comments (from a previous email) I reran the last command with the following flags -v --automake=-v and here is the result: new command> # ../../xgpc -B../../ -v --automake=-v -c -DGPC -Wall -g -I. -I../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../../config rts-base.p messages> Reading specs from ../../specs messages> gpc driver version 980420(2.8.1) executing gpc version 2.8.1 messages> ../../gpc-cpp -lang-pascal -v -I. -I../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../.. -I/usr/users/igor/TEMP/gcc-2.8.1/p/rts/../../config -isystem ../../include -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -Acpu(alpha) -Amachine(alpha) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -g -Wall -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -DGPC rts-base.p /tmp/ccaaabaa.i messages> GNU CPP version 980420(2.8.1) messages> #include "..." search starts here: messages> #include <...> search starts here: messages> . messages> ../.. messages> /usr/users/igor/TEMP/gcc-2.8.1/p/rts/../.. messages> /usr/users/igor/TEMP/gcc-2.8.1/p/rts/../../config messages> ../../include messages> /usr/local/include messages> /usr/local/alphaev56-dec-osf4.0d/include messages> /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.8.1/include messages> /usr/include messages> End of search list. messages> ../../gpc1 /tmp/ccaaabaa.i -quiet -dumpbase rts-base.pas -g -Wall -version -famtmpfile=rts-base.gpc -fautomake=-v -o /tmp/ccaaabaa.s messages> GNU Pascal version 980420(2.8.1) (alphaev56-dec-osf4.0d) compiled by GNU C version 2.8.1. messages> xgpc: Internal compiler error: program gpc1 got fatal signal 11 Peter also told me to run it with the -dy or -dY to have more info on what is going. The results are identical to the one just described above. Word for word the messages are the same. I hope that there anyone out there that knows what is going on. As you can see, I am not an expert at this but I am looking forward to be able to continue to program in pascal. Thanks a lot in advance. Igor

3 2

Re: Compiling problems when installing gpc-980420
by Frank Heckenbach 29 Apr '98

29 Apr '98

Igor Perisic wrote: > I get stuck at the compiling of rts-base.p and here is my error > message. I included some previous lines since I get something weird with > rts-string.c (which is compiled two steps before the rts-base.p): > > error> rts-string.c:632: warning: no previous prototype for `_p_val_medcard_nocheck' > error> rts-string.c:633: warning: no previous prototype for `_p_val_longcard_nocheck' > error> rts-string.c:662: warning: no previous prototype for `_p_val_shortreal' > error> rts-string.c:663: warning: no previous prototype for `_p_val_real' > error> rts-string.c:664: warning: no previous prototype for `_p_val_longreal' Sorry, I can't help you with the real problem, but these warnings are normal. I wrote those functions and I was just too lazy to write prototypes for all of them. There are more warnings while compiling the RTS which can be ignored. Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach

1 0

GNU Pascal and Delphi
by Andreas Prucha [helicon] 27 Apr '98

27 Apr '98

Hi, I'm currently evaluating the possibility to use Linux for our applications in some cases. Our applications are written in OP (Delphi) and I've had a quick look at gpc and fpc. Well, the area where I imagine using Linux are server applications, and I hope to find a solution to use (widely) the same code-base for the NT-version and the Linux-version. Since these applications usually don't have a GUI, the visual part of the VCL is not the problem. And other parts can be easily ported. Anyway, I've read that GPC's focus is on portability. That's great. But I see no reason not to support the non-windows specific things. I know, OP is not based on a standard like Extended Pascal, /but/ I think OP /is/ the standard, because I can't imagine that any other Pascal-dialect is that widely used. Anyway, I've not check GPC very deeply, yet, so some of my statements might be wrong. Ok, here is what I'd like to see: - Compatibility with OP (Delphi) as far as possible w/o leaving the portabil ity-track. (Beside some features like message-handler-methods, there should not be much) - Exception handling - OP-style object-model - OP-style strings (reference-counted or not) However, IMO it is great, that Pascal is going to be supported in the UNIX-world. It is a under-estimated langugage (esp. OP), IMO. Andreas

2 1

Linking and Libraries...
by Orlando Llanes 26 Apr '98

26 Apr '98

I have 2 questions, I tried looking in the GPC and DJGPP docs but couldn't find it.. 1) Let's say I have a compiled routine with a .o extension, how can I link it with GPC in the same command-line? 2) How do I create a library? Thanks in advance! 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 1

Append()
by Mercator-Gymnasium 23 Apr '98

23 Apr '98

Is there an append() or similar procedure that allows me to write directly to the end of text files? If you have any information, please contact me direct by email. Thanks. Geoffrey Arnold garnold(a)cyberdrive.net Mercator-Gymnasium Duisburg Tel.: (0203) 283-7960 Fax: (0203) 283-7966

2 1

Re: trouble compiling gpc source on m68k
by Peter Gerwinski 23 Apr '98

23 Apr '98

Hi, Alan! > make[1]: Entering directory `/tmp/temp/gcc-2.8.0/p/rts' > ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototy > pes -Wmissing-declarations -O3 -fomit-frame-pointer -I. -I../.. -I/tmp/temp/gcc > -2.8.0/p/rts/../.. -I/tmp/temp/gcc-2.8.0/p/rts/../../config rts-base.p > make[1]: *** [rts-base.o] IOT trap/Abort (core dumped) This *might* be a rather trivial problem with the version number. Please retry with a changed `p/version.c' that contains a line char *version_string = "2.8.0"; instead of char *version_string = GPC_VERSION_STRING; Good luck, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980410 PGP: see homepage - 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

New Alpha gpc-980410 (source and binaries)
by Peter Gerwinski 22 Apr '98

22 Apr '98

Hello, everybody! A new alpha version, gpc-980410, is being uploaded to Agnes: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ The major changes affect the DJGPP platform. Some crashes which occured under environments with memory protection (such as OS/2 or Windows 95) are fixed now. Some other minor fixes have been done, too (see `ChangeLog'). The problem was due to a new version of `libc.a' used in gpc-980405 which was necessary in order to fix the I/O problem in gpc-980401. The solution was to combine the old and the new version of `libc.a'. As you can imagine, compilation under DJGPP is now even harder than it was anyway ... The problem that `gpc' produces `.exe' files named `a.out' is still present. Just rename it, and it will work. :-/ Happy Eastern, :-) Peter

3 2

Bug??
by Bendersky 21 Apr '98

21 Apr '98

Hi again, Why do I get this: *********************************** Reading specs from c:/utils/gpc/lib/specs gpc driver version 980420(2.80) executing gpc version 2.8.0 c:/utils/gpc/bin/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__unix -D__i386 -D__GO32 -D__ MSDOS -D__DJGPP=2 -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D_ _BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acp u(i386) -Amachine(i386) mandel1.pas c:/utils/gpc/tmp/ccbaaaaa GNU CPP version 980420(2.80) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/utils/gpc/include c:/utils/gpc/lang/pascal c:/utils/gpc/contrib/grx22/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.80/include $DJDIR/include End of search list. c:/utils/gpc/bin/gpc1.exe c:/utils/gpc/tmp/ccbaaaaa -quiet -dumpbase mandel1.pa s -version -famtmpfile=mandel1.gpc -fautomake=-v -o c:/utils/gpc/tmp/cccaaaaa GNU Pascal version 980420(2.80) (djgpp) compiled by GNU C version 2.8.0. Exiting due to signal SIGSEGV Page fault at eip=00122752, error=0004 eax=003c500c ebx=00394620 ecx=00000000 edx=00084421 esi=003d8ca0 edi=003dabac ebp=0035f5f4 esp=0035f5ec program=c:/utils/gpc/bin/gpc1.exe cs: sel=0117 base=838a8000 limit=ff6b6fff ds: sel=011f base=838a8000 limit=ff6b6fff es: sel=011f base=838a8000 limit=ff6b6fff fs: sel=00ef base=00035580 limit=0000ffff gs: sel=012f base=00000000 limit=ffffffff ss: sel=011f base=838a8000 limit=ff6b6fff Call frame traceback EIPs: 0x00122752 0x0011e0a2 0x00120600 0x0011f8fd 0x0011f928 0x0011f933 0x0011f933 0x0011f933 0x0011f933 0x0011f933 0x0011f933 *********************************** While trying to compile this: ********MANDEL1.PAS************* Program Mandelbrot; Uses grx20; Procedure Genera; var z, c : complex; x, y : integer; n : integer; pre, pim : real; begin for x:=1 to 640 do for y:=1 to 480 do begin pre := (4/640)*x - 2; pim := (4/480)*y - 2; z := cmplx (pre, pim); c := z; n := 0; repeat z:=(z pow 2) + c; inc(n); until ((n=255) or (abs(z)>4)); GRplot(x, y, n); end; end; var x, y, xv, yv, c, m : integer; begin x := 640; y := 480; xv := 640; yv := 640; c := 256; M := GrSetMode(GR_width_height_color_graphics,x,y,c,xv,yv); genera; end. ********************************* Using: ********************************* gpc -v --automake=-v mandel1.pas I'm running GPC under DJGPP in a DOS box under windows 95. Thanks, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

2 1

New Alpha: gpc-980420
by Peter Gerwinski 20 Apr '98

20 Apr '98

Hi, everybody! A new alpha version of GPC is now on Agnes, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. (Source (diff) and binaries for Linux and DJGPP.) Hopefully those strange DJGPP-specific problems are solved now. AFAI could find out, they came from a stack limit of 256kB on DJGPP which was not enough for `load_tree()', a function which recurses deeply when loading a large GPI file. In the DJGPP binary just uploaded, I `stubedit'ed it to 2MB. Now you can again do `uses GRX20'. Have fun, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980410 PGP: see homepage - 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

trouble compiling gpc source on m68k
by alan czarnecki 19 Apr '98

19 Apr '98

Greetings, I am having trouble compling the latest gpc source on my m68k based system... an amiga 2000. The attempt to build from source dies at the following point: [root@localhost gcc-2.8.0]# make CFLAGS=-O3 LANGUAGES=pascal make: Circular cplib2.ready <- pascal dependency dropped. case "pascal" in \ *pascal*) cd p/rts && make \ GCC_FOR_TARGET="`case './xgcc -B./' in \ './xgcc -B./') echo ../../xgcc -B../../;; \ *) echo './xgcc -B./';; esac`" \ GPC_FOR_TARGET="`case './xgpc -B./' in \ './xgpc -B./') echo ../../xgpc -B../../;; \ *) echo './xgpc -B./';; esac`" \ GCC_FLAGS="" CROSS="" AR_FLAGS="rc" AR_FOR_TARGET="/usr/m68k-unknown-linux-gnu/bin/ar"\ BISON="bison" BISONFLAGS="" CFLAGS="-O3" X_CFLAGS="" LDFLAGS=""\ RANLIB_FOR_TARGET="/usr/m68k-unknown-linux-gnu/bin/ranlib" \ RANLIB_TEST_FOR_TARGET="[ -f /usr/m68k-unknown-linux-gnu/bin/ranlib ]"\ SHELL="/bin/sh" \ all ;; \ esac make[1]: Entering directory `/temp/gcc-2.8.0/p/rts' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith\ -Wmissing-prototypes -Wmissing-declarations -O3 -I.\ -I../.. -I/temp/gcc-2.8.0/p/rts/../.. -I/temp/gcc-2.8.0/p/rts/../../config rts-base.p make[1]: *** [rts-base.o] Aborted (core dumped) make[1]: Leaving directory `/temp/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 Any pointers as to how to deal with this would be much appreciated. Thanks, Alan Czarnecki alancz(a)columbus.rr.com

2 1

gpc with egcs
by Shane Wegner 19 Apr '98

19 Apr '98

-----BEGIN PGP SIGNED MESSAGE----- Hi all, I guess you must get this alot here but I couldn't find any info on your site. What do I have to do to get the latest alpha release of gpc to work with the egcs package? - - Shane Wegner <shane(a)continuum.eu.org> Sysadmin: Continuum Systems <http://www.continuum.eu.org> Personal website: http://www.continuum.eu.org/~shane Virtualisys: http://www.virtualisys.com/vr/swegner PGP key: finger shane(a)continuum.eu.org -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNTax/aeq+0eJMsK9AQEJFwP6A+sJZEIxgIX3FOi9iWRz9Te0zddSgnnr 10nsDN5hdg3UnwfY2dtEjxr5GAZzUzLjDjbVz3aMVAtjNS76ZbUh2sZfgT7Fs0JZ xouh78zShS+91EYEbHyeAMKYFhvSAna7tE/KOP7SVMvgvoviuj0zv9W9s0xh3dA1 VXoO/8t6kdc= =DLAC -----END PGP SIGNATURE-----

3 5

Re: String Lengths in Procedures
by Kevin A. Foss 19 Apr '98

19 Apr '98

On Sun, 19 Apr 1998 11:31:26 +0200 (MEST), Peter Gerwinski wrote: >According to Kevin A. Foss: >> [...] It appears that for some reason strings that >> are defined in procedures/functions are not initialized to a length of >> 0. > >Why should they? Local variables have no predifined value on >any Pascal compiler I know. Why? ..because >For the sake of compatibility to BP, GPC initializes >all global variables to zero/false/nil/empty string. I've never seen a compiler predefine undefined variables anywhere either locally or globally before and I thought GPC would be consistant in this strangeness by predefining in both places. I didn't realize it was another Borland "feature". Obviously I assumed wrong. But isn't this dangerous? It allows the compiler to happily accept code like: program test(output); procedure test1; var a, b : string (10); begin a := a + b end. begin test1; end. And then core dump at runtime, or presumeably some other undefined result. To me it make more sense to either set local variables to 'don't let the user shoot himself the foot' values (like global variables) or actual undefine them so that the compiler can warn/give errors about it. >That was twice the same program, and it produces 0 on my (Linux) >system, too. Ack, the second program should have been the same as above, except "a := a + b;" was replaced with "writeln(length(a));" But that is a moot point now. :) Anyway, I thought this was the source of a runtime core-dump I was having with some TP source , obviously I was wrong and I'll see if I can better locate what is happening. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

2 1

String Lengths in Procedures
by Kevin A. Foss 19 Apr '98

19 Apr '98

Hello, Today I was playing around with some code and was getting some pretty wacky results from a couple string functions (anything from random trash to SIGSEGV.) It appears that for some reason strings that are defined in procedures/functions are not initialized to a length of 0. For example: program test(output); var a : string (10); begin writeln(length(a)) end. On both Linux (gpc971001) and OS/2 (gpc980410) I get a result of 0, no problem. However: program test(output); var a : string (10); begin writeln(length(a)); end. Produces 65536 in OS/2 and 134515920 in Linux. Interestingly, if you declare more strings, usually by the third or fourth string the length will actually be 0 -- but I've seen gpc on Linux return negative integers too! I'm not sure how much of a bug this is as I'm not sure that the user should assume *anything* about undefined variables. I haven't checked the EP standard about this yet. It probably should be set to 0 for BP compatibility as the code I was trying to port to GPC was written for TP and assumed undefined strings would have a 0 length. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

2 1

unsubscribe
by Phillip Bruce 18 Apr '98

18 Apr '98

unsubscribe -- ******************************************************************** *** Phillip B. Bruce That's Me **** *** Web Site: http://www.jps.net/~pbbruce Web Site **** *** Email: pbbruce(a)jps.net **** ********************************************************************

1 0

(Fwd) Re: More on my unit
by Bendersky 16 Apr '98

16 Apr '98

I was wrong, Rhide is working perfectly. I'm sorry. Ariel. ------- Forwarded Message Follows ------- From: Self <Single-user mode> To: Peter Gerwinski <peter(a)gerwinski.de>,gpc(a)hut.fi Subject: Re: More on my unit Date: Thu, 16 Apr 1998 21:50:28 ARG > According to Bendersky: > > In part, that helped. Now I'm almost sure that it compiles with the > > 980410, but I get this error with the gpc -v --automake=-v test.pas : > > [...] > > gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' > > Abort! > > The GPI format has changed. Just delete and recompile all `.gpi' > files, and this problem will vanish. > > Peter > I think it's working fine right now, thank you!!! What I couldn't make run is the rhide, is there some way? Do I need a newer version? Thanks again, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

1 0

Re: More on my unit
by Peter Gerwinski 16 Apr '98

16 Apr '98

According to Bendersky: > In part, that helped. Now I'm almost sure that it compiles with the > 980410, but I get this error with the gpc -v --automake=-v test.pas : > [...] > gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' > Abort! The GPI format has changed. Just delete and recompile all `.gpi' files, and this problem will vanish. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980405 PGP: see homepage - 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/

2 1

Re: More on my unit
by Peter Gerwinski 15 Apr '98

15 Apr '98

According to Bendersky: > This is the output of that: > **************************** > Reading specs from c:/utils/gpc/lib/specs > gpc version 2.80 > [...] > GNU CPP version 2.0(2.7.2.1) (80386, BSD syntax) > [...] > GNU Pascal version 2.0(2.7.2.1) (80386, BSD syntax) [...] > [...] > test.pas:2: installation problem, cannot exec `gpc' Now it is clear for me: You installed gpc-980410, but you still have the old gpc-2.0 binaries in your path where they are found prior to the new ones. Thus, you are still compiling with gpc-2.0. To fix it, delete (or rename;-) the files `gpc-cpp.exe' and `gpc1.exe' in `/djgpp/bin/' and the file `libgpc.a' in `/djgpp/lib'. The new version of GPC will use the executables and libraries in `/djgpp/lib/gcc-lib/djgpp/2.80/'. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980405 PGP: see homepage - 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

Re: gpc
by Peter Gerwinski 15 Apr '98

15 Apr '98

According to Shane Wegner: > > Does the gpc (gnu pascal compiler) work with egcs? Does anyone have any > information or is this compiler even being developed anymore? Current (alpha) versions of GPC are known to work with GCC 2.8.0. Using them with EGCS will probably require some patching, but should be an affordable effort. See ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ for an up-to-date version of GPC; see http://home.pages.de/~GNU-Pascal/ for more information about GPC. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980405 PGP: see homepage - 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's the latest?
by FPL 15 Apr '98

15 Apr '98

Hi the list, Hum. Sorry, I was away from the list and only skimmed your last messages. I have seen Peter announced a new release of a new stuff, I think it is the alpha 980410, I have also seen few flyeeng feet and all those debates about djgjgpgj (well, the GNU cc for DOS). So I surmise there is no great changes for a linux fella. Well, I have crashed the box and *need* to install again some version of GPC (and everything else by the way). I thought it may be sensible to install the last one. Excuse me to (eventually) ask you: where/what is the last version? (one which is stable please, contrary to half people of the list, I do not track bugs, I escape them) Thanks.

2 1

More on my unit
by Bendersky 14 Apr '98

14 Apr '98

I'm starting to think that I don't know how to use my own defined operators :-( Should this tiny program work? : ****************************** uses vectores; var a, b, c : TVector; begin a.x:=1; a.y:=2; a.z:=3; b.x:=4; b.y:=5; b.z:=6; c:=a-b; writeln(c.x); writeln(c.y); writeln(c.z); end. ********************* 'cause I still get the same error. The error is in the line c:=a-b "invalid operands to binary -". Thanks again, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

1 0

Units
by Bendersky 14 Apr '98

14 Apr '98

Hi again. I've written a small unit to work with 3D vectors. It compiles without errors, but when I'm trying to use the operators I defined from a program I get the "invalid operands to binary" error. But I can use the type defined in the unit without problems. The source code is the following: *************************** Unit vectores; Interface {$X+} {$W-} Type TVector = Record x, y, z: Real; End; Operator + ( a, b: TVector ) c : TVector; Operator - ( a, b : TVector ) c : TVector; Operator * ( a, b : TVector ) c : Real; Operator / ( a : TVector; b : Real ) c : TVector; Operator * ( a : TVector; b : Real) c : TVector; Operator * ( a : Real; b : TVector) c : TVector; Function modu ( a : TVector ) : real; Implementation Operator + ( a, b: TVector ) c : TVector; Begin c.x := a.x + b.x; c.y := a.y + b.y; c.z := a.z + b.z; End; Operator - ( a, b : TVector ) c : TVector; Begin c.x := a.x - b.x; c.y := a.y - b.y; c.z := a.z - b.z; End; Operator * ( a, b : TVector ) c : Real; Begin c := (a.x * b.x) + (a.y * b.y) + (a.z * b.z); End; Operator / ( a : TVector; b : Real ) c : TVector; Begin c.x:=a.x / b; c.y:=a.y / b; c.z:=a.z / b; End; Operator * ( a : TVector; b : Real) c : TVector; Begin c.x:=a.x*b; c.y:=a.y*b; c.z:=a.z*b; End; Operator * ( a : Real; b : TVector) c : TVector; Begin c.x:=a*b.x; c.y:=a*b.y; c.z:=a*b.z; End; Function modu ( a : TVector ) : real; Begin modu := sqrt(sqr(a.x)+sqr(a.y)+sqr(a.z)); End; {$W+} End. *************************** Does anybody know what's wrong? Thank you, Ariel --- Ariel Bendersky bender(a)einstein.com.ar

2 2

New alpha: gpc-980405
by Peter Gerwinski 09 Apr '98

09 Apr '98

Hello, everybody! I have solved the I/O problem on the DJGPP platform (and fixed some other bugs) and am now uploading a new alpha version of GPC to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ (source (diff) and binaries). Many thanks to Eli Zaretskii for his help with the I/O problem. Have fun, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

3 4

Re: New Alpha (source only) on Agnes
by Kevin A. Foss 09 Apr '98

09 Apr '98

On Mon, 30 Mar 1998 22:38:11 +0200 (MEST), Peter Gerwinski wrote: >According to Kevin Foss: >> >> Just wondering, before I download it -- is this release based on gcc 2.7.x or do we need >> 2.8.x source to compile this alpha? > >2.8.0, hopefully also 2.8.1. (Sorry, I forgot to mention.#-) Okay, I guess I won't be trying it for a while :( Currently there is no 2.8.x gcc for EMX, and I don't expect one right off for various reasons. Hopefully by this summer there will be a new release. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

4 4

Problems compiling gpc-980405
by Pat 06 Apr '98

06 Apr '98

I;ve been trying to build gpc from the alpha sources. I downloaded gpc-980405 today and get an error when it tries to build libgpc.a. Here is the error: make[1]: Entering directory `/usr/local/gcc/gcc-2.8.0/p/rts' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O3 -I. -I../.. -I/usr/local/gcc/gcc-2.8.0/p/rts/../.. -I/usr/local/gcc/gcc-2.8.0/p/rts/../../config rts-move.p gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 make[1]: *** [rts-move.o] Error 1 make[1]: Leaving directory `/usr/local/gcc/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 Anyone have a clue how to fix it? (At least this is a different error that I got trying the gpc-980330 version!) Patrick Ouellette Assistant Computer Engineer Engineering College Computing The University of Toledo Toledo, Ohio 419-530-8022 pouellet(a)eng.utoledo.edu

3 2

RE: Request for comments: gpc-2.1 schedule (fwd)
by Geoffrey Arnold 05 Apr '98

05 Apr '98

On Tuesday, March 31, 1998 8:48 PM, Peter Gerwinski [SMTP:peter@gerwinski.de] wrote: > * We are late with gpc-2.1. Current beta and alpha versions > are already much more stable than gpc-2.0 which is still > the official version. > ... > with the release until some important "holes" (which???) > are fixed might be good for GPC's reputation. I currently still use GPC 2.0. What alpha/beta release should I download and compile (what is the MOST stable)? ----------Geoffrey Arnold--------- ------garnold(a)cyberdrive.net------ http://www.cyberdrive.net/~garnold

2 1

DJGPP 2.8.x...
by Orlando Llanes 05 Apr '98

05 Apr '98

I saw the binary for djgpp 2.8.1, but at 8MB, if I download it, I want to make sure I can run it on my computer (and who knows? Maybe someone else on the list is wondering as well). Does anyone know if DJGPP 2.8.x runs on a 486? If so, does it also compile 486 code (I don't mean optimization tho, just whether or not it'll compile 486 binaries)? Thanks in advance! 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 1

CRT
by Bendersky 04 Apr '98

04 Apr '98

Hi everybody. Is there some CRT unit to use with GPC? Because I don't want to install the BPCompat kit, so it's unit doesn't work. Or if there is no CRT unit, is there some way to use the stdio.h header file? Specially the getchar function. Thank you, ARIEL. --- Ariel Bendersky bender(a)einstein.com.ar

2 3

Re: Request for comments: gpc-2.1 schedule
by Nick Burrett 04 Apr '98

04 Apr '98

Orlando Llanes wrote: > > On Wed, 1 Apr 1998, Peter Gerwinski wrote: > > According to Orlando Llanes: > > > IMO, if the alpha and beta versions are as stable as 2.0, whichever > > > works better should be set to a "gamma" version which would serve as a > > > "stand-by" version so that when DJGPP 2.8.x is ready for release, the > > > "gama" version will be placed in the distribution. > > > > And that "stand-by" version would be called 2.0.1 or 2.1.0? > > I'm posting this from an e-mail from me to Peter about GPC 2.1. I > think that the "stand-by" version should be GPC 2.1.0 rather than 2.0.1, > there have been a great many significant improvments from gpc 2.0 to where > it is now even tho it's not quite there yet. What about seting the version to 2.0.9 then change the version to 2.0.10, 2.0.11 etc. until 2.1.0 is ready. > I also wanted to add something, when I said the "gamma" version should > be released when DJGPP 2.8.1 is released, I meant that if the current Beta > version is not ready, then the "stand-by" version be released instead with > a note saying that the next version is in the works and is near completion > (or something to that effect). We can release it is 2.1.0 when it is ready. Then we can fix it to work with DJGPP 2.8.1 and release 2.1.1. Nick.

1 0

RE: Request for comments: gpc-2.1 schedule
by Berend de Boer 04 Apr '98

04 Apr '98

On Tuesday, March 31, 1998 8:48 PM, Peter Gerwinski [SMTP:peter@gerwinski.de] wrote: > * We are late with gpc-2.1. Current beta and alpha versions > are already much more stable than gpc-2.0 which is still > the official version. > ... > with the release until some important "holes" (which???) > are fixed might be good for GPC's reputation. If the current releases are more stable, I think it's best to make the next official release asap. Groetjes, Berend.

1 0

unsubscribe
by Krzysztof Kwapien 03 Apr '98

03 Apr '98

Please erase me from this list

1 0

Re: Request for comments: gpc-2.1 schedule
by Orlando Llanes 02 Apr '98

02 Apr '98

On Wed, 1 Apr 1998, Peter Gerwinski wrote: > According to Orlando Llanes: > > IMO, if the alpha and beta versions are as stable as 2.0, whichever > > works better should be set to a "gamma" version which would serve as a > > "stand-by" version so that when DJGPP 2.8.x is ready for release, the > > "gama" version will be placed in the distribution. > > And that "stand-by" version would be called 2.0.1 or 2.1.0? I'm posting this from an e-mail from me to Peter about GPC 2.1. I think that the "stand-by" version should be GPC 2.1.0 rather than 2.0.1, there have been a great many significant improvments from gpc 2.0 to where it is now even tho it's not quite there yet. I also wanted to add something, when I said the "gamma" version should be released when DJGPP 2.8.1 is released, I meant that if the current Beta version is not ready, then the "stand-by" version be released instead with a note saying that the next version is in the works and is near completion (or something to that effect). 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

1 0

gpc-980401.zip
by Peter Gerwinski 02 Apr '98

02 Apr '98

Hello, I am uploading the source of the new alpha for gcc-2.8.0 as a `.zip' file in addition to the `.tar.gz' file: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-980401.zip The `.zip' file contains long file names, so be careful when unzipping it. Peter

1 0

Conversion tool
by Dr Jia 31 Mar '98

31 Mar '98

Hi there I was wondering if someone knows how I can obtain a tool that converts from Borland Pascal 7 to ANSI C. Thanks. Dr Jia. jai2(a)icon.co.za jia(a)bigfoot.com http://www.icon.co.za/~jai2

2 1

Request for comments: gpc-2.1 schedule
by Peter Gerwinski 31 Mar '98

31 Mar '98

Hello, everybody! At http://home.pages.de/~fjf/gpc-todo_toc.html, we have a TODO list for GPC listing known bugs, planned features, etc. This list contains a section `2.1.1' with plans what has to be done before the release of gpc-2.1.1 (i.e. one version in advance, since the next version will be gpc-2.1). Our question: Which of those features [bugs] should be implemented [fixed] already in gpc-2.1 realistically? Some thoughts: * We are late with gpc-2.1. Current beta and alpha versions are already much more stable than gpc-2.0 which is still the official version. * OTOH, the release of gpc-2.1 will be a big step towards full compliance to Extended Pascal ("towards" means that it cannot be really reached with this release) and towards high compatibility to Borland Pascal. Waiting with the release until some important "holes" (which???) are fixed might be good for GPC's reputation. Please post your comments to this list. "Me too"s are welcome as well; you can send them directly to my address. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: New Alpha (source only) on Agnes
by Kevin Foss 30 Mar '98

30 Mar '98

On Mon, 30 Mar 1998 18:58:49 +0200 (MEST), Peter Gerwinski wrote: >For those who are wondering what we have done since gpc-971001 (and >those who would like to check whether I have applied all their patches >correctly;-) I have just uploaded a new GPC alpha source distribution >(gpc-980330) to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. >Binary stuff will follow ASAP - whatever that means. Just wondering, before I download it -- is this release based on gcc 2.7.x or do we need 2.8.x source to compile this alpha? This also leads to the larger question of when 2.7.x support will be dropped (if this release still works with 2.7.x)? -Kevin

2 1

New Alpha (source only) on Agnes
by Peter Gerwinski 30 Mar '98

30 Mar '98

Hi, everybody! For those who are wondering what we have done since gpc-971001 (and those who would like to check whether I have applied all their patches correctly;-) I have just uploaded a new GPC alpha source distribution (gpc-980330) to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. Binary stuff will follow ASAP - whatever that means. Have fun! Peter

1 0

incompatible type (possibly) bug report
by FPL 30 Mar '98

30 Mar '98

Hi Frank, Hi GPC list, I downloaded rand.pas file on agnes as adviced by GPC Guru, and this one does not pass through the gpc --automake trial. Don't you think this part of code (line 113) PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; should be thus written: PROCEDURE SRand(Seed:cardinal); C; FUNCTION GetPID:cardinal; C; ? Indeed, the all-cardinal solution does work fine (as cardinal being a c long int, one should also put integer everywhere, which also works). I think that previous version of GPC did not encounter problem there but that more recent one (mine is eventually 971001(2.7.2.1)) cannot compile because of incompatible, though not that much, argument type. Regards. F.P.L

2 1

Function result from ASM...
by Orlando Llanes 28 Mar '98

28 Mar '98

Using GPC's asm statement allows us to set the function result with an ASM statement, but how do I set the result of a function through an external assembly routine? The Assembler I'll be using is NASM (just in case you need to know). Thanks in advance! 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 1

huh... random numbers?
by FPL 28 Mar '98

28 Mar '98

Hi the list, Hahem! I asked few days ago about a possibly built-in function giving random or pseudo-random numbers... And received no answer. Why it is so? Is it a trivial FAQ? I checked in GPC info and there is nothing for random but this: * GPC notes:: Random notes about GPC. And for rand, there is nothing but OPErand :) So if it is a FAQ it is well hid. It is by no means a tricky or complicated question, may be it is taboo? Dunno... Don't understand! So heretically I ask again if GPC is providing such a function. Cheers. F.P.L

2 1

stochastic numbers
by Laussy Fabrice 25 Mar '98

25 Mar '98

Hi the list, Is there a built-in function in GPC giving random numbers? F.P.L

1 0

Pi
by Miklos Cserzo 20 Mar '98

20 Mar '98

Hi Folks, the constat "Pi" apparently is not declared by default in my system. (IRIX 6.2, GPC 2.0) Am I missing something? miklos

2 1

Any good Documentation TXT,HTM,...
by OHMH＠nets.com.jo 20 Mar '98

20 Mar '98

Is there any good Documentation for the GNU-Pascal Compiler, something like a programmers reference, or like the Borland's Help ... Thanks a lot Omer

3 2

Re: reset
by Frank Heckenbach 19 Mar '98

19 Mar '98

Miklos Cserzo wrote: > the following construction fails: > > assign(ip,'input_file'); reset(ip); > > repeat > readln(ip,...... > until eof(ip); > > reset(ip); { <<<< This is the point where the shit hits the fan... } > > > I think it is legal. (It is surely OK under TP.) > > I am running IRIX 6.2, GPC 2.0. It works for me. I just tried the following program under Linux, and it correctly prints the first line of input_file. program x; var ip:text; s:string(100); begin assign(ip,'input_file'); reset(ip); repeat readln(ip); until eof(ip); reset(ip); readln(ip,s); writeln(s); close(ip); end. Doesn't this program work under IRIX? Otherwise please send a complete program that doesn't work. Oh well, maybe it didn't work in GPC 2.0. You might want to try a newer beta version. Jesper Lund wrote: > In GPC you need to close the file before calling reset/rewrite again. Add the > statement 'close(ip)' before the second reset, and everything should work. > > This issue has been raised before on the mailing list, but I am not sure > whether it is bug or a feature..... AFAIR, the problem that was discussed was that GPC closes the file and re-opens it, instead of just seeking to the beginning. This is a bit inefficient and has (I think) some other disadvantages, but does not mean that it doesn't work at all. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Re: system()
by Frank Heckenbach 18 Mar '98

18 Mar '98

Jim Roland wrote: > It works beautifully, but you must include the definition in your > procedures/functions section: > > Procedure system ( parameters ); C; > or > Function system ( parameters ); C; > > I don't remember the parameters for the system() function, but > "man system" should tell you. Yes, the man page says "char *" which is "CString" in GPC. > The C; at the end is important and the > "system" as opposed to "System" or "SYSTEM" is important too. Not really. The "C;" directive will transform all identifiers to lower case internally. I used "System" in the example I just posted, and this works, too. If one needs upper or mixed case C identifiers, one can use asmname like "procedure Foo; asmname 'bAr';" or whatever. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: Append Text Files, Exec()
by Frank Heckenbach 18 Mar '98

18 Mar '98

> > Otherwise you can simply call the system() function. The declaration is: > > > > function System (CmdLine: CString): Integer; C; > > > > (CString is the same as PChar in BP, and newer versions of GPC understand > > both CString and PChar.) > > Frank, > > Thanks for the info. If it's not too much to ask, could you send me a > sample program that uses the system() function. I have not yet explored > the depths of CStrings, and need to get some programs to function properly > in a short period of time. Try the program below. (* Note: The function Str2CStrRO converts a Pascal string into a CString. It's about the same as BP's StrPCopy. I called it Str2CStr rather than StrPCopy because this seems clearer to me, and I appended "RO" (read-only) to make it clear that neither the Pascal string nor the CString should be modified while the CString is used. Future versions of GPC should have something like this built-in, but for now, one has to do it manually. *) The rest of the program should be straightforward. Unlike BP's Exec, you don't have to specify the program and paramters in two separate strings, but rather combined into one string (with a space between them). Also, you don't have to give the full path to the program when the program is located in the system path. So, you could test it with a command like "command /s dir" for Dos or "ls -la" for Unix. program Exec_Demo; function System (cmd: CString): Integer; C; function Str2CStrRO (var s: String): CString; begin s[Length(s)+1] := #0; Str2CStrRo := @s[1] end; var s: String (1000); i: Integer; begin Write ('Enter a system command: '); Readln (s); i := System (Str2CStrRO (s)); Writeln ('The returned status of the system was ', i, '.') end. > The extend() procedure seems to tack on a newline & carriage return onto > the end of the text file before any writing can be done to the file. (* Only if there isn't one already. *) > Is this a bug/feature? It's a feature! :-) The Extended Pascal standard demands this, and actually it took a bit of extra code within the RTS to implement this behaviour. > Is there a fix/way to get around this? AFAIK, there's no way to prevent this (except using a file of char and seeking to the end, but then the formatting of Write[ln] isn't available -- only via WriteStr)-: Perhaps it would be useful to have a GPC switch to turn this behaviour off, perhaps coupled to the --borland-pascal switch? Any comments, also from the mailing list (to which I'm sending a copy)? -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

system()
by Geoffrey Arnold 18 Mar '98

18 Mar '98

When I try to make a call to the system() procedure, I get this compiler error: testex.p: In function `program_Testex': testex.p:4: undeclared identifier `System' (first use this function) testex.p:4: (Each undeclared identifier is reported only once testex.p:4: for each function it appears in.) Is there something else I must include in my program? I am using gpc-2.0 compiled for the linux 2.0 platform. ----Geoffrey Arnold--- garnold(a)cyberdrive.net

4 4

Re: Append Text Files, Exec()
by Frank Heckenbach 17 Mar '98

17 Mar '98

Geoffrey Arnold wrote: > Is there and append() or similar procedure that allows me to write > directly to the end of text files? > If you have any information, please contact me directly by email. It's called Extend. The only difference to BP's Apped (AFAIK) is that Extend creates the file if it doesn't exist. > Is there an exec() or similar procedure supported by GPC that allows the > execution of external programs? Not built-in, but if you're using GPC on a Dos platform, you might want to get the BPCompat package from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ whose Dos unit contains an Exec procedure. Otherwise you can simply call the system() function. The declaration is: function System (CmdLine: CString): Integer; C; (CString is the same as PChar in BP, and newer versions of GPC understand both CString and PChar.) -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Exec()
by Geoffrey Arnold 17 Mar '98

17 Mar '98

Is there an exec() or similar procedure supported by GPC that allows the execution of external programs? If you have any information, please contact me direct by email. Thanks. Geoffrey Arnold garnold(a)cyberdrive.net

1 0

Append()
by Geoffrey Arnold 17 Mar '98

17 Mar '98

Is there an append() or similar procedure that allows me to write directly to the end of text files? If you have any information, please contact me direct by email. Thanks. Geoffrey Arnold garnold(a)cyberdrive.net

1 0

Exec()
by Geoffrey Arnold 17 Mar '98

17 Mar '98

Is there an exec() or similar procedure supported by GPC that allows the execution of external programs? If you have any information, please contact me directly by email. Thanks. Geoffrey Arnold garnold(a)cyberdrive.net

1 0

Append Text Files
by Geoffrey Arnold 17 Mar '98

17 Mar '98

Is there and append() or similar procedure that allows me to write directly to the end of text files? If you have any information, please contact me directly by email. Thanks. Geoffrey Arnold garnold(a)cyberdrive.net

1 0

Re: Java bytecde (UCSD..TP..)
by Marta Sananes 14 Mar '98

14 Mar '98

I wish to add to this discussion, that another ancestor of TP and Delphi is the original ObjectPascal from Project Macintosh. As I read in the book Object-Oriented Programming for the Macintosh by K.J. Schmucker (1986) "the syntax for Object Pascal was jointly designed by the Apple Clascal team and Niklaus Wirth, the designer of Pascal, who was invited to Apples's Cupertino headquarters specifically for this project". It seems to me that the similarities with TP are obvious: Unit, interface, implementation, object desing and implementation since version 5, Graph unit design ... For me is a mistery why Apple abandoned such a beautiful project, why the academic computer community forgot this and the UCSD projects and why Wirth does not know get the credit he deserves for his work, including the idea of the p-code software development strategy now revived -without a word of recognition- as java and bytecode. It was like leaving a straigth and pleasant way for taking a tortuous one... > > Peter Gerwinski wrote: > > > > Hello! > > > > According to David Rauschenbach: > > > [...] > > > In my mind, Pascal is the *perfect* language to see a Java bytecode > > > implementation. > > > > Something *very* similar to this already existed many > > years ago: UCSD Pascal. I consider this the direct > > ancestor of Borland Pascal. (Somebody knows some details?) > > Indeed, UCSD seems to be the ancestor of Turbo Pascal (a lot > of similarities). AFAIK, UCSD Pascal produced portable > p-code. Certainly, the Cabot implementation of it does. The > p-code can be run on any operating system (that is supported > by Cabot environment?). The Cabot UCSD system has its own > file system, etc., and the compiled programs run in a > virtual environment which is complete with its own file > system (with long filenames, etc.). The environment itself > is enclosed in a file which appears to the host operating > system as just a single large file. The p-code binary is > very small, because all the facilities that it needs are > inside the environment. The idea is that, if a port of the > environment exists for your operating system, then any > p-code program written for any platform will run on your > operating system as well. > > Now, I am writing all this from (long term) memory. I > reviewed the Cabot UCSD Pascal compiler for the Pascal > Magazine (ancestor of the Delphi Magazine) a few years ago, > and I am writing from what I remember. I might have got some > facts mixed up, but I think I remember the general idea. > > Best regards, The Chief

1 0

Objective Pascal ...
by Christian Bockermann 09 Mar '98

09 Mar '98

Hello everyone !! After a long, long time of using GPC I began to write Object related programs. I did so at school (MacIntosh, ThinkPascal :-( ) and now I want to port my programs onto my Linux box. However here is a first error, of which I don't really know how to get around it. I think it's just an Syntax error concerning the two pascal dialects. Perhaps someone could send me a correction of it, that is compilable with GPC ? Here is my shortened program : program foo; type something = object procedure say_hello; end; procedure something.say_hello; begin writeln('Hello !'); end; var someone : something; begin new(someone); someone.say_hello; dispose(someone); end. And now, this is what GPC cries about : foo.p: In function `program_Foo': foo.p:16: pointer type required for `New' foo.p:18: pointer type required for `Dispose' I thought if I declare 'someone' as an object of the class 'something' it is automatically a pointer onto a structure of this class. Obviuosly I am wrong. Help would be great ! -- Bye, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

2 1

Java bytecode - you knew someone would eventually ask!
by David Rauschenbach 09 Mar '98

09 Mar '98

I've been following the trend of languages beginning to compile down to Java bytecode. Java was the original language to do so, and now Visual Basic, future portions of COM+, and even Perl are in the works on such a strategy. In my mind, Pascal is the *perfect* language to see a Java bytecode implementation. I've used Borland Delphi over the years, and I regret that the native ties to the O/S (Win32 messaging calls, and assembly-language RTL pieces) which made it successful and a fast performer in the short term, are the very thing that keep it from realizing its potential as a totally outstanding cross-platform tool. That possibility is still open for GNU Pascal. Just a thought, in case there are any college professors on this list who might see this as both a fresh and relevant spin on a traditional compiler course, and a worthy contribution to GNU. We all want to write our Pascal, and not see it stop running 10 years from now just because we've changed our operating environments. David

4 3

EP extend() and EMX Port of GPC
by Kevin A. Foss 09 Mar '98

09 Mar '98

Hello, Has anyone gotten code that uses extend() working on the EMX port of GPC? I was playing around tonight and realized that some relatively simple code which works fine on my Linux box, fails under EMX unless the output file to be extended is non-existant. [The dumb code I'm using is at the bottom of this message.] GPC returns no errors, it just never writes the text line and leaves the output file as it finds it. After putting some hooks in the rts code, fwrite is reporting an EACCESS (permission denied) -- this is the call to CFWRITE() at the end of rts-wrti.c. The problem isn't just in the lastest alpha but goes back to at least 971001 -- so I was wondering if people remember if extend() ever worked with EMX? Any ideas as to where to look for a problem? Obviously, I haven't tried the other ports (other than Linux) so I don't know if extend() works with the DJGPP port either, or if this is strictly an EMX problem. program extendtest(output); var out : bindable text; b : BindingType; begin b := binding(out); b.name := 'a.txt'; bind(out,b); b := binding(out); extend(out); writeln(position(out)); writeln(out, 'hello'); writeln(position(out)); { EMX returns the same number twice, unless a.txt is empty to start } end. thanks, -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Help on graphics
by Bendersky 06 Mar '98

06 Mar '98

Hi everybody. I'm using GPC for DOS, so I downloaded the file grx22.zip to use graphics. I've followed the instructions on the readme file, but I can't even make the demos run. Do I have to compile the unit some way? How? If so, please give me detailed instructions because I'm not too experienced in GPC neither in GCC. Thank you, and forgive my bad english, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

2 4

Re: patching gcc
by Peter Gerwinski 06 Mar '98

06 Mar '98

According to Laussy Fabrice: > > Hmm... I can't seem to find a patch in there anywhere. Maybe it's `/usr/local/gcc-2.7.2.1/p/diffs/gcc-2.7.2.x.diff' in your distribution? > There is only gcc-2.7.2.x.patch. There is no 2.7.2.1 once unpacked the > archive, Ah - that's correct! The documentation is outdated here, sorry. > there is no anymore after running ./configure. That should not happen! Please re-extract it from your GPC distribution archive. Here is how it should work (for gpc-98something): esmeralda/usr/local/src/gcc-2.7.2.1# ./configure This appears to be a i586-unknown-linux system. Using `./config/i386/i386.c' to output insns. Using `./config/i386/i386.md' as machine description file. Using `./config/i386/linux.h' as target machine macro file. Using `./config/i386/xm-linux.h' as host machine macro file. Merged x-linux. *** *** configure detected GCC version 2.7.2.1 *** GPC 2.1 requires a patch to build with GCC 2.7.2.1 *** This patch will now be applied. *** Press ENTER to continue, Ctrl-C to abort. *** Merged c++ pascal fragment(s). Created `./Makefile'. Merged x-linux. Created `cp/Makefile'. Merged x-linux. Created `p/Makefile'. creating cache ./config.cache [...] creating gpc-config.h Links are now set up to build a native compiler for i586-unknown-linux. esmeralda/usr/local/src/gcc-2.7.2.1# > However, as you know, I cannot create the 2.7.2.1 patch. > Incorrect path. Of course you cannot create it. You need the patched and the unpatched files in order to create the patch. > Frank Heckenbach wrote: > > > > It should be included in libgpc.a -- did you check that the version > > you use is the correct one (and not perhaps an older version is laying > > around somewhere else; perhaps try "locate libgpc.a" if that's set up > > to work on your system, and remove any old version it finds). > > I have make clean and make clean-dist, + remove my symbolic link of > old GPC in my own /bin. > > In fact, I assume my failure on patching GCC explain the problem (there > is some other problems not when compilating but when running). Normally, the patched GCC source files do not affect `libgpc.a', but obviously something went completely wrong with the configuration of your GPC source tree, so maybe `libgpc.a' was not produced due to some missing makefile or whatever. Good luck, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: Java bytecode - you knew someone would eventually ask!
by Clyde Meli 06 Mar '98

06 Mar '98

> In my mind, Pascal is the *perfect* language to see a Java bytecode > implementation. I've used Borland Delphi over the years, and I regret This would be great to have... and another point in favour of GNU PASCAL. Regards, Clyde

1 0

Re: assigning files
by Frank Heckenbach 05 Mar '98

05 Mar '98

Laussy Fabrice wrote: > laussy@localhost ~/conway 16:58:02 Thu Mar 5 > 25$ gpc -g game.of.life.pas > /tmp/cca005911.o: In function `Fileop': > /home/laussy/conway/game.of.life.pas:44: undefined reference to > `_p_assign' > > _p_assign, I just don't know what it is, since I didn't define it, > it is not due to me if that does not work! _p_assign is the procedure of the RTS (run time system) that is called internally for Assign. It should be included in libgpc.a -- did you check that the version you use is the correct one (and not perhaps an older version is laying around somewhere else; perhaps try "locate libgpc.a" if that's set up to work on your system, and remove any old version it finds). -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: patching gcc
by Peter Gerwinski 05 Mar '98

05 Mar '98

Hi! According to Laussy Fabrice: > Hi the list, > > I am currently compiling gcc and gpc, till there everything went ok but > this: > > Next, go to the GCC source directory and apply the GCC patch > required by GNU Pascal: > > % patch -s -p1 < p/patches/gcc-2.7.2.1.patch Hmm ... `./configure' should do this automatically for you when you invoke it from `/usr/local/gcc-2.7.2.1' while the subdirectory `p' is already present. > The problem is: > > root@localhost /usr/local/gcc-2.7.2.1/p/patches 09:24:02 Thu Mar 5 > 148$ ./mkpatch > diff: gcc-2.7.2.1/gcc.c.orig: No such file or directory > [...] You are trying to *create* `gcc-2.7.2.1.patch'. What you probably want is to *apply* it. Please `cd' to `/usr/local/gcc-2.7.2.1/' and really type the line `patch -s ...' above - or just `./configure'. > Is it important? Yes. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

assigning files
by Laussy Fabrice 05 Mar '98

05 Mar '98

This time it seems that GPC works all right, the compilation went fine. I promise I won't ask for bug that are mines, but look at this one: laussy@localhost ~/conway 16:58:02 Thu Mar 5 25$ gpc -g game.of.life.pas /tmp/cca005911.o: In function `Fileop': /home/laussy/conway/game.of.life.pas:44: undefined reference to `_p_assign' _p_assign, I just don't know what it is, since I didn't define it, it is not due to me if that does not work! My last assign procedure coming from the doc went okay. The new version of GPC that should support it does not accept a simple call to assign! What's the problem? If this is still a compilation problem, so there is a bug in the new installation procedure ;) I installed GPC without *any* problem the first time, I have encountered a lot of problem for those of the beta version! which I have reported (unfortunatly for you) only a very little part. Am I getting inane with time? Otherwise, now bytes and all other family is accepted. Cheers. F.P.L

1 0

patching gcc
by Laussy Fabrice 05 Mar '98

05 Mar '98

Hi the list, I am currently compiling gcc and gpc, till there everything went ok but this: Next, go to the GCC source directory and apply the GCC patch required by GNU Pascal: % patch -s -p1 < p/patches/gcc-2.7.2.1.patch The problem is: root@localhost /usr/local/gcc-2.7.2.1/p/patches 09:24:02 Thu Mar 5 148$ ./mkpatch diff: gcc-2.7.2.1/gcc.c.orig: No such file or directory diff: gcc-2.7.2.1/gcc.c: No such file or directory diff: gcc-2.7.2.1/convert.c.orig: No such file or directory diff: gcc-2.7.2.1/convert.c: No such file or directory diff: gcc-2.7.2.1/dbxout.c.orig: No such file or directory diff: gcc-2.7.2.1/dbxout.c: No such file or directory diff: gcc-2.7.2.1/expr.c.orig: No such file or directory diff: gcc-2.7.2.1/expr.c: No such file or directory diff: gcc-2.7.2.1/fold-const.c.orig: No such file or directory diff: gcc-2.7.2.1/fold-const.c: No such file or directory diff: gcc-2.7.2.1/function.c.orig: No such file or directory diff: gcc-2.7.2.1/function.c: No such file or directory diff: gcc-2.7.2.1/optabs.c.orig: No such file or directory diff: gcc-2.7.2.1/optabs.c: No such file or directory diff: gcc-2.7.2.1/stor-layout.c.orig: No such file or directory diff: gcc-2.7.2.1/stor-layout.c: No such file or directory diff: gcc-2.7.2.1/toplev.c.orig: No such file or directory diff: gcc-2.7.2.1/toplev.c: No such file or directory and no way to make the PATH okay (in /usr/local/gcc-2.7.2.1 with p/ of GPC) Is it important? Cheers.

1 0

GPC Binary for Solaris 2.6
by Geoffrey Arnold 04 Mar '98

04 Mar '98

To Whom It May Concern: I am looking for a gpc 2.0 binary package compiled for a Sun SPARC running Solaris 2.6 with gcc 2.7.2.3 installed in /usr/local. If you have any information, please contact me directly by email. Thanks. ----Geoffrey Arnold--- garnold(a)cyberdrive.net

2 1

bug: unit initializer fails on Alpha-Digital Unix
by Miguel A. Alonso Pardo 03 Mar '98

03 Mar '98

Unit Initializers begin ... end. to begin do begin ... end; to end do begin ... end; does not work on our Alpha machines with Digital Unix 4.0. It works well on machines with SPARC with Solaris 2.0 and PC with Linux. I have not found this bug as reported in the GPC web pages, so I report it to you. Please inform me if there are a fix for this problem. Version of gpc: $ gpc -v Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0/2.7.2.1/specs gpc version 2.0(2.7.2.1) Version of Digital Unix: $ uname -a OSF1 dexo V4.0 564 alpha Best Regards, ======================================================================= Miguel Angel ALONSO PARDO Grupo COLE ----------------------------------------------------------------------- Facultad de Informatica _/ email: alonso(a)dc.fi.udc.es Universidad de La Coruna _/ WWW : http://www.dc.fi.udc.es/~alonso/ Campus de Elvina s/n _/ phone: +34 (9) 81 16.70.00 ext. 1338 E-15071 La Coruna (Spain) _/ fax : +34 (9) 81 16.71.60 =======================================================================

3 2

bug report.
by Laussy Fabrice 02 Mar '98

02 Mar '98

Hi the list. I am now running what I think is the up to date gpc version: 971001(2.7.2.1) (documentation of 970714) (why is the name now xgpc?) Except my misunderstanding of something, the followings are types expected to be supported by the brand new GPC: (signed) (unsigned) (signless) GNU C equivalent typical size (bits) ByteInt ByteCard Byte [un]signed char 8 ShortInt ShortCard ShortWord [unsigned] short int 16 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord [unsinged] long int 32 LongInt LongCard LongWord [unsinged] long long int 64 But none of them is accepted by the compilator (except Integer, and may be few last I haven't tested, but ByteInt, ShortInt, MedInt, LongInt, ByteCard, Byte, Shortcard, ShortWord and Word does not work, for the others, I don't know but I bet they do not work as well). That a type "does not work" means that in my source if I put var i, j : byte; then GPC will yell at me: laussy@localhost /home/laussy/conway 18:17:35 Sun Mar 1 20$ gpc --version 971001(2.7.2.1) laussy@localhost /home/laussy/conway 18:18:19 Sun Mar 1 21$ gpc byte.test.pas byte.test.pas: In function `program_Test': byte.test.pas:3: type name expected, identifier `Byte' given The same for the others. If I keep the old type definition: type shortint = __byte__ integer; byte = __unsigned__ shortint; then the byte algebra is still bugged, with for example and absolute value of (2-4) given to be 252! Besides, in the doc, one can find: * The Run Time System (RTS) does not know about modified types such as `__byte__' or `__unsigned__ Integer's or `__long__ Real's. Especially, you cannot `writeln' such variables. Is it somewhat related? Cheers, F.P.L

2 1

Re: bug report.
by Frank Heckenbach 02 Mar '98

02 Mar '98

Laussy Fabrice wrote: > I am now running what I think is the up to date gpc version: > > 971001(2.7.2.1) This was the last beta version. More recent versions are currently available as alpha only. > (why is the name now xgpc?) xgpc is a temporary filename used while building gpc. With a "make pascal-install" or similar, it should be installed as gpc in the appropriate directory. > Except my misunderstanding of something, the followings > are types expected to be supported by the brand new GPC: > [...} > > That a type "does not work" means that in my source if I put > > var i, j : byte; > > then GPC will yell at me: > > laussy@localhost /home/laussy/conway 18:17:35 Sun Mar 1 > 20$ gpc --version > 971001(2.7.2.1) > laussy@localhost /home/laussy/conway 18:18:19 Sun Mar 1 > 21$ gpc byte.test.pas > byte.test.pas: In function `program_Test': > byte.test.pas:3: type name expected, identifier `Byte' given Should not happen in 971001. Perhaps an installation problem: "gpc" is only the compiler driver, the actual compiler is "gpc1". If you only installed gpc manually, but not gpc1, you're (for the most part) still using an older version, in spite of the "--version" output which is generated by gpc, not gpc1. (The version of your documentation might be due to the same reason.) > then the byte algebra is still bugged, with for example > and absolute value of (2-4) given to be 252! Did you do somehting like: var a,b: Byte; ... a := abs (a - b) In this case, this is not really a bug ;-) ... it's a general problem (found in other compilers and languages, too) with unsigned and/or differently sized integers. Since a and b are bytes, a - b will be evaluated as a byte, resulting in an overflow and the wrong result 254, of which then the absolute value is taken. Of course, in Pascal such an overflow should be caught, but GPC doesn't currently do range checking, unfortunately... The solution would be type casting the values (or one of them) like: a := abs (Integer(a) - b) Not tested, but should work... > Besides, in the doc, one can find: > > * The Run Time System (RTS) does not know about modified types such > as `__byte__' or `__unsigned__ Integer's or `__long__ Real's. > Especially, you cannot `writeln' such variables. This has been fixed, too. BTW: the RTS is in libgpc.a, yet another file. And there's also gpc-cpp, so be sure to do a complete installation... -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: bug: unit initializer fails on Alpha-Digital Unix
by Peter Gerwinski 02 Mar '98

02 Mar '98

According to Miguel A. Alonso Pardo: > Unit Initializers > > begin ... end. > to begin do begin ... end; > to end do begin ... end; > > does not work on our Alpha machines with Digital Unix 4.0. > [...] > gpc version 2.0(2.7.2.1) Upgrading to a more recent (beta or alpha) GPC will solve this problem. Please go to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ to get the most recent version of GPC (source code only, sorry). Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

I should really update my GPC version!
by Laussy Fabrice 26 Feb '98

26 Feb '98

Hi again list, (sorry Peter) Here is a sample of some code I am currently working on: 1 if (abs(x-transient^.x)<2) then 2 if (abs(y-transient^.y)<2) then 3 tmp:=tmp+1; 4 if (transient^.x=x) and (transient^.y=y) then Well, what happens is that everything goes ok for the first test, but whatever the value is for the second one (y-transient^.y), the PC will jump to line 4, never doing 3. I have tested with gdb: (gdb) p Y $1 = 30 '\036' (gdb) p Transient.Y $2 = 31 '\037' (gdb) n (gdb) p Tmp $3 = 0 '\000' where Tmp was previously naught. Those are declared as byte. Is it a GPC bug? Is it a Pascal misunderstanding of mine? What the hell is it?

2 1

invoking assembler
by Laussy Fabrice 26 Feb '98

26 Feb '98

Hi the list. Is the way to tackle a part of code directly in code machine with GPC is to use RTL? F.P.L

2 1

Bug report
by Laussy Fabrice 26 Feb '98

26 Feb '98

Pardon me if I report a bug of an out of date version. Mine is 2.0(2.7.2.1) (is that not getting pretty old?). Assuming I've defined type matrix = array[1..4] of array[1..4] of integer; Then an error of mine like matrix[1][1]:=1; instead of lorentz[1][1]:=1; where lorentz is defined as a type matrix in the var field, will make GPC crash. gpc: Internal compiler error: program gpc1 got fatal signal 6 F.P.L

2 1

[Req] Script Interface Feedback...
by Orlando Llanes 25 Feb '98

25 Feb '98

I've been thinking about it more and more, and I've pretty much thought of how I want to handle the script interface. One of the goals of the interface is to have multiple front-ends which will compile the same code. The two ways I plan on handling this are: 1) Setting the default language as a subset of C (not the run-time stuff, but the logic operators, identifier structures, etc). Then creating a language "translator" in the default language. [Example of script language front-end definition]: /********************/ /* PASCAL.SC */ /* */ /* Pascal front-end */ /********************/ ... tokenType getToken( char *curline ) { if( getFirstStringToken( curline ) = "BEGIN" ) return '{'; } ... int main( argc, argv[] ) { tokenType curToken; ... /* The following is shorthand for a line of source */ /* which can be a string variable */ curToken = getToken( "BEGIN END;" ); ... return erNone; } [Example of the Pascal library syntax to use the above script]: { Main program } ... { 1A } Script^.CompileScript( 'pascal.sc' ); ... { 1B } Script^.Run( 'pascal.vm', 'foobar.sp' ); Script^.CompileScript( 'foobar.sc' ); Script^.Run( 'foobar.vm', '' ); ... In the above examples, 1A needs to be executed only once, to compile the pascal translator. In 1B 'foobar.sc' or 'foobar.sp' need to be compiled once, or after the script is significantly modified. Also, 'foobar.sp' is the script in Pascal, 'foobar.sc' is the result of the Pascal translator which converts Pascal code to the default script language. 2) Providing variables to "override" symbols. [Pascal definitions]: CONST PascalKeywordDefs : TScrDef = 'b="BEGIN"' + 'e="END"' + 'i="IF"' + 't="THEN"' + 'l="ELSE"'; PascalGrammarRules : TRulesDef = 'CAPS="NONE"' + 'IF="i c t [b]..[e] [l [b]..[e]];"'; CKeywordDefs : TScrDef = 'b="{"' + 'e="}"' + 'i="IF"' + 't=""' + 'l="else"'; CGrammarRules : TRulesDef = 'CAPS="MIX"' + 'IF="i (c) [b]..[e] [l [b]..[e]];"'; ... { The following loads and parses Pascal values from memory } Script^.SetKeywordDefs( PascalKeywordDefs ); Script^.SetGrammarRules( PascalGrammarRules ); { OR } { The following loads and parses Pascal values from a file } Script^.LoadKeywordDefs( 'PAS.KWD' ); Script^.LoadGrammarRules( 'PAS.RUL' ); { Compile Pascal script } Script^.Compile( 'foo.sp' ); { The following loads and parses C values from memory } Script^.SetKeywordDefs( CKeywordDefs ); Script^.SetGrammarRules( CGrammarRules ); { OR } { The following loads and parses C values from a file } Script^.LoadKeywordDefs( 'C.KWD' ); Script^.LoadGrammarRules( 'C.RUL' ); { Compile C script } Script^.Compile( 'foo.sc' ); ... Note something about example 2, yes it might be better to use Lex/Yacc, but this allows the grammar rules and the syntax to be re-defined at run-time, and it makes it possible to load definitions from a file. The advantage to both of these examples (1 and 2) is that there is room for a user-defined language. I think that idea #1 would be easier on the programmer and user than idea #2, but that's me, I'd like to see if any of you have a good alternative if you're not comfortable with either of these ideas. Oh! One other thing, I've decided that pointers used carefully can't harm anyone as long as their addresses cannot be set. The reason I'm thinking of adding pointers is so that linked lists and/or binary trees can be implemented. Thanks in advance! 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

1 0

Protected...
by Orlando Llanes 25 Feb '98

25 Feb '98

How does the Protected keyword work? And what standards is it defined in (besides BP)? 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 1

RFC to the GPC Archive
by Hans Ecke 24 Feb '98

24 Feb '98

Hi all! Some weeks ago, I volunteered for beeing the archiver at the upcoming GPC archive. In the following, I shall lay out the prinziples and structures I would like to follow. All suggestions and comments are welcome. **1** general policy The archive will contain * the gpc-source and supplied binaries * related files (i.e. the gcc-source) * contributed tools/apps/libs The main policy should be "less is better". This means that we would prefer a well organized archive with a content that is truly spezific to gpc over an archive which contains much misc packages which could also be found in other archives. **2** Incoming policy This leads to the point, that packages which are to be included, should be selected from the archiver, rather than from the author or uploader. There will be an "Incoming"-directory with write-access. The archiver will select the appropriate files and add them to the archive. All uploaded files should contain a file foobar.lsm (which should be really descriptive not just "it is a library for graphics") and can contain a file foobar.readme. Templates will be supplied, of course. But thats all not that critical, as far as the archiver is human and not some script. **3** Access Access to the archive should be possible via raw ftp as well as via the comfortable www (but viewable with any browser, including lynx). The best solution should be a ftp-directory with files "index.html" in each directory. Some may be familar with this from the sunsite.unc.edu linux-archive. **4** The files index.html They contain * subdirectories with description * files in the current directory with description * links to navigate inside the archive : UP NEXT PREV ROOT GPC-HOME * maybe a text with information related to the current directory I would like to have the files index.html be very customized - i.e. descriptions could include links to the homepage of the package, the text could provide links to related interesting places. I personally dont like scrolling, if Im working in an archive. So I would try to design in a way, that at least the subdirectories are within one page, better that subdirectories+files are within one page. A typical page would look like ___________________________________________________ PREV NEXT UP ROOT GPC-HOME This is the Source of the Version 2.5.76 of GPC. MORE /\ /\ || || Link to a tree, see 5 Link to the Text at bottom subdirectories with description files with description some text (explanations, links) _____________________________________________________ **5** Other navigating files As a second concept of navigation, there will be a tree (<ul>) representing the archive. The Name of the directory ("This is the Source of the Version 2.5.76 of GPC" above) would link to this tree. For raw ftp-access there will be an index.txt. **6** tree structure of the archive --stable-----binary---linux .tar.gz and .rpm ask for contributed .deb | |-freebsd | |-...(djgpp, solaris) ask for contributions |-source .tar.gz, .src.rpm, gcc-source, ask for source-deb --unstable---versionx Source of unstable versions (beta versions) |-versiony If it doesnt make sense, put all in one |-versionz directory --old--------versionx Dito |-versiony |-versionz --doc list, homepage, faq, fpkvsgnu --devel gpcasm, solaris-includes, tply wenn portiert, bpcompat, bgi2grx, xbgi --contrib relochtml, lord --unported what is worth porting --system-----djgpp Directories made via symlinks. The user goes |-linux-redhat into the archive, directory |-linux-debian system/$HIS_SYSTEM. There (s)he will find |-linux-targz current stable/unstable source/binary |-emx |-freebsd |-...other. ask for contributions --Incoming **7** Search A searchfunction will be included in future. It should do search for category, name, word from name, description, lsm-file. Search-sheme would be regexp, substring, exact string, case sensitive/insensitive, agrep(fuzzy-search) **8** Other future Plans Not much. Any Ideas? Of course if the archive gets to big, one must set up an automated archiver, based on the foobar.lsm-files. These are Peters and my ideas about the archive. I hope I could make the general idea clear. Any suggestions and comments are really appreciate. As I will have no internet-access in march, maybe I wont get it done till the first days of april. Hans

2 1

Problem with gnu Pascal (memory)
by Joerg Tomes 23 Feb '98

23 Feb '98

Hello, sorry, but i have a little question, and did not know whom to ask, i found no answer in faq's neither to Gnu C nor to Gnu-Pascal. I use Gnu-Pascal for scientific reasons, and have some trouble with it (but it's a very good program!). First: I use an Pc with Linux (2XPPro 200, 256 MB Memory) Kernel 2.0.33 (new) and gpc version 2.0(2.7.2.1) . But i saw this problem with other configurations and Versions. The Problem is if i want to use much memory e.g. for arrays the compiled program results in segmentation fault, while it runs with smaller arrays. ( I found this program in Gnu-C also with static arrays). Here is an attached test program, that runs with xsiz<1010 and not with xsiz > 1050. In my opinion it's not a problem of Linux, it's a problem of gnu-C, maybe any wrong configuration. Did you hear about a solution. Sincerly Joerg Tomes ************************************************************ Joerg Tomes, Theoretische Festkoerperphysik, Uni-Tuebingen, Auf der Morgenstelle 14, D-72076 Tuebingen, Tel : 07071-29-78633 Fax : 07071-29-5604 email: joerg.tomes(a)uni-tuebingen.de ************************************************************ program benchmark; const xsiz=1010; ysiz=1000; var a,b:real; d:array[0..xsiz,0..ysiz] of real; i,j:integer; Begin a:=1.0; For j:=1 to xsiz do For i:=1 to ysiz do begin d[i,j]:=a; end; b:=0.0; For j:=1 to xsiz do For i:=1 to ysiz do begin b:=b+d[i,j]; end; writeln(b,': Array entries used'); end.

2 1

Re: Graphical UNIT
by Peter Gerwinski 22 Feb '98

22 Feb '98

Hi! According to Laussy Fabrice: > > I have no favourite SimTel mirror... What is yours? ftp://ftp.ruhr-uni-bochum.de/pub/simtelnet/gnu/djgpp/ > Also, is there a `mouse unit'? Yes: GRX includes mouse support. > Is it near compatible with BP's one? BP doesn't have a "mouse unit". In Turbo Vision, it has a `drivers' unit which covers mouse support. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Graphical UNIT
by Laussy Fabrice 21 Feb '98

21 Feb '98

Hi GPC fellows, I was few weeks ago wondering about a Borland graphical unit, and Peter answered me about the one of GPC. Few questions about it: Is it near compatible with the one of Borland (I know it is not the aim of *GNU* Pascal to be Borland compatible, that such oriented UN*X Pascal do exist, and so on...) Meanwhile I am interested in making some code with graphical output using GPC's unit and GPC itself that would be almost compatible with a Borland compilation (which would require minor changes). The other question is about the availability of the GPC library, where can one find it? Also, is it well (at least, somewhat) documented? Cheers. Laussy.

2 1

CRT unit
by Frank Heckenbach 21 Feb '98

21 Feb '98

Since I needed some functions of the BP unit CRT, I implemented them using ncurses. As a result, we now have a very primitive CRT that should be portable (ncurses is widely available, AFAIK). However, there are some problems: - Some CRT functions are missing, most prominently AssignCrt and the TFDD stuff (which is impossible to do with the current GPC -- but I'll try to implement it sometime later), the Window procedure (which might not be too hard to implement), TextMode (which doesn't make much sense in general, but perhaps can be done so it works where possible)... - As a consequence of the missing TFDD stuff, input and output is not possible though the normal routines (read[ln], write[ln]), but only through CRTRead and CRTWrite. This is, of course, a big disadvantage, but thanks to ReadStr and WriteStr input and output can at least be converted quite automatically. - The code is very alpha, I just wrote it, and didn't really test it. It only works in the program I wrote it for. Some routines haven't been tested at all. Some other remarks: - The interface routines to ncurses are written in C to remain portable (writing them in Pascal would have been possible, but require some manual translation of system headers which might be importable). - When compiling, give "-lncurses" on the command line. (Sometimes, the automake mechanism doesn't find crtc.o, then give that on the command line, too.)-: - I haven't made any attempt to merge it with the existing CRT unit for DJGPP. I'm not sure if this is useful at all (since ncurses should exist there, too), but if so, it should be possible... For anyone who's daring to try and hopefully improve it, I'll put it at: http://home.pages.de/~fjf/crt.pas http://home.pages.de/~fjf/crtc.c -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

CString
by Jim Roland 18 Feb '98

18 Feb '98

Okay, I've got a CGI app written. There are subtlies that are different than Borland 5 & 6 that I'm used to, but nonetheless it's done. I can't compile because I don't have the data-type correct for setenv() and getenv(). What exactly is __cstring__ in pascal terms? Is it a pointer to a string type, actual string, etc...help! BTW, I forget and leave one end out during a case statement, and you get errors on just about everything in the file, including errors telling you that the ; at the end of a function blah(data):blahtype is not needed...just FYI. ====================================================================== Jim Roland, running the most stable operating system in the world: OS/2 v4.0--I TALK to my OS, and IT LISTENS, does yours? ----------------------------------- Running Internet Servers on OS/2 & Linux (a free & stable Unix OS) ----------------------------------- Get free PGP software today to keep your files & messages private! Don't let ANYONE deprive you of your right to privacy!! ======================================================================

2 1

Re: BP -> GPC: High()/Low()...
by Kevin A. Foss 17 Feb '98

17 Feb '98

On Mon, 16 Feb 1998 14:40:21 -0500 (EST), Orlando Llanes wrote: > Another thing to note is that GPC will return the actual first and >last element number, but BP starts it at 0 and ends on the last element. >For example, if the index goes from -1 to 4, BP will treat it as 0..6 >whereas GPC (and any Standard Pascal compliant Pascal Compiler?) will >treat it as -1..4 (don'tcha just LOVE GPC?!?!?!?! :) Um, so Low()/High() return the indices of the lower/upper bound of the array, right? [Just making sure I understood the examples, as I have no experience with these BP functions] It seems to me that the GPC behavior makes more sense (and would return more useful values), or was that your point? What good does Low() do in BP if it always returns a 0? -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

2 1

BP -> GPC: High()/Low()...
by Orlando Llanes 16 Feb '98

16 Feb '98

I didn't see this at first, but for those of you who use High() and Low() in BP can use it in GPC with 2 "work-arounds": First a BP function (to demonstrate it's use so you understand how the work around functions): PROCEDURE BPFoo( B : ARRAY OF Integer ); BEGIN WriteLn( 'ARRAY[ ', Low( B ), '..', High( B ), ' ] OF Integer;' ); END; The 2 GPC work arounds are as follows: PROCEDURE GPCFooParam( B : ARRAY[ Low..High : Integer ] OF Integer ); BEGIN WriteLn( 'ARRAY[ ', Low, '..', High, ' ] OF Integer;' ); END; -=[ OR ]=- FUNCTION GPCHighInt( B : ARRAY[ Low..High : Integer ] OF Integer ): Integer; BEGIN GPCHighInt := High; END; FUNCTION GPCLowInt( B : ARRAY[ Low..High : Integer ] OF Integer ): Integer; BEGIN GPCLowInt := Low; END; In the first example of the GPC work around, there's no need for the High()/Low() functions as Low and High already mark the first and last element, respectively. In the second example, it's a work-around that prolly isn't worth it, but another way to do it nonetheless (especially if you need to know the first and last element index from the main program). I don't know if there's a way to do the latter GPC work-around so that it can take an array of any type (I don't know how to do that yet if it's possible), but as far as I know, you need a function for each type you will be using. Another thing to note is that GPC will return the actual first and last element number, but BP starts it at 0 and ends on the last element. For example, if the index goes from -1 to 4, BP will treat it as 0..6 whereas GPC (and any Standard Pascal compliant Pascal Compiler?) will treat it as -1..4 (don'tcha just LOVE GPC?!?!?!?! :) 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

1 0

x86 i/o port access
by Frank Heckenbach 12 Feb '98

12 Feb '98

Following a request on a German Pascal newsgroup, I put together a little unit for accessing the i/o ports on the x86 from code posted here last year, together with specific Linux functions to enable port access, and a demo program. I put them at http://home.pages.de/~fjf/programs.htm in case someone here is interested or has any comments. Frank -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Manuals...
by croy＠osiris.com 12 Feb '98

12 Feb '98

Hello, I need a better source of documentation for GPC... I did read the documentation on agnes but I still have a feeling of missing something when I use the compiler.... Most of the time I go by intuition, having used for many years various Pascal implementation I end up with a trial and error process to functions, libraries and RTL function calls... Is there a place where we have a list of the function and there call parameter structure. I am using right now a generic Pascal reference and an old Borland Pascal language definition with a grain of salt and lots of little test programs but I find that so time consuming. Hopefully some people on the list are more experience with the GPC more specific issues and can help guiding me to a better reference. Thanks Claude.

2 1

Re: GPC problem with DJGPP
by Peter Gerwinski 11 Feb '98

11 Feb '98

According to Johan Larsson: > > Furthermore, the following program does not compile (parse > error at the class model `Class' etc. are not yet implemented into GPC; only the "old" OOP model from BP7 (`object' etc.) is supported at the moment. > though -fobject-pascal -fextended-pascal is enabled): These options do not enable anything; in contrast they disable everything outside the specified Pascal dialects. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

GPC problem with DJGPP
by Johan Larsson 11 Feb '98

11 Feb '98

Hi, I've tried to install GPC together with DJGPP and RHIDE. I get some very odd results. When attempting to compile .pas files the compiler report: "cannot open crt0.o: No such file or directory (ENOENT)" It appears as the lib path cannot be reached. Furthermore, the following program does not compile (parse error at the class model though -fobject-pascal -fextended-pascal is enabled): program classes; type efClass = class constructor Create; end; efMetaClass = class end; constructor efClass.Create; begin end; begin end. Can someone help me here? Is there detailed configuration information available on the Internet? Best Regards, Johan Larsson URL: http://www.acc.umu.se/~jola/ MAIL: jola(a)acc.umu.se Also, REMEMBER to check out EFLIB, the free object-oriented framework for EVERY Pascal programmer, at http://ftp.sunet.se/EFLIB/. Simply SOPHISTICATED!

2 1

Re: BP and BO question...
by Peter Gerwinski 09 Feb '98

09 Feb '98

According to Jim Roland: > > Thanks for the help. I got a successful compile now (no errors), however, > when I run the program i compiled (with gcc cgi-postsplit.pas -o > cgi-postsplit), You mean `gpc cgi-postsplit.pas -o cgi-postsplit'? > I get a bash error telling me the file is not there. Please try the following: * Make sure that this is no trivial error, for instance the executable is in the current directory, but the current directory is not in your path. (This is - or should be - the case when you are working as `root' (which you shouldn't do anyway.;-)) To check it, try `./postsplit' instead of just `postsplit'. * Use GPC only to compile, but link with GCC: `gpc -c postsplit.pas'; `gcc postsplit.o -o postsplit'. * If this does not help, add the `-v' option to your call to `gpc' and post the result here: `gpc cgi-postsplit.pas -v -o cgi-postsplit'. BTW, what system do you use? Linux probably (from your signature), but we must be sure about this in order to offer any help. > I tried running configure and make (even a make distclean before i > started) and I get an error 126 on ../gcc-2.7.2.2/specs! Thoughts? No idea, sorry. :-( > Right > now (I don't know what happened to cause this not to work nor compile > properly), but now I can't compile a program. A simple program that > assigns a string to S and writeln's it out doesn't error on compile, but > runs w/o output (test.pas). [...] As you can imagine, my GPC has no problem with this. Good luck, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: BP and BO question... (fwd)
by Jim Roland 09 Feb '98

09 Feb '98

Thanks for the help. I got a successful compile now (no errors), however, when I run the program i compiled (with gcc cgi-postsplit.pas -o cgi-postsplit), I get a bash error telling me the file is not there. When I compile a test program test.pas, I get no output at all Attached are those files. I tried running configure and make (even a make distclean before i started) and I get an error 126 on ../gcc-2.7.2.2/specs! Thoughts? Right now (I don't know what happened to cause this not to work nor compile properly), but now I can't compile a program. A simple program that assigns a string to S and writeln's it out doesn't error on compile, but runs w/o output (test.pas). a program that I have attached (cgi-postsplit.pas) give me a bash error telling me there is no such file or directory...HELP! Thanks! program stringsplit; var x,y : integer; s : string(255); begin s:='This is a string'; writeln('The String is = ',s) end. program stringsplit; #include "strpas.pas" var x, y : integer; s, newenv, curenv, newenvval, curenvval : string(255); teststr: CString; type PCString = ^CString; Function getenv(curenv:CString): PCString; C; Function setenv(newenv,newenvval:Tstring; x:integer): integer; C; begin s:='Test string'; writeln('The String is = ',s) end.

1 0

Re: Pointer to Method...
by Peter Gerwinski 07 Feb '98

07 Feb '98

According to Orlando Llanes: > Ok, this is a tricky one. I need to know how to get a pointer to a > method from an object. I've tried a million and one different things, but > was not able to do so. Is it even possible? Not without tricks. If you carefully cast pointers and take into account the implicit `Self' parameter of each method and pass it explicitly when you invoke the method through the pointer, you might succeed. > The reason I need this is > because I'm toying with the idea of making an object method an interrupt > routine. I suspect this is hopeless because you cannot expect the interrupted process to put the `Self' parameter into a certain register or a certain stack slot. You "must" use an "ordinary" procedure as the interrupt handler which may then call the method. (* And, of course, you must be very careful with interrupts in 32-bit protected mode anyway. ;*) Good luck, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: BP and BO question...
by Peter Gerwinski 07 Feb '98

07 Feb '98

According to Jim Roland: > So the convention to access a system call or part of the C Library is to > declare a function with same parameters and return data-type and put a C; > at the end of it? Yes. > Seems too easy! :) Okay, if you prefer something more difficult: The `C' directive is only to declare functions that are lowercase only. If the C declaration is in mixed case, for instance void MyCFunction ( int foo, long bar, long long baz ); write Procedure MyCFunction ( foo: Integer; bar: MedInt; baz: LongInt ); AsmName 'MyCFunction'; (* For more about `MedInt' and friends, see `info -f gpc -n "Integer types"'. This requires something more recent than gpc-2.0; see ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ *) Have fun, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: BP and BO question...
by Peter Gerwinski 07 Feb '98

07 Feb '98

According to Jim Roland: > I am in need to use the GetEnv function (and the SetEnv) function along > with other borland functions. Does your system support a `setenv()' C function? Mine (Linux) does, but I was told that it is not part of all standards. Since `man setenv' yields int setenv(const char *name, const char *value, int overwrite); I can declare an equivalent GPC function as follows: Function SetEnv ( Name, Value: CString; overwrite: Integer ): Integer; C; (And similar for `GetEnv'.) > [BO5, BPcompat] > How do I compile both? I can't get either to compile, and there don't > seem to be complete instructions to compile them. Currently, `BPcompat' only (?) supports DJGPP out of the box. Be welcome to help us to add support for UNIX systems. BO5, OTOH, is intended to be completely portable. Unfortunatly, those versions you can find on Agnes are somehow obsolete; I am currently working on a complete new implementation of BO5 (version 0.1 rather than 0.01;-) which uses `ncurses' for terminal I/O on UNIX-like platforms. Using GRX for graphics I/O (including X11) is in preparation. > Eventually, I would like to be able to modify the sources from the BP5 > library source code that I have (Borland, permitting of course) and use > them to include in my programs--possibly make it part of the GNU library > if they will allow it. Sorry for being that sceptical, but I doubt (a) that Borland will agree to use *anything* from their code in a LGPLed library and that (b) it would be useful for us at all because Borland's code is highly specialized for MS-compatible DOS systems. IMHO it will be less work and cause fewer legal problems to re-write the needed code from scratch. Again: Be welcome to join us in performing this task. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

2 1

Re: Kampi
by Peter Gerwinski 07 Feb '98

07 Feb '98

Hi, Larry! Hi, all! According to Larry Carter: > > Is anyone else having problems getting into ftp://kampi.hut.fi Yes. ;-) > I am trying to re-download the current release version of GPC and I cannot > get through to Kampi, is it down? I don't know, but if you are looking out for something really current with GPC, go to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ instead. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: Version problem
by Peter Gerwinski 07 Feb '98

07 Feb '98

According to Orlando Llanes: > > Unfortunately I can't help you there other than telling you that GPC > only compiles on platfroms like Unix and Linux :( ... and DJGPP (DOS) and EMX (DOS, OS/2) and CygWin32 and mingw32 (Windows-95/NT). For CygWin32, see cygnus.com; for mingw32, see http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: Version problem
by Peter Gerwinski 06 Feb '98

06 Feb '98

Hello! According to Jim Roland: > I have just installed GPC 2.0 (is there a newer one than this 12/96 > version?), and I'm having a problem running configure/make. See the GPC home page (URL below), or ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ > When I configure (I had to remake my gcc-2.7.2.2) i get a version error > that GPC 2.0 requires gcc-2.7.2.1, which I have 2.7.2.2! [...] Just edit the Makefiles and change the required GCC version number. The changes between gcc-2.7.2.[1-3] are minimal enough such that GPC will work with all of them without any change. > BTW, in code, how does one access the environment variables? Also, how do > you reference items that were part of the borland units (DOS, SYSTEM, > etc)? See the BP compatibility package at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ Have fun, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

2 2

Kampi
by Larry Carter 06 Feb '98

06 Feb '98

Is anyone else having problems getting into ftp://kampi.hut.fi I am trying to re-download the current release version of GPC and I cannot get through to Kampi, is it down? Larry lcarter(a)powerslave.jf.intel.com

1 0

Version problem
by Jim Roland 06 Feb '98

06 Feb '98

I have just installed GPC 2.0 (is there a newer one than this 12/96 version?), and I'm having a problem running configure/make. When I configure (I had to remake my gcc-2.7.2.2) i get a version error that GPC 2.0 requires gcc-2.7.2.1, which I have 2.7.2.2! It's frustating since that is a newer version, and I'm excited about possibly using GPC with the borland extensions since I'm a borland pascal person! :) BTW, in code, how does one access the environment variables? Also, how do you reference items that were part of the borland units (DOS, SYSTEM, etc)? ====================================================================== Jim Roland, running the most stable operating system in the world: OS/2 v4.0--I TALK to my OS, and IT LISTENS, does yours? ----------------------------------- Running Internet Servers on OS/2 & Linux (a free & stable Unix OS) ----------------------------------- Get free PGP software today to keep your files & messages private! Don't let ANYONE deprive you of your right to privacy!! ======================================================================

2 1

Re: gpc installation problems on Digital Unix
by Peter Gerwinski 06 Feb '98

06 Feb '98

Hello! According to Gary Narayanan USG: > > 1. The compiler (I think is gcc 2.7.2.1 compiles this and not > /usr/bin/cc) could not compile the file "gpc-decl.c" . The > error was in line 2962 > > TREE_CODE (TREE_VALUE (tail)) = code; > > The compile said it was not an l-value. > > I worked around by eliminating the conditional, and typing > > return NULL_TREE; > > for both cases. Will this break the compiler functionality? Yes. It must have been `/usr/bin/cc' since gcc-2.7.2.1 is known to accept this. The problem comes from the `TREE_CODE' macro being a type cast which is not accepted by all C compilers as an lvalue. To work around, replace the line by (TREE_VALUE (tail))->common.code = code; > 2. The file "gpc-module.c" has several '#define' statements and > not starting at first character of the line. The link editor > failed because of this, eg > > ld: unreolved STORE_SPECIAL Fixed. Thanks. > 3. The rts/Makefile generated needed some editiong, ie > adding a "../" for the gcc path name. Here I am not sure. Maybe this comes from some VPath problem? Anyway, more recent versions of GPC have an automatically generated `rts/Makefile' which hopefully does not cause this problem. Greetings, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

Re: gpc compile problem on solaris x86.
by Peter Gerwinski 06 Feb '98

06 Feb '98

Hello! According to David Montgomery: > > I have attempted to install gpc-2.0 under solaris 2.5.1 and 2.6 x86 and > encounter the same internal compiler error on both platforms. > [...] > gcc: Internal compiler error: program cc1 got fatal signal 6 Please try to work around this and disable optimization and/or generation of debugging information during compilation of GPC's RTS: Instead of just `make' or `make CFLAGS="-g -O", type `make CFLAGS=-O' or `make CFLAGS=-g' or `make CFLAGS=""'. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

gpc compile problem on solaris x86.
by David Montgomery 06 Feb '98

06 Feb '98

Hello, I have attempted to install gpc-2.0 under solaris 2.5.1 and 2.6 x86 and encounter the same internal compiler error on both platforms. root(a)athene-gpc-2.0: more error for i in p_ARCTAN.o p_SQRT.o p_LN.o p_EXP.o p_SIN.o p_COS.o p_POW.o p_EXPON.o; \ do gcc -c -o $i -g -O -D`basename $i .o` -I../../gcc -I../../gcc-2.7.2.1 -I../ ../gcc-2.7.2.1/config -I. ./rts-math.c;\ done touch math-stamp for i in z_ARCTAN.o z_SQRT.o z_LN.o z_EXP.o z_SIN.o z_COS.o z_POW.o z_EXPON.o p _POLAR.o p_ARG.o; \ do gcc -c -o $i -g -O -D`basename $i .o` -I../../gcc -I../../gcc-2.7.2.1 -I../ ../gcc-2.7.2.1/config -I. ./rts-zmath.c;\ done gcc: Internal compiler error: program cc1 got fatal signal 6 *** Error code 1 make: Fatal error: Command failed for target `zmath-stamp' Current working directory /export/home/source/gpc/gpc-2.0/rts *** Error code 1 make: Fatal error: Command failed for target `rts/libgpc.a' root(a)athene-gpc-2.0: I have compiled the solaris 2.5 sparc version successfully. Has anyone compiled gpc-2.0 under solaris x86? Thanks. David. -- -------------------------------------------------------------------------------- David Montgomery Department of Computer Science University of Newcastle University Drive Phone: +61 02 4921 6174 Callaghan 2308 NSW Fax : +61 02 4921 6929 AUSTRALIA Email: david(a)cs.newcastle.edu.au --------------------------------------------------------------------------------

1 0

Re: Passing strings by value
by Frank Heckenbach 03 Feb '98

03 Feb '98

Kevin A. Foss: > Is there something special that needs to be done to pass > strings by value? Yes, there is: fixing a bug in GPC... :-( This is a known bug, and will be solved sooner or later. In the meantime, you might have to use the obvious workaround, making a local copy of the string in the function. Thanks anyway for the bug report, Frank -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

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