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) 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. > 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". 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 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". Sam > > At Mon, 24 Nov 2014 18:02:45 -0500, Sam Tobin-Hochstadt wrote: >> My understanding of the licensing issues is that if the code works with >> both "libeditline" and "libreadline" then it isn't a derived work of >> readline, and therefore could be licensed under the LGPL, like the rest of >> Racket. Furthermore, turning use of "libeditline" on by default wouldn't be >> linking to any GPL code, meaning that we could do that by default. >> >> I think we should split up the `readline` collection into `readline` and >> `readline/base` which would be what's compatible with editline, and have >> xrepl in a `readline/base` mode on by default. >> >> Sam >> >> On Mon, Nov 24, 2014 at 5:57 PM, Leif Andersen <l...@leifandersen.net> >> wrote: >> >> > Hello, >> > >> > When a user first starts the racket repl, it doesn't do line editing due >> > to licensing issues. For example, it would be nice if the default editor >> > would give the previous line if you hit up arrow, rather than writing >> > "^[[A". >> > >> > I have now pointed out xrepl to several users, and every time they always >> > ask me why it's not the default repl. Apparently the problem is that xrepl >> > uses GNU Readline, which is GPL. However, Asumu found that if we replace >> > requiring readline with BSD's libedit (not libeditline), everything works >> > fine due to libedit's readline compatibility. It doesn't have all of the >> > features of readline, but it does have some of the biggest ones (such as >> > being able to use arrow keys) >> > >> > What do you all think of having `(require editline)` that works for the >> > default repl, so that it gets line editing features. This would allow us to >> > also keep `(require readline)` as before, maintaining backwards >> > compatibility. >> > >> > If we do do this, this leads to the question of distribution. Would we >> > want to include libedit inside Racket distributions, or should we just link >> > to whatever the user has on their system? >> > >> > ~Leif Andersen >> > >> > _________________________ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev >> > >> > >> _________________________ >> Racket Developers list: >> http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
