Hi, I wanted to ask if people have good advice on how to debug M1Mac package check errors when you don?t have a Mac? Is a cloud machine the best option or is there something else? Thanks Holger [[alternative HTML version deleted]]
On 4 February 2024 at 20:41, Holger Hoefling wrote: | I wanted to ask if people have good advice on how to debug M1Mac package | check errors when you don?t have a Mac? Is a cloud machine the best option | or is there something else? a) Use the 'mac builder' CRAN offers: https://mac.r-project.org/macbuilder/submit.html b) Use the newly added M1 runners at GitHub Actions, https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/ Option a) is pretty good as the machine is set up for CRAN and builds fast. Option b) gives you more control should you need it. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On Sun, 4 Feb 2024 20:41:51 +0100 Holger Hoefling <hhoeflin at gmail.com> wrote:> I wanted to ask if people have good advice on how to debug M1Mac > package check errors when you don?t have a Mac?Apologies for not answering the question you asked, but is this about hdf5r and problems printing R_xlen_t [*] that appeared in 1.3.8 and you tried to solve in 1.3.9? We had a thread about this last November: https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010123.html To summarise, there is no single standard C format specifier that can be used to print R_xlen_t. As an implementation detail, it can be defined as int or ptrdiff_t (or something completely different in the future), and ptrdiff_t itself is usually defined as long or long long (or, also, something completely different on a weirder platform). All three basic types can have different widths and cause painful stack-related problems when a mismatch happens. In R-4.4, there will be a macro R_PRIdXLEN_T defining a compatible printf specifier. Until then (and for compatibility with R-4.3 and lower), it's relatively safe to cast to (long long) or (ptrdiff_t) and then use the corresponding specifier, but that's not 100% future-proof. Also, mind the warnings that mingw compilers sometimes emit for "new" printf specifiers despite UCRT is documented to support them. -- Best regards, Ivan [*] https://www.stats.ox.ac.uk/pub/bdr/M1mac/hdf5r.out
On 04/02/2024 19:41, Holger Hoefling wrote:> Hi, > > I wanted to ask if people have good advice on how to debug M1Mac package > check errors when you don?t have a Mac? Is a cloud machine the best option > or is there something else?I presumed this was about a CRAN package, possibly hdf5r which has a R-devel-only warning from the Apple clang compiler. And that is not a 'check error' and not something to 'debug'. The original poster had errors for his package flsa until yesterday on fedora-clang and M1mac, which were compilation errors with recent LLVM and Apple compilers. Again, not really something to 'debug' -- the compiler messages were clear and the CRAN notification contained advice on where in our manual to look this up. The mac-builder service offers checks for R 4.3.0, the 'development' option being (last time I tried) the same as the 'release' option. (When I asked, Simon said that 'development' checks were only available in the run up to a x.y.0 when he starts package building and checks for R-devel.) We were left to guess, but I doubt this has to do with the lack of 'extended precision' nor long doubles longer than doubles on arm64 macOS. And issues with that are rather rare (much rarer than numerical issues for non-reference x86_64 BLAS/LAPACKs). Of the 20,300 CRAN packages just 18 have M1mac-specific errors, none obviously from numerical inaccuracy. A quick look back suggests we get about 20 a year with M1mac numerical issues, about half of which were mirrored on the x86_64 'noLD' checks. -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford