digitalcourage.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Diese Instanz wird betrieben von Digitalcourage e.V. für die Allgemeinheit. Damit wir das nachhaltig tun können, erheben wir einen jährlichen Vorausbeitrag von 1€/Monat per SEPA-Lastschrifteinzug.

Server stats:

817
active users

#cran

2 posts2 participants0 posts today
Continued thread

I also took the opportunity to port the apt-sources to the new config file format. which worked ok. But I haven't yet managed to get the #cran Debian mirror for #rstats to work. They use non-standard syntax in the old suggested config I don't really know how to translate to the new format.

2/2

Following #rstats packages were maintained and are back on #CRAN now thanks to Andrej Spiess

- #dpcR, 2025-06-18, Digital PCR Analysis <10.32614/CRAN.package.dpcR>
- #MBmca, 2025-06-11, Nucleic Acid Melting Curve Analysis (journal.r-project.org/articles)
- #qpcR, 2025-06-10, Modelling and Analysis of Real-Time PCR Data <doi10.1093/bioinformatics/btn227>
- #PCRedux, 2025-06-13, Quantitative #PCR (#qPCR) Data Mining and Machine Learning Toolkit as Described in <doi:10.21105/Joss.04407>

#RStats {yyjsonr} update!

'yyjsonr' is a super fast JSON reader/writer supporting JSON, NDJSON and GeoJSON

v0.1.21 is released and now on #CRAN!

* Bug fixes
* More config options
* Removed non-API calls
* Using latest yyjson C lib

github.com/coolbutuseless/yyjs
cran.r-project.org/package=yyj

GitHubGitHub - coolbutuseless/yyjsonr: Fast JSON package for RFast JSON package for R. Contribute to coolbutuseless/yyjsonr development by creating an account on GitHub.

Some #R #rstats about the packages on the repositories: #CRAN has 722 packages that use Bioconductor (3%), #Bioconductor has 2802 packages that use CRAN's packages (77%).

1.3% CRAN and 0.6% Bioconductor respectively use package outside these two repositories. But 91% and 93% use packages on their respective repos. 8% and 3% do not have any dependency on external packages (but could depend on system dependencies).

Today version 0.3.2 of the swephR package for R made it unto CRAN. Main reason for the upgrade was that CRAN had found a new WARNING by also inspecting the intermediate static library file. Instead of patching the upstream sources, I opted for deleting the library after building the the symbolic library for the package. It does not help anybody when code is inspected that is not actually used.

Two things were really nice:
* The warning message displayed at cran.r-project.org/package=swe disappeared even before all test machines had build the new version. Probably once the first tests of previously failing tests came in.
* This package suggests a larger data package, that is only available on r-universe. Therefore, there had always been one NOTE, which meant manual inspection when submitting. Now this NOTE has been demoted to INFO, which goes through automatically, speeding up the process and leaving less work for the CRAN maintainers.

cran.r-project.orgswephR: High Precision Swiss EphemerisThe Swiss Ephemeris (version 2.10.03) is a high precision ephemeris based upon the DE431 ephemerides from NASA's JPL. It covers the time range 13201 BCE to 17191 CE. This package uses the semi-analytic theory by Steve Moshier. For faster and more accurate calculations, the compressed Swiss Ephemeris data is available in the 'swephRdata' package. To access this data package, run 'install.packages("swephRdata", repos = "https://rstub.r-universe.dev", type = "source")'. The size of the 'swephRdata' package is approximately 115 MB. The user can also use the original JPL DE431 data.

FYI: 14% of #CRAN links require knowing alias present on the libraries to resolve them. 80% of links to duplicated targets are present on the package. Which results on just 3% of links in packages being ambiguos (I expected more).

In related news, just 5 packages have different documentation for unix and windows! One of them breaks my #rstats link resolver...

#CRAN could halve their work on the "incoming" queue by doing the following:

"R CMD CHECK --as-cran" should fail for exported functions witthout examples - authors prompted to fix b4 submission

There. I've done it.

I've just saved CRAN XX hours a week of emailing people to "please add examples".

If someone has any inside clout with CRAN/R core please make this suggestion.

As they say "volunteer time is precious", and this trivial fix could save so much!

Idea: Can we as package developers (as a group) decide on a standard file in which to store all historical communication with CRAN?

CRAN-correspondence.txt ?

I don't mean any sanitized high-level summary, I mean a record of every CRAN interaction about your package submission. Emails could be redacted to "[CRAN member]" to avoid any privacy concerns.

I'm sick of feeling like I'm navigating CRAN blind. The lack of open discussion makes it really difficult.