headers
Uwe Ligges | 1 Jan 2008 16:51
Picon
Picon

Re: [Rd] readBin differences on Windows and Linux/mac

I see. It is either a bug or something related to the following 
paragraph from ?seek:

      We have found so many errors in the Windows implementation of file
      positioning that users are advised to use it only at their own
      risk, and asked not to waste the R developers' time with bug
      reports on Windows' deficiencies.

I will investigate more closely when I am back in office end of this week.

Best,
Uwe

Sean Davis wrote:
> 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));
(Continue reading)

Permalink | Reply | 4 comments |
headers
Henrik Bengtsson | 1 Jan 2008 17:10
Picon

Re: [Rd] readBin differences on Windows and Linux/mac

Also make sure the problem is not due to downloading a gzip file in
text mode, because to the best of my understanding that is platform
dependent.  That is, use download.file(..., mode="wb") instead of the
default, which is mode="w".  (This is such a common error that I would
like to suggest mode="wb" to become the default.)

/Henrik

On 01/01/2008, Uwe Ligges <ligges <at> statistik.uni-dortmund.de> wrote:
> I see. It is either a bug or something related to the following
> paragraph from ?seek:
>
>       We have found so many errors in the Windows implementation of file
>       positioning that users are advised to use it only at their own
>       risk, and asked not to waste the R developers' time with bug
>       reports on Windows' deficiencies.
>
> I will investigate more closely when I am back in office end of this week.
>
> Best,
> Uwe
>
>
>
>
> Sean Davis wrote:
> > Sorry, Uwe.  Of course:
> >
> > Both in relatively recent R-devel (one mac, one windows):
> >
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henrik Bengtsson | 1 Jan 2008 17:20
Picon

Re: [Rd] readBin differences on Windows and Linux/mac

On 01/01/2008, Henrik Bengtsson <hb <at> stat.berkeley.edu> wrote:
> Also make sure the problem is not due to downloading a gzip file in
> text mode, because to the best of my understanding that is platform
> dependent.  That is, use download.file(..., mode="wb") instead of the
> default, which is mode="w".  (This is such a common error that I would
> like to suggest mode="wb" to become the default.)

Ok, that solves the problem with your example file.   On WinXP/R v2.6.1:

> library(R.utils)
> uri <- "ftp://ftp.ncbi.nih.gov/pub/geo/DATA/SeriesMatrix/GSE1/GSE1_series_matrix.txt.gz"

> download.file(uri, "test.txt.gz")  # mode="w"
trying URL 'ftp://ftp.ncbi.nih.gov/pub/geo/DATA/SeriesMatrix/GSE1/GSE1_series_ma
trix.txt.gz'
ftp data connection made, file length 918804 bytes
opened URL
downloaded 897 Kb
> file.info("test.txt.gz")$size
[1] 922243

> download.file(uri, "test2.txt.gz")
ftp data connection made, file length 918804 bytes
opened URL
downloaded 897 Kb
> file.info("test2.txt.gz")$size
[1] 918804

> gunzip("test.txt.gz")
Error in readBin(inn, what = raw(0), size = 1, n = BFR.SIZE) :
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matt Calder | 1 Jan 2008 18:08
Picon

Re: [Rd] Problem with dyn.load'ed code

Andrew,
	Thanks! The version script worked like a charm. Specifically I now
build using:

g++ -shared -Wl,--version-script=ver.map to_dyn_load.cc -o to_dyn_load.so -larpack

where ver.map is the file:

{
     global: R_func_*;
     local:*;
};

and any function I want exported to R is named R_func_*. This is going
to be my new SOP. 
	Thanks again Andrew, and also Simon. I greatly appreciate you taking
your time to solve this problem for me.

	Matt

	
On Mon, 2007-12-31 at 15:30 -0500, Andrew Piskorski wrote:
> 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.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Uwe Ligges | 1 Jan 2008 18:36
Picon
Picon

Re: [Rd] readBin differences on Windows and Linux/mac

Thank you, Henrik! This saves us a lot of time!

Uwe

Henrik Bengtsson wrote:
> On 01/01/2008, Henrik Bengtsson <hb <at> stat.berkeley.edu> wrote:
>> Also make sure the problem is not due to downloading a gzip file in
>> text mode, because to the best of my understanding that is platform
>> dependent.  That is, use download.file(..., mode="wb") instead of the
>> default, which is mode="w".  (This is such a common error that I would
>> like to suggest mode="wb" to become the default.)
> 
> Ok, that solves the problem with your example file.   On WinXP/R v2.6.1:
> 
>> library(R.utils)
>> uri <- "ftp://ftp.ncbi.nih.gov/pub/geo/DATA/SeriesMatrix/GSE1/GSE1_series_matrix.txt.gz"
> 
>> download.file(uri, "test.txt.gz")  # mode="w"
> trying URL 'ftp://ftp.ncbi.nih.gov/pub/geo/DATA/SeriesMatrix/GSE1/GSE1_series_ma
> trix.txt.gz'
> ftp data connection made, file length 918804 bytes
> opened URL
> downloaded 897 Kb
>> file.info("test.txt.gz")$size
> [1] 922243
> 
>> download.file(uri, "test2.txt.gz")
> ftp data connection made, file length 918804 bytes
> opened URL
> downloaded 897 Kb
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sean Davis | 1 Jan 2008 18:54
Picon

