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() or ? is always here. This especially
of interest to large packages with a large package index. This page
could explain the package in general and
> 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() or ? is always here. This especially
> of interest to large packages with a large package index. This page
>
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() or ? is always here. This especially
of interest to large packages with a large package index. This page
could explain the pac
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() or ? is always here. This especially
of interest to large packages with a large package index. This
That worked! Thanks.
On 6/7/05, Brian D Ripley <[EMAIL PROTECTED]> wrote:
> This is due to the inconsistent way gregmisc has been unbundled. There
> was a gregmisc 2.0-7 containing gplots etc as part of a bundle, and there
> are also versions of gplots etc *with the same version number* which ar
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() or ? is always here. This
especially of interest to large packages with a large package index.
This p
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() or ? is always here. This especially
of interest to large packages with a large package index. This
On 6/7/05, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> 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() or ? is always here. This especially
> of interest to large packages with a large pack
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
McGehee, Robert wrote:
The bug might be here:
is.null(expression())
[1] TRUE
But
is.null(expression(NULL))
[1] FALSE
So it might look to the methods package like you're passing in a NULL
value for @bar. I might argue that expression() should not be NULL (and
only NULL is NULL) as I have
On Tue, 7 Jun 2005, Henrik Bengtsson wrote:
Kurt Hornik wrote:
How would this be different from the results of
help(package = )
?
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, e.g.
help(pack
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 o
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 u
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
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 important function(s) in the
package, and perhaps
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 impor
One first reaction to your suggestions.
[EMAIL PROTECTED] wrote:
On Mon, 23 May 2005 [EMAIL PROTECTED] wrote:
R-2.1.0 fails to compile on the newest release of FreeBSD, complaining about
undefined references to __builtin_alloca. On FreeBSD, alloca() is declared in
stdlib.h, not alloca.h as the
> "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'
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
organization,
On Tue, 7 Jun 2005 18:43:37 +0200 Martin Maechler wrote:
> > "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 obje
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 Tu
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 d
On Jun 7, 2005, at 12:36 PM, Rainer Hurling wrote:
One first reaction to your suggestions.
[EMAIL PROTECTED] wrote:
On Mon, 23 May 2005 [EMAIL PROTECTED] wrote:
R-2.1.0 fails to compile on the newest release of FreeBSD,
complaining about
undefined references to __builtin_alloca. On FreeBS
Simon Urbanek wrote:
On Jun 7, 2005, at 12:36 PM, Rainer Hurling wrote:
One first reaction to your suggestions.
[EMAIL PROTECTED] wrote:
On Mon, 23 May 2005 [EMAIL PROTECTED] wrote:
R-2.1.0 fails to compile on the newest release of FreeBSD,
complaining about
undefined references to __buil
This is a package, so it is not using config.h. It is using
#ifdef HAVE_ALLOCA_H
#include
#else
extern char *alloca(size_t);
#endif
and hence will have whatever the problem is with having that declaration.
The basic problem is that autoconf assumes that if alloca is defined
anywhere, it is d
Hi
Gabor Grothendieck wrote:
On 6/6/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
Hi
Gabor Grothendieck wrote:
On 6/2/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
Hi
Thanks. I have mucked around in vpTree structures and discovered its
actually quite easy to specify children so I have
On 6/7/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> Gabor Grothendieck wrote:
> > On 6/6/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> >
> >>Hi
> >>
> >>
> >>Gabor Grothendieck wrote:
> >>
> >>>On 6/2/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> Hi
> >>>
> >>>
> >>>Than
Hi
Gabor Grothendieck wrote:
On 6/7/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
Hi
Gabor Grothendieck wrote:
On 6/6/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
Hi
Gabor Grothendieck wrote:
On 6/2/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
Hi
Thanks. I have mucked around i
Here is the code once again. This time I have supplied two
names methods and a getChildren.viewport function to
encapsulate the corresponding grid internals. It would
be easiest if grid provided these itself but in the absence
of that this does encapsulate dependencies on grid
internals to a we
Yes, I understand that although such order is convenient for
the user as the significant reduction in code size here shows. I
wonder if there might be some performance parameter (e.g. hash)
to control it. If hash = TRUE then no guarantee is provided. Otherwise
order is kept.
On 6/7/05, Paul Mur
Just one additional item. Look at:
?new.env
for an example of where this approach is used in R, noting the
hash= argument.
On 6/7/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> Yes, I understand that although such order is convenient for
> the user as the significant reduction in code size
Hi
Gabor Grothendieck wrote:
Here is the code once again. This time I have supplied two
names methods and a getChildren.viewport function to
encapsulate the corresponding grid internals. It would
be easiest if grid provided these itself but in the absence
of that this does encapsulate depen
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
Thanks. Yet one other comment to consider when thinking
about this. Even if its not possible
or advisable to guarantee order, even without the hash=
idea, it may be possible to guarantee that default names
are generated in some order that can be used by
getChildren to ensure that it returns the c
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 wit
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 I
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 do
37 matches
Mail list logo
