[Rd] Problems in building a DLL in 64-bit Windows
I am trying to build a C language DLL and it works well with i386 but when I
compile with it substituted
by x64, like the FAQ page says, the result is an error message:
C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File format not
recognized
collect2: ld returned 1 exit status
How can I solve this? The problem is with R 2-14.0 and 2-13.0
The complete source code is
/*
* myfun.c
*/
#include
#include
#include
#include
void myfn(double *x){ *x += 1; }
The DLL is build like this:
R CMD SHLIB -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -lR myfun.c -o myfun64.dll
and get the error message above.
The R code:
#
# myfun.R: this works with i386, but not with x64
#
dyn.load("myfun64.dll")
f <- function(x) {.C("myfn", x=as.double(x))$x}
f(1)
f(1000)
dyn.unload("dllmain.dll")
I am trying to build a package, or at least a set of functions, and performance
is sometimes a problem.
Thank you,
Rui Barradas
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems in building a DLL in 64-bit Windows
What is R.ddl? Or is that not the actual output?
In any case, it isn't going to work unless you run 64-bit 'R', and
my guess is that you used 32-bit 'R' to do this. Make sure you use
/bin/x64/R CMD
and you do not need the -L
On Mon, 12 Dec 2011, ruipbarra...@sapo.pt wrote:
I am trying to build a C language DLL and it works well with i386 but when I
compile with it substituted
by x64, like the FAQ page says, the result is an error message:
which 'FAQ page' (which FAQ, which page ...)?
C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File format not
recognized
collect2: ld returned 1 exit status
How can I solve this? The problem is with R 2-14.0 and 2-13.0
The complete source code is
/*
* myfun.c
*/
#include
#include
#include
#include
void myfn(double *x){ *x += 1; }
The DLL is build like this:
R CMD SHLIB -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -lR myfun.c -o myfun64.dll
and get the error message above.
The R code:
#
# myfun.R: this works with i386, but not with x64
#
dyn.load("myfun64.dll")
f <- function(x) {.C("myfn", x=as.double(x))$x}
f(1)
f(1000)
dyn.unload("dllmain.dll")
I am trying to build a package, or at least a set of functions, and performance
is sometimes a problem.
Thank you,
Rui Barradas
[[alternative HTML version deleted]]
__
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
[Rd] Proper use of suppressPackageStartupMessages in package building
All, When building a package, how can I suppress startup messages of package imports? I know you can use suppressPackageStartupMessages() around library or require when loading a package, but can I set in NAMESPACE or DESCRIPTION (or elsewhere?) to suppress any startup messages from imported packages? Best, Scott Chamberlain [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] clusterSetRNGStream() question
In a vanilla R 2.14.0 GUI session (on Windows XP SP3):
> library(parallel)
> cl<-makePSOCKcluster(2)
> RNGkind()
[1] "Mersenne-Twister" "Inversion"
> clusterSetRNGStream(cl)
> RNGkind()
[1] "L'Ecuyer-CMRG" "Inversion"
> stopCluster(cl)
Is it intentional that clusterSetRNGStream() changes the RNG kind in
the master process? The code of clusterSetRNGStream() suggests that
it is not: the old random number seed is saved in 'oldseed' and then
assigned to '.Random.seed':
.Random.seed <- oldseed
(https://svn.r-project.org/R/trunk/src/library/parallel/R/RngStream.R,
line 45). However, if the intent is to restore the old seed then
this assignment should be made in the global environment, e.g. via
assign(".Random.seed", oldseed, envir = .GlobalEnv)
J. R. M. Hosking
> sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems in building a DLL in 64-bit Windows
On 12.12.2011 14:12, ruipbarra...@sapo.pt wrote:
I am trying to build a C language DLL and it works well with i386 but when I
compile with it substituted
by x64, like the FAQ page says, the result is an error message:
C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl:
What is R.ddl? Do you mean R.dll?
If this is a typo: Is your OS 64 bit? Have you used the right compiler
collection for making 64-bit code according to the manual?
Best,
Uwe Ligges
file not recognized : File format not recognized
collect2: ld returned 1 exit status
How can I solve this? The problem is with R 2-14.0 and 2-13.0
The complete source code is
/*
* myfun.c
*/
#include
#include
#include
#include
void myfn(double *x){ *x += 1; }
The DLL is build like this:
R CMD SHLIB -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -lR myfun.c -o myfun64.dll
and get the error message above.
The R code:
#
# myfun.R: this works with i386, but not with x64
#
dyn.load("myfun64.dll")
f<- function(x) {.C("myfn", x=as.double(x))$x}
f(1)
f(1000)
dyn.unload("dllmain.dll")
I am trying to build a package, or at least a set of functions, and performance
is sometimes a problem.
Thank you,
Rui Barradas
[[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] Problems in building a DLL in 64-bit Windows
Prof. Ripley,
Thank you for your suggestion.
In the mean time, I had just found a solution and was going to send a
mail saying that the problem was solved
when I read your answer, and others.
The 'ddl' is obviously not the actual output, DOS doesn't allow copy&paste.
The solution is to use the compiler directly,
gcc -c myfun.c -o myfun.o
gcc -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -shared myfun -o myfun64.dll
Note that I didn't write '-lR' and it worked. In fact, when I've tryied
to, it gave an error again, it doesn't recognize .../bin/x64/R.dll
(-L is overriden by R CMD SHLIB, it puts i386 in the end...)
Once again, thank you for your suggestion, I'll give it a try.
Rui Barradas
Citando Prof Brian Ripley :
What is R.ddl? Or is that not the actual output?
In any case, it isn't going to work unless you run 64-bit 'R', and
my guess is that you used 32-bit 'R' to do this. Make sure you use
/bin/x64/R CMD
and you do not need the -L
On Mon, 12 Dec 2011, ruipbarra...@sapo.pt wrote:
I am trying to build a C language DLL and it works well with i386
but when I compile with it substituted
by x64, like the FAQ page says, the result is an error message:
which 'FAQ page' (which FAQ, which page ...)?
C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File
format not recognized
collect2: ld returned 1 exit status
How can I solve this? The problem is with R 2-14.0 and 2-13.0
The complete source code is
/*
* myfun.c
*/
#include
#include
#include
#include
void myfn(double *x){ *x += 1; }
The DLL is build like this:
R CMD SHLIB -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -lR myfun.c -o myfun64.dll
and get the error message above.
The R code:
#
# myfun.R: this works with i386, but not with x64
#
dyn.load("myfun64.dll")
f <- function(x) {.C("myfn", x=as.double(x))$x}
f(1)
f(1000)
dyn.unload("dllmain.dll")
I am trying to build a package, or at least a set of functions, and
performance is sometimes a problem.
Thank you,
Rui Barradas
[[alternative HTML version deleted]]
__
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] Problems in building a DLL in 64-bit Windows
On 12.12.2011 21:12, ruipbarra...@sapo.pt wrote:
Prof. Ripley,
Thank you for your suggestion.
In the mean time, I had just found a solution and was going to send a
mail saying that the problem was solved
when I read your answer, and others.
The 'ddl' is obviously not the actual output, DOS
DOS is not supported by R. I believe you are talking about the Windows
command shell (and that allows copy and paste!).
> doesn't allow copy&paste.
The solution is to use the compiler directly,
gcc -c myfun.c -o myfun.o
gcc -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -shared myfun -o myfun64.dll
If you type gcc and do not need to change the name, you pretty likely
use a 32-bit compiler. At least not a 32-bit one from the Rtools.
Note that I didn't write '-lR' and it worked. In fact, when I've tryied
to, it gave an error again, it doesn't recognize .../bin/x64/R.dll
Sure, since a 32-bit compiler does not know about 64-bit binaries.
Uwe Ligges
(-L is overriden by R CMD SHLIB, it puts i386 in the end...)
Once again, thank you for your suggestion, I'll give it a try.
Rui Barradas
Citando Prof Brian Ripley :
What is R.ddl? Or is that not the actual output?
In any case, it isn't going to work unless you run 64-bit 'R', and my
guess is that you used 32-bit 'R' to do this. Make sure you use
/bin/x64/R CMD
and you do not need the -L
On Mon, 12 Dec 2011, ruipbarra...@sapo.pt wrote:
I am trying to build a C language DLL and it works well with i386 but
when I compile with it substituted
by x64, like the FAQ page says, the result is an error message:
which 'FAQ page' (which FAQ, which page ...)?
C:/PROGRA~1/R/R-214~1.0/bin/x64/R.ddl: file not recognized : File
format not recognized
collect2: ld returned 1 exit status
How can I solve this? The problem is with R 2-14.0 and 2-13.0
The complete source code is
/*
* myfun.c
*/
#include
#include
#include
#include
void myfn(double *x){ *x += 1; }
The DLL is build like this:
R CMD SHLIB -LC:/PROGRA~1/R/R-214~1.0/bin/x64 -lR myfun.c -o myfun64.dll
and get the error message above.
The R code:
#
# myfun.R: this works with i386, but not with x64
#
dyn.load("myfun64.dll")
f <- function(x) {.C("myfn", x=as.double(x))$x}
f(1)
f(1000)
dyn.unload("dllmain.dll")
I am trying to build a package, or at least a set of functions, and
performance is sometimes a problem.
Thank you,
Rui Barradas
[[alternative HTML version deleted]]
__
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, UK Fax: +44 1865 272595
__
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
[Rd] Detecting typo in function argument
With some chagrin after spending a couple of hours trying to debug a script, I
realized I
had typed in something like
ans<-optimx(start, myfn, mygr, lower<-lo, upper=up)
that is, the "<-" rather than "=". The outcome on my machine was a non-obvious
error
several layers deep in the call stack. For info, optim() seems to stop much
more quickly.
The error is "obvious", but I'm wondering if there is a simple way to trap or
warn of it.
For completeness, I include the commands I used to force the error. Note that
it will only
work fully with the latest (R-forge) version of optimx/optfntools because of
the form of
gr="gfwd" that allows a choice of different numerical gradient routines.
This is a curiosity rather than a necessity, but if there is a simple way to
check, I'll
put it in my codes.
Cheers,
JN
rm(list=ls())
start<-rep(3,6)
lo<-rep(2,6)
up<-rep(4,6)
flb <- function(x)
{ p <- length(x); sum(c(1, rep(4, p-1)) * (x - c(1, x[-p])^2)^2) }
ans<-optim(start, flb, lower=lo, upper=up)
ans
ans<-optim(start, flb, lower<-lo, upper=up)
ans
ans1<-optim(start, flb, lower<-lo, upper=up)
ans1
require(optimx)
ans1x<-optimx(start, flb, lower<-lo, upper=up)
ans1x<-optimx(start, flb, gr="gfwd",lower<-lo, upper=up)
ans1<-optim(start, flb, gr=NULL,lower<-lo, upper=up)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Detecting typo in function argument
This is valid syntax, so what should we check for?.
Uwe
On 12.12.2011 22:10, John C Nash wrote:
With some chagrin after spending a couple of hours trying to debug a script, I
realized I
had typed in something like
ans<-optimx(start, myfn, mygr, lower<-lo, upper=up)
that is, the "<-" rather than "=". The outcome on my machine was a non-obvious
error
several layers deep in the call stack. For info, optim() seems to stop much
more quickly.
The error is "obvious", but I'm wondering if there is a simple way to trap or
warn of it.
For completeness, I include the commands I used to force the error. Note that
it will only
work fully with the latest (R-forge) version of optimx/optfntools because of
the form of
gr="gfwd" that allows a choice of different numerical gradient routines.
This is a curiosity rather than a necessity, but if there is a simple way to
check, I'll
put it in my codes.
Cheers,
JN
rm(list=ls())
start<-rep(3,6)
lo<-rep(2,6)
up<-rep(4,6)
flb<- function(x)
{ p<- length(x); sum(c(1, rep(4, p-1)) * (x - c(1, x[-p])^2)^2) }
ans<-optim(start, flb, lower=lo, upper=up)
ans
ans<-optim(start, flb, lower<-lo, upper=up)
ans
ans1<-optim(start, flb, lower<-lo, upper=up)
ans1
require(optimx)
ans1x<-optimx(start, flb, lower<-lo, upper=up)
ans1x<-optimx(start, flb, gr="gfwd",lower<-lo, upper=up)
ans1<-optim(start, flb, gr=NULL,lower<-lo, upper=up)
__
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
