Also test on Linux ARM in R-CMD-check

[jeroen]

Your package has some errors on Linux Arm that affects packages that depend on RcppAlgos. With this PR you should be able to reproduce the error on CI.

[jwood000]

Reviewed my follow-up commit. The change is intentionally limited to removing the cross-OS shell fallback in startup-time core detection, which should address the linux-arm64 /bin/kstat warning while preserving the existing cache/thread heuristics. Pending CI.

[jwood000]

@jeroen

Thanks for adding the linux-arm64 check. This immediately exposed a real package startup issue in .onLoad().

I traced the warning to physicalCoreCount() in R/zzz.R. The old fallback logic tried OS-specific shell commands for other platforms after the Linux-specific checks failed, which meant the Solaris /bin/kstat command could be attempted on linux-arm64. That explains the sh: 1: /bin/kstat: not found warning appearing during unrelated check stages.

I pushed a small follow-up commit to this PR branch so the new linux-arm64 check and the package-side fix can land together. Thanks again, this was a very helpful check to add.

[eddelbuettel]

@jwood000 Just FYI base R has this covered including on OSs where it is harder for us to get access:

> parallel::detectCores()
[1] 32
> 

[jwood000]

@eddelbuettel

Thanks for the note. You’re absolutely right.

When I originally wrote this years ago, I was trying to be clever about estimating physical cores for an internal cache-size heuristic, but the result was more fragile than it needed to be. The linux-arm64 check exposed that pretty clearly.

The fix now removes the platform-specific shell-command fallback entirely and uses parallel::detectCores() with a simple fallback to 1L when needed. Much better aligned with the “don’t do harm” principle, which I picked up from your writings.

As always, I appreciate the feedback.

[eddelbuettel]

@jwood000 I am glad you are not taking it the wrong way but ... absolutely: been there, done that, and anything involving things "close to hardware" can be become a pain to maintainer especially under changing hardware environment (where we now have "three linux flavors": the eternal standard, but now arm64 and also musl/alpine with an inferior libc). Gets old quickly, and I have learned to appreciate the abstractions R gives me.