On Thu, Jun 17, 2010 at 5:01 PM, Vincenzo Carey wrote:
>
> "Rare" is vague. Almost every software package in the Bioconductor
> repository has a vignette; the informal advice to contributors is that
> the vignette should take the reader through all the steps of a
> substantively interesting anal
On Thu, Jun 17, 2010 at 7:45 AM, Dominick Samperi wrote:
>
> On Thu, Jun 17, 2010 at 5:22 AM, Patrick Burns
> wrote:
>
> > I agree with Hadley, and add that trying
> > to have an example be both an example and
> > a test may not be good for the example
> > aspect either.
> >
> > Examples should m
On Thu, Jun 17, 2010 at 9:23 AM, Hadley Wickham wrote:
> > The creation of a research compendium can be viewed as
> > a form of unit testing, and the fact that R has powerful tools
> > that support this process (Sweave) could be viewed as one of
> > its outstanding features (relating these commen
> The creation of a research compendium can be viewed as
> a form of unit testing, and the fact that R has powerful tools
> that support this process (Sweave) could be viewed as one of
> its outstanding features (relating these comments back to
> the topic of this thread).
If anything, a research
On Thu, Jun 17, 2010 at 5:22 AM, Patrick Burns wrote:
> I agree with Hadley, and add that trying
> to have an example be both an example and
> a test may not be good for the example
> aspect either.
>
> Examples should make people who are ignorant
> of the function twig as to how the function
> wo
I agree with Hadley, and add that trying
to have an example be both an example and
a test may not be good for the example
aspect either.
Examples should make people who are ignorant
of the function twig as to how the function
works. Creating good examples is hard.
Problems that really test the
> What about the encouragement to add unit tests, if only disguised as
> examples?
Examples are not unit tests. Examples are a convenient way of testing
some aspects of the package, but serve a rather different purpose to
tests. The R community does not emphase testing nearly as much as
other
Hi, Hadley:
What about the encouragement to add unit tests, if only disguised
as examples?
I've found the unit tests to be a powerful tool to help improve
and maintain the quality of packages to which I contribute. To this
end, Sundar and I added a column "Autochecks" to the t
Hi Spencer,
I think it is the emphasis on documentation that makes the R
development process unique. Many other languages have equivalents to
CRAN and R-forge - few others require the attention to documentation
that R does.
Hadley
On Tue, Jun 15, 2010 at 8:45 PM, Spencer Graves
wrote:
> Hello,
On Wed, Jun 16, 2010 at 12:20 AM, Spencer Graves
wrote:
> Hi, Gabor:
>
>
> Thanks. I added a row for Ruby and columns for "Package manager" and
> "Collaborative development platform" to the table of "Selected Repositories"
> in the Wikipedia entry for "Software repository". Please correct m
Thanks. I added rows for C++, Haskell, and PHP from your
stackoverflow.com reference. I skipped the rest because I wasn't sure
if they really fit and because I ran out of time for this right now.
More suggestions (including encouragement to study the stackoverflow.com
reference more) will b
On Wed, Jun 16, 2010 at 6:20 AM, Spencer Graves
wrote:
> Thanks. I added a row for Ruby and columns for "Package manager" and
> "Collaborative development platform" to the table of "Selected Repositories"
> in the Wikipedia entry for "Software repository". Please correct me if I'm
> wrong,
Hi, Gabor:
Thanks. I added a row for Ruby and columns for "Package manager"
and "Collaborative development platform" to the table of "Selected
Repositories" in the Wikipedia entry for "Software repository". Please
correct me if I'm wrong, but the Wiki page for Ruby suggested to me tha
On Tue, Jun 15, 2010 at 9:45 PM, Spencer Graves
wrote:
> Hello, All:
>
>
> What thoughts might you have on "The R Software Package Development
> Process"?
>
>
> I'm looking for ideas, materials, references, and / or collaborators
> for an article on this topic to be submitted to the Comm
Hello, All:
What thoughts might you have on "The R Software Package
Development Process"?
I'm looking for ideas, materials, references, and / or
collaborators for an article on this topic to be submitted to the
Communications of the ACM. My limited experience with other langua
Hi,
I have now spent some time looking at whether this is possible with one
repository. The _easy_ part is getting the selection list to display
more information. Right now, the code that determines what is displayed
is inside a function called "explode_bundles" that is defined internally
to
Perhaps it would be sufficient as a first step to just display the version
that will be downloaded. That would still only let you pick one but at
least you would know which one.
On Mon, Dec 15, 2008 at 11:43 AM, Duncan Murdoch wrote:
> On 12/15/2008 10:58 AM, Kevin R. Coombes wrote:
>>
>> I knew
On 12/15/2008 10:58 AM, Kevin R. Coombes wrote:
I knew that (but forgot to include it in my statement of the question).
Thanks for pointing it out.
Is there any way to convince the selection box (or its developers) to
include the version information that is already available?
The selection
I knew that (but forgot to include it in my statement of the question).
Thanks for pointing it out.
Is there any way to convince the selection box (or its developers) to
include the version information that is already available?
Kevin
Duncan Murdoch wrote:
On 12/15/2008 10:31 AM,
On 12/15/2008 10:31 AM, Kevin R. Coombes wrote:
Hi,
Terry Therneau's question about package development reminded me of a
different issue. I maintain several packages along with a repository for
them at "http://bioinformatics.mdanderson.org/OOMPA/";. Several people
are working on adding featur
Hi,
Terry Therneau's question about package development reminded me of a
different issue. I maintain several packages along with a repository for
them at "http://bioinformatics.mdanderson.org/OOMPA/";. Several people
are working on adding features or testing the packages. So, I often want
to
On 12 December 2008 at 11:05, Paul Gilbert wrote:
| Yes, there are several options for not distributing tests. I was
| thinking more about how to distribute them with a simple mechanism for
| anyone to run them, but in a way that they are not run by the usual R
| CMD check.
One scheme I quite
Mathieu Ribatet epfl.ch> writes:
>
> Dear Terry,
>
> One way to locate which file is wrong - surely not the most brillant
> way! You could do an R script that sources each of your .R files within
> a "for (file in file.names)" loop.
> When R will stop, it will indicate which file has a wrong
I think the /tmp file gets removed:
ERROR: lazy loading failed for package 'xts'
** Removing '/private/tmp/Rinst625532301/xts'
ERROR
Installation failed.
Removing '/tmp/Rinst625532301'
At least it seems to when I run R CMD from the shell.
>
> Yes, there are several options for not distributing
Jeff Ryan wrote:
A quick comment on two subjects:
First to get the line # from the command line:
cat pkg/R/* > all.R
wc all.R
vim +LINE all.R (or pick you favorite method here...)
The tmp file is also indicated in error message, so you can edit that,
go to the line number, find context, g
A quick comment on two subjects:
First to get the line # from the command line:
cat pkg/R/* > all.R
wc all.R
vim +LINE all.R (or pick you favorite method here...)
>From there it should be easy enough to get context. At least enough
to grep back into the R directory.
Also, the use of unit-test
Duncan Murdoch wrote:
On 11/12/2008 6:04 PM, Terry Therneau wrote:
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really
nice
instructions about how to lay out the directories, order the files, and
run
Thanks to all for the replys. I've learned several things
First -- I didn't miss anything obvious in the documentation. This is good in
one sense at least: I wasn't being blind. I had one misunderstanding pointed
out, which is that I need not worry about my test suite being run with each
INS
Using parse() is better for syntax errors;
pathnames <- list.files(path="pkg/R", pattern="[.](r|R|s|S)$", full.names=TRUE);
for (pathname in pathnames) parse(pathname)
/Henrik
On Thu, Dec 11, 2008 at 4:00 PM, Duncan Murdoch wrote:
> On 11/12/2008 6:04 PM, Terry Therneau wrote:
>>
>> I'm making
On 11/12/2008 6:04 PM, Terry Therneau wrote:
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a
Hi Terry
I suspect many people struggle with similar issues.
The new version of mvbutils contains a number of routines that facilitate
creation & maintenance of a package, hopefully through its entire life-cycle:
from "documenting your own stuff for personal use", through "giving out
semi-docu
Dear Terry,
One way to locate which file is wrong - surely not the most brillant
way! You could do an R script that sources each of your .R files within
a "for (file in file.names)" loop.
When R will stop, it will indicate which file has a wrong syntax and
more info.
Cheers,
Mathieu
Terry T
I'm making the move of the survival package from my own environment to,
and have stumbled into a vacuum. The R Extensions manual has really nice
instructions about how to lay out the directories, order the files, and
run tests for DISTRIBUTION of a product, but I can't find anything on how
to s
33 matches
Mail list logo
