Re: [Rd] Does R use "computed gotos" - a gcc extension of C?
On Fri, 4 Mar 2011, Dr. David Kirkby wrote: The R manual says R will not build with gcc on 64-bit Solaris x86 with gcc http://cran.r-project.org/doc/manuals/R-admin.html#Solaris "Tests with gcc32 on ‘x86’ and ‘amd64’ have been less successful: ‘x86’ builds have failed on tests using complex arithmetic33, whereas on ‘amd64’ the builds have failed to complete in several different ways, most recently with relocation errors for libRblas.so. " I know what the "relocation errors" problem is. That library (and in fact two other R libraries) all have non-PIC code in them, despite the fact the source is compiled with the -fPIC option. http://blogs.sun.com/rie/entry/my_relocations_don_t_fit shows how to prove this. If one runs this command on Solaris: $ elfdump -d libRblas.so | fgrep TEXTREL there is some output showing that theres non-PIC code present in the R library. R is compiled with -fPIC on Solaris, but certain things can cause non-PIC code to be generated even with that option. One is by the use of "computed gotos" which is a gcc extension. I'm wondering if R uses any of these. Yes -- in the byte code interpreter in eval.c luke I'd love to track down this problem, so R can build with gcc. R is used in the Sage maths project http://www.sagemath.org/ and R is the only component of Sage which will not build with gcc on 64-bit Solaris x86. Many components will not build with Sun Studio, but this R issue means we need to have two compilers, not just one. -- Luke Tierney Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: l...@stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Does R use "computed gotos" - a gcc extension of C?
The R manual says R will not build with gcc on 64-bit Solaris x86 with gcc http://cran.r-project.org/doc/manuals/R-admin.html#Solaris "Tests with gcc32 on ‘x86’ and ‘amd64’ have been less successful: ‘x86’ builds have failed on tests using complex arithmetic33, whereas on ‘amd64’ the builds have failed to complete in several different ways, most recently with relocation errors for libRblas.so. " I know what the "relocation errors" problem is. That library (and in fact two other R libraries) all have non-PIC code in them, despite the fact the source is compiled with the -fPIC option. http://blogs.sun.com/rie/entry/my_relocations_don_t_fit shows how to prove this. If one runs this command on Solaris: $ elfdump -d libRblas.so | fgrep TEXTREL there is some output showing that theres non-PIC code present in the R library. R is compiled with -fPIC on Solaris, but certain things can cause non-PIC code to be generated even with that option. One is by the use of "computed gotos" which is a gcc extension. I'm wondering if R uses any of these. I'd love to track down this problem, so R can build with gcc. R is used in the Sage maths project http://www.sagemath.org/ and R is the only component of Sage which will not build with gcc on 64-bit Solaris x86. Many components will not build with Sun Studio, but this R issue means we need to have two compilers, not just one. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Minor typo in "Writing R Extensions"
In "Writing R Extensions", section 1.1.1, the paragraph talking about
the Depends field has an extra right parenthesis at the end of the
second sentence (or is missing a left parenthesis somewhere). This is
on line 392 of R-exts.texi (revision 54667). I have attached a diff,
thought I don't know if it will go through.
I don't know if R-devel is the right place to send this, but I didn't
see an email address to send corrections on the documentation.
--
Brian S. Diggs, PhD
Senior Research Associate, Department of Surgery
Oregon Health & Science University
Index: R-exts.texi
===
--- R-exts.texi (revision 54667)
+++ R-exts.texi (working copy)
@@ -389,7 +389,7 @@
contain a comparison operator@footnote{only @samp{>=} and @samp{<=} were
supported prior to @R{} 2.7.0, and only @samp{>=} is supported for
package versions by @code{install.packages}.}, whitespace and a valid
-version number). You can also use the special package name @samp{R} if
+version number. You can also use the special package name @samp{R} if
your package depends on a certain version of @R{} --- e.g., if the
package works only with @R{} version 2.11.0 or later, include @samp{R
(>= 2.11.0)} in the @samp{Depends} field. Both @code{library} and the
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fixing the HDF5 package: the on.exit mystery
Looks like you should be using finalizers instead. See the RODBC
package for an example of this.
On Fri, 4 Mar 2011, H C Pumphrey wrote:
Dear all,
I'm trying to fix a subtle bug in the hdf5 package. This package provides an
interfaces to the HDF5 library and hence allows one to load data into R from
files in the HDF5 format. The bug appeared during a period in which R changed
but the package did not.
I include below both the R and C code, stripped of everything except what is
needed to show the bug. What is supposed to happen is
(*) the user calls R function hdf5load()
(*) hdf5load() calls C function do_hdf5load()
(*) do_hdf5load() opens the HDF5 file recording its HDF5 file id (fid)
(*) do_hdf5load() calls C function setup_onexit, passing fid to it
(*) setup_onexit sets up the on.exit call to be R function hdf5cleanup with
fid as its argument
(*) C function do_hdf5load() walks the HDF5 file's tree structure of groups
of groups of [...] of datasets, mapping them to an R list of lists of [...]
of array variables. This recursive procedure may have a variety of exit
points buried inside itself.
(*) C function do_hdf5load() exits for some reason. R function hdf5load()
therefore exits but before doing so it calls its on.exit code (which is
hdf5cleanup(fid) with the right value of fid), closing the file.
The problem is that when do_hdf5load() and hdf5load() exit, hdf5cleanup() is
usually not called, meaning that the file is left open. You might not notice
this, but if you are processing a few year's worth of data, which is stored
at 1 file per day, you may end up with the system limit number of files open
and be unable to open any more.
I have a suspicion that the problem dates to a change in R at 2.8.0. If you
do help(on.exit) it notes under "Details" that: "Where ‘expr’ was evaluated
changed in R 2.8.0 ..." But it is not clear how I should modify the C code to
force hdf5cleanup() to be reliably called when do_hdf5load() exits.
Any help appreciated.
Hugh (possibly the nearest thing to a maintainer that the hdf5 package
currently has)
(R and C code follow)
#
"hdf5load" <- function (file, load = TRUE, verbosity = 0, tidy = FALSE)
{
call <- sys.call()
.External("do_hdf5load", call, sys.frame(sys.parent()), file, load,
as.integer (verbosity), as.logical(tidy),
PACKAGE="hdf5")
}
"hdf5cleanup" <- function (fid)
{
call <- sys.call()
print("In hdf5cleanup: calling do_hdf5cleanup")
invisible(.External("do_hdf5cleanup", call, sys.frame(sys.parent()), fid,
PACKAGE="hdf5"))
}
#
/*---*/
SEXP do_hdf5load (SEXP args)
{
/* Code to process args snipped */
if ((fid = H5Fopen (path, H5F_ACC_RDONLY, H5P_DEFAULT)) < 0)
errorcall (call, "unable to open HDF file: %s", path);
setup_onexit (fid, env);
/* Messy code to walk tree structure of file snipped */
}
/* The following function shown in its entirety */
setup_onexit (hid_t fid, SEXP env)
{
eval (lang2 (install ("on.exit"),
lang2 (install ("hdf5cleanup"),
ScalarInteger (fid))),
env);
}
SEXP
do_hdf5cleanup (SEXP args)
{
/* Code to process args snipped */
/* various cleanup things done including this: */
H5Fclose(fid)
}
/*---*/
--
Brian D. Ripley, rip...@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, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R-2.13 r54645 on Windows
On Fri, Mar 4, 2011 at 10:53 AM, Dan Tenenbaum wrote: > On Thu, Mar 3, 2011 at 10:50 AM, Dan Tenenbaum wrote: >> I am building R-2.13 r54645 from source as described here: >> http://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source >> The "make all recommended" command ends as follows on both 32 and 64-bit >> Windows (Windows Server 2003 R2 Enterprise Edition Service Pack 2 and >> Windows Server 2008 R2 Enterprise): >> gcc -std=gnu99 -I../../include -DHAVE_CONFIG_H -O3 -Wall -pedantic -c >> zutil.c -o z >> o >> make[4]: *** No rule to make target `Rzlib.def', needed by `Rzlib.dll'. >> Stop. >> make[3]: *** [rlibs] Error 1 >> make[2]: *** [../../bin/i386/R.dll] Error 2 >> make[1]: *** [rbuild] Error 2 >> make: *** [all] Error 2 > > It looks like somebody worked on this--thanks. > However, now I am getting: > > > --- Making recommended packages > make[1]: *** No rule to make target `MASS.ts', needed by > `stamp-recommended'. Stop. > make: *** [recommended] Error 2 > > Can you help? > Never mind, this last bit was my own fault--I overlooked a step in the build process. The original issue has been fixed, so I'm happy now. Thanks Brian! Dan Thanks > Dan > > >> Thanks >> Dan >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R-2.13 r54645 on Windows
On Thu, Mar 3, 2011 at 10:50 AM, Dan Tenenbaum wrote: > I am building R-2.13 r54645 from source as described here: > http://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source > The "make all recommended" command ends as follows on both 32 and 64-bit > Windows (Windows Server 2003 R2 Enterprise Edition Service Pack 2 and > Windows Server 2008 R2 Enterprise): > gcc -std=gnu99 -I../../include -DHAVE_CONFIG_H -O3 -Wall -pedantic -c > zutil.c -o z > o > make[4]: *** No rule to make target `Rzlib.def', needed by `Rzlib.dll'. > Stop. > make[3]: *** [rlibs] Error 1 > make[2]: *** [../../bin/i386/R.dll] Error 2 > make[1]: *** [rbuild] Error 2 > make: *** [all] Error 2 It looks like somebody worked on this--thanks. However, now I am getting: --- Making recommended packages make[1]: *** No rule to make target `MASS.ts', needed by `stamp-recommended'. Stop. make: *** [recommended] Error 2 Can you help? Thanks Dan > Thanks > Dan > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] removing files on windows as part of vignette building
This is about the Bioconductor package Genominator. As part of the vignette building process, we create two sizable sqlite3 databases, in the vignette directory (inst/doc). When we build the source tarball, these databases are deleted, but when a Windows binary is being made on the Bioconductor build servers the file(s) are not removed (as far as I read the documentation/code they ought to be). If I try to remove them explicitly, by including a Makefile with a target clean: rm -rf Rplots.pdf my.db pmy.db (there are two databases), it fails with the error message rm: cannot remove `Rplots.pdf': Device or resource busy rm: cannot remove `my.db': Device or resource busy rm: cannot remove `pmy.db': Device or resource busy make: *** [all] Error 1 Error in tools::buildVignettes(dir = ".") : running 'make' failed Execution halted Note that (1) This did not happen under R-2.11 (2) It does not happen under Linux or OS X. I believe this is a general phenomenon of no cleanup on windows. If I look at the affy package from Bioconductor, the windows binary has a file doc/Rplots.pdf that is not present inside inst/doc in the source tarball. I have not been able to find a package on CRAN with a vignette with plots in it, that did also include the pdf version of the vignette or where Rplots.pdf was not also included in the source tarball, so this may be an issue specific to the Bioconductor build system. I guess an alternative to creating the database inside inst/doc is to use a tempfile. Comments? Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Extending type list: names and inherited methods issue
Hi,
I want to extend the type list, but it looks like the names are not
handled properly (in the show method), not the [ method. See below for
code example.
I imagine this comes from the S3/S4 mixing, but I would like to
understand and the recommended work around (that avoid redefining all
the list methods [, $, etc...).
Thank you.
Bests,
Renaud
# define S4 class that inherits from list
setClass('A', contains='list')
# nothing to say when one creates an object with an unnamed list
x <- new('A', list(1,2,3))
x
# set the names: seems ok but they are not printed
names(x) <- letters[1:3]
names(x)
x
# same thing if one put the S3 .Data slot
names(x@.Data) <- letters[4:6]
names(x)
x
# the subsetting works but returns a list instead of the expected object
of class A
class(x[1])
> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_ZA.utf8 LC_NUMERIC=C
LC_TIME=en_ZA.utf8LC_COLLATE=en_ZA.utf8
LC_MONETARY=C LC_MESSAGES=en_ZA.utf8LC_PAPER=en_ZA.utf8
[8] LC_NAME=C LC_ADDRESS=C
LC_TELEPHONE=CLC_MEASUREMENT=en_ZA.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Renaud Gaujoux
Computational Biology - University of Cape Town
South Africa
###
UNIVERSITY OF CAPE TOWN
This e-mail is subject to the UCT ICT policies and e-mai...{{dropped:5}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fixing the HDF5 package: the on.exit mystery
Dear all,
I'm trying to fix a subtle bug in the hdf5 package. This package provides an
interfaces to the HDF5 library and hence allows one to load data into R from
files in the HDF5 format. The bug appeared during a period in which R changed
but the package did not.
I include below both the R and C code, stripped of everything except what is
needed to show the bug. What is supposed to happen is
(*) the user calls R function hdf5load()
(*) hdf5load() calls C function do_hdf5load()
(*) do_hdf5load() opens the HDF5 file recording its HDF5 file id (fid)
(*) do_hdf5load() calls C function setup_onexit, passing fid to it
(*) setup_onexit sets up the on.exit call to be R function hdf5cleanup with
fid as its argument
(*) C function do_hdf5load() walks the HDF5 file's tree structure of groups
of groups of [...] of datasets, mapping them to an R list of lists of [...] of
array variables. This recursive procedure may have a variety of exit points
buried inside itself.
(*) C function do_hdf5load() exits for some reason. R function hdf5load()
therefore exits but before doing so it calls its on.exit code (which is
hdf5cleanup(fid) with the right value of fid), closing the file.
The problem is that when do_hdf5load() and hdf5load() exit, hdf5cleanup() is
usually not called, meaning that the file is left open. You might not notice
this, but if you are processing a few year's worth of data, which is stored at
1 file per day, you may end up with the system limit number of files open and
be unable to open any more.
I have a suspicion that the problem dates to a change in R at 2.8.0. If you do
help(on.exit) it notes under "Details" that: "Where ‘expr’ was evaluated
changed in R 2.8.0 ..." But it is not clear how I should modify the C code to
force hdf5cleanup() to be reliably called when do_hdf5load() exits.
Any help appreciated.
Hugh (possibly the nearest thing to a maintainer that the hdf5 package
currently has)
(R and C code follow)
#
"hdf5load" <- function (file, load = TRUE, verbosity = 0, tidy = FALSE)
{
call <- sys.call()
.External("do_hdf5load", call, sys.frame(sys.parent()), file, load,
as.integer (verbosity), as.logical(tidy),
PACKAGE="hdf5")
}
"hdf5cleanup" <- function (fid)
{
call <- sys.call()
print("In hdf5cleanup: calling do_hdf5cleanup")
invisible(.External("do_hdf5cleanup", call, sys.frame(sys.parent()), fid,
PACKAGE="hdf5"))
}
#
/*---*/
SEXP do_hdf5load (SEXP args)
{
/* Code to process args snipped */
if ((fid = H5Fopen (path, H5F_ACC_RDONLY, H5P_DEFAULT)) < 0)
errorcall (call, "unable to open HDF file: %s", path);
setup_onexit (fid, env);
/* Messy code to walk tree structure of file snipped */
}
/* The following function shown in its entirety */
setup_onexit (hid_t fid, SEXP env)
{
eval (lang2 (install ("on.exit"),
lang2 (install ("hdf5cleanup"),
ScalarInteger (fid))),
env);
}
SEXP
do_hdf5cleanup (SEXP args)
{
/* Code to process args snipped */
/* various cleanup things done including this: */
H5Fclose(fid)
}
/*---*/
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
