February 2013 - ghc-devs

Unicode support for Haddock
by Max Bolingbroke 10 Mar '13

10 Mar '13

Hi GHCers, I recently ran into a problem where Haddock does not correctly handle Unicode in doc comments. So for example with this file: """ module Example where -- | 好 ok :: Int -> Int ok x = x -- | 个 misinterp :: Int -> Int misinterp _ = (-1) -- | 漢 failure :: Int -> Int failure x = x-1 """ Current versions of Haddock will output the documentation for "ok" correctly, will output an empty bulleted list as the documentation for "misinterp" and not output any documentation at all for "failure" (echoing a warning to stderr instead). This is kind of sad. There is a very old open ticket about this issue: http://trac.haskell.org/haddock/ticket/20. The patches I've attached to that ticket fix the problem by using the native Unicode support in Alex 3. I've also attached to the ticket a patch which makes the necessary changes to GHC's build system required to build this new Haddock correctly. Do these patches seem OK? Is it fine to insist on Alex 3? I think it was released in 2011 so I think by now we can assume that it is available on all machines that will want to build GHC. If this patch is accepted, at some point we might want to think about switching to Alex 3's unicode support in GHC's own lexer rather than relying on the current hacks. My patches do not make any change along those lines. Cheers, Max

3 3

Trac source browser not working
by Simon Marlow 09 Mar '13

09 Mar '13

I tried to follow a link to a commit on Trac today, and got an error: internal error (got unexpected object kind 'commit') The link I followed: http://hackage.haskell.org/trac/ghc/changeset/109a1e53287f50103e8a5b5922759… This was working before, has anything changed recently that would break it? I tried browsing to a couple of other commits and got the same error, so it doesn't seem specific to that commit. Cheers, Simon

3 2

FW: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, especially arrow "forms" (49badc9)
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

Ross I've pushed a new branch, tc-arrows, for the new typechecking of arrows, based on the discussion we had last week. It all compiles, but won't work because I have done nothing to the desugaring. It uses our new representation with (env, nested-tuple-with-unit-at-end) rather than (nested-tuple-with-env-at-the-end), so desugaring needs significant attention. Would you like to work on the desugarer? I'm out of my depth, but happy to advise. Thanks Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Simon Peyton Jones | Sent: 14 February 2013 16:08 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, | especially arrow "forms" (49badc9) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : tc-arrows | | http://hackage.haskell.org/trac/ghc/changeset/49badc91c52fc1f65a3ff5bfb3 | edaecbd617de61 | | >--------------------------------------------------------------- | | commit 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Thu Feb 14 15:25:23 2013 +0000 | | Rearrange the typechecking of arrows, especially arrow "forms" | | The typechecking of arrow forms (in GHC 7.6) is known to be bogus, | because it marches down tuple types that may not yet be fully worked | out, depending on when constraint solving happens. Moreover, | coercions are generated and simply discarded. The fact that it | works | at all is a miracle. | | This refactoring is based on a conversation with Ross, where we | rearranged the typing of the argument stack, so that the arrows | have the form | a (env, (arg1, (arg2, ...(argn, ())))) res | rather than | a (arg1, (arg2, ...(argn, env))) res | as it was before. | | This is vastly simpler to typecheck; just look at the beautiful, | simple type checking of arrow forms now! | | We need a new HsCmdCast to capture the coercions generated from | the argument stack. | | Current state of play: | * syntax done | * renamer done | * typechecker done | * desugarer NOT DONE | | So nothing will work yet, hence on a branch | | compiler/deSugar/Coverage.lhs | 3 + | compiler/deSugar/DsArrows.lhs | 6 +- | compiler/hsSyn/HsExpr.lhs | 13 ++- | compiler/hsSyn/HsUtils.lhs | 7 +- | compiler/parser/Parser.y.pp | 4 +- | compiler/parser/RdrHsSyn.lhs | 4 +- | compiler/rename/RnExpr.lhs | 4 +- | compiler/rename/RnTypes.lhs | 2 +- | compiler/typecheck/TcArrows.lhs | 270 ++++++++++++++++++-------------- | ------- | compiler/typecheck/TcHsSyn.lhs | 6 +- | 10 files changed, 156 insertions(+), 163 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

missing darcs repos?
by Malcolm Wallace 02 Mar '13

02 Mar '13

Hello, Has someone recently removed the (old) darcs repos for libraries from e.g. http://darcs.haskell.org/packages/array etc? My nightly builds of nhc98 have recently started failing because this is (and no doubt others are) missing. It is not a disaster, since I can start publishing the most recent state of these repos myself, but I just wanted to check that the removal was intentional. I con't recall any specific email about it, although I admit I do not keep up very well with mailing list traffic these days. Regards, Malcolm

2 2

RE: libtoolize
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

Is this new? Does it matter? Can I ignore it? Does everyone now need to install a new tool? I'm not sure how to "install libtool on my linux". (I thought we'd been using libtool, whatever it is, for years, so I'm puzzled why this has just started to happen.) Simon | -----Original Message----- | From: Karel Gardas [mailto:karel.gardas@centrum.cz] | Sent: 27 February 2013 11:18 | To: Simon Peyton-Jones | Subject: Re: libtoolize | | | Simon, | | those messages should go away if you install libtool package on your linux. | | Cheers, | Karel | | On 02/27/13 11:17 AM, Simon Peyton-Jones wrote: | > I've started to get this when I say "sh validate". What's up? | > | > Simon | > | > Booting . | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > Booting libraries/base/ | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs

3 7

Fwd: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable
by José Pedro Magalhães 01 Mar '13

01 Mar '13

Hi Simon, How should an instance of Typeable for a polykinded tycon look like? E.g. if we have data Proxy (a :: k) = Proxy -- Proxy :: forall (k :: BOX). k -> * I suppose we want an instance forall k. instance Typeable (k -> *) (Proxy k) Right? So the universally quantified kind variables of the tycon should end up universally quantified in the instance as well. How does this translate to the ds_tvs, ds_tys, and ds_tc_args arguments of a DerivSpec?... Thanks, Pedro ---------- Forwarded message ---------- From: GHC <cvs-ghc(a)haskell.org> Date: Mon, Feb 18, 2013 at 8:42 PM Subject: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable To: Cc: ghc-tickets(a)haskell.org #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This test program, reduced from an attempt to bring ekmett's tagged package to HEAD, {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} newtype Tagged s b = Tagged { unTagged :: b } }}} results in {{{ GHCi, version 7.7.20130218: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( typeable.hs, interpreted ) typeable.hs:5:1: Derived typeable instance must be of form (Typeable Tagged) In the stand-alone deriving instance for `Data.Typeable.Internal.Typeable Tagged' }}} This message is also emitted if I replace `AutoDeriveTypeable` `StandaloneDeriving` and `deriving instance Typeable Tagged`. However, a "deriving (Typeable)" clause on the newtype definition works just fine. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets

2 2

RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 01 Mar '13

01 Mar '13

Hi all, from what I gathered so far no emission of write barriers is needed when - running on a uniprocessor (-threaded or not) - running on a multiprocessor sans having linked with -threaded. Below patch suppresses the emission of 'lwsync' when no '-threaded' is specified on PPC only. So it does not cover both criteria above. It helps me a lot since I have a uniprocessor target that does not understand the 'lwsync' instruction (instruction is newer than core). Still, I have some doubts: o do we want to extend this approach to other archs? o possibly suppress the emission of MO_WriteBarrier in compiler/codeGen/StgCmmBind.hs (more care is needed to also cover compiler/cmm/CmmParse.y). Anyway this should be a safe first step, and I'd like to push it. When we find a general solution be can back this commit out. What do you think? Cheers, Gabor $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Feb 22 18:47:00 2013 +0100 Do not emit barriers on PPC unless we go the threaded way diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 92eff36..6c33cca 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -1,9 +1,8 @@ - ----------------------------------------------------------------------------- -- -- Generating machine code (instruction selection) -- --- (c) The University of Glasgow 1996-2004 +-- (c) The University of Glasgow 1996-2013 -- ----------------------------------------------------------------------------- @@ -906,8 +905,10 @@ genCCall' -} -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ - = return $ unitOL LWSYNC +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ + = return (if WayThreaded `elem` ways dflags + then unitOL LWSYNC + else nilOL) genCCall' _ _ (PrimTarget MO_Touch) _ _ = return $ nilOL

3 8

Confusing commit messages about `type-nats`?
by Iavor Diatchki 28 Feb '13

28 Feb '13

Hello, I am receiving a bunch of commit messages for branch `type-nats`, that seem to be fake (i.e., by folks committing to other branches). Does any one know why that is? It seems to have started after my merge commit from yesterday, so did I mess something up? -Iavor

3 3

Build errors on HEAD
by Jan Stolarek 28 Feb '13

28 Feb '13

I get this error when building HEAD (8fe04eb): utils/ghc-pkg/Main.hs:881:3: No instance for (Bin.Binary (InstalledPackageInfo_ String)) arising from a use of `writeBinaryFileAtomic' Possible fix: add an instance declaration for (Bin.Binary (InstalledPackageInfo_ String)) In the first argument of `catchIO', namely `writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db))' In a stmt of a 'do' block: writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e In the expression: do { let filename = location db </> cachefilename; when (verbosity > Normal) $ infoLn ("writing cache " ++ filename); writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e } Anyone else getting this or is it just me? Janek

1 0

RE: [commit: base] master: Change rules for RealFrac methods to pointfree, so that they can also fire in pointfree use. (4036a1a)
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

I followed the link e http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e361… but got No handler matched request to /changeset/4036a1ae7a9694c9c69749ec8e36143c31bce976 I wonder why? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Daniel Fischer | Sent: 27 February 2013 13:58 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Change rules for RealFrac methods to pointfree, | so that they can also fire in pointfree use. (4036a1a) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e36 | 143c31bce976 | | >--------------------------------------------------------------- | | commit 4036a1ae7a9694c9c69749ec8e36143c31bce976 | Author: Daniel Fischer <daniel.is.fischer(a)googlemail.com> | Date: Wed Feb 13 16:10:12 2013 +0100 | | Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. | | GHC/Int.hs | 96 +++++++++++++++++++++++++++++------------------ | ----------- | GHC/Word.hs | 72 ++++++++++++++++++++++---------------------- | 2 files changed, 84 insertions(+), 84 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 4036a1ae7a9694c9c69749ec8e36143c31bce976 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1