Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language–and is
widely used by (currently) 1074 other packages on CRAN, downloaded 29.3 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 535 times according
to Google Scholar.
This release brings a new upstream release 12.4.0 made by Conrad a
day or so ago. I prepared the usual release candidate, tested on the
over 1000 reverse depends (which sadly takes almost a day on old
hardware), found no issues and sent it to CRAN. Where it got tested
again and was once again auto-processed smoothly by CRAN within a few
hours on a Friday night which is just marvelous. So this time I tweeted
about it too.
The releases actually has a relatively small set of changes as a
second follow-up release in the 12.* series.
Changes
in RcppArmadillo version 0.12.4.0.0 (2023-05-26)
Upgraded to Armadillo release 12.4.0 (Cortisol Profusion
Redux)
Added norm2est() for finding fast estimates of
matrix 2-norm (spectral norm)
Added vecnorm() for obtaining the vector norm of
each row or column of a matrix
The sixth release of the still new-ish qlcal package
arrivied at CRAN today.
qlcal
delivers the calendaring parts of QuantLib. It is provided (for the R
package) as a set of included files, so the package is self-contained
and does not depend on an external QuantLib library (which can be
demanding to build). qlcal covers
over sixty country / market calendars and can compute holiday lists, its
complement (i.e. business day lists) and much more.
This release brings updates to a few calendars which happened since
the QuantLib 1.30 release, and also updates a several of the (few)
non-calendaring functions.
Changes in version 0.0.6
(2023-05-24)
Several calendars (India, Singapore, South Africa, South Korea)
updated with post-QuantLib 1.3.0 changes (Sebastian Schmidt in #6)
Three now-used scheduled files were removed (Dirk in #7))
A number of non-calendaring files used were synchronised with the
current QuantLib repo (Dirk in #8)
Last release, we also added a quick little demo using
xts to column-bind calendars produced from each of the
different US sub-calendars. This is a slightly updated version of the
sketch we
tooted a few days ago. The output now is
Courtesy of my CRANberries, there
is a diffstat report for this
release. See the project page
and package documentation for more details, and more examples.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
We are happy to share that the RcppSimdJson
package has been updated to release 0.1.10.
RcppSimdJson
wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via
very clever algorithmic engineering to obtain largely branch-free code,
coupled with modern C++ and newer compiler instructions, it results in
parsing gigabytes of JSON parsed per second which is quite
mindboggling. The best-case performance is ‘faster than CPU speed’ as
use of parallel SIMD instructions and careful branch avoidance can lead
to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire
at QCon.
This release updates the underlying simdjson library to
version 3.1.8 (also made today). Otherwise we only made a minor edit to
the README and adjusted one tweek for code coverage.
The (very short) NEWS entry for this release follows.
Changes in version 0.1.10
(2023-05-14)
simdjson was upgraded to version 3.1.8
(Dirk in #85).
A first follow-up to the initial
announcement just days ago of the new crc32c
package. The package offers cyclical checksum with parity in
hardware-accelerated form on (recent enough) intel cpus as well as on
arm64.
This follow-up was needed because I missed, when switching to a
default static library build, that newest compilers would
complain if -fPIC was not set. gcc-12 on my
box was happy, gcc-13 on recent Fedora as used at CRAN was
not. A second error was assuming that saying
SystemRequirements: cmake would suffice. But hold on
whippersnapper: macOS always has a surprise for you! As
described at the end of the appropriate section in Writing R
Extensions, on that OS you have to go the basement, open
four cupboards, rearrange three shelves and then you get to use it. And
then in doing so (from an added configure script) I failed
to realize Windows needed a fallback. Gee.
The NEWS entry for this (as well the initial release) follows.
Changes in version 0.0.2
(2023-05-11)
Explicitly set cmake property for
position-independent code
Help macOS find its cmake binary as
detailed also in WRE
Help Windows with a non-conditional Makevars.win pointing at
cmake
Add more badges to README.md
Changes in version 0.0.1
(2023-05-07)
Initial release version and CRAN upload
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
Happy to announce a new package: crc32c. This
arose out of a user request to add crc32c (which is related
to but differnt from crc32 without the trailing c) to my digest
package. Which I did (for now in a branch), using the software-fallback
version of crc32c from the reference implementation by
Google at their crc32c
repo.
However, the Google repo also offers hardware-accelerated versions
and switches at run-time. So I pondered a little about how to offer the
additional performance without placing a dependency burden on all users
of digest.
Lo and behold, I think I found a solution by reusing what R offers.
First off, the crc32c package
wraps the Google repo cleanly and directly. We include all the repo code
– but not the logging or benchmarking code. This keeps external
dependencies down to just cmake. Which while still rare in
the CRAN world is at least not entirely uncommon. So now each time you
build the crc32c R
package, the upstream hardware detection is added transparently
thanks in part to cmake. We build libcrc32c.a
as a static library and include it in the R package and its own shared
library.
And we added exporting of three key functions, directly at the C
level, along with exporting one C level function of package that other
packages can call. The distinction matters. The second step of offering
a function R can call (also from other packages) is used and documented.
By means of an Imports: statement to instantiate the
package providing the functionality, the client package obtains access
to a compiled functions its R code can then call. A number of other R
packages use this.
But what is less well known is that we can do the same with C level
functions. Again, it takes an imports statement but once that is done we
can call ‘C to C’. Which is quite nice. I am working currently on the
branch in digest which
motivated this, and it can import the automagically
hardware-accelerated functionality on the suitable hardware. Stay
tuned for a change in digest.
I also won and lost the CRAN lottery for once: the package made it
through the ‘new package’ checks without any revisions. Only to then
immediately fail on the CRAN machines using gcc-13 as a
-fPIC was seen as missing when making the shared library.
Even though both my
CI and the r-universe builds
were all green. Ah well. So a 0.0.2 release will be coming in a day or
two.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
A new release 0.4.18 of RQuantLib
arrived at CRAN earlier today,
and will be uploaded to Debian as
well.
QuantLib is a very
comprehensice free/open-source library for quantitative
finance; RQuantLib
connects it to the R environment and language.
This release of RQuantLib
comes about six months after the previous maintenance release. It brings
a few small updates triggered by small changes in the QuantLib releases
1.29 and 1.30. It also contains updates reflecting changes in the
rgl package kindly contributed by Duncan Murdoch. Last but
not least, Jeroen Ooms helped with two pull requests updating builds on,
repspectively, macOS and Windows by updating the pre-made libraries of
QuantLib.
Changes in RQuantLib version 0.4.18 (2023-05-01)
Use of several rgl functions was updated to a new
naming scheme in the package (kindly contributed by Duncan Murdoch in #174)
A default argument is now given for option surface plots
Changed call from SwaptionVolCube1 to SabrSwaptionVolatilityCube
(conditional on using QuantLib 1.30 or later)
Some other deprecation warnings were tweaked as in QL test
file
Builds for macOS and Windows were updated with more library build
(changes kindly contributed by Jeron Ooms in #176 and
#175)
Some remaining throw calls were replace by
Rcpp::stop
The fifth release of the still new-ish qlcal package
arrivied at CRAN just now.
qlcal
delivers the calendaring parts of QuantLib. It is provided (for the R
package) as a set of included files, so the package is self-contained
and does not depend on an external QuantLib library (which can be
demanding to build). qlcal covers
over sixty country / market calendars and can compute holiday lists, its
complement (i.e. business day lists) and much more.
This release brings updates to five calendars from the QuantLib 1.30
release from this week.
Changes in version 0.0.5
(2023-04-19)
Calendars routines for Australia, Denmark, New Zealand, Turkey
and the US have been updated from QuantLib 1.30.
Support for 'Australia/ASX' has been added.
Added demo showing all US holidays in current year
We also added a quick little demo using xts to
column-bind calendars produced from each of the different US
sub-calendars. This is a slightly updated version of the sketch we
tooted a few days ago. The output now is
(and we just discovered a tiny h -> hols
bug in the demo so see the git repo – sorry!).
The release was finalized uploaded yesterday morning. But because we
have to set CXX_STD=CXX14 as satisfy requirements of some
of the Boost headers, we get ourselves a NOTE and with that a manual
inspection … and a delay of 1 1/2 days. Not really all that meaningful
in the grand scheme of things but still suboptimal relative to the fully
automated passage this release should have gotten. Oh well.
Courtesy of my CRANberries, there
is a diffstat report for this
release. See the project page
and package documentation for more details, and more examples.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language–and is
widely used by (currently) 1052 other packages on CRAN, downloaded 28.6 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 522 times according
to Google Scholar.
This release brings a new upstream release 12.2.0 made by Conrad a
day or so ago. We prepared the usual release candidate, tested on the
over 1000 reverse depends, found no issues and sent it to CRAN. Where it
got tested again and was auto-processed smoothly by CRAN.
The releases actually has a relatively small set of changes as a
first follow-up release in the 12.2.* series.
Changes
in RcppArmadillo version 0.12.2.0.0 (2023-04-04)
Upgraded to Armadillo release 12.2.0 (Cortisol Profusion
Deluxe)
more efficient use of FFTW3 by fft() and
ifft()
faster in-place element-wise multiplication of sparse matrices by
dense matrices
added spsolve_factoriser class to allow reuse of sparse matrix
factorisation for solving systems of linear equations
The nineteenth release of littler as a
CRAN package
landed this morning, following in the now seventeen year history (!!) as
a package started by Jeff in 2006, and joined
by me a few weeks later.
littler
is the first command-line interface for R as it predates
Rscript. It allows for piping as well for shebang
scripting via #!, uses command-line arguments more
consistently and still starts
faster. It also always loaded the methods package which
Rscript only began to do in recent years.
littler
lives on Linux and Unix, has its difficulties on macOS due to
yet-another-braindeadedness there (who ever thought case-insensitive
filesystems as a default were a good idea?) and simply does not exist on
Windows (yet – the build system could be extended – see RInside for
an existence proof, and volunteers are welcome!). See the FAQ
vignette on how to add it to your PATH. A few examples
are highlighted at the Github repo, as well
as in the examples
vignette.
This release is somewhat unique is not having any maintenance of the
small core but rather focussing exclusively on changes to the (many !!)
scripts collected in examples/scripts/.
We added new ones and extended several existing ones including
install2.r thanks to patches by @eitsupi. Of the new scripts, I already
use tttl.r quite a bit for tests on co-maintained packages
that use testthat (but as I have made known before my heart
belongs firmly to tinytest as nobody should need thirty-plus
recursive dependencies to run a few test predicates) as well as the
very new installRub.r to directly add r-universe Ubuntu binaries
onto an r2u systems as
demonstrated in a first
and second
tweet (and corresponding toot) this week.
The full change description follows.
Changes in littler
version 0.3.18 (2023-03-25)
Changes in examples scripts
roxy.r can now set an additional
--libpath
getRStudioDesktop.r and
getRStudioServer.r have updated default download
file
install2.r and installGithub.r can set
--type
r2u.r now has a --suffix
option
tt.r removes a redundant library
call
tttl.r has been added for
testthat::test_local()
installRub.r has been added to install r-universe
binaries on Ubuntu
install2.r has updated error capture messages
(Tatsuya Shima and Dirk in #104)
My CRANberries
service provides a comparison to the
previous release. Full details for the littler
release are provided as usual at the ChangeLog
page, and also on the package docs website.
The code is available via the GitHub repo, from
tarballs and now of course also from its CRAN
page and via install.packages("littler"). Binary
packages are available directly in Debian (currently in ‘experimental’
due to a release freeze) as well as (in a day or two) Ubuntu binaries at
CRAN thanks to the tireless Michael Rutter — and of course via r2u following its next
refresh.
Comments and suggestions are welcome at the GitHub repo.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
A new release 0.2.7 of our RcppSMC package arrived at
CRAN earlier today. It contains
several extensions added by team member (and former GSoC student) Ilya Zarubin since the last
release. We were a little slow to release those—but “one of those CRAN
emails” forced our hand for a release now. The updated ‘uninitialized
variable’ messages in clang++-16 have found a fan in Brian
Ripley, and so he sent us a note. And as the issue was trivially
reproducible with clang++-15 here too I had it fixed in no
time. And both changes taken together form the incremental 0.2.7
release.
RcppSMC
provides Rcpp-based bindings to R for the Sequential Monte Carlo
Template Classes (SMCTC) by Adam Johansen described in his JSS article.
Sequential Monte Carlo is also referred to as Particle Filter
in some contexts. The package now also features the Google Summer of Code
work by Leah South in 2017, and by Ilya Zarubin in 2021.
The release is summarized below.
Changes in RcppSMC
version 0.2.7 (2023-03-22)
Extensive extensions for conditional SMC and resample, updated
hello_world example, added skeleton function for easier
package creation (Ilya in #67,#72)
A new release 0.2.3 of pkgKitten
arrived on CRAN earlier, and
will be uploaded to Debian. pkgKitten
makes it simple to create new R packages via a simple function
invocation. A wrapper kitten.r exists in the littler
package to make it even easier.
This release improves the created ‘Description:’, and updated some of
the continuous integration.
Changes in version 0.2.3
(2023-03-11)
Small improvement to generated Description: field and
Title:
A new minor release 0.2.3 of our RcppRedis
package arrived on CRAN today.
RcppRedis
is one of several packages connecting R to the fabulous Redis in-memory datastructure store (and
much more). RcppRedis
does not pretend to be feature complete, but it may do some things
faster than the other interfaces, and also offers an optional coupling
with MessagePack binary
(de)serialization via RcppMsgPack. The
package has carried production loads on a trading floor for several
years.
This update is fairly mechanical. CRAN wants everybody off the C++11
train which is fair game given that it 2023 and most sane and lucky
people are facing sane and modern compilers so this makes sense. (And I
raise a toast to all those poor souls facing RHEL 7 / CentOS 7 with a
compiler from many moons ago: I hear it is a vibrant job market
out there so maybe time to make a switch…). As with a few of my other
packages, this release simply does away with the imposition of C++11 as
the package will compile just fine under C++14 or C++17 (as governed by
your version of R).
The detailed changes list follows.
Changes in version 0.2.3
(2023-03-08)
No longer set a C++ compilation standard as the default choices
by R are sufficient for the package
Switch include to Rcpp/Rcpp which signals use of all Rcpp
features including Modules
James Yang and I are
thrilled to announce the new CRAN package RcppFastAD which
arrived at CRAN last Monday as
version 0.0.1, and is as of today at version 0.0.2 with a first set of
small updates.
It is based on the FastAD header-only C++
library by James which provides a C++ implementation of both forward and
reverse mode of automatic differentiation in an easy-to-use header
library (which we wrapped here) that is both lightweight and performant.
With a little of bit of Rcpp glue, it
is also easy to use from R in simple C++ applications. Included in the
package are three example: a simple quadratic expression evaluating
x' S x for given x and S return the expression value with a
gradient, a linear regression example generalising this and using the
gradient to derive to arrive at the least-squares minimizing solution,
as well as the well-known Black-Scholes options pricer and its important
partial derivatives delta, rho, theta and vega derived via automatic
differentiation.
The NEWS file for these two initial releases follows.
Changes in version 0.0.2
(2023-03-05)
One C++ operation is protected from operating on a
nullptr
Additional tests have been added, tests now cover all three demo
/ example functions
Return values and code for the examples
linear_regression and quadratic_expression
have been adjusted
A new minor release of our ttdo package arrived
on CRAN a few days ago. The ttdo package extends
the excellent (and very minimal / zero depends) unit testing package tinytest by Mark van der Loo with the very
clever and well-done diffobj package by
Brodie Gaslam to give us test
results with visual diffs (as shown in the screenshot below) which
seemingly is so compelling an idea that it eventually got copied by
another package which shall remain unnamed…
This release adds a versioned dependency on the just released tinytest version
1.4.1. As we extend tinytest (for use
in the autograder we deploy within the lovely PrairieLearn framework) by
consuming the tinytest code we
have to update in sync.
There were no other code changes in the package beside the usual
maintenance of badges and continuous integration setup.
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language–and is
widely used by (currently) 1042 other packages on CRAN, downloaded 28.1 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 513 times according
to Google Scholar.
This release brings a new upstream release 12.0.1. We found a small
regression with the 12.0.0 release when we tested prior to a CRAN
upload. Conrad very promptly fixed
this with a literal one liner and made it 12.0.1 which we
wrapped up as 0.12.0.1.0. Subsequent testing revealed no issues for us,
and CRAN autoprocessed it as I
tweeted earlier. This is actually quite impressive given the over
1000 CRAN packages using it all of which got tested again by CRAN. All
this is testament to the rigour, as well as the well-oiled process at
the repository. Our thanks go to the tireless maintainers!
The releases actually has a rather nice set of changes (detailed
below) to which we added one robustification thanks to Kevin.
The full set of changes follows. We include the previous changeset as
we may have skipped the usual blog post here.
Changes
in RcppArmadillo version 0.12.0.1.0 (2023-02-20)
Upgraded to Armadillo release 12.0.1 (Cortisol Profusion)
faster fft() and ifft() via optional
use of FFTW3
faster min() and max()
faster index_min() and
index_max()
added .col_as_mat() and .row_as_mat()
which return matrix representation of cube column and cube row
added csv_opts::strict option to loading CSV files
to interpret missing values as NaN
added check_for_zeros option to form 4 of sparse
matrix batch constructors
inv() and inv_sympd() with options
inv_opts::no_ugly or inv_opts::allow_approx
now use a scaled threshold similar to pinv()
set_cout_stream() and set_cerr_stream()
are now no-ops; instead use the options ARMA_WARN_LEVEL, or
ARMA_COUT_STREAM, or ARMA_CERR_STREAM
fix regression (mis-compilation) in shift() function
(reported by us in #409)
The include directory order is now more robust (Kevin Ushey in #407
addressing #406)
Changes
in RcppArmadillo version 0.11.4.4.0 (2023-02-09)
Upgraded to Armadillo release 11.4.4 (Ship of Theseus)
extended pow() with various forms of element-wise
power operations
added find_nan() to find indices of NaN
elements
faster handling of compound expressions by
sum()
The package no longer sets a compilation standard, or progagates
on in the generated packages as R ensures C++11 on all non-ancient
versions
The CITATION file was updated to the current format
A new release 0.2.18 of RInside
arrived on CRAN and in Debian today. This is the first
release in ten months since the 0.2.17 release. RInside
provides a set of convenience classes which facilitate embedding of R inside of C++ applications and
programs, using the classes and functions provided by Rcpp.
This release brings a contributed change to how the internal REPL is
called: Dominick found the
current form more reliable when embedding R on Windows. We also updated
a few other things around the package.
The list of changes since the last release:
Changes in RInside
version 0.2.18 (2023-02-01)
The random number initialization was updated as in R.
The main REPL is now running via 'run_Rmainloop()'.
Small routine update to package and continuous
integration.
Welcome to the 39th post in the relatively randomly recurring rants,
or R4 for short. Today’s
post picks up where the previous post #38:
Faster Feedback Systems started. As we argued in #38,
the need for fast feedback loops is fairly universal and
widespread. Fairly shortly after we posted #38,
useR! 2022 happened and one presentation had the key line
Waiting 1-24 minutes for a build to finish can be a massive time
suck.
which we would like to come back to today. Furthermore, the
unimitable @b0rk had a fabulous tweet just weeks later
stating the same point debugging
strategy: shorten your feedback loop as a key in a successful
debugging strategy.
So in sum: shorter is better. Nobody likes to wait. And shorter
i.e. faster is a key and recurrent theme in the R4 series. Today we
have a fairly nice illustration of two aspects we have stressed
before:
Fewer dependencies makes for faster installation time (apart from
other desirable robustness aspects); and
Using binaries makes for faster installation time as it removes
the need for compilations.
The combined effects can be staggering as we show below. The
example is motivated by a truly “surprising” (we are being generous
here) comment we received as an aside when discussing the eternal topic
of whether R users do, or do not, have a choice when picking packages,
or approaches, or verses. To our surprise, we were told that
“packages are not substitutable”. Which is both demonstrably
false (see below) and astonishing as it came from an academic.
I.e. someone trained and paid to abstract superfluous detail
away and recognise and compare ‘core’ features of items under
investigation. Truly stunning. But I digress.
CRAN by now has many
packages, slowly moving in on 20,000 in total, and is a unique success
we commented-on time and time before. By now many packages shadow or
duplicate each other, reinvent one another, or revise/review. One
example is the pair of packages accessing PostgreSQL databases. There are
several, but two are key. The older one is RPostgreSQL
which has been around since Sameer Kumar Prayaga wrote it as a Google Summer of Code
student in 2008 under my mentorship. The package has now been maintained
well (if quietly) for many years by Tomoaki Nishiyama. The other
entrant is more recent, though not new, and is RPostgres by Kirill Müller and others. We will
for the remainder of this post refer to these two as the tiny
and the tidy version as either can been as being a
representative of a certain ‘verse’.
The aforementioned comment on non-substitutability struck us as
eminently silly, so we set out to prove just how absurd it really is. So
about a year ago we set up pair of GitHub repos with minimal code in a
pair we called lim-tiny
and lim-tidy.
Our conjecture was (and is!) that less is more – just as post
#34
titled Less Is More argued with respect to package
dependencies. Each of the repos just does one thing: a query to a
(freely accessible but remote) PostgreSQL database. The tiny version
just retrieves a data frame using only the dependencies needed for RPostgreSQL
namely DBI and
nothing else. The tidy version retrieves a tibble and has access to
everything else that comes when installing RPostgres: DBI, dplyr, and magrittr – plus
of course their respective dependencies. We were able to let the code
run in (very default) GitHub Actions on a weekly schedule without
intervention apart from one change to the SQL query when the remote
server (providing public bioinformatics data) changed its schema
slighly, plus one update to the action yaml code version. No other
changes.
We measure the time a standard continuous integration run takes in
total using the default GitHub Action setup in the tidy case (which
relies on RSPM/PPM binaries, caching, …, and does not rebuild
from source each time), and our own r-ci script (introduced
in #32
for CI with R. It switched to using r2u during the course of
this experiment but already had access to binaries via c2d4u
– so it is always binaries-based (see e.g.#37
or #13
for more). The chart shows the evolution of these run-times over the
course of the year with one weekly run each.
tiny vs tidy ci timing impact
chart
This study reveals a few things:
“Yes, Veronica, we have a choice”: one year of identical
results retrieving a data set via SQL from a PostgreSQL server. We can
often choose between alternative packages to get (or process) our
data.
There is a Free Lunch (TM) here: RPostgreSQL consistently
dominates RPostgres when measured in CI run-time for the same task.
While there is (considerable) variability (likely stemming from
heterogenous setups at GitHub Action) the tiny approach is on
average about twice as fast as the tidy approch.
You do have a choice. Would you rather wait x minutes for
CI, or 2x?
The key point there is that while the net-time to fire off a single
PostgreSQL is likely (near-)identical, the net cost of continuous
integration is not. In this setup, it is about twice the run-time
simply because ‘Less Is More’ which (in this setup) comes out
to about being twice as fast. And that is a valid (and concrete, and
verifiable) illustration of the overall implicit cost of adding
dependencies to creating and using development, test, or run-time
environments.
Faster feedback loops make for faster builds and faster debugging.
Consider using fewer dependencies, and/or using binaries as provided by
r2u.
Just days after a build-fix
release (for aarch64) and still only a few weeks after the 0.2.0
release of RcppTOML
and its switch to toml++, we have
another bugfix release 0.2.2 on CRAN also bringing release 3.3.0 of
toml++ (even if we
had large chunks of 3.3.0 already incorporated).
TOML is a file format that is most
suitable for configurations, as it is meant to be edited by
humans but read by computers. It emphasizes strong readability
for humans while at the same time supporting strong typing
as well as immediate and clear error reports. On small typos
you get parse errors, rather than silently corrupted garbage. Much
preferable to any and all of XML, JSON or YAML – though sadly these may
be too ubiquitous now. TOML is
frequently being used with the projects such as the Hugo static blog compiler, or the Cargo system of Crates (aka “packages”)
for the Rust
language.
The package was building fine on Intel-based macOS provided the
versions were recent enough. CRAN, however, aims for the
broadest possibly reach of binaries and builds on a fairly ancient macOS
10.13 with clang version 10. This confused toml++ into (wrongly)
concluding it could not build when it in fact can. After a hint from Simon that Apple in their infinite
wisdom redefines clang version ids, this has been reflected in version
3.3.0 of toml++ by
Mark so we should now build
everywhere. Big thanks to everybody for the help.
The short summary of changes follows.
Changes in version 0.2.2
(2023-01-29)
New toml++ version 3.3.0 with fix to permit
compilation on ancient macOS systems as used by CRAN for the Intel-based
builds.
Two weeks after the release of RcppTOML
0.2.0 and the switch to toml++, we have a
quick bugfix release 0.2.1.
TOML is a file format that is most
suitable for configurations, as it is meant to be edited by
humans but read by computers. It emphasizes strong readability
for humans while at the same time supporting strong typing
as well as immediate and clear error reports. On small typos
you get parse errors, rather than silently corrupted garbage. Much
preferable to any and all of XML, JSON or YAML – though sadly these may
be too ubiquitous now. TOML is
frequently being used with the projects such as the Hugo static blog compiler, or the Cargo system of Crates (aka “packages”)
for the Rust
language.
Some architectures, aarch64 included, got confused over ‘float16’
which is of course a tiny two-byte type nobody should need. After
consulting with Mark we
concluded to (at least for now) simply override this excluding the use
of ‘float16’.
The short summary of changes follows.
Changes in version 0.2.1
(2023-01-25)
Explicitly set -DTOML_ENABLE_FLOAT16=0 to permit
compilation on some architectures stumbling of the type.
The Rcpp team is thrilled to announce the newest release 1.0.10 of
the Rcpp package which is hitting CRAN now and will go to Debian shortly. Windows and macOS
builds should appear at CRAN in the next few days, as will builds in
different Linux distribution and of course at r2u. The release was
prepared a few days ago, but given the widespread use at CRAN it took a
few days to be processed. As always, our sincere thanks to the CRAN
maintainers Uwe Ligges and Kurt Hornik. This release continues with the
six-months cycle started with release
1.0.5 in July 2020. As a reminder, we do of course make interim
snapshot ‘dev’ or ‘rc’ releases available via the Rcpp drat repo and strongly
encourage their use and testing—I run my systems with these versions
which tend to work just as well, and are also fully tested against all
reverse-dependencies.
Rcpp has become the most
popular way of enhancing R with
C or C++ code. Right now, around 2623 packages on CRAN depend on Rcpp for making analytical code go
faster and further, along with 252 in BioConductor. On CRAN, 13.7% of
all packages depend (directly) on CRAN, and 58.7% of all compiled
packages do. From the cloud mirror of CRAN (which is but a subset of all
CRAN downloads), Rcpp has been
downloaded 67.1 million times.
This release is incremental as usual, preserving existing
capabilities faithfully while smoothing our corners and / or extending
slightly. Of particular note is the now fully-enabled use of the
‘unwind’ protection making some operations a little faster by default;
special thanks to Iñaki for
spearheading this. Kevin and
I also polished a few other bugs off as detailed below.
The full list of details follows.
Changes in
Rcpp release version 1.0.10 (2023-01-12)
Changes in Rcpp API:
Unwind protection is enabled by default (Iñaki in #1225). It can be
disabled by defining RCPP_NO_UNWIND_PROTECT before
including Rcpp.h. RCPP_USE_UNWIND_PROTECT is
not checked anymore and has no effect. The associated plugin
unwindProtect is therefore deprecated and will be removed
in a future release.
The 'finalize' method for Rcpp Modules is now eagerly
materialized, fixing an issue where errors can occur when Module
finalizers are run (Kevin in #1231 closing #1230).
Zero-row data.frame objects can receive
push_back or push_front (Dirk in #1233 fixing #1232).
One remaining sprintf has been replaced by
snprintf (Dirk and Kevin in #1236 and #1237).
Several conversion warnings found by clang++ have
been addressed (Dirk in #1240 and #1241).
Changes in Rcpp Attributes:
The C++20, C++2b (experimental) and C++23 standards now have
plugin support like the other C++ standards (Dirk in #1228).
The source path for attributes received one more protection from
spaces (Dirk in #1235 addressing
#1234).
Boost is a very large and
comprehensive set of (peer-reviewed) libraries for the C++ programming
language, containing well over one hundred individual libraries. The BH package provides a
sizeable subset of header-only libraries for (easier, no linking
required) use by R. It is fairly widely used: the (partial) CRAN mirror
logs (aggregated from the cloud mirrors) show over 32.6 million package
downloads.
Version 1.81.0 of Boost was released in December following the
regular Boost release schedule of April, August and December releases.
As the commits and changelog show, we packaged it almost immediately and
started testing following our annual update cycle which strives to
balance being close enough to upstream and not stressing CRAN and the
user base too much. The reverse depends check revealed about a handful
of packages requiring changes or adjustments which is a pretty good
outcome given the over three hundred direct reverse dependencies. So we
opened issue
#88 to coordinate the issue over the winter break during which CRAN
also closes (just as we did before), and also
send a
wider ‘PSA’ tweet as a heads-up. Our sincere thanks to the two
packages that already updated, and the four that likely will soon. Our
thanks also to CRAN for reviewing the package impact over the last few
days since I uploaded the package earlier this week.
There are a number of changes I have to make each time in BH, and it
is worth mentioning them. Because CRAN cares about backwards
compatibility and the ability to be used on minimal or older systems, we
still adjust the filenames of a few files to fit a jurassic
constraints of just over a 100 characters per filepath present in some
long-outdated versions of tar. Not a big deal. We also, and
that is more controversial, silence a number of
#pragma diagnostic messages for g++ and
clang++ because CRAN insists on it. I have no choice in
that matter. Next, and hopefully this time only, we also found and
replaced a few remaining sprintf uses and replaced them
with snprintf. Many of the Boost libraries did that, so I
hope by the next upgrade for Boost 1.84.0 next winter this will be fully
taken care of. Lastly, and also only this time, we silenced a warning
about Boost switching to C++14 in the next release 1.82.0 in April. This
may matter for a number of packages having a hard-wired selection of
C++11 as their C++ language standard. Luckily our compilers are good
enough for C++14 so worst case I will have to nudge a few packages next
December.
This release adds one new library for url
processing which struck us as potentially quite useful. The more
detailed NEWS log follows.
The RcppSimdJson
package was just updated to release 0.1.9.
RcppSimdJson
wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via
very clever algorithmic engineering to obtain largely branch-free code,
coupled with modern C++ and newer compiler instructions, it results in
parsing gigabytes of JSON parsed per second which is quite
mindboggling. The best-case performance is ‘faster than CPU speed’ as
use of parallel SIMD instructions and careful branch avoidance can lead
to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire
at QCon.
This release updates the underlying simdjson library to
version 3.0.1, settles on C++17 as the language standard, exports a
worker function for direct C(++) access, and polishes a few small things
around the package and tests.
The NEWS entry for this release follows.
Changes in version 0.1.9
(2023-01-21)
The internal function deseralize_json is now exported at the C++
level as well as in R (Dirk in #81
closing #80).
simdjson was upgraded to version 3.0.1
(Dirk in #83).
The package now defaults to C++17 compilation;
configure has been retired (Dirk closing #82).
The three main R access functions now use a more compact argument
check via stopifnot (Dirk).
A new release of RcppFastFloat
arrived on CRAN yesterday. The
package wraps fast_float, another
nice library by Daniel Lemire. For
details, see the arXiv
paper showing that one can convert character representations of
‘numbers’ into floating point at rates at or exceeding one gigabyte per
second.
This release updates the underlying fast_float library
version. Special thanks to Daniel
Lemire for quickly accomodating a parsing use case we had encode as
a test, namely with various whitespace codes. The default in
fast_float, as in C++17, is to be more narrow but we enable
the wider use case via two #define statements.
Changes in version 0.0.4
(2023-01-20)
Update to fast_float 3.9.0
Set two #define re-establish prior behaviour with
respect to whitespace removal prior to parsing for
as.double2()
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language–and is
widely used by (currently) 1034 packages other packages on CRAN, downloaded 27.6 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 509 times according
to Google Scholar.
This release brings another upstream bugfix interation 11.4.3,
released in accordance with the aimed-for monthly release cadence. We
had hoped to move away from suppressing deprecation warnings in this
release, and had prepared over two dozen patch sets all well as pull
requests as documented in issue
#391. However, it turns out that we both missed with one or two
needed set of changes as well as two other sets of changes triggering
deprecation warnings. So we expanded issue
#391, and added issue
#402 – and prepared another eleven pull requests and patches today.
With that we can hopefully remove the suppression of these warnings by
an expected late of late April.
The full set of changes (since the last CRAN release 0.11.4.2.1)
follows.
Changes
in RcppArmadillo version 0.11.4.3.1 (2023-01-14)
The #define ARMA_IGNORE_DEPRECATED_MARKER remains
active to suppress the (upstream) deprecation warnings, see #391 and
#402
for details.
Changes
in RcppArmadillo version 0.11.4.3.0 (2022-12-28) (GitHub Only)
Upgraded to Armadillo release 11.4.3 (Ship of Theseus)
fix corner case in pinv() when processing symmetric
matrices
Protect the undefine of NDEBUG behind additional
opt-in define
RApiDatetime
provides a number of entry points for C-level functions of the R API for
Date and Datetime calculations. The functions
asPOSIXlt and asPOSIXct convert between long
and compact datetime representation, formatPOSIXlt and
Rstrptime convert to and from character strings, and
POSIXlt2D and D2POSIXlt convert between
Date and POSIXlt datetime. Lastly,
asDatePOSIXct converts to a date type. All these functions
are rather useful, but were not previously exported by R for C-level use
by other packages. Which this package aims to change.
This release accomodates a CRAN request (as one does) to change (one
single) instance of sprintf() to snprintf().
No more, no less.
Changes in
RApiDatetime version 0.0.8 (2023-01-14)
A new release 0.3.13 of RcppGSL is
now on CRAN. The RcppGSL
package provides an interface from R to the GNU GSL by relying on the
Rcpp
package.
This release contains one change (made at the request of a CRAN email
in light of possible future changes for C standard C17 and then C23) and
removes a compiler-check from configure.ac. It is both a
fair point as our src/Makevars does not actually set a
compiler yet also a little … marginal?
The NEWS entry follows:
Changes in version 0.3.13
(2023-01-12)
Remove 'AC_PROG_CC' from 'configure.ac' per CRAN wish
An new version 0.2.5 of the random-number generator tester RDieHarder
(based on the DieHarder
suite developed / maintained by Robert Brown with contributions by David
Bauer and myself along with other contributors) is now on CRAN.
This release contains one change (made at the request of a CRAN email
in light of possible future changes for C standard C17 and then C23) and
removes a compiler-check from configure.ac. It is both a
fair point as our src/Makevars does not actually set a
compiler yet also a little … marginal?
Thanks to CRANberries, you
can also look at the most recent diff.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
A new release of our linl package for
writing LaTeX letters with (R)markdown is now on CRAN. linl makes it easy to
write letters in markdown, with some extra bells and whistles thanks to
some cleverness chiefly by Aaron.
This version add extended header and footer placement support thanks
to an included copy of wallpaper.sty as added in a nice PR
by Iñaki. As the previous
release was well over three years ago, we also enhanced continuous
integration in the process. The repository README.md
shows some screenshots of input and output files.
The NEWS entry follows:
Changes in linl
version 0.0.5 (2023-01-11)
Several updates to continuous integration and testing
Enhanced placment functionality for images in header and footer
via wallpaper.sty and new x and y offset variable (Iñaki
Ucar in #30)
The fourth release of the still new-ish qlcal package
arrivied at CRAN just now.
qlcal
is based on the calendaring subset of QuantLib. It is provided (for the R
package) as a set of included files, so the package is self-contained
and does not depend on an external QuantLib library (which can be
demanding to build). qlcal covers
over sixty country / market calendars and can compute holiday lists, its
complement (i.e. business day lists) and much more.
This release generalizes the advanceDate() function
(similar to what advanceUnits() already had), and updates
several calendars along with the upcoming QuantLib 1.29 release. This
includes updates for the UK and Australia related to changes in the
monarchy, an update for South Africa and the additional of 2023 holidays
for China.
Changes in version 0.0.4
(2023-01-11)
The advanceDate{} function can now selects a
business day convention, a time unit and an end-of-month
convention
Calendars routines for Australia, China, South Africa, UK, US
have been updated to current versions from QuantLib 1.29.
Courtesy of my CRANberries, there
is a diffstat report for this
release. See the project page
and package documentation for more details, and more examples.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
A few years since the last
release in late 2020, the RcppTOML
package is now back with a new and shiny CRAN release 0.2.0. It is now
based on the wonderful toml++ C++17 library
by Mark Gillard and gets us (at
long last!) full TOML v1.0.0
compliance for use with R.
TOML is a file format that is most
suitable for configurations, as it is meant to be edited by
humans but read by computers. It emphasizes strong readability
for humans while at the same time supporting strong typing
as well as immediate and clear error reports. On small typos
you get parse errors, rather than silently corrupted garbage. Much
preferable to any and all of XML, JSON or YAML – though sadly these may
be too ubiquitous now. TOML is
frequently being used with the projects such as the Hugo static blog compiler, or the Cargo system of Crates (aka “packages”)
for the Rust
language.
This package is a rewrite of the internals interfacing the library,
and updates the package to using toml++ and C++17. The
R interface is unchanged, and a full run of reverse dependencies passed.
This involved finding one sole test failure which turned to have been
driven by a non-conforming TOML input file which Jianfeng Li kindly fixed
at the source making his (extensive) set of tests in package configr pass too. The
actual rewrite was mostly done in a one-off repo
RcppTomlPlusPlus which can now be considered frozen.
The short summary of changes follows.
Changes in version 0.2.0
(2023-01-10)
Rewritten in C++17 using toml++ for TOML
v1.0.0 compliance
Unchanged interface from R, unchanged (and expanded
tests)
Several small continuous integration upgrades since last
release
Another quick update to the still new-ish package spdl is now om CRAN, and
in Debian. The key focus of spdl is a offering the
same interface from both R and C++ for logging by relying on spdlog via my RcppSpdlog
package.
This release add support for the stopwatch() facility.
One can now instantiate such an object, and referencing it in a log
message shows the elapsed time. No more, no less, and it works the same
way in R and C++.
A new maintenance release, now at version 0.0.18, of the RVowpalWabbit
package arrived on CRAN. It improves several sprintf()
calls by changing them to snprintf() (though there is a
remaining one creeping in from a linked-to library).
As noted before, there is a newer package rvw based on the excellent
GSoC 2018 and beyond work by Ivan Pavlov (mentored by James
and myself) so if you are into VowpalWabbit from R go check it
out.
Version 0.0.12 of RcppSpdlog is now
on CRAN and in Debian. RcppSpdlog
bundles spdlog, a
wonderful header-only C++ logging library with all the bells and
whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich.
This release adds support for the stopwatch object, a
simple container around a std::chrono object. It makes
(simple) time measurements of routines and code segments trivially easy.
Instantiate a stopwatch object, and ‘formatting’ it in a
logging string displays elapsed time. And given that the whole mojo of
RcppSpdlog (and
its sibbling package spdl) is to make use
easy in both R and C++ we can do this nicely and consistently
in both languages. The vignette has an added section with a concrete
example.
The NEWS entry for this release follows.
Changes in
RcppSpdlog version 0.0.12 (2023-01-07)
Addeed support for 'stopwatch' object allowing for simple timing
(from both C++ and R) via the logging framework.
The ‘spdlog’ logging pattern is documented via a
reference.
The first fresh release of our RcppDE package in over four years (!!) is now on CRAN.
RcppDE is a “port” of DEoptim, a popular package for derivative-free optimisation using differential evolution optimization, from plain C to C++. By using RcppArmadillo the code becomes a lot shorter and more legible. Our other main contribution is to leverage some of the excellence we get for free from using Rcpp, in particular the ability to optimise user-supplied compiled objective functions which can make things a lot faster than repeatedly evaluating interpreted objective functions as DEoptim does (and which, in fairness, most other optimisers do too). The gains can be quite substantial.
This release brings two helpful patches from Max Coulter who spotted two distinct areas for improvement, based on how DEoptim how changed in recent years. I updated a number of aspects of continuous integration since the last release, and also streamlined and simplified the C++ interface (and in doing so also squashed a bug or two).
A second update to the still-new package spdl is now om CRAN, and in Debian. The key focus of spdl is a offering the same interface from both R and C++ for logging by relying on spdlog via my RcppSpdlog package.
This release add support for a simple filesetup() initialiser to direct logging output to a file. For now the console logger and the file logger are exclusive, if there is interest we could borrow a page from upstream and combine them.
Version 0.0.11 of RcppSpdlog is now on CRAN and in Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich.
This release adds support for a basic file logger as a alternative to the console logger. This can be helpful with code which suppresses or hides console output – as for example unit test code does. We also expose the formatting helper function for direct use at the C level from other packages, and mention the handy wrapper spdl in the README.
Release 0.6.31 of the digest package arrived at CRAN this weekend, and is being uploaded to Debian as well.
digest creates hash digests of arbitrary R objects (using the md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, spookyhash, and blake3 algorithms) permitting easy comparison of R language objects. It is a mature and widely-used as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation to quickly identify the various objects.
This release contains the tiny change (in maybe a dozen places) triggered recently by macOS and now checked for by r-devel which consists of replacing (v)sprintf calls with (v)snprintf. No more, no less.
An new minor revision of the AsioHeaders package arrived at CRAN earlier today. Asio provides a cross-platform C++ library for network and low-level I/O programming. It is also included in Boost – but requires linking when used as part of Boost. This standalone version of Asio is a header-only C++ library which can be used without linking (just like our BH package with parts of Boost).
This minor update avoid use of (v)sprintf which CRAN now flags in r-devel (for all R builds), following the decision by Apple to deprecated it for macOS. Winston had notified me about email he had gotten for for his websocket package – also highlighting the issue for both iptools and ipaddress. As the issue ticket dialog shows I was initially a little hamfisted about replicating, falsely thinking I would need an updated compiler. But this really is ‘just’ a change in r-devel once again scanning shared libraries for symbols now warned about. Upstream has newer minor releases but they did not yet cover this; however I found a commit mentioning Xcode and snprint from three days ago which I essentially ported. We needed one more change, and that addressed the issue in websocket. But as it is good to increase the number of random acts of kindness, I also looked into iptools and ipaddress as CRAN has its eyes on them too for this. Turned out they needed simple and limited changes from sprint to snprintf so made those and sent them PRs: iptools PR #42 and ipaddress PR #79.
The short NEWS entry for AsioHeaders follows.
Changes in version 1.22.1-2 (2022-12-07)
Switch a handful of upstream (v)sprint uses to (v)snprintf.
A first update to the recently-released package spdl is now om CRAN. The key focus of spdl is a offering the same interface from both R and C++ for logging by relying on spdlog via my RcppSpdlog package.
This release exposes simple helpers fmt() (to format text according to the included fmt library) and cat() which formats and prints.
The very short NEWS entry for this release follows.
A new package made it to CRAN today: spdl. It provides a very simple interface to spdlog with the key focus being that provides the same interface from both R and C++. I had brought spdlog to R a little while ago via RcppSpdlog, but its use was generally limited to C++ code where we would write something like (taken from one of the examples included in the package)
spdlog::info("Welcome to spdlog!");
I then provided C-level exports from the package accessible in other package but with that the signature only became longer as it also included the package name, here RcppSpdlog. So I experimented a little with that and added another ‘more compactly named’ namespace spdl around it. So then it becomes
spdl::info("Info message with values {} and {}",42,1.23);// C++ code
which now also shows the power of the included fmt library. And I got quite used to that … and now wanted to same from R! But to create a new namespace, we need a new package. So … we made one. Now from R too:
spdl::info("Info message with values {} and {}", 42L, 1.23) # R code
We layered a very simple wrapper for fmt over this. All R argument are passed to format() and we simply send a vector of strings over the C interface to the RcppSpdlog package where the templated formatter of fmt is invoked – but for character values. You can equally well format the string locally first. Everything works: from paste() to sprintf() to any of the existing string interpolators all of which are nice. But none works just like fmt and I wanted to have the same formatter in both languages, and like how fmt works.
By tradition, the NEWS entry for this release follows.
Changes in spld version 0.0.1 (2022-11-21)
Initial release of R and C++ loggers using spdl::* namespace
A maintenance release 0.9.14 of the RcppClassic package arrived earlier today on CRAN. This package provides a maintained version of the otherwise deprecated initial Rcpp API which no new projects should use as the normal Rcpp API is so much better.
The changes is. CRAN was reporting (for all four macOS builds, and only there) that an absolute path was embedded, so we updated the (old …) call to install_name_tool use on that (and only that) OS. No other changes were made.
A version 0.0.10 of RcppSpdlog is now on CRAN and in Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich.
This release continues on the path started less than two weeks ago with the RcppSpdlog 0.0.9 release. We continue to support both R and C++ access by adding a (simple) variadic template formatter exposing fmt::format() (by focusing on just string arguments). This can be accessed from R via the exact same formatting strings that fmt uses, and which we have come to like for its simplicity. Of course if one prefers a different string interpolation method, or plain sprintf(), or even paste: they all work as all that matters is that a character variable gets passed on. We also added a little bit of new documentation in the vignette.
The NEWS entry for this release follows.
Changes in RcppSpdlog version 0.0.10 (2022-11-17)
Support variadic templates with fmt::format
Add R formatting helper which converts arguments to character taking advantage of variadic template logger: fmt logging from R
Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1027 packages other packages on CRAN, downloaded 26.9 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 503 times according to Google Scholar.
This release reflect as new upstream bugfix release 11.4.2 made recently by Conrad. To accomodate CRAN and their preference for at most a release per month, we held it back since the 11.4.0 release early October. As we usually do, we generally update once upstream Armadillo releases are made. When we do not immediately release to CRAN (in order to lower the release cadence), we make those “interim” releases available via GitHub source and the Rcpp drat repo.
This release also brings a rearranged, and as we think, simplified layout of the header files. All existing locations are still supported but we will be starting a (very patient and slow) transition at some point.
The full set of changes (since the last CRAN release 0.11.4.0.1) follows.
Changes in RcppArmadillo version 0.11.4.2.1 (2022-11-08)
Upgraded to Armadillo release 11.4.2 (Ship of Theseus)
more robust handling of corner cases in multi-threaded contexts
Internal header organisation with new sub-directories while providing full compatibility via existing paths (#395#396)
Changes in RcppArmadillo version 0.11.4.1.0 (2022-10-10) (GitHub Only)
Upgraded to Armadillo release 11.4.1 (Ship of Theseus)
fix data race in Cube::slice()
workarounds for false warnings emitted by GCC 12 when compiling with FORTIFY_SOURCE enabled (already in RcppArmadillo 0.11.4.0.1 too)
RcppCCTZ uses Rcpp to bring CCTZ to R. CCTZ is a C++ library for translating between absolute and civil times using the rules of a time zone. In fact, it is two libraries. One for dealing with civil time: human-readable dates and times, and one for converting between between absolute and civil times via time zones. And while CCTZ is made by Google(rs), it is not an official Google product. The RcppCCTZ page has a few usage examples and details. This package was the first CRAN package to use CCTZ; by now several others packages (four the last time we counted) include its sources too. Not ideal, but beyond our control.
This version adds support for NA values when parsing, and updates GitHub Action.
Changes in version 0.2.12 (2022-11-06)
Support NA values in numerical or character input
GitHub Actions were updated to checkout version 3.
A new release 0.3.3.9.3 of RcppEigen arrived on CRAN moments ago (and just went to Debian). Eigen is a C++ template library for linear algebra: matrices, vectors, numerical solvers, and related algorithms.
This update is again mostly maintenance. To accomodate one small aspect of the Fortran interface, we now require R 3.6.0 or later. Jonah Gabry spotted a really old typo and fixed it. The fastLm support code now uses the unabbreviated df.residual. We accomodated clang-15 in one signature as is common with many recent uploads, and also updated one aspect of GitHub Actions.
And once again as we said for the last four releases:
One additional and recent change was the accomodation of a recent CRAN Policy change to not allow gcc or clang to mess with diagnostic messages. A word of caution: this may make your compilation of packages using RcppEigen very noisy so consider adding -Wno-ignored-attributes to the compiler flags added in your ~/.R/Makevars.
We still find this requirement rather annoying. Eigen is only usable if you set, say,
A brand-new version 0.0.9 of RcppSpdlog got onto CRAN overnight. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich.
This release contains two changes. First, we extend usability by offering both a set of simple R functions for logging from R, and a matching set of functions at the C++ level that are directly callable (and exported) from this package (so that client packages do not need to compile). Both these changes are described (as sections seven and eight) in the vignette. Second, while we were working on this Gabi released version 1.11.0 upstream so we included this as well.
A new release 0.4.20 of RProtoBuf arrived on CRAN earlier today. RProtoBuf provides R with bindings for the Google Protocol Buffers (“ProtoBuf”) data encoding and serialization library used and released by Google, and deployed very widely in numerous projects as a language and operating-system agnostic protocol.
This release is somewhat mechanical and in the spirit of many other recent releases. clang-15 is, as more recent compilers do, more stringent on definitions and wants to see some void in argument-less signatures. Happy to oblige. At the same time, GitHub Actions started to nag us about minimum versions of node code so an upgrade to a newer action is warranted, again as with many other affected packages. We also found another http:// URL hiding somewhere so that was cleaned. Lastly, it appears Protocol Buffers themselves moved on and now need / prefer C++17 so were happy to oblige.
The following section from the NEWS.Rd file has full details.
Changes in RProtoBuf version 0.4.20 (2022-11-02)
Two function prototype were updated for clang-15.
GitHub Actions were updated to checkout version 3.
One more http:// URL was updated to https://
The package compilation is now donw with C++17 as the Protocol Buffer headers require it (and clang-15 nags otherwise).
A new version 0.1.4 of the tint package arrived at CRAN today. tint provides a style ‘not unlike Tufte’ for use in html and pdf documents created from markdown. The github repo shows several examples in its README, more as usual in the package documentation.
This is the first release in over two years and it brings a few incremental changes which are described in detail below. The trigger was an email from CRAN desiring compacted pdf files inside the package sources. Which, coincidentally, was made a default about a year ago in the build.r script from littler I use to make packages. But as we had not updated tint this has not reached CRAN. So there.
The set of changes follows, which includes a helpful contributed PR for which we are always thankful. I also improved table rendering, most other changes are packaging mechanics.
Changes in tint version 0.1.4 (2022-11-01)
Added continuous integration at GitHub using run.sh
Non-margin reference in html mode now have an improved display (David Selby and Dirk in #47)
The LaTeX package array is now installed for improved table support (Dirk addressing #48)
Minor updates made the package directory and README.md
GitHub Actions were updated to checkout version 3.
A new maintenance release 0.0.6 of RcppXts is now on CRAN. The RcppXts package demonstrates how to access the export C API of xts which we contributed a looong time ago.
This release, like so many these days, was triggered by clang-15 wanting to see a void in an otherwise argument-less signature. We also updated a GitHub Action to avoid another nag from there.
The NEWS entries follow.
Changes in version 0.0.6 (2022-08-05)
One function prototype was updated for clang-15.
GitHub Actions were updated to checkout version 3.
A new minor release 0.2.2 of our RcppRedis package arrived on CRAN this evening. RcppRedis is one of several packages connecting R to the fabulous Redis in-memory datastructure store (and much more). RcppRedis does not pretend to be feature complete, but it may do some things faster than the other interfaces, and also offers an optional coupling with MessagePack binary (de)serialization via RcppMsgPack. The package has carried production loads for several years now.
This packages now brings a neat enhancement to the real-time data plotter code (and example) I have been using with for a while now. Paul Murrell kindly suggested dev.hold() and dev.flush() when I inquired how to minimize ‘flicker’ from frequent updated. And this is perfect. I can now keep several data displays ‘on’ during market hours without being distracted by ‘flicker’. It just updates, smooth as silk. Also included in the release are the usual two updates so en vogue these days: a (sole) sprinkling of void to appease clang-15, and an update the GitHub Action for checkout. Both silence some nags we would rather not see.
The detailed changes list follows.
Changes in version 0.2.2 (2022-10-31)
Thanks to a suggestion by Paul Murrell, the real-time chart demo now uses dev.hold() and.flush() for flicker-free updates.
One function prototype was updated for clang-15.
GitHub Actions were updated to checkout version 3.
A new release 0.3.12 of RcppGSL is now on CRAN. The RcppGSL package provides an interface from R to the GNU GSL by relying on the Rcpp package.
This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at it, an updatet to GitHub Actions was made as well.
The NEWS entry follows:
Changes in version 0.3.12 (2022-10-30)
Two function prototypes were updated for clang-15.
GitHub Actions were updated to checkout version 3.
A minor maintenance release for the RcppBDT package is now on CRAN.
The RcppBDT package is an early adopter of Rcpp and was one of the first packages utilizing Boost and its Date_Time library. The now more widely-used package anytime is a direct descentant of RcppBDT.
This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at it, an updatet to GitHub Actions was made as well.
The NEWS entry follows:
Changes in version 0.2.6 (2022-10-30)
A function prototype was updated for clang-15.
GitHub Actions were updated to checkout version 3.
RApiDatetime provides a number of entry points for C-level functions of the R API for Date and Datetime calculations. The functions asPOSIXlt and asPOSIXct convert between long and compact datetime representation, formatPOSIXlt and Rstrptime convert to and from character strings, and POSIXlt2D and D2POSIXlt convert between Date and POSIXlt datetime. Lastly, asDatePOSIXct converts to a date type. All these functions are rather useful, but were not previously exported by R for C-level use by other packages. Which this package aims to change.
This release accomodates, just like so many other releases this week, the more stringent views of clang-15 about what a correct function prototype is. While we were at, updates to GitHub Actions and https URL were made as well.
Changes in RApiDatetime version 0.0.7 (2022-10-30)
A function prototype was updated for clang-15.
GitHub Actions were updated to checkout version 3.
Several remaining http:// URLs were converted to https://.
The eighteenth release of littler as a CRAN package just landed, following in the now sixteen year history (!!) as a package started by Jeff in 2006, and joined by me a few weeks later.
littler is the first command-line interface for R as it predates Rscript. It allows for piping as well for shebang scripting via #!, uses command-line arguments more consistently and still starts faster. It also always loaded the methods package which Rscript only started to do in recent years.
littler lives on Linux and Unix, has its difficulties on macOS due to yet-another-braindeadedness there (who ever thought case-insensitive filesystems as a default were a good idea?) and simply does not exist on Windows (yet – the build system could be extended – see RInside for an existence proof, and volunteers are welcome!). See the FAQ vignette on how to add it to your PATH. A few examples are highlighted at the Github repo, as well as in the examples vignette.
This release, coming just a few weeks since the last release in August, heeds to clang-15 a updates one signature to a proper interface. It also contains one kindly contributed patch updating install2.r (and installBioc.r) to cope with a change in R-devel.
The full change description follows.
Changes in littler version 0.3.17 (2022-10-29)
Changes in package
An internal function prototype was updated for clang-15.
Changes in examples
The install2.r and installBioc. were updated for an update in R-devel (Tatsuya Shima and Dirk in #104).
A minor routine update 0.0.5 of gettz arrived on CRAN overnight.
gettz provides a possible fallback in situations where Sys.timezone() fails to determine the system timezone. That happened when e.g. the file /etc/localtime somehow is not a link into the corresponding file with zoneinfo data in, say, /usr/share/zoneinfo. Since the package was written (in the fall of 2016), R added a similar extended heuristic approach itself.
This release updates a function signature to satisfy the more stringent tests by clang-15, updates the GitHub Action checkout code to suppress a nag, and changes a few remaining http documentation links to https. As with the previous releses: No functional changes, no new code, or new features.
Another minor maintenance release, now at version 0.0.20, of RcppAnnoy has arrived on CRAN. RcppAnnoy is the Rcpp-based R integration of the nifty Annoy library by Erik Bernhardsson. Annoy is a small and lightweight C++ template header library for very fast approximate nearest neighbours—originally developed to drive the Spotify music discovery algorithm.
This release only contains internal changes to please, respectively clang-15 and (macOS) Xcode 14 (one of which PRed upstream too). No changes in package functionality. Detailed changes follow.
A new release 0.4.17 of RQuantLib arrived at CRAN earlier today, and has been uploaded to Debian as well.
QuantLib is a very comprehensice free/open-source library for quantitative finance; RQuantLib connects it to the R environment and language.
The release of RQuantLib comes five months after the previous maintenance, and brings a somewhat humurous upgrade from a default C++ standard of C++11 to C++14. We waited so long for C++11 to become available for R (which happened “eventually” when g++ 4.9 was no longer the default on Windows) and now it has become a constraint!! QuantLib 1.28, released today actually switched to C++14 as a minimum required. R also supports this as the default, but we still had C++11 hardwired so this quick maintenance release does away with that.
Changes in RQuantLib version 0.4.17 (2022-10-25)
Switch compilation to C++14 which is required by QuantLib 1.28 and, while standard with R 4.2.*, may be needed for R 4.1.*
A new version of our nanotime package arrived at CRAN today as version 0.3.7. nanotime relies on the RcppCCTZ package (as well as the RcppDate package for additional C++ operations) and offers efficient high(er) resolution time parsing and formatting up to nanosecond resolution, and the bit64 package for the actual integer64 arithmetic. Initially implemented using the S3 system, it has benefitted greatly from a rigorous refactoring by Leonardo who not only rejigged nanotime internals in S4 but also added new S4 types for periods, intervals and durations.
This release adds a few more operators, plus some other fixes, that were contributed in several PRs by Trevor Davis. The NEWS snippet has the full details.
Changes in version 0.3.7 (2022-10-23)
Update mkdocs for material docs generator (Dirk in #102)
Use inherits() instead comparing to class() (Trevor Davis in #104)
Set default arguments in nanoduration() (Trevor Davis in #105)
Add as.nanoduration.difftime() support (Trevor Davis in #106)
Add +/- methods for nanotime and difftime objects (Trevor Davis in #110 closing #108, #107)
An new version 0.2.4 of the random-number generator tester RDieHarder (based on the DieHarder suite developed / maintained by Robert Brown with contributions by David Bauer and myself along with other contributors) is now on CRAN.
This release comes ten months after the previous release 0.2.3. It is once more related to R and requested CRAN changes as clang-15 brings additional warnings concerning -Wstrict-prototyping. This make use of C more solid, but it was a metric ton of work (see pull request #8).
Thanks to CRANberries, you can also look at the most recent diff.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
The third release of the still pretty new qlcal package arrivied at CRAN today.
qlcal is based on the calendaring subset of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over sixty country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more.
This release fixes a small bug affecting one function, brings calendar updates from QuantLib 1.27 and 1.28, and applies a little bit of polish to appease clang++-15.
Changes in version 0.0.3 (2022-10-19)
Correct the isBusinessDay() functionality (Fixes #2)
Update Australia and Saudi Arabia calendars from QuantLib 1.27
Update United Kingdom calendar from QuantLib 1.28
Convert one source file to utf-8 to appease clang-15
See the project page and package documentation for more details, and more examples.
If you like this or other open-source work I do, you can now sponsor me at GitHub.
