Skip to content

Forking and adapting an R package

3 messages · Duncan Murdoch, timo at timogrossenbacher.ch, Gabriel Becker

#
On 12/07/2016 7:28 AM, timo at timogrossenbacher.ch wrote:
This is more of an R-devel question, so I've posted my followup there 
(as well as a private copy to you).

The fact that you've forked the package shouldn't matter.  You are 
working in RStudio, so the way to work with a package is:

1.  Open the project consisting of your local package.
2.  In the Build pane, click on "Build and Reload".

What "Build and reload" does is to install the package from the source 
in the project, then restart R and load the installed package.

Test your code in this new R session.  If you're working on a vignette, 
you can open the vignette, and execute the code chunks one by one.

If they all succeed in that context, they still might not when you run 
checks:  it *won't* have your package loaded when it compiles a 
vignette.  You need to put an explicit

library(hexbin)

in one of the code chunks.

Duncan Murdoch
#
Okay, I'm now subscribed to this list, too.
This works. devtools::build() though throws the same error with the vignette as
with devtools::check(). See below.
Ok. But how do I debug the source code of that package? I.e. I want to call a
function from that package from another, external script (that is not part of
that project), and then jump into the function execution and debug it. 
Because when it's built it's no longer "plain source code", or am I completely
wrong with this? Or/and do I have to make the  external script part of the
hexbin project?
This is actually done in the chunk that fails (it fails on the last line here).

library("grid")
library("hexbin")
x <- rnorm(1000)
y <- rnorm(1000)
##-- Hexagon Bins: --
hbin <- hexbin(x,y, xbins = 25)

            
2 days later
#
I'm a little unclear what you're asking, so I may be off base here -
apologize if so - but it sounds like you want

debug(hexbin)


before you call the function. Note that that hexbin is referring function
you will call, NOT the name of the package which happens to be the same
thing. This will cause R-level hexbin closure (function) to be debugged
when it is called.

Note that this won't (particularly easily) work in an Rmd, I think. It
would be much easier to simply run the offending code in your session, as
debugging is interactive anyway.

Is your question how to debug the parts of hexbin that  IIRC call down to C
code?

Best,
~G
On Wed, Jul 13, 2016 at 12:13 AM, <timo at timogrossenbacher.ch> wrote: