- ghc-devs - Haskell.org

Status of the Hi Haddock project
by Simon Jakobi 14 Aug '18

14 Aug '18

Hi! I have summarized the status of my GSoC project at https://sjakobi.github.io/blog/2018/08/14/hi-haddock-3/ My WIP patches for GHC and haddock are at https://phabricator.haskell.org/D5067 and https://github.com/haskell/haddock/pull/906. Cheers, Simon

1 0

Starting hacking on GHC
by Andrew Rmnsky 13 Aug '18

13 Aug '18

Hello everyone! I would like to contribute to GHC, but I don't know where to start (I have built it already from the source). I'd be happy if someone gave me a piece of advice on what task I should pick for the beginning. A few words about my background: CS student, 4-th grade, have some experience with Haskell (I had a course on Haskell in my university where I studied some theory like Monoids, Functors, Applicatives Monads, Monad Transformers, Lens, basics of parallel and concurrent programming in Haskell and I have solved some algorithmic problems. I also practiced developing small web-apps with Haskell, using warp, aeson, postgresql-simple and some other libraries. Looking forward for your replies. Thank you in advance! Andrew Romanovsky.

3 2

Re: [ANNOUNCE] GHC 8.6.1-beta1 available
by Richard Eisenberg 12 Aug '18

12 Aug '18

> On Aug 11, 2018, at 11:27 AM, Vassil Ognyanov Keremidchiev <varosi(a)gmail.com> wrote: > > What are the new features there toward Dependent Typed Haskell? Ben's link to https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/8.6.1-… <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/8.6.1-…> includes several items, pasted here: * A new StarIsType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…> language extension has been added which controls whether * is parsed as Data.Kind.Type or a regular type operator. StarIsType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…> is enabled by default. * CUSKs now require all kind variables to be explicitly quantified. This was already the case with TypeInType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…>, but now PolyKinds <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…> also exhibits this behavior. * Functionality of TypeInType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…> has been subsumed by PolyKinds <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…>, and it is now merely a shorthand for PolyKinds <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…>, DataKinds <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…>, and NoStarIsType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…>. The users are advised to avoid TypeInType <https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/glasgo…> due to its misleading name: the Type :: Type axiom holds regardless of whether it is enabled. These are small steps, to be sure, but there's quite a bit going on behind the scenes. For example see the "Coercion Quantification" and "Type-level visible type applications" to take place at HIW (https://icfp18.sigplan.org/track/hiw-2018-papers#event-overview <https://icfp18.sigplan.org/track/hiw-2018-papers#event-overview>). There are also a great many proposals in play at https://github.com/ghc-proposals/ghc-proposals <https://github.com/ghc-proposals/ghc-proposals> More to come in the future, of course! Richard

1 0

How to test master after breaking changes
by Artem Pelenitsyn 10 Aug '18

10 Aug '18

Hello devs, Wiki page on testing says that in order to run all tests you have to install additional packages: https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Additio… and kindly provides a command to do this: cabal install --with-compiler=`pwd`/inplace/bin/ghc-stage2 --package-db=`pwd`/inplace/lib/package.conf.d mtl parallel parsec primitive QuickCheck random regex-compat syb stm utf8-string vector After the af9b744bb <https://github.com/ghc/ghc/commit/af9b744bbf1c39078e561b19edd3c5234b361b27> one of the packages, primitive, does not build anymore. At least, its last released version on Hackage. I see that the problem has been fixed on primitive's master (a2af610 <https://github.com/haskell/primitive/commit/a2af610c08c5f5afc496f907bf6b2a4…>). But what should I do to actually test master branch of GHC now? -- Best wishes, Artem

2 1

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

08 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

Re: Non-Reinstallable packages
by Moritz Angermann 07 Aug '18

07 Aug '18

Dear friends, we have a set of non-reinstallable packages with GHC, these include iirc template-haskell, and some other. I've got a few questions concerning those: - do we have a complete up-to-date list of those? - why can't we reinstall them (let's assume we use the identical version for now; and don't upgrade) - does this also hold if we essentially build a stage3 compiler with packages? Our usual build process is: 1. take a boost-strap compiler, which doesn't need to have the same version as the final compiler. 2. build the libraries necessary to build the stage1 compiler while ensuring we build some extra libraries as well, so we don't have to rely on those shipped with the boot-strap compiler. 3. use the stage1 compiler to build all libraries we want to ship with the stage2 compiler; and build the stage2 compiler. Now I do understand that the stage1 compiler could potentially be tainted by the boot-strap compiler and as such yield different libraries compared to what the stage2 compiler would yield. Shouldn't rebuilding any library with the stage1 compiler yield the same libraries these days? If the boot-strap compiler is the same version as the one we build, shouldn't the stage2 compiler be capable of building good enough libraries as well so that we can reinstall them? What I ideally would like to have is a minimal compiler: ghc + rts; than keep building all the lirbaries from ground up. A potential problem I see is that if we use dynamic libraries and get into TH, we could run into issues where we want to link libraries that are different to the ones that the ghc binary links against. Would this also hold if we used `-fexternal-interpreter` only? Cheers, Moritz

2 1

PSA: You likely want to use -O2 for the stage1 compiler.
by Andreas Klebinger 04 Aug '18

04 Aug '18

I've wondered for a good while if using O2 on stage1 might be worth it. So I did some measurements and it should be worth it for most cases. For a single "quick" flavour build they are more or less on equal footing. If you rebuild stage2 multiple times reusing stage1 it will be faster. If you build stage2 with optimizations/profiling it will be faster. Below are the timings using "time make -j9" for a quick build. I forgot to write down the seconds as I didn't expect them to be so close. But it is what it is. Timings stage1 options O1 vs O2, quick build after make clean: stage1 opt | time (wall) | time (user) -O1 | 13m | 53m -O2 | 13m | 51m I've also run the numbers for a optimized stage2 compiler a while ago, where stage1 with O2 was faster. But I no longer have these numbers around. So it seems safe to say one should use O2 if either: * stage2 is built with optimizations * you freeze stage1 and reuse it while working on stage2

2 1

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

03 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