============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.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 [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Ian Lynagh wrote:
> ============================================================= > The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 > ============================================================= > > The GHC Team is pleased to announce a new patchlevel release of GHC. > This release contains a number of bugfixes relative to 6.8.1, > including > some significant performance fixes, so we recommend upgrading. A binary distribution for Mac OS X 10.5 (Leopard) is available from http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 To use this binary distribution, you need to have "readline" from MacPorts installed. Manuel PS: This time around, there should be no dependency on MacPorts' "gmp", but this is hard for me to test locally. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Manuel M T Chakravarty wrote:
> To use this binary distribution, you need to have "readline" from > MacPorts installed. > > Manuel > > PS: This time around, there should be no dependency on MacPorts' "gmp", > but this is hard for me to test locally. What does your "otool -L" say to your binary? otool -L compiler/stage2/ghc-6.8.2 compiler/stage2/ghc-6.8.2: /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed? Christian _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Ian Lynagh
On Dec 12, 2007 7:44 PM, Ian Lynagh <[hidden email]> wrote:
> The GHC Team is pleased to announce a new patchlevel release of GHC. With the Windows release of GHC 6.8.2, GHCi does not find .ghci in %HOME% (though it finds it in the current directory): C:\wrk> echo %HOME% C:\home C:\wrk> ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :quit Leaving GHCi. C:\wrk> cd %HOME% C:\home> ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. ** Reading .ghci ** Prelude> :quit Leaving GHCi. C:\home> type .ghci putStrLn "** Reading .ghci **" C:\home> Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
> With the Windows release of GHC 6.8.2, GHCi does not find .ghci in
> %HOME% (though it finds it in the current directory): try %HOMEDRIVE% %HOMEPATH% instead? or the result of 'System.Directory.getHomeDirectory'. you might have set %HOME% to help some unix software along, but this variable doesn't seem to exist by default. claus http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx http://en.wikipedia.org/wiki/Home_directory _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 2:05 PM, Claus Reinke <[hidden email]> wrote:
> try %HOMEDRIVE% %HOMEPATH% instead? Doesn't work either. > you might have set %HOME% to help some unix software > along, but this variable doesn't seem to exist by default. It worked in 6.8.1. With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1. Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Juanma Barranquero wrote:
> On Dec 13, 2007 2:05 PM, Claus Reinke <[hidden email]> wrote: > >> try %HOMEDRIVE% %HOMEPATH% instead? > > Doesn't work either. > >> you might have set %HOME% to help some unix software >> along, but this variable doesn't seem to exist by default. > > It worked in 6.8.1. > > With which I mean, GHCi had no trouble finding .ghci at %HOME% in 6.8.1. Yes, see this ticket which was fixed in 6.8.2: http://hackage.haskell.org/trac/ghc/ticket/1838 GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever getHomeDirectory says your home directory is. Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 4:13 PM, Simon Marlow <[hidden email]> wrote:
> Yes, see this ticket which was fixed in 6.8.2: I suppose that is a fix for some people; it is a regression for me... > GHCi now uses getHomeDirectory, so you need to put your .ghci file wherever > getHomeDirectory says your home directory is. Is there any way to influence what getHomeDirectory thinks? Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 4:20 PM, Juanma Barranquero <[hidden email]> wrote:
> I suppose that is a fix for some people; it is a regression for me... In fact, it'd be better if GHC/GHCi would do what Emacs on Windows does: use HOME if defined, else use ShGetFolderPath to find the Windows-defined "home directory". Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
>> I suppose that is a fix for some people; it is a regression for me...
> > In fact, it'd be better if GHC/GHCi would do what Emacs on Windows > does: use HOME if defined, else use ShGetFolderPath to find the > Windows-defined "home directory". in the interest of backwards-compatibility, perhaps. but as the links i gave should demonstrate, there is no %HOME% on windows, unless you invent it. most users who define %HOME% probably mean it to override the system standard %HOMEPATH%, at least in those programs that look for %HOME%. but that is a guess that would need to be documented for each of those programs, and makes them different from the majority of code on that platform. and not looking for %HOMEPATH% if there's no %HOME% is always a bug. if you absolutely want to define a %HOME%, and you also absolutely want to keep it different from %HOMEPATH% (which means you have two homes to take care of!), then you could try a simple workaround: %HOMEPATH%\.ghci: :cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci") %HOME\.ghci -- as before claus _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 4:49 PM, Claus Reinke <[hidden email]> wrote:
> in the interest of backwards-compatibility, perhaps. That is a good reason, yes. > but as the links i gave should demonstrate, there is no > %HOME% on windows, unless you invent it. Sorry, it's not me who invented it. There are many tools (from Unix origin) that use HOME in Windows if defined. In fact, let me think... oh, yeah, I remember, GHCi itself used it until this very same morning... :) > and not looking for > %HOMEPATH% if there's no %HOME% is always a bug. That's why I suggest using HOME if defined, ShGetFolderPath if not. > if you absolutely want to define a %HOME%, and you > also absolutely want to keep it different from %HOMEPATH% > (which means you have two homes to take care of!) No. I don't "take care" of the Windows-provided home dir, because it is mostly used *automatically* by programs that write their setting files to it. It is rare indeed the Windows program that requires the user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there. > %HOMEPATH%\.ghci: > > :cmd System.Environment.getEnv "HOME" >>= \h->readFile (h++"/.ghci") > > %HOME\.ghci > > -- as before Thanks, I'll use that. However, I still think that breaking back-compatibility is Not a Good Idea. Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
> Sorry, it's not me who invented it. There are many tools (from Unix
> origin) that use HOME in Windows if defined. In fact, let me think... > oh, yeah, I remember, GHCi itself used it until this very same > morning... :) yes, but ghc/ghci switched from unix-emulated to windows-native long ago - since then, they've tried to behave more like other windows programs, with no built-in knowledge of unixisms. now, imagine the surprise when, in your %HOME%/.ghci, you do home <- System.Directory.getHomeDirectory System.Directory.getDirectoryContents home and the script ghci claims to be executing isn't even there!-) or imagine switching between console (no HOME) and bash (inherited HOME) ghci: now you see .ghci, now you don't.. > No. I don't "take care" of the Windows-provided home dir, because it > is mostly used *automatically* by programs that write their setting > files to it. It is rare indeed the Windows program that requires the > user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there. it would be useful if ghci could read/write its current settings (perhaps split into a .cabal file with settings and a .ghci file with scripts/definitions). but you wouldn't want it to ovewrite your old .ghci, and some of us would still like to know where it ends up so that we can check and edit it manually, or copy it elsewhere;-) > Thanks, I'll use that. However, I still think that breaking > back-compatibility is Not a Good Idea. in general, i would agree. perhaps my fault for filing that ticket in absolutes, which led to a fix replacing, rather than augmenting, the old, erroneous behaviour. but a HOME-overrides-HOMEPATH approach, while backwards-compatible, suffers from the same inconsistency issues as the old please-define-HOME-yourself approach (even worse: you might get different versions of .ghci). so, one would have to implement the overriding approach consistently (including getHomeDirectory), and issue warnings and documentation to make users aware of any such overriding taking place (and should it be optional, to avoid deviating from the platform standard?).. as a short-term deprecation workaround for ghc-6.8.x, that makes some sense, but in the long-term? claus _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 6:03 PM, Claus Reinke <[hidden email]> wrote:
> perhaps my fault for filing that ticket in absolutes, which led > to a fix replacing, rather than augmenting, the old, erroneous > behaviour. It's not a matter of "fault", but sure it would've been wiser to suggest (or implement) the new behavior without forgetting those of us who were used to the current ways :) > so, one would have to implement the overriding approach > consistently (including getHomeDirectory), and issue warnings > and documentation to make users aware of any such overriding > taking place (and should it be optional, to avoid deviating from > the platform standard?).. As I've said, Emacs already does that and there's no trouble at all. > as a short-term deprecation workaround > for ghc-6.8.x, that makes some sense, but in the long-term? Personally, I wouldn't want to use %HOMEDRIVE%%HOMEPATH%, neither short-term nor long-term, unless forced to do so. Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Manuel M T Chakravarty
Hi Manuel, On Thu, Dec 13, 2007 at 04:29:13PM +1100, Manuel M T Chakravarty wrote: > Ian Lynagh wrote: > > ============================================================= > > The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 > > ============================================================= > > A binary distribution for Mac OS X 10.5 (Leopard) is available from > > http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 Thanks! I've made this available from the 6.8.2 download page. Ian _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Manuel M T Chakravarty
Will this also work with Tiger or do I have to upgrade?
-Alex- Manuel M T Chakravarty wrote: > Ian Lynagh wrote: >> ============================================================= >> The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 >> ============================================================= >> >> The GHC Team is pleased to announce a new patchlevel release of GHC. >> This release contains a number of bugfixes relative to 6.8.1, including >> some significant performance fixes, so we recommend upgrading. > > A binary distribution for Mac OS X 10.5 (Leopard) is available from > > > http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 > > > To use this binary distribution, you need to have "readline" from > MacPorts installed. > > Manuel > > PS: This time around, there should be no dependency on MacPorts' "gmp", > but this is hard for me to test locally. > _______________________________________________ > Glasgow-haskell-users mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Claus Reinke
Juanma Barranquero wrote:
>> In fact, it'd be better if GHC/GHCi would do what Emacs on Windows >> does: use HOME if defined, else use ShGetFolderPath to find the >> Windows-defined "home directory". I agree, that is closer to the correct behavior. Except that on Vista ShGetFolderPath is deprecated. Use ShGetKnownFolderPath instead on Vista. On Vista, users may have their settings stored somewhere else on the network. The old interface does not support that. Claus Reinke wrote: > in the interest of backwards-compatibility, perhaps. > but as the links i gave should demonstrate, there is no > %HOME% on windows, unless you invent it. %HOMEPATH% is *not* the usual Windows native way of finding a place for files like dot-ghci. Your link to MS documentation of %HOMEPATH% for XP doesn't use the word "legacy", but it certainly smells that way to any modern Windows developer. It is a throwback to the old DOS days. I was unable to find any mention of %HOMEPATH% at all for Vista on the MS site, though it does still seem to exist. Anyone have a link? Note that the old cmd.exe shell itself is deprecated on Vista - the new MSH shell is based on .NET. There I think you would use the IKnownFolders interface to get (something vagualy analagous to) the home directory, not %HOMEPATH% Also, %HOMEPATH% is unsuitable for a Unix-style home directory on pre-Vista systems, because it usually points to a directory with spaces in its path name. %HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should still be supported if someone sets it. Otherwise, the native Windows way is via ShGetFolderPath on pre-Vista, and ShGetKnownFolder on Vista. The installer should create a GHC subfolder of that, and that is where dot-ghci should go on Windows, unless %HOME% is set. > now, imagine the surprise when, in your %HOME%/.ghci, you > > do home <- System.Directory.getHomeDirectory > System.Directory.getDirectoryContents home > > and the script ghci claims to be executing isn't even there!-) Yes, that is a problem. A user who sets %HOME% has indicated that this should be used. I think that should be returned by getHomeDirectory. If you like using "Documents and Settings..." no one is forcing you to set %HOME% to anything, you can just use the default settings. Thanks, Yitz _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Dec 13, 2007 11:31 PM, Yitzchak Gale <[hidden email]> wrote:
> I agree, that is closer to the correct behavior. > Except that on Vista ShGetFolderPath is deprecated. > Use ShGetKnownFolderPath instead on Vista. Aha, I didn't know that. Thanks. > Also, %HOMEPATH% is unsuitable for a Unix-style home > directory on pre-Vista systems, because it usually points to > a directory with spaces in its path name. That's one big reason why I don't use it as HOME. > %HOME% is the de-facto standard for Unix-like > shell applications that were ported to Windows and > need a home directory. If someone sets that, it > means they want to use the folder in that way. And > yes, that is the way GHCi has been working until > now, so I think it should still be supported if someone > sets it. Yes. > Yes, that is a problem. A user who sets %HOME% has > indicated that this should be used. I think that should be > returned by getHomeDirectory. Exactly! Juanma _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Alex Jacobson
Alex Jacobson:
> Will this also work with Tiger or do I have to upgrade? > I don't know. I have no box with Tiger to test. Give it a try. The worst that can happen is that it is going to complain about some missing libraries or similar. Manuel > Manuel M T Chakravarty wrote: >> Ian Lynagh wrote: >>> ============================================================= >>> The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 >>> ============================================================= >>> >>> The GHC Team is pleased to announce a new patchlevel release of GHC. >>> This release contains a number of bugfixes relative to 6.8.1, >>> including >>> some significant performance fixes, so we recommend upgrading. >> A binary distribution for Mac OS X 10.5 (Leopard) is available from >> http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 >> To use this binary distribution, you need to have "readline" from >> MacPorts installed. >> Manuel >> PS: This time around, there should be no dependency on MacPorts' >> "gmp", but this is hard for me to test locally. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> [hidden email] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Christian Maeder-2
Christian Maeder:
> Manuel M T Chakravarty wrote: >> To use this binary distribution, you need to have "readline" from >> MacPorts installed. >> >> Manuel >> >> PS: This time around, there should be no dependency on MacPorts' >> "gmp", >> but this is hard for me to test locally. > > What does your "otool -L" say to your binary? > > otool -L compiler/stage2/ghc-6.8.2 > compiler/stage2/ghc-6.8.2: > /opt/local/lib/libreadline.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, > current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current > version 111.0.0) > /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, > current version 8.1.0) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > > Does this not indicate that /opt/local/lib/libgmp.3.dylib is needed? Yes, it does. That's very strange for the *stage2* compiler. I ran otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those binaries don't depend on "gmp"). Ian, why would a stage2 compiler depend on an external gmp? I thought it would always use the one bundled with ghc. Manuel _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty wrote:
> > > >otool -L compiler/stage2/ghc-6.8.2 > > /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, > >current version 8.1.0) > > Yes, it does. That's very strange for the *stage2* compiler. I ran > otool on pwd and ghc-pkg (which were the problem in 6.8.1 and those > binaries don't depend on "gmp"). > > Ian, why would a stage2 compiler depend on an external gmp? I thought > it would always use the one bundled with ghc. Do you mean the one in gmp/ in the ghc repo? That's only used if there isn't an external GMP on the system; it's basically only there because we don't want to require that Windows users install GMP. I'm not sure where GMP frameworks on OS X fit in. Incidentally, I suspect the otool output actually means it depends on /some/ libgmp.3.dylib, and it is using one that it found in /opt/local/lib/libgmp.3.dylib, but I could be wrong. Thanks Ian _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Free forum by Nabble | Edit this page |