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(
.
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(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
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]]
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/
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
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
;>>> 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:
>
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
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
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
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:
> > >
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 は、自由なソフトウェアであり、「完全に無保証」です。
一定の条件に従えば、自由にこれを再配布することができます。
配布条件の詳細
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,
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
#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
;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
& 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
[[
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
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
> >>>>>
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
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
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
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
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
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
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,
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
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
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]]
__
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 .
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
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
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'), '
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
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
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
>
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
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 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
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
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
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
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
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
> |
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
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
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
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
/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):
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
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
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:
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
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
row.names = NULL, optional = FALSE, ...)
# ...
+ 29 other methods define 11 other arguments. See methods(as.data.frame).
Mike C
On Sun, Jun 8, 2025 at 3:57 PM Joshua Ulrich wrote:
>
> Hi Mike,
>
> On Fri, Jun 6, 2025 at 1:59 PM Michael Chirico
> wrote:
> >
> > There
intended
> that
>options() is the only exception to the rule.
>
> * More harmonious would be to implement the feature ("give me more
> information about S3 methods") as an option (disabled by default) of
>utils::.S3methods if not as a n
n my computer with R-devel (2025-06-08 r88288), the expressions
> below the "Not run:" on ? examples raise errors.
>
>
> On Mon, 9 Jun 2025 at 08:07, Michael Chirico
> wrote:
>>
>> Thanks Josh,
>>
>> With fresh eyes, it's definitely information
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
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
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
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
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
/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
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
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
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("`",
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
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
("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
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
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:
>
> >
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
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
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
perl = FALSE) :
> invalid regular expression '(invalid', reason 'Missing ')''
> In addition: Warning message:
> In grepl("(invalid", "subject", perl = FALSE) :
> TRE pattern compilation error 'Missing ')''
79 matches
Mail list logo
