Andre,
There is a new thread (of length one, sadly), which you should read:
https://stat.ethz.ch/pipermail/r-devel/2025-July/084113.html
The function of mine that you have been testing was just a fast prototype,
and much work has been done in the mean time. Can you give the current
proposa
Martin Maechler wrote:
> I don't mind putting together a minimal package with some prototypes, tests,
> comparisons, etc. But perhaps we should aim for consensus on a few issues
> beforehand. (Sorry if these have been discussed to death already elsewhere.
> In that case, links to relevant thread
On Wed, 30 Jul 2025 09:04:39 -0500
"Therneau, Terry M., Ph.D. via R-devel" wrote:
> In the survival package the survConcordance function was replaced by
> concordance a while ago, the latter works for any ordered response
> (continuous, binary, survival, ...). I deprecated the old one a
> couple
> Therneau, Terry M , Ph D via R-devel
> on Wed, 30 Jul 2025 09:04:39 -0500 writes:
> In the survival package the survConcordance function was replaced by
concordance a while
> ago, the latter works for any ordered response (continuous, binary,
survival, ...).
> I depr
In the survival package the survConcordance function was replaced by
concordance a while
ago, the latter works for any ordered response (continuous, binary, survival,
...).
I deprecated the old one a couple of years ago.
How long should I have this persist before converting it to Defunct and
re
Dear R-devel,
For a project of mine which aims to improve R package distribution and
routing, I came across the fact that the treatment of the User Agent
info alongside download requests is not consistent.
`?download.file` explains this in detail, so I’ll assume this info to
be know and just qu
[
Partly continued from the thread earlier this month
https://stat.ethz.ch/pipermail/r-devel/2025-July/084096.html
in turn continued from discussions in 2016
https://stat.ethz.ch/pipermail/r-devel/2016-August/072970.html
https://stat.ethz.ch/pipermail/r-devel/2016-N
I would only use longer intervals than the allowed minimum to reduce the
observer bias: the profiling itself is quite an expensive operation
which alters the execution of the program and poses a source of bias to
the measurements. Instead, I would ensure the profiled application runs
for long e
Rprof() has an argument `interval = 0.02` that controls how frequently
sampling takes place. On Linux the maximum sampling frequency is once
every 10 ms and on other platforms its once every 1 ms, per
help("Rprof"):
"What is feasible is machine-dependent. On Linux, R requires the
interval to be at
Thanks Ivan - I've responded in line. I'll just add here that I've put
together a single-function package and placed it in a public repository:
https://github.com/jaganmn/ifelse
Perhaps we (all) can iterate more there, opening issues as it seems that
there could be many ... ?
Mikael
On 2025-07
On Fri, 11 Jul 2025 04:41:13 -0400
Mikael Jagan wrote:
> But perhaps we should aim for consensus on a few issues beforehand.
Thank you for raising this topic!
> (Sorry if these have been discussed to death already elsewhere. In
> that case, links to relevant threads would be helpful ...)
The d
sage-
>> From: R-devel r-devel-boun...@r-project.org On Behalf Of Duncan Murdoch
>> Sent: Tuesday, July 8, 2025 3:06 PM
>> To: Josiah Parry josiah.pa...@gmail.com; Avraham Adler
avraham.ad...@gmail.com
>> Cc: r-devel@r-project.org
>> Subj
t eventually be taken into the core. I would be cautious about
> naming the package/function as whatever is chosen, ...
>
> Avi (too)
>
> -Original Message-
> From: R-devel r-devel-boun...@r-project.org On Behalf Of Duncan Murdoch
>
> Sent: Tuesday, July 8, 2025 3
on as whatever is chosen, ...
Avi (too)
-Original Message-
From: R-devel On Behalf Of Duncan Murdoch
Sent: Tuesday, July 8, 2025 3:06 PM
To: Josiah Parry ; Avraham Adler
Cc: r-devel@r-project.org
Subject: Re: [Rd] Time to revisit ifelse ?
Since you and Antoine are volunteering to do the
Since you and Antoine are volunteering to do the work, why not start in
the way I suggested? Write up a comparison of the known ifelse
implementations, and either pick the best one, or choose the best parts
of each. Put the result in a package containing nothing else, and
invite comment from
On Tue, 8 Jul 2025 at 17:23, Avraham Adler wrote:
>
> On Tue, Jul 8, 2025 at 10:55 AM Josiah Parry wrote:
> >
> > I think the point is not that there needs to be a smaller package for yet
> > another if-else (https://xkcd.com/927/). It is that if the R-language, as a
> > whole, had a performant i
Avi, appreciate the puns!
I don't think anyone is suggesting R-core dedicate all of their time to
this problem.
To me, the thread is about consensus making (as there is no formal way to
do that).
Quoting OP here:
"It's not about asking others to do it really, that was a harsh assumption.
I'd be
On Tue, Jul 8, 2025 at 10:55 AM Josiah Parry wrote:
>
> I think the point is not that there needs to be a smaller package for yet
> another if-else (https://xkcd.com/927/). It is that if the R-language, as a
> whole, had a performant if-else in the base of the language would benefit
> **everyone**
I think the point is not that there needs to be a smaller package for yet
another if-else (https://xkcd.com/927/). It is that if the R-language, as a
whole, had a performant if-else in the base of the language would benefit
**everyone** such that a data.table or dplyr or gtools etc. alternative
wou
I think Duncan's point is that R-core are (reasonably) very, very,
very conservative about adding things to base R. It would be useful to
the community, and would indeed further the discussion, to make a tiny
package containing just that function. (Even just copying it from some
other package
It's not about asking others to do it really, that was a harsh assumption.
I'd be happy to propose a version if it helps, I'd be also very happy if it
were just a copy of if_else or fifelse (both MIT FWIW).
It's a low level building block and it's broken, IMO it's way better to
have it available an
Rather than asking others to do this, why don't you create a tiny
package containing nothing other than an ifelse() replacement? I
wouldn't want to depend on dplyr or data.table just to get their
versions, but depending on your tiny package wouldn't be an issue.
Duncan Murdoch
On 2025-07-08
Dear r-devel,
`ifelse()` has a lot of issues, and for these reasons it has been redone in
`dplyr::if_else()` and `data.table::fifelse()`, which are both great. Yet
it's an important base R function, it's really hard to program in base R
without it and scores probably as high as it gets in the most
FYI: although well documented in `help("connections")` I can't find a
mention of `zstdfile()` in the NEWS file even though it was introduced
recently in R 4.5.0:
https://cran.r-project.org/doc/manuals/r-release/NEWS.html
[[alternative HTML version deleted]]
___
... and of course, immediately after clicking send, I realize you're
using macOS, not Windows. I don't think we need this sub-directory
approach on non-Windows operating systems, so if that's affecting the
behaviour here, that's surely an RStudio bug.
On Mon, Jun 30, 2025 at 10:20 AM Kevin Ushey
Hi Duncan,
We haven't investigated yet, but I strongly suspect this is an RStudio issue.
For extra context, RStudio is doing something similar to R's own
staged installation here, where the package is initially installed
into a _build sub-directory, and then moved to its final intended
installati
I'm running RStudio on MacOS Sonoma 14.7.1 on an M4 Macbook. I haven't
updated either RStudio or the OS for several months.
However, I updated R to version 4.5.0 recently, and to 4.5.1 today. In
both of those versions I'm seeing some strange behaviour when I ask
RStudio to install a package
Thanks to Martin for additional off-list discussion; this is now addressed
'both ways' as I did file bug report #18913 with the short patch but also
have a short check in .Rprofile serving the same purpose:
## interactive sessions get a fortune cookie (needs fortunes package)
quiet <- an
ve'.
|
| > R carries the state internally in the integer variable R_Quiet, so a
minimal
| > patch only needs to expose an accessor 'quiet()' model after
'interactive()'.
| > Then we get the desired behaviour:
|
| > ~/svn/r-devel$ RD -q
| &
r variable R_Quiet, so a
minimal
> patch only needs to expose an accessor 'quiet()' model after
'interactive()'.
> Then we get the desired behaviour:
> ~/svn/r-devel$ RD -q
>> quiet()
> [1] TRUE
>>
> and this is simila
ut that is clunky.) For me
'--quiet' is independent to 'interactive'.
R carries the state internally in the integer variable R_Quiet, so a minimal
patch only needs to expose an accessor 'quiet()' model after 'interactive()'.
Then we get the desired behavio
> Enrico Schumann
> on Fri, 27 Jun 2025 15:42:47 +0200 writes:
> On Thu, 26 Jun 2025, Dirk Eddelbuettel writes:
>> On 25 June 2025 at 07:11, Kurt Hornik wrote:
>> | > hormutz screed writes:
>> |
>> | Thanks. Makes sense to me, needs some discussion in R Core
I've had a busy time the past week, so this just comes now,
(and as "top-reply", unusually for me, and this list in general..).
I've been the one adding axTicks() to R a long time ago,
and also axisTicks(); these are related but really have
different goals and in particular,
- axTicks () i
On Thu, 26 Jun 2025, Dirk Eddelbuettel writes:
> On 25 June 2025 at 07:11, Kurt Hornik wrote:
> | > hormutz screed writes:
> |
> | Thanks. Makes sense to me, needs some discussion in R Core ...
>
> Nice to see this in NEWS [1]:
>
> CHANGES IN R-devel BUG FIXES
>
> ‘ %in% set’ has beco
Glad to hear this will be incorporated, thanks.
On Thu, Jun 26, 2025 at 1:45 PM Dirk Eddelbuettel wrote:
>
>
> On 25 June 2025 at 07:11, Kurt Hornik wrote:
> | > hormutz screed writes:
> |
> | Thanks. Makes sense to me, needs some discussion in R Core ...
>
> Nice to see this in NEWS [1]:
>
On 25 June 2025 at 07:11, Kurt Hornik wrote:
| > hormutz screed writes:
|
| Thanks. Makes sense to me, needs some discussion in R Core ...
Nice to see this in NEWS [1]:
CHANGES IN R-devel BUG FIXES
‘ %in% set’ has become as fast again, as it was before R 4.3.0, via
new S3 method
> hormutz screed writes:
Thanks. Makes sense to me, needs some discussion in R Core ...
Best
-k
> I recently became aware that using %in% for the Date class is about
> 100x slower from R 4.3 onward than in older versions. I did not
> include the results from R prior to 4.3 but the first an
I recently became aware that using %in% for the Date class is about
100x slower from R 4.3 onward than in older versions. I did not
include the results from R prior to 4.3 but the first and second
methods below yield equal and very fast results for older R versions.
I have suggested a fix that tr
On 6/22/25 10:13, Duncan Murdoch wrote:
On 2025-06-22 8:15 a.m., Spencer Graves wrote:
If the range fed to axTicks is too narrow, the output is only 2 points;
shouldn't it degenerate to using "pretty" in such cases?
EXAMPLE:
ylims2 <- c(0.2, 0.8)
get_axp <- function(x) 10^c(ceiling(x[1]),
If the range fed to axTicks is too narrow, the output is only 2 points;
shouldn't it degenerate to using "pretty" in such cases?
EXAMPLE:
ylims2 <- c(0.2, 0.8)
get_axp <- function(x) 10^c(ceiling(x[1]), floor(x[2]))
## mimic par("yaxs") == "i"
usr.i2 <- log10(ylims2)
(aT.i2 <- axTicks(side =
On 2025-06-22 8:15 a.m., Spencer Graves wrote:
If the range fed to axTicks is too narrow, the output is only 2 points;
shouldn't it degenerate to using "pretty" in such cases?
EXAMPLE:
ylims2 <- c(0.2, 0.8)
get_axp <- function(x) 10^c(ceiling(x[1]), floor(x[2]))
## mimic par("yaxs") == "i"
us
The build system rolled up R-4.5.1.tar.gz and .xz (codename “Great Square
Root") this morning.
This is a patch release with a handful of minor changes and mixups.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.5
R#L57-L75
Those lines arise from this entry in the Rd file:
\Sexpr[stage=render,results=rd]{dplyr:::methods_rd("mutate")}
The dplyr:::methods_rd function basically just formats the results of a
call similar to `methods("mutate")`. All the rest of that is by R Core,
On 2025-06-10 12:15 pm, Michael Chirico wrote:
Thanks for the thoughtful reply Mikael.
Any function F with '...' as a formal argument can pass '...' to another
function G.
Yes, that's true. The difference is that in print(F) we can _usually_
pick out at a glance how '...' is being used --
n the Rd file:
\Sexpr[stage=render,results=rd]{dplyr:::methods_rd("mutate")}
The dplyr:::methods_rd function basically just formats the results of a
call similar to `methods("mutate")`. All the rest of that is by R Core,
not tidyverse folks.
Duncan Murdoch
On Mo
When it comes to adding more info in the help pages, we'd be remiss
not to point out the great engineering work the tidyverse folks have
put in to this end:
https://dplyr.tidyverse.org/reference/mutate.html
> Methods available in currently loaded packages: dbplyr (tbl_lazy), dplyr
> (data.frame)
Thanks for the thoughtful reply Mikael.
> Any function F with '...' as a formal argument can pass '...' to another
> function G.
Yes, that's true. The difference is that in print(F) we can _usually_
pick out at a glance how '...' is being used -- we can see which 'G'
is getting '...'.
For S3 ge
I am not saying this is wonderful but this does work:
penguins |>
subset(species != "Gentoo") |>
stats:::t.test.formula(formula = bill_len ~ species)
Also there is a problem with t.test in that methods are not supposed
to have conflicting
signatures but
> args(t.test)
function
To use functions for common statistical tests/models, like t.test,
wilcox.test, lm, glm, and aov, we must currently use the pipe placeholder _
when using pipes:
penguins |>
subset(species != "Gentoo") |>
t.test(bill_len ~ species, data = _)
The syntax would be cleaner and perhaps more int
I don't really understand the premise. Any function F with '...' as a formal
argument can pass '...' to another function G. The actual arguments matching
'...' in the call to F will be matched to the formal arguments of G. So the
the maintainer of F may want to alert the user of F to the existe
Hi,
I agree that showing that there are other methods might help.
The print.function method could be modified to add this in addition to
print.default output.
But I guess (new) users would check the help page with ?as.data.frame and
not print the method or use args() (if they don't check with the
Thanks Josh,
With fresh eyes, it's definitely information overload for the
suggested output to take up more space than the function body itself.
I'm not sure your suggestion gets at the heart of the issue, though,
which is about steering the user with regards to interpreting '...'
they see in the
Hi Mike,
On Fri, Jun 6, 2025 at 1:59 PM Michael Chirico
wrote:
>
> There is a big difference in how to think of '...' for non-generic
> functions like data.frame() vs. S3 generics.
>
> In the former, it means "any number of inputs" [e.g. columns]; in the
> latter, it means "any number of inputs [
There is a big difference in how to think of '...' for non-generic
functions like data.frame() vs. S3 generics.
In the former, it means "any number of inputs" [e.g. columns]; in the
latter, it means "any number of inputs [think c()], as well as any
arguments that might be interpreted by class impl
- Ursprüngliche Mail -
> Von: "Kurt Hornik"
> An: "Laurent Gatto"
> CC: "Kurt Hornik" , "Trevor Davis"
> , r-devel@r-project.org, "roland
> fuss"
> Gesendet: Dienstag, 3. Juni 2025 19:23:01
> Betreff: Re: [Rd] FR: improve &quo
> Laurent Gatto writes:
Thanks.
In general, I guess we all agree that if 'include.only' or 'exclude' ask
for something (currently) impossible then a suitably classed condition
object should be thrown. Could be both a warning or an error ...
And perhaps we should take 'include.only' as 'incl
al Message-
From: R-devel On Behalf Of Simon Urbanek
Sent: Monday, June 2, 2025 7:48 PM
To: Henrik Bengtsson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Specifying a long string literal across several lines
> On 3 Jun 2025, at 09:34, Henrik Bengtsson wrote:
>
> One could also ar
I also suspect the byte compiler could constant-fold some of these
common paste expressions, effectively negating any potential runtime
cost of `paste` / `paste0` with string literals.
Beyond the syntax restrictions for automatic concatenation of
sequential string literals, it's also a big footgun
expense of a more complex,
and perhaps slow, parser.
-Original Message-
From: R-devel On Behalf Of Henrik Bengtsson
Sent: Monday, June 2, 2025 5:34 PM
To: Josiah Parry
Cc: r-devel@r-project.org
Subject: Re: [Rd] Specifying a long string literal across several lines
One could also argue
> On 3 Jun 2025, at 09:34, Henrik Bengtsson wrote:
>
> One could also argue that paste0("a", "b", "c") is a function call that needs
> to be evaluated at runtime, whereas "abc" is a string constant understood by
> the parser, and often also language agnostic. I'd assume compilers and code-
are fairly
oddball solutions such as running a program in an environment (as in POSIT
RSTUDIO) that allows python and R to work together on a single set of data so
python can be used to create variables like the ones you want and R can then
use them. I suspect you might find such a solution far w
One could also argue that paste0("a", "b", "c") is a function call
that needs to be evaluated at runtime, whereas "abc" is a string
constant understood by the parser, and often also language agnostic.
I'd assume compilers and code- and text-search tools do a better job
with the latter.
/Henrik
On
I suppose taste is learned as well. It does feel quite odd that the best
way to define a long string without a note or text wrapping is by being
creative with functions.
This is valid in Python, Julia, and Rust (if you add `let` and a
terminating semi-colon):
my_str = "part1\
part2\
part2"
I don
Like Tomas, I find the paste0 readability to be **much** better, partly
because it allows for better indentation (as Tomas pointed out). Perhaps a
pointless email, but sometimes - for these subjective issues - it is
worthwhile to point out a difference in opinion.
Best,
Kasper
On Mon, Jun 2, 2025
On 6/2/25 17:37, Josiah Parry wrote:
Tomas,
Here is a good example of where this functionality would be useful:
https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56
In order to prevent R CMD check notes I have to use `paste0()` to
concat
Tomas,
Here is a good example of where this functionality would be useful:
https://github.com/R-ArcGIS/arcgislayers/blob/2b29f4c254e7e5a1dadce8d4b0015a70dfae39d4/R/arc-open.R#L19-L56
In order to prevent R CMD check notes I have to use `paste0()` to
concatenate long URLs. If we were able to use `\
From: R-devel On Behalf Of Toby Hocking
Sent: Tuesday, 27 May 2025 08:17
To: Marttila Mikko via R-devel
Subject: Re: [Rd] Bug in prettyNum
Thanks for the contribution Mikko!
For testing future patches, you can actually do it right in the web browser,
thanks to Heather Turner's R Dev Cont
On 5/28/25 04:15, Pavel Krivitsky via R-devel wrote:
Dear All,
Perhaps this should go in r-package-devel, but I suspect that this is
going to turn into a feature request, and I want to run it by the list
before filing it in the Bugzilla.
I would like to specify a long string literal without m
Full schedule is available on developer.r-project.org (pending update from SVN).
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
> Pavel Krivitsky
> on Wed, 28 May 2025 01:36:57 + writes:
> Dear All,
> Thanks for looking into it, and apologies for bumping this.
> I think the strangest thing for me is that the C and the R
> implementations on Windows yield different results. I don't know if
Dear All,
Perhaps this should go in r-package-devel, but I suspect that this is
going to turn into a feature request, and I want to run it by the list
before filing it in the Bugzilla.
I would like to specify a long string literal without making the line
of code too long. In R,
"abc
def"
yields
Dear All,
Thanks for looking into it, and apologies for bumping this.
I think the strangest thing for me is that the C and the R
implementations on Windows yield different results. I don't know if it
warrants a deeper look.
Ultimately, I rewrote the code that relied on this behaviour. (I needed
On Tuesday, May 27th, 2025 at 9:13 AM, Kurt Hornik wrote:
> > > > > > Trevor Davis writes:
>
>
> Thanks.
>
> This is really about what
>
> library("foo", include.only = "fun2")
>
> should do if package 'foo' was already attached and the include.only
> contradicts a previous specification.
>
> Trevor Davis writes:
Thanks.
This is really about what
library("foo", include.only = "fun2")
should do if package 'foo' was already attached and the include.only
contradicts a previous specification.
In principle, one could look into allowing the underlying
attachNamespace() to add mor
Thanks for the contribution Mikko!
For testing future patches, you can actually do it right in the web
browser, thanks to Heather Turner's R Dev Container, see instructions here
https://contributor.r-project.org/r-dev-env/container_setup/
Best
Toby
On Mon, May 26, 2025 at 6:28 PM Martin Maechler
Thank you, Marttila and Ivan,
As the original author of prettyNum() {etc ..},
I will commit such a bug fix to R-devel (and probably port it to
R 4.5.0 patched) quite soon
(but not yet today).
Best regards,
Martin Maechler
> Ivan Krylov via R-devel
> on Fri, 23 May 2025 17:14:57 +
> Of course, it would be preferable if didn't need to detach the namespace.
Here's a version only detaches the namespace when necessary:
```r
use <- function(package, include.only) {
package <- as.character(package)[[1L]]
if (!requireNamespace(package, quietly = TRUE)) {
warning("
В Fri, 23 May 2025 11:47:33 +
Marttila Mikko via R-devel пишет:
> When called with a numeric vector, the `replace.zero` argument is
> disregarded.
>
> > prettyNum(0, zero.print = "- ", replace.zero = TRUE)
> [1] "-"
> Warning message:
> In .format.zeros(x, zero.print, replace = replace.zer
Dear list,
I'd like to report a bug in `prettyNum()`. When called with a numeric vector,
the `replace.zero` argument is disregarded.
> prettyNum(0, zero.print = "- ", replace.zero = TRUE)
[1] "-"
Warning message:
In .format.zeros(x, zero.print, replace = replace.zero) :
'zero.print' is truncat
Hello,
Currently `use` fails silently if you try to attach functions from the
same namespace. It would be nice and more similiar to the use of
roxygen2 if it could add (and maybe even remove?) functions. Here is a
simple proof of concept I have posted on Stack Overflow [1]. Something
similar
> Hervé Pagès writes:
> FWIW NeedsCompilation is a misnomer. IIRC when I was discussing this
> feature with R core members many years ago, it doesn't only flag
> packages that require compilation (and thus contain arch-specific binary
> files), but it is more generally intended to flag pack
This is all a bit above my head but as a Windows user I have always
interpreted NeedsCompilation as meaning I could install it without
having to wait for binaries to appear on CRAN. I do not need Rtools for
my own packages so I have never installed it.
Michael
On 17/05/2025 09:13, Iñaki Ucar
On 17 May 2025 at 10:13, Iñaki Ucar wrote:
| El sáb., 17 may. 2025 4:03, Hervé Pagès
| escribió:
|
| > FWIW NeedsCompilation is a misnomer. IIRC when I was discussing this
| > feature with R core members many years ago, it doesn't only flag
| > packages that require compilation (and thus contai
El sáb., 17 may. 2025 4:03, Hervé Pagès
escribió:
> FWIW NeedsCompilation is a misnomer. IIRC when I was discussing this
> feature with R core members many years ago, it doesn't only flag
> packages that require compilation (and thus contain arch-specific binary
> files), but it is more generally
FWIW NeedsCompilation is a misnomer. IIRC when I was discussing this
feature with R core members many years ago, it doesn't only flag
packages that require compilation (and thus contain arch-specific binary
files), but it is more generally intended to flag packages that the user
wouldn't be abl
On Thu, 15 May 2025 at 11:42, Jeroen Ooms wrote:
>
> On Wed, May 14, 2025 at 11:05 PM Simon Urbanek
> wrote:
> >
> > Can you give an example, please? I wonder if there is a real use-case or
> > just bad package design.
>
> The case that bit me yesterday was a Bioconductor package Rigraphlib,
> s
On 15 May 2025 at 11:41, Jeroen Ooms wrote:
| The case that bit me yesterday was a Bioconductor package Rigraphlib,
| see
https://bioconductor.org/packages/release/bioc/src/contrib/Rigraphlib_1.0.0.tar.gz
|
| This package builds a static library entirely from a configure script.
| Because there
On Wed, May 14, 2025 at 11:05 PM Simon Urbanek
wrote:
>
> Jeroen,
>
> thanks for raising the issues. Comments inline.
>
>
> > On May 15, 2025, at 1:47 AM, Jeroen Ooms wrote:
> >
> > R-universe builds and checks all CRAN packages on arm64 on Mac, Linux
> > and soon Windows. It is important that we
> Simon Urbanek writes:
Re part II (CRAN packages which have NeedsCompilation: yes but don't
really need it): I of course have code for this, last touched in 2016.
Running the code (which currently only looks at having a 'src' subdir,
based on one possible interpreation of
it is normally s
Jeroen,
thanks for raising the issues. Comments inline.
> On May 15, 2025, at 1:47 AM, Jeroen Ooms wrote:
>
> R-universe builds and checks all CRAN packages on arm64 on Mac, Linux
> and soon Windows. It is important that we can identify from a binary
> package for which architecture it was bui
Strongly in favour of Jeroen's suggestions. Thanks for putting them together.
Iñaki
On Wed, 14 May 2025 at 15:48, Jeroen Ooms wrote:
>
> R-universe builds and checks all CRAN packages on arm64 on Mac, Linux
> and soon Windows. It is important that we can identify from a binary
> package for whi
R-universe builds and checks all CRAN packages on arm64 on Mac, Linux
and soon Windows. It is important that we can identify from a binary
package for which architecture it was built. R inserts this
information into the second part of the "Built:" field in the
DESCRIPTION. For example, packages wit
> Stephen Wade writes:
Thanks to everyone so far.
Indeed, packages
GenomeAdmixR SpatialKWD literanger
all give the same include/c++/14/bits/stl_algobase.h:452:30
-Warray-bounds= warning for the GCC 14.2.0 compilers used for Debian
testing and windows, but not for GCC 15.1.0 used for Fedor
Thanks, I agree with the course of action, especially given literanger
seems to be the only casualty. I'm just making note that the policy
doesn't necessarily generate the outcome we want. No policy ever will!
I 100% appreciate CRAN volunteers' efforts.
In this case, the compiler is generating a f
Hi Stephen,
I still believe your best option is still to just submit a version of
your package that includes a workaround for this compiler issue.
You could, in theory, try to contact the CRAN maintainers at
c...@r-project.org, and either (1) request an exception for your
package, or (2) request
After (a lot) more work, including looking for MWE (see
https://godbolt.org/z/38nnaEcrf), I am confident this is a bug which
has already been resolved:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415.
The bug only occurs when optimisation is enabled (-O1 to -O3 at
least), on GCC 12.4, 13.1--13
Thanks all.
I can confirm that 'GenerateConsoleCtrlEvent', which Kevin and Ivan
referred to, works. I have verified that ps::ps_interrupt() can
trigger an interrupt of an Rscript process running in the background,
which then R detects as a user-interrupt (think Ctrl-C) and signals an
'interrupt' c
Sounds good. Moving over to Bugzilla:
https://bugs.r-project.org/attachment.cgi?id=3480&action=diff
On Mon, May 12, 2025 at 10:29 AM Kurt Hornik wrote:
>
> > Michael Chirico writes:
>
> Thanks. Should be ok to change the wording (provided this can be done
> without confusing maintainers).
>
> Michael Chirico writes:
Thanks. Should be ok to change the wording (provided this can be done
without confusing maintainers).
Perhaps you could make a suggestion? :-)
Best
-k
> The current wording in ?utils::news reads to me as implying we should
> use `#` and `##` for the respective v
On 4/27/25 22:19, Duncan Murdoch wrote:
BTW, the help for setTimeLimit() says that the time limit check
happens frequently during `Sys.sleep()`, but that doesn't appear to be
true. I've tried a variation on the code above which sleeps for 20
seconds, even with a time limit of 1 second.
Re
1 - 100 of 19430 matches
Mail list logo
