Kevin,
I was glad to see your list. Some of the items were reasons for creating
some of the functions in Hmisc. summarize and mApply in conjunction with
llist handle labeling of output - this is actually quite tricky and the
Hmisc solution isn't perfect. Dropping unused factor levels by default
(with easy override) is an old battle and I agree with you completely that
for everyday data analysis I almost always want to do this. But I haven't
been able to convince anyone else about that, despite repeated attempts.
[.factor in Hmisc drops unused levels by default. To be honest, the one
place I've gotten into trouble with this default occasionally is in
multiple panels in lattice related to consistent assignment of line styles
and symbols across strata when the "groups" variable has missing cells
in
some panels.
I also share your views about namespaces. These have caused numerous
problems for me. It would be nice to have more of a mechanism to put
"feelers" out to the R user community when major changes are planned.
Namespaces seemed to appear on the scene quite quickly. I do see some
advantages for them though. By contrast, I have been very relieved that
S4 classes have not posed a problem for my code that relies on "old"
classes (totally unlike my experience with S-Plus) but any time changes
are made that involve some incompatibilies with old code there should be
some pause.
In Hmisc and Design I reference several functions that were not exported
from packages that now use namespaces. There is an elegant solution with
the package:::function notation, but I have been unable to use this
solution because I use one code base for all versions of R and S-Plus.
This notation generates syntax errors in all but late versions of R.
Let me add to the wish list the creation of some mechanism to better track
improvements and bug fixes in packages, such as a change log link by each
package's area in CRAN, or easy access to CVS information from there.
When I report bugs (e.g., in read.xport in foreign [due somewhat to
problems inherent with SAS's format] or ace or avas in acepack) it would
be nice to see some announcement when the bugs are resolved, or to easily
track this. Even a checkbox that the package maintainer has seen the bug
report even if she/he currently does not have time to work on it would be
very helpful, as would a notation that the bug report was found to be
"buggy".
Frank
---
Frank E Harrell Jr Professor and Chair School of Medicine
Department of Biostatistics Vanderbilt University
Frank E Harrell Jr writes:> Let me add to the wish list the creation of some mechanism to better track > improvements and bug fixes in packages, such as a change log link by each > package's area in CRAN, or easy access to CVS information from there. > When I report bugs (e.g., in read.xport in foreign [due somewhat to > problems inherent with SAS's format] or ace or avas in acepack) it would > be nice to see some announcement when the bugs are resolved, or to easily > track this. Even a checkbox that the package maintainer has seen the bug > report even if she/he currently does not have time to work on it would be > very helpful, as would a notation that the bug report was found to be > "buggy". >I highly agree with you on this. It would be very nice having a fully featured bug reporting system, where you could upload patches, discuss improvements on existing packages or on the R-core itself, request for features and so on. I think that Bugzilla (www.bugzilla.org) would suit these expectations very well. It is the bug tracking system used by huge projects like Mozilla (bugzilla.mozilla.org), Gentoo (bugs.gentoo.org), and Redhat (bugzilla.redhat.com), and based on my own experience I'd say it addresses most of the things you pointed out. It works (at least in Gentoo, which is the one I'm more used to working with) like this: someone files in a bug report. In the bug report itself one informs the type of the bug report (a bug, a feature improvement, a request to the developer), the severity, and any other relevant information. It is also possible to upload attachments (like proposed patches) or additional information on the report. The bug report then is assigned to a given group or, in the case of packages to the person who is in charge for mantaining it. Anyone then can read the bug report and make suggestions or propose fixes (see for example: http://bugs.gentoo.org/show_bug.cgi?id=30784 ). [As opposed to the current system, where the bug report can't even be linked to a website, and all the discussion should be done via the mailing lists]. The maintainer or any other other authorized developer can then accept or reject the proposed suggestions, close the bug as duplicate, as invalid or at least inform that he is aware of the problem and will work on it some time later. Just my two cents, -- []'s Fernando Henrique Ferraz P. da Rosa
On Sat, 17 Jan 2004 09:33:10 -0500, you wrote:>I also share your views about namespaces. These have caused numerous >problems for me. It would be nice to have more of a mechanism to put >"feelers" out to the R user community when major changes are planned.Changes always show up in r-devel (the main CVS branch, not the mailing list) first. Package developers should be keeping a relatively up to date copy of it around if they're doing things that are likely to break.>In Hmisc and Design I reference several functions that were not exported >from packages that now use namespaces. There is an elegant solution with >the package:::function notation,I'd recommend avoiding that as much as you can. If things aren't exported from a package, then the package writer is likely to feel free to change them without warning. It's much better to convince the package writer that they missed something in their export list.>but I have been unable to use this >solution because I use one code base for all versions of R and S-Plus. >This notation generates syntax errors in all but late versions of R.I think it's reasonable to restrict the availability of updates to your packages to the currently released R version. There are reasons why people might not be up to date (e.g. only doing upgrades at a specific time of year), but they'll still have access via CRAN to older versions of your package. Compatibility with S-PLUS is a lot harder, of course. Duncan Murdoch
> A lot of wishlist suggestions need at least cooperation from R-core, who > may not agree that a change is desirable even if someone else were to > write the code. A bug-tracking system for contributed packages is one > of the exceptions. There's nothing to stop some package developer(s) > created a bug tracking system and making accounts available to other > people(except the time, resources, security issues, etc).Absolutely, I'm just getting at the need for better ways to provide input to R-core for their consideration, perhaps. And I wish that a unified mechanism would exist for all package developers to use, with some incentives (or bug-tracking requirements for a package to be kept in CRAN).> > Keeping track of changes is harder. The CVS commit logs for foreign and > survival are with the log for R itself on > http://developer.r-project.org. > It's not even that hard to write R code to read the page and extract > entries relevant to that package. > > For CRAN to list changes to other packages would require cooperation > from all the package developers. If the maintainer of acepack isn't > sufficiently together to reply to your messages, he probably won't be > keeping up with other aspects of change tracking. Even trying to > extract a NEWS or Changelog file might not work -- eg for survival the > Changelog file is Terry Therneau's change log, not my log for changes to > the R port. > > -thomasGood points. -Frank