Re: [Rd] install.packages now intentionally references .Rprofile?
I had a similar problem when moving to R-2.9.0 as my .Rprofile called
update.packages(). The solution was to use
if(interactive()) {
utils:::update.packages(ask = FALSE)
}
HTH,
Heather
Mark Kimpel wrote:
> This was my original post, with the code example only slightly modified by
> Martin for clarity. Prior to R-2.9.0, this repeated downloading did not
> occur, the code worked as intended. In fact, if memory serves me correctly,
> it even worked at least during the first 3 months of R-2.0.0 in its
> development stage, before release as a numbered version. Is there a reason
> for that? Is there a work-around? As I mentioned in my original post, the
> code is actually wrapped in a function that checks the date and the date of
> the last update, and proceeds to update package once per week. It was quite
> handy when it was working, hence my desire for a fix for my code.
>
> Thanks,
> Mark
>
> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
> Indiana University School of Medicine
>
> 15032 Hunter Court, Westfield, IN 46074
>
> (317) 490-5129 Work, & Mobile & VoiceMail
> (317) 399-1219 Home
> Skype: mkimpel
>
> "The real problem is not whether machines think but whether men do." -- B.
> F. Skinner
> **
>
>
> On Thu, May 21, 2009 at 2:17 AM, Prof Brian Ripley
> wrote:
>
>> On Wed, 20 May 2009, Martin Morgan wrote:
>>
>> A post on the Bioconductor mailing list
>>> https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html
>>>
>>> suggests that install.packages now references .Rprofile (?), whereas
>>> in R-2-8 it did not. Is this intentional?
>>>
>> Yes. And in fact it did in earlier versions, to find the default library
>> into which to install.
>>
>>
>>
>>> The example is, in .Rprofile
>>>
>>> library(utils)
>>> install.packages("Biobase",
>>> repos="http://bioconductor.org/packages/2.4/bioc";)
>>>
>>> then starting R from the command line results in repeated downloads
>>> of Biobase
>>>
>>> mtmor...@mm:~/tmp> R --quiet
>>> trying URL
>>> '
>>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>>> '
>>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>>> opened URL
>>> ==
>>> downloaded 1.9 Mb
>>>
>>> trying URL
>>> '
>>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>>> '
>>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>>> opened URL
>>> ==
>>> downloaded 1.9 Mb
>>>
>>> ^C
>>> Execution halted
>>>
>>> sessionInfo()
>>> R version 2.9.0 Patched (2009-05-20 r48588)
>>> x86_64-unknown-linux-gnu
>>>
>>> locale:
>>>
>>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> Martin
>>> --
>>> Martin Morgan
>>> Computational Biology / Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N.
>>> PO Box 19024 Seattle, WA 98109
>>>
>>> Location: Arnold Building M1 B861
>>> Phone: (206) 667-2793
>>>
>>> __
>>> 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/
Re: [Rd] file descriptor leak in getSrcLines in R 2.10.0 svn 48590
On 5/21/2009 2:17 PM, William Dunlap wrote:
I noticed the following file descriptor leak when I couldn't remove
a package unless I shut down the R session that had loaded and
used it. The function that triggered the problem printed the output
of a call to parse(). Each time one prints a srcref a connection is
opened and not closed. It looks like it happens in
as.character.srcref's
call to getSrcLines, which has some logic I don't understand about
closing 'srcfile' on exit only if !.is.Open(srcfile):
getSrcLines
function (srcfile, first, last)
{
if (first > last)
return(character(0L))
if (!.isOpen(srcfile))
on.exit(close(srcfile))
conn <- open(srcfile, first)
lines <- readLines(conn, n = last - first + 1L, warn = FALSE)
srcfile$line <- first + length(lines)
return(lines)
}
The idea is that if the srcfile is already open, then it should be left
open; but if it is not open, it should be closed at the end. open() on
an open srcfile is supposed to make no change to the srcfile, just
return the already open connection.
(It looks like the srcref stuff is not finished yet, as there are other
problems, like print(parse(file)) not showing what it used to.)
This is an encoding problem, which looks easy to fix. I think the leak
was caused by this: because of the encoding problem, the connections
got opened but open.srcfile aborted before completion, so close.srcfile
didn't think the srcfile was open at all, and it left the connections in
existence.
The encoding problem came because "unknown" is not a legal encoding to
pass to file(). It needs to be changed to "" or "native.enc".
Thanks for the report; I'll commit a fix after some more testing.
Duncan Murdoch
This is on Linux, compiled by me with an ancient version of gcc.
% R
R version 2.10.0 Under development (unstable) (2009-05-21 r48590)
...
showConnections()
description class mode text isopen can read can write
tf<-tempfile()
cat(file=tf, "1:7\nlog(pi)\n")
showConnections()
description class mode text isopen can read can write
p<-parse(tf)
showConnections()
description class mode text isopen can read can write
p
expression(,
)
attr(,"srcfile")
/tmp/RtmpZ1llo5/file327b23c6
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
tf
[1] "/tmp/RtmpZ1llo5/file327b23c6"
z<-attr(p,"srcref")[[2]]
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
zz<-as.character(z)
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
7 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
zz
[1] ""
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
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] file descriptor leak in getSrcLines in R 2.10.0 svn 48590
> ...
> The idea is that if the srcfile is already open, then it
> should be left
> open; but if it is not open, it should be closed at the end.
> open() on
> an open srcfile is supposed to make no change to the srcfile, just
> return the already open connection.
>
> > (It looks like the srcref stuff is not finished yet, as
> there are other
> > problems, like print(parse(file)) not showing what it used to.)
>
>
> This is an encoding problem, which looks easy to fix. I
> think the leak
> was caused by this: because of the encoding problem, the connections
> got opened but open.srcfile aborted before completion, so
> close.srcfile
> didn't think the srcfile was open at all, and it left the
> connections in
> existence.
That incompletely opened connection may be why after doing
this test closeAllConnections crashed R because the ex_ptr
component of an Rconnection object was a nil pointer:
> tf<-tempfile()
> cat(file=tf, "1:10\nlog(log(pi))\n")
> p<-parse(tf)
> p
expression(,
)
attr(,"srcfile")
/tmp/RtmpazU79B/file327b23c6
> showConnections()
descriptionclass mode text isopen can read can write
3 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
4 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
5 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
6 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
> closeAllConnections()
Program received signal SIGSEGV, Segmentation fault.
0x08118eff in Rf_setAttrib (vec=0x883f278, name=0x8621948, val=0x0)
at attrib.c:226
226 if (NAMED(val)) val = duplicate(val);
(gdb) up
#1 0x08146c7b in do_getconnection (call=0x87a3b74, op=0x85f6fd8,
args=0x87a3ca8, env=0x87a3c1c) at connections.c:4166
4166setAttrib(ans, install("conn_id"), con->ex_ptr);
(gdb) list
4161PROTECT(class = allocVector(STRSXP, 2));
4162SET_STRING_ELT(class, 0, mkChar(con->class));
4163SET_STRING_ELT(class, 1, mkChar("connection"));
4164classgets(ans, class);
4165if (what > 2)
4166setAttrib(ans, install("conn_id"), con->ex_ptr);
4167UNPROTECT(2);
4168return ans;
4169}
4170
(gdb) print con->ex_ptr
$3 = (void *) 0x0
(gdb) print *con
$4 = {class = 0x90c8940 "file",
description = 0x89c5878 "/tmp/RtmpazU79B/file327b23c6", enc = 0,
mode = "rt\000\000", text = TRUE, isopen = TRUE, incomplete = FALSE,
canread = TRUE, canwrite = FALSE, canseek = TRUE, blocking = TRUE,
isGzcon = FALSE, open = 0x813c4f2 ,
close = 0x813c77b , destroy = 0x813bcf9 ,
vfprintf = 0x813c7c3 , fgetc = 0x813bfef ,
fgetc_internal = 0x813c860 ,
seek = 0x813c8f9 , truncate = 0x813caa1 ,
fflush = 0x813cb8a , read = 0x813cbae ,
write = 0x813cc26 , nPushBack = 0, posPushBack = 64256,
PushBack = 0x204, save = -1000, save2 = -1000,
encname = "unknown", '\0' , "A", inconv = 0x0,
outconv = 0x0,
iconvbuff =
" \036\022\tE\001\000\000F\001\000\000G\001\000\000H\001\000\000I\001\000\000J",
oconvbuff =
"\001\000\000K\001\000\000L\001\000\000M\001\000\000N\001\000\000O\001\000\000P\001\000\000Q\001\000\000R\001\000\000S\001\000\000T\001\000\000U\001\000\000V\001",
next = 0x157 ,
init_out =
"X\001\000\000Y\001\000\000Z\001\000\000[\001\000\000\\\001\000\000]\001\000\000^",
navail = 0, inavail = 351, EOF_signalled = 352,
UTF8out = FALSE, id = 0x23, ex_ptr = 0x0, private = 0x908ec78}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file descriptor leak in getSrcLines in R 2.10.0 svn 48590
On 5/21/2009 2:17 PM, William Dunlap wrote:
I noticed the following file descriptor leak when I couldn't remove
a package unless I shut down the R session that had loaded and
used it. The function that triggered the problem printed the output
of a call to parse(). Each time one prints a srcref a connection is
opened and not closed. It looks like it happens in
as.character.srcref's
call to getSrcLines, which has some logic I don't understand about
closing 'srcfile' on exit only if !.is.Open(srcfile):
I have a simpler recipe to reproduce the crash now:
tf <- tempfile()
con <- file(tf, open="w", encoding="unknown")
This gives an error message about an unsupported conversion
and leaves the con object only partially built. closeAllConnections()
will then crash.
Should be relatively easy to fix...I'll take a look.
Duncan Murdoch
getSrcLines
function (srcfile, first, last)
{
if (first > last)
return(character(0L))
if (!.isOpen(srcfile))
on.exit(close(srcfile))
conn <- open(srcfile, first)
lines <- readLines(conn, n = last - first + 1L, warn = FALSE)
srcfile$line <- first + length(lines)
return(lines)
}
(It looks like the srcref stuff is not finished yet, as there are other
problems, like print(parse(file)) not showing what it used to.)
This is on Linux, compiled by me with an ancient version of gcc.
% R
R version 2.10.0 Under development (unstable) (2009-05-21 r48590)
...
showConnections()
description class mode text isopen can read can write
tf<-tempfile()
cat(file=tf, "1:7\nlog(pi)\n")
showConnections()
description class mode text isopen can read can write
p<-parse(tf)
showConnections()
description class mode text isopen can read can write
p
expression(,
)
attr(,"srcfile")
/tmp/RtmpZ1llo5/file327b23c6
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
tf
[1] "/tmp/RtmpZ1llo5/file327b23c6"
z<-attr(p,"srcref")[[2]]
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
zz<-as.character(z)
showConnections()
descriptionclass mode text isopen can read
can write
3 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
4 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
5 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
6 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
7 "/tmp/RtmpZ1llo5/file327b23c6" "file" "rt" "text" "opened" "yes"
"no"
zz
[1] ""
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
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] file descriptor leak in getSrcLines in R 2.10.0 svn 48590
On 5/22/2009 11:17 AM, William Dunlap wrote:
...
The idea is that if the srcfile is already open, then it
should be left
open; but if it is not open, it should be closed at the end.
open() on
an open srcfile is supposed to make no change to the srcfile, just
return the already open connection.
> (It looks like the srcref stuff is not finished yet, as
there are other
> problems, like print(parse(file)) not showing what it used to.)
This is an encoding problem, which looks easy to fix. I
think the leak
was caused by this: because of the encoding problem, the connections
got opened but open.srcfile aborted before completion, so
close.srcfile
didn't think the srcfile was open at all, and it left the
connections in
existence.
That incompletely opened connection may be why after doing
this test closeAllConnections crashed R because the ex_ptr
component of an Rconnection object was a nil pointer:
I saw a crash like that once, but then couldn't reproduce it. I'll see
if I can do so with your code.
Duncan Murdoch
tf<-tempfile()
cat(file=tf, "1:10\nlog(log(pi))\n")
p<-parse(tf)
p
expression(,
)
attr(,"srcfile")
/tmp/RtmpazU79B/file327b23c6
showConnections()
descriptionclass mode text isopen can read can write
3 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
4 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
5 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
6 "/tmp/RtmpazU79B/file327b23c6" "file" "rt" "text" "opened" "yes""no"
closeAllConnections()
Program received signal SIGSEGV, Segmentation fault.
0x08118eff in Rf_setAttrib (vec=0x883f278, name=0x8621948, val=0x0)
at attrib.c:226
226 if (NAMED(val)) val = duplicate(val);
(gdb) up
#1 0x08146c7b in do_getconnection (call=0x87a3b74, op=0x85f6fd8,
args=0x87a3ca8, env=0x87a3c1c) at connections.c:4166
4166setAttrib(ans, install("conn_id"), con->ex_ptr);
(gdb) list
4161PROTECT(class = allocVector(STRSXP, 2));
4162SET_STRING_ELT(class, 0, mkChar(con->class));
4163SET_STRING_ELT(class, 1, mkChar("connection"));
4164classgets(ans, class);
4165if (what > 2)
4166setAttrib(ans, install("conn_id"), con->ex_ptr);
4167UNPROTECT(2);
4168return ans;
4169}
4170
(gdb) print con->ex_ptr
$3 = (void *) 0x0
(gdb) print *con
$4 = {class = 0x90c8940 "file",
description = 0x89c5878 "/tmp/RtmpazU79B/file327b23c6", enc = 0,
mode = "rt\000\000", text = TRUE, isopen = TRUE, incomplete = FALSE,
canread = TRUE, canwrite = FALSE, canseek = TRUE, blocking = TRUE,
isGzcon = FALSE, open = 0x813c4f2 ,
close = 0x813c77b , destroy = 0x813bcf9 ,
vfprintf = 0x813c7c3 , fgetc = 0x813bfef ,
fgetc_internal = 0x813c860 ,
seek = 0x813c8f9 , truncate = 0x813caa1 ,
fflush = 0x813cb8a , read = 0x813cbae ,
write = 0x813cc26 , nPushBack = 0, posPushBack = 64256,
PushBack = 0x204, save = -1000, save2 = -1000,
encname = "unknown", '\0' , "A", inconv = 0x0,
outconv = 0x0,
iconvbuff = "
\036\022\tE\001\000\000F\001\000\000G\001\000\000H\001\000\000I\001\000\000J",
oconvbuff =
"\001\000\000K\001\000\000L\001\000\000M\001\000\000N\001\000\000O\001\000\000P\001\000\000Q\001\000\000R\001\000\000S\001\000\000T\001\000\000U\001\000\000V\001",
next = 0x157 ,
init_out =
"X\001\000\000Y\001\000\000Z\001\000\000[\001\000\000\\\001\000\000]\001\000\000^",
navail = 0, inavail = 351, EOF_signalled = 352,
UTF8out = FALSE, id = 0x23, ex_ptr = 0x0, private = 0x908ec78}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Scope problem?
I've just spent today trying to fix a Heisenbug...
this function returns a linear interpolator function:
interpOne <- function(xl,yl){
f = function(data){
t = (data-min(xl))/(max(xl)-min(xl))
return(min(yl)+t*(max(yl)-min(yl)))
}
return(f)
}
> k=interpOne(c(0,1),c(4,5))
> k(0.5)
[1] 4.5
and this function uses the above to return a function that returns a
piece-wise linear interpolator function:
mr <- function(){
parts = list()
ranges = rbind(c(0,1),c(1,2),c(2,3))
domains = rbind(c(3,4),c(5,6),c(2,8))
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
}
f = function(d){
pos = sum(d>ranges[,1])
cat("using pos = ",pos,"\n")
return(parts[[pos]](d))
}
return(f)
}
m = mr()
The 'ranges' and 'domains' vectors describe the pieces. But this doesn't work:
> m(0.5)
using pos = 1
[1] -7
- but it should be 3.5 (since 0.5 is in the first piece, and that
then interpolates between 3 and 4). What about the other pieces:
> m(1.5)
using pos = 2
[1] -1
> m(2.5)
using pos = 3
[1] 5
- which looks like it's using the last set of range/domain pairs each
time. Curious, I thought.
So I thought I'd evaluate the functions as they are created in the
list to see what's going on. Change the loop to print out:
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
cat("part ",i," at zero = ",parts[[i]](0),"\n")
}
and try:
> m=mr()
part 1 at zero = 3
part 2 at zero = 4
part 3 at zero = -10
looks good, those are the intercepts of my pieces... but now:
> m(0.5)
using pos = 1
[1] 3.5
> m(1.5)
using pos = 2
[1] 5.5
> m(2.5)
using pos = 3
[1] 5
Woah! It's now working! Trying to observe the thing changes it? A Heisenbug!
I can only think it's my misunderstanding of some aspect of R's
scoping and evaluation rules. Does evaluating the functions within
that loop cause a copy of some environment to be made, or a 'lazy
evaluation' to be evaluated? Or a 'promise' to be fulfilled? I don't
really understand those terms, I'd just hoped functions ran in the
environment they were created in. Seems sometimes they do, sometimes
they dont... What's going on?
R 2.9.0 on Ubuntu.
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scope problem?
On 5/22/2009 12:28 PM, Barry Rowlingson wrote:
I've just spent today trying to fix a Heisenbug...
this function returns a linear interpolator function:
interpOne <- function(xl,yl){
f = function(data){
t = (data-min(xl))/(max(xl)-min(xl))
return(min(yl)+t*(max(yl)-min(yl)))
}
return(f)
}
k=interpOne(c(0,1),c(4,5))
k(0.5)
[1] 4.5
and this function uses the above to return a function that returns a
piece-wise linear interpolator function:
mr <- function(){
parts = list()
ranges = rbind(c(0,1),c(1,2),c(2,3))
domains = rbind(c(3,4),c(5,6),c(2,8))
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
}
f = function(d){
pos = sum(d>ranges[,1])
cat("using pos = ",pos,"\n")
return(parts[[pos]](d))
}
return(f)
}
m = mr()
The 'ranges' and 'domains' vectors describe the pieces. But this doesn't work:
m(0.5)
using pos = 1
[1] -7
- but it should be 3.5 (since 0.5 is in the first piece, and that
then interpolates between 3 and 4). What about the other pieces:
m(1.5)
using pos = 2
[1] -1
m(2.5)
using pos = 3
[1] 5
- which looks like it's using the last set of range/domain pairs each
time. Curious, I thought.
So I thought I'd evaluate the functions as they are created in the
list to see what's going on. Change the loop to print out:
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
cat("part ",i," at zero = ",parts[[i]](0),"\n")
}
and try:
> m=mr()
part 1 at zero = 3
part 2 at zero = 4
part 3 at zero = -10
looks good, those are the intercepts of my pieces... but now:
> m(0.5)
using pos = 1
[1] 3.5
m(1.5)
using pos = 2
[1] 5.5
m(2.5)
using pos = 3
[1] 5
Woah! It's now working! Trying to observe the thing changes it? A Heisenbug!
I can only think it's my misunderstanding of some aspect of R's
scoping and evaluation rules. Does evaluating the functions within
that loop cause a copy of some environment to be made, or a 'lazy
evaluation' to be evaluated? Or a 'promise' to be fulfilled? I don't
really understand those terms, I'd just hoped functions ran in the
environment they were created in. Seems sometimes they do, sometimes
they dont... What's going on?
I think it's lazy evaluation that gets you. I haven't stepped through
your code, but have done a similar one recently, and this is my guess
about what happens:
- interpOne creates the function, but never evaluates xl or yl.
- You call it several times, to create a number of functions, but still
never evaluate xl or yl. They are left as promises to evaluate
ranges[i,] and domains[i,] in the environment of that loop.
- Finally, you start evaluating those created functions, and it's at
that point that xl and yl get forced. Since i is now on the last value,
they get the wrong values set.
Putting force(xl); force(yl) into your interpOne definition (so they get
executed when interpOne is called, not just when the returned function
is called) should work.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scope problem?
On Fri, May 22, 2009 at 6:04 PM, Duncan Murdoch wrote: > Putting force(xl); force(yl) into your interpOne definition (so they get > executed when interpOne is called, not just when the returned function is > called) should work. *sigh* yes, that looks like it. The help for "force" gives a more concise example. What I'd posted was actually a cut-down version of my original problem! I've not tested it yet, but other things I'd tried had removed the bug without me understanding why - such as reassinging the args to interpOne inside the function. Do any other languages work like this? Thanks Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strange install key for R
One user of my batchfiles http://batchfiles.googlecode.com found they did not find the R registry key because it mysteriously was at hklm\software\wow6432Node. The system was a 64 bit system. I've always seen the key at hklm\software\R-core\R which is what the batchfiles assume. Has there been some change in where the installer puts the key or are there situations in which the location of the key in the registry is somehow changed? (Note that the batchfiles do have two workarounds in case the user cannot or wishes not to access the registry but it would be better not to have to rely on those.) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scope problem?
On 22/05/2009 3:02 PM, Barry Rowlingson wrote: On Fri, May 22, 2009 at 6:04 PM, Duncan Murdoch wrote: Putting force(xl); force(yl) into your interpOne definition (so they get executed when interpOne is called, not just when the returned function is called) should work. *sigh* yes, that looks like it. The help for "force" gives a more concise example. What I'd posted was actually a cut-down version of my original problem! I've not tested it yet, but other things I'd tried had removed the bug without me understanding why - such as reassinging the args to interpOne inside the function. Do any other languages work like this? According to Wikipedia (http://en.wikipedia.org/wiki/Lazy_evaluation), functional languages tend to do this; examples they give are Haskell, Miranda, and it's optional in Scheme and Ocaml. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
