Integrating editline with ghc

newer
Security Notice: Buffer overflow...

Judah Jacobson

16 Jan 2008 16 Jan '08

4:05 p.m.

Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah

Show replies by date

Manuel M T Chakravarty

16 Jan 16 Jan

11:54 p.m.

Judah Jacobson:

...

Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/

As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).

Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following:

- Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline.

Does that sound like the right way to handle this? If so, I'll send a darcs patch.

Sounds good to me.

...

Also, should editline be made a boot-package or an extra-package (or neither)?

Given that we like this to be the default on some platforms, I believe it belongs into boot-packages (just like readline). Manuel

Christian Maeder

17 Jan 17 Jan

4:19 a.m.

Judah Jacobson wrote:

...

- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).

I would like to see a restructuring of the old readline package: 1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications. 2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name! Cheers Christian

Malcolm Wallace

5:47 a.m.

Christian Maeder wrote:

...

1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available. Regards, Malcolm

Yitzchak Gale

7:48 a.m.

Christian Maeder wrote:

...

1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline.

...

If this package is called "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

Well, we do have to take some care. This new package cannot depend on either of the two implementation packages. So when you upgrade, your programs will stop compiling until you manually install one of the two. People who are not aware of what is going on will be perplexed. Perhaps the upgrade path would be smoother if we end-of-life the readline package, and replace it with readline-iface plus the two implementation packages. The last version of readline would be emtpy, with dependencies on readline-iface and readline-readline, and a comment that it can be safely removed once installed. That is the strategy commonly used for this situation by other package systems, like Debian. What do you think? -Yitz

Manuel M T Chakravarty

8:03 p.m.

Malcolm Wallace:

...

Christian Maeder wrote:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available.

I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and they should be able to continue to do this by importing the library called System.Console.Readline. In addition System.Console.Editline should be a binding to editline. (Again if somebody want editline and nothing else, that's what they import.) Finally, we'd like a module (let's call it EditReadline) whose interface coincides with the readline emulation layer of editline (ie, ). This module should use editline where it is available and otherwise readline (if that is available). We can argue about where in the hierarchy EditReadline should be located (and whether we want to call it EditReadline or something else). Following Judah's proposal, it could be System.Console.Editline.Readline (essentially following the C header structure), but it could alternatively be System.Console.EditReadline (or something else). I think it is important to make a clear distinction between these *three* interface for two reasons: * Both editline and readline have functionality that is not exposed by EditReadline (aka ). * Static linking against EditReadline is allowed for non-GPL compatible code only on systems that have editline. Manuel

Don Stewart

8:05 p.m.

chak:

...

Malcolm Wallace:

...
Christian Maeder wrote:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available.

I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and they should be able to continue to do this by importing the library called System.Console.Readline.

I agree, it makes no sense to hide/obscure readline. Just depend on a different package. So as for the regex-compat lib, we can live happily with a readline-compat that gives a compatible interface to readline, via other means. -- Don

Manuel M T Chakravarty

18 Jan 18 Jan

12:29 a.m.

Don Stewart:

...

chak:

...
Malcolm Wallace:

...
Christian Maeder wrote:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available.

I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and they should be able to continue to do this by importing the library called System.Console.Readline.

I agree, it makes no sense to hide/obscure readline. Just depend on a different package.

So as for the regex-compat lib, we can live happily with a readline- compat that gives a compatible interface to readline, via other means.

Yes, readline-compat seems like the right package name for this. Manuel

Simon Marlow

8:07 a.m.

Manuel M T Chakravarty wrote:

...

Malcolm Wallace:

...
Christian Maeder wrote:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available.

I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and they should be able to continue to do this by importing the library called System.Console.Readline.

In addition System.Console.Editline should be a binding to editline. (Again if somebody want editline and nothing else, that's what they import.)

Finally, we'd like a module (let's call it EditReadline) whose interface coincides with the readline emulation layer of editline (ie, ). This module should use editline where it is available and otherwise readline (if that is available). We can argue about where in the hierarchy EditReadline should be located (and whether we want to call it EditReadline or something else). Following Judah's proposal, it could be System.Console.Editline.Readline (essentially following the C header structure), but it could alternatively be System.Console.EditReadline (or something else).

I think it would be a bad idea to provide EditReadline as described. The reason being that this would be a package with a variant license: its license is conditional on how it is built, which makes it that much harder for clients to understand what licensing restrictions apply, and to license themselves appropriately. (the alternative is to make EditReadline GPL, but that defeats the purpose). I don't even think we've considered variant licenses in Cabal before, and my inclination would be to disallow or at least vigorously discourage it. So I suggest we just keep readline as it is, and packages that want to use editline can switch at their discretion, using System.Console.Editline.Readline to make porting easier. In GHC I imagine we'll just switch to using editline. Cheers, Simon

Manuel M T Chakravarty

22 Jan 22 Jan

4:49 a.m.

Simon Marlow:

...

Manuel M T Chakravarty wrote:

...
...
Christian Maeder wrote:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available. I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and

Malcolm Wallace: they should be able to continue to do this by importing the library called System.Console.Readline. In addition System.Console.Editline should be a binding to editline. (Again if somebody want editline and nothing else, that's what they import.) Finally, we'd like a module (let's call it EditReadline) whose interface coincides with the readline emulation layer of editline (ie, ). This module should use editline where it is available and otherwise readline (if that is available). We can argue about where in the hierarchy EditReadline should be located (and whether we want to call it EditReadline or something else). Following Judah's proposal, it could be System.Console.Editline.Readline (essentially following the C header structure), but it could alternatively be System.Console.EditReadline (or something else).

I think it would be a bad idea to provide EditReadline as described. The reason being that this would be a package with a variant license: its license is conditional on how it is built, which makes it that much harder for clients to understand what licensing restrictions apply, and to license themselves appropriately. (the alternative is to make EditReadline GPL, but that defeats the purpose).

I don't even think we've considered variant licenses in Cabal before, and my inclination would be to disallow or at least vigorously discourage it.

I don't like this either.

...

So I suggest we just keep readline as it is, and packages that want to use editline can switch at their discretion, using System.Console.Editline.Readline to make porting easier. In GHC I imagine we'll just switch to using editline.

That's fine if all platforms that by default have readline also have editline. I just checked, Fedora 8 does have both. How about other Linux distros? What is the situation on Solaris? Manuel

Judah Jacobson

24 Jan 24 Jan

11:44 a.m.

On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty wrote:

...

Simon Marlow:

...
I think it would be a bad idea to provide EditReadline as described. The reason being that this would be a package with a variant license: its license is conditional on how it is built, which makes it that much harder for clients to understand what licensing restrictions apply, and to license themselves appropriately. (the alternative is to make EditReadline GPL, but that defeats the purpose).

I don't even think we've considered variant licenses in Cabal before, and my inclination would be to disallow or at least vigorously discourage it.

I don't like this either.

...
So I suggest we just keep readline as it is, and packages that want to use editline can switch at their discretion, using System.Console.Editline.Readline to make porting easier. In GHC I imagine we'll just switch to using editline.

That's fine if all platforms that by default have readline also have editline. I just checked, Fedora 8 does have both. How about other Linux distros? What is the situation on Solaris?

A few distros (including Solaris) have libedit version 1.*, which appears to be too old to provide enough functionality to replace readline. From what I can tell, libedit-1 provides the header , whereas libedit-2 provides as well as either or . (OS X 10.4 and 10.5 have 2.6 and 2.9, respectively.)

...

From Christian, who helped me figure out what was going on: It looks pretty bad with libedit under non-macs. It's also not on our fedora7 machines. Under Solaris I did not find histedit.h

Surely http://www.thrysoee.dk/editline/libedit-20070831-2.10.tar.gz could be installed on the platforms or supplied with ghc as a static library. With libedit dynamically linked user programs will hardly run, though, on non-macs.

-Judah

Manuel M T Chakravarty

27 Jan 27 Jan

12:41 a.m.

Am 25.01.2008 um 03:44 schrieb Judah Jacobson:

...

On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty wrote:

...
Simon Marlow:

...
I think it would be a bad idea to provide EditReadline as described. The reason being that this would be a package with a variant license: its license is conditional on how it is built, which makes it that much harder for clients to understand what licensing restrictions apply, and to license themselves appropriately. (the alternative is to make EditReadline GPL, but that defeats the purpose).

I don't even think we've considered variant licenses in Cabal before, and my inclination would be to disallow or at least vigorously discourage it.

I don't like this either.

...
So I suggest we just keep readline as it is, and packages that want to use editline can switch at their discretion, using System.Console.Editline.Readline to make porting easier. In GHC I imagine we'll just switch to using editline.

That's fine if all platforms that by default have readline also have editline. I just checked, Fedora 8 does have both. How about other Linux distros? What is the situation on Solaris?

A few distros (including Solaris) have libedit version 1.*, which appears to be too old to provide enough functionality to replace readline. From what I can tell, libedit-1 provides the header , whereas libedit-2 provides as well as either or . (OS X 10.4 and 10.5 have 2.6 and 2.9, respectively.)

From Christian, who helped me figure out what was going on:

...
It looks pretty bad with libedit under non-macs. It's also not on our fedora7 machines. Under Solaris I did not find histedit.h

Surely http://www.thrysoee.dk/editline/libedit-20070831-2.10.tar.gz could be installed on the platforms or supplied with ghc as a static library. With libedit dynamically linked user programs will hardly run, though, on non-macs.

To summarise, * I don't think it is feasible to entirely drop readline from ghci (as some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't support sufficiently recent versions of editline). * We don't seem to want a package with a variant license plus might have trouble specifying one with Cabal. My conclusion: * The readline package stays as it is (stays GPL). * We add the new editline package (as a boot package) including Editline.Readline as the compatibility layer (is BSD3). * GHC uses configure magic to pick editline when available and readline otherwise. * Any other software can, at their discretion, choose to support only readline, or only editline, or use configure magic similar to GHC. This is a bit of extra hassle, but that may be a good thing as it forces developers to become aware of the licensing issues they get into. Simon, what do you think? Manuel

Duncan Coutts

7:25 a.m.

On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote:

...

To summarise,

* I don't think it is feasible to entirely drop readline from ghci (as some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't support sufficiently recent versions of editline).

Indeed. I tried to build the editline package that was just uploaded to hackage and discovered that Gentoo does not package the editline C library at all. Duncan

Duncan Coutts

6:45 p.m.

On Sun, 2008-01-27 at 12:25 +0000, Duncan Coutts wrote:

...

On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote:

...
To summarise,

* I don't think it is feasible to entirely drop readline from ghci (as some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't support sufficiently recent versions of editline).

Indeed. I tried to build the editline package that was just uploaded to hackage and discovered that Gentoo does not package the editline C library at all.

I spoke too soon. It is packaged as libedit (I was looking for editline). Duncan

Judah Jacobson

7:06 p.m.

On Jan 27, 2008 3:45 PM, Duncan Coutts wrote:

...

On Sun, 2008-01-27 at 12:25 +0000, Duncan Coutts wrote:

...
On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote:

...
To summarise,

* I don't think it is feasible to entirely drop readline from ghci (as some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't support sufficiently recent versions of editline).

Indeed. I tried to build the editline package that was just uploaded to hackage and discovered that Gentoo does not package the editline C library at all.

I spoke too soon. It is packaged as libedit (I was looking for editline).

I should probably note that on a few distros, the package named "editline" is the older, version 1.* of the library (which provides much less functionality), whereas "libedit" is version 2.* which is necessary for building my editline package. -Judah

Ian Lynagh

6:06 p.m.

On Sun, Jan 27, 2008 at 04:41:37PM +1100, Manuel M T Chakravarty wrote:

...

My conclusion:

* The readline package stays as it is (stays GPL).

I definitely agree with this.

...

* We add the new editline package (as a boot package) including Editline.Readline as the compatibility layer (is BSD3).

And this.

...

* GHC uses configure magic to pick editline when available and readline otherwise.

I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot. Thanks Ian

Bulat Ziganshin

6:19 p.m.

New subject: Re[2]: Integrating editline with ghc

Hello Ian, Monday, January 28, 2008, 2:06:33 AM, you wrote:

...

I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot.

plus it will mean that sometime, without any notice, you used gpl'ed software - this may add more headache for commercial developers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Manuel M T Chakravarty

9:23 p.m.

Ian Lynagh:

...

On Sun, Jan 27, 2008 at 04:41:37PM +1100, Manuel M T Chakravarty wrote:

...
My conclusion:

* The readline package stays as it is (stays GPL).

I definitely agree with this.

...
* We add the new editline package (as a boot package) including Editline.Readline as the compatibility layer (is BSD3).

And this.

...
* GHC uses configure magic to pick editline when available and readline otherwise.

I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot.

Sure if you want to add another library into the tree that's an option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/libedit on all platforms, it might be useful to make sure editline compiles fine everywhere. Manuel

Judah Jacobson

10:55 p.m.

On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote:

...

Ian Lynagh:

...
...
I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot.

Sure if you want to add another library into the tree that's an option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/libedit on all platforms, it might be useful to make sure editline compiles fine everywhere.

You may have seen this already, but it looks like libedit doesn't work on mingw: http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html However, we already don't use readline on mingw, right? So I don't think that should be a strike against using editline exclusively. Also, a small correction: both readline and libedit only need termcap, not curses (which provides a termcap interface). -Judah

Simon Marlow

28 Jan 28 Jan

4:31 a.m.

Judah Jacobson wrote:

...

On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote:

...
...
I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot. Sure if you want to add another library into the tree that's an

Ian Lynagh: option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/libedit on all platforms, it might be useful to make sure editline compiles fine everywhere.

You may have seen this already, but it looks like libedit doesn't work on mingw: http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html

However, we already don't use readline on mingw, right? So I don't think that should be a strike against using editline exclusively.

Right, we don't compile GHCi against readline on Windows. I have built the readline package on Windows in the past, and even managed to get GHCi working with it, but it seems the MingW I have installed right now doesn't come with readline. IIRC readline on Windows didn't work very well in a normal Windows console. Windows console users already get up/down and primitive editing facilities courtesy of the built-in console support anyway. Personally I'd like to drop readline, if we can. As Ian says, if we leave both options in place that's another configuration variable to test, and something else to go wrong. If it means we have to drag editline into the tree, then that's fine by me - I'm thinking of dragging in gcc's libffi too (it's not GPL, FYI), so we're building up a little family of imported external libraries. Cheers, Simon

Manuel M T Chakravarty

11:53 p.m.

Judah Jacobson:

...

On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote:

...
Ian Lynagh:

...
...
I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot.

Sure if you want to add another library into the tree that's an option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/ libedit on all platforms, it might be useful to make sure editline compiles fine everywhere.

You may have seen this already, but it looks like libedit doesn't work on mingw: http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html

However, we already don't use readline on mingw, right? So I don't think that should be a strike against using editline exclusively.

Ok, that simplifies matters.

...

Also, a small correction: both readline and libedit only need termcap, not curses (which provides a termcap interface).

At http://www.thrysoee.dk/editline/ it says to link with gcc -o fileman fileman.c -ledit -lcurses and explicitly says "Note libcurses, as well as libedit, should be linked to Editline enabled programs". Manuel

Judah Jacobson

29 Jan 29 Jan

12:10 a.m.

On Jan 28, 2008 8:53 PM, Manuel M T Chakravarty wrote:

...

Judah Jacobson:

...
On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote:

...
AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses.

...
Also, a small correction: both readline and libedit only need termcap, not curses (which provides a termcap interface).

At http://www.thrysoee.dk/editline/ it says to link with

gcc -o fileman fileman.c -ledit -lcurses

and explicitly says "Note libcurses, as well as libedit, should be linked to Editline enabled programs".

Oh, sorry; I didn't see that. But when I looked through the source code and configure/build files of libedit, it seemed like it only needs libtermcap. I suspect that despite what it says on that site, either "-ledit -lcurses" or "-ledit -ltermcap" will work fine. Anyway, this is probably a moot point; I don't know of any modern systems that have termcap but not curses. (For example, on my system libtermcap.a is a symlink to libncurses.a.) Best, -Judah

Yitzchak Gale

17 Jan 17 Jan

8:08 a.m.

Christian Maeder wrote:

...

The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!

I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline. -Yitz

Isaac Dupree

8:27 a.m.

Yitzchak Gale wrote:

...

Christian Maeder wrote:

...
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!

I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.

GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"? ~Isaac

Yitzchak Gale

11:52 a.m.

Isaac Dupree wrote:

...

GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend.

Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble.

...

On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"?

Yes, I also have a Debian box, and I agree. Regards, Yitz

Christian Maeder

9 a.m.

Yitzchak Gale wrote:

...

Christian Maeder wrote:

...
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!

I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.

Just to clarify: ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed). The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments). Also editline-ext should only be used rarely, because some installation will still only have "libreadline". The new haskell package "readline" will only contain the common functionality of libedit and libreadline! The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline) Christian

Yitzchak Gale

12:20 p.m.

Christian Maeder wrote:

...

ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed).

That is one possible solution for GHC. The problem is that the readline package currently provides System.Console.Readline with the full interface to readline. It has been that way for eons, so we must assume that there is software out there that uses all of it, even though ghc only uses part of it. We don't want to break those programs, and that includes creating a situation where the programs will no longer compile unless the user installs some new package with a different name. So I think the package named "readline" needs to continue to provide both the interface and the implementation for full readline. However, if needed, it can provide some or all of the pieces vacuously by simply depending on some new packages. On the other hand, GHC should depend only on a subset of readline that can optionally be provided by editline instead. And in fact, editline should be preferred over readline when available. There should be a smooth upgrade path to the new system for all users, both of GHC and the readline, for any combination of versions installed of any of those things. Everything should happen automatically as people gradually upgrade GHC and/or various readline-like packages to new versions. Can we meet all of those goals? Thanks, Yitz

Judah Jacobson

12:22 p.m.

On Jan 17, 2008 6:00 AM, Christian Maeder wrote:

...

Yitzchak Gale wrote:

...
Christian Maeder wrote:

...
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!

I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.

Just to clarify:

ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems).

Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed).

The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments).

Also editline-ext should only be used rarely, because some installation will still only have "libreadline".

The new haskell package "readline" will only contain the common functionality of libedit and libreadline!

The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline)

This sounds fine, except I don't think that we should have a package editline-ext. A readline API is either in both libedit and libreadline (in which case it should be in the readline package), or it is only in libreadline (in which case it should be in readline-ext). The functions in System.Console.Editline are unrelated to the readline APIs; I think that they should just go in a package called "editline". -Judah

Felix Martini

12:24 p.m.

On Jan 17, 2008 2:08 PM, Yitzchak Gale wrote:

...

I would hope that ghc will link to editline-ext on all platforms.

Unfortunately it seems that editline cannot currently be build on Windows. I have tried to build the editline source from http://www.thrysoee.dk/editline/ with MinGW/msys. Pdcurses could be used instead of ncurses, but it also requires termios.h which MinGW does not have.

Manuel M T Chakravarty

8:22 p.m.

Christian Maeder:

...

Judah Jacobson wrote:

...
- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).

I would like to see a restructuring of the old readline package:

1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?) Instead, we should have a new module whose interface coincides with editline's readline emulation. Everybody who wants to use editline when available and readline only if editline is not available can then use that new module (which I called EditReadline in my previous post). GHC will be one of these programs. Manuel

Christian Maeder

18 Jan 18 Jan

4:03 a.m.

Manuel M T Chakravarty wrote:

...

Christian Maeder:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)

Your point is also supported by Yitz Gale, my point by Malcolm. Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) Disadvantage of my proposal (to change the readline interface): We have restructured libraries massively between 6.2 and 6.8 (why not for 6.10?) Disadvantage of making a new interface: Everybody who wants to profit from libedit has to do active changes (so many will not bother, although most would want it.) Christian

Manuel M T Chakravarty

22 Jan 22 Jan

4:41 a.m.

Christian Maeder:

...

Manuel M T Chakravarty wrote:

...
Christian Maeder:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)

Your point is also supported by Yitz Gale, my point by Malcolm.

Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)

Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using? Manuel

Christian Maeder

4:52 a.m.

Manuel M T Chakravarty wrote:

...

Christian Maeder:

...
Manuel M T Chakravarty wrote:

...
Christian Maeder:

...
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)

Your point is also supported by Yitz Gale, my point by Malcolm.

Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)

Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using?

I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. Christian

Yitzchak Gale

6:40 a.m.

Christian Maeder wrote:

...

...
...
Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)

...

I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger.

Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate.

It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz

Christian Maeder

7:29 a.m.

Yitzchak Gale wrote:

...

We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing.

