[Rd] Rename the package published on CRAN

[comaths]

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 



--
View this message in context: 
http://r.789695.n4.nabble.com/Rename-the-package-published-on-CRAN-tp4674670.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Minimum requirements for package submission

[Sana Wajid]

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 unless
it is required. It's just very basic at the moment with 30+ functions and
there's a driver class. There's a lot of jargon in package submission and
so it's difficult to understand the Google results. I would appreciate any
help.

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){
...
return(ancestor)
}

Is this okay or do I have to do anything else to submit the package? Later
on (within the next few months) I would have time to convert these
functions to S3/4 but at the moment the most important thing it to get it
out there on CRAN.

2. Does the vignette need to be written in latex or can I get away with
writing all of the requirements in word? (I believe I've seen a vignette
written in word -> pdf)

3. Any other suggestions/links?

Also, I think the R development team has done a phenomenal job with R and
maintaining the package libraries. My intention is not to cut
corners...it's just that I have a program written in R that is complete and
I'd like to submit it. Furthermore, although github is a great resource for
hosting code, my primary objective is to submit the package to CRAN.

Thanks!

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Hadley Wickham]

> 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){
> ...
> return(ancestor)
> }
>
> Is this okay or do I have to do anything else to submit the package? Later
> on (within the next few months) I would have time to convert these
> functions to S3/4 but at the moment the most important thing it to get it
> out there on CRAN.

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.

> 2. Does the vignette need to be written in latex or can I get away with
> writing all of the requirements in word? (I believe I've seen a vignette
> written in word -> pdf)

I don't think you can use word, but you can use Rmarkdown, which is
much simpler than latex.

> 3. Any other suggestions/links?

Make sure you read http://cran.r-project.org/web/packages/policies.html

Good luck!

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] RProf + memory profiling

[Hadley Wickham]

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 other options?

Thanks!

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Kevin Wright]

> 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 one, hope that you DO worry about what your package does.  :-)


> > 2. Does the vignette need to be written in latex or can I get away with
> > writing all of the requirements in word? (I believe I've seen a vignette
> > written in word -> pdf)
>

 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).  Something like creating an extremely
minimal .rnw file and then including the vignette with the same name and a
.pdf extension.  Search the R-help mail archives and you can find other
people who have included non-.rnw vignettes.

Kevin

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Dirk Eddelbuettel]

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).  Something like creating an extremely
| minimal .rnw file and then including the vignette with the same name and a
| .pdf extension.  Search the R-help mail archives and you can find other
| people who have included non-.rnw vignettes.

Sort of. Kinda. Maybe not quite. I think you may be assuming "constant
requirements" at the CRAN side.  They are anything but -- and to be plain,
that is a Good Thing (TM) in the long run.

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.

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 RCS is a very poor proxy.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Duncan Murdoch]

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 some trick to doing
| this (which I have forgotten).  Something like creating an extremely
| minimal .rnw file and then including the vignette with the same name and a
| .pdf extension.  Search the R-help mail archives and you can find other
| people who have included non-.rnw vignettes.

Sort of. Kinda. Maybe not quite. I think you may be assuming "constant
requirements" at the CRAN side.  They are anything but -- and to be plain,
that is a Good Thing (TM) in the long run.

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.

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 RCS is a very poor proxy.


I don't understand the difference between the CHANGES file you are 
asking for and the NEWS file.  Do you want something in purely 
chronological order, rather than categorized as NEWS is?


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Hadley Wickham]

>> 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 RCS is a very poor proxy.
>
> I don't understand the difference between the CHANGES file you are asking
> for and the NEWS file.  Do you want something in purely chronological order,
> rather than categorized as NEWS is?

I think Dirk was talking about a CHANGES/NEWS file for "Writing R extensions"

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Dirk Eddelbuettel]

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 diff the NEWS files, or glancing at commit logs
| >> via
| >> the RCS is a very poor proxy.
| >
| > I don't understand the difference between the CHANGES file you are asking
| > for and the NEWS file.  Do you want something in purely chronological order,
| > rather than categorized as NEWS is?
| 
| I think Dirk was talking about a CHANGES/NEWS file for "Writing R extensions"

Yup. In the sense of "something to look at to see what one may need to change".

Eg for Debian, the "Policy" document has a version number making discussion /
comparison and reference more tangible.  Also, if/when an update is made, an
'upgrade checklist' is provided -- see eg [1] for the most recent annoucement
[2] for the policy manual web presence, and [3] for the complete checklist
with a roll-back history.

I am not suggesting this exact format. I am merely pointing that it
(currently) takes a couple of extra steps to stay on top of required changes,
which in turn leads to everybody just uploading to CRAN as a trial, which in
turn overburdens the CRAN maintainers.  Seems suboptimal to me.

Dirk

[1] http://lists.debian.org/debian-devel-announce/2012/09/msg6.html
[2] http://www.debian.org/doc/devel-manuals#policy
[3] http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Duncan Murdoch]

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 get a succinct view of
| >> what changed.  Having to diff the NEWS files, or glancing at commit logs
| >> via
| >> the RCS is a very poor proxy.
| >
| > I don't understand the difference between the CHANGES file you are asking
| > for and the NEWS file.  Do you want something in purely chronological order,
| > rather than categorized as NEWS is?
|
| I think Dirk was talking about a CHANGES/NEWS file for "Writing R extensions"

Yup. In the sense of "something to look at to see what one may need to change".

Eg for Debian, the "Policy" document has a version number making discussion /
comparison and reference more tangible.  Also, if/when an update is made, an
'upgrade checklist' is provided -- see eg [1] for the most recent annoucement
[2] for the policy manual web presence, and [3] for the complete checklist
with a roll-back history.

I am not suggesting this exact format. I am merely pointing that it
(currently) takes a couple of extra steps to stay on top of required changes,
which in turn leads to everybody just uploading to CRAN as a trial, which in
turn overburdens the CRAN maintainers.  Seems suboptimal to me.


There is the "--as-cran" option to R CMD check, so it's not quite as bad 
as you suggest, but as others have mentioned there is some ambiguity 
about how NOTEs in those checks are treated.  But isn't any "overburden" 
mainly a CRAN problem, so not something to be discussed on this list?


To be clear:  I am not a CRAN member.  I only know CRAN policy as an 
outsider, same as you.  And before an argument starts about where CRAN 
policy discussions should take place:  this is certainly not the 
place.   You can ask CRAN where such discussions should happen, but I 
suspect the answer will be "nowhere public", because most public 
discussions of CRAN policy devolve very quickly into ridiculous demands 
on the volunteers who run it.


Duncan Murdoch


Dirk

[1] http://lists.debian.org/debian-devel-announce/2012/09/msg6.html
[2] http://www.debian.org/doc/devel-manuals#policy
[3] http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rename the package published on CRAN

[Uwe Ligges]

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 policy for this? Thanks!


Actually you cannot: CRAN had to archive rName at first, but then no 
other package with the name but different capitalization can be added to 
CRAN, since that name is taken and packages work on file level where 
some operating systems cannot distinguish capitalization appropriately 
enough, hence the name rNAME is not available after archival of rName 
... The is a simple technical restriction.


Even with a really different name, renaming packages should be reduced 
to an absolute minimum and would probably only accepted for legal 
concerns related to inappropriate package names.


Best,
Uwe Ligges







Best,

C



