<div dir="ltr"><div><span style="font-family:monospace">R Under development (unstable) (2020-06-07 r78653)<br>Platform: x86_64-w64-mingw32/x64 (64-bit)<br>Running under: Windows 10 x64 (build 18362)</span></div><div><br></div><div>It's R 4.0.1 using Jeroen rtools40 scripts on Win 10 64bit.<br></div><div><br></div><div>1513 OK, not sure why sessionInfo() went nuts though per below. Restarting R worked to provide the session info above.<br></div><div><br></div><div><br></div><div><span style="font-family:monospace">[1] "All ok, 1513 results"</span></div><span style="font-family:monospace">Warning message:<br>In dir.create("templib") : 'templib' already exists<br>> sessionInfo()<br>Error: $ operator is invalid for atomic vectors<br>In addition: Warning messages:<br>1: In FUN(X[[i]], ...) :<br> DESCRIPTION file of package 'foo' is missing or broken<br>2: In FUN(X[[i]], ...) :<br> DESCRIPTION file of package 'fooModule' is missing or broken</span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 1:47 PM Dirk Eddelbuettel <<a href="mailto:edd@debian.org">edd@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi all,<br>
<br>
Below is an ascii version of what I blogged yesterday, proper URL links are<br>
at <a href="http://dirk.eddelbuettel.com/blog/2020/06/15#rcpp_1.0.5_testing" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com/blog/2020/06/15#rcpp_1.0.5_testing</a><br>
<br>
Help in testing, particular on unusual hardware or compiler choices, or<br>
particularly old releases of OS, compiler, R, ... would be welcome. I am<br>
quite confident the release will be fine on CRAN and standard systems.<br>
<br>
But for use on less standard setups, the time to test is now. If you are a<br>
user of Rcpp under such circumstance, please help now in testing and<br>
reporting issues, if any are seen.<br>
<br>
Thanks, Dirk<br>
<br>
<br>
Mon, 15 Jun 2020<br>
<br>
Rcpp 1.0.5 in two+ weeks: Please help test<br>
<br>
rcpp logo<br>
<br>
With the current four-month release cycle, the next Rcpp release is due in<br>
July following the 1.0.4 release in March. Just prior to the 1.0.4 release<br>
I had asked this:<br>
<br>
It would be particularly beneficial if those with “unsual” build<br>
dependencies tested it as we would increase overall coverage beyond what<br>
I get from testing against 1800+ CRAN packages. BioConductor would also<br>
be welcome.<br>
<br>
but only on the rcpp-devel list, and only about a good week prior to the<br>
release.<br>
<br>
I remain rather disappointed and disillusioned about what happened after<br>
1.0.4 was released. Two PRs in that release were soon seen to have side<br>
effects on more ‘marginal’ test systems, precisely what added testing<br>
could have revealed. An additional issue arose from changes in R’s make<br>
system, which is harder to anticipate or test. Each and every infelicity<br>
was fixed within a day or so, and we always make candidate releases<br>
available—the current Rcpp as of this writing is 1.0.4.12 meaning twelve<br>
microreleases were made since 1.0.4. And those microreleases are always<br>
available for normal download and install.packages use via the Rcpp drat<br>
repository accessible to all. So it was truly troubling to see some,<br>
especially those with experience in setting up or running testing / ci<br>
platforms, pretend to be unable to access, install, and provide these for<br>
their own tests, or the tests of their users. It just doesn’t pass a basic<br>
logic test: it takes a single call to install.packages(), or, even more<br>
easily, a single assignment of an auxiliary repo. All told this was a<br>
rather sad experience.<br>
<br>
So let’s try to not repeat this. If you, or maybe users of a build or ci<br>
system you maintain, rely on Rcpp, and especially if you do so on systems<br>
outside the standard CRAN grid of three OSs and the triplet of “previous,<br>
current, next” releases of R, then please help by testing. I maitain these<br>
release as a volunteer, unpaid at that, and I simply cannot expand to more<br>
systesm. We take reverse dependency check seriously (and I just run two<br>
taking about a day each) but if you insist on building on stranger<br>
hardware or much older releases it will be up to you to ensure Rcpp<br>
passes. We prep for CRAN, and try our best to pass at CRAN. For nearly a<br>
dozen years.<br>
<br>
To install the current microrelease from the Rcpp drat repository, just do<br>
<br>
install.packages("Rcpp", repos="<a href="https://rcppcore.github.io/drat" rel="noreferrer" target="_blank">https://rcppcore.github.io/drat</a>")<br>
<br>
That is all there is to it. You could even add the Rcpp drat repository to<br>
your repository list.<br>
<br>
Rcpp has become successful because so many people help with suggestions,<br>
documentation, and code. It is used by (as of today) 1958 CRAN packages,<br>
205 BioConductor packages, and downloaded around a million times per<br>
month. So if you can, please help now with some more testing.<br>
<br>
If you like this or other open-source work I do, you can now sponsor me at<br>
GitHub. For the first year, GitHub will match your contributions.<br>
<br>
This post by Dirk Eddelbuettel originated on his Thinking inside the box<br>
blog. Please report excessive re-aggregation in third-party for-profit<br>
settings.<br>
<br>
/code/rcpp | permanent link<br>
<br>
<br>
<br>
-- <br>
<a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a><br>
_______________________________________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a></blockquote></div>