- ghc-devs - Haskell.org

Re: [commit: ghc] master: Make Data.List.takeWhile fuse: fix #9132 (d14d3f9)
by Joachim Breitner 08 Oct '14

08 Oct '14

Hi, Am Mittwoch, den 08.10.2014, 06:53 +0000 schrieb git(a)git.haskell.org: > commit d14d3f92d55a352db7faf62939127060716c4694 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Wed Oct 8 08:53:26 2014 +0200 > > Make Data.List.takeWhile fuse: fix #9132 > > Summary: > Rewrites takeWhile to a build/foldr form; fuses repeated > applications of takeWhile. > > Reviewers: nomeata, austin > > Reviewed By: nomeata > > Subscribers: thomie, carter, ezyang, simonmar > > Projects: #ghc > > Differential Revision: https://phabricator.haskell.org/D322 > > GHC Trac Issues: #9132 nofib’s fft2’s allocs -23%, nice! (otherwise no differences worth mentioning). 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

1 0

Windows build broken (again)
by Simon Peyton Jones 08 Oct '14

08 Oct '14

Sigh. The testsuite fails utterly on Windows, with thousands of identical errors =====> tc012(normal) 3039 of 4088 [1, 2677, 88] cd .\typecheck\should_compile && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc012.hs -fno-warn-incomplete-patterns >tc012.comp.stderr 2>&1 sh: line 0: cd: .typecheckshould_compile: No such file or directory Compile failed (status 256) errors were: *** unexpected failure for tc012(normal) Presumably this is some kind of Windows escape-character problem. But it has worked fine for years, so what is going on? It's very tiresome dealing with Windows breakage so frequently. A few regression test failures, maybe, but outright breakage is very bad. Simon

6 7

FFI: c/c++ struct on stack as an argument or return value
by Yuras Shumovich 07 Oct '14

07 Oct '14

Hi, Right now ghc's FFI doesn't support c/c++ structures. Whenever we have foreign function that accepts or returns struct by value, we have to create wrapper that accepts or returns pointer to struct. It is inconvenient, but actually not a big deal. But there is no easy workaround when you want to export haskell function to use it with c/c++ API that requires structures to be passed by value (Usually it is a callback in c/c++ API. You can't change it's signature, and if it doesn't provide some kind of "void* userdata", then you are stuck.) I'm interested in fixing that. I'm going to start with 'foreign import "wrapper" ...' stuff. Calling conventions for passing c/c++ structures by value are pretty tricky and platform/compiler specific. So initially I'll use libffi for that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see rts/Adjustor.c). It will allow me to explore design space without bothering about low level implementation details. Later it could be implemented for native (non-libffi) adjustors. Is anybody interested it that? I appreciate any comments/ideas. Right now I don't have clear design. It would be nice to support plain haskell data types that are 1) not recursive, 2) has one constructor and 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any ideas are welcome. An example how to use libffi with structures: http://www.atmark-techno.com/~yashi/libffi.html#Structures Thanks, Yuras

7 19

oneShot (was Re: FoldrW/buildW issues)
by David Feuer 07 Oct '14

07 Oct '14