--
View this message in context: 
http://r.789695.n4.nabble.com/Rename-the-package-published-on-CRAN-tp4674670.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Dirk Eddelbuettel]

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 "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 RCS is a very poor proxy.
| > | >
| > | > I don't understand the difference between the CHANGES file you are 
asking
| > | > for and the NEWS file.  Do you want something in purely chronological 
order,
| > | > rather than categorized as NEWS is?
| > |
| > | I think Dirk was talking about a CHANGES/NEWS file for "Writing R 
extensions"
| >
| > Yup. In the sense of "something to look at to see what one may need to 
change".
| >
| > Eg for Debian, the "Policy" document has a version number making discussion 
/
| > comparison and reference more tangible.  Also, if/when an update is made, an
| > 'upgrade checklist' is provided -- see eg [1] for the most recent 
annoucement
| > [2] for the policy manual web presence, and [3] for the complete checklist
| > with a roll-back history.
| >
| > I am not suggesting this exact format. I am merely pointing that it
| > (currently) takes a couple of extra steps to stay on top of required 
changes,
| > which in turn leads to everybody just uploading to CRAN as a trial, which in
| > turn overburdens the CRAN maintainers.  Seems suboptimal to me.
| 
| There is the "--as-cran" option to R CMD check, so it's not quite as bad 

Sure. I use that all the time, and it is the sole reason I keep an r-devel
build around. 

But it is _reactive_. I suggest something proactive.

| as you suggest, but as others have mentioned there is some ambiguity 
| about how NOTEs in those checks are treated.  But isn't any "overburden" 
| mainly a CRAN problem, so not something to be discussed on this list?
| 
| To be clear:  I am not a CRAN member.  I only know CRAN policy as an 
| outsider, same as you.  And before an argument starts about where CRAN 
| policy discussions should take place:  this is certainly not the 

This is the R development list. I have been subscribed for fourteen years,
and to the best of my recollection there never was any discussion of
this. Here.  At the place created to discuss R development issues. Ie work
meant for CRAN. 

In my book, that's a bug and not a feature.

| place.   You can ask CRAN where such discussions should happen, but I 
| suspect the answer will be "nowhere public", because most public 
| discussions of CRAN policy devolve very quickly into ridiculous demands 
| on the volunteers who run it.

By never engaging in the discussions the CRAN maintainers do not exactly help
their case, or for that matter their users (eg those submitting packages).

Dirk

ObDisclaimer: I remain a really huge fanboy of CRAN, and almost always defend
it in dicussions with other R users (not all of which are all that kindly
disposed to CRAN these days).  But even I am at a loss for explanations for
some of these things, and am tired of the current back-and-forth on submissions.
The fact that _overnight changes_ to r-devel are reasons for reject are just
silly. 

ObDisclaimer 2: I am not complaining to you. You just happent to be just
about the only R Core member engaging here.  I am grateful that you do, and I
do understand that your ability to affect change is also limited. I merely
assume it is larger than mine.


-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] ‘:::’ call

[Paul Gilbert]

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 the checks:


* checking dependencies in R code ... NOTE
Namespace imported from by a ‘:::’ call: ‘TSdbi’
  See the note in ?`:::` about the use of this operator. :: should be
  used rather than ::: if the function is exported, and a package
  almost never needs to use ::: for its own functions.

Is there a preferred method to accomplish this in a way that does not 
produce a note?


Thanks,
Paul

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Memory allocation in read.table

[Hadley Wickham]

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 = TRUE,
  gc.profiling = TRUE, interval = interval)
diamonds <- read.table("diamonds.csv", sep = ",", header = TRUE)
Rprof(NULL)

and doing an lot of data manipulation, I end up with a table that
displays the total memory (in megabytes) allocated and released (by
gc) from each line of (a local copy of) read.table:

  file line  alloc release
1 read-table.r  122 1.9797  1.1435
2 read-table.r  165 1.1148  0.6511
3 read-table.r  221 0.0763  0.0321
4 read-table.r  222 0.4922  1.5057

Lines 122 and 165 are where I expect to see big allocations and
releases - they're calling scan and convert.type respectively. Lines
221 and 222 are more of a mystery:

class(data) <- "data.frame"
attr(data, "row.names") <- row.names

Why do those lines need any allocations? I thought class<- and attr<-
were primitives, and hence would modify in place.

Re-running with gctorture(TRUE) yields roughly similar numbers,
although there is no memory release because gc is called earlier, and
the assignment of allocations to line is probably more accurate given
that gctorture runs the code about 20x slower:

   file linealloc  release
25 read-table.r  221 0.387299 0.00e+00
26 read-table.r  222 0.362964 0.00e+00

The whole object, when loaded, is ~4 meg, so those allocations
represent fairly sizeable chunks of the total.

Any suggestions would be greatly appreciated.  Thanks!

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Marc Schwartz]

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 plugin packages using TSdbi:::  but that now produces a note in the 
> checks:
> 
> * checking dependencies in R code ... NOTE
> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>  See the note in ?`:::` about the use of this operator. :: should be
>  used rather than ::: if the function is exported, and a package
>  almost never needs to use ::: for its own functions.
> 
> Is there a preferred method to accomplish this in a way that does not produce 
> a note?
> 
> Thanks,
> Paul



Paul,

See this rather lengthy discussion that occurred within the past week:

  https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html

Regards,

Marc Schwartz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Gavin Simpson]

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 the change is mentioned in there somewhere.

HTH

G

On 28 August 2013 10:15, 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 plugin packages using TSdbi:::  but that now produces a note in the
> checks:
>
> * checking dependencies in R code ... NOTE
> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>   See the note in ?`:::` about the use of this operator. :: should be
>   used rather than ::: if the function is exported, and a package
>   almost never needs to use ::: for its own functions.
>
> Is there a preferred method to accomplish this in a way that does not
> produce a note?
>
> Thanks,
> Paul
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gavin Simpson, PhD

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in read.table

[Simon Urbanek]

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
> 
> Rprof("read-table.prof", memory.profiling = TRUE, line.profiling = TRUE,
>  gc.profiling = TRUE, interval = interval)
> diamonds <- read.table("diamonds.csv", sep = ",", header = TRUE)
> Rprof(NULL)
> 
> and doing an lot of data manipulation, I end up with a table that
> displays the total memory (in megabytes) allocated and released (by
> gc) from each line of (a local copy of) read.table:
> 
>  file line  alloc release
> 1 read-table.r  122 1.9797  1.1435
> 2 read-table.r  165 1.1148  0.6511
> 3 read-table.r  221 0.0763  0.0321
> 4 read-table.r  222 0.4922  1.5057
> 
> Lines 122 and 165 are where I expect to see big allocations and
> releases - they're calling scan and convert.type respectively. Lines
> 221 and 222 are more of a mystery:
> 
>class(data) <- "data.frame"
>attr(data, "row.names") <- row.names
> 
> 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, however, it already has NAMED=2 because of 

data <- data[keep]

If you remove that line and inverse the order of class() and attr()<- then you 
get 0 copies.

Cheers,
Simon

PS: if you are loading any sizable data, the one thing you don't want to do is 
to use read.table() ;)


> Re-running with gctorture(TRUE) yields roughly similar numbers,
> although there is no memory release because gc is called earlier, and
> the assignment of allocations to line is probably more accurate given
> that gctorture runs the code about 20x slower:
> 
>   file linealloc  release
> 25 read-table.r  221 0.387299 0.00e+00
> 26 read-table.r  222 0.362964 0.00e+00
> 
> The whole object, when loaded, is ~4 meg, so those allocations
> represent fairly sizeable chunks of the total.
> 
> Any suggestions would be greatly appreciated.  Thanks!
> 
> Hadley
> 
> -- 
> Chief Scientist, RStudio
> http://had.co.nz/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in read.table

