- ghc-devs - Haskell.org

Re: [commit: ghc] master: Remove ad-hoc special case in occAnal (c16382d)
by Joachim Breitner 07 Jun '18

07 Jun '18

Dear Simon (and everyone else), Am Donnerstag, den 07.06.2018, 10:06 +0000 schrieb git(a)git.haskell.org: > I did look at the > tiny increase in allocation for cacheprof and concluded that it was > unimportant (I forget the details). don’t bother with cacheprof, it's allocation number is non- deterministic: https://ghc.haskell.org/trac/ghc/ticket/8611 I wonder how many hours were wasted by people trying find some causal connection between their change and cacheprof… Maybe we should just remove cacheprof? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

ZuriHac 2018 GHC DevOps track - Request for Contributions
by Niklas Hambüchen 05 Jun '18

05 Jun '18

Hi GHC devs, The ZuriHac 2018 conference will feature a GHC DevOps track (which Andreas and I are coordinating), that will be all about fostering contributions to GHC and learning to hack it. There will be a room or two allocated at Zurihac for this purpose. We hope to focus on roughly these topics: * How to build GHC from source * How to iterate on changes quickly * What's the development workflow, how do I get my patch merged? * How do specific parts of GHC work * Extending GHC's test suite * Improving automation, processes and release quality * Documenting the undocumented If we are successful, we will have more GHC contributers after ZuriHac than before. But we need your contributions to add content to the track! Specifically, we're looking for ZuriHac attendees who could (help) run a session in this track. Such as: * Giving a talk about one of the above or related topics * Hosting a hack session where participants of the track work together on the GHC code base towards a specific goal * Being around as a "GHC mentor" during open hack sessions, helping new GHC contributors out To give some examples, I could offer to give a talk on a recent effort to improve Ctrl+C and signal handling in the RTS, and I would like to run a hack session where we add performance regression tests based on CPU instruction counters. Please contact Andreas or me (on this list or privately) if you think you could help in any of these directions! If you're not sure, contact us anyway and tell us your idea! Best, Niklas and Andreas ZuriHac 2018 GHC DevOps track coordinators

4 8

Combining Bag/OrdList?
by Andreas Klebinger 04 Jun '18

04 Jun '18

We have OrdList which does: Provide trees (of instructions), so that lists of instructions can be appended in linear time. And Bag which claims to be: an unordered collection with duplicates However the actual implementation of Bag is also a tree if things. Given that we have snocBag, consBag that implies to me it's also an ordered collection. I wondered if besides of someone having to do it if there is a reason why these couldn't be combined into a single data structure? Their implementation seems similar enough as far as I can tell.

6 8

Trac email
by Simon Peyton Jones 01 Jun '18

01 Jun '18

Devs Trac has entirely stopped sending me email, so I have no idea what's happening on the GHC front. Could someone unglue it? Thanks! Simon

5 6

-fghci-leak-check apparently causes many tests to fail
by Ryan Scott 31 May '18

31 May '18

I recently ran the testsuite and experienced a very large number of testsuite failures, all of which seem to involve the new -fghci-leak-check flag. Here is the list of tests that fail: Unexpected failures: ghci/prog001/prog001.run prog001 [bad stdout] (ghci) ghci/prog002/prog002.run prog002 [bad stdout] (ghci) ghci/prog003/prog003.run prog003 [bad stdout] (ghci) ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci) ghci/prog013/prog013.run prog013 [bad stdout] (ghci) ghci/prog012/prog012.run prog012 [bad stdout] (ghci) ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci) ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci) ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci) ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci) ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci) ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci) ghci/scripts/T6106.run T6106 [bad stdout] (ghci) ghci/scripts/T8353.run T8353 [bad stdout] (ghci) ghci/scripts/T9293.run T9293 [bad stdout] (ghci) ghci/scripts/T10989.run T10989 [bad stdout] (ghci) ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci) ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci) ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci) ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci) ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci) perf/space_leaks/T4029.run T4029 [bad stdout] (ghci) And the full failing test output can be found here [1]. (I won't post it inline, since it's quite large). Are these changes expected? I'm not at all familiar with -fghci-leak-check, so I don't know if we should accept the new output or not. Ryan S. ----- [1] https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc…

2 1

build testsuite or not?
by Jens Petersen 31 May '18

31 May '18