Just for the heck of it, I tried out an implementation of scanl using Joachim Breitner's magical oneShot primitive. Using the test scanlA :: (b -> a -> b) -> b -> [a] -> [b] scanlA f a bs = build $ \c n -> a `c` foldr (\b g x -> let b' = f x b in (b' `c` g b')) (const n) bs a scanlB :: (b -> a -> b) -> b -> [a] -> [b] scanlB f a bs = build $ \c n -> a `c` foldr (\b g -> oneShot (\x -> let b' = f x b in (b' `c` g b'))) (const n) bs a f :: Int -> Bool f 0 = True f 1 = False {-# NOINLINE f #-} barA = scanlA (+) 0 . filter f barB = foldlB (+) 0 . filter f with -O2 (NOT disabling Call Arity) the Core from barB is really, really beautiful: it's small, there are no lets or local lambdas, and everything is completely unboxed. This is much better than the result of barA, which has a local let, and which doesn't seem to manage to unbox anything. It looks to me like this could be a pretty good tool to have around. It certainly has its limits—it doesn't do anything nice with reverse . reverse or reverse . scanl f b . reverse, but it doesn't need to be perfect to be useful. More evaluation, of course, is necessary.to make sure it doesn't go wrong when used sanely. David

3 3

Stepping through ghc
by Omar Mefire 07 Oct '14

07 Oct '14

Hi, I'm new to ghc codebase and I'm interested in stepping through the code in order to gain a better idea of how it all works. - Is there a way to load ghc into ghci ? and debug through it ? - What are the ways experienced ghc devs step through the code ? - Any techniques you guys recommend ? - What would your advices be for a newbie to the source code ? Thanks, Omar Mefire,

4 3

Framework failures
by Simon Peyton Jones 07 Oct '14

07 Oct '14

I'm getting three "framework failures" in the testsuite, as below, on Linux. Does anyone have any idea why that might happen? Simon =====> haddock.compiler(normal) 1891 of 4114 [0, 0, 2] *** framework failure for haddock.compiler(normal) do_test exception Traceback (most recent call last): File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 764, in do_test result = apply(func, [name,way] + args) File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 1035, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "/home/simonpj/code/HEAD-3/testsuite/driver/testlib.py", line 1045, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t'

1 0

Re: Stepping through ghc
by Omar Mefire 07 Oct '14

07 Oct '14

Hi Arash, Thanks for your reply. I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for now. Thanks for the link to the commentary. I'm going through it right now. ------- "Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary Cheers, Arash" Omar Mefire, Le Mardi 7 octobre 2014 0h08, Omar Mefire <omefire(a)yahoo.fr> a écrit : Hi Arash, Thanks for your reply. I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for a beginning. Thanks for the link to the commentary. I'm going through it right now. P.S: I emailed you directly because I had some difficulties figuring out how to respond only to your message instead of the whole daily digest. Hopefully, will figure it out shortly. :) " Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary" Omar Mefire, Le Lundi 6 octobre 2014 12h55, "ghc-devs-request(a)haskell.org" <ghc-devs-request(a)haskell.org> a écrit : Send ghc-devs mailing list submissions to ghc-devs(a)haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/ghc-devs or, via email, send a message with subject or body 'help' to ghc-devs-request(a)haskell.org You can reach the person managing the list at ghc-devs-owner(a)haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ghc-devs digest..." Today's Topics: 1. Re: GitHub pull requests (Richard Eisenberg) 2. RE: Show instance for SrcSpan (Simon Peyton Jones) 3. Re: GitHub pull requests (Ben Gamari) 4. Re: Stepping through ghc (Arash Rouhani) 5. RE: Again: Uniques in GHC (p.k.f.holzenspies(a)utwente.nl) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Oct 2014 10:32:23 -0400 From: Richard Eisenberg <eir(a)cis.upenn.edu> To: andreas.abel(a)gu.se Cc: "ghc-devs(a)haskell.org Devs" <ghc-devs(a)haskell.org> Subject: Re: GitHub pull requests Message-ID: <DB3A2790-D285-4DE1-B05A-AF6F68389B88(a)cis.upenn.edu> Content-Type: text/plain; charset=us-ascii I think the "arc" barrier is significant. Personally, while I feel quite comfortable hacking on Haskell code, system tools are always a bit of a mystery. Those of you who help manage the infrastructure may feel like the tools are easy enough to pick up, but I'm sure there are many competent Haskell programmers out there who dread learning new tooling. (Perhaps I'm a representative sample of this set. I still say `git help merge` before just about every merge, just to make sure that I'm remembering the concepts correctly.) I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst. All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed. I agree with the comment that users will be more committed to learn Phab once they have contributed. That's why I wanted to point them to Phab in the automated response to the GH pull request. I think there's a psychological commitment made by a person once they click "submit pull request" and they will be happy enough to follow up on Phab, especially if commenting and such doesn't require the installation of a local tool. Richard ------------------------------ Message: 2 Date: Mon, 6 Oct 2014 18:10:37 +0000 From: Simon Peyton Jones <simonpj(a)microsoft.com> To: Alan & Kim Zimmerman <alan.zimm(a)gmail.com>, "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Subject: RE: Show instance for SrcSpan Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F319EA3(a)DB3PRD3001MB020.064d.mgd.msft.net> Content-Type: text/plain; charset="utf-8" By all means do so S From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 06 October 2014 13:59 To: ghc-devs(a)haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan

1 0

Show instance for SrcSpan
by Alan & Kim Zimmerman 06 Oct '14

06 Oct '14

Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan

6 9

Re: GitHub pull requests
by Herbert Valerio Riedel 05 Oct '14

05 Oct '14

Hello, On 2014-10-05 at 14:03:41 +0200, Joachim Breitner wrote: > Am Sonntag, den 05.10.2014, 13:08 +0200 schrieb Herbert Valerio Riedel: >> On 2014-10-05 at 12:56:28 +0200, Joachim Breitner wrote: >> >> [...] >> >> > I think the advantage could outweigh the downside and it’s worth a try. >> > We don’t even have to advocate it aggressively, just remove the „Do not >> > submit PRs“ notice on the repo and see what happens. >> > >> > (The problem with the ticket numbers remain, unfortunately.) >> >> Take into account though, there's no easy going back once we open that >> Pandora box; once GitHub allocates a #-number for a repo, it can only be >> removed by involving the GitHub admins, and until then any overlapping >> #-reference will lead to confusing notifications and ticket/issue >> comments associated w/ the respective Trac-ticket and/or GitHub >> pull-request. > > that’s a valid point. > > Is there maybe a way to disable all #-number-parsing on GitHub? But I > haven’t seen it... Not that I know of; I'd be a bit suprised though if it was indeed possible, as it's a core feature of GitHub (and after all, you can't disable the PR-submission either) Cheers, hvr

1 0

Re: dropWhileEndLE breakage
by David Feuer 03 Oct '14

03 Oct '14

Simon Peyton Jones asked > What's going on here? No other library module defines this function, except in Cabal! > Simon That was my fault; I'm very sorry. I had added that function (similar to Data.List.dropWhileEnd, but not the same) to compiler/utils/Util.lhs and to another module that used it, and then forgot it was not available in libraries/base/GHC/. Since neither Phab nor I run Windows, there was little hope of catching the mistake before it went out. I believe Joachim Breitner has fixed the problem now by using Data.List.dropWhileEnd to construct that error message—the difference in behavior doesn't matter there. David Feuer

1 0