July 2018 - ghc-devs - Haskell.org

GHC's module hierarchy
by Simon Peyton Jones 03 Oct '19

03 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 05 Jan '19

05 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

perf.haskell.org functional again
by Joachim Breitner 01 Dec '18

01 Dec '18

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim

5 11

Scripts merged for easily loading and running GHC in GHCi, for fast development iterations
by Michael Sloan 09 Aug '18

09 Aug '18

Hello GHC developers! Now that D4904 and D4986 are merged, if you have recently built GHC then you can use "./utils/ghc-in-ghci/run.sh -fobject-code" to load GHC into GHCi (throwing on a "-j8" helps too). For me, this makes development far more pleasant, as often I can make a change and try it out in only 15 or 20 seconds. Thanks to Csongor Kiss for writing the initial ghci script, and Matthew Pickering for posting about it to the mailinglist, as otherwise I probably wouldn't have known about it. I wrote a blog post about the topic on my new blog: http://www.mgsloan.com/posts/ghcinception/ Once D5015 is merged, the explicit "-fobject-code" won't be needed. Once https://ghc.haskell.org/trac/ghc/ticket/15454 is addressed, it might not be needed at all, leading to even faster loading ;) Happy ghci-ing! -Michael

4 7

accuracy of asinh and atanh
by Matt Peddie 04 Aug '18

04 Aug '18

Hi devs, I tried to use asinh :: Double -> Double and discovered that it's inaccurate compared to my system library (GNU libm), even returning -Infinity in place of finite values in the neighborhood of -22 for large negative arguments. `atanh` is also inaccurate compared to the system library. I wrote up a more detailed description of the problem including plots in the README file at https://github.com/peddie/ghc-inverse-hyperbolic -- this repository is package that can help you examine the error for yourself or generate the plots, and it also contains accurate pure-Haskell translations of the system library's implementation for these functions. What's the next step to fixing this in GHC? Cheers Matt Peddie

7 11

understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?
by Carter Schonwald 02 Aug '18

02 Aug '18

