May 2015 - ghc-devs - Haskell.org

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

NOTE: Phabricator is down for a moment
by Austin Seipp 14 May '15

14 May '15

All, Phabricator is down for a few minutes - in my latest update it looks like we may have gotten hit by a bug. I'm working with upstream to fix it now. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Non-deterministic package IDs are really bad in 7.10
by Mateusz Kowalczyk 14 May '15

14 May '15

Hi, I'd like to bring some attention to ticket #4012 about non-determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. The situation was pretty bad in 7.8.4 in presence of parallel builds so we switched those off. Joachim's a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and we were hopeful for 7.10. Now that 7.10.1 is out and people have been using and testing it, the situation turns out to be really bad: daily we get multiple reports from people about their packages ending up broken and our only advice is to do what we did back in 7.8 days which is to purge GHC and rebuild everything locally or fetch everything from a machine that already built it all, as long as the two don't mix. This is not really acceptable. See comment 76 on #4012 for an example of a rather simple file you can compile right now with nothing extra but -O and get different interface hash. This e-mail is just to raise awareness that there is a serious problem. If people are thinking about cutting 7.10.2 or whatever, I would consider part of this ticket to be a blocker as it makes using GHC reliably while benefitting from binary caches pretty much impossible. Of course there's the ‘why don't you fix it yourself’ question. I certainly plan to but do not have time for a couple more weeks to do so. For all I know right now, the fix to comment 76 might be easy and someone looking for something to hack on might have the time to get to it before I do. Thanks -- Mateusz K.

4 3