Re: compiling with -DSCM_DEBUG=1

[Ken Raeburn]

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