From murdoch at stats.uwo.ca  Wed Oct 13 16:09:14 2004
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Wed Oct 13 16:09:17 2004
Subject: [Rd] RE: [R] debugging non-visible functions
In-Reply-To: <Pine.LNX.4.44.0410131124080.4310-100000@gannet.stats>
References: <3A822319EB35174CA3714066D590DCD504AF852A@usrymx25.merck.com>
	<Pine.LNX.4.44.0410131124080.4310-100000@gannet.stats>
Message-ID: <u1dqm0tuq4l5j0ach9f27fg49bnaqlbe8u@4ax.com>

On Wed, 13 Oct 2004 11:38:00 +0100 (BST), Prof Brian Ripley
<ripley@stats.ox.ac.uk> wrote :

>> > From: Prof Brian Ripley
>> [snip]
>> > Luke Tierney recommends removing the NAMESPACE file during 
>> > development of 
>> > a package if you need frequent access to debug/change its functions.
>> 
>> But isn't that a bit troublesome if there is a shared object to be loaded in
>> the NAMESPACE file?  If I rename the NAMESPACE file to something else, I
>> would need to put back library.dynam() in .First.lib(), right?  I thought it
>> might work to write some code in .First.lib that checks for existence of
>> NAMESPACE, and call libaray.dynam() conditionally.  Does this sound about
>> right?

For 2.1.0, would it be reasonable to extend debug() the way ? was
extended?  E.g. allow

debug(plot(x))

and have the debugging flag be set on the appropriate function,
whatever and wherever it happens to be?  There's some ambiguity with
S3 methods (did you want to debug the generic or the method?), but I
think defaulting to debugging of the method would be reasonable.  (And
I think ? needs to be extended to handle S3 methods too, but that's a
different question.)

Duncan Murdoch


[Rd] RE: [R] debugging non-visible functions
Duncan Murdoch