Could I trouble you to look at banocc 1.5.2 that I pushed: it has a
warning-
Is that ok or can we leave it like that to be released?
On Thu, Oct 18, 2018 at 7:21 AM Turaga, Nitesh <
nitesh.tur...@roswellpark.org> wrote:
> After a push is made it can take up to 48 hours for it to appear on the
>
No, sorry, it was also a problem with `Matrix` package. I was too quick in
checking it. I think upgrading my devtools and roxygen2 may have fixed it.
Thanks for helping me pinpoint where the problem was.
> On Oct 19, 2018, at 12:37 PM, Elizabeth Purdom
> wrote:
>
> Thanks Martin. And of
Thanks Martin. And of course you’re right! The errors I was getting came from
devtools functions— I didn’t think to check it outside of there and assumed it
was a general problem with my package setup. But it's actually a problem in
devtools.
When I set up your example (thanks!) with Roxygen
Hello, all!
The OrgDbs and TxDbs for Biocondcutor 3.8 have been built and will propagate to
Bioconductor 3.8 within a day. The following packages are available:
GO.db_3.7.0.tar.gz
PFAM.db_3.7.0.tar.gz
org.Ag.eg.db_3.7.0.tar.gz
org.At.tair.db_3.7.0.tar.gz
org.Bt.eg.db_3.7.0.tar.gz
An error involving incorrect UniProt IPIs was detected in the most recent db0
packages. This error has been corrected and the newer 3.7.1 db0s are now
available. If you are contributing an annotation package and rely on UniProt
IPIs, we would recommend that you rebuild your package. We ask that
That doesn't sound correct. I just created a simple package with
DESCRIPTION
Package: PkgA
Title: What the Package Does (one line, title case)
Version: 0.0.0.9000
Authors@R: person("First", "Last", email = "first.l...@example.com", role =
c("aut", "cre"))
Description: What the package does
Martin and Kevin,
Perhaps a variant of methods which more directly addresses the use-case
Kevin mentions might be in order?
I am happy to prepare a patch which implements a methodsForObj function
(name very much negotiable), or a third obj argument to methods which takes
the actual object and
I think this would be a good change. I think most users use the
'methods(class = <...>)' function to answer the question, "what
methods can I call on objects with these classes?", and in that
context I think it would be sensible for the function to accept more
than one class.
Kevin
On Wed, Oct
--- Begin Message ---
I do use subclassing as you suggest. In my base package I have an az_resource
class that represents any generic Azure resource. Eg in the VM package, I
extend it to obtain az_vm_resource; in the storage package I extend it to
obtain az_storage; and so on. In addition to
Sorry, I copied the wrong code from phylobase (I copied the setMethod code).
Their setGeneric calls are in the following format:
setGeneric("nNodes", function(x) {
standardGeneric("nNodes")
})
> On Oct 19, 2018, at 9:07 AM, Elizabeth Purdom
> wrote:
>
> Hello,
>
> In my package
Hello,
In my package (`clusterExperiment`) I want to extend a S4 method from a package
`phylobase` for my class. However, in the phylobase package, all of the
`setGeneric` calls are in the form of
setMethod("nTips", signature(x="phylo"),
function(x) {
Ntip(x)
})
Namely, they use braces
> AzureRMR: the "base" package, provides a number of R6 classes
> AzureVM: a "child" package that extends classes from AzureRMR with extra
> functionality related to virtual machines
> AzureStor: another child package that extends classes from AzureRMR, this
> time for storage accounts
> Etc.
>
--- Begin Message ---
I'm writing a family of packages for talking to Azure (Microsoft's cloud
service) from R. The basic architecture is
AzureRMR: the "base" package, provides a number of R6 classes
AzureVM: a "child" package that extends classes from AzureRMR with extra
functionality related
13 matches
Mail list logo
