- ghc-devs - Haskell.org

revertCAFs and -fexternal-interpreter
by Rahul Muttineni 07 Jun '18

07 Jun '18

Hello devs, I noticed that in ghc/GHCi/UI.hs, the calls to 'revertCAFs' are made in the compiler's RTS instead of the interpreter's RTS. When -fexternal-interpreter is on this distinction is visible, otherwise they are one and the same so it works as intended. Shouldn't there be a RevertCAFs data constructor in `libraries/ghci/GHCi/Message.hs` to tell the interpreter process to revert the CAFs in its heap? Thanks, Rahul Muttineni

2 1

Add taggedTrace to Debug.Trace
by Yuji Yamamoto 07 Jun '18

07 Jun '18

Nice to meet you, GHC Developers! I'm new to contributing to GHC. Today let me suggest new APIs of the Debug.Trace <http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html> module, named: - taggedTraceShowId :: Show a => String -> a -> a - taggedTraceWith :: (a -> String) -> String -> a -> a These are inspired by Elm's Debug.log <http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Debug#log> function. The prefix "tagged" is named after its argument <https://github.com/elm-lang/core/blob/5.1.1/src/Native/Debug.js#L5>. I mean, these new APIs prepend a string as a tag to the output by traceShowId etc. It helps us recognize what the printed values stand for. I frequently want such functions and write them manually or copy-and-paste from the Debug.TraceUtils. I'm tired of that. That's why I made this suggestion. *Comparison with the existing solution* - Debug.TraceUtils <http://hackage.haskell.org/package/TraceUtils-0.1.0.2/docs/Debug-TraceUtils…> : - Essentially, this suggestion is to add APIs already implemented by TraceUtils. - As the document of TraceUtils suggests, we can copy and paste the functions from its source, but it's still tiresome. - Combine Debug.Trace.traceShowId with Debug.Trace.trace: - e.g. trace "Tag" $ traceShowId x - A bit hard to type. - trace always prints a newline, which makes it difficult to tell the tags from the printed value. After receiving some feedback here, I'm going to submit to https://github.com/ghc-proposals/ghc-proposals Thanks in advance! -- Yuji Yamamoto twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

3 3

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