- ghc-devs - Haskell.org

Specialization plugin
by Ryan Trinkle 31 Oct '16

31 Oct '16

Hi everyone, I'm trying my hand at writing a GHC plugin to generate specializations for all uses of a particular typeclass, and I've run into some trouble. I'd appreciate it if someone could point me in the right direction! I'm new to GHC development, so I may just be overlooking some simple stuff. The original problem: Reflex's interface is presented as a typeclass, which allows the underlying FRP engine to be selected by instance resolution. Although some programs make use of this (particularly the semantics test suite), most only ever use one implementation. However, since their code is typically written polymorphically, the implementation cannot be inlined and its rewrite rules cannot fire. This means that the typeclass My attempted solutions: * Initially, I wrote a plugin that adds INLINABLE pragmas to everything. This helped; small programs now generally see the inlining/rule-firings I was hoping for. However, in large programs, this does not occur. I'm looking into this, but also trying another approach: * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to every binding whose type mentions Reflex. The trouble: Since SPECIALIZE pragmas seem to be removed during typechecking (DsBinds.dsSpec), I can't directly add them. I would like to, perhaps, invoke Specialise.specBind; however, I'm not sure how to obtain the necessary instance - as mentioned here <https://github.com/ghc/ghc/blob/c36904d66f30d4386a231ce365a056962a881767/co…>, "only the type checker can conjure [dictionaries] up". Perhaps it's possible to explicitly create that dictionary somewhere and extract it for use during the plugin pass? Thanks, Ryan

4 5

[Help needed] GHC HCAR Submission Contributors
by Ben Gamari 29 Oct '16

29 Oct '16

Hello everyone, Haskell Communities and Activities Report submission season is once again upon us. If you are receiving this message then you have a major contribution listed on the GHC 8.2 status page and therefore should have a corresponding entry in GHC's HCAR submission. I've collected some notes for our submission in the usual place [1]. Please have a look and refine as you see fit. In particular, I'd really like to see some text added by, * Edward Yang: Backpack * Ryan Scott: Deriving strategies, new classes * Simon Marlow: NUMA and schduler changes * Bartosz Nitka: Determinism Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct16

1 1

Dynamic Linking help
by lonetiger＠gmail.com 28 Oct '16

28 Oct '16

Hi *, I’ve been working the past 4 or so months on reviving dynamic linking support for Windows in a way that has the most chance of working. My first patch in the series is up on Phabricator and with this patch dynamic linking work again, but only for the threaded RTS. The reason for this is because the core libraries that get distributed with GHC get compiled with -threaded and shared libraries on Windows can’t have dangling symbols. In any case, I’m at the point now where I need to be able to delay the selection of the runtime library till the final link. E.g. when the exe or dll is made. The problem however is that when linked normally, dependencies are satisfied by the Windows loader, before the program is run. One way I could do this is with Window’s equivalent to SONAME. Unfortunately this only works with SxS Assemblies, and I’ll need Admin rights to be able to register the shared libraries. This is a problem for running tests in the testsuite using the inplace GHC. Typically on Windows the way you would do this is by delay loading the dll. This allows me to write some code on startup and manually load the runtime dll. The Windows loader would then just use the loaded dll. Unfortunately delay loading does not support const extern data. Such as const extern RtsConfig defaultRtsConfig; The RTS/GHC is full of such usage so it won’t be easy to change. Though I’d only have to change those exposed by Rts.h. So I have two options: 1) Replace all const externs with a function call. This would work, but isn’t ideal because it would break if someone in the future adds a new data entry instead of a function. And we have an extra function call everywhere. 2) I could do some hacks on the Windows side, e.g. compile the program to a shared library, embed the shared library inside the exe and on startup after loading the propert rts, load the DLL from (mmapped) memory and run the code. I don’t like either approach and am hoping someone here has a better solution for me. Thanks, Tamar

2 4

Linker reorganization
by Ben Gamari 28 Oct '16

