>>>>> "Jim" == Jim Lindsey <jlindsey at
alpha.luc.ac.be> writes:
Jim> 1. Brian has suggested that I check that the proper version of my
Jim> required library, rmutil, is loaded by the other libraries. Is
Jim> there any way of checking library versions when loading them?
the library can define a variable "rmutilVersion".
you would do
library(rmutil)
if(!exists("rmutilVersion") && rmutilVersion < 2.1)
stop("You must use at least version 2.1 of the `rmutil'
package")
What would be nicer and doesn't exist yet,
is something like
require(rmutil, version.minimal = 2.1)
Jim> 2.
Jim> A year or two ago, there was talk of having an option when .C and
Jim> .Fortran are used such that copies of the arguments were not
Jim> made. Has this ever been implemented?
Yes. (Jim, it's too bad you haven't subscribed to R-devel (it was a
topic there)
I still think R package writers should)
help(.Fortran) (or .C) gives
Foreign Function Interface
.C(name, ..., NAOK=FALSE, DUP=TRUE)
.Fortran(name, ..., NAOK=FALSE, DUP=TRUE)
Arguments:
.......
DUP: if `TRUE' then arguments are ``duplicated'' before
their address is passed to C or Fortran.
......
......
Note:
`DUP=FALSE' is dangerous.
There are two important dangers with `DUP=FALSE'. The
first is that garbage collection may move the object,
resulting in the pointers pointing nowhere useful and
causing hard-to-reproduce bugs.
The second is that if you pass a formal parameter of
the calling function to `.C'/`.Fortran' with
`DUP=FALSE', it may not necessarily be copied. You may
be able to change not only the local variable but the
variable one level up. This will also be very hard to
trace.
1. If your C/Fortran routine calls back any R function
including `S_alloc'/`R_alloc' then do not use
`DUP=FALSE'. Do not even think about it. Calling
almost any R function could trigger garbage collection.
2. If you don't trigger garbage collection it is safe
and useful to set `DUP=FALSE' if you don't change any
of the variables that might be affected, e.g.,
`.C("Cfunction", input=x, output=numeric(10))'.
In this case the output variable didn't exist before
the call so it can't cause trouble. If the input vari-
able is not changed in `Cfunction' you are safe.
---
Inspite of this, I've been entering several DUP=FALSE
statements in places,
**AFTER careful consideration of the above note**
Martin Maechler <maechler at stat.math.ethz.ch>
http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum SOL G1; Sonneggstr.33
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1086 <><
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._