On 12/10/2009 08:17, Philip Weaver wrote:

On Sun, Oct 11, 2009 at 1:41 PM, Ian Lynagh mailto:igloo@earth.li> wrote:

Hi all,

We are pleased to (finally!) announce the first release candidate for GHC 6.12.1:

http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ http://darcs.haskell.org/%7Eghc/dist/6.12.1rc1/

As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs.

Please test as much as possible; bugs are much cheaper if we find them before the release!

Thanks! I have been eager to try out 6.12. Unlike many of the recent snapshots, this one built and installed fine on Mac OS X 10.6 :).

Is there an extralibs tarball that I should use with this? I installed the release candidate without said tarball. First, I noticed that my old version of cabal-install could not parse the output from ghc-pkg-6.12.0.20091010:

cabal: failed to parse output of 'ghc-pkg dump'

Yes, work is in progress on cabal-install to update it to work with GHC 6.12.1. For now you have to use Cabal manually (runhaskell Setup configure, etc.).

Then, when I tried to build the network package manually, I got this:

Building network-2.2.1.4... [1 of 5] Compiling Network.URI ( Network/URI.hs, dist/build/Network/URI.o ) [2 of 5] Compiling Network.Socket.Internal ( dist/build/Network/Socket/Internal.hs, dist/build/Network/Socket/Internal.o ) [3 of 5] Compiling Network.Socket ( dist/build/Network/Socket.hs, dist/build/Network/Socket.o )

Network/Socket.hsc:1707:45: Not in scope: data constructor `System.Posix.Internals.Stream'

I think you may need the darcs version of the network package. Cheers, Simon

...

this one built and installed fine on Mac OS X 10.6 :). Interesting, I thought there were still problems there. I assume that's a 32-bit version. The problems manifest themselves only when you compile a 64-bit GHC.

I'm still trying to get mine working - no luck yet, but will keep you posted. Barney.

On Mon, Oct 12, 2009 at 9:17 AM, Philip Weaver wrote:

Then, when I tried to build the network package manually, I got this:

Building network-2.2.1.4... [1 of 5] Compiling Network.URI      ( Network/URI.hs, dist/build/Network/URI.o ) [2 of 5] Compiling Network.Socket.Internal ( dist/build/Network/Socket/Internal.hs, dist/build/Network/Socket/Internal.o ) [3 of 5] Compiling Network.Socket   ( dist/build/Network/Socket.hs, dist/build/Network/Socket.o )

Network/Socket.hsc:1707:45:     Not in scope: data constructor `System.Posix.Internals.Stream'

Please try the darcs version at http://code.haskell.org/network. If that builds fine I can make a new release of network shortly. Cheers, Johan

Hello Simon, Monday, October 12, 2009, 12:32:05 PM, you wrote:

Release notes here, for now: http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1...

1. it says

The following options are all described in Section 4.15.3, “RTS options to control the garbage collector”. * The flag +RTS -N now automatically determines how many threads to use, based on the number of CPUs in your machine.

actually -N is decribed in "4.13.2. RTS options for SMP parallelism" also, i propose to enable +RTS -N by default. Haskell is very popular as multithreaded language, don't fool novices!

"The -gn RTS option has been removed, except that -g1 is still accepted for backwards compatibility. "

why not ignore whole option for a 6.12.*? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Mon, 2009-10-12 at 13:07 +0400, Bulat Ziganshin wrote:

also, i propose to enable +RTS -N by default. Haskell is very popular as multithreaded language, don't fool novices!

Note that you'd also have to enable -threaded by default. This would have other surprising effects (like breaking most GUI progs). Duncan

On Mon, 2009-10-12 at 19:29 +0400, Bulat Ziganshin wrote:

Hello Duncan,

Monday, October 12, 2009, 6:58:43 PM, you wrote:

...

...

also, i propose to enable +RTS -N by default. Haskell is very popular as multithreaded language, don't fool novices!

...

Note that you'd also have to enable -threaded by default. This would have other surprising effects (like breaking most GUI progs).

afair, it's on by default for a few years

With runghc and ghci you get the threaded rts by default. For compiled standalone programs the single threaded rts is still the default. You have to link using the -threaded flag to get the threaded rts.

and yes, i had SERIOUS problems with it in my GUI program :)

Yeah, it's a long-standing tricky issue. Duncan

On Mon, Oct 12, 2009 at 11:31:41PM +0200, Ben Franksen wrote:

...

http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1...

In section 1.5.2. Warnings there is a duplication:

Thanks for the report; fixed. Thanks Ian

On 12/10/2009 13:12, Christian Maeder wrote:

This new version of ghc can no longer read ISO-8859 text. Text is cut off after the first non-ascii character (ie. ¢).

Is this somewhere documented? What is the recommended way to handle such text?

Take a look at this: http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know... and if you have any more questions, please post them here. Cheers, Simon

On Mon, 2009-10-12 at 18:43 +0200, Christian Maeder wrote:

P.S. I wonder why "Registering" is done twice

It's Cabal's fault. It's a new feature to let components within a package depend on each other. To do that it needs to register the lib into a local inplace package db. At the moment it's always doing it, even when it's not strictly necessary. At some point we'll probably tidy that up so that it only does so when it's needed. On the other hand, always doing so during the testing phase has already caught a couple configuration bugs so I'm not in any great rush to add the optimisation. Duncan

2009/10/23 Andrea Vezzosi :

