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
60 matches
Mail list logo