On 21/12/2011 22:36, Roman Cheplyaka wrote:

* Ian Lynagh [2011-12-21 18:29:21+0000]

...

* The profiling and hpc implementations have been merged and overhauled. Visible changes include renaming of profiling flags: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-reference.... and the cost-centre stacks have a new semantics, which should in most cases result in more useful and intuitive profiles. The +RTS -xc flag now also gives a stack trace.

Where can we learn more about the new semantics?

I haven't writtne down the semantics formally yet, I'm afraid, and it may yet change. However, you should find that the changes give more intuitive results, and profiling is now more robust to compiler optimisations. There are a few visible changes. One is that -auto-all will label nested functions by default now (but you can revert to the previous behaviour of labelling only top-level functions with -fprof-auto-top). Another visible change is that higher-order functions are now pushed on the stack when they are called, not when they are referenced. For example, in "map f xs" you will see that map calls f, whereas previously f would be shown as a child of the function containing the call to map (sometimes!). This also means that the costs of a calling a higher-order function are always part of the aggregate costs of the caller, rather than being attributed to the higher-order function itself. For example, if you have f xs ys = {-# SCC "map1" #-} map g xs ++ {-# SCC "map2" #-} map g ys where g = ... then you'll see that map1 calls g and map2 calls g, and the costs of calling g on the elements of xs are recorded separately from the costs of calling g on the elements of ys. Previously all the costs of g would be attributed to g itself, which is much less useful. I'd be interested in hearing feedback, particularly if you find a case where costs are attributed somewhere that you didn't expect, or the stack looks wrong. Cheers, Simon

On 03/01/2012 16:54, Tristan Ravitch wrote:

This might be the expected behavior but I'll ask anyway. I have what seems to be a legitimate stack overflow (due to excessive recursion and not the evaluation of a big thunk). The stack trace from -xc only shows about 13 calls on the stack (with each function that is called only appearing once).

Is it by design that functions only appear once?

Yes, and this is the area where things might change. We have to somehow make the stack finite, otherwise the data structure storing the stack would fill up the memory. Here are a few options: A) On a recursive call, truncate the stack to the previous instance of the call B) On a recursive call, do not push anything on the stack C) On a recursive call, elide some previous entries in the stack (e.g. replacing them with "...") Currently we're doing a variant of A, which is good for profiling because it means that the cost of a function call is always attributed to a stack with that function at the top. However, A doesn't satisfy all the properties we need, so certain compiler transformations aren't valid. The only option that has the right properties is B, but that isn't so useful for profiling. C is more useful for stack traces, because there is more information towards the top of the stack - the last few calls are correct, but information deeper down the stack is lost. This is what Tristan Allwood used in his "Finding the Needle" paper. Unfortunately C doesn't have the right transformational properties either. Cheers, Simon

On 17/01/2012 09:30, Roman Cheplyaka wrote:

* Simon Marlow [2012-01-03 11:00:58+0000]

...

I'd be interested in hearing feedback, particularly if you find a case where costs are attributed somewhere that you didn't expect, or the stack looks wrong.

What I often find counter-intuitive is how the 'entries' count is computed.

Sometimes I see 0 entries for some SCC while its children have non-zero entries counts. I guess this has to do with inlining? Still, I don't see why it should be so -- if it's possible to compute metrics like time and allocations for such an SCC, why shouldn't it be possible to compute entries?

Another case is when a function has a large number of entries, although in reality it's entered only once (I can confirm that using trace, for example). My guess would be that its SCC got inherited by some recursive function, but again, this is very confusing.

And because of things like that, I don't usually trust the entries counts even when they look realistic.

I observe this with GHC 7.0.3. Do you think this was improved in GHC 7.4.1?

This is improved a *lot* with 7.4.1. In fact, we know for sure that it was completely broken before that. Please try with 7.4.1 and let me know if you still find anything strange. Cheers, Simon

(Unfortunately, it's going to be hard to make a minimal test case, and it's also not trivial to simply test with a newer GHC. But if you say there's a chance, I'll put effort into that.)

On Thu, Dec 22, 2011 at 05:44, Conor McBride wrote:

under Leopard, and got this far

bash-3.2$ sudo ./configure Password: checking for path to top of build tree... dyld: unknown required load command 0x80000022 configure: error: cannot determine current directory

I'd expect that on Leopard. Unless someone does a Leopard-specific build, I suspect you're out of luck.

I don't really know what this means. I'm kind of expecting that I have

Apple adds new stuff to its dynamic loader in every OS release, and the result usually isn't compatible with earlier releases by default, in my experience (that'd be from Tiger through Lion at this point). You need to specify an ABI compatibility level to build stuff that will run on older releases, including just being understood by dyld. Part of the problem here is that a default Xcode 4.x install only includes the 10.6 and 10.7 SDKs. I'm not seeing any way to customize the install, so it looks like Xcode 4 cannot be used to build for Leopard; someone will have to do the Leopard-compatible build on Leopard or on Snow Leopard with Xcode 3.6. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 22 Dec 2011, at 16:08, Sean Leather wrote:

I've built it from source (ghc-7.4.0.20111219-src.tar.bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do.

I hope somebody who knows does just that. Meanwhile, that sounds good to try for myself. My flat's a bit on the chilly side... Cheers Conor

On Thu, Dec 22, 2011 at 22:25, Conor McBride wrote:

On 22 Dec 2011, at 16:08, Sean Leather wrote:

...

I've built it from source (ghc-7.4.0.20111219-src.tar.**bz2) on Leopard. I'd be happy to contribute my build if somebody tells me what to do.

I had a crack at this and got quite warm, literally and metaphorically. But, no, I didn't quite get there. And yes, it's some sort of libraries issue. Here's the barf...

make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -O -package-name integer-gmp-0.4.0.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-**install/build -ilibraries/integer-gmp/dist- **install/build/autogen -Ilibraries/integer-gmp/dist-**install/build -Ilibraries/integer-gmp/dist-**install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/** dist-install/build/autogen/**cabal_macros.h -package ghc-prim-0.2.0.0 -package-name integer-gmp -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XNoImplicitPrelude -XForeignFunctionInterface -XUnliftedFFITypes -O2 -no-user-package-conf -rtsopts -odir libraries/integer-gmp/dist-**install/build -hidir libraries/integer-gmp/dist-**install/build -stubdir libraries/integer-gmp/dist-**install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc libraries/integer-gmp/dist-**install/build/GHC/Integer.dyn_* *o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/GMP/**Prim.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Logarithms/Internals.dyn_o libraries/integer-gmp/dist-**install/build/GHC/Integer/**Type.dyn_o libraries/integer-gmp/dist-**install/build/cbits/gmp-**wrappers.dyn_o libraries/integer-gmp/dist-**install/build/cbits/cbits.dyn_**o libraries/integer-gmp/gmp/**objs/*.o -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-7.4.0.**20111219/`basename "libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib" | sed 's/^libHS//;s/[-]ghc.*//'`/`* *basename "libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib"` -no-auto-link-packages -o libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/**objs/add.o and libraries/integer-gmp/gmp/**objs/abs.o collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-**install/build/libHSinteger-** gmp-0.4.0.0-ghc7.4.0.20111219.**dylib] Error 1 make: *** [all] Error 2

...which makes me wonder just what I need to delete.

I'm not sure, but gmp is often a problem. You can try using my configure arguments. I create a script configure.mine that calls configure with my preferred prefix and gmp library. $ cat configure.mine VERSION=7.4.0.20111219 ./configure \ --prefix=/Library/Frameworks/GHC.framework/Versions/$VERSION/usr \ --with-gmp-libraries=/Library/Frameworks/GMP.framework \ --with-gmp-includes=/Library/Frameworks/GMP.framework/Headers I use the GMP.framework that is installed with the Haskell Platform. The prefix is just a convenient location that allows me to change a symlink to switch between GHC versions. Regards, Sean

Hi Bas, On Wed, Dec 21, 2011 at 23:02, Bas van Dijk wrote:

On 21 December 2011 19:29, Ian Lynagh wrote:

...

* There is a new feature constraint kinds (-XConstraintKinds):

http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind...

I'm trying to run the ConstraintKinds example from the documentation:

{-# LANGUAGE ConstraintKinds, TypeFamilies #-} type family Typ a b :: Constraint type instance Typ Int b = Show b type instance Typ Bool b = Num b

But GHC complains: Not in scope: type constructor or class `Constraint'

Do I have to import some GHC module for this?

Yes: GHC.Prim. (Which reminds me, Simon, we had agreed to re-export Constraint from GHC.Exts, but it wasn't clear to me how to do this, since Constraint is a kind, not a type, so it can't just go on the export list of the module...) Cheers, Pedro

Cheers,

Bas

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Am Donnerstag, den 22.12.2011, 00:02 +0100 schrieb Bas van Dijk:

On 21 December 2011 19:29, Ian Lynagh wrote:

...

* There is a new feature constraint kinds (-XConstraintKinds): http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind...

I'm trying to run the ConstraintKinds example from the documentation:

{-# LANGUAGE ConstraintKinds, TypeFamilies #-} type family Typ a b :: Constraint type instance Typ Int b = Show b type instance Typ Bool b = Num b

But GHC complains: Not in scope: type constructor or class `Constraint'

By the way, is there a reason behind the fact that “Constraint” uses the ordinary case, while “BOX” has all three letters capitalized? Wouldn’t it be more sensible if it were “Box” instead of “BOX”? Things like capitalization might not seem very important first, but unfortunately, decisions about them seem to persist. Best wishes, Wolfgang

Am Mittwoch, den 28.12.2011, 12:48 +0000 schrieb Simon Peyton-Jones:

| By the way, is there a reason behind the fact that “Constraint” uses the | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t | it be more sensible if it were “Box” instead of “BOX”?

Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users.

Okay, this makes sense then. However, note that the GHC User’s manual mixes the terminology (“kind” vs. “sort”) at one point: Note that List, for instance, does not get kind BOX -> BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphi... I think, it should say “sort BOX -> BOX”. Best wishes, Wolfgang

I've pushed a patch to the docs. Thanks S From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of José Pedro Magalhães Sent: 28 December 2011 15:08 To: Wolfgang Jeltsch Cc: glasgow-haskell-users@haskell.org Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1 Hi Wolfgang, On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch mailto:g9ks157k@acme.softbase.org> wrote: Am Mittwoch, den 28.12.2011, 12:48 +0000 schrieb Simon Peyton-Jones:

| By the way, is there a reason behind the fact that "Constraint" uses the | ordinary case, while "BOX" has all three letters capitalized? Wouldn't | it be more sensible if it were "Box" instead of "BOX"?

Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User's manual mixes the terminology ("kind" vs. "sort") at one point:

Note that List, for instance, does not get kind BOX -> BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphi... I think, it should say "sort BOX -> BOX". Yes, it should indeed say "sort", not "kind". If you know of any other places in the documentation with this type/kind/sort of inconsistency, please let me know :-) Cheers, Pedro Best wishes, Wolfgang _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Lauri wrote:

Sorts are typically constants, and there are usually a finite amount of them, each presenting a "level" of the type system.

Indeed. The literature on generic programming sometimes uses the term "superkind" to refer to the sort of BOX; see, for example, Ralf Hinze and Johan Jeuring. Generic Haskell: Applications. In Roland Carl Backhouse and Jeremy Gibbons, editors, Generic Programming: Advanced Lectures, volume 2793 of Lecture Notes in Computer Science, pages 57–96. Springer-Verlag, 2003. Cheers, Stefan

Yes, it's expected; it's also the behaviour of GHC 6.12 etc. Here what is happening. You define result = undefined What type does it get? In 6.12, and 7.4, it gets type result :: forall b. b So the two uses of 'result' in the two branches of the case have no effect on each other. But in 7.2 it was *not generalised*, so we got result :: f2 a And now the two uses *do* affect each other. Why the change. You'll remember that over the last year GHC has changed not to generalise local lets: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 I relaxed the rule in 7.2, as discussed in "Which bindings are affected?" in that post. For reasons I have not investigated, 7.2 *still* doesn't generalise 'result'; but 7.4 correctly does. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Antoine Latter | Sent: 23 December 2011 04:21 | To: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1 | | On Wed, Dec 21, 2011 at 1:29 PM, Ian Lynagh wrote: | > | > We are pleased to announce the first release candidate for GHC 7.4.1: | > | >    http://www.haskell.org/ghc/dist/7.4.1-rc1/ | > | > This includes the source tarball, installers for OS X and Windows, and | > bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. | > | > Please test as much as possible; bugs are much cheaper if we find them | > before the release! | > | | Hurrah! | | The following used to compile with GHC 7.2.1: | | >>>>> | {-# LANGUAGE RankNTypes, TypeFamilies, GADTs #-} | | import Data.Typeable ( Typeable1, gcast1, typeOf1 ) | | cast1 :: (Typeable1 f1, Typeable1 f2) => f1 a -> f2 a | cast1 val | = case gcast1 (Just val) of | Just (Just typed_val) -> typed_val `asTypeOf` result | Nothing -> error $ "Invalid cast: " ++ tag ++ " -> " ++ show | (typeOf1 result) | where result = undefined | tag = show (typeOf1 val) | | main = putStrLn "Hello, world!" | <<<<< | | But with GHC 7.4.1 RC 1 I get the error: | | >>>>> | BugDowncast.hs:9:69: | Ambiguous type variable `t0' in the constraint: | (Typeable1 t0) arising from a use of `typeOf1' | Probable fix: add a type signature that fixes these type variable(s) | In the first argument of `show', namely `(typeOf1 result)' | In the second argument of `(++)', namely `show (typeOf1 result)' | In the second argument of `(++)', namely | `" -> " ++ show (typeOf1 result)' | <<<<< | | Is this an expected change, or should I create a ticket? | | Thanks, | Antoine | | > | > The release notes are not yet available, but here are some of the | > highlights of the 7.4 branch since 7.2 and 7.0: | > | >  * There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe): | >      http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/safe- | haskell.html | >    The design has changed since 7.2. | > | >  * There is a new feature kind polymorphism (-XPolyKinds): | >      http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind- | polymorphism-and-promotion.html | >    A side-effect of this is that, when the extension is not enabled, in | >    certain circumstances kinds are now defaulted to * rather than being | >    inferred. | > | >  * There is a new feature constraint kinds (-XConstraintKinds): | > |  http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint- | kind.html | > | >  * It is now possible to give any sort of declaration at the ghci prompt: | > |  http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/interactive- | evaluation.html#ghci-decls | >    For example, you can now declare datatypes within ghci. | > | >  * The profiling and hpc implementations have been merged and overhauled. | >    Visible changes include renaming of profiling flags: | >      http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag- | reference.html#id589412 | >    and the cost-centre stacks have a new semantics, which should in most | >    cases result in more useful and intuitive profiles. The +RTS -xc flag | >    now also gives a stack trace. | > | >  * It is now possible to write compiler plugins: | >      http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/compiler- | plugins.html | > | >  * DPH support has been significantly improved. | > | >  * There is now preliminary support for registerised compilation using | >    LLVM on the ARM platform. | > | > | > Note: The release candidate accidentally includes the random, primitive, | > vector and dph libraries. The final release will not include them. | > | > | > Thanks | > Ian, on behalf of the GHC team | > | > | > _______________________________________________ | > 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

| So the 'where' binding in the following does not get generalized | because it could not have been written at the top level, correct? The other way round. 'where' bindings that could have been written at top level *are* generalised; ones that could not are *not* generalised. See "Which bindings are affected?" in http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7, which tries to be precise. If it's hard to understand can I make it easier? Simon | | >>>>> | cast :: (Typeable a, Typeable b) => a -> Maybe b | cast x = r | where | r = if typeOf x == typeOf (fromJust r) | then Just $ unsafeCoerce x | else Nothing | <<<<< | | > Why the change. You'll remember that over the last year GHC has changed not | to generalise local lets: | http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 | > | > I relaxed the rule in 7.2, as discussed in "Which bindings are affected?" | in that post. For reasons I have not investigated, 7.2 *still* doesn't | generalise 'result'; but 7.4 correctly does. | > | > Simon

Dear GHC team, I tried to fix these problems myself, and three of the bugs had more or less trivial solutions (that hopefully are right): http://hackage.haskell.org/trac/ghc/ticket/5733 http://hackage.haskell.org/trac/ghc/ticket/5735 http://hackage.haskell.org/trac/ghc/ticket/5734 However, this makes this build failure appear on those arches as well:

...

ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.4.0.20111219 for sparc-unknown-linux): pprGlobalReg: Unsupported register: CCCS

http://hackage.haskell.org/trac/ghc/ticket/5732 It seems that unregistered builds are generally broken, and that this is not specific to exotic architectures. Are unregistered builds still supported? Is this likely to be fixed for 7.4.1? Please note that support for non-x86-arches is not just an academic exercise: For example, I have a NAS device with an arm CPU (a NSLU2) that happily runs git-annex¹, which is written in Haskell. I wonder if we can help you in general with keeping these arches supported, e.g. by setting up build bots for GHC. Would that be possible? What would need to be done for that? Would a virtual machine on (some of) these arches that you can manage yourself be helpful? I’m not sure what Debian can do here, but if I know the requirements, I can talk to the right people. Greetings, Joachim ¹ http://git-annex.branchable.com/ -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On 10/01/2012 10:58, Joachim Breitner wrote:

Dear GHC team (esp. Simon and Ian),

thanks for fixing the exotic-architecture-build-errors in time for 7.4.1, everything compiles smoothly now: https://buildd.debian.org/status/package.php?p=ghc&suite=experimental (Well, arm* and mips* are not done yet, as they need more than one day, but the others work so I am optimistic.)

That's good to hear, thanks for testing! Simon