>>>>> "Ole" == Ole Rohne <ole.rohne@cern.ch> writes:
Ole> actually run correctly, this made me wonder if I should look for newer
Ole> cmucl specific patches? I didn't have much luck with the CVS
I have a few patches but they have to do with plotting. They're not
quite ready yet.
Ole> Here is a summary of my fixes, intermixed with relevant diffs:
Ole> (proclaim '(inline *quo *dif))
Ole> #+cl
Ole> (DEFun *QUO (X Y)
Ole> (cond ((and (integerp x) (integerp y))
Ole> - (truncate x y))
Ole> + (progn (truncate x y)))
Ole> (t (/ X Y))))
This progn shouldn't change anything. Don't you mean (values
(truncate x y)) so that returns exactly one value?
Ole> * My next point doesn't have a diff but is related to the build
Ole> process. When running (COMPILE-MAXIMA) followed by (SAVE-MAXIMA)
Ole> during one lisp session, some DEFMACROs in hyp.lisp (notably MABS)
Ole> remains defined in the restarted image. This is apparently not the
Ole> intention, see EVAL-WHEN in hyp.lisp. The symptom here is simple
Doesn't that mean that the eval-when is either wrong or CMUCL is not
doing the right thing with the eval-when? The current CVS versions of
CMUCL has an ANSI compliant eval-when implementation now.
Ray