ANN/RFC: package providing TAB completion for readline-based R

[Deepayan Sarkar]

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Dirk Eddelbuettel]

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Deepayan Sarkar]

On 10/23/06, Dirk Eddelbuettel <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Uwe Ligges]

Deepayan Sarkar wrote:

> 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


> -Deepayan
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Prof Brian Ripley]

On Tue, 24 Oct 2006, Uwe Ligges wrote:

>
>
> Deepayan Sarkar wrote:
>> 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,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  [phone] (self)
1 South Parks Road,                     [phone] (PA)
Oxford OX1 3TG, UK                Fax:  [phone]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Deepayan Sarkar]

On 10/24/06, Prof Brian Ripley <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel