RE: [Gcl-devel] 2.6.2.....

[Mike Thomas]

Hi Camm.

| > 'Then, shalt thou count to three. No more. No less. Three shalt be the
| > number thou shalt count, and the number of the counting shall be
| > three. Four shalt thou not count, nor either count thou two, excepting
| > that thou then proceed to three. Five is right out. Once the number
| > three, being the third number, be reached, then, releasest thou thine
| > stable GCL unto the world before thou findest more bugs and, of old
| > age, thine clients snuff it.'
| >
|
| :-)  Does humor grow on the eucalyptus there down under or what?!
| Too much.....  I've been laughing for hours.

I'd love to be able to say it was mine, but (just in case you didn't
realise) it is of course slightly modified Monty Python and therefore a
child of the UK - the Holy Hand Grenade of Antioch:

   http://www.cc.gatech.edu/~pparker/grenade.html


| Sounds like your ready.  We can and should chase down these
| optimization mismatch bugs in the near future, as, uh, they really
| shouldn't be there, but if you can get stable ansi and random test
| results, and compile the open-source (preferably all three) lisp apps
| to pass their tests *on all extant flavors of gcc 3.3* with the same
| settings, then I think we are good to go for now.  I highlight the gcc
| version bit as any sensitivity which shows up with minor gcc
| modifications will hit us with high likelihood at the next minor point
| release, greatly shortening the lifetime of 2.6.2.

OK.  I've yet to test:

1. Maxima on gcc 3.3.3,

2. ACL2 and the CLtL1 build on either gcc.

Maxima is OK with gcc 3.3.1.
The ANSI test and random tester are OK with both gcc flavours.

As far as I know no-one has actually built Axiom or nqthm on Windows yet -
perhaps Bill Page can have another go at Axiom if he's reading - I assume it
will be a major task beyond our one week release time frame though.


| If you don't find random tester errors in the first few thousand runs,
| then you most likely won't, as I've run them at the clisp high water
| mark level now without failure, and the only difference between our
| Linux and Windows ports should be stability, not correctness.  Its
| very helpful that you've double checked the memory stability under the
| new allocation scheme -- thanks!  It still would be nice to have Vadim
| hammer on it a bit.
|
| I'm going to put in Magnus' block to recursive malloc implementations
| tomorrow, and then make a read-only 2.6.2 candidate tag (tomorrow too
| most likely) unless you prefer we wait (I'll assume that silence means
| no objection :-)).  Then for I'm guessing about a week, we should all
| collect the results of all tests on exactly the same version on as
| many platforms as possible.  If there are no show-stoppers, we'll
| tabulate the results in a short release-notes doc, and then make the
| final 2.6.2 tag with this file alone newly included.  Then I'll push
| the tarball to ftp.gnu.org, and we can collect binary builds there as
| on the temporary site, and be done with it.

Agreed.


| I hope I'm not drawing this out too much for the tastes and schedules
| of the friends of GCL.  I'm most open to other release
| ideas/suggestions.

I don't see much alternative if we want to leave a high quality 2.6.2 behind
us.

Cheers

Mike Thomas.