Displaying 20 results from an estimated 4000 matches similar to: "exists, get and get0 accept silently inputs of length > 1"
2020 Nov 17
2
[External] exists, get and get0 accept silently inputs of length > 1
I noticed the recent commit to R-dev (r79434). Is this wise? I've
often used get() in constructions like
for (j in ls()) if (is.numeric(x <- get(j))) ...
(and often interactively, rather than in a package)
Am I to understand that get(j) will now be equivalent to `j` even if j
is a string referring putatively to another object?
On Sat, 14 Nov 2020 at 01:34, <luke-tierney at
2020 Nov 17
1
[External] exists, get and get0 accept silently inputs of length > 1
Come on, folks. There is no NSE involved in calls to get(): it's
standard evaluation all the way into the C code. Prior to the change a
first argument that is anything other than a character vector would
produce an error. After the change, passing in a symbol will do the
obvious thing. Code that worked previously without error (i.e. called
get() with string values) will continue to work
2020 Nov 13
0
[External] exists, get and get0 accept silently inputs of length > 1
Worth looking into. It would probably cause some check failures, so
would probably be a good idea to run a check across BIOC/CRAN. At the
same time it would be worth allowing name objects (type "symbol") so
thee don't have to be converted to character for the call and then
back to names internally for the environment lookup.
Best,
luke
On Fri, 13 Nov 2020, Antoine Fabri wrote:
2020 Nov 17
0
[External] exists, get and get0 accept silently inputs of length > 1
Hi all,
I have used variable values in get() as well, and including, I think, in
package code (though pretty infrequently).
Perhaps a character.only argument similar to library?
~G
On Mon, Nov 16, 2020 at 5:31 PM Hugh Parsonage <hugh.parsonage at gmail.com>
wrote:
> I noticed the recent commit to R-dev (r79434). Is this wise? I've
> often used get() in constructions like
>
2015 Jan 09
2
RFC: getifexists() {was [Bug 16065] "exists" ...}
>>>>> Martin Maechler <maechler at stat.math.ethz.ch>
>>>>> on Fri, 9 Jan 2015 14:00:38 +0100 writes:
>>>>> Michael Lawrence <lawrence.michael at gene.com>
>>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes:
>> On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote:
>>> On Thu, 8
2020 Aug 28
2
utils::isS3stdGeneric chokes on primitives and identity
Trace adds something to the body of the function, so it does make sense
that it doesn't. Whether traced functions still technically meet the
definition of standard s3 generic or not is, I suppose, up for debate, but
I would say that they should, I think.
As before, if desired I can work on a patch for this if desired, or someone
on R-core can just take care of it if that is easier.
Best,
~G
2020 Aug 26
2
trace creates object in base namespace if called on function argument
Please note that this is documented in ?trace. "fun" is matched to what,
it is a _name_ of the function to be traced, which is traced in the
top-level environment. I don't know why it was designed this way, but it
is documented in detail, and hence the expected behavior.
Debugging is often, and also in R, implemented in the core. Tracing is
implemented on top without specific
2020 Aug 20
2
utils::isS3stdGeneric chokes on primitives and identity
>>>>> Gabriel Becker writes:
> I added that so I can look at the proposed fix and put it or something
> similar in bugzilla for review final review.
> Apologies for the oversight.
Fixed now with
- while(as.character(bdexpr[[1L]]) == "{")
+ while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{"))
(the suggested fix does not work on
2020 Aug 25
2
trace creates object in base namespace if called on function argument
Dear R-devel,
I don't think this is expected :
foo <- function() "hello"
trace2 <- function(fun) trace(fun, quote(print("!!!")))
base::fun
# Object with tracing code, class "functionWithTrace"
# Original definition:
# function() "hello"
#
# ## (to see the tracing code, look at body(object))
`untrace()` has the same behavior.
This is
2015 Jan 08
2
RFC: getifexists() {was [Bug 16065] "exists" ...}
On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote:
> On Thu, 8 Jan 2015, Michael Lawrence wrote:
>
> If we do add an argument to get(), then it should be named consistently
>> with the ifnotfound argument of mget(). As mentioned, the possibility of a
>> NULL value is problematic. One solution is a sentinel value that indicates
>> an unbound value
2020 Sep 02
3
sys.call() 's srcref doesn't match the language
Dear R-devel,
I found this behavior disturbing, if `1 + f()` is called, `sys.call()`
called inside of `f` will return a quoted `f()` with a "srcref" that prints
"1 + f()".
I don't know which one is good but I don't think they can be correct at the
same time.
Here's a reproducible example:
f <- function(){
sc <- sys.call()
print(sc)
attr(sc,
2020 Aug 19
2
utils::isS3stdGeneric chokes on primitives and identity
Dear R-devel,
utils::isS3stdGeneric tries to subset the body of the function it's fed,
primitives don't like that because they don't have a body, identity doesn't
like it either because it's body is a symbol.
According to the doc, any function is a legal input.
See below:
identity
#> function (x)
#> x
#> <bytecode: 0x0000000013d6da28>
#> <environment:
2023 Jul 21
1
tools::parseLatex() crashes on "\\verb{}"
Do I understand correctly that we don't want Rd files to be valid latex ?
This seems odd to me.
I see that `tools::parse_Rd()` doesn't like `\verb!foo!` so maybe roxygen2
is actually doing the right thing (as opposed to just trying to) ?
`parse_Rd() ` is probably what I need indeed, for some reason I hadn't
found it, so that should fix my own issue here thanks a lot.
Le ven. 21 juil.
2023 Mar 03
2
transform.data.frame() ignores unnamed arguments when no named argument is provided
>>>>> Gabriel Becker
>>>>> on Thu, 2 Mar 2023 14:37:18 -0800 writes:
> On Thu, Mar 2, 2023 at 2:02?PM Antoine Fabri
> <antoine.fabri at gmail.com> wrote:
>> Thanks and good point about unspecified behavior. The way
>> it behaves now (when it doesn't ignore) is more
>> consistent with data.frame() though so I
2019 Jul 29
5
install packages with missing pkg argument
Dear all,
The help for `?install.packages` decribes, in the `pkg` argument
description :
> If this is missing, a listbox of available packages is presented where
possible in an interactive R session.
In fact running it with a missing argument triggers an error :
install.packages()
> Error in install.packages : argument "pkgs" is missing, with no default
What however
2023 Mar 04
1
transform.data.frame() ignores unnamed arguments when no named argument is provided
I am probably mistaken but it looks to me like the design of much of the data.frame infrastructure not only does not insist you give columns names, but even has all kinds of options such as check.names and fix.empty.names
https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/data.frame
During the lifetime of a column, it can get removed, renamed, transfomed in many ways and so on. A
2019 Oct 05
6
should base R have a piping operator ?
Dear R-devel,
The most popular piping operator sits in the package `magrittr` and is used
by a huge amount of users, and imported /reexported by more and more
packages too.
Many workflows don't even make much sense without pipes nowadays, so the
examples in the doc will use pipes, as do the README, vignettes etc. I
believe base R could have a piping operator so packages can use a pipe in
2019 Jul 13
2
Mitigating Stalls Caused by Call Deparse on Error
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)? :
??? ##?? cannot coerce type 'builtin' to vector of type 'character'
??? ##
2023 Jul 21
1
tools::parseLatex() crashes on "\\verb{}"
Surprisingly this invalid latex syntax is still formatted "right" in the
html output.
On a closer look it seems like roxygen2 introduces those, when using
markdown backtick quoting, if the quoted content is not syntactic. For
instance:
#' `c(c(1)`
#' `c(c(1))`
Will convert the first line to `\verb{c(c(1)}` and the second to
`\code{c(c(1))}`.
I've opened a ticket there FYI:
2023 Jul 21
1
tools::parseLatex() crashes on "\\verb{}"
? Fri, 21 Jul 2023 15:14:09 +0200
Antoine Fabri <antoine.fabri at gmail.com> ?????:
> On a closer look it seems like roxygen2 introduces those, when using
> markdown backtick quoting, if the quoted content is not syntactic. For
> instance:
>
> #' `c(c(1)`
> #' `c(c(1))`
>
> Will convert the first line to `\verb{c(c(1)}` and the second to
>