5.9.2



On Sat, 2004-09-25 at 11:08, CY wrote:
> Hey gang!  Now that 5.9.1 is out, I had a couple of questions about 5.9.2
> 
> a)  Should Maximabook be split out of docs into its own cvs module?  It's 
> getting rather large to be included by default now, and it's going to get 
> larger.

I think it would be a good idea to create a separate module for
maximabook. Creating a new module is trivial if we aren't worried
keeping the full change history in one file. I don't think that the
change history for maximabook is complicated enough for that to be a
problem. Just go ahead and create the new module in cvs. (If you aren't
sure how to do that, please ask.)

The history won't be lost, it will just be spread across two modules.

> b)  Should I wait to upload my changes until a) is decided?  (I'd rather not 
> as that means my machine is a single point of failure, but I can understand 
> people not liking a couple extra megs in the cvs checkout)

Right. I, too, worry when I have changes that sit for a long time
without making it into cvs.

> c)  How are we going to handle this phase of development?  I know Jim is 
> working on merging a big cleanup patch (woo-hoo!) but I'm not clear how that 
> will work with the downcasing.  Clearly we need some point at which 
> everything stops, we downcase and get working again, and then we accept new 
> patches to the downcased code.  Essentially it would be silly to do a lot of 
> work on the codebase until we know how this is going to happen. Is the plan 
> to i) have some one person do the patch merging and preliminary downcase 
> work, then have the rest of us jump in ii) merge all outstanding patches to 
> date, then break up the downcasing among ourselves?  iii)  Something more 
> intelligent I haven't thought of?

Here is my plan:

1) Apply Andreas Eder's patches. This turned out to be a little more
difficult than I expected. See * below.

2) Apply some tag to cvs to represent the last mixed-case version of the
code.

3) Downcase the code. Also, re-wrap the code using the emacs indent
routines. *No* other changes will be allowed, not even bug fixes.

4) Apply some other tag to cvs to represent the first all lower-case
version of the code.

5) Re-open cvs to regular work.

6) The only major thing left to do in 5.9.2 will be the conversion to
real case sensitivity. There are a couple of things left to discuss
about this, but I'd like to try out a couple of ideas before we get into
it.

Steps 3 and 4 won't take very much time at all.

* The real problem I have right now is with Andreas Eder's changes. He
has done a great deal of work. Unfortunately, his changes don't leave me
with a perfectly working version of Maxima. He said the code passed the
test suite at the time he made the changes. Either I am missing
something, or the test suite only appeard to succeed. (The test suite
can incorrectly report passes when lisp errors occur. It's yet another
thing to fix.) Unfortunately, I haven't been able to get through to
Andreas in the last few days. His mailbox is full.

If anyone else is interested on working on this right now, please let me
know. I actually have time right now, so I will probably be able to
solve the problem reasonably soon.

> Just for fun, I downcased all the lisp files in src/ and compiled them using 
> the lisp compile method and cmucl.  Here were the results:
> 
> ; Compilation unit finished.
> ;   11 errors
> ;   156 warnings
> ;   313 notes
> 
> All 11 errors were the same:  
> ; Error: (during macroexpansion)
> ; Error in function MFORMAT-TRANSLATE-OPEN:  Unknown format op.
> 
> So it looks like it might not be hard to at least compile a downcased Maxima, 
> although who knows what the test suite will do.

Good news. In principle there should be little to do.

> CY
> 
> P.S. - sorry if a couple duplicates of this show up - I was being a dork and 
> using the wrong identity to send the message.

If you want to post from an alternate address, please let me know. I can
add it to the list of allowed senders.