- Gpc - gnu.de

Integration Kit for Apple's Xcode IDE
by Adriaan van Os 12 Aug '05

12 Aug '05

(reposting) Available for download from <http://www.microbizz.nl/gpc.html> is the GNU Pascal Xcode integration Kit for Apple's Xcode IDE. Screendumps can be found at <http://www.microbizz.nl/gpcxcode.html>. The Xcode Kit includes demo programs, Pascal source file icons, a compiler update and project templates for Mac OS X for: * applications * application packages * application packages with nib files * command line tools * portable command line tools * dynamic libraries * frameworks * bundle files * loadable bundle packages * relocatable object files * static archive libraries Release notes are included in the package. Regards, Adriaan van Os P.S. A remaining (known (but annoying)) problem while debugging is the wrong-line (one-line-offset) problem.

1 0

FillChar Suggestion
by Pascal Viandier 11 Aug '05

11 Aug '05

Hello, Do you think it is possible to modify the prcedure "FillChar()" to make it work correctly with the type String(xx)? For example the code: VAR S10 : String(10); .... FillChar(S10, 10, 'A'); WriteLn(S10); Would display: AAAAAAAAAA I ask this because I am working on (converting to GPC) a lot of existing code, with FillChar() spread everywhere (more than 1200 SUN Pascal sources), and it works as expected on strings on SUN Pascal. However, since there is no 'Capacity' field in SUN Pascal strings, it cannot be overridden. I understand this can be a big job since calling FillChar() on a record containing Strings should work as well. I think this would be a nice feature anyway, don't you? Also, if this cannot be done or desirable from your point of view, is there a way to override the build-in FillChar() for one of mine that would be called for the type String(xx) only? I know this is not an elegant workaround, but this problem causes a lot of nasty bugs in the converted programs. If I was to write the code from scratch this would not be an issue, but rewriting more than 600 000 lines of Pascal code is an even bigger challenge :-( Regards Pascal Viandier pascal(a)accovia.com

3 7

TR : Comparing Records
by Pascal Viandier 11 Aug '05

11 Aug '05

Hi, <snip> > Out of curiosity, what kind of application is this where you have to > compare more than 600 different record types for equality? It is a complete integrated solution for the travel industry. The oldest code parts are from 1985, and it is still in development for new functionalities. > In my > whole code base, I probably have just a handful of such cases (which > I do field by field then). In fact, I don't have to compare all the record types (I hope so!). I just encountered the first case yesterday during the conversion process, and I realized I missed this one in my gap analysis between SUN and GNU Pascal. <snip> > How carefully have you tested it? Did you try global, local and > heap-allocated variables? Did you intentionally garbage-fill the > memory used before allocating the records (not applicable to global > ones, but to local and dynamic ones, with some tricks)? No, I did not check extensively. Since the SUN Pascal Manual says the records can be compared, I just dumped some to see how they were laid out. Perhaps SUN does field by field comparison, I don't know. Anyway, I will create = and <> operators only for the records implied in comparisons. Regards Pascal Viandier pascal(a)accovia.com

1 0

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 08 Aug '05

08 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