Re: [Rd] Use of C++ in Packages

[Brodie Gaslam via R-devel]

It's great to see the community mobilize to try to resolve this issue. 
Obviously C++ has become a big part of R extensions, so it would be nice 
to have clear guidelines and tools to be able to use C++ safely with the 
R API.


Unfortunately doing this will probably require a fair bit of work.  If 
R-core where to do this it would take away from other valuable 
improvements they could be making on R itself.  Given there is already a 
supported and documented extension mechanism with access to the R API 
via C, I can see why R-core might be reluctant to divert resources from 
R development to add the same level of support for C++.


Obviously it would be impossible to try to provide better documentation 
and/or mechanisms for C++ extensions without some R-core involvement, 
but it seems like much of the grunt work could be done by others.  I 
unfortunately have no C++ experience so cannot help here, but hopefully 
there are others that have the experience and the recognition in the 
community to offer to help and have their offer accepted.  Perhaps 
R-consortium can even fund, although given the level of expertise 
required here the funding may need to be meaningful.


That seems like the natural step here.  Someone with the qualifications 
to do so either volunteers or is funded to do this, and hopefully R-core 
agrees to provide input and final stamp of approval.  The documentation 
is probably more straightforward, as tools will need more work from 
R-core to integrate.  It is possible R-core may decline to do this, but 
absent someone actually offering to put in the hard work it's all 
theoretical.


Respectfully,

Brodie.

On 3/30/19 3:59 AM, Romain Francois wrote:

tl;dr: we need better C++ tools and documentation.

We collectively know more now with the rise of tools like rchk and improved 
documentation such as Tomas’s post. That’s a start, but it appears that there 
still is a lot of knowledge that would deserve to be promoted to actual 
documentation of best practices.

I think it is important to not equate C++ as a language, and Rcpp.

Also, C++ is not just RAII.

RAII is an important part of how Rcpp was conceived for sure, but it’s not the 
only thing C++ can bring as a language. Templates, lambdas, the stl are 
examples of things that can be used for expressiveness when just accessing data 
without interfering with R, calling R api functions ...

It would be nice that the usual « you should do that only if you know what 
you’re doing » be transformed to precise documentation, and maybe become part 
of some better tool. If precautions have to be taken before calling such and 
such functions: that’s ok. What are they ? Can we embed that in some tool.

  It is easy enough to enscope code that uses potentially jumpy code into a c++ 
lambda. This could be together with recommendations such as the body of the 
lambda shall only use POC data structures.

This is similar to precautions you’d take when writing concurrent code.

Romain


Le 30 mars 2019 à 00:58, Simon Urbanek  a écrit :

Kevin,



On Mar 29, 2019, at 17:01, Kevin Ushey  wrote:

I think it's also worth saying that some of these issues affect C code
as well; e.g. this is not safe:

   FILE* f = fopen(...);
   Rf_eval(...);
   fclose(f);


I fully agree, but developers using C are well aware of the necessity of 
handling lifespan of objects explicitly, so at least there are no surprises.



whereas the C++ equivalent would likely handle closing of the file in the 
destructor. In other words, I think many users just may not be cognizant of the 
fact that most R APIs can longjmp, and what that implies for cleanup of 
allocated resources. R_alloc() may help solve the issue specifically for memory 
allocations, but for any library interface that has a 'open' and 'close' step, 
the same sort of issue will arise.


Well, I hope that anyone writing native code in package is well aware of that 
and will use an external pointer with finalizer to clean up native objects in 
any 3rd party library that are created during the call.



What I believe we should do, and what Rcpp has made steps towards, is make it 
possible to interact with some subset of the R API safely from C++ contexts. 
This has always been possible with e.g. R_ToplevelExec() and 
R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). In 
theory, as a prototype, an R package could provide a 'safe' C++ interface to 
the R API using R_UnwindProtect() and friends as appropriate, and client 
packages could import and link to that package to gain access to the interface. 
Code generators (as Rcpp Attributes does) can handle some of the pain in these 
interfaces, so that users are mostly insulated from the nitty gritty details.


I agree that we should strive to provide tools that make it safer, but note 
that it still requires participation of the users - they have to use such 
facilities or else they hit the same problem. So we can only fix this for the 
future, 

Re: [R-pkg-devel] Error appearing only with check_win_devel() - could be ggplot2 R version?

