but note that you will have to document it even if it is a function
imported from another package... Perhaps help() should be intelligent
enough to link the documentation of `FUN` from package A for package B
when B imports `FUN` from A, and exports it in B's NAMESPACE. The
package name of A may be
On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer wrote:
> Export filter in the NAMESPACE file *without copying it* in the R source
> code.
>
>
Ah, it works! Thank you!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
On Mon, Nov 11, 2013 at 6:20 PM, Simon Urbanek
wrote:
>
> It’s a limitation of the Java runtime - you cannot fork a JVM. This is true
> for most libraries that use long-lived threads or any kind if UI (see the
> warnings in mcfork).
Is there some way to reset or restart the JVM within the fork?
Export filter in the NAMESPACE file *without copying it* in the R source code.
From: Winston Chang [winstoncha...@gmail.com]
Sent: 19 June 2014 21:28
To: Martyn Plummer
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
Oh, I forgot to
Oh, I forgot to mention I tried a few other variations:
=
Re-export dplyr::filter:
filter <- dplyr::filter
NAMESPACE has:
S3method(filter,test)
export(filter)
importFrom(dplyr,filter)
Then the filter.test method from s3methodtest doesn't seem to get
registered properly:
When you provide a method for a generic function imported from another
package then the generic must be on the search path. Otherwise if a user
types "filter" the dispatch to "filter.test" will never occur.
What is happening here is worse because "filter" is a non-generic
function in the stats pac
Thanks Joris, it makes sense now, though the doc is a bit misleading.
On Thu, Jun 19, 2014 at 3:22 PM, Joris Meys wrote:
> Hi Karl,
>
> that is expected. The moment you close a connection, it is destroyed as well
> (see ?close). A destroyed connection cannot be tested. In fact, I've used
> isOpen
Hi Karl,
that is expected. The moment you close a connection, it is destroyed as
well (see ?close). A destroyed connection cannot be tested. In fact, I've
used isOpen() only in combination with the argument rw.
> con <- file("clipboard",open="r")
> isOpen(con,"write")
[1] FALSE
cheers
On Thu,
Hello,
>From the doc, it says:
"isOpen returns a logical value, whether the connection is currently open."
But actually it seems to die on closed connections:
> con <- file()
> isOpen(con)
[1] TRUE
> close(con)
> isOpen(con)
Error in isOpen(con) : invalid connection
Is it expected ?
Tested on R
Hi Martyn,
> It isn't hard to set up Rtools on Windows and you only need to do it
> once. Then you build a binary package on your development system to
> distribute to your users.
Yes, but since I am working on Linux, it is slightly more steps
involved in order to generate a windows binary (even
10 matches
Mail list logo
