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
On 5/9/25 03:09, Stephen Wade wrote:
The literanger package is no longer passing on CRAN
(https://CRAN.R-project.org/package=literanger) due to array-bound
warnings in GCC 13.3 and 14.2 (more details below).
This _looks_ to me like one of either a) a compiler bug, b) a false
positive, or c) (v
I think for reliability and portability of termination, one needs to
implement an application-specific termination protocol on both ends.
Only within specific application constraints, one can also define what
graceful termination means. Typically, one also has other expectations
from the termin
This is the documented behavior since r35262 (2005), from ?format
> If x is a list, the result is a character vector obtained by applying
> format.default(x, ...) to each element of the list
One consequence is that we can't add "nice" printing methods for
list-of-object columns in data.frames:
On Sun, 11 May 2025 10:58:18 -0700
Henrik Bengtsson wrote:
> Is it possible to gracefully interrupt a child R process on MS
> Windows, e.g. a PSOCK cluster node?
Not in the general case (I think, based on the code paths leading to
Rf_onintr() on Windows), but PSOCK cluster nodes are instances of
In help("pskill", package = "tools") is says:
Only SIGINT and SIGTERM will be defined on Windows, and pskill will
always use the Windows system call TerminateProcess.
As far as I understand it, TerminateProcess [1] terminates the process
"quite abruptly". Specifically, it is not possible for th
> On 9 May 2025, at 19:29, Kevin Ushey wrote:
>
> Hopefully a member of the CRAN team will tell me I'm wrong, but I
> think whether or not there is a compiler bug is ultimately irrelevant
> -- packages on CRAN must compile cleanly even with potentially-buggy
> development versions of compilers.
Hopefully a member of the CRAN team will tell me I'm wrong, but I
think whether or not there is a compiler bug is ultimately irrelevant
-- packages on CRAN must compile cleanly even with potentially-buggy
development versions of compilers.
So, whether or not there is a bug in gcc is moot -- you'll
В Fri, 9 May 2025 11:09:22 +1000
Stephen Wade пишет:
> inlined from ‘std::vector literanger::adjust_pvalues(const
> std::vector&)’ at ../src/literanger/utility_math.h:99:48:
> /usr/include/c++/13/bits/stl_algobase.h:437:30: warning: ‘void*
> __builtin_memmove(void*, const void*, long unsigned
The literanger package is no longer passing on CRAN
(https://CRAN.R-project.org/package=literanger) due to array-bound
warnings in GCC 13.3 and 14.2 (more details below).
This _looks_ to me like one of either a) a compiler bug, b) a false
positive, or c) (very unlikely) something in the standard l
The current wording in ?utils::news reads to me as implying we should
use `#` and `##` for the respective version, category headings [1]:
> File NEWS.md should contain the news in Markdown..., with the
> primary heading level giving the version number... Where available,
> secondary headings are t
Hello!
My three Groschen:
On MacOS (Intel CPU) and R 4.4.3 I report:
> dput(.Machine$double.xmax, control = 'hex')
0x1.fp+1023
> dput(sqrt(.Machine$double.xmax), control = 'hex')
0x1.fp+511
> dput(sqrt(.Machine$double.xmax)^2, control = 'hex')
0x1.ep+1023
so as
On Tue, 29 Apr 2025 12:00:09 +0200
Martin Maechler wrote:
> Would you (or anybody else) know if this is new behaviour or it
> also happened e.g. in R 4.4.x versions on Windows?
R-4.3.1 on Windows 7 in a virtual machine gives:
dput(sqrt(.Machine$double.xmax), control = 'hex')
# 0x1p+512
sqrt(.M
> Pavel Krivitsky via R-devel
> on Mon, 28 Apr 2025 05:13:41 + writes:
> Hello, Under R 4.5.0 on Windows (x86-64), I get:
>> sqrt(.Machine$double.xmax)^2
> [1] Inf
>> sqrt(.Machine$double.xmax)*sqrt(.Machine$double.xmax)
> [1] Inf
> On other hand on other
Hello,
Under R 4.5.0 on Windows (x86-64), I get:
> sqrt(.Machine$double.xmax)^2
[1] Inf
> sqrt(.Machine$double.xmax)*sqrt(.Machine$double.xmax)
[1] Inf
On other hand on other platforms, including Debian Linux (x86-64), I
get:
d> sqrt(.Machine$double.xmax)^2
[1] 1.797693134862315508561e+308
d> s
This StackOverflow question: https://stackoverflow.com/q/79594532 and
this discussion on Github: https://github.com/r-lib/evaluate/issues/242
are talking about an interesting situation.
Under a fairly simple setup shown in both, setTimeLimit() can interrupt
the on.exit() handler that was ins
0 and 0i are parsed as constants with 'positive zero' real and imaginary parts,
whereas 0, 0i, and 00i are parsed as *calls*:
0~ ( 0 )
0i ~ ( 0i)
00i ~ ((0), 0i)
Keeping in mind R's usual arithmetic conversions and the IEEE 754 standard which
defines e
Dear r-devel,
In R `sign(0)` and `sign(-0)` both return `0` but negative zeroes do exist
in the sense that dividing by them gives `-Inf`
Complex numbers behave oddly with negative 0s, see below:
``` r
1 / Re(0 + 0i)
#> [1] Inf
1 / Im(0 + 0i)
#> [1] Inf
1 / Re(0 - 0i)
#> [1] Inf
1 / Im(0 - 0i) # n
Is it correct to say the desired behavior in the long term is for such
an error to occur?
If so, could we make it so the --enable-strict-barrier (or other
option) behavior educes those errors for developers to opt in to
finding them sooner than later?
On Wed, Apr 23, 2025 at 3:43 PM Tomas Kaliber
On 4/24/25 00:18, Michael Chirico wrote:
In that case it seems like just erroring instead of returning invalid
pointers is a much friendlier option. Why give developers an unpinned
grenade to carry around?
That would be too strict at this point. There is too much code around
depending on tha
In that case it seems like just erroring instead of returning invalid
pointers is a much friendlier option. Why give developers an unpinned
grenade to carry around?
On Wed, Apr 23, 2025 at 1:38 PM Tomas Kalibera wrote:
>
> On 4/23/25 19:03, Michael Chirico wrote:
> > h/t Tim Taylor for pointing o
h/t Tim Taylor for pointing out my blindspot :)
We have Memcpy() in API already [1], which wraps a 0-aware R_chk_memcpy() [2].
We don't quite have Memset() in API, though; instead we have Memzero()
[3] for R_chk_memset(s, 0, n) which is 0-aware memset() [4].
[1]
https://github.com/r-devel/r-svn
>From R 4.5.0 [1], all builds of R discourage use of INTEGER() [and
friends REAL(), ... and *_RO() equivalents] on length-0 SEXP [2].
Before R 4.5.0, this was the behavior under --enable-strict-barrier.
That means the following can segfault under strict builds (e.g.
-fsanitize=alignment and -O0):
A reminder that the application deadline for this event is coming up - I put
the wrong day in the original email below, the deadline is **Wednesday, 23
April (midnight anywhere on earth).**
On Wed, Apr 2, 2025, at 1:43 PM, Heather Turner wrote:
> Dear All,
>
> There will be another R Dev Day aft
Dandan,
thanks! Dirk reported it as
https://bugs.r-project.org/show_bug.cgi?id=18884
and it should be fixed in R-devel r88154 - please confirm if it works for you
and if it does, I'll port it to R 4.5.0 Patched.
Cheers,
Simon
> On Apr 17, 2025, at 3:40 PM, zhangdandan wrote:
>
> Source: r-
On 17 April 2025 at 11:40, zhangdandan wrote:
| Source: r-base
| Version: 4.5.0-1
| Severity: normal
| Tags: FTBFS patch
| User: debian-loonga...@lists.debian.org
| Usertags: loong64
|
| Hi maintainers,
|
| Compiling the rjava 1.0-11-1 failed for loong64 in the Debian Package
| Auto-Building e
Source: r-base
Version: 4.5.0-1
Severity: normal
Tags: FTBFS patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Hi maintainers,
Compiling the rjava 1.0-11-1 failed for loong64 in the Debian Package
Auto-Building environment.
The build error log(build error on 10 architectures) is
src/main/attrib.c
r87863
'TRUE' is not replaced with 'true' in functions 'row_names_gets',
'isOneDimensionalArray', 'getAttrib0', 'copyMostAttribNoTs', 'classgets',
'R_data_class2'.
But it works fine.
src/main/main.c
r87863
'FALSE' is not replaced with 'false' in
bool wasDisplayed = FALSE;
Toby,
I know this is not what you're asking for, but when I build R from source
within a conda environment I make sure I use the conda compilers. I think
what you might be doing is using system compilers with conda libraries that
may have been built using a different compiler. Not saying this is
1 - 100 of 19402 matches
Mail list logo
