[Bioc-devel] Strange error during package check (pcaMethods package)

[Wolfram Stacklies]

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.

Cheers,
Wolfram


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
>    yes?
>
>   
>> It builds and checks fine on my (Mac OS) desktop and Linux laptop with 
>> R-2.5.0.
>>     
>
> 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
>
>