similar to: logic tweak needed for as.data.frame.<class> deprecation warning

? Tue, 12 Mar 2024 12:33:17 -0700 Herv? Pag?s <hpages.on.github at gmail.com> ?????: > The acrobatics that as.data.frame.factor() is going thru in order to > recognize a direct call don't play nice if as.data.frame() is an S4 > generic: > > ??? df <- as.data.frame(factor(11:12)) > > ??? suppressPackageStartupMessages(library(BiocGenerics)) > ???

Hi, The acrobatics that as.data.frame.factor() is going thru in order to recognize a direct call don't play nice if as.data.frame() is an S4 generic: ??? df <- as.data.frame(factor(11:12)) ??? suppressPackageStartupMessages(library(BiocGenerics)) ??? isGeneric("as.data.frame") ??? # [1] TRUE ??? df <- as.data.frame(factor(11:12)) ??? # Warning message: ??? # In

>>>>> Mikael Jagan >>>>> on Wed, 21 Jun 2023 12:41:02 -0400 writes: > Surely this behaviour is just a case of ESS being "too clever", sourcing > *.R files in special way when it detects that a file belongs to a package > (loading dependencies automatically, etc.)? > The function ss() is defined inside of .ess.source(),

I'd like to pick up this thread started on 2019-04-11 (https://hypatia.math.ethz.ch/pipermail/r-devel/2019-April/077632.html). Modulo all the other suggestions in this thread, would my proposal of being able to disable forked processing via an option or an environment variable make sense? I've prototyped a working patch that works like: > options(fork.allowed = FALSE) >

>>>>> Tim Taylor >>>>> on Thu, 6 Jul 2023 15:11:41 +0100 writes: > Ah yes ... and reading the as.data.frame help we see (emphasis mine): > "... Direct calls to as.data.frame.<class>() are still possible (*base > package!*), for 12 atomic base classes, but will deprecated ..." > So it does seem that a lot of these

Naras, Thanks. I'm a bit confused, because Rmosek does not declare Matrix as a dependency: > tools::package_dependencies("Rmosek", which = "all")[[1L]] [1] "pkgbuild" nor does it contain code needing compilation: > packageDescription("Rmosek", fields="NeedsCompilation") [1] "no" Can you explain the

Surely this behaviour is just a case of ESS being "too clever", sourcing *.R files in special way when it detects that a file belongs to a package (loading dependencies automatically, etc.)? The function ss() is defined inside of .ess.source(), which is defined here: https://github.com/emacs-ess/ESS/blob/5c4ae91cefa5c56fd13b204a9a996825af836a67/etc/ESSR/R/.basic.R#L168 If you think

Reading the body of function 'AnswerType' in bind.c, called from 'do_c' and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically in the recurse = TRUE case. A corollary is that c(recursive = TRUE) and unlist(recursive = TRUE) treat expression vectors like expression(a, b) as lists of symbols and calls. And since they treat symbols and calls as

Hello, Currently, determinant(A) calculates the determinant of 'A' by factorizing A=LU and computing prod(diag(U)) [or the logarithm of the absolute value]. The factorization is done by LAPACK routine DGETRF, which gives a status code INFO, documented [1] as follows: *> INFO is INTEGER *> = 0: successful exit *> < 0: if INFO = -i, the i-th

If I understand the thread correctly this is an RStudio issue and I would suggest that the developers consider using pthread_atfork() so RStudio can handle forking as they deem fit (bail out with an error or make RStudio work). Note that in principle the functionality requested here can be easily implemented in a package so R doesn?t need to be modified. Cheers, Simon Sent from my iPhone

The deparse options used by default by 'deparse' and 'dput' are c("keepNA", "keepInteger", "niceNames", "showAttributes") but Defn.h still has #define DEFAULTDEPARSE 1089 /* KEEPINTEGER | KEEPNA | NICE_NAMES, used for calls */ i.e., with the SHOWATTRIBUTES bit turned off. Is that on purpose? Note that this leads to weird

On Mon, 15 Apr 2019 at 08:44, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 4/13/19 12:05 PM, I?aki Ucar wrote: > > On Sat, 13 Apr 2019 at 03:51, Kevin Ushey <kevinushey at gmail.com> wrote: > >> I think it's worth saying that mclapply() works as documented > > Mostly, yes. But it says nothing about fork's copy-on-write and memory >

Henrik, the example from the post works just fine in CRAN R for me - the post was about homebrew build so it's conceivably a bug in their libraries. That's exactly why I was proposing a more general solution where you can simply define a function in user-space that will issue a warning or stop on fork, it doesn't have to be part of core R, there are other packages that use fork() as

FWIW, a user on Stack Overflow just reported the same issue with list.files running R 4.3.z on Windows. They do not observe the issue running R-devel, with Tomas' patch (r84960). It is still the case that their file names did not exceed 260 wide characters. https://stackoverflow.com/q/77527167/12685768 Mikael On 2023-08-17 6:00 am, r-devel-request at r-project.org wrote: >

>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted

> Date: Sat, 8 Jun 2024 19:16:22 -0400 > From: Ben Bolker <bbolker at gmail.com> > > The ASAN errors occur *even if the zero-length object is not actually > accessed*/is used in a perfectly correct manner, i.e. it's perfectly > legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, > ncol = 0)`, whereas doing the

The ASAN errors occur *even if the zero-length object is not actually accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. i.e., these are *not* previously cryptic out-of-bounds accesses that are now being

On Sat, 8 Jun 2024, Ben Bolker wrote: > The ASAN errors occur *even if the zero-length object is not actually > accessed*/is used in a perfectly correct manner, i.e. it's perfectly legal in > base R to define `m <- numeric(0)` or `m <- matrix(nrow = 0, ncol = 0)`, > whereas doing the equivalent in Rcpp will (now) lead to an ASAN error. > > i.e., these are *not*

IMHO, this should be changed in both Rcpp and downstream packages: 1. Rcpp could check for out-of-bounds accesses in cases like these, and emit an R warning / error when such an access is detected; 2. The downstream packages unintentionally making these out-of-bounds accesses should be fixed to avoid doing that. That is, I think this is ultimately a bug in the affected packages, but Rcpp could

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly. Best,