[Gretl-devel] Rlib daily update!

Allin Cottrell cottrell at wfu.edu
Thu Jul 9 16:01:18 EDT 2009


I'm not trying to pre-empt further discussion of gretl/R
interaction, but I'd like to get the Rlib material into a state
where I'm reasonably comfortable with it, on a provisional and
still hidden basis.  So I've been doing a bit more.

First, re. Talha's "freak of nature" comment
http://lists.wfu.edu/pipermail/gretl-devel/2009-July/001967.html ,
I admit I'm not very comfortable with hard-linking a build of
gretl to libR (so that if one decided to remove R for some reason,
gretl would stop working).  That's a bit too much like Siamese
twins.  Since I've now figured out how to access libR via dlopen
(or equivalent), I think that's the way to do it: open libR on
demand.

Anyway, here's the state of play.  First a brief reminder: for
some time we have supported R via the GUI menu item for launching
R and the script "foreign" command.  These are enabled in all
builds of gretl (there's no configure option for disabling these
things), but whether they actually work or not obviously depends
on whether an R installation is accessible.

Now for Rlib (which I'll use as a generic label for libR.so on
*nix and R.dll on Windows).  Since we're opening the library on
demand we don't need to have it available at compile time, though
we do need the R headers.  Gretl's configure script now has an
option, --with-libR/--without-libR.  The default is "auto": we
test for the R headers using pkg-config and build in Rlib support
if they're found.  But if you don't want this support (even if you
have R installed), use --without-libR.

Chris's patch added a language to the "foreign" command, namely
"RLib".  I've now removed that: the language is just plain "R",
and whether the "foreign" mechanism uses the R executable or Rlib
depends on thwo things.  First, obviously, on whether Rlib support
is compiled into gretl (it is, in the current Windows snapshot).
Second, there's another "set" variable, "R_lib". Right now, if
this is unset, we use the R excutable, if it's set "on" we use
Rlib.

If you try to "set R_lib on" and there's no Rlib support in gretl,
you get a warning:

Warning: setting ignored: 'R_lib' not supported.

At some point it may be worth reversing the default: in other
words, using Rlib automatically for "foreign language=R" if it's
supported by the build, unless the user does "set Rlib off".
Or we could trash the option.  For the moment I want it there for
testing purposes.

Then there's the last point: look-up of R functions.  For the
present I've left this as I last described it.  You have to "set
R_functions" on to get this.  This depends on compiled-in Rlib
support, but it does not depend on setting "R_lib" on. And you
need to prepend "R_" to the function names to have them found.

If anyone's still reading: I've also implemented support for
"foreign language=ox" (and editing/running of Ox programs via the
GUI).  But this is not enabled by default in the gretl build:
you have to select --with-ox when configuring gretl to get it.

Allin.


More information about the Gretl-devel mailing list