Re: [Rd] Expected error with help.search in R 3.2.0
> On 14-06-2015, at 06:47, David Winsemius wrote:
>
> Using the Mavericks/Yosemite version of R 3.2.0, I see this:
>
>> utils::help.search("linear models")
> Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib, :
> 'topic' should be a name, length-one character vector or reserved word
>
> Using R 3.1.2 on a SnowLeapard branch does not produce the same result. I do
> get the expected large number of hits where those words are in the help
> pages. It's an error message from the `help` function, so seems less likely
> to be restricted to Macs. I do see that the help() code near the stop() call
> is the same in both versions. I do not see where `help.search` calls `help`.
>
> Tracing help is unrevealing. The first call to `help` throws the error and
> the call looks exactly like the calls in R 3.1.2
>
See this thread on R-SIG-Mac
https://stat.ethz.ch/pipermail/r-sig-mac/2015-April/011420.html
This may help.
Get R 3.2.0-patched or even the release candidate for R 3.2.1
Berend
> --
> David Winsemius
> Alameda, CA, USA
>
> __
> 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
[Rd] Expected error with help.search in R 3.2.0
Using the Mavericks/Yosemite version of R 3.2.0, I see this:
> utils::help.search("linear models")
Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib, :
'topic' should be a name, length-one character vector or reserved word
Using R 3.1.2 on a SnowLeapard branch does not produce the same result. I do
get the expected large number of hits where those words are in the help pages.
It's an error message from the `help` function, so seems less likely to be
restricted to Macs. I do see that the help() code near the stop() call is the
same in both versions. I do not see where `help.search` calls `help`.
Tracing help is unrevealing. The first call to `help` throws the error and the
call looks exactly like the calls in R 3.1.2
--
David Winsemius
Alameda, CA, USA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Lack of protection bug in current R release candidate
The current R release candidate has a lack of protect bug (of very
long standing) with respect to the R_print.na_string and
R_print.na_string_noquote fields of the static R_print structure
declared in Print.h. This shows up very occassionally as incorrect
output from the following lines in reg-tests-2.R:
x <- c("a", NA, "b")
factor(x)
factor(x, exclude="")
The solution (kludgy, but the whole concept is kludgy) is to forward
R_print.na_string and R_print.na_string_noquote with the other "roots"
in RunGenCollect (after the comment /* forward all roots */).
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Declaring "foo.bar" as nonS3method() ?!
Dear Martin et al., Thank you for considering so thoroughly the issue that I raised. Best, John On Sat, 13 Jun 2015 13:35:41 +0200 Martin Maechler wrote: > > Luke Tierney > > on Fri, 12 Jun 2015 10:30:29 -0500 writes: > > > The notes available off the devloper page > > https://developer.r-project.org/ describe some of the rationale for > > the S3 method search design. One thing that has changed since then is > > that all packages now have name spaces. We could change the search > > algorithm to skip attached package exports (and package imports and > > base), which would require methods defined in packages that are to be > > accessible outside the package to be declared. Methods defined inside > > a package for internal use or methods defined in scripts not in > > packages would still be found. Packages not currently registering > > their methods would have to do so -- not sure how many that would > > affect. Testing on CRAN/Bioc should show how much of an effect this > > would have and whether there are any other issues. > > > Best, > > luke > > Thanks a lot Luke, for the extra perspective. > I think the four R core commenters here (Duncan, Kurt, Luke and > me) agree that this is not trivial to implement, but hopefully > not too hard either, and I think we also +- agree that it seems > desirable to try adding a bit more flexibility in how functions > are "made into" S3 methods. > > I had not envisaged to change the S3 method search > algorithm but rather to tweak part of it "database" but am aware > that I don't know enough of the details. > Also, I did not find which notes (from developer.r-project.org) > you were refering to. > > Given the broad agreement that we want to start working / > investigating this, we can well close the thread here for now > (and deal with ideas, issues, details within R-core). > > Martin > > > On Fri, 12 Jun 2015, Duncan Murdoch wrote: > > >> On 12/06/2015 10:53 AM, Hadley Wickham wrote: > >>> To me, it seems like there's actually two problems here: > >>> > >>> 1) Preventing all() from dispatching to all.effects() for objects of > >>> class effects > >>> 2) Eliminating the NOTE in R CMD check > >>> > >>> My impression is that 1) actually causes few problems, particularly > >>> since people are mostly now aware of the problem and avoid using `.` > >>> in function names unless they're S3 methods. Fixing this issue seems > >>> like it would be a lot of work for relatively little gain. > >>> > >>> However, I think we want to prevent people from writing new functions > >>> with this confusing naming scheme, but equally we want to grandfather > >>> in existing functions, because renaming them all would be a lot of > >>> work (I'm looking at you t.test()!). > >>> > >>> Could we have a system similar to globalVariables() where you could > >>> flag a function as definitely not being an S3 method? I'm not sure > >>> what R CMD check should do - ideally you wouldn't be allow to use > >>> method.class for new functions, but still be able suppress the note > >>> for old functions that can't easily be changed. > >> > >> We have a mechanism for suppressing the warning for existing functions, > >> it's just not available to users to modify. So it would be possible to > >> add effects::all.effects to the stop list, and this might be the > easiest > >> action here. > >> > >> This isn't perfect because all.effects() would still act as a method. > >> However, it does give the deprecated message if you ever call it, so > >> nobody would do this unknowingly. The only real risk is that if anyone > >> ever wrote an all.effects function that *was* supposed to be an S3 > >> method, it might be masked by the one in effects. > >> > >> Duncan Murdoch > >> > >>> > >>> Hadley > >>> > >>> On Fri, Jun 12, 2015 at 6:52 AM, Kurt Hornik > wrote: > > Duncan Murdoch writes: > > > On 12/06/2015 7:16 AM, Kurt Hornik wrote: > >>> Duncan Murdoch writes: > >> > >>> On 12/06/2015 4:12 AM, Martin Maechler wrote: > This is a topic ' "apparent S3 methods" note in R CMD check ' > from R-package-devel > https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html > > which is relevant to here because some of us have been thinking > about extending R because of the issue. > > John Fox, maintainer of the 'effects' package has enquired about > the following output from 'R CMD check effects' > > > * checking S3 generic/method consistency ... NOTE > > Found the following apparent S3 methods exported but not > registered: > > all.effe
Re: [Rd] RFC: Declaring "foo.bar" as nonS3method() ?!
> Luke Tierney > on Fri, 12 Jun 2015 10:30:29 -0500 writes: > The notes available off the devloper page > https://developer.r-project.org/ describe some of the rationale for > the S3 method search design. One thing that has changed since then is > that all packages now have name spaces. We could change the search > algorithm to skip attached package exports (and package imports and > base), which would require methods defined in packages that are to be > accessible outside the package to be declared. Methods defined inside > a package for internal use or methods defined in scripts not in > packages would still be found. Packages not currently registering > their methods would have to do so -- not sure how many that would > affect. Testing on CRAN/Bioc should show how much of an effect this > would have and whether there are any other issues. > Best, > luke Thanks a lot Luke, for the extra perspective. I think the four R core commenters here (Duncan, Kurt, Luke and me) agree that this is not trivial to implement, but hopefully not too hard either, and I think we also +- agree that it seems desirable to try adding a bit more flexibility in how functions are "made into" S3 methods. I had not envisaged to change the S3 method search algorithm but rather to tweak part of it "database" but am aware that I don't know enough of the details. Also, I did not find which notes (from developer.r-project.org) you were refering to. Given the broad agreement that we want to start working / investigating this, we can well close the thread here for now (and deal with ideas, issues, details within R-core). Martin > On Fri, 12 Jun 2015, Duncan Murdoch wrote: >> On 12/06/2015 10:53 AM, Hadley Wickham wrote: >>> To me, it seems like there's actually two problems here: >>> >>> 1) Preventing all() from dispatching to all.effects() for objects of >>> class effects >>> 2) Eliminating the NOTE in R CMD check >>> >>> My impression is that 1) actually causes few problems, particularly >>> since people are mostly now aware of the problem and avoid using `.` >>> in function names unless they're S3 methods. Fixing this issue seems >>> like it would be a lot of work for relatively little gain. >>> >>> However, I think we want to prevent people from writing new functions >>> with this confusing naming scheme, but equally we want to grandfather >>> in existing functions, because renaming them all would be a lot of >>> work (I'm looking at you t.test()!). >>> >>> Could we have a system similar to globalVariables() where you could >>> flag a function as definitely not being an S3 method? I'm not sure >>> what R CMD check should do - ideally you wouldn't be allow to use >>> method.class for new functions, but still be able suppress the note >>> for old functions that can't easily be changed. >> >> We have a mechanism for suppressing the warning for existing functions, >> it's just not available to users to modify. So it would be possible to >> add effects::all.effects to the stop list, and this might be the easiest >> action here. >> >> This isn't perfect because all.effects() would still act as a method. >> However, it does give the deprecated message if you ever call it, so >> nobody would do this unknowingly. The only real risk is that if anyone >> ever wrote an all.effects function that *was* supposed to be an S3 >> method, it might be masked by the one in effects. >> >> Duncan Murdoch >> >>> >>> Hadley >>> >>> On Fri, Jun 12, 2015 at 6:52 AM, Kurt Hornik wrote: > Duncan Murdoch writes: > On 12/06/2015 7:16 AM, Kurt Hornik wrote: >>> Duncan Murdoch writes: >> >>> On 12/06/2015 4:12 AM, Martin Maechler wrote: This is a topic ' "apparent S3 methods" note in R CMD check ' from R-package-devel https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html which is relevant to here because some of us have been thinking about extending R because of the issue. John Fox, maintainer of the 'effects' package has enquired about the following output from 'R CMD check effects' > * checking S3 generic/method consistency ... NOTE > Found the following apparent S3 methods exported but not registered: > all.effects and added > The offending function, all.effects(), is deprecated in favour of > allEffects(), but I'd rather not get rid of it for backwards compatibility. > Is there any way to suppress the note without removing all.effects()? and I had agreed that this
