Re: compiling with -DSCM_DEBUG=1

[Neil Jerram]

Neil Jerram <address@hidden> writes:

> Ken Raeburn <address@hidden> writes:
>
>> At Andy's suggestion, re-posting the still-pending part that needs
>> review.  Without these changes, the code in the loops applies SCM_CAR
>> to non-pair objects.
>>
>> GUILE_AUTO_COMPILE=0                                 \
>>      ../meta/uninstalled-env                 \
>>      guile-tools compile -Wunbound-variable -o "ice-9/debugger.go"
>> "../../
>> guile/module/ice-9/debugger.scm"
>> Non-pair accessed with SCM_C[AD]R: `#<procedure #f (#{class\ 2865}#
>> . #{initargs\ 2866}#)>'
>>
>> This patch is my best guess, but I'm not very familiar with the code...
>
> I don't know...  Even though this code is destined for the dustbin soon
> anyway, I'd prefer if we understood it!  I'll have another go at working
> it out over the weekend.

OK, I think I mostly understand this now.  The method cache is a vector,
and this code expects each entry in the vector to look like

(TYPE1 ... ENV FORMALS FORM1 ...)

where TYPE1 ... are the types (classes) that the method is specialised
for, ENV is the environment where the method was defined, FORMALS are
the formals and FORM1 ... is the method's code.

So the comment "More arguments than specifiers => CLASS != ENV" means
"We don't have to check for reaching the end of the list of TYPEs,
because then we'll be comparing the class of the next actual arg against
ENV, and there is no possibility of those matching, so we'll exit the
loop."

Which makes sense, if the cache entry really does have the above form.
But apparently it doesn't.  I added this just inside the loops:

      if (!scm_is_pair (z))
        {
          scm_write (z, scm_current_output_port ());
          scm_newline (scm_current_output_port ());
          scm_write (SCM_SIMPLE_VECTOR_REF (method_cache,
                                            hash_value),
                     scm_current_output_port ());
          scm_newline (scm_current_output_port ());
          abort ();
        }

and then the build fails when it gets to compiling (ice-9 debugger):

GUILE_AUTO_COMPILE=0                                    \
        ../meta/uninstalled-env                 \
        guile-tools compile -Wunbound-variable -o "ice-9/debugger.go" 
"ice-9/debugger.scm"
#<procedure #f (#{class\ 2865}# . #{initargs\ 2866}#)>
(#<<class> <entity-class> 8c77990> #<<class> <keyword> 8c7a640> . #<procedure 
#f (#{class\ 2865}# . #{initargs\ 2866}#)>)

So there's at least this case where the cache entry has a different
form.  Actually I think this is a general change that Andy made a while
back - i.e. to form the old (ENV FORMALS FORM1 ...) part into a
procedure and store that in the cache instead.

Andy, can you confirm this?  Subject to that, I think that Ken's
proposed patch is correct, but it would also be good to remove or
clarify the "CLASS != ENV" comments, and to update the comments that
describe the cache entry layout (in objects.c and
oop/goops/dispatch.scm).

Thanks,
        Neil