Skip to content

7 arguments passed to .Internal(identical) which requires 6

15 messages · Dan Tenenbaum, Matt Dowle, Luke Tierney +3 more

Original
Dan Tenenbaum
# 
I know this has come up before on R-help
(http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which-requires-6-td4548460.html)
but I have a concise reproducible case that I wanted to share.

Also, please note the Bioconductor scenario which is potentially
seriously impacted by this.
The issue arises when a binary version of a package (like my example
package below) is built under R 2.15.0 Patched but then installed
under R 2.15.0.  Our package AnnotationDbi (which hundreds of other
packages depend on) is impacted by this issue to the extent that
calling virtually any function in it will return something like this:
Error in ls(2) :
  7 arguments passed to .Internal(identical) which requires 6

My concern is that when R 2.15.1 is released and Bioconductor starts
building all its packages under it, that R 2.15.0 users will start to
experience this problem. We can ask all users to upgrade to R 2.15.1
if we have to, but it's not usually the case that a minor point
release MUST be installed in order to run packages built under it
(please correct me if I'm wrong). We would much prefer a workaround or
fix to make an upgrade unnecessary.

Here is a minimal package called 'bad':

DESCRIPTION:
Package: bad
Title: test package
Description: test package
Version: 0.0.1
Author: Bad
Maintainer: Bioconductor Package Maintainer <maintainer at bioconductor.org>
License: Artistic-2.0

NAMESPACE:
exportMethods(ls)
exportClass(A)

R/code.R:
setClass("A", "numeric")
setMethod("ls", "A", function(name, pos, envir, all.names, pattern) {
"here I am" })

If under R 2.15.0 Patched I create a binary package:
R CMD INSTALL --build bad

And then under R 2.15.0 I install it:
R CMD INSTALL bad_0.0.1.tgz

Then, in R-2.15.0 (started with --vanilla):
Error in ls(2) :
  7 arguments passed to .Internal(identical) which requires 6

This is on a Mac, but per the link above this occurs on Windows as well.

Any help would be very much appreciated!

Thanks,
Dan

~~~
sessionInfo() for R 2.15.0
R version 2.15.0 (2012-03-30)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

sessionInfo() for R 2.15.0 Patched:
R version 2.15.0 Patched (2012-06-03 r59505)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
Matt Dowle
# 
Dan Tenenbaum <dtenenba <at> fhcrc.org> writes:
requires-6-td4548460.html)
I'm seeing the same issue. Installing the latest R-Forge .zip of data.table 
built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running 
data.table(a=1:3) produces the "7 arguments passed to .Internal(identical) 
which requires 6" error.  traceback() and debugger() just display the top level 
call. debug(data.table) and stepping through reveals it is a call to identical
() but just a regular one. No .Internal() call in the package, let alone 
passing 6 or 7 arguments to .Internal.

Not sure how else to debug or trace it. R-Forge is byte compiling data.table 
using R 2.15.0 patched (iiuc), would that make a difference when the byte code 
is loaded into 2.15.0 which doesn't have the new argument in identical()? 

Matthew
Luke Tierney
#
On Wed, 6 Jun 2012, Matthew Dowle wrote:

            

      
      
      
    

        
Yes it would.

luke

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
FYI, Brian has backed out the changes to identical() in r59533 of R-patched. Please retry your test codes with the new version. (Due to some ISP mess-up, Brian is temporarily unable to reply in detail himself.)

-pd

        
On Jun 6, 2012, at 20:29 , <luke-tierney at uiowa.edu> <luke-tierney at uiowa.edu> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

      
I built R-trunk (rev 59537), ran 'Rtrunk CMD build data.table',
installed the resulting tar.gz into R release and it ran tests ok. So it
seems ok now, if that tested it right. Will check R-Forge again when it
catches up. Thanks.
Matthew

        
On Wed, 2012-06-06 at 22:04 +0200, peter dalgaard wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 06/06/2012 21:04, peter dalgaard wrote:

            

      
      
      
    

        
Some comments (now my ISP has repaired its network and I can send from 
the machine on which I did this):

- AFAICS this only applies to binary distributions, not mentioned by the OP.

- There has never been any guarantee of forwards compatibility.  If you 
want a package to run under 2.x.y, install it under 2.x.y.  There is 
limited support for backwards compatibility, so packages installed under 
2.x.y will _normally_ run under 2.x.z for z > y.

So the whining appeared to be specious: if BioC want to distribute 
binary packages which run under all 2.15.x, they need to build them 
under 2.15.0, *and* check that they run under later versions.  (AFAIK 
the CRAN binary package providers expect users to be using the current 
version of R.)

R-patched should be thought of as having an intermediate version number 
for this purpose, e.g. currently > 2.15.0, < 2.15.1.

- The issue is package installations which copy code from the current 
version of R into the package. That is not a good idea, and in general 
not recommended.  We see 3 main circumstances:

+ S4 methods.  This was first reported many years ago, and bites 
frequently.  It was deemed a 'feature'.  The usual instance is that the 
default method is copied from a function in another contributed package 
which is subsequently updated, but it can also apply to the packages in 
R itself.

+ Some packages making functions into S3 default methods.  The advice 
there has changed a while ago, to write a wrapper instead of using
foo.default <- base::foo
but there are lots of packages not doing that.

+ Byte compilation, which in some cases removes the closure wrappers 
from simple .Internal calls, and so captures the .Internal call at the 
time of compilation.

