Re: [Rd] Cannot Install Custom Package On Windows7 64-bit
On 18.05.2012 08:55, Steve Pederson wrote: Hi, After uninstalling Rtools 2.14.0, I have installed the latest version of Rtools 2.15.0 which gives the two folders C:\Rtools\bin C:\Rtools\gcc-4.6.3 R is installed in the directory C:\R\R-2.15.0 I have set the Environment Variable PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\R\R-2.15.0\bin; I am trying to install a custom package (BMEA_0.2.1) which is exactly as written& built successfully on R-2.14.0 When I use R CMD INSTALL BMEA_0.2.1.tar.gz, I get the following output * installing to library 'C:/R/R-2.15.0/library' * installing *source* package 'BMEA' ... ** libs cygwin warning: MS-DOS style path detected: C:/R/R-2.15.0/etc/x64/Makeconf Preferred POSIX equivalent is: /cygdrive/c/R/R-2.15.0/etc/x64/Makeconf CYGWIN environment variable option "nodosfilewarning" turns off this warning 1. Do what it says and set CYGWIN=nodosfilewarning to avoid lots of warnings. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames gcc -m64 -I"C:/R/R-2.15.0/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -02 -Wall -std=gnu99 -mtune-core2 -c getLogFC.c -o getLogFC.o gcc: not found 2. So far your PATH look good, but it may be messed up later on, hence tell us what echo %PATH% returns and be sure you started a new Windows command shell after changing the PATH environment variable. Best, Uwe Ligges make: *** [getLogFC.o] Error 127 ERROR: compilation failed for package 'BMEA' * removing 'C:/R/R-2.15.0/library/BMEA' It looks to me like it can't find the compiler, but I'm stumped as to how to make that happen. I can see the gcc.exe file in "C:\Rtools\gcc-4.6.3\bin" so it does seem to be there (if that's what it's trying to look for) Thanks in advance, Steve [[alternative HTML version deleted]] __ 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] Cannot Install Custom Package On Windows7 64-bit
Thank you for the look with fresh eyes Uwe. It was just the simple solution of opening a new command shell window. I thought I'd tried that along with the multiple reboots, but it must have been before I figured out the correct PATH settings. And thanks for the CYGWIN reminder too. :) All the best, Steve -Original Message- From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] Sent: Friday, 18 May 2012 5:27 PM To: stephen.peder...@adelaide.edu.au Cc: r-devel@r-project.org Subject: Re: [Rd] Cannot Install Custom Package On Windows7 64-bit On 18.05.2012 08:55, Steve Pederson wrote: > Hi, > > > > After uninstalling Rtools 2.14.0, I have installed the latest version > of Rtools 2.15.0 which gives the two folders > > C:\Rtools\bin > > C:\Rtools\gcc-4.6.3 > > > > R is installed in the directory > > C:\R\R-2.15.0 > > > > I have set the Environment Variable > > PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\R\R-2.15.0\bin; > > > > I am trying to install a custom package (BMEA_0.2.1) which is exactly > as written& built successfully on R-2.14.0 > > > > When I use R CMD INSTALL BMEA_0.2.1.tar.gz, I get the following output > > * installing to library 'C:/R/R-2.15.0/library' > > * installing *source* package 'BMEA' ... > > ** libs > > cygwin warning: > >MS-DOS style path detected: C:/R/R-2.15.0/etc/x64/Makeconf > >Preferred POSIX equivalent is: > /cygdrive/c/R/R-2.15.0/etc/x64/Makeconf > >CYGWIN environment variable option "nodosfilewarning" turns off > this warning 1. Do what it says and set CYGWIN=nodosfilewarning to avoid lots of warnings. >Consult the user's guide for more details about POSIX paths: > > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > > gcc -m64 -I"C:/R/R-2.15.0/include" -DNDEBUG > -I"d:/RCompile/CRANpkg/extralibs64/local/include" -02 -Wall > -std=gnu99 -mtune-core2 -c getLogFC.c -o getLogFC.o > > gcc: not found 2. So far your PATH look good, but it may be messed up later on, hence tell us what echo %PATH% returns and be sure you started a new Windows command shell after changing the PATH environment variable. Best, Uwe Ligges > make: *** [getLogFC.o] Error 127 > > ERROR: compilation failed for package 'BMEA' > > * removing 'C:/R/R-2.15.0/library/BMEA' > > > > It looks to me like it can't find the compiler, but I'm stumped as to > how to make that happen. I can see the gcc.exe file in > "C:\Rtools\gcc-4.6.3\bin" so it does seem to be there (if that's what > it's trying to look for) > > > > Thanks in advance, > > > > Steve > > > [[alternative HTML version deleted]] > > __ > 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] R-devel on FreeBSD: new C99 functions don't build
On 15/05/2012 20:45, Rainer Hurling wrote:
On 15.05.2012 20:49 (UTC+1), Murray Stokely wrote:
On Tue, May 15, 2012 at 10:05 AM, Rainer Hurling wrote:
About April 25th, there had been some changes within R-devel's
src/nmath/pnbeta.c (and probably some other relevant places) and now
building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and
math/R-devel (selfmade forked port from math/R) fails like this:
It seems, that at least one new C99 function (log1pl) is introduced in
R-devel, see
src/nmath/pnbeta.c:l95
return (double) (log_p ? log1pl(-ans) : (1 - ans));
AFAIK, Bruce Evans is not happy with the numerical accuracy of other
open-source implementations of log1pl and so has blocked their
inclusion in FreeBSD pending work on a better implementation.
Can you put a conditional FreeBSD check here and use log1p instead of
log1pl instead as a workaround?
I can admire the insistence on correctness from the FreeBSD libm
maintainers for their technical purity, but it can be a bit of a pain
for things like this.
- Murray
I read about this discussion and in principle I concur with your
opinion. As a scientist I tend to expect greatest possible correctness
from a statistical routine, especially when it uses long double format.
As a quick and dirty workaround I applied the following patch:
--- src/nmath/pnbeta.c.orig 2012-04-25 17:55:14.0 +0200
+++ src/nmath/pnbeta.c 2012-05-15 20:58:26.0 +0200
@@ -92,7 +92,11 @@
else {
if(ans > 1 - 1e-10) ML_ERROR(ME_PRECISION, "pnbeta");
if (ans > 1.0) ans = 1.0; /* Precaution */
+#if !defined(__FreeBSD__)
return (double) (log_p ? log1pl(-ans) : (1 - ans));
+#else
+ return (double) (log_p ? log1p(-ans) : (1 - ans));
+#endif /* FreeBSD */
}
}
It builds and installs fine now and I hope there are no side effects ...
Note though that R has *required* C99 compliance for quite a while, and
that is not now even the current C standard. Using an OS that fails to
comply to a 12-year-old standard is your own choice ... and you get the
choice of using an equally old version of R.
I've added log1pl to the depressing list of FreeBSD workarounds:
untested as I currently don't have access to a FreeBSD setup.
However, I think this has to come to an end: if a project such as
Mingw-w64 can make the effort to supply a great deal of the C99
functions missing from their OS then we must expect FreeBSD to do likewise.
Thank you for the quick answer and your advice,
Rainer
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Distributing Executables.
Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable. Thanks! Daniel Fuka __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Distributing Executables.
On May 18, 2012, at 11:11 AM, Daniel Fuka wrote: > Sorry for this intrusion, but I am confused by two statements that > appear to conflict at some level in Writing R Extensions, and wanted > to make sure I understand the answer to: > Can we distribute a portable executable compiled from source by CRAN in CRAN? > > The following section of Writing R Extensions appears to not be > addressing this issue, as in this case we are discussing portable CRAN > compiled binaries, and not binaries that are submitted to CRAN: > "A source package if possible should not contain binary executable > files: they are not portable, and a security risk if they are of the > appropriate architecture. R CMD check will warn about them unless they > are listed (one filepath per line) in a file BinaryFiles at the top > level of the package. Note that CRAN will no longer accept submissions > containing binary files even if they are listed." > > The following section seems to indicate special cases in which > packages can create binary files: > "In very special cases packages may create binary files other than the > shared objects/DLLs in the src directory. Such files will not be > installed in multi-arch setting since R CMD INSTALL --libs-only is > used to merge multiple architectures and it only copies shared > objects/DLLs. If a package wants to install other binaries (for > example executable programs), it should to provide an R script > src/install.libs.R which will be run as part of the installation in > the src build directory instead of copying the shared objects/DLLs." > > Once again, sorry for my confusion on this point. I just have what I > might consider a special case where it would be very handy to > distribute a cran compiled executable. I don't quite follow - CARN obviously distributes binaries compiled by CRAN and those are called binary packages. Can you be more specific as of what you are asking about? The two paragraphs you are quoting are about entirely different things - the first states that you can't include binaries in *source* packages and the second describes how you can build executables beside dynamic objects in packages so that CRAN can include them in *binary* packages. It doesn't cover distribution. What you refer to are rules for *source* packages which can't distribute binaries, but you can always use a binary package (which contains binaries). Note that the issue in question is not who built the binary but whether it could have been injected by 3rd party or not (hence all binaries are disallowed in source packages since there is no way to tell). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Distributing Executables.
On 18/05/2012 16:11, Daniel Fuka wrote: Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, You may be confused, but the documentation does not conflict. > and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? Yes. Take a look at e.g. package Rserve (and there are others which do this via src/Makefile.win). The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: Note that by definition a binary is not portable: it is tied to one OS and perhaps one architecture on that OS. The following is about source packages. "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable. You need to discuss that with CRAN, not here. Thanks! Daniel Fuka __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] test suites for packages
svUnit - is Runit compatible and provides some IDE integration and report generation and easy syntax for defining tests. I find it works a treat, and fits very nicely with my R coding/packaging style (which also uses inlinedocs for easy package creation). --Malcolm Cook On 5/17/12 9:10 AM, "Whit Armstrong" wrote: >Can anyone share some opinions on test suites for R packages? > >I'm looking at testthat and RUnit. Does anyone have strong opinions on >either of those. > >Any additional packages I should consider? > >Thanks, >Whit > >__ >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] Distributing Executables.
Thanks Simon,
In this case, I am talking specifically about allowing CRAN to compile
source into an executable to be distributed, as discussed in the
second paragraphs "very special cases .. for example executable
programs". So, when someone runs install.packages("mypackage"), they
get a package that contains an executable that can be run from outside
of R.
Can I submit a package to CRAN that will compile source into an executable?
I hope this clears the mud on my first post.
Thanks!
dan
On Fri, May 18, 2012 at 11:24 AM, Simon Urbanek
wrote:
>
> On May 18, 2012, at 11:11 AM, Daniel Fuka wrote:
>
>> Sorry for this intrusion, but I am confused by two statements that
>> appear to conflict at some level in Writing R Extensions, and wanted
>> to make sure I understand the answer to:
>> Can we distribute a portable executable compiled from source by CRAN in CRAN?
>>
>> The following section of Writing R Extensions appears to not be
>> addressing this issue, as in this case we are discussing portable CRAN
>> compiled binaries, and not binaries that are submitted to CRAN:
>> "A source package if possible should not contain binary executable
>> files: they are not portable, and a security risk if they are of the
>> appropriate architecture. R CMD check will warn about them unless they
>> are listed (one filepath per line) in a file BinaryFiles at the top
>> level of the package. Note that CRAN will no longer accept submissions
>> containing binary files even if they are listed."
>>
>> The following section seems to indicate special cases in which
>> packages can create binary files:
>> "In very special cases packages may create binary files other than the
>> shared objects/DLLs in the src directory. Such files will not be
>> installed in multi-arch setting since R CMD INSTALL --libs-only is
>> used to merge multiple architectures and it only copies shared
>> objects/DLLs. If a package wants to install other binaries (for
>> example executable programs), it should to provide an R script
>> src/install.libs.R which will be run as part of the installation in
>> the src build directory instead of copying the shared objects/DLLs."
>>
>> Once again, sorry for my confusion on this point. I just have what I
>> might consider a special case where it would be very handy to
>> distribute a cran compiled executable.
>
> I don't quite follow - CARN obviously distributes binaries compiled by CRAN
> and those are called binary packages. Can you be more specific as of what you
> are asking about? The two paragraphs you are quoting are about entirely
> different things - the first states that you can't include binaries in
> *source* packages and the second describes how you can build executables
> beside dynamic objects in packages so that CRAN can include them in *binary*
> packages. It doesn't cover distribution.
>
> What you refer to are rules for *source* packages which can't distribute
> binaries, but you can always use a binary package (which contains binaries).
> Note that the issue in question is not who built the binary but whether it
> could have been injected by 3rd party or not (hence all binaries are
> disallowed in source packages since there is no way to tell).
>
> Cheers,
> Simon
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Distributing Executables.
On May 18, 2012, at 11:32 AM, Daniel Fuka wrote:
> Thanks Simon,
>
> In this case, I am talking specifically about allowing CRAN to compile
> source into an executable to be distributed, as discussed in the
> second paragraphs "very special cases .. for example executable
> programs". So, when someone runs install.packages("mypackage"), they
> get a package that contains an executable that can be run from outside
> of R.
>
> Can I submit a package to CRAN that will compile source into an executable?
>
Yes - that is what the second paragraph describes (and as Brian pointed out
there are examples on CRAN like Rserve).
Cheers,
Simon
> I hope this clears the mud on my first post.
>
> Thanks!
> dan
>
> On Fri, May 18, 2012 at 11:24 AM, Simon Urbanek
> wrote:
>>
>> On May 18, 2012, at 11:11 AM, Daniel Fuka wrote:
>>
>>> Sorry for this intrusion, but I am confused by two statements that
>>> appear to conflict at some level in Writing R Extensions, and wanted
>>> to make sure I understand the answer to:
>>> Can we distribute a portable executable compiled from source by CRAN in
>>> CRAN?
>>>
>>> The following section of Writing R Extensions appears to not be
>>> addressing this issue, as in this case we are discussing portable CRAN
>>> compiled binaries, and not binaries that are submitted to CRAN:
>>> "A source package if possible should not contain binary executable
>>> files: they are not portable, and a security risk if they are of the
>>> appropriate architecture. R CMD check will warn about them unless they
>>> are listed (one filepath per line) in a file BinaryFiles at the top
>>> level of the package. Note that CRAN will no longer accept submissions
>>> containing binary files even if they are listed."
>>>
>>> The following section seems to indicate special cases in which
>>> packages can create binary files:
>>> "In very special cases packages may create binary files other than the
>>> shared objects/DLLs in the src directory. Such files will not be
>>> installed in multi-arch setting since R CMD INSTALL --libs-only is
>>> used to merge multiple architectures and it only copies shared
>>> objects/DLLs. If a package wants to install other binaries (for
>>> example executable programs), it should to provide an R script
>>> src/install.libs.R which will be run as part of the installation in
>>> the src build directory instead of copying the shared objects/DLLs."
>>>
>>> Once again, sorry for my confusion on this point. I just have what I
>>> might consider a special case where it would be very handy to
>>> distribute a cran compiled executable.
>>
>> I don't quite follow - CARN obviously distributes binaries compiled by CRAN
>> and those are called binary packages. Can you be more specific as of what
>> you are asking about? The two paragraphs you are quoting are about entirely
>> different things - the first states that you can't include binaries in
>> *source* packages and the second describes how you can build executables
>> beside dynamic objects in packages so that CRAN can include them in *binary*
>> packages. It doesn't cover distribution.
>>
>> What you refer to are rules for *source* packages which can't distribute
>> binaries, but you can always use a binary package (which contains binaries).
>> Note that the issue in question is not who built the binary but whether it
>> could have been injected by 3rd party or not (hence all binaries are
>> disallowed in source packages since there is no way to tell).
>>
>> Cheers,
>> Simon
>>
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in R version 2.15.0 (2012-03-30)?
The returned text by license() says,
This can be displayed by RShowDoc("COPYING.LIB"),
or obtained at the URI given.
However,
> RShowDoc("COPYING.LIB")
Error in RShowDoc("COPYING.LIB") : document not found
Also, is URI a typo of URL?
--
Wincent Ronggui HUANG
Sociology Department of Fudan University
PhD of City University of Hong Kong
http://homepage.fudan.edu.cn/rghuang/cv/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
