Gpc August 2005

gpc@gnu.de

17 participants
30 discussions

RE : RE : Comparing Records
by Pascal Viandier 11 Aug '05

11 Aug '05

Hi, > Pascal Viandier wrote: >> When I say "compatible types", I say records with the same fields in >> the >> same order so I presume the padding bits and bytes would be done the >> same >> way. > >Yes, but the pad bits and bytes can have random values ... Ha! If only I could use FillChar() on the record before using it, there would be no problem! (Did you read the FillChar Suggestion thread?) This looks like a typical good reason to use it... I suppose the Extended Pascal's initial-state-specifier does not make initialization on padding bits and bytes neither. > snip< > >But you have been warned. If the padding content is random, I cannot use memcmp() reliably. I am done :-( Thank you very much anyway. Pascal Viandier pascal(a)accovia.com

3 4

Comparing Records
by Pascal Viandier 11 Aug '05

11 Aug '05

Hi GPC crew, I just got into a new issue in my SUN Pascal to GPC conversion process: In SUN Pascal, one can compare records variables (of the same or compatible type, obviously) with the "=" and "<>" logical operators and obviously enough, ">=" and "<=" cannot be used to compare records, it is meaningless. It looks that GPC does not implement records comparison. The compiler reports: invalid operands to `<>'. I consulted the ISO 10206 Standard but I don't find anything about records comparison in the logical operators section. It looks like a SUN Pascal extension (one more :-() So, is there a way compare records of compatible types without doing it field by field? I know I can create new operators "=" and "<>" but in this case I will have to do it for the 600+ record types of the applications. There must be a better way to do it... In C, a simple memcmp() call could do the job :-( However, I think this could be a nice and logical feature to have in GPC: Why, if we can assign a record to an other with ":=", cannot we test them for (in)equality afterwards? Perhaps I am bothering you with my conversion problems and suggestions, but you already saved me hundreds hours of work. It is invaluable! Thanks and thanks Pascal Viandier pascal(a)accovia.com

4 6

Mac objects and Delphi classes
by Waldek Hebisch 09 Aug '05

09 Aug '05

I have put a new "cumulative" diff on my GPC web page: http://www.math.uni.wroc.pl/~hebisch/gpc/delphi14.diff and http://www.math.uni.wroc.pl/~hebisch/gpc/dbxout.diff I have added a new option `--objects-are-references' (off by default, on for Mac Pascal) which choses reference model for objects. To get Mac semantics one has to use `--objects-are-references' and `--methods-always-virtual'. Delphi support still is incomplete (most visibly GPC does not know about `TObject'), but constuctors and destructors mostly work (one can not call a destructor from within another destructor), in particular allocate and deallocate memory. Adriaan van Os wrote: > I have compared various MacPascal object diffs posted on the gpc > mailing list (to delphi3.diff) with delphi9.diff. I see that two > patches are missing in Delphi9.diff. I guess the reason is > > - the first patch is not to gpc but to gpidump > - the second patch is of later date. Thanks for remainding me about gpidump patch. There are a few fixes that I found after delphi9.diff was made, the new diff collects them all (plus a new code, mostly for Delphi). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 14

Re: fill string
by willett 09 Aug '05

09 Aug '05

Just to add confirmation to what Frank and Gale have said. In the following "foo" example, yes, the string length is undefined. Yes it is supposed to be an error, and is defined as an error in ISO and Extended Pascal standards. No, it's probably not desirable to start automatically initializing everything; it would be costly in time and space and generally an error-free program will do it's own initialization when needed. And sure, GPC does not detect undefined values, in fact, very very few "compilers" (actually runtimes) do detect undefined values. (Our "Dr. Pascal" interpreter is one of the few systems that does, and it costs a lot of runtime overhead and complexity.) It's very reasonable for GPC to not try to do this. Willett Kempton Visible Software On 7 Aug 2005, at 21:21, Frank Heckenbach wrote: > Russell Whitaker wrote: > > > >>> The capacity, OTOH, is initialized, and must be in order for the >>> string to work at all. >>> >>> >>> >> Would it be reasonable to define the length to be 0 as the default >> initialization? >> >> > > It would be nonstandard. Basically the same question as defining > default values for other types. The programmer can do this > explicitly (String (n) value '') if wanted. > > > >> Otherwise the following should produce an error >> but dosen't: >> >> program foo; >> var >> s : string( 500 ); >> begin >> writeln( length(s) ); >> end. >> >> > > As I said, GPC doesn't check for using undefined values at all. > (Currently, and this isn't going to change soon, as this is not > exactly trivial to implement in general ...) > > Frank > >

