Hi,
Out of curiosity I also ran a R CMD check on the CRAN version of Rcpp,
and it failed on my machine (10.5):
Running the tests in ‘tests/doRUnit.R’ failed.
Error in eval.with.vis(expr, envir, enclos) :
unit test problems: 0 failures, 1 errors
Error in func() : object 'stdVector' not found
Calls: source -> eval.with.vis -> eval.with.vis
Execution halted
sessionInfo()
R version 2.12.1 Patched (2010-12-30 r53895)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.12.1
Sys.info()
sysname "Darwin" release "9.8.0" version "Darwin Kernel
Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
Thanks,
baptiste
On 22 February 2011 22:53, Simon Urbanek <simon.urba...@r-project.org> wrote:
>
> 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
>
_______________________________________________
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
