From peter.meilstrup at gmail.com  Fri Jan 17 11:01:42 2014
From: peter.meilstrup at gmail.com (Peter Meilstrup)
Date: Fri, 17 Jan 2014 02:01:42 -0800
Subject: [Rd] How to debug an R package (with C code)
In-Reply-To: <CADwqtCOVoP_okamqtRdfMNc-rE7VwE5gqAC1oM1+q5D0ULBqyg@mail.gmail.com>
References: <e6b8123fd4af42d78ce33ce3fee50851@SIXPR01MB224.apcprd01.prod.exchangelabs.com>
	<CAGSjAUCK1kTfpRKnuj6f4dieiFysqd4vOWJOSqkyzETr2uMkAg@mail.gmail.com>
	<CADwqtCOVoP_okamqtRdfMNc-rE7VwE5gqAC1oM1+q5D0ULBqyg@mail.gmail.com>
Message-ID: <CAJoaRhbeSJ9oLL5mPNOrZ59qbesz=RG0B8qDrnMQMvR8FrTVkg@mail.gmail.com>

On Fri, Jan 17, 2014 at 12:43 AM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:
> There were some deeper issues with what you asked, though. Sourcing an R
> file will have no effect on a package in the namespace at all unless you
> are using something like ESS's developer mode which sources the file into
> the package namespace. Furthermore, C code included in R packages is only
> compiled at installation from source or binary build time.
>
> Even if you are using a developer mode, sourcing an R file will have no
> effect on a) the shared object library (DLL/so/dylib) available in the R
> session, nor which shared objects are associated with the package. There
> are ways to unload shared libraries within an R session, but personally I
> tend to avoid them. The best way of being absolutely sure that the right
> shared library is getting used is to reinstall the package, then close the
> R session and restart.

I value having a short turnaround time in debugging over such absolute
surety, so I would recommend using load_all from Hadley's devtools
package, which is usually able to recompile and reload the library
without restarting R. I think the OP indicated that they are using
RStudio, which should have a way to drive devtools (still, "source"
would be the wrong command.)

Peter



[Rd] How to debug an R package (with C code)
Peter Meilstrup