Addendum:
unloading and reloading deSolve.so does indeed fix the problem:
library.dynam.unload("deSolve", libpath=paste(.libPaths()[1], "//deSolve",
sep=""))
library.dynam("deSolve", package="deSolve", lib.loc=.libPaths()[1])
However, this is a little clunky, and seems like overkill. Does anybody
have an idea for a more elegant workaround?
On Wed, Nov 6, 2013 at 11:20 AM, Adam Clark <atcl...@umn.edu> wrote:
> I'm having trouble running the "ode" function from the "deSolve" package.
>
> I am running RStudio under Ubuntu 13.1
>
> I am running ode() on compiled code that returns delta values using the .C
> convention. While I can include an example of the code, I suspect that it
> will not be helpful, since the problem is not replicable among systems
> (e.g. Solaris or Mac).
>
> When I call ode() on my compiled code, it occasionally will return:
>
> Error in .C("unlock_solver") :
> "unlock_solver" not resolved from current namespace (deSolve)
>
>
> All subsequent calls to ode() return the same error message, regardless of
> what I run. The problem is resolved only if I restart RStudio. However,
> since I am running many iterations of this command, I would like to find a
> way to resolve this without restarting RStudio.
>
> If I call: is.loaded("unlock_solver", PACKAGE="deSolve"), R returns TRUE.
>
> If I call: .C("unlock_solver"), R returns:
> list()
>
> If I first unload "deSolve" using
> detach("package:deSolve", unload=TRUE), deSolve disappears from my
> search() space, but is.loaded("unlock_solver", PACKAGE="deSolve") still
> returns TRUE. If I reload deSolve, the problem persists.
>
> Based on what I have read in the help files on namespace conventions in
> packages, I suspect that the problem is that the .C function
> "unlock_solver" is not corrected loaded, or was unloaded but not marked as
> unloaded.
>
> I have two guesses for what is going on:
> 1) "unlock_solver" was loaded using the library.dynam() function, but
> unloaded using the dyn.unload() function. As I understand it, this would
> leave a blank entry in the namespace, leading R to think that
> "unlock_solver" is loaded, even though the function no longer does
> anything. However, even when deSolve is working correctly,
> .C("unlock_solver") returns a blank list, so this may not be the case.
>
> 2) Some call deep in deSolve is not pointed towards the right package, and
> therefore cannot find "unlock_solver".
>
> From the source code for deSolve, posted at
> https://r-forge.r-project.org/scm/viewvc.php/pkg/deSolve/src/deSolve_utils.c?view=log&root=desolve&pathrev=344,
> "unlock_solver"
> seems to be a pretty simple function, inside the deSolve_utils.c file:
>
> void unlock_solver(void) {solver_locked = 0;}
>
> This command is a pretty recent addition to deSolve (it appeared somewhere
> between revision 319 and 324), and is meant to "prevent nesting of solvers
> that have global variables", according to the change annotation.
>
>
> In any case, I'd like to find a way to specifically unload "unlock_solver"
> and reload it, or barring that, unload as many of the DLL's associated with
> deSolve as possible and reload them. I suspect that this will solve my
> problems.
>
> Many thanks, and sorry if this is a silly question,
> Adam
>
> --
> Adam Clark
> University of Minnesota, EEB
> 100 Ecology Building
> 1987 Upper Buford Circle
> St. Paul, MN 55108
> (857)-544-6782
>
--
Adam Clark
University of Minnesota, EEB
100 Ecology Building
1987 Upper Buford Circle
St. Paul, MN 55108
(857)-544-6782
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
