- ghc-devs - Haskell.org

GHC Trac slow again
by Simon Peyton Jones 20 May '15

20 May '15

Herbert Did you manage to fix your Trac re-initialiser? Trac is soul-destroyingly slow today Simon

2 1

Interactions between type-checker plugins
by Christiaan Baaij 19 May '15

19 May '15

Hi, My apologies for this rather lengthy email. I have a question about how type-checker plugins should interact. My situation is the following: I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-checker plugin that can prove equalities involving a new type-level operation GCD. In the following, the type-checker plugin involving the stand type-level operations is called ‘A’, and the type checker involving the new GCD operations is called ‘B’. When type-checker plugin A encounters: [W] GCD 6 8 + x ~ x + GCD 9 6 It knows that (+) is commutative, so it can prove the above equality _given_ that "GCD 6 8 ~ GCD 9 6” holds. So what type-checker plugin A does now is emits a new wanted constraints: [W] GCD 6 8 ~ GCD 9 6 And remembers that it emitted this wanted constraint. In type-checker plugin lingo, it returns: TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6”] Now whenever type-checker plugin encounters [W] GCD 6 8 + x ~ x + GCD 9 6 again, it checks to see if the discharged constraint [W] GCD 6 8 ~ GCD 9 6 Is already solved, is disproven, or unsolved. If the discharged constraint is solved, it will return: TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6”] [] If the discharged constraint is dis proven, it returns: TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6”] And otherwise, it doesn’t do anything: TcPluginOk [] [] Now, type-checker plugin B, the one that knows about GCD, comes along. It sees: [W] GCD 6 8 + x ~ x + GCD 9 6 [W] GCD 6 8 ~ GCD 9 6 I doesn’t know anything about (+); but it does know about GCD, and clearly sees that GCD 6 8 is not equal to GCD 9 6. So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. In type-checker plugin lingo it says: TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6”] According to https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… What happens next is that the insoluble constraint [W] GCD 6 8 ~ GCD 9 6 is taken of the work list for all plugins. However! the same thing happens when a plugin is able to prove a constraint. That is, if B would have (erroneously) returned: TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6”] [] Then there is _no_ way for type-checker plugin A to know what happened. Were its discharged constraints taken from the work-list because it was insoluble? or because it was solved? This is a problem because to me it seems that the work list is the only way that two type-checker plugins can communicate. I guess my question is: if not through the work list, how are type-checker plugins supposed to communicate? Am I going about it all wrong in terms how I should be writing type-checker plugins? Or, should the type of ‘TcPluginSolver’ (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) be updated to?: ``` type TcPluginSolver = [Ct] -- ^ Given constraints -> [Ct] -- ^ Derived constraints -> [Ct] -- ^ Wanted constraints -> [Ct] -- ^ Insoluble constraints -> TcPluginM TcPluginResult ``` Best regards, Christiaan

2 1

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 19 May '15

19 May '15

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

5 6

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by malcolm.wallace 19 May '15

19 May '15

How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz <haskell(a)kuhtz.eu> wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, #8555
by Simon Peyton Jones 19 May '15

19 May '15

Devs, The failure seems to be for ghci.debugger/print007. I can't see the build log on Phabricator, so I can't see what went wrong. Works on my machine. I do see print007.stderr <no location info>: Warning: -O conflicts with --interactive; -O ignored. which seems odd. Why not fix the test? Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 19 May 2015 12:20 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, | #8555 | | Harbormaster failed to build B4076: rGHCfc8c5e7a5168: Test Trac #8799, | #8555! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCfc8c5e7a5168 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

2 1

api annotations test failures
by Joachim Breitner 18 May '15

18 May '15

Hi, I observe this on travis: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: collect2: ld terminated with signal 9 [Killed] make[3]: *** [t10358] Error 1 *** unexpected failure for T10358(normal) Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: collect2: ld terminated with signal 9 [Killed] make[3]: *** [T6145] Error 1 *** unexpected failure for T6145(normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/62625154/log.txt It’s hard to pin-point the exact time this started, as recently there a number of unrelated build failures made their way into master. Does anybody know where this comes from and how to fix it? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 5

Revert revert revert
by Simon Peyton Jones 18 May '15

18 May '15

Devs, Austin I've found out what the problem was, and fixed it. What is the right way to re-do all this? My thought: * git revert 3cf8ecd I think this will re-apply all my patches, in one go. (call this new path 'foogle') * apply the fix as a new patch * validate The history will look odd. In particular, if someone does 'git blame' then lots of unrelated changes will all map to 'foogle'. And 'foogle's commit message will say "revert a revert of 10 patches". Which is not helpful. Best would be to re-apply the patches one by one I suppose. How could I do that? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 14 May 2015 22:26 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic | performance lossage | | #10359: Tuple constraint synonym led to asymptotic performance lossage | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: axch | Owner: | Type: bug | Status: | closed | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Resolution: fixed | Keywords: | Operating System: Linux | Architecture: | x86_64 | Type of failure: Runtime | (amd64) | performance bug | Test Case: | Blocked By: | perf/should_run/T10359 | Related Tickets: | Blocking: | | Differential Revisions: | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Austin Seipp <austin@…>): | | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" | Revert multiple commits | | This reverts multiple commits from Simon: | | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable- | given" | check happen first | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to | checkValidTyCon | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet | from fixVarSet | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain | (stage2) | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the | build | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation | of error msg | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple | constraints | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out | line | | These break the build by causing Haddock to fail mysteriously when | trying to examine GHC.Prim it seems. | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10359#comment:9> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

3 3

GADT confusion
by Alan & Kim Zimmerman 18 May '15

18 May '15

Hi all I am working on D836 and have the following test case data MaybeDefault v where SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) GHC 7.10.1 regards the return type of SetTo4 as `MaybeDefault [a]` The question is, due to the parens, is the return type not the whole RHS? i.e. Similar to how in the signature map :: (a -> b) -> [a] -> [b] the first paramater is a single function. I am sure I am just confused here. Alan