- In the particular case of identical(), the C code has generally been 
written for backwards and attempted future compatibility, but that was 
not the case for the version in 2.15.0.  (It is the case for the version 
in R-devel and that now in R-patched: I didn't back out all the changes.)

But because identical() seems to be captured more than we anticipated 
and the change was not that important, I reverted it.  But if a similar 
change is needed for an important enough bug fix, it will go into 
R-patched (and there is one there now).


So the general principles are

- install a package under the current version of R, or perhaps an 
earlier patch release of the same series.  If using R-devel, be prepared 
to re-install any package you use (in practice this is rare: for example 
XML, compositions, timeDate and timeSeries needed to be re-installed 
since 2-15-branch was branched).

- if any dependency of an S4-using package changes, re-install the 
package.  And this includes the standard packages (which is why they 
should be listed in Depends:).   Uwe's CRAN Windows binary builder does 
do that, so you may need to re-install the binary package even though 
its version number has not changed.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

      
Prof Ripley wrote :

            

      
      
      
    

        
I guess it's quite common practice for very many users to fail that
expectation. I for one do. I'm used to seeing "Warning: package <x> was
build using <the latest R>" when installing from CRAN. But if the package
states "Depends (R >= 2.12.0)", for example, then I assume it's ok to use
it in R 2.14.1, for instance. As long as it passes its test suite in the
version of R I'm using, that's the main thing. Is that wrong?

Matthew

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 07/06/2012 11:12, Matthew Dowle wrote:

            

      
      
      
    

        
It usually works.  But when it doesn't, the choices are

- update the R.
- install from the sources.

That Depends line is about source installs.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

      
Prof Ripley wrote :

            

      
      
      
    

        
I can't see that documented in either Writing R Extensions or
?install.packages. Is it somewhere else? I thought Depends applied to
binaries from CRAN too, which is the default method on Windows and Mac.

Matthew

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 07/06/2012 11:40, Matthew Dowle wrote:

            

      
      
      
    

        
That field is documented under the description of a *source* package 
(see the first line of section 1.1, and it is in that section) and is 
simply copied from the source package for binary installs.  It is the 
extra line added to the DESCRIPTION file, e.g.

Built: R 2.15.0; x86_64-pc-mingw32; 2012-04-02 09:27:07 UTC; windows

that tells you the version a binary package was built under 
(approximately for R-patched and R-devel), and library() checks.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

          

      
      
      
    

        
I'm fairly sure I understand all that. I'm still missing something more
basic probably. Consider the follow workflow :

I look on CRAN at package boot. Its webpage states "Depends R (>=
2.14.0)". I'm a user running R and I know I use 2.14.1, so I think great I
can use it. I install it as follows.

            

      
      
      
    

        
version.string R version 2.14.1 (2011-12-22)

            

      
      
      
    

        
trying URL
'http://cran.ma.imperial.ac.uk/bin/windows/contrib/2.14/boot_1.3-4.zip'
Content type 'application/zip' length 469615 bytes (458 Kb)
opened URL
downloaded 458 Kb

package ?boot? successfully unpacked and MD5 sums checked

            

      
      
      
    

        
Loading required package: boot
Warning message:
package ?boot? was built under R version 2.14.2

            

      
      
      
    

        
Does this mean that CRAN maintainers expect me to run the latest version
of the major release I'm using (R 2.14.2 in this case), not the current
release of R (R 2.15.0 currently) as you wrote earlier?   If that's the
case I never realised it before, but that seems very reasonable.  When I
ran the above just now I expected it to say "package 'boot' was built
under R version 2.15.0".  But it didn't, it said 2.14.2.  So it seems to
be my misunderstanding.

Matthew

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 07/06/2012 12:49, Matthew Dowle wrote:

            

      
      
      
    

        
2.15.x and 2.14.x are different series, with different binary repos.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Jun 7, 2012, at 7:49 AM, Matthew Dowle wrote:

        

            

      
      
      
    

        
You are expected to run the latest patch version of your major.minor R version (ideally, you should be running the latest release but you don't have to if you are ok with getting no updates).

            

      
      
      
    

        
Packages are specific to the major.minor version, we don't guarantee any compatibility across non-patch versions, i.e. you cannot expect package binary for R 2.15.0 to work in R 2.14.2 or vice versa. If you have R x.y.z then you are asking for binaries for R x.y.* - in your case you're running 2.14.2 so you get the latest build of the package for R 2.14.*. Have a look at CRAN, e.g.
http://cran.r-project.org/bin/windows/contrib/
you will see separate packages for every x.y version of R.

Cheers,
Simon

  
  


  


      

    

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

          

      
      
      
    

        
Thanks. So CRAN will continue to build and check new versions of packages
using R 2.14.2 in the 2.14.x repo, whilst R 2.15.x progresses separately.
I'm familiar with r-oldrel results on CRAN package check results page, but
for some reason I had missed the nuance there's a binary repo too for
r-oldrel. That's great.

Matthew

  
  


  


      

    

    
6 days later

    

      
      

        


  

        

      Matt Dowle
    

    

      
      #
    

  


  

      
Matthew Dowle <mdowle <at> mdowle.plus.com> writes:

            

      
      
      
    

        
Just to confirm, R-Forge has today caught up and is now using R r59554 which 
includes the fix for the problem in this thread. Its binary build of data.table 
is now installing fine on R 2.15.0 release, which it wasn't doing before.

Many thanks,
Matthew