[Hadley Wickham]

>> 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, however, it already has NAMED=2 because of
>
> data <- data[keep]

Ah, got it - thanks!

> PS: if you are loading any sizable data, the one thing you don't want to do 
> is to use read.table() ;)

Yes ;)  Romain and I (mostly Romain) are working on some faster
alternatives at https://github.com/romainfrancois/fastread.

One surprising finding so far (to me at least), is that when loading a
file full of doubles, you pretty quickly get to the point where strtod
is the bottleneck.

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in read.table

[Simon Urbanek]

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 copy, because it would change the 
>> other copy.
>> Here, however, it already has NAMED=2 because of
>> 
>> data <- data[keep]
> 
> Ah, got it - thanks!
> 
>> PS: if you are loading any sizable data, the one thing you don't want to do 
>> is to use read.table() ;)
> 
> Yes ;)  Romain and I (mostly Romain) are working on some faster
> alternatives at https://github.com/romainfrancois/fastread.
> 
> One surprising finding so far (to me at least), is that when loading a
> file full of doubles, you pretty quickly get to the point where strtod
> is the bottleneck.
> 

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.

Re fast loading - yes, that's something I was also working around in iotools 
https://github.com/s-u/iotools 

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Geoff Jentry]

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 by this. I was one who did the stub-Rnw trick 
previously - it would be unwise for the vignette for twitteR to be run 
truly dynamically as it requires someone's real credentials to process.


Not a problem, I run it by hand before submitting and then use the stub 
.Rnw for the vignette metadata to get picked up by CRAN.


With the move to vignettes/ over inst/doc, that hasn't worked. doh!

Aside: If someone knows of a way to get a non-autogenerated documentation 
file linked on a package's CRAN page (other than URL, which is a 
possibility) I'd love to hear ideas.


-J

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in read.table

[Hadley Wickham]

> 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
anything obviously better than Rdata?

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Paul Gilbert]

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 end users. I call these from the 
plugin packages using TSdbi:::  but that now produces a note in the checks:

* checking dependencies in R code ... NOTE
Namespace imported from by a ‘:::’ call: ‘TSdbi’
  See the note in ?`:::` about the use of this operator. :: should be
  used rather than ::: if the function is exported, and a package
  almost never needs to use ::: for its own functions.

Is there a preferred method to accomplish this in a way that does not produce a 
note?

Thanks,
Paul




Paul,

See this rather lengthy discussion that occurred within the past week:

   https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html

Regards,

Marc Schwartz


I did follow the recent discussion, but no one answered the question "Is 
there a preferred method to accomplish this?" (I suppose the answer is 
that there is no other way, given that no one actually suggested 
anything else.) Most of the on topic discussion in that thread was about 
how to subvert the CRAN checks, which is not what I am trying to do and 
was also pointed out as a bad idea by Duncan. The substantive response was


>r63654 has fixed this particular issue, and R-devel will no longer
>warn against the use of ::: on packages of the same maintainer.
>
>Regards,
>Yihui

but that strikes me as a temporary work around rather than a real 
solution: suppose plugins are provided by a package from another maintainer.


Since CRAN notes have a habit of becoming warnings and then errors, it 
seems useful to identify the preferred legitimate approach while this is 
still a note. That would save work for both package developers and CRAN 
maintainers.


My thinking is that there is a need for a NAMESPACE directive something 
like limitedExport() that allows ::: for identified functions without 
provoking a CRAN complaint when packages use those functions. But there 
may already be a better way I don't know about. Or perhaps the solution 
is to split the end user functions and the utilities for plugin packages 
into two separate packages?


Paul

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Memory allocation in read.table

[Simon Urbanek]

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 recommendations for binary formats? For R, is there anything 
> obviously better than Rdata?
> 

native formats are the fastest (and versatile), so
readBin/writeBin or mmap
I tend to avoid strings (I use dates as POSIXct which are doubles and for 
anything else factors - which are integers) so the above works for me just fine.
I am working on a way to do direct mmap serialization of SEXPs but it's not 
ready yet (basic vectors are supported but complex objects not yet).

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Kasper Daniel Hansen]

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
access as well, so take the time to export and document it.

I want to use ::: specifically for the case where I have no control over
the other package.

Best,
Kasper




On Wed, Aug 28, 2013 at 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 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 the checks:
>>>
>>> * checking dependencies in R code ... NOTE
>>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>>   See the note in ?`:::` about the use of this operator. :: should be
>>>   used rather than ::: if the function is exported, and a package
>>>   almost never needs to use ::: for its own functions.
>>>
>>> Is there a preferred method to accomplish this in a way that does not
>>> produce a note?
>>>
>>> Thanks,
>>> Paul
>>>
>>
>>
>>
>> Paul,
>>
>> See this rather lengthy discussion that occurred within the past week:
>>
>>
>> https://stat.ethz.ch/**pipermail/r-devel/2013-August/**067180.html
>>
>> Regards,
>>
>> Marc Schwartz
>>
>
> I did follow the recent discussion, but no one answered the question "Is
> there a preferred method to accomplish this?" (I suppose the answer is that
> there is no other way, given that no one actually suggested anything else.)
> Most of the on topic discussion in that thread was about how to subvert the
> CRAN checks, which is not what I am trying to do and was also pointed out
> as a bad idea by Duncan. The substantive response was
>
> >r63654 has fixed this particular issue, and R-devel will no longer
> >warn against the use of ::: on packages of the same maintainer.
> >
> >Regards,
> >Yihui
>
> but that strikes me as a temporary work around rather than a real
> solution: suppose plugins are provided by a package from another maintainer.
>
> Since CRAN notes have a habit of becoming warnings and then errors, it
> seems useful to identify the preferred legitimate approach while this is
> still a note. That would save work for both package developers and CRAN
> maintainers.
>
> My thinking is that there is a need for a NAMESPACE directive something
> like limitedExport() that allows ::: for identified functions without
> provoking a CRAN complaint when packages use those functions. But there may
> already be a better way I don't know about. Or perhaps the solution is to
> split the end user functions and the utilities for plugin packages into two
> separate packages?
>
> Paul
>
>
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Duncan Murdoch]

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 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 the checks:
>>
>> * checking dependencies in R code ... NOTE
>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>   See the note in ?`:::` about the use of this operator. :: should be
>>   used rather than ::: if the function is exported, and a package
>>   almost never needs to use ::: for its own functions.
>>
>> Is there a preferred method to accomplish this in a way that does not 
produce a note?
>>
>> Thanks,
>> Paul
>
>
>
> Paul,
>
> See this rather lengthy discussion that occurred within the past week:
>
>https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html
>
> Regards,
>
> Marc Schwartz

I did follow the recent discussion, but no one answered the question "Is
there a preferred method to accomplish this?" (I suppose the answer is
that there is no other way, given that no one actually suggested
anything else.) Most of the on topic discussion in that thread was about
how to subvert the CRAN checks, which is not what I am trying to do and
was also pointed out as a bad idea by Duncan. The substantive response was

  >r63654 has fixed this particular issue, and R-devel will no longer
  >warn against the use of ::: on packages of the same maintainer.
  >
  >Regards,
  >Yihui

but that strikes me as a temporary work around rather than a real
solution: suppose plugins are provided by a package from another maintainer.

Since CRAN notes have a habit of becoming warnings and then errors, it
seems useful to identify the preferred legitimate approach while this is
still a note. That would save work for both package developers and CRAN
maintainers.

My thinking is that there is a need for a NAMESPACE directive something
like limitedExport() that allows ::: for identified functions without
provoking a CRAN complaint when packages use those functions. But there
may already be a better way I don't know about. Or perhaps the solution
is to split the end user functions and the utilities for plugin packages
into two separate packages?


I don't see a need for that.  The reason ::: is bad is because 
non-exported functions may change without notice, breaking the package 
that uses them, and possibly giving the users of that package bad 
results.  If you're the maintainer of both the donor and user of the 
non-exported function, then you can be expected to keep them in sync, 
hence r63654.  If those are different people, then the donor had better 
indicate that the function is safe to use.  That's what export() does.


If you are worried about a cluttered listing of functions and help 
pages, you can use an initial "." in the name of the object, or use 
\keyword{internal} in the .Rd file.  I forget the full list of effects 
of each of these, but using both should make your function nearly 
invisible, while still exported if it is listed as such in the NAMESPACE 
file.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Duncan Murdoch]

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 functions (for expert use), other (expert) users might want
access as well, so take the time to export and document it.

I want to use ::: specifically for the case where I have no control over
the other package.


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, just don't put your package on CRAN, 
where I get most of my packages.  Then we'll both be happy.


Duncan Murdoch


Best,
Kasper




On Wed, Aug 28, 2013 at 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 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 the checks:
>>>
>>> * checking dependencies in R code ... NOTE
>>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>>   See the note in ?`:::` about the use of this operator. :: should be
>>>   used rather than ::: if the function is exported, and a package
>>>   almost never needs to use ::: for its own functions.
>>>
>>> Is there a preferred method to accomplish this in a way that does not
>>> produce a note?
>>>
>>> Thanks,
>>> Paul
>>>
>>
>>
>>
>> Paul,
>>
>> See this rather lengthy discussion that occurred within the past week:
>>
>>
https://stat.ethz.ch/**pipermail/r-devel/2013-August/**067180.html
>>
>> Regards,
>>
>> Marc Schwartz
>>
>
> I did follow the recent discussion, but no one answered the question "Is
> there a preferred method to accomplish this?" (I suppose the answer is that
> there is no other way, given that no one actually suggested anything else.)
> Most of the on topic discussion in that thread was about how to subvert the
> CRAN checks, which is not what I am trying to do and was also pointed out
> as a bad idea by Duncan. The substantive response was
>
> >r63654 has fixed this particular issue, and R-devel will no longer
> >warn against the use of ::: on packages of the same maintainer.
> >
> >Regards,
> >Yihui
>
> but that strikes me as a temporary work around rather than a real
> solution: suppose plugins are provided by a package from another maintainer.
>
> Since CRAN notes have a habit of becoming warnings and then errors, it
> seems useful to identify the preferred legitimate approach while this is
> still a note. That would save work for both package developers and CRAN
> maintainers.
>
> My thinking is that there is a need for a NAMESPACE directive something
> like limitedExport() that allows ::: for identified functions without
> provoking a CRAN complaint when packages use those functions. But there may
> already be a better way I don't know about. Or perhaps the solution is to
> split the end user functions and the utilities for plugin packages into two
> separate packages?
>
> Paul
>
>
> __**
> R-devel@r-project.org mailing list
> 
https://stat.ethz.ch/mailman/**listinfo/r-devel
>

[[alternative HTML version deleted]]



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Error when using buildVignettes()

[cstrato]

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 get this error in earlier versions of R, could you 
please tell me what may be the reason for this error?



Here is the code for "testQAReport.R":

#--#
# testQAReport.R: test quality control report
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - -

testQAReport <-
function(dataset = "My Dataset",
 title   = "Quality Report",
 date= "October, 2011",
 author  = "Christian Stratowa",
 outdir  = file.path(getwd(), "TestQA"),
 ...)
{
   ## directory containing parts of QAReport.Rnw
   indir <- file.path(path.package("xps"), "QC");

   ## create directory containing final QAReport.Rnw
   if (!dir.create(outdir))
  stop("could not create report directory");
   if (!dir.create(file.path(outdir, "inst")))
  stop("could not create report subdirectory 'inst'");
   if (!dir.create(file.path(outdir, "inst", "doc")))
  stop("could not create report subdirectory 'doc'");
   docdir <- file.path(outdir, "inst", "doc");

   QCb <- readLines(file.path(indir, "QC.begin.Rnw"));

   ## replace title, date, author
   QCb <- sub("@TITLE@",  title,  QCb);
   QCb <- sub("@DATE@",   date,   QCb);
   QCb <- sub("@AUTHOR@", author, QCb);

   ## dataset info
   numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
   QCb <- sub("@DATASET@",  dataset,  QCb);
   QCb <- sub("@NUMTREES@", numtrees, QCb);
   QCb <- sub("@CHIPNAME@", chipname, QCb);
   QCb <- sub("@CHIPTYPE@", chiptype, QCb);

   write(QCb, file.path(docdir, "QAReport.Rnw"));

   QCe <- readLines(file.path(indir, "QC.end.Rnw"));
   QCe <- sub("@DATASET@",  dataset,  QCe);
   QCe <- gsub("_","_", QCe);

   write(QCe, file.path(docdir, "QAReport.Rnw"), append=TRUE);

   ## build vignette QC.pdf
   if (require(tools)) {
  buildVignettes(dir=outdir, lib.loc=NULL, quiet=FALSE, clean=FALSE);
   }#if
}#xpsQAReport

#--#

The file "QC.begin.Rnw" is as follows:

\documentclass{article}


\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in

\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}

\begin{document}

\title{@TITLE@}
\date{@DATE@}
\author{@AUTHOR@}
\maketitle

\tableofcontents


\section{Introduction}

 This is the quality assessment report for the dataset '@DATASET@'. The 
dataset consists of

 @NUMTREES@ Affymetrix @CHIPTYPE@ arrays of type '@CHIPNAME@'. \\

 This report was generated using function \Rfunction{xpsQAReport} of 
package \xps. \\



The file "QC.end.Rnw" is as follows:

\section{Summary}

 The current quality report for dataset '@DATASET@' displays the most 
important quality plots, using the
 default settings for most plots. Package \xps\ contains additional 
plots which can be used for further

 quality assessments. \\


\section*{Session Information:}

<>=
sessionInfo()
@

\end{document}


Finally, the output which is located in TestQA/inst/doc/QAReport.Rnw is 
as follows:


\documentclass{article}


\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in

\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}

\begin{document}

\title{Quality Report}
\date{October, 2011}
\author{Christian Stratowa}
\maketitle

\tableofcontents


\section{Introduction}

 This is the quality assessment report for the dataset 'My Dataset'. 
The dataset consists of

 6 Affymetrix GeneChip arrays of type 'Test3'. \\

 This report was generated using function \Rfunction{xpsQAReport} of 
package \xps. \\


\section{Summary}

 The current quality report for dataset 'My Dataset' displays the most 
important quality plots, using the
 default settings for most plots. Package \xps\ contains additional 
plots which can be used for further

 quality assessments. \\


\section*{Session Information:}

<>=
sessionInfo()
@

\end{document}


Can you please tell me w

Re: [Rd] ‘:::’ call

[Yihui Xie]

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 "Yes, I have read the documentation;
I understand the risk, and I want to take it like a moth flying into
the flames".

Many people have been talking about this "risk", and how about some
evidence? Who was bitten by :::? How many real cases in which a
package was broken by :::?

