Gpc

gpc@gnu.de

5400 discussions

list trouble
by Toby Ewing 20 Jun '02

20 Jun '02

Hi, all I'm having trouble with list management again. The code snipper below is part of a much longer program. It crashes apparently at random, sometimes after looping several thousand times. A simplified version ran "forever", so I know the basic strategy is fine. The crash occurs upon "dispose"ing a record in list Root, and gives sometimes a Page Fault, sometimes a General Protection Fault. Examining the record being disposed shows no pattern, such as being at the end of the list, near the edge of the lattice, etc. The object of the procedure is to define pathways through the 3-D maze defined in array Latt. Latt codes for connections in the positive and negative x, y, and z directions, and whether a given point has been tested yet (via Occ). In each pass through the list Root, the record location is examined for connected neighbors. The record is then disposed, and connected neighbors are inserted into the list "LNext". Then LNext is given to Root for the next pass. All insertions and deletions are therefore at the first position in a list. It's probably an obvious problem, and I'm hoping fresh eyes can see it. thanks, Toby --------------------------------- Procedure Advance(var Root : PRec; {rx, ry, rz: medcard; next: PRec} var Latt : PPLary; (3D lattice in schema format} var here, count : medCard); {Local to NumLatt. 1. Identify adjacent, accessible sites. 2. if sites are unoccupied, insert them into LNext. 3. Delete Self from Root. 4. Set Root = Lnext.} var LNext, PSelf : PRec; lx, ly, lz, {neighboring locations} dir : medCard; {directions} Conduct : boolean; {=accessible site} begin LNext := Nil; while (Root <> Nil) do begin PSelf := Root; with PSelf^ do for dir := 1 to 6 do begin {check all 6 directions} lX := rX; lY := rY; lZ := rZ; case dir of 1 : if (rX > 1) then begin {-X direction} lX := rX-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Xn) = Xn); end else Conduct := False; 2 : begin {-Y direction} if (rY = 1) then lY := ny else lY := rY-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Yn) = Yn); end; 3 : begin {-Z direction} if (rZ = 1) then lZ := nz else lZ := rZ-1; Conduct := ((Latt^[rX]^[rY,rZ] AND Zn) = Zn); end; 4 : begin {+Z direction} if (rZ = nz) then lZ := 1 else lZ := rZ+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Zp) = Zp); end; 5 : begin {+Y direction} if (rY = ny) then lY := 1 else lY := rY+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Yp) = Yp); end; 6 : if (rX >= nx) then Conduct := False else begin{+X direction} lX := rX+1; Conduct := ((Latt^[rX]^[rY,rZ] AND Xp) = Xp); end; end; {case} if (Conduct and (Latt^[lX]^[lY,lZ] < Occ)) then begin {unoccupied site} inc(count); {count newly accessible} LInsert(LNext, lX, lY, lZ); {insert into LNext} Latt^[lX]^[lY,lZ] := Latt^[lX]^[lY,lZ] OR Occ;{mark as occupied} if ((not Infinite) and (lX = nx) {check for breakthrough} and ((Latt^[lX]^[lY,lZ] AND Xp) = Xp)) then begin Infinite := True; MinPath := here; end; end; {if Conduct} end; {for dir} Root := Root^.next; {advance through list} write('a'); dispose(PSelf); { <<=== program crashes here } write('b. '); end; Root := LNext; end; {Advance}

2 3

Problems compiler regexdemo
by Preben Mikael Bohn 20 Jun '02

20 Jun '02

Hi all, I'm having trouble compiling regexdemo.pas, I get a $ gpc --automake --executable-file-name regexdemo.pas regexdemo.pas:31: virtual memory exhausted Line 31 is "uses regex;" My version of GPC is GNU Pascal version 20020402, based on gcc-2.95.2 19991024 (release). Any ideas? Best regards Preben Bohn ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 2

Re: new user questions
by da Silva, Joe 18 Jun '02

18 Jun '02

Try the "--autobuild" option, ie. "gpc --autobuild payroll.pas". If that doesn't work, you might not have installed correctly, particularly depending on the use or non-use of "long file names". For more information, I suggest you might read : http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt Joe. > -----Original Message----- > From: leegold [SMTP:leegold@fastmail.fm] > Sent: Tuesday, June 18, 2002 2:23 PM > To: gpc(a)gnu.de > Subject: new user questions > > please email me, I am not list member yet. > Trying to get install correct and gnu pascal working. > > ques: I got the following error message: > > A:\Turbo>gpc payroll.pas > gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) > > what should I check or try to fix? > > THANK YOU > > -- > http://fastmail.fm/ - A fast, anti-spam email service.

1 0

new user questions
by leegold 18 Jun '02

18 Jun '02

