[Rd] Error when compiling R with openblas

2014-07-01 Thread Alexander Braumann 

Hi,

I tried to compile R with openblas on a ubuntu 12.04 machine. I have to 
say that I normally use the package system and that I have no experience 
with compiling R.


I did the following:

./configure --enable-BLAS-shlib --enable-R-shlib LIBnn=lib 
--with-blas="-L/usr/lib/openblas-base/ -lopenblas" 
--enable-memory-profiling --with-x=yes



go the output:

R is now configured for x86_64-unknown-linux-gnu

  Source directory:  .
  Installation directory:/usr/local

  C compiler:gcc -std=gnu99  -g -O2
  Fortran 77 compiler:   gfortran  -g -O2

  C++ compiler:  g++  -g -O2
  C++ 11 compiler:   g++  -std=c++0x -g -O2
  Fortran 90/95 compiler:gfortran -g -O2
  Obj-C compiler:

  Interfaces supported:  X11
  External libraries:readline, BLAS(generic), lzma
  Additional capabilities:   PNG, JPEG, NLS
  Options enabled:   shared R library, shared BLAS, R 
profiling, memory profiling


  Recommended packages:  yes

configure: WARNING: you cannot build info or HTML versions of the R manuals



Then: make - and then comes the error:

make[4]: Entering directory `/home/ab/Downloads/R-3.1.0/src/main'
make[4]: Leaving directory `/home/ab/Downloads/R-3.1.0/src/main'
make[3]: Leaving directory `/home/ab/Downloads/R-3.1.0/src/main'
make[3]: Entering directory `/home/ab/Downloads/R-3.1.0/src/main'
gcc -std=gnu99 -Wl,--export-dynamic -fopenmp  -L/usr/local/lib -o R.bin 
Rmain.o  -L../../lib -lR -lRblas