2 2

New GHC performance dashboard
by Joachim Breitner 17 May '15

17 May '15

Dear ghc developers, last July I set up a performance dashboard for GHC, i.e. a website where you can see our performance numbers (nofib results, performance unit tests, build time etc.) for each commit. I used the software codespeed¹ as the backend, but I was dissatisfied with it: I found it was a tad too slow, the URLs were hard to share, but – most importantly – it tries to be VCS-agnostic, which just doesn’t work well. So in January, I wrote a new tool, called gipeda (Git Performance Dashboard)². The Haskell part generates static files, which are then displayed using JavaScript in the client (using bootstrap and handlebars), so it is reasonably fast. And it knows about (some) git concepts. I was about to announce it in February, but it ran on the same host as deb.haskell.org, which was compromised a few days before the announcement. Recently, though, davean of the haskell.org Admin team provided me with the required set (thanks for that!), so here it is: http://perf.haskell.org/ghc It should be relatively self-explanatory. Just note that by default it hides boring stuff (commits and results with no significant change), you can select what to show in the top-right corner. It does roughly what our codespeed setup did before, but I have some ideas that go beyond that: Comparison of arbitrary commits, better understanding of git branches and tags, aggregation of performance results from different hosts, e-mail notification. I hope that I’m not the only one who will work on them, and will be happy to receive help. The upcoming ZuriHac is a great possibility to join me here. There are also lot of ways you can contribute without touching Haskell (not that there are many people on this list to whom that matters :-)). Gipeda itself is in no way specific to GHC and you can use it for your own projects. We can possibly even host the results on http://perf.haskell.org/ – just talk to me. Also, see my gipeda announcement on haskell-cafe (which I’ll write next). Enjoy! Joachim ¹ https://github.com/tobami/codespeed ² https://github.com/nomeata/gipeda -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 3

Re: Debugging the RTS
by Jost Berthold 16 May '15

16 May '15

Hi Eric, definitely not bit-rotted - the #if DEBUG code is what you get when you compile with -debug. Short roadmap: In general, GHC is built in many "ways", the -debug way is one. Some ways (like -threaded, -eventlog, -debug) are RTS-only, others (like -prof) lead to different library code. Ways are defined in compiler/main/DynFlags.hs as a Haskell data structure. In _dynamic_flags_, the actual flag strings for the ghc invocation are defined (like -prof, -threaded), they will activate the respective _Way_. _wayTag_, in turn, defines short names used as a suffix for *.o and *.a files, for instance *.p_o for profiling, *.l_o for eventlog. A number of other functions in there customise behaviour depending on the ways. Note _wayOptc_ which sets some options for the C compiler, like -DTRACING for the -eventlog way. However, it does not define DEBUG for the debug way! In mk/ways.mk you will find all the short names, and some more options are defined (WAY_*_HC_OPTS). These definitions are for the driver script, and pass on the right (long-name) options to the Haskell compiler to activate what is inside DynFlags (like -prof for WAY_p_HC_OPTS). Here we find WAY_debug_HC_OPTS= -static -optc-DDEBUG -ticky -DTICKY_TICKY which is what you were looking for To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug to your build.mk (also see mk/config.mk{.in}, which gathers the default ways to build depending on platform and build configuration). I guess this might produce quite a number of new warnings and errors if you do it on a new platform... Once you have built this, you can compile with -debug and pass RTS options to get debug traces and activate sanity checks, like so: ghc -debug -myprogram.hs -o myprogramDebug ./myprogramDebug +RTS -Ds -DS (-DS = sanity checks on, -Ds = scheduler tracing) The usage message (see /rts/RtsFlags.c) tells you more options you can use. Happy debugging! / Jost On 05/14/2015 10:00 PM, ghc-devs-request(a)haskell.org wrote: > Date: Thu, 14 May 2015 18:36:04 +1000 > From: Erik de Castro Lopo <mle+hs(a)mega-nerd.com> > To: ghc-devs(a)haskell.org > Subject: Debugging the RTS > Message-ID: <20150514183604.2476baaaacd6a85ef1430b37(a)mega-nerd.com> > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > I'm trying to debug a AArch64/Linux specific RTS issue and digging > around in the rts C code, I see a large amount of code wrapped in > "#if DEBUG" type statements, but no way to enable in either > mk/build.mk or it seems in any of the other build related settings > files in the mk/ directory. > > The only way I have found to enable this debug code that actually > works is to enable this DEBUG code is to edit mk/ghc.mk as follows: > > -STANDARD_OPTS += -DCOMPILING_RTS > +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG > > However, once I do that I get a bunch of C synatx errors. > > I am doing this wrong or has the DEBUG code bit rotted? > > Cheers, > Erik >

5 6