Open waynelapierre opened 3 years ago
Thank you for the kind words and Welcome!
I agree that the interactive workflow could be improved. I don’t think I’ll have time to work in this in the next few weeks, but a PR might be welcome.
Also, I wouldn’t be surprised if once we get into it, we realize it’s not as straightforward as it seems.
One thing to consider is that perhaps we should take advantage of the work already done in the inline
package and maybe add a PR there (though they certainly wouldn’t want to take a dependency on RFI until it’s on CRAN). We could in the interim reach in with :::
and use some of their internal functions if they are useful.
Also, in response to this comment I’ve also just made public a private repo I wrote a while ago. It’s a quick proof-of-concept put together over 2 weekends: https://github.com/t-kalinowski/frast. It’s extremely hacky but, last I checked, it works. It attempts to transpile R functions to a Fortran subroutine, compile a fortran module with the subroutine, and then dyn.load the fortran module so. In a way it’s a “fake jit”. Feel free to go spelunking and salvage pieces you find useful.
(also, FYI, modifying R scalars through .ModernFortran is currently broken. I investigated a little a while ago and concluded it’s a gfortran issue. The Readme here still needs to be updated and I really should file an issue upstream)
I didn't know that the inline package can work with Fortran. The R package dotCall64 is also very useful. By the way, could you publish this RFI package in CRAN?
I would be happy to publish this on CRAN, but I'd have to investigate what the "right thing" is for dependencies that are required for a build. This package currently won't compile without "ISO_Fortran_binding.h" headers and associated library, which AFAIK are currently only available on a subset of the systems CRAN builds against. On Ubuntu 20.04+, these are provided by the system, but figuring out how to make them available on Windows and Mac and earlier versions of Linux (and I don't know anything about Solaris) would require a little leg work.
PR on helping make this package CRAN ready is welcome :)
Thanks so much for creating this great package! Not having to pass the array size when calling Fortran subroutines from R is really a game-changer. As a big fan of Fortran, I would like to transition from Rcpp to your package.
Since you have already solved the array size passing issue (which I believe is the most challenging one), do you plan to create a function interface for your package? By function interface, I mean directly compiling and exporting Fortran subroutines into R like what Rcpp::sourceCpp does. Since most users use R interactively, it is important to be able to compile and export Fortran subroutines on the fly.