Gpc March 2005

gpc@gnu.de

32 participants
67 discussions

Porting from Dec Pascal to GPC
by Angelo.Fumagalli＠alcatel.it 04 Mar '05

04 Mar '05

Hi, we are going to port thousand and thousand of Dec Pascal modules to GPC in order to migrate software from VMS to Linux platform. We know that here there are the maximum experts to ask for, so we would like to ask you wich is the better model to migrate Dec environment modules maintaining the structure in terms of files and references, without having to completely change the source code, without splitting the procedure declarations and moving them in the library implementation modules. Have you some documentation which describes how to porting from Dec pascal to GPC that you could supply us? A litte DEC Pascal environment example: 1. environmet file me.pas MODULE ME; procedure p1; extern; procedure p2; extern; ....... procedure pn; extern; END. 2. library module m1.pas .. mn.pas NOTE:: typically all library modules which implement global procedures defined in the environment file me.pas are in the following format: [INHERIT('me')] MODULE m1; [global] procedure p1; begin .... end; END. 3. Program module p.pas: [INHERIT('me')] PROGRAM P; begin p1; p2; ... pn; END. Modules migration to GPC (is this one the only possible migration?): 1. library modules m1.pas .. mn.pas module m1 interface; export m1 = all; procedure p1; forward; end. module m1 implementation; procedure p1; begin ... end; end. 2. program module p.pas program p; import lbbp1: lbbp2; ... lbbpn; begin p1; p2; ... pn; end. Otherwise, it's possible to have the same DEC Pascal file/module structure? I mean only one interface module (me.pas) which is imported/used in all library and Program modules? Thank you very much in advance for your help. Kind regards. Angelo Fumagalli

3 2

c library imports revisited
by Rick Engebretson 04 Mar '05

04 Mar '05

OK, I've updated gpc and begun to probe for "clarification." I'm glad an automated c-header translator is being discussed. The fpc people have such a tool and have translated libc. A terrific pascal development. One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts. For example using the fpc unit "libc"; the libc function "close()" takes a file descriptor parameter, while the native pascal "close()" takes a file type parameter. Thus, the fpc libc "close()" is singled out and renamed in "unistdh.inc" to "__close()". (if memory serves me) Perhaps such a naming confusion can be avoided with all libc imports being named libc_name(). A libc unit for pascal is a big departure from the dos world. Other c-libs like OpenGL, etc. will follow. I really don't care about ISO-this or ISO-that. Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.

2 3

Re: (Fwd) Re: Pascal front-end integration
by Frank Heckenbach 03 Mar '05

03 Mar '05

Joseph S. Myers wrote: > On Tue, 1 Mar 2005, Prof A Olowofoyeku (The African Chief) wrote: > > Instead of starting a totally separate project, wouldn't it be better > > to coordinate your efforts with the GPC development team? > > Effective coordination will require, for a start, the GPC mailing list > to accept messages from nonsubscribers. Sorry, that's not an option because of spam. Despite the spam filters in use, currently about 5 spams per day get through and are only rejected because of the nonsubscriber block. I don't know if the GCC list has effective spam protection -- I know that other GNU lists don't (e.g., the bison lists are just kicking me out because my own spam filter bounces spam they let through) ... I'd consider this the worse alternative, given that the gpc list is mostly used by gpc users and developers, and "cross" discussions such as this one are the exception. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

a little gpc (iwidgets) notebook
by Rick Engebretson 02 Mar '05

02 Mar '05

If anybody has Iwidgets 4, they might try this script. It's just a tabbed notebook with a few other widgets added (entry fields, disjoint listbox). The point is, pascal is an organized language, and a virtual notebook might help organize development. Certainly, text processing is yet to be added. Maybe the "diff debate" could be presented on a page. #!/bin/sh #\ exec wish "$0" package require Iwidgets 4.0 # ---------------------------------------------------------------------- # create tabnotebook # ---------------------------------------------------------------------- option add *textBackground white option add *Tabnotebook.backdrop DimGray option add *Scale.width 8 . configure -background white wm title . "T-pascal" iwidgets::tabnotebook .tnb \ -width 8i \ -height 10i \ -tabpos w \ -gap 10 \ -background seashell \ -font "helvetica 14" pack .tnb \ -expand yes \ -fill both \ -padx 4 -pady 4 # create Summary CoverPage # ---------------------------------------------------------------------- set page1 [.tnb add -label "Cover Page"] # put widgets in cover page frame $page1.filler1 \ -background "" \ -height 1i \ -width 5i pack $page1.filler1 \ -fill x iwidgets::entryfield $page1.unit_name \ -labeltext "Pascal Unit Name:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_name \ -pady 5 iwidgets::entryfield $page1.unit_info \ -labeltext "Pascal Unit Info:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_info \ -pady 5 iwidgets::entryfield $page1.unit_path \ -labeltext "Pascal Unit Path:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.unit_path \ -pady 5 frame $page1.filler2 \ -background "" \ -height 1i \ -width 5i pack $page1.filler2 \ -fill x iwidgets::entryfield $page1.c_lib_name \ -labeltext "C Library Name:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_name \ -pady 5 iwidgets::entryfield $page1.c_lib_info \ -labeltext "C Library Info:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_info \ -pady 5 iwidgets::entryfield $page1.c_lib_path \ -labeltext "C Library Path:" \ -labelfont "helvetica 14" \ -textfont "helvetica 14" \ -labelpos nw \ -background tan \ -width 50 pack $page1.c_lib_path \ -pady 5 frame $page1.filler3 \ -background "" \ -height 1i \ -width 5i pack $page1.filler3 \ -fill x iwidgets::entryfield $page1.author \ -labeltext "Author:" \ -labelpos nw \ -width 40 pack $page1.author iwidgets::entryfield $page1.author_email \ -labeltext "Author E-mail:" \ -labelpos nw \ -width 40 pack $page1.author_email frame $page1.filler4 \ -background "" \ -height 1i \ -width 5i pack $page1.filler4 \ -fill x # create more pages # ---------------------------------------------------------------------- set page2 [.tnb add -label "Compile Options"] iwidgets::disjointlistbox $page2.dlb pack $page2.dlb -padx 10 -pady 10 -fill both -expand yes $page2.dlb insertlhs {{1. DOS} {2. WINDOWS} {3. LINUX} {4. OSX} {5. SOLARIS} {6. IA32} {7. IA64} {8. M68X} {9. SPARC}} set page3 [.tnb add -label "Unit .inc Files"] # Unit Constants Page #4 # ---------------------------------------------------------------------- set page4 [.tnb add -label "Unit Constants"] iwidgets::scrolledtext $page4.scr_text \ -hscrollmode dynamic \ -vscrollmode dynamic pack $page4.scr_text \ -expand yes \ -fill both # Unit Types Page #5 # ---------------------------------------------------------------------- set page5 [.tnb add -label "Unit Types"] .tnb view "Cover Page" # End ---------------------------------------------------------------