Michal: did you write this Assert about width? and if so could you explain it so we can understand? hrmm... that code is in the procedure for generating C calls for 64bit intel systems https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#… is the top of that routine and width is defined right below the spot in question https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#… it seems like the code/assertion likely predates michal's work? (eg, a trick to make sure that genCCall64 doesn't get invoked by 32bit platforms?) On Mon, Jul 23, 2018 at 8:54 PM Abhiroop Sarkar <asiamgenius(a)gmail.com> wrote: > Hi Michal, > > In the tests that you have added to D4475, are all the tests running fine? > > On my machine, I was running the FFI tests( > https://github.com/michalt/ghc/blob/int8/testsuite/tests/ffi/should_run/Pri…) > and they seem to fail at a particular assert statement in the code > generator. > > To be precise this one: > https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#… > > Upon commenting that assert the tests run fine. Am I missing something or > is the failure expected? > > Thanks, > Abhiroop > > On Mon, Jul 9, 2018 at 8:31 PM Michal Terepeta <michal.terepeta(a)gmail.com> > wrote: > >> Just for the record, I've uploaded the changes to binary: >> https://github.com/michalt/packages-binary/tree/int8 >> >> - Michal >> >> On Wed, Jul 4, 2018 at 11:07 AM Michal Terepeta < >> michal.terepeta(a)gmail.com> wrote: >> >>> Yeah, if you look at the linked diff, there are a few tiny changes to >>> binary that are necessary. >>> >>> I'll try to upload them to github later this week. >>> >>> Ben, is something blocking the review of the diff? I think I addressed >>> all comments so far. >>> >>> - Michal >>> >>> On Wed, Jul 4, 2018 at 1:38 AM Abhiroop Sarkar <asiamgenius(a)gmail.com> >>> wrote: >>> >>>> Hello Michal, >>>> >>>> I was looking at your diff https://phabricator.haskell.org/D4475 and >>>> there seems to be some changes that you perhaps made in the binary package ( >>>> https://phabricator.haskell.org/differential/changeset/?ref=199152&whitespa…) >>>> I could not find your version of binary on your github repos list. Is it >>>> possible for you to upload that so I can pull those changes? >>>> >>>> Thanks >>>> >>>> Abhiroop >>>> >>>> On Mon, May 28, 2018 at 10:45 PM Carter Schonwald < >>>> carter.schonwald(a)gmail.com> wrote: >>>> >>>>> Abhiroop has the gist, though the size of word args for simd is more >>>>> something we want to be consistent between 32/64 bit modes aka ghc >>>>> targeting 32 or 64 bit intel with simd support :). It would be best if the >>>>> unpack and pack operations that map to and from unboxed tuples where >>>>> consistent and precise type wise. >>>>> >>>>> >>>>> >>>>> -Carter >>>>> >>>>> On May 28, 2018, at 5:02 PM, Abhiroop Sarkar <asiamgenius(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hello Michal, >>>>> >>>>> My understanding of the issues are much lesser compared to Carter. >>>>> However, I will state whatever I understood from discussions with him. Be >>>>> warned my understanding might be wrong and Carter might be asking this for >>>>> some completely different reason. >>>>> >>>>> > Out of curiosity, why do you need Word64#/Word32# story to be fixed >>>>> for SIMD? >>>>> >>>>> One of the issues we are dealing with is multiple >>>>> microarchitectures(SSE, AVX, AVX2 etc). As a result different >>>>> microarchitectures has different ways of handling an 8 bit or 16 bit or 32 >>>>> bit unsigned integer. An example I can provide is the vector multiply >>>>> instruction which has different semantics of multiplying and storing the >>>>> first 16 bits of a 32 bit unsigned integer compared to the lower 16 bits >>>>> for each of the elements in its SIMD registers. There will be some other >>>>> intricacies around handling a byte sized integer or a 64 bit integer which >>>>> will be different from the 32 bit version. >>>>> >>>>> Basically a 128 bit vector instruction will make some minor >>>>> differences when dealing with 2 64 bit integers or 4 32 bit integer or 8 16 >>>>> bit integers. >>>>> >>>>> So I think at the higher level we would want to be as precise as >>>>> possible when specifying the datatypes and want things like Word8#, >>>>> Word16#, Word32#, Word64# rather than a single ambiguous type like Word. >>>>> >>>>> One more example is this vector operation like : broadcastWord64X2# :: >>>>> Word# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> >>>>> -> Word64X2# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> which >>>>> should rather be broadcastWord64X2# :: Word64# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> >>>>> -> Word64X2# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> >>>>> >>>>> Another reason could be improving the space efficiency of packing >>>>> various datatypes. This was explained in some detail in this comment: >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/74#issuecomment-3339515… >>>>> >>>>> Thanks, >>>>> Abhiroop >>>>> >>>>> On Mon, May 28, 2018 at 6:06 PM, Michal Terepeta < >>>>> michal.terepeta(a)gmail.com> wrote: >>>>> >>>>>> Hey Carter, >>>>>> >>>>>> Yeah, I'm totally snowed under with personal stuff at the moment, so >>>>>> not much time to hack on >>>>>> anything. I've managed to make some progress on >>>>>> https://phabricator.haskell.org/D4475 (prototype >>>>>> that adds Int8#/Word8#; waiting for another round of review). Sadly >>>>>> June still looks a bit crazy for >>>>>> me, so I can't promise anything for Word64#/Word32# (and >>>>>> Int64#/Int32#). I hope to have some more >>>>>> time in July. >>>>>> >>>>>> If this is blocking you, then please don't wait for me and go ahead >>>>>> (my diff for Int8#/Word8# might >>>>>> be a decent starting point to see which places might need changes). >>>>>> >>>>>> Out of curiosity, why do you need Word64#/Word32# story to be fixed >>>>>> for SIMD? Cmm already has >>>>>> separate types for vector types (see TyCon.hs and VecRep constructor >>>>>> of PrimRep). >>>>>> >>>>>> Cheers! >>>>>> >>>>>> - Michal >>>>>> >>>>>> PS. Are you coming to ZuriHac by any chance? >>>>>> >>>>>> On Mon, May 28, 2018 at 12:37 AM Carter Schonwald < >>>>>> carter.schonwald(a)gmail.com> wrote: >>>>>> >>>>>>> Hey Michal! >>>>>>> So i'm mentoring Abhiroop around getting SIMD all nice and awesome, >>>>>>> and I realized we still dont quite yet have the nice Word32# and Word64# >>>>>>> etc story in ghc as yet. >>>>>>> >>>>>>> Whats the status on that and or is there a way we can help get that >>>>>>> over the hump for ghc? These different sized in register ints and friends >>>>>>> have a tight partnership with any nice SIMD iterating over the summer, and >>>>>>> hopefully helps inform the design >>>>>>> >>>>>>> -Carter >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Kloona - Coming Soon! >>>>> >>>>> >>>> >>>> -- >>>> Kloona - Coming Soon! >>>> >>> > > -- > Kloona - Coming Soon! >

3 7

Re: [Haskell-cafe] Access violation when stack haddock haskell-src-exts since LTS 12.0
by Sven Panne 02 Aug '18

02 Aug '18

Am Mo., 23. Juli 2018 um 05:49 Uhr schrieb Yuji Yamamoto < whosekiteneverfly(a)gmail.com>: > Thank you very much! > > I confirmed the replaced haddock executable can successfully generate the > docs! > Yesterday I had quite some trouble because of the Haddock problem, too, and I guess I'm not alone: haskell-src-exts has 165 direct reverse dependencies, so probably hundreds of Hackage packages are affected by this. The workaround is simple (don't use --haddock with stack), but far from satisfying and not very obvious. Given the fact that this affects a very central piece of the Haskell infrastructure in its latest stable incarnation (GHC 8.4.3): Can we have an 8.4.4 with a fixed Haddock?

3 2

Failure to Build
by Ara Adkins 02 Aug '18

02 Aug '18

