Hi,
On Mi, 2014-08-27 at 20:48 -0400, Sean Davis wrote:
...
Several packages in Bioconductor supply bug reporting links, so you could
look into those that do.
E.g. : https://github.com/seandavi/GEOquery/blob/master/DESCRIPTION
Yours,
Steffen (Who just looked that up himself...)
--
IPB
Sorry it took so long. Fixed in S4Vectors 0.1.3. Surprisingly, we were
missing a replaceROWs,matrix method.
On Tue, Aug 26, 2014 at 5:13 PM, Peter Hickey hic...@wehi.edu.au wrote:
Hi Michael,
Thanks for your patience. Here is a self-contained example with comments
Thanks, Michael. Do you think there's a general use case for a replaceROWs,
NULL method or shall I just specify that in my package? I require it because
the slot is matrixOrNULL via a setClassUnion but I don't know how common that
is amongst other BioC devels.
setMethod(replaceROWS,
And if, like me, you always forget which of Depends and Imports is the
one you are supposed to be using, the mnemonic device is DEPends is
DEPrecated[1], IMPorts is IMPortant.
Barry
[1] kinda.
On Thu, Aug 28, 2014 at 4:33 AM, Gavin Simpson ucfa...@gmail.com wrote:
On Aug 27, 2014 5:24 PM,
peter dalgaard pda...@gmail.com
on Wed, 27 Aug 2014 21:09:47 +0200 writes:
On 27 Aug 2014, at 16:48 , Hadley Wickham h.wick...@gmail.com wrote:
I think the right answer _is_ to export the lazy data; the question is
how to do it. There's nothing particularly strange about
On 08/27/2014 08:33 PM, Gavin Simpson wrote:
On Aug 27, 2014 5:24 PM, Hadley Wickham
snip /
I'd say: Depends is a historical artefact from ye old days before
package namespaces. Apart from depending on a specific version of R,
you should basically never use depends. (The one exception is, as
I'd say: Depends is a historical artefact from ye old days before
package namespaces. Apart from depending on a specific version of R,
you should basically never use depends. (The one exception is, as
mentioned in R-exts, if you're writing something like latticeExtras
that doesn't make sense
On 08/28/2014 05:52 AM, Hadley Wickham wrote:
I'd say: Depends is a historical artefact from ye old days before
package namespaces. Apart from depending on a specific version of R,
you should basically never use depends. (The one exception is, as
mentioned in R-exts, if you're writing something
Here is one rationale for the change, which was useful for my understanding
This arises in the survival package in the survexp function:
survexp - function(formula, data, weights, subset, na.action,
ratetable=survexp.us)
The argument has been changed to survival::survexp.us, soon to be
On Aug 27, 2014, at 6:01 PM, Gavin Simpson ucfa...@gmail.com wrote:
On 27 August 2014 15:24, Hadley Wickham h.wick...@gmail.com wrote:
Is that the cause of these NOTEs? Is the expectation that if I am using a
function from a package, even a package that I have in Depends:, that I
have to
This is a nice explanation of the Imports/Depends distinction. It
ought to go into the Extensions ref manual imho.
Cheers,
Bert
Bert Gunter
Genentech Nonclinical Biostatistics
(650) 467-7374
Data is not information. Information is not knowledge. And knowledge
is certainly not wisdom.
Clifford
Hi,
I second Bert's comment. I would like to go even farther and suggest that it
would be really useful if one of the R gurus (like Simon) wrote a relatively
non-technical article in the R journal on this topic of
Depends/Imports/Suggested. Someone like myself would benefit immensely.
Thank
From a developers point of view, these days a less ambiguous name for
'Depends' would be 'Attaches'.
...or maybe even 'ImportsAndAttaches' with 'ImportsOnly' (for 'Imports').
I think Simon phrased it very well, and as others already pointed out,
having one package attaching additional ones
I fully agree.
This is how I have come to understand Depends vs Imports and why I
currently will not be removing vegan from Depends for my analogue package.
This is also why I was pushing back against the notion that was voiced
early in this thread that *nothing* should be in Depends.
Cheers
G
Gavin,
I admit to not knowing the details of your package, but do users commonly
need to use symbols from other package *in calls to functions exported by
your package*? If so, you're in the situation Martin (Morgan) described,
which is one I think everyone agrees Depends is appropriate for.
If
Gabriel,
That is not my understanding of this at all. I could hide the fact that I
was using vegan under the hood, supplying methods for its generics and by
exporting the generic I imported from vegan, etc. But you are missing the
point that I see users of my package, because I envisioned close
Gavin,
I don't claim to be the arbiter of good package design. The following are
my opinions, along with the reasons I hold them.
If you are also importing vegan, which I think everyone agreed needs to
happen, the only thing putting vegan in Depends does is attach the package.
This is something
Yes, Depends certainly has a role. The ability of one package to
automatically provide all the facilities of another package to the
user is important. There are many situations where the functionality
you want to provide to the user is split among multiple packages.
For example,
1. xts uses zoo
(Please correct me if I'm wrong. I thought I mostly understood this,
finally, but I've made the mistake of thinking I understood something
too many times before.)
On 08/28/2014 10:39 AM, Simon Urbanek wrote:
On Aug 27, 2014, at 6:01 PM, Gavin Simpson ucfa...@gmail.com
wrote:
On 27 August
19 matches
Mail list logo
