[R-pkg-devel] Deprecating apparent S3 method, changing name

[Murray Efford via R-package-devel]

A package of mine on CRAN has some old function names (not S3 methods) that 
include "." (e.g., "esa.plot"). In a new version I want to simultaneously
1. rename these functions to e.g. "esaPlot"
2. export a new S3 generic with the base name (e.g. "esa") and methods for 
different model types (e.g. "esa.secr").

When I deprecate the old functions (by exporting a shell function that calls 
.Deprecated and the new function), I get a package check note for e.g. esa.plot
"* checking S3 generic/method consistency ... NOTE
Apparent methods for exported generics not registered: etc."

This is understandable, but how can I avoid it while properly deprecating the 
old functions? I seem to remember a recent question like this, but I'm sorry I 
cannot find it.

Murray

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

[Murray Efford via R-package-devel]

Thanks for your excellent exposition of the problem, Ivan. The set-aside option 
would be attractive in the long term and make it easier to fix historical 
errors like mine. Presumably there is also a downside to creating a safe space 
for badly named functions.

I am tossing up between (i) appealing to CRAN to allow the submission through 
with NOTEs until it feels safe to remove the functions with misleading names 
altogether, and (ii) removing them now and warning users about the new names in 
an  onLoad message.
Murray

From: Ivan Krylov 
Sent: Friday, 27 September 2024 08:48
To: Murray Efford via R-package-devel 
Cc: Murray Efford 
Subject: Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

� Wed, 25 Sep 2024 05:13:31 +
Murray Efford via R-package-devel  �:

> When I deprecate the old functions (by exporting a shell function
> that calls .Deprecated and the new function), I get a package check
> note for e.g. esa.plot "* checking S3 generic/method consistency ...
> NOTE Apparent methods for exported generics not registered: etc."
>
> This is understandable, but how can I avoid it while properly
> deprecating the old functions?

R CMD check has a hard-coded list of functions that should not be
considered S3 methods, in tools:::nonS3methods(). All other functions
that start with the name of an exported generic followed by a dot will
be considered unregistered S3 methods.

Theoretically speaking, if there was a place in your package where you
called the esa() generic with a user-supplied object, esa.plot() would
be a reachable S3 method, because the user would be able to construct
structure(list(), class = 'plot') and give it to your package code to
call esa(plot_object) and have it dispatched to esa.plot(). (Which
wouldn't be useful to the user, but that's how S3 works.)

I'm afraid that the NOTE is unavoidable in a package that has both an
esa() generic and an esa.plot() non-method function. Perhaps it could
be explained in the submission comment? (Especially since esa.plot()
currently seems unreachable as an S3 method to normal users of the
package.)

I wonder if it's possible to set aside a "please don't consider me for
S3 dispatch" bit in the CLOSXP objects. Then package authors would be
able to set it on their unfortunately named functions, R CMD check
would look it up before considering them to be unexported methods, and
the function findFunWithBaseEnvAfterGlobalEnv() that's responsible for
looking up non-registered S3 methods during UseMethod() would skip over
such closures.

--
Best regards,
Ivan

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

[Murray Efford via R-package-devel]

Check results vary. With win-builder both R-release (R 4.4.1) and R-devel I get

* checking S3 generic/method consistency ... NOTE
Apparent methods for exported generics not registered:
  esa.plot
See section 'Registering S3 methods' in the 'Writing R Extensions'
manual.

But there's no such Note on mac-builder R 4.4.0 or my own R CMD check --as-cran 
on Windows with R 4.3.2, nor apparently on R 4.4.1 linux.

Thanks for checking, but I think I do have a problem.
Murray

From: R-package-devel  on behalf of Jan 
van der Laan 
Sent: Monday, 30 September 2024 00:46
To: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

Hmm, the following doesn't seem to trigger warnings or notes in `R CMD
check --as-cran` (R 4.4.1; linux)

esa <- function(x) {


   UseMethod("esa")


}





esa.plot <- function(y) {


   .Deprecated("esaPlot")


   esaPlot(y)


}





esaPlot <- function(y) {


   message("esaPlot")


}





esa.numeric <- function(x) {


   message("esa.numeric")


}




With NAMESPACE:



S3method(esa, numeric)


export(esa)


export(esa.plot)


export(esaPlot)

Am I doing something different than you are?

Jan


On 9/25/24 07:13, Murray Efford via R-package-devel wrote:
> A package of mine on CRAN has some old function names (not S3 methods) that 
> include "." (e.g., "esa.plot"). In a new version I want to simultaneously
> 1. rename these functions to e.g. "esaPlot"
> 2. export a new S3 generic with the base name (e.g. "esa") and methods for 
> different model types (e.g. "esa.secr").
>
> When I deprecate the old functions (by exporting a shell function that calls 
> .Deprecated and the new function), I get a package check note for e.g. 
> esa.plot
> "* checking S3 generic/method consistency ... NOTE
> Apparent methods for exported generics not registered: etc."
>
> This is understandable, but how can I avoid it while properly deprecating the 
> old functions? I seem to remember a recent question like this, but I'm sorry 
> I cannot find it.
>
> Murray
>
>[[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C02%7Cmurray.efford%40otago.ac.nz%7Ce0eaedee90af46dc200e08dce07c68f8%7C0225efc578fe4928b1579ef24809e9ba%7C0%7C0%7C638632072195001025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=G%2BO6NtGHVy9xvfu2yPGy%2BBKbnOrC6hNxFXTVxLxu3wQ%3D&reserved=0<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

__
R-package-devel@r-project.org mailing list
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C02%7Cmurray.efford%40otago.ac.nz%7Ce0eaedee90af46dc200e08dce07c68f8%7C0225efc578fe4928b1579ef24809e9ba%7C0%7C0%7C638632072195023045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6hIjTj6E2HF8TGGwDb1JkVIjibztEgf10dSaxvvc8sg%3D&reserved=0<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

[Murray Efford via R-package-devel]

Almost too good to be true: with this in my NAMESPACE

export (esa.plot)
S3method(esa,plot)

it seems I can deprecate esa.plot by the usual route (calling .Deprecated and 
passing call through to the new function esaPlot).

Thanks!
Murray

From: Ivan Krylov 
Sent: Wednesday, 2 October 2024 00:45
To: Jan van der Laan 
Cc: Murray Efford ; Murray Efford via 
R-package-devel 
Subject: Re: [R-pkg-devel] Deprecating apparent S3 method, changing name

� Tue, 1 Oct 2024 09:00:24 +0200
Jan van der Laan  �:

> S3method(esa, plot, esaplotmethod)
>
> To register `esaplotmethod` as the method that is called when using
> `esa` with an object of type `plot`. This would prevent this issue.
> However, this probably (can't test as the note doesn't happen on my
> system) doesn't resolve the issue with the NOTE.

Excellent idea, thank you! It does work for R CMD check as well:

Sys.setenv("_R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_" = 'TRUE')
tools::checkS3methods(dir = '.') # used to show esa.plot as well
# Apparent methods for exported generics not registered:
#   fxi.contour fxi.mode

No need for extra bits or attributes on the esa.plot function, just
register a method for "esa" generic, "plot" class to prevent S3
dispatch from reaching the function in question.

--
Best regards,
Ivan

[[alternative HTML version deleted]]

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

[R-pkg-devel] Pre-test failure with RcppParallel on Windows R-devel

[Murray Efford via R-package-devel]

Submitting secr 5.2.0 I get this pre-test installation ERROR which is opaque to 
me. I haven't changed the relevant code, and the package passes checks on 
Winbuilder (below) and other systems (with a false positive URL fail NOTE).

* checking whether package 'secr' can be installed ... ERROR Installation 
failed. See 'd:/RCompile/CRANincoming/R-devel/secr.Rcheck/00install.out' for 
details.
which includes
undefined reference to `RcppParallel::tbbParallelFor(unsigned long long, 
unsigned long long, RcppParallel::Worker&, unsigned long long, int)'

Winbuilder and the CRAN precheck appear to use identical settings:

* using log directory 'd:/RCompile/CRANguest/R-devel/secr.Rcheck'
* using R Under development (unstable) (2025-01-22 r87618 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 13.3.0
GNU Fortran (GCC) 13.3.0
* running under: Windows Server 2022 x64 (build 20348)

Any ideas? I'm guessing it's a transient CRAN problem.




[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Pre-test failure with RcppParallel on Windows R-devel

[Murray Efford via R-package-devel]

Yes, that fixed it. My package was quickly re-tested and is now on CRAN. Thanks 
to all.
Murray

From: Kevin Ushey 
Sent: Friday, 24 January 2025 15:10
To: Murray Efford 
Cc: R-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Pre-test failure with RcppParallel on Windows R-devel

Hi Murray,

(repeating some of the conversation we had off-list)

Sorry for the trouble -- I was just in the process of submitting
RcppParallel to CRAN, and the first submission I made had this same
issue. That should now be fixed up with RcppParallel 5.1.10, which is
now on CRAN. Hopefully your next submission should go smoothly.

Thanks,
Kevin

On Thu, Jan 23, 2025 at 5:14 PM Murray Efford via R-package-devel
 wrote:
>
> Submitting secr 5.2.0 I get this pre-test installation ERROR which is opaque 
> to me. I haven't changed the relevant code, and the package passes checks on 
> Winbuilder (below) and other systems (with a false positive URL fail NOTE).
>
> * checking whether package 'secr' can be installed ... ERROR Installation 
> failed. See 'd:/RCompile/CRANincoming/R-devel/secr.Rcheck/00install.out' for 
> details.
> which includes
> undefined reference to `RcppParallel::tbbParallelFor(unsigned long long, 
> unsigned long long, RcppParallel::Worker&, unsigned long long, int)'
>
> Winbuilder and the CRAN precheck appear to use identical settings:
>
> * using log directory 'd:/RCompile/CRANguest/R-devel/secr.Rcheck'
> * using R Under development (unstable) (2025-01-22 r87618 ucrt)
> * using platform: x86_64-w64-mingw32
> * R was compiled by
> gcc.exe (GCC) 13.3.0
> GNU Fortran (GCC) 13.3.0
> * running under: Windows Server 2022 x64 (build 20348)
>
> Any ideas? I'm guessing it's a transient CRAN problem.
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C02%7Cmurray.efford%40otago.ac.nz%7Cec031787d425485d25ad08dd3c1c6162%7C0225efc578fe4928b1579ef24809e9ba%7C0%7C0%7C638732814784925323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wtlopPdXVxrQorfWcztJkHz%2BRCuMpZ7o5zIRZ8Zj3G8%3D&reserved=0<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-pkg-devel] Check time > 10min

[Murray Efford via R-package-devel]

My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0) because 
total check time exceeds 10 min (it's 760 seconds or 13 min). I can't see how 
to fix this as none of the times listed in the log 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log
 seems exceptional:
* checking CRAN incoming feasibility ... [18s] OK
* checking R code for possible problems ... [116s] OK
* checking examples ... [87s] OK
* checking tests ... [59s] OK
* checking re-building of vignette outputs ... [42s] OK
* checking PDF version of manual ... [32s] OK
* checking HTML version of manual ... [42s] OK
and the total of these components is only 396 sec (6.6 min), so I must be 
missing something. I would appreciate any advice.  Not much was added in this 
release, and I don't like the idea of blindly hacking off bits.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Check time > 10min

[Murray Efford via R-package-devel]

On the face of it,  I would need to throw out all the examples, and all the 
tests. That can't be right. Am I wrong to take the times in the log at face 
value? Where did the other 6 minutes go? Please excuse my obtuseness.

From: Dirk Eddelbuettel 
Sent: Tuesday, 3 June 2025 12:54
To: Murray Efford 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] Check time > 10min


On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
| My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0) 
because total check time exceeds 10 min (it's 760 seconds or 13 min). I can't 
see how to fix this as none of the times listed in the log 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log<https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log>
 seems exceptional:
| * checking CRAN incoming feasibility ... [18s] OK
| * checking R code for possible problems ... [116s] OK
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
| * checking re-building of vignette outputs ... [42s] OK
| * checking PDF version of manual ... [32s] OK
| * checking HTML version of manual ... [42s] OK
| and the total of these components is only 396 sec (6.6 min), so I must be 
missing something. I would appreciate any advice.  Not much was added in this 
release, and I don't like the idea of blindly hacking off bits.

To a first approximation every tests is a function of some variable we can
describe as 'N' which you, as author of the package and the tests, understand
best.

Surely you must know a way to define a new N1 <- N/2, or some other
appropriate scaling. Then try running with N1 instead. And you can also make
both tests and examples _conditional_ on some other control variable.

It's all just code. Bend it like Beckham.

Dirk

|
|[[alternative HTML version deleted]]
|
| __
| R-package-devel@r-project.org mailing list
| 
https://stat.ethz.ch/mailman/listinfo/r-package-devel<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Check time > 10min

[Murray Efford via R-package-devel]

Yes, that run is the problem. There is an attachment from CRAN-pretest with 
this NOTE that I take to be the issue:

Flavor: r-devel-windows-x86_64
Check: *, Result: NA

Flavor: r-devel-windows-x86_64
Check: Overall checktime, Result: NOTE
Overall checktime 13 min > 10 min

Flavor: r-devel-linux-x86_64-debian-gcc
Check: *, Result: OK


From: Greg Hunt 
Sent: Tuesday, 3 June 2025 13:45
To: Murray Efford 
Cc: Dirk Eddelbuettel ; R Package Development 

Subject: Re: [R-pkg-devel] Check time > 10min

That log ends with status OK, so is that the run that had the problem?  Isn't 
that time exceeded message in the log somewhere?

On Tue, 3 Jun 2025 at 11:41, Murray Efford via R-package-devel 
mailto:r-package-devel@r-project.org>> wrote:
On the face of it,  I would need to throw out all the examples, and all the 
tests. That can't be right. Am I wrong to take the times in the log at face 
value? Where did the other 6 minutes go? Please excuse my obtuseness.

From: Dirk Eddelbuettel mailto:e...@debian.org>>
Sent: Tuesday, 3 June 2025 12:54
To: Murray Efford mailto:murray.eff...@otago.ac.nz>>
Cc: R Package Development 
mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] Check time > 10min


On 3 June 2025 at 00:12, Murray Efford via R-package-devel wrote:
| My revision of package 'secr' fails CRAN pre-test on Windows (R 4.5.0) 
because total check time exceeds 10 min (it's 760 seconds or 13 min). I can't 
see how to fix this as none of the times listed in the log 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log<https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log>
 seems exceptional:
| * checking CRAN incoming feasibility ... [18s] OK
| * checking R code for possible problems ... [116s] OK
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
| * checking re-building of vignette outputs ... [42s] OK
| * checking PDF version of manual ... [32s] OK
| * checking HTML version of manual ... [42s] OK
| and the total of these components is only 396 sec (6.6 min), so I must be 
missing something. I would appreciate any advice.  Not much was added in this 
release, and I don't like the idea of blindly hacking off bits.

To a first approximation every tests is a function of some variable we can
describe as 'N' which you, as author of the package and the tests, understand
best.

Surely you must know a way to define a new N1 <- N/2, or some other
appropriate scaling. Then try running with N1 instead. And you can also make
both tests and examples _conditional_ on some other control variable.

It's all just code. Bend it like Beckham.

Dirk

|
|[[alternative HTML version deleted]]
|
| __
| R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing 
list
| 
https://stat.ethz.ch/mailman/listinfo/r-package-devel<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

--
dirk.eddelbuettel.com<http://dirk.eddelbuettel.com/> | @eddelbuettel | 
e...@debian.org<mailto:e...@debian.org>

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Check time > 10min

[Murray Efford via R-package-devel]

Thanks to Dirk, Greg and Seb for grappling with this. The comments give me 
confidence to appeal to CRAN to wave this through as it stands - I think Uwe 
has obliged in the past, but I would rather not rely on that. More complete 
reporting of check times would be welcome.
Murray

From: Dirk Eddelbuettel 
Sent: Wednesday, 4 June 2025 02:33
To: Greg Hunt 
Cc: Dirk Eddelbuettel ; Murray Efford 
; R Package Development 

Subject: Re: [R-pkg-devel] Check time > 10min


Greg,

On 4 June 2025 at 00:19, Greg Hunt wrote:
| In the original email, there was this:
|
| * checking examples ... [87s] OK
| * checking tests ... [59s] OK
|
| Am I interpreting it wrong or are these numbers the elapsed times for checking
| examples and tests?

If you follow the URL from the original post [1] you will see that it links
to a (Windows) check result ending in 'Status: OK'. No issue here.

Murray's original post also said '[it[ fails CRAN pre-test on Windows (R
4.5.0) because total check time exceeds 10 min (it's 760 seconds or 13 min)'.

So we are talking about two different checks.  As Seb alluded to, it is
unfortunate that the (failing) pre-check test does not give timings (whereas
the one you refer to does, but it did not fail).  Hth, and feel free to hit
me up off list with follow-ups as we may have gone on long enough on list.

Cheers, Dirk

[1] 
https://win-builder.r-project.org/incoming_pretest/secr_5.2.2_20250602_054847/Windows/00check.log

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

[[alternative HTML version deleted]]

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