1. Things don't break silently (I hope), they break during compilation. 2. With every new ghc major version (or library version) there is a list of user visible changes. 3. if ghci is going to use editline (at least on Macs by default) then readline would not need to be a core package und users might need to install package readline explicitely. (Then at least everybody using readline has to do something manually, at least users on Macs who complain most if something does not run out of the box.)

...

Do you see any problem with that approach?

No, I've only pointed out the alternative, I hope. I don't know what fits the needs of the majority most. Let's vote? Christian

Yitzchak Gale

9:24 a.m.

Christian Maeder wrote:

...

3. if ghci is going to use editline... then readline would not need to be a core package und users might need to install package readline explicitly.

OK, I get it. Even if we leave readline as it is, so that the package system will theoretically not force the person to take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz

Malcolm Wallace

10:05 a.m.

...

I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before.

I think I am persuaded that this is the most important goal: stability of the API and package interface, for existing clients of readline. If individual projects would like to migrate from using readline to using editline, then those are the ones that should pay the small amount of pain (in using CPP, package configurations, etc) to manage the change. Anyone else should be totally unaffected. Regards, Malcolm

Christian Maeder

10:55 a.m.

Malcolm Wallace wrote:

...

I think I am persuaded that this is the most important goal: stability of the API and package interface, for existing clients of readline. If individual projects would like to migrate from using readline to using editline, then those are the ones that should pay the small amount of pain (in using CPP, package configurations, etc) to manage the change.

Anyone else should be totally unaffected.

I would like to know from package maintainers if there packages can be easily ported from libreadline to libedit. The best indication for this would be if the package is also happy with a restricted interface of readline (i.e. readline-compat) or requires the full GNU readline. At least testing this compatibility makes sense using a readline package with a temporarily reduced interface (without the need to change the packages depending on readline.) Christian

Christian Maeder

11:28 a.m.

(my previous mail went to the bugs list by accident) Christian Maeder wrote:

...

I would like to know from package maintainers if there packages can be easily ported from libreadline to libedit.

The best indication for this would be if the package is also happy with a restricted interface of readline (i.e. readline-compat) or requires the full GNU readline.

At least testing this compatibility makes sense using a readline package with a temporarily reduced interface (without the need to change the packages depending on readline.)

In short, consider a split up of the readline package into readline-basics and readline-exts (both with GPL licence). Unfortunately it is not possible to have the package readline to be the union of readline-basics and readline-exts. So readline-basic (or readline-compat) would be a duplication of a reduced readline package. For porting packages from libreadline to libedit it would be sufficient to replace readline-basics with editline (and change the licence) in *.cabal files. Packages depending on more then readline-basics cannot be ported. I'm only worried if any package maintainer would bother to change the build-depends from readline to readline-basic (if not forced to change it anyway, i.e. to readline-basic and readline-ext). Alternatively, if the interface of readline is reduced to that of readline-basic, package maintainers could hope that their package is still okay and if not (after compilation errors) add readline-ext to their build-depends. Is this really such a crazy idea? Christian

Judah Jacobson

18 Jan 18 Jan

12:09 p.m.

On Jan 17, 2008 1:19 AM, Christian Maeder wrote:

...

Judah Jacobson wrote:

...
- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).

I would like to see a restructuring of the old readline package:

1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.

2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext

A problem with the above proposal: the readline-ext package would depend not just on the readline package, but on an instance of the readline package that was built against libreadline specifically. I don't think that we can enforce that constraint; and even if we could, on a machine with both editline and readline installed it would get confusing pretty quickly. I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues. Best, -Judah

Christian Maeder

21 Jan 21 Jan

5:40 a.m.

Judah Jacobson wrote:

...

I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues.

Could then editline go already into ghc-6.8.3, because interfaces don't change? Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.) I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat). Which version of editline to you require? Our newest version installed (under Solaris) is: editline.h,v 1.5 Which include files are used on Macs? Cheers Christian

Yitzchak Gale

8:18 a.m.

Hi Christian, Christian Maeder wrote:

...

...Even better if the current package readline is renamed to old-readline and readline-compat to readline.

I have been trying to understand why you want to do that. What would we gain? Thanks, Yitz

Christian Maeder

9:13 a.m.

Yitzchak Gale wrote:

...

Hi Christian,

Christian Maeder wrote:

