Re: [Rd] How do I put ldpaths in a specific place?
On Oct 6, 2010, at 12:38 AM, Tena Sakai wrote: > Hi Everybody, > > I made R (v. 2.11.1) from source with the following config option: >./configure --prefix=/mnt/ami-centos5.5-64bit-base \ >--exec-prefix=/mnt/ami-centos5.5-64bit-base \ >--with-tcltk > > All seemed to go well, but when I tested it with: >/usr/sbin/chroot /mnt/ami-centos5.5-64bit-base R > It told me: > /bin/R: line 217: /mnt/ami-centos5.5-64bit-base/lib64/R/etc/ldpaths: No such > file or directory > > Question: > How can I direct ldpaths file into this directory? > That's a quite irrelevant question if your underlying goal is to run R - ldpaths is your least problem - even if you fixed that nothing would work as your R.home is entirely wrong. Note that by using chroot you're making the entire configuration under which you compiled R invalid. If your chroot jailed configuration is identical to that of your main system, you should configure R against your full system and use DESTDIR on make install to place the installation in the jail. (Note that --prefix is something entirely different!) If it's not then you are entirely on your own as you will have to use the above approach but then also make sure any dependent tools and libraries used by R are also present in the chroot jail. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possible bug in summaryRprof with memory.profiling=TRUE
I apologize for the somewhat brief bug report, but we are getting
close to the release of 2.12 and I thought it was better to send
something brief than to stay silent.
R version 2.12.0 beta (2010-10-06 r53205)
compiled with memory-profiling enabled. I have very little experience
with memory profiling, but the following works
Rprof(memory.profiling = TRUE)
example(glm)
Rprof(NULL)
summaryRprof(memory = "stats")
Now, I am working on a personal function involving a number of nested functions,
smoothP contains smoothChromosome contains smoothSample
These functions contains a number of print(gc()) calls that I have
left untouched (not sure if this is related). My code also used
multicore, but currently it uses mclapply(..., mc.cores = 1) which (as
far as I can see) simply calls lapply.
When I run
Rprof(memory.profiling = TRUE)
BSdata <- smoothP(BSdata.tmp, ns = 70, h = 1000, mc.cores = 1)
Rprof(NULL)
summaryRprof(memory = "stats")
I get an error:
Error in tapply(1L:961L, list(index = c("\"smoothP\":\"print\"",
"\"smoothP\":\"print\"", :
arguments must have same length
Enter a frame number, or 0 to exit
1: summaryRprof(memory = "stats")
2: Rprof_memory_summary(filename = con, chunksize = chunksize, aggregate = ind
3: by(memcounts, index, function(these) with(these, round(c(vsize.small = mean
4: by.data.frame(memcounts, index, function(these) with(these, round(c(vsize.s
5: eval(substitute(tapply(1:nd, IND, FUNx, simplify = simplify)), data)
6: eval(expr, envir, enclos)
7: tapply(1:961, list(index = c("\"smoothP\":\"print\"",
"\"smoothP\":\"print\
Selection: 2
Called from: eval(expr, envir, enclos)
Browse[1]> dim(memcounts)
[1] 961 4
Browse[1]> length(index)
[1] 5961
Browse[1]> head(index)
[1] "\"smoothP\":\"print\"" "\"smoothP\":\"print\""
"\"smoothP\":\"print\""
[4] "\"smoothP\":\"print\"" "\"smoothP\":\"print\""
"\"smoothP\":\"print\""
Browse[1]> tail(index)
[1] "\"smoothP\":\"print\"" "\"smoothP\":\"print\""
"\"smoothP\":\"print\""
[4] "\"smoothP\":\"print\"" "\"smoothP\":\"list\""
"\"smoothP\":\"list\""
Browse[1]>
The file Rprof.out has 5962 lines according to wc -l, and looks
normal. The file is available at
http://www.biostat.jhsph.edu/~khansen/Rprof.out
It parses correctly if I just do
summaryRprof()
(without the memory = "stats" option). If I use memory = "tseries" I
also get a row number mismatch:
Error in data.frame(..., check.names = FALSE) :
arguments imply differing number of rows: 961, 5961
Enter a frame number, or 0 to exit
1: summaryRprof("http://www.biostat.jhsph.edu/~khansen/Rprof.out";, memory = "t
2: Rprof_memory_summary(filename = con, chunksize = chunksize, label = index,
3: cbind(memcounts, labels)
4: cbind(deparse.level, ...)
5: data.frame(..., check.names = FALSE)
Selection:
I see this in R-devel (build today) as well.
Kasper
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SweaveInput + keep.source = TRUE trouble
Thank you - works fine for me now.
Claudia
Duncan Murdoch wrote:
This is fixed now in R-devel and the beta version. The fix isn't
perfect: if you use \SweaveInput, you lose the error reporting that
gives line numbers from the original file. It should be possible to
have both, but I think the changes to implement that are too large to
consider in a beta.
Duncan Murdoch
On 05/10/2010 5:38 AM, Claudia Beleites wrote:
Dear all,
I have trouble with R-beta sweaving files that include definitions with
\SweaveInput in combination with keep.source = TRUE
Symptom:
SInput is taken from too far down the input file (the shift is the
number of
lines of the included file). Is that known? Searching didn't turn up
anything,
yet I think there are more people than just me using keep.source.
Example:
$ ~/tmp/R-beta/bin/R CMD Sweave baseline.Rnw&&
mv baseline.tex baseline.devel.tex&&
R CMD Sweave baseline.Rnw&&
mv baseline.tex baseline.2.11.tex&&
diff -u baseline.2.11.tex baseline.devel.tex
gives:
--- baseline.2.11.tex2010-10-05 11:33:49.0 +0200
+++ baseline.devel.tex2010-10-05 11:33:49.0 +0200
@@ -83,7 +83,7 @@
\verb+\SweaveOpts{keep.source = TRUE}+
\begin{Schunk}
\begin{Sinput}
-> 12
+> line 54
\end{Sinput}
\begin{Soutput}
[1] 12
@@ -106,7 +106,7 @@
line 63 chunk option keep.source = TRUE
\begin{Schunk}
\begin{Sinput}
-> 14
+> line 67
\end{Sinput}
\begin{Soutput}
[1] 14
I used yesterday's R-beta, and my system is Ubuntu 9.10 64 bit (though
that
probably doesn't matter).
Building the example file I also found that \SweaveInput{} cannot be
followed by
anything else on the line(not even a LaTeX comment).
\SweaveInput{x}y
complains that file xy is not found.
Best regards,
Claudia Beleites
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste
phone: +39 0 40 5 58-37 68
email: cbelei...@units.it
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I put ldpaths in a specific place?
Thank you Simon, I ran: make install DESTDIR=/mnt/ami-centos5.5-64bit-base Now I can execute this R which is in /mnt/ami-centos5.5-64bit-base/usr/local/bin two ways: cd /mnt/ami-centos5.5-64bit-base/usr/local/bin ./R and chroot /mnt/ami-centos5.5-64bit-base R Many thanks for your help. Regards, Tena Sakai tsa...@gallo.ucsf.edu On 10/6/10 4:45 AM, "Simon Urbanek" wrote: > > On Oct 6, 2010, at 12:38 AM, Tena Sakai wrote: > >> Hi Everybody, >> >> I made R (v. 2.11.1) from source with the following config option: >>./configure --prefix=/mnt/ami-centos5.5-64bit-base \ >>--exec-prefix=/mnt/ami-centos5.5-64bit-base \ >>--with-tcltk >> >> All seemed to go well, but when I tested it with: >>/usr/sbin/chroot /mnt/ami-centos5.5-64bit-base R >> It told me: >> /bin/R: line 217: /mnt/ami-centos5.5-64bit-base/lib64/R/etc/ldpaths: No such >> file or directory >> >> Question: >> How can I direct ldpaths file into this directory? >> > > That's a quite irrelevant question if your underlying goal is to run R - > ldpaths is your least problem - even if you fixed that nothing would work as > your R.home is entirely wrong. > > Note that by using chroot you're making the entire configuration under which > you compiled R invalid. > > If your chroot jailed configuration is identical to that of your main system, > you should configure R against your full system and use DESTDIR on make > install to place the installation in the jail. (Note that --prefix is > something entirely different!) > > If it's not then you are entirely on your own as you will have to use the > above approach but then also make sure any dependent tools and libraries used > by R are also present in the chroot jail. > > Cheers, > Simon > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified]
Hi all,
After no replies to my previous message I thought I might show some code to
demonstrate the change and again seek any explanation for the error now thrown
by my code after upgrading from 2.10.1 to 2.11.1.
Thanks
Troy
setClass("PortableObject",
representation(test1= "character"),
prototype( test1 = ""),
contains = ".environment"
)
setMethod("initialize", "PortableObject",
function(.Object, ..., .xData=new.env(parent=emptyenv())) {
.Object <- callNextMethod(.Object, ..., .xData=.xData)
.obj...@test1 <- "Foo"
# Following line works under 2.10.1 but now throws
# Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
#.Object[["test2"]] <- "Bar"
# The following does what I want though
.Object$test3 <- "Baa"
return(.Object)
}
)
e <- new("PortableObject")
alterEGo <- function(o = "EPOCObject") {
o...@test1 <- "Boo"
# Following line works under 2.10.1 but now throws
# Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
o[["test2"]] <- "Who"
# The following does what I want though
o$test3 <- "Hoo"
# NOTE: No return
}
alterEGo(e)
e...@test1
e$test2
e[["test3"]]
e...@.xdata[["test3"]]
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified]
On 10/06/2010 06:12 PM, Troy Robertson wrote:
> Hi all,
>
> After no replies to my previous message I thought I might show some code to
> demonstrate the change and again seek any explanation for the error now
> thrown by my code after upgrading from 2.10.1 to 2.11.1.
>
> Thanks
> Troy
>
> setClass("PortableObject",
> representation(test1= "character"),
>
> prototype( test1 = ""),
> contains = ".environment"
> )
>
> setMethod("initialize", "PortableObject",
> function(.Object, ..., .xData=new.env(parent=emptyenv())) {
> .Object <- callNextMethod(.Object, ..., .xData=.xData)
>
> .obj...@test1 <- "Foo"
> # Following line works under 2.10.1 but now throws
> # Error: evaluation nested too deeply: infinite recursion /
> options(expressions=)?
> #.Object[["test2"]] <- "Bar"
> # The following does what I want though
> .Object$test3 <- "Baa"
>
> return(.Object)
> }
> )
>
> e <- new("PortableObject")
The explicit example does help -- it's clear what bug you are
encountering. Here's the code in R-2.10
> selectMethod("[[<-", ".environment")
Method Definition:
function (x, i, j, ..., value)
{
call <- sys.call()
call[[2]] <- x...@.data
eval.parent(call)
x
}
and 2.11.1
> selectMethod("[[<-", ".environment")
Method Definition:
function (x, i, j, ..., value)
{
.local <- function (x, i, j, ..., exact = TRUE, value)
{
call <- sys.call()
call[[2]] <- x...@.data
eval.parent(call)
x
}
.local(x, i, j, ..., value = value)
}
Apparently the 'exact' argument has been added, and because the method
signature differs from the generic, a .local function is created. That
'sys.call()' originally returned the environment in which the generic
was called, but now it returns the environment in which .local is
defined. And so eval() keeps evaluating .local(). This I think is a bug.
For what it's worth, if I were interested in minimizing copying I would
set up initialize so that it ended with callNextMethod(<...>), on the
hopes that the method eventually called would take care not to make too
many copies on slot assignment.
Martin
>
> alterEGo <- function(o = "EPOCObject") {
> o...@test1 <- "Boo"
>
> # Following line works under 2.10.1 but now throws
> # Error: evaluation nested too deeply: infinite recursion /
> options(expressions=)?
> o[["test2"]] <- "Who"
> # The following does what I want though
> o$test3 <- "Hoo"
>
> # NOTE: No return
> }
>
> alterEGo(e)
> e...@test1
> e$test2
> e[["test3"]]
> e...@.xdata[["test3"]]
> ___
>
> Australian Antarctic Division - Commonwealth of Australia
> IMPORTANT: This transmission is intended for the addressee only. If you are
> not the
> intended recipient, you are notified that use or dissemination of this
> communication is
> strictly prohibited by Commonwealth law. If you have received this
> transmission in error,
> please notify the sender immediately by e-mail or by telephoning +61 3 6232
> 3209 and
> DELETE the message.
> Visit our web site at http://www.antarctica.gov.au/
> ___
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified] [Sec=Unclassified]
>
> On 10/06/2010 06:12 PM, Troy Robertson wrote:
> > Hi all,
> >
> > After no replies to my previous message I thought I might show some
> > code to demonstrate the change and again seek any
> explanation for the
> > error now thrown by my code after upgrading from 2.10.1 to 2.11.1.
> >
> > Thanks
> > Troy
> >
> > setClass("PortableObject",
> > representation(test1= "character"),
> >
> > prototype( test1 = ""),
> > contains = ".environment"
> > )
> >
> > setMethod("initialize", "PortableObject",
> > function(.Object, ..., .xData=new.env(parent=emptyenv())) {
> > .Object <- callNextMethod(.Object, ...,
> .xData=.xData)
> >
> > .obj...@test1 <- "Foo"
> > # Following line works under 2.10.1 but now throws
> > # Error: evaluation nested too deeply:
> infinite recursion / options(expressions=)?
> > #.Object[["test2"]] <- "Bar"
> > # The following does what I want though
> > .Object$test3 <- "Baa"
> >
> > return(.Object)
> > }
> > )
> >
> > e <- new("PortableObject")
>
> The explicit example does help -- it's clear what bug you are
> encountering. Here's the code in R-2.10
>
> > selectMethod("[[<-", ".environment")
> Method Definition:
>
> function (x, i, j, ..., value)
> {
> call <- sys.call()
> call[[2]] <- x...@.data
> eval.parent(call)
> x
> }
>
>
> and 2.11.1
>
> > selectMethod("[[<-", ".environment")
> Method Definition:
>
> function (x, i, j, ..., value)
> {
> .local <- function (x, i, j, ..., exact = TRUE, value)
> {
> call <- sys.call()
> call[[2]] <- x...@.data
> eval.parent(call)
> x
> }
> .local(x, i, j, ..., value = value)
> }
>
> Apparently the 'exact' argument has been added, and because
> the method signature differs from the generic, a .local
> function is created. That 'sys.call()' originally returned
> the environment in which the generic was called, but now it
> returns the environment in which .local is defined. And so
> eval() keeps evaluating .local(). This I think is a bug.
Yes, afer the email from William Dunlop, I found this difference in the methods
between 2.10.1 and 2.11.1
I had a play and by adding my own method to overload "[[<-" for my
PortableObject was able to reinstate the original functionality without the
recursive error.
setMethod("[[<-", "PortableObject",
function (x, i, j, ..., value)
{
call <- sys.call()
call[[2]] <- x...@.data
eval.parent(call)
x
}
)
>
> For what it's worth, if I were interested in minimizing
> copying I would set up initialize so that it ended with
> callNextMethod(<...>), on the hopes that the method
> eventually called would take care not to make too many copies
> on slot assignment.
>
> Martin
>
Hmmm, not sure what you mean here? My code passes objects such as these as
parameters to other S4 classes which alter their data. If the .xData slot is
used then I have no need to return the object. No copy-on-change is performed
but data held by the PortableObject is modified. This speeds up my execution
time by a LARGE amount.
I could very well have things all arse-about, having come from a Java OO
background, but this is the only way I have been able to create a
pass-by-reference paradigm using S4 classes. Any suggestions for alternative
solutions would be greatfully received.
Troy
> >
> > alterEGo <- function(o = "EPOCObject") {
> > o...@test1 <- "Boo"
> >
> > # Following line works under 2.10.1 but now throws
> > # Error: evaluation nested too deeply: infinite
> recursion / options(expressions=)?
> > o[["test2"]] <- "Who"
> > # The following does what I want though
> > o$test3 <- "Hoo"
> >
> > # NOTE: No return
> > }
> >
> > alterEGo(e)
> > e...@test1
> > e$test2
> > e[["test3"]]
> > e...@.xdata[["test3"]]
> >
___
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not
the
intended recipient, you are notified that use or dissemination of this
communication is
strictly prohibited by Commonwealth law. If you have received this transmission
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
