Hi
is there already a best practice (example?) for how to deliver vignettes
written in org-mode (http://orgmode.org) in Bioconductor packages?
(This would also require that emacs and its ESS and org modes are installed on
the build servers.)
Best wishes
Wolfgang
This isn't a direct answer to the question, but I recently learned of
this project:
http://www.dexy.it/
Basically, it is a giant set of filters that runs on text-based files
(MANY formats, including org) to produce outputs (MANY formats).
These filters include programming languages (including R)
On 08/28/2013 07:38 AM, Wolfgang Huber wrote:
Hi Martin,
thanks! Both of these sound doable, we'll explore. What was the third one?
To clarify, the intermediate form in option 2 should ideally still contain
executable code chunks -- Rmd or Rnw, rather than md or tex. One drawback of
this
On Wed, Aug 28, 2013 at 8:25 AM, Martin Morgan mtmor...@fhcrc.org wrote:
On 08/28/2013 07:38 AM, Wolfgang Huber wrote:
Hi Martin,
thanks! Both of these sound doable, we'll explore. What was the third one?
To clarify, the intermediate form in option 2 should ideally still contain
executable
On Wed, Aug 28, 2013 at 5:28 AM, Martin Morgan mtmor...@fhcrc.org wrote:
On 08/28/2013 02:50 AM, Wolfgang Huber wrote:
Hi
is there already a best practice (example?) for how to deliver vignettes
written in org-mode (http://orgmode.org) in Bioconductor packages?
Three possibilities come
Hello Folks,
I have an R package published on CRAN and I want to rename it for the next
version, something like from rName to rNAME. I have read the CRAN
policy, but did not find any topic regarding to this. So does anybody know
whether there is any CRAN policy for this? Thanks!
Best,
C
--
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
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 all,
RProf with memory profiling = TRUE provides a useful breakdown of R's
memory usage into small vectors, big vectors and nodes. Is there a
way to get this information from the command line? gc() aggregates
small and big vectors into one number and (obviously) also does a gc.
Are there any
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, for
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
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
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
via
the
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. Having to
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 order to
On 27.08.2013 18:38, comaths wrote:
Hello Folks,
I have an R package published on CRAN and I want to rename it for the next
version, something like from rName to rNAME. I have read the CRAN
policy, but did not find any topic regarding to this. So does anybody know
whether there is any CRAN
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 current
I have a package (TSdbi) which provides end user functions that I
export, and several utilities for plugin packages (e.g. TSMySQL) that I
do not export because I do not intend them to be exposed to end users. I
call these from the plugin packages using TSdbi::: but that now
produces a note in
Hi all,
I've been trying to learn more about memory profiling in R and I've
been trying memory profiling out on read.table. I'm getting a bit of a
strange result, and I hope that someone might be able to explain why.
After running
Rprof(read-table.prof, memory.profiling = TRUE, line.profiling =
On Aug 28, 2013, at 11:15 AM, Paul Gilbert pgilbert...@gmail.com wrote:
I have a package (TSdbi) which provides end user functions that I export, and
several utilities for plugin packages (e.g. TSMySQL) that I do not export
because I do not intend them to be exposed to end users. I call
Paul, this was discussed at length only a couple of days ago. See this thread:
http://comments.gmane.org/gmane.comp.lang.r.devel/34100
If I follow you, I think a change has been made that doesn't NOTE if
the use of `:::` is to packages for which you are also the maintainer.
But read the thread
On Aug 28, 2013, at 12:17 PM, Hadley Wickham wrote:
Hi all,
I've been trying to learn more about memory profiling in R and I've
been trying memory profiling out on read.table. I'm getting a bit of a
strange result, and I hope that someone might be able to explain why.
After running
Why do those lines need any allocations? I thought class- and attr-
were primitives, and hence would modify in place.
.. but only if there is no other reference to the data (i.e. NAMED 2). If
there are two references, they have to copy, because it would change the
other copy.
Here,
On Aug 28, 2013, at 1:59 PM, Hadley Wickham wrote:
Why do those lines need any allocations? I thought class- and attr-
were primitives, and hence would modify in place.
.. but only if there is no other reference to the data (i.e. NAMED 2). If
there are two references, they have to
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
Yup - parsing is the most expensive part. That's why for high-throughput data
you don't want to use ASCII representation. It's amazing that the disk speeds
are now so high that CPUs are the bottlenecks now, not vice versa.
Do you have any recommendations for binary formats? For R, is there
On 13-08-28 12:29 PM, Marc Schwartz wrote:
On Aug 28, 2013, at 11:15 AM, Paul Gilbert pgilbert...@gmail.com wrote:
I have a package (TSdbi) which provides end user functions that I export, and
several utilities for plugin packages (e.g. TSMySQL) that I do not export
because I do not intend
On Aug 28, 2013, at 2:24 PM, Hadley Wickham wrote:
Yup - parsing is the most expensive part. That's why for high-throughput
data you don't want to use ASCII representation. It's amazing that the disk
speeds are now so high that CPUs are the bottlenecks now, not vice versa.
Do you have any
My point of view is that if you have a core package where you need access
to hidden functions for making a plugin, you should probably export these
hidden functions in the first place. Chances are that if you need access
to these hidden functions (for expert use), other (expert) users might want
On 28/08/2013 2:50 PM, Paul Gilbert wrote:
On 13-08-28 12:29 PM, Marc Schwartz wrote:
On Aug 28, 2013, at 11:15 AM, Paul Gilbert pgilbert...@gmail.com wrote:
I have a package (TSdbi) which provides end user functions that I export,
and several utilities for plugin packages (e.g. TSMySQL)
On 28/08/2013 3:06 PM, Kasper Daniel Hansen wrote:
My point of view is that if you have a core package where you need access
to hidden functions for making a plugin, you should probably export these
hidden functions in the first place. Chances are that if you need access
to these hidden
Dear all,
When running function 'testQAReport()', which uses function
'buildVignettes()' to create a pdf-file I get the following error:
source(testQAReport.R)
testQAReport()
Error in .get_package_metadata(pkgdir) :
Files 'DESCRIPTION' and 'DESCRIPTION.in' are missing.
Since I did not
If this issue is going to be solved at all, it might end up as yet
another hack like utils::globalVariables just to fix R CMD check
which was trying to fix things that were not necessarily broken.
To be clear, I was not suggesting subvert this check. What I was
hoping is a way to tell CRAN that
I may have confused things by referring to ':::' which everyone reads as
not exported, not documented, not part of the API, constantly changing, ...
In my mind, the real question is about two levels of exporting, one to
other package developers, and another to end users. In both cases they
Geoff Jentry geoffjentry at 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
3/ Some functions are exported normally but hidden by using . in the
beginning of their names. Other package maintainers would know they exist,
but end users would not so easily find them. (Duncan's other suggestion of
using \keyword{internal} in the .Rd file strikes me as problematic. I'm
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
Ben,
It works for me ...
x = rpois(100, 5) + 1
y = rnorm(100, x)
d = data.frame(x,y)
m - lm(y~log(x),d)
update(m,data=model.frame(m))
Call:
lm(formula = y ~ log(x), data = model.frame(m))
Coefficients:
(Intercept) log(x)
-4.0105.817
You can also re-fit using the
sessionInfo()
R version 3.0.0 Patched (2013-04-11 r62551)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
I would check with R 3.0.1 patched and R devel before anything else,
especially when troubleshooting vignette-related issues.
/Henrik
On Wed, Aug 28, 2013 at 12:33 PM, cstrato
Dear Henrik,
Thank you for your suggestion, however the error was detected by a user
who is already using R 3.0.1, see:
https://www.stat.math.ethz.ch/pipermail/bioconductor/2013-August/054633.html
Best regards,
Christian
On 8/28/13 11:49 PM, Henrik Bengtsson wrote:
sessionInfo()
R version
Ok. ...I've now read your original thread more carefully, and I'd say
that tools::buildVignettes() is intended for building vignettes within
packages, not for compiling vignette files in general. This is most
likely why it complains - it simply looks for files that it expect to
see in a package
Extracted from email trail below
And as a potential user of your package, I don't want you to
use ::: if you don't have control over the other package,
because its author might unwittingly change it in a way that
causes me to get incorrect results.
If you want to use :::, go ahead,
On 13-08-28 05:13 PM, Hadley Wickham wrote:
3/ Some functions are exported normally but hidden by using . in the
beginning of their names. Other package maintainers would know they exist,
but end users would not so easily find them. (Duncan's other suggestion of
using \keyword{internal} in
On Wed, Aug 28, 2013 at 4:50 PM, Paul Gilbert pgilbert...@gmail.com wrote:
(Also, if you export it then you should document it, but for many
maintainers \keyword{internal} is shorthand for I don't need to document
this properly because no one is suppose to use it outside the package.)
But
On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch murdoch.dun...@gmail.comwrote:
On 28/08/2013 3:06 PM, Kasper Daniel Hansen wrote:
My point of view is that if you have a core package where you need access
to hidden functions for making a plugin, you should probably export
these
hidden
45 matches
Mail list logo
