Debugging code in modules

[mbojan]

In the comment #218 (comment) @klmr writes that all the standard R debugging tools should work. I however have problems using debugonce() with functions which are not exported from modules. If module has an non-exported fun()ction then

1. Calling debugonce(fun) won't work because there is no fun in globalenv
2. Calling debugonce(module$fun) won't work either because it is not exported

Suggestions?
It would be a great topic for a short vignette...

[klmr]

For debugging purposes etc., a module’s non-exported functions can be accessed via the module namespace. In turn, the module namespace is (currently) accessible via

mod_ns = attr(module, 'namespace')

# … and then:
debugonce(mod_ns$fun)

I’m still torn on whether this is supposed to be part of the “public API” of ‘box’, which is why it currently isn’t documented (i.e. it’s — at least in principle — subject to change). However, I can see that some way of accessing the namespace and/or non-exported names is needed. Maybe a new scope access operator (analogous to :::), e.g. mod%:::%fun?

It would be a great topic for a short vignette...

Agreed! But in addition to the above, I’m currently unsure where this would fit. A vignette on debugging? A vignette on ‘box’ module internals? For the latter, there’s The hierarchy of module environments, which could be extended with technical details; however, as noted at the top of that vignette, I don’t expect regular users of ‘box’ to actually read this (nor to need to).

[mbojan]

For debugging purposes etc., a module’s non-exported functions can be accessed via the module namespace. In turn, the module namespace is (currently) accessible via

mod_ns = attr(module, 'namespace')

# … and then:
debugonce(mod_ns$fun)

Great! Thanks!

I’m still torn on whether this is supposed to be part of the “public API” of ‘box’, which is why it currently isn’t documented (i.e. it’s — at least in principle — subject to change). However, I can see that some way of accessing the namespace and/or non-exported names is needed. Maybe a new scope access operator (analogous to :::), e.g. mod%:::%fun?

I agree with the need. The operator seems logical. I can't think of downsides at this moment.

It would be a great topic for a short vignette...

Agreed! But in addition to the above, I’m currently unsure where this would fit. A vignette on debugging? A vignette on ‘box’ module internals? For the latter, there’s The hierarchy of module environments, which could be extended with technical details; however, as noted at the top of that vignette, I don’t expect regular users of ‘box’ to actually read this (nor to need to).

I was thinking of a dedicated one with some examples of debug()ging and trace()ing.