Re: [Rd] Difference in NA behavior in R-devel running under valgrind
Forgot to mention, my builds were not instrumented for valgrind, and also: vagrant@vagrant:/vagrant/trunk$ ./bin/R --version R Under development (unstable) (2021-04-27 r80232) -- "Unsuffered Consequences" Copyright (C) 2021 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) On Thursday, April 29, 2021, 8:40:21 PM EDT, brodie gaslam via R-devel wrote: > On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang > wrote: > Just to be clear, the RD binary that Jon used was NOT compiled with > Valgrind level 2 instrumentation. In his example, however, he did run it > with valgrind, as in: > > # RD -d valgrind --quiet -e "sum(c(1, NA))" > ... > > sum(c(1, NA)) > [1] NaN > > `RD` in that Docker image is a standard build of R-devel. The Docker > image does include a build of R-devel with valgrind level 2 > instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior > when run with `-d valgrind`, but when run without `-d valgrind` it > returns NA. > > # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))" > > sum(c(1, NA)) > [1] NaN > > # RDvalgrind --quiet -e "sum(c(1, NA))" > > sum(c(1, NA)) > [1] NA > > In short `RDvalgrind` behaves the same as `RD`. However, adding `-d > valgrind` to either one causes it to return NaN. > > -Winston Thanks for the clarification. Using the same revision in the e-mail I get the reported issue under -O0, but not under -O2. It looks like r-debug builds with -O0, and presumably the release debian version is -O2 which is usually the default? I'm certainly no expert in this area but it seems like it could be an optimization level rather than a release vs devel issue? This is what I see: gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04) CC="gcc-10" CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99" vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))" ==9020== Memcheck, a memory error detector ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA)) ==9020== > sum(c(1,NA)) [1] NaN And then: CC="gcc-10" CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99" vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))" ==32751== Memcheck, a memory error detector ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA)) ==32751== > sum(c(1,NA)) [1] NA Sadly I did not think to run the -O0 version without valgrind. Best, B. __ 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] Difference in NA behavior in R-devel running under valgrind
> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang > wrote: > Just to be clear, the RD binary that Jon used was NOT compiled with > Valgrind level 2 instrumentation. In his example, however, he did run it > with valgrind, as in: > > # RD -d valgrind --quiet -e "sum(c(1, NA))" > ... > > sum(c(1, NA)) > [1] NaN > > `RD` in that Docker image is a standard build of R-devel. The Docker > image does include a build of R-devel with valgrind level 2 > instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior > when run with `-d valgrind`, but when run without `-d valgrind` it > returns NA. > > # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))" > > sum(c(1, NA)) > [1] NaN > > # RDvalgrind --quiet -e "sum(c(1, NA))" > > sum(c(1, NA)) > [1] NA > > In short `RDvalgrind` behaves the same as `RD`. However, adding `-d > valgrind` to either one causes it to return NaN. > > -Winston Thanks for the clarification. Using the same revision in the e-mail I get the reported issue under -O0, but not under -O2. It looks like r-debug builds with -O0, and presumably the release debian version is -O2 which is usually the default? I'm certainly no expert in this area but it seems like it could be an optimization level rather than a release vs devel issue? This is what I see: gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04) CC="gcc-10" CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99" vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))" ==9020== Memcheck, a memory error detector ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA)) ==9020== > sum(c(1,NA)) [1] NaN And then: CC="gcc-10" CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99" vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))" ==32751== Memcheck, a memory error detector ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA)) ==32751== > sum(c(1,NA)) [1] NA Sadly I did not think to run the -O0 version without valgrind. Best, B. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Difference in NA behavior in R-devel running under valgrind
Just to be clear, the RD binary that Jon used was NOT compiled with Valgrind level 2 instrumentation. In his example, however, he did run it with valgrind, as in: # RD -d valgrind --quiet -e "sum(c(1, NA))" ... > sum(c(1, NA)) [1] NaN `RD` in that Docker image is a standard build of R-devel. The Docker image does include a build of R-devel with valgrind level 2 instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior when run with `-d valgrind`, but when run without `-d valgrind` it returns NA. # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))" > sum(c(1, NA)) [1] NaN # RDvalgrind --quiet -e "sum(c(1, NA))" > sum(c(1, NA)) [1] NA In short `RDvalgrind` behaves the same as `RD`. However, adding `-d valgrind` to either one causes it to return NaN. -Winston On Thu, Apr 29, 2021 at 5:27 PM brodie gaslam via R-devel < r-devel@r-project.org> wrote: > NA propagation is complicated. I don't know whether what > you observe could be explained by the difference between > a valgrind instrumented vs. not version of R (I gather the > release version you used is not instrumented / possibly > compiled differently too from the github issue?). > > Hopefully someone more knowledgeable would chime in, but > I did want to share Tomas's post that touches on the > complexity of NA_real_ propagation: > > > https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/#nanan-payload-propagation > > Best, > > B. > > > > > > > On Thursday, April 29, 2021, 6:04:38 PM EDT, Jonathan Keane < > jke...@gmail.com> wrote: > > > > > > Hello, > > I'm debugging some valgrind issues, and noticed some odd behavior with > NA an R-devel under valgrind. > > Using Winston Chang's r-debug image (and some of this reproductions form > [1]): > > r-devel (2021-04-27 r80232) without Valgrind returns NA: > # RD --quiet -e "sum(c(1, NA))" > > sum(c(1, NA)) > [1] NA > > > r-devel with `-d valgrind` returns NaN: > # RD -d valgrind --quiet -e "sum(c(1, NA))" > ==8901== Memcheck, a memory error detector > ==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) > ==8901== > > sum(c(1, NA)) > [1] NaN > > > And finally release R (with valgrind) returns NA just like r-devel > while not under Valgrind: > # R -d valgrind --quiet -e "sum(c(1, NA))" > ==8983== Memcheck, a memory error detector > ==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info > ==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) > ==8983== > > sum(c(1, NA)) > [1] NA > > Thanks > > [1] - https://github.com/wch/r-debug/issues/18 > > -Jon > > __ > 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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Difference in NA behavior in R-devel running under valgrind
NA propagation is complicated. I don't know whether what you observe could be explained by the difference between a valgrind instrumented vs. not version of R (I gather the release version you used is not instrumented / possibly compiled differently too from the github issue?). Hopefully someone more knowledgeable would chime in, but I did want to share Tomas's post that touches on the complexity of NA_real_ propagation: https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/#nanan-payload-propagation Best, B. On Thursday, April 29, 2021, 6:04:38 PM EDT, Jonathan Keane wrote: Hello, I'm debugging some valgrind issues, and noticed some odd behavior with NA an R-devel under valgrind. Using Winston Chang's r-debug image (and some of this reproductions form [1]): r-devel (2021-04-27 r80232) without Valgrind returns NA: # RD --quiet -e "sum(c(1, NA))" > sum(c(1, NA)) [1] NA r-devel with `-d valgrind` returns NaN: # RD -d valgrind --quiet -e "sum(c(1, NA))" ==8901== Memcheck, a memory error detector ==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) ==8901== > sum(c(1, NA)) [1] NaN And finally release R (with valgrind) returns NA just like r-devel while not under Valgrind: # R -d valgrind --quiet -e "sum(c(1, NA))" ==8983== Memcheck, a memory error detector ==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) ==8983== > sum(c(1, NA)) [1] NA Thanks [1] - https://github.com/wch/r-debug/issues/18 -Jon __ 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
[Rd] Difference in NA behavior in R-devel running under valgrind
Hello, I'm debugging some valgrind issues, and noticed some odd behavior with NA an R-devel under valgrind. Using Winston Chang's r-debug image (and some of this reproductions form [1]): r-devel (2021-04-27 r80232) without Valgrind returns NA: # RD --quiet -e "sum(c(1, NA))" > sum(c(1, NA)) [1] NA r-devel with `-d valgrind` returns NaN: # RD -d valgrind --quiet -e "sum(c(1, NA))" ==8901== Memcheck, a memory error detector ==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) ==8901== > sum(c(1, NA)) [1] NaN And finally release R (with valgrind) returns NA just like r-devel while not under Valgrind: # R -d valgrind --quiet -e "sum(c(1, NA))" ==8983== Memcheck, a memory error detector ==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA)) ==8983== > sum(c(1, NA)) [1] NA Thanks [1] - https://github.com/wch/r-debug/issues/18 -Jon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R compilation on old(ish) CentOS
You may want to check out your checkout I see: Peter-Dalgaards-iMac:R pd$ grep newsock src/main/connections.c con = R_newsock(host, port, server, serverfd, open, timeout, options); but your file seems to have lost the ", options" bit somehow. Also, mine is line 3488, not 3477. Maybe you have an old file getting in the way? - Peter > On 29 Apr 2021, at 15:58 , Ben Bolker wrote: > > I probably don't want to go down this rabbit hole very far, but if anyone > has any *quick* ideas ... > > Attempting to build R from scratch with a fresh SVN checkout on a somewhat > out-of-date CentOS system (for which I don't have root access, although I can > bug people if I care enough). > > ../r-devel/configure; make > > ends with > > gcc -std=gnu99 -I../../../r-devel/trunk/src/extra -I. -I../../src/include > -I../../../r-devel/trunk/src/include -I/usr/local/include > -I../../../r-devel/trunk/src/nmath -DHAVE_CONFIG_H -fopenmp -g -O2 -c > ../../../r-devel/trunk/src/main/connections.c -o connections.o > ../../../r-devel/trunk/src/main/connections.c: In function ‘do_sockconn’: > ../../../r-devel/trunk/src/main/connections.c:3477:5: error: too few > arguments to function ‘R_newsock’ > con = R_newsock(host, port, server, serverfd, open, timeout); > ^ > In file included from ../../../r-devel/trunk/src/main/connections.c:80:0: > ../../../r-devel/trunk/src/include/Rconnections.h:83:13: note: declared here > Rconnection R_newsock(const char *host, int port, int server, int serverfd, > const char * const mode, int timeout, int options); > ^ > make[3]: *** [connections.o] Error 1 > > Any suggestions for a quick fix/diagnosis? > > cheers >Ben Bolker > > > > > $ gcc --version > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) > > $ lsb_release -a > LSB Version: > :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch > Distributor ID: CentOS > Description: CentOS Linux release 7.8.2003 (Core) > Release: 7.8.2003 > Codename: Core > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- 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] R compilation on old(ish) CentOS
On Thu, 29 Apr 2021 at 15:59, Ben Bolker wrote: > >I probably don't want to go down this rabbit hole very far, but if > anyone has any *quick* ideas ... > >Attempting to build R from scratch with a fresh SVN checkout on a > somewhat out-of-date CentOS system (for which I don't have root access, > although I can bug people if I care enough). Could you bug them to... update CentOS? :) [snip] > $ gcc --version > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) Ouch. You definitely need to install and activate an appropriate devtoolset as follows: $ yum install centos-release-scl $ yum install devtoolset-8 (Bug those people to at least install that). Then, put something like this in your .bashrc: $ source scl_source enable devtoolset-8 And you are ready to go with a fairly decent version of gcc, i.e.: $ gcc --version gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) Iñaki > $ lsb_release -a > LSB Version: > :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch > Distributor ID: CentOS > Description:CentOS Linux release 7.8.2003 (Core) > Release:7.8.2003 > Codename: Core > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R compilation on old(ish) CentOS
I probably don't want to go down this rabbit hole very far, but if anyone has any *quick* ideas ... Attempting to build R from scratch with a fresh SVN checkout on a somewhat out-of-date CentOS system (for which I don't have root access, although I can bug people if I care enough). ../r-devel/configure; make ends with gcc -std=gnu99 -I../../../r-devel/trunk/src/extra -I. -I../../src/include -I../../../r-devel/trunk/src/include -I/usr/local/include -I../../../r-devel/trunk/src/nmath -DHAVE_CONFIG_H -fopenmp -g -O2 -c ../../../r-devel/trunk/src/main/connections.c -o connections.o ../../../r-devel/trunk/src/main/connections.c: In function ‘do_sockconn’: ../../../r-devel/trunk/src/main/connections.c:3477:5: error: too few arguments to function ‘R_newsock’ con = R_newsock(host, port, server, serverfd, open, timeout); ^ In file included from ../../../r-devel/trunk/src/main/connections.c:80:0: ../../../r-devel/trunk/src/include/Rconnections.h:83:13: note: declared here Rconnection R_newsock(const char *host, int port, int server, int serverfd, const char * const mode, int timeout, int options); ^ make[3]: *** [connections.o] Error 1 Any suggestions for a quick fix/diagnosis? cheers Ben Bolker $ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) $ lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: CentOS Description:CentOS Linux release 7.8.2003 (Core) Release:7.8.2003 Codename: Core __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R does not start on Fedora 34
On Thu, 29 Apr 2021 at 14:36, Gábor Csárdi wrote:
>
> Dear all,
>
> Fedora 34 was released two days ago, and with a fresh build of R I get
>
> [root@2dba8b3587c1 R-devel]# bin/R
> ERROR: R_HOME ('/tmp/R-devel') not found
This is known. It's a docker issue after a glibc change. See [1] and
references therein. A newer version of docker/libseccomp should work.
[1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-March/000732.html
>
> on it, coming from
> https://github.com/wch/r-source/blob/0f0092adf14b8bd17bcce1cac0ee26b928355dab/src/scripts/R.sh.in#L263
>
> Apparently `test -x` returns 1 for an existing 755 directory on Fedora 34:
> ❯ docker run -ti fedora:latest
> [root@f944f25b16b4 /]# test -x /tmp/
> [root@f944f25b16b4 /]# echo $?
> 1
>
> On Fedora 33 this was different:
> ❯ docker run -ti fedora:33
> [root@ea55a1b92215 /]# test -x /tmp/
> [root@ea55a1b92215 /]# echo $?
> 0
>
> A workaround would be to use `test -d` which still return 0 on Fedora 34.
>
> FYI,
> Gabor
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Iñaki Úcar
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R does not start on Fedora 34
Dear all,
Fedora 34 was released two days ago, and with a fresh build of R I get
[root@2dba8b3587c1 R-devel]# bin/R
ERROR: R_HOME ('/tmp/R-devel') not found
on it, coming from
https://github.com/wch/r-source/blob/0f0092adf14b8bd17bcce1cac0ee26b928355dab/src/scripts/R.sh.in#L263
Apparently `test -x` returns 1 for an existing 755 directory on Fedora 34:
❯ docker run -ti fedora:latest
[root@f944f25b16b4 /]# test -x /tmp/
[root@f944f25b16b4 /]# echo $?
1
On Fedora 33 this was different:
❯ docker run -ti fedora:33
[root@ea55a1b92215 /]# test -x /tmp/
[root@ea55a1b92215 /]# echo $?
0
A workaround would be to use `test -d` which still return 0 on Fedora 34.
FYI,
Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help(".libPaths"): Paragraph lacks mentioning of R_LIBS_SITE
> Henrik Bengtsson writes: Thanks: Tomas and I have now improved this. Best -k > In ?base::.libPaths, there's a paragraph saying: > The library search path is initialized at startup from the environment > variable R_LIBS (which should be a colon-separated list of directories > at which R library trees are rooted) followed by those in environment > variable R_LIBS_USER. Only directories which exist at the time will be > included. > Shouldn't R_LIBS_SITE also be mentioned in that passage? Something like: > ...followed by those in environment variables R_LIBS_USER and R_LIBS_SITE. ... > /Henrik > __ > 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] as.list fails on functions with S3 classes
> brodie gaslam via R-devel
> on Thu, 29 Apr 2021 01:04:01 + (UTC) writes:
>> On Wednesday, April 28, 2021, 5:16:20 PM EDT, Gabriel Becker
wrote:
>>
>> Hi Antoine,
>>
>> I would say this is the correct behavior. S3 dispatch is solely (so far
as
>> I know?) concerned with the "actual classes" on the object. This is
because
>> S3 classes act as labels that inform dispatch what, and in what order,
>> methods should be applied. You took the function class (ie label) off of
>> your object, which means that in the S3 sense, that object is no longer a
>> function and dispatching to function methods for it would be incorrect.
>> This is independent of whether the object is still callable "as a
function".
>>
>> The analogous case for non-closures to what you are describing would be
for
>> S3 to check mode(x) after striking out with class(x) to find relevant
>> methods. I don't think that would be appropriate.
> I would think of the general case to be to check `class(unclass(x))` on
> strike-out. This would then include things such as "matrix", etc.
> Dispatching on the implicit class as fallback seems like a natural thing
> to do in a language that dispatches on implicit class when there is none.
> After all, once you've struck out of your explicit classes, you have
> none left!
> This does happen naturally in some places (e.g. interacting with a
> data.frame as a list), and is quite delightful (usually). I won't get
> into an argument of what the documentation states or whether any changes
> should be made, but to me that dispatch doesn't end with the implicit
> class seems feels like a logical wrinkle. Yes, I can twist my brain to
> see how it can be made to make sense, but I don't like it.
> A fun past conversation on this very topic:
> https://stat.ethz.ch/pipermail/r-devel/2019-March/077457.html
Thank you, Gabe and Brodie.
To the OP, Gabe's advice to *NOT* throw away an existing class
is really important, and good code -- several examples in base R --
would really *extend* a class in such cases, i.e.,
function(x, ...) {
..
ans <- things.on(x, .)
class(ans) <- c("foo", class(x)) #
ans
}
I don't have time to go in-depth here (teaching and other duties),
but I want to point you to one important extra point,
which I think you have not been aware:
S3 dispatch *does* look at what you see from class() *but* has
always done some extra things, notably for atomic and other
*base* objects. There's always been a dedicated function in R's C
code to do this, R_data_class2(), e.g., called from C
usemethod() called from R's UseMethod().
Since R 4.0.0, we have provided R function .class2() to give
the same result as the internal R_data_class2(), and hence
show the classes (in the correct order!) which are really for S3
dispatch.
The NEWS entry for that was
\item New function \code{.class2()} provides the full character
vector of class names used for S3 method dispatch.
Best,
Martin
> Best,
> B.
>> Also, as an aside, if you want your class to override methods that exist
>> for function you would want to set the class to c("foo", "function"), not
>> c("function", "foo"), as you had it in your example.
>>
>> Best,
>> ~G
>>
>> On Wed, Apr 28, 2021 at 1:45 PM Antoine Fabri
>> wrote:
>>
>>> Dear R devel,
>>>
>>> as.list() can be used on functions, but not if they have a S3 class that
>>> doesn't include "function".
>>>
>>> See below :
>>>
>>> ```r
>>> add1 <- function(x) x+1
>>>
>>> as.list(add1)
>>> #> $x
>>> #>
>>> #>
>>> #> [[2]]
>>> #> x + 1
>>>
>>> class(add1) <- c("function", "foo")
>>>
>>> as.list(add1)
>>> #> $x
>>> #>
>>> #>
>>> #> [[2]]
>>> #> x + 1
>>>
>>> class(add1) <- "foo"
>>>
>>> as.list(add1)
>>> #> Error in as.vector(x, "list"): cannot coerce type 'closure' to
vector of
>>> type 'list'
>>>
>>> as.list.function(add1)
>>> #> $x
>>> #>
>>> #>
>>> #> [[2]]
>>> #> x + 1
>>> ```
>>>
>>> In failing case the argument is dispatched to as.list.default instead of
>>> as.list.function.
>>>
>>> (1) Shouldn't it be dispatched to as.list.function ?
>>>
>>> (2) Shouldn't all generics when applied on an object of type closure
fall
>>> back to the `fun.function` method before falling back to the
`fun.default`
>>> method ?
>>>
>>> Best regards,
>>>
>>> Antoine
> __
> 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