28 Oct '16

Hello RTS people, Today I finally grew frustrated enough with my constant battle with the 7000 line tangle of CPP that is rts/Linker.c to do something about it. The result is D2643 through D2650. In short, I took the file and chopped it into more managable pieces: * linker/PEi386.[ch]: PE loading * linker/MachO.[ch]: MachO loading * linker/Elf.[ch]: ELF loading * linker/CacheFlush.[ch]: Platform-specific icache flushing logic * linker/SymbolExtras.[ch]: Symbol extras support logic * Linker.c: Everything necessary to glue all of the above together * LinkerInternals.h: Declarations shared by the above and declarations for Linker.c For the most part this involved just shuffling code around since there was some rough platform abstraction already in place. In fact, I tried quite hard to avoid performing any more intricate refactoring to keep the scope of the project in check. Consequently, this is only a start and the design is in places a bit awkward; there is still certainly no shortage of work remaining to be done. Regardless, I think this change an improvement over the current state of affairs. One concern that I have is that the RTS's header file structure (where everything is #include'd via Rts.h) doesn't work very well for this particular use, where we have a group of headers specific to a particular subsystem (e.g. linker/*.h). Consequently, these header files currently lack enclosing `extern "C"` blocks (as well as Begin/EndPrivate blocks). It would be easy to add these, but I was curious to hear if others had any better ideas. The refactoring was performed over several small-ish commits, so review shouldn't be so bad. I expect to rebase the LoadArchive.c refactoring performed in D2642 on top of this set once it has been merged. I will also offer to rebase DemiMarie's recent error-handling patch (D2652). I have tested the set on a variety of platforms, * x86-64 Linux * x86-64 Darwin * x86-64 FreeBSD * x86-64 Windows * ARM Linux What do you think? Cheers, - Ben

4 4

setnumcapabilities001 failure
by Ben Gamari 28 Oct '16

28 Oct '16

Hi Simon, It seems that setnumcapabilities001 still occassionally fails, although this time by a different mode: https://phabricator.haskell.org/harbormaster/build/14485/?l=100 Cheers, - Ben

3 8

OSX failing
by Simon Peyton Jones 27 Oct '16

27 Oct '16

All OSX builds are failing with rts/Linker.c:6371:1: error: error: unused function 'machoGetMisalignment' [-Werror,-Wunused-function] See eg https://phabricator.haskell.org/harbormaster/build/14551/ So I get lots of “Phab failed” messages, and am now simply deleting them, which rather defeats the object of the exercise. Could someone fix this, or (I suppose) switch off the OSX build? Simon

3 2

How to best display type variables with the same name
by Christopher Done 27 Oct '16

27 Oct '16

We've encountered a problem in Intero which is that when inspecting types of expressions and patterns, sometimes it happens that the type, when pretty printing, yields variables of the same name but which have different provenance. Here's a summary of the issue: https://github.com/commercialhaskell/intero/issues/280#issuecomment- 254784904 And a strawman proposal of how it could be solved: https://github.com/commercialhaskell/intero/issues/280#issuecomment- 254787927 What do you think? Also, if I were to implement the strawman proposal, is it possible to recover from a `tyvar :: Type` its original quantification/its "forall"? I've had a look through the API briefly and it looks like a _maybe_. Ciao!

4 7

Tool for minimizing examples
by Eric Crockett 26 Oct '16

26 Oct '16