../../lib/libR.so: undefined reference to `drot_'
../../lib/libR.so: undefined reference to `dtrsm_'
../../lib/libR.so: undefined reference to `dswap_'
../../lib/libR.so: undefined reference to `dcopy_'
../../lib/libR.so: undefined reference to `ddot_'
../../lib/libR.so: undefined reference to `dgemm_'
../../lib/libR.so: undefined reference to `dscal_'
../../lib/libR.so: undefined reference to `dnrm2_'
../../lib/libR.so: undefined reference to `dsyrk_'
../../lib/libR.so: undefined reference to `dasum_'
../../lib/libR.so: undefined reference to `daxpy_'
../../lib/libR.so: undefined reference to `drotg_'
../../lib/libR.so: undefined reference to `zgemm_'
collect2: ld returned 1 exit status
make[3]: *** [R.bin] Error 1
make[3]: Leaving directory `/home/ab/Downloads/R-3.1.0/src/main'
make[2]: *** [R] Error 2
make[2]: Leaving directory `/home/ab/Downloads/R-3.1.0/src/main'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/home/ab/Downloads/R-3.1.0/src'
make: *** [R] Error 1


I am wondering why libR.so wants to find these functions and not 
libRblas.so. The lib libRblas.so can be found in


> locate libRblas.so

/home/ab/Downloads/R-3.1.0/lib/libRblas.so
/home/ab/Downloads/R-3.1.0/src/extra/blas/libRblas.so

they have both the same size.


can anyone help me with this?

cheers,

alex

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error when compiling R with openblas

2014-07-01 Thread Dirk Eddelbuettel 

On 1 July 2014 at 12:00, Alexander Braumann wrote:
| I tried to compile R with openblas on a ubuntu 12.04 machine. I have to 
| say that I normally use the package system and that I have no experience 
| with compiling R.

You do not need to do that.  Just install the existing OpenBLAS package via

libopenblas-base

(which you may already have) and R will use as the BLAS interface is
generic. That is what the package tries to tell you via [edited]

  edd@max:~$ dpkg -s r-base-core
  Package: r-base-core
  [...]
  Version: 3.1.0-1trusty0
  Depends: [...], libblas3 | libblas.so.3, [...], liblapack3 | liblapack.so.3, 
[...]
  ^^^ 

Any suitable LAPACK and BLAS package providing libblas3 / liblapack3 can be
used -- plug and play. And OpenBLAS plays along.

Also:
 
| I did the following:
| 
| ./configure --enable-BLAS-shlib --enable-R-shlib LIBnn=lib 
| --with-blas="-L/usr/lib/openblas-base/ -lopenblas" 
| --enable-memory-profiling --with-x=yes
| 
| 
| go the output:
| 
| R is now configured for x86_64-unknown-linux-gnu
| 
|Source directory:  .
|Installation directory:/usr/local
| 
|C compiler:gcc -std=gnu99  -g -O2
|Fortran 77 compiler:   gfortran  -g -O2
| 
|C++ compiler:  g++  -g -O2
|C++ 11 compiler:   g++  -std=c++0x -g -O2
|Fortran 90/95 compiler:gfortran -g -O2
|Obj-C compiler:
| 
|Interfaces supported:  X11
|External libraries:readline, BLAS(generic), lzma
  ^^

tells you that you failed to tell the build about your OpenBLAS. It fell back
to generic.

This is all in the 'Installation + Administration' manual. But you really
don't need to do this by hand.

I suggest you send follow-up to the r-sig-debian list. Its archives also have
past discussions of this and related questions.

Regards,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Building R on Windows: mkdir of Rtools creates directories with read-only permissions [WEIRD]

2014-07-01 Thread Milan Bouchet-Valat 
Le lundi 30 juin 2014 à 15:32 -0400, Duncan Murdoch a écrit :
> On 30/06/2014 2:41 PM, Milan Bouchet-Valat wrote:
> > Le lundi 30 juin 2014 à 05:23 -0400, Duncan Murdoch a écrit :
> > > On 30/06/2014, 4:44 AM, Milan Bouchet-Valat wrote:
> > > > On Thu Jan 9 2014 03:47 Henrik Bengtsson wrote:
> > > >> This is is an issue that bugged me for a while.  I encountered a year
> > > >> ago (April 2012) when I first tried to build R from source on Windows.
> > > >>  I never figured out what the solution is or if I'm doing something
> > > >> wrong myself (but I have found a tedious workaround).  I'm still on
> > > >> the same Windows 7 Ultimate machine with NTFS, but I now made sure I
> > > >> started from scratch so I have a completely fresh setup (see details
> > > >> at the end).
> > > >>
> > > >> PROBLEM:
> > > >> At the very first step I do:
> > > >>
> > > >> C:\R\src\gnuwin32>make all
> > > >> [... Waiting. No errors until ...]
> > > >> cp R.dll ../../bin/i386
> > > >>  Building ../../../bin/i386/Rblas.dll 
> > > >> gcc -std=gnu99  -shared  -o ../../../bin/i386/Rblas.dll blas.o
> > > >> cmplxblas.o ../../gnuwin32/dllversion.o Rblas.def -L../../../bin/i386
> > > >> -lR -lgfortran
> > > >> c:/rtools/gcc-4.6.3/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe:
> > > >> cannot find -lR
> > > >> collect2: ld returned 1 exit status
> > > >> make[2]: *** [../../../bin/i386/Rblas.dll] Error 1
> > > >> make[1]: *** [Rblas] Error 2
> > > >> make: *** [rbuild] Error 2
> > > >>
> > > >> However:
> > > >>
> > > >> C:\R\src\gnuwin32>dir ..\..\bin\i386\
> > > >>  Volume in drive C is Windows7_OS
> > > >>  Volume Serial Number is E038-51CC
> > > >>
> > > >>  Directory of C:\R\bin\i386
> > > >>
> > > >> 01/08/2014  06:18 PM  .
> > > >> 01/08/2014  06:18 PM  ..
> > > >> 01/08/2014  06:18 PM 3,059,712 R.dll
> > > >> 01/08/2014  06:18 PM   348,995 Rgraphapp.dll
> > > >> 01/08/2014  06:18 PM   102,975 Riconv.dll
> > > >> 01/08/2014  06:18 PM   154,917 Rzlib.dll
> > > >>4 File(s)  3,666,599 bytes
> > > >>2 Dir(s)  22,424,739,840 bytes free
> > > >>
> > > >> What's weird is that these files have **read permission disabled**:
> > > >>
> > > >> C:\R\src\gnuwin32>file ..\..\bin\i386\*.dll
> > > >> ..\..\bin\i386\R.dll: writable, executable, regular file, no
> > > >> read permission
> > > >> ..\..\bin\i386\Rgraphapp.dll: writable, executable, regular file, no
> > > >> read permission
> > > >> ..\..\bin\i386\Riconv.dll:writable, executable, regular file, no
> > > >> read permission
> > > >> ..\..\bin\i386\Rzlib.dll: writable, executable, regular file, no
> > > >> read permission
> > > >>
> > > >> What is going on?  Have anyone else seen this?  I've also tried
> > > >> running as Administrator - no difference.
> > > > Hi Henrik,
> > > >
> > > > Old thread, but I think I'm experiencing exactly the same problem. I
> > > > tried running as administrator and as a normal user, and no luck. I
> > > > noticed, though, that resetting permissions on the build tree makes the
> > > > error go away, and replaces it with another one stating that headers in
> > > > include/ could not be created due to permission issues.
> > > >
> > > > This is on a machine where I was able to build R 3.0.1 successfully,
> > > > though I also remember having permission issues I eventually fixed by
> > > > resetting permissions on the build tree. Not sure what's changed since
> > > > then...
> > > >
> > > > To add bit of information to the debugging you've already done: I
> > > > noticed that when opening the directory/file property dialog, a user
> > > > with a very long name including letters and numbers appears in the
> > > > permissions list for a second, and then disappears. This user reappears
> > > > every time I run 'make'. So maybe 'mkdir' or other tools use wrong user
> > > > IDs, creating bogus users. Just a guess.
> > > >
> > > > Have you found a solution or workaround since January? I really need to
> > > > build an R installer and I seem to be stuck...
> > >
> > > I have seen this, but I don't see it on every machine.  One one where I
> > > do see it is the Windows builder machine in Dortmund.  The following is
> > > inserted into the script after building the 32 bit build
> > >
> > > cacls %name32% /T /E /G VORDEFINIERT\Benutzer:R > NUL
> > >
> > > and similar after the 64 bit build.  (I don't remember whether
> > > VORDEFINIERT\Benutzer is the current user name, or is some generic thing
> > > saying "current user".  I think Uwe Ligges came up with this...)
> > Thanks. VORDEFINIERT\Benutzer appears to mean BUILTIN\Users (BUILTIN
> > \Utilisateurs in French), and refers to any user on the system (more or
> > less).
> >
> > Unfortunately, I've run that, and it doesn't make any difference to the
> > error I'm seeing. But I don't understand what you mean by "after
> > building the 32 bit build" since the proble

Re: [Rd] R CMD check warning with S3 method

2014-07-01 Thread Michael Lawrence 
On Mon, Jun 30, 2014 at 6:19 AM, Duncan Murdoch 
wrote:

> On 30/06/2014 8:51 AM, Michael Lawrence wrote:
>
>> I think it's generally nice to be able to compute on the network of
>> imported and exported symbols, and exportFrom() preserves the information
>> that a symbol has been forwarded. But let's focus on the use case of
>> documenting the symbol.
>>
>> First, from the user perspective: my understanding (without testing
>> anything) is that with promptImport(), the call to help() will find two or
>> more hits to the symbol, so the user has to choose from a menu or otherwise
>> qualify the package.
>>
>
> It depends how the user formulates it.  The usual ?foo will find at least
> two hits.  But if a user qualifies it by saying ?pkg::foo,
> they'll just get the redirect page.
>
> I think we need ?pkg::foo to do something, and this seemed easier than
> inventing an invisible redirect.
>
>
>  Choosing the man page for the re-exported symbol will bring up a page
>> that just requests them to make an extra click. This seems like extra work
>> for the user. One potential benefit is that the user will know that a
>> re-export has occurred, but does the user care? Why not proceed directly to
>> the actual documentation? The majority of users have no or little knowledge
>> of namespaces.
>>
>
> I think some users would like to know that pkg::foo is identical to
> original::foo, so if we had the invisible redirect, I think the target page
> should be modified to say "redirected from ...", just so the users were
> sure they had come to the right place.
>
>
This is a good point. We could somehow add that message dynamically to the
displayed help, or emit a message at the console.


>
>> From the developer perspective, promptImport() means that there is
>> another man page to worry about, while exportFrom() would make it clear to
>> developers reading the NAMESPACE that symbols are being simply forwarded,
>> rather than re-defined.
>>
>
> Those are both benefits of your approach, which I wouldn't object to if
> you go ahead and do it subject to the qualifications above, and one other.
>  How should existing redirects be handled?  If a package imports and
> re-exports a symbol without change, should the author be
> encouraged/required to use exportFrom?  If we do nothing, most people will
> just do what they're currently doing, so maybe some sort of nag should be
> added.  Package writers won't like that unless there's some obvious benefit
> to the change.
>
>
Probably just not having to redocument the symbol manually (i.e., passing
check without a a warning, as there is now) will be a sufficient carrot.




> Duncan
>
>
>> Michael
>>
>>
>>
>> On Sun, Jun 29, 2014 at 12:43 PM, Duncan Murdoch <
>> murdoch.dun...@gmail.com > wrote:
>>
>> On 29/06/2014, 3:07 PM, Michael Lawrence wrote:
>> > While the change to the symbol lookup is generally useful (e.g., for
>> > finding S4 methods that become available whenever a package is
>> loaded),
>> > it seems that we ultimately want a mechanism by which a package
>> > namespace can formally declare that it is re-exporting a symbol from
>> > some package. Then, for example, the check mechanism can be made
>> smart
>> > enough to avoid throwing such warnings.
>> >
>> > I've developed a proof-of-concept exportFrom() namespace
>> directive. This
>> > is the syntax:
>> >
>> > exportFrom(utils, help)
>> >
>> > Then:
>> >
>> >> getNamespaceInfo("ReexportingPackage", "exports")$help
>> > [1] "help"
>> > attr(,"origin")
>> > [1] "utils"
>> >
>> > Comments?
>>
>> I don't see why this is needed.  What does it gain over
>> documenting that
>> the symbol "help" is just a copy of the one from utils?  As of this
>> morning, that's easy...
>>
>> Duncan Murdoch
>>
>> >
>> > Michael
>> >
>> >
>> > On Fri, Jun 27, 2014 at 8:32 PM, Yihui Xie > 
>> > >> wrote:
>> >
>> > Hi Duncan,
>> >
>> > Again, thanks a lot for making this change (help requests
>> are tried
>> > over all loaded instead of attached packages):
>> > https://github.com/wch/r-source/commit/21d2f7430b4 This makes what
>> I
>> > proposed last time possible now: if pkg B imports FUN from A and
>> > re-exports it, ?FUN will work after B is attached because A
>> will also
>> > be at least attached.
>> >
>> > Then it will be perfect if `R CMD check` can stop warning
>> against the
>> > missing documentation, which is not really missing.
>> >
>> > Regards,
>> > Yihui
>> > --
>> > Yihui Xie mailto:xieyi...@gmail.com>
>> >>
>>
>> > Web: http://yihui.name
>> >
>> >
>> > On Fri, Jun 20, 2014 at

[Rd] creating a package from a development source tree

2014-07-01 Thread Greg Minshall 
hi.  this is sort of a software methodology question.

i'm working on developing a package (with C source code).  developing
it, i use autotools, git, make, and such like.  as a result, there are
random files in my source code directory that "R CMD check" would rather
not see.  some of these files (such as .git and friends) i could arrange
to move to "just above" my development subtree; others of these (such as
configure.ac and the random crud autoreconf(1) and friends leave laying
around) can't be moved (afaik).

i'm curious how people move from their personal development tree to a
tree from which the package can be passed to "R CMD *".  do "you" have a
makefile in their tree that creates this?  during development, is this
the path you use for building and testing?

cheers, Greg Minshall

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] creating a package from a development source tree

2014-07-01 Thread Marc Schwartz 
On Jul 1, 2014, at 10:26 AM, Greg Minshall  wrote:

> hi.  this is sort of a software methodology question.
> 
> i'm working on developing a package (with C source code).  developing
> it, i use autotools, git, make, and such like.  as a result, there are
> random files in my source code directory that "R CMD check" would rather
> not see.  some of these files (such as .git and friends) i could arrange
> to move to "just above" my development subtree; others of these (such as
> configure.ac and the random crud autoreconf(1) and friends leave laying
> around) can't be moved (afaik).
> 
> i'm curious how people move from their personal development tree to a
> tree from which the package can be passed to "R CMD *".  do "you" have a
> makefile in their tree that creates this?  during development, is this
> the path you use for building and testing?
> 
> cheers, Greg Minshall


Hi,

Run 'R CMD check' on the file built from 'R CMD build', rather than on the 
actual package source file tree, as per:

  http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Checking-packages

from the Writing R Extensions manual.

You can also use the file .Rbuildignore to define files that should be 
excluded. See the fifth paragraph in:

  
http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Building-package-tarballs


Regards,

Marc Schwartz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] USE_CXX1X, Snow Leopard R binaries + Mavericks

2014-07-01 Thread Kevin Ushey 
Hi R-devel,

I'm noticing the following behaviour:

writeLines("#include ", file = "test.cpp")
Rcpp::sourceCpp("~/test.cpp") ## succeeds at trivial compile
Sys.setenv("USE_CXX1X" = "yes")
Rcpp::sourceCpp("~/test.cpp") ## fails; CXX nor CXX1X properly set (?)

IIUC, R is not propagating CXX nor CXX1X when USE_CXX1X is set on a
Snow Leopard CRAN build of R. Is this the expected behaviour? IIUC,
Snow Leopard binaries are built with older compilers and hence we
might not expect this to even work were CXX or CXX1X propagated (ie,
grabbing the Mavericks clang / clang++).

Comments on this in R-exts would be greatly appreciated as well.

kevinushey@s-169-232-64-218:~$ R --vanilla --slave -e "sessionInfo()"
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

kevinushey@s-169-232-64-218:~$ uname -a

Darwin s-169-232-64-218.resnet.ucla.edu 13.2.0 Darwin Kernel Version
13.2.0: Thu Apr 17 23:03:13 PDT 2014;
root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64

Cheers from useR2014,
Kevin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] creating a package from a development source tree

2014-07-01 Thread Greg Minshall 
thanks!  that, as did an off-list reply, gave me the clue i needed.
cheers.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel