Re: [Axiom-developer] Re: debugging

[Waldek Hebisch]

Camm Maguire wrote:
> Waldek Hebisch <address@hidden> writes:
> > I wrote:
> > > There are several functions involved.  In case of #<OBJNULL> using
> > > traces I see that |compDefineCapsuleFunction| function (defined
> > > in 'define.boot.pamphlet') gets:
> > > 
> > >  1> (|compDefineCapsuleFunction|
> > >          (DEF (|base|) (NIL) (NIL)
> > >               ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
> > > ...
> > > ...
> > > 
> 
> In which package is this?  Is it present in interpsys?
>

First a little correction: there are two versions on 
|compDefineCapsuleFunction|, one in 'define.boot.pamphlet' and
the second one in 'br-saturn.boot.pamphlet'.  Normally version
from 'br-saturn.boot.pamphlet' is in use.  

All functions in question are defined in "BOOT" package.  The
files are autoloaded.  To get the traces I did (in the algebra
build directory):

(export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export 
DAASE=/h/axp62/wh-sandbox/src/share; 
/h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
)lisp (|oldCompilerAutoloadOnceTrigger|)
)lisp (trace |compElt| |compileCases| |compDefineCapsuleFunction| |compForm1|)
)compile "DFLOAT.spad"
 
That produced about 150 Mb trace.

To be extra careful you may also do (before tracing):

)lisp (|browserAutoloadOnceTrigger|)

to load correct version of |compDefineCapsuleFunction|.

> > > 
> > > It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
> > > handled in 'compiler.boot.pamphlet':
> > > 
> > > 
> > >     2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
> > > 
> > >       3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
> > > ....
> > > ....
> > >       <3 (|compElt|
> > >              ((|call| (XLAM |ignore| '#<OBJNULL>)) $
> > > 
> > 
> 
> Can you please post the full call to compElt in 3> above?
>

The third argument is large (75 kb), so I have put call to |compElt|
and return value at:

http://www.math.uni.wroc.pl/~hebisch/compElt.txt

 
> > I have narrowed down the problem:
> > 
> >    compiling exported base : () -> PositiveInteger
> >   1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
> >     2> (|optDeltaEntry| |Zero| ($) $ CONST)
> >       3> (|compiledLookup| |Zero| ((|DoubleFloat|))
> >              #<vector 0000000002b66f90>)
> >       <3 (|compiledLookup|
> >              (|makeSpadConstant|
> >                  #<compiled-function |DFLOAT;Zero;$;15|>
> >                  #<vector 0000000002b66f90> 25))
> >     <2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> >   <1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> > 
> > 
> > |makeSpadConstant| calls its argument.  Checking this I get:
> > 
> 
> Why are there 3 arguments above?  The definition appears to take one.
>

(|makeSpadConstant|
                 #<compiled-function |DFLOAT;Zero;$;15|>
                 #<vector 0000000002b66f90> 25)

is not a call, it is just a list of length four.  This list is
passed to the SPADCALL macro with the effect that car of the list
is called with cdr as na argument (using SPADCALL is an abuse here...).
 
> > )lisp (|DFLOAT;Zero;$;15| nil)
> > 
> > Value = #<OBJNULL>
> > 
> > )lisp (disassemble '|DFLOAT;Zero;$;15|)
> > ^M
> >    >> System error:
> >    Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: 
> > Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of 
> > file:
> > 
> 
> This is a simple .h file naming bug I'll try to fix soon.
> 
> 
> > Looking at "/tmp/gazonk0.c" I see:
> > 
> > 
> > #include "cmpinclude.h"
> > #include "gazonk0.h"
> > void init__tmp_gazonk0(){do_init((void *)VV);}
> > /*      local entry for function DFLOAT;Zero;$;15       */
> > 
> > static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
> > 
> > object V2;
> > {        VMB1 VMS1 VMV1
> >         goto TTL;
> > TTL:;
> >         /*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> >         {fixnum V3;
> >         V3= (fixnum)0;
> >         V3= (fixnum)0;
> >         {double V4 = (    1.    )*((fixnum)0);VMR1
> >         (V4);}}
> >         /* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> >         {double V5 = lf(Cnil);VMR1
> >         (V5);}
> 
> This is correct but unpleasant C which needs tidying.  There can be
> extra 'unwinds' scheduled currently in GCL -- these are harmless but
> misleading.  The function returns from the macro VMR1.  I'll try to
> clean this up too.
> 

I mean that 'lf(Cnil)' looks strange -- Axiom expects double
precision 0 as the result.

> Why does this function take an argument which is ignored -- is this right? 
> 

Yes, |DFLOAT;Zero;$;15| is a Spad function.  All Spad function receive
an extra argument:  the domain or package to which they belong.  This
extra argument appears last in the argument list.  |DFLOAT;Zero;$;15|
does not need any extra information from its domain, so the
argument is ignored, but in general it may be used.  If one wants
to pass "correct" value of the argument one has to do:

)lisp (|DoubleFloat|)
)lisp (|DFLOAT;Zero;$;15| (|DoubleFloat|))

the first call to |DoubleFloat| is triggers autolading of DFLOAT.o file.

If I do the above in 2.6.8 compiled interpsys I get floating point
0.  In 2.7.0 compiled interpsys (the one from the failing build) I get
#<OBJNULL>
 

-- 
                              Waldek Hebisch
address@hidden