[Rd] Failure to load the recommended package Matrix (Was: [R] Can one get a list of recommended packages?)
On Sun, Jun 13, 2010 at 8:28 AM, Uwe Ligges wrote: > > > On 13.06.2010 01:09, Dr. David Kirkby wrote: >> >> On 06/12/10 05:27 PM, Douglas Bates wrote: >>> >>> On Sat, Jun 12, 2010 at 8:37 AM, Dr. David Kirkby >>> wrote: R 2.10.1 is used in the Sage maths project. Several recommended packages (Matrix, class, mgcv, nnet, rpart, spatial, and survival) are failing to build on Solaris 10 (SPARC). >>> >>> Have you checked the dependencies for those packages? Some require GNU >>> make. >> >> We used GNU make. >> We would like to be able to get a list of the recommended packages for R 2.10.1, but ideally via a call to R, so it is not necessary to update that list every time a new version of R is released. We do not want to access the Internet to get this information. >>> Is there a way in R to list the recommended packages? >>> >>> I'm not sure I understand the logic of this. If you are going to >>> build R then presumably you have the tar.gz file which contains the >>> sources for the recommended packages in the subdirectory >>> src/library/Recommended/. Why not get the list from there? >> >> The reason is when the version of R gets updated in Sage, then someone >> will have to check that list again, and more than likely fail to do so, >> with the result tests will fail since packages do not exist, or worst >> still we will be unaware they have failed to build properly. >> >> Therefore, being able to get them from a command would be useful, but >> can understand if that is not possible. >> >>> $ cd ~/src/R-devel/src/library/Recommended/ >>> $ ls *.tgz >>> boot.tgz codetools.tgz lattice.tgz mgcv.tgz rpart.tgz >>> class.tgz foreign.tgz MASS.tgz nlme.tgz spatial.tgz >>> cluster.tgz KernSmooth.tgz Matrix.tgz nnet.tgz survival.tgz >> >> OK, thank you for that list. >> Better still, is there a way to list the recommended packages which have not been installed, so getting a list of any failures? >>> >>> Again, this seems to be a rather convoluted approach. Why not check >>> why the packages don't install properly? >> >> R had built, and the failure of the packages to build was not very >> obvious, since it did not cause make to exit with a non-zero exit code. >> Nobody had noticed until very recently that there was a problem. >> >> Therefore I proposed to make a test of the packages that should have >> been installed, and ensure they actually all had. >> >> You need to be aware that R is just one part of Sage. Building the whole >> of Sage takes a long time (>24 hours on some computers) so needless to >> say, people will not view every line of error messages. The fact that >> 'make' succeeded left us a false sense of security, when later it was >> realsed there were problems when R run its self-tests. >> >> Dave > > > But if you really want to sense some security, you should really run > make check-all > after the installation, particularly since you are on a platform that is not > really mainstream any more. > > Uwe Ligges And if you look at the other R-help message posted by David Kirby you will find a link to the trouble ticket report in Sage as http://trac.sagemath.org/sage_trac/ticket/9201 which, fortunately, contains a link to the compilation log file http://sage.math.washington.edu/home/mpatel/trac/8306/r-2.10.1.p2.log The log file correctly points out the problem, which is that the compiled shared object for the Matrix package can't be loaded because it contains references to objects in another library from the compiler and that library is not on the LD_LIBRARY_PATH during the dyn.load from within R. So the original poster needs to look at how the DLLpath is being configured. Exactly how this ended up as a request to somehow determine a list of recommended packages on the fly from within R is a wonderful example of misguided speculation but has nothing whatsoever to do with the problem. Even the idea that there are a host of other recommended packages that failed to compile because they depend on the Matrix package is pure speculation and, of course, hopelessly wrong. The installation of the Matrix package failed because the check on whether the package could be loaded failed. The compilation of the recommended packages stopped at that point. The other packages weren't compiled because they came after the Matrix package in the compilation sequence. Problems in compilation of R or its recommended packages should be reported on the R-devel mailing list and I have moved this thread from R-help to R-devel. Admittedly it was the original poster of the Sage trouble ticket who decided that the issue to focus on was missing recommended packages. That's a red herring. The issue is the visibility of the some of the libraries from the gcc toolchain when R is loading a package. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 classes and S3 generic functions
A general goal for the next version of R is to make S4 and S3 play
better together.
As mentioned in a previous thread, one limitation has been that S3
generic functions, specifically the UseMethod() call, did not make use
of S4 inheritance when dispatching on general S4 objects.
This has been fixed in a version committed today (updated to rev 52267).
The code change is not large, but it has some general implications.
Mainly, in applying S3 generic functions to objects from S4 classes, the
default recommendation is to define an S3 method for the class, when
possible, and then set that definition to be the S4 method as well.
The section "Methods for S3 Generic Functions" of the ?Methods
documentation in the (new) version has details and points to examples.
The text of that section is appended below.
John
==
Methods for S3 Generic Functions:
S4 methods may be wanted for functions that also have S3 methods,
corresponding to classes for the first formal argument of an S3
generic function-either a regular R function in which there is a
call to the S3 dispatch function, 'UseMethod', or one of a fixed
set of primitive functions, which are not true functions but go
directly to C code. In either case S3 method dispatch looks at the
class of the first argument or the class of either argument in a
call to one of the primitive binary operators. S3 methods are
ordinary functions with the same arguments as the generic function
(for primitives the formal arguments are not actually part of the
object, but are simulated when the object is printed or viewed by
'args()'). The "signature" of an S3 method is identified by the
name to which the method is assigned, composed of the name of the
generic function, followed by '"."', followed by the name of the
class. For details, see S3Methods.
To implement a method for one of these functions corresponding to
S4 classes, there are two possibilities: either an S4 method or an
S3 method with the S4 class name. The S3 method is only possible
if the intended signature has the first argument and nothing else.
In this case, the recommended approach is to define the S3 method
and also supply the identical function as the definition of the S4
method. If the S3 generic function was 'f3(x, ...)' and the S4
class for the new method was '"myClass"':
f3.myClass <- function(x, ...) { . }
setMethod("f3", "myClass", f3.myClass)
The reasons for defining both S3 and S4 methods are as follows:
1. An S4 method alone will not be seen if the S3 generic
function is called directly. However, primitive functions
and operators are exceptions: The internal C code will look
for S4 methods if and only if the object is an S4 object. In
the examples, the method for '`[`' for class '"myFrame"' will
always be called for objects of this class.
For the same reason, an S4 method defined for an S3 class
will not be called from internal code for a non-S4 object.
(See the example for function 'Math' and class '"data.frame"'
in the examples.)
2. An S3 method alone will not be called if there is _any_
eligible non-default S4 method. (See the example for function
'f3' and class '"classA"' in the examples.)
Details of the selection computations are given below.
When an S4 method is defined for an existing function that is not
an S4 generic function (whether or not the existing function is an
S3 generic), an S4 generic function will be created corresponding
to the existing function and the package in which it is found
(more precisely, according to the implicit generic function either
specified or inferred from the ordinary function; see
'implicitGeneric'). A message is printed after the initial call to
'setMethod'; this is not an error, just a reminder that you have
created the generic. Creating the generic explicitly by the call
'setGeneric("f3")'
avoids the message, but has the same effect. The existing function
becomes the default method for the S4 generic function. Primitive
functions work the same way, but the S4 generic function is not
explicitly created (as discussed below).
S4 and S3 method selection are designed to follow compatible rules
of inheritance, as far as possible. S3 classes can be used for any
S4 method selection, provided that the S3 classes have been
registered by a call to 'setOldClass', with that call specifying
the correct S3 inheritance pattern. S4 classes can be used for any
S3 method selection; when an S4 object is detected, S3 method
selection uses the contents of 'extends(class(x))' as the
equivalent of the S3 inheritance (the inheritance is cached after
the first call).
Re: [Rd] S4 classes and S3 generic functions
On Sun, Jun 13, 2010 at 6:58 PM, John Chambers wrote:
> A general goal for the next version of R is to make S4 and S3 play better
> together.
>
> As mentioned in a previous thread, one limitation has been that S3 generic
> functions, specifically the UseMethod() call, did not make use of S4
> inheritance when dispatching on general S4 objects.
>
> This has been fixed in a version committed today (updated to rev 52267).
> The code change is not large, but it has some general implications. Mainly,
> in applying S3 generic functions to objects from S4 classes, the default
> recommendation is to define an S3 method for the class, when possible, and
> then set that definition to be the S4 method as well.
>
> The section "Methods for S3 Generic Functions" of the ?Methods documentation
> in the (new) version has details and points to examples. The text of that
> section is appended below.
>
> John
>
> ==
> Methods for S3 Generic Functions:
>
> S4 methods may be wanted for functions that also have S3 methods,
> corresponding to classes for the first formal argument of an S3
> generic function-either a regular R function in which there is a
> call to the S3 dispatch function, 'UseMethod', or one of a fixed
> set of primitive functions, which are not true functions but go
> directly to C code. In either case S3 method dispatch looks at the
> class of the first argument or the class of either argument in a
> call to one of the primitive binary operators. S3 methods are
> ordinary functions with the same arguments as the generic function
> (for primitives the formal arguments are not actually part of the
> object, but are simulated when the object is printed or viewed by
> 'args()'). The "signature" of an S3 method is identified by the
> name to which the method is assigned, composed of the name of the
> generic function, followed by '"."', followed by the name of the
> class. For details, see S3Methods.
>
> To implement a method for one of these functions corresponding to
> S4 classes, there are two possibilities: either an S4 method or an
> S3 method with the S4 class name. The S3 method is only possible
> if the intended signature has the first argument and nothing else.
> In this case, the recommended approach is to define the S3 method
> and also supply the identical function as the definition of the S4
> method. If the S3 generic function was 'f3(x, ...)' and the S4
> class for the new method was '"myClass"':
>
> f3.myClass <- function(x, ...) { . }
> setMethod("f3", "myClass", f3.myClass)
>
> The reasons for defining both S3 and S4 methods are as follows:
>
> 1. An S4 method alone will not be seen if the S3 generic
> function is called directly. However, primitive functions
> and operators are exceptions: The internal C code will look
> for S4 methods if and only if the object is an S4 object. In
> the examples, the method for '`[`' for class '"myFrame"' will
> always be called for objects of this class.
>
> For the same reason, an S4 method defined for an S3 class
> will not be called from internal code for a non-S4 object.
> (See the example for function 'Math' and class '"data.frame"'
> in the examples.)
>
> 2. An S3 method alone will not be called if there is _any_
> eligible non-default S4 method. (See the example for function
> 'f3' and class '"classA"' in the examples.)
>
> Details of the selection computations are given below.
>
> When an S4 method is defined for an existing function that is not
> an S4 generic function (whether or not the existing function is an
> S3 generic), an S4 generic function will be created corresponding
> to the existing function and the package in which it is found
> (more precisely, according to the implicit generic function either
> specified or inferred from the ordinary function; see
> 'implicitGeneric'). A message is printed after the initial call to
> 'setMethod'; this is not an error, just a reminder that you have
> created the generic. Creating the generic explicitly by the call
>
> 'setGeneric("f3")'
>
> avoids the message, but has the same effect. The existing function
> becomes the default method for the S4 generic function. Primitive
> functions work the same way, but the S4 generic function is not
> explicitly created (as discussed below).
>
> S4 and S3 method selection are designed to follow compatible rules
> of inheritance, as far as possible. S3 classes can be used for any
> S4 method selection, provided that the S3 classes have been
> registered by a call to 'setOldClass', with that call specifying
> the correct S3 inheritance pattern. S4 classes can be used for any
> S3 method selection; when an S4 object is detected, S3 method
> se
Re: [Rd] S4 classes and S3 generic functions
There are number of examples in the documentation, as noted,
illustrating different situations.
Here is one of them. Of course, to "enter and run" it you need rev 52267.
---
setClass("classA", contains = "numeric",
representation(realData = "numeric"))
Math.classA <- function(x) {(getFunction(.Generic))(x...@realdata)}
setMethod("Math", "classA", Math.classA)
x <- new("classA", log(1:10), realData = 1:10)
stopifnot(identical(abs(x), 1:10))
setClass("classB", contains = "classA")
y <- new("classB", x)
stopifnot(identical(abs(y), 1:10)) # (version 2.9.0 or earlier fails here)
## an S3 generic: just for demonstration purposes
f3 <- function(x, ...) UseMethod("f3")
f3.default <- function(x, ...) "Default f3"
## S3 method (only) for classA
f3.classA <- function(x, ...) "Class classA for f3"
## S3 and S4 method for numeric
f3.numeric <- function(x, ...) "Class numeric for f3"
setMethod("f3", "numeric", f3.numeric)
## The S3 method for classA and the closest inherited S3 method for classB
## are not found.
f3(x); f3(y) # both choose "numeric" method
## to obtain the natural inheritance, set identical S3 and S4 methods
setMethod("f3", "classA", f3.classA)
f3(x); f3(y) # now both choose "classA" method
-
On 6/13/10 4:35 PM, Gabor Grothendieck wrote:
On Sun, Jun 13, 2010 at 6:58 PM, John Chambers wrote:
A general goal for the next version of R is to make S4 and S3 play better
together.
As mentioned in a previous thread, one limitation has been that S3 generic
functions, specifically the UseMethod() call, did not make use of S4
inheritance when dispatching on general S4 objects.
This has been fixed in a version committed today (updated to rev 52267).
The code change is not large, but it has some general implications. Mainly,
in applying S3 generic functions to objects from S4 classes, the default
recommendation is to define an S3 method for the class, when possible, and
then set that definition to be the S4 method as well.
The section "Methods for S3 Generic Functions" of the ?Methods documentation
in the (new) version has details and points to examples. The text of that
section is appended below.
John
==
Methods for S3 Generic Functions:
S4 methods may be wanted for functions that also have S3 methods,
corresponding to classes for the first formal argument of an S3
generic function-either a regular R function in which there is a
call to the S3 dispatch function, 'UseMethod', or one of a fixed
set of primitive functions, which are not true functions but go
directly to C code. In either case S3 method dispatch looks at the
class of the first argument or the class of either argument in a
call to one of the primitive binary operators. S3 methods are
ordinary functions with the same arguments as the generic function
(for primitives the formal arguments are not actually part of the
object, but are simulated when the object is printed or viewed by
'args()'). The "signature" of an S3 method is identified by the
name to which the method is assigned, composed of the name of the
generic function, followed by '"."', followed by the name of the
class. For details, see S3Methods.
To implement a method for one of these functions corresponding to
S4 classes, there are two possibilities: either an S4 method or an
S3 method with the S4 class name. The S3 method is only possible
if the intended signature has the first argument and nothing else..
In this case, the recommended approach is to define the S3 method
and also supply the identical function as the definition of the S4
method. If the S3 generic function was 'f3(x, ...)' and the S4
class for the new method was '"myClass"':
f3.myClass<- function(x, ...) { . }
setMethod("f3", "myClass", f3.myClass)
The reasons for defining both S3 and S4 methods are as follows:
1. An S4 method alone will not be seen if the S3 generic
function is called directly. However, primitive functions
and operators are exceptions: The internal C code will look
for S4 methods if and only if the object is an S4 object. In
the examples, the method for '`[`' for class '"myFrame"' will
always be called for objects of this class.
For the same reason, an S4 method defined for an S3 class
will not be called from internal code for a non-S4 object.
(See the example for function 'Math' and class '"data.frame"'
in the examples.)
2. An S3 method alone will not be called if there is _any_
eligible non-default S4 method. (See the example for function
'f3' and class '"classA"' in the examples.)
Details of the selection computations are given below.
When an S4 method is defined for an existing function that is not
an S4 generic function (whether or not the existing function is an
