I guess we could make it do the equivalent of do.call(order, df).
On Mon, May 18, 2020 at 8:32 AM Rui Barradas wrote:
>
> Hello,
>
> There is a result with lists? I am getting
>
>
> order(list(letters, 1:26))
> #Error in order(list(letters, 1:26)) :
> # unimplemented type 'list' in 'orderVector1
ing again or do you
> foresee a lot of changes coming in the 4.* series?
>
> On Tue, Feb 25, 2020 at 3:39 PM Michael Lawrence via R-devel
> wrote:
>>
>> This seems to work as expected (returning "hi!") in R-devel, but there
>> have been so many destabilizin
This seems to work as expected (returning "hi!") in R-devel, but there
have been so many destabilizing changes to methods that it would be
tough to port this to release. Probably should just wait for 4.0.
Michael
On Tue, Feb 18, 2020 at 8:00 PM Michael Lawrence wrote:
>
> Thanks, I'll look into
Thanks, I'll look into it.
On Tue, Feb 18, 2020 at 8:32 AM Ezra Tucker wrote:
>
> Hi Robert,
>
> This looks like a bug to me (tested in R 3.6.2 on Windows), f(new("a"))
> should return "hi!". I'll add that this DOES work properly in 3.6.1
> which leads me to suspect this could be due to the subtl
Since substitute() is implemented in C, you could look at its implementation.
On Fri, Jan 24, 2020 at 1:09 AM Daniel Cegiełka
wrote:
>
>
> (earlier I sent it as html by mistake).
>
> Hi,
>
> How can I get from C an object name used as a function argument? I
> have sample code in C that gives me a
I've been working on this and will hopefully get a fix checked in today.
On Wed, Nov 27, 2019 at 3:53 AM Martin Maechler
wrote:
>
> > Ezra Tucker
> > on Mon, 11 Nov 2019 21:47:41 + writes:
>
> > Hi all,
> >
> > I came across an issue in using the Matrix package which made it that
If your goal is to perform multithreaded computations, why not perform
all necessary interactions with R upfront and then compute only on
primitives? It would help for us to understand your use case.
On Fri, Nov 1, 2019 at 4:26 AM Jan Gorecki wrote:
>
> Dear R developers,
>
> Motivated by discuss
Yes, any object of a class that derives from a basic type, like an
atomic vector for example, will be of the basic SEXP type, with the S4
bit set. This means that a class can extend "integer" and objects of
that class can be treated as any ordinary integer vector. S4SXP is
only for objects that do
Thanks for this interesting suggestion, Morgan. While there is no strict
criteria for base R inclusion, one criterion relevant in this case is that
the usefulness of a feature be proven in the package space first.
Michael
On Fri, Oct 11, 2019 at 5:19 AM Morgan Morgan
wrote:
> On Fri, 11 Oct 20
Thanks. The error message will now say:
undefined exports: class inla
Will check-in after running more tests.
On Fri, Sep 6, 2019 at 10:19 AM Thierry Onkelinx
wrote:
> Dear Michael,
>
> my package has setOldClass("inla") and the NAMESPACE
> contains exportClasses(inla) and importFrom(INLA, in
The core of Bioconductor and the methods package itself once took
advantage of this "feature" to avoid unnecessary duplication. Since
the introduction of shallow copying, those abuses have been removed.
Note that these assignment functions always have issues due to
optimizations that assume <-() i
Just to clarify, your package is exporting a class that is not
defined? Or is it exporting a class that is defined by a dependency
and then masked by setOldClass()? A simple reproducible example would
help.
On Fri, Sep 6, 2019 at 7:48 AM Thierry Onkelinx via R-devel
wrote:
>
> Dear all,
>
> Today
After some discussion within R core, we decided that a "nomatch"
argument on regmatches() may be a good initial step. We might add a
new function later that combines the regexpr() and regmatches() steps.
The gregexpr() and regexec() inputs are both lists so it's not clear
whether a "nomatch" value
Just started thinking about this. The name of regmatches() suggests
that it will only extract the matches but not return anything for the
non-matches. We might need another function that returns a value for
non-matches. Perhaps the value should be the empty string for
non-matches and NA for matches
I'd be happy to entertain patches or at least more specific
suggestions to improve strextract() and strcapture(). I hadn't
exported strextract(), because I wasn't quite sure how it should
behave. This feedback should be helpful.
Thanks,
Michael
On Thu, Aug 29, 2019 at 2:20 PM Cyclic Group Z_1 via
Hi Kylie,
As an alternative in the short term, you could consider deriving from
S4Vector's List class, implementing the getListElement() method to
lazily create the objects.
Michael
On Tue, Jul 23, 2019 at 9:09 AM Bemis, Kylie wrote:
>
> Hello,
>
> I was wondering if there were any plans for AL
I'm unable to reproduce this with R 3.6.1. Which version are you
using? Is this a fresh session?
On Mon, Jul 15, 2019 at 3:25 AM Ghiggi Gionata wrote:
>
> Hi all !
>
> I noticed a strange behaviour of the function `class<-` when a class-specific
> '[[.' method is defined.
>
> Here below a reprod
A generic for displaying an object in a cell would be a reasonable
solution for this particular problem. However, as soon as you start
treating these objects as data (like putting them into a matrix),
you're likely going to want vectorized operations over them, which
means formalized vector and mat
And it is used profusely by the methods package.
On Thu, Mar 28, 2019 at 4:53 AM Gábor Csárdi wrote:
> On Thu, Mar 28, 2019 at 11:43 AM Martin Maechler
> wrote:
> [...]
> >
> > Indeed... and as I mentioned I had never actively noticed the
> > use of topenv() at all...
>
> FWIW topenv() is used
Gabe described my main concern. Specifying a coercion function asserts that
the data (1) were what was expected and (2) were converted into what was
expected. Allowing a coercer to delegate to a "next method" is a good idea,
but keep in mind that any function that did that would not confer the
bene
This has some nice properties:
1) It self-documents the input expectations in a similar manner to
colClasses.
2) The implementation could eventually "push down" the coercion, e.g.,
calling it on each chunk of an iterative read operation.
The implementation needs work though, and I'm not convinced
Please file a bug on bugzilla so we can discuss this further.
On Tue, Mar 26, 2019 at 11:53 AM Kurt Van Dijck <
dev.k...@vandijck-laurijssen.be> wrote:
> Hello,
>
> I want to find out if this patch is ok or not, and if not, what should
> change.
>
> Kind regards,
> Kurt
>
> __
Agreed but I'm not sure we want users accessing documentation with those
types of aliases. One option is the method?foo("numeric") syntax.
On Thu, Mar 21, 2019 at 9:52 PM Pages, Herve wrote:
> Fine with me as long as eliminating the inconveniences associated with it
> can be put on the roadmap.
If we started over, I'd try to avoid this sort of complexity, but "ANY"
truncation has been happening since at least 2003.
> matchSignature(c("numeric", "ANY"), foo)
x
"numeric"
So I'm not sure we want to mess with it.
Michael
On Thu, Mar 21, 2019 at 8:14 PM Pages, Herve wrote:
> Hi M
This is due to the intentional truncation of ANY suffixes from method
signatures. I've hacked selectMethod() to be robust to that and will commit
soon. Thanks for the report.
Michael
On Thu, Mar 14, 2019 at 9:32 AM Pages, Herve wrote:
> Here is an example:
>
> setGeneric("foo", function(x, y)
Thanks for the report. There is a comment from 2001 in the header for
reconcilePropertiesAndPrototype() that states:
"The prototype may imply slots not in the properties list. It is not
required that the extends classes be define at this time. Should it
be?"
But somewhere in the mid 2000's, I t
26 matches
Mail list logo
