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
[[alternative HTML version deleted]]
On 06/11/2013 17:20, Adam Clark 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 wouldWho said it was unloaded? That it is not by default is explicit in ?detach.> 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.I am not sure why you think it is reasonable to do that. Clearly the designers of deSolve did not think so, as it does not have an .onUnload action. > library(deSolve) > names(getLoadedDLLs()) [1] "base" "utils" "methods" "grDevices" "graphics" "stats" [7] "deSolve" "tools" > detach("package:deSolve", unload=TRUE) > names(getLoadedDLLs()) [1] "base" "utils" "methods" "grDevices" "graphics" "stats" [7] "deSolve" "tools"> Many thanks, and sorry if this is a silly question,It is really an R-devel question: see the posting guide. In particular OSes differ in how (or even if) they can reload DLLs, and the details are way too technical for R-help. In any case, there are no reproduction instructions here: see the posting guide.> Adam >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
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 <atclark@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]]