On Oct 18, 2009, at 18:44, Neil Jerram wrote:
I've been trying to reproduce the guardian finalisation problem that
you
see with SCM_DEBUG==1 but, like Ludovic, I haven't had any luck. With
SCM_DEBUG=1 for the whole build (plus the SCM_GC_MARK_P change), I'm
afraid my machine grinds to a halt when it gets to goops.c - i.e. it
never finishes compiling goops.c, even when left for several hours.
And
with a more focussed patch - setting SCM_DEBUG_PAIR_ACCESSES to 1 only
in guardians.c, and DEBUG_GUARDIANS - I don't see any problem.
I wouldn't be surprised if it's platform- and compiler-dependent.
I've seen cases in Emacs, too, where turning on debugging versions of
macros causes compilation time to explode, especially if it results in
macros using their arguments multiple times when the arguments
themselves have now become complicated expressions. Several hours is
a new one on me, though... Often it helps to define inline or static
functions to encapsulate the work, instead of macros.
I haven't tried debug builds in a while. Now that the path problems
and other stuff have been taking care of, I should get back to that.
I'll probably want debugging options for my work with Emacs.
Your change looks straightforward, but the "More arguments than
specifiers" comment makes it look as though it might have been
intentional to let the !scm_is_pair (z) case through.
I don't fully understand what the comment means, though. Do you?
Specifically, what is the sense of `CLASS != ENV'?
Unfortunately, I don't; I was hoping someone more familiar with it
could check it.
Even if it's intended to fetch word 0 from a non-pair object at the
end, SCM_CAR is the wrong way to do it.
diff --git a/libguile/goops.c b/libguile/goops.c
These changes look good. Would you like to commit them?
Sure, I'll do that in a little bit...
Ken
