[Rd] 2 questions about signal & broken connection in R
Hi, all, I have 2 questions about signal handling in R. Would you pls help give me some suggestions? Many thanks! [How to block the signal in one R function]: If one R function hopes to be running without interrupting, how can we avoid this? To be more specific, for one R function "func1", it will do a loop to send messages to another R process, and receive responses from peers. How can we avoid users interrupt this function by pressing "Ctrl+C", so that it can finish normally, without messing up the message protocol? Are there any way to block signal handling within the function? [why writing to one broken connection for the 3rd time will hang, instead of getting exceptions]: Such as, there is one broken socket connection (in blocking mode), which is closed by peer by calling "close(conn)". The 1st write will return. The 2nd write will get an exception. The 3rd write will hang there forever. How can users always get an exception or other error messages when writing to a broken connection, instead of possibly hanging there? > writeBin(as.integer(1), con, endian="big"); > writeBin(as.integer(1), con, endian="big"); Error in writeBin(as.integer(1), con, endian = "big") : ignoring SIGPIPE signal > writeBin(as.integer(1), con, endian="big"); - hanging = Rong "Jessica", Li Platform Symphony TET, CSTL, IBM Systems &Technology Group, Development Tel:86-10-82451010 Email:rong...@cn.ibm.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 2 questions about signal & broken connection in R
You seem to be assuming that Ctrl-C is the way to interrupt an R session and that it sends a signal. Neither are true, in general, nor is there a general way to turn off interruptibility from the R console. You have not followed the posting guide and it may be that you are only interested in some particular R setup -- which you did not tell us about. If you want to run code so that it is not interruptible from a console, do not run it from a console On 14/08/2013 11:30, Rong lI Li wrote: Hi, all, I have 2 questions about signal handling in R. Would you pls help give me some suggestions? Many thanks! [How to block the signal in one R function]: If one R function hopes to be running without interrupting, how can we avoid this? To be more specific, for one R function "func1", it will do a loop to send messages to another R process, and receive responses from peers. How can we avoid users interrupt this function by pressing "Ctrl+C", so that it can finish normally, without messing up the message protocol? Are there any way to block signal handling within the function? [why writing to one broken connection for the 3rd time will hang, instead of getting exceptions]: Such as, there is one broken socket connection (in blocking mode), which is closed by peer by calling "close(conn)". The 1st write will return. The 2nd write will get an exception. The 3rd write will hang there forever. How can users always get an exception or other error messages when writing to a broken connection, instead of possibly hanging there? writeBin(as.integer(1), con, endian="big"); writeBin(as.integer(1), con, endian="big"); Error in writeBin(as.integer(1), con, endian = "big") : ignoring SIGPIPE signal writeBin(as.integer(1), con, endian="big"); - hanging = Rong "Jessica", Li Platform Symphony TET, CSTL, IBM Systems &Technology Group, Development Tel:86-10-82451010 Email:rong...@cn.ibm.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readChar and blocking connections
If readChar() reads from a connection and the specified number of bytes are not all available, it returns with what it can find. That's as documented (further down the help page) and it's what the low-level recv() does. However, for a blocking connection, wouldn't it be more natural to retry until the requested data are available? -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistency between eval and withVisible (with patch)
R-team, The $value element of the return value of *withVisible* does not agree with the return value of *eval* when *withVisible* is passed a variable (symbol) containing an expression object or anonymous code/expressions which generates an expression object when evaluated (such as calls to *parse* or * expression*). I have attached a patch against the svn trunk which addresses this. Example (under devel r63577): > withVisible(parse(text="5+pi")) $value *expression(5+pi)* $visible [1] TRUE > eval(parse(text="5+pi")) *[1] 8.141593* With the attached patch this is no longer the case: > withVisible(parse(text="5+pi")) $value *[1] 8.141593* $visible [1] TRUE The patch changes only the withVisible function in eval.c. I'm happy to work with / at the direction of an R-core member to get the patch into an different form/coding style/fix strategy/etc if its current form is not acceptable. Thanks, ~G > sessionInfo() R Under development (unstable) (2013-08-14 r63577) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base -- Gabriel Becker Graduate Student Statistics Department University of California, Davis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] local variable assignment: first copies from higher frame?
hi all -- this might not be the correct list for this
question/discussion, though R-help didn't seem like the correct venue,
either, so...
i'm looking for just some extra clarification of how local variables
are defined/bound, beyond the simple cases given in the Language
document.
the particular instance is when there is variable assignment inside a function.
normally, this creates a local variable, but there appears to be an
additional preceding step that does a bit more: the local variable is
initialized to the value of any same-named variable bound in a
containing frame.
in a sense, the lexical scoping rule is first applied to acquire a
value, and this value is then applied to the new local variable, and
is then immediately changed by the assignment operation.
i only noticed this when assigning variables to entries within a
'list' structure, like so:
tempf <- function(x, local = TRUE)
{
executing_environment <- environment()
closure_environment <- parent.env(executing_environment)
print(executing_environment)
cat(str(mget("my_list", envir = executing_environment, inherits =
FALSE, ifnotfound = NA)[[1]]))
print(closure_environment)
cat(str(mget("my_list", envir = closure_environment, inherits =
FALSE, ifnotfound = NA)[[1]]))
if(local) {
my_list$x <- x
} else {
my_list$x <<- x
}
print(executing_environment)
cat(str(mget("my_list", envir = executing_environment, inherits =
FALSE, ifnotfound = NA)[[1]]))
print(closure_environment)
cat(str(mget("my_list", envir = closure_environment, inherits =
FALSE, ifnotfound = NA)[[1]]))
}
> my_list <- list(x = 1, y = 2)
> tempf(0, local = TRUE)
logi NA
List of 2
$ x: num 1
$ y: num 2
List of 2
$ x: num 0
$ y: num 2
List of 2
$ x: num 1
$ y: num 2
> tempf(0, local = FALSE)
logi NA
List of 2
$ x: num 1
$ y: num 2
logi NA
List of 2
$ x: num 0
$ y: num 2
what surprised me in the first "local = TRUE" case is that 'y' is
still 2 in the executing environment.
so, i think my question comes down to this: when a new local variable
is created in an assignment operation, is the full value of any
matching variable in a containing frame first copied to the new local
variable?
and if so, was this chosen as a strategy specifically to allow for
these sorts of "indexed" assignment operations? (where i'm assigning
to only a single location within the vector object)?
and finally, are the other entries in the vector fully copied over, or
are they treated as "promises" similar to formal parameters, albeit
now as single entries within a containing vector?
thanks for any help on digging down a bit on the implementation here!
-murat
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] local variable assignment: first copies from higher frame?
Not anything that complicated -- your answer is in the R language definition under 'Subset assignment' and the part in "Function calls" that describes assignment functions. Whenever a call is found on the left side of a `<-`, it is munged by sticking a "<-" on the function name and pulling out the first argument. So my_list$x <- x which is syntactically equivalent to `$`(my_list, x) <- x is effectively transformed into something like: my_list <- `$<-`(my_list, x, x) The function `$<-` gets its argument from wherever it is found, and returns a modified version. Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency between eval and withVisible (with patch)
On Aug 15, 2013, at 01:46 , Gabriel Becker wrote: > R-team, > > The $value element of the return value of *withVisible* does not agree with > the return value of *eval* when *withVisible* is passed a variable (symbol) > containing an expression object or anonymous code/expressions which > generates an expression object when evaluated (such as calls to *parse* or * > expression*). > > I have attached a patch against the svn trunk which addresses this. > > Example (under devel r63577): > >> withVisible(parse(text="5+pi")) > $value > *expression(5+pi)* > > $visible > [1] TRUE > >> eval(parse(text="5+pi")) > *[1] 8.141593* > I don't think that is a bug, it is by design. The comparison should be to what happens if you just type the expression at the prompt: > parse(text="5+pi") expression(5+pi) > With the attached patch this is no longer the case: ...so the patch introduces a bug since you can no longer withVisible() something that returns a language object. > >> withVisible(parse(text="5+pi")) > $value > *[1] 8.141593* > > $visible > [1] TRUE > > The patch changes only the withVisible function in eval.c. I'm happy to > work with / at the direction of an R-core member to get the patch into an > different form/coding style/fix strategy/etc if its current form is not > acceptable. > > Thanks, > ~G > >> sessionInfo() > R Under development (unstable) (2013-08-14 r63577) > Platform: x86_64-unknown-linux-gnu (64-bit) > > locale: > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > > > -- > Gabriel Becker > Graduate Student > Statistics Department > University of California, Davis > __ > 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 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] Inconsistency between eval and withVisible (with patch)
I agree that the present behavior of withVisible is the Right Thing, but the documentation is confusing. The documentation claims that withVisible "evaluates an expression." This may capture an inside view of how the .Internal function is implemented, but is nonsense from the R user's standpoint, where "expression" is a particular type of R object and "evaluate an expression" means to do something like eval(). Peter On Wed, Aug 14, 2013 at 11:04 PM, peter dalgaard wrote: > > On Aug 15, 2013, at 01:46 , Gabriel Becker wrote: > > > R-team, > > > > The $value element of the return value of *withVisible* does not agree > with > > the return value of *eval* when *withVisible* is passed a variable > (symbol) > > containing an expression object or anonymous code/expressions which > > generates an expression object when evaluated (such as calls to *parse* > or * > > expression*). > > > > I have attached a patch against the svn trunk which addresses this. > > > > Example (under devel r63577): > > > >> withVisible(parse(text="5+pi")) > > $value > > *expression(5+pi)* > > > > $visible > > [1] TRUE > > > >> eval(parse(text="5+pi")) > > *[1] 8.141593* > > > > I don't think that is a bug, it is by design. The comparison should be to > what happens if you just type the expression at the prompt: > > > parse(text="5+pi") > expression(5+pi) > > > > With the attached patch this is no longer the case: > > ...so the patch introduces a bug since you can no longer withVisible() > something that returns a language object. > > > > >> withVisible(parse(text="5+pi")) > > $value > > *[1] 8.141593* > > > > $visible > > [1] TRUE > > > > The patch changes only the withVisible function in eval.c. I'm happy to > > work with / at the direction of an R-core member to get the patch into an > > different form/coding style/fix strategy/etc if its current form is not > > acceptable. > > > > Thanks, > > ~G > > > >> sessionInfo() > > R Under development (unstable) (2013-08-14 r63577) > > Platform: x86_64-unknown-linux-gnu (64-bit) > > > > locale: > > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 > > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 > > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > > [9] LC_ADDRESS=C LC_TELEPHONE=C > > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > > > > > -- > > Gabriel Becker > > Graduate Student > > Statistics Department > > University of California, Davis > > __ > > 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 > Email: pd@cbs.dk Priv: pda...@gmail.com > > __ > 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
