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
