Re: [Rd] Philosophy behind converting Fortran to C for use in R
Hi, Just a quick comment on (1). The C-Fortran interface has been standardized since Fortran 2003. However, it does require the Fortran interface that is being called from C to have been written with C operability in mind as specific C interoperable types etc. must be used. Trying to call a Fortran interface that hasn't been written using C interoperable types still suffers from the issues that Bill describes. Martyn -Original Message- From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of William Dunlap via R-devel Sent: 06 June 2017 22:34 To: Avraham Adler Cc: R-devel Subject: Re: [Rd] Philosophy behind converting Fortran to C for use in R Here are three reasons for converting Fortran code, especially older Fortran code, to C: 1. The C-Fortran interface is not standardized. Various Fortran compilers pass logical and character arguments in various ways. Various Fortran compilers mangle function and common block names in variousl ways. You can avoid that problem by restricting R to using a certain Fortran compiler, but that can make porting R to a new platform difficult. 2. By default, variables in Fortran routines are not allocated on the stack, but are statically allocated, making recursion hard. 3. New CS graduates tend not to know Fortran. (There are good reasons for not translating as well, risk and time being the main ones.) Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Jun 6, 2017 at 1:27 PM, Avraham Adler wrote: > Hello. > > This is not a question about a bug or even best practices; rather I'm > trying to understand the philosophy or theory as to why certain > portions of the R codebase are written as they are. If this question > is better posed elsewhere, please point me in the proper direction. > > In the thread about the issues with the Tukey line, Martin said [1]: > > > when this topic came up last (for me) in Dec. 2014, I did spend about 2 > days work (or more?) > > to get the FORTRAN code from the 1981 - book (which is abbreviated the > "ABC of EDA") > > from a somewhat useful OCR scan into compilable Fortran code and then > f2c'ed, > > wrote an R interface function found problems… > > I have seen this in the R source code and elsewhere, that native > Fortran is converted to C via f2c and then run as C within R. This is > notwithstanding R's ability to use Fortran, either directly through > .Fortran() [2] or via .Call() using simple helper C-wrappers [3]. > > I'm curious as to the reason. Is it because much of the code was > written before Fortran 90 compilers were freely available? Does it > help with maintenance or make debugging easier? Is it faster or more > likely to compile cleanly? > > Thank you, > > Avi > > [1] https://stat.ethz.ch/pipermail/r-devel/2017-May/074363.html > [2] Such as kmeans does for the Hartigan-Wong method in the stats package > [2] Such as the mvtnorm package does > > __ > 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 This e-mail has been scanned for all viruses by Star. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ALLOCATE in a FORTRAN subroutine
Hi,
"we can, once we know how to do it, 'drive' R from within FORTRAN"
I am not sure I understand what you mean by this ...
You can call routines written in Fortran or C from within R - how easy this is
depends on the interfaces to those routines.
You can call (some) R functionality from C (see for example
http://quantitative-ecology.blogspot.co.uk/2008/11/call-c-from-r-and-r-from-c.html).
As you can call C from within Fortran, it is obviously possible also call R
from within Fortran, but it is not something I have done so have no idea how
much work is required to do that.
"for what I have understood in r_exts, it's more 'efficient' to translate R
routines in C rather than in FORTRAN"
As far as I aware the R API for writing extensions etc is only available in C
and there isn't a Fortran equivalent, so I guess it would be more "efficient" /
easier in that sense as that would be one less level of cross-language
programming you would have to worry about.
"I do not know why my customer (client ?) wanted to translate some R routines
in FORTRAN."
Which language is preferred really boils down to personal preference and I am
going to be slightly biased as I do almost all my numerical computing in
Fortran. There is a good argument that Fortran is the most natural fit for
numerical computing with its built in syntax to deal with complex numbers,
matrices, array slicing, array operations etc. In theory this gives compilers
a good base to optimise from. The more restrictive nature of Fortran does make
it more difficult to interface with other languages than C (but conversely
makes it much more difficult to shoot yourself in the foot - and the Fortran
compilers tend to pick up more problems at compile time than the C ones).
Martyn
-Original Message-
From: MAURICE Jean - externe [mailto:jean-externe.maur...@edf.fr]
Sent: 07 March 2016 15:46
To: Martyn Byng
Cc: r-devel@r-project.org
Subject: RE: ALLOCATE in a FORTRAN subroutine
Hi Martyn,
Many thanks for your answer. If I make it short :
we can, once we know how to do it, 'drive' R from within FORTRAN for example to
do a
Myarray = seq(0, mydimension)
in R once we have compute mydimension in FORTRAN. Is that correct ?
If yes : it's too 'complicated' for the time I am hired (I mean I have been
hired to do FORTRAN code not to learn R !).
Second question : for what I have understood in r_exts, it's more 'efficient'
to translate R routines in C rather than in FORTRAN (speed must be the 'same',
but there are a lot more possibilities in C for the programmer) : right ? I do
not know why my customer (client ?) wanted to translate some R routines in
FORTRAN. May be it's by accident (in my humble opinion they even don't know
about C). If you confirm this fact, I'll speak about C with my customer because
we are at the very beginning of great works (great amounts of work ?) and I
don't matter, I am also a skilled C programmer !!
I hope you understand what I want to say, english is not my natural language !
Thanks again and best regards.
Jean
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:16}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ALLOCATE in a FORTRAN subroutine
Hi,
Until you get a more definitive answer, I will make an attempt to give some
advice.
When using an assumed sized array (i.e. REAL*8 array1(*)) you still need to
allocate the memory prior to calling the Fortran subroutine, so you would still
need to know its maximum length.
Arrays created in a Fortran subroutine via the use of the ALLOCATE statements
are not simple arrays (in the sense of C like pointers), but are more akin to a
C structure, in that they also contain information concerning the size of the
array, stride etc. These structures are compiler dependent, their contents
often not clearly documented and subject to change. They are therefore not very
good for cross-language computing (or even cross-compiler computing).
To try and alleviate this the Fortran standard introduced C interoperability
(see https://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html for
example) and I expect you are going to have to take a look at this in order to
pass memory allocated in your Fortran program back up to R. Care is going to
have be taken to make sure that the memory is deallocated when it has been
finished with (which is probably going to have to be done in Fortran).
The easiest way of getting all this to interact nicely with R is probably
through the R C API which is described in documents like
https://cran.r-project.org/doc/manuals/R-exts.pdf.
Martyn
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of MAURICE Jean
- externe
Sent: 04 March 2016 08:34
To: r-devel@r-project.org
Subject: [Rd] ALLOCATE in a FORTRAN subroutine
Hi,
I am a FORTRAN developer and I am 'translating' R functions in FORTRAN
subroutines. I am 'new' to R. It's my first question in this mailing-list and
English is not my natural language.
Very often, an R function gives an 'array' as result and you don't have to
bother with the dimension of the array : R creates automatically an array with
the good length. It's not really the case with FORTRAN. I call FORTRAN
subroutines with .fortran().
Until now, I create an array with the 'max' dimensions in R, give it to
FORTRAN; FORTRAN updates the array and R retrieves it. But calculating the
'max' before calling the FORTRAN subroutine can be complicated. Is it possible
to create a 'new' array in a FORTRAN subroutine and to make it be read by R ?
Or is it possible to have a 'pointer' in R, to give it to the FORTRAN
subroutine where an ALLOCATE can create the array and then R works with the
array ?
The other solution, is to work with dummies dimension in FORTRAN (REAL*8
array1(*)) but can R work with that ?
TIA
Jean
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:16}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in simulation. NAN
Hi,
You are going to have to track down exactly where the NaN is being
produced. These usually occur due to performing invalid numerical
operations, like trying to take the square-root of a negative number,
trying to calculate 0/0 etc.
Try adding a series of if / then blocks prior to performing any
operation that could result in a NaN, so something like:
if (app1_4 <= 0.0) {
error("app1_4 is -ve");
} else {
alpha_acc_P[0] = rnorm(app1_3,sqrt(app1_4) );
}
this should then give you a better idea of what is going wrong.
Martyn
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of
gianluca.mastranto...@yahoo.it
Sent: 27 August 2013 13:15
To: r-devel@r-project.org
Subject: [Rd] Error in simulation. NAN
Hi all,
im triyng to implement a bayesian model with R and c++.
I have a strange problem. I can't reproduce the error with a small
script and then i post the original one.
The problem is after the line
for(MCMC_iter2=0;MCMC_iter2
#include
using namespace std;
#include
#include
#include
#include
#include
#include "funzioni.h"
#define _USE_MATH_DEFINES
extern "C" {
SEXP Model1_imp11Cpp(
SEXP ad_start_r, SEXP ad_end_r, SEXP ad_esp_r,
SEXP burnin_r, SEXP thin_r,SEXP iter_1_r,SEXP iter_2_r,
SEXP n_j_r,SEXP J_r,
SEXP prior_alpha_r,SEXP prior_rho_r,SEXP prior_sigma2_r,SEXP
prior_phi_r,SEXP prior_zeta2_r,
SEXP sdprop_rho_r,SEXP sdprop_sigma2_r,
SEXP start_alpha_r,SEXP start_mu_r,SEXP start_rho_r,SEXP
start_sigma2_r,SEXP start_k_r,SEXP start_phi_r, SEXP start_zeta2_r,
SEXP x_r,SEXP H_r, SEXP acceptratio_r
// SEXP Sigma_adapt_sp_r, SEXP mean_adapt_sp_r, SEXP sim_acc_sp_r,
SEXP ep_sp_r, SEXP acc_index_sp_r,
// SEXP Sigma_adapt_k_r, SEXP mean_adapt_k_r, SEXP sim_acc_k_r, SEXP
ep_k_r, SEXP acc_index_k_r
//
){
/*
Varie ed eventuali
*/
// indici
int i,j,k,l,h,t,f,info,MCMC_iter,MCMC_iter2;
int nProtect= 0;
int indice_adapt=0;
double duepi = (2*M_PI);
// costanti
char const *lower = "L";
char const *upper = "U";
char const *ntran = "N";
char const *ytran = "T";
char const *rside = "R";
char const *lside = "L";
const double one = 1.0;
const double negOne = -1.0;
const double zero = 0.0;
const int incOne = 1;
/*
Set-up
*/
double *x_P = REAL(x_r);
int n_j = INTEGER(n_j_r)[0];
int J= INTEGER(J_r)[0];
int N = n_j*J;
int iter_1 = INTEGER(iter_1_r)[0];
int iter_2 = INTEGER(iter_2_r)[0];
int burnin = INTEGER(burnin_r)[0];
int thin = INTEGER(thin_r)[0];
int ad_start = INTEGER(ad_start_r)[0];
int ad_end = INTEGER(ad_end_r)[0];
double *ad_esp_P = REAL(ad_esp_r);
double *acceptratio_P = REAL(acceptratio_r);
double *H_P = REAL(H_r);
// int nSamples_save = INTEGER(nSamples_save_r)[0];
// PRIOR
double *prior_alpha = REAL(prior_alpha_r);
double M_alpha = prior_alpha[0]; double sigma2_alpha =
prior_alpha[1];
double *prior_rho = REAL(prior_rho_r);
double a_rho = prior_rho[0];double b_rho = prior_rho[1];
double *prior_sigma2 = REAL(prior_sigma2_r);
double a_sigma2 = prior_sigma2[0]; double b_sigma2 =
prior_sigma2[1];
double *prior_zeta2 = REAL(prior_zeta2_r);
double a_zeta2 = prior_zeta2[0]; double b_zeta2 = prior_zeta2[1];
double *prior_phi = REAL(prior_phi_r);
double M_phi= prior_phi[0]; double sigma2_phi = prior_phi[1];
double lim_down= prior_phi[2]; double lim_up = prior_phi[3];
// PROPOSAL
double *sdprop_rho = REAL(sdprop_rho_r);
double sd_rho = sdprop_rho[0];
double *sdprop_sigma2 = REAL(sdprop_sigma2_r);
double sd_sigma2 = sdprop_sigma2[0];
// STARTING
double *start_alpha_P = REAL(start_alpha_r);
double start_alpha = start_alpha_P[0];
double *start_mu_P = REAL(start_mu_r);
// for(j=0;jhttps://stat.ethz.ch/mailman/listinfo/r-devel
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a^b when a is large and b < 1 (64bit R on windows 7)
Hi,
The problem here appears to be due to
29: #define MAXNUM 1.7976931348623158E308
(from
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/cephe
s_mconf.h?annotate=1.5&cvsroot=src)
and
468: if( x >= MAXNUM )
469:{
470: #if INFINITIES
471:if( y > 0.0 )
472:return( INFINITY );
(from
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/pow.c
?annotate=1.1.10.1&cvsroot=src)
And so on 64bit Windows R build
.Machine$double.xmax = MAXMUM from above.
This is kind of confirmed as
(.Machine$double.xmax*(1 - .Machine$double.eps))^0.5
works as expected
Martyn
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Bryan W. Lewis
Sent: 21 November 2011 23:47
To: Joris Meys
Cc: r-devel@r-project.org
Subject: Re: [Rd] a^b when a is large and b < 1 (64bit R on windows 7)
Although it does not solve the issue, the INF result is due to the
MinGW gcc math library on 64-bit Windows that R links to. One can
easily see this by compiling just machar.c and checking pow and sqrt
on xmax.
Note that on any platform the results are likely to be quite different
between pow and sqrt for edge case numerical examples.
For example, on a 32-bit Ubuntu box with R-2.14.0, I get:
x = .Machine$double.xmax
y = sqrt(x)
z = x^0.5
y-z
[1] 1.488566e+138
There is also a long discussion about this here:
http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-users&max_
rows=25&style=nested&viewmonth=201104
--Bryan
On Mon, Nov 21, 2011 at 10:03 AM, Joris Meys
wrote:
> Should have specified I only checked on Windows. So: On Windows 7
> 64bit, the R-32bit works fine, the R-64bit gives the behaviour Martyn
> reported.
>
> Cheers
> Joris
>
> On Mon, Nov 21, 2011 at 3:58 PM, Brian G. Peterson
wrote:
>> On Mon, 2011-11-21 at 14:41 +, Martyn Byng wrote:
>>> I'm getting some strange behaviour when trying to use the power
>>> operator
>>> (a^b) when a is large and b is less than one:
>>>
>>> big <- .Machine$double.xmax
>>> big
>>> big^0.5
>>> sqrt(big)
>>>
>>> > big <- 1.797693134862315708384e+308
>>> > big^0.5
>>> [1] Inf
>>> > sqrt(big)
>>> [1] 1.340781e+154
>>>
>>>
>>> I'm guessing that this behaviour is not expected, or am I missing
>>> something about ^?
>>
>> On a recent Ubuntu 64bit install with R2.14.0 from the repositories,
I
>> get:
>>
>>> big <- .Machine$double.xmax
>>> big
>> [1] 1.797693e+308
>>> big^0.5
>> [1] 1.340781e+154
>>> sqrt(big)
>> [1] 1.340781e+154
>>
>> so it does seem to be specific either to your environment.
>>
>> --
>> Brian G. Peterson
>> http://braverock.com/brian/
>> Ph: 773-459-4973
>> IM: bgpbraverock
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a^b when a is large and b < 1 (64bit R on windows 7)
Hi,
I'm getting some strange behaviour when trying to use the power operator
(a^b) when a is large and b is less than one:
big <- .Machine$double.xmax
big
big^0.5
sqrt(big)
> big <- 1.797693134862315708384e+308
> big^0.5
[1] Inf
> sqrt(big)
[1] 1.340781e+154
I'm guessing that this behaviour is not expected, or am I missing
something about ^?
Cheers
Martyn
> sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. Th...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
Hi,
Even using the same math libraries you can get different results,
depending on what sorts of instructions those libraries use, see the
following (none R related) blog article:
http://blog.nag.com/2011/02/wandering-precision.html.
Martyn
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
Sent: 20 July 2011 14:47
To: Jeroen Ooms
Cc: r-devel@r-project.org
Subject: Re: [Rd] Randomness not due to seed
I would guess the error below is because of Java messing around in the
hardware. It's pretty common on Windows for DLLs to attempt to change
the precision setting on the floating point processor; I hadn't seen
that before on Linux, but that would be my guess as to the cause.
It's also possible that one of the attached packages has messed with R
functions somehow, e.g. by replacing the default print() or show()
method.
A third possibility is that different math libraries are being used.
So I would consider the differences in the results to be a bit of a bug,
but not one that is likely under our control, and not one that is so
large that I would worry about working around it.
Duncan Murdoch
On 20/07/2011 8:03 AM, Jeroen Ooms wrote:
> >> I think Bill Dunlap's answer addressed it: the claim appears to
be false.
>
> Here is another example where there is randomness that is not due to
> the seed. On the same machine, the same R binary, but through another
> interface. First directly in the shell:
>
> > sessionInfo()
> R version 2.13.1 (2011-07-08)
> Platform: i686-pc-linux-gnu (32-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [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
>
> > set.seed(123)
> > print(coef(lm(dist~speed, data=cars)),digits=22)
>(Intercept) speed
> -17.579094890510951643137 3.932408759124087715975
>
>
>
> # And this is through eclipse (java)
>
> > sessionInfo()
> R version 2.13.1 (2011-07-08)
> Platform: i686-pc-linux-gnu (32-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8
> [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8
> [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] rj_0.5.2-1
>
> loaded via a namespace (and not attached):
> [1] rJava_0.9-1 tools_2.13.1
>
> > set.seed(123)
> > print(coef(lm(dist~speed, data=cars)),digits=22)
> (Intercept)speed
> -17.57909489051087703615 3.93240875912408460735
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling Rscript from Makevars
Hi,
Thanks for the help.
Putting the call to Rscript directly in the definition of PKG_LIBS
rather than in a different makefile variable and using that variable
when defining PKG_LIBS did indeed fix my problem.
Martyn
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: 20 May 2011 20:17
To: Martyn Byng
Cc: r-devel@r-project.org
Subject: Re: [Rd] Calling Rscript from Makevars
On May 20, 2011, at 12:04 PM, Martyn Byng wrote:
> Hi,
>
> I am trying to package some code to use with R and wanted to call
> Rscript from within the Makevars file (I am trying to automate the
> setting of the location of a third party library depending on what is
> available / the system the package is being installed on).
>
> If I just have a simple Makevars containing
>
>
> PKG_LIBS= -lnag_nag -L/fserver/nagprod/FL22/fll6a22df/lib
>
>
> the package is built without any errors, if I attempt to add a call to
> Rscript, for example (which I think is the way that "Writing R
> Extensions" recommends):
>
>
> R_SCRIPT_NAME=Rscript
> ifneq ($(R_HOME),)
> R_SCRIPT=$(R_HOME)/bin$(R_ARCH_BIN)/$(R_SCRIPT_NAME)
> else
> R_SCRIPT=$(R_SCRIPT_NAME)
> endif
> R_ARCH=$(shell $(R_SCRIPT) -e 'cat(R.version$$arch)')
>
That's all pretty much unnecessary since all settings carry over from
the R invocation and also it is what causes your error (since your
"arch" is wrong). On unix it's as simple as
PKG_LIBS=`${R_HOME}/bin/Rscript -e 'whatever.you.meant.to.run()'`
and on Windows it's
PKG_LIBS=`${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe -e
'whatever.you.meant.to.run()'`
Note that you should NOT mess with the environment variables that R uses
as you're likely to set them incorrectly.
Cheers,
Simon
> PKG_LIBS= -lnag_nag -L/fserver/nagprod/FL22/fll6a22df/lib
>
>
> I get the following error:
>
> * checking for file 'NAGFWrappers/DESCRIPTION' ... OK
> * preparing 'NAGFWrappers':
> * checking DESCRIPTION meta-information ... OK
> * cleaning src
> make: Nothing to be done for `clean'.
> * removing junk files
> * checking for LF line-endings in source and make files
> * checking for empty or unneeded directories
> * building binary distribution
> * installing *source* package 'NAGFWrappers' ...
> ** libs
> /usr/share/R/make/shlib.mk:3: /usr/lib64/R/etcx86_64/Makeconf: No such
> file or directory
> make: *** No rule to make target `/usr/lib64/R/etcx86_64/Makeconf'.
> Stop.
> ERROR: compilation failed for package 'NAGFWrappers'
> * removing '/tmp/Rinst1513764321/NAGFWrappers'
> ERROR
> * installation failed
>
>
> Any help / pointers would be appreciated.
>
> Cheers
>
> Martyn
>
> Output from R.version:
>
> platform x86_64-redhat-linux-gnu
> arch x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major 2
> minor 11.0
> year 2010
> month 04
> day22
> svn rev51801
> language R
> version.string R version 2.11.0 (2010-04-22)
>
>
>
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses by Star.
Th...{{dropped:4}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Calling Rscript from Makevars
Hi,
I am trying to package some code to use with R and wanted to call
Rscript from within the Makevars file (I am trying to automate the
setting of the location of a third party library depending on what is
available / the system the package is being installed on).
If I just have a simple Makevars containing
PKG_LIBS= -lnag_nag -L/fserver/nagprod/FL22/fll6a22df/lib
the package is built without any errors, if I attempt to add a call to
Rscript, for example (which I think is the way that "Writing R
Extensions" recommends):
R_SCRIPT_NAME=Rscript
ifneq ($(R_HOME),)
R_SCRIPT=$(R_HOME)/bin$(R_ARCH_BIN)/$(R_SCRIPT_NAME)
else
R_SCRIPT=$(R_SCRIPT_NAME)
endif
R_ARCH=$(shell $(R_SCRIPT) -e 'cat(R.version$$arch)')
PKG_LIBS= -lnag_nag -L/fserver/nagprod/FL22/fll6a22df/lib
I get the following error:
* checking for file 'NAGFWrappers/DESCRIPTION' ... OK
* preparing 'NAGFWrappers':
* checking DESCRIPTION meta-information ... OK
* cleaning src
make: Nothing to be done for `clean'.
* removing junk files
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building binary distribution
* installing *source* package 'NAGFWrappers' ...
** libs
/usr/share/R/make/shlib.mk:3: /usr/lib64/R/etcx86_64/Makeconf: No such
file or directory
make: *** No rule to make target `/usr/lib64/R/etcx86_64/Makeconf'.
Stop.
ERROR: compilation failed for package 'NAGFWrappers'
* removing '/tmp/Rinst1513764321/NAGFWrappers'
ERROR
* installation failed
Any help / pointers would be appreciated.
Cheers
Martyn
Output from R.version:
platform x86_64-redhat-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 11.0
year 2010
month 04
day22
svn rev51801
language R
version.string R version 2.11.0 (2010-04-22)
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. Th...{{dropped:4}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
