I had a rather mysterious problem that now seems to have been
attributable to dyn.load()ing the same object twice in one R session
and I would be curious to know if this is a known issue, or something
that I should try to document further:
I had a single fortran subroutine which I was making into a .so file
with the usual R CMD SHLIB ritual. Then I would run a test problem
which involved dyn.load()ing the .so object, sourcing an R function
that called .Fortran, generating some random data and finally invoking
the R function when I sourced a file that looked like this:
# Initial test of parq algorithm
p <- 30
n <- 200
x <- matrix(rnorm(p*n),n,p)
y <- rnorm(n)
dyn.load("parq.so")
source("parq.q")
z <- parq(x,y,lambda = -1)
That is z contained a perfectly sensible result, but when I sourced this
file a second time and then tried to look at "z" the R process hung.
This
happened on both my old G5 desktop running 2.7.1 and on a new intel
mac-pancake running 2.7.1. However, on several other machines 3
linuxes and one solaris everything was copasetic, no hangups after
the second invocation.
After much agonizing under the assumption that there was something
wrong with memory allocation in my fortran -- a hypothesis that had
quite a lot of historical support -- I finally tried just running the
parq
function without the double invocation of dyn.load and this worked
perfectly. From which I draw the moral:
Don't dyn.load twice, it's not (mac)-nice.
url: www.econ.uiuc.edu/~roger Roger Koenker
email [EMAIL PROTECTED] Department of Economics
vox: 217-333-4558 University of Illinois
fax: 217-244-6678 Champaign, IL 61820
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
