Re: [Rd] Advice debugging M1Mac check errors
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, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paths capability FALSE on devel?
On 27/03/2024 10:28, Alexandre Courtiol wrote: Hi all, I don't know if it is a local issue on my hands or not, but after installing R-devel the output of grDevices::dev.capabilities()$paths is FALSE, while it is TRUE for R 4.3.3. Relatedly, I have issues with plotting paths on devel. At this stage, I simply would like to know if others running R devel and R 4.3.3 can replicate this behaviour and if there are obvious reasons why the observed change would be expected. The help says Query the capabilities of the current graphics device. You haven't told us what that was. See the posting guide for the "at a minimum" information you also did not provide -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] config.site settings for M3 Mac typo in manual?
On 20/05/2024 09:06, Duncan Murdoch wrote: I've just upgraded to an M3 Mac laptop, and I'm working through getting the right configure settings to build R. The Installation and Administration manual says to have this in config.site: FFLAGS="-g -O2 -mmacos-version-min=11.0" FCFLAGS="-g -O2 -mmacos-version-min=11.0" but those give an error on my system, with it suggesting the FFLAGS and FCFLAGS version option should be -mmacosx-version-min=11.0. I don't know if that's a typo or a change. -mmacos-version-min= is the current Apple option. However, the gfortran build recommended in the manual is quite old and this has apparently differed by GCC version (and is not documented in the 'man gfortran' I have). I'll change the manual to mention both forms, and that it is only sometimes needed (not on my current setup). -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error compiling 87283 on Windows 10 using Rtools4.4 6335-6327
On 31/10/2024 16:30, Avraham Adler wrote: When compiling R, the build fails after byte compiling grDevices with the following error: byte-compiling package 'grDevices' make[4]: *** [../../../share/make/lazycomp.mk:9: ../../../library/grDevices/R/grDevices.rdb] Error 139 make[3]: *** [Makefile.win:23: all] Error 2 make[2]: *** [Makefile.win:34: R] Error 1 make[1]: *** [Makefile:18: all] Error 2 make: *** [Makefile:392: distribution] Error 2 I restarted the build, as sometimes that allows it to power through, but it failed at the same point. Any thoughts or suggestions would be appreciated. This may be unrelated, but as I was monitoring the compilation, I saw an warning which I haven't seen before in the 20 or so years I've been building R on Windows: In function 'R_chk_memset', inlined from 'do_aperm' at ../main/array.c:1754:5: ../main/memory.c:3578:16: warning: 'memset' specified bound between 18446744056529682432 and 18446744073709551608 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 3578 | return n ? memset(s, c, n) : s; | No idea if it is related but I thought I should mention it. This is known for an LTO build with gcc 14.2.x -- not normally used on Windows though. It is a over-aggressive warning, one we are working on for R-devel. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Consider getNamespaceVersion() returning a numeric_version
On 17/10/2024 13:42, Tim Taylor wrote:
I mean the `numeric_version` object not a numeric (double/int).
Basically to protect me from myself I'd prefer not to have to remember
to wrap `getNamespaceVersion()` with `as.package_version()`.
I suspect a grep of CRAN may highlight others who are erroneously
comparing character objects rather than a comparison between a
`numeric_version` object and a character.
Perhaps you could do that rather than speculating? Similarly, try out
over CRAN the effect of getNamespaceVersion changing its return type.
It seems to be used in less than 40 CRAN packages, many boilerplate code
from a single author and most use the version as a printable character
string. A few are clearly wrong: E.g.
if(getNamespaceVersion("reticulate") >= "1.36.0")
will be false it that package ever reaches "1.100.0". This is what
compareVersion() is for
On 17/10/2024 13:22, Dirk Eddelbuettel wrote:
On 17 October 2024 at 12:38, Tim Taylor wrote:
| Would R-Core be receptive to having getNamespaceVersion() return a
| numeric_version object instead of a named character?
Is this good enough? What's your actual issue a 'numeric' would address?
> as.package_version(getNamespaceVersion("base")) < "4.5.0"
[1] TRUE
>
> as.package_version(getNamespaceVersion("Rcpp")) > "1.0.11"
[1] TRUE
> as.package_version(getNamespaceVersion("Rcpp")) > "1.0.14"
[1] FALSE
There are differences, e.g.
> (z <- getNamespaceVersion("MASS"))
version
"7.3-61"
> (zz <- as.package_version(z))
[1] ‘7.3.61’
> as.character(zz)
[1] "7.3.61"
and some uses need the first. That makes changing the return value too
disruptive.
If the issue is only comparison, getNamespaceVersion's return value
could be given a class and an Ops group method, but the existence of
compareVersion() makes that less compelling.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion to emphasize Rboolean is unrelated to LGLSXP in R-exts
On 02/02/2025 15:50, Ivan Krylov via R-devel wrote: The good news is that without a C23-enabled compiler, the problem will only happen to source files that #include . The bad news is that such a source file will technically disagree with the rest of R about the type of Rboolean, including the prototypes of the API functions that accept Rboolean: #include #include typedef void (*pordervector1)(int *, int, SEXP, Rboolean, Rboolean); // ... pordervector1 f = R_orderVector1; f(pindx, length(indx), arg, nalast, decreasing); foo.c:27:17: runtime error: call to function R_orderVector1 through pointer to incorrect function type 'void (*)(int *, int, struct SEXPREC *, bool, bool)' /tmp/R-devel/src/main/sort.c:1135: note: R_orderVector1 defined here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.c:27:17 With sanitizers disabled, this doesn't seem to cause any real problems thanks to the calling convention, where both 'enum's and 'bool's are passed and returned in a register. This is work in progress, and it was not intended to apply to R-devel unless configured with --with-C23 or using a compiler (such as GCC pre-15) that defaults to C23. We will back that out pending further testing. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] boolean and logical types -draft
Tomas, I am thinking of writing something for R-devel, and hope to have your input first. I get moderated on R-devel as I am now subscribed as brian.rip...@r-project.org which of course I cannot send from. So I am even more discouraged from posting there. (R-core is bad enough with Luke discouraging all innovation except by him and Simon completely misunderstanding the C23 status.) Thanks, Brian There are several of these, and few guarantees for inter-working. a) R's logical vectors, which include a value NA for its elements. b) R's Rboolean type in C/C++ c) C++'s bool type d) C23's bool type e) C99's _Bool type to which bool is aliased if is included. f) Fortran's LOGICAL type a) is currently implemented as a C int (so 32-bit) type with NA as the C value NA_LOGICAL which is the same a NA_INTEGER. b) is currently implemented as a C enum with two values. I don't know of any guarantees on how that is stored except in char or an integer type -- however it seems common practice to use a 32-bit type (int or unsigned int would not be distinguishable). (C23 §6.7.3.3) Enums can have a specified data type, but we do not. C23 states that bool has 1 value bit and some padding bits (§6.2.6.2) so it can be stored in char-sized storage (i.e. bytes) or multiples thereof. And that _Bool is a alternative name for bool. f) is complier-dependent: for interoperability with C or R, code should use c_bool from iso_c_binding (Fortran 2003). Fortran compilers store LOGICAL in compiler-dependent ways, and for a long time we got away with assuming that was equivalent to int (so LOGICAL values could be passed to and from with int* on the C/R side). But sometime around GCC 8 they changed to int_least32_t, which on common platforms is the same as int but does not need to be. It seems that in all cases coercion to an integer type coerces false values to 0 and true values to 1 (and this is guaranteed by C23 at least). And C23 guarantees that when coercing from an integer type to bool zero values are coerced to false and non-zero ones to true (bool is 'an unsigned integer type'). However, that does not seem to be true for C++ as UB sanitizers warn on coercing values other than 0/1. I believe it to be the intention that c), d) and e) have the same representation and interwork using the same compiler, but I could not find that documented and see signs that e) might differ in C17 and C23 modes. I need to look again at the C and C++ standards which with my vision I need to do in very small chunks. Oh for the vision I once had! -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boolean and logical types -draft
Sent in error (and not moderated). On 03/02/2025 17:36, Prof Brian Ripley via R-devel wrote: Tomas, I am thinking of writing something for R-devel, and hope to have your input first. I get moderated on R-devel as I am now subscribed as brian.ripley@R- project.org which of course I cannot send from. So I am even more discouraged from posting there. (R-core is bad enough with Luke discouraging all innovation except by him and Simon completely misunderstanding the C23 status.) Thanks, Brian There are several of these, and few guarantees for inter-working. a) R's logical vectors, which include a value NA for its elements. b) R's Rboolean type in C/C++ c) C++'s bool type d) C23's bool type e) C99's _Bool type to which bool is aliased if is included. f) Fortran's LOGICAL type a) is currently implemented as a C int (so 32-bit) type with NA as the C value NA_LOGICAL which is the same a NA_INTEGER. b) is currently implemented as a C enum with two values. I don't know of any guarantees on how that is stored except in char or an integer type -- however it seems common practice to use a 32-bit type (int or unsigned int would not be distinguishable). (C23 §6.7.3.3) Enums can have a specified data type, but we do not. C23 states that bool has 1 value bit and some padding bits (§6.2.6.2) so it can be stored in char-sized storage (i.e. bytes) or multiples thereof. And that _Bool is a alternative name for bool. f) is complier-dependent: for interoperability with C or R, code should use c_bool from iso_c_binding (Fortran 2003). Fortran compilers store LOGICAL in compiler-dependent ways, and for a long time we got away with assuming that was equivalent to int (so LOGICAL values could be passed to and from with int* on the C/R side). But sometime around GCC 8 they changed to int_least32_t, which on common platforms is the same as int but does not need to be. It seems that in all cases coercion to an integer type coerces false values to 0 and true values to 1 (and this is guaranteed by C23 at least). And C23 guarantees that when coercing from an integer type to bool zero values are coerced to false and non-zero ones to true (bool is 'an unsigned integer type'). However, that does not seem to be true for C++ as UB sanitizers warn on coercing values other than 0/1. I believe it to be the intention that c), d) and e) have the same representation and interwork using the same compiler, but I could not find that documented and see signs that e) might differ in C17 and C23 modes. I need to look again at the C and C++ standards which with my vision I need to do in very small chunks. Oh for the vision I once had! -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64bit integers
On 25/01/2025 23:37, Simon Urbanek wrote: Tony, Dirk sent a good response. I would like to add to that that it goes beyond just bits in SEXP: adding a new type involved in arithmetics is not only a lot of work but has performance implications. Also it is unclear how it should behave in the int32_t, double, int64_t triangle of vector classes in that respect (they don't nest) while retaining compatibility (doubles promote because they are a superset, but int64_t cannot do that). I am yet to see a real use-case where 53-bits are not sufficient in integer arithmetics so it is unclear that opening that big can of worms (and breaking things) would have any benefit. Typically, the only use-case for full 64-bit integers is as opaque 64-bit storage (e.g., randomly generated IDs) but there arithmetics make no sense there and packages are already covering that need. Both Luke and I have looked into 64-bit integers, and not yet found them a high enough priority. Perhaps the most compelling motivation has not yet been mentioned. Array dimensions (especially of matrices) and hence indices are restricted to 2^31-1, although total array size is limited by available storage. If we support more, people will expect to do matrix operations on such matrices, and that is going to need versions of e.g. LAPACK which work with 64-bit integers. Modern Fortran allows different INTEGER sizes to interwork, but most of the matrix code is not written in modern Fortran. If compiling them from source it would likely be possible to include both 32-bit and 64-bit matrix libraries, but this will be tricky at best with enhanced BLAS/LAPACK which often do have both 32- and 64-bit versions but using the same entry-point names. Ironically there were versions of S-PLUS with 64-bit integers. But only 64-bit integers as in S pointers and integers had to be the same size. That is not something we could contemplate for R, as vast numbers of packages assume that R's integers map to C int (tested to be 32-bit) and Fortran 32-bit INTEGER. Cheers, Simon On Jan 25, 2025, at 11:08 PM, Tony Wilkes wrote: Hi everyone, I heard somewhere that Core R is developing the implementation of true 64bit integers. Is this true? If so, may I know what the status is of this development, and when, approximately, one can expect 64bit integers to be available in R? It would have been helpful to tell us what you wanted to do with them. Thank you for your time! Kind regards, Tony -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build error with gcc 15
On 15/01/2025 16:06, Iñaki Ucar wrote: Dear R Core, GCC 15 is already in Fedora rawhide, because it will be part of the next release, Fedora 42. R 4.4.2 fails to build with the following error [1]: sys-std.c:1189:1: warning: ‘noreturn’ attribute ignored [-Wattributes] 1189 | void Rstd_CleanUp(SA_TYPE saveact, int status, int runLast) | ^~~~ sys-std.c:1189:1: error: expected identifier or ‘(’ before ‘void’ You failed to say that GCC 15 defaults to C23 (and they have not yet documented that). I've seen some references to this in the source code, so this may be fixed in R devel. If this is the case, it would be great if you could provide a patch that I can apply to v4.4.2 until the next R release (or maybe I should just specify an older C standard?). Look at the definition of NORET in R_ext/Error.h. You want r87411; r87411 | ripley | 2024-12-01 10:11:10 + (Sun, 01 Dec 2024) | 1 line gcc pre-15 does not yet support [[noreturn]] GCC 15 is not even at RC stage, and this is one of many undocumented changes -- so they have not even got to the documentation-fixing stage. This is a GCC issue -- both LLVM and Apple clang build R-patched in C23 mode. We will port this to R-patched, unless GCC 15 is fixed before its or R-patched's release. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
