similar to: Character Column-width Calculations

On 1/7/20 06:13, brodie gaslam via R-devel wrote: ... > Happy new decade. *** caught segfault *** conflicting decade boundaries Traceback: 1: new_decade <- 2020:2029 2: previous_decade <- 2011:2020 3: previous_previous_decade <- 2001:2010 4: current_millenium <- 2001:3000 5: previous_millenium <- 1001:2000 6: previous_previous_millenium <- 1:1000 Cheers, H.

Hello, The CRAN checks for the drake package (4.1.0) fail for r-devel-linux-x86_64-debian-clang. This happened right when crayon 1.3.4 was released, but I suspect the problem is not with crayon or drake, but with base R-devel. I cannot reproduce the error myself, but I have copied a minimal working example (MWE) below that should theoretically isolate the problem. `find_namespaced_functions()`

On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel <r-devel at r-project.org> wrote: > > 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. Adding a few more cents: It might be worth considering "who" should be allow to control the 'width' argument. In

Thanks Brodie, that's some nice detective work. If someone wanted to grant me access to Bugzilla, I'll be happy to post the bug and patch there (with your permission Brodie?) and help this bug get fixed. Mike. On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <brodie.gaslam at yahoo.com> wrote: > > > For what it's worth the following patch fixes that particular problem

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)): | > |

Better to add this to the wishlist item. This all needs to be looked at together, and nothing is likely to happen until after vacation/conference season. It will disappear from everyone's radar if it is just in R_devel. Best, luke On Sun, 14 Jul 2019, brodie gaslam wrote: > Luke, thanks for considering the issue.? I would like to > try to separate the problem into two parts, as I

One of the things I often wish R would work with: When calling print() explicitly --- as I do not so rarely, e.g., specifying digits = <nd> --- it sometimes seems awkward that from the printing options() , one can specify 'digits' and it has default digits = NULL which is documented to be equivalent to digits = getOption("digits"), but one cannot specify 'width'

> On Fri, 2017-10-20 at 14:01 +0000, brodie gaslam via R-devel wrote: > > 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 > > > should return one of these three values. (Non-zero values other > > > than INT_MIN are

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces lazily is a great idea. Displaying 1 line per call by default in interactive sessions, while being

>>>>> brodie gaslam via R-devel >>>>> on Thu, 5 Mar 2020 22:18:33 +0000 (UTC) writes: > 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

> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler <maechler at stat.math.ethz.ch> 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 function. (0 sarcasm here). > For that reason,

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 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 <-

Sorry, posting back to the list. Thank you all. Morgan On Thu, 21 May 2020, 16:33 Henrik Bengtsson, <henrik.bengtsson at gmail.com> wrote: > Hi. > > Good point and a good example. Feel free to post to the list. The purpose > of my reply wasn't to take away Peter's point but to emphasize that > base::mean() does a two-pass scan over the elements too lower the impact

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 problem may be that we interact with the function via a compressed form of the bounds of the

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 they are of the foreign variety (e.g `.C` and similar), > and those to special

> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard <pdalgd at gmail.com> 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-pass calculation[1] to reduce floating

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

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(string) <- "UTF-8" > substr(string, 1, 10) ==15375== Invalid read of

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 should return one of these three values. (Non-zero values other than INT_MIN are mapped to

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 >>>