similar to: Calling Fortran90 code from R

Jim Lindsey wrote: > I am getting more and more useful and interesting code in Fortran90 > that I would like to incorporate into my R libraries. I am currently > working on one that does two levels of nesting for binary data (3 > level hierarchical model). This is a great deal of work. Does anyone > know of a public domain Fortran90 compiler. I am doubtful, given the > number of

Hi, working with R, version 0.63.0, I was successful to dyn.load fortran90 subroutines on a Solaris 2.6, as long as they are more or less in conformity with f77. It was not possible to work with statements like REAL,DIMENSION(:) :: d or x=SUM(y). REAL,DIMENSION(1:10) :: d is possible. We compiled R with f77. Is it possible with real f90 routines or is is in any conflict with the shared

Hi there, We are trying to compile a 64bit version of R (2.5.1) on HP-UX (B.11.23 U ia64), but are running into some problems. This is our configure step: ../configure --prefix=/rnd/homes/lfan/R251 --enable-R-shlib CC="cc" CFLAGS="+z +DD64" CXX="aCC" CXXFLAGS="-b -lxnet +z +DD64" FC="f90" FCFLAGS="+DD64" F77="f90"

Hi, I have a problem with getting through the make process. It fails during the ld process. Can someone explain the errors that I get ? `Makedeps' is up to date. `libappl.a' is up to date. `libmath.a' is up to date. `libunix.a' is up to date. `../../bin/R.X11' is up to date. building package `base' ../../../library/base/R/base is unchanged building package `ctest'

Hi all, Is anybody here using Fortran90 and Fortran77 on their CentOS-machine(s)? If so, did you get that from a repo or something? One of our PhD-students needs a software that requires the Fortran compilers mentioned in order to make the sources for our i7-machines. The Fortran stuff that is available to me is from the standard CentOS repos, as well as Rpmforge and EPEL repos, from which I

I am trying to load a .so file and get the following error message: > dyn.load("taper.so",local=F) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library "/home/hpc1367/runs/taper/taper.so": ld.so.1: /usr/local/lib/R/bin/R.bin: fatal: relocation error: file /home/hpc1367/runs/taper/taper.so: symbol f90_init: referenced symbol not

Hi R usrs, I want to build R-2.10.0 on HP-UX, but I got following error message: ld: Unsatisfied symbol "zgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "zherk" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsm" in file

Dear R community, I have a question on how R manages memory allocation in .Fortran() calls under Windows. In brief, apparently, it is not possible to allocate large matrices inside a Fortran subroutine unless you pass them as arguments. If you do not act in this way RGUI crashes with a stack overflow error and acting on memory through vsize nsize ppsize and memory.limit does not help at all.

I have the following FORTRAN code converted to a DLL: ! my_xmean.f90 ! ! FUNCTIONS/SUBROUTINES exported from my_function.dll: ! my_function - subroutine ! subroutine my_xmean(X,N,XMEAN) ! Expose subroutine my_function to users of this DLL ! !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean ! Body of my_function DOUBLE PRECISION X(N) XMEAN=0D0 DO J=1,N

Dear all, I am puzzled at the behaviour of is.loaded() when a dyn.load() call to a a FORTRAN shared library is included in a file to be sourced. A reproducible example is the following: 1. the attached fortran subroutine try_it.f90 performs a summation of the elements of a REAL*8 vector compile with gfortran try_it.f90 -shared -s -otry_it.dll 2. create a file to be sourced (see the attached

I'm trying to compile R, not getting pass the configure step. R version is 2.7.1 from source tarball. Machine is HPUX 11.31, 32-CPUs of Itanium II. Compilers are HPUX C, C++ and Fortran. (B3910B A.06.15, May 2007) My config string: ./configure --prefix=/apps/INTEL/R --enable-R-shlib CC=/opt/aCC/bin/cc CXX=/opt/aCC/bin/aCC FC=/opt/fortran90/bin/f90 --prefix=/apps/INTEL/R --enable-R-shlib

Full_Name: Denis Sunko Version: 1.3.1 OS: HP-UX 11.0 Submission from: (NULL) (161.53.2.114) I invoked configure by env LDFLAGS=/opt/fortran90/lib ./configure --with-f77=f90 Problem: although configure completed to (its own) satisfaction, the LDFLAGS information was not propagated everywhere; I had to change the line PKG_LIBS = -l:libF90.a -lcl -lisamstub to PKG_LIBS =

Hi! Is there any package on CRAN that uses Fortran-90/95? I would like to study it. Thanks, Gregor

Hi, We have several projects in the center done by researchers over years in Fortran, there are copy right issues etc to prevent us from giving away the source codes, but a lot of social scientist are interested to use the program. We tried to use dlls to make plugins (available in our website) in various statistics platforms (SAS, STATA and R) to make it available to general public. We used

Hi All, I'm writing R code that would benefit from doing certain tasks using compiled blocks of code, specifically Fortran subroutines of my own (already written, debugged in both Fortran77 and Fortran90). I am currently working on a Windows machine using Lahey and/or MinGW(g77) compilers. It is possible to dynamically load Fortran DLLs into R as evidenced from the several documents

Hi Ashay, Do you need specifically llvm-gfortran that is based on gcc 4.2? Since that, DragonEgg has been introduced - a powerful plugin to gcc that makes it possible to utilize regular gcc compilers as frontends to llvm: http://dragonegg.llvm.org/ It generates Fortran90 programs for me very well. - D. 2011/9/1 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hello, > I have been

On Sun, Dec 07, 2014 at 05:35:37PM +0100, Johann Hartwig Hauschild wrote: > > I just had a look at the kernel-docs and the discussion here in november. > This issue should not be happening if I build a pre-3.3-kernel with > CONFIG_RELOCATABLE=y, CONFIG_EFI=y and CONFIG_EFI_STUB=y, right? Those are allready at those values at

Dear all, following the thread http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4338.html regarding the bug in the partial autocorrelation function for multivariate time series. I have prepared a web page with patches and relevant information. http://www2.stat.unibo.it/giannerini/R/pacf.htm Please do not hesitate to contact me for further clarifications regards Simone --

Am 07.12.2014 schrieb Geert Stappers: > On Sun, Dec 07, 2014 at 05:35:37PM +0100, Johann Hartwig Hauschild wrote: > > > > I just had a look at the kernel-docs and the discussion here in november. > > This issue should not be happening if I build a pre-3.3-kernel with > > CONFIG_RELOCATABLE=y, CONFIG_EFI=y and CONFIG_EFI_STUB=y, right? > > Those are allready at

Dear all, I encountered a problem when compiling the source of R patched 2.10.0 r50499 (19-11-2009) linked to ACML single threaded (4.2.0 or 4.3.0) OS: openSuSE 11.0 x86-64 make fails when it comes to installing mgcv with the following [snip] ** R ** inst ** preparing package for lazy loading Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : non esiste un pacchetto chiamato