Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Dirk Eddelbuettel

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


Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Simon Urbanek

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"  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()]

2011-02-22 Thread Dirk Eddelbuettel

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"  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()]

2011-02-22 Thread baptiste auguie
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
 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  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"  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()]

2011-02-22 Thread baptiste auguie
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  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"  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()]

2011-02-22 Thread Simon Urbanek

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"  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()]

2011-02-22 Thread baptiste auguie
On 23 February 2011 00:28, Dirk Eddelbuettel  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()]

2011-02-22 Thread Dirk Eddelbuettel

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"  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()]

2011-02-22 Thread Simon Urbanek
On Feb 22, 2011, at 5:46 PM,  
 wrote:

> On 2/22/11 4:32 PM, "Dirk Eddelbuettel"  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()]

2011-02-22 Thread Simon Urbanek

On Feb 22, 2011, at 6:03 PM, Simon Urbanek wrote:

> 
> On Feb 22, 2011, at 5:51 PM,  
>  wrote:
> 
>> 
>> 
>> On 2/22/11 4:33 PM, "Simon Urbanek"  wrote:
>> 
>>> 
>>> On Feb 22, 2011, at 5:29 PM, 
>>>  wrote:
>>> 
 
 
 
 
 On 2/22/11 4:25 PM, "Simon Urbanek"  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()]

2011-02-22 Thread Simon Urbanek

On Feb 22, 2011, at 5:51 PM,  
 wrote:

> 
> 
> On 2/22/11 4:33 PM, "Simon Urbanek"  wrote:
> 
>> 
>> On Feb 22, 2011, at 5:29 PM, 
>>  wrote:
>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2/22/11 4:25 PM, "Simon Urbanek"  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. 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()]

2011-02-22 Thread Ken.Williams




On 2/22/11 4:54 PM, "Dirk Eddelbuettel"  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


___
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()]

2011-02-22 Thread Dirk Eddelbuettel

On 22 February 2011 at 16:46, ken.willi...@thomsonreuters.com wrote:
| On 2/22/11 4:32 PM, "Dirk Eddelbuettel"  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) 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.

I could. It is a little crude. I'd rather use something already parsed. 

What is in Sys.info(), particularly fields 1 and 2:

R> Sys.info()[1:2]
sysname release 
"Linux" "2.6.32-25-generic" 
R> 

Else, .Platform() starts with 'Darwin', right?  We do test for Darwin in two
places but never AFAICT for sub-versions.

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()]

2011-02-22 Thread Ken.Williams


On 2/22/11 4:33 PM, "Simon Urbanek"  wrote:

>
>On Feb 22, 2011, at 5:29 PM, 
> wrote:
>
>> 
>> 
>> 
>> 
>> On 2/22/11 4:25 PM, "Simon Urbanek"  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()]

2011-02-22 Thread Simon Urbanek

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()]

2011-02-22 Thread Ken.Williams




On 2/22/11 4:32 PM, "Dirk Eddelbuettel"  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) 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()]

2011-02-22 Thread Simon Urbanek

On Feb 22, 2011, at 5:29 PM,  
 wrote:

> 
> 
> 
> 
> On 2/22/11 4:25 PM, "Simon Urbanek"  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()]

2011-02-22 Thread Dirk Eddelbuettel

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()]

2011-02-22 Thread Ken.Williams




On 2/22/11 4:25 PM, "Simon Urbanek"  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()]

2011-02-22 Thread Simon Urbanek
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 ;)).

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
> 
> 

___
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()]

2011-02-22 Thread Ken.Williams





On 2/22/11 4:14 PM, "baptiste auguie" 
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()]

2011-02-22 Thread baptiste auguie
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  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"  
>> 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], 
>> )' is ambiguous
>> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53: 
>> note: candidates are: Rcpp::class_& Rcpp::class_::method(const 
>> char*, OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT 
>> = void, U0 = long unsigned int, Class = std::vector> std::allocator >]
>> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80: 
>> note:                 Rcpp::class_& Rcpp::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 >]
>> | 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 Œi3

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Dirk Eddelbuettel

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()]

2011-02-22 Thread Simon Urbanek

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"  
> 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], 
> )' is ambiguous
> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53: 
> note: candidates are: Rcpp::class_& Rcpp::class_::method(const 
> char*, OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT = 
> void, U0 = long unsigned int, Class = std::vector std::allocator >]
> | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80: 
> note: Rcpp::class_& Rcpp::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 >]
> | 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
>

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Dirk Eddelbuettel

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"  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], 
)' is ambiguous
| /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53: 
note: candidates are: Rcpp::class_& Rcpp::class_::method(const 
char*, OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT = 
void, U0 = long unsigned int, Class = std::vector >]
| /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80: 
note: Rcpp::class_& Rcpp::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 >]
| 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()]

