gmane.comp.lang.r.devel

Re: R CMD config for R >= 3.0.1

Prof Brian Ripley — 2013-05-19T07:40:04

Could you try current R-patched or R-devel?  Works in my tests at least.

On 19/05/2013 08:25, Berwin A Turlach wrote:

That is not sufficient.  AFAICS the issue only occurs after installation 
(which is probably why no one else saw it), and the Renviron files for 
the different sub-architectures will be different (in R_PLATFORM).

Re: R CMD config for R >= 3.0.1

Berwin A Turlach — 2013-05-19T07:25:58

G'day Brian,

On Sat, 18 May 2013 10:28:43 +0100
Prof Brian Ripley <ripley< at >stats.ox.ac.uk> wrote:

[...]

Either that, or amend the administration and installation manual to
state that one installation should not be a sub-architecture
installation.  :)

But the latter solution also seems to have some problems.  My usual
install script did the following:

1) Run ./configure with 'r_arch=32' (and a few other options) using a
   config.site, configured for a 32bit build; followed by make  
2) make check ; make install 
3) `make distclean'; run ./configure with 'r_arch=64' (and a few other
   options using a config.site configured for a 64 bit build; followed
   by make
4) make check ; make install
5) make pdf info; make install-pdf install-info

When trying to install Rgraphviz afterwards (mmh, this is a
BioConductor package and not a CRAN package, so perhaps I should ask on
their lists?), Rgrahviz couldn't find the correct compiler settings as
"R CMD config ..." did not work (as reported originally).

So I cha

Re: R 3.0.1: wrong MD5 checksums for Windows?

Duncan Murdoch — 2013-05-18T21:37:54

Technically speaking, that's just a message, not an error.  Those files 
were changed by the installer, so the information is correct.

 From a user point of view, it does look like an error.  We could avoid 
the message in several ways:  don't bother checking those files, or 
compute the MD5 checksums on default installed versions of those files, 
or recompute the checksums after installation.

I think the third choice is too hard, so it's not something I'd do.

I don't know which of the other two is better.  A malicious attacker 
could do a lot of damage by messing with the Rprofile.site file; maybe a 
user would want to know if that had happened.  So that suggests the 
second choice.  But then users who don't choose whatever default the 
installer picks will always get the message.

Duncan Murdoch

Re: R CMD config for R >= 3.0.1

Prof Brian Ripley — 2013-05-18T09:28:43

Not exclusively, but as the Mac build no longer uses this, we do need 
people who do to test pre-releases.   One of us needs to build such a 
setup and test it ....

Re: R 3.0.1: wrong MD5 checksums for Windows?

Tal Galili — 2013-05-18T09:25:54

Thanks for the response Peter.

I am dealing with this since I'm trying to indicate to the user if they had
their R installed properly or not, when upgrading R through the installr
package.
I think I'll simply remove these checks manually in the installr package.

Still, for the long run, it makes more sense to me to do as you propose and
simply stip those files from the checksums.

With regards,
Tal





----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili< at >gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
----------------------------------------------------------------------------------------------



On Sat, May 18, 2013 at 12:11 PM, peter dalgaard <pdalgd< at >gmail.com> wrote:


[[alternative HTML version deleted]]

Re: R 3.0.1: wrong MD5 checksums for Windows?

peter dalgaard — 2013-05-18T09:11:40

On May 17, 2013, at 20:01 , Tal Galili wrote:


As has been pointed out before, it is pretty much a non-issue. The Windows installer ships with md5 sums for some local configuration files and if they are locally configured or touched by the installer, the checksums will not match. checkMD5sums is for package checking, it is not documented to be used for checking R.home(). 

Perhaps the Windows maintainer could strip those files from the checksums, but I wouldn't put it on high priority.

R CMD config for R >= 3.0.1

Berwin A Turlach — 2013-05-18T06:54:34

Dear all,

When installing the usual packages that I use, after installing R
3.0.1, I noticed that the installation of some packages that query R about
its configuration did not succeed.  The problem is exemplified by:

berwin< at >bossiaea:~$ R-3.0.1 CMD config CC
/opt/R/R-3.0.1/lib/R/bin/config: 222: .: Can't open /opt/R/R-3.0.1/lib/R/etc/Renviron

Prior to R 3.0.1 such commands worked fine:

berwin< at >bossiaea:~$ R-3.0.0 CMD config CC
gcc -std=gnu99


I noticed now that my installations of the development and
patched version of R have the same problem (since I usually do not install
packages in those versions that query the configuration, I hadn't
noticed the issue earlier).  

The problem seems to be line 222 of `R RHOME`/bin/config (when R is R
3.0.1) which reads:

. ${R_HOME}/etc/Renviron
 
The file ${R_HOME}/etc/Renviron does not necessarily exists if one has
opted for 32/64-bit builds and installed both as sub-architectures,
which I have.  In my installation ${R_HOME}/etc/32/Renviron and
${R_HOME}/etc/64/Re

R 3.0.1: wrong MD5 checksums for Windows?

Tal Galili — 2013-05-17T18:01:49

Hello dear R-devel,

I am not sure if this issue is tracked or not, but in case it isn't:
It appears that R 3.0.1 reproduces the error reported for R 3.0.0 here:
http://r.789695.n4.nabble.com/R-3-0-0-wrong-MD5-checksums-for-Windows-td4663348.html

That is, that when installing R 3.0.1 on Windows 7, and then running:

require(tools)
checkMD5sums(dir=R.home())

It produces the error:
files âetc/Rconsoleâ, âetc/Rprofile.siteâ have the wrong MD5 checksums
[1] FALSE


With regards,
Tal


----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili< at >gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
----------------------------------------------------------------------------------------------

[[alternative HTML version deleted]]

Re: problem in add1's F statistic when data contains NAs?

Paul Johnson — 2013-05-17T17:48:00

Bill

I think you are correct, there's something funny in add1, but is it just
degrees of freedom? Example below..

On Tue, May 14, 2013 at 2:23 PM, William Dunlap <wdunlap< at >tibco.com> wrote:


Here's another view of the same problem.

Error in anova.lmlist(object, ...) :
  models were not all fitted to the same size of dataset

# It is necessary to refit m1 on the smaller dataset, add1 claims it is
doing it.


Analysis of Variance Table

Model 1: y ~ x1 + x2
Model 2: y ~ x1
  Res.Df   RSS Df Sum of Sq     F   Pr(>F)
1      5 0.239
2      6 6.594 -1    -6.356 133.2 8.57e-05 ***
---
Signif. codes:  0 *** 0.001 ** 0.01 * 0.05 . 0.1   1

## Now compare add1 against m1 and m3


Single term additions

Model:
y ~ x1
       Df Sum of Sq   RSS     AIC F value   Pr(>F)
<none>              6.594   2.454
x2      1     6.356 0.239 -22.099   186.5 2.66e-06 ***
---
Signif. codes:  0 *** 0.001 ** 0.01 * 0.05 . 0.1   1
Warning message:
In add1.lm(m1, y ~ x1 + x2, test = "F") :
  using

Re: Substitute / delayedAssign (was: Substitute unaware whenpromise objects are evaluated)

peter dalgaard — 2013-05-17T10:24:20

On May 16, 2013, at 15:06 , McGehee, Robert wrote:


These things are slippery, but the usual way out is to figure out exactly which expression you want to call, compute the expression unevaluated, and evaulate it.

Something like

e <- bquote(delayedAssign( .(names(x)[i]), .(x[[i]]), eval.env=env, assign.env=env))
print(e)
eval(e)

(of course remove the print(e) once you're sure that it is doing the right thing)

Re: Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

Peter Meilstrup — 2013-05-17T10:08:24


Sure, you could pass the expressions as arguments to f instead of as the
defaults. In this case do.call does the construction of promises.

makePromiseEnv2 <- function(expressions, envir=parent.frame()) {
  f <- function() environment()
  arglist <- expressions
  arglist[] <- list(quote(expr=))       #delete defaults, keep names
  formals(f) <- as.pairlist(arglist)
  do.call(f, expressions, envir=envir)
}

e <- makePromiseEnv2(alist(a=ls()))

[[alternative HTML version deleted]]

Re: Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

Duncan Murdoch — 2013-05-17T09:47:29

I like that solution, except for one thing:  I don't see an easy way to 
control the environment where those expressions will be executed.  Since 
you've set them as defaults on the arguments, they will be evaluated in 
the evaluation frame of f(), and that might not be what we want. An 
obvious example of the problem would be

e <- makePromiseEnv(alist(a = ls()))

I don't know what Robert would want

e$a

to print, but one somewhat natural version would be to have it evaluate 
the ls() in the environment from which makePromiseEnv was called, i.e. 
the global environment in this case.  Neither your solution nor mine do 
this, but I can see how to modify mine, since it makes the evaluation 
environment of the expression explicit.  Can you see a modification that 
would do that with your approach?

Duncan Murdoch

Re: Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

Peter Meilstrup — 2013-05-17T03:17:56

On Thu, May 16, 2013 at 6:06 AM, McGehee, Robert <
Robert.McGehee< at >geodecapital.com> wrote:


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()
}

6}))
[1] "hello"
[1] 4
[1] 4
[1] "again"
[1] 6
[1] 6

[[alternative HTML version deleted]]

Re: setTimeLimit sometimes fails to terminate idle call in R

Jeroen Ooms — 2013-05-16T19:34:13

Thank you for the elaborate response. I am going to look into the quartz code.


Yes, I think this would greatly enhance the usability of setTimeLimit.


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
  p

Re: setTimeLimit sometimes fails to terminate idle call in R

Simon Urbanek — 2013-05-16T18:56:45

Jeroen,

On May 16, 2013, at 2:12 PM, Jeroen Ooms wrote:


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.



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 c

setTimeLimit sometimes fails to terminate idle call in R

Jeroen Ooms — 2013-05-16T18:12:50

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

R version 3.0.1 RC (2013-05-10 r6

Re: Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

Duncan Murdoch — 2013-05-16T13:49:07

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

Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

McGehee, Robert — 2013-05-16T13:06:27

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(

tools to document ReferenceClasses

andfra — 2013-05-16T12:03:34

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.franceschini< at >isb-sib.ch
Tel: +41 44 6353148
Mobile: +41 78 6298386
Bioinformatics Group ( Prof. Von Mering),  UZH Zurich


[[alternative HTML version deleted]]

Re: Incorrect target file name for gramLatex.c

peter dalgaard — 2013-05-16T11:40:58

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 $< $< at > 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:

Re: Incorrect target file name for gramLatex.c

Duncan Murdoch — 2013-05-16T11:39:50

Thanks, I'll put your fix in.

Duncan Murdoch