Full_Name: Ross Boylan
Version: 2.10.0
OS: Windows XP
Submission from: (NULL) (198.144.201.14)
Some of the help for setGeneric seems to have been garbled. In the section
"Basic Use", 5th paragraph (where the example counts as a single line
3rd
paragraph) it says
<quote>
Note that calling 'setGeneric()' in this form is not strictly
necessary before calling 'setMethod()' for the same function. If
the function specified in the call to 'setMethod' is not generic,
'setMethod' will execute the call to 'setGeneric' itself.
Declaring explicitly that you want the function to be generic can
be considered better programming style; the only difference in the
result, however, is that not doing so produces a You cannot (and
never need to) create an explicit generic version of the primitive
functions in the base package.
<quote>
The stuff after the semi-colon of the final sentence is garbled, or at least
unparseable by me. Probably something got deleted by mistake.
This is with ESS 5.7.1, Emacs 23.1.1.
This is a somewhat newish problem; the help in R 2.7 does not have the problem.
>>>>> Ross Boylan <ross at biostat.ucsf.edu> >>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes:> Full_Name: Ross Boylan > Version: 2.10.0 > OS: Windows XP > Submission from: (NULL) (198.144.201.14) > Some of the help for setGeneric seems to have been garbled. In the section > "Basic Use", 5th paragraph (where the example counts as a single line 3rd > paragraph) it says > <quote> > Note that calling 'setGeneric()' in this form is not strictly > necessary before calling 'setMethod()' for the same function. If > the function specified in the call to 'setMethod' is not generic, > 'setMethod' will execute the call to 'setGeneric' itself. > Declaring explicitly that you want the function to be generic can > be considered better programming style; the only difference in the > result, however, is that not doing so produces a You cannot (and > never need to) create an explicit generic version of the primitive > functions in the base package. > <quote> > The stuff after the semi-colon of the final sentence is garbled, or at least > unparseable by me. Probably something got deleted by mistake. That's very peculiar. The corresponding methods/man/setGeneric.Rd file has not been changed in a while, but I don't see your problem. > This is with ESS 5.7.1, Emacs 23.1.1. exactly same versions here, but not your problem. What happens if you start R in terminal and call ?setGeneric there ? Regards, Martin > This is a somewhat newish problem; the help in R 2.7 does not have the problem. (( peculiar indeed ... ))
>>>>> "RossB" == Ross Boylan <ross at biostat.ucsf.edu> >>>>> on Thu, 17 Dec 2009 09:42:22 -0800 writes:RossB> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote: >> >>>>> Ross Boylan <ross at biostat.ucsf.edu> >> >>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes: >> >> > Full_Name: Ross Boylan >> > Version: 2.10.0 >> > OS: Windows XP >> > Submission from: (NULL) (198.144.201.14) >> >> >> > Some of the help for setGeneric seems to have been garbled. In the section >> > "Basic Use", 5th paragraph (where the example counts as a single line 3rd >> > paragraph) it says >> > <quote> >> > Note that calling 'setGeneric()' in this form is not strictly >> > necessary before calling 'setMethod()' for the same function. If >> > the function specified in the call to 'setMethod' is not generic, >> > 'setMethod' will execute the call to 'setGeneric' itself. >> > Declaring explicitly that you want the function to be generic can >> > be considered better programming style; the only difference in the >> > result, however, is that not doing so produces a You cannot (and >> > never need to) create an explicit generic version of the primitive >> > functions in the base package. >> > <quote> >> >> > The stuff after the semi-colon of the final sentence is garbled, or at least >> > unparseable by me. Probably something got deleted by mistake. >> >> That's very peculiar. >> >> The corresponding methods/man/setGeneric.Rd file has not been >> changed in a while, >> but I don't see your problem. RossB> The help from R launched directly from the R shortcut on my desktop RossB> looks fine, in both 2.10 and 2.8. RossB> I closed all my emacs sessions and restarted, but ?setGeneric produces RossB> the same garbled text. I also tried telling ESS to use a different RossB> working directory when launching R; it didn't help. RossB> The last sentence of this paragraph is also garbled: RossB> <quote> RossB> The description above is the effect when the package that owns the RossB> non-generic function has not created an implicit generic version. RossB> Otherwise, it is this implicit generic function that is us_same_ RossB> version of the generic function will be created each time. RossB> </quote> RossB> Weird. Very weird, indeed! However, in any case, this is a bug of your version / installation of [Emacs + ESS] and not of R. So the topic should move to the ESS-help list ess-help at stat.math.ethz.ch and you could possibly additionally also send an "official Ess bug report": [iESS] emacs-menu, last line: "Send bug report" RossB> P.S. http://bugs.r-project.org was extremely sluggish, even timing out, RossB> both yesterday and today for me. Maybe the world climate is a bit more important in Copenhagen, at the moment, than R's bugs server? ;-) {{bugs.r-project.org *is* indeed located there}} Thanks for the report, but as we've established, the bug is not with R, really, but with your installation/version of the R <-> Emacs interface. Regards, Martin
>>>>> "DM" == Duncan Murdoch <murdoch at stats.uwo.ca> >>>>> on Fri, 18 Dec 2009 15:03:26 -0500 writes:DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote: >> On 18/12/2009 12:54 PM, Martin Maechler wrote: >>>>>>>> Martin Morgan <mtmorgan at fhcrc.org> >>>>>>>> on Fri, 18 Dec 2009 07:40:13 -0800 writes: >>> > Martin Maechler wrote: >>> >>>>>>> Martin Morgan <mtmorgan at fhcrc.org> >>> >>>>>>> on Thu, 17 Dec 2009 09:54:54 -0800 writes: >>> >> >>> >> > Ross Boylan wrote: >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote: >>> >> >>>>>>>> Ross Boylan <ross at biostat.ucsf.edu> >>> >> >>>>>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes: >>> >> >>> > Full_Name: Ross Boylan >>> >> >>> > Version: 2.10.0 >>> >> >>> > OS: Windows XP >>> >> >>> > Submission from: (NULL) (198.144.201.14) >>> >> >>> >>> >> >>> > Some of the help for setGeneric seems to have been garbled. In the section >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a single line 3rd >>> >> >>> > paragraph) it says >>> >> >>> > <quote> >>> >> >>> > Note that calling 'setGeneric()' in this form is not strictly >>> >> >>> > necessary before calling 'setMethod()' for the same function. If >>> >> >>> > the function specified in the call to 'setMethod' is not generic, >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself. >>> >> >>> > Declaring explicitly that you want the function to be generic can >>> >> >>> > be considered better programming style; the only difference in the >>> >> >>> > result, however, is that not doing so produces a You cannot (and >>> >> >>> > never need to) create an explicit generic version of the primitive >>> >> >>> > functions in the base package. >>> >> >>> > <quote> >>> >> >>> >>> >> >>> > The stuff after the semi-colon of the final sentence is garbled, or at least >>> >> >>> > unparseable by me. Probably something got deleted by mistake. >>> >> >>> >>> >> >> >>> >> >> The last sentence of this paragraph is also garbled: >>> >> >> <quote> >>> >> >> The description above is the effect when the package that owns the >>> >> >> non-generic function has not created an implicit generic version. >>> >> >> Otherwise, it is this implicit generic function that is us_same_ >>> >> >> version of the generic function will be created each time. >>> >> >> </quote> >>> >> >>> >> > Off-list, I guess both of these paragraphs have very long lines in the >>> >> > source; maybe your emacs is truncating lines instead of wrapping, or >>> >> > something similar? >>> >> >>> >> Thank you, Martin, but no, we never have very long lines in the >>> >> R sources (and *.Rd files belong to the sources), >>> >> and then translation of the *.Rd file to a "data base" of >>> >> text-help entries should keep newlines. >>> >>> > I meant that they _are_ very long in the source. Martin >>> >>> Oh dear, yes indeed, you are right! >>> >>> So, astonishing as that may be, indeed for the 'text' version of >>> help, it seems that ... under some circumstances ... >>> the (NAMESPACE-hidden) method >>> utils:::print.help_files_with_topic() >>> >>> which ends up calling file.show() : >>> >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) { >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB, >>> basename(file)), out = tempfile("Rtxt"), package = pkgname) >>> file.show(temp, title = gettextf("R Help on '%s'", >>> topic), delete.file = TRUE) >>> } >>> >>> >>> *is* still influenced by the original *.Rd file's (lack) of new >>> lines, somewhat astonishingly to me. >>> >>> Even more, I cannot understand that other people do not see the >>> same phenomenon (though maybe they would if they cared to notice...), >>> and also that you only get the "garbling" problem with ESS, and >>> only for R version 2.10, but not 2.8. >>> Did our 'Rd2txt()' change here on purpose? >>> >> >> I seem to recall fixing a bug in the line wrapping code, but I can't >> spot it in a quick glance over the log. Maybe I forgot to commit the >> fix? I can't look into this now, but I'll follow up later. DM> The patch I recalled did get committed on November 8, with this NEWS entry: DM> o Text help rendering did not handle very long input lines DM> properly. DM> So it made it into 2.10.1. Do you still see the problem there? I don't DM> see it in text help for setGeneric in the Windows gui. DM> Duncan Murdoch I think it was never a problem in the GUI, however when using ESS. For some reason, I did overlook that Ross was talking about Windows. I had never checked it on Windows, but did now {using our Windows terminal server}. Indeed: R 2.10.0 with ESS shows the problem Ross found R 2.10.1 with ESS *NO LONGER* shows the problem. --> I'm CC'ing R-bugs, as this bug report ... an R bug after all .. can be closed. Thanks to all helpers! Martin Maechler, ETH Zurich
On 19/12/2009 8:56 AM, Martin Maechler wrote:>>>>>> "DM" == Duncan Murdoch <murdoch at stats.uwo.ca> >>>>>> on Fri, 18 Dec 2009 15:03:26 -0500 writes: > > DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote: > >> On 18/12/2009 12:54 PM, Martin Maechler wrote: > >>>>>>>> Martin Morgan <mtmorgan at fhcrc.org> > >>>>>>>> on Fri, 18 Dec 2009 07:40:13 -0800 writes: > >>> > Martin Maechler wrote: > >>> >>>>>>> Martin Morgan <mtmorgan at fhcrc.org> > >>> >>>>>>> on Thu, 17 Dec 2009 09:54:54 -0800 writes: > >>> >> > >>> >> > Ross Boylan wrote: > >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote: > >>> >> >>>>>>>> Ross Boylan <ross at biostat.ucsf.edu> > >>> >> >>>>>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes: > >>> >> >>> > Full_Name: Ross Boylan > >>> >> >>> > Version: 2.10.0 > >>> >> >>> > OS: Windows XP > >>> >> >>> > Submission from: (NULL) (198.144.201.14) > >>> >> > >>> > >>> >> >>> > Some of the help for setGeneric seems to have been garbled. In the section > >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a single line 3rd > >>> >> >>> > paragraph) it says > >>> >> >>> > <quote> > >>> >> >>> > Note that calling 'setGeneric()' in this form is not strictly > >>> >> >>> > necessary before calling 'setMethod()' for the same function. If > >>> >> >>> > the function specified in the call to 'setMethod' is not generic, > >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself. > >>> >> >>> > Declaring explicitly that you want the function to be generic can > >>> >> >>> > be considered better programming style; the only difference in the > >>> >> >>> > result, however, is that not doing so produces a You cannot (and > >>> >> >>> > never need to) create an explicit generic version of the primitive > >>> >> >>> > functions in the base package. > >>> >> >>> > <quote> > >>> >> >>> > >>> >> >>> > The stuff after the semi-colon of the final sentence is garbled, or at least > >>> >> >>> > unparseable by me. Probably something got deleted by mistake. > >>> >> >>> > >>> >> >> > >>> >> >> The last sentence of this paragraph is also garbled: > >>> >> >> <quote> > >>> >> >> The description above is the effect when the package that owns the > >>> >> >> non-generic function has not created an implicit generic version. > >>> >> >> Otherwise, it is this implicit generic function that is us_same_ > >>> >> >> version of the generic function will be created each time. > >>> >> >> </quote> > >>> >> > >>> >> > Off-list, I guess both of these paragraphs have very long lines in the > >>> >> > source; maybe your emacs is truncating lines instead of wrapping, or > >>> >> > something similar? > >>> >> > >>> >> Thank you, Martin, but no, we never have very long lines in the > >>> >> R sources (and *.Rd files belong to the sources), > >>> >> and then translation of the *.Rd file to a "data base" of > >>> >> text-help entries should keep newlines. > >>> > >>> > I meant that they _are_ very long in the source. Martin > >>> > >>> Oh dear, yes indeed, you are right! > >>> > >>> So, astonishing as that may be, indeed for the 'text' version of > >>> help, it seems that ... under some circumstances ... > >>> the (NAMESPACE-hidden) method > >>> utils:::print.help_files_with_topic() > >>> > >>> which ends up calling file.show() : > >>> > >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) { > >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB, > >>> basename(file)), out = tempfile("Rtxt"), package = pkgname) > >>> file.show(temp, title = gettextf("R Help on '%s'", > >>> topic), delete.file = TRUE) > >>> } > >>> > >>> > >>> *is* still influenced by the original *.Rd file's (lack) of new > >>> lines, somewhat astonishingly to me. > >>> > >>> Even more, I cannot understand that other people do not see the > >>> same phenomenon (though maybe they would if they cared to notice...), > >>> and also that you only get the "garbling" problem with ESS, and > >>> only for R version 2.10, but not 2.8. > >>> Did our 'Rd2txt()' change here on purpose? > >>> > >> > >> I seem to recall fixing a bug in the line wrapping code, but I can't > >> spot it in a quick glance over the log. Maybe I forgot to commit the > >> fix? I can't look into this now, but I'll follow up later. > > DM> The patch I recalled did get committed on November 8, with this NEWS entry: > > > DM> o Text help rendering did not handle very long input lines > DM> properly. > > > DM> So it made it into 2.10.1. Do you still see the problem there? I don't > DM> see it in text help for setGeneric in the Windows gui. > > DM> Duncan Murdoch > > I think it was never a problem in the GUI, > however when using ESS.It was simply a problem of Rd2txt in 2.10.0, and appeared wherever that was used: in the GUI, in Rterm, whatever. The bug report was about an obsolete version. Duncan Murdoch> > For some reason, I did overlook that Ross was talking about > Windows. I had never checked it on Windows, > but did now {using our Windows terminal server}. > > Indeed: R 2.10.0 with ESS shows the problem Ross found > R 2.10.1 with ESS *NO LONGER* shows the problem. > > --> I'm CC'ing R-bugs, as this bug report > ... an R bug after all .. > can be closed. > > Thanks to all helpers! > Martin Maechler, ETH Zurich
I confirm that R 2.10.1 fixes the problem under ESS 5.7.1 on Windows XP. See below for one more comment. On Sat, 2009-12-19 at 10:03 -0500, Duncan Murdoch wrote:> On 19/12/2009 8:56 AM, Martin Maechler wrote: > >>>>>> "DM" == Duncan Murdoch <murdoch at stats.uwo.ca> > >>>>>> on Fri, 18 Dec 2009 15:03:26 -0500 writes: > > > > DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote: > > >> On 18/12/2009 12:54 PM, Martin Maechler wrote: > > >>>>>>>> Martin Morgan <mtmorgan at fhcrc.org> > > >>>>>>>> on Fri, 18 Dec 2009 07:40:13 -0800 writes: > > >>> > Martin Maechler wrote: > > >>> >>>>>>> Martin Morgan <mtmorgan at fhcrc.org> > > >>> >>>>>>> on Thu, 17 Dec 2009 09:54:54 -0800 writes: > > >>> >> > > >>> >> > Ross Boylan wrote: > > >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote: > > >>> >> >>>>>>>> Ross Boylan <ross at biostat.ucsf.edu> > > >>> >> >>>>>>>> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes: > > >>> >> >>> > Full_Name: Ross Boylan > > >>> >> >>> > Version: 2.10.0 > > >>> >> >>> > OS: Windows XP > > >>> >> >>> > Submission from: (NULL) (198.144.201.14) > > >>> >> > > >>> > > >>> >> >>> > Some of the help for setGeneric seems to have been garbled. In the section > > >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a single line 3rd > > >>> >> >>> > paragraph) it says > > >>> >> >>> > <quote> > > >>> >> >>> > Note that calling 'setGeneric()' in this form is not strictly > > >>> >> >>> > necessary before calling 'setMethod()' for the same function. If > > >>> >> >>> > the function specified in the call to 'setMethod' is not generic, > > >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself. > > >>> >> >>> > Declaring explicitly that you want the function to be generic can > > >>> >> >>> > be considered better programming style; the only difference in the > > >>> >> >>> > result, however, is that not doing so produces a You cannot (and > > >>> >> >>> > never need to) create an explicit generic version of the primitive > > >>> >> >>> > functions in the base package. > > >>> >> >>> > <quote> > > >>> >> >>> > > >>> >> >>> > The stuff after the semi-colon of the final sentence is garbled, or at least > > >>> >> >>> > unparseable by me. Probably something got deleted by mistake. > > >>> >> >>> > > >>> >> >> > > >>> >> >> The last sentence of this paragraph is also garbled: > > >>> >> >> <quote> > > >>> >> >> The description above is the effect when the package that owns the > > >>> >> >> non-generic function has not created an implicit generic version. > > >>> >> >> Otherwise, it is this implicit generic function that is us_same_ > > >>> >> >> version of the generic function will be created each time. > > >>> >> >> </quote> > > >>> >> > > >>> >> > Off-list, I guess both of these paragraphs have very long lines in the > > >>> >> > source; maybe your emacs is truncating lines instead of wrapping, or > > >>> >> > something similar? > > >>> >> > > >>> >> Thank you, Martin, but no, we never have very long lines in the > > >>> >> R sources (and *.Rd files belong to the sources), > > >>> >> and then translation of the *.Rd file to a "data base" of > > >>> >> text-help entries should keep newlines. > > >>> > > >>> > I meant that they _are_ very long in the source. Martin > > >>> > > >>> Oh dear, yes indeed, you are right! > > >>> > > >>> So, astonishing as that may be, indeed for the 'text' version of > > >>> help, it seems that ... under some circumstances ... > > >>> the (NAMESPACE-hidden) method > > >>> utils:::print.help_files_with_topic() > > >>> > > >>> which ends up calling file.show() : > > >>> > > >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) { > > >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB, > > >>> basename(file)), out = tempfile("Rtxt"), package = pkgname) > > >>> file.show(temp, title = gettextf("R Help on '%s'", > > >>> topic), delete.file = TRUE) > > >>> } > > >>> > > >>> > > >>> *is* still influenced by the original *.Rd file's (lack) of new > > >>> lines, somewhat astonishingly to me. > > >>> > > >>> Even more, I cannot understand that other people do not see the > > >>> same phenomenon (though maybe they would if they cared to notice...), > > >>> and also that you only get the "garbling" problem with ESS, and > > >>> only for R version 2.10, but not 2.8. > > >>> Did our 'Rd2txt()' change here on purpose? > > >>> > > >> > > >> I seem to recall fixing a bug in the line wrapping code, but I can't > > >> spot it in a quick glance over the log. Maybe I forgot to commit the > > >> fix? I can't look into this now, but I'll follow up later. > > > > DM> The patch I recalled did get committed on November 8, with this NEWS entry: > > > > > > DM> o Text help rendering did not handle very long input lines > > DM> properly. > > > > > > DM> So it made it into 2.10.1. Do you still see the problem there? I don't > > DM> see it in text help for setGeneric in the Windows gui. > > > > DM> Duncan Murdoch > > > > I think it was never a problem in the GUI, > > however when using ESS. > > It was simply a problem of Rd2txt in 2.10.0, and appeared wherever that > was used: in the GUI, in Rterm, whatever.It did not appear for me when using the standard R GUI launched from the icon for R on the desktop.> The bug report was about an > obsolete version. > > Duncan Murdoch > > > > > For some reason, I did overlook that Ross was talking about > > Windows. I had never checked it on Windows, > > but did now {using our Windows terminal server}. > > > > Indeed: R 2.10.0 with ESS shows the problem Ross found > > R 2.10.1 with ESS *NO LONGER* shows the problem. > > > > --> I'm CC'ing R-bugs, as this bug report > > ... an R bug after all .. > > can be closed. > > > > Thanks to all helpers! > > Martin Maechler, ETH Zurich >