Re: [Haskell] ANNOUNCE: Haskell Platform 7.10.2
[ re-posted with a link instead of an attachment, the mail size limit seems to be a bit small on some lists... ] 2015-07-30 21:08 GMT+02:00 Mark Lentczner mark.lentcz...@gmail.com: Haskellers, we are pleased to announce the release of Haskell Platform 7.10.2 *get it here... https://www.haskell.org/platform/* [...] Nice! I've just tested things under Windows, and everything works for me so far, only one tiny nit remains: In the documentation index (file:///.../Haskell%20Platform/7.10.2/lib/extralibs/doc/index.html) package names for the non-GHC packages are still missing in the right column, see http://i.imgur.com/jh0u8EP.png. I'm not sure if this is a glitch in the HP build or a bug in Cabal or a bug in Haddock or..., so I don't know where to open an issue. Does anybody have a clue what might cause this? If I build packages locally in a sandbox, their documentation shows similar bugs. Is this working for other people or do they experience the same behavior? Nevertheless, great work! Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
simultaneous ghc versions
The recent release of ghc 7.10.2 reminded me of something I meant to ask about a long time ago. Most of the binaries ghc installs are versioned (x linked to x-7.10.2), with some exceptions (hpc and hsc2hs). Shouldn't they all be versioned? Also, 'haddock' is inconsistent with all the rest, in that it's haddock linked to haddock-ghc-7.10.2. I've long used a few shell scripts (recently upgraded to python) to manage ghc installs. A 'set' which creates symlinks to make a particular version current, and an 'rm' to remove all traces of a version. But due to the inconsistency, I have to remember to run fix first, which moves the unversioned binaries to versioned names. As an aside, I have three scripts I use all the time: set version, remove version, and remove library. Come to think of it, shouldn't ghc include this, instead of everyone creating their own shell scripts by hand? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Btw, I simply prepend to the $PATH env variable, or pass the appropriate executable name to `cabal`'s -w --with-compiler=PATHgive the path to a particular compiler I don't understand, aren't they all in /usr/local/bin? Or do you use a version-specific prefix when installing each ghc version? Also, ghc is not just the compiler, but also hsc2hs hpc runghc ghci ghc-pkg haddock-ghc. At the least, ghc-pkg has to be the right version, but all of those are version specific since they'll break if you remove their /usr/lib/ghc-version. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On 2015-07-31 at 20:32:43 +0200, Evan Laforge wrote: On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Btw, I simply prepend to the $PATH env variable, or pass the appropriate executable name to `cabal`'s -w --with-compiler=PATHgive the path to a particular compiler I don't understand, aren't they all in /usr/local/bin? Or do you use a version-specific prefix when installing each ghc version? Sorry, I assumed this w/o saying; I maintain and use myself https://github.com/hvr/multi-ghc-travis which in fact uses version-specific install prefixes, resulting in the `bin` folder being /opt/ghc/version/bin Also, ghc is not just the compiler, but also hsc2hs hpc runghc ghci ghc-pkg haddock-ghc. At the least, ghc-pkg has to be the right version, `cabal` is actually clever enough to locate the appropriate executable, if I pass it a specific ghc executable (iirc it looks in the same folder where `ghc` was found) $ which ghc-pkg /opt/ghc/7.10.2/bin/ghc-pkg $ which hsc2hs /opt/ghc/7.10.2/bin/hsc2hs $ cabal configure -w /opt/ghc/7.6.3/bin/ghc -v2 ... Using ghc version 7.6.3 given by user at: /opt/ghc/7.6.3/bin/ghc Using ghc-pkg version 7.6.3 found on system at: /opt/ghc/7.6.3/bin/ghc-pkg Using hsc2hs version 0.67 found on system at: /opt/ghc/7.6.3/bin/hsc2hs ... but all of those are version specific since they'll break if you remove their /usr/lib/ghc-version. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On Fri, Jul 31, 2015 at 2:32 PM, Evan Laforge qdun...@gmail.com wrote: On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Btw, I simply prepend to the $PATH env variable, or pass the appropriate executable name to `cabal`'s -w --with-compiler=PATHgive the path to a particular compiler I don't understand, aren't they all in /usr/local/bin? Or do you use a version-specific prefix when installing each ghc version? You can specify just the executable name, in which case cabal will search $PATH; or specify an absolute or relative path. So cabal install -w ghc-7.10.2 cabal install -w ghc-7.8.4 cabal install -w $HOME/my-ghc-checkout/inplace/bin/ghc-stage2 I install the binary distributions with --prefix=$HOME, so that the binaries all end up in ~/bin and I can invoke the version I want easily in this fashion. The only thing I find missing is the ability to install a binary distribution without overwriting the existing symlinks (e.g. ghc - ghc-7.8.4). Regards, Reid Barton ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
[...] The only thing I find missing is the ability to install a binary distribution without overwriting the existing symlinks (e.g. ghc - ghc-7.8.4). I second the OP's request and Reid's one: I think the binary distributions for *nices should neither contain unversioned executables nor should they try to link these to the versioned ones for themselves. This is exactly what update-alternatives is for, and it does it in a very principled, standard way everyone understands (or can at least look up :-). Death to the not-invented-here syndrome! :-D ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On Fri, Jul 31, 2015 at 11:42 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Sorry, I assumed this w/o saying; I maintain and use myself https://github.com/hvr/multi-ghc-travis Ah, I see. I agree your approach is more principled in that it's local rather than modifying global state. In practice, though, my way of relinking the symlinks is simple and has worked well enough for my modest needs. And for me, the global modification is actually what I want. But it also sounds like this is also demonstrating the everyone creates their own solution that I was suggesting might be happening. I didn't know about the cabal cleverness, but it wouldn't be that useful for me since I don't use cabal. While cabal is useful, I don't think we should delegate low level functionality to it such that you can't use ghc without also committing to its not-a-build-system build system. Given that modifying global /usr/local state is the way that ghc installation (along with unix installation in general) works, wouldn't it still make sense to be more consistent about the binary names to make switching versions or uninstalling less error-prone? As far as shipping with scripts for versioning and uninstallation, I still think it makes sense to have a simple built-in way. I know I've seen a few versions of the library uninstall script floating around, so I can't be the only one. I seem to recall the OS X platform install had some uninstall or version switching scripts, but specialized to the OS X directory layout. Switching to a more principled scheme where you have truly local versions sounds like a much more ambitious task... eventually winding up with nix and plan9 style local mounts... or something. It's a worthy goal but more difficult than renaming a few binaries. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
Evan Laforge wrote: The recent release of ghc 7.10.2 reminded me of something I meant to ask about a long time ago. Most of the binaries ghc installs are versioned (x linked to x-7.10.2), with some exceptions (hpc and hsc2hs). Shouldn't they all be versioned? Also, 'haddock' is inconsistent with all the rest, in that it's haddock linked to haddock-ghc-7.10.2. I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have: * ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/ To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC. I actually have a shell function to to do this PATH mangling. I can document this more fully if anyone is interested. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
Wolfram Kahl wrote: I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. I install cabal-install from debian which just puts it in /usr/bin/ which works fine, with and without sandboxes. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I have not run into this problem with ghc-7.6.3, ghc-7.8.4 and ghc-7.10.2 installed. I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. With a recent version of cabal, run 'cabal user-config diff' to display what if different between your ~/.cabal/config and what cabal would install if it didn't exist. Sometimes an older ~/.cabal/config file can cause troubles. Cheers, Erik PS: Please reply to the list and do not CC me. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On Sat, Aug 01, 2015 at 06:31:38AM +1000, Erik de Castro Lopo wrote: I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have: * ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/ To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC. I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. It would be nice if cabal-install had an installation-time option to set its prefix directory FOR EVERYTHING. The best cludge I found was scripts /usr/lib/ghc-*/bin/mycabal that call /usr/lib/ghc-*/bin/cabal with appropriate options... Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
