August 2014 - ghc-devs

Haddock build fails
by Simon Peyton Jones 28 Aug '14

28 Aug '14

Phab that I may have committed something that makes haddock fail to build (will teach me, again, to do a completely clean validate!) I'll look into this . Sorry Simon

1 1

nofib external dependencies
by Alexander Pakhomov 25 Aug '14

25 Aug '14

Hi all! I've noticed nofib depends on external packages, such as vector. So when vector is updated we have a benchmark result change even without compiler changes. I guess we need to use fixed version. When some package has major updates we do have to pick we should rename benchmark because it's not the same benchmark.

2 1

RE: Wired-in data-constructors with UNPACKed fields
by Simon Peyton Jones 25 Aug '14

25 Aug '14

I see three alternatives. 1. Flatten out the BigNat thing. You give good reasons why this would be bad. 2. Take care to build a DCR that really does match the one you get when you compile the source module that declares the data type. In principle, the representation does indeed depend on dynflags, so you need to know the flags with which the source module will be compiled. And that's reasonable: if we generate code for an unpacked constructor, GHC's wired-in knowledge must reflect that, and vice versa. But you can probably write the code in such a way as to be mostly independent (eg explicit UNPACK rather than rely on -funbox-strict-fields), or assume that some things won't happen (e.g. souce module will not be compiled with -fomit-interface-pragmas). See MkId.mkDataConRep. 3. Stop having Integer as a wired-in type. For the most part it doesn't need to be; you won't see any mentions of 'integerTy' or 'integerTyCon' scattered about the compiler. I believe that that the sole use is in CorePrep.cvtLitInteger, which wants to use the data constructor for small integers. What is odd here is that for non-small integers we are careful to look up mkInteger in the environment (precisely so that it is not wired in). Then we stash it in the CorePrepEnv, and pass it to cvtLitInteger. What I don't understand is why we don't do exactly the same thing for S#, the data constructor for small integers. (Add a new field to CorePrepEnv for the S# data constructor.) If we did that, then the Integer type and the data constructor, would become "known-key" things, rather than "wired-in" things; and the former are MUCH easier to handle. My recommendation would be to try (3) first. Ian Lynagh (cc'd) may be able to comment about why the inconsistency above arose in the first place, and why we can't simply fix it. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 August 2014 08:56 | To: Simon Peyton Jones | Subject: Re: Wired-in data-constructors with UNPACKed fields | | Hello Simon, | | On 2014-08-17 at 23:56:32 +0200, Simon Peyton Jones wrote: | > You'll see that 'pcDataCon' in TysWiredIn ultimately calls | > pcDataConWithFixity'. And that builds a data constructor with a | > NoDataConRep field, comment "Wired-in types are too simple to need | > wrappers". | > | > But your wired-in type is NOT too simply to need a wrapper! You'll | > need to build a suitable DCR record (see DataCon.lhs), which will be | > something of a nuisance for you, although you can doubtless re-use | > utility functions that are currently used to build a DCR record. | | Wouldn't I need to access to the current dynamic flags in order to be | able to construct the effective DCR record? If so, I'm not sure I can | access the dynflags while constructing a CAF (which I seem to need doing) | | > Alternatively, just put a ByteArray# as the argument of JP# and JN#. | > After all, you have Int# as the argument of SI#! | | Well, there's a big difference between the Int# use and the BigNat use: | | Int and Int# are isomorphic to each other. However, BigNat is a subset | of what can be represented in a ByteArray#. | | Also, BigNat is meant to be available as an abstract data type in its | own right for user to use it as building-block for other data-types | (Like e.g. a more efficient multi-constructor rational type in the style | of 'Integer' or also an optimized 'Either Word BigNat'-isomorphic | 'Natural' type I've got queued up for when integer-gmp2 is done). For | instance, there's a function for creating a BigNat out of a ByteArray# | which makes sure all internal invariants are satisfied. | | | However, should the task to wire-in BigNat turn out to be more pain than | bearable: Since we now have explicitly bidirectional pattern synonyms, I | have been considering to express the user-facing low-level interface to | the 'Integer' type via such pattern synonyms (and hide the "real" | 'data Integer = SI# Int# | Jp# ByteArray# | ..' type deeper, or maybe | not even export it at all). | | From a practical point, I'd like to get to a situation where code | requiring to access the "medium-level" Integer representation (like some | of Edward Kmett's packages, or some of the crypto-packages using | 'Integer's to perform RSA calculations) doesn't need to know it's using | integer-simple, integer-gmp2, or integer-xyz, as they'd all provide the | same abstracted API. | | | [...] | | > | data Integer = SI# Int# | > | | Jp# {-# UNPACK #-} !BigNat | > | | Jn# {-# UNPACK #-} !BigNat | > | | > | data BigNat = BN# ByteArray# | | Cheers, | hvr

3 3

Status updates
by Austin Seipp 25 Aug '14

25 Aug '14

Hello *, Here are some notes from what's happened this week: - I've rejiggered some of the wiki pages a bit more, including updating the BugTracker page[1], Phabricator/Harbormaster docs[2], -- The bugtracker page mostly saw some minor updates in relation to the updates from *last* week; notably the new 'upstream' status. -- I split the Phabricator page up a bit to be easier to read, so Harbormaster is its own page now (but see more below). - I spent a day or two working on a Windows buildbot for Phabricator. Good news: I think I have a reliable set of steps to get a windows SSH instance running. However, I have not yet gotten it to build GHC through msys2, so it's not working yet. - I spent time on Friday getting a fix for #7602 ready for real this time. I'll put a review on Phabricator soon (my other machine doesn't have `arc` credentials.) Hopefully OS X users can soon rejoice with a solid performance boost. - I fiddled with Applicative-Monad a tiny bit, but haven't made much progress still. Like last time, it would be really amazing if anyone would like to help me out and try the patch yourself (feel free to email/IRC, or see last weeks' email for more). Other things: - Thomas Miedema helped out Herbert by writing a Trac anti-spam plugin for us - Thank you so much Thomas!! Hopefully the spam will go away soon. I am not yet sure if Thomas's new plugin is installed yet - Herbert? Upcoming: - #7602 will go up for review. - I will land D165 today probably since it's ready and other refactorings can come later. D166 (faster copies) is not yet ready. - I haven't done this yet, but I'm going to try to turn on `--slow` ./validate mode in the next day or two for Phabricator. At first, I'm only going to configure this for *commits* first, and perhaps patches will follow once we have more build machines. That means Phabricator is going to start annoying you with consistent failures (I think `--slow` has a few right now), but putting on pressure is the best way to fix it, I think. I'll send another email about this shortly. - I will probably rejigger the Phabricator page again to be smaller. I've had some complaints it's getting a bit large (due to the images, mostly), so I'll probably move the hierarchy around a bit. - Sit down and do some thorough code review. We have about 3 major features sitting on Phabricator at the moment which are going to need extensive review before landing. I expect this will take a while. See: -- D169, source code notes: https://phabricator.haskell.org/D169 -- D168: Partial type sigs: https://phabricator.haskell.org/D168 -- D119: StaticValues extension: https://phabricator.haskell.org/D119 Please please please - feel free to review these patches! Even if they are not your area of expertise, doing so will A) help you learn more hopefully! and B) you can surely help still (pointing out typos, needed docs, lint violations, suggestions) etc. That would be really useful to help increase the 'shared ownership' we all have, I think. [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker [2] https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Harbormaster -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

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