On Mon, Oct 12, 2009 at 6:43 PM, Christian Maeder

...

I get the following "internal Haddock or GHC error". I have no file /local/maeder/lib/ghc-6.12.0.20091010/html/haddock.css but a file /local/maeder/share/doc/ghc/html/html/haddock.css

I've the same problem, it seems that haddock's data-files are not installed anywhere by ghc's build system, even if they are present in the tarball under utils/haddock.

I think this is http://hackage.haskell.org/trac/ghc/ticket/3599 which was apparently fixed a few days ago by Ian. Jens

Brent Yorgey wrote:

What's the canonical way to install a version of ghc but not have it be the default? i.e., I'd like to try testing this release candidate but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' etc. to still be aliases to ghc-6.10.4, instead of being overwritten by the 6.12.1 install.

AFAIK think the answer is: compile from source and use --prefix option to ./configure. Cheers Ben

On Mon, Oct 12, 2009 at 04:04:23PM -0400, Brent Yorgey wrote:

What's the canonical way to install a version of ghc but not have it be the default? i.e., I'd like to try testing this release candidate but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg' etc. to still be aliases to ghc-6.10.4, instead of being overwritten by the 6.12.1 install.

If you want to install the OSX .pkg then I don't know of a way to do this. Installing one seems to uninstall the previous one for no good reason. If you're installing the Windows installer then you can choose the installation directory, but you'll have to make the aliases yourself. If you're installing one of the Linux bindists then you can use ./configure --prefix=/your/path and again you will have to set up the aliases yourself. And if installing from source you can likewise use ./configure --prefix=/your/path and set up aliases yourself. Thanks Ian

On Tue, Oct 13, 2009 at 01:17:16PM +0100, Nils Anders Danielsson wrote:

On 2009-10-13 08:58, Ian Lynagh wrote:

...

If you're installing one of the Linux bindists then you can use ./configure --prefix=/your/path and again you will have to set up the aliases yourself.

And if installing from source you can likewise use ./configure --prefix=/your/path and set up aliases yourself.

I install GHC under /usr/local/stow/ghc-<version>/, and use Stow (http://www.gnu.org/software/stow/) to create symlinks to my preferred version from /usr/local/….

Fantastic! I'd never heard of stow before. -Brent

On Mon, Oct 12, 2009 at 05:49:17PM -0700, Alexander Dunlap wrote:

When compiling, I get lots of "No such file or directory" errors. The compilation process continues, but should I be concerned about this?

It's normal to get this for various *.mk files, *.depend* files, etc. Thanks Ian

On 14/10/2009 04:43, Antoine Latter wrote:

On Sun, Oct 11, 2009 at 3:41 PM, Ian Lynagh wrote:

...

Hi all,

We are pleased to (finally!) announce the first release candidate for GHC 6.12.1:

http://darcs.haskell.org/~ghc/dist/6.12.1rc1/

As well as the source tarball: ghc-6.12.0.20091010-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs.

Please test as much as possible; bugs are much cheaper if we find them before the release!

Here is my tale of woe. I'm running this on Mac OS X 10.6.

I tried to install the syb-with-class package off of hackage, which initially failed because of the changes to the template-haskell package installed with 6.12.1rc1.

So I think to myself "Oh! I'll just put an upper bound on the version of template-haskell used in the .cabal file for syb, and install the old version off of hackage".

The current version of template-haskell installs fine on 6.12.1rc1 with a couple minor tweaks (to compensate for StringConstr not being present in Data.Data anymore).

But then when I try to build syb-with-class against the old template-haskell lib I get the following error:

...

...

...

...

...

$ ./Setup build Preprocessing library syb-with-class-0.5.1... Building syb-with-class-0.5.1... [3 of 4] Compiling Data.Generics.SYB.WithClass.Derive ( Data/Generics/SYB/WithClass/Derive.hs, dist/build/Data/Generics/SYB/WithClass/Derive.o )

Data/Generics/SYB/WithClass/Derive.hs:23:0: Bad interface file: /Users/alatter/.cabal/lib/template-haskell-2.3.0.1/ghc-6.12.0.20091010/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.3.0.1:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH <<<<<

Has anyone seen this before? Are there any tools I can use to peer into .hi files to get more information about what could be wrong?

template-haskell is a one of the packages that we call "wired-in", because GHC needs to generate references to some of the things that it defines. To make GHC independent of the version of the template-haskell package, we internally strip off the version number when referring to template-haskell. Now, this doesn't completely explain the error you're seeing. When it starts up, GHC has to decide which template-haskell package is the "wired-in" one, and my guess is that it picked the other one (because it is newer). You could find out by running GHC with the -v flag. I think GHC is assuming that when you have multiple versions of a wired-in package that the older ones are wrappers around the newer ones (like base-3 and base-4), but that assumption doesn't hold in your case. Installing a new version of a wired-in package is going to be problematic, but we ought to be able to at least improve the diagnostics. Cheers, Simon

On Sat, Nov 7, 2009 at 8:20 AM, Ian Lynagh wrote:

On Sun, Oct 18, 2009 at 03:20:21PM -0500, Antoine Latter wrote:

...

Note that what was spliced in as [] is now being spliced in as "", which is incorrect.

This has been filed as    http://hackage.haskell.org/trac/ghc/ticket/3600 and fixed.

Thanks for the quick fix - I've been running with the patch and have happstack going with minimal changes (entirely TH related, I think). Antoine