Skip to content

Several R vs S-Plus issues

4 messages · David Brahm, Thomas Lumley, Peter Dalgaard +1 more

#
Peter Dalgaard <p.dalgaard at biostat.ku.dk> wrote:
Grossly unfair, Peter!  And since you chose to vent your annoyance publicly,
I am responding publicly.  I spent several hours trying to build a coherent,
single-page summary of my observations over several weeks, and my reward is a
scolding for sending my email to the address given in the FAQ???  Jeez!  Just
delete it if it offends so much!
Not mentioned in the FAQ (section 9.2), nor anywhere else on CRAN that I can
find.  It sounds like r-bugs is some kind of automated system that cannot
handle non-standard formatting, is that it?  I assumed it was just read by a
human (the "bugs guy"), parsed, and handed out appropriately, sorry.
Then I don't understand how to communicate with the "development team", besides
just posting to the general discussion list.  Is every posting there really
read and handled by the right people?  I guess I fundamentally don't understand
your communication model, e.g. how my comment about subsetting (which isn't
strictly a "bug") gets to the guy who actually writes "[".
Likewise.  R-help sure is filled with a lot of negativity.

		       -- David Brahm (a215020 at agate.fmr.com)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
#
Some information that might be useful to readers of these lists
On Wed, 3 Oct 2001, David Brahm wrote:
R-bugs is an automated bugs repository. It's designed to make sure that
each bug is filed away separately and that we can check off which ones
have been fixed when the next release comes along.  It exists because we
found that bugs not fixed immediately often got forgotten. It also
assigns bug numbers that ensure all correspondence relevant to a
particular bug is filed together.

This means that multiple bugs in one report are a bit of a pain. They end
up filed in one place, so it's harder to check which bits of the report
are fixed.  It's particularly distracting when the same report contains
things that we intend to fix, things that we can't fix, things that are
already fixed and things that we don't want to fix.

It's not the end of the world, but it is a lot less effective than one
message per bug.
Two points: Yes, we really do read r-devel, so it's the right place for
feature requests and miscellaneous complaints that aren't bugs, just
infelicities.

Also, all email sent to r-bugs is automatically forwarded to r-devel.
Similarly r-announce is forwarded to r-devel and r-help. This means that
you should almost never send the same message to more than one R address.

R-devel is in fact the main place where R-bugs is read.  Various people go
over the repository from time to time, to make sure that there aren't
lurking problems, but most bugs get discussed and fixed
more-or-less immediately.


	-thomas


Thomas Lumley			Asst. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
#
David Brahm  <a215020 at agate.fmr.com> writes:
Sorry I cannot do that. I'm among the guys that actually try to fix
things once in a while. And has spent several *years* doing so.

And sorry for taking it out on you, but these things are recurrent.
The note was targeted at everybody.

(I don't think you'll find anything in the FAQ saying that bug
reports should be sent to r-help, though.)
Maybe the FAQ needs some points added on this, but it does talk about
reporting _a_ bug.

Let me explain: 

R-bugs is a semi-automatic bug-*filing* system, which attaches a
report number and keeps reports with similar numbers together. It
allows us to sort reports into categories, say "Language" and move
them to "Language-fixed" when they are fixed. We cannot fix everything
at once so we review unresolved reports occasionally and see if the
bug is still there (occasionally the bug gets fixed but noone updates
the repository) and maybe try another stab at isolating the problem.