...
...Even better if the current package readline is renamed to old-readline and readline-compat to readline.

I have been trying to understand why you want to do that. What would we gain?

On Macs I want Shellac-readline to use editline, under linux we don't have editline, so there I want to continue to use Shellac-readline as it is now. But I don't want to use different Haskell packages for different platforms (for the same project). On Macs, the only change I had to make to the Shellac-readline package was to replace "readline >= 1.0" with "editline >= 0.1" in Shellac-readline.cabal and "System.Console.Readline" with "System.Console.Editline.Readline" in src/System/Console/Shell/Backend/Readline.hs These changes were not necessary if readline-compat supplied a module System.Console.Readline and would be named "readline". (A better name for old-readline would be GPL-readline, though) I wonder how many other packages would work without changes and how many would break, because readline-compat supplies only a part of the old readline. Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now). HTH Christian

Christian Maeder

10:22 a.m.

Christian Maeder wrote:

...

Depending on what the ghc team and the library maintainers decide, "readline" has to be changed to "readline-compat" in *.cabal

Maybe someone could point out how the conditional build-depends entry would look like in Shellac-readline.cabal if readline is to be used for older ghc versions (with GNU readline only) and readline-compat for newer ghcs (possible using editline). Will there be a new flag hasReadlineCompat? Cheers C.

Simon Marlow

10:54 a.m.

Christian Maeder wrote:

...

Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now).

It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job. In a similar vein, we should have an editline package that provides a binding to libedit. For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd. So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file. Cheers, Simon

Christian Maeder

12:10 p.m.

Simon Marlow wrote:

...

It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job.

I only want to move (not remove).

...

For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd.

Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado.

...

So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file.

Things ghc does not support, users have to do. Christian

Simon Marlow

22 Jan 22 Jan

6:52 a.m.

Christian Maeder wrote:

...

Simon Marlow wrote:

...
It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job.

I only want to move (not remove).

I don't think it's necessary to remove (or move) anything from readline at all. That would break clients unnecessarily. By all means add a new module that exports the lowest-common-denominator API.

...

...
For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd.

Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado.

But other people really do care about licenses, and it's vitally important that each package has a clearly-defined license. Under my proposal you would be able to do exactly what you want. The difference is that you can't hide the choice between libedit and libreadline in a package of its own, unless that package is GPL.

...

...
So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file.

Things ghc does not support, users have to do.

This isn't about GHC, it's about the readline/editline packages! Cheers, Simon

Judah Jacobson

21 Jan 21 Jan

12:35 p.m.

On Jan 21, 2008 2:40 AM, Christian Maeder wrote:

...

Judah Jacobson wrote:

...
I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues.

Could then editline go already into ghc-6.8.3, because interfaces don't change?

Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.)

Hmm...As Christian suggested to me in a private email, I was wrong in my initial testing of Shellac-readline: it relies on a variable (_history_max_entries) that is not in editline. So I think we should definitely keep the readline package the way that it is. Luckily, there are other functions, giving the same functionality, which are shared by readline and editline, and are scheduled to become official parts of readline in a week or two; see (http://www.nabble.com/Readline-read_history-and-write_history-addition-td149...) I'll add those functions to the editline and readline-compat packages.

...

I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat).

Which version of editline to you require?

Our newest version installed (under Solaris) is: editline.h,v 1.5

Which include files are used on Macs?

On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that. Thanks, -Judah

Christian Maeder

22 Jan 22 Jan

4:09 a.m.

Judah Jacobson wrote:

...

On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that.

I wasn't able to install your editline-0.1 package under Solaris. Our installed files are: /usr/local/lib/libeditline.so -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0 -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0.0.0 /usr/local/lib/libeditline.a /usr/local/lib/libeditline.la /usr/local/include/editline.h Christian checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init in -ledit... no checking for readline in -ledit... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes configure: error: editline not found, so this package cannot be built

6322

Age (days ago)

6335

Last active (days ago)

List overview

Download

48 comments

12 participants

participants (12)

Bulat Ziganshin
Christian Maeder
Don Stewart
Duncan Coutts
Felix Martini
Ian Lynagh
Isaac Dupree
Judah Jacobson
Malcolm Wallace
Manuel M T Chakravarty
Simon Marlow
Yitzchak Gale