On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch wrote:
> 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 fi
On Wed, Aug 28, 2013 at 4:50 PM, Paul Gilbert 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 why would somethi
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
<< 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
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 s
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
> > 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 wrote:
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
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
> 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
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
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
are
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 tha
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
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 functi
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 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 expor
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 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 h
On 13-08-28 12:29 PM, Marc Schwartz wrote:
On Aug 28, 2013, at 11:15 AM, Paul Gilbert 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
> 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 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 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,
>> 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.
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
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 as
On Aug 28, 2013, at 11:15 AM, Paul Gilbert 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 these from
> the plug
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
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
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 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/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
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 o
> 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
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
40 matches
Mail list logo
