[Rd] Incorrect target file name for gramLatex.c
Hi! The attached patch changes the rule that describes the actions for gramLatex.c in src/library/tools/src/Makefile.in so it actually generates that file instead of "gramLatex." (no extension). The file name without extension is not referenced anywhere else and in R-2.12 the same rule still used the full name, so it appears that the "c" was lost in editing somewhere along the way. The patch was generated for R-3.0.1, but also applies cleanly to R-devel_2013-05-14. -ik diff --git a/src/library/tools/src/Makefile.in b/src/library/tools/src/Makefile.in index 76d5919..63bee32 100644 --- a/src/library/tools/src/Makefile.in +++ b/src/library/tools/src/Makefile.in @@ -64,6 +64,6 @@ $(srcdir)/gramRd.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/gramRd.y $(srcdir)/gramLatex.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/gramLatex.y @$(ECHO) "re-making gramLatex.c" $(YACC) $(YFLAGS) $(srcdir)/gramLatex.y - $(SHELL) $(top_srcdir)/tools/move-if-change y.tab.c $(srcdir)/gramLatex. + $(SHELL) $(top_srcdir)/tools/move-if-change y.tab.c $(srcdir)/gramLatex.c ## Automagically generated dependencies:__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect target file name for gramLatex.c
On 13-05-16 5:26 AM, Ingo Korb wrote: Hi! The attached patch changes the rule that describes the actions for gramLatex.c in src/library/tools/src/Makefile.in so it actually generates that file instead of "gramLatex." (no extension). The file name without extension is not referenced anywhere else and in R-2.12 the same rule still used the full name, so it appears that the "c" was lost in editing somewhere along the way. The patch was generated for R-3.0.1, but also applies cleanly to R-devel_2013-05-14. Thanks, I'll put your fix in. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect target file name for gramLatex.c
Thanks. Yes, that certainly looks like a copy/paste error when the gram* files was moved to tools. (I just wonder why we're not using $< $@ in these rules.) It should be harmless until someone tries actually modifying the grammar. (To avoid relying on yacc/bison, we ship the gram*.c along with gram*.y). -pd On May 16, 2013, at 11:26 , Ingo Korb wrote: > Hi! > > The attached patch changes the rule that describes the actions for > gramLatex.c in src/library/tools/src/Makefile.in so it actually > generates that file instead of "gramLatex." (no extension). The > file name without extension is not referenced anywhere else and > in R-2.12 the same rule still used the full name, so it appears > that the "c" was lost in editing somewhere along the way. > > The patch was generated for R-3.0.1, but also applies cleanly to > R-devel_2013-05-14. > > -ik > __ > 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
[Rd] tools to document ReferenceClasses
Dear all, Do anybody know whether tools have been developed to help writing suitable documentation for ReferenceClasses ? Given that in the ReferenceClasses is now possible to insert the documentation inside the method, I am wondering whether anybody have developed something similar to javadoc (i.e. an annotation convention + a tool to format it an produce a report). Thankyou very much, Best Regards, Andrea Franceschini -- Andrea Franceschini Swiss Institute of Bioinformatics ( http://www.isb-sib.ch ) andrea.francesch...@isb-sib.ch Tel: +41 44 6353148 Mobile: +41 78 6298386 Bioinformatics Group ( Prof. Von Mering), UZH Zurich [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)
Duncan, Thank you for the clarification on how delayedAssign works. Should
R-level interfaces to promise objects ever become available, I expect they
would at time come in handy.
On the subject of substitute and delayedAssign, I do have a follow-up question
for the list. I'm trying to convert a named list of expression objects into an
environment of promise objects. After conversion, each expression in the list
will be automatically evaluated when the variable with the same name is
accessed in the environment. Effectively, I'm trying to create a hash table of
promise objects.
Here's the code I wrote that works just fine.
x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()
for (i in seq(x)) {
key <- names(x)[i]
.Internal(delayedAssign(key,
eval(substitute(x[[i]], list(x=x,
i=i)))[[1]],
eval.env=env, assign.env=env))
}
env$b # 3+2
[1] 5
env$sleep # Sleeps for 2 seconds
NULL
The "problem" is that R CMD check complains that I shouldn't be using
.Internal() to access the delayedAssign function. However, if I don't use
.Internal(), then delayedAssign puts another substitute around my call that
prevents the 'i' iterator variable from being evaluated at the correct time,
which causes all variables to get the value x[[i]] for the very last value of
'i'.
Can I safely ignore this R CMD check warning about .Internal, or is there a
better way to write this code?
Thanks, Robert
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Wednesday, May 15, 2013 6:04 PM
To: McGehee, Robert
Cc: R-Devel (r-devel@r-project.org)
Subject: Re: [Rd] Substitute unaware when promise objects are evaluated
On 13-05-15 11:54 AM, McGehee, Robert wrote:
> R-devel,
> I used the 'substitute' function to create labels for objects inside an
> environment, without actually evaluating the objects, as the objects might be
> promises.
>
> However, I was surprised to see that 'substitute' returns the expression slot
> of the original promise even after the promise has been forcibly evaluated.
> (Doesn't the promise go away after evaluation?) This behavior probably falls
> under the "...no guarantee that the resulting expression makes any sense"
> clause of the ?substitute documentation, but in case there's something
> actually wrong here, I thought I'd send an example.
I think you misunderstand promises.
A promise has two (or three, depending how you count) parts: an
expression with an associated environment, and a value. The value isn't
filled in until the expression is evaluated, but the expression doesn't
go away then. You can still see it until you change the variable that
holds the promise.
> Here's an example showing how the evaluated expression returned by substitute
> does not match the actual variable value:
>
>> env <- new.env()
>> z <- 0
>> delayedAssign("var", z+2, assign.env=env)
>> substitute(var, env=env)
> z + 2
The documentation for substitute may not be clear on this, but for a
promise, the env argument will be ignored. It was the eval.env argument
to delayedAssign that set the promise's environment.
>> force(env$var)
> [1] 2
>> z <- 10
>> substitute(var, env=env)
> z + 2
>> eval(substitute(var, env=env))
> [1] 12
>> force(env$var)
> [1] 2
>
> Is there any obvious way to code around this behavior, e.g. can I explicitly
> check if an object in an environment is an unevaluated promise?
Not at R level. In C code you could, but you probably shouldn't. Think
of promises as values where you can look up the expression that gave the
value, and sometimes delay the calculation until you need it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)
On 16/05/2013 9:06 AM, McGehee, Robert wrote:
Duncan, Thank you for the clarification on how delayedAssign works. Should
R-level interfaces to promise objects ever become available, I expect they
would at time come in handy.
On the subject of substitute and delayedAssign, I do have a follow-up question
for the list. I'm trying to convert a named list of expression objects into an
environment of promise objects. After conversion, each expression in the list
will be automatically evaluated when the variable with the same name is
accessed in the environment. Effectively, I'm trying to create a hash table of
promise objects.
Here's the code I wrote that works just fine.
x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()
for (i in seq(x)) {
key <- names(x)[i]
.Internal(delayedAssign(key,
eval(substitute(x[[i]], list(x=x,
i=i)))[[1]],
eval.env=env, assign.env=env))
}
env$b # 3+2
[1] 5
env$sleep # Sleeps for 2 seconds
NULL
The "problem" is that R CMD check complains that I shouldn't be using
.Internal() to access the delayedAssign function. However, if I don't use .Internal(),
then delayedAssign puts another substitute around my call that prevents the 'i' iterator
variable from being evaluated at the correct time, which causes all variables to get the
value x[[i]] for the very last value of 'i'.
Can I safely ignore this R CMD check warning about .Internal, or is there a
better way to write this code?
You should never call .Internal. Arguments to internal functions may
change without notice.
Here's one way to write your example without it.
x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()
mydelay <- function(i) {
expr <- x[[i]]
name <- names(x)[i]
do.call(delayedAssign, list(x=name, value=substitute(eval(expr),
list(expr=expr)),
eval.env=env, assign.env=env))
}
for (i in seq(x)) mydelay(i)
Duncan Murdoch
Thanks, Robert
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Wednesday, May 15, 2013 6:04 PM
To: McGehee, Robert
Cc: R-Devel (r-devel@r-project.org)
Subject: Re: [Rd] Substitute unaware when promise objects are evaluated
On 13-05-15 11:54 AM, McGehee, Robert wrote:
> R-devel,
> I used the 'substitute' function to create labels for objects inside an
environment, without actually evaluating the objects, as the objects might be
promises.
>
> However, I was surprised to see that 'substitute' returns the expression slot of the
original promise even after the promise has been forcibly evaluated. (Doesn't the promise go
away after evaluation?) This behavior probably falls under the "...no guarantee that
the resulting expression makes any sense" clause of the ?substitute documentation, but
in case there's something actually wrong here, I thought I'd send an example.
I think you misunderstand promises.
A promise has two (or three, depending how you count) parts: an
expression with an associated environment, and a value. The value isn't
filled in until the expression is evaluated, but the expression doesn't
go away then. You can still see it until you change the variable that
holds the promise.
> Here's an example showing how the evaluated expression returned by substitute
does not match the actual variable value:
>
>> env <- new.env()
>> z <- 0
>> delayedAssign("var", z+2, assign.env=env)
>> substitute(var, env=env)
> z + 2
The documentation for substitute may not be clear on this, but for a
promise, the env argument will be ignored. It was the eval.env argument
to delayedAssign that set the promise's environment.
>> force(env$var)
> [1] 2
>> z <- 10
>> substitute(var, env=env)
> z + 2
>> eval(substitute(var, env=env))
> [1] 12
>> force(env$var)
> [1] 2
>
> Is there any obvious way to code around this behavior, e.g. can I explicitly
check if an object in an environment is an unevaluated promise?
Not at R level. In C code you could, but you probably shouldn't. Think
of promises as values where you can look up the expression that gave the
value, and sometimes delay the calculation until you need it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setTimeLimit sometimes fails to terminate idle call in R
I would like to use setTimeLimit to abort operations that are stuck
waiting (idle) after n seconds. Below a toy example in which Sys.sleep
is a placeholder call that is idle:
testlimit <- function(){
setTimeLimit(elapsed=3, transient=TRUE);
Sys.sleep(10);
}
system.time(testlimit());
However this is giving inconsistent results. On windows and in
r-studio server (linux) the call is correctly aborted after 3 seconds.
However, when I run this in a terminal session in either on linux or
osx, the timeout is not triggered until after Sys.sleep() returns and
the total script takes 10+ seconds to complete.
What causes this difference? Is there something I can set in my
terminal R session such that the time limit is triggered? I am using
Ubuntu 13.04 (x64), and osx 10.8. Below three videos to illustrate the
issue:
[1]: http://www.youtube.com/watch?v=d1qxbp2W2mY&hd=1
[2]: http://www.youtube.com/watch?v=S0r-O9er4kU&hd=1
[3]: http://www.youtube.com/watch?v=2D7TgtXUa3o&hd=1
> sessionInfo()
R version 3.0.1 RC (2013-05-10 r62729)
Platform: x86_64-pc-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=C 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setTimeLimit sometimes fails to terminate idle call in R
Jeroen,
On May 16, 2013, at 2:12 PM, Jeroen Ooms wrote:
> I would like to use setTimeLimit to abort operations that are stuck
> waiting (idle) after n seconds. Below a toy example in which Sys.sleep
> is a placeholder call that is idle:
>
> testlimit <- function(){
> setTimeLimit(elapsed=3, transient=TRUE);
> Sys.sleep(10);
> }
> system.time(testlimit());
>
> However this is giving inconsistent results. On windows and in
> r-studio server (linux) the call is correctly aborted after 3 seconds.
> However, when I run this in a terminal session in either on linux or
> osx, the timeout is not triggered until after Sys.sleep() returns and
> the total script takes 10+ seconds to complete.
>
> What causes this difference?
The time limit can only be checked in R_ProcessEvents() so for all practical
purposes it can be only triggered by interruptible code that calls
R_CheckUserInterrupt().
Now, it is entirely up to the front-end to decide how it will the the event
loop. For example the terminal version of R has no other interrupts to worry
about other than input handlers which trigger asynchronously, so it doesn't
need to do any polling. Sys.sleep() only triggers on input handlers, so if you
don't have any external event source hook as input handler, there is no reason
to process any events so Sys.sleep() won't see any reason to check the time
limit.
> Is there something I can set in my terminal R session such that the time
> limit is triggered?
On OS X it's actually very easy:
quartz(); dev.off()
will do the trick. The reason is that Quartz needs to force the event loop in
order to process events from the window asynchronously. It does so by
installing a timer-based input handler. This handler will make sure that
Sys.sleep() will wake up every 100ms (you can change the value using
QuartzCocoa_SetLatency) so it will timeout with that resolution:
> testlimit <- function(){
+ setTimeLimit(elapsed=3, transient=TRUE);
+ Sys.sleep(10);
+ }
> system.time(testlimit());
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0 0.001 10.001
> quartz(); dev.off()
null device
1
> testlimit <- function(){
+ setTimeLimit(elapsed=3, transient=TRUE);
+ Sys.sleep(10);
+ }
> system.time(testlimit());
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0.002 0.003 3.019
On Linux, there is no built-in timer, so you'd have to add an input handler
that will pre-empt Sys.sleep(). If you want a constant timer, you can simply
borrow the code from Quartz (have a look at QuartzCocoa_SetupEventLoop in
src/library/grDevices/src/qdCocoa.m) or the CarbonEL package. It's really just
a pipe that is added as an input handler into which you write asynchronously
when you want to wake up the event loop. On top of my head I can't think of a
built-in solution in R at this point (even though it could be argued that R
might install a handler itself when the limit is set ...).
But note that this is really just a special case of of Sys.sleep(). If you
actually run R code, then ProcessEvents is triggered automatically during the
evaluation (or in interruptible C code).
Cheers,
Simon
> I am using
> Ubuntu 13.04 (x64), and osx 10.8. Below three videos to illustrate the
> issue:
>
> [1]: http://www.youtube.com/watch?v=d1qxbp2W2mY&hd=1
> [2]: http://www.youtube.com/watch?v=S0r-O9er4kU&hd=1
> [3]: http://www.youtube.com/watch?v=2D7TgtXUa3o&hd=1
>
>> sessionInfo()
> R version 3.0.1 RC (2013-05-10 r62729)
> Platform: x86_64-pc-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=C 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
>
> __
> 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] setTimeLimit sometimes fails to terminate idle call in R
Thank you for the elaborate response. I am going to look into the quartz code.
> On top of my head I can't think of a built-in solution in R at this point
> (even though it could be argued that R might install a handler itself when
> the limit is set ...).
Yes, I think this would greatly enhance the usability of setTimeLimit.
> But note that this is really just a special case of of Sys.sleep(). If you
> actually run R code, then ProcessEvents is triggered automatically during the
> evaluation (or in interruptible C code).
Well, the main use case that I have in mind is where the process is
stuck waiting for some child process or socket. For example, I would
like to implement a timeout parameter for psockcluster nodes,
equivalent to mccollect timeout. Below a poc that I hacked together,
which works on windows, but not linux/osx for above reasons.
eval_psock <- function(expr, envir=parent.frame(), timeout=60){
#create a child process
cluster <- parallel::makePSOCKcluster(1);
child <- cluster[[1]];
parallel:::sendCall(child, eval, list(quote(Sys.getpid(;
pid <- parallel:::recvResult(child);
#set the timeout
setTimeLimit(elapsed=timeout, transient=TRUE);
on.exit({
setTimeLimit(cpu=Inf, elapsed=Inf, transient=FALSE);
tools::pskill(pid); #win
tools::pskill(pid, tools::SIGKILL); #nix
parallel:::stopNode(child);
});
#send the actual call
parallel:::sendCall(child, eval, list(expr=substitute(expr),
envir=as.list(envir)));
myresult <- parallel:::recvResult(child);
#reset timelimit
setTimeLimit(cpu=Inf, elapsed=Inf, transient=TRUE);
#forks don't throw errors themselves
if(is(myresult,"try-error")){
#snow only returns the message, not an error object
stop(myresult, call.=FALSE);
}
#send the buffered response
return(myresult);
}
test <- function(){
n <- 1e8;
k <- 1e4;
#this should take more than 10 sec
eval_psock(svd(matrix(rnorm(n), k)), timeout=10);
}
system.time(test());
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)
On Thu, May 16, 2013 at 6:06 AM, McGehee, Robert <
robert.mcge...@geodecapital.com> wrote:
> Duncan, Thank you for the clarification on how delayedAssign works. Should
> R-level interfaces to promise objects ever become available, I expect they
> would at time come in handy.
>
> On the subject of substitute and delayedAssign, I do have a follow-up
> question for the list. I'm trying to convert a named list of expression
> objects into an environment of promise objects. After conversion, each
> expression in the list will be automatically evaluated when the variable
> with the same name is accessed in the environment. Effectively, I'm trying
> to create a hash table of promise objects.
>
Populating a new environment with promises happens to be what "calling a
function" in R does anyway, so an elegant way to accomplish this goal is:
makePromiseEnv <- function(expressions, parent=parent.frame()) {
f <- function() environment()
formals(f) <- as.pairlist(expressions)
environment(f) <- parent
f()
}
> e <- makePromiseEnv(alist(a = {print("hello"); 4}, b = {print("again");
6}))
> e$a
[1] "hello"
[1] 4
> e$a
[1] 4
> e$b
[1] "again"
[1] 6
> e$b
[1] 6
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
