I wish I understood all this issues involved in this problem better.
Everything you say makes sense. I still don't understand why the old
problem with MABS didn't seem to affect, e.g., MSQRT. With the original
setup just typing
abs(z);
where z is a new variable would cause an error. I didn't see the same
behavior with
sqrt(z);
Maybe it's just time to move on.
I believe you are right that we should have separate compile and
load/save image stages. I have updated the build files to do that, but
we are still waiting for the cvs module to be installed, so I haven't
committed the changes.
--Jim
On Tue, 2002-03-12 at 04:24, Ole Rohne wrote:
> > > As I couldn't find any conflicting definition of MABS,
> >
> > The conflicting definition is in troper.lisp. It's defined via "def%tr",
> > so you may have missed it.
>
> I did see the DEF%TR, I was however mislead to look for a classical
> DEFUN/DEFMACRO conflict (of which we've had a few) and I was fooled by
> DESCRIBE not giving me any function or macro definition for MABS:
>
> 0] (let ((ext:*describe-level* 1)) (describe 'mabs))
> MABS is an internal symbol in the MAXIMA package.
> ...
> Its TRANSLATE property is #<Function "DEF%TR MABS" {11423AC1}>.
> ...
>
> You're absolutely right about the conflict, it is between the
> TRANSLATE property and the macro definition.
>
> In hyp.lisp, the intention seems to be to protect the DEFMACRO with
> (EVAL-WHEN (COMPILE EVAL) ...). Unfortunately, in some lisps (cmucl),
> DEFMACROs inside the EVAL-WHEN have toplevel effects in the lisp image
> that compiles the file and this effect persists in any core descending
> from that image. As I've mentioned earlier, this can be circumvented
> by starting cmucli anew, loading the precompiled files and then
> (SAVE-MAXIMA).
>
> > It isn't that simple. Replacing the definition I removed will cause many
> > more new errors, including the one Daniel Lemire just reported.
>
> If thats Lemire's bug as in "f(x):=abs(x+1); f(1) => fails", note that
> it would cause an error already in rtest3 problem 14 (which I don't see here).
>
> > discussed this issue on the list a while ago. I'm sorry to see that the
> > story isn't over yet. I have to confess I don't understand why the error
> > in rtest14 is happening.
>
> The recent error in rtest14 happens (on cmucl at least) because
> TRIG-LOG-1 tries to call MABS as a function/macro. It is not enough
> just to delete the DEFMACRO, the places in the code that relies on the
> DEFMACRO needs to be provided for. The only instance I can find is in
> the second (active) instance of TRIG-LOG-1 in hyp.lisp and the
> following works for me:
>
> --- maxima-pre59/src/hyp.lisp Mon Mar 11 17:27:46 2002
> +++ maxima/src/hyp.lisp Tue Mar 12 11:11:21 2002
> @@ -1228,3 +1228,3 @@
> (T ())))
> - ((=1//2 (MABS (M-T B A)))
> + ((=1//2 (SIMP `((MABS) ,(M-T B A))))
> (COND ((EQUAL (CHECKSIGNTM VAR) '$POSITIVE)
>
> For me on cmucl, this fix is *not* a substitute for quiting and
> reloading when dumping core - doing (SAVE-MAXIMA) in the same image
> that compiled the files gives me a storm of errors in rtest*.mac. I
> haven't tried the new building procedure, does it work with cmucl?
> >From scratch, no precompiled files, directly doing (SAVE-MAXIMA)?
>
> Ole
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima