- ghc-devs - Haskell.org

Bringing some observable sharing to GHCi
by David Feuer 02 Nov '17

02 Nov '17

The :sprint, :print, and :force commands in GHCi fall into infinite loops when confronted by cyclical data. This bit me hard in https://phabricator.haskell.org/D4085 because that produces cyclical TypeReps, which is trouble for (e.g.) the test break011 which tries to :force a SomeException (which wraps an Exception dictionary, which has a Typeable constraint). I could try coming up with a fix myself, but I'm rather curious whether some of the work you (or others) have already done on observing GHC data graphs could be yanked into GHCi itself for this purpose. We want 1. To be able to display cyclical data in some sensible way. > x = "hi" : x > x `seq` () > :print x should print some useful representation of x. 2. To be able to force cyclical data without looping. > x = "hi" : x > :force x should print a useful representation of x.

4 3

When does GHC produce unlifted `let` bindings?
by Sebastian Graf 02 Nov '17

02 Nov '17

Hi folks, I was debugging a Core-to-Core transform for TEST=spec-inline <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> and was wondering (yet again) why GHC produces unlifted `let` bindings in Core like it seems supposed to be doing <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> . - Why doesn't this use `case` instead? - Is there a semantic difference? - Can `case` be used with unlifted types? - And if not, why can `let`? Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem to agree. <https://github.com/ghc/ghc/search?l=Haskell&q=%22strict+let%22&type=&utf8=%…> Cheers, Sebastian

3 4

RE: Building the docs, again
by Andrey Mokhov 01 Nov '17

01 Nov '17

> Maybe Hadrian will help here? Hadrian can build documentation in various formats but the current implementation is very coarse-grain: we either build all possible docs or no docs at all. It would be relatively easy to add more fine-grain documentation targets and modes. If someone could design/describe the requirements in a ticket that would be great. Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 01 November 2017 08:28 To: Iavor Diatchki <iavor.diatchki(a)gmail.com>; ghc-devs(a)haskell.org; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: RE: Building the docs, again It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the end to inform me that it doesn't know what is `html`. Maybe Hadrian will help here? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Iavor Diatchki Sent: 31 October 2017 21:49 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Building the docs, again Hello, never mind, I figured it out---apparently the build targets were disabled for the `quick` flavor, which I was using. It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the end to inform me that it doesn't know what is `html`. -Iavor On Tue, Oct 31, 2017 at 2:26 PM Iavor Diatchki <iavor.diatchki(a)gmail.com<mailto:iavor.diatchki@gmail.com>> wrote: Hello, sometime ago, I asked if it is possible to build just the GHC docs, without building the compiler. I was told to just run `make html`. This does not appear to work, the command seems to just start building GHC. What am I doing wrong? Here is the output I see, running the command from the root of the GHC tree. > make html V=0 ===--- building phase 0 make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data…> phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data…> phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/BufWrite.o HC [stage 0] compiler/stage1/build/Pretty.o compilation IS NOT required HC [stage 0] compiler/stage1/build/PprColour.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Outputable.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Json.o compilation IS NOT required HC [stage 0] compiler/stage1/build/SrcLoc.o compilation IS NOT required HC [stage 0] compiler/stage1/build/BasicTypes.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Unique.o HC [stage 0] compiler/stage1/build/Packages.o-boot compilation IS NOT required HC [stage 0] compiler/stage1/build/FiniteMap.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Name.o-boot (then I interrupted it). Also, in `mk/config.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconfig.mk&d…>` I see this: BUILD_SPHINX_HTML = YES -Iavor

3 2

Building the docs, again
by Iavor Diatchki 01 Nov '17

01 Nov '17

Hello, sometime ago, I asked if it is possible to build just the GHC docs, without building the compiler. I was told to just run `make html`. This does not appear to work, the command seems to just start building GHC. What am I doing wrong? Here is the output I see, running the command from the root of the GHC tree. > make html V=0 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/BufWrite.o HC [stage 0] compiler/stage1/build/Pretty.o compilation IS NOT required HC [stage 0] compiler/stage1/build/PprColour.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Outputable.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Json.o compilation IS NOT required HC [stage 0] compiler/stage1/build/SrcLoc.o compilation IS NOT required HC [stage 0] compiler/stage1/build/BasicTypes.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Unique.o HC [stage 0] compiler/stage1/build/Packages.o-boot compilation IS NOT required HC [stage 0] compiler/stage1/build/FiniteMap.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Name.o-boot (then I interrupted it). Also, in `mk/config.mk` I see this: BUILD_SPHINX_HTML = YES -Iavor

2 2

[ANNOUNCE] GHC 8.2.2 release candidate 3
by Ben Gamari 31 Oct '17

31 Oct '17

Hello everyone, The GHC team is very pleased to announce the third candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc3/ This is the third and last of three release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. Release candidate three contains only two patches not present in -rc2 but fixes a packaging issue which lead to unintentional downgrading the process and Cabal libraries. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

1 0

Q: Types in GADT pattern match
by Gabor Greif 30 Oct '17

30 Oct '17

Hi Devs! I encountered a curious restriction with type signatures (tyvar bindings) in GADT pattern matches. GHC won't let me directly capture the refined type structure of GADT constructors like this: {-# Language GADTs, ScopedTypeVariables #-} data Foo a where Bar :: Foo [a] foo :: Foo a -> () foo b@(Bar :: Foo [a]) = quux b where quux :: Foo [b] -> () quux Bar = () I get: *test.hs:7:8: **error:* * • Couldn't match type ‘a1’ with ‘[a]’* * ‘a1’ is a rigid type variable bound by* * the type signature for:* * foo :: forall a1. Foo a1 -> ()* * at test.hs:6:1-18* * Expected type: Foo a1* * Actual type: Foo [a]* To me it appears that the type refinement established by the GADT pattern match is not accounted for. Of course I can write: foo :: Foo a -> () foo b@Bar | (c :: Foo [a]) <- b = quux c where quux :: Foo [b] -> () quux Bar = () but it feels like a complicated way to do it... My question is whether this is generally seen as the way to go or whether ScopedTypeVariables coming from a GADT pattern match should be able to capture the refined type. To me the latter seems more useful. Just wanted to feel the waters before writing a ticket about this. Cheers and thanks, Gabor

6 8

FW: How does GHC's testsuite work?
by Simon Peyton Jones 30 Oct '17

30 Oct '17

Forwarding to ghc-devs, a better list for this question. Simon -----Original Message----- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Sébastien Hinderer Sent: 30 October 2017 15:18 To: glasgow-haskell-users(a)haskell.org Subject: How does GHC's testsuite work? Dear all, I am a member of OCaml's developement team. More specifically, I am working on a test-driver for the OCaml compiler, which will be part of OCaml's 4.06 release. I am currently writing an article to describe the tool and its principles. In this article, I would like to also talk about how other compilers' testsuites are handled and loking how things are done in GHC is natural. In OCaml, our testsuite essentially consist in whole programs that we compile and run, checking that the compilation and execution results match the expected ones. From what I could see from GHC's testsuite, it seemed to me that it uses Python to drive the tests. I also understood that the testsuite has tests that are more kind of unit-tests, in the .T file. Am I correct here? Or do you guys also have whole program tests? If you do, how do you compile and run them? Any comment / hint on this aspect of the test harness' design would be really helpful. Many thanks in advance, Sébastien. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…

1 0

Family instance consistency
by Simon Peyton Jones 29 Oct '17

29 Oct '17

Edward Could you possibly take a look at #14396? It's going to bite us soon, as Alan's Trees That Grow patch lands (see the branch mentioned on the ticket). (In fact, Alan, I don't know how you build that branch ; I can't build it.) Simon

2 1

RE: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
by Simon Peyton Jones 27 Oct '17

27 Oct '17

Bartosz Why not just cache the #datacons in the TyCon (in the DataTyCon constructor). That seems simple, direct, and fast. And simpler than the stuff you are forced into here. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 27 October 2017 23:03 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Ffaf60e858a293affca463043c830e1edb568500 | 3%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5 | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176303711& | sdata=tp4PTSkN5iBwKkWgZdT%2BcHKK8EKz8NQZeE%2FegVdx%2FIM%3D&reserved=0 | | >--------------------------------------------------------------- | | commit faf60e858a293affca463043c830e1edb5685003 | Author: Bartosz Nitka <bnitka(a)fb.com> | Date: Fri Oct 20 20:30:52 2017 +0100 | | Make tagForCon non-linear | | Computing the number of constructors for TyCon is linear | in the number of constructors. | That's wasteful if all you want to check is if that | number is smaller than what fits in tag bits | (usually 8 things). | | What this change does is to use a function that can | determine the ineqaulity without computing the size. | | This improves compile time on a module with a | data type that has 10k constructors. | The variance in total time is (suspiciously) high, | but going by the best of 3 the numbers are 8.186s vs 7.511s. | For 1000 constructors the difference isn't noticeable: | 0.646s vs 0.624s. | The hot spots were cgDataCon and cgEnumerationTyCon | where tagForCon is called in a loop. | | One alternative would be to pass down the size. | | Test Plan: harbormaster | | Reviewers: bgamari, simonmar, austin | | Reviewed By: simonmar | | Subscribers: rwbarton, thomie | | Differential Revision: https://phabricator.haskell.org/D4116 | | | >--------------------------------------------------------------- | | faf60e858a293affca463043c830e1edb5685003 | compiler/codeGen/StgCmmClosure.hs | 11 ++++++++--- | compiler/types/TyCon.hs | 16 +++++++++++++++- | 2 files changed, 23 insertions(+), 4 deletions(-) | | diff --git a/compiler/codeGen/StgCmmClosure.hs | b/compiler/codeGen/StgCmmClosure.hs | index 1da1f70..2501ec9 100644 | --- a/compiler/codeGen/StgCmmClosure.hs | +++ b/compiler/codeGen/StgCmmClosure.hs | @@ -361,13 +361,18 @@ type DynTag = Int -- The tag on a *pointer* | isSmallFamily :: DynFlags -> Int -> Bool isSmallFamily dflags fam_size | = fam_size <= mAX_PTR_TAG dflags | | +-- | Faster version of isSmallFamily if you haven't computed the size | yet. | +isSmallFamilyTyCon :: DynFlags -> TyCon -> Bool isSmallFamilyTyCon | +dflags tycon = | + tyConFamilySizeAtMost tycon (mAX_PTR_TAG dflags) | + | tagForCon :: DynFlags -> DataCon -> DynTag tagForCon dflags con | - | isSmallFamily dflags fam_size = con_tag | - | otherwise = 1 | + | isSmallFamilyTyCon dflags tycon = con_tag | + | otherwise = 1 | where | con_tag = dataConTag con -- NB: 1-indexed | - fam_size = tyConFamilySize (dataConTyCon con) | + tycon = dataConTyCon con | | tagForArity :: DynFlags -> RepArity -> DynTag tagForArity dflags arity | diff --git a/compiler/types/TyCon.hs b/compiler/types/TyCon.hs index | 39d2e9b..103c824 100644 | --- a/compiler/types/TyCon.hs | +++ b/compiler/types/TyCon.hs | @@ -78,7 +78,7 @@ module TyCon( | tyConDataCons, tyConDataCons_maybe, | tyConSingleDataCon_maybe, tyConSingleDataCon, | tyConSingleAlgDataCon_maybe, | - tyConFamilySize, | + tyConFamilySize, tyConFamilySizeAtMost, | tyConStupidTheta, | tyConArity, | tyConRoles, | @@ -2205,6 +2205,20 @@ tyConFamilySize tc@(AlgTyCon { algTcRhs = rhs }) | _ -> pprPanic "tyConFamilySize 1" | (ppr tc) | tyConFamilySize tc = pprPanic "tyConFamilySize 2" (ppr tc) | | +-- | Determine if number of value constructors a 'TyCon' has is smaller | +-- than n. Faster than tyConFamilySize tc <= n. | +-- Panics if the 'TyCon' is not algebraic or a tuple | +tyConFamilySizeAtMost :: TyCon -> Int -> Bool tyConFamilySizeAtMost | +tc@(AlgTyCon { algTcRhs = rhs }) n | + = case rhs of | + DataTyCon { data_cons = cons } -> lengthAtMost cons n | + NewTyCon {} -> 1 <= n | + TupleTyCon {} -> 1 <= n | + SumTyCon { data_cons = cons } -> lengthAtMost cons n | + _ -> pprPanic "tyConFamilySizeAtMost | 1" | + (ppr tc) | +tyConFamilySizeAtMost tc _ = pprPanic "tyConFamilySizeAtMost 2" (ppr | +tc) | + | -- | Extract an 'AlgTyConRhs' with information about data constructors | from an | -- algebraic or tuple 'TyCon'. Panics for any other sort of 'TyCon' | algTyConRhs :: TyCon -> AlgTyConRhs | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5 | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176313720& | sdata=NfTqei3XryWnCiNRgOZDT6XfMRMfAST7EKFBSi%2FCXa8%3D&reserved=0

2 2

FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)
by Simon Peyton Jones 27 Oct '17

27 Oct '17

I've received 1500 of these commit messages overnight, and another arrives every few seconds. Are they likely to stop soon? Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 27 October 2017 01:06 To: ghc-commits(a)haskell.org Subject: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa) Repository : ssh://git@git.haskell.org/ghc On branch : wip/nfs-locking Link : https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskell… >--------------------------------------------------------------- commit 31515fad107d28f83b47d6249dd7b8c1eeb3bc70 Author: Andrey Mokhov <andrey.mokhov(a)gmail.com> Date: Fri Feb 26 11:37:47 2016 +0000 Use conventional whitespacing for @. See #210. >--------------------------------------------------------------- 31515fad107d28f83b47d6249dd7b8c1eeb3bc70 src/GHC.hs | 2 +- src/Rules/Actions.hs | 2 +- src/Rules/Compile.hs | 2 +- src/Rules/Data.hs | 4 ++-- src/Rules/Dependencies.hs | 2 +- src/Rules/Documentation.hs | 2 +- src/Rules/Generate.hs | 2 +- src/Rules/Library.hs | 4 ++-- src/Rules/Program.hs | 6 +++--- src/Rules/Register.hs | 2 +- src/Settings/Paths.hs | 10 +++++----- src/Way.hs | 2 +- 12 files changed, 20 insertions(+), 20 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc 31515fad107d28f83b47d6249dd7b8c1eeb3bc70 _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…

3 3