Devs: as I'm sure you know, the hardest part of reporting a GHC bug is finding a minimal example that triggers the bug. When I initially trigger a bug in my large code base, my workflow is something like: 1. write a driver that triggers the bug 2. do manual dead code elimination by removing unused files and functions 3. "human required" step to figure out what can be trimmed to further minimize 4. go to step 2 until example is simple enouogh Since I work on a large library (>60 modules) and also report a fair number of bugs, I spend a nontrivial amount of time on step 2, which is completely mechanical. It would be nice to have a tool that can help out. Specifically, something that takes a "driver" file, and produces a copy of the code contents to a new directory sans unimported files, and unused functions from imported files. Ideally, this tool would make a "closed universe" assumption so that exported functions can also be eliminated as dead, if they are never used elsewhere. A bonus feature would be to remove unused imports, and even unused build-depends from the cabal file. Are there any tools out there that can do any portion of this process for me? Perhaps it is possible to output contents after the compiler does a DCE pass? Regards, Eric Crockett

4 3

Re: New home for the perf.haskell.org builder wanted
by Ryan Trinkle 25 Oct '16

25 Oct '16

Hi Joachim and Sebastian, I think it would make sense to get a machine like that with Haskell.org funds. My company (Obsidian) would be happy to host it physically and cover internet/power/etc., although our facilities aren't too fancy (no redundant connections or anything like that). Best, Ryan On Tue, Oct 25, 2016 at 2:54 AM, Sebastian Graf <sgraf1337(a)gmail.com> wrote: > Hi, > > I'm the guy getting things going with the a more involved architecture ( > https://groups.google.com/forum/#!topic/haskell-cafe/Ak0eMiDVaCQ) I'm > currently reading into how to set up proper container images for master and > slave nodes, so > > I also do not necessarily need root access > > > If I'm not mistaken, root access will probably be needed for Docker, or > some way to submit container images to run stuff on. > > So long, > Sebastian > > On Tue, Oct 25, 2016 at 1:25 AM, Joachim Breitner < > mail(a)joachim-breitner.de> wrote: > >> Hi, >> >> although I have moved away from Karlsruhe three months ago, so far it >> is still my office PC driving >> https://perf.haskell.org/ghc/ >> >> But a new person is now using my desk and wants to use this machine, so >> I should really really move this away from there now. >> >> Sebastian Graf has been working on turning gipeda, the Frontend >> perf.haskell.org, into a more general service open to open source >> Haskell projects, and this is close, but not close enough to simply >> stop running the performance tests until he is good to go. >> >> He currently has a machine given from haskell.org to run this on, but >> it is a virtual machine and the measurements are too flaky for real >> use. >> >> So basically, I need a decent non-virtualized (or virtualized, but >> exclusive) machine to move my performance build runner to, as quickly >> as possible. The current specs are >> * 8 core Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz >> * 16 GB RAM >> but it does not matter too much, a slightly weaker machine would be >> able to keep up as well. I also do not necessarily need root access >> (but it would be beyond the point if the machine would do other stuff >> that incurs a heavy load). >> >> The same machine could then be used by Sebastian for his more general >> setup, once that is ready to go. >> >> Does anyone have something handy? >> >> Greetings, >> Joachim >> >> >> -- >> Joachim “nomeata” Breitner >> mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ >> XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >> Debian Developer: nomeata(a)debian.org > > >

1 1

Long-term storage of abandoned branches
by Joachim Breitner 24 Oct '16

24 Oct '16

Hi, in https://ghc.haskell.org/trac/ghc/ticket/12618#comment:37 Simon raises a question that I was wondering about as well: Where do we want to store feature branches that contain useful work that might be picked up some time later (maybe much later¹)? So far, I have left them as wip/foobar branches. Which works ok, but it clutters up the branch namespace, and “wip” is a lie. Maybe I should move the branch to archive/foobar, to make it clear that this is not something actively worked on? An alternative is having it in Phab only, where it is “more out of the way”, and there is commentary attached to it. Linked from the appropriate ticket, the code is as accessible as a git branch. But are we committed to keeping the Differential Revisions around for years? Also, if the branch contains many small commits, which presumably makes it more useful to whoever revives the project one day, it is easy to recover that from Phab? (I wonder because arc land squashes commits.) Greetings, Joachim ¹ this does happen, see https://ghc.haskell.org/trac/ghc/ticket/1600#comment:52 -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2