Re: [Rd] No RTFM?
Dear Gabor, I do not agree with your claim "In the case of the R list there is a larger potential demand for free help than resources to answer and without the usual monetary economics to allocate resources I believe that the functional purpose of rudeness here is to ration those resources and minimize duplication of questions" In fact, apart from the fact that rudeness should never be justified, I was amazed at the amount of time dedicated by some people to give unhelpful replies to dumb (and less dumb) questions (at least on R-devel). In my opinion this behaviour causes some damages to the whole R project for at least two reasons: 1. On the bug report side if you want to have a good percentage of true positive reports you should allow for a high percentage of false positive reports. But if people are scared to post you will lose the true positive together with false ones. 2. People that are potentially willing to contribute are discouraged to do it. Kind regards Simone On Fri, Aug 20, 2010 at 8:37 PM, Gabor Grothendieck wrote: > On Fri, Aug 20, 2010 at 2:12 PM, Paul Johnson > wrote: > > On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves > > wrote: > >> What do you think about adding a "No RTFM" policy to the R mailing > lists? > >> Per, "http://en.wikipedia.org/wiki/RTFM": > >> > > I think this is a great suggestion. > > > > I notice the R mailing list already has a gesture in this direction: > > "Rudeness and ad hominem comments are not acceptable. Brevity is OK." > > > > But the people who behave badly don't care about policies like this > > and they will keep doing what they do. > > Although it may seem hard to justify rudeness its often the case that > even the most bizarre behavior makes sense if you view it from the > perspective of that person. In the case of the R list there is a > larger potential demand for free help than resources to answer and > without the usual monetary economics to allocate resources I believe > that the functional purpose of rudeness here is to ration those > resources and minimize duplication of questions. If that is correct > one can predict that if civility were to become the norm on this list > then other rationing mechanisms would arise to replace it. > > For example, it might become the norm that most questions are not > answered or are answered less thoroughly or the list might be replaced > as the de facto goto medium for R questions by some other list or web > site so we have to be careful about unintended consequences. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C or Java code generation
Simon Urbanek пишет: On Aug 20, 2010, at 1:15 PM, Paul Johnson wrote: On Thu, Aug 19, 2010 at 5:47 AM, Vyacheslav Karamov wrote: x.ru>>> Hi All! I'm new to R and I need to know is it possible for R to generate C/C++ source code, Java byte code or native Win32 DLL like MatLab? Is there any posibility to use R without installing? I mean that I have my own application written in MS Visual C++ and I need to use R script in this app. I can install R and use it via DCOM, but it's not convenient for the end users of my program. Do your users have Web access? If so, you can set up an Rweb (or similar) server that could run the jobs for those users. I have one set up like that. Users transmit their code via http and can get results back in web page. I think you could probably program around the output management question, but I did not try to do it. I mean, something like "wget" could download the images directly, by-passing the http server. Rweb has been abandoned by its original author, but it can be made to work, and there are other, newer http server programs to run R. I have not tried them yet, mainly because my customers needed to run Rweb because their clients told them to use it. FWIW: FastRWeb uses Rserve as back-end and is in active development since we use it internally (it's wicked fast, scalable and supports data pre-loading and AJAX). Cheers, Simon No, we need to implement VAD and voice comparison, so RWeb is useless in this case. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
Hello, All: I think there is a logic to Gabor's perspective, especially regarding unintended consequences. For example, if the as a result of changing policy, our most creative and substantive contributors decide to reduce their level of contribution and are not effectively replaced by others, then it would be a great loss for humanity. This group, especially the R Core team and the R-devel community more generally, has been incredibly productive. The result is a substantive contribution to humanity. It would be a loss if any change reduced that. However, if rudeness is driving away potential contributors as was claimed, then this community might be more productive with a "no RTFM" policy. I accept that the experience of the Ubuntu Forums and LinuxQuestions.org may not be perfectly relevant to R, but I think they could provide some insight: I would expect them to have some of the same "rationing" problems as experienced on the R help lists. The exchange that generated my original comment on this was a question from "r.ookie" to R-Help. I don't know why this person chose to hide their real identity, but I was subsequently informed off line that the RTFM comment I saw was a response to an apparently rude reply by "r.ookie" to a previous suggestion by a regular contributor. I still think a better response is not to escalate: Either ignore the post or say something like, "I don't understand your question. Please provide a self-contained minimal example as suggested in the Posting Guide ... ." Best Wishes, Spencer On 8/21/2010 2:08 AM, Simone Giannerini wrote: Dear Gabor, I do not agree with your claim "In the case of the R list there is a larger potential demand for free help than resources to answer and without the usual monetary economics to allocate resources I believe that the functional purpose of rudeness here is to ration those resources and minimize duplication of questions" In fact, apart from the fact that rudeness should never be justified, I was amazed at the amount of time dedicated by some people to give unhelpful replies to dumb (and less dumb) questions (at least on R-devel). In my opinion this behaviour causes some damages to the whole R project for at least two reasons: 1. On the bug report side if you want to have a good percentage of true positive reports you should allow for a high percentage of false positive reports. But if people are scared to post you will lose the true positive together with false ones. 2. People that are potentially willing to contribute are discouraged to do it. Kind regards Simone On Fri, Aug 20, 2010 at 8:37 PM, Gabor Grothendieck wrote: On Fri, Aug 20, 2010 at 2:12 PM, Paul Johnson wrote: On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves wrote: What do you think about adding a "No RTFM" policy to the R mailing lists? Per, "http://en.wikipedia.org/wiki/RTFM": I think this is a great suggestion. I notice the R mailing list already has a gesture in this direction: "Rudeness and ad hominem comments are not acceptable. Brevity is OK." But the people who behave badly don't care about policies like this and they will keep doing what they do. Although it may seem hard to justify rudeness its often the case that even the most bizarre behavior makes sense if you view it from the perspective of that person. In the case of the R list there is a larger potential demand for free help than resources to answer and without the usual monetary economics to allocate resources I believe that the functional purpose of rudeness here is to ration those resources and minimize duplication of questions. If that is correct one can predict that if civility were to become the norm on this list then other rationing mechanisms would arise to replace it. For example, it might become the norm that most questions are not answered or are answered less thoroughly or the list might be replaced as the de facto goto medium for R questions by some other list or web site so we have to be careful about unintended consequences. __ 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] No RTFM?
Hello,
RTFM is a succinct and useful answer in many cases, yet somewhat
impolite. A not much more verbose verbose version of it, possibly still
more useful, and quite polite would be something like:
"Please, read rule #NN at http://www.r-project.org/posting-guide.html";
(asuming that paragraphs at the Posting Guide were numbered and number
NN would point to the paragraph "Do your homework before posting"):
* It includes the word "please".
* It increases awareness of the Posting Guide
* It provides a direct link to it.
* The information under such paragraph is very informative and helpful.
One of the purposes of the different R help lists should be serving as a
public relations platforms so as to promote the use of R.
Regards,
Carlos J. Gil Bellosta
http://www.datanalytics.com
On 08/21/2010 02:15 AM, Dr. David Kirkby wrote:
On 08/20/10 01:08 AM, Spencer Graves wrote:
What do you think about adding a "No RTFM" policy to the R mailing
lists? Per, "http://en.wikipedia.org/wiki/RTFM":
The Ubuntu Forums and LinuxQuestions.org, for instance, have instituted
"no RTFM" policies to promote a welcoming atmosphere.[8][9].
RTFM [and] "Go look on google" are two inappropriate responses to a
question. If you don't know the answer or don't wish to help, please say
nothing instead of brushing off someone's question. Politely showing
someone how you searched or obtained the answer to a question is
acceptable, even encouraged.
...
If you wish to remind a user to use search tools or other resources when
they have asked a question you feel is basic or common, please be very
polite. Any replies for help that contain language disrespectful towards
the user asking the question, i.e. "STFU" or "RTFM" are unacceptable and
will not be tolerated. —Ubuntu Forums
Gavin Simpson and I recently provided examples answering a question from
"r.ookie" that had previously elicited responses, ""You want us to read
the help page to you?" and "It yet again appears that you are asking us
to read the help pages for you."
I can appreciate the sentiment in fortunes('rtfm'). In this case,
however, "r.ookie" had RTFM (and said so), but evidently the manual was
not sufficiently clear.
Best Wishes,
Spencer Graves
I've personally found the R community somewhat unhelpful at times. In
fact, of all the resources I use:
* Newsgroups like comp.unix.shell, sci.math.symbolic, comp.unix.aix,
comp.unix.solaris
* Mailing lists for autoconf, automake, gcc, sage maths, ecl, time-nuts.
* Forums for OpenSolaris
I've found the r-devel about the least helpful of the lot.
My most recent example was when I created a bug report about a version
of R that was about 4 months old. The bug was that the configure test
failed to detect the version of libicu was unsuitable on Solaris. (Since
it was the version of the library shipped with Solaris, I would
personally have thought the configure script should detect its too old
if it is).
When submitting the bug, I selected the particular R version from the
pull-down menu, as it was listed.
Then I got some snotty reply about reading the FAQ and not submitting
bug reports for old versions of R. At the time I submitted it, I suspect
the version I had was about 4 months old. Ask on a Solaris mailing list
about a 5 year old version of Solaris and you will get civil replies.
Likewise, the gcc lists don't expect everyone to be running very recent
versions.
I would have like to have responded on the technical content of the
message, as I believe the autoconf test is flawed if it can't detect
that a version of a library installed by Sun is unsuitable. But I
decided that such responses were best ignored.
There's quite a bit in the R manual about Solaris that is just plain
wrong, but although I've reported some of the problems, these were
ignored, so I can't even be bothered to report the rest.
I must admit, I do sometimes give people links to
http://justfuckinggoogleit.com/
when I think they are being particularly dumb in not using Google, so I
do appreciate it can get annoying when people ask questions they should
be able to get answered themselves.
But it seems to me that arrogance is more normal on r-devel than on
other lists I use.
Thankfully, I don't have to use r-devel much.
Flames to /dev/null.
Dave
__
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] R-devel Digest, Vol 90, Issue 20
On 21/08/10 12:00, r-devel-requ...@r-project.org wrote:
On Aug 20, 2010, at 1:59 PM, Matt Shotwell wrote:
> On Fri, 2010-08-20 at 12:58 -0400, Sharpie wrote:
>>
>> Donald Paul Winston wrote:
(...)
>>
>> Donald Paul Winston wrote:
>>>
>>> It appears R insists on directing plot output to a file. Is their a
>>> graphics device that keeps the output in memory so it can be returned to
>>> my java app as a stream of bytes? If I have to wait for it to write to a
>>> "unique file" and then read it back again then I don't think that's going
>>> to work. My web app needs to support hundreds of concurrent clients.
>>>
>>
>> As far as I know all R graphics output that does not go to a screen device,
>> such as an X window, must be directed to some sort of file. I am not aware
>> of a graphics device that provides output to something other than a screen
>> or a file, but there very well may be such a device in existence.
For experimentation purpose, the rpy2 project is finalizing a system to
allow Python-written graphical devices (no C-level R extensions, just
Python). Beside other niceties, it will allow working around the lack of
connection API in R for graphics.
Since Python makes the use of file-like objects straightforward, we plan
providing devices that are streams (nice for serving graphics from web
applications without having to worry about temp files).
> This was essentially the conclusion of Donald's earlier thread...
>
>> The functionality you could describe could be implemented by writing a R
>> graphics device that forwards the R plotting commands to... well anywhere
>> you want, really. As the author of an R graphics device, I can say the
>> trickiest part of such an undertaking will be calculating font metrics so
>> that R can properly position text in the graphics. Everything else is very
>> straight-forward.
>
> I believe Donald wants the_rendered_ output. That is, a stream of bytes
> that represent a png, jpeg, etc. Toward this end, we have already
> discussed using an OS-level fifo to avoid disk I/O, and I think this is
> the easiest route for Donald.
>
> Alternatively, Donald might look into the X11 graphics driver, where
> Cairo is used to write pngs. In particular, the in_do_saveplot function
> (src/main/modules/X11/devX11.c) calls cairo_surface_write_to_png, in
> order to save a png to file. Cairo also provides the
> cairo_surface_write_to_png_stream function, which might be used to send
> png data to a memory buffer (i.e. a raw vector). I don't think it would
> be too difficult to modify in_do_saveplot to accommodate this.
>
That is all nice, it will require you to hack R (well, there is the Cairo
device so you could make the change outside of R instead).
As always, the reason is buried deep inside -- the lack of connection API. If
we had that, devices would take a connection instead of the file name and all
would be well since you could use in-memory connections instead of files ...;)
May I dare asking about what happened to past offers to alleviate the
problem ?
There is at least one patch (contributed 4 years ago)
http://rwiki.sciviews.org/doku.php?id=developers:r_connections_api
that remained seemingly ignored, and subsequent requests for updates (or
patch submission policies) remained similarly unanswered.
A recent thread showed unexpected progress, with the eventual
possibility of accepting a patch being worded.
http://www.mail-archive.com/r-devel@r-project.org/msg20276.html
Unfortunately the thread drifted into legalese invocations, and despite
the author of the patch complying to all demands regarding the licensing
flavour for his contribution the patch seems to have joined (all ?)
other submitted patches. (I don't get anything when running:
svn log -r {2010-04-27}:HEAD | grep -i Shotwell
).
Are there such patches included in the Revolution R sources, or are
there plans to do so ?
Laurent
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
I am reminded of a cartoon I saw recently in a urologists office that said: "In this line of work, I see a lot of ass holes and pricks." There is no shortage of people who are nasty, both among those who seek help and those who are able to give it, in any community. I would say, though, that instead of endorsing nastiness, for whatever reason, it ought to at least be ignored, and would be better repudiated. I can recall trying to teach elementary statistics to first year undergraduate students: and a particular subset that was terrified of math to begin with. They were under the mistaken belief that they could function without any quantitative capability. While I disabused them of that delusion right quick, I found I had to do that gently as they were so insecure that it would have been easy to crush their spirit to a point where they'd drop out of university altogether for lack of confidence. Instead of being harsh with them, I had to gently bring them around, in some cases giving them early on assignments that were mathematical but structured in such a way they didn't notice the mathematical nature of it until after the fact. Invariably, they succeeded in these assignments and i was able to tell them something like: "You see, you told me you couldn't do math, but look what you have done. This problem was inherently mathematical." THAT was a confidence builder. Had I taken the RTFM approach with those kids, the scientific community would have forever lost some bright minds long before they had begun to flourish. At that time, I found I also had to develop a skill in NOT laughing at questions that struck me funny. That happened frequently, simply because I was dealing with kids so new to quantitative analyses that many of the questions they asked were funny. But I dared not laugh because I knew these students asking such questions were so insecure that they'd have been crushed had I laughed. eventually, by the time I was finished with them, they had built their confidence levels and were also able to laugh at the question they'd asked initially, but it takes time to led a student to that point. I can remember, when I first used a unix system many, many, many years ago, I encountered a problem and was told by the department's system administrator to RTFM. This was a guy who was paid to help staff and students to use the department's computing resources. He was brilliant, but sorely lacking in interpersonal skills (except for when he had to deal with his supervisor). When I replied that I had, his response was that I must therefore be too stupid to deserve to use the computer system. I, however, am not the sort of individual that is so easily thwarted (I can't be insulted because I am too stupid to understand the insult! ;-), and eventually I became the "go to guy" when someone in my department had a computational problem. But often I found I had to take longer to figure things out on my own that I would have needed if I had access to someone who had both the expertise I sought to develop in myself and the spirit of a real educator. While it has been a while since I worked in an educational institution, I have found that generally when students or junior programmers came asking questions, it was MY fault. Either the documentation or verbal direction I'd provided was inadequate, or I had made assumptions about their background that led me to expect too much of them. Either they did not have the mathematical background I'd assumed, or they didn't have the knowledge of programming that I'd assumed. In many cases, these "kids" were so new to a particular issue or subject, they would not have been able to produce a useful query in Google if their life depended on it. They could try to submit a query, but the signal to noise ratio would be so low there'd be no hope they'd live long enough to find the signal. Part of the problem of this particular medium is that you never know who the person is that you are trying to help. So, then, the documentation provided to all, and help in this sort of medium, ought to be constructed not only with a view to helping peers use R, but also with a view to helping those just getting started. There is a lot of R documentation that seems to be written by experts for experts (which is fine as far as it goes), but at a level that is far to advanced (either in programming or in statistics) to be useful for beginners. Maybe that warrants two or more sets of documentation, some of which are intended for users with different levels of experience. There are a number of ways that can be handled. It is certain that the FAQs that exist are not nearly comprehensive or detailed enough for all levels of users. That said, the quality of documentation varies considrably among the different R packages I have examined, and I have found that I have tended to rely most on those packages that are best documented. A different part of the problem is time management. Ther
[Rd] Speed improvement to evalList
I've been inspired to look at the R source code by some strange timing
results that I wrote about on my blog at radfordneal.wordpress.com
(see the posts on "Speeding up parentheses..." and "Two surprising
things...".
I discovered that the strange speed advantage of curly brackets over
parentheses is partially explained by an inefficiency in the evalList
and evalListKeepMissing procedures in eval.c, in directory src/main,
which are on the critical path for many operations. These procedures
unnecessarily allocate an extra CONS node. I rewrote them to avoid
this, which seems to speed up a typical program by about 5% (assuming
it doesn't spend most of its time in things like matrix multiplies).
I think it would be well worthwhile to put this minor change into the
next R release. I'll be looking at some other places where R can also
be sped up, and expect that an average improvement of maybe 15% is
possible, with some programs probably speeding up by a factor of two.
For now, though, I'll just give the revised versions of evalList and
evalListKeepMissing, below.
Radford Neal
-
/* Used in eval and applyMethod (object.c) for builtin primitives,
do_internal (names.c) for builtin .Internals
and in evalArgs.
'n' is the number of arguments already evaluated and hence not
passed to evalArgs and hence to here.
*/
SEXP attribute_hidden evalList(SEXP el, SEXP rho, SEXP call, int n)
{
SEXP head, tail, ev, h;
int mode; /* mode==0 is 0 args, mode==1 is 1 arg, mode==2 is >1 arg */
head = R_NilValue;
mode = 0;
while (el != R_NilValue) {
n++;
if (CAR(el) == R_DotsSymbol) {
/* If we have a ... symbol, we look to see what it is bound to.
* If its binding is Null (i.e. zero length)
* we just ignore it and return the cdr with all its expressions
evaluated;
* if it is bound to a ... list of promises,
* we force all the promises and then splice
* the list of resulting values into the return value.
* Anything else bound to a ... symbol is an error
*/
h = findVar(CAR(el), rho);
if (TYPEOF(h) == DOTSXP || h == R_NilValue) {
while (h != R_NilValue) {
if (mode==1) {
PROTECT(head);
mode = 2;
}
ev = CONS(eval(CAR(h), rho), R_NilValue);
COPY_TAG(ev, h);
if (mode==0) {
head = ev;
mode = 1;
}
else {
SETCDR(tail, ev);
}
tail = ev;
h = CDR(h);
}
}
else if (h != R_MissingArg)
error(_("'...' used in an incorrect context"));
} else if (CAR(el) == R_MissingArg) {
/* It was an empty element: most likely get here from evalArgs
which may have been called on part of the args. */
errorcall(call, _("argument %d is empty"), n);
} else if (isSymbol(CAR(el)) && R_isMissing(CAR(el), rho)) {
/* It was missing */
errorcall(call, _("'%s' is missing"), CHAR(PRINTNAME(CAR(el;
} else {
if (mode==1) {
PROTECT(head);
mode = 2;
}
ev = CONS(eval(CAR(el), rho), R_NilValue);
COPY_TAG(ev, el);
if (mode==0) {
head = ev;
mode = 1;
}
else {
SETCDR(tail, ev);
}
tail = ev;
}
el = CDR(el);
}
if (mode==2) UNPROTECT(1);
return head;
} /* evalList() */
/* A slight variation of evaluating each expression in "el" in "rho". */
/* used in evalArgs, arithmetic.c, seq.c */
SEXP attribute_hidden evalListKeepMissing(SEXP el, SEXP rho)
{
SEXP head, tail, ev, h;
int mode; /* mode==0 is 0 args, mode==1 is 1 arg, mode==2 is >1 arg */
head = R_NilValue;
mode = 0;
while (el != R_NilValue) {
/* If we have a ... symbol, we look to see what it is bound to.
* If its binding is Null (i.e. zero length)
* we just ignore it and return the cdr with all its expressions
evaluated;
* if it is bound to a ... list of promises,
* we force all the promises and then splice
* the list of resulting values into the return value.
* Anything else bound to a ... symbol is an error
*/
if (CAR(el) == R_DotsSymbol) {
h = findVar(CAR(el), rho);
if (TYPEOF(h) == DOTSXP || h == R_NilValue) {
while (h != R_NilValue) {
if (mode==1) {
PROTECT(head);
m
[Rd] How do you make a formal "feature" request?
Who decides what features are in R and how they are implemented? If there is someone here who has that authority I have this request: A report() function analogous to the plot() function that makes it easy to generate a report from a table of data. This should not be in some auxiliary package, but part of the core R just like plot(). As a long time SAS user I cannot believe R does not have this. Please don't give me any crap about Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll your own" plot do you? Reports are no different. If you don't agree do not bother me. If you agree then please bring this request to the appropriate authorities for consideration or tell me how to do it. Thanks. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
The *user* decides. That would be YOU. Unlike SAS no one has a responsibility to YOU to implement some random request. Packages are how things are implemented. And to continue a previous thread ... maybe you should RTFM. Jeff On Sat, Aug 21, 2010 at 10:41 AM, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If there is > someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. > > Thanks. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeff.a.r...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
On 21 August 2010 at 11:41, Donald Winston wrote: | Who decides what features are in R and how they are implemented? If there is someone here who has that authority I have this request: | | A report() function analogous to the plot() function that makes it easy to | generate a report from a table of data. This should not be in some | auxiliary package, but part of the core R just like plot(). As a long time | SAS user I cannot believe R does not have this. Please don't give me any | crap about Sweave, LaTex, and the "power" of R to roll your own. You don't | have to "roll your own" plot do you? Reports are no different. If you don't | agree do not bother me. If you agree then please bring this request to the | appropriate authorities for consideration or tell me how to do it. I usually write them on a small note and put them under my pillow. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
> A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. I know it's frustrating when a program doesn't do what you want to do, and I agree with you that R's reporting capabilities are not (yet) as easy to use as SAS (although they can be more powerful and flexible). You may have noticed that when you downloaded R that you didn't have to pay anyone any money to use it - this has both advantages and disadvantages. The advantage are obvious (it's free!), but a disadvantage is that no-one is funded to work on R full time. This means that most contributors to R (even the core developers!) work on R either as part of another job or in their free time, and so usually work on the aspects of statistics and data analysis that most interest them. If you want a core developer to work on something, you either need to get them interested in your problem or find money to buy some of their time. Another disadvantage from your perspective is that while SAS is a business and therefore cares (at least a tiny amount) about your business, R does not. Everyone who provides help on R-help does so out of the goodness of their heart, not because they get paid. Replies can sometimes be rather irascible, and even rude, and while I personally don't like the lack of manners, you still get far more than what you pay for. At the end of the day, if R doesn't meet your needs, why not continue using SAS? 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
Re: [Rd] No RTFM?
> previous suggestion by a regular contributor. I still think a better > response is not to escalate: Either ignore the post or say something like, > "I don't understand your question. Please provide a self-contained minimal > example as suggested in the Posting Guide ... ." I agree wholeheartedly. I have tried to do this with the ggplot2 mailing list, and I think it has been extremely successful in fostering a community that is friendly and polite, yet still provides excellent technical support (and these days, most of it doesn't come from me!). I know it's frustrating when you see the same "stupid" question asked over and over and over again, and it's so tempting to reply harshly, but I think you're far better off just letting it go, and doing something fun instead. 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
Re: [Rd] How do you make a formal "feature" request?
On Sat, Aug 21, 2010 at 4:41 PM, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If there is > someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. Okay Donald, let's do this. Together. Because only you seem to know what you want in this report() function. Can you spell out the sort of tables of data that report() will take, what other options it will have and so on, and what its output will be. It is quite possible someone out there will go "Yeah, I can do that", and have a go, especially if they also go "Yeah, I could *use* that too". If you really want it done, then you can pay money. So, spec please. From your earlier postings it sounds like not much more than summary(d) and a few table(d) outputs. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
Donald Paul Winston wrote: > > Who decides what features are in R and how they are implemented? If there > is someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some > auxiliary package, but part of the core R just like plot(). As a long time > SAS user I cannot believe R does not have this. Please don't give me any > crap about Sweave, LaTex, and the "power" of R to roll your own. You don't > have to "roll your own" plot do you? Reports are no different. If you > don't agree do not bother me. If you agree then please bring this request > to the appropriate authorities for consideration or tell me how to do it. > Well, I can think of three ways it can go down: 1. You want a shiny new pony. You ask about it on the mailing list and it seems that everyone else in the world responds "Hell yeah! I want to ride that too!". In this case the natives are restless enough that someone on R-Core may personally implement the feature- especially if they want to ride the pony as well. In this case, you need to provide a detailed specification of what kind of pony you want, how it should be groomed and the exact pitch at which you want it to whinny. A good template for such as spec would be a Python Enhancement Proposal (PEP) which is the way community-suggested core changes are implemented in python. An example is: http://www.python.org/dev/peps/pep-0389/ However, going this route is extremely rare. You have to have a significant amount of the user community rallying behind your idea and buy-in from core developers who are interested in implementing and, most importantly, maintaining and supporting the code. 2. You want a shiny new pony but not many other people in the word seem interested. In this situation you can do the work yourself, or with a group of other like-minded pony enthusiasts, to bring your idea into the world. Perhaps the genetic material you are looking for is already present in the vast herds of other ponies running wild on CRAN and elsewhere and you just have to do a little breeding to get what you want. Other times, the only way to do right is to write everything from scratch. Either way, in the end you will have a pony that shines exactly the way you want it to that you can enjoy for the rest of your life. In this case, getting your new pony into R Core is unlikely. The best response you can hope for is something along the lines of "That is a mighty fine pony you have there, but we really don't want it crapping all over our stable". They are not trying to be rude- the facts of life are that the members of R Core have a limited amount of time and a lot of other ponies to clean up after. Add to that the fact that shoveling pony shit is a thankless job that does not pay well and it is understandable why R Core may be conservative about the number of ponies they let into the official stable. However, they will be more than happy to provide your pony with a stall at CRAN so that everyone else in the world can take it out for a spin. I have never had a problem with installing and using packages from CRAN, even on windows machines that have been locked down and then shot in both kneecaps by the friendly neighborhood IT gestapo. All and all, this option is actually a pretty sweet deal; you will just have to drop by the CRAN stall every once and a while and deal with the pony droppings yourself or people will start to avoid it because of the smell. 3. You want a shiny new pony, but dont have the time or energy to pick out or put together the exact one you want. In this case, you can still get the pony you want but it will cost you money. There are R programmers out there who can write you a package if you pay them the right price. Supporting your local grad student population can also work; hunger is a great motivator. In the end you can also pay a corporate pony breeder like SAS for a trusty thoroughbred that is well respected by people in high places. However, you may notice that these ponies bear some telltale signs of inbreeding-- one of their eyes may not point in the same direction as the other or the pony becomes confused easily when put in an unfamiliar situation. Given there is not a lot you can do about these defects, you may suffer a crippling case of buyers remorse especially when you see the bill. Ok, I think i've thoroughly beat this horse analogy to death and I'm going to stop now. -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/How-do-you-make-a-formal-feature-request-tp2333593p2333737.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
I use the summary function. Being unfamiliar with the SAS report function, it is difficult to answer more completely. jim On Aug 21, 2010, at 8:41 AM, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If there is > someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. > > Thanks. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 90, Issue 20
On Aug 21, 2010, at 8:46 AM, Laurent wrote:
> On 21/08/10 12:00, r-devel-requ...@r-project.org wrote:
>>
>> On Aug 20, 2010, at 1:59 PM, Matt Shotwell wrote:
>>
>>> > On Fri, 2010-08-20 at 12:58 -0400, Sharpie wrote:
>>
>> Donald Paul Winston wrote:
> (...)
>>
>> Donald Paul Winston wrote:
> >>>
> >>> It appears R insists on directing plot output to a file. Is their a
> >>> graphics device that keeps the output in memory so it can be
> >>> returned to
> >>> my java app as a stream of bytes? If I have to wait for it to write
> >>> to a
> >>> "unique file" and then read it back again then I don't think that's
> >>> going
> >>> to work. My web app needs to support hundreds of concurrent clients.
> >>>
>>
>> As far as I know all R graphics output that does not go to a screen
>> device,
>> such as an X window, must be directed to some sort of file. I am not
>> aware
>> of a graphics device that provides output to something other than a
>> screen
>> or a file, but there very well may be such a device in existence.
>
> For experimentation purpose, the rpy2 project is finalizing a system to allow
> Python-written graphical devices (no C-level R extensions, just Python).
> Beside other niceties, it will allow working around the lack of
> connection API in R for graphics.
> Since Python makes the use of file-like objects straightforward, we plan
> providing devices that are streams (nice for serving graphics from web
> applications without having to worry about temp files).
>
Well, that doesn't help with the issue we raised since you still cannot use R
connections. It's trivial to modify any of the existing devices (e.g. Cairo as
I said) to support in-memory storage as they already support that internally -
certainly much easier that to mess with Python etc. Nonetheless, yes, it is
another way along the lines of xGD, JavaGD etc.
Cheers,
Simon
>
>>> > This was essentially the conclusion of Donald's earlier thread...
>>> >
>> The functionality you could describe could be implemented by writing a
>> R
>> graphics device that forwards the R plotting commands to... well
>> anywhere
>> you want, really. As the author of an R graphics device, I can say the
>> trickiest part of such an undertaking will be calculating font metrics
>> so
>> that R can properly position text in the graphics. Everything else is
>> very
>> straight-forward.
>>> >
>>> > I believe Donald wants the_rendered_ output. That is, a stream of bytes
>>> > that represent a png, jpeg, etc. Toward this end, we have already
>>> > discussed using an OS-level fifo to avoid disk I/O, and I think this is
>>> > the easiest route for Donald.
>>> >
>>> > Alternatively, Donald might look into the X11 graphics driver, where
>>> > Cairo is used to write pngs. In particular, the in_do_saveplot function
>>> > (src/main/modules/X11/devX11.c) calls cairo_surface_write_to_png, in
>>> > order to save a png to file. Cairo also provides the
>>> > cairo_surface_write_to_png_stream function, which might be used to send
>>> > png data to a memory buffer (i.e. a raw vector). I don't think it would
>>> > be too difficult to modify in_do_saveplot to accommodate this.
>>> >
>> That is all nice, it will require you to hack R (well, there is the Cairo
>> device so you could make the change outside of R instead).
>>
>> As always, the reason is buried deep inside -- the lack of connection API.
>> If we had that, devices would take a connection instead of the file name and
>> all would be well since you could use in-memory connections instead of files
>> ...;)
>
> May I dare asking about what happened to past offers to alleviate the problem
> ?
>
> There is at least one patch (contributed 4 years ago)
> http://rwiki.sciviews.org/doku.php?id=developers:r_connections_api
> that remained seemingly ignored, and subsequent requests for updates (or
> patch submission policies) remained similarly unanswered.
>
> A recent thread showed unexpected progress, with the eventual possibility of
> accepting a patch being worded.
> http://www.mail-archive.com/r-devel@r-project.org/msg20276.html
> Unfortunately the thread drifted into legalese invocations, and despite the
> author of the patch complying to all demands regarding the licensing flavour
> for his contribution the patch seems to have joined (all ?) other submitted
> patches. (I don't get anything when running:
> svn log -r {2010-04-27}:HEAD | grep -i Shotwell
> ).
>
> Are there such patches included in the Revolution R sources, or are there
> plans to do so ?
>
>
>
> Laurent
>
>
>
>
>> Cheers,
>> Simon
>>
>>
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
On Sat, Aug 21, 2010 at 11:04 AM, Hadley Wickham wrote:
>> previous suggestion by a regular contributor. I still think a better
>> response is not to escalate: Either ignore the post or say something like,
>> "I don't understand your question. Please provide a self-contained minimal
>> example as suggested in the Posting Guide ... ."
>
> I agree wholeheartedly. I have tried to do this with the ggplot2
> mailing list, and I think it has been extremely successful in
> fostering a community that is friendly and polite, yet still provides
> excellent technical support (and these days, most of it doesn't come
> from me!).
>
I've been insulted in r-help and its no fun. After Gabor pointed out
the logic in it, I have to admit he is right. It does keep traffic
down. I don't go there anymore unless I'm completely desperate.
I agree also, sometimes RTFM is the right answer, especially if it is
stated as "That is discussed on p. 162 of the R Guide for Whatever..."
I don't think people are insulted if you tell them to check
something specific.
Usually, first time visitors don't know about the R posting guide and
when they ask an incomplete question, we should just refer them to it.
We don't need the angry tone that we often see, but I don't think
people mind being referred. This presupposes the posting guide is
helpful. If somebody forgets the posting guide twice, then I think we
should all berate and insult them. I mean vigorously :)
My personal opinion is that the R posting guide could be revised to be
more direct. Exhausted, frustrated people don't benefit as much as
they could because the document is too long.
This is hard to fix because everything in there was added for a good
reasons. (I've been here long enough to remember a time before the
guide, sad to say.) I tried to reshape the posting guide and I can
see that it is a really hard problem.
What do you think of this: The priority is to put the most important
thing at the top. The second priority is brevity.
=
Posting Guide: How to ask good questions that prompt useful answers
People are busy, so ask your question in a useful way.
1. Every question to r-help should begin with the following.
A. Output from the command sessionInfo()
B. Output from Sys.getlocale()
C. Information about how you installed R. Did you make any changes,
such as incorporating a BLAS library. If you don't know, ask your
system administrator.
D. If you see an error or something unexpected, your message MUST
include the EXACT code that you were running. We mean, ALL of your
commands that were run before the error occurred. If you are unsure
of what you did, close your session, clean up your code, and start
over to reproduce the problem in the most direct way. Your post MUST
include the EXACT VERBATIM error message.
If you are working on a long program that requires a dataset,
post the dataset and the program somewhere on the Internet and
refer us to it. It is simply not possible to guess about what
might be going wrong in your program unless we can see it.
If you don't want to share your data, construct a small example
dataset that produces the same problem. Post it and refer us to it.
E. If you have isolated the problem to a certain part of your project,
write a small, self-contained 'working example' that causes the
problem and include it with your post.
Example. Why does this code:
dat <- data.frame(x=c(1,2,3), y=c(3,4,5))
plot (x, y, data=dat)
cause this:
Error in plot(x, y, data = dat) : object 'x' not found
We can easily reproduce that and explain the problem to you. We can't
help with a question like "my plot failed, something about an object
was missing."
2. How to avoid making the members of r-help angry at you.
A. Do not call a problem a "bug" unless you really mean to say that
someone has made a mistake. If you say "bug", they hear
"embarrassing personal flaw" or "gigantic boil". We know
you don't mean that, but sometimes they forget.
B. Before you write to r-help, search for answers from previous questions.
1. Try Google? Or her cousin Yahoo?
2. Try these inside R:
help.search("whatever")
RSiteSearch("whatever")
apropos("whatever")
C. Read R-intro, R help pages, and the R FAQs.
?whatever
3. Do not send your question to r-help unless your question is about R
or the base R packages that are supported by the R Core Team.
A. Don't ask statistics questions, unless they fall into the form "Which
R procedure or package should I use to conduct an analysis of ..." or
"Does anybody have a working example of procedure XYZ?" or "Can I
obtain XYZ result from an obect of class ZYX?"
B. If you have trouble with a package from CRAN or elsewhere, write to
the author of that package. r-help might be a good place to ask,
"I've been using package XYZ and the author seems to have abandoned
the project. Does anybody know of a replacement?" Otherwise, don't.
Note that the
Re: [Rd] No RTFM?
Paul Johnson gmail.com> writes:
>
[snip: lots more snippage to try get gmane to let me post]
> What do you think of this: The priority is to put the most important
> thing at the top. The second priority is brevity.
I really like this.
Some suggestions:
=
> Posting Guide: How to ask good questions that prompt useful answers
>
> People are busy, so ask your question in a useful way.
> 1. Every question to r-help should begin with the following.
> A. Output from the command sessionInfo()
> B. Output from Sys.getlocale()
> C. Information about how you installed R. Did you make any changes,
> such as incorporating a BLAS library. If you don't know, ask your
> system administrator.
I would make this optional or put it further down. I don't see that
many problems on the list that are due to non-standard installations.
Most of the most clueless people are (a) using stock installations
and/or (b) don't even know who installed R on the computer they are
using. I don't mind sending them to find out/ask if it's a real
issue, but it feels like an unnecessary hurdle.
> D. If you see an error or something unexpected, your message MUST
> include the EXACT code that you were running. We mean, ALL of your
> commands that were run before the error occurred. If you are unsure
> of what you did, close your session, clean up your code, and start
> over to reproduce the problem in the most direct way. Your post MUST
> include the EXACT VERBATIM error message.
>
> If you are working on a long program that requires a dataset,
> post the dataset and the program somewhere on the Internet and
> refer us to it. It is simply not possible to guess about what
> might be going wrong in your program unless we can see it.
>
> If you don't want to share your data, construct a small example
> dataset that produces the same problem. Post it and refer us to it.
This is where we have to emphasize 'small, reproducible example'
more strongly -- perhaps move the next item up.
I dread the pages and pages of random R-session crap
that will be posted following this advice literally ...
> E. If you have isolated the problem to a certain part of your project,
> write a small, self-contained 'working example' that causes the
> problem and include it with your post.
>
> Example. Why does this code:
>
> dat <- data.frame(x=c(1,2,3), y=c(3,4,5))
> plot (x, y, data=dat)
>
> cause this:
>
> Error in plot(x, y, data = dat) : object 'x' not found
>
> We can easily reproduce that and explain the problem to you. We can't
> help with a question like "my plot failed, something about an object
> was missing."
>
> 2. How to avoid making the members of r-help angry at you.
>
> A. Do not call a problem a "bug" unless you really mean to say that
>someone has made a mistake. If you say "bug", they hear
>"embarrassing personal flaw" or "gigantic boil". We know
>you don't mean that, but sometimes they forget.
[note that there is already information on 'what is a bug' in the
posting guide -- I think -- or maybe it's the R FAQ]
>
> B. Before you write to r-help, search for answers from previous questions.
>1. Try Google? Or her cousin Yahoo?
This should be for more general statistics questions, and perhaps
put second.
>2. Try these inside R:
>
> help.search("whatever")
> RSiteSearch("whatever")
> apropos("whatever")
perhaps add
install.packages("sos"); library(sos); findFn("whatever")
>
> C. Read R-intro, R help pages, and the R FAQs.
>
> ?whatever
>
> 3. Do not send your question to r-help unless your question is about R
> or the base R packages that are supported by the R Core Team.
>
> A. Don't ask statistics questions, unless they fall into the form "Which
> R procedure or package should I use to conduct an analysis of ..." or
> "Does anybody have a working example of procedure XYZ?" or "Can I
> obtain XYZ result from an obect of class ZYX?"
>
> B. If you have trouble with a package from CRAN or elsewhere, write to
> the author of that package.
^^^ maintainer; use maintainer("whatever") to find their e-mail address.
> r-help might be a good place to ask,
> "I've been using package XYZ and the author seems to have abandoned
> the project. Does anybody know of a replacement?" Otherwise, don't.
>
> Note that the Bioconductor repository is not part of "R" proper and
> you should address questions about Bioconductor to their support framework.
>
> C. If you are writing code for R itself, or if you are developing a
>package, send your question to r-devel, rather than r-help.
>
> D. For operating-system or R interface questions, there are dedicated
> lists. See R-sig-Mac, R-sig-Debian, R-sig-Fedora, etc.
>
> ==
>
> It will be necessary to add, toward the end, the part about "be polite
> when posting."
>
> And along the lines of the "No RTFM" policy, I think we should say
> "All RTFM answers s
Re: [Rd] How do you make a formal "feature" request?
On Sat, 2010-08-21 at 11:41 -0400, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If > there is someone here who has that authority I have this request: The R Core Development Team decide on what goes into the base R source code. You have almost zero chance of getting such a thing in base R. I say that for several reasons; i) You haven't provided any code to implement report() or provided a good description of what you would like implemented, ii) R Core like to keep the base source code a small as possible to limit the maintenance burden on themselves, iii) R has the package mechanism so you or anyone else can add whatever features you want to R, have it hosted on CRAN and be available to any R user at the click of a button, iv) your attitude stinks! I could go on, but I feel I'm just feeding a troll at this point. I look forward to seeing your report package implementing a report() function on CRAN in the near future. There are several manuals written which document how to write extensions to the R environment, numerous books on programming in R and several example reporting systems that we've mentioned to you. Check out the R website for these. Learn some R, do some reading, examine those systems that do exist then roll your own function and let us all benefit. I won't hold my breath of course. Whiners are not often doers... Good luck! G > A report() function analogous to the plot() function that makes it > easy to generate a report from a table of data. This should not be in > some auxiliary package, but part of the core R just like plot(). As a > long time SAS user I cannot believe R does not have this. Please don't > give me any crap about Sweave, LaTex, and the "power" of R to roll > your own. You don't have to "roll your own" plot do you? Reports are > no different. If you don't agree do not bother me. If you agree then > please bring this request to the appropriate authorities for > consideration or tell me how to do it. > > Thanks. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Dr. Gavin Simpson [t] +44 (0)20 7679 0522 ECRC, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
On Sat, Aug 21, 2010 at 6:47 PM, Paul Johnson wrote:
> On Sat, Aug 21, 2010 at 11:04 AM, Hadley Wickham wrote:
>>> previous suggestion by a regular contributor. I still think a better
>>> response is not to escalate: Either ignore the post or say something like,
>>> "I don't understand your question. Please provide a self-contained minimal
>>> example as suggested in the Posting Guide ... ."
>>
>> I agree wholeheartedly. I have tried to do this with the ggplot2
>> mailing list, and I think it has been extremely successful in
>> fostering a community that is friendly and polite, yet still provides
>> excellent technical support (and these days, most of it doesn't come
>> from me!).
>>
>
> I've been insulted in r-help and its no fun. After Gabor pointed out
> the logic in it, I have to admit he is right. It does keep traffic
> down. I don't go there anymore unless I'm completely desperate.
>
> I agree also, sometimes RTFM is the right answer, especially if it is
> stated as "That is discussed on p. 162 of the R Guide for Whatever..."
> I don't think people are insulted if you tell them to check
> something specific.
>
> Usually, first time visitors don't know about the R posting guide and
> when they ask an incomplete question, we should just refer them to it.
> We don't need the angry tone that we often see, but I don't think
> people mind being referred. This presupposes the posting guide is
> helpful. If somebody forgets the posting guide twice, then I think we
> should all berate and insult them. I mean vigorously :)
>
> My personal opinion is that the R posting guide could be revised to be
> more direct. Exhausted, frustrated people don't benefit as much as
> they could because the document is too long.
Regarding length, the portion at the end of every r-help message (but
this does not appear at the end of r-devel messages or the messages
of other lists concerning R):
"provide commented, minimal, self-contained, reproducible code."
It was intended to provide a one line synopsis of the key part of the posting
guide that could be readily pointed to. Although we have to be careful about
making that too verbose, as well, it might not be too onerous to add
one more line
such as:
"and use ?, RSiteSeach("my term") and http://rseek.org before posting"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
> Regarding length, the portion at the end of every r-help message (but > this does not appear at the end of r-devel messages or the messages > of other lists concerning R): > > "provide commented, minimal, self-contained, reproducible code." > > It was intended to provide a one line synopsis of the key part of the posting > guide that could be readily pointed to. Although we have to be careful about > making that too verbose, as well, it might not be too onerous to add But no one reads email footers... 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
Re: [Rd] No RTFM?
On Sat, Aug 21, 2010 at 8:59 PM, Hadley Wickham wrote: >> Regarding length, the portion at the end of every r-help message (but >> this does not appear at the end of r-devel messages or the messages >> of other lists concerning R): >> >> "provide commented, minimal, self-contained, reproducible code." >> >> It was intended to provide a one line synopsis of the key part of the posting >> guide that could be readily pointed to. Although we have to be careful about >> making that too verbose, as well, it might not be too onerous to add > > But no one reads email footers... > I would expect that a lot more people read that than the posting guide. Its also useful as something to point to that is more accessible than the posting guide since its right there. One can be sure its been received since every message contains it. Finally it gives the key info that someone needs to effectively use r-help. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
I've answered many email posts by copying and editing the email footer. That's much more friendly, informative and effective than just RTFM. (As previously noted in this thread, it's often hard to know which FMTR.) Spencer On 8/21/2010 6:08 PM, Gabor Grothendieck wrote: On Sat, Aug 21, 2010 at 8:59 PM, Hadley Wickham wrote: Regarding length, the portion at the end of every r-help message (but this does not appear at the end of r-devel messages or the messages of other lists concerning R): "provide commented, minimal, self-contained, reproducible code." It was intended to provide a one line synopsis of the key part of the posting guide that could be readily pointed to. Although we have to be careful about making that too verbose, as well, it might not be too onerous to add But no one reads email footers... I would expect that a lot more people read that than the posting guide. Its also useful as something to point to that is more accessible than the posting guide since its right there. One can be sure its been received since every message contains it. Finally it gives the key info that someone needs to effectively use r-help. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
I've stayed in by back seat in the spectators so far, but I feel a comment may be helpful here. I'm in close sympathy with Hadley Wickham's comment on a "previous suggestion by a regular contributor" [Spencer Graves] (below) and with the comment by Spencer himself. We are a community with a variety of attitudes, from prescriptive (to the point of disciplinarian) to relaxed and permissive. The problem with this sort of discussion is that the former feel able to propose detailed prescriptions, while the latter do not have a definite "party line" to set out in any sort of detail. The more specific and detailed the prescriptive proposals become, the more they take on forms which could readily be adopted into the guidelines for the list, and may therefore seem attractive to those who maintain the guidelines. Meanwhile, the permissives have not proposed any such specific alternatives. I do not feel at all comfortable with Paul's suggestions below (for reasons which I have explained in-line). To follow these suggestions would make posting to R become more and more like filling in a Tax Return! (In the days when I had to so this, I would work with two photocopies of a 12-page form, a pencil, and an eraser, doing 1st draft on copy one, then re-starting from scratch 2nd draft on copy 2, all the time consulting a 44-page Tax Return Guide and a 16-page Tax Calculation Guide. Then comparing the two for agreement, and starting again if they didn't. Only when it was all apparently OK would I transcribe in ink onto the real Return Form. It would take at least a day.). Regarding peremptory responses to "RTFM" and the like, if I come across one (as when interested in a thread so opening the emails about it) I simply delete it with mild irritation (and regret the waste of space on the list). And with likely sympathy for the person who provoked it (see below). Regarding the sort of query which can provoke such responses, I think one can try to be discriminating. Occasionally they are pretty clearly from people who are trying to get someone else to do their work without making any effort of their own. Appropriate response should fit the case, and need not take the form of an automatic "speeding ticket". Usually, however, they are from naive users who are only beginning to find their way in R (and its documentation). Both of these are daunting and bewildering tasks for beginners. And not only beginners. I've been using R myself for well over 10 years, and seriously for nearly 10. I can still wander for a long time through "a maze of twisty tunnels, all alike" when trying to track down some essential thing (graphics parameters and other options(), in particular, can turn into a real "Dungeons and Dragons"). One can even begin to wonder whether what one is looking for is documented at all (and sometimes it isn't). What with the various introductory manuals (which are indeed good), trying '?whatever' and being led off into a trail of "See also:"s, trying '??whatever' to try to flush up some functions that might be relevant, and the mass of web-pages one might be led to on an R Site Search, we have a whole meadow full of haystacks in which to search for a needle! And don't try to tell me that all the '?...' help pages are models of simplicity, clarity, and self-containment! So, if one recognises such a query, one can try to get some insight into what the real obstacle is. If you get that, then a well-chosen example along with some clear explanation can help that beginner over that problem, encourage them, and give them confidence in their own hopes for understanding and using R, and solving such problems for themselves in future. Even if it seems that they don't even know how to climb over a stile on a footpath, a little encouragement to put one foot on the near end of the cross-step, swing the other leg over the top and put the other foot on the other end, then swing the first foot over and onto the cross-step, then finally hop neatly down onto the ground, can evoke an "Ahh!!" and leave them fully equipped to deal with the next stile (and some insight into stiles in general). With R, the analogy would be more like showing (and explaining) the manoeuvres which will take them up the first pitch of a rock-climb. I think that, if one does not feel inclined to take such an approach, then it is better simply to move on, maybe deleting the query. There is no point in a response which is both discouraging and unhelpful. "RTFM" (and variants) is likely to be perceived as a put-down, and (unless accompanied by sympathetic detailed guidance) will not help to solve the problem. (Some seem to have the mind of a Tax Man, to whom all is transparently contained in 44+16 pages of complicated and intricately cross-referenced Guides). So, in my view, the Posting Guide should be a true guide, but should avoid giving any impression that jumping through documentation hoops is a prerequisite for a valid posting to the list. Therefore it shou
[Rd] fortune? (was: Re: How do you make a formal "feature" request?)
Dear all I was wondering whether such a long post could be fortune-ed. What do you think? Regards Liviu On Sat, Aug 21, 2010 at 9:33 PM, Sharpie wrote: > Well, I can think of three ways it can go down: > > > 1. You want a shiny new pony. > > You ask about it on the mailing list and it seems that everyone else in the > world responds "Hell yeah! I want to ride that too!". In this case the > natives are restless enough that someone on R-Core may personally implement > the feature- especially if they want to ride the pony as well. > > In this case, you need to provide a detailed specification of what kind of > pony you want, how it should be groomed and the exact pitch at which you > want it to whinny. A good template for such as spec would be a Python > Enhancement Proposal (PEP) which is the way community-suggested core changes > are implemented in python. An example is: > http://www.python.org/dev/peps/pep-0389/ > > However, going this route is extremely rare. You have to have a significant > amount of the user community rallying behind your idea and buy-in from core > developers who are interested in implementing and, most importantly, > maintaining and supporting the code. > > > 2. You want a shiny new pony but not many other people in the word seem > interested. > > In this situation you can do the work yourself, or with a group of other > like-minded pony enthusiasts, to bring your idea into the world. Perhaps > the genetic material you are looking for is already present in the vast > herds of other ponies running wild on CRAN and elsewhere and you just have > to do a little breeding to get what you want. Other times, the only way to > do right is to write everything from scratch. Either way, in the end you > will have a pony that shines exactly the way you want it to that you can > enjoy for the rest of your life. > > In this case, getting your new pony into R Core is unlikely. The best > response you can hope for is something along the lines of "That is a mighty > fine pony you have there, but we really don't want it crapping all over our > stable". They are not trying to be rude- the facts of life are that the > members of R Core have a limited amount of time and a lot of other ponies to > clean up after. Add to that the fact that shoveling pony shit is a > thankless job that does not pay well and it is understandable why R Core may > be conservative about the number of ponies they let into the official > stable. > > However, they will be more than happy to provide your pony with a stall at > CRAN so that everyone else in the world can take it out for a spin. I have > never had a problem with installing and using packages from CRAN, even on > windows machines that have been locked down and then shot in both kneecaps > by the friendly neighborhood IT gestapo. All and all, this option is > actually a pretty sweet deal; you will just have to drop by the CRAN stall > every once and a while and deal with the pony droppings yourself or people > will start to avoid it because of the smell. > > > 3. You want a shiny new pony, but dont have the time or energy to pick out > or put together the exact one you want. > > In this case, you can still get the pony you want but it will cost you > money. There are R programmers out there who can write you a package if you > pay them the right price. Supporting your local grad student population can > also work; hunger is a great motivator. > > In the end you can also pay a corporate pony breeder like SAS for a trusty > thoroughbred that is well respected by people in high places. However, you > may notice that these ponies bear some telltale signs of inbreeding-- one of > their eyes may not point in the same direction as the other or the pony > becomes confused easily when put in an unfamiliar situation. Given there is > not a lot you can do about these defects, you may suffer a crippling case of > buyers remorse especially when you see the bill. > > > Ok, I think i've thoroughly beat this horse analogy to death and I'm going > to stop now. > > -Charlie > > > - > Charlie Sharpsteen > Undergraduate-- Environmental Resources Engineering > Humboldt State University > -- > View this message in context: > http://r.789695.n4.nabble.com/How-do-you-make-a-formal-feature-request-tp2333593p2333737.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
