[Rd] How to create arbitrary number of loops
Dear R users,
I'm wondering how I can generate an arbitrary number of loops in R.
For instance, I can generate two for loops to get ICC among any two-way
combination among 10 variables. Here is the code
n-10
for (i in 1:(n-1))
{
for (j in (i+1):n)
{
icc(cbind(DATA[,i],DATA[,j]))
}
}
If I need three-way combination, then a code with three for loops will be:
n-10
for (i in 1:(n-2))
{
for (j in (i+1):(n-1))
{
for (k in (j+1):n)
{
icc(cbind(DATA[,i],DATA[,j],DATA[,k]))
}
}
}
But how can I write a code if I need all m=2, 3, 4,... loops for arbitrary
m-way combinations?
Thanks!
Daisy
Electronic mail from Children's Mercy Hospitals and Clinics. This communication
is intended only for the use of the addressee. It may contain information that
is privileged or confidential under applicable law. If you are not the intended
recipient or the agent of the recipient, you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly prohibited.
If you have received this communication in error, please immediately forward
the message to Children's Mercy Hospital's Information Security Officer via
return electronic mail at informationsecurityoffi...@cmh.edu and expunge this
communication without making any copies. Thank you for your cooperation.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Wed, Mar 28, 2012 at 11:52 PM, Thomas Lumley tlum...@uw.edu wrote: On Thu, Mar 29, 2012 at 3:30 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: 2012/3/28 Uwe Ligges lig...@statistik.tu-dortmund.de: On 27.03.2012 20:33, Jeffrey Ryan wrote: Thanks Uwe for the clarification on what goes and what stays. Still fuzzy on the notion of significant though. Do you have an example or two for the list? We have to look at those notes again and again in order to find if something important is noted, hence please always try to avoid all notes unless the effect is really intended! Consider the Note No visible binding for global variable We cannot know if your code intends to use such a global variable (which is undesirable in most cases), hence would let is pass if it seems to be sensible. Another Note such as empty section or partial argument match can quickly be fixed, hence just do it and don't waste our time. Best, Uwe Ligges What is the point of notes vs warnings if you have to get rid of both of them? Furthermore, if there are notes that you don't have to get rid of its not fair that package developers should have to waste their time on things that are actually acceptable. Finally, it makes the whole system arbitrary since packages can be rejected based on undefined rules. The notes are precisely the things for which clear rules can't be written. They are reported by CMD check because they are usually signs of coding errors, but are not warnings because their use is sometimes justified. The 'No visible binding for global variable is a good example. This found some bugs in my 'survey' package, which I removed. There is still one note of this type, which arises when I have to handle two different versions of the hexbin package with different internal structures. The note is a false positive because the use is guarded by an if(), but CMD check can't tell this. So, it's a good idea to remove all Notes that can be removed without introducing other code problems, which is nearly all of them, but occasionally there may be a good reason for code that produces a Note. But if you want a simple, unambiguous, mechanical rule for *your* packages, just eliminate all Notes. I think it would be more objective and also easiest for everyone if notes were accepted. It might be that over time some notes could be split into multiple cases some of which are warnings and others continue to be notes. That way package developers don't have to waste their time on getting rid of notes which don't matter and the CRAN maintainers can turn the task of reviewing notes over to the computer. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote: The 'No visible binding for global variable is a good example. This found some bugs in my 'survey' package, which I removed. There is still one note of this type, which arises when I have to handle two different versions of the hexbin package with different internal structures. The note is a false positive because the use is guarded by an if(), but CMD check can't tell this. So, it's a good idea to remove all Notes that can be removed without introducing other code problems, which is nearly all of them, but occasionally there may be a good reason for code that produces a Note. 'occasionally' seems like an understatement. Here's an example: data(cars) lm(speed ~ dist,cars) #would produce global variables NOTE lm(speed ~ dist,cars) # would not produce the NOTE While the change required to avoid the CRAN NOTE is small, I can't think of a single example or text on using formulas that recommends quoting the formula as a best practice. I'm not sure how users or package authors are supposed to know that they should use a (non standard) way of specifying the formula to avoid wasting their time, and the CRAN volunteers time. I'm certain that there are many other examples, but this one was easy to demonstrate. Regards, - Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create arbitrary number of loops
That sounds like a job for recursion.
And also, a question for r-help and not r-devel.
Sarah
On Wed, Mar 28, 2012 at 5:34 PM, Dai, Hongying, h...@cmh.edu wrote:
Dear R users,
I'm wondering how I can generate an arbitrary number of loops in R.
For instance, I can generate two for loops to get ICC among any two-way
combination among 10 variables. Here is the code
n-10
for (i in 1:(n-1))
{
for (j in (i+1):n)
{
icc(cbind(DATA[,i],DATA[,j]))
}
}
If I need three-way combination, then a code with three for loops will be:
n-10
for (i in 1:(n-2))
{
for (j in (i+1):(n-1))
{
for (k in (j+1):n)
{
icc(cbind(DATA[,i],DATA[,j],DATA[,k]))
}
}
}
But how can I write a code if I need all m=2, 3, 4,... loops for arbitrary
m-way combinations?
Thanks!
Daisy
--
Sarah Goslee
http://www.functionaldiversity.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Mar 29, 2012, at 14:58 , Brian G. Peterson wrote: On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote: The 'No visible binding for global variable is a good example. This found some bugs in my 'survey' package, which I removed. There is still one note of this type, which arises when I have to handle two different versions of the hexbin package with different internal structures. The note is a false positive because the use is guarded by an if(), but CMD check can't tell this. So, it's a good idea to remove all Notes that can be removed without introducing other code problems, which is nearly all of them, but occasionally there may be a good reason for code that produces a Note. 'occasionally' seems like an understatement. Here's an example: data(cars) lm(speed ~ dist,cars) #would produce global variables NOTE lm(speed ~ dist,cars) # would not produce the NOTE Context, please. Where does this happen? (and why do you need data(cars)?) I find it hard to believe that quoting the formula should be the solution to this issue. There must be tons of examples to the contrary. While the change required to avoid the CRAN NOTE is small, I can't think of a single example or text on using formulas that recommends quoting the formula as a best practice. I'm not sure how users or package authors are supposed to know that they should use a (non standard) way of specifying the formula to avoid wasting their time, and the CRAN volunteers time. I'm certain that there are many other examples, but this one was easy to demonstrate. Regards, - Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On 03/29/2012 05:00 AM, r-devel-requ...@r-project.org wrote:
The 'No visible binding for global variable is a good example. This
found some bugs in my 'survey' package, which I removed. There is
still one note of this type, which arises when I have to handle two
different versions of the hexbin package with different internal
structures. The note is a false positive because the use is guarded
by an if(), but CMD check can't tell this. So, it's a good idea to
remove all Notes that can be removed without introducing other code
problems, which is nearly all of them, but occasionally there may be a
good reason for code that produces a Note.
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y - as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages. There
used to be half a dozen but I've tried to remove as many as possible,
for all the good reasons already articulated by the maintainers.
It still remains that 99/100 of the no visible binding messages I've
seen over the years were misspelled variable names, and the message is a
very welcome check.
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On 29 March 2012 at 07:58, Brian G. Peterson wrote: | On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote: | The 'No visible binding for global variable is a good example. This | found some bugs in my 'survey' package, which I removed. There is | still one note of this type, which arises when I have to handle two | different versions of the hexbin package with different internal | structures. The note is a false positive because the use is guarded | by an if(), but CMD check can't tell this. So, it's a good idea to | remove all Notes that can be removed without introducing other code | problems, which is nearly all of them, but occasionally there may be a | good reason for code that produces a Note. | | 'occasionally' seems like an understatement. | | Here's an example: | | data(cars) | lm(speed ~ dist,cars) #would produce global variables NOTE | lm(speed ~ dist,cars) # would not produce the NOTE | | While the change required to avoid the CRAN NOTE is small, I can't think | of a single example or text on using formulas that recommends quoting | the formula as a best practice. I'm not sure how users or package | authors are supposed to know that they should use a (non standard) way | of specifying the formula to avoid wasting their time, and the CRAN | volunteers time. I'm certain that there are many other examples, but | this one was easy to demonstrate. And it's close to my personal favourite of with( cars, ... some expression involving dist and / or speed ... ) which gives the same warning about dist and speed being unknown globals. Punishment for good coding style -- gotta love it. Now, we all want high-quality packages. We all strive to have as few false positives. And we all understand that writing a parser if freaking hard. One fudge-y way of helping with this may be via an overrides file. This is what Debian does to suppress known / tolerated violations of what the 'lintian' package checker picks up on. For the R package, I have a fair number of these: the file for the r-base-core binary is currently 83 lines long and this ends on r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rdiff r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/mai.png r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/oma.png r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/pch.png r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rd2pdf two warnings on files with 755 modes in a non-PATH location (fine, that's how R works) and idem with image files below /usr/lib (when the FHS probably prefers them below /usr/share/). You pipe the output of a lintian run into 'lintian-info' and you get longer one or two paragraph descriptions with further pointers on the violations. Does this sounds like something worthwhile to add to the R CMD check system ? Should we consider to allow overrides to make known good exceptions good away? Dirk -- R/Finance 2012 Conference on May 11 and 12, 2012 at UIC in Chicago, IL See agenda, registration details and more at http://www.RinFinance.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On 3/29/2012 7:07 AM, Dirk Eddelbuettel wrote: On 29 March 2012 at 07:58, Brian G. Peterson wrote: | On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote: | The 'No visible binding for global variable is a good example. This | found some bugs in my 'survey' package, which I removed. There is | still one note of this type, which arises when I have to handle two | different versions of the hexbin package with different internal | structures. The note is a false positive because the use is guarded | by an if(), but CMD check can't tell this. So, it's a good idea to | remove all Notes that can be removed without introducing other code | problems, which is nearly all of them, but occasionally there may be a | good reason for code that produces a Note. | | 'occasionally' seems like an understatement. | | Here's an example: | | data(cars) | lm(speed ~ dist,cars) #would produce global variables NOTE | lm(speed ~ dist,cars) # would not produce the NOTE Another example using library(ggplot2): =qplot(time., value, data=X, geom='line', facets=facets, color=variable, xlim=xlim, ylim=ylim, xlab='days', ylab='displacement (inches)', ...), value and variable are columns of X. If I knew how to list this in an overrides file, I would do so. My experience is similar to what others mentioned: 99 percent of the No visible bindings messages I've seen are my coding errors. This one is not. I don't recall for sure, but I think I checked trying putting value and variable in quotes, and it didn't work. The function that includes this call to qplot actually includes the definition of a global variable time., which is NOT used, because X has a column named time.. The global variable time. is a character string, while X$time. is class POSIXct. I mention this, because this discussion suddenly told me how to get rid of this NOTE: Precede this call to qplot with something like the following: value - variable - NOTE: Define these variables to override the NOTE impulse in R CMD check' I haven't tried this with qplot, but it ignores the global variable Time. and uses the Time. column of X, so it should work. I just tried something similar with lm, and it ignored a global variable in favor of a column of X. This is a silly kludge, but it's simple and does not require a modification to R CMD check. Spencer | | While the change required to avoid the CRAN NOTE is small, I can't think | of a single example or text on using formulas that recommends quoting | the formula as a best practice. I'm not sure how users or package | authors are supposed to know that they should use a (non standard) way | of specifying the formula to avoid wasting their time, and the CRAN | volunteers time. I'm certain that there are many other examples, but | this one was easy to demonstrate. And it's close to my personal favourite of with( cars, ... some expression involving dist and / or speed ... ) which gives the same warning about dist and speed being unknown globals. Punishment for good coding style -- gotta love it. Now, we all want high-quality packages. We all strive to have as few false positives. And we all understand that writing a parser if freaking hard. One fudge-y way of helping with this may be via an overrides file. This is what Debian does to suppress known / tolerated violations of what the 'lintian' package checker picks up on. For the R package, I have a fair number of these: the file for the r-base-core binary is currently 83 lines long and this ends on r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rdiff r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/mai.png r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/oma.png r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/pch.png r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rd2pdf two warnings on files with 755 modes in a non-PATH location (fine, that's how R works) and idem with image files below /usr/lib (when the FHS probably prefers them below /usr/share/). You pipe the output of a lintian run into 'lintian-info' and you get longer one or two paragraph descriptions with further pointers on the violations. Does this sounds like something worthwhile to add to the R CMD check system ? Should we consider to allow overrides to make known good exceptions good away? Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Terry Therneau
Sent: Thursday, March 29, 2012 7:02 AM
To: r-devel@r-project.org
Subject: Re: [Rd] CRAN policies
On 03/29/2012 05:00 AM, r-devel-requ...@r-project.org wrote:
The 'No visible binding for global variable is a good example. This
found some bugs in my 'survey' package, which I removed. There is
still one note of this type, which arises when I have to handle two
different versions of the hexbin package with different internal
structures. The note is a false positive because the use is guarded
by an if(), but CMD check can't tell this. So, it's a good idea to
remove all Notes that can be removed without introducing other code
problems, which is nearly all of them, but occasionally there may be a
good reason for code that produces a Note.
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y - as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages.
Suppose we defined a function like
NO_VISIBLE_BINDING(expr) expr
and added an entry to the stuff in codetools so that it
would not check for misspelled object names in call to
NO_VISIBLE_BINDING. Then Terry could write that line as
if (class(x) == chron) { y - as.numeric(x -
NO_VISIBLE_BINDING(chron)(01/01/1960)}
and the Notes would disappear.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
There
used to be half a dozen but I've tried to remove as many as possible,
for all the good reasons already articulated by the maintainers.
It still remains that 99/100 of the no visible binding messages I've
seen over the years were misspelled variable names, and the message is a
very welcome check.
Terry Therneau
__
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] Vignettes and CRAN checks
I'l like to chime in on the subject of vignette checks. I have one vignette in the coxme library that would be better described as a white paper. It discusses the adequacy of the Laplace transform under various scenarios. It contains some substantial computations, so I'd like to mark it as never ever run this for both CRAN and my local builds, my next update of it will turn it into a 30+ minute compuatation. Almost all users will need only the pdf; however, my master file for creating it is .Rnw form and I'd like to make it available to those who might want to dig deeper. I (and every other program I know of) had always assumed that the Laplace approx was excellent for a mixed effects Cox model, I'm finding out that that there are a few cases where this isn't so. Luckily only a few, but this is important documentation. I also have more conventional vignettes of the how to use this package variety, the standard CRAN check process for those is both welcome and appropriate. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
William Dunlap wdunlap at tibco.com writes:
-Original Message-
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y - as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages.
Suppose we defined a function like
NO_VISIBLE_BINDING(expr) expr
and added an entry to the stuff in codetools so that it
would not check for misspelled object names in call to
NO_VISIBLE_BINDING. Then Terry could write that line as
if (class(x) == chron) { y - as.numeric(x - NO_VISIBLE_BINDING(chron)
(01/01/1960)}
and the Notes would disappear.
That's ok for package code, but what about test suites? Say there was a test
on the result of with(DF,a+b), you wouldn't want to change the test to with
(DF,NO_VISIBLE_BINDING(a)+NO_VISIBLE_BINDING(b)) not just because that's long
and onerous, but because that's *changing* the test i.e. introducing a
difference between what's tested and what user code will do.
As others suggested, how about a new category: MEMO. The no visible binding
NOTE would be downgraded to MEMO. CRAN maintainers could then ignore MEMOs more
easily.
What I really like about NOTES is that when new checks are added to R then as a
package maintainer you know you don't have to fix them straight away. If a new
WARNING shows up on r-devel daily checks, however, then you've got some warning
about the WARNING that you need to fix more urgently and may even accelerate a
release. So it's not just about checks when submitting a package, but what
happens afterwards as R itself (and packages in Depends) move on. In other
words, you know you need to fix new NOTES but not as urgently as new WARNINGS.
Matthew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Matthew Dowle
Sent: Thursday, March 29, 2012 10:41 AM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] CRAN policies
William Dunlap wdunlap at tibco.com writes:
-Original Message-
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y - as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages.
Suppose we defined a function like
NO_VISIBLE_BINDING(expr) expr
and added an entry to the stuff in codetools so that it
would not check for misspelled object names in call to
NO_VISIBLE_BINDING. Then Terry could write that line as
if (class(x) == chron) { y - as.numeric(x -
NO_VISIBLE_BINDING(chron)
(01/01/1960)}
and the Notes would disappear.
That's ok for package code, but what about test suites? Say there was a test
on the result of with(DF,a+b), you wouldn't want to change the test to with
(DF,NO_VISIBLE_BINDING(a)+NO_VISIBLE_BINDING(b)) not just because that's long
and onerous, but because that's *changing* the test i.e. introducing a
difference between what's tested and what user code will do.
I don't know if test suites need to be checked for no visible bindings -
if there is a real problem the test ought to fail.
codetools should be able to do special checks for known functions that
do not following the standard evaluation rules . E.g., do not check any
arguments of `~`, do not check the 'expr' argument of with, do not check
the subset or weights arguments of lm.
If a package writer introduces a new function with nonstandard evaluation,
perhaps the package could include some information about the matter
in a file that codetools could could source before running its checks.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
As others suggested, how about a new category: MEMO. The no visible binding
NOTE would be downgraded to MEMO. CRAN maintainers could then ignore MEMOs
more
easily.
What I really like about NOTES is that when new checks are added to R then as
a
package maintainer you know you don't have to fix them straight away. If a new
WARNING shows up on r-devel daily checks, however, then you've got some
warning
about the WARNING that you need to fix more urgently and may even accelerate a
release. So it's not just about checks when submitting a package, but what
happens afterwards as R itself (and packages in Depends) move on. In other
words, you know you need to fix new NOTES but not as urgently as new WARNINGS.
Matthew
__
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] How to create arbitrary number of loops
On Wed, Mar 28, 2012 at 5:34 PM, Dai, Hongying, h...@cmh.edu wrote:
Dear R users,
I'm wondering how I can generate an arbitrary number of loops in R.
For instance, I can generate two for loops to get ICC among any two-way
combination among 10 variables. Here is the code
n-10
for (i in 1:(n-1))
{
for (j in (i+1):n)
{
icc(cbind(DATA[,i],DATA[,j]))
}
}
If I need three-way combination, then a code with three for loops will
be:
n-10
for (i in 1:(n-2))
{
for (j in (i+1):(n-1))
{
for (k in (j+1):n)
{
icc(cbind(DATA[,i],DATA[,j],DATA[,k]))
}
}
}
But how can I write a code if I need all m=2, 3, 4,... loops for arbitrary
m-way combinations?
Thanks!
Daisy
For your specific specific case,
combn(10, m, function(v) icc(DATA[,v]))
My 'v' is your c(i,j) or c(i,j,k), etc.
In general, Sarah is right, recursion gives the neater code, and this
discussion probably doesn't belong here.
It can be achieved without recursion; I'd gladly share code that does the
equivalent of combn (which is what Daisy is asking for) both ways. I wrote
it many years ago in C, and the non-recursive code is probably the only
time I used the 'goto' statement :-)
/Christian
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On 3/29/2012 11:29 AM, William Dunlap wrote:
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Matthew Dowle
Sent: Thursday, March 29, 2012 10:41 AM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] CRAN policies
William Dunlapwdunlapat tibco.com writes:
-Original Message-
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y- as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages.
Suppose we defined a function like
NO_VISIBLE_BINDING(expr) expr
and added an entry to the stuff in codetools so that it
would not check for misspelled object names in call to
NO_VISIBLE_BINDING. Then Terry could write that line as
if (class(x) == chron) { y- as.numeric(x - NO_VISIBLE_BINDING(chron)
(01/01/1960)}
and the Notes would disappear.
That's ok for package code, but what about test suites? Say there was a test
on the result of with(DF,a+b), you wouldn't want to change the test to with
(DF,NO_VISIBLE_BINDING(a)+NO_VISIBLE_BINDING(b)) not just because that's long
and onerous, but because that's *changing* the test i.e. introducing a
difference between what's tested and what user code will do.
I don't know if test suites need to be checked for no visible bindings -
if there is a real problem the test ought to fail.
codetools should be able to do special checks for known functions that
do not following the standard evaluation rules . E.g., do not check any
arguments of `~`, do not check the 'expr' argument of with, do not check
the subset or weights arguments of lm.
If a package writer introduces a new function with nonstandard evaluation,
perhaps the package could include some information about the matter
in a file that codetools could could source before running its checks.
This gets my vote -- but I don't have the bandwidth nor authority
to effect the change ;-) Spencer
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
As others suggested, how about a new category: MEMO. The no visible binding
NOTE would be downgraded to MEMO. CRAN maintainers could then ignore MEMOs
more
easily.
What I really like about NOTES is that when new checks are added to R then as a
package maintainer you know you don't have to fix them straight away. If a new
WARNING shows up on r-devel daily checks, however, then you've got some warning
about the WARNING that you need to fix more urgently and may even accelerate a
release. So it's not just about checks when submitting a package, but what
happens afterwards as R itself (and packages in Depends) move on. In other
words, you know you need to fix new NOTES but not as urgently as new WARNINGS.
Matthew
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
codetools should be able to do special checks for known functions that
do not following the standard evaluation rules . E.g., do not check any
arguments of `~`, do not check the 'expr' argument of with, do not check
the subset or weights arguments of lm.
If a package writer introduces a new function with nonstandard evaluation,
perhaps the package could include some information about the matter
in a file that codetools could could source before running its checks.
This gets my vote -- but I don't have the bandwidth nor authority
to effect the change ;-) Spencer
Most of that stuff is already in codetools, at least when it is checking
functions
with checkUsage(). E.g., arguments of ~ are not checked. The expr argument
to with() will not be checked if you add skipWith=FALSE to the call to
checkUsage.
library(codetools)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}))
anonymous: no visible binding for global variable 'Num' (:1)
anonymous: no visible binding for global variable 'Den' (:1)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
anonymous: no visible binding for global variable 'DataFrame'
The only part that I don't see is the mechanism to add code-walker functions to
the environment in codetools that has the standard list of them for functions
with
nonstandard evaluation:
objects(codetools:::collectUsageHandlers, all=TRUE)
[1] $ $- .Internal
[4] ::::: @
[7] @- { ~
[10] -- =
[13] assignbinomial bquote
[16] data detachexpression
[19] for function Gamma
[22] gaussian iflibrary
[25] local poisson quasi
[28] quasibinomial quasipoisson quote
[31] Quote require substitute
[34] with
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: Spencer Graves [mailto:spencer.gra...@prodsyse.com]
Sent: Thursday, March 29, 2012 12:22 PM
To: William Dunlap
Cc: Matthew Dowle; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] CRAN policies
On 3/29/2012 11:29 AM, William Dunlap wrote:
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On
Behalf
Of Matthew Dowle
Sent: Thursday, March 29, 2012 10:41 AM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] CRAN policies
William Dunlapwdunlapat tibco.com writes:
-Original Message-
The survival package has a similar special case: the routines for
expected population survival are set up to accept multiple types of date
format so have lines like
if (class(x) == 'chron') { y- as.numeric(x - chron(01/01/1960)}
This leaves me with two extraneous no visible binding messages.
Suppose we defined a function like
NO_VISIBLE_BINDING(expr) expr
and added an entry to the stuff in codetools so that it
would not check for misspelled object names in call to
NO_VISIBLE_BINDING. Then Terry could write that line as
if (class(x) == chron) { y- as.numeric(x -
NO_VISIBLE_BINDING(chron)
(01/01/1960)}
and the Notes would disappear.
That's ok for package code, but what about test suites? Say there was a
test
on the result of with(DF,a+b), you wouldn't want to change the test to
with
(DF,NO_VISIBLE_BINDING(a)+NO_VISIBLE_BINDING(b)) not just because that's
long
and onerous, but because that's *changing* the test i.e. introducing a
difference between what's tested and what user code will do.
I don't know if test suites need to be checked for no visible bindings -
if there is a real problem the test ought to fail.
codetools should be able to do special checks for known functions that
do not following the standard evaluation rules . E.g., do not check any
arguments of `~`, do not check the 'expr' argument of with, do not check
the subset or weights arguments of lm.
If a package writer introduces a new function with nonstandard evaluation,
perhaps the package could include some information about the matter
in a file that codetools could could source before running its checks.
This gets my vote -- but I don't have the bandwidth nor authority
to effect the change ;-) Spencer
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
As others suggested, how about a new category: MEMO. The no visible
binding
NOTE would be downgraded to MEMO. CRAN maintainers could then ignore MEMOs
more
easily.
What I really like about NOTES is that when new checks are added to R then
as a
package maintainer you
Re: [Rd] CRAN policies
Most of that stuff is already in codetools, at least when it is checking
functions
with checkUsage(). E.g., arguments of ~ are not checked. The expr argument
to with() will not be checked if you add skipWith=FALSE to the call to
checkUsage.
library(codetools)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}))
anonymous: no visible binding for global variable 'Num' (:1)
anonymous: no visible binding for global variable 'Den' (:1)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
anonymous: no visible binding for global variable 'DataFrame'
The only part that I don't see is the mechanism to add code-walker functions
to
the environment in codetools that has the standard list of them for functions
with
nonstandard evaluation:
objects(codetools:::collectUsageHandlers, all=TRUE)
[1] $ $- .Internal
[4] :: ::: @
[7] @- { ~
[10] - - =
[13] assign binomial bquote
[16] data detach expression
[19] for function Gamma
[22] gaussian if library
[25] local poisson quasi
[28] quasibinomial quasipoisson quote
[31] Quote require substitute
[34] with
It seems like we really need a standard way to add metadata to functions:
attr(with, special_args) - expr
attr(lm, special_args) - c(formula, weights, subset)
This would be useful because it could automatically contribute to the
documentation.
Similarly,
attr(my.new.method, s3method) - c(my.new, method)
could be useful.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r-forge build failure bafflement
I am attempting to build a package on r-forge and running into a weird error. I have been in correspondence with the R-forge admins and am turning to r-devel on the remote chance that someone might have a guess as to what is going wrong or a suggestion about further diagnostics/experiments I could try ... The package seems to build fine on my system(s) with R CMD build --compact-vignettes --resave-data=best pkg (these are the R-forge build arguments, according to the r-forge admins) -- I've tried it with R-devel on Linux-32 and R 2.14.2 on MacOS-64. The build log (basically identical across linux64/win64/macos64) is as follows: -- Thu Mar 29 20:15:21 2012: Building tarball for package glmmADMB (SVN revision 204) using R version 2.14.2 (2012-02-29) ... * checking for file 'glmmADMB/DESCRIPTION' ... OK * preparing 'glmmADMB': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * re-saving image files Error in loadNamespace(name) : there is no package called 'glmmADMB' Execution halted Run time: 0.51 seconds. -- so apparently the package is failing because it doesn't exist (!!) I originally thought this was a circular dependency problem, because glmmADMB and coefplot2 (another r-forge package) depended on each other, but I have (at least for now) removed glmmADMB's coefplot2 dependency. As far as I can tell there are *no* packages on r-forge that depend on/suggest/import glmmADMB. a1 - available.packages(contriburl= contrib.url(http://r-forge.r-project.org;)) rownames(a1)[glmmADMB %in% a1[,Suggests]] character(0) rownames(a1)[glmmADMB %in% a1[,Depends]] character(0) rownames(a1)[glmmADMB %in% a1[,Imports]] character(0) The perhaps-relevant parts of the DESCRIPTION file: = BuildVignettes: no Description: Fits mixed-effects models using a variety of distributions Imports: stats, nlme Depends: R (= 2.13), methods, MASS, R2admb Suggests: lattice, lme4, lme4.0, coda, mlmRev, scapeMCMC, ggplot2, bbmle, pscl, knitr, car = The only other thing I can think of is backing up a few SVN revisions and seeing whether I can get back to a working version, but I'd like to see if I can get it fixed by moving forward rather than backward ... For anyone who is intrigued and wants to investigate farther: http://r-forge.r-project.org/R/?group_id=847 http://r-forge.r-project.org/scm/?group_id=847 cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-forge build failure bafflement
On 29.03.2012 22:54, Ben Bolker wrote: I am attempting to build a package on r-forge and running into a weird error. I have been in correspondence with the R-forge admins and am turning to r-devel on the remote chance that someone might have a guess as to what is going wrong or a suggestion about further diagnostics/experiments I could try ... The package seems to build fine on my system(s) with R CMD build --compact-vignettes --resave-data=best pkg (these are the R-forge build arguments, according to the r-forge admins) -- I've tried it with R-devel on Linux-32 and R 2.14.2 on MacOS-64. The build log (basically identical across linux64/win64/macos64) is as follows: -- Thu Mar 29 20:15:21 2012: Building tarball for package glmmADMB (SVN revision 204) using R version 2.14.2 (2012-02-29) ... * checking for file 'glmmADMB/DESCRIPTION' ... OK * preparing 'glmmADMB': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * re-saving image files Error in loadNamespace(name) : there is no package called 'glmmADMB' Execution halted Untested: Get rid of .First.lib and use .onAttach - you have a NAMESPACE. Uwe Run time: 0.51 seconds. -- so apparently the package is failing because it doesn't exist (!!) I originally thought this was a circular dependency problem, because glmmADMB and coefplot2 (another r-forge package) depended on each other, but I have (at least for now) removed glmmADMB's coefplot2 dependency. As far as I can tell there are *no* packages on r-forge that depend on/suggest/import glmmADMB. a1- available.packages(contriburl= contrib.url(http://r-forge.r-project.org;)) rownames(a1)[glmmADMB %in% a1[,Suggests]] character(0) rownames(a1)[glmmADMB %in% a1[,Depends]] character(0) rownames(a1)[glmmADMB %in% a1[,Imports]] character(0) The perhaps-relevant parts of the DESCRIPTION file: = BuildVignettes: no Description: Fits mixed-effects models using a variety of distributions Imports: stats, nlme Depends: R (= 2.13), methods, MASS, R2admb Suggests: lattice, lme4, lme4.0, coda, mlmRev, scapeMCMC, ggplot2, bbmle, pscl, knitr, car = The only other thing I can think of is backing up a few SVN revisions and seeing whether I can get back to a working version, but I'd like to see if I can get it fixed by moving forward rather than backward ... For anyone who is intrigued and wants to investigate farther: http://r-forge.r-project.org/R/?group_id=847 http://r-forge.r-project.org/scm/?group_id=847 cheers Ben Bolker __ 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] CRAN policies
I'm concerned this thread is heading the wrong way, towards techno-fixes for
imaginary problems. R package-building is already encumbered with a huge set of
complicated rules, and more instructions/rules eg for metadata would make
things worse not better.
RCMD CHECK on the 'mvbutils' package generates over 300 Notes about no visible
binding..., which inevitably I just ignore. They arise because RCMD CHECK is
too stupid to understand one of my preferred coding idioms (I'm not going to
explain what-- that's beside the point). And RCMD CHECK always will be too
stupid to understand everything that a rich language like R might quite
reasonably cause experienced coders to do.
It should not be CRAN's business how I write my code, or even whether my code
does what it is supposed to. It might be CRAN's business to try to work out
whether my code breaks CRAN's policies, eg by causing R to crash horribly--
that's presumably what Warnings are for (but see below). And maybe there could
be circumstances where an automatic check might be worried enough to alert
the CRANia and require manual explanation and emails etc from a developer, but
even that seems doomed given the growing deluge of packages.
RCMD CHECK currently functions both as a sanitizer for CRAN, and as a
developer-tool. But the fact that the one programl does both things seems
accidental to me, and I think this dual-use is muddying the discussion. There's
a big distinction between (i) code-checks that developers themselves might or
might not find useful-- which should be left to the developer, and will vary
from person to person-- and (ii) code-checks that CRAN enforces for its own
peace-of-mind. Maybe it's convenient to have both functions in the same place,
and it'd be fine to use Notes for one and Warnings for the other, but the
different purposes should surely be kept clear.
Personally, in building over 10 packages (only 2 on CRAN), I haven't found RCMD
CHECK to be of any use, except for the code-documentation and example-running
bits. I know other people have different opinions, but that's the point:
one-size-does-not-fit-all when it comes to coding tools.
And wrto the Warnings themselves: I feel compelled to point out that it's
logically impossible to fully check whether R code will do bad things. One has
to wonder at what point adding new checks becomes futile or counterproductive.
There must be over 2000 people who have written CRAN packages by now; every
extra check and non-back-compatible additional requirement runs the risk of
generating false-negatives and incurring many extra person-hours to fix
non-problems. Plus someone needs to document and explain the check (adding to
the rule mountain), plus there is the time spent in discussions like this..!
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of Hadley Wickham [had...@rice.edu]
Sent: 30 March 2012 07:42
To: William Dunlap
Cc: r-de...@stat.math.ethz.ch; Spencer Graves
Subject: Re: [Rd] CRAN policies
Most of that stuff is already in codetools, at least when it is checking
functions
with checkUsage(). E.g., arguments of ~ are not checked. The expr argument
to with() will not be checked if you add skipWith=FALSE to the call to
checkUsage.
library(codetools)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}))
anonymous: no visible binding for global variable 'Num' (:1)
anonymous: no visible binding for global variable 'Den' (:1)
checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~ Pred}),
skipWith=TRUE)
anonymous: no visible binding for global variable 'DataFrame'
The only part that I don't see is the mechanism to add code-walker functions
to
the environment in codetools that has the standard list of them for functions
with
nonstandard evaluation:
objects(codetools:::collectUsageHandlers, all=TRUE)
[1] $ $- .Internal
[4] ::::: @
[7] @- { ~
[10] -- =
[13] assignbinomial bquote
[16] data detachexpression
[19] for function Gamma
[22] gaussian iflibrary
[25] local poisson quasi
[28] quasibinomial quasipoisson quote
[31] Quote require substitute
[34] with
It seems like we really need a standard way to add metadata to functions:
attr(with, special_args) - expr
attr(lm, special_args) - c(formula, weights, subset)
This would be useful because it could automatically contribute to the
documentation.
Similarly,
attr(my.new.method, s3method) - c(my.new, method)
could be useful.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics
Re: [Rd] CRAN policies
On 12-03-29 09:29 PM, mark.braving...@csiro.au wrote: I'm concerned this thread is heading the wrong way, towards techno-fixes for imaginary problems. R package-building is already encumbered with a huge set of complicated rules, and more instructions/rules eg for metadata would make things worse not better. RCMD CHECK on the 'mvbutils' package generates over 300 Notes about no visible binding..., which inevitably I just ignore. They arise because RCMD CHECK is too stupid to understand one of my preferred coding idioms (I'm not going to explain what-- that's beside the point). Actually, I think that is the point. If your code is generating that many notes then I think you should explain your idiom, so the checks can be made to accommodate it if it really is good. Otherwise, I'd be worried about the quality of your code. And RCMD CHECK always will be too stupid to understand everything that a rich language like R might quite reasonably cause experienced coders to do. Possibly the interpreter is too stupid to understand it too? It should not be CRAN's business how I write my code, or even whether my code does what it is supposed to. It might be CRAN's business to try to work out whether my code breaks CRAN's policies, eg by causing R to crash horribly-- that's presumably what Warnings are for (but see below). And maybe there could be circumstances where an automatic check might be worried enough to alert the CRANia and require manual explanation and emails etc from a developer, but even that seems doomed given the growing deluge of packages. RCMD CHECK currently functions both as a sanitizer for CRAN, and as a developer-tool. But the fact that the one programl does both things seems accidental to me, and I think this dual-use is muddying the discussion. There's a big distinction between (i) code-checks that developers themselves might or might not find useful-- which should be left to the developer, and will vary from person to person-- I think this a case of two heads are better than one. I did lots of checks before the CRAN checks existed, but the CRAN checks still found bugs in code that I considerer very mature, including bugs in code has been running without noticeable problems for over 15 years. Despite all the noise today, most of us are only talking about a small inconvenience around the intended meaning of note, not about whether quality control is a bad thing. I've found the errors and warnings are always valid, even though I do not always like having to fix the bugs, and the notes are most often valid too. But there are a few false positives, so the checks that give notes are not yet reliable enough to give warnings or errors. But they should be sometime, so one should usually consider fixing the package code. and (ii) code-checks that CRAN enforces for its own peace-of-mind. I think of this as being for the piece-of-mind of your package users. Maybe it's convenient to have both functions in the same place, and it'd be fine to use Notes for one and Warnings for the other, but the different purposes should surely be kept clear. Personally, in building over 10 packages (only 2 on CRAN), I haven't found RCMD CHECK to be of any use, except for the code-documentation and example-running bits. I know other people have different opinions, but that's the point: one-size-does-not-fit-all when it comes to coding tools. And wrto the Warnings themselves: I feel compelled to point out that it's logically impossible to fully check whether R code will do bad things. One has to wonder at what point adding new checks becomes futile or counterproductive. There must be over 2000 people who have written CRAN packages by now; every extra check and non-back- compatible additional requirement runs the risk of generating false- negatives and incurring many extra person-hours to fix non-problems. Plus someone needs to document and explain the check (adding to the rule mountain), plus there is the time spent in discussions like this..! Bugs in your packages will require users to waste a lot of time too, and possibly reach faulty results with much more serious consequences. Just because perfection may never be attained, this does not mean that progress should not be attempted, in small steps. Compared to Statlib, which basicly followed your recommended approach, CRAN is a vast improvement. Paul Mark Mark Bravington CSIRO CMIS Marine Lab Hobart Australia From:r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Hadley Wickham [had...@rice.edu] Sent: 30 March 2012 07:42 To: William Dunlap Cc:r-de...@stat.math.ethz.ch; Spencer Graves Subject: Re: [Rd] CRAN policies Most of that stuff is already in codetools, at least when it is checking functions with checkUsage(). E.g., arguments of ~ are not checked. The expr argument to with() will not be checked if
Re: [Rd] CRAN policies
On 3/29/2012 8:39 PM, Paul Gilbert wrote: On 12-03-29 09:29 PM, mark.braving...@csiro.au wrote: I'm concerned this thread is heading the wrong way, towards techno-fixes for imaginary problems. R package-building is already encumbered with a huge set of complicated rules, and more instructions/rules eg for metadata would make things worse not better. RCMD CHECK on the 'mvbutils' package generates over 300 Notes about no visible binding..., which inevitably I just ignore. They arise because RCMD CHECK is too stupid to understand one of my preferred coding idioms (I'm not going to explain what-- that's beside the point). Actually, I think that is the point. If your code is generating that many notes then I think you should explain your idiom, so the checks can be made to accommodate it if it really is good. Otherwise, I'd be worried about the quality of your code. The R CMD check process is by far the best system I know for producing trustworthy software (Bill Chambers' term). I'm not leading researcher in software development, merely a guy who has written a fair amount of code over the past half century in a number of different languages. I'm now bald, having torn all my hair out trying to debug mountains of spaghetti code ;-) With R CMD check (including all those pesky notes), I get working code in a third the time (subjective guestimate) AND documentation I can had to others as a byproduct for free. I've been so impressed with it that I wrote the Wikipedia article on Package development process and added a table (with help from Sundar Dorai-Raj) to the Software repository article identifying software repositories for different languages, trying to suggest that users of other languages could benefit from developing some similar code quality checking system for other languages and accompanying repositories. I mention this, in case any of you know a researcher in information technology / computer science / software engineering who might be invited to do a comparison of R CMD check with what's available for other languages. I think it could help people writing code in other languages -- and it might even generate ideas to help the R community. Best Wishes, Spencer And RCMD CHECK always will be too stupid to understand everything that a rich language like R might quite reasonably cause experienced coders to do. Possibly the interpreter is too stupid to understand it too? It should not be CRAN's business how I write my code, or even whether my code does what it is supposed to. It might be CRAN's business to try to work out whether my code breaks CRAN's policies, eg by causing R to crash horribly-- that's presumably what Warnings are for (but see below). And maybe there could be circumstances where an automatic check might be worried enough to alert the CRANia and require manual explanation and emails etc from a developer, but even that seems doomed given the growing deluge of packages. RCMD CHECK currently functions both as a sanitizer for CRAN, and as a developer-tool. But the fact that the one programl does both things seems accidental to me, and I think this dual-use is muddying the discussion. There's a big distinction between (i) code-checks that developers themselves might or might not find useful-- which should be left to the developer, and will vary from person to person-- I think this a case of two heads are better than one. I did lots of checks before the CRAN checks existed, but the CRAN checks still found bugs in code that I considerer very mature, including bugs in code has been running without noticeable problems for over 15 years. Despite all the noise today, most of us are only talking about a small inconvenience around the intended meaning of note, not about whether quality control is a bad thing. I've found the errors and warnings are always valid, even though I do not always like having to fix the bugs, and the notes are most often valid too. But there are a few false positives, so the checks that give notes are not yet reliable enough to give warnings or errors. But they should be sometime, so one should usually consider fixing the package code. and (ii) code-checks that CRAN enforces for its own peace-of-mind. I think of this as being for the piece-of-mind of your package users. Maybe it's convenient to have both functions in the same place, and it'd be fine to use Notes for one and Warnings for the other, but the different purposes should surely be kept clear. Personally, in building over 10 packages (only 2 on CRAN), I haven't found RCMD CHECK to be of any use, except for the code-documentation and example-running bits. I know other people have different opinions, but that's the point: one-size-does-not-fit-all when it comes to coding tools. And wrto the Warnings themselves: I feel compelled to point out that it's logically impossible to fully check
Re: [Rd] r-forge build failure bafflement
We've seen similar things several times with CRAN submissions. Basic scenario was - INSTALL (via build or check) is trying to install a package that is not already installed, into a private library not on the usual .libPaths(). - Start-up code in that package is looking for the package, and does not respect lib[name] as passed to .First.lib or .onLoad/.onAttach. E.g. a call to installed.package() or packageDescription. - As the maintainer has an earlier version installed in .Library (s)he cannot reproduce it. I took a very quick look at the package: it has .First.lib and not .onLoad/.onAttach, and of course it has a namespace (all packages now do). I would start by fixing that. On 29/03/2012 21:54, Ben Bolker wrote: I am attempting to build a package on r-forge and running into a weird error. I have been in correspondence with the R-forge admins and am turning to r-devel on the remote chance that someone might have a guess as to what is going wrong or a suggestion about further diagnostics/experiments I could try ... The package seems to build fine on my system(s) with R CMD build --compact-vignettes --resave-data=best pkg (these are the R-forge build arguments, according to the r-forge admins) -- I've tried it with R-devel on Linux-32 and R 2.14.2 on MacOS-64. The build log (basically identical across linux64/win64/macos64) is as follows: -- Thu Mar 29 20:15:21 2012: Building tarball for package glmmADMB (SVN revision 204) using R version 2.14.2 (2012-02-29) ... * checking for file 'glmmADMB/DESCRIPTION' ... OK * preparing 'glmmADMB': * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files * checking for empty or unneeded directories * looking to see if a 'data/datalist' file should be added * re-saving image files Error in loadNamespace(name) : there is no package called 'glmmADMB' Execution halted Run time: 0.51 seconds. -- so apparently the package is failing because it doesn't exist (!!) I originally thought this was a circular dependency problem, because glmmADMB and coefplot2 (another r-forge package) depended on each other, but I have (at least for now) removed glmmADMB's coefplot2 dependency. As far as I can tell there are *no* packages on r-forge that depend on/suggest/import glmmADMB. a1- available.packages(contriburl= contrib.url(http://r-forge.r-project.org;)) rownames(a1)[glmmADMB %in% a1[,Suggests]] character(0) rownames(a1)[glmmADMB %in% a1[,Depends]] character(0) rownames(a1)[glmmADMB %in% a1[,Imports]] character(0) The perhaps-relevant parts of the DESCRIPTION file: = BuildVignettes: no Description: Fits mixed-effects models using a variety of distributions Imports: stats, nlme Depends: R (= 2.13), methods, MASS, R2admb Suggests: lattice, lme4, lme4.0, coda, mlmRev, scapeMCMC, ggplot2, bbmle, pscl, knitr, car = The only other thing I can think of is backing up a few SVN revisions and seeing whether I can get back to a working version, but I'd like to see if I can get it fixed by moving forward rather than backward ... For anyone who is intrigued and wants to investigate farther: http://r-forge.r-project.org/R/?group_id=847 http://r-forge.r-project.org/scm/?group_id=847 cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
