[R] two questions

Martin Maechler maechler at stat.math.ethz.ch
Fri Jan 22 10:26:39 CET 1999


>>>>> "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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list