#201 pickapart misnumbers next C-line FIX

Lisp Core (471)

In Maxima 5.5 Windows GCL

Pickapart usually misnumbers the C-line following its
result. Instead of (e.g.) E5 E6 D6 C7 D7, you get E5 E6
D6 C6 D6, which means that the pickapart return value
D6 is overwritten by the more recent return value.

The test case below consistently elicits this behavior in
a fresh Maxima, or after a Kill(Labels). So does example
(pickapart). Sometimes when Pickapart reuses a
preexisting label -- or perhaps under other
circumstances -- it does not present this problem.

(C1) (x+1)*(x+2);
(D1) (x + 1) (x + 2)
(C2) pickapart(d1,1);

(E2) x + 1

(E3) x + 2

(D3) E2 E3
(C3) x^3;
(D3) x

This can be fixed in Continue (macsys.lisp) as follows:

(when (or (not (checklabel $inchar))
(not (checklabel $outchar))) ;new
(setq $linenum (f1+ $linenum)))

I am tempted to change the when to a while just to be
sure, but I don't know of any reason that would be


  • Robert Dodier

    Robert Dodier - 2006-07-01
    • status: open --> closed
    • labels: --> Lisp Core
  • Robert Dodier

    Robert Dodier - 2006-07-01

    Logged In: YES

    Suggested patch applied & committed as r1.51
    src/macsys.lisp. Closing this report as fixed.

    This fixes the above pickapart example and also stuff like
    dispfun and ldisplay which showed the same wrong behavior.
    E.g. before patch:

    (%i1) ldisplay (a, b, c);
    (%t1) a = a

    (%t2) b = b

    (%t3) c = c

    (%o3) [%t1, %t2, %t3]
    (%i3) foo;
    (%o3) foo

    after patch:

    (%i1) ldisplay (a, b, c);
    (%t1) a = a

    (%t2) b = b

    (%t3) c = c

    (%o3) [%t1, %t2, %t3]
    (%i4) foo;
    (%o4) foo


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks