Gpc June 2002

gpc@gnu.de

22 participants
29 discussions

Data structure like file system
by Preben Mikael Bohn 22 Jun '02

22 Jun '02

Hi all, this is not a GPC-specific question, but here it goes anyway... :-) I need a data structure or object in Pascal that basically can hold a file-system. Only difference between this and an ordinary filesystem is that permissions, timetags, etc, are not needed, "only" the directories and filenames as well as ~10-20 bytes storage for each file. Any idea how this could be accomplished, or pointers to already existing source? 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

3 3

FSF directory
by Maurice Lombardi 22 Jun '02

22 Jun '02

Hi all While browsing informations on the Free software directory I have found the page http://www.gnu.org/directory/Software_development/Compilers/freePascal.html where there is complete confusion between FPC and GPC. One should ask to have two different pages for the two compilers. But who is entitled to ask for rectification and where to do that ? Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: list trouble
by Toby Ewing 22 Jun '02

22 Jun '02

Hi, again CBFalconer wrote: > Simplify your basic list handling and publish the whole thing. It > is highly suspect, because you are in the habit of making copies > of pointers in a rather undisciplined manner. You are not working > with the lists you think you are. I have to admit that everything I (formally) learned about programming I learned in Fortran on punch cards. But I didn't think my pointer work was all that bad! Below is the program, stripped of everything but the list handling. Now it works perfectly, of course. But perhaps the error is still lurking? I'd appreciate any suggestions. I'm flummoxed. The basic idea is that I start with a list with a bunch of entries. I pass through the list, using information in it to generate a new list. Each record I examine, I dispose. I then pass the new list to the old one (pointer), and repeat. Eventually, there are no more entries, and the program moves on to the next realization (main loop). I thought perhaps there was a systematic memory leak, so I have two simple detection schemes. One is that I print out the starting address of the list for each realization (no trend, just random drift). The other is that each pass through the first list should generate the same number of records that is deleted on the next pass (this is the countIn, countOut, prevIn stuff - it also checks out). regards, Toby ------------------------ Program Snowbird; Const Realize = 20; initial = 6500; Type PRec = ^Rec; Rec = record rx, ry, rz : shortCard; check : PtrCard; next : PRec; end; var r : shortCard; PrevIn : medCard; {________________________________________________ } Procedure NumLatt(var PrevIn : medCard); var Root : PRec; countIn : medCard; i : shortCard; {-----------------------} Procedure LInsert(var Root : PRec; x, y, z : shortCard); var temp : PRec; begin New(temp); with temp^ do begin rx := x; ry := y; rz := z; check := PtrCard(temp); next := Root; end; Root := temp; end; {LInsert} {-----------------------} Procedure Advance(var Root : PRec; var countIn, PrevIn : medCard); var LNext, PSelf : PRec; i, countOut : medCard; begin LNext := Nil; countOut := 0; while (Root <> Nil) do begin {walk through Root list} for i := 1 to trunc(2.98*random) do begin {build LNext list} inc(countIn); LInsert(LNext, i, 2*i, 3*i); end; PSelf := Root; {destroy Root in passing} Root := Root^.next; inc(countOut); Dispose(PSelf); PSelf := Nil; end; Root := LNext; {give LNext to Root} LNext := Nil; if (countOut <> PrevIn) then begin {do numbers balance?} writeln('error: countOut = ', countOut:1, ', PrevIn = ', PrevIn:1); readln; end; PrevIn := countIn; end; {Advance} {-----------------------} begin {NumLatt} Root := Nil; LInsert(Root, 1, 2, 3); writeln('Root starts at ', Root^.check:1); for i := 2 to Initial do LInsert(Root, i, 2*i, 3*i); repeat countIn := 0; Advance(Root, countIn, PrevIn); until (countIn = 0); end; {________________________________________________ } begin {Main Program} writeln; writeln('List checking'); writeln; Randomize; for r := 1 to Realize do begin write('Realization ', r:2, ': '); PrevIn := Initial; NumLatt(PrevIn); end; end.

1 0

Re: list trouble
by da Silva, Joe 21 Jun '02

21 Jun '02

