[Rd] Browse option to change working directory (PR#10537)
Full_Name: Merrick McCracken Version: 2.6.1 OS: Vista Home Premium 32-bit Submission from: (NULL) (63.239.240.2) In the R GUI I select File>Change dir... to change the working directory and select browse and the only folders available to select are those on the Desktop and none others. I am running in Windows Vista. If I were to select Load Workspace... or Source R Code... I can browse freely through my hard drive but with the Browse option in Change dir... I cannot. Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Browse option to change working directory (PR#10537)
This is the same as PR#9959, a known Vista bug. It is documented under ?choose.dir. On Sun, 30 Dec 2007, [EMAIL PROTECTED] wrote: > Full_Name: Merrick McCracken > Version: 2.6.1 > OS: Vista Home Premium 32-bit > Submission from: (NULL) (63.239.240.2) > > > In the R GUI I select File>Change dir... to change the working directory and > select browse and the only folders available to select are those on the > Desktop > and none others. I am running in Windows Vista. If I were to select Load > Workspace... or Source R Code... I can browse freely through my hard drive but > with the Browse option in Change dir... I cannot. Thanks. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readBin differences on Windows and Linux/mac
I have been trying to use the gunzip function in the R.utils package. It opens a connection to a gzfile, uses readBin to read from that connection, and then uses writeBin to write out the raw data to a new file. This works as expected under linux/mac, but under Windows, I get: Error in readBin(inn, what= raw(0), size = 1, n=BFR.SIZE) : negative length vectors are not allowed A simple traceback shows the error in readBin. I wouldn't be surprised if this is a programming issue not located in readBin, but I am confused about the difference in behaviors on Windows versus mac/linux. Any insight into what I can do to remedy the issue and have a cross-platform gunzip()? Thanks, Sean [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readBin differences on Windows and Linux/mac
Can you give a reproducible example, pelase? Uwe Ligges Sean Davis wrote: > I have been trying to use the gunzip function in the R.utils package. It > opens a connection to a gzfile, uses readBin to read from that connection, > and then uses writeBin to write out the raw data to a new file. This works > as expected under linux/mac, but under Windows, I get: > > Error in readBin(inn, what= raw(0), size = 1, n=BFR.SIZE) : > negative length vectors are not allowed > > A simple traceback shows the error in readBin. I wouldn't be surprised if > this is a programming issue not located in readBin, but I am confused about > the difference in behaviors on Windows versus mac/linux. Any insight into > what I can do to remedy the issue and have a cross-platform gunzip()? > > Thanks, > Sean > > [[alternative HTML version deleted]] > > __ > 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] readBin differences on Windows and Linux/mac
Sorry, Uwe. Of course:
Both in relatively recent R-devel (one mac, one windows):
### gunzip pulled from R.utils to be a simple function
### In R.utils, implemented as a method
gunzip <- function(filename, destname=gsub("[.]gz$", "", filename),
overwrite=FALSE, remove=TRUE, BFR.SIZE=1e7) {
if (filename == destname)
stop(sprintf("Argument 'filename' and 'destname' are identical: %s",
filename));
if (!overwrite && file.exists(destname))
stop(sprintf("File already exists: %s", destname));
inn <- gzfile(filename, "rb");
on.exit(if (!is.null(inn)) close(inn));
out <- file(destname, "wb");
on.exit(close(out), add=TRUE);
nbytes <- 0;
repeat {
bfr <- readBin(inn, what=raw(0), size=1, n=BFR.SIZE);
n <- length(bfr);
if (n == 0)
break;
nbytes <- nbytes + n;
writeBin(bfr, con=out, size=1);
};
if (remove) {
close(inn);
inn <- NULL;
file.remove(filename);
}
invisible(nbytes);
}
download.file('
ftp://ftp.ncbi.nih.gov/pub/geo/DATA/SeriesMatrix/GSE1/GSE1_series_matrix.txt.gz','test.txt.gz'
)
gunzip('test.txt.gz')
Under windows, this results in the error reported below. Under mac and
linux, results in test.txt being created in the current working directory.
The actual gunzip function is pretty bare bones, so I don't think it
complicates matters much to use it in this example.
Sean
On Dec 31, 2007 1:24 PM, Uwe Ligges <[EMAIL PROTECTED]>
wrote:
> Can you give a reproducible example, pelase?
>
> Uwe Ligges
>
>
> Sean Davis wrote:
> > I have been trying to use the gunzip function in the R.utils package.
> It
> > opens a connection to a gzfile, uses readBin to read from that
> connection,
> > and then uses writeBin to write out the raw data to a new file. This
> works
> > as expected under linux/mac, but under Windows, I get:
> >
> > Error in readBin(inn, what= raw(0), size = 1, n=BFR.SIZE) :
> > negative length vectors are not allowed
> >
> > A simple traceback shows the error in readBin. I wouldn't be surprised
> if
> > this is a programming issue not located in readBin, but I am confused
> about
> > the difference in behaviors on Windows versus mac/linux. Any insight
> into
> > what I can do to remedy the issue and have a cross-platform gunzip()?
> >
> > Thanks,
> > Sean
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load'ed code
On Sun, Dec 30, 2007 at 10:43:50PM -0500, Matt Calder wrote: > Simon, > Thanks for the reply. Indeed, declaring the function static fixes the > example. Unfortunately, the real problem that gave rise to the example > arises in a large Fortran library that is not under my control (ARPACK). > The author is providing BLAS and LAPACK functionality intentionally. > That may or may not be good practice, but it is a given in this case. Ok, so R is calling its one "dnrm2_" function, let's call this "A", while ARPACK defines a second, different "dnrm2_", which we'll call "B". You want to call function A from your own C code, while R keeps calling function A as before without any change or interference. And of course, A and B are two C-coded functions with different behaviors but the exact same name. You can make that work, it just requires some tricks. > I still feel like the linker ought to be able to solve this problem for > me. My impression was that the static keyword passed to the linker It can, you just need to tell it exactly what you want. I assume you are building your own custom C code into a shared library, which you then load into R. Thus, one solution is to statically link the ARPACK library into your own shared library, and then carefully tell the linker which symbols to export and which to keep private inside your shared library. As long as the symbol ARPACK's "B" dnrm2_ function is kept private inside your own shared library (not exported), R will never see it and will happily keep using dnrm2_ "A" as before. That's how I've solved this sort of name collision problem in the past. In your "src/Makevars", you may want something like to this: PKG_LIBS = -Wl,--version-script=vis.map -Wl,-Bstatic -L/usr/local/lib/ARPACK -lARPACK -Wl,-Bdynamic You may also need a PG_PKG_LIBS with the same stuff, but I don't remember why. The '--version-script=' and related matters were also disccussed here back in February: https://stat.ethz.ch/pipermail/r-devel/2007-February/044531.html -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
