On 7/24/23 4:10 AM, Duncan Murdoch wrote:
On 23/07/2023 9:01 p.m., Brodie Gaslam wrote:
On 7/23/23 4:29 PM, Duncan Murdoch wrote:
The help page for `?gsub` says (in the context of performance
considerations):
"... just one UTF-8 string will force all the matching to be done in
Unicode"
On 7/23/23 4:29 PM, Duncan Murdoch wrote:
The help page for `?gsub` says (in the context of performance
considerations):
"... just one UTF-8 string will force all the matching to be done in
Unicode"
It's been a little while since I looked at the code but IIRC this just
means that string
FWIW, I suspect the problem might have something to do with:
> 1/1e-308
[1] 1e+308
> 1/1e-309
[1] Inf
> 1e-309 > 0
[1] TRUE
> 1e-324 > 0
[1] FALSE
That is 1e-309 starts being treated as zero by division, but not by comparison
(which happens at 1e-324). This is not quite the range of values you
Hi Taras,
I have not looked in detail at your examples here, but the
use of evalq and sys.parent makes me think these issues:
https://bugs.r-project.org/show_bug.cgi?id=17849
https://bugs.r-project.org/show_bug.cgi?id=15531
are possibly related.
Best,
B.
On Wednesday, September 28, 2022 at
> On Tuesday, January 4, 2022, 02:35:50 PM EST, Martin Morgan
> wrote:
>
> I'm not very good at character encoding / etc so this might be user
> error. The following code is meant to replace extended ASCII characters,
> in particular a non-breaking space, with "", and it works in
> R-4-1-branch
> On Thursday, September 30, 2021, 01:25:02 PM EDT,
> wrote:
>
>> On Thu, 30 Sep 2021, brodie gaslam via R-devel wrote:
>>
>> André,
>>
>> I'm not an R core member, but happen to have looked a little bit at this
>> issue myself. I've se
André,
I'm not an R core member, but happen to have looked a little bit at this
issue myself. I've seen similar things on Skylake and Coffee Lake 2
(9700, one generation past your latest) too. I think it would make sense
to have some handling of this, although I would want to show the trade-of
> On Friday, September 10, 2021, 03:13:54 PM EDT, Hervé Pagès
> wrote:
>
> Good catch, thanks!
>
> Replacing
>
> if(ISNAN(vi) || (tmp = (int) vi) < 0 || tmp > 255) {
> tmp = 0;
>
> warn |= WARN_RAW;
>
> }
> pa[i] = (Rbyte) tmp;
>
> with
>
> if(ISNAN(vi) || vi <=
> On Sunday, June 20, 2021, 9:29:28 PM EDT, brodie gaslam via R-devel
> wrote:
>
>> On Sunday, June 20, 2021, 6:21:22 PM EDT, Michael Chirico
>> wrote:
>>
>> The max width of a string is .Machine$integer.max-1:
>
> I think the max width is .Machine$integ
> On Sunday, June 20, 2021, 6:21:22 PM EDT, Michael Chirico
> wrote:
>
> Currently, substring defaults to last=100L, which strongly
> suggests the intent is to default to "nchar(x)" without having to
> compute/allocate that up front.
>
> Unfortunately, this default makes no sense for "very
> On Wednesday, June 2, 2021, 7:58:54 PM EDT, xiaoyan yu
> wrote:
>
> I am using gmail. Not sure of the configuration of plain text.
> The memory pointed by the char * as the output of Rf_translateChar() is
> actually the string "".
Hi Xiaoyan,
Unfortunately I'm not super familiar with R on W
> On Sunday, May 23, 2021, 10:45:22 AM EDT, Adrian Dușa
> wrote:
>
> On Sun, May 23, 2021 at 4:33 PM brodie gaslam via R-devel
> wrote:
> > I should add, I don't know that you can rely on this
> > particular encoding of R's NA. If I were trying to restor
Best,
B.
On Sunday, May 23, 2021, 9:23:54 AM EDT, brodie gaslam via R-devel
wrote:
This is because the NA in question is NA_real_, which
is encoded in double precision IEEE-754, which uses
64 bits. The "1954" is just part of the NA. The NA
must also conform to the NaN enco
This is because the NA in question is NA_real_, which
is encoded in double precision IEEE-754, which uses
64 bits. The "1954" is just part of the NA. The NA
must also conform to the NaN encoding for double precision
numbers, which requires that the "beginning" portion of
the number be "0x7ff0" (w
-linux-gnu (64-bit)
On Thursday, April 29, 2021, 8:40:21 PM EDT, brodie gaslam via R-devel
wrote:
> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang
> wrote:
> Just to be clear, the RD binary that Jon used was NOT compiled with
> Valgrind level 2 instrumentation. In hi
> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang
> wrote:
> Just to be clear, the RD binary that Jon used was NOT compiled with
> Valgrind level 2 instrumentation. In his example, however, he did run it
> with valgrind, as in:
>
> # RD -d valgrind --quiet -e "sum(c(1, NA))"
> ...
>
NA propagation is complicated. I don't know whether what
you observe could be explained by the difference between
a valgrind instrumented vs. not version of R (I gather the
release version you used is not instrumented / possibly
compiled differently too from the github issue?).
Hopefully someone
> On Wednesday, April 28, 2021, 5:16:20 PM EDT, Gabriel Becker
> wrote:
>
> Hi Antoine,
>
> I would say this is the correct behavior. S3 dispatch is solely (so far as
> I know?) concerned with the "actual classes" on the object. This is because
> S3 classes act as labels that inform dispatch wh
> On Saturday, December 12, 2020, 6:33:33 PM EST, Ben Bolker
> wrote:
>
> On Windows you can use memory.limit.
>
> https://stackoverflow.com/questions/12582793/limiting-memory-usage-in-r-under-linux
>
> Not sure how much that helps.
>
>On 12/12/20 6:19 PM, Arne Henningsen wrote:
>> When wor
>On Wednesday, September 2, 2020, 6:19:20 PM EDT, Lionel Henry
> wrote:
>
>Hello,
>
>The source references are useful for debugging tools because they
>allow linking to call sites in the source files.
>
>I agree the output can be confusing. Perhaps this could be fixed by
>tweaking the print method
I ran into an interesting issue with `evalq` (and also
`eval(quote(...))`):
f <- function() {
list(
sys.parent(1),
evalq(sys.parent(1)),
evalq((function() sys.parent(2))()), # add an anon fun layer
evalq((function() sys.parent(1))())
)
In 1.4 Contexts[1], should the following:
> Note that whilst calls to closures and builtins set a context,
> those to special internal functions never do.
Be something like:
> Note that whilst calls to closures always set a context,
> those to builtins only set a context under profiling
> or if
> On Friday, May 22, 2020, 6:16:45 PM EDT, Hervé Pagès
> wrote:
>
> Gabe,
>
> It's the current behavior of paste() that is a major source of bugs:
>
> ## Add "rs" prefix to SNP ids and collapse them in a
> ## comma-separated string.
> collapse_snp_ids <- function(snp_ids)
> paste("rs"
> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard
> wrote:
>
> Expected, see FAQ 7.31.
>
> You just can't trust == on FP operations. Notice also
Additionally, since you're implementing a "mean" function you are testing
against R's mean, you might want to consider that R uses a two-p
> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel
> wrote:
> On 15 May 2020 at 15:41, Martin Maechler wrote:
> |
> |
> | Why does nobody anymore help R development by working with
> | "R-devel", or at least then the alpha, beta and the "RC"
> | (Release Candidate) version
est in addressing this.
Best,
B.
>On 5/10/20, brodie gaslam via R-devel wrote:
>> Currently S3 objects nested in generic vectors cause the tag buffer to be
>> reset. This feels sub-optimal for those objects that don't have a print
>> method:
>>
>>> li
Currently S3 objects nested in generic vectors cause the tag buffer to be
reset. This feels sub-optimal for those objects that don't have a print method:
> list(a=list(b='hello'))
$a
$a$b ### notice "$a$b"
[1] "hello"
> list(a=structure(list(b='hello'), class='world'))
$a
I just submitted a patch on bugzilla[1] to update the internal column-width
tables to a more recent version of Unicode. The most obvious way this shows up
is with emoji now having a computed width of 2 columns instead of 1 once the
patch is applied:
> nchar('\U0001F600', type='width'). # grinn
As per `?intToUtf8`, and in the comments to `valid_utf8`[1], R
intends to prevent illegal UTF-8 such as UTF-8 encoded
UTF-16 surrogate pairs. `R_nchar`, invoked via `base::nchar`,
explicitly validates UTF-8 strings[2], but allows the surrogate:
> Encoding('\ud800')
[1] "UTF-8"
> ncha
> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler
> wrote:
> Note that the * -> LaTex -> PDF rendered version looks a bitnicer.
Ah yes, that does indeed look quite a bit nicer.
> I wrote the function and that help page originally.
And thank you for doing so. It is a wonderful fu
Trying the attachment as .txt instead of Rd.
On Thursday, March 5, 2020, 5:20:25 PM EST, brodie gaslam via R-devel
wrote:
% File src/library/base/man/findInterval.Rd
% Part of the R package, https://www.R-project.org
% Copyright 1995-2020 R Core Team
% Distributed under GPL 2 or later
I've found over time that R documentation that comes off as terse at
first blush is usually revealed to be precise, concise, and complete
on close reading. I'm sure this is also true of `?findInterval`, but
for whatever reason my brain simply refuses to extract meaning from it.
Part of the proble
I _think_ the relevant section of the C standard is 6.5.6 Additive Operators
Par 8, excerpted here:
> If both the pointer operand and the result point to elements
> of the same array object, or one past the last element of the
> array object, the evaluation shall not produce an overflow;
> oth
For whatever my 2c are worth I think this would be nice. I'm still
uncomfortable at having to call `options` in my package `diffobj` to set output
width.
And since the topic is here, what about `show`? Feels like it should accept
`...` so that it too could be given some set of standard or no
; Best,
>>
>> Brodie.
>>
>> [1]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17580
>>
>> On Sunday, July 14, 2019, 8:52:45 AM EDT, Tierney, Luke
>> wrote:
>>
>>
>>
>>
>>
>> This is probably best viewed in
n-standard evaluation contexts. Might be good to move to a wishlist
item in bugzilla.
Best,
luke
On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote:
> When large calls cause errors R may stall for extended periods. This
> is particularly likely to happen with `do.call`, as in this exa
Re ENSURE_NAMEDMAX, I am unsure but think this happens in (src/eval.c@492):
static SEXP forcePromise(SEXP e)
{
if (PRVALUE(e) == R_UnboundValue) {
/* ... SNIP ...*/
val = eval(PRCODE(e), PRENV(e));
/* ... SNIP ...*/
SET_PRSEEN(e, 0);
SET_PRVALUE(e, val);
ENSURE_NAMEDMAX
If you would like more details I wrote about this recently:
https://www.brodieg.com/2019/02/18/an-unofficial-reference-for-internal-inspect/
Basically as soon as you hit a closure R assumes that theargument might still
have a surviving reference to iteven after the closure evaluation ends because
When large calls cause errors R may stall for extended periods. This
is particularly likely to happen with `do.call`, as in this example
with a 24 second stall:
x <- runif(1e7)
system.time(do.call(paste0, list(abs, x))) # intentional error
## Error in (function (..., collapse = NULL
The addition of `.traceback` in r70207 adds one more function to the call stack
when invoking `traceback()`. This changes the output of one of the examples to
include the error handler call:
> options(error = function() traceback(2))
> foo(2)
[1] 1
Error in bar(2) : object 'a.variable.which.do
It's great to see the community mobilize to try to resolve this issue.
Obviously C++ has become a big part of R extensions, so it would be nice
to have clear guidelines and tools to be able to use C++ safely with the
R API.
Unfortunately doing this will probably require a fair bit of work. If
According the R-ints the only current uses of the `truelength` meta datum is
for environment hash tables. Jim Hester just made me aware that R3.4.0
introduces a new use case: growable vectors.
I attach a patch to the R-ints manual that reflects this change. The wording
is obviously just a sug
I'm encountering a problem caused by class unions from unloaded
packages that are referenced by the still-loaded subclasses. In
essence, when the class union is loaded initially, it registers itself
as a super class of the component classes in the S4 cache. When the
package the class union lives
Indeed that was on oversight on my part. It is surprising that things like
this work:
> setClass('test', slots=c(a='ANY'), prototype=list(a=NULL, b='hello'))
> new('test')@b
[1] "hello"
> slotNames(new('test'))
[1] "a"
I'm planning a release of diffobj right now so I will fix this, but I agree
`grDevices::convertColor` performance can be improved by 30-300x with
small changes to the code. `colorRamp(space='Lab')` uses `convertColor`
so it too benefits from substantial performance gains.
`convertColor` vectorizes explicitly over the rows of the input color
matrix using `apply`. The
For what it's worth the following patch fixes that particular problem on my
system. I have not checked very carefully to make sure this does not cause
other problems, but at a high level it seems to make sense. In this particular
part of the code I believe `mode` is taken to be the highest
It appears that the chromatic adaptation feature of `grDevices::convertColor`is
broken, and likely has been for many years. While a little surprising, it is
an obscure enough feature that there is some possibility this is actually
broken, as opposed to user error on my part. If it turns out to
hlighting
this in the release notes.
Best,
Brodie.
On Thursday, March 29, 2018, 9:11:15 AM EDT, Tomas Kalibera
wrote:
Thanks, fixed in R-devel (by checking validity of UTF-8 strings for
substr/substring).
Tomas
On 03/29/2018 03:53 AM, brodie gaslam via R-devel wrote:
> I think the
I think there is a memory bug in `substr` that is triggered by a UTF-8 corner
case: an incomplete UTF-8 byte sequence at the end of a string. With a
valgrind level 2 instrumented build of R-devel I get:
> string <- "abc\xEE" # \xEE indicates the start of a 3 byte UTF-8 sequence
> Encoding(st
I'm wondering if WRE Section 5.2 should be a little more explicit about misuse
of integer values other than NA, 0, and 1 in LGLSXPs. I'm thinking of this
passage:
> Logical values are sent as 0 (FALSE), 1 (TRUE) or INT_MIN = -2147483648 (NA,
> but only if NAOK is true), and the compiled code s
I'm not entirely sure this even qualifies as a bug given how unusual a case it
is:
> x <- list('a')
> name.x <- '\x81'
> Encoding(name.x) <- 'bytes'
> names(x) <- name.x
> x
$`\\x81`[1] "a"> c(x)Error: translating strings with "bytes" encoding is not
allowed
> unlist(x)
Error in unlist(x) :
tr
I'm noticing some interesting behavior in `match.call` in some corner-ish cases
that arise when you try to use `match.call` to match a "grandparent" function
and there are dots involved:
fun0 <- function(a, ...) fun1(...)
fun1 <- function(b, ...) fun2()
fun2 <- function()
m
rk Eddelbuettel
To: Duncan Murdoch
Cc: brodie gaslam ; "r-devel@r-project.org"
Sent: Sunday, November 27, 2016 2:44 PM
Subject: Re: [Rd] Changes in error reporting in r-devel
On 27 November 2016 at 13:20, Duncan Murdoch wrote:
| On 27/11/2016 11:34 AM, brodie gaslam via R-devel wrote:
Minor issue, but the following changed as of R3.3.2 from:
> a <- function() b()
> a()
Error in a() : could not find function "b"
To (at least in R Under development (unstable) (2016-11-20 r71670)):
Error in b() : could not find function "b"
Notice the "Error in **b**() :" part.
I noticed some problems that cropped in the latest versions of R-devel
(2016-11-08 r71639 in my case) for one of my packages. I _think_ I have
narrowed it down to the changes to what gets byte-compiled by default. The
following example run illustrates the problem I'm having:
compiler::enabl
I'm working on a package that implements a REPL. A typical interaction with
the package might look like:
> launch_REPL()REPL> 1 + 1[1] 2REPL> QDo you wish to save results? [y/n]REPL>
> ygoodbye ...>
This is very similar to what happens when in `browser()`: the REPL evaluates
arbitrary R user ex
I was thrilled to see this in the change log:
> match.call() gains an envir argument for specifying the environment from
> which to retrieve the ... in the call, if any; this environment was wrong (or
> at least undesirable) when the definition argument was a function.
This was an issue I ran int
Under some specific conditions, `parse` seems to produce inconsistent and
potentially incorrect results the first time it is run in a fresh clean R
session. Consider this code where we parse the same text twice in a row, and
get one value in the parse data that is mismatched:
```Type 'demo()' f
58 matches
Mail list logo