please email me, I am not list member yet. Trying to get install correct and gnu pascal working. ques: I got the following error message: A:\Turbo>gpc payroll.pas gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) what should I check or try to fix? THANK YOU -- http://fastmail.fm/ - A fast, anti-spam email service.

1 0

Syntax problem
by Cserzo Miklos 15 Jun '02

15 Jun '02

Hi Folks, the 2.1 release under SuSE 8.0 misbehaving slightly. If there is a syntax error in the code like: .... if pass[i] in 'A'..'Z' then ... instead of the correct version: .... if pass[i] in ['A'..'Z'] then ... The compilation terminates with a fatal error instead of halt and correct syntax error message. Regards, miklos ======================================================================= Miklos Cserzo E-mail: cserzo(a)abc.hu Bioinformatics Group Agricultural Biotechnology Center Phone: +36-28-430-600 ext. 112 Godollo, Szent-Gyorgyi A. ut 4. Fax: +36-28-420-096 H-2100 Hungary =======================================================================

2 1

Re: Pascal-Standard Question
by da Silva, Joe 07 Jun '02

07 Jun '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, June 06, 2002 12:29 PM > To: gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > da Silva, Joe wrote: > > > I've been following this debate and wondering just what the ISO > standards > > define. As you know, it's not easy reading through the standards and > > finding obscure little details such as this. <g> > > > > However, I think section 6.13 of ISO-10206 indicates that a program can > > indeed consist of multiple modules and can include one main program, > > each of which is terminated by a "full stop" (aka. "period"). > > Yes, even in any order. This is rather difficult to handle, if a > program precedes a required module. A way to do it is to split the > source file and pass each part separately to the compiler. This > could be done transparently by a preprocessor, and serve as a (more > general) replacement for the current feature ... > [Joe da Silva] Yes, odd isn't it? Well, IMHO, if it's too difficult to handle sections (ie. program-components) in any order, it should be an acceptable implementation restriction to require that the main program is the last section (in the usual "define it before you use it" manner). > > Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When > > eoln(f) is activated, it shall be an error if ... eof(f) is true". > > This means, in my words, that it's a runtime error to test EOLn when > the file is already at EOF. However, 6.4.3.6 says: > > : The structure of the type denoted by text shall define an additional > : sequencetype whose values shall be designated lines. A line shall be a > : sequence cs~S(endofline), where cs is a sequence of components > possessing > : the chartype, and endofline shall represent a special componentvalue. > : > : [...] > : > : Every value t of the type denoted by text shall satisfy the following > two > : rules: > : > : a) If t.M = Inspection, then t.L~t.R shall be a linesequence. > : > : b) If t.M = Generation, then t.L~t.R shall be ls~cs, where ls is a > : linesequence and cs is a sequence of components possessing the > : chartype. > : > : NOTE --- 5 In rule b), cs may be considered, especially if it is > nonempty, > : to be a partial line that is being generated. Such a partial line cannot > : occur during inspection of a file. Also, cs does not correspond to t.R, > : since t.R is the empty sequence if t.M = Generation. > > This indicates that it doesn't support partial lines at the end of > the file except during writing -- whether or not that's a good idea > is certainly arguable (I don't really think so) ... > [Joe da Silva] Yes, the standards seem to consider that a text file must consist of lines and that therefore such a file is invalid (as a text file) if there isn't an EOLN before EOF. Of course, such a file can still be a "file of char", but this means the text file features of read() and write() are lost. IMHO, the ability of a compiler to handle invalid situations in a more "user friendly" manner, does not truly detract from it's standards compliance, provided this does not affect how it handles valid situations, of course. I consider it a form of "error recovery". Therefore, I see nothing really wrong with a compiler simply returning TRUE for eoln() when eof() is TRUE. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

1 0

Re: Crash & various misc problems
by Waldek Hebisch 06 Jun '02

06 Jun '02

Frank's patches fixed crash and --nested-comments works. Thanks -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Re: Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Pierre Muller pointed out that, in my post of July 2 on this topic, I forgot to indicate that the file to patch is `gdb/dbxread.c' under the source tree. Sorry. > Did you test it by using insight in non windowed mode (with --nw option), then you get the normal text mode version of gdb. In my original post I wrote: > insight running in non-graphical mode (with the --nowin flag ) does > not exhibit this problem. One difference, I think, between the two modes is that, in the graphical mode, the entire symbol table is read at the time the binary file is opened, whereas it is apparently NOT read, at least not by the same routine, in the text mode. *** A few more details: If you use gdb on itself, as I did, and you break at line 2768 of dbxread.c, within fcn. process_one_symbol (which is the first line of my patch), you'll see that the context of the call is below `gdb_load_disassembly'. Apparently this fcn. is not called, or not in the same way, in the text mode. (Alternatively, in the unpatched source, line 2755 is the pop_context macro invocation where the problem occurs, and provides a suitable breakpoint for analysis. After fewer than 10 breaks, if memory serves, you arrive at one where context_stack_depth is already 0 - which is the problem situation. It's only easier to see this in the patched version because the variable is right in front of you. BTW, my procedure is to give `gdb gdb', set args to "" and run, and when the `debuggee' appears, to command it to open `smalltest' or some other program built with gpc 2.1.) ***** With regard to my post of July 3, "GPC2.1: all types "void" under gdb", please note that this problem can be easily observed in the text mode by using the "print" commmand. Finally, as a user, I'd like to thank the developers collectively for an impressive and useful product. Bob Scher

1 0

Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Hello. Hopefully this will be of interest to some of you - if not, my apologies if I am off-topic. I found that when trying to use the "insight gdb" visual debugger on a binary made using (my locally built) GPC 2.1, the debugger crashes while performing an initial read of the "stabs" info in the binary. But it doesn't crash on binaries made from the (Redhat distributed binary) gpc-19990118. I'm not 100% sure that this is an insight gdb problem - it might take a stabs expert to decide whether insight's logic is correct here or whether there's anything invalid about the stabs sequence emitted by gpc. In any case, below is a simple patch of insight to work around the problem. It works for a couple of multi-module gpc programs that I've tried it with. BTW, the debugger source is ftp://sources.redhat.com/pub/gdb/releases/insight-5.2.tar.bz2 I just submitted a problem report to the insight developers - we'll see what they say. Here's the patch: 1,12d0 < /* modified 5/31/02 Robert Scher. Changes flagged with "RBS". < Works around a problem encountered when reading executables produced < by gpc (Gnu Pascal) version 2.1. Without this change - or hopefully < a more proper correction that attacks the problem head-on, < the "insight" (graphical) variant of gdb crashes at the point where it < reads the stabs section associated with the file error.pas in the < gpc 2.1 support files set. This is a problem peculiar to the graphical < mode (and has been seen on several versions of "insight"). < insight running in non-graphical mode (with the --nowin flag ) does < not exhibit this problem. < */ < 1613c1601 < { --- > { 1641d1628 < 1652a1640 > 2767,2771c2755 < // start RBS patch: check to prevent popping garbage when depth is already 0 < if (!context_stack_depth) < break; // ignore it! < // end RBS patch < new = pop_context (); --- > new = pop_context (); Bob Scher

2 1

Re: Pascal-Standard Question
by da Silva, Joe 06 Jun '02

06 Jun '02

I've been following this debate and wondering just what the ISO standards define. As you know, it's not easy reading through the standards and finding obscure little details such as this. <g> However, I think section 6.13 of ISO-10206 indicates that a program can indeed consist of multiple modules and can include one main program, each of which is terminated by a "full stop" (aka. "period"). Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When eoln(f) is activated, it shall be an error if ... eof(f) is true". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, June 05, 2002 8:00 PM > To: cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > CBFalconer wrote: > > > Frank Heckenbach wrote: > > > Eike Lange wrote: > > > > On Tue, Jun 04, 2002 at 10:16:21AM -0400, CBFalconer wrote: > > > > > Put in those terms, he is absolutely right IMO. Anything that > > > > > follows the "end ." should be ignored, in fact not even read. The > > > > > period should be parsed and cause compilation to stop. I think > > > > > the syntax is something like: > > > > > > > > > > program ::= 'program' progparms ';' declarations block '.' > > > > > > > > Yes, but there might be a statement like this (not exactly BNF :-) > > > > part ::= program or unit > > > > file ::= part until EOF > > > > > > Yes, I'd also think so. Normally, a grammar doesn't imply that > > > anything may follow the program. > > > > > > However, BP behaves like this, and GPC does so with > > > `--borland-pascal' (but I don't think we should make this the > > > default). > > > > Who are you agreeing with? I hope it is me :-) > > No, Eike who I quoted directly. > > > I actually had to go to some trouble to get this to work correctly > > in PascalP, because I allowed EOF to appear immediately after the > > '.', with no eoln. At the same time I wanted to collect source > > lines for a listing. > > Why don't you just read it as a text file (provided PascalP was > written in Pascal)? According to the standard, a text file in Pascal > consists of lines, so there is always an EOLn before EOF (whether or > not the external file contains a newline at the end). > > Obviously, GPC (written in C) doesn't do this, either. It just > processes the input character-wise and counts the newlines (for > messages) and outputs it character-wise (with `--debug-source'). > > > This characteristic is convenient for appending rambling notes > > after the final "end." without worrying about forming proper > > comments. > > The question is not whether it's convenient, but whether it's > allowed by the standards. Do you have any reference where they allow > it? > > > BTW I just ran across a fascinating essay at: > > > > <http://www.epemag.com/zuse/forword.htm> > > > > which might especially interest you. > > Gives me a 404. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc