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

2024-03-15 Thread Martin Maechler 
> 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

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

Re: [Rd] RSS Feed of NEWS needs a hand

2024-03-15 Thread Duncan Murdoch 
Usually the duplication happens because there's a small change between 
the entries, e.g. a spelling correction.  Other times it's not 
duplication, but a substantive change to the NEWS entry, so those really 
should be duplicated.


I can't spot a change in the example you gave, so it's probably a change 
to the white space.  The comparison code tries to ignore those changes, 
but it doesn't always get it right.


Sometime I should put the code on Github so others can fix bugs like 
this.  It's currently in a private SVN repository (and has been since I 
wrote it about 16 years ago).


Duncan Murdoch

On 15/03/2024 12:04 p.m., Lluís Revilla wrote:

Hi!

Thanks for this service! It is very helpful to know what is being developed.

I distribute the content to other venues and I noticed some times that the
updates are duplicated.
For example, the sentence "‘is.R()’ is deprecated as no other S dialect is
known to be in use (and this could only identify historical dialects, not
future ones)." is duplicated in different days:
Day 1:
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2024/03/07#n2024-03-07
Day 2:
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2024/03/09#n2024-03-09

I tried to look up how to avoid duplications with Blosxom
 but I didn't find a way.
It would be great if this could be further improved to avoid this
duplication.

Thanks!

Lluís

On Fri, 15 Mar 2024 at 13:50, Dirk Eddelbuettel  wrote:



Years ago Duncan set up a nightly job to feed RSS based off changes to
NEWS,
borrowing some setup parts from CRANberries as for example the RSS
'compiler'.

That job is currently showing the new \I{...} curly protection in an
unfavourable light. Copying from the RSS reader I had pointed at this since
the start [1], for today I see (indented by four spaces)

 CHANGES IN R-devel INSTALLATION on WINDOWS

 The makefiles and installer scripts for Windows have been tailored to
 \IRtools44, an update of the \IRtools43 toolchain. It is based on GCC
13
 and newer versions of \IMinGW-W64, \Ibinutils and libraries (targeting
 64-bit Intel CPUs). R-devel can no longer be built using \IRtools43
 without changes.

 \IRtools44 has experimental suport for 64-bit ARM (aarch64) CPUs via
LLVM
 17 toolchain using lld, clang/flang-new and libc++.

Can some kind soul put a filter over it to remove the \I ?

Thanks,  Dirk

[1] Feedly. Unless we set this up so early that I once used Google
Reader. It's been a while...

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

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



[[alternative HTML version deleted]]

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


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

Re: [Rd] RSS Feed of NEWS needs a hand

2024-03-15 Thread Lluís Revilla 
Hi!

Thanks for this service! It is very helpful to know what is being developed.

I distribute the content to other venues and I noticed some times that the
updates are duplicated.
For example, the sentence "‘is.R()’ is deprecated as no other S dialect is
known to be in use (and this could only identify historical dialects, not
future ones)." is duplicated in different days:
Day 1:
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2024/03/07#n2024-03-07
Day 2:
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2024/03/09#n2024-03-09

I tried to look up how to avoid duplications with Blosxom
 but I didn't find a way.
It would be great if this could be further improved to avoid this
duplication.

Thanks!

Lluís

On Fri, 15 Mar 2024 at 13:50, Dirk Eddelbuettel  wrote:

>
> Years ago Duncan set up a nightly job to feed RSS based off changes to
> NEWS,
> borrowing some setup parts from CRANberries as for example the RSS
> 'compiler'.
>
> That job is currently showing the new \I{...} curly protection in an
> unfavourable light. Copying from the RSS reader I had pointed at this since
> the start [1], for today I see (indented by four spaces)
>
> CHANGES IN R-devel INSTALLATION on WINDOWS
>
> The makefiles and installer scripts for Windows have been tailored to
> \IRtools44, an update of the \IRtools43 toolchain. It is based on GCC
> 13
> and newer versions of \IMinGW-W64, \Ibinutils and libraries (targeting
> 64-bit Intel CPUs). R-devel can no longer be built using \IRtools43
> without changes.
>
> \IRtools44 has experimental suport for 64-bit ARM (aarch64) CPUs via
> LLVM
> 17 toolchain using lld, clang/flang-new and libc++.
>
> Can some kind soul put a filter over it to remove the \I ?
>
> Thanks,  Dirk
>
> [1] Feedly. Unless we set this up so early that I once used Google
> Reader. It's been a while...
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Rd] RSS Feed of NEWS needs a hand

2024-03-15 Thread Dirk Eddelbuettel 


Years ago Duncan set up a nightly job to feed RSS based off changes to NEWS,
borrowing some setup parts from CRANberries as for example the RSS 'compiler'.

That job is currently showing the new \I{...} curly protection in an
unfavourable light. Copying from the RSS reader I had pointed at this since
the start [1], for today I see (indented by four spaces)

CHANGES IN R-devel INSTALLATION on WINDOWS

The makefiles and installer scripts for Windows have been tailored to
\IRtools44, an update of the \IRtools43 toolchain. It is based on GCC 13
and newer versions of \IMinGW-W64, \Ibinutils and libraries (targeting
64-bit Intel CPUs). R-devel can no longer be built using \IRtools43
without changes. 

\IRtools44 has experimental suport for 64-bit ARM (aarch64) CPUs via LLVM
17 toolchain using lld, clang/flang-new and libc++. 

Can some kind soul put a filter over it to remove the \I ?

Thanks,  Dirk

[1] Feedly. Unless we set this up so early that I once used Google
Reader. It's been a while...

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

__
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-15 Thread Martin Maechler 
> 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!

Martin

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