Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 12:32 PM, Dirk Eddelbuettel wrote: On 22 February 2011 at 11:26, ken.willi...@thomsonreuters.com wrote: | On 2/22/11 11:13 AM, Dirk Eddelbuettel e...@debian.org wrote: | Just a quick note to say that ... | | On 22 February 2011 at 10:53, ken.willi...@thomsonreuters.com wrote: | | got farther, so now I'm getting correct output from it. BTW, I changed | | the prereq on Rcpp from 0.9.0 to 0.8.6 since that's the latest public | | release. | | ... this ain't so. Are you running an old R version that looks into a | versioned subtree of CRAN? Rcpp is at 0.9.1, its Archive/ has the | history up | from 0.6.0. See http://cran.r-project.org/web/packages/Rcpp/index.html | | Oh! Looks like the GUI package installer in R.app was set to just show | the latest OS X binary on CRAN, which is 0.8.6. Is there some reason | that's trailing the source release? Crap, you're absolutely correct. Forgot about the OS X aspect, as well as my mental note to bug Simon about the stone-old build, so doing that now. 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.html And OS X is not the only place as you'll see when you look at http://cran.r-project.org/web/checks/check_results_Rcpp.html You may want to keep an eye on your check results ... Cheers, Simon Thanks as always for keeping that builder running. Dirk -- 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
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::vectordouble, std::allocatordouble ] /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::vectordouble, std::allocatordouble ] make: *** [stdVector.o] Error 1 ERROR: compilation failed for package 'testRcppModule' You owe me one. 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 ___ 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
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::vectordouble,
std::allocatordouble ]
| /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::vectordouble,
std::allocatordouble ]
| 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?
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.
Thanks from the OS X-less Dirk
| 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
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::vectordouble,
std::allocatordouble ]
| /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::vectordouble, std::allocatordouble ]
| 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
|
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 22 February 2011 at 16:53, Simon Urbanek wrote: | 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). Is there any expectation of you upgrading these from OS X 10.5 to 10.6? Is there a possibility that you bifurcate the builds into 'current' and 'older' systems which, IIRC, is done for Windoze as per http://cran.r-project.org/web/checks/check_results_Rcpp.html It is a bit of a mismatch that you pull pre-release versions of R itself yet host them on older OS versions. Anyway---I will point our OS X user to source installs. There is no issue AFAICT with Rcpp. I cannot trigger a single warning with the three g++ versions at my disposal all of which are more recent than what you deploy. Thanks for running the builds and the continued help. Dirk -- 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
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::vectordouble,
std::allocatordouble ]
| /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::vectordouble, std::allocatordouble ]
| 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
| | *
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 2/22/11 4:14 PM, baptiste auguie baptiste.aug...@googlemail.com wrote: 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): Looks like the big difference might be 10.5 vs. 10.6. My compiler is the same as Simon's build machine. -- Ken Williams Senior Research Scientist Thomson Reuters http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 2/22/11 4:25 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote: Anyway---I will point our OS X user to source installs. Well, I don't think that helps in any way - the test will still fail for all 10.5 users. Why don't you just fix the test? It's up to you, but removing Rcpp from CRAN won't help anyone (well, almost ;)). Actually it helps a great deal, it means that 10.6 users can install something. What's this about removing Rcpp from CRAN though? Just a joke I assume? -- Ken Williams Senior Research Scientist Thomson Reuters http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 22 February 2011 at 17:25, Simon Urbanek wrote: | On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote: | | | On 22 February 2011 at 16:53, Simon Urbanek wrote: | | 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). | | Is there any expectation of you upgrading these from OS X 10.5 to 10.6? | | | No, too many users still have 10.5 and 10.6 has dropped ppc support, so we don't plan to drop Leopard support anytime soon. | | | Is there a possibility that you bifurcate the builds into 'current' and | 'older' systems which, IIRC, is done for Windoze as per | http://cran.r-project.org/web/checks/check_results_Rcpp.html | | It is a bit of a mismatch that you pull pre-release versions of R itself yet | host them on older OS versions. | | | No, even R-devel is build with 10.5 target - R version and OS have nothing it common. Windows is split only because of 64-bit support which is not available in older OSes - that is the only reason why the builds are not on XP anymore, they would be otherwise. | | | Anyway---I will point our OS X user to source installs. | | | Well, I don't think that helps in any way - the test will still fail for all 10.5 users. Why don't you just fix the test? It's up to you, but removing Rcpp from CRAN won't help anyone (well, almost ;)). I CC'ed you on a detailed post I sent to our internal rcpp-core list. It smells like a compiler issue to me. What boolean test for 'am I on OS X 10.5' can you suggest? I will then disable the test. Maybe Ken or Baptiste can test that and I would submit the thusly amended tarball as 0.9.2 so the we all can get back to peace, love and apple pie rather than fighting Steve Jobs' insistence on an outdated compiler. Dirk | | Cheers, | Simon | | | | There is no issue AFAICT with Rcpp. I cannot trigger a single warning with | the three g++ versions at my disposal all of which are more recent than what | you deploy. | | Thanks for running the builds and the continued help. | | 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 5:29 PM, ken.willi...@thomsonreuters.com ken.willi...@thomsonreuters.com wrote: On 2/22/11 4:25 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote: Anyway---I will point our OS X user to source installs. Well, I don't think that helps in any way - the test will still fail for all 10.5 users. Why don't you just fix the test? It's up to you, but removing Rcpp from CRAN won't help anyone (well, almost ;)). Actually it helps a great deal, it means that 10.6 users can install something. Can you explain? You can always install from sources (provided you have all the tools etc.) - regardless whether there is a binary or not... What's this about removing Rcpp from CRAN though? Just a joke I assume? No, why? Cheers, Simon ___ 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 5:32 PM, Dirk Eddelbuettel wrote:
On 22 February 2011 at 17:25, Simon Urbanek wrote:
| On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote:
|
|
| On 22 February 2011 at 16:53, Simon Urbanek wrote:
| | 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).
|
| Is there any expectation of you upgrading these from OS X 10.5 to 10.6?
|
|
| No, too many users still have 10.5 and 10.6 has dropped ppc support, so we
don't plan to drop Leopard support anytime soon.
|
|
| Is there a possibility that you bifurcate the builds into 'current' and
| 'older' systems which, IIRC, is done for Windoze as per
| http://cran.r-project.org/web/checks/check_results_Rcpp.html
|
| It is a bit of a mismatch that you pull pre-release versions of R itself
yet
| host them on older OS versions.
|
|
| No, even R-devel is build with 10.5 target - R version and OS have nothing
it common. Windows is split only because of 64-bit support which is not
available in older OSes - that is the only reason why the builds are not on
XP anymore, they would be otherwise.
|
|
| Anyway---I will point our OS X user to source installs.
|
|
| Well, I don't think that helps in any way - the test will still fail for
all 10.5 users. Why don't you just fix the test? It's up to you, but removing
Rcpp from CRAN won't help anyone (well, almost ;)).
I CC'ed you on a detailed post I sent to our internal rcpp-core list. It
smells like a compiler issue to me.
What boolean test for 'am I on OS X 10.5' can you suggest? I will then
disable the test.
You could use something like
if (Sys.info()['sysname'] != Darwin ||
isTRUE(as.integer(gsub(\\..*,,Sys.info()['release'])) 10L)) { # run the
test ... }
Maybe Ken or Baptiste can test that and I would submit the
thusly amended tarball as 0.9.2 so the we all can get back to peace, love and
apple pie rather than fighting Steve Jobs' insistence on an outdated compiler.
Dirk
|
| Cheers,
| Simon
|
|
|
| There is no issue AFAICT with Rcpp. I cannot trigger a single warning with
| the three g++ versions at my disposal all of which are more recent than
what
| you deploy.
|
| Thanks for running the builds and the continued help.
|
| 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 2/22/11 4:33 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:29 PM, ken.willi...@thomsonreuters.com ken.willi...@thomsonreuters.com wrote: On 2/22/11 4:25 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote: Anyway---I will point our OS X user to source installs. Well, I don't think that helps in any way - the test will still fail for all 10.5 users. Why don't you just fix the test? It's up to you, but removing Rcpp from CRAN won't help anyone (well, almost ;)). Actually it helps a great deal, it means that 10.6 users can install something. Can you explain? You can always install from sources (provided you have all the tools etc.) - regardless whether there is a binary or not... That's true - but for most OS X users, myself included until just a couple hours ago, it looks like (when using the R.app GUI install tools) the oldest successfully-built binary is the latest available version, unless someone like Dirk points us to the source install and says it should work fine. So it certainly helped me because I didn't know what I was missing. What's this about removing Rcpp from CRAN though? Just a joke I assume? No, why? Because it's a useful package, of course. And CRAN is where someone should go to find useful R packages. -- Ken Williams Senior Research Scientist Thomson Reuters http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 6:03 PM, Simon Urbanek wrote: On Feb 22, 2011, at 5:51 PM, ken.willi...@thomsonreuters.com ken.willi...@thomsonreuters.com wrote: On 2/22/11 4:33 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:29 PM, ken.willi...@thomsonreuters.com ken.willi...@thomsonreuters.com wrote: On 2/22/11 4:25 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Feb 22, 2011, at 5:12 PM, Dirk Eddelbuettel wrote: Anyway---I will point our OS X user to source installs. Well, I don't think that helps in any way - the test will still fail for all 10.5 users. Why don't you just fix the test? It's up to you, but removing Rcpp from CRAN won't help anyone (well, almost ;)). Actually it helps a great deal, it means that 10.6 users can install something. Can you explain? You can always install from sources (provided you have all the tools etc.) - regardless whether there is a binary or not... That's true - but for most OS X users, myself included until just a couple hours ago, it looks like (when using the R.app GUI install tools) the oldest successfully-built binary is the latest available version, unless someone like Dirk points us to the source install and says it should work fine. So it certainly helped me because I didn't know what I was missing. Ok, I'll take it down, but note that this will have a snowball effect since it implies that all depending packages will fail as well. Actually, thinking of it, I could initiate the build manually, skipping checks. Given that we know what fails it should be safe. However, there are currently two issues: a) I can do it only for the current version, i.e. if you update Rcpp make sure the fix is in, otherwise it won't build and b) the build machine is currently catching up R-devel packages so I can only do it when it's done -- could mean tomorrow. Cheers, Simon I can change the policy such that check failures result in the removal of the old binary - from what you said it may be useful since the users will be more likely to bug the maintainers for a fix. The drawback is that in the meantime there is no binary. Personally, either is fine with me. What's this about removing Rcpp from CRAN though? Just a joke I assume? No, why? Because it's a useful package, of course. And CRAN is where someone should go to find useful R packages. Well, if that was true, CRAN would have a much fewer packages ;). Cheers, Simon ___ 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 5:46 PM, ken.willi...@thomsonreuters.com ken.willi...@thomsonreuters.com wrote: On 2/22/11 4:32 PM, Dirk Eddelbuettel e...@debian.org wrote: What boolean test for 'am I on OS X 10.5' can you suggest? You could use system(uname -r), which on my system gives 10.6.0 (even though my system is 10.6.6) uname -r (and Sys.info()['release']) shows the Darwin release, so 10.6.0 means OS X 10.6.6 since OS X versions are 10.(darwin_maj - 4).darwin_min so 10.(10 - 4).6 = 10.6.6. It would be more obvious if you didn't have exactly 10.6.6 ;) Cheers, Simon and on a 10.5.x system seems to give 9.something. Or if you don't mind a command that will only exist on OS X, you can do system(sw_vers -productVersion), which gives the actual OS version. -- Ken Williams Senior Research Scientist Thomson Reuters http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
Ken,
Could you test the 0.9.1 tarball? Then in
inst/unitTests/runit.Module.client.package.R, apply the diff below:
-- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
-- change the test to add a! .badOSX()
so that the test that barfs under g++ 4.2.1 is not getting run.
If that passes everything, yet failed before, we would have ourselves a new
version which may things better.
Dirk
Index: runit.Module.client.package.R
===
--- runit.Module.client.package.R (revision 2902)
+++ runit.Module.client.package.R (working copy)
@@ -22,8 +22,18 @@
gc()
}
-if( Rcpp:::capabilities()[[Rcpp modules]] ) {
+.badOSX - function() {# the unit test in this
file fails on OS X 10.5
+val - FALSE # assume we are not on an old
OS X
+if (Sys.info()['sysname'] != Darwin) {# if on Darwin, let's test
+vertxt - Sys.info()['release']# 10.5.0 or 10.6.0 or
+osx - as.numeric(strsplit(vertxt, \\.)[[1]])
+val - osx[1] == 10 osx[2] = 5 # 10 and le 5 will mark
as bad
+}
+val
+}
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
+
test.Module.package - function( ){
td - tempfile()
On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
|
|
|
|
| On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
|
| What is in Sys.info(), particularly fields 1 and 2:
|
| R Sys.info()[1:2]
| sysname release
| Linux 2.6.32-25-generic
|
| That's probably the right way to do it, as Simon suggested too in the
| meantime.
|
| Sys.info()[1:2]
| sysname release
| Darwin 10.6.0
|
|
|
|
|
|
|
| Else, .Platform() starts with 'Darwin', right?
|
| Nope:
|
| .Platform[1]
| $OS.type
| [1] unix
|
|
|
| --
| Ken Williams
| Senior Research Scientist
| Thomson Reuters
| http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 23 February 2011 00:28, Dirk Eddelbuettel e...@debian.org wrote:
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
You probably meant,
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .badOSX() ) {
(check in progress...)
baptiste
___
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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
Ken,
Could you test the 0.9.1 tarball? Then in
inst/unitTests/runit.Module.client.package.R, apply the diff below:
-- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
You have a typo in the call (.basOSX vs .badOSX) and you got the test all wrong
-- you're testing for anything but Darwin and you have the versions wrong (only
major matters and bad is anything below 10). Why don't you just use my code ?
;) You can just copy my condition in verbatim just after
Rcpp:::capabilities()[[Rcpp modules]] - it was designed that way ...
Cheers,
S
-- change the test to add a! .badOSX()
so that the test that barfs under g++ 4.2.1 is not getting run.
If that passes everything, yet failed before, we would have ourselves a new
version which may things better.
Dirk
Index: runit.Module.client.package.R
===
--- runit.Module.client.package.R (revision 2902)
+++ runit.Module.client.package.R (working copy)
@@ -22,8 +22,18 @@
gc()
}
-if( Rcpp:::capabilities()[[Rcpp modules]] ) {
+.badOSX - function() { # the unit test in this
file fails on OS X 10.5
+val - FALSE # assume we are not on an old
OS X
+if (Sys.info()['sysname'] != Darwin) {# if on Darwin, let's test
+vertxt - Sys.info()['release'] # 10.5.0 or 10.6.0 or
+osx - as.numeric(strsplit(vertxt, \\.)[[1]])
+val - osx[1] == 10 osx[2] = 5 # 10 and le 5 will mark
as bad
+}
+val
+}
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
+
test.Module.package - function( ){
td - tempfile()
On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
|
|
|
|
| On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
|
| What is in Sys.info(), particularly fields 1 and 2:
|
| R Sys.info()[1:2]
| sysname release
| Linux 2.6.32-25-generic
|
| That's probably the right way to do it, as Simon suggested too in the
| meantime.
|
| Sys.info()[1:2]
| sysname release
| Darwin 10.6.0
|
|
|
|
|
|
|
| Else, .Platform() starts with 'Darwin', right?
|
| Nope:
|
| .Platform[1]
| $OS.type
| [1] unix
|
|
|
| --
| Ken Williams
| Senior Research Scientist
| Thomson Reuters
| http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
R CMD check now successfully completes on my machine with
.badOSX - !( Sys.info()['sysname'] == Darwin
isTRUE(as.integer(gsub(\\..*,,Sys.info()['release'])) 10L) )
if( Rcpp:::capabilities()[[Rcpp modules]] .badOSX ) {
Cheers,
baptiste
On 23 February 2011 00:56, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
Ken,
Could you test the 0.9.1 tarball? Then in
inst/unitTests/runit.Module.client.package.R, apply the diff below:
-- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
You have a typo in the call (.basOSX vs .badOSX) and you got the test all
wrong -- you're testing for anything but Darwin and you have the versions
wrong (only major matters and bad is anything below 10). Why don't you just
use my code ? ;) You can just copy my condition in verbatim just after
Rcpp:::capabilities()[[Rcpp modules]] - it was designed that way ...
Cheers,
S
-- change the test to add a ! .badOSX()
so that the test that barfs under g++ 4.2.1 is not getting run.
If that passes everything, yet failed before, we would have ourselves a new
version which may things better.
Dirk
Index: runit.Module.client.package.R
===
--- runit.Module.client.package.R (revision 2902)
+++ runit.Module.client.package.R (working copy)
@@ -22,8 +22,18 @@
gc()
}
-if( Rcpp:::capabilities()[[Rcpp modules]] ) {
+.badOSX - function() { # the unit test in
this file fails on OS X 10.5
+ val - FALSE # assume we are not on an old
OS X
+ if (Sys.info()['sysname'] != Darwin) { # if on Darwin, let's test
+ vertxt - Sys.info()['release'] # 10.5.0 or 10.6.0 or
+ osx - as.numeric(strsplit(vertxt, \\.)[[1]])
+ val - osx[1] == 10 osx[2] = 5 # 10 and le 5 will
mark as bad
+ }
+ val
+}
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
+
test.Module.package - function( ){
td - tempfile()
On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
|
|
|
|
| On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
|
| What is in Sys.info(), particularly fields 1 and 2:
|
| R Sys.info()[1:2]
| sysname release
| Linux 2.6.32-25-generic
|
| That's probably the right way to do it, as Simon suggested too in the
| meantime.
|
| Sys.info()[1:2]
| sysname release
| Darwin 10.6.0
|
|
|
|
|
|
|
| Else, .Platform() starts with 'Darwin', right?
|
| Nope:
|
| .Platform[1]
| $OS.type
| [1] unix
|
|
|
| --
| Ken Williams
| Senior Research Scientist
| Thomson Reuters
| http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
Oops, just realised the silliness of my having renamed .badOSX a good
one. Oh well, never mind that, I guess it's a matter of opinion ;)
baptiste
On 23 February 2011 01:08, baptiste auguie
baptiste.aug...@googlemail.com wrote:
R CMD check now successfully completes on my machine with
.badOSX - !( Sys.info()['sysname'] == Darwin
isTRUE(as.integer(gsub(\\..*,,Sys.info()['release'])) 10L) )
if( Rcpp:::capabilities()[[Rcpp modules]] .badOSX ) {
Cheers,
baptiste
On 23 February 2011 00:56, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
Ken,
Could you test the 0.9.1 tarball? Then in
inst/unitTests/runit.Module.client.package.R, apply the diff below:
-- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
You have a typo in the call (.basOSX vs .badOSX) and you got the test all
wrong -- you're testing for anything but Darwin and you have the versions
wrong (only major matters and bad is anything below 10). Why don't you
just use my code ? ;) You can just copy my condition in verbatim just after
Rcpp:::capabilities()[[Rcpp modules]] - it was designed that way ...
Cheers,
S
-- change the test to add a ! .badOSX()
so that the test that barfs under g++ 4.2.1 is not getting run.
If that passes everything, yet failed before, we would have ourselves a new
version which may things better.
Dirk
Index: runit.Module.client.package.R
===
--- runit.Module.client.package.R (revision 2902)
+++ runit.Module.client.package.R (working copy)
@@ -22,8 +22,18 @@
gc()
}
-if( Rcpp:::capabilities()[[Rcpp modules]] ) {
+.badOSX - function() { # the unit test in
this file fails on OS X 10.5
+ val - FALSE # assume we are not on an old
OS X
+ if (Sys.info()['sysname'] != Darwin) { # if on Darwin, let's test
+ vertxt - Sys.info()['release'] # 10.5.0 or 10.6.0 or
+ osx - as.numeric(strsplit(vertxt, \\.)[[1]])
+ val - osx[1] == 10 osx[2] = 5 # 10 and le 5 will
mark as bad
+ }
+ val
+}
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
+
test.Module.package - function( ){
td - tempfile()
On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
|
|
|
|
| On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
|
| What is in Sys.info(), particularly fields 1 and 2:
|
| R Sys.info()[1:2]
| sysname release
| Linux 2.6.32-25-generic
|
| That's probably the right way to do it, as Simon suggested too in the
| meantime.
|
| Sys.info()[1:2]
| sysname release
| Darwin 10.6.0
|
|
|
|
|
|
|
| Else, .Platform() starts with 'Darwin', right?
|
| Nope:
|
| .Platform[1]
| $OS.type
| [1] unix
|
|
|
| --
| Ken Williams
| Senior Research Scientist
| Thomson Reuters
| http://labs.thomsonreuters.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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 22 February 2011 at 18:56, Simon Urbanek wrote:
|
| On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
|
|
| Ken,
|
| Could you test the 0.9.1 tarball? Then in
| inst/unitTests/runit.Module.client.package.R, apply the diff below:
|
| -- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
|
|
| You have a typo in the call (.basOSX vs .badOSX)
Yes, just corrected thanks to Baptiste.
| and you got the test all wrong -- you're testing for anything but Darwin
Ooops. Now corrected too.
| and you have the versions wrong (only major matters and bad is anything
below 10).
Based on the extensive discussion here it appears that
10.5.0 fails as evidenced by your setup and confirmation by other
10.6.0 passes
so I want a test that screams if I 10.5 or lower. I don't care about major
8, 9, ...
| Why don't you just use my code ? ;) You can just copy my condition in
verbatim just after Rcpp:::capabilities()[[Rcpp modules]] - it was
designed that way ...
I tested your code on static strings here and I fail to see how it
differentiates between 10.5.0 (bad) and 10.6.0 (good).
What am I missing here?
Dirk
|
| Cheers,
| S
|
|
| -- change the test to add a! .badOSX()
|
| so that the test that barfs under g++ 4.2.1 is not getting run.
|
| If that passes everything, yet failed before, we would have ourselves a new
| version which may things better.
|
| Dirk
|
|
| Index: runit.Module.client.package.R
| ===
| --- runit.Module.client.package.R (revision 2902)
| +++ runit.Module.client.package.R (working copy)
| @@ -22,8 +22,18 @@
| gc()
| }
|
| -if( Rcpp:::capabilities()[[Rcpp modules]] ) {
| +.badOSX - function() {# the unit test in this
file fails on OS X 10.5
| +val - FALSE # assume we are not on
an old OS X
| +if (Sys.info()['sysname'] != Darwin) {# if on Darwin, let's test
| +vertxt - Sys.info()['release']# 10.5.0 or 10.6.0 or
| +osx - as.numeric(strsplit(vertxt, \\.)[[1]])
| +val - osx[1] == 10 osx[2] = 5 # 10 and le 5
will mark as bad
| +}
| +val
| +}
|
| +if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
| +
| test.Module.package - function( ){
|
| td - tempfile()
|
| On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
| |
| |
| |
| |
| | On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
| |
| | What is in Sys.info(), particularly fields 1 and 2:
| |
| | R Sys.info()[1:2]
| | sysname release
| | Linux 2.6.32-25-generic
| |
| | That's probably the right way to do it, as Simon suggested too in the
| | meantime.
| |
| | Sys.info()[1:2]
| | sysname release
| | Darwin 10.6.0
| |
| |
| |
| |
| |
| |
| |
| | Else, .Platform() starts with 'Darwin', right?
| |
| | Nope:
| |
| | .Platform[1]
| | $OS.type
| | [1] unix
| |
| |
| |
| | --
| | Ken Williams
| | Senior Research Scientist
| | Thomson Reuters
| | http://labs.thomsonreuters.com
| |
| |
|
| --
| 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On Feb 22, 2011, at 7:35 PM, Dirk Eddelbuettel wrote:
On 22 February 2011 at 18:56, Simon Urbanek wrote:
|
| On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:
|
|
| Ken,
|
| Could you test the 0.9.1 tarball? Then in
| inst/unitTests/runit.Module.client.package.R, apply the diff below:
|
| -- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')
|
|
| You have a typo in the call (.basOSX vs .badOSX)
Yes, just corrected thanks to Baptiste.
| and you got the test all wrong -- you're testing for anything but Darwin
Ooops. Now corrected too.
| and you have the versions wrong (only major matters and bad is anything
below 10).
Based on the extensive discussion here it appears that
10.5.0 fails as evidenced by your setup and confirmation by other
10.6.0 passes
so I want a test that screams if I 10.5 or lower. I don't care about major
8, 9, ...
| Why don't you just use my code ? ;) You can just copy my condition in
verbatim just after Rcpp:::capabilities()[[Rcpp modules]] - it was
designed that way ...
I tested your code on static strings here and I fail to see how it
differentiates between 10.5.0 (bad) and 10.6.0 (good).
What am I missing here?
The e-mailI sent about version numbers ;). OS X 10.5.n results in
Sys.info()['release'] == 9.n and OS X 10.6.n in Sys.info()['release'] == 10.n
because Sys.info() reports the Darwin version, not OS X version. Ken had 10.6.6
so incidentally that corresponds to Darwin (6+4).6 = 10.6 so the 6 there has
nothing to do with the first 6 in 10.6.6 ;). Ah, don't we all love riddles? ;)
Cheers,
S
Dirk
|
| Cheers,
| S
|
|
| -- change the test to add a! .badOSX()
|
| so that the test that barfs under g++ 4.2.1 is not getting run.
|
| If that passes everything, yet failed before, we would have ourselves a
new
| version which may things better.
|
| Dirk
|
|
| Index: runit.Module.client.package.R
| ===
| --- runit.Module.client.package.R (revision 2902)
| +++ runit.Module.client.package.R (working copy)
| @@ -22,8 +22,18 @@
|gc()
| }
|
| -if( Rcpp:::capabilities()[[Rcpp modules]] ) {
| +.badOSX - function() { # the unit test in this
file fails on OS X 10.5
| +val - FALSE # assume we are not on
an old OS X
| +if (Sys.info()['sysname'] != Darwin) {# if on Darwin, let's
test
| +vertxt - Sys.info()['release'] # 10.5.0 or 10.6.0 or
| +osx - as.numeric(strsplit(vertxt, \\.)[[1]])
| +val - osx[1] == 10 osx[2] = 5 # 10 and le 5
will mark as bad
| +}
| +val
| +}
|
| +if( Rcpp:::capabilities()[[Rcpp modules]] ! .basOSX() ) {
| +
| test.Module.package - function( ){
|
| td - tempfile()
|
| On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
| |
| |
| |
| |
| | On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
| |
| | What is in Sys.info(), particularly fields 1 and 2:
| |
| | R Sys.info()[1:2]
| | sysname release
| | Linux 2.6.32-25-generic
| |
| | That's probably the right way to do it, as Simon suggested too in the
| | meantime.
| |
| | Sys.info()[1:2]
| | sysname release
| | Darwin 10.6.0
| |
| |
| |
| |
| |
| |
| |
| | Else, .Platform() starts with 'Darwin', right?
| |
| | Nope:
| |
| | .Platform[1]
| | $OS.type
| | [1] unix
| |
| |
| |
| | --
| | Ken Williams
| | Senior Research Scientist
| | Thomson Reuters
| | http://labs.thomsonreuters.com
| |
| |
|
| --
| 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
Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]
On 22 February 2011 at 19:42, Simon Urbanek wrote:
| Based on the extensive discussion here it appears that
|
| 10.5.0 fails as evidenced by your setup and confirmation by other
|
| 10.6.0 passes
|
| so I want a test that screams if I 10.5 or lower. I don't care about major
| 8, 9, ...
|
| | Why don't you just use my code ? ;) You can just copy my condition in
verbatim just after Rcpp:::capabilities()[[Rcpp modules]] - it was
designed that way ...
|
| I tested your code on static strings here and I fail to see how it
| differentiates between 10.5.0 (bad) and 10.6.0 (good).
|
| What am I missing here?
|
|
| The e-mailI sent about version numbers ;). OS X 10.5.n results in
Sys.info()['release'] == 9.n and OS X 10.6.n in Sys.info()['release'] == 10.n
because Sys.info() reports the Darwin version, not OS X version. Ken had 10.6.6
so incidentally that corresponds to Darwin (6+4).6 = 10.6 so the 6 there has
nothing to do with the first 6 in 10.6.6 ;). Ah, don't we all love riddles? ;)
Ouch, that is sick.
New version based in part on Baptiste's tests too:
@@ -22,8 +22,14 @@
gc()
}
-if( Rcpp:::capabilities()[[Rcpp modules]] ) {
+## The unit test in this file fails on OS X 10.5.* but pass on 10.6.*
+## Sys.info release comes back with 10.* for the latter but 9.* for the former
+## Thanks to Simon Urbanek and Baptiste Auguie for suggesting and testing this
+.badOSX - (Sys.info()['sysname'] == Darwin
+isTRUE(as.integer(gsub(\\..*,,Sys.info()['release'])) 10L) )
+if( Rcpp:::capabilities()[[Rcpp modules]] ! .badOSX ) {
+
test.Module.package - function( ){
td - tempfile()
With a bit of luck I don't have too many typos and condition inversions in
here.
Dirk
--
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