Okay I have one more question about my packaging of ghc for Fedora. For long I always build the testsuite for every release perf build on all archs (for an example see the build.log links on https://koji.fedoraproject.org/koji/buildinfo?buildID=1086491) Is this a useful meaningful thing to do? I thought it good to have it as a reference for ghc builds on Fedora and EPEL, but it does add a considerable amount of time to builds (specially for the slower ARM arch's) so it is not without cost. So I am wondering how useful it is to continue running the testsuite for each "production" build I do. What do others and other distros, etc do for final releases? Thanks, Jens

2 2

Unable to build on NixOS
by Sean D Gillespie 30 May '18

30 May '18

Howdy, I am unable to build the latest revision of GHC on NixOS. I can build older revisions. Here's my error: ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id ghc-heap-8.5 -hide-all-packages -i -ilibraries/ghc-heap/. -ilibraries/gh c-heap/dist-install/build -Ilibraries/ghc-heap/dist-install/build -ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist-install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -O2 -no-user-packa ge-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-heap/dist-install/build -hidir libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/ dist-install/build -split-sections -c libraries/ghc-heap/./GHC/Exts/Heap/Closures.hs -o libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o -dyno libraries/ghc-heap/dist-instal l/build/GHC/Exts/Heap/Closures.dyn_o libraries/ghc-heap/GHC/Exts/Heap/Closures.hs:23:1: error: Could not find module `GHC.Exts.Heap.InfoTableProf' It is a member of the hidden package `ghc-heap-8.5'. You can run `:set -package ghc-heap' to expose it. (Note: this unloads all the modules in the current scope.) Use -v to see a list of the files searched for. | 23 | import GHC.Exts.Heap.InfoTableProf | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/ghc-heap/ghc.mk:4: libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o] Error 1 make: *** [Makefile:127: all] Error 2 For reference, here's my shell.nix: { nixpkgs ? import <nixpkgs> {}, compiler ? "ghcHEAD" }: let inherit (nixpkgs) pkgs; ghc = pkgs.haskell.packages.${compiler}.ghc; in with nixpkgs; lib.overrideDerivation ghc (drv: { name = "ghc-dev"; nativeBuildInputs = drv.nativeBuildInputs ++ [ arcanist git python36Packages.sphinx texlive.combined.scheme-basic ]; }) Any help would be appreciated. Thanks Sean G

3 3

Re: [Haskell] [ANNOUNCE] GHC 8.4.2 released
by Ben Gamari 30 May '18

30 May '18

Andrés Sicard-Ramírez <asr(a)eafit.edu.co> writes: > On 19 April 2018 at 19:01, Ben Gamari <ben(a)well-typed.com> wrote: >> The GHC team is pleased to announce the availability of GHC 8.4.2. > > Please note that the tar files for the binary distributions for Linux > (x86_64) Debian 9 and Debian 8 are the same (i.e. > ghc-8.4.2-x86_64-deb8-linux.tar.xz) on the following link > > https://www.haskell.org/ghc/download_ghc_8_4_2.html#linux_x86_64 > > The same happens on GHC 8.4.3. > Fixed. Thanks for letting me know. Cheers, - Ben

1 0

LclId -> GblId question
by Gabor Greif 30 May '18

30 May '18

Hi devs, I have a simple question, but could not find an answer yet. The same variable (I checked!) appears in two dumps with different names and different external visibilities. Which pass transforms this variable to a global id, and why? Shouldn't a LclId remain local along the entire optimisation chain? Any hint appreciated! Cheers and thanks, Gabor Snippets from dumps below ############################################################## -rw-r--r-- 1 ggreif sw12 3281225 May 29 14:14 TcSMonad.dump-stranal -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} lvl_sOra :: TcTyVarDetails [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] lvl_sOra = ghc-prim-0.5.3:GHC.Magic.noinline @ TcTyVarDetails vanillaSkolemTv ############################################################## -rw-r--r-- 1 ggreif sw12 1438015 May 29 14:14 TcSMonad.dump-simpl -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} TcSMonad.isFilledMetaTyVar_maybe2 :: TcTyVarDetails [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] TcSMonad.isFilledMetaTyVar_maybe2 = ghc-prim-0.5.3:GHC.Magic.noinline @ TcTyVarDetails vanillaSkolemTv ##############################################################

1 1

ghci recompilation avoidance
by Evan Laforge 30 May '18

30 May '18

After switching to git, I discovered that ghci is interpreting a lot of modules when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)' instead of 'Skipped SomeModule'). It turns out that git checkouts update the modtime on checked-out files, even when they get reverted back to their original contents. Shake has an option ChangeModtimeAndDigestInput to check file contents in addition to modtime to not get fooled by this, but ghc is still doing a plain modtime check. So shake correctly skips the rebuild on those modules, but ghci recompiles them anyway. This means I'm better off just disabling shake's digest check, since otherwise I can just never recompile that stuff at all. Would it be reasonable to do the same kind of check as shake in ghc? Namely, shake does a quick check if modtime has changed, but even if it has, it checks the file contents digest to make sure. My understanding is that ghc does the quick modtime check, and then does an expensive interface check. This would augment that to become a quick modtime check, then a quick-ish digest check, and then the expensive interface check. I guess the old input file digest will have to be stored somewhere, presumably in the .hi file, so it's not a totally trivial change. The benefit should be that anyone working with git should be able to reuse more .o files after branch checkouts. The two relevant places seem to be GHC.loadModule and DriverPipeline.runPhase. I'm willing to have a go at this if people think it's a good idea and I can get some pointers on the .hi plumbing if I get hung up there.

2 2