Gpc December 2004

gpc@gnu.de

27 participants
37 discussions

automatic CRTInit
by Francesco Bonomi 31 Dec '04

31 Dec '04

Dear all, My question is :how can I disable or delay the automatic CRTInit? What I need to do is write a program that (according to situations) writes binary data to output or open an interface (requiring CRT) The problem is that my binary data gets "filtered" somehow, and some bytes are replaced. I imagine this is because of ncurses, and reading the docs I found out that: > If you terminate the program before calling CRTInit or any routine > that causes automatic initialization, curses will never be > initialized, so e.g., the screen won't be cleared. But in effects, even without using any CRT routine, just including the crt in the uses clause will initialize ncurses. I have minimized this problem to a small program that uses the ANSI "reverse video" escape sequence Esc-[7m (I use an ansi sequence just because it's easily visible, the problem is the same with any other non-printable character). unit beforecrt; interface implementation begin write(chr(27),'[7m','BEFORE'); readln; end. program chr; uses beforecrt, crt; begin write(chr(27),'[7m','AFTER'); end. This is what happens: 1) without any clear screen, I see BEFORE in reverse 2) I press Enter 3) The screen is cleared, and "<[7m AFTER" is printed (in normal mode) The unit beforecrt is initialized before crt, so it's output is correct. The output from the main program (that gets executed after the initialization of crt) is filtered. Somehow, CRTInit is happening even if I do not use any routine of crt. How can I avoid this? Alternatively, how can I disable the ncurses at all? I have tried to use CRTSetTerminal('dumb', input, output); without any result. thanks Francesco (using gps 20040516)

2 1

gpc-20041218 released
by Frank Heckenbach 23 Dec '04

