[Rd] R 4.4.0 scheduled for April 24

2024-03-18 Thread Peter Dalgaard via R-devel
Full schedule is available on developer.r-project.org (pending update from SVN).

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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


Re: [Rd] Spurious warning in as.data.frame.factor()

2024-03-18 Thread Hervé Pagès
Thanks Martin. We'll update the BioC builders to the latest R devel soon.

Cheers,

H.

On 3/15/24 10:26, Martin Maechler wrote:
>> Martin Maechler
>>  on Fri, 15 Mar 2024 11:24:22 +0100 writes:
>> Ivan Krylov
>>  on Thu, 14 Mar 2024 14:17:38 +0300 writes:
>  >> On Thu, 14 Mar 2024 10:41:54 +0100
>  >> Martin Maechler  wrote:
>
>  >>> Anybody trying S7 examples and see if they work w/o producing
>  >>> wrong warnings?
>
>  >> It looks like this is not applicable to S7. If I overwrite
>  >> as.data.frame with a newly created S7 generic, it fails to dispatch on
>  >> existing S3 classes:
>
>  >> new_generic('as.data.frame', 'x')(factor(1))
>  >> # Error: Can't find method for `as.data.frame(S3)`.
>
>  >> But there is no need to overwrite the generic, because S7 classes
>  >> should work with existing S3 generics:
>
>  >> foo <- new_class('foo', parent = class_double)
>  >> method(as.data.frame, foo) <- function(x) structure(
>  >> # this is probably not generally correct
>  >> list(x),
>  >> names = deparse1(substitute(x)),
>  >> row.names = seq_len(length(x)),
>  >> class = 'data.frame'
>  >> )
>  >> str(as.data.frame(foo(pi)))
>  >> # 'data.frame':   1 obs. of  1 variable:
>  >> #  $ x:  num 3.14
>
>  >> So I think that is nothing to break because S7 methods for
>  >> as.data.frame will rely on S3 for dispatch.
>
>  > Yes, as it should be.  Thank you for checking..
>
>
>  >>> > The patch passes make check-devel, but I'm not sure how to safely
>  >>> > put setGeneric('as.data.frame'); as.data.frame(factor(1:10)) in a
>  >>> > regression test.
>  >>>
>  >>> {What's the danger/problem?  we do have "similar" tests in both
>  >>> src/library/methods/tests/*.R
>  >>> tests/reg-S4.R
>  >>>
>  >>> -- maybe we can discuss bi-laterally  (or here, as you prefer)
>  >>> }
>
>  >> This might be educational for other people wanting to add a regression
>  >> test to their patch. I see that tests/reg-tests-1e.R is already 
> running
>  >> under options(warn = 2), so if I add the following near line 750
>  >> ("Deprecation of *direct* calls to as.data.frame.")...
>
>  >> # Should not warn for a call from a derivedDefaultMethod to the raw
>  >> # S3 method -- implementation detail of S4 dispatch
>  >> setGeneric('as.data.frame')
>  >> as.data.frame(factor(1))
>
>  >> ...then as.data.frame will remain an S4 generic. Should the test then
>  >> rm(as.data.frame) and keep going? (Or even keep the S4 generic?) Is
>  >> there any hidden state I may be breaking for the rest of the test this
>  >> way?
>  >> The test does pass like this, so this may be worrying about nothing.
>
>  > Indeed, this could be educational;  I think just adding
>
>  > removeGeneric('as.data.frame')
>
>  > is appropriate here as it is self-explaining and should not leave
>  > much traces.
>
>  > I'm about to test this in reg-tests-1e.R and with make check-all
>  > and commit later today,
>  > thanking you, Ivan!
>
> This has been committed to R-devel svn rev 86139 now.
>
> So these spurious warnings in situations where  as.data.frame()
> is an S4 generic --- notably for the many Bioconductor package
> depending on {BiocGenerics} ---  should disappear within 24
> hours or less.
>
> Martin

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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