Thanks Abby and Martin,
In every company I worked using R - 3 in total - there was at least
one (up to ~10) processes designed (dev and implemented) to depend on
current package naming scheme, having underscore as separator of
package name and its version. From my experience I believe this is a
(v
Hello,
deparse(structure(as.raw(1), .Names=c('a'))) gives "as.raw(c(a = 0x01))"
in 3.5.1 and later (actually tested on 3.5.1, 3.6.1 and devel). If you
execute as.raw(c(a = 0x01)), you get a raw vector without the names.
If the stripping of the names is the correct behavior of as.raw (I would
I've heard the arguments against dots in names many times. The t.test and
data.frame examples have been repeated so often that it has become accepted
as gospel. In my experience, evidence of any actual problems is fairly
limited (almost non-existent). I've been happily using dots in function
name
Thanks for the suggestions, everyone.
Is it not a pressing issue requiring alternatives, since the ‘matter_list’
object already behaves like a list, and I am just looking for a way to present
a native R list (VECSXP) when a regular list is required.
In this case (in my typical use case), the ‘m
Using R_tryWrap() at the C-level works perfectly and does what I need. Thanks,
Gabe!
Yes, my reference count is maxed (I assume) because I am using
MARK_NOT_MUTABLE().
Which makes me think I may want to return a wrapped matter/ALTREP object by
default, so the user can set the names() and dim()
I was initially pretty shocked by the result in this question:
https://stackoverflow.com/questions/57527434/when-do-i-need-parentheses-around-an-if-statement-to-control-the-sequence-of-a-f
Briefly, the following returns 0, not 3 as might be expected:
if (TRUE) {
0
} else {
2
} + 3
At fir
On 16/08/2019 12:36 p.m., Hugh Parsonage wrote:
I was initially pretty shocked by the result in this question:
https://stackoverflow.com/questions/57527434/when-do-i-need-parentheses-around-an-if-statement-to-control-the-sequence-of-a-f
Briefly, the following returns 0, not 3 as might be expecte
Using strcapture seems like a great workaround for use cases of this kind, at
least in base R. I agree as well that filling with NA for regmatches(...,
gregexpr(...)) makes less sense, given the outputs are lists and thus are
retained in the list. Also, I suppose in the meantime the stringr pac
