General comments.  A number of packages will likely be showing weird 
warnings on attach() about packages being out of date.  Likely caused by 
a confusion when two packages define the same generic.  The bug is being 
worked on, but there are some issues of package design that will need 
discussion later.

Early revisions with the new code did have a C-level problem but that is 
now fixed AFAIK, so any hard evidence of protection problems would be 
valuable.

There have been some changes, up to svn revision 39037 at the moment, 
but there will be some more.  All reports are appreciated.  Some are 
easier for me to check out than others (I'm working from a home setup 
that does not have all of CRAN available (!) so it takes time to test a 
package with many dependencies in "CMD check"s view of things.)

John


Roger Bivand wrote:
> On Fri, 1 Sep 2006, Roger Bivand wrote:
>
>   
>> On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
>>
>>     
>>> Since writing that, I have found that there is a similar problem with 
>>> testing mvoutliers (which does load sp), and it depends on exactly what 
>>> has been done in what order.  (I'll forward to you the exact description.)
>>>       
>
> On a different RHEL 4 i386 with R version 2.4.0 (2006-09-01 r39049), and 
> fully updated sp CVS from 
>
> cvs -z3 -d:pserver:anonymous@r-spatial.cvs.sourceforge.net:/cvsroot/r-spatial checkout sp
>
> CND check sp passes with no error (with RColorBrewer the only installed 
> package in a test library).
>
> I'll try again on the first machine (which is also RHEL 4 i386, but where 
> R was at 2006-08-31 r39045, and where there may have been configuration 
> issues (wrong library path?).
>
> Roger
>
>   
>> Thanks.
>>
>> I reran the interactive test:
>>
>> library(sp, lib.loc="sp.Rcheck")
>> example("DMS-class")
>>
>> which ran without problems.
>>
>>     
>>> .libPaths()
>>>       
>> [1] "/home/rsb/topics/r_libs"                
>> [2] "/home/rsb/topics/Rtobe240/lib/R/library"
>>     
>>> list.files(.libPaths()[1])
>>>       
>> [1] "abind"        "maptools"     "pixmap"       "RColorBrewer" "R.css"       
>> [6] "rgdal"        "SparseM"      "spdep"        "tripack"
>>     
>>> sessionInfo()
>>>       
>> R version 2.4.0 Under development (unstable) (2006-08-31 r39045) 
>> i686-pc-linux-gnu 
>>
>> locale:
>> LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
>> MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
>> NT=en_GB;LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
>> [7] "base"     
>>
>> other attached packages:
>>       sp 
>> "0.8-19" 
>>
>>     
>>> I now suspect there is a protection problem in the new S4 dispatch code.
>>> Using gctorture/valgrind may help locate it.
>>>       
>> Running check --use-gct sp now.
>>
>> Roger
>>
>>     
>>> Brian
>>>
>>> On Fri, 1 Sep 2006, Roger Bivand wrote:
>>>
>>>       
>>>> On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
>>>>
>>>>         
>>>>> Roger,
>>>>>
>>>>> I had managed to run R CMD check on sp successfully on r39021 and r39043 
>>>>> (current) in my nightly checks.  (There are a couple of tests where the 
>>>>> show/print method is not being invoked, but that is not new.)
>>>>>
>>>>> All I can suggest is to install R from scratch (make distclean), and then 
>>>>> reinstall all relevant packages.  At a guess, your interactive use and R 
>>>>> CMD check are picking up different libraries.
>>>>>           
>>>> Brian,
>>>>
>>>> I added .libPaths() and sessionInfo() to the offending example, and tried
>>>> with a fresh svn checkout built in a fresh directory and installed in a
>>>> fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
>>>> set with export R_LIBS=):
>>>>
>>>>         
>>>>> data(state)
>>>>> .libPaths()
>>>>>           
>>>> [1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
>>>> [2] "/home/rsb/topics/r_libs"                      
>>>> [3] "/home/rsb/topics/Rtobe240/lib/R/library"      
>>>>         
>>>>> sessionInfo()
>>>>>           
>>>> R version 2.4.0 Under development (unstable) (2006-08-31 r39045) 
>>>> i686-pc-linux-gnu 
>>>>
>>>> locale:
>>>> LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
>>>> MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
>>>> NT=en_GB;LC_IDENTIFICATION=C
>>>>
>>>> attached base packages:
>>>> [1] "methods"   "stats"     "graphics"  "grDevices" "utils"     "datasets" 
>>>> [7] "base"     
>>>>
>>>> other attached packages:
>>>>       sp 
>>>> "0.8-19" 
>>>>         
>>>>> dd2dms(state.center$x)
>>>>>           
>>>> Error in function (classes, fdef, mtable)  : 
>>>>         unable to find an inherited method for function "initialize", for 
>>>> signature "integer"
>>>> Execution halted
>>>>
>>>> I also tried to replicate the problem by making a new, very small, package 
>>>> with just the apparently offending files:
>>>>
>>>> spS4:
>>>> DESCRIPTION  man/  NAMESPACE  R/
>>>>
>>>> spS4/man:
>>>> char2dms.Rd  DMS-class.Rd
>>>>
>>>> spS4/R:
>>>> AAA.R  dms.R
>>>>
>>>> and edited DESCRIPTION, NAMESPACE, and AAA.R to suit. In this setting 
>>>> there was no problem. I'll carry on looking. None of these files has 
>>>> changed between released 0.8-18 and CVS 0.8-19. 
>>>>
>>>> Roger
>>>>
>>>>         
>>>>> There are around a dozen S4-using packages on CRAN that are currently 
>>>>> failing their checks: some look like newly-discovered bugs but some look 
>>>>> like problems in S4 dispatch (even of S3 dispatch for S3 generics turned 
>>>>> into S4 generics).  More are producing apparently incorrect warnings.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>> On Thu, 31 Aug 2006, Roger Bivand wrote:
>>>>>
>>>>>           
>>>>>> Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
>>>>>> the latest changes in methods.
>>>>>>
>>>>>> The failures are in running examples and occur in CMD check:
>>>>>>
>>>>>>             
>>>>>>> data(state)
>>>>>>> dd2dms(state.center$x)
>>>>>>>               
>>>>>> Error in function (classes, fdef, mtable)  : 
>>>>>>         unable to find an inherited method for function "initialize", for 
>>>>>> signature "integer"
>>>>>>
>>>>>> Offending code:
>>>>>>
>>>>>> 	deg <- as(floor(dd), "integer") 
>>>>>>
>>>>>> After replacing by as.integer(floor(dd)), it fails on the local class 
>>>>>> definition:
>>>>>>
>>>>>>             
>>>>>>> dd2dms(state.center$x)
>>>>>>>               
>>>>>> Error in function (classes, fdef, mtable)  : 
>>>>>>         unable to find an inherited method for function "initialize", for 
>>>>>> signature "DMS"
>>>>>>
>>>>>> Installing sp, example("DMS-class") runs successfully interactively 
>>>>>> (other examples do too).
>>>>>>
>>>>>> The methods package is declared as Depends: in DESCRIPTION, and
>>>>>> import(methods) in NAMESPACE; 
>>>>>>
>>>>>> .onLoad <- function(lib, pkg) require(methods) is in the first R source 
>>>>>> file in Collate: order.
>>>>>>
>>>>>> Should the methods package be being invoked in some other way, is there a 
>>>>>> reason why the installed package appears to run examples successfully that 
>>>>>> fail under CMD check?
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>             
>>>>>           
>>>>         
>>>       
>>     
>
>   

	[[alternative HTML version deleted]]


