Re: [Rd] NextMethod() and argument laziness
On 8/7/19 3:10 PM, Davis Vaughan wrote: Hi all, I'd like to ask if the following behavior is a bug. To me it certainly feels surprising, at the very least. In this example, I would like to call NextMethod() from my `child` object, have `cols` be left untouched, and then substitute(cols) in the parent method. It works when you use a `parent` object (as expected), but I would have also expected to get `mpg` back when calling it from the `child` method. my_generic <- function(x, cols) { UseMethod("my_generic") } my_generic.parent <- function(x, cols) { substitute(cols) } my_generic.child <- function(x, cols) { NextMethod() } obj_parent <- structure(mtcars, class = c("parent", class(mtcars))) obj_child <- structure(obj_parent, class = c("child", class(obj_parent))) my_generic(obj_parent, mpg) #> mpg my_generic(obj_child, mpg) #> cols This works as documented, see ?NextMethod: "the arguments will be the same in number, order and name as those to the current method but their values will be promises to evaluate their name in the current method and environment" Hence NextMethod needs to create a promise with a name matching the formal argument name of the function from which NextMethod is invoked. Note this is not the same as with UseMethod, and this is also why substitute() works differently with UseMethod. Best Tomas Thanks, Davis [[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] Underscores in package names
To throw a very small pennyworth into this debate, the metRology package I maintain uses mixed case to highlight R for that community when I'm talking about, or citing it. R takeup in that community is not yet high and the visible reminder seems to help. I'll obviously accept a consensus decision for some other case convention taken on sound technical grounds, but if this is essentially an aesthetic matter I'd prefer not to change it for someone else's idea of what looks pretty and what doesn’t. Steve Ellison > -Original Message- > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of neonira > Arinoem > Sent: 09 August 2019 20:39 > To: Ben Bolker > Cc: r-devel@r-project.org > Subject: Re: [Rd] Underscores in package names > > > Naming policies are always tricky. The one proposed by Hadley, as the one > proposed by Google, are usable but not optimal according to most common > needs, that are > > 1. Name a package > 2. Name a class > 3. Name a function > 4. Name a parameter of a function > 5. Name a variable > > ... *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MacOS parallel::makeCluster fails
For reference, in the end it turned out to be caused by that "localhost" could not be resolved. Thanks to Dominik for the report and debugging of the problem. To be robust against such problems in the future, R now falls back to the loopback device for localhost. Best Tomas On 7/12/19 11:22 AM, Dominik Leutnant wrote: Hi Thomas, thanks for your reply (and thanks for your patience...). I am now using the following minimal reprex: library(parallel) cl <- makeCluster(2L) I freshly started the machine and did not open any other app. Just R.app (3.6.1). After executing the second line of code, R seems to hang infinitely and does not respond. The R process itself uses almost no CPU. Unfortunately, I do not have any experience with neither "Sock_listen" nor "dtruss". Is there an example somewhere available? Best Dominik Am 05.06.19, 10:18 schrieb "Tomas Kalibera" : Hi Dominik, from the output, the master process could not "listen" on the port where it expects a connection from the worker. We need to find out why. I'd recommend first to create a minimal reproducible example (and one that does not use future, only parallel, and a minimal number of threads, ideally just 2). Then I'd recommend to check if the problem still exists with R-devel. Then I'd check if the problem happens in all invocations, even after reboots, on a clean system, without many running applications - if it does, this is good news. Then you could post such example and we could help more - if we can reproduce on our system indeed we could debug, if not there could at least be more directed advice on how to debug on your side. What I'd do myself if I could reproduce on my system would be instrument R around Sock_listen in internet module to see exactly what has failed with which error. Maybe dtruss would help too, but instrumenting may be easier. The earlier problem you mention has never been diagnosed (it was only intermittent on the reporter's machine, we could not reproduce on our systems, and despite a lot of effort on our side and on the reporter's, we could not reliably diagnose). In principle, it could be some race condition in R (one has been fixed since the previous report), but especially if it is deterministic it would more likely be some OS limit on your system. You could of course try playing with OS limits, on the number of open files, etc, with changing the port number (port= option), etc, but I would recommend the systematic approach of debugging the cause. Best Tomas On 6/4/19 10:45 AM, Dominik Leutnant wrote: > Hi all, > > The call parallel::makeCluster(1L) hangs infinitely on my MacOS machine which seems to be already reported by some people (e.g., https://stat.ethz.ch/pipermail/r-devel/2018-February/075565.html). > However, the solutions posted on SO, GH or R-devel do not work in my case. > > So far, I unsuccessfully tested … > >1. Couple of reboots >2. Adding 192.0.0.1 to /etc/hosts >3. Using R.app instead of RStudio.app >4. Turn off the firewall > > Following Hendriks advice, “cl <- future::makeClusterPSOCK(1L, verbose = TRUE, timeout = 60)” gives (note: without adding the timeout parameter, R just hangs): >> Sys.setenv(LANGUAGE='en') >> cl <- future::makeClusterPSOCK(1L, verbose = TRUE, timeout = 60) > [local output] Workers: [n = 1] ‘localhost’ > [local output] Base port: 11867 > [local output] Creating node 1 of 1 ... > [local output] - setting up node > Testing if worker's PID can be inferred: ‘'/Library/Frameworks/R.framework/Resources/bin/Rscript' -e 'try(cat(Sys.getpid(),file="/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid"), silent = TRUE)' -e "file.exists('/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid')"’ > - Possible to infer worker's PID: TRUE > [local output] Starting worker #1 on ‘localhost’: '/Library/Frameworks/R.framework/Resources/bin/Rscript' --default-packages=datasets,utils,grDevices,graphics,stats,methods -e 'try(cat(Sys.getpid(),file="/var/folders/5s/kgm05t2s0_52gz1s445mnlgwgn/T//RtmpZp1RX6/future.parent=835.3434fe0c5c6.pid"), silent = TRUE)' -e 'parallel:::.slaveRSOCK()' MASTER=localhost PORT=11867 OUT=/dev/null TIMEOUT=60 XDR=TRUE > [local output] - Exit code of system() call: 0 > [local output] Waiting for worker #1 on ‘localhost’ to connect back > [local output] Detected a warning from socketConnection(): ‘problem in listening on this socket’ > Killing worker process (PID 903) if still alive > Worker (PID 903) was successfully killed: TRUE > Error in socketConnection("localhost", port = port, server = TRUE, blocking = TRUE, : >Failed to laun
[Rd] ALTREP package interaction with testthat
Hi I found a weird problem in testthat while working with an ALTREP package. The package name is AltWrapper. My ALTREP serialize function is called even when I'm trying to serialize a non-ALTREP object. Here is an example ``` context("altrep") length_func<-function(x){ return(length(x)) } setAltClass(className = "test", classType = "real") setAltMethod(className = "test", getLength = length_func) testData = runif(10) myAltrep = makeAltrep("test", testData) test_that("Auto serialize", { browser() A = 10 A_serialized=serialize(A,NULL) B = new.env() B_serialized=serialize(B,NULL) }) ``` There is nothing but two variables A and B in the test function. I use browser() to stop and debug the code. Here is the weird thing, my package function is called when I’m trying to serialize *A* and *B*: ``` Browse[1]> A = 10 Browse[1]> A_serialized=serialize(A,NULL) Browse[1]> B = new.env() Browse[1]> B_serialized=serialize(B,NULL) serializing data Auto serializing data [1] "Internal serialize altWrapper function" ``` The output indicates that my package function is called. The function is designed for an ALTREP object. Since *B* is not an ALTREP, I don’t understand why the ALTREP related function has been called. Also, variable A works find. It seems like R dispatches the serialize function according to the variable type, but I am not sure if there is any way to see the dispatching rules. Here are the things I have tried: 1. if I comment out the code that defines an ALTREP in my example, the bug will disappear, so it might relate to the implementation of ALTREP. 2. If I run the test script in the global environment, R wouldn’t call the internal function, it only happens when I call `devtools::test()`. I am stuck here. I do not know if it is a bug of my package or testthat or the ALTREP implementation of R or possibly the interaction between them. I will appreciate if anyone can shed light on it. Here is the link to my package test file: https://github.com/Jiefei-Wang/AltWrapper/blob/master/tests/testthat/test_test.R Best, Jiefei [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ALTREP package interaction with testthat
On 12 August 2019 at 12:56, Wang Jiefei wrote: | I am stuck here. I do not know if it is a bug of my package or testthat or | the ALTREP implementation of R or possibly the interaction between them. I don't have any concrete advice for your issue here but when I find myself in similar debugging situations involving four or more moving parts, I usually try to remove one or two. Once I am down to 'just base R and my package' it tends to become much clearer where the issue is. _Narrator: Base R usually wins._ Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel