[Bioc-devel] Strange error during package check (pcaMethods package)
wolfram.stacklies at gmail.com
Fri Apr 13 09:21:18 CEST 2007
Hello Seth and Herve,
Thanks a lot for your suggestions!
I introduced the changes suggested by Seth (creating a .onLoad function
and setting SaveImage: yes).
Let's see if it helps.
Seth Falcon wrote:
> Hi Wolfram,
> Wolfram Stacklies <wolfram.stacklies at gmail.com> writes:
>> I am the maintainer of the pcaMethods package. During the automated
>> package checks I receive the following error message on
>> /wellington/ Linux (SUSE 9.2) and on /derby/ Mac OS X (10.4.8) (see below).
>> Build is fine for all packages.
>> I guess that has something to do with the upgrade to R-2.5.0, but I really
>> cannot interpret the error message.
> It is not one I've seen before either. The "could not find function"
> part appears to be coming from findFun in envir.c and this gets used
> by the methods package (among others).
> I don't know if it will solve the issue, but two things you should do:
> 1. Since you define S4 classes and methods and have a NAMESPACE file,
> you need to add a .onLoad function to your package as described in
> the Writing R Extensions manual:
> .onLoad <- function(libname, pkgname) require("methods")
> 2. You have 'SaveImage: no' in the DESCERIPTION file and this is not
> recommended for packages that use S4. Can you try setting this to
>> It builds and checks fine on my (Mac OS) desktop and Linux laptop with
> It builds and checks for me using an R-2.5.0 beta. The build
> (vignette) and the check (examples + vignette) take a looong time. If
> it were my package, I would see about trimming down the example data
> so that checking the package takes less time.
> Another comment: in the example for svdImpute, you demonstrate
> extracting components from the result object using direct slot access
> via '@'. You might consider using accessor methods instead. So
> instead of result at scores you would do scores(result). When you want
> to reorganize how the result is structured you will be very glad for
> such an interface layer.
> + seth
More information about the Bioc-devel