2011-02-22 Thread Simon Urbanek

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"  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], )' is ambiguous
/private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53: note: 
candidates are: Rcpp::class_& Rcpp::class_::method(const char*, 
OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT = void, U0 
= long unsigned int, Class = std::vector >]
/private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80: note: 
Rcpp::class_& Rcpp::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 >]
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()]

2011-02-22 Thread Dirk Eddelbuettel

On 22 February 2011 at 13:49, ken.willi...@thomsonreuters.com wrote:
| On 2/22/11 11:45 AM, "Simon Urbanek"  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 ...
 
| 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()]

2011-02-22 Thread Ken.Williams
On 2/22/11 11:45 AM, "Simon Urbanek"  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.

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?


--
Ken Williams
Senior Research Scientist
Thomson Reuters
Phone: 651-848-7712
ken.willi...@thomsonreuters.com
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()]

2011-02-22 Thread Rainer Hurling
Just as an incidental remark about Rcpp on FreeBSD, since that 
Unix-alike OS is 'non standard' in some way ;-)


On 22.02.2011 18:55 (UTC+1), Dirk Eddelbuettel wrote:


On 22 February 2011 at 12:45, Simon Urbanek wrote:
|
| 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"  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

Tres etrange, as Romain develops on OS X himself. I will have to pass on this
one for lack of access to such shiny hardware.  He may fix it, or he may not.
I vaguely recall us discussing that with you and Romain's inability to
reproduce it.  As such, chances of improvement may be slim.  Tant pis.

| 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

I do look there regularly but I cannot fix Slowlaris and the funky SunOS
compiler messages until we get the rumoured 'bin-builder'.

Hints for shutting up R-devel on the 'size' NOTE concerning the arbitrary 1mb
cutoff (hey, "640kb should be enough for everyone" so why not use that?) would
be welcome too.

Dirk


I checked (and installed) Rcpp_0.9.1.tar.gz on FreeBSD 9.0-CURRENT 
(amd64), the development version of FreeBSD. Compiler is 
gcc-4.5.3.20110210. After some FreeBSD specific adaptions Dirk made some 
weeks ago Rcpp works great now ;-)



Some more information for people who are interested in:

This is R-2.13.0 with sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-22 r54523)
Platform: x86_64-unknown-freebsd9.0 (64-bit)
locale:
[1] de_DE.ISO8859-15/de_DE.ISO8859-15/C/C/de_DE.ISO8859-15/de_DE.ISO8859-15
attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


# R CMD check Rcpp_0.9.1.tar.gz
* using log directory '/usr/home/rhurlin/CRAN-R/Packages/Rcpp.Rcheck'
* using R version 2.13.0 Under development (unstable) (2011-02-22 r54523)
* using platform: x86_64-unknown-freebsd9.0 (64-bit)
* using session charset: ISO8859-1
* checking for file 'Rcpp/DESCRIPTION' ... OK
* this is package 'Rcpp' version '0.9.1'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for executable files ... OK
* checking whether package 'Rcpp' can be installed ... OK
* checking installed package size ... NOTE
  installed size is 18.1Mb
  sub-directories of 1Mb or more:
libs  2.2Mb
doc   2.0Mb
include   5.6Mb
lib   7.7Mb
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the name space can be loaded with stated dependencies 
... OK

* checking whether the name space can be unloaded cleanly ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking l

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Dirk Eddelbuettel

On 22 February 2011 at 12:45, Simon Urbanek wrote:
| 
| 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"  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

Tres etrange, as Romain develops on OS X himself. I will have to pass on this
one for lack of access to such shiny hardware.  He may fix it, or he may not.
I vaguely recall us discussing that with you and Romain's inability to
reproduce it.  As such, chances of improvement may be slim.  Tant pis.

| 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

I do look there regularly but I cannot fix Slowlaris and the funky SunOS
compiler messages until we get the rumoured 'bin-builder'. 

Hints for shutting up R-devel on the 'size' NOTE concerning the arbitrary 1mb
cutoff (hey, "640kb should be enough for everyone" so why not use that?) would
be welcome too.

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()]

2011-02-22 Thread Simon Urbanek

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"  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


[Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

2011-02-22 Thread Dirk Eddelbuettel

On 22 February 2011 at 11:26, ken.willi...@thomsonreuters.com wrote:
| On 2/22/11 11:13 AM, "Dirk Eddelbuettel"  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?  

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] Building/linking trouble with cxxfunction()

