- ghc-devs - Haskell.org

[GHC Proposal] "Constraint to Bool" wired-in type family
by Ben Gamari 17 Jan '17

17 Jan '17

Hello everyone, Sylvain Henry just opened Pull Request #22 [1] against the ghc-proposals repository. This proposal describes a type family which would given users access to type-level evidence of the satisfiability of a constraint. Please feel free to read and discuss the proposal on the pull request. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/22

1 1

RE: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation
by Simon Peyton Jones 16 Jan '17

16 Jan '17

I'm sorry but I cannot make head or tail of the offending build log here. I validated from scratch at my end. Could it be a Harbormaster error? Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 16 January 2017 16:52 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation Harbormaster failed to build B13227: rGHC5a9a1738023a: Refine exprOkForSpeculation! BRANCHES master USERS simonpj (Author) O12 (Auditor) O20 (Auditor) COMMIT https://phabricator.haskell.org/rGHC5a9a1738023a EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

2 1

Including remote-iserv upstream?
by Shea Levy 16 Jan '17

16 Jan '17

Hi Simon, devs, As part of my work to get TH working when cross-compiling to iOS, I've developed remote-iserv [1] (not yet on hackage), a set of libraries for letting GHC communicate with an external interpreter that may be on another machine. So far, there are only three additions of note on top of what the ghci library offers: 1. The remote-iserv protocol has facilities for the host sending archives and object files the target doesn't have (dynlibs not yet implemented but there's no reason they can't be). This works by having the server send back a Bool after a loadObj or loadArchive indicating whether it needs the object sent, and then just reading it off the Pipe. 2. The remote-iserv lib abstracts over how the Pipe it communicates over is obtained. One could imagine e.g. an ssh-based implementation that just uses stdin and stdout* for the communication, the implementation I've actually tested on is a TCP server advertised over bonjour. 3. There is a protocol version included to address forwards compatibility concerns. As the library currently stands, it works for my use case. However, there would be a number of benefits if it were included with ghc (and used for local iserv as well): 1. Reduced code duplication (the server side copies iserv/src/Main.hs pretty heavily) 2. Reduced overhead keeping up to date with iserv protocol changes 3. No need for an extra client-side process, GHC can just open the Pipe itself 4. Proper library distribution in the cross-compiling case. The client needs to be linked with the ghci lib built by the stage0 compiler, as it runs on the build machine, while the server needs to be linked with the ghci lib built by the stage1 compiler. With a distribution created by 'make install', we only get the ghci lib for the target. Currently, I'm working around this by just using the ghci lib of the bootstrap compiler, which in my case is built from the same source checkout, but of course this isn't correct. If these libs were upstream, we'd only need one version of the client lib exposed and one version of the server lib exposed and could have them be for the build machine and the target, respectively 5. Better haskell hackers than I invested in the code ;) Thoughts on this? Would this be welcome upstream in some form? Thanks, Shea * Note that, in the general case, having the server process's stdio be the same as the compiler's (as we have in the local-iserv case) is not possible. Future work includes adding something to the protocol to allow forwarding stdio over the protocol pipe, to make GHCi usable without watching the *server*'s console. [1]: https://github.com/obsidiansystems/remote-iserv

3 4

Exhaustiveness checking for pattern synonyms
by Matthew Pickering 14 Jan '17

14 Jan '17

Hello devs, I have implemented exhaustiveness checking for pattern synonyms. The idea is very simple, you specify a set of pattern synonyms (or data constructors) which are regarded as a complete match. The pattern match checker then uses this information in order to check whether a function covers all possibilities. Specification: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs https://phabricator.haskell.org/D2669 https://phabricator.haskell.org/D2725 Matt

3 4

Travis Builds are broken
by Matthew Pickering 13 Jan '17

13 Jan '17

A recent commit has caused the Travis builds to stop working. I think it was caused by https://phabricator.haskell.org/rGHCc2bd62ed62d2fae126819136d428989a7b4ddc79 Example failure Wrong exit code for plugins01()(expected 0 , actual 2 ) Stderr ( plugins01 ): ghc-stage2: /home/travis/build/ghc/ghc/libraries/ghci/dist-install/build/HSghci-8.1.o: unknown symbol `purgeObj' ghc-stage2: unable to load package `ghci-8.1' make[2]: *** [plugins01] Error 1 *** unexpected failure for plugins01(normal) Full log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/190738798/log.txt Jon, could you perhaps take a look to see if the fix is obvious? Matt

1 0

Kind page of trac wiki
by Takenobu Tani 13 Jan '17

13 Jan '17

Dear devs, May I update Kind page of trac wiki [1] as following ? - "#" is the kind of unboxed values. Things like Int# have kind #. + "#" is the kind of unlifted values. Things like Int# have kind #. Is this correct? (These pages [2][3] are explained as "unlifted values".) [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Kinds [2]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes [3]: https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds Regards, Takenobu

2 2

Build failures
by Simon Peyton Jones 13 Jan '17

13 Jan '17

recomp001 is failing on Harbormaster on OSX (only). Does anyone know why? See for example https://phabricator.haskell.org/harbormaster/build/18293/ Simon

2 1

ANN: `dump-core` a prettier GHC core viewer
by Iavor Diatchki 13 Jan '17

13 Jan '17

Hello, Over the holidays I wrote a small GHC plugin to help me do some low-level optimizations of Haskell code. I thought it might be of use to other people too, so please try it out! When enabled, the plugin will save the Core generated by GHC in JSON format, and also render it in HTML for human inspection. The plugin is available on Hackage: http://hackage.haskell.org/package/dump-core The instructions on how to use it are in the README file. You may also read about it at the github page: http://hackage.haskell.org/package/dump-core There are many things that could probably be improved, just let me know. Also, if you are good at design, I could use some help making things look prettier :) Happy hacking, -Iavor

6 7

Inlining Wiki Page
by Matthew Pickering 12 Jan '17

12 Jan '17

Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a newcomer to start working on GHC. The inliner is quite well contained, there are lots of open tickets with well-specified aims and lots of investigatory work to be done. So the purpose of this email is: 1. Please tag any tickets relevant to inlining/specialisation with "Inlining" 2. Any newcomers keen to get involved should read the wiki page and see if they can tackle one of the tickets there. Matt

3 3

many haskell's mails are detected as spam on gmail
by Takenobu Tani 12 Jan '17

12 Jan '17

Hi, I'm using gmail. Recently, many haskell's mails are detected as spam on gmail. (ghc-devs, haskell-cafe, ghc-commit, ...) Does anyone know why? Do you know the workaround? Regards, Takenobu

5 4