Announcement:
(For those every-once-in-a-while occasions when you run R from a
terminal instead of Emacs, and then wish something would happen when
you hit TAB...)
Last week, I started looking at the GNU Readline documentation to see
if I could figure out how to use it for command completion within R.
It turned out to be easier than I had expected, and I now have a beta
version of the 'rcompletion' package available at
http://www.stat.wisc.edu/~deepayan/R/rcompletion_0.0-6.tar.gz
From the help page:
Description:
This package provides pseudo-intelligent TAB completion for a
readline enabled instance of R when it is run from a terminal (or
more specifically, an interface which uses readline to accept user
input). It has no effect on the various GUI interfaces to R,
including ESS and the standard Windows interface.
For more details, install and load the package, then type
package?rcompletion
at the R prompt. Testing and feedback would be appreciated. Feature
requests and patches are also welcome, of course.
Questions:
There are a couple of things about which I would like some advice:
(1) The package currently contains a very rudimentary configure script
which stops installation when readline is not found. I'm not sure if
this is portable enough. .../src/unix/sys-std.c has more sophisticated
conditional directives, but I don't know enough about this sort of
thing to interpret those. Any thoughts or suggestions on this would be
appreciated.
(2) What's the recommended procedure to distribute this, given that
(a) it's not relevant on Windows (i.e. won't do anything even if it
could be installed) and (b) may or may not be relevant on Macs, some
of which apparently have a fake readline that doesn't support
completion?
-Deepayan
On 23 October 2006 at 16:51, Deepayan Sarkar wrote:
[... nice announcement trimmed ...]
| There are a couple of things about which I would like some advice:
|
| (1) The package currently contains a very rudimentary configure script
| which stops installation when readline is not found. I'm not sure if
| this is portable enough. .../src/unix/sys-std.c has more sophisticated
| conditional directives, but I don't know enough about this sort of
| thing to interpret those. Any thoughts or suggestions on this would be
| appreciated.
littler has the same issue for getopt, R itself, R as a dynamic library,
.... So far, we are going with 'just bark and stop'.
For rcompletion, I hope you simply stick with configure. I don't like the
trend of shipping everything again and again (Hi, Seth :)
| (2) What's the recommended procedure to distribute this, given that
| (a) it's not relevant on Windows (i.e. won't do anything even if it
| could be installed) and (b) may or may not be relevant on Macs, some
| of which apparently have a fake readline that doesn't support
| completion?
Again, I also wondered if littler should just pretend to be a CRAN package so
that at least the update and compile mechanism works from R (given how we
need re-runs of configure and make if something changes as we depend on
compile-time 'hard' settings for littler as opposed to env. vars for R).
The problem we are facing is that we're unsure how to get to
/usr/(local/)/bin from update.packages() ...
Given that you'll undoubtedly come up with something clever, Jeff and I will
be sure to see if we can mimic it :)
Dirk
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
On 10/23/06, Dirk Eddelbuettel <edd at debian.org> wrote:
On 23 October 2006 at 16:51, Deepayan Sarkar wrote:
[... nice announcement trimmed ...]
| There are a couple of things about which I would like some advice:
|
| (1) The package currently contains a very rudimentary configure script
| which stops installation when readline is not found. I'm not sure if
| this is portable enough. .../src/unix/sys-std.c has more sophisticated
| conditional directives, but I don't know enough about this sort of
| thing to interpret those. Any thoughts or suggestions on this would be
| appreciated.
littler has the same issue for getopt, R itself, R as a dynamic library,
.... So far, we are going with 'just bark and stop'.
For rcompletion, I hope you simply stick with configure. I don't like the
trend of shipping everything again and again (Hi, Seth :)
| (2) What's the recommended procedure to distribute this, given that
| (a) it's not relevant on Windows (i.e. won't do anything even if it
| could be installed) and (b) may or may not be relevant on Macs, some
| of which apparently have a fake readline that doesn't support
| completion?
Again, I also wondered if littler should just pretend to be a CRAN package so
that at least the update and compile mechanism works from R (given how we
need re-runs of configure and make if something changes as we depend on
compile-time 'hard' settings for littler as opposed to env. vars for R).
The problem we are facing is that we're unsure how to get to
/usr/(local/)/bin from update.packages() ...
Given that you'll undoubtedly come up with something clever, Jeff and
I will be sure to see if we can mimic it :)
Well, rcompletion is a proper package, the only issue is that it's
platform / environment dependent. I know there are other such
packages, I just don't know how they are dealt with.
I don't see how you can get around the /usr/bin problem for littler,
except by asking the user to manually do something like
ln -s /path/to/library/littler/bin/r /usr/local/bin/
which at least wouldn't have to be repeated on further upgrades if you
detect that the link exists.
-Deepayan
Announcement:
(For those every-once-in-a-while occasions when you run R from a
terminal instead of Emacs, and then wish something would happen when
you hit TAB...)
Last week, I started looking at the GNU Readline documentation to see
if I could figure out how to use it for command completion within R.
It turned out to be easier than I had expected, and I now have a beta
version of the 'rcompletion' package available at
http://www.stat.wisc.edu/~deepayan/R/rcompletion_0.0-6.tar.gz
From the help page:
Description:
This package provides pseudo-intelligent TAB completion for a
readline enabled instance of R when it is run from a terminal (or
more specifically, an interface which uses readline to accept user
input). It has no effect on the various GUI interfaces to R,
including ESS and the standard Windows interface.
For more details, install and load the package, then type
package?rcompletion
at the R prompt. Testing and feedback would be appreciated. Feature
requests and patches are also welcome, of course.
Questions:
There are a couple of things about which I would like some advice:
(1) The package currently contains a very rudimentary configure script
which stops installation when readline is not found. I'm not sure if
this is portable enough. .../src/unix/sys-std.c has more sophisticated
conditional directives, but I don't know enough about this sort of
thing to interpret those. Any thoughts or suggestions on this would be
appreciated.
(2) What's the recommended procedure to distribute this, given that
(a) it's not relevant on Windows (i.e. won't do anything even if it
could be installed) and (b) may or may not be relevant on Macs, some
of which apparently have a fake readline that doesn't support
completion?
Distribution can happen regularly as a CRAN package. I will put it on my
exclude list in order not to try building Windows binaries in that case.
Uwe
Announcement:
(For those every-once-in-a-while occasions when you run R from a
terminal instead of Emacs, and then wish something would happen when
you hit TAB...)
Last week, I started looking at the GNU Readline documentation to see
if I could figure out how to use it for command completion within R.
It turned out to be easier than I had expected, and I now have a beta
version of the 'rcompletion' package available at
http://www.stat.wisc.edu/~deepayan/R/rcompletion_0.0-6.tar.gz
From the help page:
Description:
This package provides pseudo-intelligent TAB completion for a
readline enabled instance of R when it is run from a terminal (or
more specifically, an interface which uses readline to accept user
input). It has no effect on the various GUI interfaces to R,
including ESS and the standard Windows interface.
For more details, install and load the package, then type
package?rcompletion
at the R prompt. Testing and feedback would be appreciated. Feature
requests and patches are also welcome, of course.
Questions:
There are a couple of things about which I would like some advice:
(1) The package currently contains a very rudimentary configure script
which stops installation when readline is not found. I'm not sure if
this is portable enough. .../src/unix/sys-std.c has more sophisticated
conditional directives, but I don't know enough about this sort of
thing to interpret those. Any thoughts or suggestions on this would be
appreciated.
I don't think that is safe. You can have R installed with readline
support even if there are neither readline headers nor library on the
current machine (use a static library), and R can be run without readline
(via --no-readline) even if it is installed.
However, your configure script fails on my machine (x86_64 FC5). It seems
that you need both to get LDFLAGS and LD_LIBRARY_PATH from R and use them,
and also use a version of autoconf that knows about lib64 (since the
readline DSO is in /usr/lib64). Since I don't get any further I am not
sure what really happens, but it seems you don't link your DLL against
-lreadline, and I think you need to to allow for static libreadline.a (the
relevant code seems to be a separate .o and so is likely not linked into R
in that case).
I guess that you want to know that R was installed with readline support
at install time, and is running with the readline console? It is not
immediately obvious to me that either is currently known to a package
writer/user.
(2) What's the recommended procedure to distribute this, given that
(a) it's not relevant on Windows (i.e. won't do anything even if it
could be installed) and (b) may or may not be relevant on Macs, some
of which apparently have a fake readline that doesn't support
completion?
Distribution can happen regularly as a CRAN package. I will put it on my
exclude list in order not to try building Windows binaries in that case.
I think there should also be a configure.win which explains that the
package is not usable on Windows, in case someone tries to install from
the sources.
Brian D. Ripley, ripley at 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
On 10/24/06, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
On Tue, 24 Oct 2006, Uwe Ligges wrote:
[...]
Questions:
There are a couple of things about which I would like some advice:
(1) The package currently contains a very rudimentary configure script
which stops installation when readline is not found. I'm not sure if
this is portable enough. .../src/unix/sys-std.c has more sophisticated
conditional directives, but I don't know enough about this sort of
thing to interpret those. Any thoughts or suggestions on this would be
appreciated.
I don't think that is safe. You can have R installed with readline
support even if there are neither readline headers nor library on the
current machine (use a static library), and R can be run without readline
(via --no-readline) even if it is installed.
I don't think the last case is a problem; nothing useful will happen
after loading the package in that case, but nothing bad will happen
either. If there's no readline library, is there anything the
configure script can reasonably do other than abort? If the library is
there but the headers aren't, I can probably use headers included in
the package. Is that a reasonable approach? I have no idea what to do
with a static library.
However, your configure script fails on my machine (x86_64 FC5).
Fails in what sense? Does it abort saying it didn't find readline?
It seems
that you need both to get LDFLAGS and LD_LIBRARY_PATH from R and use them,
and also use a version of autoconf that knows about lib64 (since the
readline DSO is in /usr/lib64). Since I don't get any further I am not
sure what really happens, but it seems you don't link your DLL against
-lreadline, and I think you need to to allow for static libreadline.a (the
relevant code seems to be a separate .o and so is likely not linked into R
in that case).
I have modified configure.in to add a -lreadline to PKG_LIBS, and also
to use header files from within the package if the system headers are
not found. The new version is at
http://www.stat.wisc.edu/~deepayan/R/rcompletion_0.0-7.tar.gz
I'm working on a 64 bit system, so I'm hoping autoconf knows what to
do there. I'm not sure how to get or use LDFLAGS and LD_LIBRARY_PATH
from R. R CMD config LDFLAGS does give me something (but I'm not sure
what to do with it), but there doesn't seem to be anything analogous
to LD_LIBRARY_PATH.
I guess that you want to know that R was installed with readline support
at install time, and is running with the readline console? It is not
immediately obvious to me that either is currently known to a package
writer/user.
I don't think that's as much of an issue. If R doesn't ever make a
call to readline(), whether the rcompletion package is loaded or not
won't make any difference. The user won't get the benefits, but that's
a choice made by the user. For example, running R through ESS and then
loading rcompletion doesn't have any effect at all.
The one scenario that definitely needs to be avoided is where R CMD
INSTALL appears to install the package successfully and then
library(rcompletion) causes an error (either immediately on load or
later). Unless anyone reports seeing that, I'll plan to upload this to
CRAN in a few days.
Cases where configure aborts even though it shouldn't will probably
need some time (and help) to work out, since I'm completely new to
autotools.
(2) What's the recommended procedure to distribute this, given that
(a) it's not relevant on Windows (i.e. won't do anything even if it
could be installed) and (b) may or may not be relevant on Macs, some
of which apparently have a fake readline that doesn't support
completion?
Distribution can happen regularly as a CRAN package. I will put it on my
exclude list in order not to try building Windows binaries in that case.
I think there should also be a configure.win which explains that the
package is not usable on Windows, in case someone tries to install from
the sources.
If configure.win doesn't exist, would it try to use configure? In that
case, installation should just abort when readline isn't found,
shouldn't it? Would having a configure.win serve any additional
purpose?
-Deepayan