I believe you will find this is already fixed in R-patched and R-devel as
the logs say (2005-10-07)
r35790 Fixed a typo in aqua R code
and it seems to be that line.
On Thu, 3 Nov 2005, G. Sawitzki wrote:
See below.
gs.
Error in browse.pkgs("CRAN", "binary") : couldn't find function
"avaliable.packages"
Your version of R is up to date
browse.pkgs
function (repos = getOption("repos"), contriburl = contrib.url(repos,
type), type = getOption("pkgType"))
{
if (.Platform$GUI != "AQUA")
stop("this function is intended to work with the Aqua GUI")
x <- installed.packages()
i.pkgs <- as.character(x[, 1])
i.vers <- as.character(x[, 3])
label <- paste("(", type, ") @", contriburl)
y <- avaliable.packages(contriburl = contriburl)
c.pkgs <- as.character(y[, 1])
c.vers <- as.character(y[, 2])
idx <- match(i.pkgs, c.pkgs)
vers2 <- character(length(c.pkgs))
xx <- idx[which(!is.na(idx))]
vers2[xx] <- i.vers[which(!is.na(idx))]
i.vers <- vers2
want.update <- rep(FALSE, length(i.vers))
.Internal(pkgbrowser(c.pkgs, c.vers, i.vers, label, want.update))
}
<environment: namespace:utils>
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
At 15:44 +0000 03.11.2005, Prof Brian Ripley wrote:
I believe you will find this is already fixed in R-patched and
R-devel as the logs say (2005-10-07)
r35790 Fixed a typo in aqua R code
and it seems to be that line.
... but possibly it did not find its way into the version "R for Mac
OS X 2.2.0 released on 2005/10/18" ....
g.
At 15:44 +0000 03.11.2005, Prof Brian Ripley wrote:
I believe you will find this is already fixed in R-patched and R-devel as
the logs say (2005-10-07)
r35790 Fixed a typo in aqua R code
and it seems to be that line.
... but possibly it did not find its way into the version "R for Mac OS X
2.2.0 released on 2005/10/18" ....
R 2.2.0 was released on 2005-10-06, so it postdates that.
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
See below.
gs.
Error in browse.pkgs("CRAN", "binary") : couldn't find function
"avaliable.packages"
You seem to have an old version of the R.app, because the R 2.2.0
release R GUI has a work-around for that problem. Please update your
R.app either from the R release or the nightly builds page:
http://research.att.com/~urbanek/R/
As Brian was saying, the error was fixed in R immediately after the
release - strangely enough no one reported the error during the alpha
and beta cycle although both the GUI and R binaries were available
for download :(.
Cheers,
Simon
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
"Simon" == Simon Urbanek <simon.urbanek at r-project.org>
on Thu, 3 Nov 2005 12:16:25 -0500 writes:
<............>
Simon> As Brian was saying, the error was fixed in R
Simon> immediately after the release - strangely enough no
Simon> one reported the error during the alpha and beta
Simon> cycle although both the GUI and R binaries were
Simon> available for download :(.
Unfortunately, the phrase "strangely enough" could be replaced with
``as almost always''.
Maybe we (the R-foundation) should give serious thoughts to
offer prizes for valid bug reports during alpha and beta
testing. These could include
- Reduced fee for 'useR' and 'DSC' conferences
- being listed as helpful person in R's 'THANKS' file
{but that may not entice those who are already listed},
or even in the NEWS of the new relase
or on the "Hall of fame of R beta testers"
In order to discourage an increased number of non-bug reports we
may have to also open a "hall of shame" though...
Martin
Martin's point is generally very valid, but in the case of the 2.2.0
release remarkably few of the bugs found since release were new in 2.2.0.
One thing we have learnt is that none of the testers seem to look at HTML
help (which accounts for 2 of the 4 2.2.0-only bugs I counted).
What we need most is persistent help in testing each release, especially
on unusual platforms. How do we `incentivize' that?
On Fri, 4 Nov 2005, Martin Maechler wrote:
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
"Simon" == Simon Urbanek <simon.urbanek at r-project.org>
on Thu, 3 Nov 2005 12:16:25 -0500 writes:
<............>
Simon> As Brian was saying, the error was fixed in R
Simon> immediately after the release - strangely enough no
Simon> one reported the error during the alpha and beta
Simon> cycle although both the GUI and R binaries were
Simon> available for download :(.
Unfortunately, the phrase "strangely enough" could be replaced with
``as almost always''.
Maybe we (the R-foundation) should give serious thoughts to
offer prizes for valid bug reports during alpha and beta
testing. These could include
- Reduced fee for 'useR' and 'DSC' conferences
- being listed as helpful person in R's 'THANKS' file
{but that may not entice those who are already listed},
or even in the NEWS of the new relase
or on the "Hall of fame of R beta testers"
In order to discourage an increased number of non-bug reports we
may have to also open a "hall of shame" though...
Martin
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
On Nov 4, 2005, at 6:58 AM, Prof Brian Ripley wrote:
Martin's point is generally very valid, but in the case of the
2.2.0 release remarkably few of the bugs found since release were
new in 2.2.0.
One thing we have learnt is that none of the testers seem to look
at HTML help (which accounts for 2 of the 4 2.2.0-only bugs I
counted).
What we need most is persistent help in testing each release,
especially on unusual platforms. How do we `incentivize' that?
I suspect that in the particular case of OS X the problem was
probably visibility - it was the first time ever that nightly OS X
binaries were available during alpha/beta phase (afaict), but I'm not
sure how many people knew about it. I think posted about it on R-SIG-
Mac during some discussion, but maybe I should have announced it more
specifically somewhere. I'm, not even sure whether there was a link
from the main page on CRAN. I would think that OS X users are more
likely to rely on binaries, so the above is more relevant than on
other platforms.
- being listed as helpful person in R's 'THANKS' file
{but that may not entice those who are already listed},
or even in the NEWS of the new relase
or on the "Hall of fame of R beta testers"
The latter sounds good to me, although I'm not sure how many of our
users are striving for fame ;).
Cheers,
Simon
On Fri, Nov 04, 2005 at 09:58:47AM +0100, Martin Maechler wrote:
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
I'll take up the invitation to brainstorm.
As a user of R for a number of years, I'd really like to perform some
useful service. I use a relatively obscure platform (FreeBSD) and I
can compile code. I'd like to think that I'm in the target market for
beta testing :). But, I'm timid. I do not feel, in general, that R
core welcomes bug reports.
I think that there are several things that could be tried to encourage
more, and more useful, bug reports.
1) Put the following text on the *front page* of the tracking system, so
that it is seen before the reader clicks on "New Bug Report":
"Before submitting a bug report, please read Chapter `R Bugs' of `The
R FAQ'. It describes what a bug is and how to report a bug.
If you are not sure whether you have observed a bug or not, it is a
good idea to ask on the mailing list R-Help by sending an e-mail to
r-help at stat.math.ethz.ch rather than submitting a bug report."
(BTW is this true also for alpha/beta testing?)
2) Try to use the structure of the reporting page to prompt good
reporting. On the report page, summarize the key points of
identifying and reporting a bug in a checklist format. Maybe even
insist that the boxes be checked before allowing submission.
Include seperate text boxes for description and sample code, to
suggest that sample code is valued.
3) On either or both pages (and in FAQ), explain that thoughtful bug
reports are valued and appreciated. Further, explain that bug
reports that do not follow the protocol are less valuable, and take
more time.
4) Add checkboxes to the report page for alpha/beta. (I suggest this
for the purposes of marketing, not organization.)
5) On the report page, include hyperlinks to archived bug reports that
were good. Do likewise with some artificial bug reports that are
bad.
6) Add an intermediate, draft step for bug submission, to allow
checking. If possible, include as part of this step an automated
pattern matching call that identifies similarly texted bug reports,
provides links to the reports, and invites a last-minute cross-check.
7) Keep a list of people who report useful bugs in alpha/beta phase on
the website. Many academics could point to it as evidence of
community service.
In order to discourage an increased number of non-bug reports we
may have to also open a "hall of shame" though...
8) I'm sure that you're being ironic! But I will take the point
seriously, for what it's worth. I think that humiliating
submitters who haven't followed the protocol is deleterious. It
seems like almost every month we see someone get slapped on the
wrist for not doing something the right way. Of course, it's
frustrating that people aren't following the posting guide. But,
why is that? Where is the breakdown? It might be interesting to
try some follow-up (an exit interview!). If someone has failed to
follow the protocol, perhaps we should try to find out why it was
confusing, or if they just ignored it.
The R-core is surrounded by, and serves, a community that comprises
people who are not sufficiently good at what R-core does to be
invited in to R-core. But, we're clearly interested in what R-core
produces. Please don't assume that bug submissions that do not
follow the R protocol are the consequence of deliberate
malfeasance.
To paraphrase Ian Fleming: Once is happenstance. Twice is
incompetence. The third time, Mr. Bond, is enemy action. So, ...
9) Publicly thank bug reporters whether their reports are useful or
not. I just googled 'R-devel thank' and you figure prominently,
Martin :).
Cheers
Andrew
Andrew Robinson
Senior Lecturer in Statistics Tel: +61-3-8344-9763
Department of Mathematics and Statistics Fax: +61-3-8344-4599
University of Melbourne, VIC 3010 Australia
Email: a.robinson at ms.unimelb.edu.au Website: http://www.ms.unimelb.edu.au
Hi Martin,
On Fri, Nov 04, 2005 at 09:58:47AM +0100, Martin Maechler wrote:
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
I'll take up the invitation to brainstorm.
As a user of R for a number of years, I'd really like to perform some
useful service. I use a relatively obscure platform (FreeBSD) and I
can compile code. I'd like to think that I'm in the target market for
beta testing :). But, I'm timid. I do not feel, in general, that R
core welcomes bug reports.
I think that there are several things that could be tried to encourage
more, and more useful, bug reports.
1) Put the following text on the *front page* of the tracking system, so
that it is seen before the reader clicks on "New Bug Report":
"Before submitting a bug report, please read Chapter `R Bugs' of `The
R FAQ'. It describes what a bug is and how to report a bug.
If you are not sure whether you have observed a bug or not, it is a
good idea to ask on the mailing list R-Help by sending an e-mail to
r-help at stat.math.ethz.ch rather than submitting a bug report."
(BTW is this true also for alpha/beta testing?)
2) Try to use the structure of the reporting page to prompt good
reporting. On the report page, summarize the key points of
identifying and reporting a bug in a checklist format. Maybe even
insist that the boxes be checked before allowing submission.
Include seperate text boxes for description and sample code, to
suggest that sample code is valued.
...and a optional field to select one or several packages related to the
bug. This is a good place to clarify that problems related to
third-party packages should not be reporter "here". Example HTML code:
Package(s) related to the bug, if applicable:<br>
(Bugs related to packages not listed below should <em>not</em> be
reported here. Instead, contact the package manager.)
<select name="packages" multiple>
<option value="">- - Select one or more packages related to the bug -
-</option>
<option value="base">base (Base R functions)</option>
<option value="datasets">datasets (Base R datasets)</option>
<option value="grDevices">grDevices (Graphics devices for base and grid
graphics)</option>
<option value="graphics">graphics (R functions for base graphics)</option>
<option value="grid">grid (A rewrite of the graphics layout
capabilities, plus some support for interaction)</option>
<option value="methods">methods (Formally defined methods and classes
for R objects, plus other programming tools, as described in the Green
Book)</option>
<option value="splines">splines (Regression spline functions and
classes)</option>
<option value="stats">stats (R statistical functions)</option>
<option value="stats4">stats4 (Statistical functions using S4
classes)</option>
<option value="tcltk">tcltk (Interface and language bindings to Tcl/Tk
GUI elements)</option>
<option value="tools">tools (Tools for package development and
administration)</option>
<option value="utils">utils (R utility functions)</option>
</select>
/Henrik
3) On either or both pages (and in FAQ), explain that thoughtful bug
reports are valued and appreciated. Further, explain that bug
reports that do not follow the protocol are less valuable, and take
more time.
4) Add checkboxes to the report page for alpha/beta. (I suggest this
for the purposes of marketing, not organization.)
5) On the report page, include hyperlinks to archived bug reports that
were good. Do likewise with some artificial bug reports that are
bad.
6) Add an intermediate, draft step for bug submission, to allow
checking. If possible, include as part of this step an automated
pattern matching call that identifies similarly texted bug reports,
provides links to the reports, and invites a last-minute cross-check.
7) Keep a list of people who report useful bugs in alpha/beta phase on
the website. Many academics could point to it as evidence of
community service.
In order to discourage an increased number of non-bug reports we
may have to also open a "hall of shame" though...
8) I'm sure that you're being ironic! But I will take the point
seriously, for what it's worth. I think that humiliating
submitters who haven't followed the protocol is deleterious. It
seems like almost every month we see someone get slapped on the
wrist for not doing something the right way. Of course, it's
frustrating that people aren't following the posting guide. But,
why is that? Where is the breakdown? It might be interesting to
try some follow-up (an exit interview!). If someone has failed to
follow the protocol, perhaps we should try to find out why it was
confusing, or if they just ignored it.
The R-core is surrounded by, and serves, a community that comprises
people who are not sufficiently good at what R-core does to be
invited in to R-core. But, we're clearly interested in what R-core
produces. Please don't assume that bug submissions that do not
follow the R protocol are the consequence of deliberate
malfeasance.
To paraphrase Ian Fleming: Once is happenstance. Twice is
incompetence. The third time, Mr. Bond, is enemy action. So, ...
9) Publicly thank bug reporters whether their reports are useful or
not. I just googled 'R-devel thank' and you figure prominently,
Martin :).
Cheers
Andrew
On Fri, Nov 04, 2005 at 09:58:47AM +0100, Martin Maechler wrote:
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
[SNIP]
2) Try to use the structure of the reporting page to prompt good
reporting. On the report page, summarize the key points of
identifying and reporting a bug in a checklist format. Maybe even
insist that the boxes be checked before allowing submission.
Include seperate text boxes for description and sample code, to
suggest that sample code is valued.
...and a optional field to select one or several packages related to the
bug. This is a good place to clarify that problems related to
third-party packages should not be reporter "here". Example HTML code:
Package(s) related to the bug, if applicable:<br>
(Bugs related to packages not listed below should <em>not</em> be
reported here. Instead, contact the package manager.)
Perhaps there should be no attempt to swim upstream here.
Why not just have the bug-reporter forward the report to
the maintainer? From user perspective, they would have a
single point to report bugs.
I'm not advocating increasing manual processing of bug
reports by R Core, rather that an alternative to the
problem [of package bug reports] may exist.
----------------------------------------------------------
SIGSIG -- signature too long (core dumped)
Thanks a lot,
Andrew, for your input!
A general point about your suggestions: You seem to assume that
bug reports are typically entered via the R-bugs web interface
(which is down at the moment and for a few more dozen hours probably},
rather than via R's builtin bug.report() function or the
simple e-mail to R-bugs at r-project.org [[which will also not
properly work for the moment, as long as the bug repository is
suffering from a fiber cable cut in Kopenhagen]].
For some dinosaurs like me, having to fill a web page rather
than sending e-mail would be quite a loss of comfort, but
actually, it might not be a bad idea to require a unique
bug-entry interface -- actually we have been thinking of moving
to bugzilla -- if only Peter Dalgaard could find a smart enough
person (even to be paid) who'd port all the old bug reports into the
new format..
"Andrew" == Andrew Robinson <A.Robinson at ms.unimelb.edu.au>
on Sun, 6 Nov 2005 11:01:30 +1100 writes:
Andrew> Hi Martin, On Fri, Nov 04, 2005 at 09:58:47AM +0100,
Andrew> Martin Maechler wrote:
>> [Mainly for R-foundation members; but kept in public for
>> general brainstorming...]
Andrew> I'll take up the invitation to brainstorm.
good, thank
Andrew> As a user of R for a number of years, I'd really
Andrew> like to perform some useful service. I use a
Andrew> relatively obscure platform (FreeBSD) and I can
Andrew> compile code. I'd like to think that I'm in the
Andrew> target market for beta testing :).
indeed!
Andrew> But, I'm timid. I do not feel, in general, that R core welcomes bug
Andrew> reports.
I think that's a partly wrong feeling; understandibly nourished
by some of our reactions about some "bug reports" that stemmed
from user misconceptions. As you've remarked below, I've
expressed gratitude more than once for helpful bug reports.
Andrew> I think that there are several things that could be
Andrew> tried to encourage more, and more useful, bug
Andrew> reports.
Andrew> 1) Put the following text on the *front page* of the
Andrew> tracking system, so that it is seen before the
Andrew> reader clicks on "New Bug Report":
Andrew> "Before submitting a bug report, please read Chapter
Andrew> `R Bugs' of `The R FAQ'. It describes what a bug is
Andrew> and how to report a bug.
Andrew> If you are not sure whether you have observed a bug
Andrew> or not, it is a good idea to ask on the mailing list
Andrew> R-Help by sending an e-mail to
Andrew> r-help at stat.math.ethz.ch rather than submitting a
Andrew> bug report."
Andrew> (BTW is this true also for alpha/beta testing?)
Yes, in principile. The only thing to be changed would be
sub("-help", "-devel", <the above text>)
Andrew> 2) Try to use the structure of the reporting page to
Andrew> prompt good reporting. On the report page,
Andrew> summarize the key points of identifying and
Andrew> reporting a bug in a checklist format. Maybe even
Andrew> insist that the boxes be checked before allowing
Andrew> submission. Include seperate text boxes for
Andrew> description and sample code, to suggest that sample
Andrew> code is valued.
Andrew> 3) On either or both pages (and in FAQ), explain
Andrew> that thoughtful bug reports are valued and
Andrew> appreciated. Further, explain that bug reports that
Andrew> do not follow the protocol are less valuable, and
Andrew> take more time.
Andrew> 4) Add checkboxes to the report page for alpha/beta.
Andrew> (I suggest this for the purposes of marketing, not
Andrew> organization.)
Andrew> 5) On the report page, include hyperlinks to
Andrew> archived bug reports that were good. Do likewise
Andrew> with some artificial bug reports that are bad.
Andrew> 6) Add an intermediate, draft step for bug
Andrew> submission, to allow checking. If possible, include
Andrew> as part of this step an automated pattern matching
Andrew> call that identifies similarly texted bug reports,
Andrew> provides links to the reports, and invites a
Andrew> last-minute cross-check.
Andrew> 7) Keep a list of people who report useful bugs in
Andrew> alpha/beta phase on the website. Many academics
Andrew> could point to it as evidence of community service.
>> In order to discourage an increased number of non-bug
>> reports we may have to also open a "hall of shame"
>> though...
Andrew> 8) I'm sure that you're being ironic!
indeed I was, partly. The point was just that if the bug
reporting will be something like a challenge with prizes, we had
to discourage too many entries {which would be made just to try
to win (a|the) prize}.
Andrew> 8) I'm sure that you're being ironic! But I will
Andrew> take the point seriously, for what it's worth. I
Andrew> think that humiliating submitters who haven't
Andrew> followed the protocol is deleterious. It seems like
Andrew> almost every month we see someone get slapped on the
Andrew> wrist for not doing something the right way. Of
Andrew> course, it's frustrating that people aren't
Andrew> following the posting guide. But, why is that?
Andrew> Where is the breakdown? It might be interesting to
Andrew> try some follow-up (an exit interview!). If someone
Andrew> has failed to follow the protocol, perhaps we should
Andrew> try to find out why it was confusing, or if they
Andrew> just ignored it.
Andrew> The R-core is surrounded by, and serves, a
Andrew> community that comprises people who are not
Andrew> sufficiently good at what R-core does to be invited
Andrew> in to R-core. But, we're clearly interested in what
Andrew> R-core produces. Please don't assume that bug
Andrew> submissions that do not follow the R protocol are
Andrew> the consequence of deliberate malfeasance.
Andrew> To paraphrase Ian Fleming: Once is happenstance.
Andrew> Twice is incompetence. The third time, Mr. Bond, is
Andrew> enemy action. So, ...
Andrew> 9) Publicly thank bug reporters whether their
Andrew> reports are useful or not. I just googled 'R-devel
Andrew> thank' and you figure prominently, Martin :).
Thanks again, Andrew,
for your useful input!
Martin
A general point about your suggestions: You seem to assume that
bug reports are typically entered via the R-bugs web interface
Yes, that was the premiss of my suggestions. Perhaps to supplement
these ideas, bug.report() could be rewritten to prompt useful
information, much as prompt() does. And simple e-mail to
R-bugs at r-project.org could be filtered to only allow entries from R
core, and/or a list of registered beta testers.
actually we have been thinking of moving to bugzilla -- if only
Peter Dalgaard could find a smart enough person (even to be paid)
who'd port all the old bug reports into the new format..
I see that this would be useful. What are the challenges? If funding
is available, then I wonder if any of the linked organizations might
be suitable?
http://www.bugzilla.org/support/consulting.html
As you've remarked below, I've expressed gratitude more than once
for helpful bug reports.
Absolutely, and the effect is appreciated. Sadly, the average user
struggles to distinguish between a helpful and an unhelpful bug report
before sending it.
indeed I was, partly. The point was just that if the bug
reporting will be something like a challenge with prizes, we had
to discourage too many entries {which would be made just to try
to win (a|the) prize}.
Yes, I see that. I really don't think that we need prizes; I really
do think that we need to create an environment that actively mitigates
against the kinds of error that you/we find so frustrating. A sort of
TQM strategy.
Cheers
Andrew
Andrew Robinson
Senior Lecturer in Statistics Tel: +61-3-8344-9763
Department of Mathematics and Statistics Fax: +61-3-8344-4599
University of Melbourne, VIC 3010 Australia
Email: a.robinson at ms.unimelb.edu.au Website: http://www.ms.unimelb.edu.au
actually, it might not be a bad idea to require a unique
bug-entry interface -- actually we have been thinking of moving
to bugzilla -- if only Peter Dalgaard could find a smart enough
person (even to be paid) who'd port all the old bug reports into the
new format..
If you haven't already it might worthwhile looking in to fogbugz and trac.
Fogbugz (http://www.fogcreek.com/FogBugz/) is a commercial bug
tracking software package. It is very professional and has been
designed to make tracking and submitting bugs as easy as possible
(sometimes you do get what you pay for).
Trac (http://www.edgewall.com/trac/) is more of an integrated software
development environment (open source) offering svn repository
browsing, a wiki and bug tracking. It makes it very easy to link
between bug reports and the commits that fix them (although I know
fogbugz does this too, and I'm sure bugzilla does as well).
Hadley