1 1

20 month snapshot diffs
by James A. Morrison 02 Mar '05

02 Mar '05

Hi, I've posted[1] a diff between December's snapshot and February's snapshot. However, the diff 850K, that seems really large for only 4 changelog entries. Is that the size of the usual diff between patches? -- Thanks, Jim http://phython.blogspot.com [1] http://www.csclub.uwaterloo.ca/~ja2morri/gpc-20041218-20050217.diff.gz

3 4

Pascal front-end integration
by James A. Morrison 02 Mar '05

02 Mar '05

Hi, I've decided I'm going to try to take the time and cleanup and update the Pascal frontend for gcc and try it get it integrated into the upstream source. I'm doing this because I wouldn't like to see GPC work with GCC 4+. I don't care at all at supporting GPC on anything less than GCC 4.1 so I've started by ripping out as much obviously compatibility code as I can and removing any traces of GPC being a separate project. So far I have only accomplished converting lang-options.h to lang.opt. I'm going to continue cleaning up the GPC code, then once I am happy with how the code looks with respect to the rest of the GCC code, I'm going to get it to compile with the current version of GCC mainline. I'm starting with the boring conflict happy whitespace changes first so the code is easier for me to read and so that I can try to get an idea what the GPC frontend is doing. My current changes are available through bazaar (an arch implementation) which people can get with: baz register-archive http://www.csclub.uwaterloo.ca/~ja2morri/arch baz get phython(a)gcc.gnu.org--pascal/gcc-pascal--mainline--0.3 Once I get the front-end to compile I'll look into creating a branch on gcc.gnu.org, but until that point it really isn't worth while. Patches are welcome, but please have your copyright assignment filed with the FSF and add a changelog entry to ChangeLog.gcc. I don't have any timeline for this work. -- Thanks, Jim http://phython.blogspot.com

3 2

Internal compiler errors
by Adriaan van Os 01 Mar '05

01 Mar '05

An Internal compiler error has been reported on the macpascal mailing list, as reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo10.pas program avo10; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( [bold, italic]); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo10.pas ../../gcc-3.4.3/gcc/p/typecheck.c:123:incomplete_type_error: failed assertion `0' avo10.pas: In main program: avo10.pas:8: error: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc343d7/lib/gcc/powerpc-apple-darwin7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 Thread model: posix gpc version 20050217, based on gcc-3.4.3 Adding a typecast triggers another error: G5:gcc/p/test] adriaan% cat avo11.pas program avo11; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( StyleParameter( [bold, italic])); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo11.pas avo11.pas: In main program: avo11.pas:8: warning: cast to type of different size avo11.pas:8: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. with backtrace: Command: gpc1 Path: /Developer/Pascal/gpc343d7/libexec/gcc/powerpc-apple-darwin7/3.4.3/gpc1 Version: ??? (???) PID: 1333 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000038 Thread 0 Crashed: 0 gpc1 0x000c66d4 get_set_constructor_bits + 0x34 (tree.c:4654) 1 gpc1 0x000c693c get_set_constructor_bytes + 0x4c (tree.c:4730) 2 gpc1 0x000e4204 const_hash_1 + 0x3b4 (varasm.c:2130) 3 gpc1 0x002f773c htab_find_slot + 0x2c (hashtab.c:560) 4 gpc1 0x000e34c8 output_constant_def + 0x38 (varasm.c:2496) 5 gpc1 0x0007d6b0 expand_expr_real + 0x3c88 (expr.c:6910) 6 gpc1 0x0007d54c expand_expr_real + 0x3b24 (expr.c:8863) 7 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 8 gpc1 0x0007a620 expand_expr_real + 0xbf8 (expr.c:6952) 9 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 10 gpc1 0x00196ac8 expand_call + 0x2760 (calls.c:793) 11 gpc1 0x0007b6a0 expand_expr_real + 0x1c78 (expr.c:7595) 12 gpc1 0x000c9ff4 expand_expr_stmt_value + 0xe0 (stmt.c:2171) 13 gpc1 0x00007e5c yyuserAction + 0x4cd8 (parse.c:4691) 14 gpc1 0x000114cc main_yyparse + 0x738 (parse.c:8136) 15 gpc1 0x000be2ec toplev_main + 0x7b8 (toplev.c:1826) 16 gpc1 0x00001ed8 _start + 0x188 (crt.c:267) 17 dyld 0x8fe1a558 _dyld_start + 0x64 Regards, Adriaan van Os

4 8

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