guile-devel
[Top][All Lists]
Advanced

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

Re: compiling with -DSCM_DEBUG=1


From: Andy Wingo
Subject: Re: compiling with -DSCM_DEBUG=1
Date: Sat, 14 Nov 2009 12:46:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hi,

On Sat 31 Oct 2009 16:42, Neil Jerram <address@hidden> writes:

> 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 ...)
[...]
> 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?

This diagnosis sounds about right. Actually, you will never see the env
formals form1 ..., it's all in the new improper-list format. I haven't
determined if Ken's patch is correct, though.

Andy
-- 
http://wingolog.org/




reply via email to

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