[R-pkg-devel] "apparent S3 methods" note in R CMD check

[John Fox]

Dear list members,

One of the packages I maintain, effects, generates the following note in R
CMD check:

* checking S3 generic/method consistency ... NOTE
Found the following apparent S3 methods exported but not registered:
  all.effects

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()? 

To be clear, all.effects() is *not* a method of all(), and is defined as

> effects::all.effects
function (...) 
{
.Deprecated("allEffects")
allEffects(...)
}


Thanks,
 John

-------
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
http://socserv.socsci.mcmaster.ca/jfox/




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] "apparent S3 methods" note in R CMD check

[John Fox]

Dear Martin,

Thank you for addressing this issue. Introducing a nonS3method() directive in 
NAMESPACE seems a reasonable solution. It could replace export() for functions 
with "."s in their names.

Best,
 John

On Fri, 12 Jun 2015 09:55:18 +0200
 Martin Maechler  wrote:
> >>>>> John Fox 
> >>>>> on Wed, 10 Jun 2015 10:12:46 -0400 writes:
> 
> > Dear list members,
> > One of the packages I maintain, effects, generates the following note 
> in R
> > CMD check:
> 
> > * checking S3 generic/method consistency ... NOTE
> > Found the following apparent S3 methods exported but not registered:
> > all.effects
> 
> > 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()? 
> 
> > To be clear, all.effects() is *not* a method of all(), and is defined as
> 
> >> effects::all.effects
> > function (...) 
> > {
> >  .Deprecated("allEffects")
> >  allEffects(...)
> > }
> 
> Dear John,
> this is a good question without an obvious answer for the
> moment.
> 
> The check producing it is relatively new *and* has helped to
> detect problems in many packages and places,  but I would agree
> is a "False Positive" in this case.
> 
> One reason for such a check is the following output {in R >= 3.2.0},
> 
>  > require("effects")
>  Loading required package: effects
>  > methods(all)
>  [1] all,ddiMatrix-method all,ldiMatrix-method 
> all,lsparseMatrix-method
>  [4] all,Matrix-methodall,nsparseMatrix-method all.effects
>  
>  see '?methods' for accessing help and source code
>  >
> 
> which wrongly does list your all.effects() among the all
> methods and indeed (even worse), it *is* taken as S3 method
> for all():
>  
>  > ex <- structure(FALSE, class="effects")
>  > all(ex)
>  Error: $ operator is invalid for atomic vectors
>  In addition: Warning message:
>  'all.effects' is deprecated.
>  Use 'allEffects' instead.
>  See help("Deprecated") 
>  > 
> 
> ---
> 
> Now I agree .. and have e-talked about this with another R core
> member .. that it would be desirable for the package author to
> effectively declare the fact that such a function is not an S3
> method even though it "looks like it" at least if looked from far.
> 
> So, ideally, you could have something like
> 
>  nonS3method("all.effects")
> 
> somewhere in your package source ( in NAMESPACE or R/*.R )
> which would tell the package-checking code -- but *ALSO* all the other S3
> method code that  all.effects should be treated as a regular R
> function.
> 
> I would very much like such a feature in R, and for that reason,
> I'm cross posting this (as one of the famous exceptions that
> accompany real-life rules!!) to R-devel.
> 
> There is one current work-around -- some would say "hack" -- in the R sources
> for exceptions on a per package basis, and I will now activate
> that workaround for you.
> 
> Martin
>

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

t;))),
envir=.GlobalEnv),
silent=TRUE)
options(save.options)
if (class(check) == "try-error"){
errorCondition(recall=readDataFromPackage,

message=sprintf(gettextRcmdr("Data set %s does not exit"), dsnameValue))
return()
}
activeDataSet(dsnameValue)
tkfocus(CommanderWindow())
}
else{
if (is.null(package)) {
errorCondition(recall=readDataFromPackage,
message=gettextRcmdr("You must select a package."))
return()
}
if (length(datasetName) == 0) {
errorCondition(recall=readDataFromPackage,
message=gettextRcmdr("You must select a data set."))
return()
}
if (is.element(datasetName, listDataSets())) {
if ("no" ==
tclvalue(checkReplace(datasetName, gettextRcmdr("Data set"{
if (GrabFocus()) tkgrab.release(top)
tkdestroy(top)
readDataFromPackage()
return()
}
}
closeDialog()
command <- paste("data(", datasetName, ',
package="', package, '")', sep="")
result <- justDoIt(command)
logger(command)
if (class(result)[1] !=  "try-error")
activeDataSet(datasetName)
tkfocus(CommanderWindow())
}
}
onDataHelp <- function(){
datasetName <- datasets[as.numeric(tkcurselection(datasetBox)) + 1]
dsnameValue <- tclvalue(dsname)
if (dsnameValue == "") dsnameValue <- datasetName
if (length(dsnameValue) == 0) Message(gettextRcmdr("No data
set selected."), type="warning")
else if (is.null(package)) doItAndPrint(paste('help("',
dsnameValue, '")', sep=""))
else doItAndPrint(paste('help("', dsnameValue, '",
package="', package, '")', sep=""))
}
OKCancelHelp(helpSubject="data")
dataHelpButton <- buttonRcmdr(top, text=gettextRcmdr("Help on
selected data set"), command=onDataHelp)
tkgrid(labelRcmdr(packageDatasetFrame, text=gettextRcmdr("Package
(Double-click to select)"), fg=getRcmdr("title.color"),
font="RcmdrTitleFont"),
labelRcmdr(packageDatasetFrame, text="   "),
labelRcmdr(packageDatasetFrame, text=gettextRcmdr("Data set (Double-click to
select)"),
fg=getRcmdr("title.color"),
font="RcmdrTitleFont"), sticky="w")
tkgrid(packageBox, packageScroll, sticky="nw")
tkgrid(datasetBox, datasetScroll, sticky="nw")
tkgrid(packageFrame, labelRcmdr(packageDatasetFrame, text="   "),
datasetFrame, sticky="nw")
tkgrid(packageDatasetFrame, sticky="w")
tkgrid(labelRcmdr(top, text=gettextRcmdr("OR"), fg="red"),
sticky="w")
tkgrid(labelRcmdr(enterFrame, text=gettextRcmdr("Enter name of data
set:  "), fg=getRcmdr("title.color"), font="RcmdrTitleFont"), entryDsname,
sticky="w")
tkgrid(enterFrame, sticky="w")
tkgrid(dataHelpButton, sticky="w")
tkgrid(buttonsFrame, sticky="ew")
tkgrid.configure(packageScroll, sticky="ns")
tkgrid.configure(datasetScroll, sticky="ns")
tkbind(packageBox, "", onPackageSelect)
tkbind(datasetBox, "", onDatasetSelect)
dialogSuffix(focus=entryDsname)
}

 snip --

Any insight into the problem would be appreciated.

Thanks,
 John

---
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
http://socserv.socsci.mcmaster.ca/jfox/




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Peter,

> -Original Message-
> From: peter dalgaard [mailto:pda...@gmail.com]
> Sent: July-13-15 4:52 PM
> To: John Fox
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> 
> Yes, there was a similar note from Alexandra Kuznetsova a couple of days

Sorry, I didn't notice that.

> ago. Look unintentional, but it is not easy to spot what triggers it. If
> someone could cook up a minimal example, or - maybe easier given the
> relatively short timeframe - bisect their way to the exact svn revision
> that triggered it, it might help in getting it fixed.

I'm afraid that I'm not set up to build R-devel and I'm about to leave town
for three weeks. I'll see if I can produce a simpler example triggering the
error, however.

Thanks for this,
 John

> 
> -pd
> 
> > On 13 Jul 2015, at 22:31 , John Fox  wrote:
> >
> > Dear list members,
> >
> > I'm getting a new note from R-devel that I haven't seen before when
> checking
> > the development version of the Rcmdr package:
> >
> > * checking R code for possible problems ... NOTE
> > readDataFromPackage: Error while checking: invalid 'envir' argument
> >
> > This note doesn't appear in R 3.2.1.
> >
> > My session info:
> >
> >  snip --
> >
> > R Under development (unstable) (2015-07-12 r68650)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > Running under: Windows 7 x64 (build 7601) Service Pack 1
> >
> > locale:
> > [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
> > LC_MONETARY=English_Canada.1252
> > [4] LC_NUMERIC=CLC_TIME=English_Canada.1252
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] tools_3.3.0
> >
> >  snip --
> >
> > I can't even localize the problem in readDataFromPackage(). There are
> only
> > two places in this function where there's a function call with an
> envir
> > argument, and I still get the note if I comment these out. As well,
> > readDataFromPackage() seems to work as intended -- there is no obvious
> error
> > in it.
> >
> > FWIW, here's readDataFromPackage(). The complete sources for the
> development
> > version of the Rcmdr package are on R-Forge.
> >
> >  snip --
> >
> > readDataFromPackage <- function() {
> > env <- environment()
> > datasets <- NULL
> > initializeDialog(title=gettextRcmdr("Read Data From Package"))
> > dsname <- tclVar("")
> > package <- NULL
> > enterFrame <- tkframe(top)
> > entryDsname <- ttkentry(enterFrame, width="20",
> textvariable=dsname)
> > packages <- sort(.packages())
> > packages <- packages[! packages %in% c("base", "stats")]
> > packages <- packages[sapply(packages, function(package){
> > ds <-
> > data(package=package)$results
> > if (nrow(ds) == 0)
> > return(FALSE)
> > ds <- ds[, "Item"]
> > valid <- sapply(ds,
> > is.valid.name)
> > length(ds[valid]) > 0
> > })]
> > packageDatasetFrame <- tkframe(top)
> > packageFrame <- tkframe(packageDatasetFrame)
> > max.height <- getRcmdr("variable.list.height")
> > packageBox <- tklistbox(packageFrame, height=min(max.height,
> > length(packages)),
> >exportselection="FALSE",
> > selectmode="single", background="white")
> > packageScroll <- ttkscrollbar(packageFrame,
> > command=function(...) tkyview(packageBox, ...))
> > tkconfigure(packageBox, yscrollcommand=function(...)
> > tkset(packageScroll, ...))
> > for (p in packages) tkinsert(packageBox, "end", p)
> > datasetFrame <- tkframe(packageDatasetFrame)
> > datasetBox <- tklistbox(datasetFrame, height=max.height,
> > exportselection="FALSE",
> > selectmode="single", background="white")
> > datasetScroll <- t

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Duncan and Peter,

I've just arrived at more or less the same thing:

foo <- function() data(package="MASS")

bar <- function() data(package="MASS", envir=.GlobalEnv)

baz <- function() data(package="MASS", envir=globalenv())

all trigger the note when included with the Rcmdr sources:

* checking R code for possible problems ... NOTE
bar: Error while checking: invalid 'envir' argument
baz: Error while checking: invalid 'envir' argument
foo: Error while checking: invalid 'envir' argument 

The envir argument to data() defaults to .GlobaEnv .

I hope this helps,
 John

> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: July-13-15 6:32 PM
> To: John Fox; 'peter dalgaard'
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> 
> On 13/07/2015 5:23 PM, John Fox wrote:
> > Dear Peter,
> >
> >> -Original Message-
> >> From: peter dalgaard [mailto:pda...@gmail.com]
> >> Sent: July-13-15 4:52 PM
> >> To: John Fox
> >> Cc: r-package-devel@r-project.org
> >> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> devel
> >>
> >> Yes, there was a similar note from Alexandra Kuznetsova a couple of
> days
> >
> > Sorry, I didn't notice that.
> >
> >> ago. Look unintentional, but it is not easy to spot what triggers it.
> If
> >> someone could cook up a minimal example, or - maybe easier given the
> >> relatively short timeframe - bisect their way to the exact svn
> revision
> >> that triggered it, it might help in getting it fixed.
> >
> > I'm afraid that I'm not set up to build R-devel and I'm about to leave
> town
> > for three weeks. I'll see if I can produce a simpler example
> triggering the
> > error, however.
> 
> Hana Sevcikova posted a simple example.  I'll bisect on it.
> 
> Here's her example:
> 
> e <- new.env()
> data("mydataset", envir=e)
> 
> I've substituted USArrests for "mydataset".
> 
> Duncan Murdoch
> 
> >
> > Thanks for this,
> >  John
> >
> >>
> >> -pd
> >>
> >>> On 13 Jul 2015, at 22:31 , John Fox  wrote:
> >>>
> >>> Dear list members,
> >>>
> >>> I'm getting a new note from R-devel that I haven't seen before when
> >> checking
> >>> the development version of the Rcmdr package:
> >>>
> >>>   * checking R code for possible problems ... NOTE
> >>>   readDataFromPackage: Error while checking: invalid 'envir' argument
> >>>
> >>> This note doesn't appear in R 3.2.1.
> >>>
> >>> My session info:
> >>>
> >>>  snip --
> >>>
> >>> R Under development (unstable) (2015-07-12 r68650)
> >>> Platform: x86_64-w64-mingw32/x64 (64-bit)
> >>> Running under: Windows 7 x64 (build 7601) Service Pack 1
> >>>
> >>> locale:
> >>> [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
> >>> LC_MONETARY=English_Canada.1252
> >>> [4] LC_NUMERIC=CLC_TIME=English_Canada.1252
> >>>
> >>> attached base packages:
> >>> [1] stats graphics  grDevices utils datasets  methods   base
> >>>
> >>> loaded via a namespace (and not attached):
> >>> [1] tools_3.3.0
> >>>
> >>>  snip --
> >>>
> >>> I can't even localize the problem in readDataFromPackage(). There
> are
> >> only
> >>> two places in this function where there's a function call with an
> >> envir
> >>> argument, and I still get the note if I comment these out. As well,
> >>> readDataFromPackage() seems to work as intended -- there is no
> obvious
> >> error
> >>> in it.
> >>>
> >>> FWIW, here's readDataFromPackage(). The complete sources for the
> >> development
> >>> version of the Rcmdr package are on R-Forge.
> >>>
> >>>  snip --
> >>>
> >>> readDataFromPackage <- function() {
> >>>   env <- environment()
> >>>   datasets <- NULL
> >>>   initializeDialog(title=gettextRcmdr(&

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Duncan,

> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: July-13-15 7:01 PM
> To: John Fox; 'peter dalgaard'
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> 
> It happened in r68597.  In my example, I hadn't imported the data()
> function from utils; when I did that, it was fixed.
> 
> Not sure why the error is complaining about the envir argument.


Yes, importing data works for me too! It's odd that the problem didn't show
up as an undefined global symbol rather than as a note about the envir
argument. (I was fixing imports from standard packages when the problem
arose.)

Thanks for tracking this down.

John

> 
> Duncan Murdoch
> 
> On 13/07/2015 6:47 PM, John Fox wrote:
> > Dear Duncan and Peter,
> >
> > I've just arrived at more or less the same thing:
> >
> > foo <- function() data(package="MASS")
> >
> > bar <- function() data(package="MASS", envir=.GlobalEnv)
> >
> > baz <- function() data(package="MASS", envir=globalenv())
> >
> > all trigger the note when included with the Rcmdr sources:
> >
> > * checking R code for possible problems ... NOTE
> > bar: Error while checking: invalid 'envir' argument
> > baz: Error while checking: invalid 'envir' argument
> > foo: Error while checking: invalid 'envir' argument
> >
> > The envir argument to data() defaults to .GlobaEnv .
> >
> > I hope this helps,
> >  John
> >
> >> -Original Message-
> >> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >> Sent: July-13-15 6:32 PM
> >> To: John Fox; 'peter dalgaard'
> >> Cc: r-package-devel@r-project.org
> >> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> devel
> >>
> >> On 13/07/2015 5:23 PM, John Fox wrote:
> >>> Dear Peter,
> >>>
> >>>> -Original Message-
> >>>> From: peter dalgaard [mailto:pda...@gmail.com]
> >>>> Sent: July-13-15 4:52 PM
> >>>> To: John Fox
> >>>> Cc: r-package-devel@r-project.org
> >>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >> devel
> >>>>
> >>>> Yes, there was a similar note from Alexandra Kuznetsova a couple of
> >> days
> >>>
> >>> Sorry, I didn't notice that.
> >>>
> >>>> ago. Look unintentional, but it is not easy to spot what triggers
> it.
> >> If
> >>>> someone could cook up a minimal example, or - maybe easier given
> the
> >>>> relatively short timeframe - bisect their way to the exact svn
> >> revision
> >>>> that triggered it, it might help in getting it fixed.
> >>>
> >>> I'm afraid that I'm not set up to build R-devel and I'm about to
> leave
> >> town
> >>> for three weeks. I'll see if I can produce a simpler example
> >> triggering the
> >>> error, however.
> >>
> >> Hana Sevcikova posted a simple example.  I'll bisect on it.
> >>
> >> Here's her example:
> >>
> >> e <- new.env()
> >> data("mydataset", envir=e)
> >>
> >> I've substituted USArrests for "mydataset".
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>> Thanks for this,
> >>>  John
> >>>
> >>>>
> >>>> -pd
> >>>>
> >>>>> On 13 Jul 2015, at 22:31 , John Fox  wrote:
> >>>>>
> >>>>> Dear list members,
> >>>>>
> >>>>> I'm getting a new note from R-devel that I haven't seen before
> when
> >>>> checking
> >>>>> the development version of the Rcmdr package:
> >>>>>
> >>>>> * checking R code for possible problems ... NOTE
> >>>>> readDataFromPackage: Error while checking: invalid 'envir'
> argument
> >>>>>
> >>>>> This note doesn't appear in R 3.2.1.
> >>>>>
> >>>>> My session info:
> >>>>>
> >>>>>  snip --
> >>>>>
> >>>

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Duncan,

On Mon, 13 Jul 2015 20:00:02 -0400
 Duncan Murdoch  wrote:
> On 13/07/2015 7:35 PM, John Fox wrote:
> > Dear Duncan,
> > 
> >> -Original Message-
> >> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >> Sent: July-13-15 7:01 PM
> >> To: John Fox; 'peter dalgaard'
> >> Cc: r-package-devel@r-project.org
> >> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> >>
> >> It happened in r68597.  In my example, I hadn't imported the data()
> >> function from utils; when I did that, it was fixed.
> >>
> >> Not sure why the error is complaining about the envir argument.
> > 
> > 
> > Yes, importing data works for me too! It's odd that the problem didn't show
> > up as an undefined global symbol rather than as a note about the envir
> > argument. (I was fixing imports from standard packages when the problem
> > arose.)
> 
> I'd guess that it's finding some other private function called data();
> that's probably worth fixing.

If you mean an unexported function named data() in the Rcmdr package, then I'm 
pretty sure that there is none -- and I just checked all of the many uses of 
the word "data" in the Rcmdr sources. Of course, I may have missed something 
or, more likely, misunderstood what you're suggesting.

Best,
 John

> 
> Duncan
> 
> > 
> > Thanks for tracking this down.
> > 
> > John
> > 
> >>
> >> Duncan Murdoch
> >>
> >> On 13/07/2015 6:47 PM, John Fox wrote:
> >>> Dear Duncan and Peter,
> >>>
> >>> I've just arrived at more or less the same thing:
> >>>
> >>>   foo <- function() data(package="MASS")
> >>>
> >>>   bar <- function() data(package="MASS", envir=.GlobalEnv)
> >>>
> >>>   baz <- function() data(package="MASS", envir=globalenv())
> >>>
> >>> all trigger the note when included with the Rcmdr sources:
> >>>
> >>>   * checking R code for possible problems ... NOTE
> >>>   bar: Error while checking: invalid 'envir' argument
> >>>   baz: Error while checking: invalid 'envir' argument
> >>>   foo: Error while checking: invalid 'envir' argument
> >>>
> >>> The envir argument to data() defaults to .GlobaEnv .
> >>>
> >>> I hope this helps,
> >>>  John
> >>>
> >>>> -Original Message-
> >>>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >>>> Sent: July-13-15 6:32 PM
> >>>> To: John Fox; 'peter dalgaard'
> >>>> Cc: r-package-devel@r-project.org
> >>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >> devel
> >>>>
> >>>> On 13/07/2015 5:23 PM, John Fox wrote:
> >>>>> Dear Peter,
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: peter dalgaard [mailto:pda...@gmail.com]
> >>>>>> Sent: July-13-15 4:52 PM
> >>>>>> To: John Fox
> >>>>>> Cc: r-package-devel@r-project.org
> >>>>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >>>> devel
> >>>>>>
> >>>>>> Yes, there was a similar note from Alexandra Kuznetsova a couple of
> >>>> days
> >>>>>
> >>>>> Sorry, I didn't notice that.
> >>>>>
> >>>>>> ago. Look unintentional, but it is not easy to spot what triggers
> >> it.
> >>>> If
> >>>>>> someone could cook up a minimal example, or - maybe easier given
> >> the
> >>>>>> relatively short timeframe - bisect their way to the exact svn
> >>>> revision
> >>>>>> that triggered it, it might help in getting it fixed.
> >>>>>
> >>>>> I'm afraid that I'm not set up to build R-devel and I'm about to
> >> leave
> >>>> town
> >>>>> for three weeks. I'll see if I can produce a simpler example
> >>>> triggering the
> >>>>> error, however.
> >>>>
> >>>> Hana Sevcikova posted a simple example.  I'll bisect on it.

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Duncan,

Further to my last message, and in case it's relevant, with the development 
version of the Rcmdr package loaded, I get

> getAnywhere("data")
A single object matching 'data' was found
It was found in the following places
  package:utils
  namespace:utils
with value . . .

Best,
 John

On Mon, 13 Jul 2015 20:00:02 -0400
 Duncan Murdoch  wrote:
> On 13/07/2015 7:35 PM, John Fox wrote:
> > Dear Duncan,
> > 
> >> -Original Message-
> >> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >> Sent: July-13-15 7:01 PM
> >> To: John Fox; 'peter dalgaard'
> >> Cc: r-package-devel@r-project.org
> >> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> >>
> >> It happened in r68597.  In my example, I hadn't imported the data()
> >> function from utils; when I did that, it was fixed.
> >>
> >> Not sure why the error is complaining about the envir argument.
> > 
> > 
> > Yes, importing data works for me too! It's odd that the problem didn't show
> > up as an undefined global symbol rather than as a note about the envir
> > argument. (I was fixing imports from standard packages when the problem
> > arose.)
> 
> I'd guess that it's finding some other private function called data();
> that's probably worth fixing.
> 
> Duncan
> 
> > 
> > Thanks for tracking this down.
> > 
> > John
> > 
> >>
> >> Duncan Murdoch
> >>
> >> On 13/07/2015 6:47 PM, John Fox wrote:
> >>> Dear Duncan and Peter,
> >>>
> >>> I've just arrived at more or less the same thing:
> >>>
> >>>   foo <- function() data(package="MASS")
> >>>
> >>>   bar <- function() data(package="MASS", envir=.GlobalEnv)
> >>>
> >>>   baz <- function() data(package="MASS", envir=globalenv())
> >>>
> >>> all trigger the note when included with the Rcmdr sources:
> >>>
> >>>   * checking R code for possible problems ... NOTE
> >>>   bar: Error while checking: invalid 'envir' argument
> >>>   baz: Error while checking: invalid 'envir' argument
> >>>   foo: Error while checking: invalid 'envir' argument
> >>>
> >>> The envir argument to data() defaults to .GlobaEnv .
> >>>
> >>> I hope this helps,
> >>>  John
> >>>
> >>>> -Original Message-
> >>>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >>>> Sent: July-13-15 6:32 PM
> >>>> To: John Fox; 'peter dalgaard'
> >>>> Cc: r-package-devel@r-project.org
> >>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >> devel
> >>>>
> >>>> On 13/07/2015 5:23 PM, John Fox wrote:
> >>>>> Dear Peter,
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: peter dalgaard [mailto:pda...@gmail.com]
> >>>>>> Sent: July-13-15 4:52 PM
> >>>>>> To: John Fox
> >>>>>> Cc: r-package-devel@r-project.org
> >>>>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >>>> devel
> >>>>>>
> >>>>>> Yes, there was a similar note from Alexandra Kuznetsova a couple of
> >>>> days
> >>>>>
> >>>>> Sorry, I didn't notice that.
> >>>>>
> >>>>>> ago. Look unintentional, but it is not easy to spot what triggers
> >> it.
> >>>> If
> >>>>>> someone could cook up a minimal example, or - maybe easier given
> >> the
> >>>>>> relatively short timeframe - bisect their way to the exact svn
> >>>> revision
> >>>>>> that triggered it, it might help in getting it fixed.
> >>>>>
> >>>>> I'm afraid that I'm not set up to build R-devel and I'm about to
> >> leave
> >>>> town
> >>>>> for three weeks. I'll see if I can produce a simpler example
> >>>> triggering the
> >>>>> error, however.
> >>>>
> >>>> Hana Sevcikova posted a simple example.  I'll bisect on it.
> 

Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel

[John Fox]

Dear Duncan,

Thank you for tracking down the source of this error.

Best,
 John

On Tue, 14 Jul 2015 07:22:21 -0400
 Duncan Murdoch  wrote:
> On 13/07/2015 9:42 PM, John Fox wrote:
> > Dear Duncan,
> > 
> > On Mon, 13 Jul 2015 20:00:02 -0400
> >  Duncan Murdoch  wrote:
> >> On 13/07/2015 7:35 PM, John Fox wrote:
> >>> Dear Duncan,
> >>>
> >>>> -Original Message-
> >>>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >>>> Sent: July-13-15 7:01 PM
> >>>> To: John Fox; 'peter dalgaard'
> >>>> Cc: r-package-devel@r-project.org
> >>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
> >>>>
> >>>> It happened in r68597.  In my example, I hadn't imported the data()
> >>>> function from utils; when I did that, it was fixed.
> >>>>
> >>>> Not sure why the error is complaining about the envir argument.
> >>>
> >>>
> >>> Yes, importing data works for me too! It's odd that the problem didn't 
> >>> show
> >>> up as an undefined global symbol rather than as a note about the envir
> >>> argument. (I was fixing imports from standard packages when the problem
> >>> arose.)
> >>
> >> I'd guess that it's finding some other private function called data();
> >> that's probably worth fixing.
> > 
> > If you mean an unexported function named data() in the Rcmdr package, then 
> > I'm pretty sure that there is none -- and I just checked all of the many 
> > uses of the word "data" in the Rcmdr sources. Of course, I may have missed 
> > something or, more likely, misunderstood what you're suggesting.
> 
> I tracked it down to a bug in codetools.  The "envir" it is talking
> about is an argument to a different function, nothing to do with the
> argument to data().
> 
> I've passed it on to Luke Tierney, author of codetools.
> 
> Duncan Murdoch
> 
> > Best,
> >  John
> > 
> >>
> >> Duncan
> >>
> >>>
> >>> Thanks for tracking this down.
> >>>
> >>> John
> >>>
> >>>>
> >>>> Duncan Murdoch
> >>>>
> >>>> On 13/07/2015 6:47 PM, John Fox wrote:
> >>>>> Dear Duncan and Peter,
> >>>>>
> >>>>> I've just arrived at more or less the same thing:
> >>>>>
> >>>>> foo <- function() data(package="MASS")
> >>>>>
> >>>>> bar <- function() data(package="MASS", envir=.GlobalEnv)
> >>>>>
> >>>>> baz <- function() data(package="MASS", envir=globalenv())
> >>>>>
> >>>>> all trigger the note when included with the Rcmdr sources:
> >>>>>
> >>>>>         * checking R code for possible problems ... NOTE
> >>>>> bar: Error while checking: invalid 'envir' argument
> >>>>> baz: Error while checking: invalid 'envir' argument
> >>>>> foo: Error while checking: invalid 'envir' argument
> >>>>>
> >>>>> The envir argument to data() defaults to .GlobaEnv .
> >>>>>
> >>>>> I hope this helps,
> >>>>>  John
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> >>>>>> Sent: July-13-15 6:32 PM
> >>>>>> To: John Fox; 'peter dalgaard'
> >>>>>> Cc: r-package-devel@r-project.org
> >>>>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
> >>>> devel
> >>>>>>
> >>>>>> On 13/07/2015 5:23 PM, John Fox wrote:
> >>>>>>> Dear Peter,
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: peter dalgaard [mailto:pda...@gmail.com]
> >>>>>>>> Sent: July-13-15 4:52 PM
> >>>>>>>> To: John Fox
> >>>>>>>> Cc: r-package-devel@r-project.org
> >>>>>>>> Subject: Re: [R-pkg-devel] "invalid 'envir&

[R-pkg-devel] recursive dependencies and install.packages()

[John Fox]

Dear list members,

I'm pretty sure (from memory) that this was discussed before but I can't
find a relevant thread.

The Rcmdr packages "depends" on the RcmdrMisc package which "depends" on the
Hmisc package which "imports" the ggplot2 package.

When the Rcmdr package is installed via install.packages("Rcmdr"), i.e.,
with all arguments other than pkgs at their defaults, the RcmdrMisc and
Hmisc packages are installed but not ggplot2, causing the Rcmdr to fail to
load, unless ggplot2 is installed directly.

>From ?install.packages I see:

-- snip -
Dependencies:   
logical indicating whether to also install uninstalled packages which these
packages depend on/link to/import/suggest (and so on recursively). Not used
if repos = NULL. Can also be a character vector, a subset of c("Depends",
"Imports", "LinkingTo", "Suggests", "Enhances").
Only supported if lib is of length one (or missing), so it is unambiguous
where to install the dependent packages. If this is not the case it is
ignored, with a warning.
The default, NA, means c("Depends", "Imports", "LinkingTo").
TRUE means to use c("Depends", "Imports", "LinkingTo", "Suggests") for pkgs
and c("Depends", "Imports", "LinkingTo") for added dependencies: this
installs all the packages needed to run pkgs, their examples, tests and
vignettes (if the package author specified them correctly).
In all of these, "LinkingTo" is omitted for binary packages.

-- snip -

from which I infer, obviously incorrectly, that the three-deep recursive
dependency on ggplot2 would cause it to be installed.

So, two questions:

(1) What is the correct understanding of how recursive dependencies are
handled by install.packages() with default arguments?

(2) What is the best fix assuming that naïve users will use
install.packages() with default arguments? I can specify that RcmdrMisc
"imports" ggplot2, which I believe will cause ggplot2 to be installed when
the Rcmdr package is installed, since the recursive dependency would then be
two deep, which apparently works. Is that a reasonable solution? (It seems
like a kludge to me.)

Thanks for any help,

John

---
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
http://socserv.socsci.mcmaster.ca/jfox/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] recursive dependencies and install.packages()

[John Fox]

Dear list members,

My question was prompted by a message from a user indicating that loading
the Rcmdr package following installation via install.packages("Rcmdr")
failed in the manner I indicated, with the indirect dependency ggplot2
missing. 

I thought that I was able to duplicate this error by deleting the Rcmdr,
RcmdrMisc, Hmisc, and ggplot packages from the R 3.2.2 library on my Windows
10 system and then reinstalling the Rcmdr package via
install.packages("Rcmdr"). But when I tried installing the Rcmdr on a
Windows (8) machine with a newly installed R 3.2.2, I was unable to
duplicate the error. That is, everything worked fine, including the
recursively installed ggplot2 dependency.

I subsequently uninstalled R 3.2.2 from my Windows 10 machine, deleted the R
3.2.2 library, and reinstalled R 3.2.2 and the Rcmdr package. Again,
everything worked as expected.

So I expect that my original message reflected idiosyncratic errors (the
source of which I don't understand) -- and that recursive dependencies are
in fact resolved as I understood, and as implied by ?install.packages.

My apologies for what appears to be a false alarm.

John

> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
> Behalf Of John Fox
> Sent: Wednesday, August 19, 2015 3:16 PM
> To: r-package-devel@r-project.org
> Subject: [R-pkg-devel] recursive dependencies and install.packages()
> 
> Dear list members,
> 
> I'm pretty sure (from memory) that this was discussed before but I can't
> find a relevant thread.
> 
> The Rcmdr packages "depends" on the RcmdrMisc package which "depends" on
> the
> Hmisc package which "imports" the ggplot2 package.
> 
> When the Rcmdr package is installed via install.packages("Rcmdr"), i.e.,
> with all arguments other than pkgs at their defaults, the RcmdrMisc and
> Hmisc packages are installed but not ggplot2, causing the Rcmdr to fail
> to
> load, unless ggplot2 is installed directly.
> 
> >From ?install.packages I see:
> 
> -- snip -
> Dependencies:
> logical indicating whether to also install uninstalled packages which
> these
> packages depend on/link to/import/suggest (and so on recursively). Not
> used
> if repos = NULL. Can also be a character vector, a subset of
> c("Depends",
> "Imports", "LinkingTo", "Suggests", "Enhances").
> Only supported if lib is of length one (or missing), so it is
> unambiguous
> where to install the dependent packages. If this is not the case it is
> ignored, with a warning.
> The default, NA, means c("Depends", "Imports", "LinkingTo").
> TRUE means to use c("Depends", "Imports", "LinkingTo", "Suggests") for
> pkgs
> and c("Depends", "Imports", "LinkingTo") for added dependencies: this
> installs all the packages needed to run pkgs, their examples, tests and
> vignettes (if the package author specified them correctly).
> In all of these, "LinkingTo" is omitted for binary packages.
> 
> -- snip -
> 
> from which I infer, obviously incorrectly, that the three-deep recursive
> dependency on ggplot2 would cause it to be installed.
> 
> So, two questions:
> 
> (1) What is the correct understanding of how recursive dependencies are
> handled by install.packages() with default arguments?
> 
> (2) What is the best fix assuming that naïve users will use
> install.packages() with default arguments? I can specify that RcmdrMisc
> "imports" ggplot2, which I believe will cause ggplot2 to be installed
> when
> the Rcmdr package is installed, since the recursive dependency would
> then be
> two deep, which apparently works. Is that a reasonable solution? (It
> seems
> like a kludge to me.)
> 
> Thanks for any help,
> 
> John
> 
> ---
> John Fox, Professor
> McMaster University
> Hamilton, Ontario, Canada
> http://socserv.socsci.mcmaster.ca/jfox/
> 
> __
> 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] Strange behaviour of function called from within a function

[John Fox]

Dear John,

After further thought, it's probably a better idea to evaluate the 
weights argument in the same environment as the formula rather than to 
bypass nonstandard evaluation. You could use lm() as a guide. I don't 
entirely understand what you're trying to do so maybe this suggestion is 
off-base.


Best,
 John

On 2022-08-13 9:41 a.m., J C Nash wrote:


Thanks to John Fox and Noah Greifer. Both their approaches resolved my 
immediate

problem.

That is, to provide a summary of the fix of my example code,

tw <- function(formula, data, start, control, trace, weights) {
   firstcoef <- c(b1=199, b2=50, b3=0.3)
   cat("firstcoef:\n")
   print(firstcoef)
   cat("weights:"); print(weights)
# Following fails -- closure error
#  secondw<-nls(formula, data, firstcoef, control, algorithm=NULL, TRUE, 
weights=weights)

# from noah.grei...@gmail.com # this works OK
   secondw <- do.call("nls", list(formula, data, firstcoef, control, 
algorithm=NULL, TRUE, weights = weights))

#  As does putting weights in the data dataframe (here not active)
#  data$weights <- weights # from John Fox
#  secondw<-nls(formula, data, firstcoef, control, algorithm=NULL, TRUE, 
weights=weights)

   secondw
}

Afraid I avoid the wonders of non-standard evaluation, and this time it 
jumped up and bit me.
But then I remember what machine instruction 2689 did on an IBM 
1620.


The swiftness of reply from John and Noah was much appreciated.

Best, JN

--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Advice on elegant way to alias function name

[John Fox]

Dear John,

I've used an alternative solution in similar situations, equivalent to 
defining


thefn <- function(...) myfn(...)

Then only ... needs to be documented as arguments passed down to myfn(). 
Maybe that would work for you too.


Best,
 John

On 2022-09-02 4:22 p.m., J C Nash wrote:

With some playing around I found a workable solution.

- NAMESPACE needs  export(thefn)
- thefn.Rd needs usage and arguments documented
- myfn.Rd must NOT have alias(thefn)

And I believe I've got the roxygen2 tags to work in Rstudio. In R itself,
roxygen2 gives an error
     Error: invalid version specification ‘0.68’
though the string '0.68' appears nowhere in my package according to grep.
I have no idea what this is about, especially as Rstudio works fine.

While I like the idea of documentation in code files, I think I'll go
back to separately created .Rd files.

If anyone is interested, package and README are at
https://gitlab.com/nashjc/nlsr2022

Best,

John Nash


On 2022-09-01 11:29, Hadley Wickham wrote:

On Thu, Sep 1, 2022 at 9:48 AM J C Nash  wrote:


Hi,

I've a package where it has been suggested that one of the functions 
-- call
it "myfn()" -- should be called something else, say "thefn()". Of 
course, I'll

need to keep the old name around for a while.

Web search has suggested simple assignment of

  thefn <- myfn

but I cannot seem to get this to work with R CMD check when I put 
this in a .R
file in the code and put alias and usage stanzas in documentation. I 
get alias
and missing argument type errors. I've tried a number of variations 
on this theme

without appreciable success.

A workaround is to copy the entire function with Roxygen2 
documentation and

name change, but this seems inelegant.


You'll also need to add a couple of roxygen tags:

#' @export
#' @rdname myfn
thefn <- myfn

Hadley



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] roxygen style documentation for data sets

[John Fox]

Hi Michael,

I'm no license expert either, but I too believe that while a 
GPL-licensed package can incorporate MIT-licensed code, an MIT-licensed 
package can't incorporate GPL-licensed code.


One solution, I think, would be to put your use_data_doc() in a separate 
GPL-licensed package, which then could be specified as a dependency of 
usethis. Of course, the usethis developers would have to agree.


I hope this helps,
 John


On 2023-09-21 12:33 p.m., Michael L Friendly wrote:

Caution: External email.


I have many datasets in a some of my packages, and always used 
`utils::promptData()` to generate the skeleton of a man/data.Rd file.
Now that I've switched to roxygen style, I have found no simple equivalent. In 
fact, with RStudio tools for generating documentation
for functions, it is surprising that documenting data has been overlooked.

I solved this problem by simply editing `utils::promptData()` to replace .Rd 
style with equivalent roxygen tags.

The result in now in a gist, 
https://gist.github.com/friendly/14f3ee1464213bb0b9fbcb489468383b
I called this function `use_data_doc()`, because I thought it would be a 
welcome addition to the usethis package.

I hope that someone on this list can advise how to make such a function 
available to all R package developers.

-Michael

---
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University  Voice: 416 736-2100 x66249
4700 Keele StreetWeb: http://www.datavis.ca | 
@datavisFriendly
Toronto, ONT  M3J 1P3 CANADA


 [[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

Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Fox]

Hello Dirk,

Thank you (and Kevin and John) for addressing my questions.

No one directly answered my first question, however, which was whether 
the approach that I suggested would work. I guess that the implication 
is that it won't, but it would be nice to confirm that before I try 
something else, specifically using R.rsp.


Best,
 John

On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:

Caution: External email.


On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
| package.

For completeness, that approach also works directly with Sweave. Described in
a blog post by Mark van der Loo in 2019, and used in a number of packages
including a few of mine.

That said, I also used the approach described by John Harrold and cached
results myself.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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] Suppressing long-running vignette code in CRAN submission

[John Fox]

Hello Dirk,

Thank you for the additional information.

As you suggest, what you did to distribute pre-built PDF vignettes is 
quite similar to what R.rsp does, except that the latter also supports 
pre-built HTML vignettes, which is what I'd prefer to distribute. Since 
I apparently have that working now, we'll probably go with it unless we 
hit snags when the package is sent to CRAN.


While I appreciate the offer, it's probably not necessary for you to 
spend more time on this now.


Thanks again,
 John

On 2023-10-17 3:19 p.m., Dirk Eddelbuettel wrote:

Caution: External email.


John,

On 17 October 2023 at 10:02, John Fox wrote:
| Hello Dirk,
|
| Thank you (and Kevin and John) for addressing my questions.
|
| No one directly answered my first question, however, which was whether
| the approach that I suggested would work. I guess that the implication
| is that it won't, but it would be nice to confirm that before I try
| something else, specifically using R.rsp.

I am a little remote here, both mentally and physically. What I might do here
in the case of your long-running vignette, and have done in about half a
dozen packages where I wanted 'certainty' and no surprises, is to render the
pdf vignette I want as I want them locally, ship them in the package as an
included file (sometimes from a subdirectory) and have a five-or-so line
Sweave .Rnw file include it. That works without hassles. Here is the Rnw I
use for package anytime

-
\documentclass{article}
\usepackage{pdfpages}
%\VignetteIndexEntry{Introduction to anytime}
%\VignetteKeywords{anytime, date, datetime, conversion}
%\VignettePackage{anytime}
%\VignetteEncoding{UTF-8}

\begin{document}
\includepdf[pages=-, fitpaper=true]{anytime-intro.pdf}
\end{document}
-

That is five lines of LaTeX code slurping in the pdf (per the blog post by
Mark). As I understand it R.rsp does something similar at the marginal cost
of an added dependency.

Now, as mentioned, you can also 'conditionally' conpute in a vignette and
choose if and when to use a data cache. I think that we show most of that in
the package described in the RJournal piece by Brooke and myself on drat for
data repositories. (We may be skipping the compute when the data is not
accessible. Loading a precomputed set is similar. I may be doing that in the
much older never quite finished gcbd package and its vignette.

Hope this helps, maybe more once I am back home.

Cheers, Dirk

| Best,
|   John
|
| On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
| > Caution: External email.
| >
| >
| > On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| > | Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
| > | package.
| >
| > For completeness, that approach also works directly with Sweave. Described 
in
| > a blog post by Mark van der Loo in 2019, and used in a number of packages
| > including a few of mine.
| >
| > That said, I also used the approach described by John Harrold and cached
| > results myself.
| >
| > Dirk
| >
| > --
| > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >
| > __
| > R-package-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-package-devel
|

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Fox]

Dear Henrik,

I'd already read the R.rsp vignette to which you refer, and, as I said, 
confirmed that I can use R.rsp to implement static HTML vignettes for 
our package.


Thank you for the confirmation,
 John

On 2023-10-17 3:50 p.m., Henrik Bengtsson wrote:

Caution: External email.


On Tue, Oct 17, 2023 at 12:45 PM John Fox  wrote:


Hello Dirk,

Thank you for the additional information.

As you suggest, what you did to distribute pre-built PDF vignettes is
quite similar to what R.rsp does, except that the latter also supports
pre-built HTML vignettes, which is what I'd prefer to distribute. Since


Author of R.rsp here: It supports both static PDFs and static HTMLs, cf.

https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf

/Henrik


I apparently have that working now, we'll probably go with it unless we
hit snags when the package is sent to CRAN.

While I appreciate the offer, it's probably not necessary for you to
spend more time on this now.

Thanks again,
   John

On 2023-10-17 3:19 p.m., Dirk Eddelbuettel wrote:

Caution: External email.


John,

On 17 October 2023 at 10:02, John Fox wrote:
| Hello Dirk,
|
| Thank you (and Kevin and John) for addressing my questions.
|
| No one directly answered my first question, however, which was whether
| the approach that I suggested would work. I guess that the implication
| is that it won't, but it would be nice to confirm that before I try
| something else, specifically using R.rsp.

I am a little remote here, both mentally and physically. What I might do here
in the case of your long-running vignette, and have done in about half a
dozen packages where I wanted 'certainty' and no surprises, is to render the
pdf vignette I want as I want them locally, ship them in the package as an
included file (sometimes from a subdirectory) and have a five-or-so line
Sweave .Rnw file include it. That works without hassles. Here is the Rnw I
use for package anytime

-
\documentclass{article}
\usepackage{pdfpages}
%\VignetteIndexEntry{Introduction to anytime}
%\VignetteKeywords{anytime, date, datetime, conversion}
%\VignettePackage{anytime}
%\VignetteEncoding{UTF-8}

\begin{document}
\includepdf[pages=-, fitpaper=true]{anytime-intro.pdf}
\end{document}
-

That is five lines of LaTeX code slurping in the pdf (per the blog post by
Mark). As I understand it R.rsp does something similar at the marginal cost
of an added dependency.

Now, as mentioned, you can also 'conditionally' conpute in a vignette and
choose if and when to use a data cache. I think that we show most of that in
the package described in the RJournal piece by Brooke and myself on drat for
data repositories. (We may be skipping the compute when the data is not
accessible. Loading a precomputed set is similar. I may be doing that in the
much older never quite finished gcbd package and its vignette.

Hope this helps, maybe more once I am back home.

Cheers, Dirk

| Best,
|   John
|
| On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
| > Caution: External email.
| >
| >
| > On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| > | Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
| > | package.
| >
| > For completeness, that approach also works directly with Sweave. Described 
in
| > a blog post by Mark van der Loo in 2019, and used in a number of packages
| > including a few of mine.
| >
| > That said, I also used the approach described by John Harrold and cached
| > results myself.
| >
| > Dirk
| >
| > --
| > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >
| > __
| > R-package-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-package-devel
|

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


__
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] Suppressing long-running vignette code in CRAN submission

[John Fox]

Hello Simon,

On 2023-10-17 3:51 p.m., Simon Urbanek wrote:

Caution: External email.


John,

the short answer is it won't work (it defeats the purpose of vignettes).


Thank you for confirming that.



However, this sounds like a purely hypothetical question - CRAN policies allow 
long-running vignettes if they declared.


I assume that we'd declare the long-running vignette in our submission 
note to CRAN. Maybe that's better than pre-building the HTML vignettes 
in the package.


Best,
 John



Cheers,
Simon



On 18/10/2023, at 3:02 AM, John Fox  wrote:

Hello Dirk,

Thank you (and Kevin and John) for addressing my questions.

No one directly answered my first question, however, which was whether the 
approach that I suggested would work. I guess that the implication is that it 
won't, but it would be nice to confirm that before I try something else, 
specifically using R.rsp.

Best,
John

On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:

Caution: External email.
On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
| package.
For completeness, that approach also works directly with Sweave. Described in
a blog post by Mark van der Loo in 2019, and used in a number of packages
including a few of mine.
That said, I also used the approach described by John Harrold and cached
results myself.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Fox]

Hello Duncan,

On 2023-10-17 4:43 p.m., Duncan Murdoch wrote:

Caution: External email.


On 17/10/2023 4:21 p.m., John Fox wrote:

Hello Simon,

On 2023-10-17 3:51 p.m., Simon Urbanek wrote:

Caution: External email.


John,

the short answer is it won't work (it defeats the purpose of vignettes).


Thank you for confirming that.



However, this sounds like a purely hypothetical question - CRAN 
policies allow long-running vignettes if they declared.


I assume that we'd declare the long-running vignette in our submission
note to CRAN. Maybe that's better than pre-building the HTML vignettes
in the package.




There's also the "BuildVignettes: false" field in DESCRIPTION, but its
use is discouraged, and I don't think it allows you to ask CRAN to build
some vignettes but not all.


Thanks, I wasn't aware of that. There are two vignettes, one of which is 
slow to build.


Given Simon's suggestion, we'll likely submit the package with a note 
about the long-running vignette, and if that proves problematic, we can 
use R.asp to pre-build the HTML vignettes.


Best,
 John



Duncan Murdoch


Best,
   John



Cheers,
Simon



On 18/10/2023, at 3:02 AM, John Fox  wrote:

Hello Dirk,

Thank you (and Kevin and John) for addressing my questions.

No one directly answered my first question, however, which was 
whether the approach that I suggested would work. I guess that the 
implication is that it won't, but it would be nice to confirm that 
before I try something else, specifically using R.rsp.


Best,
John

On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:

Caution: External email.
On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| Produce a PDF file yourself, then use the "as.is" feature of the 
R.rsp

| package.
For completeness, that approach also works directly with Sweave. 
Described in
a blog post by Mark van der Loo in 2019, and used in a number of 
packages

including a few of mine.
That said, I also used the approach described by John Harrold and 
cached

results myself.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
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-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] Suppressing long-running vignette code in CRAN submission

[John Fox]

Dear John,

Unless I'm mistaken, the *installation* time of the package isn't really 
at issue. If a user installs a package from a tarball provided by CRAN, 
the vignettes aren't normally rebuilt.


Best,
 John

On 2023-10-17 6:30 p.m., John Harrold wrote:

Caution: External email.


I ask myself the question: Who is the vignette for?  It does server two
purposes. One is testing but primarily it's for the users to learn how to
use a package. I think the testing is secondary, and if it slows down
installation or general usability I'd sacrifice the testing. If it's that
important, then the tests can be added explicitly in tests/.

On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel  wrote:



On 18 October 2023 at 08:51, Simon Urbanek wrote:
| John,
|
| the short answer is it won't work (it defeats the purpose of vignettes).

Not exactly. Everything is under our (i.e. package author) control, and
when
we want to replace 'computed' values with cached values we can.

All this is somewhat of a charade. "Of course" we want vignettes to run
tests. But then we don't want to fall over random missing .sty files or
fonts
(macOS machines have been less forgiving than others), not to mention
compile
time.

So for simplicity I often pre-make pdf vignettes that get included in other
latex code as source. Works great, never fails, CRAN never complained --
which is somewhat contrary to your statement.

It is effectively the same with tests. We all want maximum test surfaces.
But
when tests fail, or when they run too long, or [insert many other reasons
here] so many packages run tests conditionally.  Such is life.

Dirk


| However, this sounds like a purely hypothetical question - CRAN policies
allow long-running vignettes if they declared.
|
| Cheers,
| Simon
|
|
| > On 18/10/2023, at 3:02 AM, John Fox  wrote:
| >
| > Hello Dirk,
| >
| > Thank you (and Kevin and John) for addressing my questions.
| >
| > No one directly answered my first question, however, which was whether
the approach that I suggested would work. I guess that the implication is
that it won't, but it would be nice to confirm that before I try something
else, specifically using R.rsp.
| >
| > Best,
| > John
| >
| > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
| >> Caution: External email.
| >> On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| >> | Produce a PDF file yourself, then use the "as.is" feature of the
R.rsp
| >> | package.
| >> For completeness, that approach also works directly with Sweave.
Described in
| >> a blog post by Mark van der Loo in 2019, and used in a number of
packages
| >> including a few of mine.
| >> That said, I also used the approach described by John Harrold and
cached
| >> results myself.
| >> Dirk
| >> --
| >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >> __
| >> 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-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
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


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Fox]

Dear Shu Fai,

This approach is certainly relevant, and I think it is slightly better 
than using R.rsp. My preference is still to include the original .Rmd 
file along with a note to CRAN about the long-running vignette.


Thank you,
 John


On 2023-10-17 9:25 p.m., Shu Fai Cheung wrote:

Caution: External email.


Please pardon me if I suggest something unrelated below. Many experts
have made suggestions that I would also like to consider because I
also have a similar issue with some packages.

This is an approach I found, for Rmarkdown vignettes:

https://www.kloppenborg.ca/2021/06/long-running-vignettes/

This is similar to some of the suggestions. The vignette is rendered
locally. It uses the trick that, If we render the vignette by calling
knitr::knit() directly, the extension of the source file does not
matter. The output, although with the extension ".Rmd", actually
contains the results of the code, in chunks starting with "```r", not
"```{r}".

When this pre-buiult .Rmd file is built again, it will just convert
the file to an HTML file, with no need to rerun the code.

The method uses an extension for the source Rmd file (".orig" in the
post) to make sure the "real" source files are ignored when building
the vignettes.

Perhaps this is also a feasible solution for long running vignettes?

Regards,
Shu Fai

On Wed, Oct 18, 2023 at 6:51 AM John Fox  wrote:


Dear John,

Unless I'm mistaken, the *installation* time of the package isn't really
at issue. If a user installs a package from a tarball provided by CRAN,
the vignettes aren't normally rebuilt.

Best,
   John

On 2023-10-17 6:30 p.m., John Harrold wrote:

Caution: External email.


I ask myself the question: Who is the vignette for?  It does server two
purposes. One is testing but primarily it's for the users to learn how to
use a package. I think the testing is secondary, and if it slows down
installation or general usability I'd sacrifice the testing. If it's that
important, then the tests can be added explicitly in tests/.

On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel  wrote:



On 18 October 2023 at 08:51, Simon Urbanek wrote:
| John,
|
| the short answer is it won't work (it defeats the purpose of vignettes).

Not exactly. Everything is under our (i.e. package author) control, and
when
we want to replace 'computed' values with cached values we can.

All this is somewhat of a charade. "Of course" we want vignettes to run
tests. But then we don't want to fall over random missing .sty files or
fonts
(macOS machines have been less forgiving than others), not to mention
compile
time.

So for simplicity I often pre-make pdf vignettes that get included in other
latex code as source. Works great, never fails, CRAN never complained --
which is somewhat contrary to your statement.

It is effectively the same with tests. We all want maximum test surfaces.
But
when tests fail, or when they run too long, or [insert many other reasons
here] so many packages run tests conditionally.  Such is life.

Dirk


| However, this sounds like a purely hypothetical question - CRAN policies
allow long-running vignettes if they declared.
|
| Cheers,
| Simon
|
|
| > On 18/10/2023, at 3:02 AM, John Fox  wrote:
| >
| > Hello Dirk,
| >
| > Thank you (and Kevin and John) for addressing my questions.
| >
| > No one directly answered my first question, however, which was whether
the approach that I suggested would work. I guess that the implication is
that it won't, but it would be nice to confirm that before I try something
else, specifically using R.rsp.
| >
| > Best,
| > John
| >
| > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
| >> Caution: External email.
| >> On 16 October 2023 at 10:42, Kevin R Coombes wrote:
| >> | Produce a PDF file yourself, then use the "as.is" feature of the
R.rsp
| >> | package.
| >> For completeness, that approach also works directly with Sweave.
Described in
| >> a blog post by Mark van der Loo in 2019, and used in a number of
packages
| >> including a few of mine.
| >> That said, I also used the approach described by John Harrold and
cached
| >> results myself.
| >> Dirk
| >> --
| >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >> __
| >> 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-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debia

[R-pkg-devel] unregistered S3 methods in a package

[John Fox]

Dear R-package-devel list members,

I want to introduce several unregistered S3 methods into the cv package 
(code at <https://github.com/gmonette/cv>). These methods have the form


coef.merMod <- function(object, ...) lme4::fixef(object)

The object is to mask, e.g., lme4:::coef.merMod(), which returns BLUPs 
rather than fixed effects, internally in the cv package but *not* to 
mask the lme4 version of the method for users of the cv package -- that 
could wreak havoc with their work. Doing this substantially simplifies 
some of the code in the cv package.


My question: Is it legitimate to define a method in a package for 
internal use without registering it?


This approach appears to work fine, and R CMD check doesn't complain, 
although Roxygen does complain that the method isn't "exported" 
(actually, isn't registered).


Any advice or relevant information would be appreciated.

Thank you,
 John
--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://www.john-fox.ca/
--

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] unregistered S3 methods in a package

[John Fox]

As it turned out, I was able to avoid redefining coef.merMod(), etc., by 
making a simple modification to the cv package.


I'm still curious about whether it's OK to have unregistered S3 methods 
for internal use in a package even though that's no longer necessary for 
the cv package.


On 2024-09-02 11:34 a.m., John Fox wrote:

Caution: External email.


Dear R-package-devel list members,

I want to introduce several unregistered S3 methods into the cv package
(code at <https://github.com/gmonette/cv>). These methods have the form

    coef.merMod <- function(object, ...) lme4::fixef(object)

The object is to mask, e.g., lme4:::coef.merMod(), which returns BLUPs
rather than fixed effects, internally in the cv package but *not* to
mask the lme4 version of the method for users of the cv package -- that
could wreak havoc with their work. Doing this substantially simplifies
some of the code in the cv package.

My question: Is it legitimate to define a method in a package for
internal use without registering it?

This approach appears to work fine, and R CMD check doesn't complain,
although Roxygen does complain that the method isn't "exported"
(actually, isn't registered).

Any advice or relevant information would be appreciated.

Thank you,
  John
--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://www.john-fox.ca/
--

__
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] unregistered S3 methods in a package

[John Fox]

Thanks Toby and Jeff for chiming in on this.

Jeff: I already read Kurt Hornik's post on "S3 Method Lookup" and quite 
a few other sources.


The main point is that failing to register the methods works in that the 
methods are nevertheless invoked internally by functions in the package 
but don't shadow versions of the methods registered by other package 
externally (e.g., at the command prompt), which was the effect that I 
wanted. Moreover, as I said, R CMD check (unlike roxygen) didn't complain.


As I mentioned, this is now moot for the cv package, but I'm still 
interested in the answer, as, apparently, is Toby.


Best,
 John

On 2024-09-04 5:12 p.m., Jeff Newmiller wrote:

Caution: External email.


I have been reluctant to pipe up on this because I am no expert on the dark 
corners of the S3 dispatch mechanism, but I think unregistered S3 methods in 
packages are verboten. Perhaps [1] will shed some light?

[1] https://blog.r-project.org/2019/08/19/s3-method-lookup/

On September 4, 2024 11:21:22 AM PDT, Toby Hocking  wrote:

I got this warning too, so I filed an issue to ask
https://github.com/r-lib/roxygen2/issues/1654

On Mon, Sep 2, 2024 at 2:58 PM John Fox  wrote:


As it turned out, I was able to avoid redefining coef.merMod(), etc., by
making a simple modification to the cv package.

I'm still curious about whether it's OK to have unregistered S3 methods
for internal use in a package even though that's no longer necessary for
the cv package.

On 2024-09-02 11:34 a.m., John Fox wrote:

Caution: External email.


Dear R-package-devel list members,

I want to introduce several unregistered S3 methods into the cv package
(code at <https://github.com/gmonette/cv>). These methods have the form

 coef.merMod <- function(object, ...) lme4::fixef(object)

The object is to mask, e.g., lme4:::coef.merMod(), which returns BLUPs
rather than fixed effects, internally in the cv package but *not* to
mask the lme4 version of the method for users of the cv package -- that
could wreak havoc with their work. Doing this substantially simplifies
some of the code in the cv package.

My question: Is it legitimate to define a method in a package for
internal use without registering it?

This approach appears to work fine, and R CMD check doesn't complain,
although Roxygen does complain that the method isn't "exported"
(actually, isn't registered).

Any advice or relevant information would be appreciated.

Thank you,
   John
--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://www.john-fox.ca/
--

__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


--
Sent from my phone. Please excuse my brevity.


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] unregistered S3 methods in a package

[John Fox]

Thank you Uwe and Martin for clarifying this issue.

The last paragraph of the comments that Kurt pointed out refers to a 
generic function defined in a package; in my case, the generic is 
coef(), which is in the stats package not in the cv package, and the 
question concerned methods for coef() (previously) defined in the cv 
package and not registered. But the comments as a whole do cover that 
case as well.


Best,
 John


On 2024-09-05 3:44 a.m., Martin Maechler wrote:

Caution: External email.



Uwe Ligges
 on Thu, 5 Sep 2024 08:47:06 +0200 writes:


 > Dear John,
 > the question is not really easy to answer, but there is a nice summary
 > Kurt pointed me to: The code of checkS3methods() includes the following
 > comments with the last paragraph containing the short answer to your
 > question:

 > ## Check S3 generics and methods consistency.

 > ## Unfortunately, what is an S3 method is not clear.
 > ## These days, S3 methods for a generic GEN are found
 > ## A. via GEN.CLS lookup from the callenv to its topenv;
 > ## B. the S3 registry;
 > ## C. GEN.CLS lookup from the parent of the topenv to baseenv,
 > ##skipping everything on the search path between globalenv and
 > ##baseenv.
 > ## Thus if "package code" calls GEN, we first look in the package
 > ## namespace itself, then in the registry, and then in the package
 > ## imports and .BaseNamespaceEnv (and globalenv and baseenv again).
 > ##
 > ## Clearly, everything registered via S3method() should be an S3
 > ## method.  Interestingly, we seem to have some registrations for
 > ## non-generics, such as grDevices::axis().  These are "harmless"
 > ## but likely not "as intended", and hence inconsistencies are not
 > ## ignored.
 > ##
 > ## If the package namespace has a function named GEN.CLS, it is used
 > ## as an S3 method for an S3 generic named GEN (and hence "is an S3
 > ## method") only if the package code actually calls GEN (see A
 > ## above).  So one could argue that we should not be looking at all
 > ## GEN.CLS matches with GEN a generic in the package itself, its
 > ## imports or base, but restrict to only the ones where the package
 > ## code calls GEN.  Doable, but not straightforward (calls could be
 > ## PKG::GEN) and possibly quite time consuming.  For generics from
 > ## the package itself or its imports, not restricting should not
 > ## make a difference (why define or import when not calling?), but
 > ## for generics from base it may: hence we filter out the mismatches
 > ## for base GEN not called in the package.
 > ##
 > ## If a package provides an S3 generic GEN, there is no need to
 > ## register GEN.CLS functions for "internal use" (see above).
 > ## However, if GEN is exported then likely all GEN.CLS functions
 > ## should be registered as S3 methods.

 > Best wishes,
 > Uwe

Excellent!  Thank you, Uwe, for digging this out.

I'd also had answered to John Fox (even more strongly)
that it *must* remain to be allowed to define "private"
S3 methods in a package in all cases:
- for a generic from the package (where the generic would also
   not be exported)
- for a generic from another package (which is imported)
   or base (which need not and cannot be imported).

Note that the same is possible with S4 and (AFAIK, untested)
with S7.  {which people should really try using more ... }

Martin



 > On 05.09.2024 00:10, John Fox wrote:
 >> Thanks Toby and Jeff for chiming in on this.
 >>
 >> Jeff: I already read Kurt Hornik's post on "S3 Method Lookup" and quite
 >> a few other sources.
 >>
 >> The main point is that failing to register the methods works in that the
 >> methods are nevertheless invoked internally by functions in the package
 >> but don't shadow versions of the methods registered by other package
 >> externally (e.g., at the command prompt), which was the effect that I
 >> wanted. Moreover, as I said, R CMD check (unlike roxygen) didn't 
complain.
 >>
 >> As I mentioned, this is now moot for the cv package, but I'm still
 >> interested in the answer, as, apparently, is Toby.
 >>
 >> Best,
 >>  John
 >>
 >> On 2024-09-04 5:12 p.m., Jeff Newmiller wrote:
 >>> Caution: External email.
 >>>
 >>>
 >>> I have been reluctant to pipe up on this because I am no expert on the
 >>> dark corners of the S3 dispatch mechanism, but I think unregistered S3
 >>> methods in pa

[R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear r-package-devel list members,

I got the following note when checking two different packages today 
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and 
macOS Catalina systems, and on several platforms on rhub:


* checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned 
this problem recently, in case it's produced by something that I'm 
doing. There is a discussion of a similar problem from 2019 at 
<https://stat.ethz.ch/pipermail/r-package-devel/2019q1/003577.html>.


Both packages that I was checking are close to CRAN releases and so I'd 
like to know whether I can disregard the note.


Any help would be appreciated.

John

--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear Duncan,

Thank you and the others who responded to my message.

John

On 2020-08-27 2:17 p.m., Duncan Murdoch wrote:

R tries to get the time from

http://worldtimeapi.org/api/timezone/UTC or
http://worldclockapi.com/api/json/utc/now

The first one doesn't accept UTC as a timezone; it appears to want 
etc/UTC instead.  The second one is offline.


Duncan Murdoch

If both of those fail, you'll get the message you saw.

On 27/08/2020 1:23 p.m., John Fox wrote:

Dear r-package-devel list members,

I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:

* checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned
this problem recently, in case it's produced by something that I'm
doing. There is a discussion of a similar problem from 2019 at
<https://stat.ethz.ch/pipermail/r-package-devel/2019q1/003577.html>.

Both packages that I was checking are close to CRAN releases and so I'd
like to know whether I can disregard the note.

Any help would be appreciated.

John





__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear Dustin,

On 2020-08-27 8:26 p.m., Tracy, Josef wrote:

Hi John,

Duncan explained the cause of the problem, but i'm afraid I didn't 
follow how one solves it.  Did you manage to get a check without that note?


I didn't -- I just disregarded the note assuming that it would go away 
when the time server was back up.


(I've cc'd the R-package-devel list so that others can see your question 
and my response.)


Best,
 John



Thanks You,
Dustin

Dustin Tracy

Postdoctoral Researcher

Economic Science Institute

Chapman University

www.DustinTracy.com <http://www.DustinTracy.com>




*From:* R-package-devel  on 
behalf of John Fox 

*Sent:* Thursday, August 27, 2020 11:39 AM
*To:* Duncan Murdoch ; 
r-package-devel@r-project.org 

*Subject:* Re: [R-pkg-devel] R CMD check "unable to verify current time"
External Message


[External Message]

Dear Duncan,

Thank you and the others who responded to my message.

John

On 2020-08-27 2:17 p.m., Duncan Murdoch wrote:

R tries to get the time from

https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworldtimeapi.org%2Fapi%2Ftimezone%2FUTC&data=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320&sdata=GHBn6K9Yl7qaRU6tYzAEzymO3751Uczj51xB9c17Zm4%3D&reserved=0 

or

https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworldclockapi.com%2Fapi%2Fjson%2Futc%2Fnow&data=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320&sdata=psttxEnhMO6MjLyEv%2BchRopHyhLvgCxgqLT0JDPQVys%3D&reserved=0

The first one doesn't accept UTC as a timezone; it appears to want
etc/UTC instead.  The second one is offline.

Duncan Murdoch

If both of those fail, you'll get the message you saw.

On 27/08/2020 1:23 p.m., John Fox wrote:

Dear r-package-devel list members,

I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:

 * checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned
this problem recently, in case it's produced by something that I'm
doing. There is a discussion of a similar problem from 2019 at
<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fpipermail%2Fr-package-devel%2F2019q1%2F003577.html&data=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320&sdata=GWnhngNH3UypXzbCzQOOwVHa8q87slWBhEW6n4PthGQ%3D&reserved=0>.

Both packages that I was checking are close to CRAN releases and so I'd
like to know whether I can disregard the note.

Any help would be appreciated.

John





__
R-package-devel@r-project.org mailing list
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320&sdata=rMlgTGg8rp7hxPhaiADuBl4%2FWSqGgx4wbKLIPgPS9o8%3D&reserved=0
- NOTE: This email originated from outside Chapman’s network. Do not 
click links or open attachments unless you recognize the sender and know 
content is safe.


NOTE: This email originated from outside Chapman’s network. Do not click 
links or open attachments unless you recognize the sender and know 
content is safe.




__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] is R CMD build --compact-vignettes working as expected?

[John Fox]

Dear Ben,

I was hoping that someone would pick up on this problem, because I've 
experienced the same issue of --compact-vignettes apparently ignored, 
e.g., with the Rcmdr package under R 4.0.2 on both macOS and Windows.


Best,
 John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2020-10-05 1:09 p.m., Ben Bolker wrote:

   Am I confused, or doing something wrong, or ... ?

   I have qpdf installed, and am running R CMD build with 
--compact-vignettes, but the PDF in the tarball doesn't seem to be 
compressed despite the fact that the output messages say "compacting 
vignettes ..."



   $ R CMD build --compact-vignettes lme4
* checking for file ‘lme4/DESCRIPTION’ ... OK
* preparing ‘lme4’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... OK
Warning: ‘inst/doc’ files
     ‘lmerperf.html’, ‘lmer.pdf’, ‘PLSvGLS.pdf’, ‘Theory.pdf’
   ignored as vignettes have been rebuilt.
   Run R CMD build with --no-build-vignettes to prevent rebuilding.
* compacting vignettes and other PDF files
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘lme4_1.1-24.tar.gz’

   The copy of lmer.pdf in the resulting tarball is 900K or so:

$ tar ztvf lme4_1.1-24.tar.gz lme4/inst/doc/lmer.pdf
-rw-r--r-- bolker/bolker 907022 2020-10-05 12:59 lme4/inst/doc/lmer.pdf

   The previously built (and manually compacted) version of lmer.pdf in 
the tarball is 500K:


$ ls -l lme4/inst/doc/lmer.pdf
-rw-r--r-- 1 bolker bolker 495199 Oct  3 22:15 lme4/inst/doc/lmer.pdf

    Is 'R CMD build' confused by the presence of a pre-built PDF in the 
inst/doc directory? Or am I somehow mistaken about how this is supposed 
to work?


    I would just use --no-build-vignettes and submit the tarball with 
the previously built/compressed PDF, but I'm trying to avoid a
"Package has a VignetteBuilder field but no prebuilt vignette index" 
NOTE, which I assume is missing because I built without building 
vignettes ... ?


   As always, enlightenment is welcome.

   cheers
     Ben Bolker

__
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] is R CMD build --compact-vignettes working as expected?

[John Fox]

Dear Ben,

On 2020-10-07 5:26 p.m., Ben Bolker wrote:
   I hope so too. The (annoying) workaround is to compact the vignette 
yourself (using qpdf directly or using tools::compactPDF), then use 
no-build-vignettes.  The problem there is whatever's supposed to happen 
with building vignette indices.  The ugly workaround, I guess, is to 
build the tarball, compact the vignettes oneself, then *replace* them in 
the tarball.  (Obviously I can automate that, but it seems as though it 
would be unnecessary if I knew what was going on ...)


I've used both of these workarounds and agree that it would be nice to 
avoid them. After all, what is the --compact-vignettes argument for?


Best,
 John



   cheers
    Ben


On 10/7/20 4:10 PM, John Fox wrote:

Dear Ben,

I was hoping that someone would pick up on this problem, because I've 
experienced the same issue of --compact-vignettes apparently ignored, 
e.g., with the Rcmdr package under R 4.0.2 on both macOS and Windows.


Best,
  John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2020-10-05 1:09 p.m., Ben Bolker wrote:

   Am I confused, or doing something wrong, or ... ?

   I have qpdf installed, and am running R CMD build with 
--compact-vignettes, but the PDF in the tarball doesn't seem to be 
compressed despite the fact that the output messages say "compacting 
vignettes ..."



   $ R CMD build --compact-vignettes lme4
* checking for file ‘lme4/DESCRIPTION’ ... OK
* preparing ‘lme4’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... OK
Warning: ‘inst/doc’ files
 ‘lmerperf.html’, ‘lmer.pdf’, ‘PLSvGLS.pdf’, ‘Theory.pdf’
   ignored as vignettes have been rebuilt.
   Run R CMD build with --no-build-vignettes to prevent rebuilding.
* compacting vignettes and other PDF files
* cleaning src
* checking for LF line-endings in source and make files and shell 
scripts

* checking for empty or unneeded directories
* building ‘lme4_1.1-24.tar.gz’

   The copy of lmer.pdf in the resulting tarball is 900K or so:

$ tar ztvf lme4_1.1-24.tar.gz lme4/inst/doc/lmer.pdf
-rw-r--r-- bolker/bolker 907022 2020-10-05 12:59 lme4/inst/doc/lmer.pdf

   The previously built (and manually compacted) version of lmer.pdf 
in the tarball is 500K:


$ ls -l lme4/inst/doc/lmer.pdf
-rw-r--r-- 1 bolker bolker 495199 Oct  3 22:15 lme4/inst/doc/lmer.pdf

    Is 'R CMD build' confused by the presence of a pre-built PDF in 
the inst/doc directory? Or am I somehow mistaken about how this is 
supposed to work?


    I would just use --no-build-vignettes and submit the tarball with 
the previously built/compressed PDF, but I'm trying to avoid a
"Package has a VignetteBuilder field but no prebuilt vignette index" 
NOTE, which I assume is missing because I built without building 
vignettes ... ?


   As always, enlightenment is welcome.

   cheers
 Ben Bolker

__
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] is R CMD build --compact-vignettes working as expected?

[John Fox]

Dear Ben,

Actually, what I used was --compact-vignettes="both", with qpdf and gs 
installed on my Windows and Mac machines, and that apparently didn't 
work for me.


Best,
 John

On 2020-10-07 10:06 p.m., Ben Bolker wrote:
   OK, I think I see the problem. tl;dr use --compact-vignettes="both" 
when building the vignettes.


   --compact-vignettes  by default only tries qpdf.

   when the R CMD check --as-cran is run, it tries both qpdf and gs. 
Since gs (apparently, in this case) compresses more aggressively than 
qpdf, it succeeds in compressing further, and the check complains.


 From R CMD build --help:

  --compact-vignettes=  try to compact PDF files under inst/doc:
     "no" (default), "qpdf", "gs", "gs+qpdf", "both"
   --compact-vignettes   same as --compact-vignettes=qpdf


   I don't know if this is worth documenting somewhere, or modifying the 
behaviour to make "both" the default for --compact-vignettes ?



On 10/7/20 8:35 PM, Duncan Murdoch wrote:

On 07/10/2020 8:32 p.m., Ben Bolker wrote:

    Thanks for the tip, I'll take a look.

    Given that three relatively experienced package authors all seem to
have experienced similar issues, it seems that maybe this is worth
figuring out/maybe I'm not just doing something boneheaded.


Just to clarify:  I've never noticed the problem you mention.  I just 
know how to debug R CMD build.


Duncan



    cheers
  Ben

On 10/7/20 8:31 PM, Duncan Murdoch wrote:

I don't know the answer to your question, but you can debug the
--compact-vignettes option as follows.

debug(tools::compactPDF)
tools:::.build_packages(c("--compact-vignettes", "pkgdir"))

where "pkgdir" is the directory of the source of your package.  Add
extra options to the build as separate elements of the argument to
.build():  this function is called after args have been parsed.

When I do that, I see that it rejects the compaction, because none of
mine benefit much from it:  it wants at least a 10% and 10K reduction.
But Ben's example met those criteria.  When I trick it into accepting
the compaction, it does put the compacted PDF into the tarball.

Duncan Murdoch

On 07/10/2020 6:03 p.m., John Fox wrote:

Dear Ben,

On 2020-10-07 5:26 p.m., Ben Bolker wrote:
     I hope so too. The (annoying) workaround is to compact the 
vignette

yourself (using qpdf directly or using tools::compactPDF), then use
no-build-vignettes.  The problem there is whatever's supposed to 
happen
with building vignette indices.  The ugly workaround, I guess, 
is to
build the tarball, compact the vignettes oneself, then *replace* 
them in
the tarball.  (Obviously I can automate that, but it seems as 
though it

would be unnecessary if I knew what was going on ...)


I've used both of these workarounds and agree that it would be nice to
avoid them. After all, what is the --compact-vignettes argument for?

Best,
    John



     cheers
      Ben


On 10/7/20 4:10 PM, John Fox wrote:

Dear Ben,

I was hoping that someone would pick up on this problem, because 
I've
experienced the same issue of --compact-vignettes apparently 
ignored,
e.g., with the Rcmdr package under R 4.0.2 on both macOS and 
Windows.


Best,
John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2020-10-05 1:09 p.m., Ben Bolker wrote:

 Am I confused, or doing something wrong, or ... ?

 I have qpdf installed, and am running R CMD build with
--compact-vignettes, but the PDF in the tarball doesn't seem to be
compressed despite the fact that the output messages say 
"compacting

vignettes ..."


 $ R CMD build --compact-vignettes lme4
* checking for file ‘lme4/DESCRIPTION’ ... OK
* preparing ‘lme4’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... OK
Warning: ‘inst/doc’ files
   ‘lmerperf.html’, ‘lmer.pdf’, ‘PLSvGLS.pdf’, ‘Theory.pdf’
 ignored as vignettes have been rebuilt.
 Run R CMD build with --no-build-vignettes to prevent 
rebuilding.

* compacting vignettes and other PDF files
* cleaning src
* checking for LF line-endings in source and make files and shell
scripts
* checking for empty or unneeded directories
* building ‘lme4_1.1-24.tar.gz’

 The copy of lmer.pdf in the resulting tarball is 900K or so:

$ tar ztvf lme4_1.1-24.tar.gz lme4/inst/doc/lmer.pdf
-rw-r--r-- bolker/bolker 907022 2020-10-05 12:59
lme4/inst/doc/lmer.pdf

 The previously built (and manually compacted) version of 
lmer.pdf

in the tarball is 500K:

$ ls -l lme4/inst/doc/lmer.pdf
-rw-r--r-- 1 bolker bolker 495199 Oct  3 22:15 
lme4/inst/doc/lmer.pdf


  Is 'R CMD build' confused by the presence of a pre-built 
PDF in

the inst/doc di

Re: [R-pkg-devel] is R CMD build --compact-vignettes working as expected?

[John Fox]

Dear all,

First, thank you to everyone who responded.

Let me be more specific about what I did, focusing on macOS (since I did 
most of this on Windows too):


(1) I observed the problem with the Rcmdr package, including version 
2.7-1, which is newly on CRAN. Presumably, it wouldn't be hard to 
duplicate what I did.


(2) I previously tried both --compact-vignettes="both", 
--compact-vignettes=both, and also just --compact-vignettes. R CMD build 
says that it's "* compacting vignettes and other PDF files", and R CMD 
check --as-cran doesn't complain, reporting "* checking sizes of PDF 
files under ‘inst/doc’ ... OK."


(3) Nothing changes when, following Duncan's advice, I set GS_QUALITY=screen

In the tarball built by R CMD build, the vignette in 
inst/doc/Getting-Started-with-the-Rcmdr.pdf is 1.6 MB. When I compacted 
the vignette with Adobe Acrobat, it was reduced to 395 KB.


Putting all of this together, I suspect that Acrobat may just do a 
better job than gs and qpdf.


Best,
 John


On 2020-10-08 12:06 p.m., Duncan Murdoch wrote:
When I tried that on MacOS, it did the gs compression with gs_quality 
set to "none", which does nothing.  I don't know what quality CRAN uses, 
but for me setting the environment variable GS_QUALITY=screen made a big 
difference.


Duncan Murdoch

On 08/10/2020 11:10 a.m., John Fox wrote:

Dear Ben,

Actually, what I used was --compact-vignettes="both", with qpdf and gs
installed on my Windows and Mac machines, and that apparently didn't
work for me.

Best,
   John

On 2020-10-07 10:06 p.m., Ben Bolker wrote:

    OK, I think I see the problem. tl;dr use --compact-vignettes="both"
when building the vignettes.

    --compact-vignettes  by default only tries qpdf.

    when the R CMD check --as-cran is run, it tries both qpdf and gs.
Since gs (apparently, in this case) compresses more aggressively than
qpdf, it succeeds in compressing further, and the check complains.

  From R CMD build --help:

   --compact-vignettes=  try to compact PDF files under inst/doc:
      "no" (default), "qpdf", "gs", "gs+qpdf", 
"both"

    --compact-vignettes   same as --compact-vignettes=qpdf


    I don't know if this is worth documenting somewhere, or modifying 
the

behaviour to make "both" the default for --compact-vignettes ?


On 10/7/20 8:35 PM, Duncan Murdoch wrote:

On 07/10/2020 8:32 p.m., Ben Bolker wrote:

 Thanks for the tip, I'll take a look.

 Given that three relatively experienced package authors all 
seem to

have experienced similar issues, it seems that maybe this is worth
figuring out/maybe I'm not just doing something boneheaded.


Just to clarify:  I've never noticed the problem you mention.  I just
know how to debug R CMD build.

Duncan



 cheers
   Ben

On 10/7/20 8:31 PM, Duncan Murdoch wrote:

I don't know the answer to your question, but you can debug the
--compact-vignettes option as follows.

debug(tools::compactPDF)
tools:::.build_packages(c("--compact-vignettes", "pkgdir"))

where "pkgdir" is the directory of the source of your package.  Add
extra options to the build as separate elements of the argument to
.build():  this function is called after args have been parsed.

When I do that, I see that it rejects the compaction, because none of
mine benefit much from it:  it wants at least a 10% and 10K 
reduction.

But Ben's example met those criteria.  When I trick it into accepting
the compaction, it does put the compacted PDF into the tarball.

Duncan Murdoch

On 07/10/2020 6:03 p.m., John Fox wrote:

Dear Ben,

On 2020-10-07 5:26 p.m., Ben Bolker wrote:

      I hope so too. The (annoying) workaround is to compact the
vignette
yourself (using qpdf directly or using tools::compactPDF), then use
no-build-vignettes.  The problem there is whatever's supposed to
happen
with building vignette indices.  The ugly workaround, I guess,
is to
build the tarball, compact the vignettes oneself, then *replace*
them in
the tarball.  (Obviously I can automate that, but it seems as
though it
would be unnecessary if I knew what was going on ...)


I've used both of these workarounds and agree that it would be 
nice to

avoid them. After all, what is the --compact-vignettes argument for?

Best,
 John



      cheers
       Ben


On 10/7/20 4:10 PM, John Fox wrote:

Dear Ben,

I was hoping that someone would pick up on this problem, because
I've
experienced the same issue of --compact-vignettes apparently
ignored,
e.g., with the Rcmdr package under R 4.0.2 on both macOS and
Windows.

Best,
 John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2020-10-05 1:09 p.m., Ben Bolker wrote:

  Am I confused, or doing something 

Re: [R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally

[John Fox]

Hi Michael,

It should be fine to have rgl in Suggests, and to have the 3D graphics 
functions that use rgl throw an error if rgl is absent. What's not fine 
is having these errors triggered in the absence of rgl when examples are 
run or vignettes are compiled.


Putting rgl into Depends rather than Suggests would make the problem 
worse, because you couldn't then load your package without rgl.


So, as I believe a couple of others have suggested, wrap the problematic 
examples in, e.g., if(requireNamespace("rgl")){}, and do something 
similar in the vignettes.


I hope this helps,
 John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2020-12-12 1:40 p.m., Michael L Friendly wrote:

Thanks, Dirk

Just to clarify--
In my packages, candisc, heplots, vcdExtra I have mostly 2D graphic methods, 
but some 3D methods that use
rgl.  I therefore put rgl into Suggests:

Could I solve this by making rgl a Depends: ?

-Michael


-Original Message-
From: Dirk Eddelbuettel 
Sent: Saturday, December 12, 2020 12:46 PM
To: Michael L Friendly 
Cc: r-package-devel@R-project.org; Prof Brian Ripley 
Subject: Re: [R-pkg-devel] CRAN packages suggesting other packages but not 
using them conditionally


On 12 December 2020 at 16:24, Michael L Friendly wrote:
| I got the email below concerning 3 of my packages but wonder if they
| are false alarms or if not, how to locate & fix the problem.
|
| This concerns packages: ...
|
| Suggested packages should be used conditionally: see  1.1.3.1 of 'Writing 
R Extensions'.  Some of these are hard to install on a platform without X11 
such as M1 Macs: see the logs at https://www.stats.ox.ac.uk/pub/bdr/M1mac/.
|
| You can check all of the suggested packages by setting environment 
variable _R_CHECK_DEPENDS_ONLY_=true  -- see 
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .
|
| Is this a false alarm?
|
| In each case, the outfile contains:
|
| * checking package namespace information ... OK
| * checking package dependencies ... NOTE
| Package suggested but not available for checking: 'rgl'
|
| indicating that rgl is not avaiable on the testing machine.  Then,
| when checking examples an error is triggered when an example calls something 
that requires rgl.
|
| >
| > heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
| + col = c("red", "blue", "black", "gray"), wire=FALSE)
| Loading required namespace: rgl
| Failed with error:  'there is no package called 'rgl''
| Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg = c("AMED", 
"BMIQ")),  :
|   rgl package is required.
| Calls: heplot3d -> heplot3d.mlm
| Execution halted
|
| Yet, heplot3d seems to contain the required way to refer to the suggested rgl 
package:
|
| if (!requireNamespace("rgl")) stop("rgl package is
| required.")
|
| So, I'm mystified.  Can anyone help?

This is not conditional use in the sense of my reading of WRE.

What you have here is essentially an "assert()" and equivalent to
   stopifnot(requireNamespace("rgl"))
which, in turn, is equivalent to a strong Depends or Imports as your package 
will experience a _critical error_ triggered by `stop()` if rgl is missing.

The idea of a conditional use is to, well, be conditional. Below I make use of 
Rcpp if is present, but it is only a suggests:

   ## see the source files in the snippets/ directory of the package
   ## check for (optional, only in Suggests:) Rcpp, and also wrapped in a
   ## dontrun as it takes 10s at CRAN (yet only 3.5 here) yielding a NOTE
   if (requireNamespace("Rcpp", quietly=TRUE)) {
   Rcpp::sourceCpp(system.file("snippets", "convolveExample.cpp", 
package="tidyCpp"))
   }

If the _suggested_ package is present, it is used. If not we quietly move on.
(It's not the full story as the compilation occassionally takes longer, Windows 
complained so all this is now in a \dontrun{} block too. But the idea is 
generic and there are many more examples to be found.)

Hope this helps,  Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
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] Changes in function call with respect to the current published version

[John Fox]

Dear Jose,

On 2024-12-18 10:26 a.m., John Fox wrote:

Caution: External email.


Dear Jose,

Assuming that you can fix the bugs in the original function, one
approach would be to make myfun() generic, say myfun <- function(y, ...)
UseMethod("myfun"), with the (fixed) original myfun() as the default
method and a new function method, which would probably set up a call to


That should read "a new formula method" (not "a new function method").

Sorry for the confusion,
 John


the default method. Then existing code wouldn't break and users would
have the option of using a formula.

I hope this helps,
  John
--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://www.john-fox.ca/
--

On 2024-12-17 4:00 p.m., Jose Barrera-Gómez wrote:
[You don't often get email from jose.barr...@isglobal.org. Learn why 
this is important at https://aka.ms/LearnAboutSenderIdentification ]


Caution: External email.


Dear List,

I have a package that works in the context of regression models. The main
function has arguments (y, x, z, data, ...), where y is the response
variable, x is the explanatory variable and z can be other covariates.

Due to some bugs, I am interested in changing the call from (y, x, z, 
data,

...) to (formula, data, ...).

For instance, current usage is

myfun(y = birthweight, x = cotinine, z = age, data = mydata, ...)

and new usage would be

myfun(formula = birthweight ~ cotinine + age, data = mydata, ...)

This change would have no impact on the usage for the rest of the 
package.


My concern is that users updating the package won't be able to reproduce
old analyses. I.e. they would need to update the calls to myfun (but
nothing else related to the usage of other functions or methods).

I think the new usage would result in some advantages and bugs fixing and
only the disadvantage I mentioned just above.

I would appreciate advice on:

1) There could be other disadvantages for users of previous versions 
that I

don't see?

2) What would be the best location(s) in the documentation to explain in
detail this change?

Thanks in advance,

Jose Barrera
Statistician, Associate Lecturer

*IS**Global*
Barcelona Institute for Global Health - Campus MAR
Barcelona Biomedical Research Park (PRBB) (Room Hypatia)

Doctor Aiguader, 88
08003 Barcelona, Spain
Tel. +34 93 2147383
jose.barr...@isglobal.org
<https://www.linkedin.com/in/josebarrera>
Personal website: sites.google.com/view/josebarrera
www.isglobal.org

This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited by law. If this message has been received in error, please
immediately notify us via e-mail and delete it.

DATA PROTECTION. We inform you that your personal data, including your
e-mail address and data included in your email correspondence, are 
included

in the ISGlobal Foundation filing system. Your personal data will be used
for the purpose of contacting you and sending information on the 
activities

of the above foundations. You can exercise your rights to  access to
personal data, rectification, erasure, restriction of processing, data
portability and object by contacting the following address: 
*l...@isglobal.org

*. ISGlobal Privacy Policy at *www.isglobal.org
<http://www.isglobal.org/>*.


-

CONFIDENCIALIDAD. Este mensaje y sus anexos se dirigen exclusivamente 
a su

destinatario y puede contener información confidencial, por lo que la
utilización, divulgación y/o copia sin autorización está prohibida por la
legislación vigente. Si ha recibido este mensaje por error, le rogamos lo
comunique inmediatamente por esta misma vía y proceda a su destrucción.

PROTECCIÓN DE DATOS. Sus datos de carácter personal utilizados en este
envío, incluida su dirección de e-mail, forman parte de ficheros de
titularidad de la Fundación ISGlobal  para cualquier finalidades de
contacto, relación institucional y/o envío de información sobre sus
actividades. Los datos que usted nos pueda facilitar contestando este
correo quedarán incorporados en los correspondientes ficheros, 
autorizando

el uso de su dirección de e-mail para las finalidades citadas. Puede
ejercer los derechos de acceso, rectificación, supresión, limitación del
tratamiento, portabilidad y oposición dirigiéndose a *l...@isglobal.org
* . Política de privacidad en *www.isglobal.org
<http://www.isglobal.org/>*.

--


This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If
you are not the intended recipient you are hereby notified that any
dissemi

Re: [R-pkg-devel] Changes in function call with respect to the current published version

[John Fox]

Dear Jose,

Assuming that you can fix the bugs in the original function, one 
approach would be to make myfun() generic, say myfun <- function(y, ...) 
UseMethod("myfun"), with the (fixed) original myfun() as the default 
method and a new function method, which would probably set up a call to 
the default method. Then existing code wouldn't break and users would 
have the option of using a formula.


I hope this helps,
 John
--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://www.john-fox.ca/
--

On 2024-12-17 4:00 p.m., Jose Barrera-Gómez wrote:

[You don't often get email from jose.barr...@isglobal.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Caution: External email.


Dear List,

I have a package that works in the context of regression models. The main
function has arguments (y, x, z, data, ...), where y is the response
variable, x is the explanatory variable and z can be other covariates.

Due to some bugs, I am interested in changing the call from (y, x, z, data,
...) to (formula, data, ...).

For instance, current usage is

myfun(y = birthweight, x = cotinine, z = age, data = mydata, ...)

and new usage would be

myfun(formula = birthweight ~ cotinine + age, data = mydata, ...)

This change would have no impact on the usage for the rest of the package.

My concern is that users updating the package won't be able to reproduce
old analyses. I.e. they would need to update the calls to myfun (but
nothing else related to the usage of other functions or methods).

I think the new usage would result in some advantages and bugs fixing and
only the disadvantage I mentioned just above.

I would appreciate advice on:

1) There could be other disadvantages for users of previous versions that I
don't see?

2) What would be the best location(s) in the documentation to explain in
detail this change?

Thanks in advance,

Jose Barrera
Statistician, Associate Lecturer

*IS**Global*
Barcelona Institute for Global Health - Campus MAR
Barcelona Biomedical Research Park (PRBB) (Room Hypatia)

Doctor Aiguader, 88
08003 Barcelona, Spain
Tel. +34 93 2147383
jose.barr...@isglobal.org
<https://www.linkedin.com/in/josebarrera>
Personal website: sites.google.com/view/josebarrera
www.isglobal.org

This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited by law. If this message has been received in error, please
immediately notify us via e-mail and delete it.

DATA PROTECTION. We inform you that your personal data, including your
e-mail address and data included in your email correspondence, are included
in the ISGlobal Foundation filing system. Your personal data will be used
for the purpose of contacting you and sending information on the activities
of the above foundations. You can exercise your rights to  access to
personal data, rectification, erasure, restriction of processing, data
portability and object by contacting the following address: *l...@isglobal.org
*. ISGlobal Privacy Policy at *www.isglobal.org
<http://www.isglobal.org/>*.


-

CONFIDENCIALIDAD. Este mensaje y sus anexos se dirigen exclusivamente a su
destinatario y puede contener información confidencial, por lo que la
utilización, divulgación y/o copia sin autorización está prohibida por la
legislación vigente. Si ha recibido este mensaje por error, le rogamos lo
comunique inmediatamente por esta misma vía y proceda a su destrucción.

PROTECCIÓN DE DATOS. Sus datos de carácter personal utilizados en este
envío, incluida su dirección de e-mail, forman parte de ficheros de
titularidad de la Fundación ISGlobal  para cualquier finalidades de
contacto, relación institucional y/o envío de información sobre sus
actividades. Los datos que usted nos pueda facilitar contestando este
correo quedarán incorporados en los correspondientes ficheros, autorizando
el uso de su dirección de e-mail para las finalidades citadas. Puede
ejercer los derechos de acceso, rectificación, supresión, limitación del
tratamiento, portabilidad y oposición dirigiéndose a *l...@isglobal.org
* . Política de privacidad en *www.isglobal.org
<http://www.isglobal.org/>*.

--


This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If
you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited
by law. If this message has been received in error, please
immediately notify
us via e-mail and delete it.



DATA PROTECTION. We
inform you that yo