Subject: Maxima 5.26.0 tagged in Git & posted to SF
From: Oliver Kullmann
Date: Tue, 20 Dec 2011 00:22:02 +0000
On Mon, Dec 19, 2011 at 10:04:04AM -0700, Robert Dodier wrote:
> On 12/19/11, Oliver Kullmann <O.Kullmann at swansea.ac.uk> wrote:
>
> > Running tests in rtest8:
>
> I think I observed this before & reported it to the ECL mailing list.
> If it's the same error, there is a difference between compiled
> and interpreted code in ECL. If you load these files from the
> Maxima prompt:
>
> :lisp (load "src/numerical/slatec/xermsg.lisp");
> :lisp (load "src/numerical/slatec/xerprn.lisp");
> :lisp (load "src/numerical/slatec/xersve.lisp");
>
> and then re-run the test, does the problem go away?
>
Yes, it goes away (only rtest14.mac problem: (144) remains).
> > /* Print a string without line-breaks: */
> > print_nlb(s) := block([old_linel : linel],
> > linel : slength(s) + 1,
> > print(s),
> > linel : old_linel)$
>
> To preserve & restore a global variable, block([some_variable : foo], ....)
> is enough (i.e. block restores the value, you don't have to).
>
Sure; I didn't look at the function --- this function was one of the first I ever wrote
in Maxima (good old days, I was still naive and full of hope ;-)).
> Maybe it works better to call Lisp FORMAT ?
> (i.e. ?format(s)) I haven't tried it.
>
Indeed, the best implementation seems to be
/* Print a string on one line, with exactly one line-break: */
print_nlb(s) := printf(true,"~a~a",s,newline)$
> > As it should be. However 5.26.0 introduces an extra empty line:
> > ---
> > (%i2) print_nlb("XXX");
> >
> > XXX
>
> Well, without looking I don't know what might have changed.
> Different Lisp implementations handle the "fresh line" business
> differently so it's just a lot of trial & error to get it straight for
> all implementations.
>
With Ecl linel apparently has to be at least 2 more than the length of the string
to be printed --- otherwise one gets the extra new line (and this behaviour is
new with 5.26.0).
It seems that we don't have further problems then with 5.26.0. It seems a bit
slower (perhaps 5% more time on our testsuite).
Thanks for your help!
Oliver