Hey Devs, I'm having trouble building the head of the ghc-8.6 branch (`26a7f850d1`) on my Arch Linux machine. The essence of the error is this as follows, though the full result of make (to the point of error) is attached. ``` Configuring template-haskell-2.14.0.0... ghc-cabal: Encountered missing dependencies: ghc-boot-th ==8.6.* && ==8.7 ``` The output of configure is as follows: ``` ---------------------------------------------------------------------- Configure completed successfully. Building GHC version : 8.7.20180730 Git commit id : 26a7f850d15b91ad68d1e28d467faba00bb79144 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /usr/bin/ghc which is version : 8.4.3 Using (for bootstrapping) : gcc Using gcc : gcc which is version : 8.1.1 Building a cross compiler : NO Unregisterised : NO hs-cpp : gcc hs-cpp-flags : -E -undef -traditional ar : ar ld : ld.gold nm : nm libtool : libtool objdump : objdump ranlib : ranlib windres : dllwrap : genlib : Happy : /home/ara/.local/bin/happy (1.19.9) Alex : /usr/bin/alex (3.2.4) Perl : /usr/bin/perl sphinx-build : /usr/bin/sphinx-build xelatex : /usr/bin/xelatex Using LLVM tools clang : clang llc : opt : HsColour : /usr/bin/HsColour Tools to build Sphinx HTML documentation available: YES Tools to build Sphinx PDF documentation available: YES ---------------------------------------------------------------------- ``` Any help would be most appreciated. Best, _ara

4 6

Type constraint: isOneOf
by Sylvain Henry 01 Aug '18

01 Aug '18

Hi, Motivating example: I have an open sum type (Variant, or V) which can be used to store values of different types: x,y :: V '[String,Int] x = V "test" y = V @Int 10 f :: V '[String,Int] -> String f = \case V s -> "Found string: " ++ s V (i :: Int) -> "Found int: " ++ show (i+10) V is a pattern synonym defined like this (you don't need to understand the details): pattern V :: forall c cs. (c :< cs) => c -> Variant cs pattern V x <- (fromVariant -> Just x) where V x = toVariant x Where the (:<) constraint checks that we are not doing anything wrong: z :: V '[String,Int] z = V @Float 10 Test.hs:15:5: error: • `Float' is not a member of '[String, Int] • In the expression: V @Float 10 In an equation for ‘z’: z = V @Float 10 f :: V '[String,Int] -> String f = \case ... V (i :: Float) -> "Found float: " ++ show i Test.hs:20:4: error: • `Float' is not a member of '[String, Int] • In the pattern: V (i :: Float) In a case alternative: V (i :: Float) -> "Found float: " ++ show i So far so good, it works well. Now the issues: 1) The case-expression in "f" is reported as non-exhaustive 2) We have to disambiguate the type of "10" in the definition of "y" and in the match "(V (i :: Int))" Both of these issues are caused by the fact that even with the (c :< cs) constraint, GHC doesn't know/use the fact that the type "c" is really one of the types in "cs". Would it make sense to add the following built-in "isOneOf" constraint: ∈ :: k -> [k] ->Constraint pattern V :: forall c cs. (c :< cs, c ∈ cs) => c -> Variant cs 1) GHC could infer pattern completeness information when the V pattern is used depending on the type list "cs" 2) GHC might use the "c ∈ cs" constraint in the last resort to infer "c" if it remains ambiguous: try to type-check with c~c' forall c' in cs and if there is only one valid and unambiguous c', then infer c~c'. Has it already been considered? I don't know how hard it would be to implement nor if it is sound to add something like this. 1 seems simpler/safer than 2, though (it is similar to a new kind of COMPLETE pragma), and it would already be great! Any thoughts? Best regards, Sylvain

1 0

Nondeterministic Failure on aarch64 with -jn, n > 1
by Travis Whitaker 28 Jul '18

28 Jul '18

Hello GHC Devs, It seems to me that GHC is rather broken on aarch64, at least since 8.2.1 (and at least on the machines I have access to). I first noticed this issue with Nixpkgs (https://github.com/NixOS/nixpkgs/issues/40301) so to check that this isn't some Nixpkgs idiosyncrasy I went ahead and built my own GHC 8.4.3 for aarch64 (there's no binary release at https://www.haskell.org/ghc/download_ghc_8_4_3.html to try, but perhaps I've missed something. It seems the only Nix idiosyncrasy was passing "--ghc-option=-j${cores}" to "./Setup.hs configure". The issue is triggered by using '-jn' for any n greater than one when building any non-trivial package, but I've found hscolour1.24.4 reproduces it very reliably (perhaps because there are opportunities for parallelism early in its module dependency graph?). GHC very often (although not always) will fail with one of: - Segmentation fault. - Bus fault - <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for aarch64-unknown-linux): Binary.UserData: no put_binding_name - ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.4.3 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) The fix, excruciating as it may be on already slow arm machines, is to use '-j1'. This issue seems present on each GHC release since 8.2.1 (although I haven't tried HEAD yet). I haven't noticed any issues with any other concurrent Haskell programs on aarch64. There are some umbrella bugs for aarch64 in Trac, so I wanted to ask here before filing a ticket. Has anyone else noticed this behavior on aarch64? What's more, are there any tips for using GDB to hunt down synchronization issues in GHC? Thanks for all your hard work! Travis

2 2