August 2018 - ghc-devs

Should StablePtr# have its own kind?
by David Feuer 19 Aug '18

19 Aug '18

Currently, StablePtr# :: Type -> TYPE 'AddrRep The fact that a stable pointer table index has the same size as a pointer seems somewhat coincidental. Would it make sense to add a `StablePtrRep` constructor to `RuntimeRep` and use that? That should allow StablePtr# to change its representation with less trouble, if that ever proves desirable.

1 0

Can't build 8.6.1-beta1 with debugging.
by Mateusz Kowalczyk 15 Aug '18

15 Aug '18

Hi all, I wanted to try our codebase with 8.6. I happened to already have 8.6.0.20180714 ready so I started with that. Compilation went well but I got a segfault when running a benchmark we have with profiling on. GDB told me the segfault was in stg_ap_ppppp_info in AutoApply.cmm which as I understand is generated. Strange but OK... I decided to try unprofiled with LLVM to see if some LLVM issue we had with current version (7.10.x) has gone away. Sadly I encountered a segfault during regular compilation (clean build, LLVM 6.0). I had no debugging symbols. Next I decided to try the beta1 version. I copied mk/build.mk.sample into mk/build.mk and added the following: GhcDebugged = YES GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -DDEBUG I checked out the 8.6.1-beta1 tag then ran following. fuuzetsu@rubin:~/programming/ghc$ echo $PREFIX /usr/local/ghc/ghc-8.6.1-beta1 fuuzetsu@rubin:~/programming/ghc$ ./configure --prefix=$PREFIX && make -j4 && make install After some time I was met with: /usr/bin/ld.gold: error: cannot find -lHSrts_thr_debug_p Also a long chain of messages about undefined refs you can find at [1]. Considering I haven't touched any settings beyond adding debug flags, it surprised me a little that I can't build successfully. Please advise and feel free to ask for any specs. uname -a: Linux rubin.tsuru.it 4.15.0-30-generic #32~16.04.1-Ubuntu SMP Thu Jul 26 20:25:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [1]: https://gist.github.com/Fuuzetsu/7a65a963dd625386d13938ba1e22af5c -- Mateusz K.

2 2

CI constanly fails on clonning
by Artem Pelenitsyn 14 Aug '18

14 Aug '18

Hello, devs, Could someone point me where I go wrong in the following? My Differentials constantly fail to CI with the messages like this one: exception 'PhabricatorWorkerPermanentFailureException' with message 'Lease "PHID-DRYL-sydepw7hjxlnim325sdu" never activated.' in /opt/phabricator/src/applications/harbormaster/step/HarbormasterLeaseWorkingCopyBuildStepImplementation.php:91 Stack trace: #0 /opt/phabricator/src/applications/harbormaster/worker/HarbormasterTargetWorker.php(70): HarbormasterLeaseWorkingCopyBuildStepImplementation->execute(Object(HarbormasterBuild), Object(HarbormasterBuildTarget)) #1 /opt/phabricator/src/infrastructure/daemon/workers/PhabricatorWorker.php(123): HarbormasterTargetWorker->doWork() #2 /opt/phabricator/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php(171): PhabricatorWorker->executeTask() #3 /opt/phabricator/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php(22): PhabricatorWorkerActiveTask->executeTask() #4 /opt/libphutil/src/daemon/PhutilDaemon.php(219): PhabricatorTaskmasterDaemon->run() #5 /opt/libphutil/scripts/daemon/exec/exec_daemon.php(131): PhutilDaemon->execute() #6 {main} Examples: https://phabricator.haskell.org/harbormaster/build/50735/ https://phabricator.haskell.org/harbormaster/build/51066/ https://phabricator.haskell.org/harbormaster/build/51616/ I googled this and found a similar topic on Phab's bug tracker: https://secure.phabricator.com/T10982 Not particularly helpful 'cause I don't really understand the internals of Phab. This started to happen roughly when I moved my ghc hacking setup to a new hardware this summer. Maybe, that's connected. Also, what suspicious is that `arc diff` tries to push changes in master right away, so I have to pass --skip-staging. This wasn't the case before, I believe. -- Best, Artem Best, Artem

2 2

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