Re: [R-pkg-devel] Documenting courtesy S3 methods
>From WRE:
"As from R 3.6.0 one can also use S3method() directives to perform
*delayed*registration.
With
if(getRversion() >= "3.6.0") {
S3method(pkg::gen, cls)
}
function gen.cls will get registered as an S3 method for class cls and
generic gen from package pkg only when the namespace of pkg is loaded. This
can be employed to deal with situations where the method is not
“immediately” needed, and having to pre-load the namespace of pkg (and all
its strong dependencies) in order to perform immediate registration is
considered too onerous."
I understand the issue is documentation, but if you took this route, could
you not document your S3 method as usual without loading multcomp's (or
whatever) namespace. You could include a \note section in the doc saying
that the multcomp namespace must be explicitly loaded if your method is to
be used (perhaps showing the code to do so)
If I am clearly mistaken about this, feel free to dismiss without reply.
Cheers,
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Wed, Aug 5, 2020 at 5:58 PM Lenth, Russell V
wrote:
> Dear package developers,
>
> My package offers a few methods whose generics are in other packages; for
> example, 'cld', for which the generic is in the 'multcomp' package. Unless
> the user wants to use cld() (which I don't even encourage), they do not
> need the multcomp package to use other features of my package. Therefore, I
> do not want to import and re-export multcomp::cld. Instead, on loading my
> package, I dynamically register the method via RegisterS3Method() if the
> user's system happens to have multcomp installed; and if they don't, then
> they can still use my package, just not the cld method. this has worked
> well and keeps down the number of dependencies.
>
> The problem is documenting it. I thought I had it solved by using this
> roxygen2 tag:
>
> #' @method multcomp::cld emmGrid
>
> In turn, this tag generates these lines in the \usage section of my .Rd
> file:
>
> \method{multcomp::cld}{emmGrid}(object, details = FALSE, sort = TRUE,
> by,
> alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
> reversed = FALSE, ...)
>
> and the resulting help file looks like this:
>
> ## S3 method for class 'emmGrid'
> multcomp::cld(object, details = FALSE, sort = TRUE, by,
> alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
> reversed = FALSE, ...)
>
> This is exactly what I want. It tells the user clearly that if they want
> to use cld(), they have to have multcomp installed, and either name it
> explicitly in the call or have it in the search path.
>
> No problems occur until I check the package, when I get this warning
> message:
>
> Bad \usage lines found in documentation object 'summary.emmGrid':
> method{multcomp::cld}{emmGrid}(object, details =
> FALSE, sort = TRUE, by,
> alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
> reversed = FALSE, ...)
>
> Well I suppose this is "bad" as in unexpected; but it seems to be not bad
> in that it doesn't keep the help page from formatting correctly. And truly,
> I don't see how it could cause any harm. At lest the usage comes out
> correctly in both the HTML help and the PDF manual.
>
> I can avoid the problem just by omitting "multcomp::". But then the user
> doesn't get such a clear message about how to use the function.
>
> I'm interested in suggestions, but again I would regard importing
> multcomp::cld as an unhelpful suggestion. We ought to be able to provide
> courtesy methods for generics in other packages (and this is not the only
> one in my package) without importing a whole bunch of unneeded stuff and
> doubling the number of required installations.
>
> Thanks
>
> Russ
>
> Russell V. Lenth - Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa - Iowa City, IA 52242 USA
> Voice (319)335-0712 (Dept. office) - FAX (319)335-3017
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] incomplete gamma function Fortran subroutine
BTW, if you search for "incomplete gamma function" on Rseek.org, you will find whole packages for this. Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Tue, Jul 21, 2020 at 10:54 AM Bert Gunter wrote: > Why? -- see ?dgamma > > See also the section on including fortran code in "Writing R Extensions," > which should be your first port of call for such questions. > > If neither of these is what you need, it may be helpful if you explain why > not. > > Bert Gunter > > "The trouble with having an open mind is that people keep coming along and > sticking things into it." > -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) > > > On Tue, Jul 21, 2020 at 10:45 AM Wang, Zhu wrote: > >> Hello, >> >> In an R function within a package, I would like to call a Fortran >> subroutine to compute lower gamma function. Any advice will be appreciated. >> >> Thanks! >> >> Zhu Wang >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] incomplete gamma function Fortran subroutine
Why? -- see ?dgamma See also the section on including fortran code in "Writing R Extensions," which should be your first port of call for such questions. If neither of these is what you need, it may be helpful if you explain why not. Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Tue, Jul 21, 2020 at 10:45 AM Wang, Zhu wrote: > Hello, > > In an R function within a package, I would like to call a Fortran > subroutine to compute lower gamma function. Any advice will be appreciated. > > Thanks! > > Zhu Wang > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] error when submit a package
Did you not post this before and receive answers? Please explain why the previous answers were insufficient. "Some notes are not fixable" is not a satisfactory response. Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Fri, Jun 26, 2020 at 11:50 AM Guo, Wei (NIH/NIMH) [C] via R-package-devel wrote: > Good afternoon, > > I am trying to submit my package to CRAN, and it failed to pass the checks > due to 5 notes. I am wondering how to fix it. > > Within the 5 notes, some are not fixable. > Thanks. > Best, > Wei > > > > Dear maintainer, > > package postGGIR_2.0.0.tar.gz does not pass the incoming checks > automatically, please see the following pre-tests: > > Windows: < > https://win-builder.r-project.org/incoming_pretest/postGGIR_2.0.0_20200626_200952/Windows/00check.log > > > > Status: 5 NOTEs > > Debian: < > https://win-builder.r-project.org/incoming_pretest/postGGIR_2.0.0_20200626_200952/Debian/00check.log > > > > Status: 6 NOTEs > > > ... > Wei Guo [C] | Biostatistician > National Institute of Mental Health (NIMH) > E-mail: wei.g...@nih.gov<mailto:wei.g...@nih.gov> > Tel: 301-435-2206 > 35 Convent Dr, Bethesda,MD,20892 > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: Two packages with the same generic function
Yes, but I think my concern may have been bogus. WRE says that even though
the whole package is loaded, it is *not* placed on the search path. Only
exports from the package go on the search path. So if the imported generic
is not then explicitly exported, it would not be seen nor cause a conflict
with another generic of the same name that is exported.
At least that's my understanding. However, this discussion is getting too
esoteric for me, so I'm just going to shut up and leave it to folks who are
more knowledgeable. With apologies for my noise.
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Tue, Jun 23, 2020 at 7:29 AM Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
> Still, if pkgA imports the generic from pkgB, then installing pkgA
> installs pkgB and all of its dependencies (Depends and Imports). Which of
> course makes sense (as otherwise pkgB cannot be installed). But all of this
> just for importing
>
> foo <- function(x, ...)
>UseMethod("foo")
>
> from pkgB.
>
> Best,
> Wolfgang
>
> >-Original Message-
> >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
> >Behalf Of Duncan Murdoch
> >Sent: Tuesday, 23 June, 2020 12:25
> >To: Guido Schwarzer; r-package-devel@r-project.org
> >Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same
> generic
> >function
> >
> >On 23/06/2020 4:22 a.m., Guido Schwarzer wrote:
> >> Am 23.06.20 um 10:00 schrieb Viechtbauer, Wolfgang (SP):
> >>> [...]
> >>> @Neal: A separate package with generic functions that pkgA and pkgB
> could
> >import is an interesting suggestion, thanks!
> >>
> >> What makes this interesting is that there is no dependency on other
> >> packages in generics.
> >>
> >> Remains the question which help page would be shown for help(foo).
> >
> >If a package imports and then exports the generic, it would normally
> >create a help page referring to the original one where the generic is
> >defined. So both pkgA and pkgB would probably both create help pages,
> >and the help system would show a page listing them both plus the generic
> >one, and asking the user to choose.
> >
> >An example happens if you use
> >
> >library(broom)
> >?tidy
> >
> >The broom package links to a page that says "These objects are imported
> >from other packages. Follow the links below to see their documentation."
> >One of the links is to the ?tidy page in the generics package.
> >
> >You are allowed to say ?broom::tidy, and then you don't go to the list
> >of possibilities, you go directly to the one you asked for.
> >
> >Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: Two packages with the same generic function
OK. Thanks.
Bert Gunter
On Mon, Jun 22, 2020 at 7:51 PM wrote:
> On Tue, 23 Jun 2020, Bert Gunter wrote:
>
> > "Users don't get warned about overriding names in packages they've
> > loaded, because that would just be irritating."
>
> All Duncan is saying is that you don't get a notification if you do
>
> mean <- log
>
> in the interpreter. If you attach a package that does this you would
> get a notification (or an error if you configure your conflict
> resolution options appropriately).
>
> Best,
>
> luke
>
> >
> > Is that also true if the package or generic is imported by another that
> > they load; or is a dependency of a package they load? If so, I would not
> > call it "just irritating" because if silent, how would they know?
> >
> >
> > Bert Gunter
> >
> > "The trouble with having an open mind is that people keep coming along
> and
> > sticking things into it."
> > -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
> >
> >
> > On Mon, Jun 22, 2020 at 5:58 PM Mark Leeds wrote:
> >
> >> Hi Duncan: I maintain dynlm and your example is the exact reason I've
> been
> >> getting emails from people regarding
> >> it not working correctly. I've been telling them to load dplyr by using
> >>
> >> library(dplyr, exclude = c("filter", "lag"))
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Jun 22, 2020 at 7:57 PM Duncan Murdoch <
> murdoch.dun...@gmail.com>
> >> wrote:
> >>
> >>> On 22/06/2020 3:48 p.m., Tom Wainwright wrote:
> >>>> Yet another alternative is simply to prevent your second package from
> >>>> overriding the previously defined generic. The basic problem is the
> >> ease
> >>>> with which R allows overriding prior generic definitions (one of those
> >>> bits
> >>>> of bad behavior we in the USA used to call "a Bozo No-No"), which
> hides
> >>> all
> >>>> the previous methods, as demonstrated by the following code:
> >>>>
> >>>>> plot(1:3)
> >>>>>> plot <- function(x, ...) UseMethod("plot")
> >>>>>> plot(1:3)
> >>>>> Error in UseMethod("plot") :
> >>>>>no applicable method for 'plot' applied to an object of class
> >>>>> "c('integer', 'numeric')"
> >>>>>> rm(plot)
> >>>>>> plot(1:3)
> >>>>
> >>>>
> >>>> (Despite Murdoch's suggestion that overriding the generic SHOULD issue
> >> a
> >>>> warning, it doesn't seem to in R 4.0.1.)
> >>>
> >>> Sure it does, if pkgA and pkgB both export the same name, then you get
> a
> >>> warning when you attach the second one. For example,
> >>>
> >>> > library(MASS)
> >>> > library(dplyr)
> >>>
> >>> Attaching package: ‘dplyr’
> >>>
> >>> The following object is masked from ‘package:MASS’:
> >>>
> >>> select
> >>>
> >>> The following objects are masked from ‘package:stats’:
> >>>
> >>> filter, lag
> >>>
> >>> The following objects are masked from ‘package:base’:
> >>>
> >>> intersect, setdiff, setequal, union
> >>>
> >>> Users don't get warned about overriding names in packages they've
> >>> loaded, because that would just be irritating.
> >>>
> >>> Duncan Murdoch
> >>>
> >>>>
> >>>> So, we might try protecting the generic definitions of "foo" in both
> >>>> packages by enclosing them in something like:
> >>>>
> >>>> tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
> >>>>> UseMethod("foo")}, finally=NULL)
> >>>>
> >>>>
> >>>> There's probably a more elegant way to accomplish this. This relies on
> >>>> "methods" returning an error if "foo" has no defined methods, so it is
> >>> not
> >>>> redefined if their are previous methods. I haven't had time to try
> this
> >>> in
> >>>> the two-package example, but it might work, although I'm not sure how
> >> to
> >>>> handle t
Re: [R-pkg-devel] Two packages with the same generic function
"Users don't get warned about overriding names in packages they've
loaded, because that would just be irritating."
Is that also true if the package or generic is imported by another that
they load; or is a dependency of a package they load? If so, I would not
call it "just irritating" because if silent, how would they know?
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, Jun 22, 2020 at 5:58 PM Mark Leeds wrote:
> Hi Duncan: I maintain dynlm and your example is the exact reason I've been
> getting emails from people regarding
> it not working correctly. I've been telling them to load dplyr by using
>
> library(dplyr, exclude = c("filter", "lag"))
>
>
>
>
>
> On Mon, Jun 22, 2020 at 7:57 PM Duncan Murdoch
> wrote:
>
> > On 22/06/2020 3:48 p.m., Tom Wainwright wrote:
> > > Yet another alternative is simply to prevent your second package from
> > > overriding the previously defined generic. The basic problem is the
> ease
> > > with which R allows overriding prior generic definitions (one of those
> > bits
> > > of bad behavior we in the USA used to call "a Bozo No-No"), which hides
> > all
> > > the previous methods, as demonstrated by the following code:
> > >
> > >> plot(1:3)
> > >>> plot <- function(x, ...) UseMethod("plot")
> > >>> plot(1:3)
> > >> Error in UseMethod("plot") :
> > >>no applicable method for 'plot' applied to an object of class
> > >> "c('integer', 'numeric')"
> > >>> rm(plot)
> > >>> plot(1:3)
> > >
> > >
> > > (Despite Murdoch's suggestion that overriding the generic SHOULD issue
> a
> > > warning, it doesn't seem to in R 4.0.1.)
> >
> > Sure it does, if pkgA and pkgB both export the same name, then you get a
> > warning when you attach the second one. For example,
> >
> > > library(MASS)
> > > library(dplyr)
> >
> > Attaching package: ‘dplyr’
> >
> > The following object is masked from ‘package:MASS’:
> >
> > select
> >
> > The following objects are masked from ‘package:stats’:
> >
> > filter, lag
> >
> > The following objects are masked from ‘package:base’:
> >
> > intersect, setdiff, setequal, union
> >
> > Users don't get warned about overriding names in packages they've
> > loaded, because that would just be irritating.
> >
> > Duncan Murdoch
> >
> > >
> > > So, we might try protecting the generic definitions of "foo" in both
> > > packages by enclosing them in something like:
> > >
> > > tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
> > >> UseMethod("foo")}, finally=NULL)
> > >
> > >
> > > There's probably a more elegant way to accomplish this. This relies on
> > > "methods" returning an error if "foo" has no defined methods, so it is
> > not
> > > redefined if their are previous methods. I haven't had time to try this
> > in
> > > the two-package example, but it might work, although I'm not sure how
> to
> > > handle the Namespace declarations.
> > >
> > >Tom Wainwright
> > >
> > > On Mon, Jun 22, 2020 at 10:41 AM Bert Gunter
> > wrote:
> > >
> > >> ...
> > >> and just to add to the query, assume the author of pkg B did (does)
> not
> > >> know of pkg A and so, for example, could (did) not import any of pkg
> A's
> > >> content into B. Given that there are at the moment ~20,000 packages
> out
> > >> there, this does not seem to be an unreasonable assumption. One may
> even
> > >> further assume that the user may not know that (s)he has package B
> > loaded,
> > >> as it may be a dependency of another package that (s)he uses. I
> > certainly
> > >> don't keep track of all the dependencies of packages I use.
> > >>
> > >> Under these assumptions, is there any more convenient alternative to
> > >> Wolfgang's pkgA:foo(x) explicit call under such assumptions? If pkgA
> > has a
> > >> long name, what might one do?
> > >>
> > >> Bert Gunter
> > >>
> > >> "The trouble with having an open mind is that peopl
Re: [R-pkg-devel] Two packages with the same generic function
...
and just to add to the query, assume the author of pkg B did (does) not
know of pkg A and so, for example, could (did) not import any of pkg A's
content into B. Given that there are at the moment ~20,000 packages out
there, this does not seem to be an unreasonable assumption. One may even
further assume that the user may not know that (s)he has package B loaded,
as it may be a dependency of another package that (s)he uses. I certainly
don't keep track of all the dependencies of packages I use.
Under these assumptions, is there any more convenient alternative to
Wolfgang's pkgA:foo(x) explicit call under such assumptions? If pkgA has a
long name, what might one do?
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, Jun 22, 2020 at 10:00 AM Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
> Hi All,
>
> Let's say there are two packages pkgA and pkgB, both of which have a
> generic function
>
> foo <- function(x, ...)
>UseMethod("foo")
>
> and pkgA has a method for objects of class "A":
>
> foo.A <- function(x, ...)
>print(x)
>
> and pkgB has a method for objects of class "B":
>
> foo.B <- function(x, ...)
>plot(x)
>
> Both packages export foo and their method and declare their respective S3
> methods, so:
>
> export(foo)
> export(foo.A)
> S3method(foo, A)
>
> in NAMESPACE of pkgA and
>
> export(foo)
> export(foo.B)
> S3method(foo, B)
>
> in NAMESPACE of pkgB.
>
> If a user loads pkgA first and then pkgB, this fails:
>
> library(pkgA)
> library(pkgB)
> x <- 1:4
> class(x) <- "A"
> foo(x)
>
> Error in UseMethod("foo") :
> no applicable method for 'foo' applied to an object of class "A"
>
> and vice-versa. Of course, pkgA::foo(x) works. Aside from pkgA importing
> foo() or vice-versa, is there some other clever way to make this work? In
> earlier versions of R (at least in 3.6.3), this used to work (i.e., the
> generic foo() from pkgB would find method foo.A() and vice-versa), but not
> since 4.0.0.
>
> Best,
> Wolfgang
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Uncaught use of internal functions from other packages in R CMD check
Do note that ?asNamespace says:
"Not **intended** to be called directly," (emphasis added)
but not "should never be called directly" or some such. I don't know if
this makes a difference to package checking, but it isn't clear to me that
it would.
Cheers,
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, Jun 15, 2020 at 3:03 PM Balasubramanian Narasimhan <
na...@stanford.edu> wrote:
> At least one package on CRAN uses
>
> get("foo", envir=asNamespace("imported_package"))
>
> and passes check.
>
> Is this known?
>
> -Naras
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] A Note about Vignette
You really need to read the 'Writing R Extensions" manual, in particular the section on the DESCRIPTION file. You are asking basic questions that are covered there. Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Mon, May 11, 2020 at 2:09 PM Sapphire Zhou wrote: > > I obtained a note for my R package from the feedback of CRAN > > > Package has a VignetteBuilder field but no prebuilt vignette index. > > > Actually, there is no vignettes in my package. What is meaning of this note? > How could I fix it? > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Assigning values to fields in Reference Classes
What does this have to do with package development? Seems more like a
query for r-help.
Cheers,
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, May 11, 2020 at 11:27 AM Per Nyfelt wrote:
>
> Hi,
>
> I have been playing with alternative ways to assign values to fields in
> reference classes.
>
> Besides the "standard" <<- there are two other ways that also "seems to
> work". One is using .self$fieldName assigned with <- and the the other
> one is field(fieldName, value).
>
> With regards to the ".self method" (example below): is this a "safe"
> equivalent to <<- i.e. are these two ways identical in result and
> possible "side effects"?
>
> StandardAssignment <- setRefClass(
>Class ="StandardAssignment",
>fields = list(
> m_attributes = "list"
>),
>methods = list(
> setAttribute = function(name, value) {
>m_attributes[[as.character(name)]] <<- as.character(value)
>return(invisible(.self))
> },
> getAttribute = function(name) {
>m_attributes[[name]]
> }
>)
> )
>
> s1 <- StandardAssignment$new()
> s1$setAttribute("name", "foo")
> s1$getAttribute("name")
>
> [1] "foo"
>
> SelfAssignment <- setRefClass(
>Class ="SelfAssignment",
>fields = list(
> m_attributes = "list"
>),
>methods = list(
> setAttribute = function(name, value) {
>.self$m_attributes[[as.character(name)]] <- as.character(value)
>return(invisible(.self))
> },
> getAttribute = function(name) {
>m_attributes[[name]]
> }
>)
> )
>
> s2 <- SelfAssignment$new()
> s2$setAttribute("name", "foo")
> s2$getAttribute("name")
>
> [1] "foo"
>
>
> Best regards,
>
> Per
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Documentation for non-user-level objects
1. Don't export them.
2. Use: \keyword{ internal } in the .Rd file
>From "Writing R Extensions"
"The special keyword ‘internal’ marks a page of internal objects that
are not part of the package’s API. If the help page for object foo has
keyword ‘internal’, then help(foo) gives this help page, but foo is
excluded from several object indices, including the alphabetical list
of objects in the HTMLhelp system."
Cheers,
Bert
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Sun, May 10, 2020 at 2:31 PM Sapphire Zhou
wrote:
>
> I met a problem when I uploaded the package to CRAN. There is a warning told
> me
> “All user-level objects in a package should have documentation entries.”
>
> Actually, those functions are not user-level functions. How could I claim
> non-user-level functions in an R package.
> Is there any idea to remove this warning.
>
> Thanks!
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FORGED] Math symbols in .Rd files
Thanks, Rolf. This is very helpful.
Actually, I'm not that concerned about latex --> pdf. It's the html
that I want rendered nicely. So I'll see is that \enc{...} approach
works and gets me through the CRAN checks.
Not that the package is a big deal anyway -- just something I hope
might be useful to a few folks on occasion.
Bert
On Wed, Apr 22, 2020 at 7:17 PM Rolf Turner wrote:
>
>
> On 23/04/20 11:03 am, Bert Gunter wrote:
>
> > OS: Mac OSX Catalina
> > R Version 3.6.3
> > UTF-8 declared as Encoding in DESCRIPTION file
> >
> > First, apologies: I'm nearly certain that this has been asked (many
> > times) before, and I think I know the answer. But I need to verify.
> >
> > \eqn{...} allows me to insert a few math symbols in .Rd files, but
> > does not seem to work for symbols equivalent to unicode U+00B0 (degree
> > sign) and U+00B1 (plus minus sign). That is \eqn{\pm } is not rendered
> > properly, and there is no degree sign for Latex without adding
> > packages. I can enter these as Mac symbols (presumably using UTF-8
> > encoding) and they render properly on my machine in the installed
> > package documentation. But CRAN's winbuilder doesn't like them with
> > error message:
> >
> > LaTeX errors found:
> > ! Package inputenc Error: Unicode char ≤ (U+2264)
> > (inputenc)not set up for use with LaTeX.
> >
> > Are there any fixes/workarounds other than a fallback to plain text?
> >
> > Thanks. Again, my apologies for asking this again, but I just wanted
> > to be sure my understanding is correct -- or find out where I'm
> > confused.
>
> My understanding is that \eqn{...} doesn't really work with html, only
> with LaTeX. You need to do something like:
>
> \eqn{\hat{\theta} \pm 1.96 \times SE}{theta.hat +/- 1.96*SE}
>
> which (for me at least) gives a nicely rendered result in LaTeX -> pdf
> and the kludgy workaround in html.
>
> As for the degree sign I find that \eqn{42^\circ} gives acceptable
> results in LaTeX, but of course doesn't work in html.
>
> My understanding is that if you enclose things like "±" or "°" in
> \enc{...} and have
>
> \encoding{UTF-8}
>
> as the very first line of your *.Rd file, then CRAN won't complain about
> the presence of these symbols. But this doesn't work inside \eqn{...};
> there the "\enc{...}" gets rendered literally.
>
> So for html I think you are stuck with the kludgy fallback to plain text.
>
> cheers,
>
> Rolf
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Math symbols in .Rd files
OS: Mac OSX Catalina
R Version 3.6.3
UTF-8 declared as Encoding in DESCRIPTION file
First, apologies: I'm nearly certain that this has been asked (many
times) before, and I think I know the answer. But I need to verify.
\eqn{...} allows me to insert a few math symbols in .Rd files, but
does not seem to work for symbols equivalent to unicode U+00B0 (degree
sign) and U+00B1 (plus minus sign). That is \eqn{\pm } is not rendered
properly, and there is no degree sign for Latex without adding
packages. I can enter these as Mac symbols (presumably using UTF-8
encoding) and they render properly on my machine in the installed
package documentation. But CRAN's winbuilder doesn't like them with
error message:
LaTeX errors found:
! Package inputenc Error: Unicode char ≤ (U+2264)
(inputenc)not set up for use with LaTeX.
Are there any fixes/workarounds other than a fallback to plain text?
Thanks. Again, my apologies for asking this again, but I just wanted
to be sure my understanding is correct -- or find out where I'm
confused.
Bert Gunter
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Validate CRAN package using a linked library
Are you aware of Ryacas or rSymPy ?? If not, does it really add anything to these? If so, feel free to ignore. Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it.” -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) > On Sep 14, 2016, at 5:52 AM, Dorel, Mathurin <mathurin.do...@charite.de> > wrote: > > Hi, > > I developed a package using the symbolic calculus C library ginac > (http://www.ginac.de/<https://email.charite.de/owa/redir.aspx?REF=fSvQ3yE_XkDlPenE4F0MzYwBnO23griAuHvI5OZfSugms-XfndzTCAFodHRwOi8vd3d3LmdpbmFjLmRlLw..>). > I want to submit my package to CRAN, but the library is not installed on CRAN > computers > so the C/C++ code does not compile on CRAN winbuilder > (http://win-builder.r-project.org/upload.aspx<https://email.charite.de/owa/redir.aspx?REF=KMGXFEO-FDxPH92uJokI4LhZLoWd8IY1gdu9k7Wswrcms-XfndzTCAFodHRwOi8vd2luLWJ1aWxkZXIuci1wcm9qZWN0Lm9yZy91cGxvYWQuYXNweA..>). > > What would be an appropriate solution? Should I ask the CRAN administrators > to install ginac on > their test machines, or should I submit a source package in the style of BH > which would provided > a compiled version of the ginac library that I could link to? > > Best, > Mathurin Dorel > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] vignette issues
Folks:
My stripless package passed all cran checks and built without issues.
But I received the following message from the Windows build:
-
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]]) :
there is no package called ‘lme4'
Quitting from lines 108-111 (stripless_vignette.Rmd)
Error: processing vignette 'stripless_vignette.Rmd' failed with diagnostics:
object 'hsb' not found
Execution halted
-
I do not have any reference to lme4 in my package or vignette. So is this the
dependency from the faraway package, which my vignette uses (a couple of its
datasets) and which does depend on lme4? If so, do I have to move faraway from
my “suggests” to “imports” or “depends, which I read as contrary to what the R
extensions manual says. If so, this sounds like a bug to me — why should I be
responsible for such dependencies, which could be endless?
2nd: “hsb” is in the faraway package. I state specifically in the vignette
that the package needs to be installed, and I have the following code in the
vignette (using rmarkdown and knitr):
```{r, echo = FALSE,message= FALSE }
if(!require(faraway, quietly = TRUE)){
cat("\n, The **faraway** package must be installed to run",
"subsequent examples in this vignette.\n",sep = "")
}
```
I don’t think I should install the package automatically, as this seems an
inappropriate intrusion on the user. I do make the compiled pdf version
available in /docs. What is “appropropriate behavior” for me to avoid these
warnings?
Best,
Bert
Bert Gunter
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
