On Tue, Nov 25, 2014 at 11:38 AM, Sam Tobin-Hochstadt
<sa...@cs.indiana.edu> wrote:
> On Tue, Nov 25, 2014 at 11:00 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>> Do you have in mind making "xrepl" intended to be part of Minimal
>> Racket? If not, what's the mechanism for `racket` using "xrepl" when
>> it's available?
>
> I can think of a few ways of doing this.
>
> 1 Just make xrepl part of minimal Racket (probably removing the
> mandatory dependency on scribble/text/wrap)
If this is the only dependency that stands in the way of making it more
minimal, then it should be easy to make it dynamically loaded (like much
of the other functionality it uses). Just have a wrapper that
dynamically requires the wrap function, and if it fails, it will just
not do the wrapping. (IIRC, the things that xrepl uses wrapping for
fall outside of what you can get with a naive and quick implementation,
like wrapping error messages where the indentation matters.)
> 2 Have `racket/init` dynamically test of the presence of
> "xrepl/main.rkt" as a collection-file-path, and load it if available.
> 3 Have `racket/init` (or the `racket` binary) test for something like
> `racket/init/extended` which would be part of "xrepl" and part of
> other extended repls.
> 4 Like 3, but have an additional package which depends on "xrepl" and
> just contains `racket/init/extended`
>
> I prefer 2, 3, or 4 of these options -- it seems fine for "Minimal
> Racket" to not have line editing, but I'd be interested to hear what
> others expect.
(3) and (4) sound to me like an overkill -- `racket/init' is already
supposed to be extra interactive repl stuff, and adding an extra-extra
thing seem like overcomplicating it. (2) sounds perfectly fine though.
Also, as I said above, getting (1) should be easy, but is that the only
dependency that would fall outside of a minimal distribution?
>> A similar question applies to "libeditline". Currently, for Linux and
>> other Unix platforms (not counting "natipkg" variants), our
>> convention is that native libraries are either part of the
>> `[g]racket` executable or they are installed separately by users
>> through the OS's package manager. We can't link to "libreadline" by
>> default in a Racket distribution, and since "libeditline" isn't
>> typically included with Linux distributions (as far as I can tell),
>> it seems like we haven't solved any problem unless we provide
>> "libeditline". Should "libeditline" become not only part of the
>> Minimal Racket distribution, but even part of the Racket executable?
>> Or should our convention and/or distribution infrastructure change?
>
> I was thinking that the "readline-core" package would dynamically test
> of "libeditline", and if it's not there fall back to "libreadline".
Why is it needed to have a core subset? => What are the readline
features that are missing from editline?
> My opinion, as someone who isn't a lawyer but has read a lot about
> this, is that this would not cause Racket to be a derived work of
> readline.
If that's valid, then that would be really nice.
> If we don't want to do that, I see a few possibilities:
>
> 1. We ship xrepl in whichever way we decide, and change the message
> it prints when it can't find "libeditline" to suggest changing things
> or adding (require xrepl/readline) to .racketrc.
> 2. We ship a copy of "libeditline"with xrepl as a built binary, even on
> linux.
> 3. We statically link "libeditline" to Racket in the standard distribution.
>
> I think 1 sounds most appealing if we're not ok with dynamically
> falling back to "libreadline".
(1) sounds good, except that it must target naive users -- so suggetsing
package installation is not a good idea. An alternative to a printout
would be a question:
I can't find editline (a library for line editing), but I see that
you have readline installed. Use it instead?
(And if readline does have some feature that editline doesn't, then the
question can be always be asked.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
