Release 0.6.39 of the digest package arrived at CRAN today and has also been uploaded to Debian.
digest
creates hash digests of arbitrary R objects. It can use a number
different hashing algorithms (md5, sha-1,
sha-256, sha-512, crc32,
xxhash32, xxhash64, murmur32,
spookyhash, blake3,crc32c,
xxh3_64 and xxh3_128), and enables easy
comparison of (potentially large and nested) R language objects as it
relies on the native serialization in R. It is a mature and widely-used
package (with 86.8 million downloads just on the partial cloud mirrors
of CRAN which keep logs) as many tasks may involve caching of
objects for which it provides convenient general-purpose hash key
generation to quickly identify the various objects.
As noted last week in the 0.6.38
release note, hours after it was admitted to CRAN, I heard from the
ever-so-tireless Brian Ripley about an SAN issue on arm64 only (and
apparently non-reproducible elsewhere). He kindly provided a fix; it
needed a cast. Checking this on amd64 against our Rocker-based ASAN and UBSAN
containers (where is remains impossible to replicate, this issue is
apparently known for some arm64 issues) another micro-issue (of a
missing final argument NULL missing in one
.Call()) was detected. Both issues were fixed the same day,
and constitute the only change here. I merely waited a week to avoid a
mechanical nag triggered when release happen within a week.
My CRANberries provides a summary of changes to the previous version. For questions or comments use the issue tracker off the GitHub repo. For documentation (including the changelog) see the documentation site.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Welcome to post 55 in the R4 series.
r2u brings CRAN packages for R to Ubuntu. We mentioned it in the R4 series within the last year in posts #54 about faster CI, #48 about the r2u keynote at U Mons, #47 reviewing r2u it at its third birthday, #46 about adding arm64 support, and #44 about the r2u for mlops talk.
Today brings news of an important (internal) update. Following both the arm64 builds as well as the last bi-annual BioConductor package update (and the extension of BioConductor coverage to arm64), more and more of our build setup became automated at GitHub. This has now been unified. We dispatch builds for amd64 packages for ‘jammy’ (22.04) and ‘noble’ (24.04) (as well as for the arm64 binaries for ‘noble’) from the central build repository and enjoy the highly parallel build of the up to fourty available GitHub Runners. In the process we also switched fully to source builds.
In the past, we had relied on p3m.dev (formerly known as ppm and
rspm) using its binaries. These so-called ‘naked binaries’ are what R
produces when called as R CMD INSTALL --build. They are
portable with the same build architecture and release, but do not carry
packaging information. Now, when a Debian or Ubuntu .deb binary is
built, the same step of R CMD INSTALL --build happens. So
our earlier insight was to skip the compilation step, use the p3m
binary, and then wrap the remainder of a complete package around it.
Which includes the all-important dependency information for both the R
package relations (from hard Depends / Imports / LinkingTo or soft
Suggests declarations) as well as the shared library dependency
resolution we can do when building for a Linux
distribution.
That served us well, and we remain really grateful for the p3m.dev build service. But it also meant were dependending on the ‘clock’ and ‘cadence’ of p3m.dev. Which was not really a problem when it ran reliably daily, and early too, included weekends, and showed a timestamp of last updates. By now it is a bit more erratic, frequently late, skips weekends more regularly and long stopped showing when it was last updated. Late afternoon releases reflecting the CRAN updates ending one and half-days earlier is still good, it’s just not all that current. Plus there was always the very opaque occurrencem where maybe one in 50 packages or so would not even be provided as a binary so we had to build it anyway—the fallback always existing, and was used for both BioConductor (no binaries) and arm64 (no binaries at first, this now changed). So now we just build packages the standard way, albeit as GitHub Actions.
In doing so we can ignore p3m.dev, and rather follow the CRAN clock and cadence (as for
example CRANberries does),
and can update several times a day. For example early this morning
(Central time) we ran update for the then-new 28 source packages
resulting in 28 jammy and 36 noble binary packages; right now in
mid-afternoon we are running another build for 37 source packages
resuling in 37 jammy and 47 noble packages. (Packages without a
src/ directory and hence no compilation can be used across
amd64 and arm64; those that do have src/ are rebuilt for
arm64 hence the different sets of jammy and noble packages as only the
latter has arm64 now.) This gets us packages from this morning into r2u which p3m.dev should
have by tomorrow afternoon or so.
And with that r2u remains “Fast. Easy. Reliable. Pick all three!” and also a little more predictable and current in its delivery. What’s not to like?
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.