On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
- to recommend that pkg.package contain general information about
the package, and
On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
- to recommend that pkg.package contain general information about
the package,
On 6/8/05, Torsten Hothorn [EMAIL PROTECTED] wrote:
On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
- to recommend
A J Rossini writes:
On 6/8/05, Torsten Hothorn [EMAIL PROTECTED] wrote:
On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and
Henrik Bengtsson wrote:
It seems that it comes down to two things: 1) a standard Rd topic or
alias pkg.package, and 2) enforcing this standard with R CMD check.
Pro's and con's for (1):
Pros:
- Easy to find overview information on a package, that is, you know
*where* to find it.
- Allows a
Torsten Hothorn wrote:
On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
- to recommend that pkg.package contain general information
On Wed, 8 Jun 2005, Duncan Murdoch wrote:
Torsten Hothorn wrote:
On Tue, 7 Jun 2005, Duncan Murdoch wrote:
[...]
My proposal (modified following the suggestions I've heard so far) is as
follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
-
Hi,
I would like to suggest a standard where all packages provide an Rd page
with the same name (or aliased) as the name of package so that
help(package name) or ?package name is always here. This especially
of interest to large packages with a large package index. This page
could explain
Henrik Bengtsson writes:
Hi,
I would like to suggest a standard where all packages provide an Rd page
with the same name (or aliased) as the name of package so that
help(package name) or ?package name is always here. This especially
of interest to large packages with a large package
Henrik Bengtsson writes:
I would like to suggest a standard where all packages provide an Rd page
with the same name (or aliased) as the name of package so that
help(package name) or ?package name is always here. This especially
of interest to large packages with a large package index. This
Kurt Hornik wrote:
Henrik Bengtsson writes:
Hi,
I would like to suggest a standard where all packages provide an Rd page
with the same name (or aliased) as the name of package so that
help(package name) or ?package name is always here. This especially
of interest to large packages with a
Wolfgang Huber wrote:
Henrik Bengtsson writes:
I would like to suggest a standard where all packages provide an Rd
page with the same name (or aliased) as the name of package so that
help(package name) or ?package name is always here. This
especially of interest to large packages with a
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things like
details and rationale for package
organization, pointers to the most important function(s) in the
package, and perhaps function descriptors
for ubiquitous functions that don't warrant their own helppage, but
need
On Tue, 7 Jun 2005, Henrik Bengtsson wrote:
Kurt Hornik wrote:
How would this be different from the results of
help(package = package name)
?
Thanks for that. I was not aware of this one; I like how DESCRIPTION is
included and how the index is divided in functions and dataset,
Robin Hankin wrote:
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things like
details and rationale for package
organization, pointers to the most important function(s) in the
package, and perhaps function descriptors
for ubiquitous functions that don't warrant their
On 6/7/2005 11:12 AM, Robert Gentleman wrote:
Robin Hankin wrote:
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things like
details and rationale for package
organization, pointers to the most important function(s) in the
package, and perhaps function descriptors
for
On 6/7/05, Robert Gentleman [EMAIL PROTECTED] wrote:
Robin Hankin wrote:
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things like
details and rationale for package
organization, pointers to the most important function(s) in the
package, and perhaps function
On 6/7/2005 11:59 AM, Robert Gentleman wrote:
Duncan Murdoch wrote:
On 6/7/2005 11:12 AM, Robert Gentleman wrote:
Robin Hankin wrote:
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things
like details and rationale for package
organization, pointers to the most
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Tue, 07 Jun 2005 12:12:57 -0400 writes:
.
The current .Rd files don't just document functions, they also document
data objects and classes.
But the main point here is that it's not good to have
Duncan Murdoch wrote:
On 6/7/2005 11:59 AM, Robert Gentleman wrote:
Duncan Murdoch wrote:
On 6/7/2005 11:12 AM, Robert Gentleman wrote:
Robin Hankin wrote:
My 0.02:
I use Misc.Rd for the purpose that Duncan suggests. I put things
like details and rationale for package
Currently methods?e will look for the alias e-methods so perhaps package?e
could look for alias e-package.
On 6/7/05, Achim Zeileis [EMAIL PROTECTED] wrote:
On Tue, 7 Jun 2005 18:43:37 +0200 Martin Maechler wrote:
Duncan == Duncan Murdoch [EMAIL PROTECTED]
on Tue, 07 Jun 2005
I share Robert's `pretty strenuous' objections.
Adding compulsory things for package writers seems to me to need very
compelling arguments. Checking that a package does what it says (e.g. the
code in vignettes can be run) is one thing, but checking it does things it
does not say it wants to
Prof Brian Ripley wrote:
I share Robert's `pretty strenuous' objections.
Adding compulsory things for package writers seems to me to need very
compelling arguments. Checking that a package does what it says (e.g. the
code in vignettes can be run) is one thing, but checking it does things it
Let me add to the pot:
I think Robert and Brian are against imposing additional _requirement_ on
packages to provide an overview in .Rd, and I tend to agree with that
sentiment.
However, if such a facility is made optional (like vignettes) for package
author/maintainer, then I have no problem
Liaw, Andy wrote:
Let me add to the pot:
I think Robert and Brian are against imposing additional _requirement_ on
packages to provide an overview in .Rd, and I tend to agree with that
sentiment.
However, if such a facility is made optional (like vignettes) for package
author/maintainer, then
My understanding is that one could still build, install and distribute
a package that did not conform to this requirement but it would
fail R CMD CHECK. Thus as long as you don't want to place it
in a repository that requires a clean R CMD CHECK you are
under no obligation to do it. But if you
26 matches
Mail list logo