[Winston Chang]

On Sat, Mar 30, 2019 at 5:06 PM Gábor Csárdi  wrote:

> I think this is temporary and will go away once R-devel is built with
> this:
> https://github.com/wch/r-source/commit/9542c3215a8f8cfee4a313b6c2fd03320e38e1de
>
>
Before that commit (76285), I was getting a different error when I
submitted a package that used ggplot2 (and therefore grid). Now, I'm
getting the same "invalid unit" error that the others have mentioned,
with 76300
on Debian, though not with 76300 Windows.

-Winston

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Error appearing only with check_win_devel() - could be ggplot2 R version?

[Gábor Csárdi]

I think this is temporary and will go away once R-devel is built with
this: 
https://github.com/wch/r-source/commit/9542c3215a8f8cfee4a313b6c2fd03320e38e1de

Gabor


On Sat, Mar 30, 2019 at 9:56 PM Pedro J. Aphalo
 wrote:
>
> My packages are getting the same error in some CRAN checks as well as
> ggplot2 itself. With my updated package 'ggpmisc' that I was planning to
> submit to CRAN I see the same in Winbuilder under R-devel but no error
> when checking with rhub.
>
> For the 'ggplot2' failed checks see:
>
> https://cran.r-project.org/web/checks/check_results_ggplot2.html
>
> Pedro.
>
> On 2019-03-30 20:53, thorgamma wrote:
> > I have a plot example that runs fine on Windows, but in the windows check I
> > get the following message:
> >
> > Warning: package 'ggplot2' was built under R version 3.7.0
> >> plot_spec_from_hist(photons_cs137_hist[1:16, ], "mR_h", "Example: Cs-137 
> >> with scatter")
> > Error in valid.units(units) : Invalid unit
> > Calls:  ... unit.c -> unit -> valid.unit -> structure -> 
> > valid.units
> >
> >
> > Could this be only happening because of the version ggplot2 is built
> > under in this test? I'm running the latest R version - 3.5.3.
> >
> >
> > Thanks,
> >
> > Mark
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> --
> 
> Pedro J. Aphalo
> University Lecturer, Principal Investigator
> (Office 5605, Biocenter 3, Viikinkaari 1)
>
> Department of Biosciences
> Plant Biology
> P.O. Box 65
> 00014 University of Helsinki
> Finland
>
> e-mail: pedro.aph...@helsinki.fi 
> Tel. (mobile) +358 50 4150623
> Tel. (office) +358 2941 57897
>
> 
> *Web sites and blogs*
> Web site (research group): http://blogs.helsinki.fi/senpep-blog/
> Web site (own teaching): http://www.helsinki.fi/people/pedro.aphalo/
> Web site (using R in photobiology): http://www.r4photobiology.info/
> 
> *Societies*
> UV4Plants  (communications officer), ESP
>  (member) SEB 
> (member), BES  (member), SPPS
>  (member), SMS
>  (member), TUG
>  (member), FOAS  (member).
> 
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Error appearing only with check_win_devel() - could be ggplot2 R version?

[Pedro J. Aphalo]

My packages are getting the same error in some CRAN checks as well as 
ggplot2 itself. With my updated package 'ggpmisc' that I was planning to 
submit to CRAN I see the same in Winbuilder under R-devel but no error 
when checking with rhub.

For the 'ggplot2' failed checks see:

https://cran.r-project.org/web/checks/check_results_ggplot2.html

Pedro.

On 2019-03-30 20:53, thorgamma wrote:
> I have a plot example that runs fine on Windows, but in the windows check I
> get the following message:
>
> Warning: package 'ggplot2' was built under R version 3.7.0
>> plot_spec_from_hist(photons_cs137_hist[1:16, ], "mR_h", "Example: Cs-137 
>> with scatter")
> Error in valid.units(units) : Invalid unit
> Calls:  ... unit.c -> unit -> valid.unit -> structure -> 
> valid.units
>
>
> Could this be only happening because of the version ggplot2 is built
> under in this test? I'm running the latest R version - 3.5.3.
>
>
> Thanks,
>
> Mark
>
>   [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
-- 

Pedro J. Aphalo
University Lecturer, Principal Investigator
(Office 5605, Biocenter 3, Viikinkaari 1)

Department of Biosciences
Plant Biology
P.O. Box 65
00014 University of Helsinki
Finland

e-mail: pedro.aph...@helsinki.fi 
Tel. (mobile) +358 50 4150623
Tel. (office) +358 2941 57897


*Web sites and blogs*
Web site (research group): http://blogs.helsinki.fi/senpep-blog/
Web site (own teaching): http://www.helsinki.fi/people/pedro.aphalo/
Web site (using R in photobiology): http://www.r4photobiology.info/

*Societies*
UV4Plants  (communications officer), ESP 
 (member) SEB  
(member), BES  (member), SPPS 
 (member), SMS 
 (member), TUG 
 (member), FOAS  (member).


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Error appearing only with check_win_devel() - could be ggplot2 R version?

[thorgamma]

I have a plot example that runs fine on Windows, but in the windows check I
get the following message:

Warning: package 'ggplot2' was built under R version 3.7.0
> plot_spec_from_hist(photons_cs137_hist[1:16, ], "mR_h", "Example: Cs-137 with 
> scatter")
Error in valid.units(units) : Invalid unit
Calls:  ... unit.c -> unit -> valid.unit -> structure -> valid.units


Could this be only happening because of the version ggplot2 is built
under in this test? I'm running the latest R version - 3.5.3.


Thanks,

Mark

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] [External] re: default for 'signif.stars'

[Lenth, Russell V]

Abs,

There are definitely problems with the editorial, but I think "most 
mega-ultra-super-biased" is an overreaction. It appears that you have 
overlooked some of the points made there, and the fact that it does not pretend 
to be an exhaustive list of alternative methods. The editorial attempts to 
digest what is in 43 articles in that special issue. Some of those articles do 
promote Bayesian methods – not a surprise – and some advocate using P values 
but without ascribing magical properties to P < 0.05. My own emmeans package 
does present P values (sans stars, or emojis either) in a lot of contexts.

More to the point, the criticisms you offer have to do with later sections of 
the editorial – not the initial part, which is largely a repeat of an earlier 
ASA statement on interpretation of P values with the added recommendation that 
people should never say "statistically significant." It is that initial part 
that I think does describe a consensus of a large and growing proportion of 
statisticians and other scientists that placing undue emphasis on "statistical 
significance" is a bad thing. Emphasizing P values by adding stars encourages 
that kind of misdirected emphasis.

It seems fairly harmless to change the default for "show.signif.stars" to 
FALSE. However, I do recognize that no change to R's defaults should be taken 
lightly or done without careful consideration. I only ask that such careful 
consideration take place, and hope in fact that a plan can be made to phase-in 
such a change. 

Thanks,

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science   
The University of Iowa  -  Iowa City, IA 52242  USA   
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017



From: Abs Spurdle  
Sent: Thursday, March 28, 2019 12:19 AM
To: Lenth, Russell V ; r-devel 
Subject: [External] re: [Rd] default for 'signif.stars'

I read through the editorial.
This is the one of the most mega-ultra-super-biased articles I've ever read.

e.g.
The authors encourage Baysian methods, and literally encourage subjective 
approaches.
However, there's only one reference to robust methods and one reference to 
nonparametric methods, both of which are labelled as purely exploratory 
methods, which I regard as extremely offensive.
And there don't appear to be any references to semiparameric methods, or 
machine learning.

Surprisingly, they encourage multiple testing, however, don't mention the 
multiple comparison problem.
Something I can't understand at all.

So, maybe we should replace signif.stars with emoji...?


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use of C++ in Packages

[cstrato]

Hi,

It may or may not be of interest to you but an example how to access R 
functions from C++ can be found in the ROOT C++ framework, ROOT Version 
6, see e.g.:

https://root.cern/doc/master/classROOT_1_1R_1_1TRInterface.html
with an example shown in:
https://root.cern/doc/master/r_2example_8C.html

BTW, I strongly disagree that C++ does not have  a bright future!

Best regards,
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
V.i.e.n.n.a   A.u.s.t.r.i.a
e.m.a.i.l:    cstrato at aon.at
_._._._._._._._._._._._._._._._._._


P.S.: Accessing a complete C++ program (based on ROOT Version 5) from R 
is shown in my Bioconductor package 'xps'


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use of C++ in Packages

[Romain Francois]

tl;dr: we need better C++ tools and documentation. 

We collectively know more now with the rise of tools like rchk and improved 
documentation such as Tomas’s post. That’s a start, but it appears that there 
still is a lot of knowledge that would deserve to be promoted to actual 
documentation of best practices. 

I think it is important to not equate C++ as a language, and Rcpp. 

Also, C++ is not just RAII. 

RAII is an important part of how Rcpp was conceived for sure, but it’s not the 
only thing C++ can bring as a language. Templates, lambdas, the stl are 
examples of things that can be used for expressiveness when just accessing data 
without interfering with R, calling R api functions ... 

It would be nice that the usual « you should do that only if you know what 
you’re doing » be transformed to precise documentation, and maybe become part 
of some better tool. If precautions have to be taken before calling such and 
such functions: that’s ok. What are they ? Can we embed that in some tool.

 It is easy enough to enscope code that uses potentially jumpy code into a c++ 
lambda. This could be together with recommendations such as the body of the 
lambda shall only use POC data structures. 

This is similar to precautions you’d take when writing concurrent code. 

Romain

> Le 30 mars 2019 à 00:58, Simon Urbanek  a écrit :
> 
> Kevin,
> 
> 
>> On Mar 29, 2019, at 17:01, Kevin Ushey  wrote:
>> 
>> I think it's also worth saying that some of these issues affect C code
>> as well; e.g. this is not safe:
>> 
>>   FILE* f = fopen(...);
>>   Rf_eval(...);
>>   fclose(f);
> 
> I fully agree, but developers using C are well aware of the necessity of 
> handling lifespan of objects explicitly, so at least there are no surprises.
> 
> 
>> whereas the C++ equivalent would likely handle closing of the file in the 
>> destructor. In other words, I think many users just may not be cognizant of 
>> the fact that most R APIs can longjmp, and what that implies for cleanup of 
>> allocated resources. R_alloc() may help solve the issue specifically for 
>> memory allocations, but for any library interface that has a 'open' and 
>> 'close' step, the same sort of issue will arise.
> 
> Well, I hope that anyone writing native code in package is well aware of that 
> and will use an external pointer with finalizer to clean up native objects in 
> any 3rd party library that are created during the call.
> 
> 
>> What I believe we should do, and what Rcpp has made steps towards, is make 
>> it possible to interact with some subset of the R API safely from C++ 
>> contexts. This has always been possible with e.g. R_ToplevelExec() and 
>> R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). 
>> In theory, as a prototype, an R package could provide a 'safe' C++ interface 
>> to the R API using R_UnwindProtect() and friends as appropriate, and client 
>> packages could import and link to that package to gain access to the 
>> interface. Code generators (as Rcpp Attributes does) can handle some of the 
>> pain in these interfaces, so that users are mostly insulated from the nitty 
>> gritty details.
> 
> I agree that we should strive to provide tools that make it safer, but note 
> that it still requires participation of the users - they have to use such 
> facilities or else they hit the same problem. So we can only fix this for the 
> future, but let's start now.
> 
> 
>> I agree that the content of Tomas's post is very helpful, especially since I 
>> expect many R programmers who dip their toes into the C++ world are not 
>> aware of the caveats of talking to R from C++. However, I don't think it's 
>> helpful to recommend "don't use C++"; rather, I believe the question should 
>> be, "what can we do to make it possible to easily and safely interact with R 
>> from C++?". Because, as I understand it, all of the problems raised are 
>> solvable: either through a well-defined C++ interface, or through better 
>> education.
> 
> I think the recommendation would be different if such tools existed, but they 
> don't. It was based on the current reality which is not so rosy.  Apparently 
> the post had its effect of mobilizing C++ proponents to do something about 
> it, which is great, because if this leads to some solution, the 
> recommendation in the future may change to "use C++ using tools XYZ".
> 
> 
>> I'll add my own opinion: writing correct C code is an incredibly difficult 
>> task. C++, while obviously not perfect, makes things substantially easier 
>> with tools like RAII, the STL, smart pointers, and so on. And I strongly 
>> believe that C++ (with Rcpp) is still a better choice than C for new users 
>> who want to interface with R from compiled code.
> 
> My take is that Rcpp makes the interface *look* easier, but you still have to 
> understand more about the R API that you think. Hence it much easier to write 
> buggy code. Personally, that's why I don't like it (apart from the code 
>