I'm attaching a new/improved set of patches (against this afternoon's
CVS) that address some of the things you suggested/pointed out. I'll
reply to the points separately, but basically:
These patches allow :lisp to be used in the testsuite .mac files in a
sensible way. At the moment, they only allow one to use it for the
first of the two lines. Allowing both probably wouldn't be
particularly hard, but: it seems that atm the second line is just read
in and then compared via batch-equal-check: no "eval"ing is done. I'd
be interested to know what people think is the right thing to do - is
there a sensible set of semantics for :lisp as the "second line" in
the testsuite files?
On Mon, Mar 10, 2008 at 2:40 AM, Robert Dodier <robert.dodier at gmail.com> wrote:
> On 3/3/08, Rupert Swarbrick <rswarbrick at googlemail.com> wrote:
>
> > 1) lisp-eval and lisp-quiet (which are called by break-call when you
> > do :lisp or :lisp-quiet) now return something, specifically the list of
> > values. Before, :lisp (+ 1 2) would print 3 with princ, but left it at
> > that, so calling code definitely couldn't get at the results.
>
> OK by me. A question: what is returned if the :lisp stuff
> returns multiple values -- does :lisp return all of them or only
> the primary value?
As of this new version, it returns all of them in an (mlist simp)
list, so (values 1 2) gives [1,2] as far as the testsuite is
concerned. The code to do this is mdebug.lisp:721.
> > 2) test-batch now uses dbm-read to get new lines. This doesn't break
> > anything... EXCEPT: A stream ending in some whitespace including actual
> > spaces/tabs causes an error break in dbm-read.
>
> Well, whitespace seems to creep in at random ... Can you take
> a look at DBM-READ and fix it so that it doesn't barf on trailing whitespace?
Done.
> > 4) There's a test!!! (-: In rtest_testsuite.mac, and yes it should
> > probably be made more complete, but this at least shows that everything
> > I changed works I hope.
>
> I see the tests look like
> :lisp (foo)
> bar$
>
> Does it work with :lisp in the expected result? I am imagining that
> the first use of :lisp would be to specify exact results so that
> simplification or the lack of it doesn't cause test failures.
>
Not atm: see above. Not sure what the right thing to do is.
> Thanks for looking into to this. Let's keep the ball rolling.
Er, I'm only pushing it along slowly, sorry! But still I'd like to get
this finished and maybe I'll be a little more proactive this time
round.
Rupert
P.S. One of the problems that me getting round to this so slowly
caused was that of course CVS is being updated in the interim. But
I've been using a local git copy and it's working absolutely
fantastically - especially since I found rebasing this afternoon! Does
anyone have any other tips for doing stuff like this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 27-03-08.patch
Type: text/x-diff
Size: 6002 bytes
Desc: not available
Url : http://www.math.utexas.edu/pipermail/maxima/attachments/20080327/af95bf6e/attachment-0001.bin