2011-02-22 Thread Ken.Williams


On 2/22/11 11:13 AM, "Dirk Eddelbuettel"  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?


--
Ken Williams
Senior Research Scientist
Thomson Reuters
Phone: 651-848-7712
ken.willi...@thomsonreuters.com
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] Building/linking trouble with cxxfunction()

2011-02-22 Thread Douglas Bates
On Tue, Feb 22, 2011 at 10:53 AM,   wrote:
>
>
> On 2/19/11 9:20 AM, "Douglas Bates"  wrote:
>
>>On Fri, Feb 18, 2011 at 4:50 PM,   wrote:
>>
>>> Hi Doug, did you ever get a test case working for this?
>>
>>I didn't try further.  I was hoping that you would pick up the sources
>>for the package and experiment with it. :-)
>
> Yes, a reasonable thing to hope for - I did pick it up and play with it
> some that day, but I didn't get very far. I messed with it again now and
> 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.
>
>
>> I was using a value of 712 for the number of eigenvalue-eigenvector
>> pairs to determine, which may have been a reason that it was taking so
>> long, relative to the example you show below where only 3 pairs are
>> determined.
>
>
> Looks like that was probably the case.  Running my example matrix with
> your wrapper gives me the results I expect, in a fraction of a second.
>
> So now I'll modify your package to add return values for the eigenvectors,
> as well as the eigenvalues you returned, so that it looks like the return
> values from svd().
>
> So it looks relatively straightforward (now) to package this up.  I'm
> willing to do that, but would it be better to integrate this into the
> Matrix package, or something like that, so that it "just works" for a
> greater percentage of people?
>
> I asked Doug Rohde if his licensing terms would allow redistribution, and
> he said "SVDLIBC currently has an 'I don't care, use it for whatever'
> license.  :-)"  But since it's based in turn on SVDPACKC, it would be good
> to also contact its author, Michael Berry.
>
>
>> In my opinion Tim's code is
>> the state of the art in sparse matrix methods (except for the fact
>> that it is primarily in C rather than expressed as classes in C++).
>
> I may be missing it, but I don't see any SVD/eigenvector stuff in Tim's
> code.  Is it an easy consequence of some other capability?

No.  I'm just saying that he indicates this is in development so it
would be worthwhile watching his archive to see if it is incorporated.

>
> --
> Ken Williams
> Senior Research Scientist
> Thomson Reuters
> Phone: 651-848-7712
> ken.willi...@thomsonreuters.com
> 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] Building/linking trouble with cxxfunction()

2011-02-22 Thread Dirk Eddelbuettel

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

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] Building/linking trouble with cxxfunction()

2011-02-22 Thread Ken.Williams


On 2/19/11 9:20 AM, "Douglas Bates"  wrote:

>On Fri, Feb 18, 2011 at 4:50 PM,   wrote:
>
>> Hi Doug, did you ever get a test case working for this?
>
>I didn't try further.  I was hoping that you would pick up the sources
>for the package and experiment with it. :-)

Yes, a reasonable thing to hope for - I did pick it up and play with it
some that day, but I didn't get very far. I messed with it again now and
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.


> I was using a value of 712 for the number of eigenvalue-eigenvector
> pairs to determine, which may have been a reason that it was taking so
> long, relative to the example you show below where only 3 pairs are
> determined.


Looks like that was probably the case.  Running my example matrix with
your wrapper gives me the results I expect, in a fraction of a second.

So now I'll modify your package to add return values for the eigenvectors,
as well as the eigenvalues you returned, so that it looks like the return
values from svd().

So it looks relatively straightforward (now) to package this up.  I'm
willing to do that, but would it be better to integrate this into the
Matrix package, or something like that, so that it "just works" for a
greater percentage of people?

I asked Doug Rohde if his licensing terms would allow redistribution, and
he said "SVDLIBC currently has an 'I don't care, use it for whatever'
license.  :-)"  But since it's based in turn on SVDPACKC, it would be good
to also contact its author, Michael Berry.


> In my opinion Tim's code is
> the state of the art in sparse matrix methods (except for the fact
> that it is primarily in C rather than expressed as classes in C++).

I may be missing it, but I don't see any SVD/eigenvector stuff in Tim's
code.  Is it an easy consequence of some other capability?


--
Ken Williams
Senior Research Scientist
Thomson Reuters
Phone: 651-848-7712
ken.willi...@thomsonreuters.com
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