Re: [Rd] does subset.data.frame need to accept extra arguments?
> It needs to have ... in the formal argument list because the generic > subset() does. > > It could enforce a run-time warning that some arguments were being skipped > (by testing length(list(...)) for example), but then NextMethod might fail, > in a case where an object has a complicated class vector. That wouldn't be a problem if the check was implemented in subset.data.frame, would it? Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] does subset.data.frame need to accept extra arguments?
On 13-07-11 12:59 PM, Hadley Wickham wrote:
It needs to have ... in the formal argument list because the generic
subset() does.
It could enforce a run-time warning that some arguments were being skipped
(by testing length(list(...)) for example), but then NextMethod might fail,
in a case where an object has a complicated class vector.
That wouldn't be a problem if the check was implemented in
subset.data.frame, would it?
Suppose the class vector is c("myclass", "data.frame"). Then
subset.myclass would be called first if it existed. It might do some
simple computation and then use NextMethod. It should not need to know
that it is calling subset.data.frame next, so it will pass all of its
arguments along, possibly including some that subset.data.frame should
ignore.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] robustbase compilation problem: probably boneheaded? maybe 32-bit?
With a recent SVN build (R Under development (unstable) (2013-07-10
r63264) -- "Unsuffered Consequences"), I'm having trouble installing the
robustbase package. The bottom line is that I *think* it's a
32-bit-system problem, but I could easily be mistaken.
robustbase is passing its package checks:
http://cran.r-project.org/web/checks/check_results_robustbase.html
... but from the names of the targets it doesn't look like it is tested
on 32-bit platforms?
The error is:
gcc -std=gnu99 -I/usr/local/lib/R/include -DNDEBUG -I/usr/local/include
-fpic -g -O2 -c init.c -o init.o
In file included from init.c:3:
robustbase.h:20: error: redefinition of typedef ‘R_xlen_t’
/usr/local/lib/R/include/Rinternals.h:69: note: previous declaration of
‘R_xlen_t’ was here
As far as I can see there isn't any junk left over in my systems from
previous installs.
Rinternals.h has
#ifdef LONG_VECTOR_SUPPORT
typedef ptrdiff_t R_xlen_t;
typedef struct { R_xlen_t lv_length, lv_truelength; } R_long_vec_hdr_t;
# define R_XLEN_T_MAX 4503599627370496
# define R_SHORT_LEN_MAX 2147483647
# define R_LONG_VEC_TOKEN -1
#else
typedef int R_xlen_t;
# define R_XLEN_T_MAX R_LEN_T_MAX
#endif
while robustbase has
#ifndef LONG_VECTOR_SUPPORT
# ifndef XLENGTH
// for R <= 2.15.x :
# define XLENGTH(x) LENGTH(x)
typedef int R_xlen_t;
# endif
#endif
It seems the problem is that I have
#define SIZEOF_SIZE_T 4
in my config.log , which in turn turns off LONG_VECTOR_SUPPORT, which is
otherwise (?) assumed only to be true for R<=2.15.x ... can this be
because I'm on 32-bit Linux , or on old linux with gcc 4.4.3, or ... ?
Can anyone confirm/enlighten me?
cheers
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] robustbase compilation problem: probably boneheaded? maybe 32-bit?
On Jul 11, 2013, at 10:57 PM, Ben Bolker wrote:
>
> With a recent SVN build (R Under development (unstable) (2013-07-10
> r63264) -- "Unsuffered Consequences"), I'm having trouble installing the
> robustbase package. The bottom line is that I *think* it's a
> 32-bit-system problem, but I could easily be mistaken.
>
It's a bug in robustbase - it redefines R_xlen_t without checking the R
version. I think the author's true intention was to make it conditional on R
version for compatibility so it should be using R_VERSION and not
LONG_VECTOR_SUPPORT since the latter is irrelevant here as R 3.0.0+ will have
R_xlen_t regardless of the long vector support.
Cheers,
Simon
> robustbase is passing its package checks:
> http://cran.r-project.org/web/checks/check_results_robustbase.html
>
> ... but from the names of the targets it doesn't look like it is tested
> on 32-bit platforms?
>
> The error is:
>
> gcc -std=gnu99 -I/usr/local/lib/R/include -DNDEBUG -I/usr/local/include
> -fpic -g -O2 -c init.c -o init.o
> In file included from init.c:3:
> robustbase.h:20: error: redefinition of typedef ‘R_xlen_t’
> /usr/local/lib/R/include/Rinternals.h:69: note: previous declaration of
> ‘R_xlen_t’ was here
>
> As far as I can see there isn't any junk left over in my systems from
> previous installs.
>
> Rinternals.h has
>
> #ifdef LONG_VECTOR_SUPPORT
>typedef ptrdiff_t R_xlen_t;
>typedef struct { R_xlen_t lv_length, lv_truelength; } R_long_vec_hdr_t;
> # define R_XLEN_T_MAX 4503599627370496
> # define R_SHORT_LEN_MAX 2147483647
> # define R_LONG_VEC_TOKEN -1
> #else
>typedef int R_xlen_t;
> # define R_XLEN_T_MAX R_LEN_T_MAX
> #endif
>
> while robustbase has
>
> #ifndef LONG_VECTOR_SUPPORT
> # ifndef XLENGTH
> // for R <= 2.15.x :
> # define XLENGTH(x) LENGTH(x)
> typedef int R_xlen_t;
> # endif
> #endif
>
> It seems the problem is that I have
>
> #define SIZEOF_SIZE_T 4
>
> in my config.log , which in turn turns off LONG_VECTOR_SUPPORT, which is
> otherwise (?) assumed only to be true for R<=2.15.x ... can this be
> because I'm on 32-bit Linux , or on old linux with gcc 4.4.3, or ... ?
>
>
> Can anyone confirm/enlighten me?
>
> cheers
>Ben Bolker
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
