Gpc March 2005

gpc@gnu.de

32 participants
67 discussions

Who uses Pascal.
by Anonymous 31 Mar '05

31 Mar '05

Pascal numbers _are_ dwindeling. Very slowly but surely. It reminds me a bit of Apple before Mac OS X. Not many desert, but the ones that do are not replaced. I agree with Tom that there is still quite some use in the Brazil and Eastern Europe countries. They count for quite a lot of the download counters (FPC Bloodshed Pascal downloads are in the 6 figures) In the professional world, Delphi is still quite strong, mainly in NW Europe (the heartland seems to be Benelux+Germany+Scandinavia) However any group without a influx of new persons is bound to die, even though that can take another 5-10 years. Another problem I have with the push to so called industry languages is not so much the change of language, but also e.g. IDE. I've seen students wrestle with overly complex Java GUI IDEs and frameworks (SWING) that are slow and slightly instable. Most students don't get it, and simply go with the flow, copy assignments etc. They never actually get the bigger picture, and were fighting to master the IDE and the designer most of the class. (Tom: this was in the institution just on the other side of the road from your perspective). So the problem is not that (only) that the language is changed, but that other standards of educational usability slip too. Most notably simplicity and stability, all because of industry standard use that the students don't get any real benefit from in the first place.

1 0

C types.
by Anonymous 31 Mar '05

31 Mar '05

Frank said: >For interfacing to C in GPC use the C compatible types (see manual). >For fixed size types use `Integer attribute (Size = 32)' or >`Cardinal attribute (Size = 32)' etc. I don't know what FPC has. FPC 1.9.x+ has in the "ctypes" unit all C types prefixed with "c". So clong, culong, cuint32 etc. Not all existing headers are converted to this already. Most older header conversions were submitted by users, so they use all kinds of conventions. Some dedicated users are slowly "ctypes"ifying them.

1 0

Posting via web
by Anonymous 31 Mar '05

31 Mar '05

Recently some people wanted to post to this mailing list, but didn't want to sub-scribe. Since this list allows posts only from subscribers, this was a problem. Therefore, I've now set up an experimental web posting facility. It is available under "Mailing list archives" on the web site. One can send a new mail from the main archive page, or reply to mails in the archive. If this service starts to be abused by spammers, we might have to stop it. Let's hope this doesn't happen so soon. 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 GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Testsuite results on MirOS #8-beta / 3.4.4-20050325 / gpc-20050217
by Thorsten Glaser 30 Mar '05

30 Mar '05

Hi, this time it looks a bit better (though -ftrampolines is now required for generating them, and you broke GNAT with the version_string changes). I've kept closer to original sources while integrating, because this time, I can use GNU Make for building the stuff. Test Run By tg on 2005-03-29 00:07:02 Native configuration is i386-ecce-mirbsd8 (odem.66h.42h.de) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: crttest.pas FAIL: filehand.pas UNSUPPORTED: fjf165a.pas FAIL: fjf684.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: formattimetest.pas UNSUPPORTED: gmptest.pas FAIL: gpc_c_p.pas FAIL: gpctest.pas FAIL: gpcu_c_u.pas UNSUPPORTED: longr2.pas FAIL: random.pas === gpc Summary === # of tests 4537 # of expected passes 4520 # of unexpected failures 10 # of unsupported tests 7 gpc version 20050217, based on gcc-3.4.4 (propolice; MirOS 0825) TEST filehand.pas: ./filehand.pas: In main program: ./filehand.pas:11: error: statement used as an expression failed TEST fjf684.pas: ./fjf684.pas: In main program: ./fjf684.pas:12: error: invalid operands to =' failed TEST fjf751k.pas: ./fjf751k.pas: In main program: ./fjf751k.pas:8: error: argument to riteLn' is of wrong type failed TEST fjf751l.pas: ./fjf751l.pas: In main program: ./fjf751l.pas:8: error: argument to riteLn' is of wrong type failed TEST fjf800.pas: ./fjf800.pas:65: error: redeclaration of jf800' ./fjf800.pas:1: error: previous declaration ./fjf800.pas:65: error: redeclaration of jf800' ./fjf800.pas:1: error: previous declaration failed TEST formattimetest.pas: failed: could not compile strftime() test program TEST gpc_c_p.pas: gpc_c_c.c:2:22: gpc-in-c.h: No such file or directory gpc_c_c.c: In function ain': gpc_c_c.c:27: warning: implicit declaration of function p_initialize' gpc_c_c.c:31: warning: implicit declaration of function nit_pascal_main_program' gpc_c_c.c:53: warning: implicit declaration of function p_finalize' gpc1: gpc exited with status 1 failed TEST gpctest.pas: 86400 0 943841988 True True 1999 1999 11 11 29 29 1 1 2 2 19 19 26 48 0 0 Error in UnixTimeToTimeStamp TEST gpcu_c_u.pas: gpcu_c_c.c:2:22: gpc-in-c.h: No such file or directory gpcu_c_c.c: In function ain': gpcu_c_c.c:26: warning: implicit declaration of function p_initialize' gpcu_c_c.c:45: warning: implicit declaration of function p_finalize' gpc1: gpc exited with status 1 gpc: gpcu_c_c.o: No such file or directory failed TEST random.pas: ./random.pas: In main program: ./random.pas:22: error: invalid operands to *' ./random.pas:22: error: invalid operands to *' failed ------------------------------------------------------------ Some reasoning: strftime.cmp | if gcc dummy.c > /dev/null 2>&1 && [ -r "$A_OUT" ]; then What if gcc is not /usr/bin/gcc? Use $(CC) instead. After fixing that and rts-config.inc (which didn't get that I have got strftime() due to a mismatching prototype and -Werror): TEST formattimetest.pas: OK I'll fix that (the second issue) in the build process, then. After moving gpc-in-c.h to /usr/include, I get: TEST gpc_c_p.pas: OK TEST gpcu_c_u.pas: OK As for the gpctest.pas failure, I suspect that, somewhere, the system doesn't realise that time_t == int64_t even on 32 bit machines on MirOS/i386 (not for MirOS/sparc). That leaves me with 6 failures, which is kind of good, I guess. bye, //mirabile -- > [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der > richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt. Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...] weil selbst einfachste Operationen *echt* *Zeit* brauchen. (aus d.a.s.r)

2 1

Compile with gcc 3.3 CVS and new tools
by James A. Morrison 29 Mar '05

29 Mar '05

Hi, I needed the attached patch to compile gpc with gcc 3.3 cvs. I am using flex 2.5.31 and I copied gcc-3.3.5.diff to gcc-3.3.6.diff. I don't know what happened to set_word_size and set_words_big_endian from gcc 3.3.5 to cvs. Having gpc-lex.c define malloc and realloc instead of yyalloc and yyrealloc allows gpc to link against libiberty which defines xmalloc and xrealloc. -- Thanks, Jim http://phython.blogspot.com

2 4

GPC and GNU plotutils - problem
by Prof A Olowofoyeku (The African Chief) 25 Mar '05

25 Mar '05

Hi I have produced a GPC interface unit for GNU plotutils (courtesy of the "headconv" program). However, there is a problem. Trying to compile a test program gives this error: "d:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/libgpc.a(init.o): In function `p_initialize': d:/src/mingw/gcc-3.2.3/gcc/p/rts/init.pas:266: multiple definition of `_p_initialize' d:/mingw/lib/libplot.a(p_defplot.o):p_defplot.c:(.text+0x0): first defined here" "p_defplot.c" has this: void #ifdef _HAVE_PROTOS _p_initialize (S___(Plotter *_plotter)) #else _p_initialize (S___(_plotter)) S___(Plotter *_plotter;) #endif Any ideas? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

5 24

Re: GPC and GNU plotutils - problem
by Prof A Olowofoyeku (The African Chief) 24 Mar '05

24 Mar '05

On 22 Mar 2005 at 22:28, Frank Heckenbach wrote: [...] > Of course, you could also convert the octal to (hexa)decimal > numbers. [...] Can we have a series of conversion routines (perhaps in gpcutil.pas)? octal2hex hex2octal int2octal octal2int Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

3 4

installation trouble
by Toby Ewing 23 Mar '05

23 Mar '05

Hi, I wrote earlier and got no response. Now I'm trying again. I installed gpc on a new machine with redhat 9. I can compile and run easy demo programs. But any program the has C-code in it, or uses a unit with C-code, gets rejected. Under gp, the message is gp: Pascal and C compilers specified seem to be for different platforms gp: ('i686-pc-linux-gnu' and 'i386-redhat-linux') Using gpc directly, I can compile the unit crt.pas, but when I try to compile a program that uses it, I get a message saying that crt.gpi needs to be recompiled. Recompiling crt.gpi does not change anything. What do I need to do to get some version of gpc working on this system? thanks, Toby

5 7

Pointer and object checks
by Frank Heckenbach 20 Mar '05

20 Mar '05

I'm considering adding runtime checks for nil pointer access. The benefits are not as big as one might suppose, since most systems catch a nil pointer access anyway and give a segmentation fault automatically. Whereas explicit runtime checks might add considerable runtime overhead. Additionally, some valid (well, let's at least say, working) BP and similar programs might fail then, e.g. if they pass dereferenced pointers (which may be nil) as var parameters, and the called routine either doesn't access the parameter or explicitly checks if it's address is nil. On the positive side, such a check might provide a somewhat nicer error message (proper runtime error instead of segfault), and it can be caught like other runtime errors (e.g. via `AtExit') rather than with a signal handler as for segfaults. Also, strict standard conformance makes it an error, even in a situation as described above where the var parameter is never used. Therefore, perhaps, the check should be off by default, and on only in standard modes, and of course, triggered by its own new option (`--[no-]pointer-checking'?). Another runtime check (which BTW should also be rather easy to implement now), is for objects, whether they point to a valid VMT, using the `NegatedSize' VMT field, just like BP does. AFAIR, BP does it on virtual method calls, where the VMT is used. In principle, the check could be done on every object operation/access, but that might be overkill. Since a simple check per virtual method call is not much overhead, I propose the check to be on by default, in all dialects. Of course, it will also get its own option (`--[no-]object-checking'?). BP couples it to range-checking (I can only guess why -- perhaps because they only have short, i.e. one-letter, compiler directives, and they wanted to save a letter). For strict compatibility, we could add a combined option (`--[no-]range-and-object-checking'), and make `{$R[+-]}' equivalent to that. 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 GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 13

assert -> gcc_assert
by James A. Morrison 20 Mar '05

20 Mar '05

Hi, GCC 4.0.0 and up use gcc_assert and gcc_unreachable for assertions and unreachable code. This patch updates gpc's assert to be gcc_assert and gcc_unreachable and have the same sematics as the upstream assertion functions. This along with the other patch was built and tested against gcc 3.3 cvs on ia64-linux. -- Thanks, Jim http://phython.blogspot.com

2 2

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