Gerrit P. Haase wrote:
It should be exactly the same output if he uses bison with the same version number... sigh.
I have applied some patches to bison. I know it's an unfortunate situation. I have sent some patches and reported some issues on the bison lists, but not all of them have been integrated yet (some have been in the CVS version I suppose. I didn't check this in detail -- it would just be extra work for me since that version wouldn't be usable for me until the remaining issues are fixed).
I will stay in touch with the bison developers, and hopefully the issues are solved until the next GPC release. (This last release was a bit hurried due to a Debian deadline, perhaps it wasn't such a good idea after all ...)
More general comments about the GPC project:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable. (Especially these years, when we're fixing a lot of fundamental problems which involve bigger changes. Perhaps it will be different a few years from now when things will roll along nicely with small, localized and independent changes, but that's always a nice dream, and I don't know if/when we'll ever get there.)
E.g., just now I've replaced the lexer with a new, flex based one. Even though I had prepared and unit-tested the new lexer for some time, after putting it in and fixing the most obvious problems I found immediately, I got about 450 test suite failures (which was actually better than I'd expected :-). The next day, there were only 40 failures and one basic problem left -- which still means unusable for practical work. Today I got the test suite running ok, but I expect some more subtle, hidden bugs. (And there are entanglements with upcoming changes in the parser and preprocessor which I've just worked around now, but it may be better to do them right before a new release.)
Now if these intermediate versions were available to the public, I'd expect a lot of bug reports, and I'd probably be busy for the next few weeks reading through them, suggesting partial fixes or work-arounds, and not getting to fix the real problems since my time is also limited.
As I said, such a fundamental change is not rare in GPC currently. Changes involving the parser, preprocessor, automake system, qualified identifiers etc. etc. will be at least so wide-reaching, as well as about 10-20 other changes I did in the last two years.
And when I'm working on smaller changes, I usually do several of them in a row (because running the test suite each time would take too long -- often it finds a small problem or five, so it takes several runs to get it right), so also then the intermediate versions are not so stable. In fact it's rather rare for me to have error-free test suite runs except shortly before a release.
Also, before a release I run the tests on some other systems (since target-specific bugs are not so rare, unfortunately) -- though for alpha releases I don't necessarily fix all the bugs I find there if they're tricky and uncommon enough --, and run some scripts that prepare the download files, web pages etc.
Besides, it's of course much easier to fix a bug I find myself than I'm reported. Even if the bug-report is well-written (which, unfortunately, is not always the case), it often takes some asking back until I can reproduce the problem (of course, each time with some delay, so I have to get back to the context of the problem (mentally) again). So it really, measurably, saves me time if I keep the changes to myself for a while until I find the bug myself. Of course, I can't find all bugs myself, so the bug reports I get after a release are also necessary and helpful. But if I can find 95% (roughly) of the bugs myself, this seems to be much more efficient with my time.
I know that other projects make daily snapshots. But (a) they usually have more developers (we're currently bascially two developers, Waldek and me, and some occasional contributors) and (b) IME they often have a "slightly different" attitude to bug reports (i.e., if they can't reproduce it immediately, or they think it's not important they just ignore it -- or let it gather dust in a bug database which to me often appears like "Ablage P" in German ...)
(And they often have several branches. Of course, this can help against the above-mentioned stability problems, and in some cases (like Linux) this is absolutely essential. But it takes even more work (testing, porting changes between versions and branches, etc.), and we simply don't have the resources to do that -- or rather, all resources we'd allocate to that would be taken away from the actual development.)
Sorry for this little rant, but to make it short: If you mean why I don't make daily snapshots: I don't have the time and I don't like to. If you mean anyone else: Just go ahead and tell us the name of your download server (you can write to gpc-announce, of course) ...
How should I know if the gpc-20030830.tar.gz I fetched is really the latest available? There are no timestamps at the website which would tell me the real last modified date.
Usually, the version number corresponds to the date of last change. This time was an (unfortunate) exception because (at least) two serious bugs had crept into the (over-hurried) release and I wanted to fix the files on the server without going through the regular release preparation (I had almost no time for GPC recently, so otherwise it would have delayed the bug-fixing until this week or so) or change things manually (which surely would have resulted in more problems, especially when done in a hurry).
Frank