Re: [Rd] update.packages fails with directory not found
Mike, If you have the time and can consistently reproduce this problem you might try using Sysinternal's Process Monitor program to capture the details of what R and other programs were doing in that directory around the time of the problem. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx I have not used Process Monitor, but have profitably used the older Filemon program and Process Explorer from Sysinternals. They act somewhat like the Linux lsof and strace programs, tracing things at the interface between a program and the operating system. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Mike Prager Sent: Tuesday, May 11, 2010 3:21 PM To: r-de...@stat.math.ethz.ch Subject: Re: [Rd] update.packages fails with directory not found On Tue, 11 May 2010 11:05:45 -0400, Duncan Murdoch murdoch.dun...@gmail.com wrote: I'd appreciate it if you could check whether the problems remain in R-devel, revision 51980 or later. (A build of this revision should be on CRAN by tomorrow, at http://cran.r-project.org/bin/windows/base/rdevel.html .) Thanks for trying to fix this. Here is a cut-and-paste [...edited] from Rgui.exe. Hope it helps. MHP R version 2.12.0 Under development (unstable) (2010-05-11 r51980) Copyright (C) 2010 The R Foundation for Statistical Computing ISBN 3-900051-07-0 [...] Natural language support but running in an English locale [...] Loading required package: survival Loading required package: stats Loading required package: utils Loading required package: graphics Loading required package: splines Attaching package: 'Hmisc' [...] update.packages(ask='graphics') trying URL [...] downloaded 1.0 Mb package 'maps' successfully unpacked and MD5 sums checked package 'rgl' successfully unpacked and MD5 sums checked package 'rJava' successfully unpacked and MD5 sums checked Warning: unable to move temporary installation 'c:\Program Files\R\Library\file390c7e87\rJava' to 'c:\Program Files\R\Library\rJava' package 'strucchange' successfully unpacked and MD5 sums checked package 'svMisc' successfully unpacked and MD5 sums checked package 'tkrplot' successfully unpacked and MD5 sums checked package 'vcd' successfully unpacked and MD5 sums checked package 'XML' successfully unpacked and MD5 sums checked package 'zoo' successfully unpacked and MD5 sums checked The downloaded packages are in C:\Documents and Settings\mike.prager\Local Settings\Temp\RtmpyrBgXD\downloaded_packages Warning message: In normalizePath(path) : path[1]=c:\Program Files\R\Library/rJava: The system cannot find the file specified traceback() No traceback available __ 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] update.packages fails with directory not found
On 12/05/2010 12:42 PM, Mike Prager wrote: Shortened a bit further. Answers to queries are at the end. MHP Duncan Murdoch wrote on 5/11/2010 7:03 PM: On 11/05/2010 6:21 PM, Mike Prager wrote: On Tue, 11 May 2010 11:05:45 -0400, Duncan Murdoch murdoch.dun...@gmail.com wrote: I'd appreciate it if you could check whether the problems remain in R-devel, revision 51980 or later. Thanks for trying to fix this. Here is a cut-and-paste [...edited] from Rgui.exe. Hope it helps. MHP R version 2.12.0 Under development (unstable) (2010-05-11 r51980) Copyright (C) 2010 The R Foundation for Statistical Computing ISBN 3-900051-07-0 [...] Was rJava among the packages loaded at the time you tried this? update.packages(ask='graphics') trying URL [...] downloaded 1.0 Mb package 'rJava' successfully unpacked and MD5 sums checked Warning: unable to move temporary installation 'c:\Program Files\R\Library\file390c7e87\rJava' to 'c:\Program Files\R\Library\rJava' After the install was complete, was rJava present in Library? Was it updated? Was the temporary directory file390c7e87 still present? [...] The downloaded packages are in C:\Documents and Settings\mike.prager\Local Settings\Temp\RtmpyrBgXD\downloaded_packages Warning message: In normalizePath(path) : path[1]=c:\Program Files\R\Library/rJava: The system cannot find the file specified Answers: rJava was not loaded when the update started. After the install, rJava was no longer present in the library. The temporary directory file390c7e87 was not present. Checking my undelete program, the temp directory had existed and had contained the rJava package but was (and is) deleted. I don't know what the problem is. My current guesses: - Antivirus bugs. Are you running some AV program? Sometimes they interfere with other programs. - Permissions problems. I don't know why rJava would have had different permissions than the other packages you successfully updated, but if it did, that could be a cause. - Windows bug. R uses Windows services to move the temporary directory into place, and that's failing for no apparent reason. If you can follow Bill Dunlap's advice and monitor the process as it's taking place, you might be able to diagnose this, but I don't see a way to make any progress otherwise. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gc() reports bytes (MB) but uses notation for bits (Mb)
I am not a standards expert, but the notation here seems incorrect to me: gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 138668 7.5 650970 34.8 492193 26.3 Vcells 6668566 50.9 18582019 141.8 17001419 129.8 In the IEEE 1541-2002 document ( http://en.wikipedia.org/wiki/IEEE_1541-2002) the recommended notation for bytes is a capital B, whereas bits is either a lower case b, (or bits per IEC 60027-2) Both documents, while possibly in disagreement as to the prefix (e.g. M vs. Mi) agree that B is for bytes. gc's output is commonly considered confusing, or at least not overly obvious to many, but the notational confusion surely can't help. Additional link: http://physics.nist.gov/cuu/Units/binary.html Thanks, Jeff -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ranges and contiguity checking
Hi All, I am interfacing to some C libraries (hdf5) and I have methods defined for '[', these methods do hyperslab selection, however, currently I am limiting slab selection to contiguous blocks, i.e., things defined like: i:(i+k). I don't do any contiguity checking at this point, I just grab the max and min of the range and them potentially do an in-memory subselection which is what I am definitely trying to avoid. Besides using deparse, I can't see anyway to figure out that these things (i:(i+k) and c(i, i+1, ..., i+k)) are different. I have always liked how 1:10 was a valid expression in R (as opposed to python where it is not by itself.), however I'd somehow like to know that the thing was contiguous range without examining the un-evaluated expression or worse, all(diff(i:(i+k)) == 1) thanks, jim __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ranges and contiguity checking
On 12/05/2010 2:18 PM, James Bullard wrote: Hi All, I am interfacing to some C libraries (hdf5) and I have methods defined for '[', these methods do hyperslab selection, however, currently I am limiting slab selection to contiguous blocks, i.e., things defined like: i:(i+k). I don't do any contiguity checking at this point, I just grab the max and min of the range and them potentially do an in-memory subselection which is what I am definitely trying to avoid. Besides using deparse, I can't see anyway to figure out that these things (i:(i+k) and c(i, i+1, ..., i+k)) are different. I have always liked how 1:10 was a valid expression in R (as opposed to python where it is not by itself.), however I'd somehow like to know that the thing was contiguous range without examining the un-evaluated expression or worse, all(diff(i:(i+k)) == 1) You can implement all(diff(x) == 1) more efficiently in C, but I don't see how you could hope to do any better than that without putting very un-R-like restrictions on your code. Do you really want to say that A[i:(i+k)] is legal, but x - i:(i+k) A[x] is not? That will be very confusing for your users. The problem is that objects don't remember where they came from, only arguments to functions do, and functions that make use of this fact mainly do it for decorating the output (nice labels in plots) or making error messages more intelligible. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ranges and contiguity checking
-Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch Sent: Wednesday, May 12, 2010 11:35 AM To: bull...@stat.berkeley.edu Cc: r-de...@stat.math.ethz.ch Subject: Re: [Rd] ranges and contiguity checking On 12/05/2010 2:18 PM, James Bullard wrote: Hi All, I am interfacing to some C libraries (hdf5) and I have methods defined for '[', these methods do hyperslab selection, however, currently I am limiting slab selection to contiguous blocks, i.e., things defined like: i:(i+k). I don't do any contiguity checking at this point, I just grab the max and min of the range and them potentially do an in-memory subselection which is what I am definitely trying to avoid. Besides using deparse, I can't see anyway to figure out that these things (i:(i+k) and c(i, i+1, ..., i+k)) are different. I have always liked how 1:10 was a valid expression in R (as opposed to python where it is not by itself.), however I'd somehow like to know that the thing was contiguous range without examining the un-evaluated expression or worse, all(diff(i:(i+k)) == 1) You could define a sequence class, say 'hfcSeq' and insist that the indices given to [.hfc are hfcSeq objects. E.g., instead of hcf[i:(i+k)] the user would use hcf[hfcSeq(i,i+k)] or index - hcfSeq(i,i+k) hcf[index] max, min, and range methods for hcfSeq would just inspect one or both of its elements. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com You can implement all(diff(x) == 1) more efficiently in C, but I don't see how you could hope to do any better than that without putting very un-R-like restrictions on your code. Do you really want to say that A[i:(i+k)] is legal, but x - i:(i+k) A[x] is not? That will be very confusing for your users. The problem is that objects don't remember where they came from, only arguments to functions do, and functions that make use of this fact mainly do it for decorating the output (nice labels in plots) or making error messages more intelligible. Duncan Murdoch __ 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
[Rd] How to profile R interpreter?
Hi, all. Does anyone know how to profile R interpreter? I tried Rprof, which only gave me profiling information at script level. My intention is to identify hot spots in R interpreter. I compiled R interpreter with -pg for gprof. However, I couldn't generate gmon.out when I ran the R interpreter with a script. Thanks. Xiaoming [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ranges and contiguity checking
-Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch Sent: Wednesday, May 12, 2010 11:35 AM To: bull...@stat.berkeley.edu Cc: r-de...@stat.math.ethz.ch Subject: Re: [Rd] ranges and contiguity checking On 12/05/2010 2:18 PM, James Bullard wrote: Hi All, I am interfacing to some C libraries (hdf5) and I have methods defined for '[', these methods do hyperslab selection, however, currently I am limiting slab selection to contiguous blocks, i.e., things defined like: i:(i+k). I don't do any contiguity checking at this point, I just grab the max and min of the range and them potentially do an in-memory subselection which is what I am definitely trying to avoid. Besides using deparse, I can't see anyway to figure out that these things (i:(i+k) and c(i, i+1, ..., i+k)) are different. I have always liked how 1:10 was a valid expression in R (as opposed to python where it is not by itself.), however I'd somehow like to know that the thing was contiguous range without examining the un-evaluated expression or worse, all(diff(i:(i+k)) == 1) You could define a sequence class, say 'hfcSeq' and insist that the indices given to [.hfc are hfcSeq objects. E.g., instead of hcf[i:(i+k)] the user would use hcf[hfcSeq(i,i+k)] or index - hcfSeq(i,i+k) hcf[index] max, min, and range methods for hcfSeq would just inspect one or both of its elements. I could do this, but I wanted it to not matter to the user whether or not they were dealing with a HDF5Dataset or a plain-old matrix. It seems like I cannot define methods on: ':'. If I could do that then I could implement an immutable 'range' class which would be good, but then I'd have to also implement: '['(matrix, range) -- which would be easy, but still more work than I wanted to do. I guess I was thinking that there is some inherent value in an immutable native range type which is constant in time and memory for construction. Then I could define methods on '['(matrix, range) and '['(matrix, integer). I'm pretty confident this is more less what is happening in the IRanges package in Bioconductor, but (maybe for the lack of support for setting methods on ':') it is happening in a way that makes things very non-transparent to a user. As it stands, I can optimize for performance by using a IRange-type wrapper or I can optimize for code-clarity by killing performance. thanks again, jim Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com You can implement all(diff(x) == 1) more efficiently in C, but I don't see how you could hope to do any better than that without putting very un-R-like restrictions on your code. Do you really want to say that A[i:(i+k)] is legal, but x - i:(i+k) A[x] is not? That will be very confusing for your users. The problem is that objects don't remember where they came from, only arguments to functions do, and functions that make use of this fact mainly do it for decorating the output (nice labels in plots) or making error messages more intelligible. Duncan Murdoch __ 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] ranges and contiguity checking
Providing the wrapper would allow for both performance as well as
user-simplicity.
x[RANGE(1,1e6)] and x[1:1e6] could both be handled internally, where:
RANGE - function(from,to) {
structure(seq(from,to), class=RANGE)
}
Just testing for a 'RANGE' object in your [. method would let the
optimization be up to the end user.
The 'xts' package provides something similar with respect to subsetting by
time. We accept a character string conforming to ISO8601 style time ranges,
as well as standard classes that would be available to subset any other
matrix-like object.
The ISO way will get you fast binary searching over the time-index, whereas
using POSIX time is a linear search.
HTH
Jeff
On Wed, May 12, 2010 at 3:27 PM, James Bullard bull...@stat.berkeley.eduwrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
Sent: Wednesday, May 12, 2010 11:35 AM
To: bull...@stat.berkeley.edu
Cc: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] ranges and contiguity checking
On 12/05/2010 2:18 PM, James Bullard wrote:
Hi All,
I am interfacing to some C libraries (hdf5) and I have
methods defined for
'[', these methods do hyperslab selection, however, currently I am
limiting slab selection to contiguous blocks, i.e., things
defined like:
i:(i+k). I don't do any contiguity checking at this point,
I just grab the
max and min of the range and them potentially do an
in-memory subselection
which is what I am definitely trying to avoid. Besides
using deparse, I
can't see anyway to figure out that these things (i:(i+k)
and c(i, i+1,
..., i+k)) are different.
I have always liked how 1:10 was a valid expression in R
(as opposed to
python where it is not by itself.), however I'd somehow
like to know that
the thing was contiguous range without examining the un-evaluated
expression or worse, all(diff(i:(i+k)) == 1)
You could define a sequence class, say 'hfcSeq'
and insist that the indices given to [.hfc are
hfcSeq objects. E.g., instead of
hcf[i:(i+k)]
the user would use
hcf[hfcSeq(i,i+k)]
or
index - hcfSeq(i,i+k)
hcf[index]
max, min, and range methods for hcfSeq
would just inspect one or both of its
elements.
I could do this, but I wanted it to not matter to the user whether or not
they were dealing with a HDF5Dataset or a plain-old matrix.
It seems like I cannot define methods on: ':'. If I could do that then I
could implement an immutable 'range' class which would be good, but then
I'd have to also implement: '['(matrix, range) -- which would be easy, but
still more work than I wanted to do.
I guess I was thinking that there is some inherent value in an immutable
native range type which is constant in time and memory for construction.
Then I could define methods on '['(matrix, range) and '['(matrix,
integer). I'm pretty confident this is more less what is happening in the
IRanges package in Bioconductor, but (maybe for the lack of support for
setting methods on ':') it is happening in a way that makes things very
non-transparent to a user. As it stands, I can optimize for performance by
using a IRange-type wrapper or I can optimize for code-clarity by killing
performance.
thanks again, jim
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
You can implement all(diff(x) == 1) more efficiently in C,
but I don't
see how you could hope to do any better than that without
putting very
un-R-like restrictions on your code. Do you really want to say that
A[i:(i+k)]
is legal, but
x - i:(i+k)
A[x]
is not? That will be very confusing for your users. The problem is
that objects don't remember where they came from, only arguments to
functions do, and functions that make use of this fact mainly
do it for
decorating the output (nice labels in plots) or making error messages
more intelligible.
Duncan Murdoch
__
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
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.11.0 on RHEL5 / RODBC
I am compiling R 2.11.0 on a RHEL5.3 box using the following settings ./configure --with-readline=yes --enable-R-shlib=yes --with-x=yes --with-blas=-llibptf77blas -lpthread -llibatlas --prefix=/usr/local/R-2.11.0 JAVA_HOME=$JAVA_HOME CPPFLAGS=-I/usr/local/unixODBC-2.3.0/include I have compiled and installed unixODBC-2.3.0 (64-bit) in /usr/local and can connect to and query the database using isql. When I try to build RODBC, I get the following error: checking for sqlext.h... yes checking for library containing SQLTables... no configure: error: no ODBC driver manager found ERROR: configuration failed for package âRODBCâ * removing â/usr/local/R-2.11.0/lib64/R/library/RODBCâ The directory /usr/local/unixODBC-2.3.0/lib has the files libodbc.so and libodbc.la, and LD_LIBRARY_PATH has /usr/local/lib64:/usr/lib64:/usr/local/unixODBC-2.3.0/lib. Also, there is no other unixODBC version on the box. I would appreciate any help in this regard. Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
