- ghc-devs - Haskell.org

Re: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2, Success
by Karel Gardas 25 Aug '14

25 Aug '14

Gabor, thanks a lot for your fantastic job on getting windows builder running. It's great to have that in the pool and not need to speculate if the change breaks windows build or not sometimes in the future when someone attempts to build that. Now it's one night turn over and this is great. Thanks a lot! Karel On 08/23/14 07:33 AM, Builder wrote: > windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2 > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading windows extra src tarball | Success > uploading tarball source | Success > testing bindist | Success > testing | Success > testsuite summary | Success > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-builds

2 1

Suggestion for GHC System User's Guide documentation change
by Howard B. Golden 25 Aug '14

25 Aug '14

I suggest changing the User's Guide extensions documentation to consistently use the LANGUAGE pragma form to specify extensions and code examples, rather than a combination of LANGUAGE pragmas and -XExtension flags. I find the combination of the two confusing. Also, the reader copying code examples which require a specific LANGUAGE to compile will be assisted by including the LANGUAGE pragma in the code examples. For example, in section 7.3, I would change: -------------------------------------------- 7.3. Syntactic extensions 7.3.1. Unicode syntax The language extension -XUnicodeSyntax enables Unicode characters to be used to stand for certain ASCII character sequences. -------------------------------------------- To: -------------------------------------------- 7.3. Syntactic extensions 7.3.1. Unicode syntax The language extension {-# LANGUAGE UnicodeSyntax #-} enables Unicode characters to be used to stand for certain ASCII character sequences. -------------------------------------------- Similarly, I would include the required LANGUAGE pragma(s) in _all_ code examples. For example, in section 7.3.7, I would change: -------------------------------------------- type Typ data TypView = Unit | Arrow Typ Typ view :: Typ -> TypView -- additional operations for constructing Typ's ... -------------------------------------------- To: -------------------------------------------- {-# LANGUAGE ViewPatterns #-} type Typ data TypView = Unit | Arrow Typ Typ view :: Typ -> TypView -- additional operations for constructing Typ's ... -------------------------------------------- I realize that LANGUAGE pragmas must be in file headers. While it is possible that users may be confused if they try to put pragmas in the body of a source file, I believe this will be outweighed by the benefit of making the examples clearer about the extensions necessary to use them. If this change is accepted, I volunteer to make the necessary documentation patches to implement it. Howard B. Golden Northridge, CA USA

3 4

How's the integration of DWARF support coming along?
by Johan Tibell 23 Aug '14

23 Aug '14

Hi, How's the integration of DWARF support coming along? It's probably one of the most important improvements to the runtime in quite some time since unlocks *two* important features, namely * trustworthy profiling (using e.g. Linux perf events and other low-overhead, code preserving, sampling profilers), and * stack traces. The former is really important to move our core libraries performance up a notch. Right now -prof is too invasive for it to be useful when evaluating the hotspots in these libraries (which are already often heavily tuned). The latter one is really important for real life Haskell on the server, where you can sometimes can get some crash that only happens once a day under very specific conditions. Knowing where the crash happens is then *very* useful. -- Johan

6 16

RE: Windows build fails -- again!
by Simon Peyton Jones 23 Aug '14

23 Aug '14

Thanks Gabor. But it makes no difference. Your change is inside an #ifdef that checks for windows, and your change is in the no-windows branch only. Also there are two IOManager.h file includes/rts/IOManager.h rts/win32/IOManager.h Should there be? It seems terribly confusing, and I have no idea which will win when it is #included. Thanks Simon | -----Original Message----- | From: Gabor Greif [mailto:ggreif@gmail.com] | Sent: 19 August 2014 23:38 | To: Simon Peyton Jones | Subject: Re: Windows build fails -- again! | | Simon, | | try this (attached) patch: | | $ git am 0001-Make-sure-that-a-prototype-is-included-for- | setIOMana.patch | | Cheers, | | Gabor | | PS: on MacOS all is good, so I could not test it at all | | On 8/20/14, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: | > Aaargh! My windows build is broken, again. | > It's very painful that this keeps happening. | > Can anyone help? | > Simon | > | > "inplace/bin/ghc-stage1.exe" -optc-U__i686 -optc-march=i686 | > -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall | > -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes | > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return | > -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs | > -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist | > -optc-Iincludes/dist-derivedconstants/header | > -optc-Iincludes/dist-ghcconstants/header -optc-Irts | > -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing | > -optc-fno-common -optc-O2 -optc-fomit-frame-pointer | > -optc-DRtsWay=\"rts_v\" -static -H32m -O -Werror -Wall -H64m -O0 | > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header | > -Iincludes/dist-ghcconstants/header | > -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts | > -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen - | Irts/dist/build | > -Irts/dist/build/autogen -O2 -c rts/Task.c -o | > rts/dist/build/Task.o | > | > cc1.exe: warnings being treated as errors | > | > | > | > rts\Capability.c:1080:6: | > | > error: no previous prototype for 'setIOManagerControlFd' | > | > rts/ghc.mk:236: recipe for target 'rts/dist/build/Capability.o' | failed | > | > make[1]: *** [rts/dist/build/Capability.o] Error 1 | > | > make[1]: *** Waiting for unfinished jobs.... | > | > Makefile:71: recipe for target 'all' failed | > | > make: *** [all] Error 2 | > | > HEAD (master)$ | > | > | >

5 7

Random maintainership -- Was: [core libraries] RE: Core libraries bug tracker
by Ryan Newton 22 Aug '14

22 Aug '14

Dear core library folks & others, > On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones < simonpj(a)microsoft.com> wrote: > Some core libraries (e.g. random) have a maintainer that isn’t the committee. Ah, since it came up, maybe this is a good time to discuss that particular maintainership. I'm afraid that since it isn't close to my current work (and I'm pre-tenure!) I haven't been able to really push the random library forward the way it deserves to be pushed these last three years. Shall we move maintainership of it to the core libraries committee? Also/alternatively "Thomas Miedema <thomasmiedema(a)gmail.com>" has stepped forward as a volunteer for taking over maintainership. The library was in limbo in part because it was clear that some API changes needed to be made and but there wasn't a major consensus building design effort around that topic. One thing that was already agreed upon on via the libraries list decision process was to separate out SplittableGen. Duncan Coutts was in favor of this and also (I think) had some other ideas about API changes that should be made. On the implementation front, my hope was that "tf-random" could replace random as the default/standard library. Koen and Michal support this, but I think they didn't want to become the maintainers themselves yet. (I think that was to maintain some separation, and get buy-in from someone other than them, the implementors, before/during the transition). Best, -Ryan On Tue, Aug 19, 2014 at 5:55 PM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > > If you don't mind the extra traffic in the ghc trac, I'm open to the plan to work there. > > > > OK great. > > > > Let’s agree that: > > · The “owner” of a Core Libraries ticket is the person responsible for progressing it – or “Core Libraries Committee” as one possibility. > > · The “component” should identify the ticket as belonging to the core libraries committee, not GHC. We have a bunch of components like “libraries/base”, “libraries/directory”, etc, but I’m sure that doesn’t cover all the core libraries, and even if it did, it’s probably too fine grain. I suggest having just “Core Libraries”. > > > > Actions: > > · Edward: update the Core Libraries home page (where is that?) to point people to the Trac, tell them how to correctly submit a ticket, etc? > > · Edward: send email to tell everyone about the new plan. > > · Austin: add the same guidance to the GHC bug tracker. > > · Austin: add “core libraries committee” as something that can be an owner. > > · Austin: change the “components” list to replace all the “libraires/*” stuff with “Core Libraries”. > > > > Thanks > > > > Simon > > > > > > From: haskell-core-libraries(a)googlegroups.com [mailto: haskell-core-libraries(a)googlegroups.com] On Behalf Of Edward Kmett > Sent: 19 August 2014 16:23 > To: Simon Peyton Jones > Cc: core-libraries-committee(a)haskell.org; ghc-devs(a)haskell.org > Subject: Re: [core libraries] RE: Core libraries bug tracker > > > > Hi Simon, > > > > If you don't mind the extra traffic in the ghc trac, I'm open to the plan to work there. > > > > I was talking to Eric Mertens a few days ago about this and he agreed to take lead on getting us set up to actually build tickets for items that go into the libraries@ proposal process, so we have something helping to force us to come to a definitive conclusion rather than letting things trail off. > > > > -Edward > > > > On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones < simonpj(a)microsoft.com> wrote: > > Edward, and core library colleagues, > > Any views on this? It would be good to make progress. > > Thanks > > Simon > > > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon Peyton Jones > Sent: 04 August 2014 16:01 > To: core-libraries-committee(a)haskell.org > Cc: ghc-devs(a)haskell.org > Subject: Core libraries bug tracker > > > > Edward, and core library colleagues, > > This came up in our weekly GHC discussion > > · Does the Core Libraries Committee have a Trac? Surely, surely you should, else you’ll lose track of issues. > > · Would you like to use GHC’s Trac for the purpose? Advantages: > > o People often report core library issues on GHC’s Trac anyway, so telling them to move it somewhere else just creates busy-work --- and maybe they won’t bother, which leaves it in our pile. > > o Several of these libraries are closely coupled to GHC, and you might want to milestone some library tickets with an upcoming GHC release > > · If so we’d need a canonical way to identify tickets as CLC issues. Perhaps by making “core-libraries” the owner? Or perhaps the “Component” field? > > · Some core libraries (e.g. random) have a maintainer that isn’t the committee. So that maintainer should be the owner of the ticket. Or the CLC might like a particular member to own a ticket. Either way, that suggest using the “Component” field to identify CLC tickets > > · Or maybe you want a Trac of your own? > > The underlying issue from our end is that we’d like a way to > > · filter out tickets that you are dealing with > > · and be sure you are dealing with them > > · without losing track of milestones… i.e. when building a release we want to be sure that important tickets are indeed fixed before releasing > > Simon > > -- > You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

2 1

Re: [GHC] #9496: Simplify primitives for short cut fusion
by David Feuer 22 Aug '14

22 Aug '14

Yes, I meant "producer" there. On Fri, Aug 22, 2014 at 9:36 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9496: Simplify primitives for short cut fusion > -------------------------------------+------------------------------------- > Reporter: dfeuer | Owner: dfeuer > Type: task | Status: new > Priority: normal | Milestone: > Component: | Version: 7.8.3 > libraries/base | Keywords: fusion > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: Other | Related Tickets: > Test Case: | > Blocking: | > Differential Revisions: | > -------------------------------------+------------------------------------- > > Comment (by dfeuer): > > Replying to [comment:2 simonpj]: > > I believe that there are good reasons for distinguishing build and > augment. [http://research.microsoft.com/en-us/um/people/simonpj/papers > /andy-thesis.ps.gz Andy Gill's thesis] would be a good place to look. > But perhaps one could do everything in terms of augment; I'm not sure. > Worth a try. > > > > I think there is really only one primitive consumer, foldr. I thought > we rewrote into foldr and then back. If that is not done for or, any, > etc, I'm not sure why. Again, perhaps worth investigation. > > > > Certainly the original goal of the foldr/build paper was to say "ONE > rule, not n*m rules". > > > > Simon > > An aside: Just last night I saw a bit of the work Takano Akio has done on > incorporating a worker/wrapper transformation into the framework (although > I don't quite understand how it works yet). It doesn't seem to be quite > ready for prime time (there were apparently some issues with one NoFib > benchmark), but we might want to keep it in mind. > > I think the one rule concept is great. If that can be made to really work, > that would be ''ideal''. Unfortunately, the need to wrangle the inliner as > it currently works turns the one rule concept into an n*m-rule concept, > where m is certainly at least 1, but currently 2 (the rewrite back rule > clearly seems necessary for now—I don't yet understand things deeply > enough to know for sure if the rewrite to rule is strictly necessary in > all cases). I would speculate that the and/or/any/head/... rules came > about because someone thought to themselves "There's only one [sic] > consumer, `build`, so we can skip this difficult and invasive rewrite > to/from process and just fuse with `build`. That's easy!" Well, they were > a little wrong, but I'm not sure they were very wrong. > > I haven't had a chance to read the thesis yet, but from a purely practical > perspective, I don't see any difference between `build g` and `augment g > []`. I don't ''think'' anyone's tossing around partially applied > `augment`s or anything. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9496#comment:3> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler

1 0

Re: The formal definition of a crash in GHC
by Alexander Berntsen 22 Aug '14

22 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 28/02/14 13:41, Simon Peyton Jones wrote: > Crashing is usually formalised by the "progress" and "type > preservation" theorems that papers about statically-typed > programming languages usually offer. You will find many examples > of such theorems (and their proofs) in the papers about GHC's > intermediate language > http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ > > A "crash" would mean that execution get stuck, and the progress > theorem guarantees that cannot happen. Would you, or anyone else, be able to make a wiki article on these theorems? So that we have a centralised resource that we can refer to. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlP3Ip0ACgkQRtClrXBQc7WfAAD/VoQHW/bZLgdgoLCkSsLBGyIO B4F30jFLGuEB7NRvoIQBAKm0V4y2eutGUiSii0lTnzsP8Md3hKbZpUlcrqFmEQzf =OBHG -----END PGP SIGNATURE-----

1 0

Status of GHC targetting ARM?
by Iavor Diatchki 21 Aug '14

21 Aug '14

Hello, Does anyone have information about the status of GHC cross-compiling to ARM architectures? More specifically, I am interested in finding out what works and what still needs to be done before we can get GHC to generate binaries that can run on the various mobile platforms (Android, iOS). -Iavor

2 1

Status updates
by Austin Seipp 20 Aug '14

20 Aug '14

Hello *, Sorry for the scatter-brained-ness of my update. But without further ado, here are some things that have been going on: - I was going to land AMP, but I've gotten stuck again! It seems that now, Haddock infinite loops, but this one I really can't figure out. See my comment on the ticket[1] if you're adventurous - a small patch to Haddock and you should be able to build things, but it'll fail while Haddocking `ghc-prim`. Any help here would be much appreciated! - Phabricator now has significantly better build integration, as I'm sure many of you have seen. It is less noisy (and doesn't email you as much), has better logging support (that actually works), and it now builds commits AND patches! It's been in-production since last week and a lot more reliable than the crap I wrote before. I am thinking of changing the Phabricator GHC commit builder to validate all commits in `--slow` mode, which we can't do on Travis, and will catch more failures. I assume most people would approve of this. :) - The wiki has been updated in several spots: - The Phabricator page is now more detailed about Audits and more up to date about builds.[2] Yes, I know it looks long, but it's really just due to a lot of pictures. It's actually quite short still. - The Git workflow pages (starting from WorkingConventions/Git) have seen some minor updates[3], but nothing substantial. Some old pages still need to be deleted possibly, and some things (e.g. GitHub) might need further tweaks. - Yes, we're still seeing spam, but unfortunately nobody has had time to fix the CAPTCHAs yet. If you can write some python and want to, I'm sure Herbert would like to know. :) - There is a new status in Trac, primarily useful for patches, called 'upstream', which is very similar to 'patch', but says that the change goes to an upstream library that GHC must synchronize with. This difference is now much more important since many of our packages are tracked through submodules. See the working conventions page for some details and a pretty graph[4]. - I've gone ahead and split my old optimized-memcpy patch into two patches - D165 and D166 on Phabricator. Hopefully these will go in soon after some discussion with Johan about how we want to handle the flags is talked out. - All of the Phabricator patches from outstanding contributors have been merged, I think. There are some outstanding reviews still going on, and some accepted commits still waiting for other reviewers I believe. - Almost all of the current outstanding patches have been either merged, taken out of patch state (in case they were in limbo), or moved to 'upstream' status. Take a look at this wiki page: https://ghc.haskell.org/trac/ghc/query?status=patch&differential=&or&status… These are all the patches and upstream tickets, specifically those which do NOT have ongoing Phabricator code reviews for them. I chose this so we don't see tickets that may already be going under review elsewhere. Notably I'm testing the fusion tickets before merging them. OK, I think that's it. Do let me know if you have any questions (or would like to help with D13 :) [1] https://phabricator.haskell.org/D13#26 [2] https://ghc.haskell.org/trac/ghc/wiki/Phabricator [3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [4] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Unifying inferred and declared *existential* type variables
by Dr. ERDI Gergo 20 Aug '14

20 Aug '14

Hi, Background: Type signatures for pattern synonyms are / can be explicit about the existentially-bound type variables of the pattern. For example, given the following definitions: data T where C :: (Eq a) => [a] -> (a, Bool) -> T pattern P x y = C x y the inferred type of P (with explicit foralls printed) is pattern type forall a. Eq a => P [a] (a, Bool) :: T My problem: Ticket #8968 is a good example of a situation where we need this pattern type signature to be entered by the user. So continuing with the previous example, the user should be able to write, e.g. pattern type forall b. Eq b => P [b] (b, Bool) : T So in this case, I have to unify the argument types [b] ~ [a] and (b, Bool) ~ (a, Bool), and then use the resulting coercions of the existentially-bound variables before calling the success continuation. So I generate a pattern synonym matcher as such (going with the previous example) (I've pushed my code to wip/T8584): $mP{v r0} :: forall t [sk]. T -> (forall b [sk]. Eq b [sk] => [b [sk]] -> (b [sk], Bool) -> t [sk]) -> t [sk] -> t [sk] $mP{v r0} = /\(@ t [sk]). \ ((scrut [lid] :: T)) ((cont [lid] :: forall b [sk]. Eq b [sk] => [b [sk]] -> (b [sk], Bool) -> t [sk])) ((fail [lid] :: t [sk])) -> case scrut of { C {@ a [ssk] ($dEq_aCt [lid] :: Eq a [ssk]) EvBindsVar<aCu>} (x [lid] :: [a [ssk]]) (y [lid] :: (a [ssk], Bool)) -> cont b $dEq_aCr x y |> (cobox{v} [lid], <Bool>_N)_N |> [cobox{v} [lid]]_N } <>} The two 'cobox'es are the results of unifyType'ing [a] with [b] and (a, Bool) with (b, Bool). So basically what I hoped to do was to pattern-match on 'C{@ a $dEqA} x y' and pass that to cont as 'b' and '$dEqB' by rewriting them with the coercions. (It's unfortunate that even with full -dppr-debug output, I can't see what's inside the 'cobox'es). However, when I try doing this, I end up with the error message SigGADT2.hs:10:9: Couldn't match type ‘a [ssk]’ with ‘b [sk]’ because type variable ‘b [sk]’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for P :: [b [sk]] -> (b [sk], Bool) -> T at SigGADT2.hs:10:9 Expected type: [b [sk]] Actual type: [a [ssk]] Also, while the result of unifying '[b]' ~ '[a]' and '(b, Bool)' ~ '(a, Bool)' should take care of turning the 'a' bound by the constructor into the 'b' expected by the continuation function, it seems to me I'll need to do some extra magic to also turn the bound 'Eq a' evidence variable into the 'Eq b'. Obviously, I am missing a ton of stuff here. Can someone help me out? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' I love vegetarians - some of my favorite foods are vegetarians.

2 1