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
E. Weddington wrote:
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?
This is a frequently asked question. Googling for `GNU Pascal GCC integration' gave me a few relevant hits. I think that:
http://gcc.gnu.org/ml/gcc/1999-05n/msg00358.html
still holds (just change a few names). There are __much__ more such messages both on GCC and GPC mailing lists.
and the related question: What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
Waldek Hebisch wrote:
E. Weddington wrote:
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?
This is a frequently asked question.
Then how come it isn't in the GPC FAQ?..... Where one would obviously look...
Googling for `GNU Pascal GCC integration' gave me a few relevant hits. I think that:
Thanks for the link!
still holds (just change a few names). There are __much__ more such messages both on GCC and GPC mailing lists.
It's sad that reasons that were valid back in 1999 are still valid 5 years later.....
and the related question: What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
Unless the listing of team members here http://www.gnu-pascal.de/gpc/h-team.html is wildly inaccurate, how many other developers and testers do you need?
Thanks Eric
E. Weddington wrote:
Waldek Hebisch wrote:
E. Weddington wrote:
<snip>
and the related question: What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
Unless the listing of team members here http://www.gnu-pascal.de/gpc/h-team.html is wildly inaccurate, how many other developers and testers do you need?
The web page may be slightly misleading: do not think that 21 persons is constantly working on GPC. AFAIK all contributors to GPC do their work in addition to another (regular) occupation. And many of the contirbutors no longer work on GPC.
It is tricky to estimate development effort, but my guesstimate is 2-3 _full_ time developers plus 10 testers should be enough to develop GPC as part of GCC.
To have a comparison: I have not metered time spent hacking GPC, but in the last year it is probably equivalent to 2-3 months.
Waldek Hebisch wrote:
E. Weddington wrote:
Waldek Hebisch wrote:
E. Weddington wrote:
<snip>
and the related question: What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
Unless the listing of team members here http://www.gnu-pascal.de/gpc/h-team.html is wildly inaccurate, how many other developers and testers do you need?
The web page may be slightly misleading: do not think that 21 persons is constantly working on GPC. AFAIK all contributors to GPC do their work in addition to another (regular) occupation. And many of the contirbutors no longer work on GPC.
I understand.
It is tricky to estimate development effort, but my guesstimate is 2-3 _full_ time developers plus 10 testers should be enough to develop GPC as part of GCC.
To have a comparison: I have not metered time spent hacking GPC, but in the last year it is probably equivalent to 2-3 months.
Thanks for the estimate! And thanks for your time.
Eric
Waldek Hebisch wrote:
What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
Gerrit
Gerrit P. Haase wrote:
Waldek Hebisch wrote:
What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
I've heard this claim, but I see no evidence. Getting the source code by HTTP is no more complicated than by CVS (in fact, it's much easier for most of us, myself included, even if it may take a second longer because a few more files are included).
Building from a proper distribution is much easier than from CVS sources (my experience with other CVS packages is abysmal -- it took me over a year until I managed to build a CVS Bison at all, and I had tried it on several different systems, including a current Debian system).
Getting patches to a slightly older (alpha/beta) version is *really not* a big deal. I can handle some changed contexts, renamed identifiers etc.
Frank
Frank Heckenbach wrote:
Gerrit P. Haase wrote:
Waldek Hebisch wrote:
What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
I've heard this claim, but I see no evidence. Getting the source
Have you tried it? Source managed by CVS is 'standard' and most OS developers are used to use it.
code by HTTP is no more complicated than by CVS (in fact, it's much easier for most of us, myself included, even if it may take a second longer because a few more files are included).
May be easier for people who are not familiar with CVS, but simply retrieving is not the problem. You could release snapshots whenever you like to do so as it is now, no problem. It is an additional service to keep the reference source in a public repository instead of having the reference at your harddisk where I have no access.
Additionally you could use the facilities at sourceware.org to distribute snapshots, releases and the website & mailinglist.
If you don't like being part of GCC and having things hosted at sourceware.org, there are other possibilities, get an account at sourceforge or savannah?
Building from a proper distribution is much easier than from CVS sources (my experience with other CVS packages is abysmal -- it took me over a year until I managed to build a CVS Bison at all, and I had tried it on several different systems, including a current Debian system).
I don't speak of releases or snapshots and how to distrbute these, I'm talking of services for developers (mailinglists, bugtracking sytem, feature request system, source repository), all these things are needed if you need to manage more than ten developers.
Getting patches to a slightly older (alpha/beta) version is *really not* a big deal. I can handle some changed contexts, renamed identifiers etc.
Not a big deal for you. But a big deal for me. I need to ask *you* because I cannot ask CVS.
Gerrit
Gerrit P. Haase wrote:
I don't speak of releases or snapshots and how to distrbute these, I'm talking of services for developers (mailinglists, bugtracking sytem, feature request system, source repository), all these things are needed if you need to manage more than ten developers.
So - where are these ten developers, working daily on the gpc source code ? This is hypothetical. You are talking about the wrong problem,
Regards,
Adriaan van Os
Adriaan van Os wrote:
Gerrit P. Haase wrote:
I don't speak of releases or snapshots and how to distrbute these, I'm talking of services for developers (mailinglists, bugtracking sytem, feature request system, source repository), all these things are needed if you need to manage more than ten developers.
So - where are these ten developers, working daily on the gpc source code ? This is hypothetical. You are talking about the wrong problem,
I don't include GPC with the Cygwin GCC distribution currently because: - no according MinGW version available because GPC is no regular part of the GCC. - too much work to do, everytime I do a release it is difficult enough to get it out anyway, no time to integrate another backend. - GPC with 3.4.x seems to be broken or at least not supported.
I don't report bugs because I don't build GPC on a regular basis and so I count not as a developer / tester / user, whatever you want. But you would count me if I were building GPC on a regular basis and if I would be reporting errors / bugs / problems when building / using it or running the testsuite.
Since it is too much hassle to integrate an extern frontend into GCC or it is entirely impossible since the needed MinGW port is not available you have lost me as developer / tester / user.
I have done this before and there is still a GCC with Pascal frontend part of the Cygwin GCC distribution, however I don't see that it will happen with 3.4.x.
Gerrit
On 28 Nov 2004 at 18:02, Gerrit P. Haase wrote:
[...]
I don't include GPC with the Cygwin GCC distribution currently because:
- no according MinGW version available because GPC is no regular part of the GCC.
I am not sure what this means. As the person responsible for the Mingw GPC binaries, I need to understand what you mean. Can you please explain? Thx.
- too much work to do, everytime I do a release it is difficult enough to get it out anyway, no time to integrate another backend.
I stay with the last fully supported backend (i.e., gcc-3.2.3). After all, what I need is a working Pascal compiler. The fact that the backend is an old gcc release is neither here nor there.
- GPC with 3.4.x seems to be broken or at least not supported.
See above ...
I don't report bugs because I don't build GPC on a regular basis and so I count not as a developer / tester / user, whatever you want. But you would count me if I were building GPC on a regular basis and if I would be reporting errors / bugs / problems when building / using it or running the testsuite.
Well, if you have given up the Cygwin binaries, then I will take them up again. I stopped because you had taken them up.
Since it is too much hassle to integrate an extern frontend into GCC or it is entirely impossible since the needed MinGW port is not available you have lost me as developer / tester / user.
I still have no idea what you mean by saying that the Mingw port is not available. Mingw binaries are available, up till the latest snapshot. I believe that I announce the release of Mingw binaries here.
I have done this before and there is still a GCC with Pascal frontend part of the Cygwin GCC distribution, however I don't see that it will happen with 3.4.x.
The best option is to stick with a backend version that you know works perfectly well. Under Windows, this is gcc-3.2.3. This is only until gpc becomes integrated into gcc (whenever that happens). Until then, there is absolutely no harm staying with gcc-3.2.3.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 28 Nov 2004 at 18:02, Gerrit P. Haase wrote:
[...]
I don't include GPC with the Cygwin GCC distribution currently because:
- no according MinGW version available because GPC is no regular part of the GCC.
I am not sure what this means. As the person responsible for the Mingw GPC binaries, I need to understand what you mean. Can you please explain? Thx.
I have now gcc here: /usr/lib/gcc/i686-pc-cygwin/3.4.1/... But gpc is still there: /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/...
Does this work?
If the Pascal frontend would be included in the big all-included gcc release tarballs like it is with C++, Ada, Java, ObjC or Fortran, then the MinGW maintainer for GCC would build it on a regular basis as he does with all other frontends.
[...]
Well, if you have given up the Cygwin binaries, then I will take them up again. I stopped because you had taken them up.
I'm about to release gcc-3.4.x, I cannot include GPC as long as it is not supported upstreams. As long as gcc-3.4.x is in 'test' and 3.3.3 is the 'current' release the gpc compiler is available in 'current'.
Gerrit
Gerrit P. Haase wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 28 Nov 2004 at 18:02, Gerrit P. Haase wrote:
[...]
I don't include GPC with the Cygwin GCC distribution currently because:
- no according MinGW version available because GPC is no regular part of the GCC.
I am not sure what this means. As the person responsible for the Mingw GPC binaries, I need to understand what you mean. Can you please explain? Thx.
I have now gcc here: /usr/lib/gcc/i686-pc-cygwin/3.4.1/... But gpc is still there: /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/...
Does this work?
I think it should work. That's why the directories contain version numbers, precisely so that they don't conflict. (I have currently 4 different backend versions installed on my system plus various cross-compilers.)
The only conflict would be the executables in /usr/bin. But since you shouldn't install a `gcc' executable built with a GPC distribution (only the `gpc' executable; and the `gcc' built with your current GCC version), there should be no problem. Again, that's what I do (my gcc executable happens to be a different backend version than all of my installed GPC versions).
Frank
Gerrit P. Haase dixit:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
It would even be easier to be _used_, since people can just build their system gcc with gpc.
Have you tried it? Source managed by CVS is 'standard' and most OS developers are used to use it.
Ack.
If you don't like being part of GCC and having things hosted at sourceware.org, there are other possibilities, get an account at sourceforge or savannah?
What about a development branch at gcc.gnu.org? I've heard these are pretty easy to get, and a branch like gcc_3_4_with_gpc_and_waldeks_patches would even be a speaking name... ;-)
bye, //mirabile
On 28 Nov 2004 at 0:13, Thorsten Glaser wrote:
Gerrit P. Haase dixit:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
It would even be easier to be _used_, since people can just build their system gcc with gpc.
And *this* is what I was implying by starting this thread.....
I'm the creator and admin of WinAVR, a prebuilt suite of dev tools (binutils, gcc, gdb, others) for the Atmel AVR processor line. Currently, C and C++ are available for the AVR. It would be great if I could get other languages compiling for the AVR target. There is work being done on Ada for the AVR. I feel that it be a benefit to have Pascal for the AVR.
However,.... It's difficult enough trying to keep track of GCC patches that are AVR specific, without having to try to integrate another patch to add Pascal to the mix. Yes, the GPC people seem to do a *wonderful* job on making sure the patch works with a released version of GCC, and thank you very much for doing this!
But, it just doesn't seem to make sense when there is an item in the GNU list on Savannah, wanting more languages for GCC, and here is "GNU Pascal" sitting all by itself and not integrated into the main GCC tree!
Yes, I understand that the GPC "patch" follows the main GCC tree, that it's not applicable to the latest release.
But, with the new changes in GCC for 4.0.0, it seems like this would be a good opportunity to start the integration work, however long it takes with the resources as they are. My only concern would be that it might be too late for 4.0.x, but possibly for 4.1.x.
I echo the sentiment, that it would attract more users, and hence more developers, if GPC were integrated into GCC.
Thanks for listening, Eric
E. Weddington dixit:
And *this* is what I was implying by starting this thread.....
[...]
However,....
Same here, BSD-based free operating system.
But, with the new changes in GCC for 4.0.0, it seems like this would be a good opportunity to start the integration work, however long it takes with the resources as they are. My only concern would be that it might be too late for 4.0.x, but possibly for 4.1.x.
For 4.0 it's too late, plus 4.0 has a completely different internal structure due to tree-ssa.
My concern with 4.x is that many people will stay with 3.4.x for a while, but the gcc steering commitee won't bring out a 3.4.5 or even 3.5 version until tree-ssa dust has settled (probably 4.2 or 4.3), all languages are supported etc.
I have heard that Propolice SSP by Hiroaki Etoh, which we're using (most BSDs), will be in 4.1 or 4.2 too (with changed design), and how much work it is. Ada is said to be still broken for 4.0, and they had to replace g77 by gfortran.
bye, //mirabile
Thorsten Glaser wrote:
What about a development branch at gcc.gnu.org? I've heard these are pretty easy to get, and a branch like gcc_3_4_with_gpc_and_waldeks_patches would even be a speaking name... ;-)
Having a presence on gcc.gnu.org in *some* way may help to get:
- bugs in the back-end fixed - get changes needed for gpc into gcc.
The back-end team would no longer have false excuses "oh, did you integrate gpc been into gcc" or refuse to fix bugs (e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901) by giving a bug the lowest possible "priority".
So, if this if somebody volunteers (without introducing extra work for Frank and Waldek), this it doesn't sound like a bad idea.
Regards,
Adriaan van Os
Adriaan van Os dixit:
What about a development branch at gcc.gnu.org? I've heard these are pretty easy to get, and a branch like gcc_3_4_with_gpc_and_waldeks_patches would even be a speaking name... ;-)
Having a presence on gcc.gnu.org in *some* way may help to get:
- bugs in the back-end fixed
- get changes needed for gpc into gcc.
No, I was talking about a branch, not mainline or an already existing gcc branch.
On the other hand, diffs from _there_ could then get merged back, but I think the gcc team would be reluctant to merge them into anything other than mainline (gcc 4.1, for now), which means a lot of work to be done first.
So, if this if somebody volunteers (without introducing extra work for Frank and Waldek), this it doesn't sound like a bad idea.
I've tried to tie together gcc and gpc already, and except for the circular make dependencies, and the way the RTS is built, it was not too difficult to make gpc built by de- fault just like Ada or C++.
It would probably be feasible to move the RTS out of the gcc/p/ subdirectory, though. (I hope they will do that for Ada, too.)
bye, //mirabile
Adriaan van Os wrote:
The back-end team would no longer have false excuses "oh, did you integrate gpc been into gcc" or refuse to fix bugs (e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901) by giving a bug the lowest possible "priority".
Well, this page does contain a reproducible C program for this bug, which was incidentally also written by me (see http://www.gnu-pascal.de/crystal/gpc/en/mail8313.html), precisely so developers wouldn't have to bother with GPC in order to fix this bug. (And, of course, to make sure the bug isn't in our frontend.)
Even if GPC was integrated, I suppose they'd rather use this C test when fixing the bug instead of a Pascal test, because most developers are more familiar with C. And that's fine because it's a generic backend bug, not specific to either frontend. They can do this now just as well as later when GPC might be integrated.
But if nobody cares to fix the bug, they don't need any "excuses", of course (it's free software etc.).
So I fail to see that GPC integration would make any difference here either.
Frank
Gerrit P. Haase wrote:
Frank Heckenbach wrote:
Gerrit P. Haase wrote:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
I've heard this claim, but I see no evidence. Getting the source
Have you tried it? Source managed by CVS is 'standard' and most OS developers are used to use it.
(I've heard of some rather popular OS having switched to a different system. Just a side-note ...)
And yes, I think I mentioned it before, we've tried it once. It didn't attract new contributors (nobody asked us for write access, or sent patches based on a CVS snapshot), and it was just more work for Peter and me.
code by HTTP is no more complicated than by CVS (in fact, it's much easier for most of us, myself included, even if it may take a second longer because a few more files are included).
May be easier for people who are not familiar with CVS,
Including myself.
but simply retrieving is not the problem.
Well, for me it still is a problem. I always have to look things up if I need to get something from CVS, and I still haven't really understood all those strange options. I seem to know that there are different access methods, and they all need their own special options, and there are more parameters than would actually be necessary for an anonymous checkout.
OTOH, I know very well (as probably most people do) how to get a file by HTTP.
To make it clear what I mean, this is the relevant part that was in the GPC manual when we had a CVS. I'm not sure if it has to be so complicated. For other CVS packages, I usually see different (but not much easier) instructions ...
---8<---
... via anonymous CVS from:
@smallexample CVS root: :pserver:anonymous@@agnes.dida.physik.uni-essen.de:/usr/local/cvsroot Password: anonymous Command: checkout gpc @end smallexample
If you haven't used CVS yet, here's what to do:
Make sure you have the @file{cvs} executable. If not, you can get its source from a GNU mirror or binaries for various platforms (Linux @file{.rpm} or @file{.deb}, CygWin archives, etc.) from the usual places.
Execute once the following command:
@smallexample @t{cvs -d } @t{ :pserver:anonymous@@agnes.dida.physik.uni-essen.de:/usr/local/cvsroot login} @end smallexample
Create a directory where you want to store the GPC sources.
Each time you want to get/update your copy of GPC, change to that directory and execute the following command. The first time, it will take a while to get all the GPC sources. Subsequent invocations will only transmit changes and therefore usually be quite fast.
@smallexample @t{cvs -z9 -d } @t{ :pserver:anonymous@@agnes.dida.physik.uni-essen.de:/usr/local/cvsroot } @t{ checkout gpc} @end smallexample
(You may want to store this last command in a script or as an alias so you can invoke it more easily.)
---8<---
Additionally you could use the facilities at sourceware.org to distribute snapshots, releases and the website & mailinglist.
We do have the facilities, and we do all that, thanks. (Unless the server goes down ... but this can happen to anyone, see Debian last year ...)
Getting patches to a slightly older (alpha/beta) version is *really not* a big deal. I can handle some changed contexts, renamed identifiers etc.
Not a big deal for you. But a big deal for me. I need to ask *you* because I cannot ask CVS.
So why would you want to get an instable version from me? When things are stable enough, I make a release anyway.
Frank
On 19 Dec 2004 at 2:07, Frank Heckenbach wrote:
[...]
To make it clear what I mean, this is the relevant part that was in the GPC manual when we had a CVS. I'm not sure if it has to be so complicated. For other CVS packages, I usually see different (but not much easier) instructions ...
---8<---
... via anonymous CVS from:
@smallexample CVS root: :pserver:anonymous@@agnes.dida.physik.uni-essen.de:/usr/local/cvsroot Password: anonymous Command: checkout gpc @end smallexample
[...]
I think that the CVS debate is a red herring. FWIW, I find CVS to be of dubious benefit (unless people are keen to download unstable code that might very well change quite significantly after they have downloaded it). I would rather download tarballs of released code. And Frank is right. I remember when gpc was available via CVS. IMHO it did not improve anything from the point of view of getting more developers working on the compiler, while it made more work for those actually developing the compiler. If anyone is interested to work on the compiler itself, I am sure that Frank and Waldek would be most obliged - but I don't think that CVS is what will cause this to happen.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Frank Heckenbach wrote:
Gerrit P. Haase wrote:
Have you tried it? Source managed by CVS is 'standard' and most OS developers are used to use it.
(I've heard of some rather popular OS having switched to a different system. Just a side-note ...)
And yes, I think I mentioned it before, we've tried it once. It didn't attract new contributors (nobody asked us for write access, or sent patches based on a CVS snapshot), and it was just more work for Peter and me.
<snip>
Well, for me it still is a problem. I always have to look things up if I need to get something from CVS, and I still haven't really understood all those strange options. I seem to know that there are different access methods, and they all need their own special options, and there are more parameters than would actually be necessary for an anonymous checkout.
OTOH, I know very well (as probably most people do) how to get a file by HTTP.
<snip>
Getting patches to a slightly older (alpha/beta) version is *really not* a big deal. I can handle some changed contexts, renamed identifiers etc.
Not a big deal for you. But a big deal for me. I need to ask *you* because I cannot ask CVS.
So why would you want to get an instable version from me? When things are stable enough, I make a release anyway.
Frank, I think you are blurring here difference between releases and snapshots. Basically you are telling us: I want show you my code, unless it is ready for release. For me it is a significant problem: I can easily do things as small separate patches, but keeping track of them without a single "master" version is a big pain. Alternatively, I can create my own development line, and submit you a big chunk when ready. You claim that such big chunks are OK, but it seems that they cause you problems.
I am for quality releases, but key to quality is testing. I working on a program rather quickly get to point of diminishing returns: new bugs show from time to time, but it takes long time to find one. The program still has bugs, but it takes new usage pattern to discover them. You may be better at that, but I think that in general in-house testing can give quality compiler only with _huge_ efforts.
So I think we need multi-layer process. For example: development snaphots -- where complete and cleaned features or fixes go, snaphots should build and pass the test suite at least on a single machine beta releases -- when things are stable enough: we have small number of outstanding bugs. Betas should build and do not give unexpected test failures on large variety of systems.
The point here is that snapshots should be ready for semi-automatic testing: knoledgable people can set up build and test scripts to do things with little effort. At the moment GPC benefits from Debian testing, but with regular snapshots we could get more info from Debian and possibly some people would set up similar things for other systems.
I agree with Chief that CVS is a red herring here. What really is needed is open process with fast development cycle (in particular big features should be split into small pieces). And, I see nothing done on GPC in last two years that could not be split into pieces taking at most few days to implement.
Waldek Hebisch wrote:
Frank, I think you are blurring here difference between releases and snapshots. Basically you are telling us: I want show you my code, unless it is ready for release. For me it is a significant problem: I can easily do things as small separate patches, but keeping track of them without a single "master" version is a big pain. Alternatively, I can create my own development line, and submit you a big chunk when ready. You claim that such big chunks are OK, but it seems that they cause you problems.
The problems weren't so much in the patch itself, or (probably) that it was against 20040516. I simply didn't have the time recently to look into it. My actual jobs kept me quite busy, and of course things like the broken-down server which caused me quite a bit of work to restore didn't help either. In the remaining time that I had for GPC, I could only focus on the changes I needed myself and some particular issues (such as `CInteger' and initializers -- both of which had many more ramifications and were more work in the end than I had expected).
I am for quality releases, but key to quality is testing. I working on a program rather quickly get to point of diminishing returns: new bugs show from time to time, but it takes long time to find one. The program still has bugs, but it takes new usage pattern to discover them. You may be better at that, but I think that in general in-house testing can give quality compiler only with _huge_ efforts.
I see your point, though for me it's sometimes the other way around (see below).
So I think we need multi-layer process. For example: development snaphots -- where complete and cleaned features or fixes go, snaphots should build and pass the test suite at least on a single machine beta releases -- when things are stable enough: we have small number of outstanding bugs. Betas should build and do not give unexpected test failures on large variety of systems.
I agree, since I might not have the time I'd like to in the future either ...
So I'll try to handle beta versions mostly like now, and in addition try to make more often what you call development snaphots -- I think we can also call them alphas and put them in that directory, which is probably more in line with the usual meaning of alpha (previous GPC "alphas" often were much better tested than alphas elsewhere). (For users this will mean, of course, they can decide to stick with the betas only, or try the alphas, but then be prepared for more failures ...)
One thing I'd like to stress, though, is that we should try not to keep too many "alphaish" features around. That would be much like the situation a few years ago where GPC contained a number of hardly-tested/not-fully-implemented/full-of-known-bugs features which I've at least mostly tried to clean up by now.
Of course, there can always be difficult areas that must be postponed (we still have a few tricky problems with schemata, e.g., but these are becoming more and more exotic situations), but IMHO we shouldn't jump too quickly from one area to another until the first one is reasonably stable (though there can be several alphas on the way there), since for a non-alpha-tester user (including myself as a user of GPC) it's better to have one feature basically working than three features where it's pure luck whether they'll work in any given situation (again, that's the situation some years ago as I experienced it as a user of GPC, and I don't want to get back there).
I agree with Chief that CVS is a red herring here. What really is needed is open process with fast development cycle (in particular big features should be split into small pieces). And, I see nothing done on GPC in last two years that could not be split into pieces taking at most few days to implement.
BTW, implementing is one thing, testing another one. It usually takes me longer to debug a problem from a mailing list bug report (somewhat longer to much much longer, depending on the quality of the report) than one I find myself. So I guess I'll then have to ignore bug reports on new features until I consider them stable enough myself in the first place, because I can't afford the extra debugging time it would cost me. If you like to do it, fine, otherwise users will just have to remember their bugs, test them again, and finally resend them (or, of course preferred, fix them themselves -- but I know that hacking GPC is a bit difficult for many users) ...
Frank
Gerrit P. Haase wrote:
Waldek Hebisch wrote:
What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
Indeed. If it were on a devel branch at GCC CVS, a certain number of us GCC hackers would work to integrate it and get the branch merged; as it is, it's really rather inconvient to do such integration work
For example, I'm working on cleaning up the icky Ada configury, not because I know anything about Ada, but because it's part of GCC and I don't like having ickinesses like that in GCC mainline.
In contrast, I actually do know something about Pascal.
On Thu, 16 Dec 2004, Nathanael Nerode wrote:
Gerrit P. Haase wrote:
Waldek Hebisch wrote:
What would it take to integrate GNU Pascal with the rest of GCC?
Short answer: more developers (and testers).
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
Indeed. If it were on a devel branch at GCC CVS, a certain number of us GCC hackers would work to integrate it and get the branch merged; as it is, it's really rather inconvient to do such integration work
For example, I'm working on cleaning up the icky Ada configury, not because I know anything about Ada, but because it's part of GCC and I don't like having ickinesses like that in GCC mainline.
In contrast, I actually do know something about Pascal.
Perhaps GPC could be integrated with GCC-3.3.6 which is scheduled for release April 30, 2005
As far as I know GPC compiles nicely with GCC-3.3.5 so the problems with the integration might be mostly political.
Russ
Russell Whitaker wrote:
On Thu, 16 Dec 2004, Nathanael Nerode wrote:
Gerrit P. Haase wrote:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
Indeed. If it were on a devel branch at GCC CVS, a certain number of us GCC hackers would work to integrate it and get the branch merged; as it is, it's really rather inconvient to do such integration work
For example, I'm working on cleaning up the icky Ada configury, not because I know anything about Ada, but because it's part of GCC and I don't like having ickinesses like that in GCC mainline.
In contrast, I actually do know something about Pascal.
Perhaps GPC could be integrated with GCC-3.3.6 which is scheduled for release April 30, 2005
As far as I know GPC compiles nicely with GCC-3.3.5 so the problems with the integration might be mostly political.
Why would the problems be mostly political? From what I can tell, isn't GPC under the GNU aegis, same as GCC? Or do you mean political issues with the two camps of developers? (which would make sense to me)
Eric
On Thu, 16 Dec 2004, E. Weddington wrote:
Russell Whitaker wrote:
On Thu, 16 Dec 2004, Nathanael Nerode wrote:
Gerrit P. Haase wrote:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers .
Indeed. If it were on a devel branch at GCC CVS, a certain number of us GCC hackers would work to integrate it and get the branch merged; as it is, it's really rather inconvient to do such integration work
For example, I'm working on cleaning up the icky Ada configury, not because I know anything about Ada, but because it's part of GCC and I don't like having ickinesses like that in GCC mainline.
In contrast, I actually do know something about Pascal.
Perhaps GPC could be integrated with GCC-3.3.6 which is scheduled for release April 30, 2005
As far as I know GPC compiles nicely with GCC-3.3.5 so the problems with the integration might be mostly political.
Why would the problems be mostly political? From what I can tell, isn't GPC under the GNU aegis, same as GCC? Or do you mean political issues with the two camps of developers? (which would make sense to me)
I suspect the first problem would be to convince Gabriel Dos Reis, et al, to change the status of 3.3.6 from "open for regression fixes only" to add "and GPC integration"
Russ
Russell Whitaker wrote:
On Thu, 16 Dec 2004, E. Weddington wrote:
Russell Whitaker wrote:
On Thu, 16 Dec 2004, Nathanael Nerode wrote:
Gerrit P. Haase wrote:
IMHO you would get more testers (users) automatically if GPC would be included into the GCC repository. And it would be much easier to contribtueif the code could be checked out via CVS and so there would be also a better chance to recruit more developers.
Indeed. If it were on a devel branch at GCC CVS, a certain number of us GCC hackers would work to integrate it and get the branch merged; as it is, it's really rather inconvient to do such integration work
For example, I'm working on cleaning up the icky Ada configury, not because I know anything about Ada, but because it's part of GCC and I don't like having ickinesses like that in GCC mainline.
In contrast, I actually do know something about Pascal.
Perhaps GPC could be integrated with GCC-3.3.6 which is scheduled for release April 30, 2005
As far as I know GPC compiles nicely with GCC-3.3.5 so the problems with the integration might be mostly political.
Why would the problems be mostly political? From what I can tell, isn't GPC under the GNU aegis, same as GCC? Or do you mean political issues with the two camps of developers? (which would make sense to me)
I suspect the first problem would be to convince Gabriel Dos Reis, et al, to change the status of 3.3.6 from "open for regression fixes only" to add "and GPC integration"
I suspect the barrier, in the past, has been that unusual things have to be done to the gcc core in order to handle such things as case insensitive identifiers with a specific case sensitive linkage form, debuggery and validation which includes range limits, modularization, native string formats, etc. However, if Ada is now successfully integrated most of these problems should have been solved, and the politics will be in merging how they were solved in gcc/ada and in gpc.
I am on the outside looking in and pontificating. I expect Frank Heckenbach, who has done the majority of work on gpc, will be unusually sensitive to change. He has almost certainly had to resort to various expedients, not necessarily clean, in the past. Consultation with the Ada integrators should certainly help.
CBFalconer wrote:
Russell Whitaker wrote:
I suspect the first problem would be to convince Gabriel Dos Reis, et al, to change the status of 3.3.6 from "open for regression fixes only" to add "and GPC integration"
I suspect the barrier, in the past, has been that unusual things have to be done to the gcc core in order to handle such things as case insensitive identifiers with a specific case sensitive linkage form, debuggery and validation which includes range limits, modularization, native string formats, etc. However, if Ada is now successfully integrated most of these problems should have been solved, and the politics will be in merging how they were solved in gcc/ada and in gpc.
Indeed, there are some issues, though not exactly those you're thinking of.
The most important ones (WRT integration) currently are automake, support of older backend versions (in particular gcc-2), and the separate preprocessor (which is responsible for the problems with conditionals in gcc-3.3.x since these versions now basically assume a built-in preprocessor -- we're partly working around it, but it's clear that this is not the right solution). Debugging is also an issue (and it still looks rather dark), which will probably require a lot of work, but AFAICS it doesn't interfere with integration that much.
On a broader perspective, there has been a lot of "cruft" in GPC for a long time (actually since its beginning) for various reasons, mostly historical ones. For a few years, I've been cleaning up things together with Waldek, and I think we've made some progress. I'd estimate we're about 2/3 done now.
For the remaining big issues there are plans:
- Older backend versions: Mostly done, and testing. I've yet to test some particular configurations, and occasionally I hit a new bug in gcc-3.x, but recently Waldek has usually provided fixes quickly which got mostly integrated into the main gcc distributions. Still, I'd like to make at least one more major release (gpc-2.2 or 3.0, whichever we might call it) with gcc-2 support deprecated, but not removed. It will probably get more widespread use than the betas, and given the extensive changes since gpc-2.1, I'd prefer users to still have the choice WRT backend versions.
- 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.
- Preprocessor: Has to be rewritten. (I have the plans, just have to find the time to do it.) Since the effects on normal Pascal code will be small, we probably won't need a long transition period here.
All in all, if things go well, all of these issues should be resolved after the next major GPC release.
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. The latter IMHO smells too much like certain proprietary companies, 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. So that's one reason why I have some aversions against integration, if those schedules will also dictate our releases. (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?)
I am on the outside looking in and pontificating. I expect Frank Heckenbach, who has done the majority of work on gpc, will be unusually sensitive to change. He has almost certainly had to resort to various expedients, not necessarily clean, in the past. Consultation with the Ada integrators should certainly help.
I suppose trying to integrate now will cause quite a bit more work in total (such as keeping two source trees in sync for the current GCC branch and for older backends -- it's much easier with the ifdefs we have now, in particular since many of the changes (so far and upcoming) are quite backend-independent). Again, once the issues above are solved, this won't be such a big problem (e.g., differences between gcc-3.x versions are much smaller in their effect on GPC).
So I don't want to haste things (now that I'm beginning to see the light at the end of the cleanup-tunnel ...). If anyone wants to do it now, you can try it (it's free software), but don't count on my support. I'll continue working on a single source tree for different backend versions etc. until I think it's ready, even if it may take another year or two.
Frank
Russell Whitaker wrote:
Perhaps GPC could be integrated with GCC-3.3.6 which is scheduled for release April 30, 2005
As far as I know GPC compiles nicely with GCC-3.3.5 so the problems with the integration might be mostly political.
Well: 1) I should not speak for GCC developers, but GCC policy is to do new developement on CVS version (currenly coming 4.0). Improvements to older versions are actively discouraged.
2) One can get "integrated" compiler dropping in gpc tarball and appling the patch form `diffs' subdirectory. Going beyond that would be mostly wasted effort, because gcc-3.4.x and coming 4.x are different enough (so one would have to re-do the work for newer versions)
Waldek Hebisch dixit:
(cross-posted to gcc list, please reply to the gpc list)
appling the patch form `diffs' subdirectory. Going beyond that would be mostly wasted effort, because gcc-3.4.x and coming 4.x are different enough (so one would have to re-do the work for
Exactly this is the cause for the following request of mine:
Since gcc 4.0 will be out of the door not in less than two months from now, and given that gcc 4.1, which ought to solve at least the basic problems with tree-ssa etc. is not even in sight yet, I propose that there will be a gcc-3.5 release with support for Pascal, based upon gcc-3.4, current gpc and Waldek's patches.
This would be great since we already had the new directory layout (what I would greatly like to see for Ada and Pascal is that their RTS moves from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5 specific diffs integrated into the core, while the backend patches for gcc 3.3 and older are still available (I don't think Frank is going to throw them away after the integration), and so, if you do _not_ remove the ifdefs from gcc/p/*, you could do another standalone GPC release based upon the code in the gcc-3.5 development tree.
While it might also be worthwhile to integrate Hiroaki Etoh's ProPolice SSP, and probably other fixes (Apple stuff?), this would mean gcc 3.5 must be an "official" release. If the SC really is reluctant to do so, it might be feasible to do a "gpc+gcc 3.5" version, developed as a branch in the gcc cvs, but not endorsed by the SC. (Of course, if there'd be interest, one could add ProPolice to that branch as well, unless you really want it to be only for your gpc-specific work. If there is interest, I myself could try to get cvs ci access to gcc.gnu.org - I've already signed the relevant forms, and etoh has, too - and integrate the current propolice; I'm already doing this for the gcc contained in my OS at the moment).
For others, developers, especially OS vendors, this would also be great, because history has shown that gcc 3.x branches tend to end after 3.x.3 or 3.x.4, and for the aforementioned reasons 4.0/4.1 will not gain wide acceptance outside of Gentoo (j/k) soon; if one were to incorporate generic 3.x bugfixes and maybe backport 4.x bugfixes into a 3.5 series, this could not only get much adoption, but maybe support from the large (e.g.) GNU/Linux vendors (Novell?).
This support would lead to a faster distribution of gpc to "the masses" than releasing a standalone gpc version now and then integrating it into 4.1/4.2 ever could. Besides, support for 3.4 is "almost" done for the more common platforms; I doubt gpc will make it into mainline before it runs on almost all platforms, and having it in gcc cvs will surely help to both get more eyes on the code (Nathanael said something like this IIRC) and get these who do changes to the backend more aware of gpc.
Just my 0.02 EUR, //mirabile
-
Adriaan van Os -
CBFalconer -
E. Weddington -
Frank Heckenbach -
Gerrit P. Haase -
Nathanael Nerode -
Prof A Olowofoyeku (The African Chief) -
Russell Whitaker -
Thorsten Glaser -
Thorsten Glaser -
Waldek Hebisch