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:
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
Kalibera wrote:
>
>
> 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
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
/RS.h#L62-L63
[4]
https://github.com/r-devel/r-svn/blob/9e597ca8132e8b6298b0bedb39fa8deba5c819df/src/main/memory.c#L3582-L3587
Mike C
On Wed, Apr 23, 2025 at 8:57 AM Michael Chirico
wrote:
>
> From R 4.5.0 [1], all builds of R discourage use of INTEGER() [and
> friends REAL()
>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):
thod to
> decide whether to follow the suggestion in 15654, and could maybe submit
> a patch for that, too.
>
> Duncan Murdoch
>
>
> On 2025-03-25 2:12 a.m., Michael Chirico wrote:
> > Consider:
> >
> > foo <- function(x, y, ...) {
> > UseMethod(&q
Consider:
foo <- function(x, y, ...) {
UseMethod("foo")
}
foo.default <- function(x, y = 0, ...) {
cat(sprintf("%s: x=%s, y=%s\n", as.character(match.call()[[1L]]), x, y))
if (...length()) str(list(...))
}
foo.C <- function(x, y = 3, ...) {
cat(sprintf("%s: x=%s, y=%s\n", as.char
The current documentation of ?on.exit reads [1]
> `on.exit` records [`expr`] as needing to be executed when the current
> function exits...
This is almost always how it is used, however I don't see that as
explaining this other common way to use on.exit():
local({
old = setwd(...)
on.exit(s
is
> \emph{not} related to the R logical type LGLSXP. This can conflict with other
> software: for example it conflicts with the headers in IJG’s jpeg-9 (but not
> earlier versions).
It would also be nice if this mistake could be caught by the compiler,
but that's another issue.
Michael
this.
Mike C
On Sat, Dec 14, 2024 at 4:02 AM Dirk Eddelbuettel wrote:
>
>
> On 11 December 2024 at 15:00, Michael Chirico wrote:
> | Thanks Simon, I didn't know that! That's definitely a compelling
> | reason to leave the current default untouched and to eschew any
> |
d set EDITOR or VISUAL - it's just a default
> when neither the system nor user doesn't declare their preference. I don't
> think R should be fishing for random programs that may or may not be editors
> at run-time.
>
> Cheers,
> Simon
>
>
> > On Dec 1
> As for the conjecture
To quickly clarify, I mean "it is much more common to write code from
lightweight environments [now as compared to the year 2000 when the
EDITOR default was set to 'vi']". We agree about where most code is
written still today.
And yes, we can set VISUAL/EDITOR (as my perso
It looks like R has defaulted to using 'vi' for file.edit() (via
EDITOR since ~24 years ago[1][2].
These days I think it is much more common to write code from
lightweight environments, e.g. Docker files which strip all
unnecessary commands. On such machines, it is not safe to assume 'vi'
is insta
Hi all,
What it says in the title. This is likely to cause a lot of CRAN packages
to fail (I can try and quantify this if seen fit), but I think it's for the
best. Packages should not (IMHO) be relying on partial matching in package
code / tests. One might be more permissive for vignette/examples
fruit.
On Mon, Apr 15, 2024 at 6:46 AM Martin Maechler
wrote:
> I think we should try to advance and hopefully finalize this
> thread before we forget about it ..
>
> >>>>> Michael Chirico n Thu, 11 Apr 2024 09:10:11 -0700 writes:
>
> >> I would assume
I think your suggestion to just point to
detach()+attachNamespace() is reasonable enough, the rare users that care
about this are likely to be able to figure out the rest from there.
On Thu, Apr 11, 2024 at 7:37 AM wrote:
> On Thu, 11 Apr 2024, Duncan Murdoch wrote:
>
> &g
Right now, attaching the same package with different include.only= has no
effect:
library(Matrix, include.only="fac2sparse")
library(Matrix)
ls("package:Matrix")
# [1] "fac2sparse"
?library does not cover this case -- what is covered is the _loading_
behavior of repeated calls:
> [library and re
I am curious why readLines() has a default (n=-1L) to read the full
file while readChar() has no default for nchars= (i.e., readChar(file)
is an error). Is there a technical reason for this?
I often[1] see code like paste(readLines(f), collapse="\n") which
would be better served by readChar(), esp
main/bind.c#L418-L425
And indeed! It's not "coercion" in the sense I just described... there's a
branch for the 'x == NA_LOGICAL' case to _convert_ to NA_complex_.
On Mon, Nov 6, 2023 at 3:08 AM Martin Maechler
wrote:
> >>>>> Michael Chirico
>
This is another follow-up to the thread from September "Recent changes to
as.complex(NA_real_)".
A test in data.table was broken by the changes for NA coercion to complex;
the breakage essentially comes from
c(NA, 0+1i)
# vs
c(as.complex(NA), 0+1i)
The former is the output we tested against; the
perl = FALSE) :
> invalid regular expression '(invalid', reason 'Missing ')''
> In addition: Warning message:
> In grepl("(invalid", "subject", perl = FALSE) :
> TRE pattern compilation error 'Missing ')''
ng" before any regex is actually executed.
At a bare minimum this is a good place to return a classed warning (say
invalid_regex_warning) to allow finer control than tryCatch(condition=).
On Mon, Oct 9, 2023, 11:30 PM Tomas Kalibera
wrote:
>
> On 10/10/23 01:57, Michael Chirico
It will be useful to package authors trying to validate input which is
supposed to be a valid regular expression.
As near as I can tell, the only way we can do so now is to run any
regex function and check for the warning and/or condition to bubble
up:
valid_regex <- function(str) {
stopifnot(i
MRE to produce the message is the following:
setClass("Foo")
setOldClass("Bar")
setAs("Bar", "Foo", \(x) x)
# NOTE: arguments in definition for coerce changed from (x) to (from)
In an interactive setting, that may be fine, but I first encountered
this message in the install log of a package for w
re(x = "double", y = "double"), \(x,
y, ...) x + y)
BaseGeneric(X = 1, Y = 2)
# Error: unable to find an inherited method for function ‘BaseGeneric’
for signature ‘x="missing", y="missing"’
On Fri, Aug 11, 2023 at 2:26 AM Martin Maechler
wrote:
>
> >
cents that I think it would be very useful and
> beneficial to improve S4 to surface that information as well.
>
> More information about the way that the dispatch failed would be of great
> help in situations like the one Michael pointed out.
>
> ~G
>
> On Thu, A
("conn", "statement"))
> dbGetQuery(connection = NULL, query = NULL)
> #> Error: Can't find method for generic `dbGetQuery(conn, statement)`:
> #> - conn : MISSING
> #> - statement: MISSING
>
> Hadley
>
> On Wed, Aug 9, 2023 at 10:02 PM Mi
I fielded a debugging request from a non-expert user today. At root
was running the following:
dbGetQuery(connection = conn, query = query)
The problem is that they've named the arguments incorrectly -- it
should have been [1]:
dbGetQuery(conn = conn, statement = query)
The problem is that the
I personally wouldn't like using a string, and this comment makes me
think it's against the r-core preference as well:
https://bugs.r-project.org/show_bug.cgi?id=18429#c1
Thanks both for catching the sloppy mistake in vapply() :)
Let's continue discussion on the bug/PR.
On Thu, Mar 2, 2023 at 1
Great suggestion! I've started a patch:
https://bugs.r-project.org/show_bug.cgi?id=18479
On Wed, Mar 1, 2023 at 1:56 AM Ivan Krylov wrote:
>
> В Wed, 1 Mar 2023 01:36:02 -0800
> Michael Chirico via R-devel пишет:
>
> > +comps[non_syntactic] <- paste0("`",
Consider:
x <- list(`a b` = 1)
x$a
(i.e., press the 'tab' key after typing 'x$a')
The auto-complete mechanism will fill the buffer like so:
x$a b
This is not particularly helpful because this is now a syntax error.
It seems to me there's a simple fix -- in
utils:::specialCompletions(), we can
x27;s a more general issue of static analysis).
Michael Chirico
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
/github.com/r-devel/r-svn/blob/f55b24945d56e824f124638c596b99887441354a/src/main/gram.y#L2978-L3008
('\n' is in the list of valid items after '\')
I don't see any special handling for '\r', so there may be a gap in
the R parser? Or I just don't understand w
I'm coming across some code that uses the fact the parser ignores a
line-terminal '\', e.g.
identical("\
", "\n")
# [1] TRUE
x = "abc \
def"
y = "abc \ndef"
identical(x, y)
# [1] TRUE
However:
identical("\\n", "\n")
# [1] FALSE
This appears to be undocumented behavior; the closest thing I see i
require() and library() both emit this message immediately before
running library():
"Loading required package: %s"
https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L967-L968
https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c
o))
# [1] "original" "source" "class"
PS one day I hope to master the dark art of choosing r-devel or
bugzilla for issues :)
On Wed, Jun 8, 2022 at 3:44 AM Martin Maechler
wrote:
>
> >>>>> Michael Chirico
> >>>>> on Mon, 6 Ju
pushing
> back against your linter were using messages from .onLoad for...
>
> Best,
> ~G
>
>
>
> On Thu, Nov 4, 2021 at 12:37 PM Duncan Murdoch
> wrote:
>>
>> On 04/11/2021 2:50 p.m., Michael Chirico via R-devel wrote:
>> > I wrote a linter to
I wrote a linter to stop users from using packageStartupMessage() in
their .onLoad() hook because of the R CMD check warning it triggers:
https://github.com/wch/r-source/blob/8b6625e39cd62424dc23399dade37f20fa8afa91/src/library/tools/R/QC.R#L5167
However, this received some pushback which I ultim
today <- Sys.Date()
typeof(today)
# [1] "double"
typeof(seq(today, by=1, length.out=2))
# [1] "integer"
Clearly minor as it doesn't seem to have come up before (e.g. coercion
to numeric will happen automatically whenever fractional dates are
needed); I only noticed because of a test using identica
Here is a reprex:
# initialize reprex package
cd /tmp
mkdir myPkg && cd myPkg
echo "Package: myPkg" > DESCRIPTION
echo "Version: 0.0.1" >> DESCRIPTION
mkdir R
echo "print.my_class = function(x, ...) { cat(gettext(\"'%s' is
deprecated.\"), '\n', gettext(\"'%s' is deprecated.\",
domain='R-myPkg'), '
Hi all,
I am about 99% sure tools::update_pkg_po() is using an invocation that
is not supported by the Solaris version of msgfmt.
The invocation[1]:
msgfmt -c --statistics -o /path/to/file.mo /path/to/file.po
AFAICT neither -c nor --statistics appear to be supported by Solaris [2]:
I don't hav
on, Jun 21, 2021 at 1:32 AM Martin Maechler
wrote:
>
> >>>>> Tomas Kalibera
> >>>>> on Mon, 21 Jun 2021 10:08:37 +0200 writes:
>
> > On 6/21/21 9:35 AM, Martin Maechler wrote:
> >>>>>>> Michael Chirico
> >&g
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 large" strings
which may exceed 100L in "width".
The max width of a string is .
Is this something that should be updated to use #include? Other packages
appear to have done so, e.g. from GitHub:
https://github.com/search?q=%22%23include+cocoa%2Fcocoa.h%22&type=code
Michael Chirico
[[alternative HTML version deleted]]
__
the issue (AFAICT via trioremap.h).
On Thu, Apr 30, 2020 at 4:16 PM Michael Chirico
wrote:
> [a bit unsure on if this is maybe better for r-package-devel]
>
> We recently added translations to messages at the R and C level to
> data.table.
>
> At the C level, we did _() wrappi
ltiplication of logical values even means).
FALSE * NA = 0L
On Sat, May 23, 2020 at 6:49 PM Martin Maechler
wrote:
>
> >>>>> Michael Chirico
> >>>>> on Sat, 23 May 2020 18:08:22 +0800 writes:
>
> > I don't see this specific case documented
I don't see this specific case documented anywhere (I also tried to search
the r-devel archives, as well as I could); the only close reference
mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
snippet from R-lang:
In cases where the result of the operation would be the same for
the use of snprintf specifically appears to have caused
a crash on Windows:
https://github.com/Rdatatable/data.table/issues/4402
Is there any guidance against using gettext with snprintf, or perhaps
guidance on which "outputters" *are* OK for translation?
Michael Chirico
[[a
Awesome. Gabe, since you already have a workshopped version, would you like
to proceed? Feel free to ping me to review the patch once it's posted.
On Mon, Sep 16, 2019 at 3:26 PM Martin Maechler
wrote:
> >>>>> Michael Chirico
> >>>>>
Finally read in detail your response Gabe. Looks great, and I agree it's
quite intuitive, as well as agree against non-recycling.
Once the length(n) == length(dim(x)) behavior is enabled, I don't think
there's any need/desire to have head() do x[1:6,1:6] anymore. head(x, c(6,
6)) is quite clear fo
& the ambiguity is
immediate -- the commit mentions disable-long-double but builds
enable-long-double.
https://github.com/wch/r-source/commit/fb8e36f8be0aaf47a9c54c9effb219dae34f0e41
Could someone please help to clear the confusion?
Thanks
Michael Chirico
[[
;format" "usetz" "..."
Is there any reason not to accept a tz argument for format.POSIXlt? It's
quite convenient to be able to specify an output timezone format on the fly
with format.POSIXct; in the case at hand, I'm trying to
#x27;', gsub('[^\U{0021}-\U{0039}\U{003B}-\U{007E}]', '.',
names(x)))
(Or maybe errors for having invalid names)
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
I think of head() as a standard helper for "glancing" at objects, so I'm
sometimes surprised that head() produces massive output:
M = matrix(nrow = 10L, ncol = 10L)
print(head(M)) # <- beware, could be a huge print
I assume there are lots of backwards-compatibility issues as well as valid
use
gt; >
> > Follow-up (inline) on my comment about a potential issue in `[<-.Date`.
> >
> > On Mon, May 27, 2019 at 9:31 AM Michael Chirico
> > wrote:
> > >
> > > Yes, thanks for following up on thread here. And thanks again for
> clearing things up,
Since a while ago, R on my Mac terminal is being started in Japanese:
R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.0 (64-bit)
R は、自由なソフトウェアであり、「完全に無保証」です。
一定の条件に従えば、自由にこれを再配布することができます。
配布条件の詳細
use.
My last curiosity on this issue will be in my follow-up thread.
Mike C
On Mon, May 27, 2019, 10:25 PM Joshua Ulrich
wrote:
> On Sun, May 26, 2019 at 6:47 AM Joshua Ulrich
> wrote:
> >
> > On Sun, May 26, 2019 at 4:06 AM Michael Chirico
> > wrote:
> > >
extMethod(.Generic), oldClass(x)) # <- restores 'IDate' class
So we can fix our bug by defining a [<- class; the question that I still
don't see answered in documentation or source code is, why/where is [<-
called, exactly?
Mike C
On Sun, May 26, 2019 at 1:16 PM Michael Chirico
Debugging this issue:
https://github.com/Rdatatable/data.table/issues/2008
We have custom class 'IDate' which inherits from 'Date' (it just forces
integer storage for efficiency, hence, I).
The concatenation done by rbind, however, breaks this and returns a double:
library(data.table)
DF = data
it is the first line looks like it's commented out
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
;>>> Martin Maechler
> >>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes:
>
> >>>>> Michael Chirico
> >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes:
>
> >> Identified as root cause of a bug in data.table:
>
So, what is the correct output of strtoi("", base = 2L)? Is the
cross-platform inconsistency to be expected/documentable?
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Indeed! Sorry, I need more sleep, should have known better. Thanks!
On Fri, Dec 7, 2018 at 6:22 PM Martin Maechler
wrote:
> >>>>> Michael Chirico
> >>>>> on Fri, 7 Dec 2018 10:36:37 +0800 writes:
>
> > This link is referenced in ?timezones a
This link is referenced in ?timezones and appears to have been
moved/removed. Is there a replacement?
http://www.twinsun.com/tz/tz-link.htm
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/
ase query; the error message will first
reproduce the entirety of the query and then give some diagnostic
information. Queries can get quite long, so it stands to reason that this
8190-length limit might be binding.
Thanks,
Michael Chirico
[[alternative HTML version deleted]]
t(DF)$y)
# [1] "numeric"
is.object(na.omit(DF)$y)
# [1] FALSE
That is, similarly presented with a classed object, na.omit strips the
class *and* the OBJECT attribute.
Thanks,
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
.
On Mar 2, 2018 1:52 AM, "Martin Maechler"
wrote:
> >>>>> Michael Chirico
> >>>>> on Tue, 27 Feb 2018 20:18:34 +0800 writes:
>
> Slightly amended 'Subject': (unimportant mistake: a dgeMatrix is *not*
> sparse)
>
> MM: m
t a minimum, the error message needs to be repaired; do we also want to
attempt as.numeric(normx) (which I believe would have allowed scale to work
in this case)?
(I'm aware that there's some import issues in lars, as the offending line
to create normx *should* work, as is.numeric(sqrt(
https://github.com/Rdatatable/data.table/issues/2171
The fix was easy, it's just surprising to see the behavior change almost on
a whim. Just wanted to point it out in case this is unknown behavior, but
Evan seems to have found this as well.
On Tue, May 23, 2017 at 12:00 PM, Michael Ch
gt;> to do with the vectors longer than 1 and their positioning vis-a-vis the
>> format string.) The safest thing is just to pass the right type. In this
>> case, sprintf('%d', as.integer(NA_real_)) works.
>>
>> Best,
>>
>> Evan
>>
>> On Fri,
is correct, but if it works for other numeric input,
why doesn't R just coerce NA_real_ to NA_integer_?
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
de superscripts, respectively.
With this implemented, converting ord_dates to a Date or POSIXct would be
as simple as:
as.Date(ord_dates, format = "%B %d%o, %Y")
Is there something on the C level preventing this from happening?
Michael Chirico
[[alternative HTML version dele
origin <- as.Date("-01-01", ...) - 1
setNames(as.Date(origin, ...) + x, NULL)
}
as.Date.POSIXct <- function (x, tz = "UTC", ...)
{
if (tz == "UTC") {
z <- floor(unclass(x)/86400)
attr(z
74 matches
Mail list logo