The problem with a multiple report like yours is that it is cannot be
uniquely filed (although there's a TooMuchAtOnce category), but worse:
It lingers in the repository until every problem in it is resolved,
and there is no heading that can tell us at a glance what the report
is all about. Every time it is reviewed we have to read the whole
thing through to recall what the issues were and filter out those
questions that were already resolved, or previously decided to be
unresolvable. This makes the whole debugging process take much more
time.
If you mail to r-bugs, the report is copied to the R-devel list and
presumably read by the interested developers. A copy of this and any
follow-ups on the list get stored in the repository.
That one arguably *is* a bug (whereas the fact that R gets you a
missing result from indexing with a missing value is a design
improvement). 

For discussing the design of things, you could take up the issue on
the r-devel list as a normal topic. This may or may not spark some
discussion, which is about the best you can hope for. Obviously, noone
is *obliged* to change things according to your tastes.
Sorry if you feel that. I think there are others who actually feel
they are getting help.
#
I understand you feel shoked when you spend hours and hours compiling a
message with all bugs and differences you found between R and Splus. But,
please, understand that what you call the "development team" is just a group
of volunteers. This is *very* different than the "development team" of Splus
whose job is to develop the software for others, called "users". With GPL
software, like R, there is no clear limit between the "development team" and
the "users". When "users" reach you level of understanding of the software,
they are expected to become somehow part of the "development team". It means
that you should preferrably propose patches, that is, corrections for bugs
you found. If you cannot, then there are standard methods for submitting
bugs to the _fuzzy_ developers community. It is because everybody can take
part of the development that these methods (that you find too rigid) are
like that.

A last point. R is not a clone of Splus... It is just "not unlike Splus".
Thus, any difference is not necessarily a bug. But, since you did already a
good job there, why not to start making a pdf document that underlines all
differences between Splus and R? This document would be intended for
developers that translate Splus code to R code and vice versa. This sounds
great to me, because I am developing code for both Splus and R, and I
sometimes lose hours figuring out why my code works in R and not in Splus,
or the contrary.
Best regards,

Philippe Grosjean


...........]<(({?<...............<?}))><...............................
 ) ) ) ) )	 __               	 __
( ( ( ( ( 	|__)              	|  _
 ) ) ) ) )	|   hilippe       	|__)rosjean
( ( ( ( ( 	Marine Biol. Lab., ULB, Belgium
 ) ) ) ) )	                  	 __
( ( ( ( ( 	|\  /|            	|__)
 ) ) ) ) )	| \/ |ariculture &	|__)iostatistics
( ( ( ( (
 ) ) ) ) )	e-mail: phgrosje at ulb.ac.be or phgrosjean at sciviews.org
( ( ( ( ( 	SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )      tel: 00-32-2-650.29.70 (lab), 00-32-2-673.31.33 (home)
( ( ( ( (
 ) ) ) ) )      "I'm 100% confident that p is between 0 and 1"
( ( ( ( (                                  L. Gonick & W. Smith (1993)
 ) ) ) ) )
.......................................................................


-----Message d'origine-----
De : owner-r-help at stat.math.ethz.ch
[mailto:owner-r-help at stat.math.ethz.ch]De la part de David Brahm
Envoy? : mercredi 3 octobre 2001 18:57
? : p.dalgaard at biostat.ku.dk
Cc : r-help at stat.math.ethz.ch
Objet : Re: [R] Several R vs S-Plus issues
Peter Dalgaard <p.dalgaard at biostat.ku.dk> wrote:
Grossly unfair, Peter!  And since you chose to vent your annoyance publicly,
I am responding publicly.  I spent several hours trying to build a coherent,
single-page summary of my observations over several weeks, and my reward is
a
scolding for sending my email to the address given in the FAQ???  Jeez!
Just
delete it if it offends so much!
Not mentioned in the FAQ (section 9.2), nor anywhere else on CRAN that I can
find.  It sounds like r-bugs is some kind of automated system that cannot
handle non-standard formatting, is that it?  I assumed it was just read by a
human (the "bugs guy"), parsed, and handed out appropriately, sorry.
Then I don't understand how to communicate with the "development team",
besides
just posting to the general discussion list.  Is every posting there really
read and handled by the right people?  I guess I fundamentally don't
understand
your communication model, e.g. how my comment about subsetting (which isn't
strictly a "bug") gets to the guy who actually writes "[".
Likewise.  R-help sure is filled with a lot of negativity.

		       -- David Brahm (a215020 at agate.fmr.com)
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
_._


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._