Re: [Rd] R CMD check warning with S3 method
While the change to the symbol lookup is generally useful (e.g., for
finding S4 methods that become available whenever a package is loaded), it
seems that we ultimately want a mechanism by which a package namespace can
formally declare that it is re-exporting a symbol from some package. Then,
for example, the check mechanism can be made smart enough to avoid throwing
such warnings.
I've developed a proof-of-concept exportFrom() namespace directive. This is
the syntax:
exportFrom(utils, help)
Then:
> getNamespaceInfo("ReexportingPackage", "exports")$help
[1] "help"
attr(,"origin")
[1] "utils"
Comments?
Michael
On Fri, Jun 27, 2014 at 8:32 PM, Yihui Xie wrote:
> Hi Duncan,
>
> Again, thanks a lot for making this change (help requests are tried
> over all loaded instead of attached packages):
> https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I
> proposed last time possible now: if pkg B imports FUN from A and
> re-exports it, ?FUN will work after B is attached because A will also
> be at least attached.
>
> Then it will be perfect if `R CMD check` can stop warning against the
> missing documentation, which is not really missing.
>
> Regards,
> Yihui
> --
> Yihui Xie
> Web: http://yihui.name
>
>
> On Fri, Jun 20, 2014 at 1:34 AM, Yihui Xie wrote:
> > but note that you will have to document it even if it is a function
> > imported from another package... Perhaps help() should be intelligent
> > enough to link the documentation of `FUN` from package A for package B
> > when B imports `FUN` from A, and exports it in B's NAMESPACE. The
> > package name of A may be obtained from
> > environmentName(environment(FUN)). At the moment, since R CMD check
> > will warn against the missing documentation of `FUN` in B, I have to
> > copy FUN.Rd from A to B in this case, which seems to be inefficient
> > and not a best way to maintain. Did I miss anything in the R-exts
> > manual?
> >
> > Regards,
> > Yihui
> > --
> > Yihui Xie
> > Web: http://yihui.name
> >
> >
> > On Fri, Jun 20, 2014 at 12:19 AM, Winston Chang
> wrote:
> >> On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer
> wrote:
> >>
> >>> Export filter in the NAMESPACE file *without copying it* in the R
> source
> >>> code.
> >>>
> >>>
> >> Ah, it works! Thank you!
> >>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [patch] Fix n arg in mclapply call to ngettext
Regarding the following code,
warning(sprintf(ngettext(has.errors,
"scheduled core %s encountered error in user code, all values of
the job will be affected",
"scheduled cores %s encountered errors in user code, all values
of the jobs will be affected"),
paste(has.errors, collapse = ", ")),
domain = NA)
has.errors is a vector whose elements are the cores that have encountered
errors. The plural message thus appears if the first element of has.errors is
greater than one and is singular otherwise. What we want is for the plural
message to be given if more than one core encountered errors. Changing the n
arg of ngettext from has.errors to length(has.errors) leads to the correct
messages.
Attached is a patch.
More details for completeness:
I've reproduced this on 3.1.0 and r66050.
Below is an example that leads to bad output sometimes (depending on
the order in which the cores finish).
library(parallel)
options(mc.cores = 4)
abc <- mclapply(2:5, FUN = function(x) stopifnot(x >= 4))
# Warning message:
# In mclapply(2:5, FUN = function(x) { :
# scheduled core 1, 2 encountered error in user code, all values of
the job will be affected
# if a core with number great than 1 has the only error, then an
incorrect message is shown:
library(parallel)
options(mc.cores = 4)
abc <- mclapply(2:5, FUN = function(x) stopifnot(x <= 4))
# Warning message:
# In mclapply(2:5, FUN = function(x) { :
# scheduled cores 4 encountered errors in user code, all values of
the jobs will be affected
> sessionInfo()
R Under development (unstable) (2014-06-29 r66050)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Scott
--
Scott Kostyshak
Economics PhD Candidate
Princeton University
Index: src/library/parallel/R/unix/mclapply.R
===
--- src/library/parallel/R/unix/mclapply.R (revision 66050)
+++ src/library/parallel/R/unix/mclapply.R (working copy)
@@ -172,7 +172,7 @@
if (length(has.errors) == cores)
warning("all scheduled cores encountered errors in user code")
else
-warning(sprintf(ngettext(has.errors,
+warning(sprintf(ngettext(length(has.errors),
"scheduled core %s encountered error in
user code, all values of the job will be affected",
"scheduled cores %s encountered errors in
user code, all values of the jobs will be affected"),
paste(has.errors, collapse = ", ")),
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning with S3 method
On 29/06/2014, 3:07 PM, Michael Lawrence wrote:
> While the change to the symbol lookup is generally useful (e.g., for
> finding S4 methods that become available whenever a package is loaded),
> it seems that we ultimately want a mechanism by which a package
> namespace can formally declare that it is re-exporting a symbol from
> some package. Then, for example, the check mechanism can be made smart
> enough to avoid throwing such warnings.
>
> I've developed a proof-of-concept exportFrom() namespace directive. This
> is the syntax:
>
> exportFrom(utils, help)
>
> Then:
>
>> getNamespaceInfo("ReexportingPackage", "exports")$help
> [1] "help"
> attr(,"origin")
> [1] "utils"
>
> Comments?
I don't see why this is needed. What does it gain over documenting that
the symbol "help" is just a copy of the one from utils? As of this
morning, that's easy...
Duncan Murdoch
>
> Michael
>
>
> On Fri, Jun 27, 2014 at 8:32 PM, Yihui Xie > wrote:
>
> Hi Duncan,
>
> Again, thanks a lot for making this change (help requests are tried
> over all loaded instead of attached packages):
> https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I
> proposed last time possible now: if pkg B imports FUN from A and
> re-exports it, ?FUN will work after B is attached because A will also
> be at least attached.
>
> Then it will be perfect if `R CMD check` can stop warning against the
> missing documentation, which is not really missing.
>
> Regards,
> Yihui
> --
> Yihui Xie mailto:xieyi...@gmail.com>>
> Web: http://yihui.name
>
>
> On Fri, Jun 20, 2014 at 1:34 AM, Yihui Xie > wrote:
> > but note that you will have to document it even if it is a function
> > imported from another package... Perhaps help() should be intelligent
> > enough to link the documentation of `FUN` from package A for package B
> > when B imports `FUN` from A, and exports it in B's NAMESPACE. The
> > package name of A may be obtained from
> > environmentName(environment(FUN)). At the moment, since R CMD check
> > will warn against the missing documentation of `FUN` in B, I have to
> > copy FUN.Rd from A to B in this case, which seems to be inefficient
> > and not a best way to maintain. Did I miss anything in the R-exts
> > manual?
> >
> > Regards,
> > Yihui
> > --
> > Yihui Xie mailto:xieyi...@gmail.com>>
> > Web: http://yihui.name
> >
> >
> > On Fri, Jun 20, 2014 at 12:19 AM, Winston Chang
> mailto:winstoncha...@gmail.com>> wrote:
> >> On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer > wrote:
> >>
> >>> Export filter in the NAMESPACE file *without copying it* in the
> R source
> >>> code.
> >>>
> >>>
> >> Ah, it works! Thank you!
> >>
>
> __
> 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
