[Rcpp-devel] dataptr / char_get_string_elt not provided by package ‘Rcpp’

[Dan Tenenbaum]

----- Original Message -----
> From: "Dirk Eddelbuettel" <edd at debian.org>
> To: "Dan Tenenbaum" <dtenenba at fhcrc.org>
> Cc: rcpp-devel at lists.r-forge.r-project.org
> Sent: Wednesday, February 5, 2014 11:02:10 AM
> Subject: Re: [Rcpp-devel] dataptr / char_get_string_elt not provided by package ‘Rcpp’
> 
> 
> On 5 February 2014 at 10:45, Dan Tenenbaum wrote:
> | A couple of Bioconductor packages have these errors:
> | 
> | package: DOSE
> | 
> | error:
> | 
> | function ‘char_get_string_elt’ not provided by package ‘Rcpp’
> | Execution halted
> | 
> | package: GOSim
> | 
> | error:
> | 
> |  function ‘dataptr’ not provided by package ‘Rcpp’
> 
> See below.
> 
> 
> | I see in
> | https://github.com/RcppCore/Rcpp/issues/92
> 
> That ticket is __closed__ so why do you look there?
> 
> Logs for Rcpp testing are at https://github.com/RcppCore/rcpp-logs
> Poke around there, particular in the status/ directory
> 
> All that was communicated here.
> 
> | Does this indicate the issue has not been resolved? Or is there a
> | workaround?
> 
> In most cases, yes. As shown in the repo and here.
> 
> To sum up again:
> 
>   i)  Either one of
> 
>          function 'enterRNGScope' not provided by package 'Rcpp'
> 
>          function ‘char_get_string_elt’ not provided by package
>          ‘Rcpp’
> 
>       can be fixed by strengthening the Rcpp initialization.
> 
>   ii) For that I provided patches doing this, noted it in the
>   announcements
>       and release notes.
> 
>       You now need
> 
>           DESCRIPTION:   Imports: Rcpp                 instead of
>           Depends:
> 
>           NAMESPACE:     importFrom(Rcpp, evalCpp)
> 
>       Sometimes a simple import(Rcpp) works, the importFrom(Rcpp,
>       evalRcpp)
>       is better. It can use any symbol, evalCpp is nice and short.
> 
> That should do.  The odd thing is that packages sometimes pass (which
> is why
> the defect rate was down to < 10 when we released -- count based on
> my
> machine) but fail on other machines.
> 
> In any case, the fix for i) above is to do what is in ii)
> 
> Ok?
> 
> In your particular case, you may also consider picking up the phone
> and
> making an in-house call to Kevin who tested all of BioC prior to
> release as
> well. And that too was noted in my release announcement.
> 

Indeed, you guys have done a really good job documenting all your work. You have to forgive me, as I was only told about all these changes recently, and I did not follow all the communication as it was happening, but had to come upon it later where it wasn't always clear which document was the canonical one to read. 

Anyway, your suggestion did the trick for both packages. Thanks!
Dan


> Dirk
> 
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>