[Rd] how to install header files in package
Is there a way to get R CMD INSTALL (and friends) to copy the header files from a source package's src directory to the include directory? Thanks. Kjell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to install header files in package
On 13 June 2008 at 14:28, Kjell Konis wrote: | Is there a way to get R CMD INSTALL (and friends) to copy the header | files from a source package's src directory to the include directory? Only if you (ab-)use the 'make all' target in src/Makefile to copy them, as a recent thread on r-devel showed. Some of us suggested that a 'make install' target would be a nice thing to have. No resolution, or for that matter comment, comment from R Core, though. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to install header files in package
On Fri, 13 Jun 2008, Dirk Eddelbuettel wrote: > > On 13 June 2008 at 14:28, Kjell Konis wrote: > | Is there a way to get R CMD INSTALL (and friends) to copy the header > | files from a source package's src directory to the include directory? > > Only if you (ab-)use the 'make all' target in src/Makefile to copy them, as a > recent thread on r-devel showed. Some of us suggested that a 'make install' > target would be a nice thing to have. Which 'include' directory do you mean? $RHOME/include or /include? You could put a copy of the *.h files into inst/include to get them into /include. Putting them into $RHOME/include isn't always desirable or possible (permission problems). If you install *.h files then you are probably also distributing *.so, *.dll, and *.lib (on Windows) files and they should go into a parallel directory. Where should they go? Bill Dunlap Insightful Corporation bill at insightful dot com "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compiling 2.7.0 GNU/Linux | BLAS & Lapack query
Greetings - For a host of reasons I chose (was forced) to upgrade my multi-Opteron box from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had installed from 4.0.0 to 4.1.0. While I get no errors (that I can find) in the config -> make -> make install sequence, I'm pretty sure (based on some benchmarks) that I'm not getting BLAS and/or Lapack to compile in. So, either something has changed from 2.6.2 -> 2.7.0, or something has changed from Fedora 7 -> Fedora 8, or both. Here is the sequence I follow to do the config (which seemed to work perfectly before - note: using bash shell): 1. LD_LIBRARY_PATH=/opt/acml4.1.0/gfortran64/lib 2. export LD_LIBRARY_PATH 3. ./configure --with-lapack="-L/usr/lib64" --with-blas="L/opt/acml4.1.0/gfortran64/lib -lacml" However, when I try this, at the end of the config script I'm told Interfaces supported: X11 External libraries: readline Additional capabilites: PNG, JPEG, iconv, MBCS, NLS, cairo Options enabled: shared BLAS, R profiling, Java I'm pretty sure that readline being the only external library being reported is diagnostic of some sort of issue - normally, I'm given information about lapack, and generic BLAS being linked. But, no more. Suggestions? Points to the obvious? Both ACML and Lapack are where they should be, so I'm quite frankly puzzled as to what is going on. Thanks very much in advance. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to install header files in package
* On 2008-06-13 at 08:40 -0500 Dirk Eddelbuettel wrote: > On 13 June 2008 at 14:28, Kjell Konis wrote: > | Is there a way to get R CMD INSTALL (and friends) to copy the header > | files from a source package's src directory to the include directory? > > Only if you (ab-)use the 'make all' target in src/Makefile to copy > them, as a recent thread on r-devel showed. Some of us suggested > that a 'make install' target would be a nice thing to have. Can you elaborate on the use case? If the desire is to allow pkgB to access header files provided by pkgA, then you can use the LinkingTo field in the DESCRIPTION file as described in Writing R Extensions in the "Registering native routines" section. + seth -- Seth Falcon | http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling 2.7.0 GNU/Linux | BLAS & Lapack query
Evan, It might depend on the way ACML has been compiled by the AMD people. Your version of gcc/gfortran might be incompatible with ACML 4.1.0. This is known to users and is causing problems. You can see it reported in the ACML forum here (it applies to 4.0.1 but I think the problems have not been solved) http://forums.amd.com/devforum/messageview.cfm?catid=217&threadid=90399&enterthread=y Here I report a part of a post of that thread Begin quote: "The gfortran ACML libraries are currently built with two different GCC/GFORTRAN compilers. The SINGLE THREADED libraries found in /opt/gfortran64 and /opt/gfortran64_int64 are built with 4.1.2. This compiler version is used because it is the most widely supported compiler with most new linux distributions (or was in 2007). The OpenMP MULTI THREADED libraries found in /opt/gfortran64_mp and /opt/gfortran64_mp_int64 are built with 4.2.0. This compiler is used because it was finally released in 2007 and 4.1.2 does not natively support OpenMP. This is mentioned in the release notes, but it's obvious not very clear. When using GCC/GFORTRAN 4.3, you will likely need to use the mp versions of the library. This has not been tested by AMD. When 4.3 releases, AMD may provide a 4.3 build. This issue happens because of the incompatibility between GCC 4.1.2 and 4.2. Now that more distributions are supplying GCC 4.2 AMD may only support GCC 4.2 for 2008 releases. In other words, no more 4.1.2 builds. Both single- and multi-threaded libraries would be built with 4.2. " end quote Se also subsequent replies. Maybe you should try first to see whether the ACML work at all on your system apart from R. Hope this helps Ciao Simone On Fri, Jun 13, 2008 at 5:03 PM, evan cooch <[EMAIL PROTECTED]> wrote: > Greetings - > > For a host of reasons I chose (was forced) to upgrade my multi-Opteron box > from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had > installed from 4.0.0 to 4.1.0. > > While I get no errors (that I can find) in the config -> make -> make > install sequence, I'm pretty sure (based on some benchmarks) that I'm not > getting BLAS and/or Lapack to compile in. So, either something has changed > from 2.6.2 -> 2.7.0, or something has changed from Fedora 7 -> Fedora 8, or > both. > > Here is the sequence I follow to do the config (which seemed to work > perfectly before - note: using bash shell): > > 1. LD_LIBRARY_PATH=/opt/acml4.1.0/gfortran64/lib > > 2. export LD_LIBRARY_PATH > > 3. ./configure --with-lapack="-L/usr/lib64" > --with-blas="L/opt/acml4.1.0/gfortran64/lib -lacml" > > > However, when I try this, at the end of the config script I'm told > > Interfaces supported: X11 > External libraries: readline > Additional capabilites: PNG, JPEG, iconv, MBCS, NLS, cairo > Options enabled: shared BLAS, R profiling, Java > > > I'm pretty sure that readline being the only external library being > reported > is diagnostic of some sort of issue - normally, I'm given information about > lapack, and generic BLAS being linked. But, no more. > > Suggestions? Points to the obvious? Both ACML and Lapack are where they > should be, so I'm quite frankly puzzled as to what is going on. > > > Thanks very much in advance. > >[[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to install header files in package
Here's what I'm doing: I define some C functions in pkgA and register them with R_RegisterCCallable and I want to use them in pkgB. When building pkgB, R CMD INSTALL expects to find the header files for the registered C functions in pkgA*/include (where the * denotes the installed version of pkgA). AFAICT there is no mechanism to put the header files from pkgA into pkgA*/include. Putting the header files in pkgA/inst/include solves the problem but it seems like there should be a better way to do this. Kjell On 13 juin 08, at 16:54, Bill Dunlap wrote: On Fri, 13 Jun 2008, Dirk Eddelbuettel wrote: On 13 June 2008 at 14:28, Kjell Konis wrote: | Is there a way to get R CMD INSTALL (and friends) to copy the header | files from a source package's src directory to the include directory? Only if you (ab-)use the 'make all' target in src/Makefile to copy them, as a recent thread on r-devel showed. Some of us suggested that a 'make install' target would be a nice thing to have. Which 'include' directory do you mean? $RHOME/include or /include? You could put a copy of the *.h files into inst/include to get them into /include. Putting them into $RHOME/include isn't always desirable or possible (permission problems). If you install *.h files then you are probably also distributing *.so, *.dll, and *.lib (on Windows) files and they should go into a parallel directory. Where should they go? Bill Dunlap Insightful Corporation bill at insightful dot com "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to install header files in package
On Fri, 13 Jun 2008, Kjell Konis wrote: Here's what I'm doing: I define some C functions in pkgA and register them with R_RegisterCCallable and I want to use them in pkgB. When building pkgB, R CMD INSTALL expects to find the header files for the registered C functions in pkgA*/include (where the * denotes the installed version of pkgA). AFAICT there is no mechanism to put the header files from pkgA into pkgA*/include. Putting the header files in pkgA/inst/include solves the problem but it seems like there should be a better way to do this. That is the intended way. The headers you want to install may not be the same as those you use to build the package. See e.g. Matrix for an example. Kjell On 13 juin 08, at 16:54, Bill Dunlap wrote: On Fri, 13 Jun 2008, Dirk Eddelbuettel wrote: On 13 June 2008 at 14:28, Kjell Konis wrote: | Is there a way to get R CMD INSTALL (and friends) to copy the header | files from a source package's src directory to the include directory? Only if you (ab-)use the 'make all' target in src/Makefile to copy them, as a recent thread on r-devel showed. Some of us suggested that a 'make install' target would be a nice thing to have. Which 'include' directory do you mean? $RHOME/include or /include? You could put a copy of the *.h files into inst/include to get them into /include. Putting them into $RHOME/include isn't always desirable or possible (permission problems). If you install *.h files then you are probably also distributing *.so, *.dll, and *.lib (on Windows) files and they should go into a parallel directory. Where should they go? Bill Dunlap Insightful Corporation bill at insightful dot com "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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] (PR#11064) how to reproduce...
You can try this:
data <- cbind("a"=sample(1:10), "b"=sample(1:10))
fact <- sample(rep(1:1, each=10))
system.time(std <- by(data, fact, colSums))
by.matrix <- function (data, INDICES, FUN, ...) {
if (!is.list(INDICES)) {
IND <- vector("list", 1)
IND[[1]] <- INDICES
names(IND) <- deparse(substitute(INDICES))[1]
}
else IND <- INDICES
FUNx <- function(x) FUN(data[x, , drop = FALSE], ...)
nd <- nrow(data)
ans <- eval(substitute(tapply(1:nd, IND, FUNx)), as.data.frame
(data))
attr(ans, "call") <- match.call()
class(ans) <- "by"
ans
}
system.time(mod <- by(data, fact, colSums))
all.equal(std, mod)
I get a 30x speed up
(I'm not sure why the attributes differ, but I'm sure this can be
fixed...)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling 2.7.0 GNU/Linux | BLAS & Lapack query
You need to look in config.log to see what happened.
But note what 'R Installation and Administration' says about
See @pxref{Shared BLAS} for an alternative (and in many ways preferable)
way to use ACML.
On Fri, 13 Jun 2008, evan cooch wrote:
Greetings -
For a host of reasons I chose (was forced) to upgrade my multi-Opteron box
from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had
installed from 4.0.0 to 4.1.0.
While I get no errors (that I can find) in the config -> make -> make
install sequence, I'm pretty sure (based on some benchmarks) that I'm not
getting BLAS and/or Lapack to compile in. So, either something has changed
from 2.6.2 -> 2.7.0, or something has changed from Fedora 7 -> Fedora 8, or
both.
Here is the sequence I follow to do the config (which seemed to work
perfectly before - note: using bash shell):
1. LD_LIBRARY_PATH=/opt/acml4.1.0/gfortran64/lib
2. export LD_LIBRARY_PATH
3. ./configure --with-lapack="-L/usr/lib64"
--with-blas="L/opt/acml4.1.0/gfortran64/lib -lacml"
However, when I try this, at the end of the config script I'm told
Interfaces supported: X11
External libraries: readline
Additional capabilites: PNG, JPEG, iconv, MBCS, NLS, cairo
Options enabled: shared BLAS, R profiling, Java
I'm pretty sure that readline being the only external library being reported
is diagnostic of some sort of issue - normally, I'm given information about
lapack, and generic BLAS being linked. But, no more.
Suggestions? Points to the obvious? Both ACML and Lapack are where they
should be, so I'm quite frankly puzzled as to what is going on.
Thanks very much in advance.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