Yes, unexported functions may change, so are exported functions (they
may change API, be deprecated, add new arguments, change defaults, and
so on). Almost everything in a package is constantly evolving, and I
believe the correct way (and the only way) to stop things from being
broken is to write enough test cases. When something is broken, we
will be able to know that. Yes, we may not have control over other
people's packages, but we always have control over our own test cases.
IMHO, testing is the justification of CRAN's reputation and quality,
and that is a part of what CRAN does.

In God we trust, and everyone else should bring tests.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Aug 28, 2013 at 1: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
>>> 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 the
>>> checks:
>>>
>>> * checking dependencies in R code ... NOTE
>>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>>   See the note in ?`:::` about the use of this operator. :: should be
>>>   used rather than ::: if the function is exported, and a package
>>>   almost never needs to use ::: for its own functions.
>>>
>>> Is there a preferred method to accomplish this in a way that does not
>>> produce a note?
>>>
>>> Thanks,
>>> Paul
>>
>>
>>
>>
>> Paul,
>>
>> See this rather lengthy discussion that occurred within the past week:
>>
>>https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html
>>
>> Regards,
>>
>> Marc Schwartz
>
>
> I did follow the recent discussion, but no one answered the question "Is
> there a preferred method to accomplish this?" (I suppose the answer is that
> there is no other way, given that no one actually suggested anything else.)
> Most of the on topic discussion in that thread was about how to subvert the
> CRAN checks, which is not what I am trying to do and was also pointed out as
> a bad idea by Duncan. The substantive response was
>
>>r63654 has fixed this particular issue, and R-devel will no longer
>>warn against the use of ::: on packages of the same maintainer.
>>
>>Regards,
>>Yihui
>
> but that strikes me as a temporary work around rather than a real solution:
> suppose plugins are provided by a package from another maintainer.
>
> Since CRAN notes have a habit of becoming warnings and then errors, it seems
> useful to identify the preferred legitimate approach while this is still a
> note. That would save work for both package developers and CRAN maintainers.
>
> My thinking is that there is a need for a NAMESPACE directive something like
> limitedExport() that allows ::: for identified functions without provoking a
> CRAN complaint when packages use those functions. But there may already be a
> better way I don't know about. Or perhaps the solution is to split the end
> user functions and the utilities for plugin packages into two separate
> packages?
>
> Paul

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Paul Gilbert]

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 part of the "API", relatively constant, and documented. (I try to 
document even internal functions, otherwise I can't remember what they do.)


So far, I see three possible solutions:

  1/ R adds another namespace directive allowing certain functions to 
be "exported" differently, possibly just by causing the checks to be 
silent about ::: when those functions are used in that way by other 
packages.


 2/ The package gets split in two, one for use by other packages and 
one for use by end users.


 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 surprised CRAN checks do not already object to 
functions exported and documented with \keyword{internal}.)


Paul

On 13-08-28 03:44 PM, Yihui Xie wrote:

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 "Yes, I have read the documentation;
I understand the risk, and I want to take it like a moth flying into
the flames".

Many people have been talking about this "risk", and how about some
evidence? Who was bitten by :::? How many real cases in which a
package was broken by :::?

Yes, unexported functions may change, so are exported functions (they
may change API, be deprecated, add new arguments, change defaults, and
so on). Almost everything in a package is constantly evolving, and I
believe the correct way (and the only way) to stop things from being
broken is to write enough test cases. When something is broken, we
will be able to know that. Yes, we may not have control over other
people's packages, but we always have control over our own test cases.
IMHO, testing is the justification of CRAN's reputation and quality,
and that is a part of what CRAN does.

In God we trust, and everyone else should bring tests.

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Wed, Aug 28, 2013 at 1: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
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 the
checks:

* checking dependencies in R code ... NOTE
Namespace imported from by a ‘:::’ call: ‘TSdbi’
   See the note in ?`:::` about the use of this operator. :: should be
   used rather than ::: if the function is exported, and a package
   almost never needs to use ::: for its own functions.

Is there a preferred method to accomplish this in a way that does not
produce a note?

Thanks,
Paul





Paul,

See this rather lengthy discussion that occurred within the past week:

https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html

Regards,

Marc Schwartz



I did follow the recent discussion, but no one answered the question "Is
there a preferred method to accomplish this?" (I suppose the answer is that
there is no other way, given that no one actually suggested anything else.)
Most of the on topic discussion in that thread was about how to subvert the
CRAN checks, which is not what I am trying to do and was also pointed out as
a bad idea by Duncan. The substantive response was


r63654 has fixed this particular issue, and R-devel will no longer
warn against the use of ::: on packages of the same maintainer.

Regards,
Yihui


but that strikes me as a temporary work around rather than a real solution:
suppose plugins are provided by a package from another maintainer.

Since CRAN notes have a habit of becoming warnings and then errors, it seems
useful to identify the preferred legitimate approach while this is still a
note. That would save work for both package developers and CRAN maintainers.

My thinking is that there is a need for a NAMESPACE directive something like
limitedExport() that allows ::: for identified functions without provoking a
CRAN complaint when packages use those functions. But there may already be a
better way I don't know about. Or perhaps the solution is to split the end
user functions and the utilities for plugin packages into two separate
packages?

Paul


__

Re: [Rd] Minimum requirements for package submission

[Ben Bolker]

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-Rnw / non-(la)tex vignettes.
> 
> I'm currently stymied by this. I was one who did the stub-Rnw trick 
> previously - it would be unwise for the vignette for twitteR to be run 
> truly dynamically as it requires someone's real credentials to process.
> 
> Not a problem, I run it by hand before submitting and then use the stub 
> .Rnw for the vignette metadata to get picked up by CRAN.
> 
> With the move to vignettes/ over inst/doc, that hasn't worked. doh!
> 
> Aside: If someone knows of a way to get a non-autogenerated documentation 
> file linked on a package's CRAN page (other than URL, which is a 
> possibility) I'd love to hear ideas.


  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 appears to run
the command, and an eval'd but non-echo'd chunk that loads the results
of having run the command.

   Ben Bolker

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Hadley Wickham]

>  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
> surprised CRAN checks do not already object to functions exported and
> documented with \keyword{internal}.)

Why? I think this is exactly the use case of \keyword{internal}.

-- 
Chief Scientist, RStudio
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Minimum requirements for package submission

[Geoff Jentry]

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 appears to run the command, 
and an eval'd but non-echo'd chunk that loads the results of having run 
the command.


Interesting, I'll look into doing that.

Thanks
-J

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] model.frame(), model.matrix(), and derived predictor variables

[Gabriel Becker]

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 model.matrix directly. In your example, the
model frame can be passed directly to lm.fit /lm.wfit.


~G

> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=C LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] tools_3.0.1




On Sat, Aug 24, 2013 at 7:40 PM, Ben Bolker  wrote:

>
>   Bump: just trying one more time to see if anyone had thoughts on this
> (so far it's just  ...)
>
>
>  Original Message 
> Subject: model.frame(), model.matrix(), and derived predictor variables
> Date: Sat, 17 Aug 2013 12:19:58 -0400
> From: Ben Bolker 
> To: r-de...@stat.math.ethz.ch 
>
>
>   Dear r-developers:
>
>   I am struggling with some fundamental aspects of model.frame().
>
>   Conceptually, I think of a flow from data -> model.frame() ->
> model.matrix; the data contain _input variables_, while model.matrix
> contains _predictor variables_: data have been transformed, splines and
> polynomials have been expanded into their corresponding
> multi-dimensional bases, and factors have been expanded into appropriate
> sets of dummy variables depending on their contrasts.
>   I originally thought of model.frame() as containing input variables as
> well (but with only the variables needed by the model, and with cases
> containing NAs handled according to the relevant na.action setting), but
> that's not quite true.  While factors are retained as-is, splines and
> polynomials and parameter transformations are evaluated. For example
>
> d <- data.frame(x=1:10,y=1:10)
> model.frame(y~log(x),d)
>
> produces a model frame with columns 'y', 'log(x)' (not 'y', 'x').
>
> This makes it hard (impossible?) to use the model frame to re-evaluate
> the existing formula in a model, e.g.
>
> m <- lm(y~log(x),d)
> update(m,data=model.frame(m))
> ## Error in eval(expr, envir, enclos) : object 'x' not found
>
> It seems to me that this is a reasonable thing to want to do
> (i.e. use the model frame as a stored copy of the data that
>  can be used for additional model operations); otherwise, I
> either need to carry along an additional copy of the data in
> a slot, or hope that the model is still living in an environment
> where it can find a copy of the original data.
>
> Does anyone have any insights into the original design choices,
> or suggestions about how they have handled this within their own
> code? Do you just add an additional data slot to the model?  I've
> considered trying to write some kind of 'augmented' model frame, that
> would contain the equivalent of
> setdiff(all.vars(formula),model.frame(m)) [i.e.  all input variables
> that appeared in the formula but not in the model frame ...].
>
>   thanks
>Ben Bolker
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error when using buildVignettes()

[Henrik Bengtsson]

> > 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:
> 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 get this error in earlier versions of R, could you please
> tell me what may be the reason for this error?
>
>
> Here is the code for "testQAReport.R":
>
> #--#
> # testQAReport.R: test quality control report
> # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - -
> testQAReport <-
> function(dataset = "My Dataset",
>  title   = "Quality Report",
>  date= "October, 2011",
>  author  = "Christian Stratowa",
>  outdir  = file.path(getwd(), "TestQA"),
>  ...)
> {
>## directory containing parts of QAReport.Rnw
>indir <- file.path(path.package("xps"), "QC");
>
>## create directory containing final QAReport.Rnw
>if (!dir.create(outdir))
>   stop("could not create report directory");
>if (!dir.create(file.path(outdir, "inst")))
>   stop("could not create report subdirectory 'inst'");
>if (!dir.create(file.path(outdir, "inst", "doc")))
>   stop("could not create report subdirectory 'doc'");
>docdir <- file.path(outdir, "inst", "doc");
>
>QCb <- readLines(file.path(indir, "QC.begin.Rnw"));
>
>## replace title, date, author
>QCb <- sub("@TITLE@",  title,  QCb);
>QCb <- sub("@DATE@",   date,   QCb);
>QCb <- sub("@AUTHOR@", author, QCb);
>
>## dataset info
>numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
>QCb <- sub("@DATASET@",  dataset,  QCb);
>QCb <- sub("@NUMTREES@", numtrees, QCb);
>QCb <- sub("@CHIPNAME@", chipname, QCb);
>QCb <- sub("@CHIPTYPE@", chiptype, QCb);
>
>write(QCb, file.path(docdir, "QAReport.Rnw"));
>
>QCe <- readLines(file.path(indir, "QC.end.Rnw"));
>QCe <- sub("@DATASET@",  dataset,  QCe);
>QCe <- gsub("_","_", QCe);
>
>write(QCe, file.path(docdir, "QAReport.Rnw"), append=TRUE);
>
>## build vignette QC.pdf
>if (require(tools)) {
>   buildVignettes(dir=outdir, lib.loc=NULL, quiet=FALSE, clean=FALSE);
>}#if
> }#xpsQAReport
>
> #--#
>
> The file "QC.begin.Rnw" is as follows:
>
> \documentclass{article}
>
>
> \textwidth=6.2in
> \textheight=8.5in
> %\parskip=.3cm
> \oddsidemargin=.1in
> \evensidemargin=.1in
> \headheight=-.3in
>
> \newcommand{\Rfunction}[1]{{\texttt{#1}}}
> \newcommand{\Rmethod}[1]{{\texttt{#1}}}
> \newcommand{\Rcode}[1]{{\texttt{#1}}}
> \newcommand{\Robject}[1]{{\texttt{#1}}}
> \newcommand{\Rpackage}[1]{{\textsf{#1}}}
> \newcommand{\Rclass}[1]{{\textit{#1}}}
> \newcommand{\Cclass}[1]{{\textit{#1}}}
> \newcommand{\Rexten}[1]{{\textit{#1}}}
> \newcommand{\xps}{\Rpackage{xps}}
> \newcommand{\ROOT}{\Robject{ROOT}}
>
> \begin{document}
>
> \title{@TITLE@}
> \date{@DATE@}
> \author{@AUTHOR@}
> \maketitle
>
> \tableofcontents
>
>
> \section{Introduction}
>
>  This is the quality assessment report for the dataset '@DATASET@'. The
> dataset consists of
>  @NUMTREES@ Affymetrix @CHIPTYPE@ arrays of type '@CHIPNAME@'. \\
>
>  This report was generated using function \Rfunction{xpsQAReport} of package
> \xps. \\
>
>
> The file "QC.end.Rnw" is as follows:
>
> \section{Summary}
>
>  The current quality report for dataset '@DATASET@' displays the most
> important quality plots, using the
>  default settings for most plots. Package \xps\ contains additional plots
> which can be used for further
>  quality assessments. \\
>
>
> \section*{Session Information:}
>
> <>=
> sessionInfo()
> @
>
> \end{document}
>
>
> Finally, the output which is located in TestQA/inst/doc/QAReport.Rnw is as
> follows:
>
> \documentclass{article}
>
>
> \textwidth=6.2in
> \textheight=8.5in
> %\parskip=.3cm
> \oddsidemargin=.1in
> \evensidemargin=.1in
> \headheight=-.3in
>
> \newcommand{\Rfunction}[1]{{\texttt{#1}}}
> \newcommand{\Rmethod}[1]{{\texttt{#1}}}
> \newcommand{\Rcode}[1]{{\texttt{#1}}}
> \newcommand{\Robject}[1]{{\texttt{#1}}}
> \newcommand{\Rpackage}[1]{{\textsf{#1}}}
> \newcommand{\Rclass}[1]{{\textit{#1}}}
> \newcommand{\Cclass}[1]{{\textit{#1}}}
> \newcommand{\Rexten}[1]{{\textit{#1}}}
> \newcommand{\xps}{\Rpackage{xps}}
> \newcommand{\ROOT}{\Robject{ROOT}}
>
> \begin{document}
>
> \title{Quality Report}
> \date{October, 2011}
> \author{Christian Stratowa}
> \maketitle
>
> \tableofcontents
>
>
> \section{Introduction}
>
>  This is the qu

Re: [Rd] Error when using buildVignettes()

[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 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:

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 get this error in earlier versions of R, could you please
tell me what may be the reason for this error?


Here is the code for "testQAReport.R":

#--#
# testQAReport.R: test quality control report
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
testQAReport <-
function(dataset = "My Dataset",
  title   = "Quality Report",
  date= "October, 2011",
  author  = "Christian Stratowa",
  outdir  = file.path(getwd(), "TestQA"),
  ...)
{
## directory containing parts of QAReport.Rnw
indir <- file.path(path.package("xps"), "QC");

## create directory containing final QAReport.Rnw
if (!dir.create(outdir))
   stop("could not create report directory");
if (!dir.create(file.path(outdir, "inst")))
   stop("could not create report subdirectory 'inst'");
if (!dir.create(file.path(outdir, "inst", "doc")))
   stop("could not create report subdirectory 'doc'");
docdir <- file.path(outdir, "inst", "doc");

QCb <- readLines(file.path(indir, "QC.begin.Rnw"));

## replace title, date, author
QCb <- sub("@TITLE@",  title,  QCb);
QCb <- sub("@DATE@",   date,   QCb);
QCb <- sub("@AUTHOR@", author, QCb);

## dataset info
numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
QCb <- sub("@DATASET@",  dataset,  QCb);
QCb <- sub("@NUMTREES@", numtrees, QCb);
QCb <- sub("@CHIPNAME@", chipname, QCb);
QCb <- sub("@CHIPTYPE@", chiptype, QCb);

write(QCb, file.path(docdir, "QAReport.Rnw"));

QCe <- readLines(file.path(indir, "QC.end.Rnw"));
QCe <- sub("@DATASET@",  dataset,  QCe);
QCe <- gsub("_","_", QCe);

write(QCe, file.path(docdir, "QAReport.Rnw"), append=TRUE);

## build vignette QC.pdf
if (require(tools)) {
   buildVignettes(dir=outdir, lib.loc=NULL, quiet=FALSE, clean=FALSE);
}#if
}#xpsQAReport

#--#

The file "QC.begin.Rnw" is as follows:

\documentclass{article}


\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in

\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}

\begin{document}

\title{@TITLE@}
\date{@DATE@}
\author{@AUTHOR@}
\maketitle

\tableofcontents


\section{Introduction}

  This is the quality assessment report for the dataset '@DATASET@'. The
dataset consists of
  @NUMTREES@ Affymetrix @CHIPTYPE@ arrays of type '@CHIPNAME@'. \\

  This report was generated using function \Rfunction{xpsQAReport} of package
\xps. \\


The file "QC.end.Rnw" is as follows:

\section{Summary}

  The current quality report for dataset '@DATASET@' displays the most
important quality plots, using the
  default settings for most plots. Package \xps\ contains additional plots
which can be used for further
  quality assessments. \\


\section*{Session Information:}

<>=
sessionInfo()
@

\end{document}


Finally, the output which is located in TestQA/inst/doc/QAReport.Rnw is as
follows:

\documentclass{article}


\textwidth=6.2in
\textheight=8.5in
%\parskip=.3cm
\oddsidemargin=.1in
\evensidemargin=.1in
\headheight=-.3in

\newcommand{\Rfunction}[1]{{\texttt{#1}}}
\newcommand{\Rmethod}[1]{{\texttt{#1}}}
\newcommand{\Rcode}[1]{{\texttt{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textsf{#1}}}
\newcommand{\Rclass}[1]{{\textit{#1}}}
\newcommand{\Cclass}[1]{{\textit{#1}}}
\newcommand{\Rexten}[1]{{\textit{#1}}}
\newcommand{\xps}{\Rpackage{xps}}
\newcommand{\ROOT}{\Robject{ROOT}}

\begin{document}

\title{Quality Report}
\date{October, 2011}
\author{Christian Stratowa}
\maketitle

\tableofcontents


\section{Introduction

Re: [Rd] Error when using buildVignettes()

[Henrik Bengtsson]

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 source tree.  FYI, lots of changes were made to these
tools in R 3.0.0, which may explain why you didn't see them before
(not saying it was correct usage before either).

I'd say, use Sweave/Stangle "manually" and then pass it on to tools::texi2pdf().


1. For *.Rnw -> *.tex -> *.pdf, you can use R.rsp::compileRnw() that
does all this in one go with more sanity checks.

2. Instead of using all those sub("@TITLE@",  title, ...) coding to
generate the report Rnw from a main Rnw template, add a layer of RSP
markup and run it through the RSP compiler.  For instance, with a
template.Rnw.rsp containing:

 This is the quality assessment report for the dataset '<%=dataset%>'.
The dataset consists of
 <%=numtrees%> Affymetrix <%=chiptype%> arrays of type '<%=chipname%>'.

you can compile it all in one go into a final PDF by pdf <-
R.rsp::rfile("template.Rnw.rsp").  RSP supports <%@include
file="..."%> statements and more if you wish to bring multiple Rnw
templates into a final one.  See help("R.rsp") for vignettes etc.


On Wed, Aug 28, 2013 at 3:10 PM, cstrato  wrote:
> 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 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:
>>>
>>> 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 get this error in earlier versions of R, could you please
>>> tell me what may be the reason for this error?
>>>
>>>
>>> Here is the code for "testQAReport.R":
>>>
>>>
>>> #--#
>>> # testQAReport.R: test quality control report
>>> # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>> -
>>> - -
>>> testQAReport <-
>>> function(dataset = "My Dataset",
>>>   title   = "Quality Report",
>>>   date= "October, 2011",
>>>   author  = "Christian Stratowa",
>>>   outdir  = file.path(getwd(), "TestQA"),
>>>   ...)
>>> {
>>> ## directory containing parts of QAReport.Rnw
>>> indir <- file.path(path.package("xps"), "QC");
>>>
>>> ## create directory containing final QAReport.Rnw
>>> if (!dir.create(outdir))
>>>stop("could not create report directory");
>>> if (!dir.create(file.path(outdir, "inst")))
>>>stop("could not create report subdirectory 'inst'");
>>> if (!dir.create(file.path(outdir, "inst", "doc")))
>>>stop("could not create report subdirectory 'doc'");
>>> docdir <- file.path(outdir, "inst", "doc");
>>>
>>> QCb <- readLines(file.path(indir, "QC.begin.Rnw"));
>>>
>>> ## replace title, date, author
>>> QCb <- sub("@TITLE@",  title,  QCb);
>>> QCb <- sub("@DATE@",   date,   QCb);
>>> QCb <- sub("@AUTHOR@", author, QCb);
>>>
>>> ## dataset info
>>> numtrees <- 6; chipname <- "Test3"; chiptype <- "GeneChip";
>>> QCb <- sub("@DATASET@",  dataset,  QCb);
>>> QCb <- sub("@NUMTREES@", numtrees, QCb);
>>> QCb <- sub("@CHIPNAME@", chipname, QCb);
>>> QCb <- sub("@CHIPTYPE@", chiptype, QCb);
>>>
>>> write(QCb, file.path(docdir, "QAReport.Rnw"));
>>>
>>> QCe <- readLines(file.path(indir, "QC.end.Rnw"));
>>> QCe <- sub("@DATASET@",  dataset,  QCe);
>>> QCe <- gsub("_","_", QCe);
>>>
>>> write(QCe, file.path(docdir, "QAReport.Rnw"), append=TRUE);
>>>
>>> ## build vignette QC.pdf
>>> if (require(tools)) {
>>>buildVignettes(dir=outdir, lib.loc=NULL, quiet=FALSE,
>>> clean=FALSE);
>>> }#if
>>> }#xpsQAReport
>>>
>>>
>>> #--#
>>>
>>> The file "QC.begin.Rnw" is as follows:
>>>
>>> \documentclass{article}
>>>
>>>
>>> \textwidth=6.2in
>>> \textheight=8.5in
>>> %\parskip=.3cm
>>> \oddsidemargin=.1in
>>> \evensidemargin=.1in
>>> \headheight=-.3in
>>>
>>> \newcommand{\Rfunction}[1]{{\texttt{#1}}}
>>> \newcommand{\Rmethod}[1]{{\texttt{#1}}}
>>> \newcommand{\Rcode

Re: [Rd] ':::' call

[Mark.Bravington]

<< 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, just don't put your package 
> on CRAN, where I get most of my packages.  Then we'll both be happy.
> 

Fine. BTW, when will CRAN be removing the C(omprehensive) from its name?

CRAN can never offer any guarantee that code works properly. Lots of code on 
CRAN doesn't, that's why packages have bug-fix releases all the time. And 
packages sometimes change the functionality even of functions that they *do* 
export. I certainly don't blindly trust stuff I download from CRAN; code aside, 
lots of it has excruciating documentation which hardly inspires faith. Nor do I 
blame CRAN for hosting bad code. CRAN is just a library; libraries are not 
responsible for the content of the books they hold.

With respect specifically to ::: : to guard against functionality changes of 
the type mentioned, B just needs to use a strict version check on A's package 
in the NAMESPACE. When A updates on CRAN, B will realize that the new version 
needs to be checked (because B's package will refuse to load on systems using 
the new version of A), and B can check functionality and amend their version 
check.

Adding yet more options about limited exports etc is not a good idea, I think. 
R's structure is REALLY complicated, particularly when it comes to packages. 
There is already too much stuff, too many different ways to do things. That is 
probably one reason why there is so much confusion and indeed so many bad 
choices from maintainers. Adding yet more techno-fixes is liable to be 
counterproductive.

Still in the case of :::, I agree with Yihui Xie that CRAN should not bother 
worrying about it. A Note would be OK if it weren't that Notes have a nasty 
habit of somehow turning into Warnings. In that respect: why not just have a 
separate package that has all sort of checks that anyone might ever want (I 
find most of them useless, but I know others like them), but that is 
independent of CRAN checks?

More generally, while the principles that CRAN espouses seemed OK to me last 
time I checked (eg  packages shouldn't mess each other up), the same is not 
true for the approach CRAN takes to them. The plethora of checks makes the 
whole thing legalistic: the criterion becomes not "is this package any good?" 
but "does it pass checks AA-ZZ?" So, for a maintainer with very limited time 
for arguments and who knows their own code and is well aware that the CRAN 
checks produce lots of False Positives and also False Negatives (there is lots 
of bad code out there...), it's hardly surprising if there is every temptation 
to just pop in a workaround.

If there was a much tighter, and well-explained, set of checks, then I reckon 
there would be fewer workarounds overall (because of a cultural shift, not just 
in terms of superfluous checks that have been removed) and there wouldn't be 
the need for lengthy dialogs between maintainers and CRAN. Notwithstanding the 
enormous efforts that the CRAN people put in (whoever they may be...): CRAN 
might be better off working with human nature(s), not against it.

bye
Mark

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
 

> -Original Message-
> From: r-devel-boun...@r-project.org 
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> Sent: Thursday, 29 August 2013 5:22 AM
> To: Kasper Daniel Hansen
> Cc: Marc Schwartz; R-devel@r-project.org; Paul Gilbert
> Subject: Re: [Rd] ':::' call
> 
> 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 functions (for expert use), other 
> > (expert) users might want access as well, so take the time 
> to export and document it.
> >
> > I want to use ::: specifically for the case where I have no control 
> > over the other package.
> 
> 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, just don't put your package 
> on CRAN, where I get most of my packages.  Then we'll both be happy.
> 
> Duncan Murdoch
> >
> > Best,
> > Kasper
> >
> >
> >
> >
> > On Wed, Aug 28, 2013 at 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:
> > 

Re: [Rd] ‘:::’ call

[Paul Gilbert]

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 the .Rd file strikes me as problematic. I'm
surprised CRAN checks do not already object to functions exported and
documented with \keyword{internal}.)


Why? I think this is exactly the use case of \keyword{internal}.



From Writing R extensions "The special keyword ‘internal’ marks a page 
of internal objects that are not part of the package’s API" which 
suggests to me that a function with \keyword{internal} should not be 
exported, since that makes it part of the API. And, if it is really for 
internal use in a package, why would you export it? I think you are 
interpreting "internal" to mean internal to a group of packages, not 
internal to a package. But that is just the complement of what I am 
saying: there may be a need for two levels of export.


(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.)


Paul

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Gabriel Becker]

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 something that is internal and not exported have a
documentation file at all?


>
> Paul
>
>
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ‘:::’ call

[Kasper Daniel Hansen]

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 first place.  Chances are that if you need access
>> to these hidden functions (for expert use), other (expert) users might
>> want
>> access as well, so take the time to export and document it.
>>
>> I want to use ::: specifically for the case where I have no control over
>> the other package.
>>
>
> 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.
>

Perhaps you have heard of the concept of "testing".  R actually has good
testing facilities (if you include add-on packages) and these facilities
are very helpful in checking whether the answers provided by a package are
correct. /sarcasm off

And btw. nothing guarantees that the output of an exported function does
not change when the package version change.  Only testing can help you here.

I don't know if CRAN re-checks a package if dependencies change, but
obviously it ought to, from a software validity point of view.

Best,
Kasper



> If you want to use :::, go ahead, just don't put your package on CRAN,
> where I get most of my packages.  Then we'll both be happy.
>
> Duncan Murdoch
>
>>
>> Best,
>> Kasper
>>
>>
>>
>>
>> On Wed, Aug 28, 2013 at 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 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 the checks:
>> >>>
>> >>> * checking dependencies in R code ... NOTE
>> >>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>> >>>   See the note in ?`:::` about the use of this operator. :: should be
>> >>>   used rather than ::: if the function is exported, and a package
>> >>>   almost never needs to use ::: for its own functions.
>> >>>
>> >>> Is there a preferred method to accomplish this in a way that does not
>> >>> produce a note?
>> >>>
>> >>> Thanks,
>> >>> Paul
>> >>>
>> >>
>> >>
>> >>
>> >> Paul,
>> >>
>> >> See this rather lengthy discussion that occurred within the past week:
>> >>
>> >>https://stat.ethz.ch/pipermail/r-devel/2013-August/**
>> **067180.html
>> 
>> >
>>
>> >>
>> >> Regards,
>> >>
>> >> Marc Schwartz
>> >>
>> >
>> > I did follow the recent discussion, but no one answered the question "Is
>> > there a preferred method to accomplish this?" (I suppose the answer is
>> that
>> > there is no other way, given that no one actually suggested anything
>> else.)
>> > Most of the on topic discussion in that thread was about how to subvert
>> the
>> > CRAN checks, which is not what I am trying to do and was also pointed
>> out
>> > as a bad idea by Duncan. The substantive response was
>> >
>> > >r63654 has fixed this particular issue, and R-devel will no longer
>> > >warn against the use of ::: on packages of the same maintainer.
>> > >
>> > >Regards,
>> > >Yihui
>> >
>> > but that strikes me as a temporary work around rather than a real
>> > solution: suppose plugins are provided by a package from another
>> maintainer.
>> >
>> > Since CRAN notes have a habit of becoming warnings and then errors, it
>> > seems useful to identify the preferred legitimate approach while this is
>> > still a note. That would save work for both package developers and CRAN
>> > maintainers.
>> >
>> > My thinking is that there is a need for a NAMESPACE directive something
>> > like limitedExport() that allows ::: for identified functions without
>> > provoking a CRAN complaint when packages use those functions. But there
>> may
>> > already be a better way I don't know about. Or perhaps the solution is
>> to
>> > split the end user functions and the utilities for plugin packages into
>> two
>> > separate packages?
>> >
>> > Paul
>> >
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> >
>> >
>>
>> [[alternative HTML version deleted]]
>>
>>
>>
>>
>> __**
>> R-dev