On Feb 22, 2011, at 3:56 PM, Dirk Eddelbuettel wrote:
>
> On 22 February 2011 at 15:32, Simon Urbanek wrote:
> |
> | On Feb 22, 2011, at 3:21 PM, Dirk Eddelbuettel wrote:
> |
> | >
> | > On 22 February 2011 at 13:49, ken.willi...@thomsonreuters.com wrote:
> | > | On 2/22/11 11:45 AM, "Simon Urbanek" <simon.urba...@r-project.org>
> wrote:
> | > |
> | > |
> | > | >
> | > | >On Feb 22, 2011, at 12:32 PM, Dirk Eddelbuettel wrote:
> | > | >
> | > | >>
> | > | >>Simon: Are there are any reasons Rcpp is frozen on a version that is
> | > | >>five
> | > | >> months old and five releases behind?
> | > | >>
> | > | >
> | > | >Yes, it's not passing checks - it's that simple:
> | > |
> >http://www.R-project.org/nosvn/R.check/r-prerel-macosx-ix86/Rcpp-00check.h
> | > | >tml
> | > |
> | > | On my machine, which is running R 2.12.1 on OS X 10.6.6 with nothing
> | > | remarkable changed (e.g. GCC is at 4.2.1), Rcpp_0.9.1.tar.gz builds &
> | > | tests & installs fine from the source release.
> | >
> | > Thanks for doing that. I was about to beg you do it. As I mentioned, I
> seem
> | > to recall that it also works swimmingly on Romain's OS X machine. So
> there
> | > error may be somewhere between Simon and his computers ...
> | >
> |
> | Yeah, right, between me and my computers? Well, I did the legwork to track
> down your mistakes and here is at least one that causes the test to fail:
> |
> | * installing *source* package 'testRcppModule' ...
> | ** libs
> | *** arch - i386
> | [...]
> | g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include
> -I/Library/Frameworks/R.framework/Resources/include/i386
> -I/usr/local/include -I"/private/tmp/ttt/l/Rcpp/include" -fPIC -g -O2 -c
> stdVector.cpp -o stdVector.o
> | stdVector.cpp: In function 'void _rcpp_module_stdVector_init()':
> | stdVector.cpp:36: error: call of overloaded 'method(const char [7],
> <unresolved overloaded function type>)' is ambiguous
> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53:
> note: candidates are: Rcpp::class_<Class>& Rcpp::class_<Class>::method(const
> char*, OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT =
> void, U0 = long unsigned int, Class = std::vector<double,
> std::allocator<double> >]
> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80:
> note: Rcpp::class_<Class>& Rcpp::class_<Class>::method(const
> char*, OUT (Class::*)(U0, U1), const char*, bool (*)(SEXPREC**, int)) [with
> OUT = void, U0 = long unsigned int, U1 = const double&, Class =
> std::vector<double, std::allocator<double> >]
> | make: *** [stdVector.o] Error 1
> | ERROR: compilation failed for package 'testRcppModule'
> |
> |
> | You owe me one.
>
> I thought that was a constant anyway? ;-)
>
> Was that 32 bit or 64 bit? What OS X version? What g++ version? Any idea why
> Romain and Ken are not affected?
>
i386 = 32-bit (not that is matters) and the CRAN specs are listed in "CRAN
Package Check Flavors" saying OS X 10.5.8, gcc 4.2.1 (5577 to be precise).
I can only speculate why they are not affected, and I'd say it's because they
use 10.6 and not 10.5 (consequence of which are different compilers as well).
> Could you do one further test and disable the appropriate unit test to see if
> 'the rest' passes? To do so, edit
>
> inst/unitTests/runit.Module.client.package.R
>
> either make the initial test
>
> if( Rcpp:::capabilities()[["Rcpp modules"]] ) {
>
> 'false' or else return right at the top of
>
> test.Module.package <- function( ){
>
> because the file stdVector.cpp that failed for you is part of the test
> package for Rcpp modules as wrappers around various STL functions.
>
I assume that it would succeed, because that's what the unit test file says
(only 1 failure). I have already deleted the tmp files I used for testing so
we'll have to trust RUnit on this ;).
Cheers,
Simon
> |
> | > | The last part of the output (where it differs from the Rcpp-00check.html
> | > | above) is:
> | > |
> | > | =====================
> | > | * checking tests ...
> | > | ** running tests for arch Œi386¹
> | > | Running ŒdoRUnit.R¹
> | > | OK
> | > | ** running tests for arch Œx86_64¹
> | > | Running ŒdoRUnit.R¹
> | > | OK
> | > | * checking package vignettes in Œinst/doc¹ ... OK
> | > | * checking PDF version of manual ... OK
> | > |
> | > | R CMD CHECK . 425.14s user 57.08s system 98% cpu 8:07.23 total
> | > | =====================
> | > |
> | > |
> | > |
> | > | I noticed that on OS X the check server is using "r-prerel". Why's
> that?
> | > | What version of R does that mean?
> | >
> | > Fresh from SVN I reckon. I happen to have built one from the r-devel
> branch
> | > earlier which says
> | > R version 2.13.0 Under development (unstable) (2011-02-22 r54544)
> | > and then there are of course the R 2.12.2 pre-releases (currently at 'rc'
> | > following 'alpha' and 'beta') per the usual schedule (and I put two of
> them
> | > into Debian unstable too).
> | >
> | > Simon is probably running those 2.12.2 pre-releases.
> | >
> | > Dirk
> | >
> | > --
> | > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
> | >
> | >
> |
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