Speaking of optimization, are you using any "heavy" optimization settings that may be giving side-effects? Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Friday, June 21, 2002 5:59 AM > To: gpc(a)gnu.de > Subject: Re: list trouble > > Toby Ewing wrote: > > CBFalconer wrote: > > > Toby Ewing wrote: > > > > > > > > I'm having trouble with list management again. > > ... snip ... > > > > It's probably an obvious problem, and I'm hoping fresh eyes can see > it. > > > > > > All I have done below is reformat, so I could follow it, and > > > separate out the mundane operations into a local procedure, so > > > that the actual list manipulation stands alone, and also because I > > > have no idea what that piece of code is doing. Many variables > > > should be moved into the local, and the item to manipulate should > > > be passed into it, but that is another matter. > > > > It's a trade-off between clarity and speed. The loop will execute > > several billions of times, and the run time is several days. I try not > > to call functions or procedures from inner loops. But as you say, > > that's a whole other discussion. > > You are doing enough in that routine that there should be no > perceptible difference in speed. The first rule of optimization > is don't. The second is profile first. > > > > > >Now go to the end > > > > > > > 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} > > > > > > > > (* 2--------------------2 *) > > > > > > > > PROCEDURE operate; > > > > > > > > BEGIN (* operate *) > ... snip ... > > > > END; (* operate *) > > > > > > > > (* 2--------------------2 *) > > > > > > > > BEGIN (* advance *) > > > > LNext := Nil; > > > > WHILE (Root <> Nil) DO BEGIN > > > > PSelf := Root; > > > > operate; > > > > Root := Root^.next; {advance through > list} > > > > write('a'); > > > > dispose(PSelf); { <<=== program crashes here } > > > > write('b. '); > > > > END; (* while *) > > > > Root := LNext; > > > > END; {Advance} > > > > > > The above makes it pretty obvious that the problem is NOT in the > > > operate action, but in the list itself. The fact that dispose > > > crashes shows that PSelf is not a valid pointer to a record, which > > > includes *the fact that the record was created with new* > > > > I agree that the problem is that PSelf is apparently not a valid > > pointer. I don't understand what you're saying about New. Is New not > > stable or trustworthy? > > Perfectly stable and trustworthy. > > > > > > I think you should look into the areas where the list is created. > > > You may have a global instance of an element, for example, that > > > you are incorporating into the list somehow. > > > > The list is created by > > 1) declaring the variable Root : PRec (outside procedure Advance), and > > 2) using the procedure LInsert to add elements to the list. > > LInsert is: > > > > Procedure LInsert(var Root : PRec; > > var x, y, z : medCard); > > var temp : PRec; > > begin > > new(temp); > > with temp^ do begin > > rx := x; > > ry := y; > > rz := z; > > next := Root; > > end; > > Root := temp; > > end; > > > > The only list manipulation is the LInsert procedure, and the dispose > > line that sometimes crashes the program. All records in the list come > > from LInsert. What I find disturbing is that this is a very simple > > piece of list work. The program sometimes runs through over 2,000,000 > > records without crashing - and sometimes crashes after about 100 > > records. Frustrating. > > > > CBFalconer continues: > > > GPC new/dispose is dependant on the C malloc, I believe. If you > > > are using DJGPP you can probably use my nmalloc, available on my > > > site, which provides some hooks for examining the allocation > > > chains and also detects most illegal frees. If it is linked ahead > > > of the runtime library it will replace the library malloc stuff. > > > But that should be only a last resort. > > > > Yes, I'm using DJGPP and will check out your nmalloc. I'm also > > installing GPC on a Linux box so I can try te program there. Because > > this is memory weirdness, I'm wondering if at heart it's a windows > > problem. > > I assume you have a declaration somewhere like: > > TYPE > prec = ^rec; > rec = RECORD > ... > next : prec; > END; > > and I was envisioning you had done something like declare > > VAR > root : rec; > ... > > but you say not. Have you ever initialized root to be NIL? > > VAR > root : prec; > > .... > root := NIL; (* <---- absolutely crucial *) > WHILE whatever DO linsert(root, ...); > .... > > If you don't have ECC memory it is conceivable you have hardware > problems. Another possibility is some bad indexing fouling the > chains (gpc doesn't have range checking :-[) where the nmalloc > stuff might come in handy. > > You could build a list validator, which only walks the list from > root to final NIL. To use it add a field set to a constant value, > and the validator checks that value is there for each entry. > Should be quite fast, and you can then call it here and there in > the program. This would give an early indication of fouled > storage. > > CONST > VALIDMARK = 1234; > > TYPE > rec = RECORD > validation : integer; > .... > END; > > PROCEDURE linsert(....) > .... > new(temp); > temp.validation := VALIDMARK; > ... > > PROCEDURE listvalidate(calledfrom : integer); > > LABEL 10; > > VAR temp : prec; > > BEGIN (* listvalidate *) > temp := root; > WHILE temp <> NIL DO > IF temp.validation <> VALIDMARK THEN BEGIN > takesomeaction(calledfrom); > goto 10; END; > 10: END; (* listvalidate *) > > (you may notice I don't believe in using things outside of ISO7185 > without very good reasons, none of which I see here <g>) > > If all else fails see line 2 of the sig. > > -- > Chuck F (cbfalconer@yahX-Mozilla-Status: 0009rldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address!

3 2

Re: list trouble
by Toby Ewing 20 Jun '02

20 Jun '02

Hi again CBFalconer sent me a list validating procedure, which I stuck into the program. I actually made two versions, one to check the immediate record, and one to check the entire list. I ran it in many ways, but the results are always the same. The checker says everything is fine, and then the program still crashes as before. Checking the record pointed at by PSelf, immediately before disposing it, finds nothing. I modified the checker procedure so it would write a new value (0) to the validation mark, then write the validmark again. Same result. Now here's the twister. I tried running the program on a linux machine - same code, same version of gpc. It crashed in a different place, but also on a dispose statement. In that case, it was disposing a schema (array). Any suggestions? I'm starting to get worried that this code will never work! regards, Toby

1 0

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

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 June 2002