You only need ::: from outside the package.
Hadley
On Thu, Aug 29, 2013 at 2:37 PM, Jonathan Greenberg wrote:
> Ah, sorry -- I thought if I try to call a "hidden" function that has
> not be exported (and, I thought, if it is exported, it needs to be
> documented?), I have to call it via ::: ?
>
>
Ah, sorry -- I thought if I try to call a "hidden" function that has
not be exported (and, I thought, if it is exported, it needs to be
documented?), I have to call it via ::: ?
--j
On Thu, Aug 29, 2013 at 2:33 PM, Hadley Wickham wrote:
> You only need ::: if you're calling it from another packa
You only need ::: if you're calling it from another package (and see
the lengthly recent discussion on that issue). The key distinction is
whether the function is exported or not: You must document any
function that you export. You don't have to document any function you
don't export.
Hadley
On
I had a similar question awhile ago. Basically, my understanding is
if it is a function, it needs to be documented UNLESS you are calling
it via :::
--j
On Thu, Aug 29, 2013 at 1:11 PM, Sana Wajid wrote:
> Thank you all, I appreciate your responses. Just a quick follow up
> question: couple of
Thank you all, I appreciate your responses. Just a quick follow up
question: couple of my functions are "background" or "behind the scenes"
functions. Do these have to be documented in the manual as well?
On Wed, Aug 28, 2013 at 5:19 PM, Geoff Jentry wrote:
> On Wed, 28 Aug 2013, Ben Bolker wrot
On Wed, 28 Aug 2013, Ben Bolker wrote:
It may be suboptimal/there may be better ways, but what I would do in
your situation would be to save the real twitteR results to a .Rdata
file (e.g. put it in inst/vignetteData) and then 'fake' the twitter
call: add a non-eval'd but echo'd chunk that app
Geoff Jentry hexdump.org> writes:
>
> On Wed, 28 Aug 2013, Dirk Eddelbuettel wrote:
> > The change to preferring vignettes/ over inst/doc/ is just one of many;
> there
> > is also an ongoing preference for vignettes that fully reproducible from
> > source. Which may eventually put an end to non
On Wed, 28 Aug 2013, Dirk Eddelbuettel wrote:
The change to preferring vignettes/ over inst/doc/ is just one of many; there
is also an ongoing preference for vignettes that fully reproducible from
source. Which may eventually put an end to non-Rnw / non-(la)tex vignettes.
I'm currently stymied
On 28 August 2013 at 11:18, Duncan Murdoch wrote:
| On 28/08/2013 10:59 AM, Dirk Eddelbuettel wrote:
| > On 28 August 2013 at 09:44, Hadley Wickham wrote:
| > | >> Related rant: I really wish we had "CHANGES" file, or a section in the
| > | >> manuals. It is virtually impossible to look at a curre
On 28/08/2013 10:59 AM, Dirk Eddelbuettel wrote:
On 28 August 2013 at 09:44, Hadley Wickham wrote:
| >> Related rant: I really wish we had "CHANGES" file, or a section in the
| >> manuals. It is virtually impossible to look at a current "Writing R
| >> Extensions" manual, and a previous one, in o
On 28 August 2013 at 09:44, Hadley Wickham wrote:
| >> Related rant: I really wish we had "CHANGES" file, or a section in the
| >> manuals. It is virtually impossible to look at a current "Writing R
| >> Extensions" manual, and a previous one, in order to get a succinct view of
| >> what changed.
>> Related rant: I really wish we had "CHANGES" file, or a section in the
>> manuals. It is virtually impossible to look at a current "Writing R
>> Extensions" manual, and a previous one, in order to get a succinct view of
>> what changed. Having to diff the NEWS files, or glancing at commit logs
On 28/08/2013 10:26 AM, Dirk Eddelbuettel wrote:
On 28 August 2013 at 09:01, Kevin Wright wrote:
| Before knitr became an accepted engine for vignettes, I had a
| knitr-generated vignette that I included in a package. It could just as
| easily have been a Word file saved as a pdf. There was so
On 28 August 2013 at 09:01, Kevin Wright wrote:
| Before knitr became an accepted engine for vignettes, I had a
| knitr-generated vignette that I included in a package. It could just as
| easily have been a Word file saved as a pdf. There was some trick to doing
| this (which I have forgotten).
> As long as your package passes R CMD check --as-cran on the
> development version of R, CRAN will be happy. They do not generally
> read your source code, and CRAN does not certify that your package is
> useful or even correct - so you don't need to worry about what your
> package does.
>
> I, f
> 1. My functions are very basic. For example, getRoot gets the root of the
> current tree (APE phylo object) and getAncestor gets the ancestor to the
> current node:
>
> getRoot <- function(cur_Tree){
> return(length(cur_Tree$tip.label)+1)
> }
>
> getAncestor <- function(cur_Node, cur_Tree){
>
Hi,
I'm a newbie to R package submission. I've written a program using basic
functions inside R to manipulate phylogeny tree data. I've relied on the
APE package. After almost year of working on it, it's time for me to submit
the package and I have very little time to rewrite it as S3/4 style unle
17 matches
Mail list logo
