[Rd] windows 64-bit package build on 32-bit machine
Hello, Is it possible to build a 64-bit package on a 32-bit machine on windows? I can cross-compile for x86, x86_64, and ppc on a 32-bit OS X machine. And it looks like I could build a 32-bit library on a 64-bit windows machine. But it doesn't look possible to build a 64-bit library on a 32-bit windows machine? Thanks, --Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows 64-bit package build on 32-bit machine
Hmm. So our package does not have no src/Makefile.win and only an empty configure.win. We usually build a binary version with R CMD INSTALL --build. R --arch x64 CMD INSTALL --build yields the message "The system cannot find the path specified." On Tue, Oct 26, 2010 at 10:41 PM, Simon Urbanek wrote: > > On Oct 26, 2010, at 9:04 PM, Michael Spiegel wrote: > >> Hello, >> >> Is it possible to build a 64-bit package on a 32-bit machine on >> windows? I can cross-compile for x86, x86_64, and ppc on a 32-bit OS X >> machine. And it looks like I could build a 32-bit library on a 64-bit >> windows machine. But it doesn't look possible to build a 64-bit >> library on a 32-bit windows machine? >> > > Why not? It works for me without problems ... > > Cheers, > Simon > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] BLAS benchmarks on R 2.12.0
Hi, I saw on the mailing list and in the NEWS file that some unsafe math transformations were disabled for the reference BLAS implementation that is used in R. We have a set of performance tests for the OpenMx library, and some of the tests have a x3-10 slowdown in R 2.12.0 versus 2.11.1. When I copy the shared library libRblas.0.dylib from the 2.11.1 installation into the 2.12.0 installation, the slowdown goes away. It seems reasonable that BLAS should conform to IEEE requirements. For the purposes of our library, we are considering two options but I need some advice on both choices: 1) Compile the reference BLAS implementation with unsafe optimizations and include it as a part of the OpenMx library. I can't seem to reproduce the speed of the 2.11.1 reference BLAS library. What compiler, which version of the compiler, and what flags are used when an R binary is distributed? My test machine is a Mac Pro, that may change the answer. 2) Is there any support for adding a libRblas.unsafe.dylib shared library in the R installation, much like libRblas.veclib.dylib is currently included in OS X binaries? Then we could just change the OpenMx shared library to use the unsafe library when we give it to users. We currently change the OpenMx shared library to use the reference blas implementation, because it is faster than the veclib implementation for small matrices. Thank you! --Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] BLAS benchmarks on R 2.12.0
Hi Andrew, In the majority of use cases of our package, we end up doing lots and lots of matrix operations on small matrices, as opposed to matrix operations on large matrices. The optimized BLAS libraries are usually optimized for large matrices. The reference implementation is faster than either veclib, Atlas, or the Goto BLAS implementations, I've tested all of them on our performance test suite. --Michael On Mon, Nov 1, 2010 at 6:07 PM, Andrew Piskorski wrote: > On Sun, Oct 31, 2010 at 12:41:24PM -0400, Michael Spiegel wrote: > >> 1) Compile the reference BLAS implementation with unsafe optimizations >> and include it as a part of the OpenMx library. > > If BLAS speed is important to you, why are you even trying to use the > slow reference BLAS library at all, rather than one of the faster > optimized BLAS libraries (Atlas, Goto, AMD, Intel, etc.)? > > -- > Andrew Piskorski > http://www.piskorski.com/ > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-SIG-Mac] BLAS benchmarks on R 2.12.0
My apologies. I finally noticed that the source files in src/extra/blas had changed. I had been looking at the diff file for a few days, until I remembered that the "c" at the beginning of a line signifies the line as a comment. OK, so the game plan for our specific R package will be to take the reference BLAS source from 2.11.1 and stick it in our package. Thanks to Simon and everyone else for all their help. On Wed, Nov 3, 2010 at 12:29 PM, Simon Urbanek wrote: >> I have one small follow-up question. I thought the compilation flags for >> building src/extra/blas had changed from version 2.12.0 to 2.11.1. But you >> suggest maybe they haven't changed? >> > > I did not change anything as far as the configure flags go. > > Cheers, > Simon > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD INSTALL configure.args and CC customization
I am running into the following issue that has been previously
reported on the R-devel mailing list. The short version is that I'm
writing a package for MPI, and I'd like to change CC and SHLIB_LD to
"mpicc". Trying to change them in Makevars.in has no effect, because
the values are clobbered by /etc/R/Makeconf. Will the following
changes to Makeconf.in introduce any problems?
--Michael
Subject:[Rd] R CMD INSTALL configure.args and CC customization
From: Paul Johnson (paul...@gmail.com)
Date: Jan 20, 2010 11:30:44 am
List: org.r-project.r-devel
Hi, everybody.
I hope the new year is treating you well.
In a Rocks Cluster Linux system (that's Centos 5.2 based), I have
built R-2.10 and it runs well.
While fiddling with MPI libraries and R packages, I've noticed a few
little wrinkles.
This comes as no surprise to the veteran R programmers, but let me
share to the new guys the following gem:
There is a difference between . and -
Simple, and yet so vital!
install.packages inside R takes a period between "configure" and
"args", as in "configure.args=", while in the shell, the same option
specified to R CMD INSTALL wants a dash, as in "--configure-args=".
The "period" versus the "hyphen" was killing me all morning!
When building Rmpi, I had to specify configure options to let R know
which MPI library to use. I *tried* to avoid that by forcing the
compiler to be "mpicc", not "gcc". I believe that if one uses mpicc,
then the compiler really is gcc, but it is initiated with the INC and
LIB dirs set so that the configure can find what it needs. But gcc
seems to be deeply glued to R installation of packages.
I find various posts in the r-help list in which people claim this should work:
CC=mpicc R CMD INSTALL ...
but it doesn't make a difference for me. The compiler that gets used
is gcc, no matter how many different ways I try to say it should be
mpicc:
$ CC=mpicc R CMD INSTALL
--configure-args=--with-mpi=/usr/lib64/openmpi/1.2.7-gcc
--configure-vars=CC=mpicc Rmpi_0.5-8.tar.gz
Password:
* installing to library '/share/apps/lib/R/site-library'
* installing *source* package 'Rmpi' ...
checking for gcc... gcc -m64 -std=gnu99
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -m64 -std=gnu99 accepts -g... yes
checking for gcc -m64 -std=gnu99 option to accept ISO C89... none needed
Trying to find mpi.h ...
Found in /usr/lib64/openmpi/1.2.7-gcc/include
Trying to find libmpi.so or libmpich.a ...
Found libmpi in /usr/lib64/openmpi/1.2.7-gcc/lib
checking for openpty in -lutil... yes
checking for main in -lpthread... yes
configure: creating ./config.status
config.status: creating src/Makevars
** libs
gcc -m64 -std=gnu99 -I/usr/include/R -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -I/usr/lib64/openmpi/1.2.7-gcc/include
-DMPI2 -DOPENMPI -I/usr/local/include-fpic -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c RegQuery.c -o
RegQuery.o
gcc -m64 -std=gnu99 -I/usr/include/R -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -I/usr/lib64/openmpi/1.2.7-gcc/include
-DMPI2 -DOPENMPI -I/usr/local/include-fpic -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c Rmpi.c -o Rmpi.o
gcc -m64 -std=gnu99 -I/usr/include/R -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -I/usr/lib64/openmpi/1.2.7-gcc/include
-DMPI2 -DOPENMPI -I/usr/local/include-fpic -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c conversion.c -o
conversion.o
gcc -m64 -std=gnu99 -I/usr/include/R -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -I/usr/lib64/openmpi/1.2.7-gcc/include
-DMPI2 -DOPENMPI -I/usr/local/include-fpic -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c internal.c -o
internal.o
gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o Rmpi.so RegQuery.o
Rmpi.o conversion.o internal.o -L/usr/lib64/openmpi/1.2.7-gcc/lib
-lmpi -lutil -lpthread -L/usr/lib64/R/lib -lR
** R
** demo
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
* DONE (Rmpi)
==
The same effect (or lack thereof) can be had with configure.vars in
install.packages:
install.packages("Rmpi",
configure.args="--with-mpi=/usr/lib64/openmpi/1.2.7-gcc",
configure.vars="CC=mpicc")
Warnin
[Rd] serialize/unserialize vector improvement
Hi folks,
I've attached a patch to the svn trunk that improves the performance
of the serialize/unserialize interface for vector types. The current
implementation: a) invokes the R_XDREncode operation for each element
of the vector type, and b) uses a switch statement to determine the
stream type for each element of the vector type. I've added
R_XDREncodeVector/R_XDRDecodeVector functions that accept N elements
at a time, and I've reorganized the implementation so that the stream
type is not queried once per element.
In the following microbenchmark (below), I've observed performance
improvements of about x2.4. In a real benchmark that is using the
serialization interface to make MPI calls, I see about a 10%
improvement in performance.
Cheers,
--Michael
microbenchmark:
input <- matrix(1:1, 1, 1)
output <- serialize(input, NULL)
for(i in 1:10) { print(system.time(serialize(input, NULL))) }
for(i in 1:10) { print(system.time(unserialize(output))) }
Index: src/include/Rinternals.h
===
--- src/include/Rinternals.h (revision 57107)
+++ src/include/Rinternals.h (working copy)
@@ -749,6 +749,7 @@
void Rf_warningcall_immediate(SEXP, const char *, ...);
/* Save/Load Interface */
+#define R_XDR_COMPLEX_SIZE 16
#define R_XDR_DOUBLE_SIZE 8
#define R_XDR_INTEGER_SIZE 4
@@ -757,6 +758,13 @@
void R_XDREncodeInteger(int i, void *buf);
int R_XDRDecodeInteger(void *buf);
+void R_XDREncodeDoubleVector(double *d, void *buf, int len);
+void R_XDRDecodeDoubleVector(void *input, double *output, int len);
+void R_XDREncodeComplexVector(Rcomplex *c, void *buf, int len);
+void R_XDRDecodeComplexVector(void *input, Rcomplex *output, int len);
+void R_XDREncodeIntegerVector(int *i, void *buf, int len);
+void R_XDRDecodeIntegerVector(void *input, int *output, int len);
+
typedef void *R_pstream_data_t;
typedef enum {
Index: src/main/serialize.c
===
--- src/main/serialize.c (revision 57107)
+++ src/main/serialize.c (working copy)
@@ -792,20 +792,62 @@
WriteItem(STRING_ELT(s, i), ref_table, stream);
}
-/* e.g., OutVec(fp, obj, INTEGER, OutInteger) */
-#define OutVec(fp, obj, accessor, outfunc)\
- do {\
- int cnt; \
- for (cnt = 0; cnt < LENGTH(obj); ++cnt) \
- outfunc(fp, accessor(obj, cnt)); \
- } while (0)
-
-#define LOGICAL_ELT(x,__i__) LOGICAL(x)[__i__]
#define INTEGER_ELT(x,__i__) INTEGER(x)[__i__]
#define REAL_ELT(x,__i__) REAL(x)[__i__]
#define COMPLEX_ELT(x,__i__) COMPLEX(x)[__i__]
#define RAW_ELT(x,__i__) RAW(x)[__i__]
+#define OutVec(NAME, CAPNAME, XDR, CAPXDR, TYPE) \
+static R_INLINE void Out ## NAME ## Vec(R_outpstream_t stream, SEXP s, int length) \
+{\
+ OutInteger(stream, length); \
+ switch (stream->type) { \
+ case R_pstream_xdr_format: \
+ if (length > (128 / R_XDR_## CAPXDR ##_SIZE)) \
+ { \
+ char *buf = Calloc( R_XDR_ ## CAPXDR ## _SIZE * length, char); \
+ R_XDREncode ## XDR ## Vector(CAPNAME(s), buf, length);\
+ stream->OutBytes(stream, buf, R_XDR_ ## CAPXDR ## _SIZE * length); \
+ Free(buf); \
+ } else {\
+ char buf[128]; \
+ R_XDREncode ## XDR ## Vector(CAPNAME(s), buf, length);\
+ stream->OutBytes(stream, buf, R_XDR_ ## CAPXDR ## _SIZE * length); \
+ } \
+ break; \
+ case R_pstream_binary_format:\
+ stream->OutBytes(stream, CAPNAME(s), sizeof(TYPE) * length); \
+ break; \
+ default: \
+ { \
+ int cnt;\
+ for (cnt = 0; cnt < length; ++cnt) \
+ Out ## NAME(stream, CAPNAME ## _ELT(s, cnt)); \
+ } \
+ } \
+}
+
+OutVec(Integer, INTEGER, Integer, INTEGER, int)
+OutVec(Real, REAL, Double, DOUBLE, double)
+OutVec(Complex, COMPLEX, Complex, COMPLEX, Rcomplex)
+
+static R_INLINE void OutByteVec(R_outpstream_t stream, SEXP s, int length)
+{
+ OutInteger(stream, length);
+ switch (stream->type) {
+ case R_pstream_xdr_format:
+ case R_pstream_binary_format:
+ stream->OutBytes(stream, RAW(s), length);
+ break;
+ default:
+ {
+ int cnt;
+ for (cnt = 0; cnt < length; ++cnt)
+ OutByte(stream, RAW_ELT(s, cnt));
+ }
+ }
+}
+
static void WriteItem (SEXP s, SEXP ref_table, R_outpstream_t stream)
{
int i;
@@ -932,16 +974,13 @@
break;
case LGLSXP:
case INTSXP:
- OutInteger(stream, LENGTH(s));
- OutVec(stream, s, INTEGER_ELT, OutInteger);
+ OutIntegerVec(stream, s, LENGTH(s));
break;
case REALSXP:
- OutInteger(stream, LENGTH(s));
- OutVec(stream, s, REAL_ELT, OutReal);
+ OutRealVec(stream, s, LENGTH(s));
break;
case CPLXSXP:
- OutInteger(stream, LENGTH(s));
- OutVec(stream, s, COMPLEX_ELT, OutComplex);
+ OutComplexVec(stream, s, LENGTH(s));
bre
Re: [Rd] serialize/unserialize vector improvement
Any thoughts? I haven't heard any feedback on this patch.
Thanks!
--Michael
On Wed, Sep 28, 2011 at 3:10 PM, Michael Spiegel
wrote:
> Hi folks,
>
> I've attached a patch to the svn trunk that improves the performance
> of the serialize/unserialize interface for vector types. The current
> implementation: a) invokes the R_XDREncode operation for each element
> of the vector type, and b) uses a switch statement to determine the
> stream type for each element of the vector type. I've added
> R_XDREncodeVector/R_XDRDecodeVector functions that accept N elements
> at a time, and I've reorganized the implementation so that the stream
> type is not queried once per element.
>
> In the following microbenchmark (below), I've observed performance
> improvements of about x2.4. In a real benchmark that is using the
> serialization interface to make MPI calls, I see about a 10%
> improvement in performance.
>
> Cheers,
> --Michael
>
> microbenchmark:
>
> input <- matrix(1:1, 1, 1)
> output <- serialize(input, NULL)
> for(i in 1:10) { print(system.time(serialize(input, NULL))) }
> for(i in 1:10) { print(system.time(unserialize(output))) }
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-sig-hpc] R CMD INSTALL configure.args and CC customization
Thanks! This is a possible solution, but I would argue not a preferable solution. I'd advocate a mechanism that provides transparent support for MPI, analogous to the way that R 2.13.0 and upwards provides transparent support for OpenMP. Expressing a personal opinion, I would stress the importance of providing both shared memory and message parallel parallelism out-of-the-box in the R interpreter. To use OpenMP or MPI the user would need to have runtime libraries pre-installed on their system. This patch would make it easier for a library to auto-detect an MPI implementation, assuming mpicc is in the path. My initial post on r-devel had a bug, sorry about that. I've posted a new patch on r-sig-hpc that behaves as intended. It is available here: https://stat.ethz.ch/pipermail/r-sig-hpc/2011-September/001104.html. -Original Message- From: r-sig-hpc-boun...@r-project.org [mailto:r-sig-hpc-boun...@r-project.org] On Behalf Of George Ostrouchov Sent: Tuesday, October 11, 2011 9:59 AM To: michael.m.spieg...@gmail.com Cc: r-sig-...@r-project.org; r-devel@r-project.org Subject: Re: [R-sig-hpc] R CMD INSTALL configure.args and CC customization One way to deal with this is to install R itself with mpicc. Then all packages are installed with mpicc and get the required MPI libraries and includes by default. I have done this with R-2.13.0 on an Opteron cluster running CentOS-5 a while ago and so far it has worked out great. I crosspost to r-sig-hpc and welcome others to comment if there are potential downsides to this solution. George > Michael Spiegel michael.m.spiegel at gmail.com > <mailto:r-devel%40r-project.org?Subject=Re%3A%20%5BRd%5D%20R%20CMD%20I > NSTALL%20configure.args%20and%20CC%20customization&In-Reply-To=%3CCANw > u5-rGUYrC73vRo04GJCdW_ZQerycbVU4K_2Dun1ytqNXQ7g%40mail.gmail.com%3E> > /Fri Sep 9 20:40:42 CEST 2011/ > I am running into the following issue that has been previously > reported on the R-devel mailing list. The short version is that I'm > writing a package for MPI, and I'd like to change CC and SHLIB_LD to > "mpicc". Trying to change them in Makevars.in has no effect, because > the values are clobbered by /etc/R/Makeconf. Will the following > changes to Makeconf.in introduce any problems? > > --Michael -- George Ostrouchov Statistics and Data Sciences Group Computer Science and Mathematics Division Oak Ridge National Laboratory (865) 574-3137 http://www.csm.ornl.gov/~ost [[alternative HTML version deleted]] ___ R-sig-hpc mailing list r-sig-...@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-hpc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] exporting isChild in package parallel
I was wondering if there is any interest in making the function isChild() exported from the package parallel? This would be of great help to anyone writing R packages that use thread-level parallelism, and would like to throttle the spawning of threads whenever the R process is detected to be a child process that was constructed by mcfork(). Cheers, --Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serialize/unserialize vector improvement
Has there been any movement on this patch? It will improve the
serialize/unserialize performance.
Thanks,
--Michael
On Mon, Oct 3, 2011 at 9:28 AM, wrote:
> It's on my list to look at but I may not get to it for a couple of
> weeks. Someone else may get there earlier.
>
> Best,
>
> luke
>
>
> On Mon, 3 Oct 2011, Michael Spiegel wrote:
>
>> Any thoughts? I haven't heard any feedback on this patch.
>>
>> Thanks!
>> --Michael
>>
>> On Wed, Sep 28, 2011 at 3:10 PM, Michael Spiegel
>> wrote:
>>>
>>> Hi folks,
>>>
>>> I've attached a patch to the svn trunk that improves the performance
>>> of the serialize/unserialize interface for vector types. The current
>>> implementation: a) invokes the R_XDREncode operation for each element
>>> of the vector type, and b) uses a switch statement to determine the
>>> stream type for each element of the vector type. I've added
>>> R_XDREncodeVector/R_XDRDecodeVector functions that accept N elements
>>> at a time, and I've reorganized the implementation so that the stream
>>> type is not queried once per element.
>>>
>>> In the following microbenchmark (below), I've observed performance
>>> improvements of about x2.4. In a real benchmark that is using the
>>> serialization interface to make MPI calls, I see about a 10%
>>> improvement in performance.
>>>
>>> Cheers,
>>> --Michael
>>>
>>> microbenchmark:
>>>
>>> input <- matrix(1:1, 1, 1)
>>> output <- serialize(input, NULL)
>>> for(i in 1:10) { print(system.time(serialize(input, NULL))) }
>>> for(i in 1:10) { print(system.time(unserialize(output))) }
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics and Fax: 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
Re: [Rd] diag() has a bug (PR#13702)
The intent of diag(foo, 2, 2) was to return a matrix that is a 2 x 2 matrix which contains only the diagonal entries of the matrix foo. I can't do diag(foo) because this returns a vector. I could reach my goal with matrix(diag(foo), nrow = nrow(foo), ncol = ncol(foo)). If this is not a reasonable thing for diag(, , ) to return, then at the very least the error message should be changed, as the first argument is in fact a matrix. On Thu, May 14, 2009 at 3:24 PM, Benilton Carvalho wrote: > My understanding is that providing nrow and ncol, you want to create a > diagonal matrix with those dimensions. > > diag(pi, 6, 6) > > and that by > > diag(foo, 2, 2) > > you really meant > > diag(foo)[2] > > Apologies if I misunderstood. > > b > > On May 14, 2009, at 10:45 AM, michael.m.spie...@gmail.com wrote: > > Full_Name: Michael Spiegel >> Version: 2.9.0 >> OS: linux >> Submission from: (NULL) (204.111.252.142) >> >> >> The diag() function appears to reject the first argument when it is a >> matrix, >> and nrow and ncol arguments are also provided. >> >> foo <- matrix(c(1:4),2,2) >>> foo >>> >>[,1] [,2] >> [1,]13 >> [2,]24 >> >>> diag(foo) >>> >> [1] 1 4 >> >>> diag(foo, 2, 2) >>> >> Error in diag(foo, 2, 2) : first argument is array, but not matrix. >> >>> is.matrix(foo) >>> >> [1] TRUE >> >> __ >> 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] diag() has a bug (PR#13702)
Aha. Yes, it would. Thank you. However the error message is still incorrect. On Thu, May 14, 2009 at 3:35 PM, Benilton Carvalho wrote: > in that case, wouldn't > > diag(diag(foo)) > > suffice? > > b > > > On May 14, 2009, at 4:30 PM, Michael Spiegel wrote: > > The intent of diag(foo, 2, 2) was to return a matrix that is a 2 x 2 >> matrix which contains only the diagonal entries of the matrix foo. I can't >> do diag(foo) because this returns a vector. I could reach my goal with >> matrix(diag(foo), nrow = nrow(foo), ncol = ncol(foo)). If this is not a >> reasonable thing for diag(, , ) to return, then at >> the very least the error message should be changed, as the first argument is >> in fact a matrix. >> >> On Thu, May 14, 2009 at 3:24 PM, Benilton Carvalho >> wrote: >> My understanding is that providing nrow and ncol, you want to create a >> diagonal matrix with those dimensions. >> >> diag(pi, 6, 6) >> >> and that by >> >> diag(foo, 2, 2) >> >> you really meant >> >> diag(foo)[2] >> >> Apologies if I misunderstood. >> >> b >> >> On May 14, 2009, at 10:45 AM, michael.m.spie...@gmail.com wrote: >> >> Full_Name: Michael Spiegel >> Version: 2.9.0 >> OS: linux >> Submission from: (NULL) (204.111.252.142) >> >> >> The diag() function appears to reject the first argument when it is a >> matrix, >> and nrow and ncol arguments are also provided. >> >> foo <- matrix(c(1:4),2,2) >> foo >> [,1] [,2] >> [1,]13 >> [2,]24 >> diag(foo) >> [1] 1 4 >> diag(foo, 2, 2) >> Error in diag(foo, 2, 2) : first argument is array, but not matrix. >> is.matrix(foo) >> [1] TRUE >> >> __ >> 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] c() poor error reporting (PR#13917)
Hi, Thanks. I think I failed to communicate what I believe should be corrected. The error message itself contains correct information, it is what is missing from the error message that is desired. The message "argument is missing, with no default" does not inform the user in what function the error occured. I have the good sense to run traceback() and figure out where the error occured. But several of the users in the R package we maintain write horribly nested scripts "foo(bar(baz(quux(c(,'a','b','c')" and don't incrementally test their programs. I am proposing the error message state "in function c() an argument is missing, with no default". It's an issue of usability, but granted not a major issue. I will not be able to submit a patch in the near future, but thank you for the reply. --Michael On Sat, Aug 29, 2009 at 5:53 PM, Duncan Murdoch wrote: > On 28/08/2009 5:00 PM, michael.m.spie...@gmail.com wrote: >> >> Full_Name: Michael Spiegel >> Version: 2.9.1 >> OS: linux >> Submission from: (NULL) (137.54.6.192) >> >> >> The function c() gives a cryptic error message if an "empty" argument is >> accidentally passed to the function. > > I wouldn't call that cryptic. You put in a blank argument, and it told you > the argument was missing. > > The expression c(,,,) yields the error >> >> message "argument is missing, with no default". For comparison, the >> expression >> sum(,,,) yields the error message "element 1 is empty; the part of the >> args list >> of 'sum' being evaluated was: (, , , )". This type of error was produced >> by >> accidentally typing an expression similar to "sum(c(,1,2,3))" which was a >> sub-expression inside a much larger expression spanning tens of lines. >> When the >> entire expression was evaluated, the error message "argument is missing, >> with no >> default" provides little context for determining the cause of the error. > > Yes, sum() is more friendly in its error reporting. This hardly qualifies > as a bug, but if you want to submit a patch, it would be considered. > > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install (PR#14226)
I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. To create the binary release, I run R CMD INSTALL --build. The beta test users install the package using the following script: http://openmx.psyc.virginia.edu/getOpenMx.R. On Wed, Mar 3, 2010 at 9:48 AM, Tim Brick wrote: > > >> From: Simon Urbanek >> Date: March 3, 2010 8:32:52 AM MST >> To: tbr...@virginia.edu >> Cc: r-de...@stat.math.ethz.ch, r-b...@r-project.org >> Subject: Re: [Rd] libgfortran misplaced in Mac OS X R install (PR#14226) >> >> This is not an R bug so please don't abuse R-bugs. It is likely a bug in the >> way OpenMx binaries are distributed by someone (you didn't even say where >> you got them from) - OpenMx is not even on CRAN so take that to whoever gave >> you the binaries. On CRAN we use the correct paths. >> >> Cheers, >> Simon >> >> >> On Mar 2, 2010, at 11:45 , tbr...@virginia.edu wrote: >> >>> Full_Name: Timothy Brick >>> Version: 2.10 >>> OS: Mac OS X (seen on both 10.6 and 10.5) >>> Submission from: (NULL) (63.255.24.5) >>> >>> >>> When using install.packages in R on Mac OS X, packages that require gfortran >>> throws an error (Example below from installation of OpenMx package): >>> >>> Loading required package: OpenMx >>> Error in dyn.load(file, DLLpath = DLLpath, ...) : >>> unable to load shared library >>> '/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so': >>> dlopen(/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so, >>> 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib >>> Referenced from: >>> /Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so >>> Reason: image not found >>> >>> libgfortran.2.dylib does exist, but in >>> /Library/Frameworks/R.framework/Versions/2.10/Resouces/lib/libgfortran.2.dylib >>> (or /2.9/, depending on version installed). >>> >>> A workaround at present involves creating a symbolic link from the above >>> file to >>> /usr/local/lib/libgfortran.2.dylib, however this requires sudo access and is >>> confusing for novice users. >>> >>> There is more discussion of this bug as it relates to OpenMx at: >>> http://openmx.psyc.virginia.edu/thread/316 >>> >>> Posts on other forums indicate a similar issue with other packages including >>> vegan and lme4: >>> http://r-forge.r-project.org/forum/forum.php?thread_id=728&forum_id=194 >>> https://stat.ethz.ch/pipermail/r-sig-mac/2009-May/006210.html >>> >> >> Those are very old posts and those were temporary issues in the CRAN build >> system that have been promptly resolved. >> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install
Thank you both for the advice. It sounds like we have a solution for our next binary release of the beta package. --Michael On Thu, Mar 4, 2010 at 2:44 PM, Prof Brian Ripley wrote: > Another possibility is to link statically to libgfortran. That has pros and > cons, but for libgfortran not many cons apart from space for multiple copies > in sundry packages (and is what is done on Windows, BTW). > > There are several ways to arrange that. As far as I recall I temporarily > removed /usr/local/lib/libgfortran*.dylib: another way is to edit FLIBS in > Makeconf (but then you do need to know which copies of that file you need to > edit). > > As far as I know we don't document in the standard manuals how to build > distributable binary Mac packages, and perhaps we should do so in due course > (or at least point at where the information can be found). > > On Thu, 4 Mar 2010, Simon Urbanek wrote: > >> Hi Michael, >> >> On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: >> >>> I am the guy who compiles the OpenMx binaries. We would be delighted to >>> place our package on CRAN, once the project is stable enough so that we are >>> comfortable releasing it to the larger public. Let's try to track down >>> where I made a mistake. Our Makevars.in file contains the line: >>> >>> PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) >>> >>> In addition, on the build machine I noticed that a copy of >>> libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install >>> placed a copy of it there. >> >> No, it is part of the GNU Fortran installation. Anything you compile with >> a Fortran requires that you have that Fortran installed at run time, because >> Fortran uses its own run-time libraries (if the Fortran you compiled with >> used dynamic libraries). This implies that if you distribute your package >> you have to tell users to install the same Fortran you used to compile it. >> >> However, unlike other unices Mac users don't necessarily have development >> tools installed, so on CRAN we make an effort to modify the binaries such >> that they work even without the tools they have been compiled with. There >> are several possible approaches, but since R itself already uses the same >> Fortran, we ship a copy of the Fortran libraries inside R and modify >> packages such that they use it instead of the one from dev tools (see below >> for details). >> >> >>> To create the binary release, I run R CMD INSTALL --build. >> >> That is not sufficient to create a binary of your package, because it >> contains a configure script (this is unrelated to the above - see R-admin >> 2.6). What you want to use is something like this (assuming R 2.10.1 Leopard >> build and Fortran from CRAN): >> >> R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz >> R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz >> R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz >> cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library >> >> # fix the Fortran paths to point to R 2.10 instead >> for lib in `ls OpenMx/libs/*/*.so`; do >> install_name_tool -change /usr/local/lib/libgfortran.2.dylib \ >> >> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libgfortran.2.dylib >> \ >> $lib >> done >> >> # change permissions for distribution >> sudo chown -Rh root:admin OpenMx >> sudo chmod -R g+w OpenMx >> >> # pack it up >> tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx >> >> >> You can check that you have the correct paths using otool -L: >> >> ginaz:library$ otool -L OpenMx/libs/*/*.so >> OpenMx/libs/i386/OpenMx.so: >> OpenMx.so (compatibility version 0.0.0, current version 0.0.0) >> >> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libgfortran.2.dylib >> (compatibility version 3.0.0, current version 3.0.0) >> >> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRblas.dylib >> (compatibility version 0.0.0, current version 0.0.0) >> >> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRlapack.dylib >> (compatibility version 2.10.0, current version 2.10.1) >> >> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib >> (compatibility version 2.10.0, current version 2.10.1) >> >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> (compatibility version 150.0.0, current version 476.19.0) >> /usr/lib/libgcc_s.1.dylib (compatibility versi
