Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
(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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
On Jan 17, 2008 1:19 AM, Christian Maeder [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Yitzchak Gale wrote: 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. Yes. I'm still learning Haskell, and it's my intention to use GHC to produce commercial plugins for an application on Windows (and possibly OS X, haven't decided yet). This whole discussion makes me worry - not because I have any intention to break any licences, but because I might do so by accident. At this point in my learning, I've got no idea what will cause problem packages (problems from my point of view being ones that cause a phone call to a lawyer) to be linked in to my binaries. It would be enormously helpful if there was a wiki page somewhere that said To use GHC/mingw as a compiler for commercial software, it's likely you want to avoid these modules and command-line flags or alternatively To guarantee that no LGPL or GPL libraries are linked, use these flags. The last thing I want is to cause myself extra work when someone chucks my plugin through a hex editor, sees a whole load of GMP symbols (for example) and demands some form of compliance that commercially I'd rather avoid. -- Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
On Jan 17, 2008 6:00 AM, Christian Maeder [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Alex Young: Yitzchak Gale wrote: 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. Yes. I'm still learning Haskell, and it's my intention to use GHC to produce commercial plugins for an application on Windows (and possibly OS X, haven't decided yet). This whole discussion makes me worry - not because I have any intention to break any licences, but because I might do so by accident. At this point in my learning, I've got no idea what will cause problem packages (problems from my point of view being ones that cause a phone call to a lawyer) to be linked in to my binaries. It would be enormously helpful if there was a wiki page somewhere that said To use GHC/mingw as a compiler for commercial software, it's likely you want to avoid these modules and command-line flags or alternatively To guarantee that no LGPL or GPL libraries are linked, use these flags. The last thing I want is to cause myself extra work when someone chucks my plugin through a hex editor, sees a whole load of GMP symbols (for example) and demands some form of compliance that commercially I'd rather avoid. The Haskell package system Cabal has a package description format that includes an entry stating the packages license. You can browse packages at http://hackage.haskell.org/packages/hackage.html and the package entries include the license field. For example, the entry for readline http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline-1.0.1.0 says it is GPL'ed - ie, you may not link it into proprietary code. I agree that a wiki page explaining this and the situation with static versus dynamic linking of LGPL'ed code would be helpful. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Hello, On Wednesday 16 January 2008 22:05, Judah Jacobson wrote: 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). Excellent! 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) That's the way. - 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. An alternative that would make the GHC configure script more symmetric with respect to command line editor would be to have --with-line-editor=editline, --with-line-editor=readline and also, perhaps, --with-line-editor=none (or even --with-line-editor=). All of these with, hopefully, obvious meanings. On top of this, one could have --with-edit-line=automatic with some automatic selection taking place. And the default? I'm sure that my favorite --with-line-editor=none will not be considered practical, so I will leave this most difficult choice to others. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah ... Thanks a lot again. Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
