Simon,
Running dyn.load twice is certainly dumb, I just didn't realize that
it was also
dangerous. (And I was surprised, in retrospect, that it didn't also
cause
problems on our linux boxes.) I've put a toy example at:
http://www.econ.uiuc.edu/~roger/research/qss/toy.tar.gz
that I hope will be self explanatory. Thanks for looking into this,
of course
I recognize that this probably fits into the category of trimming my
toenails
with a chainsaw that shouldn't be covered by product liability -- even
if there
were product liability for R, which there isn't.
Roger
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
On Aug 26, 2008, at 8:32 AM, Simon Urbanek wrote:
Roger,
can you give us a simple, reproducible example, please? From your
description it's not clear to me what is your speculation and what
are the facts. Running dyn.load twice is very dangerous in general
unless you know what you're doing, especially with dylibs involving
Fortran, because those usually contain initializer functions that
may have unexpected side effects. This is common to all platforms,
not just Macs.
Cheers,
Simon
On Aug 25, 2008, at 18:23 , roger koenker wrote:
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
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
