gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: Interpretation of random tester output


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: Interpretation of random tester output
Date: 02 Mar 2004 22:03:44 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Paul F. Dietz" <address@hidden> writes:

> Camm Maguire wrote:
> > Greetings, and thanks, Paul!
> > 1) Your clear and very helpful explanations agree with my guesses as
> >    to what the output was saying.  But I'm still having a quandary.
> >    After adjusting for the latest fix, I'm running the tester again
> >    and found another form.  I eval the :unoptimized-form with
> >    arguments given in :vals, then the optimized form, and lastly I
> >    compile the latter and run the compiled version on the same
> >    arguments, and come up with the same answer all three times.  (I
> >    take the (lambda form, and change lambda to defun foo, could that
> >    possibly be the difference?)
> >    The example of which I speak is attached.
> 
> This looks like it wasn't pruned...
> 
> > 2) How long does one have to abort and find the g, y etc. variables
> >    set?
> 
> ...LOOP-RANDOM-INT-FORM does groups of 2000 iterations before it
> reduces anything.  So, wait for those progress numbers to reach
> the next line.  I should probably make it do this continually.
> 
> 
> > 3) What can :kind be besides optimized-form?
> 
> It can be a (printed representation of) a compiler error, meaning
> the compile aborted, it can be :(un)optimized-form, meaning an error
> occured during evaluation of the (un)optimized form, or it can
> be :different-results, meaning they evaluated successfully, but
> computed different things.
> 
> The irreproducibility of the error might be related to stack
> corruption, or some problem in compiling the code of random-int-form.lsp
> itself.  You might try just loading random-int-form.lsp instead of
> compiling and loading it (this should not slow down the testing
> significantly.)
> 

OK and loading interpreted, but the results so far seem the same.  I
have maybe one or two different-results errors, which (I think) I can
track down fairly easily, and a handful of optimized-form-error errors
which I cannot reproduce.  Is the best thing for me to do to set a
break when this kind is set in random-int-form.lsp?  Isn't there a way
to trap and report the eval error like is done with the compilation error?

Take care,



>       Paul
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]