23 Dec '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de>! The main changes are fixes for 64 bit platforms that were partly broken with 20041017 (some tests still fail on these platforms, but these are mostly problems with the tests themselves), and slightly improved compatibility to Mac Pascal dialects. In detail, new features: - `Exit' with an argument (non-local exits not yet supported) (fjf988*.pas) (U) - new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M) - enable `Pointer' in `--mac-pascal' mode (Mac Pascal has a `Pointer' function which does the same as a type-cast to `Pointer'; though adding `Pointer' as a type allows more, it's backward-compatible) (M) - `&' and `|' (shortcut `and' and `or') (fjf981*.pas) (M) - `Leave' and `Cycle' (equivalent to `Break' and `Continue') (avo3.pas) (M) - optimize `WriteLn (... string_constant') and `Write (... string_constant, string_constant ...)' - `BindingType' is now a packed record as EP demands (fjf975a.pas) (E) Fixed bugs: - accessing components of a constant (EP) constructor (indexed by a constant for arrays) must yield a constant again (dave3*.pas) - GPC crashes when using two variables with identically-named fields in a single `with' statement (withbug.pas) - GPC doesn't accept `case' statements without case-list-elements (fjf982*.pas) - gcc-3.x: options are wrongly reordered (so, e.g., `--gnu-pascal -Wno-underscore' doesn't work as expected) (avo7.pas) - applying `not' to a function result in parentheses doesn't work (avo6.pas) - packed array indices containing `mod' don't work (avo4.pas) - GPC sometimes prints `???' instead of the actual file name in messages - function results (of record type) must not be allowed as `with' elements (only a warning in `--delphi' and `--mac-pascal' modes for compatibility); fields of non-lvalue `with' elements must not be lvalues either (fjf493*.pas) - value parameters of type `String' (undiscriminated) must take the capacity of the actual parameter, according to EP (waldek11*.pas) - initialized types in arrays (fjf233.pas, fjf974*.pas) - initializers are ignored in `New' and `Initialize' (fjf967[j-l].pas) - the address of global routines is not allowed in initializers (avo2*.pas) 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 NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

7 20

Software patents, please close your pages
by Eike Lange 22 Dec '04

22 Dec '04

Hi! It would be nice, if you could close your private site like this one http://www.ffii.org/ or this one http://www.gnu-pascal.de/ We are, again, demonstrating against software patents in the european union. Eike -- --**-- Webseite gesperrt --**-- http://www.gnushi.de/index.html

3 2

GCC integration?
by E. Weddington 22 Dec '04

22 Dec '04

Hello, I couldn't find the answer anywhere on the website, FAQ, or mailing list archives: Why isn't GNU Pascal integrated with the rest of GCC? and the related question: What would it take to integrate GNU Pascal with the rest of GCC? Thanks for your time. Eric

11 30

CInteger and --delphi
by Adam Naumowicz 21 Dec '04

21 Dec '04

Hello, I've tried to compile the following code with --delphi option toggled on, but the compiler reported tester.pas:17: error: reference expected, value given program tester; uses gpc; procedure CatchSignal(aSig : Integer); begin case aSig of 2, 3, 15 : {SigInt, SigQuit, SigTerm} begin end; end; end; var OldSigInt : TSignalHandler; r,dummy:boolean; begin r:=InstallSignalHandler(SigInt,CatchSignal,true,false,OldSigInt,dummy); end. Then I checked the declaration of InstallSignalHandler and tried the same with aSig's type changed to CInteger. It compiled fine, except when the --delphi switch was on, because then CInteger seemed to be unknown ;-( Do you have any suggestions how to fix this problem? Any help appreciated. I used the freshly uploaded beta gpc version 20041218, based on gcc-3.3.3. Best, Adam Naumowicz ====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail: adamn(a)mizar.org Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================

4 5

Re: GCC integration?
by Frank Heckenbach 19 Dec '04

19 Dec '04

Steven Bosscher <stevenb(a)suse.de> wrote in private mail: > Since I'm not allowed to post to the gpc list, I'll just mail you > in private. Feel free to forward this. These are just my personal > ideas on the matter, so don't attach to much value to them ;-) Thanks, I'm forwarding it with my reply. (Only subscribed members are allowed to post, unfortunately, but it's necessary for spam protection.) > You wrote: > > If you ask me when this will be, I don't know. And I should point > > out that I'm a supporter of "release when it's ready", instead of > > setting fixed release dates. > > So does GCC. All the release managers of old release branches do is > set target dates. More often than not, the release is not ready by > then and so it is postponed. > > > > The latter IMHO smells too much like > > certain proprietary companies, > > Oh, no, not proprietary! :-) > > To me it just sounds like decent engineering practice to set targets > and deadlines. Otherwise there would *never* be a stable GCC. Even > now, when GCC is in stage3, the number of files changed from day to > day is simply frightening. At some point you have to say, stop, let > us first fix bugs and get this out of the door, *then* we can start > hacking like mad on our toy projects again. > > > > and usually leads to the same results > > -- such as last year when a fatal bug which was clearly identified > > (and a fix provided) was intentionally left unfixed in a GCC release > > (3.2.2 AFAIR) because of the fixed release schedule. > > I don't recall such a bug. It very much does *not* sound like GCC > practice to release a compiler with a known show-stopper bug. I was also very surprised to see such behaviour in such a high-profile free software project, but that's what happened. If you want to read it yourself: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9279 In short, I discovered a bug on sparc-linux (later it was found that it also affected other platforms). I noticed it in the form of GPC misbehaving. It took me several hours to track it down through a C library function (fwrite) via some complex macros in the libc headers to a GCC code generation bug which I could demonstrate in a short, reproducible example. Someone provided a fix, but this fix was intentionally rejected because of the fixed release deadline. (The actual bug was in the backend, and it showed in the C compiler when compiling GPC; no GPC issues involved in the actual bug, just to avoid misunderstandings.) In my view, the following comment (http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg01529.html) says it all (emphasis added by me): : > The fix introduces a performance regression for PowerPC (and possibly ^^^^^^^^^^^^^^^^^^^^^^ : > other platforms) on the 3.2 branch. : : Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with ^^^^^^^^^^^^^^^^^^^^^^^^ : the bug. A performance regression more important than a fatal bug, hear hear! Gabriel Dos Reis later added that the patch might cause "possibly a wrong code generation" which Eric Botcazou questioned. I don't know if it did, but even if so, that's no excuse for shipping a fatal bug. I don't know if that other wrong code generation (if it existed) was also fatal -- if not, I'd rather accept that than a known fatal bug; if so, the only reasonable thing to do IMHO would have been to delay the release until the fatal bugs are fixed. But as the following quote says: : I would like to avoid last time minute patch chasing. So clearly release dates are more important than correctness. (Otherwise there would be no required "last minute", obviously.) BTW, of course, one can always argue which bugs are fatal. But since this bug (a) affects fwrite(), a standard and very common I/O function, and (b) produces silently wrong results, the worst possible failure mode, I fail to see how it could not be considered fatal. (Only a security bug would be worse, and I'm not even sure one couldn't construct one with this bug -- I/O routines give plenty of opportunities.) > > So that's one > > reason why I have some aversions against integration, if those > > schedules will also dictate our releases. > > They would, gpc would stop existing as a separate compiler as far as > GCC is concerned, so it would be released along with the rest of GCC. > Having said that, you'd have the advantages of "being part of GCC" > such as having your compiler modified when something changes in GCC > that requires front end modifications. A reduced maintenance burden, > so to speak (that sounds proprietary too I guess, but that's life). No, I do see this as an advantage. I'm just weighing it against the disadvantages that I also see ... > If you are so opposed to integration, you should say that on gcc@ and > explain your problems. Making such statements in a list that almost > nobody in the "mainstream" gcc community reads is not going to help > anyone. > > I know I'd like to see gpc be integrated in GCC, but only as "just a > new front end". From my perspective, it's strange that you want to > do releases on your own schedule. Why not spend time on making gpc > better, and let others worry about getting it out? I think GCC as a > project has a pretty decent track record for getting things released > with a high quality. To add some background, I'm not only working on GPC just for fun. I'm also using it for professional work, and as such I'm dependent on having usable versions available. (And by that, I currently mean the betas I release -- my own development code is most of the time not suitable to be used out in the wild.) Another point to note is that in GPC much work is done in visible front-end changes (new syntax etc.), probably more than in many other frontends. And I usually want to use the new features in my own code (otherwise I wouldn't have to spend my time implementing them). So using older releases of GPC is usually not an option for me, unlike say for the C compiler (where, for my purposes, I hardly notice a difference WRT features even between 2.x and 3.x). So let's consider a situation such as after the release of gcc-3.2.2. Let's assume there were some new frontend features I wanted to use. (I could look up which ones exactly those might have been at that time, but it's a safe bet there were some.) So, what should I have done, if GPC would have been integrated and the current GPC release at the time were tied to gcc-3.2.2: - Rewrite my code to avoid all new features (and later rewrite it back) -- inacceptable (too much work) - Let the customer wait for months for the next release which *hopefully* will fix the bug -- obviously inacceptable - Tell them to get another machine or OS if the bug is platform dependent such as here -- usually not an option - Tell them to get a CVS snapshot -- bad idea: unusual for most people and probably difficult to build for them, conveying strange ideas about free software etc.; it's a game of luck (as you write below, it's likely that the backend would not be as stable), and a support nightmare (if something goes wrong, and I have a slightly different version) - Take a CVS snapshot of my own, make sure it's stable (which in this case might mean, take the release and add this particular bugfix) and release that on my own. So, AFAICS, I'm bound to the last option, and I'm seriously considering it for the time after an eventual integration. (E.g., by keeping the current website, and placing releases there according to my own schedule and preferences.) If we're lucky, all official GCC releases will be stable and there will be no need for anything else, but I don't think I'd like to take the risk. > > (BTW, would this be so, or > > could we also make releases independent of GCC schedules, e.g. when > > we think it's stable rather than on a fixed date?) > > You could do that but probably the backend you'd make your release > against would not yet be stable. You could do it for release branches > of course. But as I said, I don't understand why you'd want that. See above. Of course, the GPC frontend changes will probably slow done sometime when all important features have been added (or so ;-), and then the version dependencies will not be as severe anymore. But this will probably be many years from now, much later than even my ideas of integration ... > > Automake: To be replaced by gp. (gp: Mostly working, some smaller > > known problems, some less-important to-dos.) Again, I'd like to > > keep automake present, but deprecated in one more major release > > for the same reasons as above. > > If you'd integrate with GCC, you would not need automake for the front > end sec, but for the runtime libraries, all GCC libraries use automake. > Not everyone is happy with that (automake and libtool are brain damage > in the view of many, including yours truly) but then, the alternatives > for keeping the build system portable are not very attractive either. Misunderstanding. GPC currently has a mechanism also called "automake". This is a kludge (and has always been) which, in various ways, conflicts with GCC's usual behaviour. It will be removed and replaced by a utility called "gp" (of which the first betas have been released, and it's almost ready to take over). As for automake and libtool, and partly also autoconf, I might subscribe to the view you stated. But I'm not too concerned about it. The RTS currently relies on autoconf-2.12. Someday it will have to be adjusted to a newer version, or something different, and probably libtool has to be added (if it must ;-). But these things are rather peripheral to most of our code (e.g., the RTS only contains one C file anymore which uses the autoconf macros; everything else is written in Pascal and doesn't use them directly). So while I expect some nuisances with those tools in the future, I don't expect serious problems here. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

2 1

Re: Re: GCC integration?
by Thorsten Glaser 19 Dec '04

19 Dec '04

Matt Austern dixit: > I suppose it's time to ask: *should* Pascal integration be a goal for 4.1? What about the goal being: Pascal should at least compile and work for simple programmes for 4.1 and be "delivered with", but not built by default, and full integration being the goal for 4.2 (if it's made in time for 4.1, even better)? In my experience, lower goals tend to be more easily achieved. I'll shut up from now and leave it to the GPC maintainers to express what they want (I think Frank has already said that). //mirabile

2 1

gpc and gcc-3.3.5
by Prof A Olowofoyeku (The African Chief) 18 Dec '04

18 Dec '04

Hi I have built gpc-20041017 based on gcc-3.3.5 (for Mingw). It seems to be alright. It passes the testsuite, except for these: "TEST piextn.pas: OK TEST pipetes2.pas: ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed TEST pipetest.pas: ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed" The same tests are failed under Mingw, regardless of the underlying gcc version. Any ideas? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 4

Re: Re: GCC integration?
by E. Weddington 17 Dec '04

17 Dec '04

Steven Bosscher wrote: >On Friday 17 December 2004 20:31, Nathanael Nerode wrote: > > >>* Pascal integration as a release goal for GCC 4.1 >> >> > >You forget that it is not clear if the gpc people actually >want this. I don't see the GNU Pascal maintainers in this >discussion. > > > Since I started this whole thread off in the GPC list... What I don't fully understand is (and anybody correct me if I'm wrong): 1. From what I can tell, it looks like that GPC is a part of the GNU project. <http://gnu-pascal.de/gpc/h-gnu.html> 2. So is GCC (obvious). 3. At one point, there was an item under the "GNU Help Wanted" list on Savannah: <http://savannah.gnu.org/people/?group=tasklist>, that asked for new languages for GCC. Unfortunately, I don't see this item there now. So why isn't GPC integrated? If the FSF has the copyright for the Pascal front-end, why can't anybody just take the available patches and start moving them over and getting them worked up? Eric

1 0

GPC: Is it currently being developed
by Jon Foster 17 Dec '04

17 Dec '04

Hi guys! I recently became aware of your project. Is GPC currently being developed? The last "stable" release was two years ago. Are Delphi classes and exceptions going to become a reality anytime soon? I wouldn't mind working with some pre-stable code if they are. If they aren't what are the GPC alternatives? THX - Jon -- Jon Foster JF Possibilites, LLC jon(a)jfpossibilities.com 541-410-2760 Making computers work for you!

3 2

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 December 2004