[Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
Dear all,
I was trying to use the R swig wrapper with R 2.7 and shogun
( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't
even compile and even after patching then though compiling - crashes...
So I asked on swig-users/swig-devel CC'ing the potential R maintainer
but I never received a reply. I now wonder if anyone here could help or
would be willing to maintain R+swig.
The compile fix for R 2.7 is here
http://article.gmane.org/gmane.comp.programming.swig/12697
and the crash I am now that it compiles see is
#0 0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2
#1 0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2
#2 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
#3 0xb8050f5e in _dl_open () from /lib/ld-linux.so.2
#4 0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2
#5 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
#6 0xb74c42bc in _dlerror_run () from /lib/i686/cmov/libdl.so.2
#7 0xb74c3b51 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2
#8 0xb7efd036 in loadLibrary (path=0xbfa5650c
"/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
asLocal=1, now=1, search=0x9a81f20 "") at dynload.c:92
#9 0xb7d6efb3 in AddDLL (path=0xbfa5650c
"/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
asLocal=1, now=1, DLLsearchpath=0x9a81f20 "") at Rdynload.c:543
#10 0xb7d6f657 in do_dynload (call=0x9e23998, op=0x9a91e44, args=0xa60d5e0,
env=0xa60d650) at Rdynload.c:904
#11 0xb7e43dba in do_internal (call=0x9e239d0, op=0x9a8798c, args=0xa60d5e0,
env=0xa60d650) at names.c:1129
#12 0xb7e0df21 in Rf_eval (e=0x9e239d0, rho=0xa60d650) at eval.c:463
#13 0xb7e11a3c in Rf_applyClosure (call=0xa60d74c, op=0x9e23a94,
arglist=0xa60d6dc, rho=0x9a9a720, suppliedenv=0x9a9a73c) at eval.c:669
#14 0xb7e0de19 in Rf_eval (e=0xa60d74c, rho=0x9a9a720) at eval.c:507
#15 0xb7e31a00 in Rf_ReplIteration (rho=0x9a9a720, savestack=0, browselevel=0,
state=0xbfa589a8) at main.c:257
#16 0xb7e31ddc in run_Rmainloop () at main.c:306
#17 0xb7e31e1c in Rf_mainloop () at main.c:974
#18 0x08048776 in main (ac=1, av=0xb805b668) at Rmain.c:35
#19 0xb7be8450 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#20 0x08048691 in _start ()
To reproduce
wget http://nn7.de/debugging/shogun-0.6.1+svn2882.tar.bz2
tar xjf shogun-0.6.1+svn2882.tar.bz2
cd shogun-0.6.1+svn2882/src
./configure --interface=R-modular
make
(wait a few minutes)
R
dyn.load('features/Features.so')
#source("features/Features.R") # not even necessary.
Note that shogun works for both python and octave nicely...
So the question for me is, will this be better maintained in the future
or should I stop investing time on getting R supported?
Desperate,
Soeren
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [rd] sage <--> r integration
> On Thu, 17 Apr 2008 09:05:56 -0700, > Rob Goedman (RG) wrote: > Mike, > I'm also surprised so few reactions have been forthcoming. I saw > William's email shortly after Jan's email about Sage. There is a priovate mailing list for all R Google SoC mentors and parts were discussed there. > Having been involved in the Ryacas project (R to Yacas - Yet Another > Computer Algebra System - with Gabor, Soren and Ayal), I believe in > the tremendous benefits of such an integration and have, over the > last couple of days, been studying Sage and its notebook interface to > better understand how it could be used as an alternative/complement to > the current Mac R.app (having occasionally helped out Simon on the Mac > R GUI - R.app). > I am a firm believer in Python, and have worked on Python/ > Django/"Python on Embedded systems for biometrics" for well over 2 > years now. I do believe this is also a major benefit of Sage. And > projects such as Google's App Engine provide further support. > From Willliam's email I take it the best route right now is to try to > bring this project the attention of the GSoC mentors. Sorry, it is not a problem of "not enough attention". The problem is, that the R Foundation was assigned four slots by Google, and we have much more projects than 4, and cannot even fund all projects by R core members. If things stay the way they are only two of the four will be mentored by members of the core team, so it's not like we take all slots for us. If we fund the R-Sage project, I have to take somebody else his slot away. The decision is not "do we fund R-Sage or not", but which 4 of the 20+ applications do we choose. The decisions which projects to fund were based on factors like: 1) Quality of the student application, i.e., how much work of the student went into preparing the application, did he read into code or textbooks that can help, how much email exchange with the prospective mentor etc (most important) 2) How important is the project for R? 3) How much did the mentor contribute to R in the past? Number 3) looks like we don't like outsiders, but that is not the point. If we want to participate again next year, our number of slots will also be based on how successfull we are this year. And for mentors we know well it is easier to guess if they can meet their goals than for people unknown to us. This is of particular importance for writing interfaces between systems, where knowledge of R internals can be crucial. It is not like that I do not think that the project can be done by the people proposing it, but there are no means for me to assess in the limited time we have whether they can do it or not. I would love to assign slots to every projects that looks good, but Google gave us only four, so somebody has to be disappointed. But allmost all of R got created without any external funding, so I don't see why this should be stop for the project. It won't be me doing it, but I would be very excited to see it happen! Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure can't find dgemm in MKL10
Hi, I'm trying to follow the R-admin instructions for using MKL10 as the external BLAS compiling R-2.6.2 under Linux on a RH EL head node of a cluster. The configure process seems to have problems when it checks for dgemm in the BLAS. I'm using configure as: ./configure CC=icc F77=ifort --with-lapack="$MKL" --with-blas="$MKL" where $MKL is defined as in R-admin section A.3.1.4. checking for cblas_cdotu_sub in vecLib framework... no checking for dgemm_ in-L/usr1/util/Intel/mkl/10.0.1.014/lib/em64t -Wl,--start-group /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gf_lp64.a /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gnu_thread.a /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_core.a -Wl,--end-group -liomp5 -lguide -lpthread -lgomp... no checking for dgemm_... no checking for ATL_xerbla in -latlas... yes checking for dgemm_ in -lf77blas... no checking for dgemm_ in -lblas... yes checking for dgemm_ in -ldgemm... no checking for dgemm_ in -lblas... (cached) yes checking for dgemm_ in -lessl... no checking for dgemm_ in -lblas... (cached) yes I've looked in the MKL .a files and do not actually see dgemm or dgemm_ explicitly. So this seemingly explains the result of configure which is that BLAS_LIBS is not set to point to MKL but defaults to pointing to the usual Rblas (based on BLAS_LIBS in Makeconf (BLAS_LIBS = -L$(R_HOME)/lib$(R_ARCH) -lRblas) and the absence of a mention of BLAS in the 'External libraries' line at the end of the configure process output. In looking for dgemm in the MKL .a files (ar t libName.a | grep dgemm), libmkl_gf_lp64.a lists cblas_dgemm_lp64.o,_dgemm_lp64.o libmkl_core.a lists a bunch of things with dgemm in the name but not dgemm itself, e.g., _dgemm_kernel_0_fb.o,_mc_dgemm_bufs_0.o libmkl_gnu_thread.a lists dgemm_omp.o Incidentally _dgemm.o is listed in libmkl_gf_ilp64.a. We're running Red Hat Enterprise Linux AS release 4 (Nahant Update 5) on an Intel Xeon head node of a cluster. Incidentally, this has come about because in playing with my new $1300 Macbook, I found it was doing basic matrix work (dense matrix multiplication, Cholesky) about 5x as fast as our Linux cluster. I haven't looked into it much, but given that CPU use is listed as nearing 200% on the dual core Mac, part of this may be due to the Mac taking advantage of both cores. My hope is that with a faster BLAS the difference between the Mac and our cluster for basic linear algebra will lessen or disappear. Any tips on what may be going wrong in the configure test process or how to get around this would be helpful. Thanks, Chris -- Chris Paciorek / Asst. ProfessorEmail: [EMAIL PROTECTED] Department of Biostatistics Voice: 617-432-4912 Harvard School of Public Health Fax: 617-432-5619 655 Huntington Av., Bldg. 2-407 WWW: www.biostat.harvard.edu/~paciorek Boston, MA 02115 USAPermanent forward: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure can't find dgemm in MKL10
Did you see See 'Shared BLAS' for an alternative (and in many ways preferable) way to use MKL. ? That's an easier route to get working, and you can swap BLASes almost instantly. But you need to look at the config.log to see what went wrong. 'Xeon' covers a multitude of processors, but my group's experience is that for recent Intel CPUs the Goto BLAS beats all others (including MKL and ATLAS). As you are in academia it is available to you, and it too is easy to swap in. On Fri, 18 Apr 2008, Christopher Paciorek wrote: > Hi, > I'm trying to follow the R-admin instructions for using MKL10 as the external > BLAS compiling R-2.6.2 under Linux on a RH EL head node of a cluster. The > configure process seems to have problems when it checks for dgemm in the > BLAS. I'm using configure as: > ./configure CC=icc F77=ifort --with-lapack="$MKL" --with-blas="$MKL" where > $MKL is defined as in R-admin section A.3.1.4. > > checking for cblas_cdotu_sub in vecLib framework... no > checking for dgemm_ in-L/usr1/util/Intel/mkl/10.0.1.014/lib/em64t >-Wl,--start-group > > /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gf_lp64.a > /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gnu_thread.a > /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_core.a >-Wl,--end-group > -liomp5 -lguide -lpthread -lgomp... no > checking for dgemm_... no > checking for ATL_xerbla in -latlas... yes > checking for dgemm_ in -lf77blas... no > checking for dgemm_ in -lblas... yes > checking for dgemm_ in -ldgemm... no > checking for dgemm_ in -lblas... (cached) yes > checking for dgemm_ in -lessl... no > checking for dgemm_ in -lblas... (cached) yes > > I've looked in the MKL .a files and do not actually see dgemm or dgemm_ > explicitly. So this seemingly explains the result of configure which is that > BLAS_LIBS is not set to point to MKL but defaults to pointing to the usual > Rblas (based on BLAS_LIBS in Makeconf (BLAS_LIBS = -L$(R_HOME)/lib$(R_ARCH) > -lRblas) and the absence of a mention of BLAS in the 'External libraries' > line at the end of the configure process output. > > In looking for dgemm in the MKL .a files (ar t libName.a | grep dgemm), > libmkl_gf_lp64.a lists cblas_dgemm_lp64.o,_dgemm_lp64.o > libmkl_core.a lists a bunch of things with dgemm in the name but not dgemm > itself, e.g., _dgemm_kernel_0_fb.o,_mc_dgemm_bufs_0.o > libmkl_gnu_thread.a lists dgemm_omp.o > > Incidentally _dgemm.o is listed in libmkl_gf_ilp64.a. > > We're running Red Hat Enterprise Linux AS release 4 (Nahant Update 5) on > an Intel Xeon head node of a cluster. > > Incidentally, this has come about because in playing with my new $1300 > Macbook, I found it was doing basic matrix work (dense matrix > multiplication, Cholesky) about 5x as fast as our Linux cluster. I > haven't looked into it much, but given that CPU use is listed as nearing > 200% on the dual core Mac, part of this may be due to the Mac taking > advantage of both cores. My hope is that with a faster BLAS the > difference between the Mac and our cluster for basic linear algebra will > lessen or disappear. > > Any tips on what may be going wrong in the configure test process or how > to get around this would be helpful. > > Thanks, > Chris > > -- > Chris Paciorek / Asst. ProfessorEmail: [EMAIL PROTECTED] > Department of Biostatistics Voice: 617-432-4912 > Harvard School of Public Health Fax: 617-432-5619 > 655 Huntington Av., Bldg. 2-407 WWW: www.biostat.harvard.edu/~paciorek > Boston, MA 02115 USAPermanent forward: [EMAIL PROTECTED] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] 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] R-extension in unix system -- help to locate header files
Thank you for your reply. I'm really new to this unix system and let me ask
one more
time to make sure if I understand it right.
So I do it this way?
1. Change my codes to like below:
#include
#include
#include
#include
#include
#include
2. and at the command line,
set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include $path)
set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include/R_ext $path)
Then what is about -I flags? I googled it but couldn't find anything. I
don't really
know what you meant by "The search paths supplemented by -I flags on
the command
line". How do I use it? Like this?
set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include $path) -I
Thank you so much.
Kyeongmi Cheon
University of memphis
You should never give full paths in #include statements.
The search paths for include ('header') files are set by the compiler and
supplemented by -I flags on the command line. If your C compiler is
unable to find something is badly wrong, and you need to ask
your 'unix' advisor for help. (BTW, these header files are OS-specific,
and some of them will be compiler-specific -- on my Solaris Unix box cc
and gcc use different versions of some of these headers.)
-
Kyeongmi,
University of Memphis
--
View this message in context:
http://www.nabble.com/R-extension-in-unix-systemhelp-to-locate-header-files-tp16760424p16763526.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] naive question regarding running parallel C code from R
Hi, I have only the vaguest notions of what parallel programing, but I think I have a situation where it might be of use to me, or at least provide me with the opportunity to learn more about it. Before I invest in figuring out the nuts and bolts, can anyone confirm that this is a sane approach, or provide alternatives that I could pursue? I'm running stochastic simulations, with the actual simulation in C code, with an R interface to set up the parameters, format the output, and save the resulting objects periodically through the run. The basic layout is: R function sets up the run R for(c = 0; c < CYCLES; c++) call C function C for(i = 0; i < TIME; i++) immigration loop adds individuals to the recruit vector birth loop adds individuals to the recruit vector recruit vector is added to the community vector death loop removes excess individuals Return results to R, which processes and saves the objects Repeat A typical run has 20 cycles, each with 500 time steps, and takes about an hour. The immigration and birth loops are independent of each other, and so could run simultaneously. They both add to the recruit vector, but the order of the addition doesn't matter so long as both finish before the recruit vector is added to the community vector. The immigration, birth, and death loop iterate over arrays in a way that the outcome at different locations is independent. i.e., the impact of the birth vector on recruit vector position 0 has no influence on what the birth vector does to recruit vector position 1. What I'm thinking of doing is running the birth and immigration loops as separate threads, and possibly running each of those threads as a group of threads - so a thread for a birth loop that iterates over the first N positions, another thread for the second N positions and so on. I'm keen to learn about parallel programming, but I don't understand enough yet to make sense of the information in the R extensions manual and the various discussions on this list about R being thread-safe. Does it matter if R is thread-safe if the actual simulation is being computed in separate, shared C code? I'm running my current, sequential code, on a cluster that supports both OpenMP and MPI, should I figure out how to use it. Thanks for your patience, Tyler -- Don't learn the tricks of the trade; learn the trade. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem customizing CXXFLAGS in Windows
Hi all, I am running R 2.6.2 in Windows XP with Rtools 2.7 and am trying to compile a shared library in Windows with customized level of optimization. Specifically, I would like to have "-O3 -funroll-loops" as flags when I run "R CMD SHLIB ***.cc" to speed the program for my simulations. I have read through the documentation and have tried adding the line PKG_CXXFLAGS = -O3 -funroll-loops in my Makevars in my package's src directory. However, this places the flags before the -O2 flag, thereby overriding it. I have also tried creating a config.site file in R_HOME/etc, but that seems to be ignored. I found a possible solution at http://tolstoy.newcastle.edu.au/R/e2/devel/07/03/2520.html. However, when I use this suggestion, I get errors that R.h cannot be found. Please note that I do not plan to submit this package to CRAN or to other users with the modified flags, but I just need to set them on my machine to speed up simulations for testing, etc. I appreciate any suggestions, Ian -- View this message in context: http://www.nabble.com/problem-customizing-CXXFLAGS-in-Windows-tp16763558p16763558.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-extension in unix system -- help to locate header files
On Apr 18, 2008, at 11:49 AM, Kyeongmi Cheon wrote: > Thank you for your reply. I'm really new to this unix system and let > me ask > one more > time to make sure if I understand it right. > > So I do it this way? > 1. Change my codes to like below: > #include > #include > #include > #include > #include > #include > > 2. and at the command line, > set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include $path) > set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include/R_ext > $path) > No. You're confusing PATH (I supposed) and compilation. > Then what is about -I flags? I googled it but couldn't find anything. I hope you didn't google for "-I" ;) Those flags (see man gcc for details) are added automatically when you compile code for R via R CMD SHLIB or R CMD INSTALL so you should not worry about it at all. Please read "Writing R Extensions" manual, but before you do that you should familiarize yourself with the basics of C and compilation in the first place. The process it the same on both Windows and unix, so you should be using R CMD INSTALL for your package as you did on Windows without any changes. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] naive question regarding running parallel C code from R
On Apr 18, 2008, at 12:03 PM, tyler wrote: > Hi, > > I have only the vaguest notions of what parallel programing, but I > think > I have a situation where it might be of use to me, or at least provide > me with the opportunity to learn more about it. Before I invest in > figuring out the nuts and bolts, can anyone confirm that this is a > sane > approach, or provide alternatives that I could pursue? > > I'm running stochastic simulations, with the actual simulation in C > code, with an R interface to set up the parameters, format the output, > and save the resulting objects periodically through the run. The basic > layout is: > > R function sets up the run > R for(c = 0; c < CYCLES; c++) > call C function > C for(i = 0; i < TIME; i++) >immigration loop adds individuals to the recruit vector >birth loop adds individuals to the recruit vector >recruit vector is added to the community vector >death loop removes excess individuals > Return results to R, which processes and saves the objects > Repeat > > A typical run has 20 cycles, each with 500 time steps, and takes about > an hour. The immigration and birth loops are independent of each > other, > and so could run simultaneously. They both add to the recruit vector, > but the order of the addition doesn't matter so long as both finish > before the recruit vector is added to the community vector. The > immigration, birth, and death loop iterate over arrays in a way that > the > outcome at different locations is independent. i.e., the impact of the > birth vector on recruit vector position 0 has no influence on what the > birth vector does to recruit vector position 1. > > What I'm thinking of doing is running the birth and immigration > loops as > separate threads, and possibly running each of those threads as a > group > of threads - so a thread for a birth loop that iterates over the > first N > positions, another thread for the second N positions and so on. > > I'm keen to learn about parallel programming, but I don't understand > enough yet to make sense of the information in the R extensions manual > and the various discussions on this list about R being thread-safe. > Does > it matter if R is thread-safe if the actual simulation is being > computed > in separate, shared C code? > As long as the code doesn't touch R during the time it's running threads, no (for all practical purposes). I.e. if you setup native structures to work on, you're free to spawn threads, wait for them to finish and then return to R. There are some issues that you could encounter: on some platforms you need special, reentrant versions of system libraries which you don't get with R; there could be issues with error handling and interrupts - you will be on your own. > I'm running my current, sequential code, on a cluster that supports > both OpenMP and MPI, should I figure out how to use it. > You can save yourself all the hassle and just use snow + Rmpi - that allows you to parallelize even R code, so you don' t need any of the above. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] naive question regarding running parallel C code from R
On 18 April 2008 at 13:03, tyler wrote: | Hi, | | I have only the vaguest notions of what parallel programing, but I think | I have a situation where it might be of use to me, or at least provide | me with the opportunity to learn more about it. Before I invest in | figuring out the nuts and bolts, can anyone confirm that this is a sane | approach, or provide alternatives that I could pursue? | | I'm running stochastic simulations, with the actual simulation in C | code, with an R interface to set up the parameters, format the output, | and save the resulting objects periodically through the run. The basic | layout is: | | R function sets up the run | R for(c = 0; c < CYCLES; c++) | call C function | C for(i = 0; i < TIME; i++) | immigration loop adds individuals to the recruit vector | birth loop adds individuals to the recruit vector | recruit vector is added to the community vector | death loop removes excess individuals | Return results to R, which processes and saves the objects | Repeat | | A typical run has 20 cycles, each with 500 time steps, and takes about | an hour. The immigration and birth loops are independent of each other, | and so could run simultaneously. They both add to the recruit vector, | but the order of the addition doesn't matter so long as both finish | before the recruit vector is added to the community vector. The | immigration, birth, and death loop iterate over arrays in a way that the | outcome at different locations is independent. i.e., the impact of the | birth vector on recruit vector position 0 has no influence on what the | birth vector does to recruit vector position 1. | | What I'm thinking of doing is running the birth and immigration loops as | separate threads, and possibly running each of those threads as a group | of threads - so a thread for a birth loop that iterates over the first N | positions, another thread for the second N positions and so on. | | I'm keen to learn about parallel programming, but I don't understand | enough yet to make sense of the information in the R extensions manual | and the various discussions on this list about R being thread-safe. Does | it matter if R is thread-safe if the actual simulation is being computed | in separate, shared C code? | | I'm running my current, sequential code, on a cluster that supports both | OpenMP and MPI, should I figure out how to use it. As I recall, you use Debian so do $ sudo apt-get install r-cran-snow r-cran-rmpi to get R support working out-of-the box. Then study the examples for Snow on Luke's website. [ I also have some slides on my website from presentations I gave a few years ago. ] That allows you to _easily_ do the so-called embarassingly parallel: same problem, different parameters. Or, you could also loop over CYCLES across the cluster. Start with something simple to study it and then go from there. Hope this helps, Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-extension in unix system -- help to locate header files
I suggested you ask your 'unix' advisor for help. This is *way* off topic
for an R forum.
On Fri, 18 Apr 2008, Kyeongmi Cheon wrote:
>
>
> Thank you for your reply. I'm really new to this unix system and let me ask
> one more
> time to make sure if I understand it right.
>
> So I do it this way?
> 1. Change my codes to like below:
> #include
> #include
> #include
> #include
> #include
> #include
>
> 2. and at the command line,
> set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include $path)
> set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include/R_ext $path)
>
> Then what is about -I flags? I googled it but couldn't find anything. I
> don't really
> know what you meant by "The search paths supplemented by -I flags on
> the command
> line". How do I use it? Like this?
> set path = (/gpfs/data/local/linux/R-2.6.2/lib64/R/include $path) -I
>
>
> Thank you so much.
> Kyeongmi Cheon
>
> University of memphis
>
>
>
> You should never give full paths in #include statements.
>
> The search paths for include ('header') files are set by the compiler and
> supplemented by -I flags on the command line. If your C compiler is
> unable to find something is badly wrong, and you need to ask
> your 'unix' advisor for help. (BTW, these header files are OS-specific,
> and some of them will be compiler-specific -- on my Solaris Unix box cc
> and gcc use different versions of some of these headers.)
>
>
> -
> Kyeongmi,
>
> University of Memphis
> --
> View this message in context:
> http://www.nabble.com/R-extension-in-unix-systemhelp-to-locate-header-files-tp16760424p16763526.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] problem customizing CXXFLAGS in Windows
On Fri, 18 Apr 2008, Ian Fiske wrote: > Hi all, > > I am running R 2.6.2 in Windows XP with Rtools 2.7 and am trying to compile > a shared library in Windows with customized level of optimization. > Specifically, I would like to have "-O3 -funroll-loops" as flags when I run > "R CMD SHLIB ***.cc" to speed the program for my simulations. > > I have read through the documentation and have tried adding the line > > PKG_CXXFLAGS = -O3 -funroll-loops > > in my Makevars in my package's src directory. However, this places the > flags before the -O2 flag, thereby overriding it. I presume you meant the opposite -- 'it' refers to its immediate antecdent, 'the -O2 flag', which overrides not is overridden? That is, the flags are processed from left to right and later settings win. > I have also tried creating a config.site file in R_HOME/etc, but that > seems to be ignored. What gave you the idea that would be relevant? I don't see it in any of the manuals. > I found a possible solution at > http://tolstoy.newcastle.edu.au/R/e2/devel/07/03/2520.html. However, when I > use this suggestion, I get errors that R.h cannot be found. > > Please note that I do not plan to submit this package to CRAN or to other > users with the modified flags, but I just need to set them on my machine to > speed up simulations for testing, etc. >From the R-admin manual: 'Package-specific compilation flags can be overridden or added to using the personal file $HOME/.R/Makevars.win, or if that does not exist, $HOME/.R/Makevars. (See the rw-FAQ for the meaning of $HOME.) For the record, the order of precedence is (last wins) * MakeDll and MkRules * src/Makevars.win if it exists, otherwise src/Makevars * $HOME/.R/Makevars.win if it exists, otherwise $HOME/.R/Makevars. * src/Makefile.win if present causes all but the last of the above to be ignored. ' So you can set CXXFLAGS in src/Makevars.win and that will override the system's values. Or you could change the system setting to -O3 in MakeDll -- it is -O3 for C and Fortran, but -O2 for C++ (which R itself does not use) because -O3 for C++ used to be problematic (with gcc 3.4.5, not the current version). I think the URL you give is too old -- it probably preceeds the corrected separation of CPPFLAGS and C[XX]FLAGS. The rule is (from MkRules) .cc.o: $(CXX) $(CPPFLAGS) $($*-CPPFLAGS) $(CXXFLAGS) $($*-CXXFLAGS) -c $< -o $@ and so CPPFLAGS should contain include paths, and CXXFLAGS optimization levels. I've just taken a C++-using package and added CXXFLAGS=-O3 -funroll-loops to its Makevars. All the headers were found, and that was the optimization level used. > I appreciate any suggestions, > Ian -- Brian D. Ripley, [EMAIL PROTECTED] 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] problem customizing CXXFLAGS in Windows
Thanks for your suggestion, Prof Ripley. The problem was that I was originally specifying PKG_CXXFLAGS and not CXXFLAGS in my Makevars, as you pointed out. Now -O3 is recognized and working. Thanks, Ian On Fri, Apr 18, 2008 at 1:41 PM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Fri, 18 Apr 2008, Ian Fiske wrote: > > > > Hi all, > > > > > > I am running R 2.6.2 in Windows XP with Rtools 2.7 and am trying to > compile > > a shared library in Windows with customized level of optimization. > > Specifically, I would like to have "-O3 -funroll-loops" as flags when I > run > > "R CMD SHLIB ***.cc" to speed the program for my simulations. > > > > I have read through the documentation and have tried adding the line > > > > PKG_CXXFLAGS = -O3 -funroll-loops > > > > in my Makevars in my package's src directory. However, this places the > > flags before the -O2 flag, thereby overriding it. > > > > I presume you meant the opposite -- 'it' refers to its immediate antecdent, > 'the -O2 flag', which overrides not is overridden? That is, the flags are > processed from left to right and later settings win. > > > > I have also tried creating a config.site file in R_HOME/etc, but that > seems to be ignored. > > > > What gave you the idea that would be relevant? I don't see it in any of > the manuals. > > > > I found a possible solution at > > http://tolstoy.newcastle.edu.au/R/e2/devel/07/03/2520.html. However, when > I > > use this suggestion, I get errors that R.h cannot be found. > > > > Please note that I do not plan to submit this package to CRAN or to other > > users with the modified flags, but I just need to set them on my machine > to > > speed up simulations for testing, etc. > > > > From the R-admin manual: > > 'Package-specific compilation flags can be overridden or added to using the > personal file $HOME/.R/Makevars.win, or if that does not exist, > $HOME/.R/Makevars. (See the rw-FAQ for the meaning of $HOME.) For the > record, the order of precedence is (last wins) > > * MakeDll and MkRules > * src/Makevars.win if it exists, otherwise src/Makevars > * $HOME/.R/Makevars.win if it exists, otherwise $HOME/.R/Makevars. > * src/Makefile.win if present causes all but the last of the above to > be ignored. > ' > > > So you can set CXXFLAGS in src/Makevars.win and that will override the > system's values. Or you could change the system setting to -O3 in > MakeDll -- it is -O3 for C and Fortran, but -O2 for C++ (which R itself > does not use) because -O3 for C++ used to be problematic (with gcc 3.4.5, > not the current version). > > I think the URL you give is too old -- it probably preceeds the corrected > separation of CPPFLAGS and C[XX]FLAGS. The rule is (from MkRules) > > .cc.o: > $(CXX) $(CPPFLAGS) $($*-CPPFLAGS) $(CXXFLAGS) $($*-CXXFLAGS) -c $< > -o $@ > > and so CPPFLAGS should contain include paths, and CXXFLAGS optimization > levels. > > I've just taken a C++-using package and added > > CXXFLAGS=-O3 -funroll-loops > > to its Makevars. All the headers were found, and that was the optimization > level used. > > > > > I appreciate any suggestions, > > Ian > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > 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] [rd] sage <--> r integration
On Fri, Apr 18, 2008 at 8:17 AM, Rob Goedman <[EMAIL PROTECTED]> wrote: > Fritz, > > Thanks a lot for your very clear answer (it provided me with the needed > context for the decisions)! > > I'll continue to investigate what can be done on a small(er) scale with R, > the > already available R/python bridges (e.g. RSPython, RPy) and Sage. > Hi, You might also want to look at http://wiki.sagemath.org/R briefly. The code that is linked to there (in trac) will be going into Sage-3.0, which is due to be released very soon. I'm working on getting another UW undergrad student interested in this project summer, so Rob I hope you'll join sage-devel if you haven't already and keep us posted about anything you're interested in working on regarding R / Python-Sage integration. -- William __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
I am not sure what is included with swig, but have you seen this?
http://www.omegahat.org/RSWIG/
I'm not sure if it's actively maintained, but at the very least it might
help in your efforts at getting an R swig driver working.
Michael
On Fri, Apr 18, 2008 at 3:49 AM, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I was trying to use the R swig wrapper with R 2.7 and shogun
> ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't
> even compile and even after patching then though compiling - crashes...
>
> So I asked on swig-users/swig-devel CC'ing the potential R maintainer
> but I never received a reply. I now wonder if anyone here could help or
> would be willing to maintain R+swig.
>
> The compile fix for R 2.7 is here
>
> http://article.gmane.org/gmane.comp.programming.swig/12697
>
> and the crash I am now that it compiles see is
>
> #0 0xb804e201 in _dl_debug_state () from /lib/ld-linux.so.2
> #1 0xb8051608 in dl_open_worker () from /lib/ld-linux.so.2
> #2 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
> #3 0xb8050f5e in _dl_open () from /lib/ld-linux.so.2
> #4 0xb74c3c19 in dlopen_doit () from /lib/i686/cmov/libdl.so.2
> #5 0xb804d5d6 in _dl_catch_error () from /lib/ld-linux.so.2
> #6 0xb74c42bc in _dlerror_run () from /lib/i686/cmov/libdl.so.2
> #7 0xb74c3b51 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2
> #8 0xb7efd036 in loadLibrary (path=0xbfa5650c
> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
> asLocal=1, now=1, search=0x9a81f20 "") at dynload.c:92
> #9 0xb7d6efb3 in AddDLL (path=0xbfa5650c
> "/home/sonne/Documents/work/fml/repositories/shogun/trunk/src/features/Features.so",
> asLocal=1, now=1, DLLsearchpath=0x9a81f20 "") at Rdynload.c:543
> #10 0xb7d6f657 in do_dynload (call=0x9e23998, op=0x9a91e44,
> args=0xa60d5e0, env=0xa60d650) at Rdynload.c:904
> #11 0xb7e43dba in do_internal (call=0x9e239d0, op=0x9a8798c,
> args=0xa60d5e0, env=0xa60d650) at names.c:1129
> #12 0xb7e0df21 in Rf_eval (e=0x9e239d0, rho=0xa60d650) at eval.c:463
> #13 0xb7e11a3c in Rf_applyClosure (call=0xa60d74c, op=0x9e23a94,
> arglist=0xa60d6dc, rho=0x9a9a720, suppliedenv=0x9a9a73c) at eval.c:669
> #14 0xb7e0de19 in Rf_eval (e=0xa60d74c, rho=0x9a9a720) at eval.c:507
> #15 0xb7e31a00 in Rf_ReplIteration (rho=0x9a9a720, savestack=0,
> browselevel=0, state=0xbfa589a8) at main.c:257
> #16 0xb7e31ddc in run_Rmainloop () at main.c:306
> #17 0xb7e31e1c in Rf_mainloop () at main.c:974
> #18 0x08048776 in main (ac=1, av=0xb805b668) at Rmain.c:35
> #19 0xb7be8450 in __libc_start_main () from /lib/i686/cmov/libc.so.6
> #20 0x08048691 in _start ()
>
> To reproduce
>
> wget http://nn7.de/debugging/shogun-0.6.1+svn2882.tar.bz2
> tar xjf shogun-0.6.1+svn2882.tar.bz2
> cd shogun-0.6.1+svn2882/src
> ./configure --interface=R-modular
> make
>
> (wait a few minutes)
>
> R
> dyn.load('features/Features.so')
> #source("features/Features.R") # not even necessary.
>
> Note that shogun works for both python and octave nicely...
>
> So the question for me is, will this be better maintained in the future
> or should I stop investing time on getting R supported?
>
> Desperate,
> Soeren
>
> __
> 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] Couldn't (and shouldn't) is.unsorted() be faster?
Prof Brian Ripley wrote: > On Thu, 17 Apr 2008, Herve Pages wrote: [...] >> BTW, why not make is.unsorted() a little bit more prepared to silly user >> input: > > Because R is a volunteer project and resources spent on trapping misuse > are resources not available to be spent on other things. (Same as for > bug reports on fixed issues ) I know that, thanks! Hope that you noticed that I'm not requesting a new feature or anything fancy. Neither am I suggesting that I'm stuck because is.unsorted() doesn't check its arguments (like any other function directly exposed to the user is expected to do, especially for things that are used in an if statement). H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pb with package::foo(x) <- value
Hi, The parser doesn't seem to like this: somePackage::foo(x) <- value somePackage:::foo(x) <- value where foo() is a replacement function or method defined in package somePackage. For example: > x <- integer(4) > base::length(x) <- 7 Error in base::length(x) <- 7 : invalid function in complex assignment I've tried to put some back quotes on the left side of the assignment in different ways but was not successful. So finally I had to use the non-replacement form: > x <- base::`length<-`(x, 7) > x [1] 0 0 0 0 NA NA NA Is there a way to avoid this? Thanks! H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with package::foo(x) <- value
On Fri, Apr 18, 2008 at 7:17 PM, Herve Pages <[EMAIL PROTECTED]> wrote: > Hi, > > The parser doesn't seem to like this: > > somePackage::foo(x) <- value > somePackage:::foo(x) <- value > > where foo() is a replacement function or method defined in package > somePackage. > > For example: > > > x <- integer(4) > > base::length(x) <- 7 > Error in base::length(x) <- 7 : invalid function in complex assignment > I don't think this is a problem with the parser per se but rather with the way replacement works in R. It's trying to replace the length function inside the base namespace, which is not supported. You'd need to do this in two steps. "base_len<-" <- base::"length<-" base_len(x) <- 7 But maybe the way you suggest below is better... > I've tried to put some back quotes on the left side of the assignment in > different ways but was not successful. So finally I had to use the > non-replacement form: > > > x <- base::`length<-`(x, 7) > > x > [1] 0 0 0 0 NA NA NA > > Is there a way to avoid this? > > Thanks! > H. > > __ > 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
[Rd] AddComment (gram.y)
AddComment in gram.y would have been an extremely useful feature, but it's been #if-0'd out; is it unimplemented? It should have attached a comment attribute to any SEXP associated with a comment. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nondigits in R_FILEVERSION mess up Windows build
I tried for the first time to build R from source on Windows, where I
got the source code via svn. Per the Installation and Administration
manual, I altered src\gnuwin32\MkRules so it had the the locally
correct paths to HTML Help Workshop and Inno Setup 5. I also set
USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in
the directory src/gnuwin32 I ran 'make all recommended' and got an
error from windres very early in the build:
E:\R\R-svn\r-devel\src\gnuwin32>make all recommended
make --no-print-directory -C front-ends Rpwd
make -C ../../include -f Makefile.win version
make Rpwd.exe
gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o
windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o
c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error
make[3]: *** [rcico.o] Error 1
make[2]: *** [Rpwd] Error 2
make[1]: *** [front-ends/Rpwd.exe] Error 2
make: *** [all] Error 2
Line 9 of src\gnuwin32\front-ends\rcico.rc is
FILEVERSION R_FILEVERSION
The problem was that my change to MkRules caused 'svnversion' to put an
'M' (modified) on the end of the svn version it reports. This svn
version number is used in the R_FILEVERSION macro, which is used in in
the *.rc files. The resource file compiler, windres, appears to choke on
non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates
it might choke on leading 0's as well.)
After the following change, to remove the trailing M or S from the
svn version number, the build worked. In R itself, the svn version
contains the trailing 'M' to show it came from modified source.
In the long run it might be nice to alter MkRules so it can read
a LocalMkRules file which is not under svn control, so trivial path
changes in MkRules don't make it look like the build is from modified
source code. I don't think the M-less svn version in R_FILEVERSION
will cause any confusion.
Index: tools/GETVERSION
===
--- tools/GETVERSION(revision 45381)
+++ tools/GETVERSION(working copy)
@@ -43,7 +43,9 @@
echo "#define R_SVN_REVISION \"${svn_rev}\""
## Using 1-digit year stops problems with leading zeros
# echo "#define R_FILEVERSION${maj},${pl}${sl},${y1}${m}${d},0"
- echo "#define R_FILEVERSION${maj},${pl}${sl},${svn_rev},0"
+# echo "#define R_FILEVERSION${maj},${pl}${sl},${svn_rev},0"
+# Non-digits in R_FILEVERSION stop windres file.rc, remove trailing M or S.
+ echo "#define R_FILEVERSION${maj},${pl}${sl},`echo ${svn_rev}|sed -e
's/[MS]*$//'`,0"
echo
echo '#ifdef __cplusplus'
echo '}'
Bill Dunlap
Insightful Corporation
bill at insightful dot com
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with package::foo(x) <- value
On Fri, 18 Apr 2008, Herve Pages wrote: > Hi, > > The parser doesn't seem to like this: > > somePackage::foo(x) <- value > somePackage:::foo(x) <- value > > where foo() is a replacement function or method defined in package > somePackage. But the error message you show is not from the parser, and > parse(text="somePackage:::foo(x) <- value") expression(somePackage:::foo(x) <- value) attr(,"srcfile") does work. The error you show arises is in the evaluator. That's because that is not legal code. :: and ::: are operators, not part of the language per se (although I have proposed changing that). The message comes at a check for a name, and base::length is not a name. It often helps to look error messages up in the sources. > For example: > > > x <- integer(4) > > base::length(x) <- 7 > Error in base::length(x) <- 7 : invalid function in complex assignment > > I've tried to put some back quotes on the left side of the assignment in > different ways but was not successful. So finally I had to use the > non-replacement form: > > > x <- base::`length<-`(x, 7) > > x > [1] 0 0 0 0 NA NA NA > > Is there a way to avoid this? > > Thanks! > H. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] 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