3 4

fill string
by Russell Whitaker 07 Aug '05

07 Aug '05

hi This used to work: program fil; var i : integer; s : string( 500 ); begin for i := 1 to 500 do s[ i ] := ' '; writeln("ok"); end. Now I get "Value out of range" Is it me or it? Russ

4 7

profiling information
by Peter N Lewis 05 Aug '05

05 Aug '05

Adriaan suggested I use --propagate-units to improve my compile speed. I tried that, but given I use --uses=GPCMacOSAll, where GPCMacOSAll is all the Mac OS X system interfaces in a single unit, and it compiles to a gpi of 27Meg, that would make each of my gpi's 27Meg (perhaps worse if it ends up being included multiple times). But regardless, it didn't work because a simple compile of a trivial unit ended up taking multiple minutes itself, so something it not happy. I'll have to see if I can manage to add explicit system units to the uses clause of my units in order to get --propagate-units in order to see if that will improve things, but I haven't done that yet. Then I tried turning off one of my processors, reverting back to the original gp so it compiles one unit at a time, and using the Mac OS X Shark tool to profile the system while compiling some units. It's not clear from the results what percentage of the time is actually being spent inside gpc1, but the report on a gpc1 processes is interesting (attached below). It shows 50+% in import_interface. This matches with what Adriaan saw in the progress messages (that the progress messages spent a long time in the lines around the uses clause). Enjoy, Peter. # Time Profile of Everything SharkProfileViewer # Generated from the visible portion of the outline view + 73.0% start (gpc1) | + 73.0% _start (gpc1) | | + 72.0% toplev_main (gpc1) | | | + 70.2% main_yyparse (gpc1) | | | : + 70.1% yyuserAction (gpc1) | | | : | + 54.3% do_extra_import (gpc1) | | | : | | + 54.3% import_interface (gpc1) | | | : | | | + 41.7% load_gpi_file (gpc1) | | | : | | | : + 27.4% load_node (gpc1) | | | : | | | : | - 6.4% get_identifier (gpc1) | | | : | | | : | - 4.7% load_string (gpc1) | | | : | | | : | - 4.7% mread1 (gpc1) | | | : | | | : | - 3.1% set_identifier_spelling (gpc1) | | | : | | | : | - 1.8% make_node (gpc1) | | | : | | | : | - 1.4% free (libSystem.B.dylib) | | | : | | | : | 1.1% szone_free (libSystem.B.dylib) | | | : | | | : | 0.3% mseek (gpc1) | | | : | | | : | 0.2% ggc_alloc (gpc1) | | | : | | | : | 0.1% itab_store_node (gpc1) | | | : | | | : | - 0.1% ht_lookup (gpc1) | | | : | | | : | - 0.1% build_decl (gpc1) | | | : | | | : | 0.1% sort_fields (gpc1) | | | : | | | : | 0.1% dyld_stub_free (gpc1) | | | : | | | : | 0.1% allocate_decl_lang_specific (gpc1) | | | : | | | : 11.8% compute_checksum (gpc1) | | | : | | | : - 1.5% gpi_open (gpc1) | | | : | | | : - 0.1% mread1 (gpc1) | | | : | | | - 12.4% import_node (gpc1) | | | : | - 13.2% finish_routine (gpc1) | | | : | - 2.0% finalize_module (gpc1) | | | : | - 0.3% import_interface (gpc1) | | | : | - 0.1% build_predef_call (gpc1) | | | : | - 0.1% start_unit_implementation (gpc1) | | | : - 0.2% yylex (gpc1) | | | - 1.5% write_global_declarations (gpc1) | | | - 0.1% init_regs (gpc1) | | | - 0.1% yyparse (gpc1) | | | - 0.1% lang_init_3_4 (gpc1) | | | - 0.1% init_emit_once (gpc1) | | 0.8% write_global_declarations (gpc1) | | 0.1% recog_12 (gpc1) | | 0.1% init_regs (gpc1) | | - 0.1% _call_mod_init_funcs (gpc1) - 15.9% thandler (mach_kernel) - 10.7% shandler (mach_kernel) - 0.3% unix_syscall (mach_kernel) - 0.1% thread_continue (mach_kernel) - 0.1% _dyld_start (dyld) -- <http://www.stairways.com/> <http://download.stairways.com/>

2 1

broken link
by Tom Schneider 04 Aug '05

04 Aug '05

Dear GPC Folks: http://www.gnu-pascal.de/gpc/Invoking-GPC.html#Invoking-GPC link to GCC Command Options (the GCC Manual) is | Not Found | The requested URL /gcc/Invoking-GCC.html was not found on this server. Where is it? Thanks, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 2

can't get dbx to find lines
by Tom Schneider 04 Aug '05

04 Aug '05

Folks: A program of mine is giving a segmentation fault and it's hard to locate. So I need to compile with debugging on and then run dbx to find the line number. I compiled as: gpc \ -g \ --transparent-file-names \ --no-mixed-comments \ -Wall \ lister.p -o lister When I run dbx dbx lister I get (header stuff deleted) Reading lister Reading ld.so.1 Reading libm.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libc_psr.so.1 dbx: warning: Unknown symbol type: /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #5 char:t(0,2)=@s8;-20; dbx: warning: Unknown symbol type: /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #176 Sof:S(0,192)=@s24;@S;S(0,193)=r(0,1);0000000000001;0000000000003; dbx: warning: can't find local function 'Digit': /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #265 Digit:f(0,61),Digit,Pluckdigit dbx: warning: can't find local function 'Pluckdigit': /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #291 Pluckdigit:f(0,68),Pluckdigit,Getdatetime dbx: warning: Unknown symbol type: /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #1222 tmp_string_32:(0,210)=s12Capacity:(0,4),0,32;length:(0,4),32,32;_p_schema_:(0,211)=@s8;@S;S(0,212)=r(0,1);0000000000001;0000000000001;,64,8;; dbx: number not found at /home/strawberry/toms/work/lister/bug2005aug3/lister:lister.p stab #1222 tmp_string_32:(0,210)=s12Capacity:(0,4),0,32;length:(0,4),32,32;_p_schema_:(0,211)=@s8;@S;S(0,212)=r(0,1);0000000000001;0000000000001;,64,8;; (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) and then tell it to run It runs fine (up to the crash): (expected output) signal SEGV (no mapping at the fault address) in 272 at 0x3003c 0x0003003c: 272+0x0350: ld [%o0 + 0x4], %o1 (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) but for the line command I always get: dbx: no current source file Somehow it does not locate the Pascal source. What (perhaps obviously trivial) thing am I missing? (I tried xping but it was not obvious how to get it to point to the error. I tried workshop on this sun machine and it gave me a machine code location.) Maybe there is a page somewhere that says how to do this? I didn't find it. gpc -g --transparent-file-names --no-mixed-comments -Wall lister.p -o lister The command files gives dbx: no program Thanks! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

const s: String(1000) passed by value?
by Peter N Lewis 03 Aug '05

03 Aug '05

It seems that const parameters of string types are passed by value, eg: program peterT4; type Str = String(1000); var gs: Str; procedure Doit( const s: Str ); begin if @s = @gs then begin WriteLn( 'OK' ); end else begin WriteLn( 'failed' ); end; end; begin Doit( gs ); end. fails. I checked the code and it definitely looks like it is doing a copy. I use a lot of long strings (2500) and so this seems like a serious problem to me... Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

4 5

Heap dimensions
by Silvio a Beccara 01 Aug '05

01 Aug '05

Hello, is it possible to increase heap dimensions? I am running a GPC program which uses "big" dynamic arrays of double precision floats (up to 200 x 500) and, while it runs fine with smaller dimensions, from 128 x 256 up I get the following error: /u/dms/abeccara/pimc/parpi/pimb: out of heap when allocating 629145608 bytes (error #853 at 8071a32) I wasn't getting this error when using an older GPC version 2.1 (20020510), based on gcc-2.95.2 19991024. I am running on 30 processors with 1 GB RAM each, so I would like to use this memory. Thanks in advance, best regards Silvio a Beccara -Trieste Italy -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vuoi bere tanta acqua pura e risparmiare ben 495 euro all'anno? * Con BeviSano avrai finito di comprare acqua in bottiglia - clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3628&d=21-7

9 20

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 August 2005