Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Simon Marlow wrote: I think it's a good idea to avoid variant licenses, especially in libraries. We want it to be easy for someone to know whether they're complying with the licenses for the libraries they depend on, and if those licenses depend on choices made at the time the library was built, then it's much harder. Oh, I should add that ghci-bin (or whatever) is an application, not a library, so it's less of an issue for it to have a variant license. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Duncan Coutts wrote: On Fri, 2008-11-21 at 14:01 +, Simon Marlow wrote: I propose we do this: * extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package. This is good independently of the other suggestions. * Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies. I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies. Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it. Yes - I did some work on this, but didn't finish it. Unfortunately trying to shoehorn encodings into the IO library isn't pretty, and I became a bit disillusioned. I could probably still get it working, but I think I was really hoping that a better architecture for the IO library might emerge, and so far it didn't :-) > In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale). Right, this will certainly be possible when we have System.IO doing encoding/decoding, we just need to agree on an API. Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package? A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a "bad thing". I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file. I think it's a good idea to avoid variant licenses, especially in libraries. We want it to be easy for someone to know whether they're complying with the licenses for the libraries they depend on, and if those licenses depend on choices made at the time the library was built, then it's much harder. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sat, Nov 22, 2008 at 01:49:43PM +, Duncan Coutts wrote: > On Fri, 2008-11-21 at 14:01 +, Simon Marlow wrote: > > > * Move to Haskeline for the default build. We have to bring in terminfo > > and utf8-string as bootlibs. This gives us line-editing on Windows, > > and removes problematic external C library dependencies. > > I think this is worth trying. It seems like Judah is prepared to put the > work in to make haskeline work on various platforms and to trim the > dependencies. > > Eg I'd rather us decide what to do about Unicode input rather than just > end up de-facto standardising the utf8-string package. Right, if we're targetting this for 6.12 then there's no rush (and we have some time until 6.10.2, too, if we decide to change things for that). I think we should step back and think about whether utf8-string is the package that we're going to want to use for: * IO in the base libraries * The ptext function in Text.PrettyPrint * Implementing FastString on top of as we really want all of these to use the same library. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-21 at 14:01 +, Simon Marlow wrote: > I propose we do this: > > * extract the GHCi UI from the GHC package, put it in the ghc-bin package > (maybe we should rename this package to ghc-main or something). This > removes the editline and bytestring (for now) dependencies from the GHC > package. This is good independently of the other suggestions. > * Move to Haskeline for the default build. We have to bring in terminfo > and utf8-string as bootlibs. This gives us line-editing on Windows, > and removes problematic external C library dependencies. I think this is worth trying. It seems like Judah is prepared to put the work in to make haskeline work on various platforms and to trim the dependencies. Eg I'd rather us decide what to do about Unicode input rather than just end up de-facto standardising the utf8-string package. It seemed like we had a consensus on what to do for the H98 IO with Unicode. We just need to get on with it. In addition we need to agree some control over encoding when using a specific encoding is called for (eg reading a file that is known to be UTF-16 independent of the locale). > * Make it possible to compile the ghc-bin package against readline. > Upload ghc-bin to Hackage, so people can say >cabal install ghc-bin -f readline > and get a GHCi built against readline if they want. If haskeline "works" then I doubt there will be much pressure for readline support. The pining for the "good old days of readline" at the moment are only because editline clearly doesn't "work". [For some definition of "work"] > Oops - except that > this would mean that the ghc-main package has a variant license. So > maybe we have to have a separate ghc-readline package? A variant license isn't a fundamental technical problem though perhaps the consensus is that variant licenses are a "bad thing". I'm not sure. One would have to use OtherLicense and specify what the conditions are in the license file. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On 2008 Nov 21, at 9:01, Simon Marlow wrote:
* extract the GHCi UI from the GHC package, put it in the ghc-bin
package
(maybe we should rename this package to ghc-main or something).
This
removes the editline and bytestring (for now) dependencies from
the GHC
package.
* Move to Haskeline for the default build. We have to bring in
terminfo
and utf8-string as bootlibs. This gives us line-editing on Windows,
and removes problematic external C library dependencies.
* Make it possible to compile the ghc-bin package against readline.
Upload ghc-bin to Hackage, so people can say
cabal install ghc-bin -f readline
and get a GHCi built against readline if they want. Oops - except
that
this would mean that the ghc-main package has a variant license. So
maybe we have to have a separate ghc-readline package?
My humble opinion:
Dissociate ghc-bin and ghci from ghc; the latter is actually ghci-
{haskeline,readline,editline,noediting,...}. (Does cabal have virtual
packages yet?)
There is a corresponding library issue, though:
System.Console.Readline. I'd handle this by having packages which
export their own namespaces... but we'd like to have a generic
interface too so someone can write a program using any available
editing package. So, have the packages also output a module which is
by default hidden, and allow the user to select which one is used by
unhiding it. (This might lead to wanting additional cabal
functionality: "preferred" packages. Or maybe flags already handle
that well enough.)
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On 11/21/08, Simon Marlow <[EMAIL PROTECTED]> wrote: > > I propose we do this: > > * extract the GHCi UI from the GHC package, put it in the ghc-bin package > (maybe we should rename this package to ghc-main or something). This > removes the editline and bytestring (for now) dependencies from the GHC > package. > > * Move to Haskeline for the default build. We have to bring in terminfo > and utf8-string as bootlibs. > > This gives us line-editing on Windows, and removes problematic external C > library dependencies. Just so it's clear, Haskeline on POSIX does require (n)curses, an external C library, in order to access terminfo capabilities portably. But in my experience curses is much more widely available by default than readline or editline, so I still think this is a significant improvement. > * Make it possible to compile the ghc-bin package against readline. > Upload ghc-bin to Hackage, so people can say > cabal install ghc-bin -f readline > and get a GHCi built against readline if they want. Oops - except that > this would mean that the ghc-main package has a variant license. So > maybe we have to have a separate ghc-readline package? That sounds reasonable. As a side note, I'm very interested to learn of any more issues with Haskeline that would make it less preferable than the readline backend. -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
On Fri, Nov 21, 2008 at 2:27 AM, Simon Marlow <[EMAIL PROTECTED]> wrote: > Judah Jacobson wrote: >> >> On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: >>> >>> Although another option would be to make GHCi a separate (GPL) frontend >>> to the (BSD) GHC API. The only downside is that (with static linking) we >>> have another large binary. Another upside is that other GHC API users >>> don't get an editline dependency. >> >> I've actually been experimenting with something similar: >> >> darcs get http://code.haskell.org/~judah/ghci-haskeline/ >> >> If you have ghc-6.10.1, 'cabal install'ing inside that repo will give >> you a version of ghci which uses Haskeline as its backend. >> >> Basically, I copied 4 modules from the GHC source tree (GhciMonad, >> InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; >> the rest of GHC is obtained through the API. > > BTW, your LICENSE file looks like it was copied from the GHC source tree, it > still has various references to GHC and the University of Glasgow. The vast majority of code in that project is copied directly from the GHC source tree, and any changes I've made are intended to be merged back into GHC (or a ghci subproject); so I thought it easiest just to keep the code under the same license and copyright. Is there a better way to do this? -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On 11/21/08, Duncan Coutts <[EMAIL PROTECTED]> wrote: > On Fri, 2008-11-21 at 11:59 +0100, Philip K.F. Hölzenspies wrote: > > On Friday 21 November 2008 10:49:47 Jules Bean wrote: > > > > Something must be very very broken : surely it is not expected behaviour > > > for editline to need configuration in this way? > > > > One can call it broken, another will say users should settle for the default > > behaviour. Neither readline, nor editline *need* configuration this way, > > because they do come with sensible defaults. > > But that's just it. It seems that readline does come with sensible > defaults and editline does not. For example xterm is not a rare kind of > terminal (basically every terminal in use claims to be xterm) and yet > delete does not work with it out-of-the-box with editline. That is > broken. > > [To add insult to injury, even when I look up the escape sequence for > delete using the cat/telnet trick, I still cannot configure editline to > recognise it.] After further investigation, I think this technically isn't a terminal compatibility issue, but rather a missing feature; i.e., editline just doesn't intentionally support using the delete key. The command ed-delete-next-char which we found in the editrc manpage is really meant to represent pressing 'x' in the vi bindings, which is why it hasn't been working as expected. AFAICT, editline has no command equivalent to pressing 'delete'. Of course, regardless of the cause, the net result (delete key not working) is the same. I just wanted to point out that editline does use the same terminal capability libraries (termcap/terminfo) as readline, so there's no fundamental reason this couldn't be implemented portably other than (I'm guessing) the lack of motivation or time from its authors/contributors. -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
Hello, 2008/11/21 John O'Donnell <[EMAIL PROTECTED]>: > Simon says... > >> Could we reduce GHC's surface area by just using haskeline and dumping >> readline/editline support altogether? > > I'm in favor of doing this. For portability and consistency, it's better > to have just one version that is unencumbered by these license issues, > as long as it works on the main platforms (including Macintosh - has that > been tested?). It works very well on my Mac. Both tab completion of quoted filenames in Haskell expressions and of unicode identifiers works well. (It doesn't complete non-latin file names, but I can live with that.) I've also noticed that with haskeline one can type in ghci non-latin characters, as was the case before, with readline, but not anymore with editline. Hope it helps C.Chryssochoidis > If ghc tries to support both readline and editline, along > with haskeline, applications written in Haskell will have different > behaviours > depending on the combination (platform,line-editor). Better just to > simplify. > > John O'Donnell > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Simon > Peyton-Jones > Sent: Fri 2008-11-21 10:39 > To: Simon Marlow; Judah Jacobson > Cc: glasgow-haskell-users@haskell.org > Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - > EditLine / terminal incompatibility?) > > | > I've actually been experimenting with something similar: > | > > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ > > | > > | > Current benefits over the readline/editline versions: > | > - Works on Windows > | > | I can attest to that. Nice going Judah! > | > | $ cabal update > | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ > | $ cd ghci-haskeline > | $ cabal install > | > | and I have a GHCi on Windows that can do completion, history search, and > | exits when I hit ^D. That's made my day. > > If I had £1 for every email I've seen in the last decade about > platform-related or license-related problems with readline and now editline, > I'd be rich man. Super rich. > > Could we reduce GHC's surface area by just using haskeline and dumping > readline/editline support altogether? Yes that might reduce functionality > slightly -- readline/editline are complicated for good reasons. But it's > increase functionality in other ways (as Judah says), and by giving us one > piece of software that we understand, and can distribute with GHC, it might > remove a whole class of problems. > > Simon > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Hi Thorkil, On Nov 21, 2008, at 11:03 AM, Thorkil Naur wrote: Hello Greg, On Friday 21 November 2008 15:56, Gregory Wright wrote: ... ppc/ Leopard still fails, but I now have an account on a machine that I can use to test and debug. And if you need such an access (now or in the future), please just say the word and you can get access to my PPC Mac OS X 10.5 Leopard machine. ... Best regards Thorkil Thank you for your kind offer. I will likely take you up on it in the future. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
Simon says... > Could we reduce GHC's surface area by just using haskeline and dumping > readline/editline support altogether? I'm in favor of doing this. For portability and consistency, it's better to have just one version that is unencumbered by these license issues, as long as it works on the main platforms (including Macintosh - has that been tested?). If ghc tries to support both readline and editline, along with haskeline, applications written in Haskell will have different behaviours depending on the combination (platform,line-editor). Better just to simplify. John O'Donnell -Original Message- From: [EMAIL PROTECTED] on behalf of Simon Peyton-Jones Sent: Fri 2008-11-21 10:39 To: Simon Marlow; Judah Jacobson Cc: glasgow-haskell-users@haskell.org Subject: RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?) | > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had £1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Hello Greg, On Friday 21 November 2008 15:56, Gregory Wright wrote: > ... > ppc/ > Leopard still > fails, but I now have an account on a machine that I can use to test > and debug. And if you need such an access (now or in the future), please just say the word and you can get access to my PPC Mac OS X 10.5 Leopard machine. > ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Fri, Nov 21, 2008 at 7:04 AM, Christian Maeder <[EMAIL PROTECTED]> wrote: > Jason Dagit wrote: >> On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder >> <[EMAIL PROTECTED]> wrote: >>> Also note that gmp.h will not be found without: >>> >>> export CPATH=/opt/local/include >>> >>> This directory should be part of the "include-dirs:" for the rts >>> package. And again the file /opt/local/include/gmp.h could be simply >>> copied to /lib/ghc-6.10.1/include/ >> >> Hmm...Okay, so how do I add a path to include-dirs? In my case >> =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see >> any files I could modify to change it. > > I would suggest to only copy libgmp.a and gmp.h, because the file to > edit it /lib/ghc-6.10.1/package.conf. Search for (package) "rts" > and the fields "libraryDirs" and "includeDirs". But if you mess up this > file, all may be lost (so back it up first). I created a backup, then made the edits you suggested and the build failure I was seeing went away. Thanks! >> >> Was it an option I missed when I was doing the configure for the install? > > I'm not sure what configure options to pass (before my building or your > installing) Hopefully someone like Ian can comment here. Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Fri, Nov 21, 2008 at 6:56 AM, Gregory Wright <[EMAIL PROTECTED]> wrote: > > Hi Jason, > > On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote: > >> On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty >> <[EMAIL PROTECTED]> wrote: >>> >>> Jason Dagit: >>> >>> On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty >>> <[EMAIL PROTECTED]> wrote: Ian Lynagh: > > On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH > wrote: >> >> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>> >>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty >>> <[EMAIL PROTECTED]> wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. >> >> I expect if you used the OSX installer then /Library/Receipts is >> screwing you (it wipes the old files listed in the .bom file). Try >> finding and removing the receipt directory and bom file before >> installing. > > The only file I can see that looks relevant is > /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom > > Wouldn't removing it make uninstall impossible? > > In fact, if you did manage to get 2 versions installed, how would > /Library/Frameworks/GHC.framework/Tools/Uninstaller > know which version to uninstall? Wouldn't it only know how to uninstall > the version it came with? I'd suggest that the overlapping file > "Uninstaller" could be why the older version gets removed, but that > wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#//apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as "bundles": http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a "rm -rf /Library/Frameworks/GHC.framework/Versions/"). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a "rm -rf" as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). >>> >>> Is there an update on this thread? I would still like to have my cake >>> and >>> eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the >>> installer hasn't been updated and if I try again I will lose my copy of >>> 6.8.3. >>> >>> Sorry, but for the moment, my (rather limited knowledge) of the >>> MacOS packaging system is exhausted, and currently I don't have the time >>> to >>> search the web or experiment to try to learn more. It would be helpful >>> to >>> have the input of somebody who has more experience with MacOS packages. >>> Manuel >> >> Okay. That's fine, the OSX installer system sounds odd. I don't want >> to fight with it myself. I just want to upgrade ghc and I was getting >> pressure to do so and I tried the .tar.bz version, but I had some >> annoying experiences that I can share. >> >> So, the page here: >> http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxin
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Jason Dagit wrote: > On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder > <[EMAIL PROTECTED]> wrote: >> Also note that gmp.h will not be found without: >> >> export CPATH=/opt/local/include >> >> This directory should be part of the "include-dirs:" for the rts >> package. And again the file /opt/local/include/gmp.h could be simply >> copied to /lib/ghc-6.10.1/include/ > > Hmm...Okay, so how do I add a path to include-dirs? In my case > =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see > any files I could modify to change it. I would suggest to only copy libgmp.a and gmp.h, because the file to edit it /lib/ghc-6.10.1/package.conf. Search for (package) "rts" and the fields "libraryDirs" and "includeDirs". But if you mess up this file, all may be lost (so back it up first). > > Was it an option I missed when I was doing the configure for the install? I'm not sure what configure options to pass (before my building or your installing) > Thanks for making this package. I hope we can make the install easier > to understand and less error prone (fewer things to tweak locally). > > Thanks, > Jason Thanks, too Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Hi Jason, On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote: On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Jason Dagit: On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Ian Lynagh: On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. The only file I can see that looks relevant is /Library/Receipts/boms/ org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file "Uninstaller" could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as "bundles": http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a "rm -rf /Library/Frameworks/GHC.framework/Versions/"). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a "rm -rf" as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Sorry, but for the moment, my (rather limited knowledge) of the MacOS packaging system is exhausted, and currently I don't have the time to search the web or experiment to try to learn more. It would be helpful to have the input of somebody who has more experience with MacOS packages. Manuel Okay. That's fine, the OSX installer system sounds odd. I don't want to fight with it myself. I just want to upgrade ghc and I was getting pressure to do so and I tried the .tar.bz version, but I had some annoying experiences that I can share. So, the page here: http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel Has only this as installation instructions: This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/. I had no idea how to do the install or how to satisfy the requirements. By pestering others I learned that you install libraries into /opt/local using MacPorts. The next challenge was learning what to do with the .tar.bz file once it was downloaded. I found an INSTALL file inside the tarball with some instructions thankfully. I wish the download page said something
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Fri, Nov 21, 2008 at 6:10 AM, Christian Maeder <[EMAIL PROTECTED]> wrote: > Also note that gmp.h will not be found without: > > export CPATH=/opt/local/include > > This directory should be part of the "include-dirs:" for the rts > package. And again the file /opt/local/include/gmp.h could be simply > copied to /lib/ghc-6.10.1/include/ Hmm...Okay, so how do I add a path to include-dirs? In my case =$HOME, so I looked under ~/lib/ghc-6.10.1 and I didn't see any files I could modify to change it. Was it an option I missed when I was doing the configure for the install? Thanks for making this package. I hope we can make the install easier to understand and less error prone (fewer things to tweak locally). Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Also note that gmp.h will not be found without: export CPATH=/opt/local/include This directory should be part of the "include-dirs:" for the rts package. And again the file /opt/local/include/gmp.h could be simply copied to /lib/ghc-6.10.1/include/ Sorry for the trouble Christian Christian Maeder wrote: > Jason Dagit wrote: >> But, I still think I did something wrong because the first thing I >> tried to build with 6.10 complained that -lgmp was not found. I have >> checked, it's installed and I saw the ./configure script for the 6.10 >> installation find it. > > Actually I have the same problem. I need to set > > export LIBRARY_PATH=/opt/local/lib > > when linking, because I've created the binary-dist with this setting. > > Ideally, /opt/local/lib should also be listed under "library-dirs:" for > > ghc-pkg describe rts > > Alternatively, you can copy /opt/local/lib/libgmp.a into ghc's libdir > /lib/ghc-6.10.1/, with the additional "benefit" that gmp is > statically linked into your binary (for platforms without > /opt/local/lib/libgmp.dylib) > > Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Duncan Coutts wrote: On Thu, 2008-11-20 at 12:51 +, Simon Marlow wrote: Duncan Coutts wrote: What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach. One downside I can see is that it gives us an extra configuration to test and maintain. It's hard enough keeping one line-editing binding working, let alone two! It's true that editline seems to have brought a bunch of headaches with it, though. Perhaps Haskelline is the way to go in the future. My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration. I get the feeling they don't care about if it works well, just that it's got the license they want (which is a perfectly reasonable position). I propose we do this: * extract the GHCi UI from the GHC package, put it in the ghc-bin package (maybe we should rename this package to ghc-main or something). This removes the editline and bytestring (for now) dependencies from the GHC package. * Move to Haskeline for the default build. We have to bring in terminfo and utf8-string as bootlibs. This gives us line-editing on Windows, and removes problematic external C library dependencies. * Make it possible to compile the ghc-bin package against readline. Upload ghc-bin to Hackage, so people can say cabal install ghc-bin -f readline and get a GHCi built against readline if they want. Oops - except that this would mean that the ghc-main package has a variant license. So maybe we have to have a separate ghc-readline package? Ok? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Jason Dagit wrote: > But, I still think I did something wrong because the first thing I > tried to build with 6.10 complained that -lgmp was not found. I have > checked, it's installed and I saw the ./configure script for the 6.10 > installation find it. Actually I have the same problem. I need to set export LIBRARY_PATH=/opt/local/lib when linking, because I've created the binary-dist with this setting. Ideally, /opt/local/lib should also be listed under "library-dirs:" for ghc-pkg describe rts Alternatively, you can copy /opt/local/lib/libgmp.a into ghc's libdir /lib/ghc-6.10.1/, with the additional "benefit" that gmp is statically linked into your binary (for platforms without /opt/local/lib/libgmp.dylib) Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: > Jason Dagit: > > On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty > <[EMAIL PROTECTED]> wrote: >> >> Ian Lynagh: >>> >>> On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: > > On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty > <[EMAIL PROTECTED]> wrote: >> >> Are you sure it does deinstall the 6.8 compiler? >> >> After installing 6.10, there should be a 608/ and a 610/ >> directory. This >> certainly happens on my Mac and I am not aware of an option to >> change that >> behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. >>> >>> The only file I can see that looks relevant is >>> /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >>> >>> Wouldn't removing it make uninstall impossible? >>> >>> In fact, if you did manage to get 2 versions installed, how would >>> /Library/Frameworks/GHC.framework/Tools/Uninstaller >>> know which version to uninstall? Wouldn't it only know how to uninstall >>> the version it came with? I'd suggest that the overlapping file >>> "Uninstaller" could be why the older version gets removed, but that >>> wouldn't explain why Manuel can install both at once. >> >> A current limitation of the MacOS package system is that it does not >> support uninstalling of packages; cf >> >> >> >> http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#//apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 >> >> This is not a big drama on MacOS, as MacOS encourages the distribution of >> software packages as "bundles": >> >> >> >> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html >> >> This essentially means that instead of sprinkling files all over the file >> system (as is common in other OSes), MacOS applications and frameworks >> (Mac-speak for libraries) are kept in a single directory. Uninstalling then >> means doing an rm -rf on that directory. >> >> Unfortunately, some applications (including GHC and Apple's Xcode IDE) >> can't be entirely contained in a single directory. In the case of GHC, we >> want symlinks in /usr/bin. The established way of uninstalling such >> applications is by supplying an Uninstaller script, just as I did for GHC. >> (Apple does the same for Xcode.) >> >> The purpose of the Uninstaller script is too completely remove >> GHC.framework from a machine - not just to remove one version. In fact, if >> more than one version of GHC is installed, the Uninstaller will refuse to >> run and require the manual removal of all versions, but the current (easily >> achieved by a "rm -rf >> /Library/Frameworks/GHC.framework/Versions/"). The main feature of >> the Uninstaller script is to get rid of all symlinks pointing into >> GHC.framework. The framework itself is just deleted by a "rm -rf" as >> expected. (It also removes the above mentioned receipt file.) >> >> So, to directly answer the above questions: >> * The package manger (which uses the receipts) can't uninstall and the >> uninstaller script doesn't need the receipt. So, even after deleteing the >> receibt, you can still uninstall. >> * The Uninstaller can uninstall any version (at least as long as no >> symlinks are put into new directories outside of the bundle that the >> Uninstaller doesn't know about). > > Is there an update on this thread? I would still like to have my cake and > eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the > installer hasn't been updated and if I try again I will lose my copy of > 6.8.3. > > Sorry, but for the moment, my (rather limited knowledge) of the > MacOS packaging system is exhausted, and currently I don't have the time to > search the web or experiment to try to learn more. It would be helpful to > have the input of somebody who has more experience with MacOS packages. > Manuel Okay. That's fine, the OSX installer system sounds odd. I don't want to fight with it myself. I just want to upgrade ghc and I was getting pressure to do so and I tried the .tar.bz version, but I had some annoying experiences that I can share. So, the page here: http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel Has only this as installation instructions: This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and libgmp.3.dylib under /opt/local/lib/. I had no idea how to do the install or how to satisfy the requirements. By pestering others I learned that you install libraries into /opt/local using MacPorts. The next challenge was learning
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-21 at 11:59 +0100, Philip K.F. Hölzenspies wrote: > On Friday 21 November 2008 10:49:47 Jules Bean wrote: > > Something must be very very broken : surely it is not expected behaviour > > for editline to need configuration in this way? > > One can call it broken, another will say users should settle for the default > behaviour. Neither readline, nor editline *need* configuration this way, > because they do come with sensible defaults. But that's just it. It seems that readline does come with sensible defaults and editline does not. For example xterm is not a rare kind of terminal (basically every terminal in use claims to be xterm) and yet delete does not work with it out-of-the-box with editline. That is broken. [To add insult to injury, even when I look up the escape sequence for delete using the cat/telnet trick, I still cannot configure editline to recognise it.] > However, some people want custom behaviour and they'll have to figure > out how stuff works for their machine. That's a different matter. Most people have never configured anything custom and just want the common basics to work. In fact most linux users have never looked at a readline man page and don't know what an escape sequence is. It has to work right for the users who do not know that it is possible to configure, otherwise they will call it broken. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Philip K.F. Hölzenspies wrote: On Friday 21 November 2008 10:49:47 Jules Bean wrote: Philip Hölzenspies wrote: Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose. But this is abhorrent. The whole point of the existence of termcap and libraries which build upon it (ncurses, readline, editline, etc) is so that individual users do not have to work out what the escape sequences produced by their terminal are. Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way? One can call it broken, another will say users should settle for the default behaviour. Neither readline, nor editline *need* configuration this way, because they do come with sensible defaults. However, some people want custom behaviour and they'll have to figure out how stuff works for their machine. And suppose I log on from another machine with a different TERM setting? or just use a different terminal program? This is broken. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Friday 21 November 2008 10:49:47 Jules Bean wrote: > Philip Hölzenspies wrote: > > Also, there are no de facto escape sequences, because special keys (like > > function and arrow keys) have different sequences on different > > terminals. A useful tip that may be useful to include in the wiki is an > > easy trick that will help you find out your terminals escape sequences. > > I usually just like to start an application that has no editline or > > readline capabilities and press the keys. Telnet is one of my favorite > > applications for this purpose. > > But this is abhorrent. > > The whole point of the existence of termcap and libraries which build > upon it (ncurses, readline, editline, etc) is so that individual users > do not have to work out what the escape sequences produced by their > terminal are. > > Something must be very very broken : surely it is not expected behaviour > for editline to need configuration in this way? One can call it broken, another will say users should settle for the default behaviour. Neither readline, nor editline *need* configuration this way, because they do come with sensible defaults. However, some people want custom behaviour and they'll have to figure out how stuff works for their machine. I think a sensible purpose of a Wiki is to help people get some of the more tricky business done. Also, I don't see what is wrong with typing in terms of escape sequences per se, but for those that have something against it; there's bound to be some program somewhere that will allow you to type instead of ^[[A. The upside of the telnet tip, is that it works on many *NIXs and their derivatives. It even works on OSX, so it's a one-size-fits-(almost)-all tip. Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
| > I've actually been experimenting with something similar: | > | > darcs get http://code.haskell.org/~judah/ghci-haskeline/ | > | > Current benefits over the readline/editline versions: | > - Works on Windows | | I can attest to that. Nice going Judah! | | $ cabal update | $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ | $ cd ghci-haskeline | $ cabal install | | and I have a GHCi on Windows that can do completion, history search, and | exits when I hit ^D. That's made my day. If I had £1 for every email I've seen in the last decade about platform-related or license-related problems with readline and now editline, I'd be rich man. Super rich. Could we reduce GHC's surface area by just using haskeline and dumping readline/editline support altogether? Yes that might reduce functionality slightly -- readline/editline are complicated for good reasons. But it's increase functionality in other ways (as Judah says), and by giving us one piece of software that we understand, and can distribute with GHC, it might remove a whole class of problems. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
Judah Jacobson wrote: On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency. I've actually been experimenting with something similar: darcs get http://code.haskell.org/~judah/ghci-haskeline/ If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend. Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API. Current benefits over the readline/editline versions: - Works on Windows I can attest to that. Nice going Judah! $ cabal update $ darcs get http://code.haskell.org/~judah/ghci-haskeline/ $ cd ghci-haskeline $ cabal install and I have a GHCi on Windows that can do completion, history search, and exits when I hit ^D. That's made my day. BTW, your LICENSE file looks like it was copied from the GHC source tree, it still has various references to GHC and the University of Glasgow. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Philip Hölzenspies wrote: On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Dear Simon, all, I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes. For example, aside from the word-jumping Duncan suggested, I alway use zsh-like history searching, so I like: bind "^[[A" ed-search-prev-history bind "^[[B" ed-search-next-history Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose. But this is abhorrent. The whole point of the existence of termcap and libraries which build upon it (ncurses, readline, editline, etc) is so that individual users do not have to work out what the escape sequences produced by their terminal are. Something must be very very broken : surely it is not expected behaviour for editline to need configuration in this way? Jules ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci-haskeline (was: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?)
On Thu, Nov 20, 2008 at 7:16 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: > > Although another option would be to make GHCi a separate (GPL) frontend > to the (BSD) GHC API. The only downside is that (with static linking) we > have another large binary. Another upside is that other GHC API users > don't get an editline dependency. I've actually been experimenting with something similar: darcs get http://code.haskell.org/~judah/ghci-haskeline/ If you have ghc-6.10.1, 'cabal install'ing inside that repo will give you a version of ghci which uses Haskeline as its backend. Basically, I copied 4 modules from the GHC source tree (GhciMonad, InteractiveUI, GhciTags and Main) and modifed them to use Haskeline; the rest of GHC is obtained through the API. Current benefits over the readline/editline versions: - Works on Windows - Tab completion of quoted filenames within Haskell expressions - Tab completion of Unicode identifiers (trac #2058) - Internally, eliminates the need for some GLOBAL_VARs The only real regression I'm aware of is that Haskeline doesn't yet provide a way to "bind" custom key commands as in an inputrc or editrc file. The recent discussion has indicated how important that feature is for some users, so it's next on my TODO list. -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Thu, Nov 20, 2008 at 06:43:49PM +, Duncan Coutts wrote: > On Thu, 2008-11-20 at 15:16 +, Ian Lynagh wrote: > > On Thu, Nov 20, 2008 at 01:52:12PM +, Duncan Coutts wrote: > > > > > > My selfish suggestion is that we maintain the readline configuration and > > > let the people who originally wanted editline support do the work to > > > maintain that configuration. > > > > Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to > > be BSD then it can't use it. > > It's not quite that simple. GHC HQ does not ship readline, it's just > shipping BSD code. If I link ghc against readline then the result must > be distributed in compliance with the GPL, but that's ok, all linux > distros do that. When GHC HQ ship binaries they can configure it to use > editline. OK, so I should have said "... it can't use it exclusively". But it's still GHC HQ that needs editline support (or a switch to haskeline, or splitting ghci off, or some other solution. But just reverting to readline-only won't work). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Thu, 2008-11-20 at 15:16 +, Ian Lynagh wrote: > On Thu, Nov 20, 2008 at 01:52:12PM +, Duncan Coutts wrote: > > > > My selfish suggestion is that we maintain the readline configuration and > > let the people who originally wanted editline support do the work to > > maintain that configuration. > > Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to > be BSD then it can't use it. It's not quite that simple. GHC HQ does not ship readline, it's just shipping BSD code. If I link ghc against readline then the result must be distributed in compliance with the GPL, but that's ok, all linux distros do that. When GHC HQ ship binaries they can configure it to use editline. If someone (even GHC HQ) ships BSD code and GPL code linked together then that doesn't mean that suddenly the BSD code has to be re-licensed, it just means the overall result has to be shipped in a way that is compliant with the GPL (ie providing source and providing a copy of the GPL for the GPL components). I presume this already happens in the windows installer that includes gcc etc. > Although another option would be to make GHCi a separate (GPL) frontend > to the (BSD) GHC API. The only downside is that (with static linking) we > have another large binary. Another upside is that other GHC API users > don't get an editline dependency. Yes, independently of licence issues there's no need for the ghc api package to depend on any line editor. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Thu, Nov 20, 2008 at 01:52:12PM +, Duncan Coutts wrote: > > My selfish suggestion is that we maintain the readline configuration and > let the people who originally wanted editline support do the work to > maintain that configuration. Those people are GHC HQ: readline is GPL (not LGPL), so if GHC wants to be BSD then it can't use it. Although another option would be to make GHCi a separate (GPL) frontend to the (BSD) GHC API. The only downside is that (with static linking) we have another large binary. Another upside is that other GHC API users don't get an editline dependency. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Thu, 2008-11-20 at 12:51 +, Simon Marlow wrote: > Duncan Coutts wrote: > > What I really think is that we should add back optional readline > > support. People building closed source ghc binaries would not use it but > > linux distros could enable it and provide a better "out of the box" > > experience. As I understand it there would be no licencing problems with > > that approach. > > One downside I can see is that it gives us an extra configuration to test > and maintain. It's hard enough keeping one line-editing binding working, > let alone two! > > It's true that editline seems to have brought a bunch of headaches with it, > though. Perhaps Haskelline is the way to go in the future. My selfish suggestion is that we maintain the readline configuration and let the people who originally wanted editline support do the work to maintain that configuration. I get the feeling they don't care about if it works well, just that it's got the license they want (which is a perfectly reasonable position). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Duncan Coutts wrote: On Wed, 2008-11-19 at 20:45 +0100, Philip Hölzenspies wrote: On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Dear Simon, all, I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes. I don't have any particular wishes. I just want it to "work" where "work" means does what the rest of my system does. I never configured readline, it came with sensible defaults (possibly set by my linux system distributor). What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach. One downside I can see is that it gives us an extra configuration to test and maintain. It's hard enough keeping one line-editing binding working, let alone two! It's true that editline seems to have brought a bunch of headaches with it, though. Perhaps Haskelline is the way to go in the future. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Wed, 2008-11-19 at 20:45 +0100, Philip Hölzenspies wrote: > On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: > > Would it be worth adding this hard-won lore somewhere on a Wiki > > where it can be found later? > > Dear Simon, all, > > I don't think logging a specific option on the Wiki is particularly > useful (maybe you would have a default editrc file), because, of > course, everybody has their own particular wishes. I don't have any particular wishes. I just want it to "work" where "work" means does what the rest of my system does. I never configured readline, it came with sensible defaults (possibly set by my linux system distributor). What I really think is that we should add back optional readline support. People building closed source ghc binaries would not use it but linux distros could enable it and provide a better "out of the box" experience. As I understand it there would be no licencing problems with that approach. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Philip Hölzenspies wrote: Something that I would personally very much enjoy is a clear and unmistakable warning from configure when editline is not found. After installing libedit-devel (my ghci-6.10.1 finally has comfortable editing now), I checked config.log; there's not even a mention of libedit capabilities. Maybe a general summary at the end of configure of all the optional capabilities that were or were not configured. As an inspiration, look at gtk2hs' configure output. Good idea - I've added it to the list of things to do in the new build system. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Nov 19, 2008, at 6:25 PM, Simon Peyton-Jones wrote: Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Dear Simon, all, I don't think logging a specific option on the Wiki is particularly useful (maybe you would have a default editrc file), because, of course, everybody has their own particular wishes. For example, aside from the word-jumping Duncan suggested, I alway use zsh-like history searching, so I like: bind "^[[A" ed-search-prev-history bind "^[[B" ed-search-next-history Also, there are no de facto escape sequences, because special keys (like function and arrow keys) have different sequences on different terminals. A useful tip that may be useful to include in the wiki is an easy trick that will help you find out your terminals escape sequences. I usually just like to start an application that has no editline or readline capabilities and press the keys. Telnet is one of my favorite applications for this purpose. Something that I would personally very much enjoy is a clear and unmistakable warning from configure when editline is not found. After installing libedit-devel (my ghci-6.10.1 finally has comfortable editing now), I checked config.log; there's not even a mention of libedit capabilities. Maybe a general summary at the end of configure of all the optional capabilities that were or were not configured. As an inspiration, look at gtk2hs' configure output. Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Would it be worth adding this hard-won lore somewhere on a Wiki where it can be found later? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Duncan Coutts | Sent: 07 November 2008 18:09 | To: GHC-users list | Cc: Philip K.F. Hölzenspies | Subject: Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility? | | On Fri, 2008-11-07 at 09:14 -0800, Judah Jacobson wrote: | > On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts | > <[EMAIL PROTECTED]> wrote: | > > | > > I get some working and some non-working. Eg backspace, del, home, end | > > work, but the ctl-left/ctl-right to jump words does not. | > > | > > Does anyone know how libedit is supposed to be configured? readline | > > uses /etc/inputrc but libedit either does not or doesn't understand all | > > of it. | > > | > > /me wonders if it was really necessary to switch from readline | > > | > > Duncan | > | > You can configure libedit with a ~/.editrc file. | > | > http://www.manpagez.com/man/5/editrc/ | | Thanks Judah. | | To save everyone else having to read the man page and working out | through trial and error what the key escape codes are, add the following | to your ~/.editrc file. | | # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving | bind "\e[1;5D" vi-prev-word | bind "\e[1;5C" vi-next-word | | (though from reading the readline /etc/inputrc it suggests that "\e[5C" | and "\e[5D" might be right on some systems) | | It's unfortunate that editline does not seem to support any | global /etc/editrc file which would enable distros to make it do the | right thing by default like they do for readline. | | Duncan | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Jason Dagit: On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty <[EMAIL PROTECTED] > wrote: Ian Lynagh: On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. The only file I can see that looks relevant is /Library/Receipts/boms/ org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file "Uninstaller" could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as "bundles": http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a "rm -rf /Library/Frameworks/ GHC.framework/Versions/"). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a "rm -rf" as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Sorry, but for the moment, my (rather limited knowledge) of the MacOS packaging system is exhausted, and currently I don't have the time to search the web or experiment to try to learn more. It would be helpful to have the input of somebody who has more experience with MacOS packages. Manuel___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty <[EMAIL PROTECTED] > wrote: > Ian Lynagh: > > On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: >> >>> On 2008 Nov 4, at 20:26, Jason Dagit wrote: >>> On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: > > Are you sure it does deinstall the 6.8 compiler? > > After installing 6.10, there should be a 608/ and a 610/ > directory. This > certainly happens on my Mac and I am not aware of an option to > change that > behaviour. > >>> I expect if you used the OSX installer then /Library/Receipts is >>> screwing you (it wipes the old files listed in the .bom file). Try >>> finding and removing the receipt directory and bom file before >>> installing. >>> >> >> The only file I can see that looks relevant is >> /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom >> >> Wouldn't removing it make uninstall impossible? >> >> In fact, if you did manage to get 2 versions installed, how would >> /Library/Frameworks/GHC.framework/Tools/Uninstaller >> know which version to uninstall? Wouldn't it only know how to uninstall >> the version it came with? I'd suggest that the overlapping file >> "Uninstaller" could be why the older version gets removed, but that >> wouldn't explain why Manuel can install both at once. >> > > A current limitation of the MacOS package system is that it does not > support uninstalling of packages; cf > > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ > /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 > > This is not a big drama on MacOS, as MacOS encourages the distribution of > software packages as "bundles": > > > http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html > > This essentially means that instead of sprinkling files all over the file > system (as is common in other OSes), MacOS applications and frameworks > (Mac-speak for libraries) are kept in a single directory. Uninstalling then > means doing an rm -rf on that directory. > > Unfortunately, some applications (including GHC and Apple's Xcode IDE) > can't be entirely contained in a single directory. In the case of GHC, we > want symlinks in /usr/bin. The established way of uninstalling such > applications is by supplying an Uninstaller script, just as I did for GHC. > (Apple does the same for Xcode.) > > The purpose of the Uninstaller script is too completely remove > GHC.framework from a machine - not just to remove one version. In fact, if > more than one version of GHC is installed, the Uninstaller will refuse to > run and require the manual removal of all versions, but the current (easily > achieved by a "rm -rf > /Library/Frameworks/GHC.framework/Versions/"). The main feature of > the Uninstaller script is to get rid of all symlinks pointing into > GHC.framework. The framework itself is just deleted by a "rm -rf" as > expected. (It also removes the above mentioned receipt file.) > > So, to directly answer the above questions: > * The package manger (which uses the receipts) can't uninstall and the > uninstaller script doesn't need the receipt. So, even after deleteing the > receibt, you can still uninstall. > * The Uninstaller can uninstall any version (at least as long as no > symlinks are put into new directories outside of the bundle that the > Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1
Magicloud wrote: Hi, It is a few days after the release. But why the darcs repos of 6.10 is still changing? The 6.10 repo is a branch. We tagged the 6.10.1 release, and we're now working towards a 6.10.2 release. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1
Hi, It is a few days after the release. But why the darcs repos of 6.10 is still changing? Ian Lynagh wrote: == The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Some new language features have been implemented: * Record syntax: wild-card patterns, punning, and field disambiguation * Generalised quasi-quotes * Generalised list comprehensions * View patterns * Type families have been completely re-implemented * Now comes with Haddock 2, which supports all GHC extensions * Parallel garbage collection * Base provides extensible exceptions * The GHC API is easier to use * External core (output only) now works again * Data Parallel Haskell (DPH) comes as part of GHC The full release notes are here: http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Mon, Nov 10, 2008 at 10:39:42AM -0800, Judah Jacobson wrote: > On Sun, Nov 9, 2008 at 11:03 AM, Don Stewart <[EMAIL PROTECTED]> wrote: > > judah.jacobson: > >> > > >> > Note that haskeline has a lot of dependencies and requires > >> > TemplateHaskell and many other language extensions. > >> > >> I'm also somewhat wary of switching to haskeline in ghc-6.10. I think > >> these issues could be resolved in time for 6.12, though: > > > > haskeline needs /way/ too many extensions for a simple console reader... > > Well, even though the external API of a line reader may look simple, > under the hood there can be a lot going on I don't think extensions are an issue for ghci, except for TH (which you say can be replaced). They doesn't even cause extra problems for bootstrapping with other Haskell impls, as it's stage >= 2 only. Extra package dependencies are a pain, but aren't the end of the world. The big thing, in my opinion, is portability - not in the sense of the code compiling, but in the sense of "will the arrow keys Just Work if I run ghci in, say, an rxvt on a Solaris machine"? Although it seems like editline fails this anyway, even for the common case of xterm/Linux. Haskell code would also cause fewer build system headaches than linking to a C library. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sun, Nov 9, 2008 at 11:03 AM, Don Stewart <[EMAIL PROTECTED]> wrote: > judah.jacobson: >> > >> > Note that haskeline has a lot of dependencies and requires >> > TemplateHaskell and many other language extensions. >> >> I'm also somewhat wary of switching to haskeline in ghc-6.10. I think >> these issues could be resolved in time for 6.12, though: > > haskeline needs /way/ too many extensions for a simple console reader... Well, even though the external API of a line reader may look simple, under the hood there can be a lot going on, both in the user interface (e.g. user preferences, multiple key bindings, history recall/search, undo/redo, tab completion) and backend (e.g. redraw efficiently, cross-platform compatibility). Using a stack of monad transformers to encapsulate the state and settings helped make the code much more modular, understandable and concise, but also required several type extensions to work the way I wanted (MultiParamTypeClasses, OverlappingInstances, FlexibleContexts, etc.). I felt the tradeoff was worth it when originally writing the code, but patches or suggestions are, of course, welcome :-) (Incidentally, the .cabal file in haskeline-3.2 erroneously lists GADTs and FunDeps which are not actually required; those extensions will be removed for the next release.) Best, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
judah.jacobson: > On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts > <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-11-09 at 01:49 +, Ian Lynagh wrote: > >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > >> > > >> > bind "\e[3~" ed-delete-next-char > >> > >> It's a shame this doesn't just work out of the box in an xterm, on > >> Debian at least. Perhaps we should consider switching to haskeline? Do > >> we know anything about how portable and complete that is? > > > > If we're considering that I think we should consider bringing back > > readline as an option and let the people who have problems with gpl code > > configure in editline support instead. > > > > Note that haskeline has a lot of dependencies and requires > > TemplateHaskell and many other language extensions. > > I'm also somewhat wary of switching to haskeline in ghc-6.10. I think > these issues could be resolved in time for 6.12, though: haskeline needs /way/ too many extensions for a simple console reader... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts <[EMAIL PROTECTED]> wrote: > On Sun, 2008-11-09 at 01:49 +, Ian Lynagh wrote: >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: >> > >> > bind "\e[3~" ed-delete-next-char >> >> It's a shame this doesn't just work out of the box in an xterm, on >> Debian at least. Perhaps we should consider switching to haskeline? Do >> we know anything about how portable and complete that is? > > If we're considering that I think we should consider bringing back > readline as an option and let the people who have problems with gpl code > configure in editline support instead. > > Note that haskeline has a lot of dependencies and requires > TemplateHaskell and many other language extensions. I'm also somewhat wary of switching to haskeline in ghc-6.10. I think these issues could be resolved in time for 6.12, though: 1) Completeness: IMHO as the package author, haskeline already has enough features and cross-platform compatibility to warrant its use by ghci. (The full feature-list is at http://trac.haskell.org/haskeline/ .) 2) Language extensions: Since ghci is only ever built in stage 2 (and never by the bootstrapping compiler), the language extensions should not be an issue. The only exception is TemplateHaskell, as Duncan mentioned, since it cannot be used by a stage 1 compiler. But TH is limited to one function in one module and could be easily replaced either by hard-coding the generated code or by using syb. (Some other extensions may also no longer be necessary: I haven't checked recently). 3) Dependencies: Outside of ghc's bootlibs, haskeline depends on mtl and stm (which are extralibs), terminfo (which is only used on POSIX), and utf8-string. - utf8-string should not be needed when unicode text I/O is implemented for ghc-6.12, as mentioned in http://hackage.haskell.org/trac/ghc/wiki/Status/October08 - terminfo is a lightweight binding to a foreign library (ncurses, really) and could either be added to the bootlibs (my preference) or folded into the haskeline package. - stm: I don't see why this couldn't also be a bootlib, although if necessary I can investigate using MVar-based concurrency instead. - mtl: haskeline uses MonadTrans and MonadIO from that package, which ghc reimplements internally. I'm not sure of the right thing to do here. -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminalincompatibility?
On Sun, 2008-11-09 at 14:59 +, Claus Reinke wrote: > Talking about dependencies of cabal packages: > > - some packages depend on everything and the kitchen-sink, > following the "ah, great, here's another package I should use" > idea of what it means to provide a modern haskell package. > > It would be nice if package authors would consider separate minimal > and extended dependencies, the former sufficient to enable the package > functionality, the latter enabled by a flag, and only needed for testing > frameworks, parser re-generation, convenience, performance, .. That's fine so long as it does not change the external api of a package. > - since Duncan has put in the work for making meta-packages possible > for the Haskell Platform anyway, couldn't that be used to group typical > dependencies together (eg, ghc corelibs, old extralibs, haskell platform, > testing, ..), to make those dependency lists on hackage somewhat > easier to comprehend? > > Probably, hackage/cabal could offer some support for reducing > detailed dependencies to standard dependency groups. Yes, it'd be useful to see what are the "non-standard" deps, ie those outside of the core libs or the platform libs. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminalincompatibility?
It's a shame this doesn't just work out of the box in an xterm, on Debian at least. Perhaps we should consider switching to haskeline? Do we know anything about how portable and complete that is? If a haskell-based solution could be made to work, that would be great - if you think that editline somehow less nice than readline, consider us poor windows users: we have neither! Note that haskeline has a lot of dependencies and requires TemplateHaskell and many other language extensions. Talking about dependencies of cabal packages: - some packages depend on everything and the kitchen-sink, following the "ah, great, here's another package I should use" idea of what it means to provide a modern haskell package. It would be nice if package authors would consider separate minimal and extended dependencies, the former sufficient to enable the package functionality, the latter enabled by a flag, and only needed for testing frameworks, parser re-generation, convenience, performance, .. - since Duncan has put in the work for making meta-packages possible for the Haskell Platform anyway, couldn't that be used to group typical dependencies together (eg, ghc corelibs, old extralibs, haskell platform, testing, ..), to make those dependency lists on hackage somewhat easier to comprehend? Probably, hackage/cabal could offer some support for reducing detailed dependencies to standard dependency groups. Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sun, 2008-11-09 at 01:49 +, Ian Lynagh wrote: > On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > > > bind "\e[3~" ed-delete-next-char > > It's a shame this doesn't just work out of the box in an xterm, on > Debian at least. Perhaps we should consider switching to haskeline? Do > we know anything about how portable and complete that is? If we're considering that I think we should consider bringing back readline as an option and let the people who have problems with gpl code configure in editline support instead. Note that haskeline has a lot of dependencies and requires TemplateHaskell and many other language extensions. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On 2008 Nov 8, at 22:13, Rohan Drape wrote: Emacs sends text to processes in packets of at most 255 characters. In between these ghci now gets a ^D character sequence inserted into the text. This did not happen previously (ie. with 6.8.2). This sounds like a bug: either editline or ghci assumes that when it successfully reads data which lacks a line terminator than it has seen an EOF, so inserts a ^D. But if it received the data at the maximum tty buffer size (255) then there is no trigger character. (This is easy enough to work around: special-case reads of length 255. But in reality, this means something is Doing It Wrong.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On 2008-11-09, Reiner Pope <[EMAIL PROTECTED]> wrote: > I'm not sure if this is Emacs' fault, but when I run GHCi through > Emacs, entered text is printed to stdout or stderr immediately after > Enter is pressed; when this is done after a file is loaded, "^J" is > appended. Also here, and there is a further problem with long lines. Emacs sends text to processes in packets of at most 255 characters. In between these ghci now gets a ^D character sequence inserted into the text. This did not happen previously (ie. with 6.8.2). I've edited the emacs mode I use to split long strings into packets before requesting emacs sends them, which has 'solved' the problem here. However it seems unlikely that emacs is doing anything too odd? Regards, Rohan (I doubt this affects many people, the emacs mode I use collapses a region written without layout into a single long line and sends that to ghci for evaluation.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sun, Nov 9, 2008 at 12:53 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote: > On Sun, Nov 09, 2008 at 01:49:43AM +, Ian Lynagh wrote: >> On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: >> > >> > bind "\e[3~" ed-delete-next-char >> >> It's a shame this doesn't just work out of the box in an xterm, on > > Oh, the other thing I meant to say is that it seems to behaves > unexpectedly too. If I type "abc" and press delete, then the "c" is > deleted and the cursor is left on (on, not after) the "b". I'd expect > the "c" to remain, and the cursor to stay after the "c". > > > Thanks > Ian > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Hi, I'm not sure if this is Emacs' fault, but when I run GHCi through Emacs, entered text is printed to stdout or stderr immediately after Enter is pressed; when this is done after a file is loaded, "^J" is appended. For example >GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help >Loading package ghc-prim ... linking ... done. >Loading package integer ... linking ... done. >Loading package base ... linking ... done. >Prelude> :t id >:t id >id :: a -> a >Prelude> :l Pair.hs >:l Pair.hs >[1 of 1] Compiling Pair ( Pair.hs, interpreted ) >Ok, modules loaded: Pair. >*Pair> :t id >:t id^Jid :: a -> a >*Pair> Note that this happens even without haskell-mode, using just M-x shell. I'm using Ubuntu 8.10, GHC 6.10.1. I symlinked libedit.so.0 to libedit.so.2 as Simon Marlow suggested. It works fine in gnome-terminal, but not in Emacs. Cheers, Reiner ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sun, Nov 09, 2008 at 01:49:43AM +, Ian Lynagh wrote: > On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > > > bind "\e[3~" ed-delete-next-char > > It's a shame this doesn't just work out of the box in an xterm, on Oh, the other thing I meant to say is that it seems to behaves unexpectedly too. If I type "abc" and press delete, then the "c" is deleted and the cursor is left on (on, not after) the "b". I'd expect the "c" to remain, and the cursor to stay after the "c". Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote: > > bind "\e[3~" ed-delete-next-char It's a shame this doesn't just work out of the box in an xterm, on Debian at least. Perhaps we should consider switching to haskeline? Do we know anything about how portable and complete that is? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Sat, Nov 8, 2008 at 12:33 PM, Judah Jacobson <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 8:38 PM, Alexander Dunlap > <[EMAIL PROTECTED]> wrote: >> On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. Hölzenspies >> <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> I apologize if this is off-topic, but I'm having a similar (but >> distinct) problem: editline thinks that my delete key is a tilde key. >> When I type , it inserts a tilde. The tilde then acts >> completely like a tilde (i.e. GHCi interprets it as a tilde). I have >> been unable to find an answer by googling. Does anyone else have/know >> how to fix this problem? > > First, just to make sure: do the arrow keys work or is all editing > functionality broken? If it's the latter, then ghc probably wasn't > built with libedit and you need the libedit-devel package. > > Assuming that's not the issue, and you don't get the same problem with > readline-based programs, then it sounds like editline doesn't know > about the key binding for DELETE on your system. The simplest fix is > to edit the ~/.editrc file. For example: > > Running "ghc -e getLine", then pressing DELETE followed by RETURN, I see: > > $ ghc -e getLine > ^[[3~ > "\ESC[3~" > > This tells me the key sequence for the DELETE key in my terminal, so I > add the following line to my ~/.editrc file > (http://www.manpagez.com/man/5/editrc/): > > bind "\e[3~" ed-delete-next-char > > > Hope that helps, > -Judah > Your latter instructions were exactly what I needed. Thank you very much! Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, Nov 7, 2008 at 8:38 PM, Alexander Dunlap <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. Hölzenspies > <[EMAIL PROTECTED]> wrote: > > Hi all, > > I apologize if this is off-topic, but I'm having a similar (but > distinct) problem: editline thinks that my delete key is a tilde key. > When I type , it inserts a tilde. The tilde then acts > completely like a tilde (i.e. GHCi interprets it as a tilde). I have > been unable to find an answer by googling. Does anyone else have/know > how to fix this problem? First, just to make sure: do the arrow keys work or is all editing functionality broken? If it's the latter, then ghc probably wasn't built with libedit and you need the libedit-devel package. Assuming that's not the issue, and you don't get the same problem with readline-based programs, then it sounds like editline doesn't know about the key binding for DELETE on your system. The simplest fix is to edit the ~/.editrc file. For example: Running "ghc -e getLine", then pressing DELETE followed by RETURN, I see: $ ghc -e getLine ^[[3~ "\ESC[3~" This tells me the key sequence for the DELETE key in my terminal, so I add the following line to my ~/.editrc file (http://www.manpagez.com/man/5/editrc/): bind "\e[3~" ed-delete-next-char Hope that helps, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Hi Philip, On Fri, Nov 07, 2008 at 12:13:04PM +0100, Philip K.F. Hölzenspies wrote: > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. For future reference, the RCs are built in exactly the same way as the releases. So if there's a bug of any kind in an RC, and it's not reported, then the chances are it'll be in the release too. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. Hölzenspies <[EMAIL PROTECTED]> wrote: > Dear Ian, all, > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. Which bug? Well... > > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). > > I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the > default termcap settings. Any clues? Is this bug known? > > Regards, > Philip > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Hi all, I apologize if this is off-topic, but I'm having a similar (but distinct) problem: editline thinks that my delete key is a tilde key. When I type , it inserts a tilde. The tilde then acts completely like a tilde (i.e. GHCi interprets it as a tilde). I have been unable to find an answer by googling. Does anyone else have/know how to fix this problem? Thanks, Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
duncan.coutts: > On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote: > > > > Does anyone know how libedit is supposed to be configured? readline > > > uses /etc/inputrc but libedit either does not or doesn't understand all > > > of it. > > > > > > /me wonders if it was really necessary to switch from readline > > > > I'll note that it is all working find on Arch. > > The behaviour is indistinguishable to readline. > > > > Perhaps the editline package is correctly configured here? > > Does the arch editline package include a config file? /etc/something? > Hmm... I don't see anything weird configuration-wise, http://www.archlinux.org/packages/extra/x86_64/libedit/ Chasing up the maintainer... -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote: > > Does anyone know how libedit is supposed to be configured? readline > > uses /etc/inputrc but libedit either does not or doesn't understand all > > of it. > > > > /me wonders if it was really necessary to switch from readline > > I'll note that it is all working find on Arch. > The behaviour is indistinguishable to readline. > > Perhaps the editline package is correctly configured here? Does the arch editline package include a config file? /etc/something? Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
duncan.coutts: > On Fri, 2008-11-07 at 12:13 +0100, Philip K.F. Hölzenspies wrote: > > > It seems editline has some incompatibility with my terminal. Maybe, I > > should > > configure something differently, but any and all of the control characters > > I > > type and work for all readline based (and all custom line-readers I have > > come > > across), but not for the new ghci. Most annoying is the fact that backspace > > doesn't work (instead, the control sequence ^? is printed and pressing > > enter > > results in "lexical error at character '\DEL'"). However, arrow keys (left > > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations > > (^d, > > ^e, ^a) also give similar errors. It is striking that the lexer does > > recognize them as the correct characters (printed error messages doe say > > \DEL, \EOT, \ENQ, etc). > > I get some working and some non-working. Eg backspace, del, home, end > work, but the ctl-left/ctl-right to jump words does not. > > Does anyone know how libedit is supposed to be configured? readline > uses /etc/inputrc but libedit either does not or doesn't understand all > of it. > > /me wonders if it was really necessary to switch from readline I'll note that it is all working find on Arch. The behaviour is indistinguishable to readline. Perhaps the editline package is correctly configured here? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-07 at 09:14 -0800, Judah Jacobson wrote: > On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts > <[EMAIL PROTECTED]> wrote: > > > > I get some working and some non-working. Eg backspace, del, home, end > > work, but the ctl-left/ctl-right to jump words does not. > > > > Does anyone know how libedit is supposed to be configured? readline > > uses /etc/inputrc but libedit either does not or doesn't understand all > > of it. > > > > /me wonders if it was really necessary to switch from readline > > > > Duncan > > You can configure libedit with a ~/.editrc file. > > http://www.manpagez.com/man/5/editrc/ Thanks Judah. To save everyone else having to read the man page and working out through trial and error what the key escape codes are, add the following to your ~/.editrc file. # mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving bind "\e[1;5D" vi-prev-word bind "\e[1;5C" vi-next-word (though from reading the readline /etc/inputrc it suggests that "\e[5C" and "\e[5D" might be right on some systems) It's unfortunate that editline does not seem to support any global /etc/editrc file which would enable distros to make it do the right thing by default like they do for readline. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, Nov 7, 2008 at 4:36 AM, Duncan Coutts <[EMAIL PROTECTED]> wrote: > > I get some working and some non-working. Eg backspace, del, home, end > work, but the ctl-left/ctl-right to jump words does not. > > Does anyone know how libedit is supposed to be configured? readline > uses /etc/inputrc but libedit either does not or doesn't understand all > of it. > > /me wonders if it was really necessary to switch from readline > > Duncan You can configure libedit with a ~/.editrc file. http://www.manpagez.com/man/5/editrc/ -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, Nov 7, 2008 at 3:13 AM, Philip K.F. Hölzenspies <[EMAIL PROTECTED]> wrote: > Dear Ian, all, > > After the announcement, I downloaded and installed the final release of > 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, > but I had generally assumed it to be an RC-phenomenon. Which bug? Well... > > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). > > I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the > default termcap settings. Any clues? Is this bug known? > If the arrow keys don't work, it's a good sign that ghc just wasn't built with editline support. To build againt editline, you will probably need to install the libedit-devel package. Hope that helps, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
On Fri, 2008-11-07 at 12:13 +0100, Philip K.F. Hölzenspies wrote: > It seems editline has some incompatibility with my terminal. Maybe, I should > configure something differently, but any and all of the control characters I > type and work for all readline based (and all custom line-readers I have come > across), but not for the new ghci. Most annoying is the fact that backspace > doesn't work (instead, the control sequence ^? is printed and pressing enter > results in "lexical error at character '\DEL'"). However, arrow keys (left > ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, > ^e, ^a) also give similar errors. It is striking that the lexer does > recognize them as the correct characters (printed error messages doe say > \DEL, \EOT, \ENQ, etc). I get some working and some non-working. Eg backspace, del, home, end work, but the ctl-left/ctl-right to jump words does not. Does anyone know how libedit is supposed to be configured? readline uses /etc/inputrc but libedit either does not or doesn't understand all of it. /me wonders if it was really necessary to switch from readline Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - EditLine / terminal incompatibility?
Dear Ian, all, After the announcement, I downloaded and installed the final release of 6.10.1. At some prior stage, I used the RC1 release, which had the same bug, but I had generally assumed it to be an RC-phenomenon. Which bug? Well... It seems editline has some incompatibility with my terminal. Maybe, I should configure something differently, but any and all of the control characters I type and work for all readline based (and all custom line-readers I have come across), but not for the new ghci. Most annoying is the fact that backspace doesn't work (instead, the control sequence ^? is printed and pressing enter results in "lexical error at character '\DEL'"). However, arrow keys (left ^[[D, up ^[[A, right ^[[C and down ^[[B) and common Ctrl+_ combinations (^d, ^e, ^a) also give similar errors. It is striking that the lexer does recognize them as the correct characters (printed error messages doe say \DEL, \EOT, \ENQ, etc). I'm using xterm (X.Org 6.8.99.903(229)) on an OpenSuSE 10.3 system and the default termcap settings. Any clues? Is this bug known? Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Ian Lynagh: On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. The only file I can see that looks relevant is /Library/Receipts/boms/ org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file "Uninstaller" could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as "bundles": http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a "rm -rf /Library/Frameworks/ GHC.framework/Versions/"). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a "rm -rf" as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: > On 2008 Nov 4, at 20:26, Jason Dagit wrote: > >On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty > ><[EMAIL PROTECTED]> wrote: > >> > >>Are you sure it does deinstall the 6.8 compiler? > >> > >>After installing 6.10, there should be a 608/ and a 610/ > >>directory. This > >>certainly happens on my Mac and I am not aware of an option to > >>change that > >>behaviour. > > I expect if you used the OSX installer then /Library/Receipts is > screwing you (it wipes the old files listed in the .bom file). Try > finding and removing the receipt directory and bom file before > installing. The only file I can see that looks relevant is /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file "Uninstaller" could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: Jason Dagit: I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed from a pkg). I would like to add ghc-6.10.1 to my system. I tried to do this with RC1 of 6.10, but I found that it uninstalled my ghc-6.8.3. What will I need to do to get both 6.8.3 and 6.10.1? Are you sure it does deinstall the 6.8 compiler? Or does it just overwrite the symbolic links in /usr/bin? To check, have a look at /Library/Frameworks/GHC.framework/Versions After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I haven't tried the 6.10.1 install, but after using the 6.8.3 pkg followed by the 6.10 RC1 pkg, followed by the 6.8.3 pkg, I have just 608 in the directory you mention. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: > Jason Dagit: >> >> On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: >>> >>> How to get it >>> ~ >>> >>> The easy way is to go to the web page, which should be self-explanatory: >>> >>> http://www.haskell.org/ghc/ >>> >>> We supply binary builds in the native package format for many >>> platforms, and the source distribution is available from the same >>> place. >>> >>> Packages will appear as they are built - if the package for your >>> system isn't available yet, please try again later. >> >> I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed >> from a pkg). I would like to add ghc-6.10.1 to my system. I tried to >> do this with RC1 of 6.10, but I found that it uninstalled my >> ghc-6.8.3. >> >> What will I need to do to get both 6.8.3 and 6.10.1? > > Are you sure it does deinstall the 6.8 compiler? Or does it just overwrite > the symbolic links in /usr/bin? To check, have a look at > > /Library/Frameworks/GHC.framework/Versions > > After installing 6.10, there should be a 608/ and a 610/ directory. This > certainly happens on my Mac and I am not aware of an option to change that > behaviour. I haven't tried the 6.10.1 install, but after using the 6.8.3 pkg followed by the 6.10 RC1 pkg, followed by the 6.8.3 pkg, I have just 608 in the directory you mention. I guess I should try the 6.10.1 install. If I have to reinstall 6.8.3 again, not the end of the world for me. > And while we are at it...a BIG FAT WARNING: > > If you installed the 6.10.200081007 pre-release installer package, > uninstall that *before* installing the 6.10.1 package. Okay thanks. Although, I don't think that will be a problem for me given the directories I can see. Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Wed, Nov 05, 2008 at 11:26:20AM +1100, Manuel M T Chakravarty wrote: > Jason Dagit: > > > >What will I need to do to get both 6.8.3 and 6.10.1? > > Are you sure it does deinstall the 6.8 compiler? It definitely deinstalls it for me; I've just confirmed it. Here's what I saw with a 6.9 OS X installer a while ago: If I start off with 6.8.3 installed: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Jun 18 03:10 608 lrwxr-xr-x 1 root admin3 Aug 29 12:57 Current -> 608 then while my GHC-6.9.20080828-i386.pkg is installing I see: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Aug 29 12:58 609 lrwxr-xr-x 1 root admin3 Aug 29 12:57 Current -> 608 (i.e. 608 has disappeared, but it isn't the whole GHC.framework that's been removed because the Current link is still there) and then when the installer has finished: $ ls -l /Library/Frameworks/GHC.framework/Versions/ total 8 drwxrwxr-x 4 root admin 136 Aug 29 12:58 609 lrwxr-xr-x 1 root admin3 Aug 29 12:57 Current -> 608 Thanks IAn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
Jason Dagit: On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: How to get it ~ The easy way is to go to the web page, which should be self- explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed from a pkg). I would like to add ghc-6.10.1 to my system. I tried to do this with RC1 of 6.10, but I found that it uninstalled my ghc-6.8.3. What will I need to do to get both 6.8.3 and 6.10.1? Are you sure it does deinstall the 6.8 compiler? Or does it just overwrite the symbolic links in /usr/bin? To check, have a look at /Library/Frameworks/GHC.framework/Versions After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. And while we are at it...a BIG FAT WARNING: If you installed the 6.10.200081007 pre-release installer package, uninstall that *before* installing the 6.10.1 package. For reasons, I don't understand, the installer otherwise half removes the old package, but doesn't seem to install the new one. Can a Mac expert shed any light on that behaviour? If you tried installing 6.10.1 before reading that, just remove the partial installation you are left with, and install again. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1
On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote: > > How to get it > ~ > > The easy way is to go to the web page, which should be self-explanatory: > >http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. I'm on OSX and I currently have ghc-6.6.1 and ghc-6.8.3 (installed from a pkg). I would like to add ghc-6.10.1 to my system. I tried to do this with RC1 of 6.10, but I found that it uninstalled my ghc-6.8.3. What will I need to do to get both 6.8.3 and 6.10.1? Thank you! Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1
Hello fellow GHC users, Ian Lynagh wrote: == The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 == [snip] How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ Gentoo Linux users can get it from the gentoo-haskell overlay[1]. If you're not familiar with this overlay (a gold mine for haskell hackers using gentoo), you can easily use layman[2] to get access. Make sure you have darcs installed, as it is a requirement for our overlay. Once layman is set up, add the overlay with: $ layman -a haskell Note that ghc-6.10.1 still is masked by keyword, and you need to unmask it first. If you're not familiar with how to do this, here's a quick guide: # make sure /etc/portage exists $ [[ -d /etc/portage ]] || mkdir /etc/portage # accept ghc being ~arch $ echo "dev-lang/ghc" >> /etc/portage/package.keywords # ghc requires the very latest libedit package $ echo "dev-libs/libedit" >> /etc/portage/package.keywords You may then install ghc-6.10.1 by saying: # this requires that you already have an older ghc version installed $ USE="ghcbootstrap -binary" emerge ghc The USE flags are required as we don't just yet provide the required binaries to bootstrap ghc. The command above requires that you already have a ghc version installed to bootstrap with. This version will be replaced with ghc-6.10.1 once the installation finishes. GHC binaries will follow shortly, which will shorten the procedure to: $ emerge ghc The packages from extralibs will also be available from the overlay. If you run into trouble, reply to the ml, or find us in #gentoo-haskell at freenode. Cheers, Lennart Kolmodin -- using his Gentoo Linux Developer hat [1] http://code.haskell.org/gentoo/gentoo-haskell/ [2] http://www.gentoo.org/proj/en/overlays/userguide.xml ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.10.1
== The (Interactive) Glasgow Haskell Compiler -- version 6.10.1 == The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Some new language features have been implemented: * Record syntax: wild-card patterns, punning, and field disambiguation * Generalised quasi-quotes * Generalised list comprehensions * View patterns * Type families have been completely re-implemented * Now comes with Haddock 2, which supports all GHC extensions * Parallel garbage collection * Base provides extensible exceptions * The GHC API is easier to use * External core (output only) now works again * Data Parallel Haskell (DPH) comes as part of GHC The full release notes are here: http://haskell.org/ghc/docs/6.10.1/html/users_guide/release-6-10-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
