Re: [Rd] R CMD build --resave-data
> Hervé Pagès
> on Tue, 12 Apr 2011 22:21:58 -0700 writes:
> On 11-04-12 07:06 PM, Simon Urbanek wrote:
>>
>> On Apr 12, 2011, at 8:53 PM, Hervé Pagès wrote:
>>
>>> Hi Uwe,
>>>
>>> On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
> Hi,
>
> More about the new --resave-data option
>
> As mentioned previously here
>
> https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
>
> 'R CMD build' and 'R CMD INSTALL' handle this new option
> inconsistently. The former does --resave-data="gzip" by
> default. The latter doesn't seem to support the
> --resave-data= syntax: the --resave-data flag must either be
> present or not. And by default 'R CMD INSTALL' won't resave
> the data.
>
> Also, because now 'R CMD build' is resaving the data,
> shouldn't it reinstall the package in order to be able to do
> this correctly?
>
> Here is why. There is this new warning in 'R CMD check' that
> complains about files not of a type allowed in a 'data'
> directory:
>
>
>
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
>
>
>
> The Icens package also has .R files under data/ with things
> like:
>
> bet<- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
>
> i.e. the R code needs to access some of the text files
> located in the data/ folder. So in order to get rid of this
> warning I tried to move those text files to inst/extdata/
> and I modified the code in the .R file so it does:
>
> CMVdata_filepath<- system.file("extdata", "CMVdata",
> package="Icens") bet<- matrix(scan(CMVdata_filepath,
> quiet=TRUE),nc=5,byr=TRUE)
>
> But now 'R CMD build' fails to resave the data because the
> package was not installed first and the CMVdata file could
> not be found.
>
> Unfortunately, for a lot of people that means that the safe
> way to build a source tarball now is with
>
> R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a
CRAN maintainer's point of view:
--keep-empty-dirs: we found many packages containing empty
dirs unnecessarily and the idea is to exclude them at the
build state rather than at the later installation stage. Note
that the package maintainer is supposed to run build (and
knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data: We found many packages with unsufficiently
compressed data. This should be fixed when building the
package, not later when installing it, since the reduces size
is useful in the source tarball already.
So it does make some sense to have different defaults in
build as opposed to INSTALL from my point of view (although I
could live with different, tough).
>>>
>>> If you deliberately ignore the fact that 'R CMD INSTALL' is
>>> also used by developers to install from the *package source
>>> tree* (by opposition to end users who use it to install from a
>>> *source tarball*,
>>
>> .. for a good reason, IMHO no serious developer would do that
>> for obvious reasons -
> This sounds like saying that no serious developer working on a
> big project involving a lot of files to compile should use
> 'make'. I mean, serious developers like you *always* do 'make
> clean' before they do 'make' on the R tree when they need to
> test a change, even a small one? And this only takes a "fraction
> of second" for them? Hey, I'd love to be able to do that too!
> ;-)
> H.
>> you'd be working on a dirty copy creating many unnecessary
>> problems and polluting your sources. The first time you'll
>> spend an hour chasing a non-existent problem due to stale
>> binary objects in your tree you'll learn that lesson ;). The
>> fraction of a second spent in R CMD build is well worth the
>> hours saved. IMHO the only valid reason to run INSTALL on a
>> (freshly unpacked tar ball) directory is to capture config.log.
>>
>> Cheers, Simon
>>
>>
>>
>>> even though they don't use it directly), then you have a
>>> point. So maybe I should have been more explicit about the
>>> problem that it can be for the *developer* to have 'R CMD
>>> build' and 'R CMD INSTALL' behave differently by default.
>>>
>>> Of course I'm not suggesting that 'R CMD
Re: [Rd] Excited about the near future...
Since I've posted this a month ago, several persons have been emailing me offline asking what I'm referring to. From the NEWS of R v2.13.0 (released today): Package 'compiler' is now provided as a standard package. See ?compiler::compile for information on how to use the compiler. This package implements a byte code compiler for R: by default the compiler is not used in this release. See the ‘R Installation and Administration Manual’ for how to compile the base and recommended packages. The fact that it is now a standard package means everyone will have it installed by default, which means it is much more likely to get lots of real CPU mileage. The 'compiler' package has been a long-term effort by Luke Tierney. He has some nice talks/slides on this: http://www.stat.uiowa.edu/~luke/ Yesterday, Dirk Eddelbuettel wrote a piece about the compiler on his blog 'Thinking inside the box': http://dirk.eddelbuettel.com/blog/2011/04/12/ /Henrik PS. Stephen Milborrow's package 'jit' provides a just-in-time compiler iff used with his Ra build of R. It seems to be a discontinued project though. On Sat, Mar 12, 2011 at 9:45 PM, Henrik Bengtsson wrote: > Some already know, but I think it deserves a bit of a attention here as well: > > It looks like we're about to get new features in R that will be very powerful! > > That should be a good enough teaser for now... > > /Henrik > > PS ...and thanks for making it available plus credits to similar > efforts by others. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in hist.POSIXt , hist.Date
The behaviour of hist.POSIXt when using the col argument is different from the default hist, in the respect that it colors the axes as well. I think this is due to the ... argument, which is passed to the axis.POSIXct() function. In the default hist, col is set as a fixed argument, and hence cannot be passed unwantedly to other functions. Maybe this should be done with hist.POSIXt as well. The same goes for hist.Date Cheers Joris -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in hist.POSIXt , hist.Date
Joris Meys gmail.com> writes: > > The behaviour of hist.POSIXt when using the col argument is different > from the default hist, in the respect that it colors the axes as well. > I think this is due to the ... argument, which is passed to the > axis.POSIXct() function. In the default hist, col is set as a fixed > argument, and hence cannot be passed unwantedly to other functions. > Maybe this should be done with hist.POSIXt as well. The same goes for > hist.Date Reproducible example: hist(.leap.seconds, "years", freq = TRUE,col=2) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reading 64-bit integers
Simon (et al.), I was just wondering if anything further came of this... I would be willing to help put together an updated patch, if the semantics can be decided upon. All the best, Jon On 30 March 2011 19:22, Simon Urbanek wrote: > Bill, > > thanks. I like that idea of the output parameter better, especially if we > ever add different scalar vector types. Admittedly, what=integer() is the > most useful case. What I was worried about is things like what=double(), > output=integer() which could be legal, but are more conveniently dealt with > via as.integer(readBin()) instead. > I won't have more time today, but I'll have a look tomorrow. > > Thanks, > Simon > > > On Mar 30, 2011, at 1:38 PM, William Dunlap wrote: > >> >>> -Original Message- >>> From: r-devel-boun...@r-project.org >>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Simon Urbanek >>> Sent: Tuesday, March 29, 2011 6:49 PM >>> To: Duncan Murdoch >>> Cc: r-devel@r-project.org >>> Subject: Re: [Rd] Reading 64-bit integers >>> >>> >>> On Mar 29, 2011, at 8:47 PM, Duncan Murdoch wrote: >>> On 29/03/2011 7:01 PM, Jon Clayden wrote: > Dear Simon, > > On 29 March 2011 22:40, Simon >>> Urbanek wrote: >> Jon, >> >> On Mar 29, 2011, at 1:33 PM, Jon Clayden wrote: >> >>> Dear Simon, >>> >>> Thank you for the response. >>> >>> On 29 March 2011 15:06, Simon >>> Urbanek wrote: On Mar 29, 2011, at 8:46 AM, Jon Clayden wrote: > Dear all, > > I see from some previous threads that support for >>> 64-bit integers in R > may be an aim for future versions, but in the meantime >>> I'm wondering > whether it is possible to read in integers of greater >>> than 32 bits at > all. Judging from ?readBin, it should be possible to >>> read 8-byte > integers to some degree, but it is clearly limited in >>> practice by R's > internally 32-bit integer type: > >> x<- as.raw(c(0,0,0,0,1,0,0,0)) >> (readBin(x,"integer",n=1,size=8,signed=F,endian="big")) > [1] 16777216 >> x<- as.raw(c(0,0,0,1,0,0,0,0)) >> (readBin(x,"integer",n=1,size=8,signed=F,endian="big")) > [1] 0 > > For values that fit into 32 bits it works fine, but >>> for larger values > it fails. (I'm a bit surprised by the zero - should >>> the value not be > NA if it is out of range? No, it's not out of range - int is only 4 bytes so only >>> 4 first bytes (respecting endianness order, hence LSB) are used. >>> >>> The fact remains that I ask for the value of an 8-byte >>> integer and >>> don't get it. >> >> I think you're misinterpreting the documentation: >> >> If 'size' is specified and not the natural size of the object, >> each element of the vector is coerced to an appropriate type >> before being written or as it is read. >> >> The "integer" object type is defined as signed 32-bit in >>> R, so if you ask for "8 bytes into object type integer", you >>> get a coercion into that object type -- 32-bit signed integer >>> -- as documented. I think the issue may come from the >>> confusion of the object type "integer" with general "integer >>> number" in mathematical sense that has no representation >>> restrictions. (FWIW in C the "integer" type is "int" and it >>> is 32-bit on all modern OSes regardless of platform - that's >>> where the limitation comes from, it's not something R has made up). > > OK, but it still seems like there is a case for raising a >>> warning. As > it is there is no way to tell when reading an 8-byte integer from a > file whether its value is really 0, or if it merely has 0 in its > least-significant 4 bytes. If 99% of such stored numbers are below > 2^31, one is going to need some extra logic to catch the other 1% > where you (silently) get the wrong value. In essence, unless you're > certain that you will never come across a number that actually uses > the upper 4 bytes, you will always have to read it as two 4-byte > numbers and check that the high-order one (which is endianness > dependent, of course) is zero. A C-level sanity check seems more > efficient and more helpful to me. Seems to me that the S-PLUS solution (output="double") >>> would be a lot more useful. I'd commit that if you write it; >>> I don't think I'd commit the warning. >>> >>> I was going to write some thing similar (idea = good, patch >>> welcome ;)). My only worry is that the "output" argument is a >>> bit misleading in that one could expect to use any >>> combination of "input"/"output" which may be a maintenance >>> nightmare. If I understand it correctly it's only a special >>> case for integer input. I don't have S+ so can't say how they >>> deal with that. >> >> In S+'s readBin the output argument can be >> only double() or singl
Re: [Rd] R CMD build --resave-data
On 13.04.2011 02:53, Hervé Pagès wrote:
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*, even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
It is one thing to talk about sensible defaults and another thing to
talk about bugs. I just talked about sensible defaults. And I have not
had the time to look iunto details. I just arrived in Dortmund 15
minutes ago and I the first thing I have to do is repairing some
winbuilder stuff and get 2.13.0 ready on it. I may look into other
details later this week or at the beginning of next week.
Uwe
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
Hi Uwe,
On 11-04-13 10:50 AM, Uwe Ligges wrote:
On 13.04.2011 02:53, Hervé Pagès wrote:
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*, even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
It is one thing to talk about sensible defaults and another thing to
talk about bugs. I just talked about sensible defaults. And I have not
had the time to look iunto details. I just arrived in Dortmund 15
minutes ago and I the first thing I have to do is repairing some
winbuilder stuff and get 2.13.0 ready on it. I may look into other
details later this week or at the beginning of next week.
No problem. I understand perfectly. Release times are very busy time
on the Bioconductor side too. Thanks for looking into this!
H.
Uwe
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mai
[Rd] Problem with dyn.load in R 2.13.0
I have a test directory for the survival suite, and dyn.load has ceased
to work in it. Below shows the log:
tmt1075% R --vanilla
R version 2.12.2 (2011-02-25)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> dyn.load('survival.so')
> q()
tmt1076% R13 --vanilla
R version 2.13.0 RC (2011-04-11 r55409)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> dyn.load('survival.so')
Error in dyn.load("survival.so") :
unable to load shared object
'/people/biostat2/therneau/research/surv/Rtest/survival.so':
libR.so: cannot open shared object file: No such file or directory
> q()
--
Is the issue that the .so file must have been created with the R2.13
script? That's not what the error message says, however. It almost
looks like it is ignoring my first argument and looking instead for
"libR".
Terry Therneau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0
On 13 April 2011 at 13:00, Terry Therneau wrote:
| I have a test directory for the survival suite, and dyn.load has ceased
| to work in it. Below shows the log:
|
| tmt1075% R --vanilla
|
| R version 2.12.2 (2011-02-25)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| > dyn.load('survival.so')
| > q()
[...]
|
| tmt1076% R13 --vanilla
|
| R version 2.13.0 RC (2011-04-11 r55409)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
| > dyn.load('survival.so')
| Error in dyn.load("survival.so") :
| unable to load shared object
| '/people/biostat2/therneau/research/surv/Rtest/survival.so':
| libR.so: cannot open shared object file: No such file or directory
| > q()
|
| --
|
| Is the issue that the .so file must have been created with the R2.13
| script? That's not what the error message says, however. It almost
| looks like it is ignoring my first argument and looking instead for
| "libR".
What does 'ldd /path/to/your/survial.so' say? Does the system find libR.so?
I have no issues whatsoever on my Ubuntu box with the packages distributed
via CRAN (and now also a PPA if you want alpha/beta/rc builds) based on the
underlying Debian package I maintain.
I have a (pretty visible) hourly cronjob that drives our littler /usr/bin/r
frontend to do the CRANberries summaries---and even while /usr/bin/r was last
built under R 2.11.1, it continued to work merrily under R 2.12.0, 2.12.1,
2.12.2, and 2.13.0 prereleases:
edd@max:~$ r --version | head -4
r ('littler') version 0.1.3
svn revision 178 as of 2010-01-05 20:57:41
built at 20:08:17 on Oct 11 2010
using GNU R Version 2.11.1 (2010-05-31)
edd@max:~$
edd@max:~$ R --version | head -1
R version 2.13.0 RC (2011-04-07 r55373)
edd@max:~$
Both use the same shared library version libR.so from whichever current
r-base-core is installed.
So I see no particular breakage. Recompiling your project may also be a start.
Hth, Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0
On 04/13/2011 11:34 AM, Dirk Eddelbuettel wrote:
On 13 April 2011 at 13:00, Terry Therneau wrote:
| I have a test directory for the survival suite, and dyn.load has ceased
| to work in it. Below shows the log:
|
| tmt1075% R --vanilla
|
| R version 2.12.2 (2011-02-25)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
|> dyn.load('survival.so')
|> q()
[...]
|
| tmt1076% R13 --vanilla
|
| R version 2.13.0 RC (2011-04-11 r55409)
| Copyright (C) 2011 The R Foundation for Statistical Computing
| ISBN 3-900051-07-0
| Platform: x86_64-unknown-linux-gnu (64-bit)
[...]
|> dyn.load('survival.so')
| Error in dyn.load("survival.so") :
| unable to load shared object
| '/people/biostat2/therneau/research/surv/Rtest/survival.so':
| libR.so: cannot open shared object file: No such file or directory
|> q()
|
| --
|
| Is the issue that the .so file must have been created with the R2.13
| script? That's not what the error message says, however. It almost
| looks like it is ignoring my first argument and looking instead for
| "libR".
What does 'ldd /path/to/your/survial.so' say? Does the system find libR.so?
Maybe R CMD ldd /path/to/your/survival.so to pick up whatever
environment R configures.
Martin
I have no issues whatsoever on my Ubuntu box with the packages distributed
via CRAN (and now also a PPA if you want alpha/beta/rc builds) based on the
underlying Debian package I maintain.
I have a (pretty visible) hourly cronjob that drives our littler /usr/bin/r
frontend to do the CRANberries summaries---and even while /usr/bin/r was last
built under R 2.11.1, it continued to work merrily under R 2.12.0, 2.12.1,
2.12.2, and 2.13.0 prereleases:
edd@max:~$ r --version | head -4
r ('littler') version 0.1.3
svn revision 178 as of 2010-01-05 20:57:41
built at 20:08:17 on Oct 11 2010
using GNU R Version 2.11.1 (2010-05-31)
edd@max:~$
edd@max:~$ R --version | head -1
R version 2.13.0 RC (2011-04-07 r55373)
edd@max:~$
Both use the same shared library version libR.so from whichever current
r-base-core is installed.
So I see no particular breakage. Recompiling your project may also be a start.
Hth, Dirk
--
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] Problem with dyn.load in R 2.13.0
We have no details, but my wild guess would be that you did not re-build the
package for 2.13.0 and you have static libR in 2.13.0 yet dynamic in 2.12.2.
Cheers,
Simon
On Apr 13, 2011, at 2:00 PM, Terry Therneau wrote:
> I have a test directory for the survival suite, and dyn.load has ceased
> to work in it. Below shows the log:
>
> tmt1075% R --vanilla
>
> R version 2.12.2 (2011-02-25)
> Copyright (C) 2011 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> dyn.load('survival.so')
>> q()
>
> tmt1076% R13 --vanilla
>
> R version 2.13.0 RC (2011-04-11 r55409)
> Copyright (C) 2011 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> dyn.load('survival.so')
> Error in dyn.load("survival.so") :
> unable to load shared object
> '/people/biostat2/therneau/research/surv/Rtest/survival.so':
> libR.so: cannot open shared object file: No such file or directory
>> q()
>
> --
>
> Is the issue that the .so file must have been created with the R2.13
> script? That's not what the error message says, however. It almost
> looks like it is ignoring my first argument and looking instead for
> "libR".
>
> Terry Therneau
>
> __
> 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] Problem with dyn.load in R 2.13.0 -- the real problem
On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote: > Terry, > > You replied to > > From: Terry Therneau > To: Dirk Eddelbuettel > Cc: c...@r-project.org > Subject: Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem > > but dropped r-devel. On purpose? No, not on purpose. Corrected. > This still looks like a local config issue about local libraries to me. > > Dirk I fail to see how. Running the newest release of R 2.13, if I issue a library() command for something installed earlier in R_LIBS_USER, something I expect lots of people to do, and that library has a .so file with reference to the now-nonexistent Rlib.so file, an error ensues. This is easy to test elsewhere. I don't anticipate that every user will erase all libraries and reinstall with each new R release. At work particularly, the default R release changes without user intervention; the system admin is not going to go looking for all local downloads. (A lot of people use R_LIBS_USER, as they don't have permission to put things elsewhere -- this includes me.) The error message for logspline is great as it tells them what to do. I'm only looking for a better one in the case I found. > > On 13 April 2011 at 15:01, Terry Therneau wrote: > | Dirk's comment made it clearer: > | > | On Wed, 2011-04-13 at 13:34 -0500, Dirk Eddelbuettel wrote: > | > What does 'ldd /path/to/your/survial.so' say? Does the system find > | > libR.so? > | > > | > | tmt1077% pwd > | /people/biostat2/therneau/research/surv/Rtest > | tmt1078% ldd survival.so > | libR.so => not found > | libc.so.6 => /lib64/libc.so.6 (0x2aede2d94000) > | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) > | > | However, this is a survival.so file created by R12, and that version has > | a libR.so in RHOME/lib. Version R2.13 has no such file. If I remake > | the .so file using R 2.13: then I get > | > | tmt1084% ldd survival.so > | libc.so.6 => /lib64/libc.so.6 (0x2b656a2f1000) > | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) > | > | And R > | > | -- > | > | So, the real problem is a misleading error message. I have several > | pacakges loaded into my own ~/Rlib. When I access one of these from > | version 2.13 I get variable errors, or success. > | > | tmt1087% R13 --vanilla > | > | R version 2.13.0 RC (2011-04-11 r55409) > | Copyright (C) 2011 The R Foundation for Statistical Computing > | ISBN 3-900051-07-0 > | Platform: x86_64-unknown-linux-gnu (64-bit) > | ... > | > | > library(logspline) > | Error: package 'logspline' was built before R 2.10.0: please re-install > | it > | > | > library(quadprog) > | Error in dyn.load(file, DLLpath = DLLpath, ...) : > | unable to load shared object > | '/people/biostat2/therneau/Rlib/quadprog/libs/quadprog.so': > | libR.so: cannot open shared object file: No such file or directory > | Error: package/namespace load failed for 'quadprog' > | > | > library(xtable) > | > > | > | My problem is solved, but is this a "user confuser" issue that should be > | addressed in the release? > | > | Terry T. > | > | > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem
On Apr 13, 2011, at 4:47 PM, Terry Therneau wrote: > > On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote: >> Terry, >> >> You replied to >> >> From: Terry Therneau >> To: Dirk Eddelbuettel >> Cc: c...@r-project.org >> Subject: Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem >> >> but dropped r-devel. On purpose? > > No, not on purpose. Corrected. > >> This still looks like a local config issue about local libraries to me. >> >> Dirk > > I fail to see how. Running the newest release of R 2.13, if I issue a > library() command for something installed earlier in R_LIBS_USER, something I > expect lots of people to do, and that library has a .so file with reference > to the now-nonexistent Rlib.so file, an error ensues. This depends on the OS - on Linux the path to libR is not embedded in the package's .so, so R will happily try to load whatever libR is current - regardless whether that breaks or not. Again, this is entirely OS-dependent. Also in your case you have an entirely different build of R so your issue is independent of R version - you'd get exactly the same issue if both R builds were 2.12.2. > This is easy to test elsewhere. > I don't anticipate that every user will erase all libraries and > reinstall with each new R release. Well, then they are entirely on their own. Major releases are not guaranteed to be binary compatible and often they are not. Depending on the subset of the features a package may use it may or may not work, but it is never guaranteed. The first thing any user should do after R upgrade is to run update.packages. But, again, this is not really related to your problem ;). I suppose your admin has forgotten to use --enable-R-shlib when building 2.13.0. Cheers, Simon > At work particularly, the default R > release changes without user intervention; the system admin is not going > to go looking for all local downloads. (A lot of people use > R_LIBS_USER, as they don't have permission to put things elsewhere -- > this includes me.) > The error message for logspline is great as it tells them what to do. > I'm only looking for a better one in the case I found. > >> >> On 13 April 2011 at 15:01, Terry Therneau wrote: >> | Dirk's comment made it clearer: >> | >> | On Wed, 2011-04-13 at 13:34 -0500, Dirk Eddelbuettel wrote: >> | > What does 'ldd /path/to/your/survial.so' say? Does the system find >> | > libR.so? >> | > >> | >> | tmt1077% pwd >> | /people/biostat2/therneau/research/surv/Rtest >> | tmt1078% ldd survival.so >> | libR.so => not found >> | libc.so.6 => /lib64/libc.so.6 (0x2aede2d94000) >> | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) >> | >> | However, this is a survival.so file created by R12, and that version has >> | a libR.so in RHOME/lib. Version R2.13 has no such file. If I remake >> | the .so file using R 2.13: then I get >> | >> | tmt1084% ldd survival.so >> | libc.so.6 => /lib64/libc.so.6 (0x2b656a2f1000) >> | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) >> | >> | And R >> | >> | -- >> | >> | So, the real problem is a misleading error message. I have several >> | pacakges loaded into my own ~/Rlib. When I access one of these from >> | version 2.13 I get variable errors, or success. >> | >> | tmt1087% R13 --vanilla >> | >> | R version 2.13.0 RC (2011-04-11 r55409) >> | Copyright (C) 2011 The R Foundation for Statistical Computing >> | ISBN 3-900051-07-0 >> | Platform: x86_64-unknown-linux-gnu (64-bit) >> | ... >> | >> | > library(logspline) >> | Error: package 'logspline' was built before R 2.10.0: please re-install >> | it >> | >> | > library(quadprog) >> | Error in dyn.load(file, DLLpath = DLLpath, ...) : >> | unable to load shared object >> | '/people/biostat2/therneau/Rlib/quadprog/libs/quadprog.so': >> | libR.so: cannot open shared object file: No such file or directory >> | Error: package/namespace load failed for 'quadprog' >> | >> | > library(xtable) >> | > >> | >> | My problem is solved, but is this a "user confuser" issue that should be >> | addressed in the release? >> | >> | Terry T. >> | >> | >> > > __ > 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] Problem with dyn.load in R 2.13.0
On Wed, 2011-04-13 at 16:45 -0400, Simon Urbanek wrote: > We have no details, but my wild guess would be that you did not > re-build the package for 2.13.0 and you have static libR in 2.13.0 yet > dynamic in 2.12.2. > > Cheers, > Simon > Per my prior note, my guess at the root of the issue is use of user libraries, which is common here. Here are futher details if that helps. R2.13 was downloaded and built this AM in my ~/temp directory, using the standard ./configure make Then a copy of the shell script was copied to in ~therneau/bin/R13 for my convenience. I paid very little attention to the output of configure. This is running on a shared server using CentOS release 5.5 (98 users at the moment). R2.12.2 is centrally available. > sessionInfo() R version 2.13.0 RC (2011-04-11 r55409) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=C [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base I can't find a libR.so anywhere -- perhaps it's static. tmt1119% pwd /people/biostat2/therneau/temp/R-rc tmt1120% find . -name 'libR*' ./src/extra/blas/libRblas.so ./src/main/libR.a ./src/modules/lapack/libRlapack.so ./src/nmath/standalone/libRmath.pc.in ./src/unix/libR.pc.in ./lib/libRblas.so ./lib/libRlapack.so Thanks for everyone's help. Terry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem
Terry You may not be aware of this, but the "new" default in R is to use a user library which is architecture and R-version dependent. Ie. if you do not play around with R_USER_LIBS or .Rprofile, functions like R CMD INSTALL or install.packages will default to something like (from my current version) "/home/bst/student/khansen/R/x86_64-unknown-linux-gnu-library/2.12" My home is /home/bst/student/khansen so it puts it inside R / ARCHITECTURE / VERSION Ok, it requires that you accept an R directory in your top level home, but this is in almost all cases much preferred to playing with R_USER_LIBS yourself (in my humble opinion). Of course, this requires a re-install of all packages when you switch R version and it also requires that you install each package separately under each R you are using. But it highly minimize the possibility of errors. I don't think installed packages are assured to be compatible across R versions in any way. Kasper On Wed, Apr 13, 2011 at 5:05 PM, Simon Urbanek wrote: > > On Apr 13, 2011, at 4:47 PM, Terry Therneau wrote: > >> >> On Wed, 2011-04-13 at 15:32 -0500, Dirk Eddelbuettel wrote: >>> Terry, >>> >>> You replied to >>> >>> From: Terry Therneau >>> To: Dirk Eddelbuettel >>> Cc: c...@r-project.org >>> Subject: Re: [Rd] Problem with dyn.load in R 2.13.0 -- the real problem >>> >>> but dropped r-devel. On purpose? >> >> No, not on purpose. Corrected. >> >>> This still looks like a local config issue about local libraries to me. >>> >>> Dirk >> >> I fail to see how. Running the newest release of R 2.13, if I issue a >> library() command for something installed earlier in R_LIBS_USER, something >> I expect lots of people to do, and that library has a .so file with >> reference to the now-nonexistent Rlib.so file, an error ensues. > > This depends on the OS - on Linux the path to libR is not embedded in the > package's .so, so R will happily try to load whatever libR is current - > regardless whether that breaks or not. Again, this is entirely OS-dependent. > Also in your case you have an entirely different build of R so your issue is > independent of R version - you'd get exactly the same issue if both R builds > were 2.12.2. > > >> This is easy to test elsewhere. >> I don't anticipate that every user will erase all libraries and >> reinstall with each new R release. > > Well, then they are entirely on their own. Major releases are not guaranteed > to be binary compatible and often they are not. Depending on the subset of > the features a package may use it may or may not work, but it is never > guaranteed. The first thing any user should do after R upgrade is to run > update.packages. But, again, this is not really related to your problem ;). I > suppose your admin has forgotten to use --enable-R-shlib when building 2.13.0. > > Cheers, > Simon > > >> At work particularly, the default R >> release changes without user intervention; the system admin is not going >> to go looking for all local downloads. (A lot of people use >> R_LIBS_USER, as they don't have permission to put things elsewhere -- >> this includes me.) >> The error message for logspline is great as it tells them what to do. >> I'm only looking for a better one in the case I found. >> >>> >>> On 13 April 2011 at 15:01, Terry Therneau wrote: >>> | Dirk's comment made it clearer: >>> | >>> | On Wed, 2011-04-13 at 13:34 -0500, Dirk Eddelbuettel wrote: >>> | > What does 'ldd /path/to/your/survial.so' say? Does the system find >>> | > libR.so? >>> | > >>> | >>> | tmt1077% pwd >>> | /people/biostat2/therneau/research/surv/Rtest >>> | tmt1078% ldd survival.so >>> | libR.so => not found >>> | libc.so.6 => /lib64/libc.so.6 (0x2aede2d94000) >>> | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) >>> | >>> | However, this is a survival.so file created by R12, and that version has >>> | a libR.so in RHOME/lib. Version R2.13 has no such file. If I remake >>> | the .so file using R 2.13: then I get >>> | >>> | tmt1084% ldd survival.so >>> | libc.so.6 => /lib64/libc.so.6 (0x2b656a2f1000) >>> | /lib64/ld-linux-x86-64.so.2 (0x0033cd80) >>> | >>> | And R >>> | >>> | -- >>> | >>> | So, the real problem is a misleading error message. I have several >>> | pacakges loaded into my own ~/Rlib. When I access one of these from >>> | version 2.13 I get variable errors, or success. >>> | >>> | tmt1087% R13 --vanilla >>> | >>> | R version 2.13.0 RC (2011-04-11 r55409) >>> | Copyright (C) 2011 The R Foundation for Statistical Computing >>> | ISBN 3-900051-07-0 >>> | Platform: x86_64-unknown-linux-gnu (64-bit) >>> | ... >>> | >>> | > library(logspline) >>> | Error: package 'logspline' was built before R 2.10.0: please re-install >>> | it >>> | >>> | > library(quadprog) >>> | Error in dyn.load(file, DLLpath = DLLpath, ...) : >>> | unable to load shared object >>> | '/people/biostat2/therneau/Rlib/quadprog/libs/quadprog.so': >>> | libR.so:
[Rd] Using GSL Routines
Dear R-programmers, I am trying out certain methods in R, and the statistics require me to calculate n-(sample size) dimensional equations. They are not really very hard to solve - my home-brew implentation of Newton-Raphson in R succeeds most of time with simulated data. (Note that I am assured of a unique solution by theory). Problem comes in with real data, for which I should really implement a good line search (convergence issues). Being lazy, i would like to link to the GSL routines which are of course faster and more reliable. My question is should i use the C - GSL routines or the Python ones in NumPy? My major concern is the portability of the code i write: really dont want users to have to install a bunch of software just to use my package. (Im looking at Windows here) Alternatively, should i just hack out the code (fsolve) and put it in my package? Thanks for the advice, Mohit Dayal Applied Statistics & Computing Lab ISB [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using GSL Routines
Hi the gsl R package includes many wrappers which you may find useful, but if you write new ones please let me know and I'll include them in a future release. best wishes Robin On Thu, Apr 14, 2011 at 5:49 PM, Mohit Dayal wrote: > Dear R-programmers, > > I am trying out certain methods in R, and the statistics require me to > calculate n-(sample size) dimensional equations. They are not really very > hard to solve - my home-brew implentation of Newton-Raphson in R succeeds > most of time with simulated data. (Note that I am assured of a unique > solution by theory). Problem comes in with real data, for which I should > really implement a good line search (convergence issues). Being lazy, i > would like to link to the GSL routines which are of course faster and more > reliable. > > My question is should i use the C - GSL routines or the Python ones in > NumPy? My major concern is the portability of the code i write: really dont > want users to have to install a bunch of software just to use my package. > (Im looking at Windows here) > > Alternatively, should i just hack out the code (fsolve) and put it in my > package? > > Thanks for the advice, > Mohit Dayal > Applied Statistics & Computing Lab > ISB > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Robin Hankin Uncertainty Analyst hankin.ro...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