Re: [Rd] readBin differences on Windows and Linux/mac

On Jan 1, 2008 12:36 PM, Uwe Ligges <ligges <at> statistik.uni-dortmund.de>
wrote:

> Thank you, Henrik! This saves us a lot of time!
>
> Uwe
>
>
> Henrik Bengtsson wrote:
> > On 01/01/2008, Henrik Bengtsson <hb <at> stat.berkeley.edu> wrote:
> >> Also make sure the problem is not due to downloading a gzip file in
> >> text mode, because to the best of my understanding that is platform
> >> dependent.  That is, use download.file(..., mode="wb") instead of the
> >> default, which is mode="w".  (This is such a common error that I would
> >> like to suggest mode="wb" to become the default.)
>

Great!!  Thanks, Henrik and Uwe.

Sean

	[[alternative HTML version deleted]]

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 0 comments |
headers
Simon Urbanek | 1 Jan 2008 19:33
Favicon

Re: [Rd] Problem with dyn.load'ed code

Matt,

On Jan 1, 2008, at 12:08 PM, Matt Calder wrote:

> Andrew,
> 	Thanks! The version script worked like a charm. Specifically I now
> build using:
>
> g++ -shared -Wl,--version-script=ver.map to_dyn_load.cc -o  
> to_dyn_load.so -larpack
>

just a word of warning - this is in no way portable. It is probably ok  
for your private compilation, but it won't work in general. In any  
case, I'd strongly recommend enabling this hack only if you know that  
the target system supports it for the sake of portability. However, if  
you are concerned about the latter, you should probably have a look at  
libtool and --export-symbols - it allows you to control the visibility  
on most systems that support it.
Note that there are systems that don't support it at all.

Cheers,
Simon

> where ver.map is the file:
>
> {
>     global: R_func_*;
>     local:*;
> };
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gabor Grothendieck | 1 Jan 2008 20:59
Picon

[Rd] Wish List

Most of the items on this list have been mentioned before but it
may be useful to see them altogether and at any rate every year
I have posted my R wishlist at the beginning of the year.

High priority items pertain to the foundations of R (promises,
environments) since those form the basis of everything
else and the foundation needs to be looked after first.

The medium items are focused on scripting since with a few additional
features R could work more smoothly with other software.

For the Low priority items we listed the rest.  They are not necessarily
low in terms of desirability but I wanted to focus the high and
medium items on foundations and scripting.

There is also a section at the end focusing on addon packages.
These may be strictly speaking part of R but are widely used.

High

1. Some way of inspecting promises.  It is possible to get
the expression associated with a promise using substitute but
not its environment.  Also need a way to copy a promise without
forcing it.  See:
https://stat.ethz.ch/pipermail/r-devel/2007-September/046966.html

2. Fix bug when promises are stored in lists:

    f <- function(x) environment()
    as.list(f(0))$x == 0 # gives error.  Should be TRUE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Huber | 1 Jan 2008 22:53
Picon
Picon
Favicon

[Rd] Error from wilcox.test

When one of the two groups has only one member and the other one more 
than 49, wilcox.test will exit with the below error message,

  n=51; wilcox.test(1:n ~ 1:n==1, conf.int=TRUE)

  Error in uniroot(wdiff, c(mumin, mumax), tol = 1e-04, zq = 
qnorm(alpha/2,  :
   f() values at end points not of opposite sign

whereas with n=50 a result is returned:

  n=50; wilcox.test(1:n ~ 1:n==1, conf.int=TRUE)

         Wilcoxon rank sum test

data:  1:n by 1:n == 1
W = 49, p-value = 0.04
alternative hypothesis: true location shift is not equal to 0
95 percent confidence interval:
   1 49
sample estimates:
difference in location
                     25

I wonder whether it would be worthwhile to make the wilcox.test function 
handle such (admittedly pathologic) cases more gracefully.

Happy New Year to all -
   Wolfgang
(Continue reading)

Permalink | Reply | 2 comments |
headers
Prof Brian Ripley | 2 Jan 2008 07:59
Picon
Picon
Favicon

Re: [Rd] large netCDF files under Windows.

For the record: Thomas provided a test case and both ncdf and RNetCDF have 
been rebuilt with support for files > 2Gb.  Updated versions are now on 
the CRANextras repository.

On Sun, 30 Dec 2007, Prof Brian Ripley wrote:

> The netcdf code is rather silly: it uses 64-bit versions of seek etc when
> building a DLL, not on Windows.  I can rebuild it using 64-bit seek, but
> could you please send me (privately) a test case?
>
> On Sat, 29 Dec 2007, Thomas Lumley wrote:
>
>> Has anyone successfully used R to access netCDF files larger than 2Gb
>> under Windows?
>>
>> With the version of the ncdf package that Brian Ripley provides for CRAN
>> extras I get an assertion failure with a 12Gb file, but not a 1Gb subset
>> of it. The same 12Gb file is ok with ncdf on Mac OS X (32bit R) and on
>> Linux(64bit R).

--

-- 
Brian D. Ripley,                  ripley <at> stats.ox.ac.uk
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, UK                Fax:  +44 1865 272595

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
(Continue reading)

Permalink | Reply | 0 comments |

Gmane