From juhp at community.haskell.org Sun Jun 1 12:39:59 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Sun, 1 Jun 2014 21:39:59 +0900 Subject: GHC 7.8.3 release In-Reply-To: References: Message-ID: (Sorry late response...) On 27 May 2014 17:06, Austin Seipp wrote: > just a general vote in favor of doing it within some X timeframe (even > 'real soon' or 'a week would be great') would be nice. > +1 for 7.8.3 RSN :) I am planning to import ghc-7.8 into Fedora 21 soon so having 7.8.3 available now would be much better. Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From edskodevries at gmail.com Sun Jun 1 17:03:51 2014 From: edskodevries at gmail.com (Edsko de Vries) Date: Sun, 1 Jun 2014 18:03:51 +0100 Subject: 32-bit OSX Message-ID: Hi guys, I have been trying to compile a 32-bit version ghc, versions 7.8 as well as HEAD, in a myriad of ways, bootstrapping with the 32-bit binary of 7.4 (which is the latest 32-bit binary available from haskell.org), but no matter which way I try, it always fails somewhere. I was trying this mostly just because I wanted to inspect the output of the code generator, but 32-bit OSX is listed as a tier 1 platform on https://ghc.haskell.org/trac/ghc/wiki/Platforms, so I expected this to be simple. Compiling normally (build flavour quick) eventually fails with a bus error, which somebody else seems to have got too -- although I have no idea who or what there were trying to do; I just found http://lpaste.net/99008 When I try to build with the quick-cross flavour, but using -fasm rather than -fllvm, for some reason building fails when it tries to call ghc-stage2; the quick-cross flavour sets Stage1Only = YES so this seems a bug to me. When using -fllvm it fails even sooner. I don't know if I'm doing this wrong, if I should file a bug, or whether we should record 32-bit OSX as unsupported. Edsko -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Jun 1 18:01:05 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 1 Jun 2014 14:01:05 -0400 Subject: GHC 7.8.3 release In-Reply-To: References: Message-ID: +1 on the RSN the Mvar and MkStableName bugs alone are pretty nasty for those who need those tools. On Sun, Jun 1, 2014 at 8:39 AM, Jens Petersen wrote: > (Sorry late response...) > > On 27 May 2014 17:06, Austin Seipp wrote: > >> just a general vote in favor of doing it within some X timeframe (even >> 'real soon' or 'a week would be great') would be nice. >> > > +1 for 7.8.3 RSN :) > > I am planning to import ghc-7.8 into Fedora 21 soon so having 7.8.3 > available now would be much better. > > Thanks, Jens > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sun Jun 1 20:10:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 1 Jun 2014 20:10:35 +0000 Subject: Expose Other Parsers for GHC API In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103C8542@DB3PRD3001MB020.064d.mgd.msft.net> It sounds ok to me, especially if you take the time to Haddock-document them. It?d also be great to improve the user-generated documentation about the GHC API http://www.haskell.org/haskellwiki/GHC/As_a_library perhaps you can add a section about the stuff that you add. thanks Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Andrew Gibiansky Sent: 31 May 2014 04:09 To: ghc-devs at haskell.org Subject: Expose Other Parsers for GHC API Hello, I would like to be able to use the GHC API for parsing. Right now this is in the Parser and Lexer modules: Parser: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html Lexer: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html GHC currently exposes only a few parsers here. I'd like to make a few modifications: 1. Expose a few more parsers than currently are exposed in the Parser module. In particular, I'd like import statements, type signatures, declarations, and expressions, at least, in addition to what's already there. 2. Re-export some things from Lexer from Parser, since they're reused. This would include unP, PState, and the 2-3 other core things you have to use in order to use the GHC Parser. 3. Add some Haddock documentation to the top of the Parser module describing how to use it, since the types themselves are pretty opaque here. I think (1) and (3) are definitely a good idea, not so sure about (2) though IMHO it would be convenient for using the Parser. Would this make for an acceptable patch? Thoughts? -- Andrew Gibiansky -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Jun 2 15:19:21 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 2 Jun 2014 18:19:21 +0300 Subject: suspicious piece of code in RTS(Profiling.c) code Message-ID: Hi all, I recently found a suspicious piece of code in RTS code. * https://github.com/ghc/ghc/blob/master/rts/Profiling.c#L622 here it's checking that ccs is not EMPTY_STACK. * https://github.com/ghc/ghc/blob/master/includes/rts/prof/CCS.h#L96 here EMPTY_STACK is defined as NULL. Now weird part is that before the if-statement checks for `ccs != NULL` ccs is used to reach some of it's fields(for example, line 601 and 602). As far as I can see either we have a bug here or the if-statement is not necessary and we can move it's body to top level. Am I missing anything here? Thanks. --- ?mer Sinan A?acan http://osa1.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Jun 2 18:09:09 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 02 Jun 2014 11:09:09 -0700 Subject: suspicious piece of code in RTS(Profiling.c) code In-Reply-To: References: Message-ID: <1401732376-sup-6064@sabre> Hello ?mer, That does seem pretty suspicious. My interpretation is that ccs should just never be EMPTY_STACK. If we look at the calling codepaths, the only case that a NULL could be passed is if pushCostCentre is called with NULL ccs, but we only create these invocations in code generation and never pass a NULL in such situations. What I am not sure is if there is some special treatment for empty stacks that should be happening, but is not, at the moment. Edward Excerpts from ?mer Sinan A?acan's message of 2014-06-02 08:19:21 -0700: > Hi all, > > I recently found a suspicious piece of code in RTS code. > > * https://github.com/ghc/ghc/blob/master/rts/Profiling.c#L622 here it's > checking that ccs is not EMPTY_STACK. > * https://github.com/ghc/ghc/blob/master/includes/rts/prof/CCS.h#L96 here > EMPTY_STACK is defined as NULL. > > Now weird part is that before the if-statement checks for `ccs != NULL` ccs > is used to reach some of it's fields(for example, line 601 and 602). As far > as I can see either we have a bug here or the if-statement is not necessary > and we can move it's body to top level. > > Am I missing anything here? > > Thanks. > > --- > ?mer Sinan A?acan > http://osa1.net From timothy.schmid at gmail.com Tue Jun 3 06:06:00 2014 From: timothy.schmid at gmail.com (transfuturist) Date: Mon, 2 Jun 2014 23:06:00 -0700 Subject: [PATCH] Fix T5435_dyn_asm on mingw and T8832 on 32-bit architecture Message-ID: <1401775560-9908-1-git-send-email-timothy.schmid@gmail.com> --- testsuite/tests/rts/all.T | 3 +++ testsuite/tests/simplCore/should_compile/all.T | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/testsuite/tests/rts/all.T b/testsuite/tests/rts/all.T index a56a3f3..c52cea0 100644 --- a/testsuite/tests/rts/all.T +++ b/testsuite/tests/rts/all.T @@ -141,6 +141,9 @@ def checkDynAsm(actual_file, normaliser): elif actual == ['ctors1', 'ctors2', 'initArray1', 'initArray2', 'success']: if_verbose(1, 'T5435_dyn_asm detected old-style dlopen, see #8458') return 1 + elif opsys('mingw32'): + if actual == ['ctors1', 'ctors2', 'success']: + return 1 else: if_verbose(1, 'T5435_dyn_asm failed with %s, see all.T for details' % actual) return 0 diff --git a/testsuite/tests/simplCore/should_compile/all.T b/testsuite/tests/simplCore/should_compile/all.T index 616b6cc..ffc7131 100644 --- a/testsuite/tests/simplCore/should_compile/all.T +++ b/testsuite/tests/simplCore/should_compile/all.T @@ -198,7 +198,8 @@ test('T5996', ['$MAKE -s --no-print-directory T5996']) test('T8537', normal, compile, ['']) test('T8832', - extra_clean(['T8832.hi', 'T8832a.o']), + [extra_clean(['T8832.hi', 'T8832a.o']), + when(wordsize(32),expect_broken(8832))], run_command, ['$MAKE -s --no-print-directory T8832']) test('T8848', only_ways(['optasm']), compile, ['-ddump-rule-firings']) -- 1.8.4.msysgit.0 From timothy.schmid at gmail.com Tue Jun 3 06:06:19 2014 From: timothy.schmid at gmail.com (transfuturist) Date: Mon, 2 Jun 2014 23:06:19 -0700 Subject: [PATCH] Fix -unawareness of large-addresses on mingw (#8520) Message-ID: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> --- compiler/main/SysTools.lhs | 1 + 1 file changed, 1 insertion(+) diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index dc9642d..1cf1155 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do [ -- Reduce ld memory usage "-Wl,--hash-size=31" , "-Wl,--reduce-memory-overheads" + , "-Wl,--large-address-aware" --Trac #8520 -- Increase default stack, see -- Note [Windows stack usage] , "-Xlinker", "--stack=0x800000,0x800000" ] -- 1.8.4.msysgit.0 From simonpj at microsoft.com Tue Jun 3 11:13:19 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Jun 2014 11:13:19 +0000 Subject: Ptr type Message-ID: <618BE556AADD624C9C918AA5D5911BEF103CF173@DB3PRD3001MB020.064d.mgd.msft.net> Richard In GHC.Ptr we see type role Ptr representational data Ptr a = Ptr Addr# deriving (Eq, Ord) with no comments. Why is Ptr representational? In the same module we have castPtr, which unpacks and repacks a Ptr. If Ptr was phantom, we could use coerce. And that in turn would actually make a lot of code more efficient - there are lots of calls to castPtr. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Jun 3 12:24:30 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 3 Jun 2014 08:24:30 -0400 Subject: Ptr type In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103CF173@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103CF173@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <12B94500-F808-4026-BBBE-AB5D4BE9D77A@cis.upenn.edu> It seemed clear to me that Ptr *should* be representational, thinking that we don't want to coerce a `Ptr Int` to a `Ptr Bool`. I don't see any reason why this couldn't be changed. Why is Ptr a `data` not a `newtype`? If it were a newtype, we could keep the role annotation and use `coerce` internally, according to the updated Coercible solver. However, it is crucial that FunPtr have a representational argument, as normaliseFfiType' depends on this fact. There is a brief comment in TcForeign, but clearly more comments are necessary. Will do shortly. If we want to change FunPtr's role, normaliseFfiType' would have to be updated, too, but it shouldn't be hard. More comments in the code later today. Richard On Jun 3, 2014, at 7:13 AM, Simon Peyton Jones wrote: > Richard > > In GHC.Ptr we see > > type role Ptr representational > data Ptr a = Ptr Addr# deriving (Eq, Ord) > with no comments. Why is Ptr representational? > > In the same module we have castPtr, which unpacks and repacks a Ptr. If Ptr was phantom, we could use coerce. And that in turn would actually make a lot of code more efficient ? there are lots of calls to castPtr. > > Simon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jun 3 12:30:26 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 03 Jun 2014 13:30:26 +0100 Subject: Proposal: run GHC API tests on fast In-Reply-To: <1401411058-sup-8260@sabre> References: <1401411058-sup-8260@sabre> Message-ID: <538DBFE2.4080907@gmail.com> Fine by me. In practice tests that aren't part of fast tend to bitrot, so until we have better infrastructure to tell us about failing non-fast tests, it's better to move more of them into fast. On 30/05/2014 01:55, Edward Z. Yang wrote: > Currently, most GHC API tests are not run on 'make fast', > ostensibly because linking against the GHC API can take a while. > I propose that change this, and run GHC API tests by default. > Reasons: > > 1. The GHC API is closely tied a lot of internal structure of GHC, so > it's very easy to make a change, track it through the rest of the > compiler, but forget to update the tests/documentation. > > 2. We can boost this into poor man's testable documentation. The idea > is to duplicate all GHC API examples in the manual in the test suite, > and have a comment on all of the examples asking the developer to update > the manual. (Or we could automatically extract the snippets from the > manual, but that's work and this I could do in a few minutes.) > > 3. I don't think running these tests will add that much extra run > time to the test suite; certainly interactively the time spent linking > is unnoticeable. > > Let's set a one week discussion period for this proposal. > > Thanks, > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Tue Jun 3 12:33:37 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 03 Jun 2014 13:33:37 +0100 Subject: suspicious piece of code in RTS(Profiling.c) code In-Reply-To: <1401732376-sup-6064@sabre> References: <1401732376-sup-6064@sabre> Message-ID: <538DC0A1.9040601@gmail.com> We could probably remove that check. Cheers, Simon On 02/06/2014 19:09, Edward Z. Yang wrote: > Hello ?mer, > > That does seem pretty suspicious. My interpretation is that > ccs should just never be EMPTY_STACK. If we look at the calling > codepaths, the only case that a NULL could be passed is if > pushCostCentre is called with NULL ccs, but we only create these > invocations in code generation and never pass a NULL in such situations. > > What I am not sure is if there is some special treatment for empty > stacks that should be happening, but is not, at the moment. > > Edward > > Excerpts from ?mer Sinan A?acan's message of 2014-06-02 08:19:21 -0700: >> Hi all, >> >> I recently found a suspicious piece of code in RTS code. >> >> * https://github.com/ghc/ghc/blob/master/rts/Profiling.c#L622 here it's >> checking that ccs is not EMPTY_STACK. >> * https://github.com/ghc/ghc/blob/master/includes/rts/prof/CCS.h#L96 here >> EMPTY_STACK is defined as NULL. >> >> Now weird part is that before the if-statement checks for `ccs != NULL` ccs >> is used to reach some of it's fields(for example, line 601 and 602). As far >> as I can see either we have a bug here or the if-statement is not necessary >> and we can move it's body to top level. >> >> Am I missing anything here? >> >> Thanks. >> >> --- >> ?mer Sinan A?acan >> http://osa1.net > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From austin at well-typed.com Tue Jun 3 13:22:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Jun 2014 08:22:20 -0500 Subject: Ptr type In-Reply-To: <12B94500-F808-4026-BBBE-AB5D4BE9D77A@cis.upenn.edu> References: <618BE556AADD624C9C918AA5D5911BEF103CF173@DB3PRD3001MB020.064d.mgd.msft.net> <12B94500-F808-4026-BBBE-AB5D4BE9D77A@cis.upenn.edu> Message-ID: I think Ptr should almost certainly be representational, as it is a case where the actual underlying value is the same, but what it points to is not (I'll ignore castPtr here for a second). This makes me think of something I talked about before with Andres - in general, phantom roles seem somewhat dangerous, and I kind of wonder if they should be inferred by default. Often you see some code along the lines of: ---------------------------------- module A ( Bar, newBarInt ) where data Bar a = Bar Int newBarInt :: Int -> Bar Int --------------------------------- where A is exported to the client and the module boundary enforces some restrictions on 'Bar', like what types we can instantiate 'Bar a' to (the example is dumb but bear with me). In the above example, I believe the `a` in `Bar a` would be inferred at phantom role. The question I have is: what legitimate case would there be for phantom roles like this? Such usage of phantom type parameters seems very common, but in almost *all* cases I can't think of a reason why I would ever want a user to be allowed to `coerce` away the type information, if the `a` parameter was phantom. It seems like in the above example, I would almost certainly want `a` to be representational instead. What other cases exist for legitimate phantom roles such as this where we want this inference? I wonder if instead we should require an explicit role annotation for phantoms in this case - not the other way around. Ptr is a similar story - by default it would maybe seem reasonable to be phantom, but that seems like an especially grievous error, given we don't want people to `poke` incorrect values in or something (again, ignoring castPtr for a second, but I think the general idea holds.) On Tue, Jun 3, 2014 at 7:24 AM, Richard Eisenberg wrote: > It seemed clear to me that Ptr *should* be representational, thinking that > we don't want to coerce a `Ptr Int` to a `Ptr Bool`. I don't see any reason > why this couldn't be changed. > > Why is Ptr a `data` not a `newtype`? If it were a newtype, we could keep the > role annotation and use `coerce` internally, according to the updated > Coercible solver. > > However, it is crucial that FunPtr have a representational argument, as > normaliseFfiType' depends on this fact. There is a brief comment in > TcForeign, but clearly more comments are necessary. Will do shortly. If we > want to change FunPtr's role, normaliseFfiType' would have to be updated, > too, but it shouldn't be hard. > > More comments in the code later today. > > Richard > > On Jun 3, 2014, at 7:13 AM, Simon Peyton Jones > wrote: > > Richard > > In GHC.Ptr we see > > type role Ptr representational > data Ptr a = Ptr Addr# deriving (Eq, Ord) > > with no comments. Why is Ptr representational? > > In the same module we have castPtr, which unpacks and repacks a Ptr. If Ptr > was phantom, we could use coerce. And that in turn would actually make a > lot of code more efficient ? there are lots of calls to castPtr. > > Simon > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Jun 3 13:40:27 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Jun 2014 13:40:27 +0000 Subject: Ptr type In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103CF173@DB3PRD3001MB020.064d.mgd.msft.net> <12B94500-F808-4026-BBBE-AB5D4BE9D77A@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D2CEA@DB3PRD3001MB020.064d.mgd.msft.net> I've moved this thread to https://ghc.haskell.org/trac/ghc/ticket/9163 | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 03 June 2014 14:22 | To: Richard Eisenberg | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: Ptr type | | I think Ptr should almost certainly be representational, as it is a case | where the actual underlying value is the same, but what it points to is | not (I'll ignore castPtr here for a second). | | This makes me think of something I talked about before with Andres - in | general, phantom roles seem somewhat dangerous, and I kind of wonder if | they should be inferred by default. Often you see some code along the | lines of: | | ---------------------------------- | | module A ( Bar, newBarInt ) where | | data Bar a = Bar Int | | newBarInt :: Int -> Bar Int | | --------------------------------- | | where A is exported to the client and the module boundary enforces some | restrictions on 'Bar', like what types we can instantiate 'Bar a' | to (the example is dumb but bear with me). | | In the above example, I believe the `a` in `Bar a` would be inferred at | phantom role. | | The question I have is: what legitimate case would there be for phantom | roles like this? Such usage of phantom type parameters seems very | common, but in almost *all* cases I can't think of a reason why I would | ever want a user to be allowed to `coerce` away the type information, if | the `a` parameter was phantom. It seems like in the above example, I | would almost certainly want `a` to be representational instead. | | What other cases exist for legitimate phantom roles such as this where | we want this inference? I wonder if instead we should require an | explicit role annotation for phantoms in this case - not the other way | around. | | Ptr is a similar story - by default it would maybe seem reasonable to be | phantom, but that seems like an especially grievous error, given we | don't want people to `poke` incorrect values in or something (again, | ignoring castPtr for a second, but I think the general idea holds.) | | | On Tue, Jun 3, 2014 at 7:24 AM, Richard Eisenberg | wrote: | > It seemed clear to me that Ptr *should* be representational, thinking | > that we don't want to coerce a `Ptr Int` to a `Ptr Bool`. I don't see | > any reason why this couldn't be changed. | > | > Why is Ptr a `data` not a `newtype`? If it were a newtype, we could | > keep the role annotation and use `coerce` internally, according to the | > updated Coercible solver. | > | > However, it is crucial that FunPtr have a representational argument, | > as normaliseFfiType' depends on this fact. There is a brief comment in | > TcForeign, but clearly more comments are necessary. Will do shortly. | > If we want to change FunPtr's role, normaliseFfiType' would have to be | > updated, too, but it shouldn't be hard. | > | > More comments in the code later today. | > | > Richard | > | > On Jun 3, 2014, at 7:13 AM, Simon Peyton Jones | > wrote: | > | > Richard | > | > In GHC.Ptr we see | > | > type role Ptr representational | > data Ptr a = Ptr Addr# deriving (Eq, Ord) | > | > with no comments. Why is Ptr representational? | > | > In the same module we have castPtr, which unpacks and repacks a Ptr. | > If Ptr was phantom, we could use coerce. And that in turn would | > actually make a lot of code more efficient ? there are lots of calls | to castPtr. | > | > Simon | > | > | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Tue Jun 3 14:55:15 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 03 Jun 2014 16:55:15 +0200 Subject: Validate failures In-Reply-To: <1400439260.2221.40.camel@kirk> References: <1399147687.19761.1.camel@kirk> <1400439260.2221.40.camel@kirk> Message-ID: <1401807315.4730.22.camel@kirk> Dear Release branch managers, may I remind you of this small merge request? It would help cut down noise from Travis, and help me catch real errors more easily: Am Sonntag, den 18.05.2014, 20:54 +0200 schrieb Joachim Breitner: > a small reminder to the masteres of the stable branch: The ghc-7.8 > branch currently still does not validate on Travis: > > Am Samstag, den 03.05.2014, 22:08 +0200 schrieb Joachim Breitner: > > ghc-7.8: > > > > Unexpected failures: > > annotations/should_compile/th annth_compunits [bad exit code] (normal) > > annotations/should_compile/th annth_make [bad stdout] (normal) > > > > Please merge 0fe726829d468badf830dd82bc296832d709733b into ghc-7.8 (this > > annotates the tests to require have_dynamic()) Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Tue Jun 3 15:00:36 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Jun 2014 10:00:36 -0500 Subject: Validate failures In-Reply-To: <1401807315.4730.22.camel@kirk> References: <1399147687.19761.1.camel@kirk> <1400439260.2221.40.camel@kirk> <1401807315.4730.22.camel@kirk> Message-ID: Sorry about that, fixed and pushed in aede2d6bbc168724409267c3e08887f7289d22be! On Tue, Jun 3, 2014 at 9:55 AM, Joachim Breitner wrote: > Dear Release branch managers, > > may I remind you of this small merge request? It would help cut down > noise from Travis, and help me catch real errors more easily: > > Am Sonntag, den 18.05.2014, 20:54 +0200 schrieb Joachim Breitner: >> a small reminder to the masteres of the stable branch: The ghc-7.8 >> branch currently still does not validate on Travis: >> >> Am Samstag, den 03.05.2014, 22:08 +0200 schrieb Joachim Breitner: >> > ghc-7.8: >> > >> > Unexpected failures: >> > annotations/should_compile/th annth_compunits [bad exit code] (normal) >> > annotations/should_compile/th annth_make [bad stdout] (normal) >> > >> > Please merge 0fe726829d468badf830dd82bc296832d709733b into ghc-7.8 (this >> > annotates the tests to require have_dynamic()) > > Thanks, > Joachim > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From marlowsd at gmail.com Wed Jun 4 07:20:54 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 04 Jun 2014 08:20:54 +0100 Subject: [PATCH] Fix T5435_dyn_asm on mingw and T8832 on 32-bit architecture In-Reply-To: <1401775560-9908-1-git-send-email-timothy.schmid@gmail.com> References: <1401775560-9908-1-git-send-email-timothy.schmid@gmail.com> Message-ID: <538EC8D6.8070609@gmail.com> Rather than marking T8832 as broken, we should just have the 32-bit output. I believe you can put it in the file T8832.stdout-ws-32. On 03/06/2014 07:06, transfuturist wrote: > --- > testsuite/tests/rts/all.T | 3 +++ > testsuite/tests/simplCore/should_compile/all.T | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/testsuite/tests/rts/all.T b/testsuite/tests/rts/all.T > index a56a3f3..c52cea0 100644 > --- a/testsuite/tests/rts/all.T > +++ b/testsuite/tests/rts/all.T > @@ -141,6 +141,9 @@ def checkDynAsm(actual_file, normaliser): > elif actual == ['ctors1', 'ctors2', 'initArray1', 'initArray2', 'success']: > if_verbose(1, 'T5435_dyn_asm detected old-style dlopen, see #8458') > return 1 > + elif opsys('mingw32'): > + if actual == ['ctors1', 'ctors2', 'success']: > + return 1 > else: > if_verbose(1, 'T5435_dyn_asm failed with %s, see all.T for details' % actual) > return 0 > diff --git a/testsuite/tests/simplCore/should_compile/all.T b/testsuite/tests/simplCore/should_compile/all.T > index 616b6cc..ffc7131 100644 > --- a/testsuite/tests/simplCore/should_compile/all.T > +++ b/testsuite/tests/simplCore/should_compile/all.T > @@ -198,7 +198,8 @@ test('T5996', > ['$MAKE -s --no-print-directory T5996']) > test('T8537', normal, compile, ['']) > test('T8832', > - extra_clean(['T8832.hi', 'T8832a.o']), > + [extra_clean(['T8832.hi', 'T8832a.o']), > + when(wordsize(32),expect_broken(8832))], > run_command, > ['$MAKE -s --no-print-directory T8832']) > test('T8848', only_ways(['optasm']), compile, ['-ddump-rule-firings']) > From marlowsd at gmail.com Wed Jun 4 07:23:48 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 04 Jun 2014 08:23:48 +0100 Subject: [PATCH] Fix -unawareness of large-addresses on mingw (#8520) In-Reply-To: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> References: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> Message-ID: <538EC984.2010706@gmail.com> I don't know what this does, and there doesn't seem to be any info in #8520 either. Could you add the patch to the ticket, and help us out by saying why this fixes the problem (and if possible, explain why it won't break anything else)? On 03/06/2014 07:06, transfuturist wrote: > --- > compiler/main/SysTools.lhs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs > index dc9642d..1cf1155 100644 > --- a/compiler/main/SysTools.lhs > +++ b/compiler/main/SysTools.lhs > @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do > [ -- Reduce ld memory usage > "-Wl,--hash-size=31" > , "-Wl,--reduce-memory-overheads" > + , "-Wl,--large-address-aware" --Trac #8520 > -- Increase default stack, see > -- Note [Windows stack usage] > , "-Xlinker", "--stack=0x800000,0x800000" ] > From marlowsd at gmail.com Wed Jun 4 07:33:25 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 04 Jun 2014 08:33:25 +0100 Subject: Expose Other Parsers for GHC API In-Reply-To: References: Message-ID: <538ECBC5.6050107@gmail.com> I'd say (1) and (3) are good, but we typically don't do (2) in the compiler. On the other hand, if you want to export a clean and self-contained API for the parser from the GHC module, I think that would be great. There is GHC.parser for parsing a whole module, but I'm sure a more complete API would be useful. Cheers, Simon On 31/05/2014 04:09, Andrew Gibiansky wrote: > Hello, > > I would like to be able to use the GHC API for parsing. Right now this > is in the Parser and Lexer modules: > > Parser: > http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html > Lexer: > http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html > > GHC currently exposes only a few parsers here. I'd like to make a few > modifications: > > 1. Expose a few more parsers than currently are exposed in the Parser > module. In particular, I'd like import statements, type signatures, > declarations, and expressions, at least, in addition to what's already > there. > > 2. Re-export some things from Lexer from Parser, since they're reused. > This would include unP, PState, and the 2-3 other core things you > /have/ to use in order to use the GHC Parser. > > 3. Add some Haddock documentation to the top of the Parser module > describing how to use it, since the types themselves are pretty opaque here. > > I think (1) and (3) are definitely a good idea, not so sure about (2) > though IMHO it would be convenient for using the Parser. > > Would this make for an acceptable patch? Thoughts? > > -- Andrew Gibiansky > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From kyrab at mail.ru Wed Jun 4 08:15:36 2014 From: kyrab at mail.ru (kyra) Date: Wed, 04 Jun 2014 12:15:36 +0400 Subject: [PATCH] Fix -unawareness of large-addresses on mingw (#8520) In-Reply-To: <538EC984.2010706@gmail.com> References: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> <538EC984.2010706@gmail.com> Message-ID: <538ED5A8.60301@mail.ru> LARGEADDRESSAWARE flag if set in executable's header tells the OS that the application can handle addresses larger than 2GB. For 32-bit executables it is disabled usually. To enable it we must tell linker to enable it or manually edit an executable - for example, peflags of editbin (from Microsoft) utilities could be used. Cheers, Kyra On 6/4/2014 11:23, Simon Marlow wrote: > I don't know what this does, and there doesn't seem to be any info in > #8520 either. > > Could you add the patch to the ticket, and help us out by saying why > this fixes the problem (and if possible, explain why it won't break > anything else)? > > On 03/06/2014 07:06, transfuturist wrote: >> --- >> compiler/main/SysTools.lhs | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs >> index dc9642d..1cf1155 100644 >> --- a/compiler/main/SysTools.lhs >> +++ b/compiler/main/SysTools.lhs >> @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do >> [ -- Reduce ld memory usage >> "-Wl,--hash-size=31" >> , "-Wl,--reduce-memory-overheads" >> + , "-Wl,--large-address-aware" --Trac #8520 >> -- Increase default stack, see >> -- Note [Windows stack usage] >> , "-Xlinker", "--stack=0x800000,0x800000" ] >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From ghc-dev at maartenfaddegon.nl Thu Jun 5 06:46:29 2014 From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon) Date: Thu, 05 Jun 2014 07:46:29 +0100 Subject: (drop)CommonPrefix: ccs call implementation Message-ID: <53901245.9060603@maartenfaddegon.nl> Dear list, I am reading up on cost centre stacks. Simon Marlow's "solving an old problem"-slides is the more recent resource I could find. On slide 43 he describes a call function implemented as: > call Sapp Slam = foldr push Spre Slam? > where (Spre, Sapp?, Slam?) = commonPrefix Sapp Slam However in rts/profiling.c the following is written: > Set CCCS when entering a function. > > The algorithm is as follows. > > ccs ++> ccsfn = ccs ++ dropCommonPrefix ccs ccsfn > > where > > dropCommonPrefix A B > -- returns the suffix of B after removing any prefix common > -- to both A and B. > > e.g. > > ++> <> = > ++> = > ++> = > ++> = > ++> = For the given examples Simon's proposal would result in different stacks: <>, , , and . Has the implementation changed since Simon Marlow gave his talk? If so, is there something I can read on the motivation behind this change? Or do I maybe misinterpret the slides? Thank you, Maarten Faddegon From omeragacan at gmail.com Thu Jun 5 08:57:33 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 5 Jun 2014 11:57:33 +0300 Subject: (drop)CommonPrefix: ccs call implementation In-Reply-To: <53901245.9060603@maartenfaddegon.nl> References: <53901245.9060603@maartenfaddegon.nl> Message-ID: Hi Maarten, Where did you find that slides? I have slides for same talk(also attached) but mine has a different definition for call: (on page 39) call sapp slam = sapp ++ slam' where (spre, sapp', slam') = commonPrefix sapp slam This one works same with the implementation. --- ?mer Sinan A?acan http://osa1.net -------------- next part -------------- A non-text attachment was scrubbed... Name: Hiw2012-simon-marlow.pdf Type: application/pdf Size: 999600 bytes Desc: not available URL: From austin at well-typed.com Thu Jun 5 13:26:37 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 5 Jun 2014 08:26:37 -0500 Subject: Status updates Message-ID: Hello all, A cumulative status update will now appear, to summarize a few things that have happened in the past little while since I've been somewhat absent and short on time. - 7.8.3 is looming, because we have a lot of bugfixes as I said last week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 That's nearly 30 tickets axed in the past few weeks since 7.8.2, so not bad! As I said before, I'm eager to release sooner rather than later as my time is short. Do keep weighing in if you have anything to say or want something fixed. Now is really the time! - AMP/ORF - these are still on branches, but me and Simon have gotten hung up on a few things delaying it. They'll go in soon, promise! (For certain definitions of 'soon', cooperating with time schedules). AMP in particular can probably land very, very soon. Otherwise we're past a lot of other churn, like removing external core and whatnot. - I merged a bunch of patches this morning to the 7.8 branch, bringing it close to what I expect we will ship 7.8.3 with. Again, pester me soon if you want something! - There's now a proper CI link for GHC on Trac so people don't lose it. The new builders are checking in regularly, so please watch out for them - and subscribe to ghc-builds at haskell.org if you haven't already. - Some other churn in the tree has not yet passed; I still need to improve and land my performance patches for copies, for example. - XCode 5.1 has introduced some other breaking changes I'll need to fix (things *work*, but the testsuite is useless due to the warning spewage), along with merging the remaining patches. - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will have better dedicated Windows targets soon. I'll send another email about 7.8.3 shortly. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Thu Jun 5 13:35:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 5 Jun 2014 13:35:17 +0000 Subject: Status updates In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D7E60@DB3PRD3001MB020.064d.mgd.msft.net> | - 7.8.3 is looming, because we have a lot of bugfixes as I said last | week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 Just to be clear, on that page: closed = done in 7.8.3 branch patch = will go in 7.8.3 branch new/infoneeded = will NOT go in 7.8.3 unless you yell loudly and soon and argue for delay to get it in | - There's now a proper CI link for GHC on Trac so people don't lose it. | The new builders are checking in regularly, so please watch out for them | - and subscribe to ghc-builds at haskell.org if you haven't already. Where exactly is the link? (Ie not "what is the link" but where on Trac is it posted?) Simon From austin at well-typed.com Thu Jun 5 13:36:35 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 5 Jun 2014 08:36:35 -0500 Subject: 7.8.3 release - please speak up soon. Message-ID: Hello all, I'm going to do the 7.8.3 release very soon. Now is the time to speak up if something should go in. Here's the take away from this: I *am not* going to fix any other bugs for 7.8.3 or close any other tickets than the following: - #9155 https://ghc.haskell.org/trac/ghc/ticket/9155 - #7241 https://ghc.haskell.org/trac/ghc/ticket/7241 - #8683 https://ghc.haskell.org/trac/ghc/ticket/8683 - #8935 https://ghc.haskell.org/trac/ghc/ticket/8935 - #9080 https://ghc.haskell.org/trac/ghc/ticket/9080 The first one is a bug fix from Simon for the code generator. The remaining ones are patches I intend to land today. So here's the deal: if you don't speak up now, you'll have to wait until 7.8.4 (sometime in the late summer I imagine) to get your word in. Is there anything anyone absolutely must have that I've missed? Full details on what was fixed are on this page - the 'infoneeded' and 'new' tickets will be punted to a new milestone shortly. All 'closed' tickets are merged and in the 7.8 branch already: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Jun 5 13:39:50 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 5 Jun 2014 08:39:50 -0500 Subject: Status updates In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D7E60@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D7E60@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Drats, I forgot that. Here's where it is: Go to the GHC Trac hompeage: https://ghc.haskell.org/trac/ghc/ and scroll down just a tiny bit. There's a section called 'Nightly builds' with the updated link to the new UI, located on Gabor's server: http://haskell.inf.elte.hu/builders/ Simon, did we talk about adding this to the sidebar? Or maybe we should just highlight it on the front page a little more, and then link to it from somewhere else on the sidebar (like "Building Guide" links to the builder page). On Thu, Jun 5, 2014 at 8:35 AM, Simon Peyton Jones wrote: > | - 7.8.3 is looming, because we have a lot of bugfixes as I said last > | week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 > > Just to be clear, on that page: > closed = done in 7.8.3 branch > patch = will go in 7.8.3 branch > new/infoneeded = will NOT go in 7.8.3 unless you yell loudly and soon > and argue for delay to get it in > > | - There's now a proper CI link for GHC on Trac so people don't lose it. > | The new builders are checking in regularly, so please watch out for them > | - and subscribe to ghc-builds at haskell.org if you haven't already. > > Where exactly is the link? (Ie not "what is the link" but where on Trac is it posted?) > > Simon > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From gergely at risko.hu Thu Jun 5 14:37:36 2014 From: gergely at risko.hu (Gergely Risko) Date: Thu, 05 Jun 2014 16:37:36 +0200 Subject: 7.8.3 release - please speak up soon. References: Message-ID: <871tv3l8wf.fsf@gergely.risko.hu> Hi, > So here's the deal: if you don't speak up now, you'll have to wait > until 7.8.4 (sometime in the late summer I imagine) to get your word > in. Is there anything anyone absolutely must have that I've missed? Probably I'm very late, and the Nix guys can hopefully workaround this on their own side, but can you take a quick look on: https://ghc.haskell.org/trac/ghc/ticket/8919 It seems reasonable to just make terminfo, haskeline and xhtml visible to the users from the ghc included packagedb. What can possible go wrong? :) Gergely From juhpetersen at gmail.com Thu Jun 5 16:31:09 2014 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 6 Jun 2014 01:31:09 +0900 Subject: 7.8.3 release - please speak up soon. In-Reply-To: <871tv3l8wf.fsf@gergely.risko.hu> References: <871tv3l8wf.fsf@gergely.risko.hu> Message-ID: On 5 June 2014 23:37, Gergely Risko wrote: > It seems reasonable to just make terminfo, haskeline and xhtml visible > to the users from the ghc included packagedb. What can possible go > wrong? :) > +1 I am planning to do this anyway in the Fedora package [1] and haven't encountered any problems yet (with [2]). But if It is too late, I would suggest doing it for 7.10 anyway Jens. [1] I attached the simple patch to the ticket now. [2] http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora-20-x86_64/ghc-7.8.2-33.3.fc20/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Jun 5 16:59:36 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 5 Jun 2014 19:59:36 +0300 Subject: can a StgRhs have NoCCS when -prof is provided? Message-ID: Hi all, Can a StgRhs have `NoCCS` as cost-centre stack when -prof is provided while compiling? Or is it always oneOf [CurrentCCS, DontCareCCS, SingletonCCS]? I presume that since we have CCS constructor "DontCareCCS" and CCS field of StgRhs constructors are not `Maybe CostCentreStack` (so they're not optional), when -prof is provided CCS fields should not be filled with NoCCS(if we still don't care about CCS for some reason, it should be DontCareCCS) but I just wanted to make sure. Thanks. --- ?mer Sinan A?acan http://osa1.net From slyich at gmail.com Thu Jun 5 19:27:30 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Thu, 5 Jun 2014 22:27:30 +0300 Subject: 7.8.3 release - please speak up soon. In-Reply-To: <871tv3l8wf.fsf@gergely.risko.hu> References: <871tv3l8wf.fsf@gergely.risko.hu> Message-ID: <20140605222730.1d2afaf1@sf> On Thu, 05 Jun 2014 16:37:36 +0200 Gergely Risko wrote: > Probably I'm very late, and the Nix guys can hopefully workaround this > on their own side, but can you take a quick look on: > https://ghc.haskell.org/trac/ghc/ticket/8919 Hia! Can you write what problems are to ship those libraries in it's current form? Do you have some linking problems or something? Ticket does not describe any actual problems. Thanks! -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ezyang at mit.edu Thu Jun 5 19:22:21 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 05 Jun 2014 12:22:21 -0700 Subject: can a StgRhs have NoCCS when -prof is provided? In-Reply-To: References: Message-ID: <1401995878-sup-2568@sabre> Yes, I think all NoCCS are removed in the SCCfinal pass. NoCCS is a convenient thing to fill in when STG is initially created. Edward Excerpts from ?mer Sinan A?acan's message of 2014-06-05 09:59:36 -0700: > Hi all, > > Can a StgRhs have `NoCCS` as cost-centre stack when -prof is provided > while compiling? Or is it always oneOf [CurrentCCS, DontCareCCS, > SingletonCCS]? > > I presume that since we have CCS constructor "DontCareCCS" and CCS > field of StgRhs constructors are not `Maybe CostCentreStack` (so > they're not optional), when -prof is provided CCS fields should not be > filled with NoCCS(if we still don't care about CCS for some reason, it > should be DontCareCCS) but I just wanted to make sure. > > Thanks. > > --- > ?mer Sinan A?acan > http://osa1.net From kazu at iij.ad.jp Fri Jun 6 01:26:32 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 06 Jun 2014 10:26:32 +0900 (JST) Subject: Status updates In-Reply-To: References: Message-ID: <20140606.102632.311670019412324206.kazu@iij.ad.jp> Hi, > - Also, if you have spare hardware, please email Gabor Pali (or just > email the list itself, or reply to this thread) if you're willing to > donate, that would be awesome. Another Mac OS X target would be > especially welcome, I think (my development machine is on loan right > now), and I will have better dedicated Windows targets soon. I have one Mac Pro to build GHC. But it is behind a firewall. Is this useful for this purpose? --Kazu From carter.schonwald at gmail.com Fri Jun 6 01:33:15 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 5 Jun 2014 21:33:15 -0400 Subject: Status updates In-Reply-To: <20140606.102632.311670019412324206.kazu@iij.ad.jp> References: <20140606.102632.311670019412324206.kazu@iij.ad.jp> Message-ID: I can build on my Mac. Happy to do so since I'll be doing anyways :-) On Thursday, June 5, 2014, Kazu Yamamoto wrote: > Hi, > > > - Also, if you have spare hardware, please email Gabor Pali (or just > > email the list itself, or reply to this thread) if you're willing to > > donate, that would be awesome. Another Mac OS X target would be > > especially welcome, I think (my development machine is on loan right > > now), and I will have better dedicated Windows targets soon. > > I have one Mac Pro to build GHC. But it is behind a firewall. > Is this useful for this purpose? > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Jun 6 04:05:35 2014 From: austin at well-typed.com (Austin Seipp) Date: Thu, 5 Jun 2014 23:05:35 -0500 Subject: RFC: Phabricator for patches and code review Message-ID: Hello all, Recently, while doing server maintenance, several of the administrators for Haskell.org set up an instance of Phabricator[1], located at https://phabricator.haskell.org For those who aren't aware, Phabricator (or "Phab") is a suite of tools for software development. Think of it like a polished, semi-private GitHub with a lot of applications and tools for all kinds of needs. We've been using it to do issue tracking for Haskell.org maintenance and like it a lot so far. One very nice aspect of Phabricator though is it has a very nice code review tool, called 'Differential', that is very useful. For people who have used a tool like Review Board, it's similar. Furthermore, it has a very convenient userland tool called 'Arcanist' which makes it easy for newcomers to post a review and get it merged when it's ready all from the command line. I'd like to see if people are interested in using Phab _strictly_ for code review of GHC patches. It is a dedicated tool specifically for this, and I think it works much better than Trac or inline GitHub comments. Also, Phab can also support post-commit reviews. So if I touch something in the runtime system and just push, perhaps Simon or Edward would like to look, and they can be alerted right when I do this, and then yell if I did something stupid. Before I go much further, I'd like to ask: is there *any* interest in this? Or are people satisifed with Trac? The primary motivations are roughly, in no particular order: 1) Code review is good for everyone, a good way for people to learn the code and ask questions, and useful to give feedback to newcomers. And even experienced GHC hackers can learn things from reading code, as we all do regularly, or find things that need cleanup. 2) Phabricator in particular makes it very easy to submit patches for review. To submit a patch, I just run the command 'arc diff' and it Does The Right Thing. It also makes it easy to ensure people are *alerted* when a patch might be relevant to them. 3) They can be uploaded and created from the command line, and merged easily afterwords the same way. This is particularly useful for newcomers, and for me. :) 4) Differential is dedicated to code review, and much better at it than just reading patches on Trac IMO. 5) It supports both post-commit code review, as well as pre-commit review. Post commit would be especially useful for us too, I think. Point #2 and #3 are mostly relevant for me, because I mostly handle incoming patches. But I think in general it would be nice, and make it a lot easier for newcomers to submit patches, and us to look over them. Here's an example of a Differential code review: https://phabricator.haskell.org/D4 This is a demo using my 'wip/ermsb' patch. You'll need to create an account to login, but it shouldn't be much trouble, you can login several ways. I'll fix the login requirement soon. Feel free to read the code, comment on it, and play around. It's more of a demonstration, but real code review would be welcome too. :) If people are interested in doing this, I can add notes to the wiki pages for newcomers, and I'll send another email about Phab so people can understand it a little better. But I want to ask first. There is an argument that our team is so small, code review has unnecessary burdens. But I think Phab could help a lot with tracking outside patches and getting good reviews for incoming patches, and it'll make it easier for newcomers. And experienced pros can probably learn a thing as well. Again, to be clear, I don't propose we migrate anything to Phabricator from, say, Trac. There's no real pressure to do so and it would be tons of work. I only propose we use it for code review, which is perfectly fine, and how other projects like LLVM do code review (they use Bugzilla). I also don't think the usage of Phabricator should be mandatory (unless we decide that later because we like it), but I would like to see people use it if possible. [1] http://phabricator.org -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Fri Jun 6 04:19:59 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 6 Jun 2014 00:19:59 -0400 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: while i'm a novice at using ANY code review tools, having some persistent tooling for patch reviews would be really great! theres a lot of good feedback that otherwise only exists in an email somewhere! On Fri, Jun 6, 2014 at 12:05 AM, Austin Seipp wrote: > Hello all, > > Recently, while doing server maintenance, several of the > administrators for Haskell.org set up an instance of Phabricator[1], > located at https://phabricator.haskell.org > > For those who aren't aware, Phabricator (or "Phab") is a suite of > tools for software development. Think of it like a polished, > semi-private GitHub with a lot of applications and tools for all kinds > of needs. We've been using it to do issue tracking for Haskell.org > maintenance and like it a lot so far. > > One very nice aspect of Phabricator though is it has a very nice code > review tool, called 'Differential', that is very useful. For people > who have used a tool like Review Board, it's similar. Furthermore, it > has a very convenient userland tool called 'Arcanist' which makes it > easy for newcomers to post a review and get it merged when it's ready > all from the command line. > > I'd like to see if people are interested in using Phab _strictly_ for > code review of GHC patches. It is a dedicated tool specifically for > this, and I think it works much better than Trac or inline GitHub > comments. > > Also, Phab can also support post-commit reviews. So if I touch > something in the runtime system and just push, perhaps Simon or Edward > would like to look, and they can be alerted right when I do this, and > then yell if I did something stupid. > > Before I go much further, I'd like to ask: is there *any* interest in > this? Or are people satisifed with Trac? The primary motivations are > roughly, in no particular order: > > 1) Code review is good for everyone, a good way for people to learn > the code and ask questions, and useful to give feedback to newcomers. > And even experienced GHC hackers can learn things from reading code, > as we all do regularly, or find things that need cleanup. > > 2) Phabricator in particular makes it very easy to submit patches for > review. To submit a patch, I just run the command 'arc diff' and it > Does The Right Thing. It also makes it easy to ensure people are > *alerted* when a patch might be relevant to them. > > 3) They can be uploaded and created from the command line, and merged > easily afterwords the same way. This is particularly useful for > newcomers, and for me. :) > > 4) Differential is dedicated to code review, and much better at it > than just reading patches on Trac IMO. > > 5) It supports both post-commit code review, as well as pre-commit > review. Post commit would be especially useful for us too, I think. > > Point #2 and #3 are mostly relevant for me, because I mostly handle > incoming patches. But I think in general it would be nice, and make it > a lot easier for newcomers to submit patches, and us to look over > them. > > Here's an example of a Differential code review: > > https://phabricator.haskell.org/D4 > > This is a demo using my 'wip/ermsb' patch. You'll need to create an > account to login, but it shouldn't be much trouble, you can login > several ways. I'll fix the login requirement soon. Feel free to read > the code, comment on it, and play around. It's more of a > demonstration, but real code review would be welcome too. :) > > If people are interested in doing this, I can add notes to the wiki > pages for newcomers, and I'll send another email about Phab so people > can understand it a little better. But I want to ask first. > > There is an argument that our team is so small, code review has > unnecessary burdens. But I think Phab could help a lot with tracking > outside patches and getting good reviews for incoming patches, and > it'll make it easier for newcomers. And experienced pros can probably > learn a thing as well. > > Again, to be clear, I don't propose we migrate anything to Phabricator > from, say, Trac. There's no real pressure to do so and it would be > tons of work. I only propose we use it for code review, which is > perfectly fine, and how other projects like LLVM do code review (they > use Bugzilla). > > I also don't think the usage of Phabricator should be mandatory > (unless we decide that later because we like it), but I would like to > see people use it if possible. > > [1] http://phabricator.org > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jun 6 06:28:26 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 06:28:26 +0000 Subject: Phabricator for patches and code review In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs at haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the administrators | for Haskell.org set up an instance of Phabricator[1], located at | https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or "Phab") is a suite of tools | for software development. Think of it like a polished, semi-private | GitHub with a lot of applications and tools for all kinds of needs. | We've been using it to do issue tracking for Haskell.org maintenance and | like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people who | have used a tool like Review Board, it's similar. Furthermore, it has a | very convenient userland tool called 'Arcanist' which makes it easy for | newcomers to post a review and get it merged when it's ready all from | the command line. | | I'd like to see if people are interested in using Phab _strictly_ for | code review of GHC patches. It is a dedicated tool specifically for | this, and I think it works much better than Trac or inline GitHub | comments. | | Also, Phab can also support post-commit reviews. So if I touch something | in the runtime system and just push, perhaps Simon or Edward would like | to look, and they can be alerted right when I do this, and then yell if | I did something stupid. | | Before I go much further, I'd like to ask: is there *any* interest in | this? Or are people satisifed with Trac? The primary motivations are | roughly, in no particular order: | | 1) Code review is good for everyone, a good way for people to learn the | code and ask questions, and useful to give feedback to newcomers. | And even experienced GHC hackers can learn things from reading code, as | we all do regularly, or find things that need cleanup. | | 2) Phabricator in particular makes it very easy to submit patches for | review. To submit a patch, I just run the command 'arc diff' and it Does | The Right Thing. It also makes it easy to ensure people are | *alerted* when a patch might be relevant to them. | | 3) They can be uploaded and created from the command line, and merged | easily afterwords the same way. This is particularly useful for | newcomers, and for me. :) | | 4) Differential is dedicated to code review, and much better at it than | just reading patches on Trac IMO. | | 5) It supports both post-commit code review, as well as pre-commit | review. Post commit would be especially useful for us too, I think. | | Point #2 and #3 are mostly relevant for me, because I mostly handle | incoming patches. But I think in general it would be nice, and make it a | lot easier for newcomers to submit patches, and us to look over them. | | Here's an example of a Differential code review: | | https://phabricator.haskell.org/D4 | | This is a demo using my 'wip/ermsb' patch. You'll need to create an | account to login, but it shouldn't be much trouble, you can login | several ways. I'll fix the login requirement soon. Feel free to read the | code, comment on it, and play around. It's more of a demonstration, but | real code review would be welcome too. :) | | If people are interested in doing this, I can add notes to the wiki | pages for newcomers, and I'll send another email about Phab so people | can understand it a little better. But I want to ask first. | | There is an argument that our team is so small, code review has | unnecessary burdens. But I think Phab could help a lot with tracking | outside patches and getting good reviews for incoming patches, and it'll | make it easier for newcomers. And experienced pros can probably learn a | thing as well. | | Again, to be clear, I don't propose we migrate anything to Phabricator | from, say, Trac. There's no real pressure to do so and it would be tons | of work. I only propose we use it for code review, which is perfectly | fine, and how other projects like LLVM do code review (they use | Bugzilla). | | I also don't think the usage of Phabricator should be mandatory (unless | we decide that later because we like it), but I would like to see people | use it if possible. | | [1] http://phabricator.org | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Fri Jun 6 06:29:08 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 06:29:08 +0000 Subject: Phabricator for patches and code review In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8AF9@DB3PRD3001MB020.064d.mgd.msft.net> PS I couldn't get past the login box at https://phabricator.haskell.org/D4 | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs at haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the administrators | for Haskell.org set up an instance of Phabricator[1], located at | https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or "Phab") is a suite of tools | for software development. Think of it like a polished, semi-private | GitHub with a lot of applications and tools for all kinds of needs. | We've been using it to do issue tracking for Haskell.org maintenance and | like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people who | have used a tool like Review Board, it's similar. Furthermore, it has a | very convenient userland tool called 'Arcanist' which makes it easy for | newcomers to post a review and get it merged when it's ready all from | the command line. | | I'd like to see if people are interested in using Phab _strictly_ for | code review of GHC patches. It is a dedicated tool specifically for | this, and I think it works much better than Trac or inline GitHub | comments. | | Also, Phab can also support post-commit reviews. So if I touch something | in the runtime system and just push, perhaps Simon or Edward would like | to look, and they can be alerted right when I do this, and then yell if | I did something stupid. | | Before I go much further, I'd like to ask: is there *any* interest in | this? Or are people satisifed with Trac? The primary motivations are | roughly, in no particular order: | | 1) Code review is good for everyone, a good way for people to learn the | code and ask questions, and useful to give feedback to newcomers. | And even experienced GHC hackers can learn things from reading code, as | we all do regularly, or find things that need cleanup. | | 2) Phabricator in particular makes it very easy to submit patches for | review. To submit a patch, I just run the command 'arc diff' and it Does | The Right Thing. It also makes it easy to ensure people are | *alerted* when a patch might be relevant to them. | | 3) They can be uploaded and created from the command line, and merged | easily afterwords the same way. This is particularly useful for | newcomers, and for me. :) | | 4) Differential is dedicated to code review, and much better at it than | just reading patches on Trac IMO. | | 5) It supports both post-commit code review, as well as pre-commit | review. Post commit would be especially useful for us too, I think. | | Point #2 and #3 are mostly relevant for me, because I mostly handle | incoming patches. But I think in general it would be nice, and make it a | lot easier for newcomers to submit patches, and us to look over them. | | Here's an example of a Differential code review: | | https://phabricator.haskell.org/D4 | | This is a demo using my 'wip/ermsb' patch. You'll need to create an | account to login, but it shouldn't be much trouble, you can login | several ways. I'll fix the login requirement soon. Feel free to read the | code, comment on it, and play around. It's more of a demonstration, but | real code review would be welcome too. :) | | If people are interested in doing this, I can add notes to the wiki | pages for newcomers, and I'll send another email about Phab so people | can understand it a little better. But I want to ask first. | | There is an argument that our team is so small, code review has | unnecessary burdens. But I think Phab could help a lot with tracking | outside patches and getting good reviews for incoming patches, and it'll | make it easier for newcomers. And experienced pros can probably learn a | thing as well. | | Again, to be clear, I don't propose we migrate anything to Phabricator | from, say, Trac. There's no real pressure to do so and it would be tons | of work. I only propose we use it for code review, which is perfectly | fine, and how other projects like LLVM do code review (they use | Bugzilla). | | I also don't think the usage of Phabricator should be mandatory (unless | we decide that later because we like it), but I would like to see people | use it if possible. | | [1] http://phabricator.org | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Fri Jun 6 07:04:27 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Jun 2014 02:04:27 -0500 Subject: Phabricator for patches and code review In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Fri, Jun 6, 2014 at 1:28 AM, Simon Peyton Jones wrote: > So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Yes, that's right - I think it will really help the whole workflow. As for Phabricator: it is used by several very large companies, including Facebook (so Simon might feel at home at least ;), it is actively developed by a team, and the Haskell.org admin team wants to keep using it. I don't think there are any plans for it to go away at this point, but it's still new. There are some other projects, like Review Board, but that leads me to... > Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. Good news: the workflow is quite easy at first, you can submit patches from the command line, and yes, the command line tool works on Windows! I *specifically* wanted this when choosing it. I can write up some documents discussing the basic idea. At my last job, we fiddled endlessly with Review Board for basic stuff like "create a review from the commit I just made". Being able to submit and interate patches so quickly is a huge, massive time saver for everyone. > I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Right. Actually, by default, when you merge in a set of changes using the Phabricator tool (which is mostly what I will do), it squashes them into a single commit, and adds a message pointing back to the review. So the commit is self contained, logical, and small, but you still get the full breadcrumbs, at least. > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin > | Seipp > | Sent: 06 June 2014 05:06 > | To: ghc-devs at haskell.org > | Subject: RFC: Phabricator for patches and code review > | > | Hello all, > | > | Recently, while doing server maintenance, several of the administrators > | for Haskell.org set up an instance of Phabricator[1], located at > | https://phabricator.haskell.org > | > | For those who aren't aware, Phabricator (or "Phab") is a suite of tools > | for software development. Think of it like a polished, semi-private > | GitHub with a lot of applications and tools for all kinds of needs. > | We've been using it to do issue tracking for Haskell.org maintenance and > | like it a lot so far. > | > | One very nice aspect of Phabricator though is it has a very nice code > | review tool, called 'Differential', that is very useful. For people who > | have used a tool like Review Board, it's similar. Furthermore, it has a > | very convenient userland tool called 'Arcanist' which makes it easy for > | newcomers to post a review and get it merged when it's ready all from > | the command line. > | > | I'd like to see if people are interested in using Phab _strictly_ for > | code review of GHC patches. It is a dedicated tool specifically for > | this, and I think it works much better than Trac or inline GitHub > | comments. > | > | Also, Phab can also support post-commit reviews. So if I touch something > | in the runtime system and just push, perhaps Simon or Edward would like > | to look, and they can be alerted right when I do this, and then yell if > | I did something stupid. > | > | Before I go much further, I'd like to ask: is there *any* interest in > | this? Or are people satisifed with Trac? The primary motivations are > | roughly, in no particular order: > | > | 1) Code review is good for everyone, a good way for people to learn the > | code and ask questions, and useful to give feedback to newcomers. > | And even experienced GHC hackers can learn things from reading code, as > | we all do regularly, or find things that need cleanup. > | > | 2) Phabricator in particular makes it very easy to submit patches for > | review. To submit a patch, I just run the command 'arc diff' and it Does > | The Right Thing. It also makes it easy to ensure people are > | *alerted* when a patch might be relevant to them. > | > | 3) They can be uploaded and created from the command line, and merged > | easily afterwords the same way. This is particularly useful for > | newcomers, and for me. :) > | > | 4) Differential is dedicated to code review, and much better at it than > | just reading patches on Trac IMO. > | > | 5) It supports both post-commit code review, as well as pre-commit > | review. Post commit would be especially useful for us too, I think. > | > | Point #2 and #3 are mostly relevant for me, because I mostly handle > | incoming patches. But I think in general it would be nice, and make it a > | lot easier for newcomers to submit patches, and us to look over them. > | > | Here's an example of a Differential code review: > | > | https://phabricator.haskell.org/D4 > | > | This is a demo using my 'wip/ermsb' patch. You'll need to create an > | account to login, but it shouldn't be much trouble, you can login > | several ways. I'll fix the login requirement soon. Feel free to read the > | code, comment on it, and play around. It's more of a demonstration, but > | real code review would be welcome too. :) > | > | If people are interested in doing this, I can add notes to the wiki > | pages for newcomers, and I'll send another email about Phab so people > | can understand it a little better. But I want to ask first. > | > | There is an argument that our team is so small, code review has > | unnecessary burdens. But I think Phab could help a lot with tracking > | outside patches and getting good reviews for incoming patches, and it'll > | make it easier for newcomers. And experienced pros can probably learn a > | thing as well. > | > | Again, to be clear, I don't propose we migrate anything to Phabricator > | from, say, Trac. There's no real pressure to do so and it would be tons > | of work. I only propose we use it for code review, which is perfectly > | fine, and how other projects like LLVM do code review (they use > | Bugzilla). > | > | I also don't think the usage of Phabricator should be mandatory (unless > | we decide that later because we like it), but I would like to see people > | use it if possible. > | > | [1] http://phabricator.org > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Jun 6 07:05:58 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Jun 2014 02:05:58 -0500 Subject: Phabricator for patches and code review In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8AF9@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D8AF9@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm fiddling with the access policies a bit, to make it all publicly viewable. I thought I fixed it, but apparently not... In the mean time, you can just register an account (with a username/password, or just use your existing GitHub login!) and everything will be viewable. On Fri, Jun 6, 2014 at 1:29 AM, Simon Peyton Jones wrote: > PS I couldn't get past the login box at https://phabricator.haskell.org/D4 > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin > | Seipp > | Sent: 06 June 2014 05:06 > | To: ghc-devs at haskell.org > | Subject: RFC: Phabricator for patches and code review > | > | Hello all, > | > | Recently, while doing server maintenance, several of the administrators > | for Haskell.org set up an instance of Phabricator[1], located at > | https://phabricator.haskell.org > | > | For those who aren't aware, Phabricator (or "Phab") is a suite of tools > | for software development. Think of it like a polished, semi-private > | GitHub with a lot of applications and tools for all kinds of needs. > | We've been using it to do issue tracking for Haskell.org maintenance and > | like it a lot so far. > | > | One very nice aspect of Phabricator though is it has a very nice code > | review tool, called 'Differential', that is very useful. For people who > | have used a tool like Review Board, it's similar. Furthermore, it has a > | very convenient userland tool called 'Arcanist' which makes it easy for > | newcomers to post a review and get it merged when it's ready all from > | the command line. > | > | I'd like to see if people are interested in using Phab _strictly_ for > | code review of GHC patches. It is a dedicated tool specifically for > | this, and I think it works much better than Trac or inline GitHub > | comments. > | > | Also, Phab can also support post-commit reviews. So if I touch something > | in the runtime system and just push, perhaps Simon or Edward would like > | to look, and they can be alerted right when I do this, and then yell if > | I did something stupid. > | > | Before I go much further, I'd like to ask: is there *any* interest in > | this? Or are people satisifed with Trac? The primary motivations are > | roughly, in no particular order: > | > | 1) Code review is good for everyone, a good way for people to learn the > | code and ask questions, and useful to give feedback to newcomers. > | And even experienced GHC hackers can learn things from reading code, as > | we all do regularly, or find things that need cleanup. > | > | 2) Phabricator in particular makes it very easy to submit patches for > | review. To submit a patch, I just run the command 'arc diff' and it Does > | The Right Thing. It also makes it easy to ensure people are > | *alerted* when a patch might be relevant to them. > | > | 3) They can be uploaded and created from the command line, and merged > | easily afterwords the same way. This is particularly useful for > | newcomers, and for me. :) > | > | 4) Differential is dedicated to code review, and much better at it than > | just reading patches on Trac IMO. > | > | 5) It supports both post-commit code review, as well as pre-commit > | review. Post commit would be especially useful for us too, I think. > | > | Point #2 and #3 are mostly relevant for me, because I mostly handle > | incoming patches. But I think in general it would be nice, and make it a > | lot easier for newcomers to submit patches, and us to look over them. > | > | Here's an example of a Differential code review: > | > | https://phabricator.haskell.org/D4 > | > | This is a demo using my 'wip/ermsb' patch. You'll need to create an > | account to login, but it shouldn't be much trouble, you can login > | several ways. I'll fix the login requirement soon. Feel free to read the > | code, comment on it, and play around. It's more of a demonstration, but > | real code review would be welcome too. :) > | > | If people are interested in doing this, I can add notes to the wiki > | pages for newcomers, and I'll send another email about Phab so people > | can understand it a little better. But I want to ask first. > | > | There is an argument that our team is so small, code review has > | unnecessary burdens. But I think Phab could help a lot with tracking > | outside patches and getting good reviews for incoming patches, and it'll > | make it easier for newcomers. And experienced pros can probably learn a > | thing as well. > | > | Again, to be clear, I don't propose we migrate anything to Phabricator > | from, say, Trac. There's no real pressure to do so and it would be tons > | of work. I only propose we use it for code review, which is perfectly > | fine, and how other projects like LLVM do code review (they use > | Bugzilla). > | > | I also don't think the usage of Phabricator should be mandatory (unless > | we decide that later because we like it), but I would like to see people > | use it if possible. > | > | [1] http://phabricator.org > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From omeragacan at gmail.com Fri Jun 6 08:13:22 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 6 Jun 2014 11:13:22 +0300 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: 2014-06-06 7:05 GMT+03:00 Austin Seipp : > 2) Phabricator in particular makes it very easy to submit patches for > review. To submit a patch, I just run the command 'arc diff' and it > Does The Right Thing. It also makes it easy to ensure people are > *alerted* when a patch might be relevant to them. This sounds really good. I was thinking about sending an email about this for a while now. I'm reading some parts of GHC and there are lots of small patches I'd like to submit for reviews. Most of the time these are <10 lines of changes. But trac makes everything so hard and the interface is so horrible, I'm ending up not sending the patch. Also, testing is a huge problem for me. I can't test GHC on my laptop(which is my only development environment) because it takes forever to finish. With something like Github and a CI server(Jenkins/Travis/whatever) integrated to the Github repository that runs tests on pull request, it would be super easy for new contributors to submit small patches. As far as I can understand(altough currently I can't see how to send a patch) Phabricator helps sending pull requests/patches, but does it help with testing too? --- ?mer Sinan A?acan http://osa1.net From marlowsd at gmail.com Fri Jun 6 09:39:00 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 06 Jun 2014 10:39:00 +0100 Subject: (drop)CommonPrefix: ccs call implementation In-Reply-To: References: <53901245.9060603@maartenfaddegon.nl> Message-ID: <53918C34.7010600@gmail.com> The motivation for this design is to make it so that let f = \x . E in ... f y ... Gives the same call stack as ... (\x . E) y ... That is, inlining a function does not change the call stack. GHC assumes that this is valid, so the call stack semantics should reflect that. Intuitively it works like this: in the first version, the CCS attached to the closure for f is some prefix of the CCS that will be in force at the call site, and in that case we don't want to push anything on the stack for the call. However, we might have: let f = scc "f" (\x . E) in ... f y ... and in this case we want to push "f" on the stack. I don't claim that this always works (recursion in particular causes problems) but it behaves in a sensible way in most cases, and it was the best formulation I was able to find. It remains to be seen whether there's a semantics that allows the inlining equivalence to be formally proven; if you can do that I think it would be a significant step forwards. Cheers, Simon On 05/06/2014 09:57, ?mer Sinan A?acan wrote: > Hi Maarten, > > Where did you find that slides? I have slides for same talk(also > attached) but mine has a different definition for call: (on page 39) > > call sapp slam = sapp ++ slam' > where (spre, sapp', slam') = commonPrefix sapp slam > > This one works same with the implementation. > > --- > ?mer Sinan A?acan > http://osa1.net > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Fri Jun 6 09:44:38 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 09:44:38 +0000 Subject: haddock in 7.8.3 Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8C28@DB3PRD3001MB020.064d.mgd.msft.net> I want to change the interface to PatSyn.patSynSig, as part of fixing a bug in 7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock on change to Haddock Is that acceptable in a 7.8.3 release cycle? If not, I can program round it in the 7.8.3 branch. But if it's not a problem, it'd be a bit easier just to make the change in Haddock? (Really Haddock has to be co-released with GHC, since it depends on many internal GHC details.) Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Jun 6 09:54:26 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 06 Jun 2014 10:54:26 +0100 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: <53918FD2.1070505@gmail.com> tl;dir I strongly support this, but for code review only, and only if we can integrate it well with Trac. Phabricator is what we use internally at Facebook, and it's a really good code review tool (better than github, IMO). For one thing, you only get one email for a complete review, rather than one email for each comment(!). The UI is clean and streamlined, and reviewing diffs is a pleasure. If done right, this could improve our workflow a lot. If done wrong, it could just make things more complex - we'd want to steer people away from both github pull requests and attaching patches in Trac and towards Phabricator instead. They have to install a local tool (arc), which could be a barrier to contribution. We would need some integration between Phabricator and Trac. I don't know whether any of this exists, but for example we'd want to have a way to link to Trac tickets from Differential, and to have diffs automatically show up attached to Trac tickets when they are linked to the ticket (by mentioning the ticket in the commit message, for example). So I think this is a lot of work, but if someone were prepared to do it then I think it could improve our lives. Cheers, Simon On 06/06/2014 05:05, Austin Seipp wrote: > Hello all, > > Recently, while doing server maintenance, several of the > administrators for Haskell.org set up an instance of Phabricator[1], > located at https://phabricator.haskell.org > > For those who aren't aware, Phabricator (or "Phab") is a suite of > tools for software development. Think of it like a polished, > semi-private GitHub with a lot of applications and tools for all kinds > of needs. We've been using it to do issue tracking for Haskell.org > maintenance and like it a lot so far. > > One very nice aspect of Phabricator though is it has a very nice code > review tool, called 'Differential', that is very useful. For people > who have used a tool like Review Board, it's similar. Furthermore, it > has a very convenient userland tool called 'Arcanist' which makes it > easy for newcomers to post a review and get it merged when it's ready > all from the command line. > > I'd like to see if people are interested in using Phab _strictly_ for > code review of GHC patches. It is a dedicated tool specifically for > this, and I think it works much better than Trac or inline GitHub > comments. > > Also, Phab can also support post-commit reviews. So if I touch > something in the runtime system and just push, perhaps Simon or Edward > would like to look, and they can be alerted right when I do this, and > then yell if I did something stupid. > > Before I go much further, I'd like to ask: is there *any* interest in > this? Or are people satisifed with Trac? The primary motivations are > roughly, in no particular order: > > 1) Code review is good for everyone, a good way for people to learn > the code and ask questions, and useful to give feedback to newcomers. > And even experienced GHC hackers can learn things from reading code, > as we all do regularly, or find things that need cleanup. > > 2) Phabricator in particular makes it very easy to submit patches for > review. To submit a patch, I just run the command 'arc diff' and it > Does The Right Thing. It also makes it easy to ensure people are > *alerted* when a patch might be relevant to them. > > 3) They can be uploaded and created from the command line, and merged > easily afterwords the same way. This is particularly useful for > newcomers, and for me. :) > > 4) Differential is dedicated to code review, and much better at it > than just reading patches on Trac IMO. > > 5) It supports both post-commit code review, as well as pre-commit > review. Post commit would be especially useful for us too, I think. > > Point #2 and #3 are mostly relevant for me, because I mostly handle > incoming patches. But I think in general it would be nice, and make it > a lot easier for newcomers to submit patches, and us to look over > them. > > Here's an example of a Differential code review: > > https://phabricator.haskell.org/D4 > > This is a demo using my 'wip/ermsb' patch. You'll need to create an > account to login, but it shouldn't be much trouble, you can login > several ways. I'll fix the login requirement soon. Feel free to read > the code, comment on it, and play around. It's more of a > demonstration, but real code review would be welcome too. :) > > If people are interested in doing this, I can add notes to the wiki > pages for newcomers, and I'll send another email about Phab so people > can understand it a little better. But I want to ask first. > > There is an argument that our team is so small, code review has > unnecessary burdens. But I think Phab could help a lot with tracking > outside patches and getting good reviews for incoming patches, and > it'll make it easier for newcomers. And experienced pros can probably > learn a thing as well. > > Again, to be clear, I don't propose we migrate anything to Phabricator > from, say, Trac. There's no real pressure to do so and it would be > tons of work. I only propose we use it for code review, which is > perfectly fine, and how other projects like LLVM do code review (they > use Bugzilla). > > I also don't think the usage of Phabricator should be mandatory > (unless we decide that later because we like it), but I would like to > see people use it if possible. > > [1] http://phabricator.org > From fuuzetsu at fuuzetsu.co.uk Fri Jun 6 09:59:08 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 06 Jun 2014 11:59:08 +0200 Subject: haddock in 7.8.3 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8C28@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D8C28@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <539190EC.6020608@fuuzetsu.co.uk> On 06/06/2014 11:44 AM, Simon Peyton Jones wrote: > I want to change the interface to PatSyn.patSynSig, as part of fixing a bug in 7.8.2. But Haddock calls patSynSig, so there is a (fairly trivial) knock on change to Haddock > Is that acceptable in a 7.8.3 release cycle? There are already some Haddock changes going into 7.8.3 anyway so I don't see why not as long as someone can push it into the ghc-7.8 branch. The only thing to watch out for is that this branch is separate from the current master branch so the fix has to be applied on both. > If not, I can program round it in the 7.8.3 branch. But if it's not a problem, it'd be a bit easier just to make the change in Haddock? (Really Haddock has to be co-released with GHC, since it depends on many internal GHC details.) > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Mateusz K. From pali.gabor at gmail.com Fri Jun 6 10:50:50 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Fri, 6 Jun 2014 12:50:50 +0200 Subject: Status updates In-Reply-To: <20140606.102632.311670019412324206.kazu@iij.ad.jp> References: <20140606.102632.311670019412324206.kazu@iij.ad.jp> Message-ID: 2014-06-06 3:26 GMT+02:00 Kazu Yamamoto : > I have one Mac Pro to build GHC. But it is behind a firewall. > Is this useful for this purpose? If it can reach the server (haskell.inf.elte.hu) on port 4938 then you are probably good to go. The other requirement would be to able to run 24/7 so the clients could do their work seamlessly. From simonpj at microsoft.com Fri Jun 6 11:47:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 11:47:03 +0000 Subject: pushing to haddock Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> I'm trying desperately to follow the instructions on https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules for how to update haddock to follow a small change to GHC. I've checked out the haddock master, made my patch, and want to push to haddock. But my push is rejected for an inscrutable reason: git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean) simonpj at cam-05-unx:~/code/HEAD-2/utils/haddock$ git push Counting objects: 9, done. Delta compression using up to 32 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 470 bytes, done. Total 5 (delta 4), reused 0 (delta 0) remote: W refs/heads/master haddock simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/master To ssh://git at ghc.haskell.org/haddock.git ! [remote rejected] HEAD -> master (hook declined) error: failed to push some refs to 'ssh://git at ghc.haskell.org/haddock.git' simonpj at cam-05-unx:~/code/HEAD-2/utils/haddock$ What do I do now? Presumably once that's done I include the change to utils/haddock in my patch to HEAD, correct? Getting to Haddock HEAD added 12 new patches on the haddock branch so I suppose they'll be included too. I don't know whether that is good or bad. help! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Jun 6 11:56:10 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 06 Jun 2014 13:56:10 +0200 Subject: pushing to haddock In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Fri, 6 Jun 2014 11:47:03 +0000") References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87bnu6i751.fsf@gmail.com> On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote: > I'm trying desperately to follow the instructions on > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules > for how to update haddock to follow a small change to GHC. > I've checked out the haddock master, made my patch, and want to push > to haddock. But my push is rejected for an inscrutable reason: Sorry, I haven't gotten to provide more guidance for haddock.git, which is the first repo whose primary repo has been relocated to GitHub. So you have to push via GitHub now. Short story: you have to use ssh://git at github.com/haskell/haddock.git as push-url git push ssh://git at github.com/haskell/haddock.git where refers to the kind of branch-update operation you want to push, like e.g. 'HEAD:master' to update the remote master branch to what your current local HEAD points to. There will be a more "guided" process as soon as I get to provide some tooling + additional docs for that. [...] > What do I do now? > Presumably once that's done I include the change to utils/haddock in my patch to HEAD, correct? > Getting to Haddock HEAD added 12 new patches on the haddock branch so > I suppose they'll be included too. I don't know whether that is good > or bad. > help! Once you were able to push the commits to GitHub's haddock.git repo, they'll be mirrored to git.haskell.org within one minute. At which point you'll be able to push the Git submodule/gitlink update to ghc.git pointing to the new 'master'-tip of haddock.git (if that was your question) From hvriedel at gmail.com Fri Jun 6 12:04:37 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 06 Jun 2014 14:04:37 +0200 Subject: pushing to haddock In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Fri, 6 Jun 2014 11:47:03 +0000") References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <877g4ui6qy.fsf@gmail.com> On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote: [...] > To ssh://git at ghc.haskell.org/haddock.git PS: you could also try to configure the following (assuming your Git is new enough): git config --global \ url."ssh://git at github.com/haskell/haddock.git".pushInsteadOf \ ssh://git at ghc.haskell.org/haddock.git This would instruct Git to redirect pushes to ssh://git at ghc.haskell.org/haddock.git to go via ssh://git at github.com/haskell/haddock.git instead (the idea is generally described on https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules and is what the tooling I'm planning to code up would help you manage based on the ./packages file) From simonpj at microsoft.com Fri Jun 6 12:07:44 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 12:07:44 +0000 Subject: pushing to haddock In-Reply-To: <87bnu6i751.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> <87bnu6i751.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8F94@DB3PRD3001MB020.064d.mgd.msft.net> | Short story: you have to use ssh://git at github.com/haskell/haddock.git as | push-url | | git push ssh://git at github.com/haskell/haddock.git | | where refers to the kind of branch-update operation you want | to push, like e.g. 'HEAD:master' to update the remote master branch to | what your current local HEAD points to. Can't I just set the push-url and then say git push I just did that and it appeared to work. | Once you were able to push the commits to GitHub's haddock.git repo, | they'll be mirrored to git.haskell.org within one minute. At which point | you'll be able to push the Git submodule/gitlink update to ghc.git | pointing to the new 'master'-tip of haddock.git (if that was your | question) How exactly do I do that? That is, when I'm back in the ghc repo, I just stage utils/haddock along with the rest of my changes, and push? What if I did so "too early" before the mirroring happened? Anyway, I did as above and pushed to GHC. Would you like to just check that I did it right. It would be ABSOLUTELY FANTASTIC to have these new workflows documented. Please! Thanks for a very prompt reply Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 06 June 2014 12:56 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: pushing to haddock | | On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote: | > I'm trying desperately to follow the instructions on | > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodule | > s for how to update haddock to follow a small change to GHC. | > I've checked out the haddock master, made my patch, and want to push | > to haddock. But my push is rejected for an inscrutable reason: | | Sorry, I haven't gotten to provide more guidance for haddock.git, which | is the first repo whose primary repo has been relocated to GitHub. So | you have to push via GitHub now. | | Short story: you have to use ssh://git at github.com/haskell/haddock.git as | push-url | | git push ssh://git at github.com/haskell/haddock.git | | where refers to the kind of branch-update operation you want | to push, like e.g. 'HEAD:master' to update the remote master branch to | what your current local HEAD points to. | | There will be a more "guided" process as soon as I get to provide some | tooling + additional docs for that. | | [...] | | > What do I do now? | > Presumably once that's done I include the change to utils/haddock in | my patch to HEAD, correct? | > Getting to Haddock HEAD added 12 new patches on the haddock branch so | > I suppose they'll be included too. I don't know whether that is good | > or bad. | > help! | | Once you were able to push the commits to GitHub's haddock.git repo, | they'll be mirrored to git.haskell.org within one minute. At which point | you'll be able to push the Git submodule/gitlink update to ghc.git | pointing to the new 'master'-tip of haddock.git (if that was your | question) From simonpj at microsoft.com Fri Jun 6 12:11:21 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 12:11:21 +0000 Subject: pushing to haddock In-Reply-To: <877g4ui6qy.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> <877g4ui6qy.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D8FB0@DB3PRD3001MB020.064d.mgd.msft.net> I ran that command and it didn't complain. No idea whether it worked or not though! This now appears in .gitconfig [url "ssh://git at github.com/haskell/haddock.git"] pushInsteadOf = ssh://git at ghc.haskell.org/haddock.git But shouldn't sync-all set this push-url stuff up correctly? Having to remember to look for redirects in .gitconfig seems like one more way to get confused when looking at a .git/config file. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 06 June 2014 13:05 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: pushing to haddock | | On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote: | | [...] | | > To ssh://git at ghc.haskell.org/haddock.git | | PS: you could also try to configure the following (assuming your Git is | new enough): | | git config --global \ | url."ssh://git at github.com/haskell/haddock.git".pushInsteadOf \ | ssh://git at ghc.haskell.org/haddock.git | | This would instruct Git to redirect pushes to | ssh://git at ghc.haskell.org/haddock.git to go via | ssh://git at github.com/haskell/haddock.git instead | | (the idea is generally described on | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules | and is what the tooling I'm planning to code up would help you manage | based on the ./packages file) From hvriedel at gmail.com Fri Jun 6 12:15:01 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 06 Jun 2014 14:15:01 +0200 Subject: pushing to haddock In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8F94@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Fri, 6 Jun 2014 12:07:44 +0000") References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> <87bnu6i751.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103D8F94@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <8738fii69m.fsf@gmail.com> On 2014-06-06 at 14:07:44 +0200, Simon Peyton Jones wrote: > | Short story: you have to use ssh://git at github.com/haskell/haddock.git as > | push-url > | > | git push ssh://git at github.com/haskell/haddock.git > | > | where refers to the kind of branch-update operation you want > | to push, like e.g. 'HEAD:master' to update the remote master branch to > | what your current local HEAD points to. > > Can't I just set the push-url and then say > > git push > > I just did that and it appeared to work. Yes, that'd be another way to accomplish that... Git supports many roads leading to rome :-) > | Once you were able to push the commits to GitHub's haddock.git repo, > | they'll be mirrored to git.haskell.org within one minute. At which point > | you'll be able to push the Git submodule/gitlink update to ghc.git > | pointing to the new 'master'-tip of haddock.git (if that was your > | question) > > How exactly do I do that? That is, when I'm back in the ghc repo, I > just stage utils/haddock along with the rest of my changes, and push? > > What if I did so "too early" before the mirroring happened? The validation hook would reject your ghc.git push telling you it couldn't find the referenced haddock.git commit (on git.haskell.org) > Anyway, I did as above and pushed to GHC. Would you like to just > check that I did it right. Everything looks perfect to me. > It would be ABSOLUTELY FANTASTIC to have these new workflows documented. Please! I'm planning to! haddock.git was just the first repo to be migrated in order to be able to work out the workflow a bit more isolated (as typically only few devs push to haddock.git these days) w/o breaking multiple repos at once :-) > Thanks for a very prompt reply From hvriedel at gmail.com Fri Jun 6 12:37:30 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 06 Jun 2014 14:37:30 +0200 Subject: pushing to haddock In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8FB0@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Fri, 6 Jun 2014 12:11:21 +0000") References: <618BE556AADD624C9C918AA5D5911BEF103D8EAE@DB3PRD3001MB020.064d.mgd.msft.net> <877g4ui6qy.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103D8FB0@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87wqcugqnp.fsf@gmail.com> On 2014-06-06 at 14:11:21 +0200, Simon Peyton Jones wrote: > I ran that command and it didn't complain. No idea whether it worked or not though! This now appears in .gitconfig > > [url "ssh://git at github.com/haskell/haddock.git"] > pushInsteadOf = ssh://git at ghc.haskell.org/haddock.git > > But shouldn't sync-all set this push-url stuff up correctly? Having > to remember to look for redirects in .gitconfig seems like one more > way to get confused when looking at a .git/config file. That's a valid argument of course. Otoh, I consider the {insteadOf,pushInsteadOf} more convenient, as it allows for simpler workflows, here's a few benefits I can see from the top of my head: - You have to set it up once, and then something like git clone --recursive git://git.haskell.org/ghc.git simply works, even when you want to use the GitHub mirror and git.haskell.org is unreachable. (without that, you'd have to first clone ghc.git non-recursively from GitHub, then 'git submodule init', then rewrite the submodule urls, and then finally 'git submodule update') - If git.haskell.org goes down suddenly or you need to switch from git:// to https:// suddenly, simply reconfigure your git-redirects to point to the new Git urls. And everything works as before -- for *all* your local GHC clones, but uses the new locations. If git.haskell.org is back up, you can revert the redirects. - When working with multiple local GHC clones, you don't have to keep track whether you need to update the push-urls/fetch-urls for submodules for the invidual clone. If you have configured the global redirects properly in some other GHC clone, it'll just work for the other clones as well. - When switching between post/pre-submodule conversion states, the global redirects take care of preserving/providing the proper push-url mappings. - For the previously used standard use-case, the following simple git config --global \ url."ssh://git at git.haskell.org/".pushInsteadOf \ git://git.haskell.org/ one-time "parametric" redirect rule setup, IMHO beats the complexity of the current './sync-all set-url --push' implementation which has nasty corner-cases to take into account. From simonpj at microsoft.com Fri Jun 6 12:37:19 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 12:37:19 +0000 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> Michael I think that would be great. Absolutely: the earlier we can catch regressions the better. Couldn?t we make it part of the continuous-integration builds (Travis?) that various folk are running, eg. Joachim? I?m hazy about how all of this works, but I?d love it just to happen automatically every night or whatever, with failure being reported by email, with instructions on how to reproduce the failure. Might you work with Joachim and others to make that possible? Thanks for suggesting it Simon From: Michael Snoyman [mailto:michael at fpcomplete.com] Sent: 05 June 2014 17:10 To: Simon Peyton Jones Subject: GHC/cabal release procedures, and Stackage Hi Simon, I wanted to bring up an idea I've been playing with for a few weeks now. The past few releases of GHC and cabal-install have introduced regressions that were not caught by test suites, but were caught by building code from Hackage. In particular, I discovered some of these bugs almost immediately after release by doing normal Stackage builds. So I'd like to propose that part of the GHC and cabal-install release processes include trying to run a build of Stackage. This should be both a good stress test, plus- since Stackage covers the majority of actively used packages- should also be a good indication that early adopters of the new version won't immediately hit bugs. I'm happy to volunteer to be a part of this process (e.g., to be the guy who actually runs the builds). As a user, I'd definitely appreciate the opportunity to iron out bugs before they hit the light of day and start causing larger headaches. What do you think? Thanks, Michael PS: A relevant issue is an upcoming yesod-bin breakage in GHC 7.8.3: https://github.com/yesodweb/yesod/issues/748. I haven't been able to investigate this myself since there seems to be a build bug for 7.8.3 when using the Gold linker. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jun 6 12:40:04 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Jun 2014 12:40:04 +0000 Subject: Status updates In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D7E60@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103D98BA@DB3PRD3001MB020.064d.mgd.msft.net> The obvious place to put it is on the "Status reports" page, which is one click from the side bar. A new heading with link to the nightly builds or Travis or whatever, and some description about how to interpret the information you find. Simon | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 05 June 2014 14:40 | To: Simon Peyton Jones | Cc: Austin Seipp; ghc-devs at haskell.org | Subject: Re: Status updates | | Drats, I forgot that. Here's where it is: | | Go to the GHC Trac hompeage: https://ghc.haskell.org/trac/ghc/ and | scroll down just a tiny bit. There's a section called 'Nightly builds' | with the updated link to the new UI, located on Gabor's server: | http://haskell.inf.elte.hu/builders/ | | Simon, did we talk about adding this to the sidebar? Or maybe we should | just highlight it on the front page a little more, and then link to it | from somewhere else on the sidebar (like "Building Guide" | links to the builder page). | | On Thu, Jun 5, 2014 at 8:35 AM, Simon Peyton Jones | wrote: | > | - 7.8.3 is looming, because we have a lot of bugfixes as I said | > | last | > | week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 | > | > Just to be clear, on that page: | > closed = done in 7.8.3 branch | > patch = will go in 7.8.3 branch | > new/infoneeded = will NOT go in 7.8.3 unless you yell loudly and | soon | > and argue for delay to get it in | > | > | - There's now a proper CI link for GHC on Trac so people don't lose | it. | > | The new builders are checking in regularly, so please watch out for | > | them | > | - and subscribe to ghc-builds at haskell.org if you haven't already. | > | > Where exactly is the link? (Ie not "what is the link" but where on | > Trac is it posted?) | > | > Simon | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Fri Jun 6 12:54:33 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Jun 2014 07:54:33 -0500 Subject: RFC: Phabricator for patches and code review In-Reply-To: <53918FD2.1070505@gmail.com> References: <53918FD2.1070505@gmail.com> Message-ID: I haven't looked deeply into Trac integration yet, but I believe this should generally be possible. I'll probably pester the developers about it later today. I'm glad people seem receptive to it. I don't think Arcanist will be a barrier, actually. Here's what I propose: we add arcanist and libphutil to the GHC repository as submodules (perhaps under ./utils), and just have a top level script to execute 'arc', e.g. './arc' just executes 'php ./utils/arcanist/bin/arc' or whatnot. Then any user can just checkout GHC and use the './arc' command to submit diffs - no install necessary, even on Windows. You'd just need PHP. This also has the advantage we'll generally want Arcanist to be in sync for all developers, and roughly in sync with the Phabricator server. As me and Herbert are admins anyway, keeping the submodule up to date once every week or two isn't a huge deal. On Fri, Jun 6, 2014 at 4:54 AM, Simon Marlow wrote: > tl;dir I strongly support this, but for code review only, and only if we can > integrate it well with Trac. > > Phabricator is what we use internally at Facebook, and it's a really good > code review tool (better than github, IMO). For one thing, you only get one > email for a complete review, rather than one email for each comment(!). The > UI is clean and streamlined, and reviewing diffs is a pleasure. > > If done right, this could improve our workflow a lot. If done wrong, it > could just make things more complex - we'd want to steer people away from > both github pull requests and attaching patches in Trac and towards > Phabricator instead. They have to install a local tool (arc), which could > be a barrier to contribution. > > We would need some integration between Phabricator and Trac. I don't know > whether any of this exists, but for example we'd want to have a way to link > to Trac tickets from Differential, and to have diffs automatically show up > attached to Trac tickets when they are linked to the ticket (by mentioning > the ticket in the commit message, for example). > > So I think this is a lot of work, but if someone were prepared to do it then > I think it could improve our lives. > > Cheers, > Simon > > > On 06/06/2014 05:05, Austin Seipp wrote: >> >> Hello all, >> >> Recently, while doing server maintenance, several of the >> administrators for Haskell.org set up an instance of Phabricator[1], >> located at https://phabricator.haskell.org >> >> For those who aren't aware, Phabricator (or "Phab") is a suite of >> tools for software development. Think of it like a polished, >> semi-private GitHub with a lot of applications and tools for all kinds >> of needs. We've been using it to do issue tracking for Haskell.org >> maintenance and like it a lot so far. >> >> One very nice aspect of Phabricator though is it has a very nice code >> review tool, called 'Differential', that is very useful. For people >> who have used a tool like Review Board, it's similar. Furthermore, it >> has a very convenient userland tool called 'Arcanist' which makes it >> easy for newcomers to post a review and get it merged when it's ready >> all from the command line. >> >> I'd like to see if people are interested in using Phab _strictly_ for >> code review of GHC patches. It is a dedicated tool specifically for >> this, and I think it works much better than Trac or inline GitHub >> comments. >> >> Also, Phab can also support post-commit reviews. So if I touch >> something in the runtime system and just push, perhaps Simon or Edward >> would like to look, and they can be alerted right when I do this, and >> then yell if I did something stupid. >> >> Before I go much further, I'd like to ask: is there *any* interest in >> this? Or are people satisifed with Trac? The primary motivations are >> roughly, in no particular order: >> >> 1) Code review is good for everyone, a good way for people to learn >> the code and ask questions, and useful to give feedback to newcomers. >> And even experienced GHC hackers can learn things from reading code, >> as we all do regularly, or find things that need cleanup. >> >> 2) Phabricator in particular makes it very easy to submit patches for >> review. To submit a patch, I just run the command 'arc diff' and it >> Does The Right Thing. It also makes it easy to ensure people are >> *alerted* when a patch might be relevant to them. >> >> 3) They can be uploaded and created from the command line, and merged >> easily afterwords the same way. This is particularly useful for >> newcomers, and for me. :) >> >> 4) Differential is dedicated to code review, and much better at it >> than just reading patches on Trac IMO. >> >> 5) It supports both post-commit code review, as well as pre-commit >> review. Post commit would be especially useful for us too, I think. >> >> Point #2 and #3 are mostly relevant for me, because I mostly handle >> incoming patches. But I think in general it would be nice, and make it >> a lot easier for newcomers to submit patches, and us to look over >> them. >> >> Here's an example of a Differential code review: >> >> https://phabricator.haskell.org/D4 >> >> This is a demo using my 'wip/ermsb' patch. You'll need to create an >> account to login, but it shouldn't be much trouble, you can login >> several ways. I'll fix the login requirement soon. Feel free to read >> the code, comment on it, and play around. It's more of a >> demonstration, but real code review would be welcome too. :) >> >> If people are interested in doing this, I can add notes to the wiki >> pages for newcomers, and I'll send another email about Phab so people >> can understand it a little better. But I want to ask first. >> >> There is an argument that our team is so small, code review has >> unnecessary burdens. But I think Phab could help a lot with tracking >> outside patches and getting good reviews for incoming patches, and >> it'll make it easier for newcomers. And experienced pros can probably >> learn a thing as well. >> >> Again, to be clear, I don't propose we migrate anything to Phabricator >> from, say, Trac. There's no real pressure to do so and it would be >> tons of work. I only propose we use it for code review, which is >> perfectly fine, and how other projects like LLVM do code review (they >> use Bugzilla). >> >> I also don't think the usage of Phabricator should be mandatory >> (unless we decide that later because we like it), but I would like to >> see people use it if possible. >> >> [1] http://phabricator.org >> > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Fri Jun 6 12:54:47 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Jun 2014 14:54:47 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1402059287.2928.2.camel@kirk> Hi, Am Freitag, den 06.06.2014, 12:37 +0000 schrieb Simon Peyton Jones: > I think that would be great. Absolutely: the earlier we can catch > regressions the better. > > Couldn?t we make it part of the continuous-integration builds > (Travis?) that various folk are running, eg. Joachim? Travis has a hard time limit that we are already hitting, so this road is blocked. I guess we should extend our own build infrastructure (e.g. the buildbots) to do that. Alternatively, the stackage people ? who already seem to rebuild stackage regularly for CI, might just include a build from a daily snapshot. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Fri Jun 6 12:59:36 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Jun 2014 07:59:36 -0500 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: No, at the moment Phabricator is not integrated with any testing functionality. It could be, but that would be a bit of work I think to integrate with GHC's ./validate process. It would be nice to have long-term, however, but I don't think it's necessary right now - I run ./validate before every push out anyway just in case. If you do need a machine to help run builds, a recommendation: sign up for AWS. A GHC build can be done in < 1hr on those machines, and an x1.xlarge for example would cost you about .28c USD to run for that period. It's less than optimal, but I'm not the only one who has resorted to this on less-than-adequate machines... Another recommendation is to make sure you've got the right build settings, which can have a pretty dramatic impact on build times. See here: https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking and also https://ghc.haskell.org/trac/ghc/wiki/Building/Using#HowtomakeGHCbuildquickly On Fri, Jun 6, 2014 at 3:13 AM, ?mer Sinan A?acan wrote: > 2014-06-06 7:05 GMT+03:00 Austin Seipp : >> 2) Phabricator in particular makes it very easy to submit patches for >> review. To submit a patch, I just run the command 'arc diff' and it >> Does The Right Thing. It also makes it easy to ensure people are >> *alerted* when a patch might be relevant to them. > > This sounds really good. I was thinking about sending an email about > this for a while now. I'm reading some parts of GHC and there are lots > of small patches I'd like to submit for reviews. Most of the time > these are <10 lines of changes. But trac makes everything so hard and > the interface is so horrible, I'm ending up not sending the patch. > Also, testing is a huge problem for me. I can't test GHC on my > laptop(which is my only development environment) because it takes > forever to finish. > > With something like Github and a CI server(Jenkins/Travis/whatever) > integrated to the Github repository that runs tests on pull request, > it would be super easy for new contributors to submit small patches. > > As far as I can understand(altough currently I can't see how to send a > patch) Phabricator helps sending pull requests/patches, but does it > help with testing too? > > --- > ?mer Sinan A?acan > http://osa1.net > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From juhpetersen at gmail.com Fri Jun 6 13:55:30 2014 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 6 Jun 2014 22:55:30 +0900 Subject: 7.8.3 release - please speak up soon. In-Reply-To: <20140605222730.1d2afaf1@sf> References: <871tv3l8wf.fsf@gergely.risko.hu> <20140605222730.1d2afaf1@sf> Message-ID: On 6 June 2014 04:27, Sergei Trofimovich wrote: > Can you write what problems are to ship those libraries in it's current > form? > Do you have some linking problems or something? > I suppose one could exclude the shared library from the separate distro packages of terminfo, haskeline and xhtml but that feels very weird and wrong, so the point remains: why not just ship the devel files with ghc too? :) Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Jun 6 14:09:43 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 6 Jun 2014 10:09:43 -0400 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: <8263007D-1C04-4D4C-BC79-99BDC388817E@cis.upenn.edu> Piggybacking a bit on ?mer's point: It is often the case that something flies by that I can fix in a few moments (for example, #9163) but that I have to defer until I have enough time for a GHC hacking session. Making even a tiny patch requires that I'm up-to-date, that my unchanged tree compiles (and, if I have time, validates!), and then, after the patch, that everything validates again. This generally means that I don't touch GHC unless I have 3+ hours *that day* to devote to GHC -- there are enough commits that I don't want things getting too stale if I can't validate the same day I update. Compounding the problem, my desire for efficiency leads me to accumulate GHC tasks, meaning that my time requirements become even worse, making it harder to get anything done. It sounds like, perhaps, Phab isn't the answer, but a way to create a lightweight, *untested* patch that doesn't require all of this would be simply wonderful. Experience has told me even to be scared of just adding comments without a validate! Is there such a facility now? How hard would it be to create one? Richard On Jun 6, 2014, at 8:59 AM, Austin Seipp wrote: > No, at the moment Phabricator is not integrated with any testing > functionality. It could be, but that would be a bit of work I think to > integrate with GHC's ./validate process. It would be nice to have > long-term, however, but I don't think it's necessary right now - I run > ./validate before every push out anyway just in case. > > If you do need a machine to help run builds, a recommendation: sign up > for AWS. A GHC build can be done in < 1hr on those machines, and an > x1.xlarge for example would cost you about .28c USD to run for that > period. It's less than optimal, but I'm not the only one who has > resorted to this on less-than-adequate machines... > > Another recommendation is to make sure you've got the right build > settings, which can have a pretty dramatic impact on build times. See > here: https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking and also > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#HowtomakeGHCbuildquickly > > On Fri, Jun 6, 2014 at 3:13 AM, ?mer Sinan A?acan wrote: >> 2014-06-06 7:05 GMT+03:00 Austin Seipp : >>> 2) Phabricator in particular makes it very easy to submit patches for >>> review. To submit a patch, I just run the command 'arc diff' and it >>> Does The Right Thing. It also makes it easy to ensure people are >>> *alerted* when a patch might be relevant to them. >> >> This sounds really good. I was thinking about sending an email about >> this for a while now. I'm reading some parts of GHC and there are lots >> of small patches I'd like to submit for reviews. Most of the time >> these are <10 lines of changes. But trac makes everything so hard and >> the interface is so horrible, I'm ending up not sending the patch. >> Also, testing is a huge problem for me. I can't test GHC on my >> laptop(which is my only development environment) because it takes >> forever to finish. >> >> With something like Github and a CI server(Jenkins/Travis/whatever) >> integrated to the Github repository that runs tests on pull request, >> it would be super easy for new contributors to submit small patches. >> >> As far as I can understand(altough currently I can't see how to send a >> patch) Phabricator helps sending pull requests/patches, but does it >> help with testing too? >> >> --- >> ?mer Sinan A?acan >> http://osa1.net >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From austin at well-typed.com Fri Jun 6 18:05:33 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Jun 2014 13:05:33 -0500 Subject: RFC: Phabricator for patches and code review In-Reply-To: <8263007D-1C04-4D4C-BC79-99BDC388817E@cis.upenn.edu> References: <8263007D-1C04-4D4C-BC79-99BDC388817E@cis.upenn.edu> Message-ID: Richard, I think Phabricator would suit this just fine. Here's (roughly) how Phabricator will work from a GHC hackers point of view. 1) I have a thing I want. Make a branch, hack hack hack away. $ git branch new-thing $ git checkout new-thing $ emacs .... $ git commit -a -m "Add minor new thing" 2) Use the CLI tool, Arcanist, to submit a diff: $ arc diff This uploads your changes on your branch to the web server. (The CLI interface will explain in detail what will happen.) Done. When you do #2, this will take the patch, upload it to Phabricator, and tie a lot of metadata to it. As an example, you can see D4, which I posted before: https://phabricator.haskell.org/D4 - Herbert and Carter for example commented before, and I've updated the review since then. After a review is on differential, we can review it, easily merge it if we think it's acceptable and test it - or just leave it alone until you're ready for us to review it later. Most importantly, things uploaded for code review can absolutely be work-in-progress, untested, and it's *easy* to do upload them. Just one command. I think that's just what you want. Just make a branch, and create a review on Differential. You can come back to it later, and in the mean time we can review it, track it, or even merge it ourselves if we have time. On Fri, Jun 6, 2014 at 9:09 AM, Richard Eisenberg wrote: > Piggybacking a bit on ?mer's point: > > It is often the case that something flies by that I can fix in a few moments (for example, #9163) but that I have to defer until I have enough time for a GHC hacking session. Making even a tiny patch requires that I'm up-to-date, that my unchanged tree compiles (and, if I have time, validates!), and then, after the patch, that everything validates again. This generally means that I don't touch GHC unless I have 3+ hours *that day* to devote to GHC -- there are enough commits that I don't want things getting too stale if I can't validate the same day I update. Compounding the problem, my desire for efficiency leads me to accumulate GHC tasks, meaning that my time requirements become even worse, making it harder to get anything done. > > It sounds like, perhaps, Phab isn't the answer, but a way to create a lightweight, *untested* patch that doesn't require all of this would be simply wonderful. Experience has told me even to be scared of just adding comments without a validate! > > Is there such a facility now? How hard would it be to create one? > > Richard > > On Jun 6, 2014, at 8:59 AM, Austin Seipp wrote: > >> No, at the moment Phabricator is not integrated with any testing >> functionality. It could be, but that would be a bit of work I think to >> integrate with GHC's ./validate process. It would be nice to have >> long-term, however, but I don't think it's necessary right now - I run >> ./validate before every push out anyway just in case. >> >> If you do need a machine to help run builds, a recommendation: sign up >> for AWS. A GHC build can be done in < 1hr on those machines, and an >> x1.xlarge for example would cost you about .28c USD to run for that >> period. It's less than optimal, but I'm not the only one who has >> resorted to this on less-than-adequate machines... >> >> Another recommendation is to make sure you've got the right build >> settings, which can have a pretty dramatic impact on build times. See >> here: https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking and also >> https://ghc.haskell.org/trac/ghc/wiki/Building/Using#HowtomakeGHCbuildquickly >> >> On Fri, Jun 6, 2014 at 3:13 AM, ?mer Sinan A?acan wrote: >>> 2014-06-06 7:05 GMT+03:00 Austin Seipp : >>>> 2) Phabricator in particular makes it very easy to submit patches for >>>> review. To submit a patch, I just run the command 'arc diff' and it >>>> Does The Right Thing. It also makes it easy to ensure people are >>>> *alerted* when a patch might be relevant to them. >>> >>> This sounds really good. I was thinking about sending an email about >>> this for a while now. I'm reading some parts of GHC and there are lots >>> of small patches I'd like to submit for reviews. Most of the time >>> these are <10 lines of changes. But trac makes everything so hard and >>> the interface is so horrible, I'm ending up not sending the patch. >>> Also, testing is a huge problem for me. I can't test GHC on my >>> laptop(which is my only development environment) because it takes >>> forever to finish. >>> >>> With something like Github and a CI server(Jenkins/Travis/whatever) >>> integrated to the Github repository that runs tests on pull request, >>> it would be super easy for new contributors to submit small patches. >>> >>> As far as I can understand(altough currently I can't see how to send a >>> patch) Phabricator helps sending pull requests/patches, but does it >>> help with testing too? >>> >>> --- >>> ?mer Sinan A?acan >>> http://osa1.net >>> >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From nicolas at incubaid.com Fri Jun 6 19:56:54 2014 From: nicolas at incubaid.com (Nicolas Trangez) Date: Fri, 6 Jun 2014 21:56:54 +0200 Subject: RFC: Phabricator for patches and code review In-Reply-To: References: Message-ID: I assume if the decission is made to use this, the read-only view won't require any login or registration? Nicolas On Jun 6, 2014 6:05 AM, "Austin Seipp" wrote: > Hello all, > > Recently, while doing server maintenance, several of the > administrators for Haskell.org set up an instance of Phabricator[1], > located at https://phabricator.haskell.org > > For those who aren't aware, Phabricator (or "Phab") is a suite of > tools for software development. Think of it like a polished, > semi-private GitHub with a lot of applications and tools for all kinds > of needs. We've been using it to do issue tracking for Haskell.org > maintenance and like it a lot so far. > > One very nice aspect of Phabricator though is it has a very nice code > review tool, called 'Differential', that is very useful. For people > who have used a tool like Review Board, it's similar. Furthermore, it > has a very convenient userland tool called 'Arcanist' which makes it > easy for newcomers to post a review and get it merged when it's ready > all from the command line. > > I'd like to see if people are interested in using Phab _strictly_ for > code review of GHC patches. It is a dedicated tool specifically for > this, and I think it works much better than Trac or inline GitHub > comments. > > Also, Phab can also support post-commit reviews. So if I touch > something in the runtime system and just push, perhaps Simon or Edward > would like to look, and they can be alerted right when I do this, and > then yell if I did something stupid. > > Before I go much further, I'd like to ask: is there *any* interest in > this? Or are people satisifed with Trac? The primary motivations are > roughly, in no particular order: > > 1) Code review is good for everyone, a good way for people to learn > the code and ask questions, and useful to give feedback to newcomers. > And even experienced GHC hackers can learn things from reading code, > as we all do regularly, or find things that need cleanup. > > 2) Phabricator in particular makes it very easy to submit patches for > review. To submit a patch, I just run the command 'arc diff' and it > Does The Right Thing. It also makes it easy to ensure people are > *alerted* when a patch might be relevant to them. > > 3) They can be uploaded and created from the command line, and merged > easily afterwords the same way. This is particularly useful for > newcomers, and for me. :) > > 4) Differential is dedicated to code review, and much better at it > than just reading patches on Trac IMO. > > 5) It supports both post-commit code review, as well as pre-commit > review. Post commit would be especially useful for us too, I think. > > Point #2 and #3 are mostly relevant for me, because I mostly handle > incoming patches. But I think in general it would be nice, and make it > a lot easier for newcomers to submit patches, and us to look over > them. > > Here's an example of a Differential code review: > > https://phabricator.haskell.org/D4 > > This is a demo using my 'wip/ermsb' patch. You'll need to create an > account to login, but it shouldn't be much trouble, you can login > several ways. I'll fix the login requirement soon. Feel free to read > the code, comment on it, and play around. It's more of a > demonstration, but real code review would be welcome too. :) > > If people are interested in doing this, I can add notes to the wiki > pages for newcomers, and I'll send another email about Phab so people > can understand it a little better. But I want to ask first. > > There is an argument that our team is so small, code review has > unnecessary burdens. But I think Phab could help a lot with tracking > outside patches and getting good reviews for incoming patches, and > it'll make it easier for newcomers. And experienced pros can probably > learn a thing as well. > > Again, to be clear, I don't propose we migrate anything to Phabricator > from, say, Trac. There's no real pressure to do so and it would be > tons of work. I only propose we use it for code review, which is > perfectly fine, and how other projects like LLVM do code review (they > use Bugzilla). > > I also don't think the usage of Phabricator should be mandatory > (unless we decide that later because we like it), but I would like to > see people use it if possible. > > [1] http://phabricator.org > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Fri Jun 6 22:17:41 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 07 Jun 2014 00:17:41 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <603234EA-24AA-4201-B4D7-D62491B949AD@orthanc.ca> Message-ID: <53923E05.7070904@fuuzetsu.co.uk> On 04/10/2014 12:12 AM, P?li G?bor J?nos wrote: > 2014-04-09 0:25 GMT+02:00 Lyndon Nerenberg : >> Is there any way to verify that builder-client can actually do a successful build, >> without having access to the build system server? 'builder-client --do-build' >> wants to connect and authenticate first; it would be helpful if there was a way >> to bypass that so that I can first verify the local build environment is sane. > > This is because the builder client gets the commands to be executed > from the server. A naive solution would be to put the commands in the > script and run it. > > You can find the current set of installed commands at one of the > active builders page, e.g. [1]. Note that you may have to change some > of them, such as the flags passed to configure script and name of the > make(1) command. > > [1] http://haskell.inf.elte.hu/builders/solaris-x86-head/23.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > Just to revive this thread a bit, I notice that the builds with failing test results are still marked as successful. Would it not be useful to indicate that there are failing tests somehow? It'd be a shame to have various test results from multiple machines but not use them. -- Mateusz K. From chak at cse.unsw.edu.au Sat Jun 7 05:21:39 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat, 7 Jun 2014 15:21:39 +1000 Subject: Phabricator for patches and code review In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: So, why not put everything on GutHub and use pull requests and so on? SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. Manuel Simon Peyton Jones : > At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. > > So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? > > Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. > > I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin > | Seipp > | Sent: 06 June 2014 05:06 > | To: ghc-devs at haskell.org > | Subject: RFC: Phabricator for patches and code review > | > | Hello all, > | > | Recently, while doing server maintenance, several of the administrators > | for Haskell.org set up an instance of Phabricator[1], located at > | https://phabricator.haskell.org > | > | For those who aren't aware, Phabricator (or "Phab") is a suite of tools > | for software development. Think of it like a polished, semi-private > | GitHub with a lot of applications and tools for all kinds of needs. > | We've been using it to do issue tracking for Haskell.org maintenance and > | like it a lot so far. > | > | One very nice aspect of Phabricator though is it has a very nice code > | review tool, called 'Differential', that is very useful. For people who > | have used a tool like Review Board, it's similar. Furthermore, it has a > | very convenient userland tool called 'Arcanist' which makes it easy for > | newcomers to post a review and get it merged when it's ready all from > | the command line. > | > | I'd like to see if people are interested in using Phab _strictly_ for > | code review of GHC patches. It is a dedicated tool specifically for > | this, and I think it works much better than Trac or inline GitHub > | comments. > | > | Also, Phab can also support post-commit reviews. So if I touch something > | in the runtime system and just push, perhaps Simon or Edward would like > | to look, and they can be alerted right when I do this, and then yell if > | I did something stupid. > | > | Before I go much further, I'd like to ask: is there *any* interest in > | this? Or are people satisifed with Trac? The primary motivations are > | roughly, in no particular order: > | > | 1) Code review is good for everyone, a good way for people to learn the > | code and ask questions, and useful to give feedback to newcomers. > | And even experienced GHC hackers can learn things from reading code, as > | we all do regularly, or find things that need cleanup. > | > | 2) Phabricator in particular makes it very easy to submit patches for > | review. To submit a patch, I just run the command 'arc diff' and it Does > | The Right Thing. It also makes it easy to ensure people are > | *alerted* when a patch might be relevant to them. > | > | 3) They can be uploaded and created from the command line, and merged > | easily afterwords the same way. This is particularly useful for > | newcomers, and for me. :) > | > | 4) Differential is dedicated to code review, and much better at it than > | just reading patches on Trac IMO. > | > | 5) It supports both post-commit code review, as well as pre-commit > | review. Post commit would be especially useful for us too, I think. > | > | Point #2 and #3 are mostly relevant for me, because I mostly handle > | incoming patches. But I think in general it would be nice, and make it a > | lot easier for newcomers to submit patches, and us to look over them. > | > | Here's an example of a Differential code review: > | > | https://phabricator.haskell.org/D4 > | > | This is a demo using my 'wip/ermsb' patch. You'll need to create an > | account to login, but it shouldn't be much trouble, you can login > | several ways. I'll fix the login requirement soon. Feel free to read the > | code, comment on it, and play around. It's more of a demonstration, but > | real code review would be welcome too. :) > | > | If people are interested in doing this, I can add notes to the wiki > | pages for newcomers, and I'll send another email about Phab so people > | can understand it a little better. But I want to ask first. > | > | There is an argument that our team is so small, code review has > | unnecessary burdens. But I think Phab could help a lot with tracking > | outside patches and getting good reviews for incoming patches, and it'll > | make it easier for newcomers. And experienced pros can probably learn a > | thing as well. > | > | Again, to be clear, I don't propose we migrate anything to Phabricator > | from, say, Trac. There's no real pressure to do so and it would be tons > | of work. I only propose we use it for code review, which is perfectly > | fine, and how other projects like LLVM do code review (they use > | Bugzilla). > | > | I also don't think the usage of Phabricator should be mandatory (unless > | we decide that later because we like it), but I would like to see people > | use it if possible. > | > | [1] http://phabricator.org > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From rarash at student.chalmers.se Sat Jun 7 07:18:48 2014 From: rarash at student.chalmers.se (Arash Rouhani) Date: Sat, 7 Jun 2014 09:18:48 +0200 Subject: Phabricator for patches and code review In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5392BCD8.1020306@student.chalmers.se> Could not have agreed more with Manuel. I would also like to point out that one of the missions of the arcanist tool is to support all version control systems. That have made sense for FaceBook Inc, who went from Subversion to Git to Mercurial. GHC team only use git now. I think the consequence is that the arcanist command line tool becomes quite weak*, for example I were not able to push a given gitrevision, you have to go through `arc diff` which only pushes the commit that HEAD is at. For sure github is the lead thing most everyone is using and already know how to use. As for side-by-side diffs on github, there is a browser extension for it. But yes, the Phabricator has a better review tool. :) Cheers, Arash * Based on my experience with it from my summer internship at FaceBook 2013. On 2014-06-07 07:21, Manuel M T Chakravarty wrote: > So, why not put everything on GutHub and use pull requests and so on? > > SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. > > So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. > > We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. > > Manuel > > Simon Peyton Jones : >> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. >> >> So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? >> >> Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. >> >> I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin >> | Seipp >> | Sent: 06 June 2014 05:06 >> | To: ghc-devs at haskell.org >> | Subject: RFC: Phabricator for patches and code review >> | >> | Hello all, >> | >> | Recently, while doing server maintenance, several of the administrators >> | for Haskell.org set up an instance of Phabricator[1], located at >> | https://phabricator.haskell.org >> | >> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >> | for software development. Think of it like a polished, semi-private >> | GitHub with a lot of applications and tools for all kinds of needs. >> | We've been using it to do issue tracking for Haskell.org maintenance and >> | like it a lot so far. >> | >> | One very nice aspect of Phabricator though is it has a very nice code >> | review tool, called 'Differential', that is very useful. For people who >> | have used a tool like Review Board, it's similar. Furthermore, it has a >> | very convenient userland tool called 'Arcanist' which makes it easy for >> | newcomers to post a review and get it merged when it's ready all from >> | the command line. >> | >> | I'd like to see if people are interested in using Phab _strictly_ for >> | code review of GHC patches. It is a dedicated tool specifically for >> | this, and I think it works much better than Trac or inline GitHub >> | comments. >> | >> | Also, Phab can also support post-commit reviews. So if I touch something >> | in the runtime system and just push, perhaps Simon or Edward would like >> | to look, and they can be alerted right when I do this, and then yell if >> | I did something stupid. >> | >> | Before I go much further, I'd like to ask: is there *any* interest in >> | this? Or are people satisifed with Trac? The primary motivations are >> | roughly, in no particular order: >> | >> | 1) Code review is good for everyone, a good way for people to learn the >> | code and ask questions, and useful to give feedback to newcomers. >> | And even experienced GHC hackers can learn things from reading code, as >> | we all do regularly, or find things that need cleanup. >> | >> | 2) Phabricator in particular makes it very easy to submit patches for >> | review. To submit a patch, I just run the command 'arc diff' and it Does >> | The Right Thing. It also makes it easy to ensure people are >> | *alerted* when a patch might be relevant to them. >> | >> | 3) They can be uploaded and created from the command line, and merged >> | easily afterwords the same way. This is particularly useful for >> | newcomers, and for me. :) >> | >> | 4) Differential is dedicated to code review, and much better at it than >> | just reading patches on Trac IMO. >> | >> | 5) It supports both post-commit code review, as well as pre-commit >> | review. Post commit would be especially useful for us too, I think. >> | >> | Point #2 and #3 are mostly relevant for me, because I mostly handle >> | incoming patches. But I think in general it would be nice, and make it a >> | lot easier for newcomers to submit patches, and us to look over them. >> | >> | Here's an example of a Differential code review: >> | >> | https://phabricator.haskell.org/D4 >> | >> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >> | account to login, but it shouldn't be much trouble, you can login >> | several ways. I'll fix the login requirement soon. Feel free to read the >> | code, comment on it, and play around. It's more of a demonstration, but >> | real code review would be welcome too. :) >> | >> | If people are interested in doing this, I can add notes to the wiki >> | pages for newcomers, and I'll send another email about Phab so people >> | can understand it a little better. But I want to ask first. >> | >> | There is an argument that our team is so small, code review has >> | unnecessary burdens. But I think Phab could help a lot with tracking >> | outside patches and getting good reviews for incoming patches, and it'll >> | make it easier for newcomers. And experienced pros can probably learn a >> | thing as well. >> | >> | Again, to be clear, I don't propose we migrate anything to Phabricator >> | from, say, Trac. There's no real pressure to do so and it would be tons >> | of work. I only propose we use it for code review, which is perfectly >> | fine, and how other projects like LLVM do code review (they use >> | Bugzilla). >> | >> | I also don't think the usage of Phabricator should be mandatory (unless >> | we decide that later because we like it), but I would like to see people >> | use it if possible. >> | >> | [1] http://phabricator.org >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From fuuzetsu at fuuzetsu.co.uk Sat Jun 7 07:20:06 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 07 Jun 2014 09:20:06 +0200 Subject: Phabricator for patches and code review In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5392BD26.2010506@fuuzetsu.co.uk> On 06/07/2014 07:21 AM, Manuel M T Chakravarty wrote: > So, why not put everything on GutHub and use pull requests and so on? > > SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. > > So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. > > We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. > > Manuel While I'm usually in favour of using GitHub for something due to the sheer amount of exposure to people with existing accounts, I have to say that there are few major deficiencies with it for this particular task: issue tracking is crap, you can do very little in ways of customisation, the TOS is pretty scary, labels are not sufficient enough for anything serious, it's very easy to miss comments on specific lines?. It's really not suited for medium/large scale issue tracking and code review. I do agree with you on the 3 disadvantages of using something like Phabricator (and I add an extra one that now a browser so for example you can't use it on X-less box although I'm not sure what the locally installed software does) but if people reading the patches (Austin, Herbert, anyone concerned at the moment) find it easier to do their job AND it becomes easier to ask for feedback then I think we should give it a go. As it stands, I'd rather use e-mail + few policies for code review &c rather than GitHub which is really not suited for this task. Big downside of e-mail/Trac for this is it's hard to give iterative feedback on changing parts of patches. > Simon Peyton Jones : >> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. >> >> So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? >> >> Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. >> >> I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin >> | Seipp >> | Sent: 06 June 2014 05:06 >> | To: ghc-devs at haskell.org >> | Subject: RFC: Phabricator for patches and code review >> | >> | Hello all, >> | >> | Recently, while doing server maintenance, several of the administrators >> | for Haskell.org set up an instance of Phabricator[1], located at >> | https://phabricator.haskell.org >> | >> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >> | for software development. Think of it like a polished, semi-private >> | GitHub with a lot of applications and tools for all kinds of needs. >> | We've been using it to do issue tracking for Haskell.org maintenance and >> | like it a lot so far. >> | >> | One very nice aspect of Phabricator though is it has a very nice code >> | review tool, called 'Differential', that is very useful. For people who >> | have used a tool like Review Board, it's similar. Furthermore, it has a >> | very convenient userland tool called 'Arcanist' which makes it easy for >> | newcomers to post a review and get it merged when it's ready all from >> | the command line. >> | >> | I'd like to see if people are interested in using Phab _strictly_ for >> | code review of GHC patches. It is a dedicated tool specifically for >> | this, and I think it works much better than Trac or inline GitHub >> | comments. >> | >> | Also, Phab can also support post-commit reviews. So if I touch something >> | in the runtime system and just push, perhaps Simon or Edward would like >> | to look, and they can be alerted right when I do this, and then yell if >> | I did something stupid. >> | >> | Before I go much further, I'd like to ask: is there *any* interest in >> | this? Or are people satisifed with Trac? The primary motivations are >> | roughly, in no particular order: >> | >> | 1) Code review is good for everyone, a good way for people to learn the >> | code and ask questions, and useful to give feedback to newcomers. >> | And even experienced GHC hackers can learn things from reading code, as >> | we all do regularly, or find things that need cleanup. >> | >> | 2) Phabricator in particular makes it very easy to submit patches for >> | review. To submit a patch, I just run the command 'arc diff' and it Does >> | The Right Thing. It also makes it easy to ensure people are >> | *alerted* when a patch might be relevant to them. >> | >> | 3) They can be uploaded and created from the command line, and merged >> | easily afterwords the same way. This is particularly useful for >> | newcomers, and for me. :) >> | >> | 4) Differential is dedicated to code review, and much better at it than >> | just reading patches on Trac IMO. >> | >> | 5) It supports both post-commit code review, as well as pre-commit >> | review. Post commit would be especially useful for us too, I think. >> | >> | Point #2 and #3 are mostly relevant for me, because I mostly handle >> | incoming patches. But I think in general it would be nice, and make it a >> | lot easier for newcomers to submit patches, and us to look over them. >> | >> | Here's an example of a Differential code review: >> | >> | https://phabricator.haskell.org/D4 >> | >> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >> | account to login, but it shouldn't be much trouble, you can login >> | several ways. I'll fix the login requirement soon. Feel free to read the >> | code, comment on it, and play around. It's more of a demonstration, but >> | real code review would be welcome too. :) >> | >> | If people are interested in doing this, I can add notes to the wiki >> | pages for newcomers, and I'll send another email about Phab so people >> | can understand it a little better. But I want to ask first. >> | >> | There is an argument that our team is so small, code review has >> | unnecessary burdens. But I think Phab could help a lot with tracking >> | outside patches and getting good reviews for incoming patches, and it'll >> | make it easier for newcomers. And experienced pros can probably learn a >> | thing as well. >> | >> | Again, to be clear, I don't propose we migrate anything to Phabricator >> | from, say, Trac. There's no real pressure to do so and it would be tons >> | of work. I only propose we use it for code review, which is perfectly >> | fine, and how other projects like LLVM do code review (they use >> | Bugzilla). >> | >> | I also don't think the usage of Phabricator should be mandatory (unless >> | we decide that later because we like it), but I would like to see people >> | use it if possible. >> | >> | [1] http://phabricator.org >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Mateusz K. From austin at well-typed.com Sat Jun 7 07:24:18 2014 From: austin at well-typed.com (Austin Seipp) Date: Sat, 7 Jun 2014 02:24:18 -0500 Subject: Phabricator for patches and code review In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This always gets brought up, but I (still) think there are several reasons to prefer our own infrastructure over GitHub: - Phab is far more flexible, especially for review. GitHub doesn't even have side-by-side diffs (a massive improvement), much less the suite of tools that make code review easy. I cannot set emails to notify me when someone touches something I am the owner of, for example, it's just blind emails all the time. This applies to incoming patches (pre-commit review), and changes merged to the tree (post-commit review). And both of these workflows are useful ones for GHC I think. - I also now think it is *easier* to submit changes for review with Phabricator having done it, because there is a simple command line utility to do so. This utility can easily be integrated into the GHC tree. It is also easier for me to manage patches, or for anyone to merge patches! It's just one more command. And the reality is that most commits need to be validated before we commit them. This has been the standard for a long time - GitHub's "automated workflows" don't accommodate this. I would rarely, if ever, hit the "merge button" on GitHub for GHC for example. You must run the tests for foreign patches you are incorporating - always. - I don't think maintenance is an issue. We've been using it for Haskell.org ticket tracking since we needed a replacement for some of our old infrastructure (including private support tickets which GitHub does not support), since we're consolidating it all. The admin team has about 3 people working on it (including me), and we've been doing upgrades, migrating things, automating them, and generally making the servers more redundant and simpler. - I think code review, in general, massively increases the 'shared knowledge' pool for developers, and a dedicated tool really, really helps. I can only point to my experience introducing dedicated tools multiple times in my career in the past as examples. Most people besides me don't really review patches unless I ask them to, and a good tool of pending things that can notify you if you might be interested is really useful. As for GitHub and Trac in general: - GitHub lacks several things we already use. For example, there is no way to add commit hooks to repositories that ban commits containing whitespace, trailing spaces, and other 'lint' errors. git.haskell.org automatically enforces this to help keep new code tab-free. GitHub has no alternative to this. - We also use this facility to keep submodules sane: as of today, git.haskell.org will not let you commit a 'dangling submodule reference' to ghc.git. You must push the corresponding submodule code first, so the top-level repository never breaks. This is also not possible with GitHub and has been a historical error source for developers. - Speaking of builds, any kind of integration with a CI system, at some level, is going to require custom infrastructure on our side, GitHub or not, so there's no clear advantage here. Travis-CI is simply not going to be long-term acceptable for GHC - we are within 5m or so of the build limit, and it only builds GHC with some conservative settings. Also Travis-CI does not allow custom infrastructure, like ARM buildbots, or multiple differently-versioned OS X buildbots. Gabor's nightly servers for example allow all of this. Joachim's builds are very useful though, but we need more. - Speaking of that, we need to maintain our own server so that Git pushes can interface with Trac, and the mailing notifier. - And then you might ask, well we could just migrate it all to GitHub. That's a _huge_ amount of work. GHC is probably one of the largest Trac installations around at nearly 10,000 tickets, a gigantic wiki, and tons of metadata and a *lot* of users. Preserving the necessary metadata, rewriting intra-wiki links, references, and preserving everything is just going to be a ton of work. GitHub doesn't even have an 'import' facility for example, just the raw API, so this would involve a lot of local processing to 'fix' everything. This includes moving labels, etc. I strictly shot down that idea, because it's time I don't think anyone wants to dedicate to it. Dropping all the data is out of the question. Trac is well understood at least and has many valuable aspects, and a migration should be considered a very, very serious matter after a lot more discussion. Phabricator would only be used for GHC code review. On Sat, Jun 7, 2014 at 12:21 AM, Manuel M T Chakravarty wrote: > So, why not put everything on GutHub and use pull requests and so on? > > SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. > > So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. > > We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. > > Manuel > > Simon Peyton Jones : >> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. >> >> So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? >> >> Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. >> >> I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin >> | Seipp >> | Sent: 06 June 2014 05:06 >> | To: ghc-devs at haskell.org >> | Subject: RFC: Phabricator for patches and code review >> | >> | Hello all, >> | >> | Recently, while doing server maintenance, several of the administrators >> | for Haskell.org set up an instance of Phabricator[1], located at >> | https://phabricator.haskell.org >> | >> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >> | for software development. Think of it like a polished, semi-private >> | GitHub with a lot of applications and tools for all kinds of needs. >> | We've been using it to do issue tracking for Haskell.org maintenance and >> | like it a lot so far. >> | >> | One very nice aspect of Phabricator though is it has a very nice code >> | review tool, called 'Differential', that is very useful. For people who >> | have used a tool like Review Board, it's similar. Furthermore, it has a >> | very convenient userland tool called 'Arcanist' which makes it easy for >> | newcomers to post a review and get it merged when it's ready all from >> | the command line. >> | >> | I'd like to see if people are interested in using Phab _strictly_ for >> | code review of GHC patches. It is a dedicated tool specifically for >> | this, and I think it works much better than Trac or inline GitHub >> | comments. >> | >> | Also, Phab can also support post-commit reviews. So if I touch something >> | in the runtime system and just push, perhaps Simon or Edward would like >> | to look, and they can be alerted right when I do this, and then yell if >> | I did something stupid. >> | >> | Before I go much further, I'd like to ask: is there *any* interest in >> | this? Or are people satisifed with Trac? The primary motivations are >> | roughly, in no particular order: >> | >> | 1) Code review is good for everyone, a good way for people to learn the >> | code and ask questions, and useful to give feedback to newcomers. >> | And even experienced GHC hackers can learn things from reading code, as >> | we all do regularly, or find things that need cleanup. >> | >> | 2) Phabricator in particular makes it very easy to submit patches for >> | review. To submit a patch, I just run the command 'arc diff' and it Does >> | The Right Thing. It also makes it easy to ensure people are >> | *alerted* when a patch might be relevant to them. >> | >> | 3) They can be uploaded and created from the command line, and merged >> | easily afterwords the same way. This is particularly useful for >> | newcomers, and for me. :) >> | >> | 4) Differential is dedicated to code review, and much better at it than >> | just reading patches on Trac IMO. >> | >> | 5) It supports both post-commit code review, as well as pre-commit >> | review. Post commit would be especially useful for us too, I think. >> | >> | Point #2 and #3 are mostly relevant for me, because I mostly handle >> | incoming patches. But I think in general it would be nice, and make it a >> | lot easier for newcomers to submit patches, and us to look over them. >> | >> | Here's an example of a Differential code review: >> | >> | https://phabricator.haskell.org/D4 >> | >> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >> | account to login, but it shouldn't be much trouble, you can login >> | several ways. I'll fix the login requirement soon. Feel free to read the >> | code, comment on it, and play around. It's more of a demonstration, but >> | real code review would be welcome too. :) >> | >> | If people are interested in doing this, I can add notes to the wiki >> | pages for newcomers, and I'll send another email about Phab so people >> | can understand it a little better. But I want to ask first. >> | >> | There is an argument that our team is so small, code review has >> | unnecessary burdens. But I think Phab could help a lot with tracking >> | outside patches and getting good reviews for incoming patches, and it'll >> | make it easier for newcomers. And experienced pros can probably learn a >> | thing as well. >> | >> | Again, to be clear, I don't propose we migrate anything to Phabricator >> | from, say, Trac. There's no real pressure to do so and it would be tons >> | of work. I only propose we use it for code review, which is perfectly >> | fine, and how other projects like LLVM do code review (they use >> | Bugzilla). >> | >> | I also don't think the usage of Phabricator should be mandatory (unless >> | we decide that later because we like it), but I would like to see people >> | use it if possible. >> | >> | [1] http://phabricator.org >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Sat Jun 7 07:28:45 2014 From: austin at well-typed.com (Austin Seipp) Date: Sat, 7 Jun 2014 02:28:45 -0500 Subject: Phabricator for patches and code review In-Reply-To: <5392BCD8.1020306@student.chalmers.se> References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> <5392BCD8.1020306@student.chalmers.se> Message-ID: I don't think Arcanist forces any particular workflow after working with it a bit. Generally, all you have to do is checkout a branch, make some commits on that branch, and run 'arc diff'. Make more commits on that branch, run 'arc diff' again. When it's ready I can merge it however I want. This workflow should be very sensible to most people, and it's easier than uploading diffs to Trac IMO. Phabricator will not host the repository. Existing committers will have the exact same access they always did. The only thing that would change is people submitting patches can use Phabricator instead of uploading diffs manually. In addition, existing committers can also use Phabricator's post-review tools to track commits they might find relevant after people author them. This is a very useful feature in my experience, and GitHub has no equivalent to this. On Sat, Jun 7, 2014 at 2:18 AM, Arash Rouhani wrote: > Could not have agreed more with Manuel. > > I would also like to point out that one of the missions of the arcanist tool > is to support all version control systems. That have made sense for FaceBook > Inc, who went from Subversion to Git to Mercurial. GHC team only use git > now. I think the consequence is that the arcanist command line tool becomes > quite weak*, for example I were not able to push a given gitrevision, you > have to go through `arc diff` which only pushes the commit that HEAD is at. > > For sure github is the lead thing most everyone is using and already know > how to use. As for side-by-side diffs on github, there is a browser > extension for it. But yes, the Phabricator has a better review tool. :) > > Cheers, > Arash > > * Based on my experience with it from my summer internship at FaceBook 2013. > > > > > On 2014-06-07 07:21, Manuel M T Chakravarty wrote: >> >> So, why not put everything on GutHub and use pull requests and so on? >> >> SimonM writes that Phabricator is better than GitHub. I?m happy to believe >> that, but he also writes that using it requires installing local software >> and quite a bit of work. Moreover, I like to add that lots of people already >> know how to use GitHub and probably few know Phabricator. >> >> So, we are talking about having a somewhat better tool in return for three >> very significant disadvantages: (1) local installation, (2) work to set up >> and maintain Phabricator, and (3) effort by many people to learn to use it. >> >> We also have a constant lack of sufficient men power. So, why spend effort >> on building our own infrastructure, which will only increase the hurdle for >> contributors (as they have to deal with an unknown system)? Let?s outsource >> the effort to GitHub. >> >> Manuel >> >> Simon Peyton Jones : >>> >>> At the moment GHC's main sources aren't on github, which means that that >>> (in my highly imperfect understanding) people can't submit pull requests or >>> use their code review mechanisms. Moreover, most people don't have commit >>> rights on the main GHC server, so if someone wants to offer a patch they can >>> really only do so in textual form attached to Trac. People with commit >>> rights can make a branch, but there's a danger that over a decade we'll >>> accumulate zillions of dead branches which people forgot to delete. I think >>> on github the branch is in a different repo, belonging to the patch author. >>> >>> So we really don't have a good work flow for creating, reviewing, >>> modifying, and finally apply patches. I am no expert on these matters. If >>> Phabricator would help with that I'm all for it. But perhaps there are >>> other alternatives? Or is Phab the lead thing. Will it stay around? >>> >>> Also before going too far I'd really like someone to document the >>> workflow carefully, and make sure it works from Windows equally well. >>> >>> I'm not too stressed out about losing the review trail of a patch. Much >>> of it will be commenting on stuff that no longer appears in the final patch. >>> Anything that's important should appear in a Note in the source code; even >>> the commit messages are invisible until you really start digging. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>> Austin >>> | Seipp >>> | Sent: 06 June 2014 05:06 >>> | To: ghc-devs at haskell.org >>> | Subject: RFC: Phabricator for patches and code review >>> | >>> | Hello all, >>> | >>> | Recently, while doing server maintenance, several of the administrators >>> | for Haskell.org set up an instance of Phabricator[1], located at >>> | https://phabricator.haskell.org >>> | >>> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >>> | for software development. Think of it like a polished, semi-private >>> | GitHub with a lot of applications and tools for all kinds of needs. >>> | We've been using it to do issue tracking for Haskell.org maintenance >>> and >>> | like it a lot so far. >>> | >>> | One very nice aspect of Phabricator though is it has a very nice code >>> | review tool, called 'Differential', that is very useful. For people who >>> | have used a tool like Review Board, it's similar. Furthermore, it has a >>> | very convenient userland tool called 'Arcanist' which makes it easy for >>> | newcomers to post a review and get it merged when it's ready all from >>> | the command line. >>> | >>> | I'd like to see if people are interested in using Phab _strictly_ for >>> | code review of GHC patches. It is a dedicated tool specifically for >>> | this, and I think it works much better than Trac or inline GitHub >>> | comments. >>> | >>> | Also, Phab can also support post-commit reviews. So if I touch >>> something >>> | in the runtime system and just push, perhaps Simon or Edward would like >>> | to look, and they can be alerted right when I do this, and then yell if >>> | I did something stupid. >>> | >>> | Before I go much further, I'd like to ask: is there *any* interest in >>> | this? Or are people satisifed with Trac? The primary motivations are >>> | roughly, in no particular order: >>> | >>> | 1) Code review is good for everyone, a good way for people to learn >>> the >>> | code and ask questions, and useful to give feedback to newcomers. >>> | And even experienced GHC hackers can learn things from reading code, as >>> | we all do regularly, or find things that need cleanup. >>> | >>> | 2) Phabricator in particular makes it very easy to submit patches for >>> | review. To submit a patch, I just run the command 'arc diff' and it >>> Does >>> | The Right Thing. It also makes it easy to ensure people are >>> | *alerted* when a patch might be relevant to them. >>> | >>> | 3) They can be uploaded and created from the command line, and merged >>> | easily afterwords the same way. This is particularly useful for >>> | newcomers, and for me. :) >>> | >>> | 4) Differential is dedicated to code review, and much better at it >>> than >>> | just reading patches on Trac IMO. >>> | >>> | 5) It supports both post-commit code review, as well as pre-commit >>> | review. Post commit would be especially useful for us too, I think. >>> | >>> | Point #2 and #3 are mostly relevant for me, because I mostly handle >>> | incoming patches. But I think in general it would be nice, and make it >>> a >>> | lot easier for newcomers to submit patches, and us to look over them. >>> | >>> | Here's an example of a Differential code review: >>> | >>> | https://phabricator.haskell.org/D4 >>> | >>> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >>> | account to login, but it shouldn't be much trouble, you can login >>> | several ways. I'll fix the login requirement soon. Feel free to read >>> the >>> | code, comment on it, and play around. It's more of a demonstration, but >>> | real code review would be welcome too. :) >>> | >>> | If people are interested in doing this, I can add notes to the wiki >>> | pages for newcomers, and I'll send another email about Phab so people >>> | can understand it a little better. But I want to ask first. >>> | >>> | There is an argument that our team is so small, code review has >>> | unnecessary burdens. But I think Phab could help a lot with tracking >>> | outside patches and getting good reviews for incoming patches, and >>> it'll >>> | make it easier for newcomers. And experienced pros can probably learn a >>> | thing as well. >>> | >>> | Again, to be clear, I don't propose we migrate anything to Phabricator >>> | from, say, Trac. There's no real pressure to do so and it would be tons >>> | of work. I only propose we use it for code review, which is perfectly >>> | fine, and how other projects like LLVM do code review (they use >>> | Bugzilla). >>> | >>> | I also don't think the usage of Phabricator should be mandatory (unless >>> | we decide that later because we like it), but I would like to see >>> people >>> | use it if possible. >>> | >>> | [1] http://phabricator.org >>> | >>> | -- >>> | Regards, >>> | >>> | Austin Seipp, Haskell Consultant >>> | Well-Typed LLP, http://www.well-typed.com/ >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From rarash at student.chalmers.se Sat Jun 7 08:17:43 2014 From: rarash at student.chalmers.se (Arash Rouhani) Date: Sat, 7 Jun 2014 10:17:43 +0200 Subject: Phabricator for patches and code review In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5392CAA7.1090008@student.chalmers.se> Well, I'm convinced now that you have researched this thoroughly. Thanks for doing so and addressing mine and Manuel's concerns. Cheers, Arash On 2014-06-07 09:24, Austin Seipp wrote: > This always gets brought up, but I (still) think there are several > reasons to prefer our own infrastructure over GitHub: > > - Phab is far more flexible, especially for review. GitHub doesn't > even have side-by-side diffs (a massive improvement), much less the > suite of tools that make code review easy. I cannot set emails to > notify me when someone touches something I am the owner of, for > example, it's just blind emails all the time. This applies to incoming > patches (pre-commit review), and changes merged to the tree > (post-commit review). And both of these workflows are useful ones for > GHC I think. > > - I also now think it is *easier* to submit changes for review with > Phabricator having done it, because there is a simple command line > utility to do so. This utility can easily be integrated into the GHC > tree. It is also easier for me to manage patches, or for anyone to > merge patches! It's just one more command. > > And the reality is that most commits need to be validated before we > commit them. This has been the standard for a long time - GitHub's > "automated workflows" don't accommodate this. I would rarely, if ever, > hit the "merge button" on GitHub for GHC for example. You must run the > tests for foreign patches you are incorporating - always. > > - I don't think maintenance is an issue. We've been using it for > Haskell.org ticket tracking since we needed a replacement for some of > our old infrastructure (including private support tickets which GitHub > does not support), since we're consolidating it all. The admin team > has about 3 people working on it (including me), and we've been doing > upgrades, migrating things, automating them, and generally making the > servers more redundant and simpler. > > - I think code review, in general, massively increases the 'shared > knowledge' pool for developers, and a dedicated tool really, really > helps. I can only point to my experience introducing dedicated tools > multiple times in my career in the past as examples. Most people > besides me don't really review patches unless I ask them to, and a > good tool of pending things that can notify you if you might be > interested is really useful. > > As for GitHub and Trac in general: > > - GitHub lacks several things we already use. For example, there is > no way to add commit hooks to repositories that ban commits containing > whitespace, trailing spaces, and other 'lint' errors. git.haskell.org > automatically enforces this to help keep new code tab-free. GitHub has > no alternative to this. > > - We also use this facility to keep submodules sane: as of today, > git.haskell.org will not let you commit a 'dangling submodule > reference' to ghc.git. You must push the corresponding submodule code > first, so the top-level repository never breaks. This is also not > possible with GitHub and has been a historical error source for > developers. > > - Speaking of builds, any kind of integration with a CI system, at > some level, is going to require custom infrastructure on our side, > GitHub or not, so there's no clear advantage here. Travis-CI is simply > not going to be long-term acceptable for GHC - we are within 5m or so > of the build limit, and it only builds GHC with some conservative > settings. Also Travis-CI does not allow custom infrastructure, like > ARM buildbots, or multiple differently-versioned OS X buildbots. > Gabor's nightly servers for example allow all of this. Joachim's > builds are very useful though, but we need more. > > - Speaking of that, we need to maintain our own server so that Git > pushes can interface with Trac, and the mailing notifier. > > - And then you might ask, well we could just migrate it all to > GitHub. That's a _huge_ amount of work. GHC is probably one of the > largest Trac installations around at nearly 10,000 tickets, a gigantic > wiki, and tons of metadata and a *lot* of users. Preserving the > necessary metadata, rewriting intra-wiki links, references, and > preserving everything is just going to be a ton of work. GitHub > doesn't even have an 'import' facility for example, just the raw API, > so this would involve a lot of local processing to 'fix' everything. > This includes moving labels, etc. > > I strictly shot down that idea, because it's time I don't think > anyone wants to dedicate to it. Dropping all the data is out of the > question. Trac is well understood at least and has many valuable > aspects, and a migration should be considered a very, very serious > matter after a lot more discussion. Phabricator would only be used for > GHC code review. > > On Sat, Jun 7, 2014 at 12:21 AM, Manuel M T Chakravarty > wrote: >> So, why not put everything on GutHub and use pull requests and so on? >> >> SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. >> >> So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. >> >> We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. >> >> Manuel >> >> Simon Peyton Jones : >>> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. >>> >>> So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? >>> >>> Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. >>> >>> I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin >>> | Seipp >>> | Sent: 06 June 2014 05:06 >>> | To: ghc-devs at haskell.org >>> | Subject: RFC: Phabricator for patches and code review >>> | >>> | Hello all, >>> | >>> | Recently, while doing server maintenance, several of the administrators >>> | for Haskell.org set up an instance of Phabricator[1], located at >>> | https://phabricator.haskell.org >>> | >>> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >>> | for software development. Think of it like a polished, semi-private >>> | GitHub with a lot of applications and tools for all kinds of needs. >>> | We've been using it to do issue tracking for Haskell.org maintenance and >>> | like it a lot so far. >>> | >>> | One very nice aspect of Phabricator though is it has a very nice code >>> | review tool, called 'Differential', that is very useful. For people who >>> | have used a tool like Review Board, it's similar. Furthermore, it has a >>> | very convenient userland tool called 'Arcanist' which makes it easy for >>> | newcomers to post a review and get it merged when it's ready all from >>> | the command line. >>> | >>> | I'd like to see if people are interested in using Phab _strictly_ for >>> | code review of GHC patches. It is a dedicated tool specifically for >>> | this, and I think it works much better than Trac or inline GitHub >>> | comments. >>> | >>> | Also, Phab can also support post-commit reviews. So if I touch something >>> | in the runtime system and just push, perhaps Simon or Edward would like >>> | to look, and they can be alerted right when I do this, and then yell if >>> | I did something stupid. >>> | >>> | Before I go much further, I'd like to ask: is there *any* interest in >>> | this? Or are people satisifed with Trac? The primary motivations are >>> | roughly, in no particular order: >>> | >>> | 1) Code review is good for everyone, a good way for people to learn the >>> | code and ask questions, and useful to give feedback to newcomers. >>> | And even experienced GHC hackers can learn things from reading code, as >>> | we all do regularly, or find things that need cleanup. >>> | >>> | 2) Phabricator in particular makes it very easy to submit patches for >>> | review. To submit a patch, I just run the command 'arc diff' and it Does >>> | The Right Thing. It also makes it easy to ensure people are >>> | *alerted* when a patch might be relevant to them. >>> | >>> | 3) They can be uploaded and created from the command line, and merged >>> | easily afterwords the same way. This is particularly useful for >>> | newcomers, and for me. :) >>> | >>> | 4) Differential is dedicated to code review, and much better at it than >>> | just reading patches on Trac IMO. >>> | >>> | 5) It supports both post-commit code review, as well as pre-commit >>> | review. Post commit would be especially useful for us too, I think. >>> | >>> | Point #2 and #3 are mostly relevant for me, because I mostly handle >>> | incoming patches. But I think in general it would be nice, and make it a >>> | lot easier for newcomers to submit patches, and us to look over them. >>> | >>> | Here's an example of a Differential code review: >>> | >>> | https://phabricator.haskell.org/D4 >>> | >>> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >>> | account to login, but it shouldn't be much trouble, you can login >>> | several ways. I'll fix the login requirement soon. Feel free to read the >>> | code, comment on it, and play around. It's more of a demonstration, but >>> | real code review would be welcome too. :) >>> | >>> | If people are interested in doing this, I can add notes to the wiki >>> | pages for newcomers, and I'll send another email about Phab so people >>> | can understand it a little better. But I want to ask first. >>> | >>> | There is an argument that our team is so small, code review has >>> | unnecessary burdens. But I think Phab could help a lot with tracking >>> | outside patches and getting good reviews for incoming patches, and it'll >>> | make it easier for newcomers. And experienced pros can probably learn a >>> | thing as well. >>> | >>> | Again, to be clear, I don't propose we migrate anything to Phabricator >>> | from, say, Trac. There's no real pressure to do so and it would be tons >>> | of work. I only propose we use it for code review, which is perfectly >>> | fine, and how other projects like LLVM do code review (they use >>> | Bugzilla). >>> | >>> | I also don't think the usage of Phabricator should be mandatory (unless >>> | we decide that later because we like it), but I would like to see people >>> | use it if possible. >>> | >>> | [1] http://phabricator.org >>> | >>> | -- >>> | Regards, >>> | >>> | Austin Seipp, Haskell Consultant >>> | Well-Typed LLP, http://www.well-typed.com/ >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > From pali.gabor at gmail.com Sat Jun 7 10:21:21 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Sat, 7 Jun 2014 12:21:21 +0200 Subject: Offering GHC builder build slaves In-Reply-To: <53923E05.7070904@fuuzetsu.co.uk> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <603234EA-24AA-4201-B4D7-D62491B949AD@orthanc.ca> <53923E05.7070904@fuuzetsu.co.uk> Message-ID: 2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk : > I notice that the builds with failing > test results are still marked as successful. Would it not be useful to > indicate that there are failing tests somehow? The result is based on the value that the invoked command returns. That is, for the testing phase, the "make test BINDIST=YES" command returned ExitSuccess, that is why it is marked green. > It'd be a shame to have > various test results from multiple machines but not use them. I see what you mean. But I would also feel strange to mark the test results failed if only a few of them fail. Note that the testsuite summaries are forwarded to the ghc-builds mailing list so they are published and archived. From mail at joachim-breitner.de Sat Jun 7 11:02:51 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 07 Jun 2014 13:02:51 +0200 Subject: Offering GHC builder build slaves In-Reply-To: References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> <1396945852.2514.17.camel@kirk> <603234EA-24AA-4201-B4D7-D62491B949AD@orthanc.ca> <53923E05.7070904@fuuzetsu.co.uk> Message-ID: <1402138971.3164.7.camel@kirk> Hi, Am Samstag, den 07.06.2014, 12:21 +0200 schrieb P?li G?bor J?nos: > 2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk : > > It'd be a shame to have > > various test results from multiple machines but not use them. > > I see what you mean. But I would also feel strange to mark the test > results failed if only a few of them fail. Note that the testsuite > summaries are forwarded to the ghc-builds mailing list so they are > published and archived. ideally, these would be collected in a meaningful way, so that one can see ?Commit 123 changed the number of failing tests from 2 to 3? or ?Test T1234 fails since 1.1.2014? or so. Ideally together with performance numbers (?This commit improved nofib by x%?) and nice graphs. It must be possible to collect and present such results that without reinventing the wheel, I just haven?t seen such a tool yet. (And I know that ?we should have X? mails are not very useful...) Greetings from Z?rich, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From gergely at risko.hu Sat Jun 7 11:58:49 2014 From: gergely at risko.hu (Gergely Risko) Date: Sat, 07 Jun 2014 13:58:49 +0200 Subject: 7.8.3 release - please speak up soon. References: <871tv3l8wf.fsf@gergely.risko.hu> <20140605222730.1d2afaf1@sf> Message-ID: <87sinh53t2.fsf@gergely.risko.hu> On Thu, 5 Jun 2014 22:27:30 +0300, Sergei Trofimovich writes: > Can you write what problems are to ship those libraries in it's current form? > Do you have some linking problems or something? > > Ticket does not describe any actual problems. Sorry for the two days of delay, I'm on Zurihac. I modified the ticket with a more verbose description of the issue, I hope it makes sense now. I also summarized two proposals on how to deal with this. Gergely From alfredo.dinapoli at gmail.com Sat Jun 7 15:38:56 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Sat, 7 Jun 2014 17:38:56 +0200 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <062.bce0005a8850aa18a86951d9858aa066@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> <062.bce0005a8850aa18a86951d9858aa066@haskell.org> Message-ID: <37B6AB85-760C-46E6-8112-20D83F3802F6@gmail.com> Thanks Fuuzetsu, Tomorrow I'll still be at the ZuriHac, so hopefully I'll able to adjust the patch :) I'll poke you if you'll be around Thanks! Alfredo Di Napoli > On 07/giu/2014, at 07:23, "GHC" wrote: > > #8226: Remove the old style -- # Haddock comments. > -------------------------------------+------------------------------------ > Reporter: Fuuzetsu | Owner: > Type: task | Status: patch > Priority: normal | Milestone: 7.10.1 > Component: Compiler | Version: 7.7 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: > -------------------------------------+------------------------------------ > > Comment (by Fuuzetsu): > > Sorry I fell behind a bit on reading GHC tickets. > > Yes adinapoli, those should also be removed, we do not use --# for > anything and it served the same purpose as {-# as far as I know. > > Also the data type used to store that type of comment should be removed: > > https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L625 > > FTR the Haddock ticket is now tracked at > https://github.com/haskell/haddock/issues/171 > > Thanks for looking into this, feel free to poke me on IRC/e-mail if you > need more immediate review. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler From mail at joachim-breitner.de Sat Jun 7 21:57:57 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 07 Jun 2014 23:57:57 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> Message-ID: <1402178277.30242.6.camel@kirk> Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: > If there was a daily snapshot build, I would be happy to set up some > kind of regular process to download that snapshot and do a Stackage > run on it. I'm currently blocked on this kind of activity, since I > can't get a successful GHC 7.8 build due to my system using the Gold > linker. That would be great, both for GHC and for people who want to have their packages work on GHC HEAD without manually monitoring it. There is http://deb.haskell.org/ which should produce daily debian packages for Debian wheezy. I guess if you are building on that platform, such packages are easiest to use (as you need no particular tooling to update and install). http://deb.haskell.org/dailies/latest/ is currently lagging due to temporary full disk, but I hope that by tomorrow, we have a new build. There used to be daily snapshot builds at http://darcs.haskell.org/ghcBuilder/uploads/ but that is defuct (Can someone remove the link from http://www.haskell.org/ghc/download). I wonder if the ?new? builder infrastructure at http://haskell.inf.elte.hu/builders/ assembles the snapshots somewhere, then you can use them. Or you can build GHC yourself as part of the stackage run. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fuuzetsu at fuuzetsu.co.uk Sat Jun 7 22:16:58 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 08 Jun 2014 00:16:58 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: <1402178277.30242.6.camel@kirk> References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> <1402178277.30242.6.camel@kirk> Message-ID: <53938F5A.3040204@fuuzetsu.co.uk> On 06/07/2014 11:57 PM, Joachim Breitner wrote: > Hi Michael, > > Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: > >> If there was a daily snapshot build, I would be happy to set up some >> kind of regular process to download that snapshot and do a Stackage >> run on it. I'm currently blocked on this kind of activity, since I >> can't get a successful GHC 7.8 build due to my system using the Gold >> linker. > > That would be great, both for GHC and for people who want to have their > packages work on GHC HEAD without manually monitoring it. > > There is http://deb.haskell.org/ which should produce daily debian > packages for Debian wheezy. I guess if you are building on that > platform, such packages are easiest to use (as you need no particular > tooling to update and install). http://deb.haskell.org/dailies/latest/ > is currently lagging due to temporary full disk, but I hope that by > tomorrow, we have a new build. > > There used to be daily snapshot builds at > http://darcs.haskell.org/ghcBuilder/uploads/ > but that is defuct (Can someone remove the link from > http://www.haskell.org/ghc/download). I wonder if the ?new? builder > infrastructure at http://haskell.inf.elte.hu/builders/ assembles the > snapshots somewhere, then you can use them. Some builders such as upload snapshots but I don't know how it's decided which. See [1] for example of such build. I think Pali makes the call. > Or you can build GHC yourself as part of the stackage run. > > Greetings, > Joachim > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > [1]: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/282.html -- Mateusz K. From marlowsd at gmail.com Sun Jun 8 07:32:34 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 08 Jun 2014 09:32:34 +0200 Subject: Phabricator for patches and code review In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D8AEF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53941192.8080208@gmail.com> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > So, why not put everything on GutHub and use pull requests and so on? github just isn't great for doing code reviews. No side-by-side diffs, and it sends you a separate email for every single comment, there's no concept of a "review" consisting of multiple inline comments (unless I've missed something). I'm afraid if we were using this for regular reviews I would have to disable the email notifications, which makes it significantly less useful. > SimonM writes that Phabricator is better than GitHub. I?m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. > > So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. Well, you've tipped the balance with "somewhat" and "significant" here, I'd say Phabricator is "significantly" better than github for code reviews, while installing arc is "somewhat" annoying :-) I have to admit it's not a no-brainer, but I do worry that github just wouldn't cut it for doing a lot of code reviewing, whereas I spend my life inside Phabricator so I know it works really well. What's more, github doesn't let you put animated gifs in code reviews. Need I say more? Cheers, Simon > > We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let?s outsource the effort to GitHub. > > Manuel > > Simon Peyton Jones : >> At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. >> >> So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? >> >> Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. >> >> I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin >> | Seipp >> | Sent: 06 June 2014 05:06 >> | To: ghc-devs at haskell.org >> | Subject: RFC: Phabricator for patches and code review >> | >> | Hello all, >> | >> | Recently, while doing server maintenance, several of the administrators >> | for Haskell.org set up an instance of Phabricator[1], located at >> | https://phabricator.haskell.org >> | >> | For those who aren't aware, Phabricator (or "Phab") is a suite of tools >> | for software development. Think of it like a polished, semi-private >> | GitHub with a lot of applications and tools for all kinds of needs. >> | We've been using it to do issue tracking for Haskell.org maintenance and >> | like it a lot so far. >> | >> | One very nice aspect of Phabricator though is it has a very nice code >> | review tool, called 'Differential', that is very useful. For people who >> | have used a tool like Review Board, it's similar. Furthermore, it has a >> | very convenient userland tool called 'Arcanist' which makes it easy for >> | newcomers to post a review and get it merged when it's ready all from >> | the command line. >> | >> | I'd like to see if people are interested in using Phab _strictly_ for >> | code review of GHC patches. It is a dedicated tool specifically for >> | this, and I think it works much better than Trac or inline GitHub >> | comments. >> | >> | Also, Phab can also support post-commit reviews. So if I touch something >> | in the runtime system and just push, perhaps Simon or Edward would like >> | to look, and they can be alerted right when I do this, and then yell if >> | I did something stupid. >> | >> | Before I go much further, I'd like to ask: is there *any* interest in >> | this? Or are people satisifed with Trac? The primary motivations are >> | roughly, in no particular order: >> | >> | 1) Code review is good for everyone, a good way for people to learn the >> | code and ask questions, and useful to give feedback to newcomers. >> | And even experienced GHC hackers can learn things from reading code, as >> | we all do regularly, or find things that need cleanup. >> | >> | 2) Phabricator in particular makes it very easy to submit patches for >> | review. To submit a patch, I just run the command 'arc diff' and it Does >> | The Right Thing. It also makes it easy to ensure people are >> | *alerted* when a patch might be relevant to them. >> | >> | 3) They can be uploaded and created from the command line, and merged >> | easily afterwords the same way. This is particularly useful for >> | newcomers, and for me. :) >> | >> | 4) Differential is dedicated to code review, and much better at it than >> | just reading patches on Trac IMO. >> | >> | 5) It supports both post-commit code review, as well as pre-commit >> | review. Post commit would be especially useful for us too, I think. >> | >> | Point #2 and #3 are mostly relevant for me, because I mostly handle >> | incoming patches. But I think in general it would be nice, and make it a >> | lot easier for newcomers to submit patches, and us to look over them. >> | >> | Here's an example of a Differential code review: >> | >> | https://phabricator.haskell.org/D4 >> | >> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >> | account to login, but it shouldn't be much trouble, you can login >> | several ways. I'll fix the login requirement soon. Feel free to read the >> | code, comment on it, and play around. It's more of a demonstration, but >> | real code review would be welcome too. :) >> | >> | If people are interested in doing this, I can add notes to the wiki >> | pages for newcomers, and I'll send another email about Phab so people >> | can understand it a little better. But I want to ask first. >> | >> | There is an argument that our team is so small, code review has >> | unnecessary burdens. But I think Phab could help a lot with tracking >> | outside patches and getting good reviews for incoming patches, and it'll >> | make it easier for newcomers. And experienced pros can probably learn a >> | thing as well. >> | >> | Again, to be clear, I don't propose we migrate anything to Phabricator >> | from, say, Trac. There's no real pressure to do so and it would be tons >> | of work. I only propose we use it for code review, which is perfectly >> | fine, and how other projects like LLVM do code review (they use >> | Bugzilla). >> | >> | I also don't think the usage of Phabricator should be mandatory (unless >> | we decide that later because we like it), but I would like to see people >> | use it if possible. >> | >> | [1] http://phabricator.org >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From mail at joachim-breitner.de Sun Jun 8 08:00:46 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 08 Jun 2014 10:00:46 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> <1402178277.30242.6.camel@kirk> Message-ID: <1402214446.2330.3.camel@kirk> Hi, Am Sonntag, den 08.06.2014, 07:55 +0300 schrieb Michael Snoyman: > > Actually, GHC HEAD isn't the problem I'm running into right now. I'm > already testing that[1] using Herbert's Ubuntu PPA[2] Ah, cool! > I'm specifically looking for builds off of the 7.8 branch so I can > start testing point releases. Then I guess the easiest would be if Herbert would add that to his PPA. > [2] And in case anyone's curious, restrictive upper bounds on > transformers and template-haskell are preventing a build right now. Hmm, it would be nice if cabal had a ?best effort? mode where when some of the requested packages cannot be built it at least builds the rest. Also, isn?t there a new flag to cabal to selectively ignore upper bounds? (I can?t find the documentation for the latest cabal-install online right now.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Sun Jun 8 08:07:46 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sun, 08 Jun 2014 10:07:46 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: <1402214446.2330.3.camel@kirk> (Joachim Breitner's message of "Sun, 08 Jun 2014 10:00:46 +0200") References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> <1402178277.30242.6.camel@kirk> <1402214446.2330.3.camel@kirk> Message-ID: <87ioobsu25.fsf@gmail.com> On 2014-06-08 at 10:00:46 +0200, Joachim Breitner wrote: [...] >> I'm specifically looking for builds off of the 7.8 branch so I can >> start testing point releases. > > Then I guess the easiest would be if Herbert would add that to his > PPA. Fwiw, there have been already 'ghc-7.8.3' packages in the PPA for about a week, which are snapshots of the upcoming 7.8.3 release (i.e. they correspond to the current ghc-7.8 Git branch). >> [2] And in case anyone's curious, restrictive upper bounds on >> transformers and template-haskell are preventing a build right now. > > > Hmm, it would be nice if cabal had a ?best effort? mode where when some > of the requested packages cannot be built it at least builds the rest. > > Also, isn?t there a new flag to cabal to selectively ignore upper > bounds? (I can?t find the documentation for the latest cabal-install > online right now.) You mean this one: | --allow-newer[=PKGS] Ignore upper bounds in dependencies on some | or all packages. From marlowsd at gmail.com Sun Jun 8 08:30:26 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 08 Jun 2014 10:30:26 +0200 Subject: [PATCH] Fix -unawareness of large-addresses on mingw (#8520) In-Reply-To: <538ED5A8.60301@mail.ru> References: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> <538EC984.2010706@gmail.com> <538ED5A8.60301@mail.ru> Message-ID: <53941F22.7020706@gmail.com> If someone validates this on Windows it could go in. Add it to #8520 and put the ticket in the patch state? On 04/06/2014 10:15, kyra wrote: > LARGEADDRESSAWARE flag if set in executable's header tells the OS that > the application can handle addresses larger than 2GB. > > For 32-bit executables it is disabled usually. To enable it we must tell > linker to enable it or manually edit an executable - for example, > peflags of editbin (from Microsoft) utilities could be used. > > Cheers, > Kyra > > On 6/4/2014 11:23, Simon Marlow wrote: >> I don't know what this does, and there doesn't seem to be any info in >> #8520 either. >> >> Could you add the patch to the ticket, and help us out by saying why >> this fixes the problem (and if possible, explain why it won't break >> anything else)? >> >> On 03/06/2014 07:06, transfuturist wrote: >>> --- >>> compiler/main/SysTools.lhs | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs >>> index dc9642d..1cf1155 100644 >>> --- a/compiler/main/SysTools.lhs >>> +++ b/compiler/main/SysTools.lhs >>> @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do >>> [ -- Reduce ld memory usage >>> "-Wl,--hash-size=31" >>> , "-Wl,--reduce-memory-overheads" >>> + , "-Wl,--large-address-aware" --Trac #8520 >>> -- Increase default stack, see >>> -- Note [Windows stack usage] >>> , "-Xlinker", "--stack=0x800000,0x800000" ] >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From kyrab at mail.ru Sun Jun 8 09:23:36 2014 From: kyrab at mail.ru (kyra) Date: Sun, 08 Jun 2014 13:23:36 +0400 Subject: [PATCH] Fix -unawareness of large-addresses on mingw (#8520) In-Reply-To: <53941F22.7020706@gmail.com> References: <1401775579-12636-1-git-send-email-timothy.schmid@gmail.com> <538EC984.2010706@gmail.com> <538ED5A8.60301@mail.ru> <53941F22.7020706@gmail.com> Message-ID: <53942B98.6050009@mail.ru> There is a problem here. While setting LARGEADDRESSAWARE apparently works for GHC *itself*, we can't be sure it works for any GHC-generated executable because it can potentially be linked with some *foreign* code which is not LARGEADDRESSAWARE compatible (see https://ghc.haskell.org/trac/ghc/ticket/8520#comment:6). So, perhaps, we should not apply this patch, but only set this flag for GHC *itself*. After all it's possible to feed GHC with something like '-optl-Xlinker -optl--large-address-aware' to set this flag on the particular executable if necessary. Cheers, Kyra On 6/8/2014 12:30, Simon Marlow wrote: > If someone validates this on Windows it could go in. Add it to #8520 > and put the ticket in the patch state? > > On 04/06/2014 10:15, kyra wrote: >> LARGEADDRESSAWARE flag if set in executable's header tells the OS that >> the application can handle addresses larger than 2GB. >> >> For 32-bit executables it is disabled usually. To enable it we must tell >> linker to enable it or manually edit an executable - for example, >> peflags of editbin (from Microsoft) utilities could be used. >> >> Cheers, >> Kyra >> >> On 6/4/2014 11:23, Simon Marlow wrote: >>> I don't know what this does, and there doesn't seem to be any info in >>> #8520 either. >>> >>> Could you add the patch to the ticket, and help us out by saying why >>> this fixes the problem (and if possible, explain why it won't break >>> anything else)? >>> >>> On 03/06/2014 07:06, transfuturist wrote: >>>> --- >>>> compiler/main/SysTools.lhs | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs >>>> index dc9642d..1cf1155 100644 >>>> --- a/compiler/main/SysTools.lhs >>>> +++ b/compiler/main/SysTools.lhs >>>> @@ -740,6 +740,7 @@ getLinkerInfo' dflags = do >>>> [ -- Reduce ld memory usage >>>> "-Wl,--hash-size=31" >>>> , "-Wl,--reduce-memory-overheads" >>>> + , "-Wl,--large-address-aware" --Trac #8520 >>>> -- Increase default stack, see >>>> -- Note [Windows stack usage] >>>> , "-Xlinker", "--stack=0x800000,0x800000" ] >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From johan.tibell at gmail.com Mon Jun 9 11:16:51 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 9 Jun 2014 13:16:51 +0200 Subject: Adding atomic primops In-Reply-To: References: <1399199455-sup-5590@sabre> <5371FD1E.4040600@gmail.com> Message-ID: I now have a working implementation: https://phabricator.haskell.org/D12 The code that's generated is pretty good, except for 1-2 extra moves that I think are due to the thing being a CallishMachOp: https://gist.github.com/tibbe/02e6dfdb5a63a9793651 The remaining TODO is to get things working in the LLVM codegen. It should be difficult (we just need to output the corresponding LLVM intrinsics), but I'm very familiar with that code. On Tue, May 20, 2014 at 6:12 PM, Ryan Newton wrote: > Yes, that's exactly what I'd like to see as well. Also, we must confess > that most worldwide GHC cycles are currently spent on x86. Arm will surely > become more important over time. But what's right for x86 is probably > right for us for the near/medium term. > > > > > On Tue, May 20, 2014 at 11:04 AM, Johan Tibell > wrote: > >> Sequentially consistent also corresponds to, according to the LLVM docs: >> "the C++0x/C1x memory_order_seq_cst, Java volatile, and the gcc-compatible >> __sync_* builtins", so we'll be in good company. >> >> >> On Tue, May 20, 2014 at 5:01 PM, Johan Tibell >> wrote: >> >>> After some discussion with Simon, I will go ahead and try to implement >>> fully sequentially consistent versions of these primops. We can add other >>> versions that take the consistency model as an argument later, if needed. >>> >>> >>> On Thu, May 15, 2014 at 9:03 PM, Carter Schonwald < >>> carter.schonwald at gmail.com> wrote: >>> >>>> Hey Johan, >>>> on https://ghc.haskell.org/trac/ghc/ticket/7883 Ryan helped articulate >>>> what he'd want wrt memory ordering semantics. >>>> >>>> One point is that It might be totally valid and reasonable to provide >>>> *both* variants, though if we only were to do one, the strong ordering >>>> guarantees might be a better default, albeit your use case and others does >>>> benefit from using the weakest / simplest primops possible, >>>> >>>> >>>> On Thu, May 15, 2014 at 6:01 AM, Johan Tibell >>>> wrote: >>>> >>>>> I will update the wiki page (and later CmmSink) with the guarantees we >>>>> expect CallishMachOps to provide. We do need to pick what kind of guarantee >>>>> we want to provide. Options are here: >>>>> http://en.cppreference.com/w/cpp/atomic/memory_order >>>>> >>>>> Do we want to have these CallishMachOps to imply a full memory fence >>>>> CPU instruction or some more relaxed ordering (e.g. only atomicity)? >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Jun 9 18:00:24 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 9 Jun 2014 20:00:24 +0200 Subject: Adding atomic primops In-Reply-To: References: <1399199455-sup-5590@sabre> <5371FD1E.4040600@gmail.com> Message-ID: The code review was moved to https://phabricator.haskell.org/D15 On Mon, Jun 9, 2014 at 1:16 PM, Johan Tibell wrote: > I now have a working implementation: https://phabricator.haskell.org/D12 > > The code that's generated is pretty good, except for 1-2 extra moves that > I think are due to the thing being a CallishMachOp: > https://gist.github.com/tibbe/02e6dfdb5a63a9793651 > > The remaining TODO is to get things working in the LLVM codegen. It should > be difficult (we just need to output the corresponding LLVM intrinsics), > but I'm very familiar with that code. > > > On Tue, May 20, 2014 at 6:12 PM, Ryan Newton wrote: > >> Yes, that's exactly what I'd like to see as well. Also, we must confess >> that most worldwide GHC cycles are currently spent on x86. Arm will surely >> become more important over time. But what's right for x86 is probably >> right for us for the near/medium term. >> >> >> >> >> On Tue, May 20, 2014 at 11:04 AM, Johan Tibell >> wrote: >> >>> Sequentially consistent also corresponds to, according to the LLVM docs: >>> "the C++0x/C1x memory_order_seq_cst, Java volatile, and the gcc-compatible >>> __sync_* builtins", so we'll be in good company. >>> >>> >>> On Tue, May 20, 2014 at 5:01 PM, Johan Tibell >>> wrote: >>> >>>> After some discussion with Simon, I will go ahead and try to implement >>>> fully sequentially consistent versions of these primops. We can add other >>>> versions that take the consistency model as an argument later, if needed. >>>> >>>> >>>> On Thu, May 15, 2014 at 9:03 PM, Carter Schonwald < >>>> carter.schonwald at gmail.com> wrote: >>>> >>>>> Hey Johan, >>>>> on https://ghc.haskell.org/trac/ghc/ticket/7883 Ryan helped >>>>> articulate what he'd want wrt memory ordering semantics. >>>>> >>>>> One point is that It might be totally valid and reasonable to provide >>>>> *both* variants, though if we only were to do one, the strong ordering >>>>> guarantees might be a better default, albeit your use case and others does >>>>> benefit from using the weakest / simplest primops possible, >>>>> >>>>> >>>>> On Thu, May 15, 2014 at 6:01 AM, Johan Tibell >>>>> wrote: >>>>> >>>>>> I will update the wiki page (and later CmmSink) with the guarantees >>>>>> we expect CallishMachOps to provide. We do need to pick what kind of >>>>>> guarantee we want to provide. Options are here: >>>>>> http://en.cppreference.com/w/cpp/atomic/memory_order >>>>>> >>>>>> Do we want to have these CallishMachOps to imply a full memory fence >>>>>> CPU instruction or some more relaxed ordering (e.g. only atomicity)? >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Jun 9 19:45:27 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Jun 2014 21:45:27 +0200 Subject: Failed to load interface for GHC.Integer.Type Message-ID: <1402343127.14642.10.camel@kirk> Hi, since http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 travis is complaining: HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o Top level: Failed to load interface for ???GHC.Integer.Type??? There are files missing in the ???integer-gmp??? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Does anyone have an idea what may be causing this? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From slyich at gmail.com Mon Jun 9 20:56:37 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Mon, 9 Jun 2014 23:56:37 +0300 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <1402343127.14642.10.camel@kirk> References: <1402343127.14642.10.camel@kirk> Message-ID: <20140609235637.2292eb17@sf> On Mon, 09 Jun 2014 21:45:27 +0200 Joachim Breitner wrote: > Hi, > > since > http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 travis is complaining: > > > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o > > Top level: > Failed to load interface for ???GHC.Integer.Type??? > There are files missing in the ???integer-gmp??? package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > Does anyone have an idea what may be causing this? A bit more context here is haddock started too early: Writing utils/haddock/doc/haddock/invoking.html for chapter(invoking) cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a HC [stage 1] libraries/base/dist-install/build/GHC/IO.o-boot HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o Writing utils/haddock/doc/haddock/ch03s02.html for section Writing utils/haddock/doc/haddock/ch03s03.html for section HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o Writing utils/haddock/doc/haddock/ch03s04.html for section Writing utils/haddock/doc/haddock/ch03s05.html for section Writing utils/haddock/doc/haddock/hyperlinking.html for section(hyperlinking) Writing utils/haddock/doc/haddock/module-attributes.html for section(module-attributes) HC [stage 1] libraries/base/dist-install/build/GHC/Exception.o-boot HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o Writing utils/haddock/doc/haddock/ch03s08.html for section Writing utils/haddock/doc/haddock/markup.html for chapter(markup) HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o Top level: Failed to load interface for ?GHC.Integer.Type? There are files missing in the ?integer-gmp? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] ... I guess real fault is: http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Jun 9 21:44:56 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Jun 2014 23:44:56 +0200 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <20140609235637.2292eb17@sf> References: <1402343127.14642.10.camel@kirk> <20140609235637.2292eb17@sf> Message-ID: <1402350296.14642.34.camel@kirk> Hi, Am Montag, den 09.06.2014, 23:56 +0300 schrieb Sergei Trofimovich: > I guess real fault is: > http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc I don?t think so, reverting my patch fixed it again. Given that I as able to build with the patch from an unclean tree, I conclude that there is a build ordering problem, i.e. something else (in integer-gmp?) needs to build before Data.Coerce. But that is just an guess. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From slyich at gmail.com Mon Jun 9 22:08:29 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Tue, 10 Jun 2014 01:08:29 +0300 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <20140609235637.2292eb17@sf> References: <1402343127.14642.10.camel@kirk> <20140609235637.2292eb17@sf> Message-ID: <20140610010829.606fac09@sf> On Mon, 9 Jun 2014 23:56:37 +0300 Sergei Trofimovich wrote: > On Mon, 09 Jun 2014 21:45:27 +0200 > Joachim Breitner wrote: > > > Hi, > > > > since > > http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 travis is complaining: > > > > > > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o > > > > Top level: > > Failed to load interface for ???GHC.Integer.Type??? > > There are files missing in the ???integer-gmp??? package, > > try running 'ghc-pkg check'. > > Use -v to see a list of the files searched for. > > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > Does anyone have an idea what may be causing this? > > A bit more context here is haddock started too early: > > Writing utils/haddock/doc/haddock/invoking.html for chapter(invoking) > cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a > HC [stage 1] libraries/base/dist-install/build/GHC/IO.o-boot > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o > Writing utils/haddock/doc/haddock/ch03s02.html for section > Writing utils/haddock/doc/haddock/ch03s03.html for section > HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o > Writing utils/haddock/doc/haddock/ch03s04.html for section > Writing utils/haddock/doc/haddock/ch03s05.html for section > Writing utils/haddock/doc/haddock/hyperlinking.html for section(hyperlinking) > Writing utils/haddock/doc/haddock/module-attributes.html for section(module-attributes) > HC [stage 1] libraries/base/dist-install/build/GHC/Exception.o-boot > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o > Writing utils/haddock/doc/haddock/ch03s08.html for section > Writing utils/haddock/doc/haddock/markup.html for chapter(markup) > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > > Top level: > Failed to load interface for ?GHC.Integer.Type? > There are files missing in the ?integer-gmp? package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] ... > > I guess real fault is: > http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc Or not. Looks like it's easy to reproduce as: $ make libraries/base/dist-install/build/Data/Coerce.o V=1 What is more interesting: ghc/libraries/base/Unsafe/Coerce.hs: > import GHC.Integer () -- for build ordering Attached patch fixes the error, but I have no idea why. Maybe, NoImplicitPrelude is not enough and some types leak in here? Maybe Ian (CCed) remembers the story. > commit aba043a0a142ef0ee66ed0e6cbfe2a39c65d8792 > Author: Ian Lynagh > Date: Sun May 19 16:35:40 2013 +0100 > > Fix build order when building with integer-simple > > The problem hasn't shown up with integer-gmp, but I can't see > why it couldn't happen in that case too. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Data-Coerce.hs-add-GHC.Integer-as-a-depend-to-coerce.patch Type: text/x-patch Size: 1202 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From simonpj at microsoft.com Mon Jun 9 22:16:26 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Jun 2014 22:16:26 +0000 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <1402343127.14642.10.camel@kirk> References: <1402343127.14642.10.camel@kirk> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DB508@DB3PRD3001MB020.064d.mgd.msft.net> I'm guessing that it may be the fact that the type-class defaulting rules involve Integer. You added NoImplicitPrelude, which removed a dependency on Prelude. Maybe defaulting is looking for the type Integer, but the build system doesn't see any dependency on the module that declares the Integer data type. Try adding default () Or alternatively (and perhaps easier) import GHC.Base (), which in turn depends on GHC.Integer. To be honest Data.Coerce is so trivial that I don't know why it needs Integer, but I bet that fixes it Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim | Breitner | Sent: 09 June 2014 20:45 | To: ghc-devs at haskell.org | Subject: Failed to load interface for GHC.Integer.Type | | Hi, | | since | http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd | 6501abd98 travis is complaining: | | | HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot | HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o | HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o | | Top level: | Failed to load interface for ???GHC.Integer.Type??? | There are files missing in the ???integer-gmp??? package, | try running 'ghc-pkg check'. | Use -v to see a list of the files searched for. | make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 | make[1]: *** Waiting for unfinished jobs.... | make: *** [all] Error 2 | | Does anyone have an idea what may be causing this? | | Greetings, | Joachim | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org From simonpj at microsoft.com Mon Jun 9 22:26:47 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Jun 2014 22:26:47 +0000 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DB508@DB3PRD3001MB020.064d.mgd.msft.net> References: <1402343127.14642.10.camel@kirk> <618BE556AADD624C9C918AA5D5911BEF103DB508@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DB570@DB3PRD3001MB020.064d.mgd.msft.net> Ah. The reason that Data.Coerce looks for the interface for GHC.Integer.Type is because TidyPgm expands integer literals using 'mkInteger' from that module, and TidyPgm always does the lookup regardless just in case. There's a hack to switch this off for packages ghc-prim and integer-gmp/simple, but every other compilation will read that interface. That's why anyway Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Peyton Jones | Sent: 09 June 2014 23:16 | To: Joachim Breitner; ghc-devs at haskell.org | Subject: RE: Failed to load interface for GHC.Integer.Type | | I'm guessing that it may be the fact that the type-class defaulting rules | involve Integer. You added NoImplicitPrelude, which removed a dependency | on Prelude. Maybe defaulting is looking for the type Integer, but the | build system doesn't see any dependency on the module that declares the | Integer data type. | | Try adding | default () | | Or alternatively (and perhaps easier) import GHC.Base (), which in turn | depends on GHC.Integer. | | To be honest Data.Coerce is so trivial that I don't know why it needs | Integer, but I bet that fixes it | | Simon | | | -----Original Message----- | | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim | | Breitner | | Sent: 09 June 2014 20:45 | | To: ghc-devs at haskell.org | | Subject: Failed to load interface for GHC.Integer.Type | | | | Hi, | | | | since | | | http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd | | 6501abd98 travis is complaining: | | | | | | HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot | | HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o | | HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o | | | | Top level: | | Failed to load interface for ???GHC.Integer.Type??? | | There are files missing in the ???integer-gmp??? package, | | try running 'ghc-pkg check'. | | Use -v to see a list of the files searched for. | | make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 | | make[1]: *** Waiting for unfinished jobs.... | | make: *** [all] Error 2 | | | | Does anyone have an idea what may be causing this? | | | | Greetings, | | Joachim | | | | -- | | Joachim ?nomeata? Breitner | | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | | Debian Developer: nomeata at debian.org | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From komadori at gekkou.co.uk Mon Jun 9 23:46:28 2014 From: komadori at gekkou.co.uk (Robin KAY) Date: Tue, 10 Jun 2014 00:46:28 +0100 Subject: GHC MinGW distribution Message-ID: <53964754.6000408@gekkou.co.uk> Dear All, I wanted to enquire about the prospects for updating the version of MinGW which ships with the Windows binary distribution of GHC. The version included as of 7.8.2 is now several years old and in some cases I've found that it's incompatible with the libraries produced by newer versions of MinGW (as to be expected, per my understanding). Specifically, my HsQML binding for Qt can't be used with the libraries from the official Windows binary distribution of Qt 5 because the resulting executables crash on start-up with runtime incompatibilities. I'm in the process of trying to build out-of-the-box compatible Qt binaries against GHC's MinGW, but Qt's stated minimum requirements on the tool-chain version aren't encouraging. The only way I currently have of making this work is for users to edit their GHC settings file to point GHC at a version of gcc.exe from a newer MinGW (such as the one which ships with Qt). The fact that this seems to work is encouraging, but it's still a bit of a difficult process to put people through. I know that Windows developers are in short supply, so I would like to offer what assistance I can in making this happen. There appear to be copies of MinGW stored in the GHC repository at http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use these automatically or are they just there for reference? Thanks, -- Robin KAY From kyrab at mail.ru Tue Jun 10 05:48:13 2014 From: kyrab at mail.ru (kyra) Date: Tue, 10 Jun 2014 09:48:13 +0400 Subject: GHC MinGW distribution In-Reply-To: <53964754.6000408@gekkou.co.uk> References: <53964754.6000408@gekkou.co.uk> Message-ID: <53969C1D.9070407@mail.ru> On 6/10/2014 03:46, Robin KAY wrote: > Dear All, > > I wanted to enquire about the prospects for updating the version of > MinGW which ships with the Windows binary distribution of GHC. The > version included as of 7.8.2 is now several years old and in some > cases I've found that it's incompatible with the libraries produced by > newer versions of MinGW (as to be expected, per my understanding). > > Specifically, my HsQML binding for Qt can't be used with the libraries > from the official Windows binary distribution of Qt 5 because the > resulting executables crash on start-up with runtime > incompatibilities. I'm in the process of trying to build > out-of-the-box compatible Qt binaries against GHC's MinGW, but Qt's > stated minimum requirements on the tool-chain version aren't > encouraging. The only way I currently have of making this work is for > users to edit their GHC settings file to point GHC at a version of > gcc.exe from a newer MinGW (such as the one which ships with Qt). The > fact that this seems to work is encouraging, but it's still a bit of a > difficult process to put people through. > > I know that Windows developers are in short supply, so I would like to > offer what assistance I can in making this happen. There appear to be > copies of MinGW stored in the GHC repository at > http://git.haskell.org/ghc-tarballs.git/tree . Does the build system > use these automatically or are they just there for reference? > > Thanks, > My experience is as follows: 1. 64-bit GHC uses mingw-w64 runtime/toolchain. Mingw-64 runtime and binutils may be upgraded to the most recent versions and gcc may be upgraded to versions up to 4.8.x. Gcc 4.9 is incompatible with GHC's runtime linker now. Btw, did anybody try GHC + gcc 4.9 on linux? 2. 32-bit GHC uses mingw runtime/toolchain. I didn't try to upgrade it for a long time but I think it shall succeed too (latest mingw gcc is 4.8.1). Btw, mingw runtime/toolchain development is stalled and it lags behind mingw-w64 *considerably*. It is possible to use 32-bit mingw-w64 runtime/toolchain with GHC, but it requires some patches to be made. I have such a patchset ready and can provide it if GHC HQ decide to switch 32-bit GHC distribution to mingw-w64 runtime/toolchain. It is also important using mingw-w64 opens the door to *plenty* of prebuilt packages available through Msys2 project, see http://sourceforge.net/projects/msys2/files/REPOS/MINGW. Cheers, Kyra From mail at joachim-breitner.de Tue Jun 10 07:26:51 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 10 Jun 2014 09:26:51 +0200 Subject: Failed to load interface for GHC.Integer.Type In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DB508@DB3PRD3001MB020.064d.mgd.msft.net> References: <1402343127.14642.10.camel@kirk> <618BE556AADD624C9C918AA5D5911BEF103DB508@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1402385211.10986.1.camel@kirk> Hi, Am Montag, den 09.06.2014, 22:16 +0000 schrieb Simon Peyton Jones: > I'm guessing that it may be the fact that the type-class defaulting > rules involve Integer. You added NoImplicitPrelude, which removed a > dependency on Prelude. Maybe defaulting is looking for the type > Integer, but the build system doesn't see any dependency on the module > that declares the Integer data type. > > Try adding > default () that didn?t help (for me). > Or alternatively (and perhaps easier) import GHC.Base (), which in > turn depends on GHC.Integer. That seems to work. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Jun 10 08:25:46 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Jun 2014 08:25:46 +0000 Subject: GHC MinGW distribution In-Reply-To: <53964754.6000408@gekkou.co.uk> References: <53964754.6000408@gekkou.co.uk> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> Robin We would be thrilled if you would help. We physically include very selective chunks of MinGW in a GHC Windows distribution - so that users don't need to install MinGW - so that GHC doesn't break just because a user has a different version of MinGW than we expected We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) precisely so that we know exactly which bits to ship. The intention is that the MinGW bits shipped with GHC are essentially invisible to the user. They just see a ghc.exe, which just happens internally to call some Mingw binaries. But as you point out, it's not quite invisible if the GHC-compiled stuff has to be compatible in some way with stuff compiled some other way. One route is to use GHC as your C compiler (which will in turn invoke the private MinGW binary), but that probably won't work; I have learned that things are Never Simple. Moreover, it would be great to update the MinGW bits to a more modern version. If you can do this, fantastic. What you need to do, I think, is - look at what is in ghc-tarballs - pull out selected bits of the new MinGW and use them to replace what's in ghc-tarballs - test thoroughly I'm sure that others will be happy to help. Do keep ghc-devs posted. You could make a ticket and post information to it as you learn about it. Or even a wiki page to describe the process, so that in four years time when someone wants to do the same thing, they have a guide. Speaking of which, do search the Trac Wiki in case someone *has* already docuemented some aspects of this. I would really like to have a Windows Strike Force who collectively take responsibility for the Windows port of GHC, if you and some others felt able to be part of such a thing. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Robin | KAY | Sent: 10 June 2014 00:46 | To: ghc-devs at haskell.org | Subject: GHC MinGW distribution | | Dear All, | | I wanted to enquire about the prospects for updating the version of | MinGW which ships with the Windows binary distribution of GHC. The | version included as of 7.8.2 is now several years old and in some cases | I've found that it's incompatible with the libraries produced by newer | versions of MinGW (as to be expected, per my understanding). | | Specifically, my HsQML binding for Qt can't be used with the libraries | from the official Windows binary distribution of Qt 5 because the | resulting executables crash on start-up with runtime incompatibilities. | I'm in the process of trying to build out-of-the-box compatible Qt | binaries against GHC's MinGW, but Qt's stated minimum requirements on | the tool-chain version aren't encouraging. The only way I currently have | of making this work is for users to edit their GHC settings file to | point GHC at a version of gcc.exe from a newer MinGW (such as the one | which ships with Qt). The fact that this seems to work is encouraging, | but it's still a bit of a difficult process to put people through. | | I know that Windows developers are in short supply, so I would like to | offer what assistance I can in making this happen. There appear to be | copies of MinGW stored in the GHC repository at | http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use | these automatically or are they just there for reference? | | Thanks, | | -- | Robin KAY | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From hvriedel at gmail.com Tue Jun 10 08:42:49 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 10 Jun 2014 10:42:49 +0200 Subject: GHC MinGW distribution In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Tue, 10 Jun 2014 08:25:46 +0000") References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87lht52m0m.fsf@gmail.com> Hello Simon, On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: [...] > We physically include very selective chunks of MinGW in a GHC Windows distribution > - so that users don't need to install MinGW > - so that GHC doesn't break just because a user has > a different version of MinGW than we expected > We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) > precisely so that we know exactly which bits to ship. Btw, there's just one thing I'm worried about with keeping those large MinGW binary tarballs in a Git repo: The Git repo will grow monotonically with each new compressed .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect shared bitstreams. So effectively each MiB of binary-data added will effectively grow the Git repo everyone will have to clone (even if only the latest MinGW for a specific 32/64-bit platform is desired) by that same amount. Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. Can't we simply put the tarballs in a plain HTTP folder on http://ghc.haskell.org, and store a list (or rather a shell script) of URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? Cheers, hvr From alexander at plaimi.net Tue Jun 10 09:37:51 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 10 Jun 2014 11:37:51 +0200 Subject: GHC MinGW distribution In-Reply-To: <87lht52m0m.fsf@gmail.com> References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> <87lht52m0m.fsf@gmail.com> Message-ID: <5396D1EF.5010608@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/06/14 10:42, Herbert Valerio Riedel wrote: > Btw, there's just one thing I'm worried about with keeping those > large MinGW binary tarballs in a Git repo: > > The Git repo will grow monotonically with each new compressed > .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to > detect shared bitstreams. So effectively each MiB of binary-data > added will effectively grow the Git repo everyone will have to > clone (even if only the latest MinGW for a specific 32/64-bit > platform is desired) by that same amount. > > Right now, cloning the ghc-tarballs.git repo requires to fetch > ~130MiB. > > Can't we simply put the tarballs in a plain HTTP folder on > http://ghc.haskell.org, and store a list (or rather a shell script) > of URLs+checksums in ghc.git to retrieve the tarballs if needed on > demand? I agree with this. Having binaries in git is really dirty for several reasons. It would be cleaner to retrieve src and build it through the build system. But I suspect Windows people don't commonly do this(?), so checking for the binaries, and if they're not found, downloading them (or asking the user to fix their paths) would likely suffice. The binaries should in any event not be in git... And as hvr points out, tarballs are a mess by themselves regardless of whether they contain binaries or source, because git (rightly) thinks they are blobs. Apologies for any assumptions made in this email that don't hold true - -- I do not use Windows. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOW0e8ACgkQRtClrXBQc7WzFAD9Fcz+Ur80Dh2wCqrZxGYEABEC QetdlxKC49nCPfLRfwwA/0e4PdVDv6+af7eeHFmUKXf5nDjxPx8ex3i+PpWC/xgL =tE6K -----END PGP SIGNATURE----- From hvr at gnu.org Tue Jun 10 11:17:24 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 10 Jun 2014 13:17:24 +0200 Subject: [commit: ghc] ghc-7.8: Release notes (32b4bf3) In-Reply-To: <20140609160820.54A132406D@ghc.haskell.org> (git-4Dsf34iY's message of "Mon, 9 Jun 2014 16:08:20 +0000 (UTC)") References: <20140609160820.54A132406D@ghc.haskell.org> Message-ID: <87bnu12euz.fsf@gnu.org> On 2014-06-09 at 18:08:20 +0200, git-4Dsf34iY/NkouOHNgZ69ag at public.gmane.org wrote: [...] > + > + > + The libraries haskeline, > + xhtml, terminfo, > + transformers, and > + haskeline are now exported and > + registered in the package database. They previously > + shipped with GHC but were not registered, leading to > + errors where shared objects could be overwritten. (issue > + #8919). > + > + Just a minor nit-pick: Afaik, 'transformers' *was* properly exported & registered in 7.8.[12]. It just wasn't mentioned in the release notes for 7.8.[12] IIRC. From ptrommler at me.com Tue Jun 10 11:29:58 2014 From: ptrommler at me.com (Peter Trommler) Date: Tue, 10 Jun 2014 13:29:58 +0200 Subject: ghc 7.8.2: Reachable modules from DynFlags out of date Message-ID: <7F9B1FE5-44B6-42FC-B150-76123453AE12@me.com> Hi, Preparing ghc for the upcoming Haskell Platform 2014.2 on openSUSE I came across the following issue on PowerPC 64 bit: > [ 6023s] inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" > [ 6025s] Reachable modules from DynFlags out of date > [ 6025s] Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) > [ 6025s] Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream > [ 6025s] make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 My build.mk contains the following: > GhcUnregisterised=YES > GhcWithNativeCodeGen=NO > GhcWithInterpreter=NO > SplitObjs=NO > SRC_HC_OPTS+= -optc-mminimal-toc -optc-fno-builtin > SRC_CC_OPTS+= -mminimal-toc -fno-builtin I need the last two lines to: 1. have the build get that far (something is overflowing the TOC on powerpc64) 2. to get rid of loads of gcc warnings about built-in mem* functions What do I need to do to ?fix compiler/ghc.mk? (see line 3 of my build log excerpt)? Thanks! Peter From metaniklas at gmail.com Tue Jun 10 11:30:57 2014 From: metaniklas at gmail.com (Niklas Larsson) Date: Tue, 10 Jun 2014 13:30:57 +0200 Subject: SV: GHC MinGW distribution Message-ID: <5396eca0.499f700a.514d.570e@mx.google.com> I think this is a great idea, I was thinking of creating a ticket for it after 7.8.3 was out of the way. In my case the reason is C++11 support, LLVM has 4.7 as the minimum version now. Just having a script in git and downloading the tarballs sounds very sensible. Speaking of LLVM, how about making it (optionally?) download an llvm tarball too? Niklas ----- Ursprungligt meddelande ----- Fr?n: "Robin KAY" Skickat: ?2014-?06-?10 01:46 Till: "ghc-devs at haskell.org" ?mne: GHC MinGW distribution Dear All, I wanted to enquire about the prospects for updating the version of MinGW which ships with the Windows binary distribution of GHC. The version included as of 7.8.2 is now several years old and in some cases I've found that it's incompatible with the libraries produced by newer versions of MinGW (as to be expected, per my understanding). Specifically, my HsQML binding for Qt can't be used with the libraries from the official Windows binary distribution of Qt 5 because the resulting executables crash on start-up with runtime incompatibilities. I'm in the process of trying to build out-of-the-box compatible Qt binaries against GHC's MinGW, but Qt's stated minimum requirements on the tool-chain version aren't encouraging. The only way I currently have of making this work is for users to edit their GHC settings file to point GHC at a version of gcc.exe from a newer MinGW (such as the one which ships with Qt). The fact that this seems to work is encouraging, but it's still a bit of a difficult process to put people through. I know that Windows developers are in short supply, so I would like to offer what assistance I can in making this happen. There appear to be copies of MinGW stored in the GHC repository at http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use these automatically or are they just there for reference? Thanks, -- Robin KAY _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Tue Jun 10 11:55:10 2014 From: ggreif at gmail.com (Gabor Greif) Date: Tue, 10 Jun 2014 13:55:10 +0200 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) Message-ID: Devs, as of recently GHC HEAD stopped building the diagrams library. Several prerequisite libs also fail to compile. A specific error message appears in an attoparsec issue , for which I have submitted a workaround. But as Herbert cautiously points out, this could be a recent GHC bug surfacing. The symptoms of the bug seem to be that GHC complains about the usage of (~) type equality operation, but there is no reference to that type operator in the source code. To work around the problem it suffices to add -XGADTs or -XTypeFamilies. Does this ring any bells? Can automatized tests catch such things in the future? Cheers, Gabor From mail at joachim-breitner.de Tue Jun 10 14:19:51 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 10 Jun 2014 16:19:51 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> <1402178277.30242.6.camel@kirk> <1402214446.2330.3.camel@kirk> <87ioobsu25.fsf@gmail.com> Message-ID: <1402409991.3136.15.camel@kirk> Hi, Am Sonntag, den 08.06.2014, 21:25 +0300 schrieb Michael Snoyman: > That's great news, thanks! I'll try to get a test going with that. Another benefit of this would be that it is more likely that $ cabal install criterion --with-compiler=.../ghc/inplace/bin/ghc-stage2 works, which would be very handy when developing on GHC head (currently it fails to compile attoparsec, as reported by Gabor). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From rwbarton at gmail.com Tue Jun 10 14:53:54 2014 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 10 Jun 2014 10:53:54 -0400 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: References: Message-ID: I expect this is a result of https://ghc.haskell.org/trac/ghc/ticket/8883, but even so it's not clear to me whether the error is correct. It would be nice if GHC printed the type it inferred for succ' in this kind of situation. Regards, Reid Barton On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif wrote: > Devs, > > as of recently GHC HEAD stopped building the diagrams library. Several > prerequisite libs also fail to compile. A specific error message > appears in an attoparsec issue > , for which I have > submitted a workaround. But as Herbert cautiously points out, this > could be a recent GHC bug surfacing. > > The symptoms of the bug seem to be that GHC complains about the usage > of (~) type equality operation, but there is no reference to that type > operator in the source code. To work around the problem it suffices to > add -XGADTs or -XTypeFamilies. > > Does this ring any bells? Can automatized tests catch such things in the > future? > > Cheers, > > Gabor > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jun 10 15:02:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Jun 2014 15:02:17 +0000 Subject: GHC MinGW distribution In-Reply-To: <87lht52m0m.fsf@gmail.com> References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> <87lht52m0m.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DC90A@DB3PRD3001MB020.064d.mgd.msft.net> | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? Personally I'm fine with that, if someone feels able to implement it (and document in the wiki:Repositories page). But remember that I'm not very au fait with all the issues so I defer to others Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 10 June 2014 09:43 | To: Simon Peyton Jones | Cc: Robin KAY; ghc-devs at haskell.org | Subject: Re: GHC MinGW distribution | | Hello Simon, | | On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: | | [...] | | > We physically include very selective chunks of MinGW in a GHC Windows | distribution | > - so that users don't need to install MinGW | > - so that GHC doesn't break just because a user has | > a different version of MinGW than we expected | > We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) | > precisely so that we know exactly which bits to ship. | | Btw, there's just one thing I'm worried about with keeping those large | MinGW binary tarballs in a Git repo: | | The Git repo will grow monotonically with each new compressed | .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect | shared bitstreams. So effectively each MiB of binary-data added will | effectively grow the Git repo everyone will have to clone (even if only | the latest MinGW for a specific 32/64-bit platform is desired) by that | same amount. | | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? | | Cheers, | hvr From simonpj at microsoft.com Tue Jun 10 15:02:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Jun 2014 15:02:59 +0000 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DC935@DB3PRD3001MB020.064d.mgd.msft.net> I suspect that the issue is the following: GHC is inferring a type for a function that could not be written by the user, at least not without -XTypeFamilies or -XGADTs, something like f :: (a ~ F b) => blah blah It's a good principle that if GHC infers a type, then it should be ok to put that type in manually. But that means that you need -XTypeFamilies even for the inferred type. So unless I'm misunderstanding the issue, it's not a bug but a feature. It is a change, certainly, and one that makes GHC a bit more picky. Can you update diagrams to include type signatures or -XGADTs/TypeFamilies? Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 10 June 2014 12:55 | To: ghc-devs | Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) | | Devs, | | as of recently GHC HEAD stopped building the diagrams library. Several | prerequisite libs also fail to compile. A specific error message | appears in an attoparsec issue | , for which I have | submitted a workaround. But as Herbert cautiously points out, this | could be a recent GHC bug surfacing. | | The symptoms of the bug seem to be that GHC complains about the usage | of (~) type equality operation, but there is no reference to that type | operator in the source code. To work around the problem it suffices to | add -XGADTs or -XTypeFamilies. | | Does this ring any bells? Can automatized tests catch such things in the | future? | | Cheers, | | Gabor | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue Jun 10 16:16:02 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 10 Jun 2014 18:16:02 +0200 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: References: Message-ID: <201406101816.02374.jan.stolarek@p.lodz.pl> Reid is correct. This is a result of fixing #8883. I agree that printing the inferred signature sounds like a good idea. Janek Dnia wtorek, 10 czerwca 2014, Reid Barton napisa?: > I expect this is a result of https://ghc.haskell.org/trac/ghc/ticket/8883, > but even so it's not clear to me whether the error is correct. It would be > nice if GHC printed the type it inferred for succ' in this kind of > situation. > > Regards, > Reid Barton > > On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif wrote: > > Devs, > > > > as of recently GHC HEAD stopped building the diagrams library. Several > > prerequisite libs also fail to compile. A specific error message > > appears in an attoparsec issue > > , for which I have > > submitted a workaround. But as Herbert cautiously points out, this > > could be a recent GHC bug surfacing. > > > > The symptoms of the bug seem to be that GHC complains about the usage > > of (~) type equality operation, but there is no reference to that type > > operator in the source code. To work around the problem it suffices to > > add -XGADTs or -XTypeFamilies. > > > > Does this ring any bells? Can automatized tests catch such things in the > > future? > > > > Cheers, > > > > Gabor > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Jun 10 16:52:38 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Jun 2014 16:52:38 +0000 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: <201406101816.02374.jan.stolarek@p.lodz.pl> References: <201406101816.02374.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DCF0F@DB3PRD3001MB020.064d.mgd.msft.net> I'm doing that now | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 10 June 2014 17:16 | To: ghc-devs at haskell.org | Subject: Re: HEADS-UP: diagrams does not compile with HEAD (regressions) | | Reid is correct. This is a result of fixing #8883. I agree that printing | the inferred signature | sounds like a good idea. | | Janek | | Dnia wtorek, 10 czerwca 2014, Reid Barton napisa?: | > I expect this is a result of | https://ghc.haskell.org/trac/ghc/ticket/8883, | > but even so it's not clear to me whether the error is correct. It would | be | > nice if GHC printed the type it inferred for succ' in this kind of | > situation. | > | > Regards, | > Reid Barton | > | > On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif wrote: | > > Devs, | > > | > > as of recently GHC HEAD stopped building the diagrams library. | Several | > > prerequisite libs also fail to compile. A specific error message | > > appears in an attoparsec issue | > > , for which I have | > > submitted a workaround. But as Herbert cautiously points out, this | > > could be a recent GHC bug surfacing. | > > | > > The symptoms of the bug seem to be that GHC complains about the usage | > > of (~) type equality operation, but there is no reference to that | type | > > operator in the source code. To work around the problem it suffices | to | > > add -XGADTs or -XTypeFamilies. | > > | > > Does this ring any bells? Can automatized tests catch such things in | the | > > future? | > > | > > Cheers, | > > | > > Gabor | > > _______________________________________________ | > > ghc-devs mailing list | > > ghc-devs at haskell.org | > > http://www.haskell.org/mailman/listinfo/ghc-devs | | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From edskodevries at gmail.com Wed Jun 11 08:18:07 2014 From: edskodevries at gmail.com (Edsko de Vries) Date: Wed, 11 Jun 2014 09:18:07 +0100 Subject: GHC MinGW distribution In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DC90A@DB3PRD3001MB020.064d.mgd.msft.net> References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> <87lht52m0m.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103DC90A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: git-annex (written in Haskell!) is designed specifically for this purpose. might be worth a look. -E On Tue, Jun 10, 2014 at 4:02 PM, Simon Peyton Jones wrote: > | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. > | > | Can't we simply put the tarballs in a plain HTTP folder on > | http://ghc.haskell.org, and store a list (or rather a shell script) of > | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? > > Personally I'm fine with that, if someone feels able to implement it (and > document in the wiki:Repositories page). > > But remember that I'm not very au fait with all the issues so I defer to > others > > Simon > > | -----Original Message----- > | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] > | Sent: 10 June 2014 09:43 > | To: Simon Peyton Jones > | Cc: Robin KAY; ghc-devs at haskell.org > | Subject: Re: GHC MinGW distribution > | > | Hello Simon, > | > | On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: > | > | [...] > | > | > We physically include very selective chunks of MinGW in a GHC Windows > | distribution > | > - so that users don't need to install MinGW > | > - so that GHC doesn't break just because a user has > | > a different version of MinGW than we expected > | > We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) > | > precisely so that we know exactly which bits to ship. > | > | Btw, there's just one thing I'm worried about with keeping those large > | MinGW binary tarballs in a Git repo: > | > | The Git repo will grow monotonically with each new compressed > | .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect > | shared bitstreams. So effectively each MiB of binary-data added will > | effectively grow the Git repo everyone will have to clone (even if only > | the latest MinGW for a specific 32/64-bit platform is desired) by that > | same amount. > | > | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. > | > | Can't we simply put the tarballs in a plain HTTP folder on > | http://ghc.haskell.org, and store a list (or rather a shell script) of > | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? > | > | Cheers, > | hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jun 11 08:18:30 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 11 Jun 2014 08:18:30 +0000 Subject: Windows breakage Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DD5FD@DB3PRD3001MB020.064d.mgd.msft.net> Stefan, Guys This commit breaks the Windows build (ie my laptop) commit 9fd507e5758f4141ac2619f0db57136bcab035c6 Author: Sergei Trofimovich Date: Fri May 23 23:58:06 2014 +0300 Raise exceptions when blocked in bad FDs (fixes Trac #4934) The breakage is this: C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS getStablePtr((StgPtr)blockedOnBadFD_closure); I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. Can someone do this, please? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-dev at maartenfaddegon.nl Wed Jun 11 10:14:01 2014 From: ghc-dev at maartenfaddegon.nl (Maarten Faddegon) Date: Wed, 11 Jun 2014 11:14:01 +0100 Subject: (drop)CommonPrefix: ccs call implementation In-Reply-To: <53918C34.7010600@gmail.com> References: <53901245.9060603@maartenfaddegon.nl> <53918C34.7010600@gmail.com> Message-ID: <53982BE9.5060206@maartenfaddegon.nl> Hi Simon, Thank you for the explanation, I begin to understand the reasoning behind your definition now. I have another question though: If inlining sets the call site's stack as prefix, I would say that the following definition: call sApp sLam = sApp ++ sLam' | sApp `isPrefixOf` sLam = sLam | otherwise = sApp ++ sLam Gives the same result as your definition: call sApp sLam = sApp ++ sLam' where (sPre,sApp',sLam') = commonPrefix sApp sLam Is that correct or are there situation where sApp' is non-empty? Cheers, Maarten On 06/06/14 10:39, Simon Marlow wrote: > The motivation for this design is to make it so that > > let > f = \x . E > in > ... f y ... > > Gives the same call stack as > > ... (\x . E) y ... > > That is, inlining a function does not change the call stack. GHC > assumes that this is valid, so the call stack semantics should reflect > that. > > Intuitively it works like this: in the first version, the CCS attached > to the closure for f is some prefix of the CCS that will be in force at > the call site, and in that case we don't want to push anything on the > stack for the call. However, we might have: > > let > f = scc "f" (\x . E) > in > ... f y ... > > and in this case we want to push "f" on the stack. > > I don't claim that this always works (recursion in particular causes > problems) but it behaves in a sensible way in most cases, and it was the > best formulation I was able to find. > > It remains to be seen whether there's a semantics that allows the > inlining equivalence to be formally proven; if you can do that I think > it would be a significant step forwards. > > Cheers, > Simon > > > On 05/06/2014 09:57, ?mer Sinan A?acan wrote: >> Hi Maarten, >> >> Where did you find that slides? I have slides for same talk(also >> attached) but mine has a different definition for call: (on page 39) >> >> call sapp slam = sapp ++ slam' >> where (spre, sapp', slam') = commonPrefix sapp slam >> >> This one works same with the implementation. >> >> --- >> ?mer Sinan A?acan >> http://osa1.net >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> From gale at sefer.org Wed Jun 11 10:36:54 2014 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 11 Jun 2014 13:36:54 +0300 Subject: Hashes for download files Message-ID: Perhaps it would be a good idea to post hashes on the download site for each downloadable file, to make it easier to verify that you have the genuine article. Thanks, Yitz From ggreif at gmail.com Wed Jun 11 11:06:55 2014 From: ggreif at gmail.com (Gabor Greif) Date: Wed, 11 Jun 2014 13:06:55 +0200 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: <201406101816.02374.jan.stolarek@p.lodz.pl> References: <201406101816.02374.jan.stolarek@p.lodz.pl> Message-ID: Hello Jan, thanks for clarifying this! As it is biting various libraries, it would warrant to add some blurb into the release notes. Or does an entry exist already? Cheers, Gabor On 6/10/14, Jan Stolarek wrote: > Reid is correct. This is a result of fixing #8883. I agree that printing the > inferred signature > sounds like a good idea. > > Janek > > Dnia wtorek, 10 czerwca 2014, Reid Barton napisa?: >> I expect this is a result of >> https://ghc.haskell.org/trac/ghc/ticket/8883, >> but even so it's not clear to me whether the error is correct. It would >> be >> nice if GHC printed the type it inferred for succ' in this kind of >> situation. >> >> Regards, >> Reid Barton >> >> On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif wrote: >> > Devs, >> > >> > as of recently GHC HEAD stopped building the diagrams library. Several >> > prerequisite libs also fail to compile. A specific error message >> > appears in an attoparsec issue >> > , for which I have >> > submitted a workaround. But as Herbert cautiously points out, this >> > could be a recent GHC bug surfacing. >> > >> > The symptoms of the bug seem to be that GHC complains about the usage >> > of (~) type equality operation, but there is no reference to that type >> > operator in the source code. To work around the problem it suffices to >> > add -XGADTs or -XTypeFamilies. >> > >> > Does this ring any bells? Can automatized tests catch such things in >> > the >> > future? >> > >> > Cheers, >> > >> > Gabor >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs > > > From jan.stolarek at p.lodz.pl Wed Jun 11 11:42:03 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 11 Jun 2014 13:42:03 +0200 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: References: <201406101816.02374.jan.stolarek@p.lodz.pl> Message-ID: <201406111342.03666.jan.stolarek@p.lodz.pl> No, there is no mention of it in the release notes. My bad. I'm putting it on my TODO list. Janek Dnia ?roda, 11 czerwca 2014, Gabor Greif napisa?: > Hello Jan, > > thanks for clarifying this! As it is biting various libraries, it > would warrant to add some blurb into the release notes. Or does an > entry exist already? > > Cheers, > > Gabor > > On 6/10/14, Jan Stolarek wrote: > > Reid is correct. This is a result of fixing #8883. I agree that printing > > the inferred signature > > sounds like a good idea. > > > > Janek > > > > Dnia wtorek, 10 czerwca 2014, Reid Barton napisa?: > >> I expect this is a result of > >> https://ghc.haskell.org/trac/ghc/ticket/8883, > >> but even so it's not clear to me whether the error is correct. It would > >> be > >> nice if GHC printed the type it inferred for succ' in this kind of > >> situation. > >> > >> Regards, > >> Reid Barton > >> > >> On Tue, Jun 10, 2014 at 7:55 AM, Gabor Greif wrote: > >> > Devs, > >> > > >> > as of recently GHC HEAD stopped building the diagrams library. Several > >> > prerequisite libs also fail to compile. A specific error message > >> > appears in an attoparsec issue > >> > , for which I have > >> > submitted a workaround. But as Herbert cautiously points out, this > >> > could be a recent GHC bug surfacing. > >> > > >> > The symptoms of the bug seem to be that GHC complains about the usage > >> > of (~) type equality operation, but there is no reference to that type > >> > operator in the source code. To work around the problem it suffices to > >> > add -XGADTs or -XTypeFamilies. > >> > > >> > Does this ring any bells? Can automatized tests catch such things in > >> > the > >> > future? > >> > > >> > Cheers, > >> > > >> > Gabor > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs at haskell.org > >> > http://www.haskell.org/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Jun 11 13:22:59 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 11 Jun 2014 09:22:59 -0400 Subject: [commit: ghc] master: Update mod73 test output (1178fa4) In-Reply-To: <20140606140958.4D0F12406D@ghc.haskell.org> References: <20140606140958.4D0F12406D@ghc.haskell.org> Message-ID: This test case is failing on my machine, too. Is it perhaps possible to sort the output to avoid these wibbles? I looked at the code and it's not immediately obvious to me the best place to do this... Thanks, Richard On Jun 6, 2014, at 10:09 AM, git at ghc.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/1178fa4ada1ac054976f3abb2e303ad42653e303/ghc > >> --------------------------------------------------------------- > > commit 1178fa4ada1ac054976f3abb2e303ad42653e303 > Author: Joachim Breitner > Date: Fri Jun 6 15:03:36 2014 +0200 > > Update mod73 test output > > to what I observe on travis and on my validate machine, even though my > local tree produces the previous output. > > >> --------------------------------------------------------------- > > 1178fa4ada1ac054976f3abb2e303ad42653e303 > testsuite/tests/module/mod73.stderr | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/testsuite/tests/module/mod73.stderr b/testsuite/tests/module/mod73.stderr > index d19a032..576b0e3 100644 > --- a/testsuite/tests/module/mod73.stderr > +++ b/testsuite/tests/module/mod73.stderr > @@ -2,6 +2,6 @@ > mod73.hs:3:7: > Not in scope: ?Prelude.g? > Perhaps you meant one of these: > - data constructor ?Prelude.GT? (imported from Prelude), > + data constructor ?Prelude.LT? (imported from Prelude), > data constructor ?Prelude.EQ? (imported from Prelude), > - data constructor ?Prelude.LT? (imported from Prelude) > + data constructor ?Prelude.GT? (imported from Prelude) > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From slyich at gmail.com Wed Jun 11 19:50:34 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Wed, 11 Jun 2014 22:50:34 +0300 Subject: Windows breakage (+patch) In-Reply-To: <20140611213557.26f0eb8e@sf> References: <618BE556AADD624C9C918AA5D5911BEF103DD5FD@DB3PRD3001MB020.064d.mgd.msft.net> <20140611213557.26f0eb8e@sf> Message-ID: <20140611225034.168b257e@sf> On Wed, 11 Jun 2014 21:35:57 +0300 Sergei Trofimovich wrote: > On Wed, 11 Jun 2014 08:18:30 +0000 > Simon Peyton Jones wrote: > > > Stefan, Guys > > This commit breaks the Windows build (ie my laptop) > > > > commit 9fd507e5758f4141ac2619f0db57136bcab035c6 > > > > Author: Sergei Trofimovich > > > > Date: Fri May 23 23:58:06 2014 +0300 > > > > > > > > Raise exceptions when blocked in bad FDs (fixes Trac #4934) > > The breakage is this: > > > > C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' > > The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS > > > > getStablePtr((StgPtr)blockedOnBadFD_closure); > > I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. > > Can someone do this, please? > > Oh, I've missed the fact GHC.Event.Thread in a non-windows thing. > The whole patch was for posix-only platform, but i tried to export > that exception for all platforms. > > CCed Simon M. > > There is 2 routes: > a) move an exception a common module to all platforms. > For example to Foreign.C.Error (I've started to prepare a patch) To avoid import loops and make things clear I've moved it to GHC.Exception.RTS (other from-rts exceptions can be pushded there as well) Patch is in attach. Please review. Thank you! -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-rts-fix-linkage-on-windows-missing-blockedOnBadFD_cl.patch Type: text/x-patch Size: 6756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From pali.gabor at gmail.com Wed Jun 11 20:26:02 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Wed, 11 Jun 2014 22:26:02 +0200 Subject: GHC/cabal release procedures, and Stackage In-Reply-To: <53938F5A.3040204@fuuzetsu.co.uk> References: <618BE556AADD624C9C918AA5D5911BEF103D9894@DB3PRD3001MB020.064d.mgd.msft.net> <1402059287.2928.2.camel@kirk> <1402178277.30242.6.camel@kirk> <53938F5A.3040204@fuuzetsu.co.uk> Message-ID: 2014-06-08 0:16 GMT+02:00 Mateusz Kowalczyk : > Some builders such as upload snapshots but I don't know how it's decided > which. See [1] for example of such build. I think Pali makes the call. There is no exact clear criteria for deciding which clients shall upload the snapshots. If you need snapshots for a builder that currently does not have, tell me. But I think it would make more sense to save the resulting builds only for builders that build for Tier-1 platforms and the build is the different enough from others for the (similar) platform. For example, keeping the snapshots for every minor version of OS X or Linux + glibc might not be a great idea. However, validating on the most possible combination of systems is. From ggreif at gmail.com Thu Jun 12 10:16:27 2014 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 12 Jun 2014 12:16:27 +0200 Subject: HEADS-UP: diagrams does not compile with HEAD (regressions) In-Reply-To: <201406111342.03666.jan.stolarek@p.lodz.pl> References: <201406101816.02374.jan.stolarek@p.lodz.pl> <201406111342.03666.jan.stolarek@p.lodz.pl> Message-ID: On 6/11/14, Jan Stolarek wrote: > No, there is no mention of it in the release notes. My bad. I'm putting it > on my TODO list. That's cool, thanks! Gabor > > Janek > From alfredo.dinapoli at gmail.com Thu Jun 12 11:31:22 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Thu, 12 Jun 2014 13:31:22 +0200 Subject: Getting error about unused instances during "sh validate" Message-ID: Hello guys, am I the only one to get the following when I run "sh validate"? libraries/base/Data/Maybe.hs:139:1: Warning: Defined but not used: ?mapMaybeFB? : Failing due to -Werror. make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 I'm working on this ticket, but I can't see how that can be related: https://ghc.haskell.org/trac/ghc/ticket/8226 Thanks! Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 12 14:36:08 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 12 Jun 2014 14:36:08 +0000 Subject: Getting error about unused instances during "sh validate" In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103DEEA8@DB3PRD3001MB020.064d.mgd.msft.net> Does not happen for me. Maybe you are compiling without ?O (odd, but possible)? mapMaybeFB is mentioned only inside a RULE, so perhaps it?s regarded as un-referenced without ?O? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alfredo Di Napoli Sent: 12 June 2014 12:31 To: ghc-devs at haskell.org Subject: Getting error about unused instances during "sh validate" Hello guys, am I the only one to get the following when I run "sh validate"? libraries/base/Data/Maybe.hs:139:1: Warning: Defined but not used: ?mapMaybeFB? : Failing due to -Werror. make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 I'm working on this ticket, but I can't see how that can be related: https://ghc.haskell.org/trac/ghc/ticket/8226 Thanks! Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.dinapoli at gmail.com Thu Jun 12 17:30:13 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Thu, 12 Jun 2014 19:30:13 +0200 Subject: Getting error about unused instances during "sh validate" In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DEEA8@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103DEEA8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <13DDCBB0-0A7D-4E92-9CC7-225619081ED2@gmail.com> Hi Simon, It's strange because I was not getting that before (say 2 weeks ago) and as far as I know I have not changed my build type (always been "quick"). I'll try to see if playing around with -O will change things and report back. Thanks! Alfredo > On 12/giu/2014, at 16:36, Simon Peyton Jones wrote: > > Does not happen for me. Maybe you are compiling without ?O (odd, but possible)? mapMaybeFB is mentioned only inside a RULE, so perhaps it?s regarded as un-referenced without ?O? > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alfredo Di Napoli > Sent: 12 June 2014 12:31 > To: ghc-devs at haskell.org > Subject: Getting error about unused instances during "sh validate" > > Hello guys, > > am I the only one to get the following when I run "sh validate"? > > > libraries/base/Data/Maybe.hs:139:1: Warning: > Defined but not used: ?mapMaybeFB? > > : > Failing due to -Werror. > make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > > I'm working on this ticket, but I can't see how that can be related: > > https://ghc.haskell.org/trac/ghc/ticket/8226 > > Thanks! > Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Fri Jun 13 09:47:20 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 13 Jun 2014 11:47:20 +0200 Subject: Phabricator for patches and code review In-Reply-To: <53941192.8080208@gmail.com> References: <53941192.8080208@gmail.com> Message-ID: <201406131147.21001.jan.stolarek@p.lodz.pl> It seems that most people are in favour of using Phabricator for code review. So what are the next steps? Can we just start using the existing phabricator instance? I'm working on some code right now that definitely needs reviewing. Janek Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: > On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > > So, why not put everything on GutHub and use pull requests and so on? > > github just isn't great for doing code reviews. No side-by-side diffs, > and it sends you a separate email for every single comment, there's no > concept of a "review" consisting of multiple inline comments (unless > I've missed something). I'm afraid if we were using this for regular > reviews I would have to disable the email notifications, which makes it > significantly less useful. > > > SimonM writes that Phabricator is better than GitHub. I?m happy to > > believe that, but he also writes that using it requires installing local > > software and quite a bit of work. Moreover, I like to add that lots of > > people already know how to use GitHub and probably few know Phabricator. > > > > So, we are talking about having a somewhat better tool in return for > > three very significant disadvantages: (1) local installation, (2) work to > > set up and maintain Phabricator, and (3) effort by many people to learn > > to use it. > > Well, you've tipped the balance with "somewhat" and "significant" here, > I'd say Phabricator is "significantly" better than github for code > reviews, while installing arc is "somewhat" annoying :-) > > I have to admit it's not a no-brainer, but I do worry that github just > wouldn't cut it for doing a lot of code reviewing, whereas I spend my > life inside Phabricator so I know it works really well. > > What's more, github doesn't let you put animated gifs in code reviews. > Need I say more? > > Cheers, > Simon > > > We also have a constant lack of sufficient men power. So, why spend > > effort on building our own infrastructure, which will only increase the > > hurdle for contributors (as they have to deal with an unknown system)? > > Let?s outsource the effort to GitHub. > > > > Manuel > > > > Simon Peyton Jones : > >> At the moment GHC's main sources aren't on github, which means that that > >> (in my highly imperfect understanding) people can't submit pull requests > >> or use their code review mechanisms. Moreover, most people don't have > >> commit rights on the main GHC server, so if someone wants to offer a > >> patch they can really only do so in textual form attached to Trac. > >> People with commit rights can make a branch, but there's a danger that > >> over a decade we'll accumulate zillions of dead branches which people > >> forgot to delete. I think on github the branch is in a different repo, > >> belonging to the patch author. > >> > >> So we really don't have a good work flow for creating, reviewing, > >> modifying, and finally apply patches. I am no expert on these matters. > >> If Phabricator would help with that I'm all for it. But perhaps there > >> are other alternatives? Or is Phab the lead thing. Will it stay > >> around? > >> > >> Also before going too far I'd really like someone to document the > >> workflow carefully, and make sure it works from Windows equally well. > >> > >> I'm not too stressed out about losing the review trail of a patch. Much > >> of it will be commenting on stuff that no longer appears in the final > >> patch. Anything that's important should appear in a Note in the source > >> code; even the commit messages are invisible until you really start > >> digging. > >> > >> Simon > >> > >> | -----Original Message----- > >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > >> | Austin Seipp > >> | Sent: 06 June 2014 05:06 > >> | To: ghc-devs at haskell.org > >> | Subject: RFC: Phabricator for patches and code review > >> | > >> | Hello all, > >> | > >> | Recently, while doing server maintenance, several of the > >> | administrators for Haskell.org set up an instance of Phabricator[1], > >> | located at https://phabricator.haskell.org > >> | > >> | For those who aren't aware, Phabricator (or "Phab") is a suite of > >> | tools for software development. Think of it like a polished, > >> | semi-private GitHub with a lot of applications and tools for all kinds > >> | of needs. We've been using it to do issue tracking for Haskell.org > >> | maintenance and like it a lot so far. > >> | > >> | One very nice aspect of Phabricator though is it has a very nice code > >> | review tool, called 'Differential', that is very useful. For people > >> | who have used a tool like Review Board, it's similar. Furthermore, it > >> | has a very convenient userland tool called 'Arcanist' which makes it > >> | easy for newcomers to post a review and get it merged when it's ready > >> | all from the command line. > >> | > >> | I'd like to see if people are interested in using Phab _strictly_ for > >> | code review of GHC patches. It is a dedicated tool specifically for > >> | this, and I think it works much better than Trac or inline GitHub > >> | comments. > >> | > >> | Also, Phab can also support post-commit reviews. So if I touch > >> | something in the runtime system and just push, perhaps Simon or Edward > >> | would like to look, and they can be alerted right when I do this, and > >> | then yell if I did something stupid. > >> | > >> | Before I go much further, I'd like to ask: is there *any* interest in > >> | this? Or are people satisifed with Trac? The primary motivations are > >> | roughly, in no particular order: > >> | > >> | 1) Code review is good for everyone, a good way for people to learn > >> | the code and ask questions, and useful to give feedback to newcomers. > >> | And even experienced GHC hackers can learn things from reading code, > >> | as we all do regularly, or find things that need cleanup. > >> | > >> | 2) Phabricator in particular makes it very easy to submit patches for > >> | review. To submit a patch, I just run the command 'arc diff' and it > >> | Does The Right Thing. It also makes it easy to ensure people are > >> | *alerted* when a patch might be relevant to them. > >> | > >> | 3) They can be uploaded and created from the command line, and merged > >> | easily afterwords the same way. This is particularly useful for > >> | newcomers, and for me. :) > >> | > >> | 4) Differential is dedicated to code review, and much better at it > >> | than just reading patches on Trac IMO. > >> | > >> | 5) It supports both post-commit code review, as well as pre-commit > >> | review. Post commit would be especially useful for us too, I think. > >> | > >> | Point #2 and #3 are mostly relevant for me, because I mostly handle > >> | incoming patches. But I think in general it would be nice, and make it > >> | a lot easier for newcomers to submit patches, and us to look over > >> | them. > >> | > >> | Here's an example of a Differential code review: > >> | > >> | https://phabricator.haskell.org/D4 > >> | > >> | This is a demo using my 'wip/ermsb' patch. You'll need to create an > >> | account to login, but it shouldn't be much trouble, you can login > >> | several ways. I'll fix the login requirement soon. Feel free to read > >> | the code, comment on it, and play around. It's more of a > >> | demonstration, but real code review would be welcome too. :) > >> | > >> | If people are interested in doing this, I can add notes to the wiki > >> | pages for newcomers, and I'll send another email about Phab so people > >> | can understand it a little better. But I want to ask first. > >> | > >> | There is an argument that our team is so small, code review has > >> | unnecessary burdens. But I think Phab could help a lot with tracking > >> | outside patches and getting good reviews for incoming patches, and > >> | it'll make it easier for newcomers. And experienced pros can probably > >> | learn a thing as well. > >> | > >> | Again, to be clear, I don't propose we migrate anything to Phabricator > >> | from, say, Trac. There's no real pressure to do so and it would be > >> | tons of work. I only propose we use it for code review, which is > >> | perfectly fine, and how other projects like LLVM do code review (they > >> | use Bugzilla). > >> | > >> | I also don't think the usage of Phabricator should be mandatory > >> | (unless we decide that later because we like it), but I would like to > >> | see people use it if possible. > >> | > >> | [1] http://phabricator.org > >> | > >> | -- > >> | Regards, > >> | > >> | Austin Seipp, Haskell Consultant > >> | Well-Typed LLP, http://www.well-typed.com/ > >> | _______________________________________________ > >> | ghc-devs mailing list > >> | ghc-devs at haskell.org > >> | http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From alfredo.dinapoli at gmail.com Fri Jun 13 14:29:52 2014 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Fri, 13 Jun 2014 16:29:52 +0200 Subject: Getting error about unused instances during "sh validate" In-Reply-To: <13DDCBB0-0A7D-4E92-9CC7-225619081ED2@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF103DEEA8@DB3PRD3001MB020.064d.mgd.msft.net> <13DDCBB0-0A7D-4E92-9CC7-225619081ED2@gmail.com> Message-ID: I think I have finally understood what's going on. As Simon pointed out (that was the key insight) mapMaybeFP is referenced inside the RULE, but I'm working on the Lexer to remove old Haddock 0.x comments, and I suspect my patch broke the Lexer, so the GHC version on my branch is interpreting that rule as a normal comment, causing the aforementioned error. Well, at least I know the problem is just mine and that my patch needs improvement :) Thanks SPJ! Alfredo On Thursday, 12 June 2014, Alfredo Di Napoli wrote: > Hi Simon, > It's strange because I was not getting that before (say 2 weeks ago) and as far as I know I have not changed my build type (always been "quick"). > I'll try to see if playing around with -O will change things and report back. > Thanks! > > Alfredo > On 12/giu/2014, at 16:36, Simon Peyton Jones wrote: > > Does not happen for me. Maybe you are compiling without ?O (odd, but possible)? mapMaybeFB is mentioned only inside a RULE, so perhaps it?s regarded as un-referenced without ?O? > > > > Simon > > > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alfredo Di Napoli > Sent: 12 June 2014 12:31 > To: ghc-devs at haskell.org > Subject: Getting error about unused instances during "sh validate" > > > > Hello guys, > > am I the only one to get the following when I run "sh validate"? > > > libraries/base/Data/Maybe.hs:139:1: Warning: > Defined but not used: ?mapMaybeFB? > > : > Failing due to -Werror. > make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > > I'm working on this ticket, but I can't see how that can be related: > > https://ghc.haskell.org/trac/ghc/ticket/8226 > > Thanks! > Alfredo -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sat Jun 14 15:57:50 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 14 Jun 2014 18:57:50 +0300 Subject: FFI: c/c++ struct on stack as an argument or return value In-Reply-To: <5328BAE9.6080805@gmail.com> References: <1394797839.4664.35.camel@shum-lt> <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au> <1394887862.4722.31.camel@shum-lt> <532839B4.7040609@gmail.com> <1395163879.4601.35.camel@shum-lt> <5328BAE9.6080805@gmail.com> Message-ID: <1402761470.4765.20.camel@shum-lt> Hello, I implemented support for returning C structures by value in cmm for x86_64 (most likely it works only on linux). You can find it here: https://github.com/Yuras/ghc/commits/cmm-cstruct It supports I8, I16, I32, I64, F_, D_ cmm types, and requires special annotation. For example: #include "Cmm.h" #define MyStruct struct(CInt, I8, struct(I8, CInt)) cmm_test(W_ i) { CInt i1; I8 i2, i3; float32 i4; (i1, i2, i3, i4) = ccall c_test(W_TO_INT(i)) MyStruct; return (TO_W_(i1), TO_W_(i2), TO_W_(i3), i4); } (See "test" directory for full examples.) Do you think it is right approach? Could anyone review the code please? And the last thing, I need mentor for this project. Is anyone interested? Thanks, Yuras On Tue, 2014-03-18 at 21:30 +0000, Simon Marlow wrote: > So the hard parts are: > > - the native code generators > - native adjustor support (rts/Adjustor.c) > > Everything else is relatively striaghtforward: we use libffi for > adjustors on some platforms and for GHCi, and the LLVM backend should be > quite easy too. > > I would at least take a look at the hard bits and see whether you think > it's going to be possible to extend these to handle struct args/returns. > Because if not, then the idea is a dead end. Or maybe we will need to > limit the scope to make things easier (e.g. only integer and pointer > fields). > > Cheers, > Simon > > On 18/03/2014 17:31, Yuras Shumovich wrote: > > Hi, > > > > I thought I have lost the battle :) > > Thank you for the support, Simon! > > > > I'm interested in full featured solution: arguments, return value, > > foreign import, foreign export, etc. But it is too much for me to do it > > all at once. So I started with dynamic wrapper. > > > > The plan is to support structs as arguments and return value for dynamic > > wrapper using libffi; > > then implement native adjustors at least for x86_64 linux; > > then make final design decision (tuple or data? language pragma? union > > support? etc); > > and only then start working on foreign import. > > > > But I'm open for suggestions. Just let me know if you think it is better > > to start with return value support for foreign import. > > > > Thanks, > > Yuras > > > > On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote: > >> I'm really keen to have support for returning structs in particular. > >> Passing structs less so, because working around the lack of struct > >> passing isn't nearly as onerous as working around the lack of struct > >> returns. Returning multiple values from a C function is a real pain > >> without struct returns: you have to either allocate some memory in > >> Haskell or in C, and both methods are needlessly complex and slow. > >> (though allocating in Haskell is usually better.) C++ code does this all > >> the time, so if you're wrapping C++ code for calling from Haskell, the > >> lack of multiple returns bites a lot. > >> > >> In fact implementing this is on my todo list, I'm really glad to see > >> someone else is planning to do it :-) > >> > >> The vague plan I had in my head was to allow the return value of a > >> foreign import to be a tuple containing marshallable types, which would > >> map to the appropriate return convention for a struct on the current > >> platform. Perhaps allowing it to be an arbitrary single-constructor > >> type is better, because it allows us to use a type that has a Storable > >> instance. > >> > >> Cheers, > >> Simon > >> > > > > From iavor.diatchki at gmail.com Sun Jun 15 01:04:12 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat, 14 Jun 2014 18:04:12 -0700 Subject: FFI: c/c++ struct on stack as an argument or return value In-Reply-To: <1402761470.4765.20.camel@shum-lt> References: <1394797839.4664.35.camel@shum-lt> <5F969E34-BCF1-40CB-86DF-20F84245BEDB@cse.unsw.edu.au> <1394887862.4722.31.camel@shum-lt> <532839B4.7040609@gmail.com> <1395163879.4601.35.camel@shum-lt> <5328BAE9.6080805@gmail.com> <1402761470.4765.20.camel@shum-lt> Message-ID: Hello, just as another data point: I'd also find this functionality useful. I've run into the problem when trying to bind to C libraries that have functions with struct parameters being passed by value, or returned (the idea being that under the hood these structs often end up split up across registers). In the library I was working with, colors were implemented as RGBA structs which were passed and returned by value all over the place. -Iavor On Sat, Jun 14, 2014 at 8:57 AM, Yuras Shumovich wrote: > Hello, > > I implemented support for returning C structures by value in cmm for > x86_64 (most likely it works only on linux). You can find it here: > https://github.com/Yuras/ghc/commits/cmm-cstruct > > It supports I8, I16, I32, I64, F_, D_ cmm types, and requires special > annotation. For example: > > #include "Cmm.h" > > #define MyStruct struct(CInt, I8, struct(I8, CInt)) > > cmm_test(W_ i) > { > CInt i1; > I8 i2, i3; > float32 i4; > (i1, i2, i3, i4) = ccall c_test(W_TO_INT(i)) MyStruct; > return (TO_W_(i1), TO_W_(i2), TO_W_(i3), i4); > } > > (See "test" directory for full examples.) > > > Do you think it is right approach? > Could anyone review the code please? > > And the last thing, I need mentor for this project. Is anyone interested? > > Thanks, > Yuras > > On Tue, 2014-03-18 at 21:30 +0000, Simon Marlow wrote: > > So the hard parts are: > > > > - the native code generators > > - native adjustor support (rts/Adjustor.c) > > > > Everything else is relatively striaghtforward: we use libffi for > > adjustors on some platforms and for GHCi, and the LLVM backend should be > > quite easy too. > > > > I would at least take a look at the hard bits and see whether you think > > it's going to be possible to extend these to handle struct args/returns. > > Because if not, then the idea is a dead end. Or maybe we will need to > > limit the scope to make things easier (e.g. only integer and pointer > > fields). > > > > Cheers, > > Simon > > > > On 18/03/2014 17:31, Yuras Shumovich wrote: > > > Hi, > > > > > > I thought I have lost the battle :) > > > Thank you for the support, Simon! > > > > > > I'm interested in full featured solution: arguments, return value, > > > foreign import, foreign export, etc. But it is too much for me to do it > > > all at once. So I started with dynamic wrapper. > > > > > > The plan is to support structs as arguments and return value for > dynamic > > > wrapper using libffi; > > > then implement native adjustors at least for x86_64 linux; > > > then make final design decision (tuple or data? language pragma? union > > > support? etc); > > > and only then start working on foreign import. > > > > > > But I'm open for suggestions. Just let me know if you think it is > better > > > to start with return value support for foreign import. > > > > > > Thanks, > > > Yuras > > > > > > On Tue, 2014-03-18 at 12:19 +0000, Simon Marlow wrote: > > >> I'm really keen to have support for returning structs in particular. > > >> Passing structs less so, because working around the lack of struct > > >> passing isn't nearly as onerous as working around the lack of struct > > >> returns. Returning multiple values from a C function is a real pain > > >> without struct returns: you have to either allocate some memory in > > >> Haskell or in C, and both methods are needlessly complex and slow. > > >> (though allocating in Haskell is usually better.) C++ code does this > all > > >> the time, so if you're wrapping C++ code for calling from Haskell, the > > >> lack of multiple returns bites a lot. > > >> > > >> In fact implementing this is on my todo list, I'm really glad to see > > >> someone else is planning to do it :-) > > >> > > >> The vague plan I had in my head was to allow the return value of a > > >> foreign import to be a tuple containing marshallable types, which > would > > >> map to the appropriate return convention for a struct on the current > > >> platform. Perhaps allowing it to be an arbitrary single-constructor > > >> type is better, because it allows us to use a type that has a Storable > > >> instance. > > >> > > >> Cheers, > > >> Simon > > >> > > > > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Jun 16 11:45:03 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 16 Jun 2014 13:45:03 +0200 Subject: Uniquable RdrName instance Message-ID: <201406161345.03423.jan.stolarek@p.lodz.pl> Hi all, I just found myself in the need of Uniquable instance for RdrName. I'm surprised that such instance does not exist already because other datatypes like Name or OccName already have Uniquable instances. So, is there a reason why Uniquable instance for RdrName does not exist already (other than "it wasn't needed")? How should such an instance look like? I made an attempt: rdrNameUnique :: RdrName -> Unique rdrNameUnique (Unqual occName) = getUnique occName rdrNameUnique (Qual _ occName) = getUnique occName rdrNameUnique (Orig _ occName) = getUnique occName rdrNameUnique (Exact name ) = getUnique name But I suspect this might be wrong: - cases 1 and 4 simply return a Unique for the OccName/Name stored inside RdrName. I think this will assign the same Unique to RdrName and corresponding OccName/Name. Is this allowed? - cases 2 and 3 ignore the Module stored inside RdrName. Again, this assigns the RdrName with a Unique identical to OccNames stored inside it. Help appreciated. Janek From simonpj at microsoft.com Mon Jun 16 12:59:30 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Jun 2014 12:59:30 +0000 Subject: Regression in the typechecker in GHC 7.8.2 In-Reply-To: <20140616104537.30015.qmail@www1.g3.pair.com> References: <20140616104537.30015.qmail@www1.g3.pair.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E2819@DB3PRD3001MB020.064d.mgd.msft.net> Copying ghc-devs. Oleg says: | Sorry for reporting a problem via e-mail. It seems track no | longer accepts anonymous (guest) submissions. When I tried to register | the account I was told that my submission is a spam. The tracker is | really well protected. Can anyone help him? I'll open a ticket. Simon | -----Original Message----- | From: oleg at okmij.org [mailto:oleg at okmij.org] | Sent: 16 June 2014 11:46 | To: Simon Peyton Jones | Subject: Regression in the typechecker in GHC 7.8.2 | | | Hello! | | Sorry for reporting a problem via e-mail. It seems track no | longer accepts anonymous (guest) submissions. When I tried to register | the account I was told that my submission is a spam. The tracker is | really well protected. | | Here is the problem: what used to type check in GHC 7.4.1 (and I think | in 7.6.2, although I no longer have access to that version) fails in GHC | 7.8.2. | | The following program type-checks with GHC 7.4.1 and GHC 7.8.2: | | {-# LANGUAGE RankNTypes #-} | {-# LANGUAGE TypeFamilies #-} | | module T where | | foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] | -- foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] | foo tr x = tr x | | t = foo (fmap not) [True] | | The following code (which differs only in the signature of foo) | | {-# LANGUAGE RankNTypes #-} | {-# LANGUAGE TypeFamilies #-} | | module T where | | -- foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] foo :: | (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = | tr x | | t = foo (fmap not) [True] | | | type-checks with 7.4.1 but not with 7.8.2. The latter reports the error | | Couldn't match type `b' with `Bool' | `b' is untouchable | inside the constraints (Functor f, g ~ f) | bound by a type expected by the context: | (Functor f, g ~ f) => g Bool -> g b | at /tmp/t.hs:12:5-25 | `b' is a rigid type variable bound by | the inferred type of t :: [b] at /tmp/t.hs:12:1 | Expected type: Bool -> b | Actual type: Bool -> Bool | Relevant bindings include t :: [b] (bound at /tmp/t.hs:12:1) | In the first argument of `fmap', namely `not' | In the first argument of `foo', namely `(fmap not)' | | Giving t the type signature [Bool] fixes the problem. Alas, I come | across the similar untouchable error in situations where giving the type | signature is quite difficult (in local bindings, with quite large | types). | | Sorry again for the off-line report, | Oleg From ekmett at gmail.com Mon Jun 16 13:23:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 16 Jun 2014 09:23:01 -0400 Subject: Fwd: Regression in the typechecker in GHC 7.8.2 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E2819@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140616104537.30015.qmail@www1.g3.pair.com> <618BE556AADD624C9C918AA5D5911BEF103E2819@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Forwarding to haskell-infrastructure. ---------- Forwarded message ---------- From: Simon Peyton Jones Date: Mon, Jun 16, 2014 at 8:59 AM Subject: RE: Regression in the typechecker in GHC 7.8.2 To: "oleg at okmij.org" , "ghc-devs at haskell.org" < ghc-devs at haskell.org> Copying ghc-devs. Oleg says: | Sorry for reporting a problem via e-mail. It seems track no | longer accepts anonymous (guest) submissions. When I tried to register | the account I was told that my submission is a spam. The tracker is | really well protected. Can anyone help him? I'll open a ticket. Simon | -----Original Message----- | From: oleg at okmij.org [mailto:oleg at okmij.org] | Sent: 16 June 2014 11:46 | To: Simon Peyton Jones | Subject: Regression in the typechecker in GHC 7.8.2 | | | Hello! | | Sorry for reporting a problem via e-mail. It seems track no | longer accepts anonymous (guest) submissions. When I tried to register | the account I was told that my submission is a spam. The tracker is | really well protected. | | Here is the problem: what used to type check in GHC 7.4.1 (and I think | in 7.6.2, although I no longer have access to that version) fails in GHC | 7.8.2. | | The following program type-checks with GHC 7.4.1 and GHC 7.8.2: | | {-# LANGUAGE RankNTypes #-} | {-# LANGUAGE TypeFamilies #-} | | module T where | | foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] | -- foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] | foo tr x = tr x | | t = foo (fmap not) [True] | | The following code (which differs only in the signature of foo) | | {-# LANGUAGE RankNTypes #-} | {-# LANGUAGE TypeFamilies #-} | | module T where | | -- foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] foo :: | (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = | tr x | | t = foo (fmap not) [True] | | | type-checks with 7.4.1 but not with 7.8.2. The latter reports the error | | Couldn't match type `b' with `Bool' | `b' is untouchable | inside the constraints (Functor f, g ~ f) | bound by a type expected by the context: | (Functor f, g ~ f) => g Bool -> g b | at /tmp/t.hs:12:5-25 | `b' is a rigid type variable bound by | the inferred type of t :: [b] at /tmp/t.hs:12:1 | Expected type: Bool -> b | Actual type: Bool -> Bool | Relevant bindings include t :: [b] (bound at /tmp/t.hs:12:1) | In the first argument of `fmap', namely `not' | In the first argument of `foo', namely `(fmap not)' | | Giving t the type signature [Bool] fixes the problem. Alas, I come | across the similar untouchable error in situations where giving the type | signature is quite difficult (in local bindings, with quite large | types). | | Sorry again for the off-line report, | Oleg _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jun 16 13:52:51 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 16 Jun 2014 09:52:51 -0400 Subject: Uniquable RdrName instance In-Reply-To: <201406161345.03423.jan.stolarek@p.lodz.pl> References: <201406161345.03423.jan.stolarek@p.lodz.pl> Message-ID: <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> Without looking into the precise details, this looks dangerous to me. Why do you want this? The danger I see lurking is that you might find two RdrNames that give the same answer to getUnique but represent different things: foo x = x + (\x -> x) 3 I see two `x`s there that will have the same Unique attached to their RdrNames but will be very different. In fact, I'm surprised that OccName has a Uniquable instance, which seems similarly dangerous to me. Richard On Jun 16, 2014, at 7:45 AM, Jan Stolarek wrote: > Hi all, > > I just found myself in the need of Uniquable instance for RdrName. I'm surprised that such > instance does not exist already because other datatypes like Name or OccName already have > Uniquable instances. So, is there a reason why Uniquable instance for RdrName does not exist > already (other than "it wasn't needed")? How should such an instance look like? I made an > attempt: > > rdrNameUnique :: RdrName -> Unique > rdrNameUnique (Unqual occName) = getUnique occName > rdrNameUnique (Qual _ occName) = getUnique occName > rdrNameUnique (Orig _ occName) = getUnique occName > rdrNameUnique (Exact name ) = getUnique name > > But I suspect this might be wrong: > - cases 1 and 4 simply return a Unique for the OccName/Name stored inside RdrName. I think this > will assign the same Unique to RdrName and corresponding OccName/Name. Is this allowed? > - cases 2 and 3 ignore the Module stored inside RdrName. Again, this assigns the RdrName with a > Unique identical to OccNames stored inside it. > > Help appreciated. > > Janek > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Mon Jun 16 19:33:06 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 16 Jun 2014 21:33:06 +0200 Subject: Uniquable RdrName instance In-Reply-To: <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> Message-ID: <201406162133.06490.jan.stolarek@p.lodz.pl> > Why do you want this? The danger I see lurking is that you might find two > RdrNames that give the same answer to getUnique but represent different Yes, that's exactly my concern. > Why do you want this? I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet from desugaring of arrow notation: leaves = concatMap leavesMatch matches where leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), IdSet)] leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) = let defined_vars = mkVarSet (collectPatsBinders pats) `unionVarSet` mkVarSet (collectLocalBinders binds) in [(body, mkVarSet (collectLStmtsBinders stmts) `unionVarSet` defined_vars) | L _ (GRHS stmts body) <- grhss] This is in the desugarer. But I need to also know `length leaves` at the renaming stage, which means I need to call `concatMap leavesMatch matches`. The problem is that in the renamer my datatypes are not parametrised by `Id`. I turned `Id` into a type parameter `id`, but then I can't use VarSets. I could use more general UniqueSets but only if `id` type parameter is an instance of Uniquable. And since in the renamer the datatypes are parametrized with RdrName this leads me to wanting Uniqable RdrName instance. Janek From nicolas.frisby at gmail.com Mon Jun 16 21:14:06 2014 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon, 16 Jun 2014 16:14:06 -0500 Subject: Uniquable RdrName instance In-Reply-To: <201406162133.06490.jan.stolarek@p.lodz.pl> References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> <201406162133.06490.jan.stolarek@p.lodz.pl> Message-ID: FYI it's #7828, not #7282. Jan, I'm very glad you're working on this. Thanks! On Mon, Jun 16, 2014 at 2:33 PM, Jan Stolarek wrote: > > Why do you want this? The danger I see lurking is that you might find two > > RdrNames that give the same answer to getUnique but represent different > Yes, that's exactly my concern. > > > Why do you want this? > I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet from > desugaring of arrow > notation: > > leaves = concatMap leavesMatch matches > where > leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), > IdSet)] > leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) > = let defined_vars = mkVarSet (collectPatsBinders pats) > `unionVarSet` > mkVarSet (collectLocalBinders > binds) > in [(body, mkVarSet (collectLStmtsBinders stmts) > `unionVarSet` defined_vars) | L _ > (GRHS stmts body) <- grhss] > > This is in the desugarer. But I need to also know `length leaves` at the > renaming stage, which > means I need to call `concatMap leavesMatch matches`. The problem is that > in the renamer my > datatypes are not parametrised by `Id`. I turned `Id` into a type > parameter `id`, but then I > can't use VarSets. I could use more general UniqueSets but only if `id` > type parameter is an > instance of Uniquable. And since in the renamer the datatypes are > parametrized with RdrName this > leads me to wanting Uniqable RdrName instance. > > Janek > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Jun 16 22:30:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 16 Jun 2014 18:30:31 -0400 Subject: Uniquable RdrName instance In-Reply-To: References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> <201406162133.06490.jan.stolarek@p.lodz.pl> Message-ID: would making arrow remindable involve dropping the arr == haksell functions assumption or doing something that would allow generalized arrows? On Mon, Jun 16, 2014 at 5:14 PM, Nicolas Frisby wrote: > FYI it's #7828, not #7282. > > Jan, I'm very glad you're working on this. Thanks! > > > On Mon, Jun 16, 2014 at 2:33 PM, Jan Stolarek > wrote: > >> > Why do you want this? The danger I see lurking is that you might find >> two >> > RdrNames that give the same answer to getUnique but represent different >> Yes, that's exactly my concern. >> >> > Why do you want this? >> I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet from >> desugaring of arrow >> notation: >> >> leaves = concatMap leavesMatch matches >> where >> leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), >> IdSet)] >> leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) >> = let defined_vars = mkVarSet (collectPatsBinders pats) >> `unionVarSet` >> mkVarSet (collectLocalBinders >> binds) >> in [(body, mkVarSet (collectLStmtsBinders stmts) >> `unionVarSet` defined_vars) | L _ >> (GRHS stmts body) <- grhss] >> >> This is in the desugarer. But I need to also know `length leaves` at the >> renaming stage, which >> means I need to call `concatMap leavesMatch matches`. The problem is that >> in the renamer my >> datatypes are not parametrised by `Id`. I turned `Id` into a type >> parameter `id`, but then I >> can't use VarSets. I could use more general UniqueSets but only if `id` >> type parameter is an >> instance of Uniquable. And since in the renamer the datatypes are >> parametrized with RdrName this >> leads me to wanting Uniqable RdrName instance. >> >> Janek >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Tue Jun 17 08:06:11 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 17 Jun 2014 10:06:11 +0200 Subject: Uniquable RdrName instance In-Reply-To: References: <201406161345.03423.jan.stolarek@p.lodz.pl> <201406162133.06490.jan.stolarek@p.lodz.pl> Message-ID: <201406171006.11283.jan.stolarek@p.lodz.pl> > FYI it's #7828, not #7282. Of course, yes. > would making arrow remindable involve dropping the arr == haksell functions assumption or doing > something that would allow generalized arrows? Not sure if I fully understand what you mean. There's an idea to give up on current desugaring that heavily uses arr, >>> etc. in favor of desugaring based on bind equivalents for arrows. Is this what you wanted to know? There's some discussion on the Trac you might want to follow. Janek From marlowsd at gmail.com Tue Jun 17 12:14:16 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Jun 2014 13:14:16 +0100 Subject: Phabricator for patches and code review In-Reply-To: <201406131147.21001.jan.stolarek@p.lodz.pl> References: <53941192.8080208@gmail.com> <201406131147.21001.jan.stolarek@p.lodz.pl> Message-ID: <53A03118.5000006@gmail.com> On 13/06/14 10:47, Jan Stolarek wrote: > It seems that most people are in favour of using Phabricator for code review. So what are the next > steps? Can we just start using the existing phabricator instance? I'm working on some code right > now that definitely needs reviewing. You can use it, and a few of us have already been doing so. There isn't any Trac integration yet, but it works nicely for patch review. There's a short intro doc here: https://secure.phabricator.com/book/phabricator/article/differential/, but it's not hard to figure out the basics, and you'll learn by watching how other people use it. If you go to the Herald tool you have yourself automatically subscribed to diffs that touch areas of the code that you're interested in. Pro tip: the keyboard shortcuts are really useful, especially "z". Hit "?" to see all the shortcuts. Cheers, Simon > Janek > > Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >>> So, why not put everything on GutHub and use pull requests and so on? >> >> github just isn't great for doing code reviews. No side-by-side diffs, >> and it sends you a separate email for every single comment, there's no >> concept of a "review" consisting of multiple inline comments (unless >> I've missed something). I'm afraid if we were using this for regular >> reviews I would have to disable the email notifications, which makes it >> significantly less useful. >> >>> SimonM writes that Phabricator is better than GitHub. I?m happy to >>> believe that, but he also writes that using it requires installing local >>> software and quite a bit of work. Moreover, I like to add that lots of >>> people already know how to use GitHub and probably few know Phabricator. >>> >>> So, we are talking about having a somewhat better tool in return for >>> three very significant disadvantages: (1) local installation, (2) work to >>> set up and maintain Phabricator, and (3) effort by many people to learn >>> to use it. >> >> Well, you've tipped the balance with "somewhat" and "significant" here, >> I'd say Phabricator is "significantly" better than github for code >> reviews, while installing arc is "somewhat" annoying :-) >> >> I have to admit it's not a no-brainer, but I do worry that github just >> wouldn't cut it for doing a lot of code reviewing, whereas I spend my >> life inside Phabricator so I know it works really well. >> >> What's more, github doesn't let you put animated gifs in code reviews. >> Need I say more? >> >> Cheers, >> Simon >> >>> We also have a constant lack of sufficient men power. So, why spend >>> effort on building our own infrastructure, which will only increase the >>> hurdle for contributors (as they have to deal with an unknown system)? >>> Let?s outsource the effort to GitHub. >>> >>> Manuel >>> >>> Simon Peyton Jones : >>>> At the moment GHC's main sources aren't on github, which means that that >>>> (in my highly imperfect understanding) people can't submit pull requests >>>> or use their code review mechanisms. Moreover, most people don't have >>>> commit rights on the main GHC server, so if someone wants to offer a >>>> patch they can really only do so in textual form attached to Trac. >>>> People with commit rights can make a branch, but there's a danger that >>>> over a decade we'll accumulate zillions of dead branches which people >>>> forgot to delete. I think on github the branch is in a different repo, >>>> belonging to the patch author. >>>> >>>> So we really don't have a good work flow for creating, reviewing, >>>> modifying, and finally apply patches. I am no expert on these matters. >>>> If Phabricator would help with that I'm all for it. But perhaps there >>>> are other alternatives? Or is Phab the lead thing. Will it stay >>>> around? >>>> >>>> Also before going too far I'd really like someone to document the >>>> workflow carefully, and make sure it works from Windows equally well. >>>> >>>> I'm not too stressed out about losing the review trail of a patch. Much >>>> of it will be commenting on stuff that no longer appears in the final >>>> patch. Anything that's important should appear in a Note in the source >>>> code; even the commit messages are invisible until you really start >>>> digging. >>>> >>>> Simon >>>> >>>> | -----Original Message----- >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>>> | Austin Seipp >>>> | Sent: 06 June 2014 05:06 >>>> | To: ghc-devs at haskell.org >>>> | Subject: RFC: Phabricator for patches and code review >>>> | >>>> | Hello all, >>>> | >>>> | Recently, while doing server maintenance, several of the >>>> | administrators for Haskell.org set up an instance of Phabricator[1], >>>> | located at https://phabricator.haskell.org >>>> | >>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of >>>> | tools for software development. Think of it like a polished, >>>> | semi-private GitHub with a lot of applications and tools for all kinds >>>> | of needs. We've been using it to do issue tracking for Haskell.org >>>> | maintenance and like it a lot so far. >>>> | >>>> | One very nice aspect of Phabricator though is it has a very nice code >>>> | review tool, called 'Differential', that is very useful. For people >>>> | who have used a tool like Review Board, it's similar. Furthermore, it >>>> | has a very convenient userland tool called 'Arcanist' which makes it >>>> | easy for newcomers to post a review and get it merged when it's ready >>>> | all from the command line. >>>> | >>>> | I'd like to see if people are interested in using Phab _strictly_ for >>>> | code review of GHC patches. It is a dedicated tool specifically for >>>> | this, and I think it works much better than Trac or inline GitHub >>>> | comments. >>>> | >>>> | Also, Phab can also support post-commit reviews. So if I touch >>>> | something in the runtime system and just push, perhaps Simon or Edward >>>> | would like to look, and they can be alerted right when I do this, and >>>> | then yell if I did something stupid. >>>> | >>>> | Before I go much further, I'd like to ask: is there *any* interest in >>>> | this? Or are people satisifed with Trac? The primary motivations are >>>> | roughly, in no particular order: >>>> | >>>> | 1) Code review is good for everyone, a good way for people to learn >>>> | the code and ask questions, and useful to give feedback to newcomers. >>>> | And even experienced GHC hackers can learn things from reading code, >>>> | as we all do regularly, or find things that need cleanup. >>>> | >>>> | 2) Phabricator in particular makes it very easy to submit patches for >>>> | review. To submit a patch, I just run the command 'arc diff' and it >>>> | Does The Right Thing. It also makes it easy to ensure people are >>>> | *alerted* when a patch might be relevant to them. >>>> | >>>> | 3) They can be uploaded and created from the command line, and merged >>>> | easily afterwords the same way. This is particularly useful for >>>> | newcomers, and for me. :) >>>> | >>>> | 4) Differential is dedicated to code review, and much better at it >>>> | than just reading patches on Trac IMO. >>>> | >>>> | 5) It supports both post-commit code review, as well as pre-commit >>>> | review. Post commit would be especially useful for us too, I think. >>>> | >>>> | Point #2 and #3 are mostly relevant for me, because I mostly handle >>>> | incoming patches. But I think in general it would be nice, and make it >>>> | a lot easier for newcomers to submit patches, and us to look over >>>> | them. >>>> | >>>> | Here's an example of a Differential code review: >>>> | >>>> | https://phabricator.haskell.org/D4 >>>> | >>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create an >>>> | account to login, but it shouldn't be much trouble, you can login >>>> | several ways. I'll fix the login requirement soon. Feel free to read >>>> | the code, comment on it, and play around. It's more of a >>>> | demonstration, but real code review would be welcome too. :) >>>> | >>>> | If people are interested in doing this, I can add notes to the wiki >>>> | pages for newcomers, and I'll send another email about Phab so people >>>> | can understand it a little better. But I want to ask first. >>>> | >>>> | There is an argument that our team is so small, code review has >>>> | unnecessary burdens. But I think Phab could help a lot with tracking >>>> | outside patches and getting good reviews for incoming patches, and >>>> | it'll make it easier for newcomers. And experienced pros can probably >>>> | learn a thing as well. >>>> | >>>> | Again, to be clear, I don't propose we migrate anything to Phabricator >>>> | from, say, Trac. There's no real pressure to do so and it would be >>>> | tons of work. I only propose we use it for code review, which is >>>> | perfectly fine, and how other projects like LLVM do code review (they >>>> | use Bugzilla). >>>> | >>>> | I also don't think the usage of Phabricator should be mandatory >>>> | (unless we decide that later because we like it), but I would like to >>>> | see people use it if possible. >>>> | >>>> | [1] http://phabricator.org >>>> | >>>> | -- >>>> | Regards, >>>> | >>>> | Austin Seipp, Haskell Consultant >>>> | Well-Typed LLP, http://www.well-typed.com/ >>>> | _______________________________________________ >>>> | ghc-devs mailing list >>>> | ghc-devs at haskell.org >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Tue Jun 17 14:00:41 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 17 Jun 2014 10:00:41 -0400 Subject: Uniquable RdrName instance In-Reply-To: <201406162133.06490.jan.stolarek@p.lodz.pl> References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> <201406162133.06490.jan.stolarek@p.lodz.pl> Message-ID: <7C701CC2-41BF-453B-B2C5-55D22084A1CF@cis.upenn.edu> So, without really trying to understand the code, what you are saying is this: you want a finite map from RdrNames. That seems sensible enough, if the domain elements all appear in the same scope in the Haskell source. I don't have enough perspective to say whether a Uniquable instance is the way to get to a finite map here. Richard On Jun 16, 2014, at 3:33 PM, Jan Stolarek wrote: >> Why do you want this? The danger I see lurking is that you might find two >> RdrNames that give the same answer to getUnique but represent different > Yes, that's exactly my concern. > >> Why do you want this? > I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet from desugaring of arrow > notation: > > leaves = concatMap leavesMatch matches > where > leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), IdSet)] > leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) > = let defined_vars = mkVarSet (collectPatsBinders pats) `unionVarSet` > mkVarSet (collectLocalBinders binds) > in [(body, mkVarSet (collectLStmtsBinders stmts) `unionVarSet` defined_vars) | L _ > (GRHS stmts body) <- grhss] > > This is in the desugarer. But I need to also know `length leaves` at the renaming stage, which > means I need to call `concatMap leavesMatch matches`. The problem is that in the renamer my > datatypes are not parametrised by `Id`. I turned `Id` into a type parameter `id`, but then I > can't use VarSets. I could use more general UniqueSets but only if `id` type parameter is an > instance of Uniquable. And since in the renamer the datatypes are parametrized with RdrName this > leads me to wanting Uniqable RdrName instance. > > Janek From simonpj at microsoft.com Tue Jun 17 16:00:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Jun 2014 16:00:17 +0000 Subject: Uniquable RdrName instance In-Reply-To: <201406161345.03423.jan.stolarek@p.lodz.pl> References: <201406161345.03423.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E3C09@DB3PRD3001MB020.064d.mgd.msft.net> We just haven't needed one so far. Can a RdrName and a Name have the same Unique? Well, of course that just depends on what you are using the RdrName Uniques for. It's not a question that has a yes or no answer. Does it matter if (Orig m x) and (Orig n x) have the same Unique? Same answer, except that I bet the answer is "yes it matters". FWIW the "OrigNameCache" is a finite map keyed by (ModuleName,Orig) pairs. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 16 June 2014 12:45 | To: ghc-devs at haskell.org | Subject: Uniquable RdrName instance | | Hi all, | | I just found myself in the need of Uniquable instance for RdrName. I'm | surprised that such instance does not exist already because other | datatypes like Name or OccName already have Uniquable instances. So, is | there a reason why Uniquable instance for RdrName does not exist already | (other than "it wasn't needed")? How should such an instance look like? | I made an | attempt: | | rdrNameUnique :: RdrName -> Unique | rdrNameUnique (Unqual occName) = getUnique occName rdrNameUnique (Qual _ | occName) = getUnique occName rdrNameUnique (Orig _ occName) = getUnique | occName | rdrNameUnique (Exact name ) = getUnique name | | But I suspect this might be wrong: | - cases 1 and 4 simply return a Unique for the OccName/Name stored | inside RdrName. I think this will assign the same Unique to RdrName and | corresponding OccName/Name. Is this allowed? | - cases 2 and 3 ignore the Module stored inside RdrName. Again, this | assigns the RdrName with a Unique identical to OccNames stored inside | it. | | Help appreciated. | | Janek | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Tue Jun 17 19:10:14 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 17 Jun 2014 15:10:14 -0400 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance Message-ID: to clarify: having bind would be equivalent to having arr for the purposes of my question (assuming its the standard monadic bind). having arr :: (b -> c) -> a b c is tantamount to assuming that any haskell function can be embedded in an arrow instance which prevents a lot of interesting deep embedding uses of the Arrow abstraction/ or at least makes it a bit tricker. (eg things like writing circuits or certain types of compiled FRP models). On Tue, Jun 17, 2014 at 4:06 AM, Jan Stolarek wrote: > > FYI it's #7828, not #7282. > Of course, yes. > > > would making arrow remindable involve dropping the arr == haksell > functions assumption or doing > > something that would allow generalized arrows? > Not sure if I fully understand what you mean. There's an idea to give up > on current desugaring > that heavily uses arr, >>> etc. in favor of desugaring based on bind > equivalents for arrows. Is > this what you wanted to know? There's some discussion on the Trac you > might want to follow. > > Janek > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jun 17 19:53:47 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Jun 2014 19:53:47 +0000 Subject: Uniquable RdrName instance In-Reply-To: <7C701CC2-41BF-453B-B2C5-55D22084A1CF@cis.upenn.edu> References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> <201406162133.06490.jan.stolarek@p.lodz.pl> <7C701CC2-41BF-453B-B2C5-55D22084A1CF@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E3EC4@DB3PRD3001MB020.064d.mgd.msft.net> I would require a lot of convincing that we wanted Uniques for RdrNames. I seriously doubt that, once the dust has settled, you'll need a finite map indexed by RdrNames. But even if you do, you could use a TrieMap-like structure. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 17 June 2014 15:01 | To: Jan Stolarek | Cc: ghc-devs at haskell.org | Subject: Re: Uniquable RdrName instance | | So, without really trying to understand the code, what you are saying is | this: you want a finite map from RdrNames. That seems sensible enough, if | the domain elements all appear in the same scope in the Haskell source. I | don't have enough perspective to say whether a Uniquable instance is the | way to get to a finite map here. | | Richard | | On Jun 16, 2014, at 3:33 PM, Jan Stolarek wrote: | | >> Why do you want this? The danger I see lurking is that you might find | two | >> RdrNames that give the same answer to getUnique but represent | different | > Yes, that's exactly my concern. | > | >> Why do you want this? | > I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet | from desugaring of arrow | > notation: | > | > leaves = concatMap leavesMatch matches | > where | > leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), | IdSet)] | > leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) | > = let defined_vars = mkVarSet (collectPatsBinders pats) | `unionVarSet` | > mkVarSet (collectLocalBinders | binds) | > in [(body, mkVarSet (collectLStmtsBinders stmts) | `unionVarSet` defined_vars) | L _ | > (GRHS stmts body) <- grhss] | > | > This is in the desugarer. But I need to also know `length leaves` at | the renaming stage, which | > means I need to call `concatMap leavesMatch matches`. The problem is | that in the renamer my | > datatypes are not parametrised by `Id`. I turned `Id` into a type | parameter `id`, but then I | > can't use VarSets. I could use more general UniqueSets but only if `id` | type parameter is an | > instance of Uniquable. And since in the renamer the datatypes are | parametrized with RdrName this | > leads me to wanting Uniqable RdrName instance. | > | > Janek | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Tue Jun 17 20:34:03 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 17 Jun 2014 22:34:03 +0200 Subject: Phabricator for patches and code review In-Reply-To: <53A03118.5000006@gmail.com> References: <201406131147.21001.jan.stolarek@p.lodz.pl> <53A03118.5000006@gmail.com> Message-ID: <201406172234.03985.jan.stolarek@p.lodz.pl> > You can use it, and a few of us have already been doing so. There isn't > any Trac integration yet, but it works nicely for patch review. Right. I was wondering about the inclusion of phabricator utilities in the GHC tree - I believe this was mentioned in the discussion. > There's a short intro doc here: > https://secure.phabricator.com/book/phabricator/article/differential/, > but it's not hard to figure out the basics, and you'll learn by watching > how other people use it. No doubt, although I must say that it doesn't yet feel intuitive and some UI things could be done better. > If you go to the Herald tool you have yourself > automatically subscribed to diffs that touch areas of the code that > you're interested in. Is there a way to create a notification for a particular directory in the GHC source tree? I see I can create a notification for "Any changed filename contains ..." - if I give a part of path (say compiler/basicTypes) will I get notifications if anything in that directory changes? > Pro tip: the keyboard shortcuts are really useful, especially "z". Hit > "?" to see all the shortcuts. Duh, no C-x prefix ;-) Janek From jan.stolarek at p.lodz.pl Tue Jun 17 20:37:08 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 17 Jun 2014 22:37:08 +0200 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: References: Message-ID: <201406172237.08514.jan.stolarek@p.lodz.pl> > assuming that any haskell function can be embedded in an > arrow instance (...) prevents a lot of interesting deep embedding uses of the Arrow > abstraction Could you point me to some specific examples? I'm new to arrows and definitely far from groking all the arcana of their usage. Janek From carter.schonwald at gmail.com Tue Jun 17 20:45:45 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 17 Jun 2014 16:45:45 -0400 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: <201406172237.08514.jan.stolarek@p.lodz.pl> References: <201406172237.08514.jan.stolarek@p.lodz.pl> Message-ID: ok, so one example of this design, albeit implemented in a funky way (compiler passes written in coq), was Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/ a more concrete example of a haskell lib that enjoys a deep embedding and doesn't let you inject arbitrary (f:: a-> b ) would be Accelerate hackage.haskell.org/package/accelerate (the expression language there could be made into an "*arr* free Arrow" but not an Arrow that has *arr*) basically not having *arr* or the monadic equiv *bind*, gives you a way to write libs where you can get a program as a first order AST when you "run it" and be able to analyze/compile it in user land at runtime On Tue, Jun 17, 2014 at 4:37 PM, Jan Stolarek wrote: > > assuming that any haskell function can be embedded in an > > arrow instance (...) prevents a lot of interesting deep embedding uses > of the Arrow > > abstraction > Could you point me to some specific examples? I'm new to arrows and > definitely far from groking > all the arcana of their usage. > > Janek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jun 17 20:46:34 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 17 Jun 2014 16:46:34 -0400 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: References: <201406172237.08514.jan.stolarek@p.lodz.pl> Message-ID: Conal (cc'd) also has an ongoing blog series about this http://conal.net/blog/ On Tue, Jun 17, 2014 at 4:45 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > ok, so one example of this design, albeit implemented in a funky way > (compiler passes written in coq), was > Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/ > > a more concrete example of a haskell lib that enjoys a deep embedding and > doesn't let you inject arbitrary (f:: a-> b ) > would be Accelerate hackage.haskell.org/package/accelerate (the > expression language there could be made into an "*arr* free Arrow" but > not an Arrow that has *arr*) > > basically not having *arr* or the monadic equiv *bind*, gives you a way > to write libs where you can get a program as a first order AST when you > "run it" and be able to analyze/compile it in user land at runtime > > > > On Tue, Jun 17, 2014 at 4:37 PM, Jan Stolarek > wrote: > >> > assuming that any haskell function can be embedded in an >> > arrow instance (...) prevents a lot of interesting deep embedding uses >> of the Arrow >> > abstraction >> Could you point me to some specific examples? I'm new to arrows and >> definitely far from groking >> all the arcana of their usage. >> >> Janek >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Jun 17 21:33:27 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 17 Jun 2014 14:33:27 -0700 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: References: <201406172237.08514.jan.stolarek@p.lodz.pl> Message-ID: Did you mean pure/return as the monadic equivalent? I've frequently encountered embeddings where it's possible to have a valid <*> and >>= but not pure (or fmap). On Jun 17, 2014 1:46 PM, "Carter Schonwald" wrote: > > ok, so one example of this design, albeit implemented in a funky way (compiler passes written in coq), was > Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/ > > a more concrete example of a haskell lib that enjoys a deep embedding and doesn't let you inject arbitrary (f:: a-> b ) > would be Accelerate hackage.haskell.org/package/accelerate (the expression language there could be made into an "arr free Arrow" but not an Arrow that has arr) > > basically not having arr or the monadic equiv bind, gives you a way to write libs where you can get a program as a first order AST when you "run it" and be able to analyze/compile it in user land at runtime > > > > On Tue, Jun 17, 2014 at 4:37 PM, Jan Stolarek wrote: >> >> > assuming that any haskell function can be embedded in an >> > arrow instance (...) prevents a lot of interesting deep embedding uses of the Arrow >> > abstraction >> Could you point me to some specific examples? I'm new to arrows and definitely far from groking >> all the arcana of their usage. >> >> Janek > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jun 17 21:41:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 17 Jun 2014 17:41:27 -0400 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: References: <201406172237.08514.jan.stolarek@p.lodz.pl> Message-ID: yes, that what I meant, though the standard >>= does need to be used carefully on a restricted universe of types to ensure you can get a deep embedding On Tue, Jun 17, 2014 at 5:33 PM, John Lato wrote: > Did you mean pure/return as the monadic equivalent? I've frequently > encountered embeddings where it's possible to have a valid <*> and >>= but > not pure (or fmap). > > On Jun 17, 2014 1:46 PM, "Carter Schonwald" > wrote: > > > > ok, so one example of this design, albeit implemented in a funky way > (compiler passes written in coq), was > > Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/ > > > > a more concrete example of a haskell lib that enjoys a deep embedding > and doesn't let you inject arbitrary (f:: a-> b ) > > would be Accelerate hackage.haskell.org/package/accelerate (the > expression language there could be made into an "arr free Arrow" but not an > Arrow that has arr) > > > > basically not having arr or the monadic equiv bind, gives you a way to > write libs where you can get a program as a first order AST when you "run > it" and be able to analyze/compile it in user land at runtime > > > > > > > > On Tue, Jun 17, 2014 at 4:37 PM, Jan Stolarek > wrote: > >> > >> > assuming that any haskell function can be embedded in an > >> > arrow instance (...) prevents a lot of interesting deep embedding > uses of the Arrow > >> > abstraction > >> Could you point me to some specific examples? I'm new to arrows and > definitely far from groking > >> all the arcana of their usage. > >> > >> Janek > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Paterson at city.ac.uk Wed Jun 18 00:06:09 2014 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Wed, 18 Jun 2014 01:06:09 +0100 Subject: Deep embeddings and Arrows Re: Uniquable RdrName instance In-Reply-To: References: Message-ID: <20140618000609.GA10818@city.ac.uk> On Tue, Jun 17, 2014 at 03:10:14PM -0400, Carter Schonwald wrote: > to clarify: having bind would be equivalent to having arr for the > purposes of my question (assuming its the standard monadic bind). > > having?arr?:: (b -> c) -> a b c > > is tantamount to assuming that any haskell function can be embedded in > an arrow instance which prevents a lot of interesting deep embedding > uses of the Arrow abstraction/ or at least makes it a bit tricker. > (eg things like writing circuits or certain types of compiled FRP models).? I have two answers: First, it's not that difficult using the Arrow class. For example, see the netlist example at the end of my "Fun of Programming" slides (http://www.soi.city.ac.uk/~ross/papers/fop.html). The idea is that arr can take any function, but if you require the circuit to be parametric in the value types, you can limit the types of function the programmer can pass to arr to simple plumbing. Second, suppose we split arr :: forall b c. (b -> c) -> a b c into two primitives (^>>) :: forall b c d. (b -> c) -> a c d -> a b d id :: forall b. a b b Arrow notation relies on (^>>) being a contravariant functor -- that's what allows the translation to manipulate environments, and it gives you a substitution property for commands. On the other hand it doesn't need id (or equivalently returnA). Perhaps the problem is the universally quantified b in the type of id. One might instead use a variant of id constrained to an ADT with just the operations you want. From jan.stolarek at p.lodz.pl Wed Jun 18 07:36:27 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 18 Jun 2014 09:36:27 +0200 Subject: Phabricator for patches and code review In-Reply-To: <53A03118.5000006@gmail.com> References: <201406131147.21001.jan.stolarek@p.lodz.pl> <53A03118.5000006@gmail.com> Message-ID: <201406180936.27364.jan.stolarek@p.lodz.pl> I read the friendly Arcanist manual and I wonder if we intend to have a default .arcconfig file in the GHC repo? From the docs it seems like a good idea. Janek Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: > On 13/06/14 10:47, Jan Stolarek wrote: > > It seems that most people are in favour of using Phabricator for code > > review. So what are the next steps? Can we just start using the existing > > phabricator instance? I'm working on some code right now that definitely > > needs reviewing. > > You can use it, and a few of us have already been doing so. There isn't > any Trac integration yet, but it works nicely for patch review. > > There's a short intro doc here: > https://secure.phabricator.com/book/phabricator/article/differential/, > but it's not hard to figure out the basics, and you'll learn by watching > how other people use it. If you go to the Herald tool you have yourself > automatically subscribed to diffs that touch areas of the code that > you're interested in. > > Pro tip: the keyboard shortcuts are really useful, especially "z". Hit > "?" to see all the shortcuts. > > Cheers, > Simon > > > Janek > > > > Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: > >> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > >>> So, why not put everything on GutHub and use pull requests and so on? > >> > >> github just isn't great for doing code reviews. No side-by-side diffs, > >> and it sends you a separate email for every single comment, there's no > >> concept of a "review" consisting of multiple inline comments (unless > >> I've missed something). I'm afraid if we were using this for regular > >> reviews I would have to disable the email notifications, which makes it > >> significantly less useful. > >> > >>> SimonM writes that Phabricator is better than GitHub. I?m happy to > >>> believe that, but he also writes that using it requires installing > >>> local software and quite a bit of work. Moreover, I like to add that > >>> lots of people already know how to use GitHub and probably few know > >>> Phabricator. > >>> > >>> So, we are talking about having a somewhat better tool in return for > >>> three very significant disadvantages: (1) local installation, (2) work > >>> to set up and maintain Phabricator, and (3) effort by many people to > >>> learn to use it. > >> > >> Well, you've tipped the balance with "somewhat" and "significant" here, > >> I'd say Phabricator is "significantly" better than github for code > >> reviews, while installing arc is "somewhat" annoying :-) > >> > >> I have to admit it's not a no-brainer, but I do worry that github just > >> wouldn't cut it for doing a lot of code reviewing, whereas I spend my > >> life inside Phabricator so I know it works really well. > >> > >> What's more, github doesn't let you put animated gifs in code reviews. > >> Need I say more? > >> > >> Cheers, > >> Simon > >> > >>> We also have a constant lack of sufficient men power. So, why spend > >>> effort on building our own infrastructure, which will only increase the > >>> hurdle for contributors (as they have to deal with an unknown system)? > >>> Let?s outsource the effort to GitHub. > >>> > >>> Manuel > >>> > >>> Simon Peyton Jones : > >>>> At the moment GHC's main sources aren't on github, which means that > >>>> that (in my highly imperfect understanding) people can't submit pull > >>>> requests or use their code review mechanisms. Moreover, most people > >>>> don't have commit rights on the main GHC server, so if someone wants > >>>> to offer a patch they can really only do so in textual form attached > >>>> to Trac. People with commit rights can make a branch, but there's a > >>>> danger that over a decade we'll accumulate zillions of dead branches > >>>> which people forgot to delete. I think on github the branch is in a > >>>> different repo, belonging to the patch author. > >>>> > >>>> So we really don't have a good work flow for creating, reviewing, > >>>> modifying, and finally apply patches. I am no expert on these > >>>> matters. If Phabricator would help with that I'm all for it. But > >>>> perhaps there are other alternatives? Or is Phab the lead thing. > >>>> Will it stay around? > >>>> > >>>> Also before going too far I'd really like someone to document the > >>>> workflow carefully, and make sure it works from Windows equally well. > >>>> > >>>> I'm not too stressed out about losing the review trail of a patch. > >>>> Much of it will be commenting on stuff that no longer appears in the > >>>> final patch. Anything that's important should appear in a Note in the > >>>> source code; even the commit messages are invisible until you really > >>>> start digging. > >>>> > >>>> Simon > >>>> > >>>> | -----Original Message----- > >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > >>>> | Austin Seipp > >>>> | Sent: 06 June 2014 05:06 > >>>> | To: ghc-devs at haskell.org > >>>> | Subject: RFC: Phabricator for patches and code review > >>>> | > >>>> | Hello all, > >>>> | > >>>> | Recently, while doing server maintenance, several of the > >>>> | administrators for Haskell.org set up an instance of Phabricator[1], > >>>> | located at https://phabricator.haskell.org > >>>> | > >>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of > >>>> | tools for software development. Think of it like a polished, > >>>> | semi-private GitHub with a lot of applications and tools for all > >>>> | kinds of needs. We've been using it to do issue tracking for > >>>> | Haskell.org maintenance and like it a lot so far. > >>>> | > >>>> | One very nice aspect of Phabricator though is it has a very nice > >>>> | code review tool, called 'Differential', that is very useful. For > >>>> | people who have used a tool like Review Board, it's similar. > >>>> | Furthermore, it has a very convenient userland tool called > >>>> | 'Arcanist' which makes it easy for newcomers to post a review and > >>>> | get it merged when it's ready all from the command line. > >>>> | > >>>> | I'd like to see if people are interested in using Phab _strictly_ > >>>> | for code review of GHC patches. It is a dedicated tool specifically > >>>> | for this, and I think it works much better than Trac or inline > >>>> | GitHub comments. > >>>> | > >>>> | Also, Phab can also support post-commit reviews. So if I touch > >>>> | something in the runtime system and just push, perhaps Simon or > >>>> | Edward would like to look, and they can be alerted right when I do > >>>> | this, and then yell if I did something stupid. > >>>> | > >>>> | Before I go much further, I'd like to ask: is there *any* interest > >>>> | in this? Or are people satisifed with Trac? The primary motivations > >>>> | are roughly, in no particular order: > >>>> | > >>>> | 1) Code review is good for everyone, a good way for people to learn > >>>> | the code and ask questions, and useful to give feedback to > >>>> | newcomers. And even experienced GHC hackers can learn things from > >>>> | reading code, as we all do regularly, or find things that need > >>>> | cleanup. > >>>> | > >>>> | 2) Phabricator in particular makes it very easy to submit patches > >>>> | for review. To submit a patch, I just run the command 'arc diff' and > >>>> | it Does The Right Thing. It also makes it easy to ensure people are > >>>> | *alerted* when a patch might be relevant to them. > >>>> | > >>>> | 3) They can be uploaded and created from the command line, and > >>>> | merged easily afterwords the same way. This is particularly useful > >>>> | for newcomers, and for me. :) > >>>> | > >>>> | 4) Differential is dedicated to code review, and much better at it > >>>> | than just reading patches on Trac IMO. > >>>> | > >>>> | 5) It supports both post-commit code review, as well as pre-commit > >>>> | review. Post commit would be especially useful for us too, I think. > >>>> | > >>>> | Point #2 and #3 are mostly relevant for me, because I mostly handle > >>>> | incoming patches. But I think in general it would be nice, and make > >>>> | it a lot easier for newcomers to submit patches, and us to look over > >>>> | them. > >>>> | > >>>> | Here's an example of a Differential code review: > >>>> | > >>>> | https://phabricator.haskell.org/D4 > >>>> | > >>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create an > >>>> | account to login, but it shouldn't be much trouble, you can login > >>>> | several ways. I'll fix the login requirement soon. Feel free to read > >>>> | the code, comment on it, and play around. It's more of a > >>>> | demonstration, but real code review would be welcome too. :) > >>>> | > >>>> | If people are interested in doing this, I can add notes to the wiki > >>>> | pages for newcomers, and I'll send another email about Phab so > >>>> | people can understand it a little better. But I want to ask first. > >>>> | > >>>> | There is an argument that our team is so small, code review has > >>>> | unnecessary burdens. But I think Phab could help a lot with tracking > >>>> | outside patches and getting good reviews for incoming patches, and > >>>> | it'll make it easier for newcomers. And experienced pros can > >>>> | probably learn a thing as well. > >>>> | > >>>> | Again, to be clear, I don't propose we migrate anything to > >>>> | Phabricator from, say, Trac. There's no real pressure to do so and > >>>> | it would be tons of work. I only propose we use it for code review, > >>>> | which is perfectly fine, and how other projects like LLVM do code > >>>> | review (they use Bugzilla). > >>>> | > >>>> | I also don't think the usage of Phabricator should be mandatory > >>>> | (unless we decide that later because we like it), but I would like > >>>> | to see people use it if possible. > >>>> | > >>>> | [1] http://phabricator.org > >>>> | > >>>> | -- > >>>> | Regards, > >>>> | > >>>> | Austin Seipp, Haskell Consultant > >>>> | Well-Typed LLP, http://www.well-typed.com/ > >>>> | _______________________________________________ > >>>> | ghc-devs mailing list > >>>> | ghc-devs at haskell.org > >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs > >>>> > >>>> _______________________________________________ > >>>> ghc-devs mailing list > >>>> ghc-devs at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Wed Jun 18 07:38:04 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 18 Jun 2014 09:38:04 +0200 Subject: Phabricator for patches and code review In-Reply-To: <201406180936.27364.jan.stolarek@p.lodz.pl> References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> Message-ID: <201406180938.04852.jan.stolarek@p.lodz.pl> Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) Janek Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: > I read the friendly Arcanist manual and I wonder if we intend to have a > default .arcconfig file in the GHC repo? From the docs it seems like a good > idea. > > Janek > > Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: > > On 13/06/14 10:47, Jan Stolarek wrote: > > > It seems that most people are in favour of using Phabricator for code > > > review. So what are the next steps? Can we just start using the > > > existing phabricator instance? I'm working on some code right now that > > > definitely needs reviewing. > > > > You can use it, and a few of us have already been doing so. There isn't > > any Trac integration yet, but it works nicely for patch review. > > > > There's a short intro doc here: > > https://secure.phabricator.com/book/phabricator/article/differential/, > > but it's not hard to figure out the basics, and you'll learn by watching > > how other people use it. If you go to the Herald tool you have yourself > > automatically subscribed to diffs that touch areas of the code that > > you're interested in. > > > > Pro tip: the keyboard shortcuts are really useful, especially "z". Hit > > "?" to see all the shortcuts. > > > > Cheers, > > Simon > > > > > Janek > > > > > > Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: > > >> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > > >>> So, why not put everything on GutHub and use pull requests and so on? > > >> > > >> github just isn't great for doing code reviews. No side-by-side diffs, > > >> and it sends you a separate email for every single comment, there's no > > >> concept of a "review" consisting of multiple inline comments (unless > > >> I've missed something). I'm afraid if we were using this for regular > > >> reviews I would have to disable the email notifications, which makes > > >> it significantly less useful. > > >> > > >>> SimonM writes that Phabricator is better than GitHub. I?m happy to > > >>> believe that, but he also writes that using it requires installing > > >>> local software and quite a bit of work. Moreover, I like to add that > > >>> lots of people already know how to use GitHub and probably few know > > >>> Phabricator. > > >>> > > >>> So, we are talking about having a somewhat better tool in return for > > >>> three very significant disadvantages: (1) local installation, (2) > > >>> work to set up and maintain Phabricator, and (3) effort by many > > >>> people to learn to use it. > > >> > > >> Well, you've tipped the balance with "somewhat" and "significant" > > >> here, I'd say Phabricator is "significantly" better than github for > > >> code reviews, while installing arc is "somewhat" annoying :-) > > >> > > >> I have to admit it's not a no-brainer, but I do worry that github just > > >> wouldn't cut it for doing a lot of code reviewing, whereas I spend my > > >> life inside Phabricator so I know it works really well. > > >> > > >> What's more, github doesn't let you put animated gifs in code reviews. > > >> Need I say more? > > >> > > >> Cheers, > > >> Simon > > >> > > >>> We also have a constant lack of sufficient men power. So, why spend > > >>> effort on building our own infrastructure, which will only increase > > >>> the hurdle for contributors (as they have to deal with an unknown > > >>> system)? Let?s outsource the effort to GitHub. > > >>> > > >>> Manuel > > >>> > > >>> Simon Peyton Jones : > > >>>> At the moment GHC's main sources aren't on github, which means that > > >>>> that (in my highly imperfect understanding) people can't submit pull > > >>>> requests or use their code review mechanisms. Moreover, most people > > >>>> don't have commit rights on the main GHC server, so if someone wants > > >>>> to offer a patch they can really only do so in textual form attached > > >>>> to Trac. People with commit rights can make a branch, but there's a > > >>>> danger that over a decade we'll accumulate zillions of dead branches > > >>>> which people forgot to delete. I think on github the branch is in a > > >>>> different repo, belonging to the patch author. > > >>>> > > >>>> So we really don't have a good work flow for creating, reviewing, > > >>>> modifying, and finally apply patches. I am no expert on these > > >>>> matters. If Phabricator would help with that I'm all for it. But > > >>>> perhaps there are other alternatives? Or is Phab the lead thing. > > >>>> Will it stay around? > > >>>> > > >>>> Also before going too far I'd really like someone to document the > > >>>> workflow carefully, and make sure it works from Windows equally > > >>>> well. > > >>>> > > >>>> I'm not too stressed out about losing the review trail of a patch. > > >>>> Much of it will be commenting on stuff that no longer appears in the > > >>>> final patch. Anything that's important should appear in a Note in > > >>>> the source code; even the commit messages are invisible until you > > >>>> really start digging. > > >>>> > > >>>> Simon > > >>>> > > >>>> | -----Original Message----- > > >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > > >>>> | Austin Seipp > > >>>> | Sent: 06 June 2014 05:06 > > >>>> | To: ghc-devs at haskell.org > > >>>> | Subject: RFC: Phabricator for patches and code review > > >>>> | > > >>>> | Hello all, > > >>>> | > > >>>> | Recently, while doing server maintenance, several of the > > >>>> | administrators for Haskell.org set up an instance of > > >>>> | Phabricator[1], located at https://phabricator.haskell.org > > >>>> | > > >>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of > > >>>> | tools for software development. Think of it like a polished, > > >>>> | semi-private GitHub with a lot of applications and tools for all > > >>>> | kinds of needs. We've been using it to do issue tracking for > > >>>> | Haskell.org maintenance and like it a lot so far. > > >>>> | > > >>>> | One very nice aspect of Phabricator though is it has a very nice > > >>>> | code review tool, called 'Differential', that is very useful. For > > >>>> | people who have used a tool like Review Board, it's similar. > > >>>> | Furthermore, it has a very convenient userland tool called > > >>>> | 'Arcanist' which makes it easy for newcomers to post a review and > > >>>> | get it merged when it's ready all from the command line. > > >>>> | > > >>>> | I'd like to see if people are interested in using Phab _strictly_ > > >>>> | for code review of GHC patches. It is a dedicated tool > > >>>> | specifically for this, and I think it works much better than Trac > > >>>> | or inline GitHub comments. > > >>>> | > > >>>> | Also, Phab can also support post-commit reviews. So if I touch > > >>>> | something in the runtime system and just push, perhaps Simon or > > >>>> | Edward would like to look, and they can be alerted right when I do > > >>>> | this, and then yell if I did something stupid. > > >>>> | > > >>>> | Before I go much further, I'd like to ask: is there *any* interest > > >>>> | in this? Or are people satisifed with Trac? The primary > > >>>> | motivations are roughly, in no particular order: > > >>>> | > > >>>> | 1) Code review is good for everyone, a good way for people to > > >>>> | learn the code and ask questions, and useful to give feedback to > > >>>> | newcomers. And even experienced GHC hackers can learn things from > > >>>> | reading code, as we all do regularly, or find things that need > > >>>> | cleanup. > > >>>> | > > >>>> | 2) Phabricator in particular makes it very easy to submit patches > > >>>> | for review. To submit a patch, I just run the command 'arc diff' > > >>>> | and it Does The Right Thing. It also makes it easy to ensure > > >>>> | people are *alerted* when a patch might be relevant to them. > > >>>> | > > >>>> | 3) They can be uploaded and created from the command line, and > > >>>> | merged easily afterwords the same way. This is particularly useful > > >>>> | for newcomers, and for me. :) > > >>>> | > > >>>> | 4) Differential is dedicated to code review, and much better at > > >>>> | it than just reading patches on Trac IMO. > > >>>> | > > >>>> | 5) It supports both post-commit code review, as well as > > >>>> | pre-commit review. Post commit would be especially useful for us > > >>>> | too, I think. > > >>>> | > > >>>> | Point #2 and #3 are mostly relevant for me, because I mostly > > >>>> | handle incoming patches. But I think in general it would be nice, > > >>>> | and make it a lot easier for newcomers to submit patches, and us > > >>>> | to look over them. > > >>>> | > > >>>> | Here's an example of a Differential code review: > > >>>> | > > >>>> | https://phabricator.haskell.org/D4 > > >>>> | > > >>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create > > >>>> | an account to login, but it shouldn't be much trouble, you can > > >>>> | login several ways. I'll fix the login requirement soon. Feel free > > >>>> | to read the code, comment on it, and play around. It's more of a > > >>>> | demonstration, but real code review would be welcome too. :) > > >>>> | > > >>>> | If people are interested in doing this, I can add notes to the > > >>>> | wiki pages for newcomers, and I'll send another email about Phab > > >>>> | so people can understand it a little better. But I want to ask > > >>>> | first. > > >>>> | > > >>>> | There is an argument that our team is so small, code review has > > >>>> | unnecessary burdens. But I think Phab could help a lot with > > >>>> | tracking outside patches and getting good reviews for incoming > > >>>> | patches, and it'll make it easier for newcomers. And experienced > > >>>> | pros can probably learn a thing as well. > > >>>> | > > >>>> | Again, to be clear, I don't propose we migrate anything to > > >>>> | Phabricator from, say, Trac. There's no real pressure to do so and > > >>>> | it would be tons of work. I only propose we use it for code > > >>>> | review, which is perfectly fine, and how other projects like LLVM > > >>>> | do code review (they use Bugzilla). > > >>>> | > > >>>> | I also don't think the usage of Phabricator should be mandatory > > >>>> | (unless we decide that later because we like it), but I would like > > >>>> | to see people use it if possible. > > >>>> | > > >>>> | [1] http://phabricator.org > > >>>> | > > >>>> | -- > > >>>> | Regards, > > >>>> | > > >>>> | Austin Seipp, Haskell Consultant > > >>>> | Well-Typed LLP, http://www.well-typed.com/ > > >>>> | _______________________________________________ > > >>>> | ghc-devs mailing list > > >>>> | ghc-devs at haskell.org > > >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs > > >>>> > > >>>> _______________________________________________ > > >>>> ghc-devs mailing list > > >>>> ghc-devs at haskell.org > > >>>> http://www.haskell.org/mailman/listinfo/ghc-devs > > >>> > > >>> _______________________________________________ > > >>> ghc-devs mailing list > > >>> ghc-devs at haskell.org > > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > > >> > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs at haskell.org > > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From tom-lists-ghc-devs at jaguarpaw.co.uk Wed Jun 18 13:43:05 2014 From: tom-lists-ghc-devs at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 18 Jun 2014 14:43:05 +0100 Subject: Case expressions in STG Message-ID: <20140618134305.GA13172@henry> I am reading SPJ's seminal work "Implementing lazy functional languages on stock hardware: the Spinless Tagless G-machine" (1992). The paper is available here http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 On p62 we see "The expression scrutinised by a case expression must eventually evaluate either to a primitive value or a constructor application.". This doesn't make sense to me. Isn't the following a valid STG program? What am I missing? Where is it specified that the scrutinee of a case expression cannot be of a function type? {x} \n {z} -> let f = \{x} \n {y} -> g x y in case f of f' -> f' z Thanks, Tom From william.knop.nospam at gmail.com Wed Jun 18 20:10:20 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Wed, 18 Jun 2014 16:10:20 -0400 Subject: Continuous Integration and Cross Compilation Message-ID: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> Hello all, I?ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It?s troublesome not only because it?s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: 1. Implement proper cross-compilation, such that build and host may be different? e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. 3. Send the package to our buildbots, and run the test suite. 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. Cheers, Will * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don?t think this conflicts with the desire to use Phabricator, either, so I?ll send details and motivations to that thread. From simonpj at microsoft.com Wed Jun 18 22:47:51 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Jun 2014 22:47:51 +0000 Subject: Offering GHC builder build slaves In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> References: <53434B93.9000201@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0EA61E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E53C8@DB3PRD3001MB020.064d.mgd.msft.net> Back in April I said: | Seriously, I advertised a couple of weeks ago for help with our nightly- | build infrastructure. Quite a few people responded -- thank you very | much. | | So we have willing horsepower. But the moment we lack leadership. Alain | rightly says "I don't know what the process is" because we don't *have* a | process. We need a mechanism for creating a process, taking decisions, | etc. | | I think what is needed is: | | * A group of people willing to act as a kind of committee. That | could be everyone who replied. You could create a mailing list, | or (initially better) just chat on ghc-devs. But it would be | useful to have a list of who is involved. | | * Someone (or a couple of people) to play the role of chair. | That doesn't mean an autocrat... it means someone who gently pushes | discussions to a conclusion, and says "I propose that we do X". | | * Then the group can formulate a plan and proceed with it. | For example, should Pali's efforts be "blessed"? I don't | know enough to know, but you guys do. | | In my experience, people are often unwilling to put themselves forward as | chair, not because they are unwilling, but because they feel it'd be | "pushy". So I suggest this: if you think (based on the traffic you've | seen) that X would be a chair you'd trust, suggest them. | | In short: power to the people! GHC is your compiler. Since then various people have done various things, but so far as I know we don't have any of the three "*" items above. The people who seem in principle willing to help include Joachim Breitner Herbert Valerio Riedel P?li G?bor J?nos Karel Gardas Alain O'Dea William Knop Austin Seipp There may well be others! I sense that the problem is not willingness but simply that no one feels accredited to take the lead. Please, I would love someone to do so! I was reminded of this by William Knop's recent message below, in which he implicitly offers to help (thanks William). But his offer will fall on deaf ears unless that little group exists to welcome him in. In hope, and with thanks, Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of William | Knop | Sent: 18 June 2014 21:10 | To: ghc-devs at haskell.org | Subject: Continuous Integration and Cross Compilation | | Hello all, | | I've seen quite a few comments on the list and elsewhere lamenting the | time it takes to compile and validate ghc. It's troublesome not only | because it's inconvenient, but, more seriously, people are holding off on | sending patches in which stifles development. I would like to propose a | solution: | | 1. Implement proper cross-compilation, such that build and host may be | different- e.g. a linux x86_64 machine can build ghc that runs on Windows | x86. What sort of work would this entail? | | 2. Batch cross-compiled builds for all OSs/archs on a continuous | integration service (e.g. Travis CI) or cloud service, then package up | the binaries with the test suite. | | 3. Send the package to our buildbots, and run the test suite. | | 4. (optional) If using a CI service, have the buildbots send results back | to the CI. This could be useful if we'd use GitHub for pulls in the | future *. | | Cheers, | Will | | | * I realize vanilla GitHub currently has certain annoying limitations, | though some of them are pretty easy to solve via the github-services | and/or webhooks. I don't think this conflicts with the desire to use | Phabricator, either, so I'll send details and motivations to that thread. | From william.knop.nospam at gmail.com Wed Jun 18 22:54:02 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Wed, 18 Jun 2014 18:54:02 -0400 Subject: Case expressions in STG In-Reply-To: <20140618134305.GA13172@henry> References: <20140618134305.GA13172@henry> Message-ID: <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> Hi Tom, SPJ is surely more qualified to answer than I, but I'll take a stab. In general, it is computationally infeasible to compare functions. Granted, in your example, the function isn't being compared-- and therefore the case expr is extraneous. I don't think there exists a feasible, uncontrived example, so I imagine that's why STG forbids it (though I don't know where it's specified). Cheers, Will > On Jun 18, 2014, at 9:43 AM, Tom Ellis wrote: > > I am reading SPJ's seminal work "Implementing lazy functional languages on > stock hardware: the Spinless Tagless G-machine" (1992). The paper is > available here > > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 > > On p62 we see "The expression scrutinised by a case expression must > eventually evaluate either to a primitive value or a constructor > application.". > > This doesn't make sense to me. Isn't the following a valid STG program? > What am I missing? Where is it specified that the scrutinee of a case > expression cannot be of a function type? > > {x} \n {z} -> let f = \{x} \n {y} -> g x y > in case f of f' -> f' z > > Thanks, > > Tom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Wed Jun 18 23:04:22 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Jun 2014 23:04:22 +0000 Subject: Case expressions in STG In-Reply-To: <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> I've forgotten what I intended in the STG paper, but GHC's Core language certainly allows case on a function; all it does is to force the function to head normal form. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of William | Knop | Sent: 18 June 2014 23:54 | To: ghc-devs at haskell.org | Subject: Re: Case expressions in STG | | Hi Tom, | | SPJ is surely more qualified to answer than I, but I'll take a stab. | | In general, it is computationally infeasible to compare functions. | Granted, in your example, the function isn't being compared-- and | therefore the case expr is extraneous. I don't think there exists a | feasible, uncontrived example, so I imagine that's why STG forbids it | (though I don't know where it's specified). | | Cheers, | Will | | | > On Jun 18, 2014, at 9:43 AM, Tom Ellis wrote: | > | > I am reading SPJ's seminal work "Implementing lazy functional languages | on | > stock hardware: the Spinless Tagless G-machine" (1992). The paper is | > available here | > | > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 | > | > On p62 we see "The expression scrutinised by a case expression must | > eventually evaluate either to a primitive value or a constructor | > application.". | > | > This doesn't make sense to me. Isn't the following a valid STG | program? | > What am I missing? Where is it specified that the scrutinee of a case | > expression cannot be of a function type? | > | > {x} \n {z} -> let f = \{x} \n {y} -> g x y | > in case f of f' -> f' z | > | > Thanks, | > | > Tom | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From komadori at gekkou.co.uk Wed Jun 18 23:27:08 2014 From: komadori at gekkou.co.uk (Robin KAY) Date: Thu, 19 Jun 2014 00:27:08 +0100 Subject: GHC MinGW distribution In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53A2204C.4080405@gekkou.co.uk> Dear Simon et al., On 10/06/14 09:25, Simon Peyton Jones wrote: [snip] > I'm sure that others will be happy to help. Do keep ghc-devs posted. You could make a ticket and post information to it as you learn about it. Or even a wiki page to describe the process, so that in four years time when someone wants to do the same thing, they have a guide. Speaking of which, do search the Trac Wiki in case someone *has* already docuemented some aspects of this. Thanks for your encouragement. I hope to have some time to start working on this shortly and have created ticket #9218 [1] to track my progress. [1] https://ghc.haskell.org/trac/ghc/ticket/9218 Regards, -- Robin KAY From william.knop.nospam at gmail.com Wed Jun 18 23:40:26 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Wed, 18 Jun 2014 19:40:26 -0400 Subject: Case expressions in STG In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> Whoops, looks like my phone dropped Tom from the CC (fixed). Simon, what about the following: f = \x -> x g = \x -> (x,1) h = \x -> fst (g x) i = \x -> case f of f -> True _ -> False i f => True i h => ? If g isn't inlined into h and fst optimized out, wouldn't the head normal form of f and h be different, and the comparison fail even though it shouldn't? Or should it? I've taken function equality to be "f and g are equal iff f x == g x, for all x." Will > On Jun 18, 2014, at 7:04 PM, Simon Peyton Jones wrote: > > I've forgotten what I intended in the STG paper, but GHC's Core language certainly allows case on a function; all it does is to force the function to head normal form. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of William > | Knop > | Sent: 18 June 2014 23:54 > | To: ghc-devs at haskell.org > | Subject: Re: Case expressions in STG > | > | Hi Tom, > | > | SPJ is surely more qualified to answer than I, but I'll take a stab. > | > | In general, it is computationally infeasible to compare functions. > | Granted, in your example, the function isn't being compared-- and > | therefore the case expr is extraneous. I don't think there exists a > | feasible, uncontrived example, so I imagine that's why STG forbids it > | (though I don't know where it's specified). > | > | Cheers, > | Will > | > | > | > On Jun 18, 2014, at 9:43 AM, Tom Ellis | devs at jaguarpaw.co.uk> wrote: > | > > | > I am reading SPJ's seminal work "Implementing lazy functional languages > | on > | > stock hardware: the Spinless Tagless G-machine" (1992). The paper is > | > available here > | > > | > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 > | > > | > On p62 we see "The expression scrutinised by a case expression must > | > eventually evaluate either to a primitive value or a constructor > | > application.". > | > > | > This doesn't make sense to me. Isn't the following a valid STG > | program? > | > What am I missing? Where is it specified that the scrutinee of a case > | > expression cannot be of a function type? > | > > | > {x} \n {z} -> let f = \{x} \n {y} -> g x y > | > in case f of f' -> f' z > | > > | > Thanks, > | > > | > Tom > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Wed Jun 18 23:53:08 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 18 Jun 2014 18:53:08 -0500 Subject: Continuous Integration and Cross Compilation In-Reply-To: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> Message-ID: Hi William, Thanks for the email. Here're some things to consider. For one, cross compilation is a hot topic, but it is going to be a rather large amount of work to fix and it won't be easy. The primary problem is that we need to make Template Haskell cross-compile, but in general this is nontrivial: TemplateHaskell must load and run object code on the *host* platform, but the compiler must generate code for the *target* platform. There are ways around some of these problems; for one, we could compile every module twice, once for the host, and once for the target. Upon requesting TH, the Host GHC would load Host Object Code, but the final executable would link with the Target Object Code. There are many, many subtle points to consider if we go down this route - what happens for example if I cross compile from a 64bit machine to a 32bit one, but TemplateHaskell wants some knowledge like what "sizeOf (undefined :: CLong)" is? The host code sees a 64-bit quantity while the target actually will deal with a 32bit one. This could later explode horribly. And this isn't limited to different endianness either - it applies to the ABI in general. 64bit Linux -> 64bit Windows would be just as problematic with this exact case, as one uses LP64, while the other uses LLP64 data models. So #1 by itself is a very, very non-trivial amount of work, and IMO I don't think it's necessary for better builds. There are other routes possible for cross compilation perhaps, but I'd speculate they are all equally as non-trivial as this one. Finally, the remainder of the scheme, including shipping builds to remote machines and have them be tested sounds a bit more complicated, and I'm wondering what the advantages are. In particular it seems like this merely exposes more opportunities for failure points in the CI system, because now all CI depends on cross compilation working properly, being able to ship reports back and forth, and more. Depending on CC in particular is a huge burden it sounds: it makes it hard to distinguish when a cross-compilation bug may cause a failure as opposed to a changeset from a committer, which widens the scope of what we need to consider. A CI system should be absolutely as predictable as possible, and this adds a *lot* of variables to the mix. Cross compilation is really something that's not just one big task - there will be many *small* bugs laying in wait after that, the pain of a thousand cuts. Really, we need to distinguish between two needs: 1) Continuous integration. 2) Nightly builds. These two systems have very different needs in practice: 1) A CI system needs to be *fast*, and it needs to have dedicated resources to respond to changes quickly. This means we need to *minimize* the amount of time for developer turn around to see results. That includes minimizing the needed configurations. Shipping builds to remote machines just for CI would greatly complicate this and likely make it far longer on its own, not to mention it increases with every system we add. 2) A nightly build system is under nowhere near the same time constraints, although it also needs to be dedicated. If an ARM/Linux machine takes 6 hours to build (perhaps it's shared or something, or just really wimpy), that's totally acceptable. These can then report nightly about the results and we can reasonably blame people/changesets based on that. Finally, both of these become more complicated by the fact GHC is a large project that has a highly variable number of configurations we have to keep under control: static, dynamic, static+dynamic, profiling, LLVM builds, builds where GHC itself is profiled, as well as the matrix of those combinations: LLVM+GHC Profiled, etc etc etc. Each of these configurations expose bugs in their own right. Unfortunately doing #1 with all these configurations would be ludicrous: it would explode the build times for any given system, and it also drastically multiplies the hardware resources we'd need for CI if we wanted them to respond quickly to any given changeset, because you not only have to *build* them, you must run them. And now you have to run a lot of them. A nightly build system is more reasonable for these problems, because taking hours and hours is expected. These problems would still be true even with cross compilation, because it multiplies the amount of work every CI run must do no matter what. We actually already do have both of these already, too: Joachim Breitner for example has set us up a Travis-CI[1] setup, while Gabor Pali has set us up nightly builds[2]. Travis-CI does the job of fast CI, but it's not good for a few reasons: 1) We have literally zero visibility into it for reports. Essentially we only know when it explodes because Joachim yells at us (normally at me :) This is because GitHub is not our center-of-the-universe, despite how much people yearn for it to be so. 2) The time limit is unacceptable. Travis-CI for example actually cannot do dynamic builds of GHC because it takes too long. Considering GHC is shipping dynamically on major platforms now, that's quite a huge loss for a CI system to miss (and no, a separate build matrix configuration doesn't work here - GHC builds statically and dynamically at the same time, and ships both - there's no way to have "only static" and "only dynamic" entries.) 3) It has limited platform support - only recently did it have OS X, and Windows is not yet in sight. Ditto for FreeBSD. These are crucial for CI as well, as they encompass all our Tier-1 platforms. This could be fixed with cross compilation, but again, that's a big, big project. And finally, on the GitHub note, as I said in the prior thread about Phabricator, I don't actually think it offers us anything useful at this point in time - literally almost nothing other than "other projects use GitHub", which is not an advantage, it's an appeal to popularity IMO. Webhooks still cannot do things like ban tabs, trailing whitespace, or enforce submodule integrity. We have to have our own setup for all of that. I'm never going to hit the 'Merge Button' for PRs - validation is 100% mandatory on behalf of the merger, and again, Travis-CI cannot provide coherent coverage even if we could use it for that. And because of that there's no difference between GitHub any other code site - I have to pull the branch manually and test myself, which I could do with any random git repository in the world. The code review tools are worse than Phabricator. Finally, if we are going to accept patches from people, we need to have a coherent, singular way to do it - mixing GitHub PRs, Phabricator, and uploading patches to Trac is just a nightmare for pain, and not just for me, even though I do most of the patch work - it incurs the burden on *every* person who wants to review code to now do so in many separate places. And we need to make code review *easier*, not harder! If anything, we should be consolidating on a single place (obviously, I'd vote for Phabricator), not adding more places to make changes that we all have to keep up with, when we don't even use the service itself! That's why I proposed Phabricator: because it is coherent and a singular place to go to, and very good at what it does, and does not attempt to 'take over' GHC itself. GitHub is a fairly all-or-nothing proposition if you want any benefits it delivers, if you ask me (I say this as someone who likes GitHub for smaller projects). I just don't think their tools are suitable for us. So, back to the topic. I think the nightly builds are actually in an OK state at the moment, since we do get reports from them, and builders do check in regularly. The nightly builders also cover a more diverse set of platforms than our CI will. But the CI and turnaround could be *greatly* improved, I think, because ghc-complete is essentially ignored or unknown by many people. So I'll also make a suggestion: just to actually get something that will pull GHC's repo every 10 minutes or so, do a build, and then email ghc-devs *only* if failures pop up. In fact, we could just re-use the existing nightly build infrastructure for this, and just make it check very regularly, and just run standard amd64/Linux and Windows builds upon changes. I could provide hardware for this. This would increase the visibility of reports, not require *any* new code, and already works. Overall, I will absolutely help you in every possible way, because this really is a problem for newcomers, and existing developers, when we catch dumb failures later than we should. But I think the proposed solution here is extraordinarily complex in comparison to what we actually need right now. ... I will say that if you *did* fix cross compilation however to work with TH you would be a hero to many people - myself included - continuous integration aside! :) [1] https://github.com/nomeata/ghc-complete [2] http://haskell.inf.elte.hu/builders/ On Wed, Jun 18, 2014 at 3:10 PM, William Knop wrote: > Hello all, > > I?ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It?s troublesome not only because it?s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: > > 1. Implement proper cross-compilation, such that build and host may be different? e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? > > 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. > > 3. Send the package to our buildbots, and run the test suite. > > 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. > > Cheers, > Will > > > * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don?t think this conflicts with the desire to use Phabricator, either, so I?ll send details and motivations to that thread. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Wed Jun 18 23:58:55 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 18 Jun 2014 18:58:55 -0500 Subject: GHC MinGW distribution In-Reply-To: <53A2204C.4080405@gekkou.co.uk> References: <53964754.6000408@gekkou.co.uk> <618BE556AADD624C9C918AA5D5911BEF103DC3A8@DB3PRD3001MB020.064d.mgd.msft.net> <53A2204C.4080405@gekkou.co.uk> Message-ID: Robin, Thanks a lot. This has been on my TODO list for a while, but it's been low priority. I'd love to see a more modern MinGW tools (it will surely come with many bugfixes), and I know many windows users would agree. Do let us know if something comes up. On Wed, Jun 18, 2014 at 6:27 PM, Robin KAY wrote: > Dear Simon et al., > > On 10/06/14 09:25, Simon Peyton Jones wrote: > [snip] > >> I'm sure that others will be happy to help. Do keep ghc-devs posted. You >> could make a ticket and post information to it as you learn about it. Or >> even a wiki page to describe the process, so that in four years time when >> someone wants to do the same thing, they have a guide. Speaking of which, >> do search the Trac Wiki in case someone *has* already docuemented some >> aspects of this. > > Thanks for your encouragement. I hope to have some time to start working on > this shortly and have created ticket #9218 [1] to track my progress. > > [1] https://ghc.haskell.org/trac/ghc/ticket/9218 > > Regards, > > > -- > Robin KAY > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From alain.odea at gmail.com Thu Jun 19 00:23:07 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Thu, 19 Jun 2014 00:23:07 +0000 Subject: Continuous Integration and Cross Compilation In-Reply-To: References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> Message-ID: <53A22D6B.2040007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Great and detailed response Austin. Thank you. William, I'm happy to help in any way I can. I run SmartOS x86 and x86_64 builds of GHC HEAD on my own equipment using the GHC Builder Ian Lynagh developed: https://ghc.haskell.org/trac/ghc/wiki/Builder https://github.com/haskell/ghc-builder I'm also currently working on small tweaks to the ghc-builder and getting the GHC testsuite to pass on Illumos (and indirectly Solaris). I follow G?bor's lead on the GHC Builder priorities and Carter Schonwald acts a Pull Request gatekeeper for changes. Best, Alain On 06/18/2014 11:53 PM, Austin Seipp wrote: > Hi William, > > Thanks for the email. Here're some things to consider. > > For one, cross compilation is a hot topic, but it is going to be a > rather large amount of work to fix and it won't be easy. The > primary problem is that we need to make Template Haskell > cross-compile, but in general this is nontrivial: TemplateHaskell > must load and run object code on the *host* platform, but the > compiler must generate code for the *target* platform. There are > ways around some of these problems; for one, we could compile every > module twice, once for the host, and once for the target. Upon > requesting TH, the Host GHC would load Host Object Code, but the > final executable would link with the Target Object Code. > > There are many, many subtle points to consider if we go down this > route - what happens for example if I cross compile from a 64bit > machine to a 32bit one, but TemplateHaskell wants some knowledge > like what "sizeOf (undefined :: CLong)" is? The host code sees a > 64-bit quantity while the target actually will deal with a 32bit > one. This could later explode horribly. And this isn't limited to > different endianness either - it applies to the ABI in general. > 64bit Linux -> 64bit Windows would be just as problematic with this > exact case, as one uses LP64, while the other uses LLP64 data > models. > > So #1 by itself is a very, very non-trivial amount of work, and IMO > I don't think it's necessary for better builds. There are other > routes possible for cross compilation perhaps, but I'd speculate > they are all equally as non-trivial as this one. > > Finally, the remainder of the scheme, including shipping builds to > remote machines and have them be tested sounds a bit more > complicated, and I'm wondering what the advantages are. In > particular it seems like this merely exposes more opportunities for > failure points in the CI system, because now all CI depends on > cross compilation working properly, being able to ship reports back > and forth, and more. Depending on CC in particular is a huge burden > it sounds: it makes it hard to distinguish when a cross-compilation > bug may cause a failure as opposed to a changeset from a committer, > which widens the scope of what we need to consider. A CI system > should be absolutely as predictable as possible, and this adds a > *lot* of variables to the mix. Cross compilation is really > something that's not just one big task - there will be many *small* > bugs laying in wait after that, the pain of a thousand cuts. > > Really, we need to distinguish between two needs: > > 1) Continuous integration. > > 2) Nightly builds. > > These two systems have very different needs in practice: > > 1) A CI system needs to be *fast*, and it needs to have dedicated > resources to respond to changes quickly. This means we need to > *minimize* the amount of time for developer turn around to see > results. That includes minimizing the needed configurations. > Shipping builds to remote machines just for CI would greatly > complicate this and likely make it far longer on its own, not to > mention it increases with every system we add. > > 2) A nightly build system is under nowhere near the same time > constraints, although it also needs to be dedicated. If an > ARM/Linux machine takes 6 hours to build (perhaps it's shared or > something, or just really wimpy), that's totally acceptable. These > can then report nightly about the results and we can reasonably > blame people/changesets based on that. > > Finally, both of these become more complicated by the fact GHC is > a large project that has a highly variable number of configurations > we have to keep under control: static, dynamic, static+dynamic, > profiling, LLVM builds, builds where GHC itself is profiled, as > well as the matrix of those combinations: LLVM+GHC Profiled, etc > etc etc. Each of these configurations expose bugs in their own > right. Unfortunately doing #1 with all these configurations would > be ludicrous: it would explode the build times for any given > system, and it also drastically multiplies the hardware resources > we'd need for CI if we wanted them to respond quickly to any given > changeset, because you not only have to *build* them, you must run > them. And now you have to run a lot of them. A nightly build system > is more reasonable for these problems, because taking hours and > hours is expected. These problems would still be true even with > cross compilation, because it multiplies the amount of work every > CI run must do no matter what. > > We actually already do have both of these already, too: Joachim > Breitner for example has set us up a Travis-CI[1] setup, while > Gabor Pali has set us up nightly builds[2]. Travis-CI does the job > of fast CI, but it's not good for a few reasons: > > 1) We have literally zero visibility into it for reports. > Essentially we only know when it explodes because Joachim yells at > us (normally at me :) This is because GitHub is not our > center-of-the-universe, despite how much people yearn for it to be > so. > > 2) The time limit is unacceptable. Travis-CI for example actually > cannot do dynamic builds of GHC because it takes too long. > Considering GHC is shipping dynamically on major platforms now, > that's quite a huge loss for a CI system to miss (and no, a > separate build matrix configuration doesn't work here - GHC builds > statically and dynamically at the same time, and ships both - > there's no way to have "only static" and "only dynamic" entries.) > > 3) It has limited platform support - only recently did it have OS > X, and Windows is not yet in sight. Ditto for FreeBSD. These are > crucial for CI as well, as they encompass all our Tier-1 platforms. > This could be fixed with cross compilation, but again, that's a > big, big project. > > And finally, on the GitHub note, as I said in the prior thread > about Phabricator, I don't actually think it offers us anything > useful at this point in time - literally almost nothing other than > "other projects use GitHub", which is not an advantage, it's an > appeal to popularity IMO. Webhooks still cannot do things like ban > tabs, trailing whitespace, or enforce submodule integrity. We have > to have our own setup for all of that. I'm never going to hit the > 'Merge Button' for PRs - validation is 100% mandatory on behalf of > the merger, and again, Travis-CI cannot provide coherent coverage > even if we could use it for that. And because of that there's no > difference between GitHub any other code site - I have to pull the > branch manually and test myself, which I could do with any random > git repository in the world. > > The code review tools are worse than Phabricator. Finally, if we > are going to accept patches from people, we need to have a > coherent, singular way to do it - mixing GitHub PRs, Phabricator, > and uploading patches to Trac is just a nightmare for pain, and not > just for me, even though I do most of the patch work - it incurs > the burden on *every* person who wants to review code to now do so > in many separate places. And we need to make code review *easier*, > not harder! If anything, we should be consolidating on a single > place (obviously, I'd vote for Phabricator), not adding more places > to make changes that we all have to keep up with, when we don't > even use the service itself! That's why I proposed Phabricator: > because it is coherent and a singular place to go to, and very good > at what it does, and does not attempt to 'take over' GHC itself. > GitHub is a fairly all-or-nothing proposition if you want any > benefits it delivers, if you ask me (I say this as someone who > likes GitHub for smaller projects). I just don't think their tools > are suitable for us. > > So, back to the topic. I think the nightly builds are actually in > an OK state at the moment, since we do get reports from them, and > builders do check in regularly. The nightly builders also cover a > more diverse set of platforms than our CI will. But the CI and > turnaround could be *greatly* improved, I think, because > ghc-complete is essentially ignored or unknown by many people. > > So I'll also make a suggestion: just to actually get something > that will pull GHC's repo every 10 minutes or so, do a build, and > then email ghc-devs *only* if failures pop up. In fact, we could > just re-use the existing nightly build infrastructure for this, and > just make it check very regularly, and just run standard > amd64/Linux and Windows builds upon changes. I could provide > hardware for this. This would increase the visibility of reports, > not require *any* new code, and already works. > > Overall, I will absolutely help you in every possible way, because > this really is a problem for newcomers, and existing developers, > when we catch dumb failures later than we should. But I think the > proposed solution here is extraordinarily complex in comparison to > what we actually need right now. > > ... I will say that if you *did* fix cross compilation however to > work with TH you would be a hero to many people - myself included > - continuous integration aside! :) > > [1] https://github.com/nomeata/ghc-complete [2] > http://haskell.inf.elte.hu/builders/ > > On Wed, Jun 18, 2014 at 3:10 PM, William Knop > wrote: >> Hello all, >> >> I?ve seen quite a few comments on the list and elsewhere >> lamenting the time it takes to compile and validate ghc. It?s >> troublesome not only because it?s inconvenient, but, more >> seriously, people are holding off on sending patches in which >> stifles development. I would like to propose a solution: >> >> 1. Implement proper cross-compilation, such that build and host >> may be different? e.g. a linux x86_64 machine can build ghc that >> runs on Windows x86. What sort of work would this entail? >> >> 2. Batch cross-compiled builds for all OSs/archs on a continuous >> integration service (e.g. Travis CI) or cloud service, then >> package up the binaries with the test suite. >> >> 3. Send the package to our buildbots, and run the test suite. >> >> 4. (optional) If using a CI service, have the buildbots send >> results back to the CI. This could be useful if we'd use GitHub >> for pulls in the future *. >> >> Cheers, Will >> >> >> * I realize vanilla GitHub currently has certain annoying >> limitations, though some of them are pretty easy to solve via the >> github-services and/or webhooks. I don?t think this conflicts >> with the desire to use Phabricator, either, so I?ll send details >> and motivations to that thread. >> >> >> _______________________________________________ ghc-devs mailing >> list ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToi1rAAoJEP0rIXJNjNSA7EkIAL2FFR8aBRsxHBTXIcCx6QsM HE9EHpO9zVF0hZYoTTw9+SwyI08NCMUvRg65YD2Wwrgq+yvGurX/+Oat7UI+6ZJY jWRY6LJpTDX9OcIFs3wCv7FmSbMDDLgdNR+2t1/atw/buVBityoYKi+1rqeU4I0y l5mCxL1hXIKwpOVU0IQ1NlZ/Q0G9er5qFSkbQFlRwS2rYNArvmp8UlTxsClZBw07 uSt5Mq2sKuUAth3ZCAt+8Hqp+kWDmV8UPDfDbP/tKSx83XOmH0SDwYCtVj7WwT+V psHkQwKPOg9QBto2DkxNVXLvwedV3awDhS88emtxQeulCZqly9FP5SWuHjRFHsU= =Ldqt -----END PGP SIGNATURE----- From tom-lists-ghc-devs at jaguarpaw.co.uk Thu Jun 19 07:19:19 2014 From: tom-lists-ghc-devs at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 19 Jun 2014 08:19:19 +0100 Subject: Case expressions in STG In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140619071919.GB30126@henry> On Wed, Jun 18, 2014 at 11:04:22PM +0000, Simon Peyton Jones wrote: > I've forgotten what I intended in the STG paper, but GHC's Core language > certainly allows case on a function; all it does is to force the function > to head normal form. Right, that's what I imagined. I will have a look for some more up-to-date references to see how this works in modern GHC. Tom From tom-lists-ghc-devs at jaguarpaw.co.uk Thu Jun 19 07:27:02 2014 From: tom-lists-ghc-devs at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 19 Jun 2014 08:27:02 +0100 Subject: Case expressions in STG In-Reply-To: <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> Message-ID: <20140619072702.GC30126@henry> On Wed, Jun 18, 2014 at 07:40:26PM -0400, William Knop wrote: > f = \x -> x > g = \x -> (x,1) > h = \x -> fst (g x) > i = \x -> case f of > f -> True > _ -> False > > i f => True > i h => ? > > If g isn't inlined into h and fst optimized out, wouldn't the head normal > form of f and h be different, and the comparison fail even though it > shouldn't? Or should it? I've taken function equality to be "f and g are > equal iff f x == g x, for all x." You mean 'i = \x -> case x of' ... Anyway, I'm not suggesting using case to *compare* functions, simply force their thunk before proceeding with a single default alternative. Tom From pali.gabor at gmail.com Thu Jun 19 14:48:44 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Thu, 19 Jun 2014 16:48:44 +0200 Subject: Continuous Integration and Cross Compilation In-Reply-To: References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> Message-ID: 2014-06-19 1:53 GMT+02:00 Austin Seipp : > We actually already do have both of these already, too: Joachim > Breitner for example has set us up a Travis-CI[1] setup, while Gabor > Pali has set us up nightly builds[2]. Travis-CI does the job of fast > CI, but it's not good for a few reasons: [..] > 3) It has limited platform support - only recently did it have OS X, > and Windows is not yet in sight. Ditto for FreeBSD. These are crucial > for CI as well, as they encompass all our Tier-1 platforms. This could > be fixed with cross compilation, but again, that's a big, big project. Regarding FreeBSD, I am fine with having only the nightly builds for them. Fortunately, it is seldom the case when something is broken due to some platform-specific setting. > So I'll also make a suggestion: just to actually get something that > will pull GHC's repo every 10 minutes or so, do a build, and then > email ghc-devs *only* if failures pop up. Yeah, this could be done by the nightly builders. They have a "Continuous" build mode (thanks to Ian) which probably means that they will start over the same process as soon as the current one has finished. I wrote "probably" because I have not ever tried it but saw it in the sources :-) I think sending mails in case of failures only could be also done somehow, but that may require some changes to the sources. From eir at cis.upenn.edu Thu Jun 19 15:57:06 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 19 Jun 2014 11:57:06 -0400 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> References: <532062AB.50108@cs.kuleuven.be> <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> Message-ID: <56148909-E690-43C3-B107-2259477CD745@cis.upenn.edu> Hi Thomas, Vigorous debate on #9200 (https://ghc.haskell.org/trac/ghc/ticket/9200) has led me to think about polymorphic recursion in the presence of a partial type signature. For example, take the following silly but well-typed function: > foo :: (a -> Bool) -> a -> () > foo _ _ = foo not True GHC reasonably requires the type signature here, because the recursive call to foo is called with *different* type parameters than the original call -- this is exactly polymorphic recursion. But, what about this? > bar :: _ -> a -> () > bar _ _ = bar not True I see several possible outcomes of type-checking bar: 1) Failure. Categorically disallow polymorphic recursion in the presence of a partial type signature. 2) bar :: (Bool -> Bool) -> a -> () 3) bar :: (a -> Bool) -> a -> () 4) bar :: (a -> a ) -> a -> () 5) bar :: (Bool -> a ) -> a -> () None of (2-5) is more general than another. So, I advocate for (1), which is essentially what we have decided to do at the kind level. The other approach is to say that wildcards refine to types that never mention user-written type variables. This would select (2) as the correct type. But, it is generally useful to allow wildcards to unify with user-written type variables! We could, I suppose, notice that polymorphic recursion is happening and then impose the restriction, but that seems very unpredictable to a user. What do you think? Have you pondered this particular corner case? Thanks, Richard On Apr 22, 2014, at 10:17 AM, Thomas Winant wrote: > Hi, > > My apologies for the late reply. > > On 2014-04-10 17:43, Richard Eisenberg wrote: >> What's the next step from your point of view? Are there unimplemented >> bits of this? > > We do see some bits left to implement: > * Partial pattern and expression signatures (see [1] for our view on > this issue). > * Partial type signatures for local bindings. What with 'let should not > be generalised' (see [2])? > > The implementation also needs a thorough code review (and probably some > refactoring as well) from a GHC dev. > > We'll be talking to SPJ via Skype on Thursday to discuss further > details. I'll post another status update in due course. > > > Cheers, > Thomas Winant > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#PartialExpressionandPatternSignatures > [2]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#LocalDefinitions > > > >> On Apr 10, 2014, at 3:48 AM, Thomas Winant wrote: >>> Hi, >>> I'm back with a status update. We implemented Austin's suggestion to >>> make wildcards in partial type signatures behave like holes. >>> Let's demonstrate the new behaviour with an example. The example >>> program: >>>> module Example where >>>> foo :: (Show _a, _) => _a -> _ >>>> foo x = show (succ x) >>> Compiled with GHC master gives: >>>> Example.hs:3:18: parse error on input ?_? >>> When we compile it with our branch: >>>> Example.hs:3:18: >>>> Instantiated extra-constraints wildcard ?_? to: >>>> (Enum _a) >>>> in the type signature for foo :: (Show _a, _) => _a -> _ >>>> at Example.hs:3:8-30 >>>> The complete inferred type is: >>>> foo :: forall _a. (Show _a, Enum _a) => _a -> String >>>> To use the inferred type, enable PartialTypeSignatures >>>> Example.hs:3:30: >>>> Instantiated wildcard ?_? to: String >>>> in the type signature for foo :: (Show _a, _) => _a -> _ >>>> at Example.hs:3:8-30 >>>> The complete inferred type is: >>>> foo :: forall _a. (Show _a, Enum _a) => _a -> String >>>> To use the inferred type, enable PartialTypeSignatures >>> Now the types the wildcards were instantiated to are reported. Note that >>> `_a` is still treated as a type variable, as prescribed in Haskell 2010. >>> To treat it as a /named wildcard/, we pass the -XNamedWildcards flag and >>> get: >>>> [..] >>>> Example.hs:3:24: >>>> Instantiated wildcard ?_a? to: tw_a >>>> in the type signature for foo :: (Show _a, _) => _a -> _ >>>> at Example.hs:3:8-30 >>>> The complete inferred type is: >>>> foo :: forall tw_a. (Show tw_a, Enum tw_a) => tw_a -> String >>>> To use the inferred type, enable PartialTypeSignatures >>>> [..] >>> An extra error message appears, reporting that `_a` was instantiated to >>> a new type variable (`tw_a`). >>> Finally, when passed the -XPartialTypeSignatures flag, the typechecker >>> will just use the inferred types for the wildcards and compile the >>> program without generating any error messages. >>> We added this example and a section about the monomorphism restriction >>> to the wiki page [1]. >>> Comments and feedback are still welcome. >>> Cheers, >>> Thomas Winant >>> [1]: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures >>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm From dominique.devriese at cs.kuleuven.be Thu Jun 19 20:58:43 2014 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Thu, 19 Jun 2014 22:58:43 +0200 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: <56148909-E690-43C3-B107-2259477CD745@cis.upenn.edu> References: <532062AB.50108@cs.kuleuven.be> <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> <56148909-E690-43C3-B107-2259477CD745@cis.upenn.edu> Message-ID: Richard, Since Thomas is attending a summer school for the moment, I'll try to provide a response and Thomas can correct me later if needed... 2014-06-19 17:57 GMT+02:00 Richard Eisenberg : > Vigorous debate on #9200 (https://ghc.haskell.org/trac/ghc/ticket/9200) has led me to think about polymorphic recursion in the presence of a partial type signature. For example, take the following silly but well-typed function: > >> foo :: (a -> Bool) -> a -> () >> foo _ _ = foo not True > > GHC reasonably requires the type signature here, because the recursive call to foo is called with *different* type parameters than the original call -- this is exactly polymorphic recursion. But, what about this? > >> bar :: _ -> a -> () >> bar _ _ = bar not True > > I see several possible outcomes of type-checking bar: > 1) Failure. Categorically disallow polymorphic recursion in the presence of a partial type signature. > 2) bar :: (Bool -> Bool) -> a -> () > 3) bar :: (a -> Bool) -> a -> () > 4) bar :: (a -> a ) -> a -> () > 5) bar :: (Bool -> a ) -> a -> () > > None of (2-5) is more general than another. So, I advocate for (1), which is essentially what we have decided to do at the kind level. The other approach is to say that wildcards refine to types that never mention user-written type variables. This would select (2) as the correct type. But, it is generally useful to allow wildcards to unify with user-written type variables! We could, I suppose, notice that polymorphic recursion is happening and then impose the restriction, but that seems very unpredictable to a user. > > What do you think? Have you pondered this particular corner case? Interesting question. In general, we definitely unify wildcards with user-written type variables. This is implied by a guiding design principle that we have used: a function with a trivial partial signature ":: _ => _" should be treated the same as one with no signature at all. We even share most of the code that does inference for definitions with partial type signatures with the code for definitions with no signature. Note: this sharing is something Thomas has worked on recently, after discussion with SPJ. As for your concrete example, I have tried it on our current branch and here's an overview of what we get for the function definition "bar _ _ = bar not True", depending on the provided signature: signature result inferred type/error no signature works (Bool -> Bool) -> Bool -> t _ -> _ -> () works (Bool -> Bool) -> Bool -> () _ works (Bool -> Bool) -> Bool -> t _ -> a -> () doesn't work Couldn't match type ?a? with ?Bool? (a -> _) -> a -> () doesn't work Couldn't match type ?a? with ?Bool? So in general, if there is a partial type signature, the compiler tries to infer a type under the assumption that there is no polymorphic recursion, similar to what it does when there is no signature. Regards, Dominique From simonpj at microsoft.com Thu Jun 19 22:00:50 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Jun 2014 22:00:50 +0000 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: References: <532062AB.50108@cs.kuleuven.be> <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> <56148909-E690-43C3-B107-2259477CD745@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E658A@DB3PRD3001MB020.064d.mgd.msft.net> | So in general, if there is a partial type signature, the compiler | tries to infer a type under the assumption that there is no | polymorphic recursion, similar to what it does when there is no | signature. Yes. The way to think of it (at both term and type level) is this. A full type signature breaks dependency loops, and supports polymorphic recursion. A partial type signature is treated exactly like *no* type signature, except that extra typing constraints are added. Where the signature has a variable, we insist that the result is a variable; where the signature are distinct variables we insist that the final inferred type has distinct variables. Moreover, the explicitly mentioned variables can lexically scope over the definition. But no polymorphic recursion at all, with a partial type signature. Simon From william.knop.nospam at gmail.com Thu Jun 19 22:50:51 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Thu, 19 Jun 2014 18:50:51 -0400 Subject: Continuous Integration and Cross Compilation In-Reply-To: References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> Message-ID: <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> Hi Austin, Thank you for the quick and thorough reply! There are a lot of points to cover, so I?ll respond in a few sections. *** The CI Scheme I realize the vast majority of the work would be in #1, but just want to highlight the idea that there is a real benefit to be had. To address the latter part of your email, I suggested splitting the test suite from the build for a few reasons: 1. We have a pretty good spread of buildbots, but as far as I know there aren?t very many of them. Running only the test suite would increase their utility by roughly 5x (from looking at the buildbot time breakdowns [1]). 2. Building ghc is time and resource intensive, which makes it hard for people to host buildbots. Even though my machines are relatively new, I can?t usually host one because it would interfere with my other work. I would be more tempted to if it was limited to just the test suite, and perhaps others would as well. 3. Cloud computing would enable very fast builds, such that we could conceivably automatically build (and then test on the buildbots) for every patch set submission / pull request. I believe that sort of streamlining would make ghc development both more accessible to others and more enjoyable for all. *** Cross Compilation and Template Haskell Now on to the meat of the problem! I?m not too familiar with the really scary bits of TH, but I'll start with: > TemplateHaskell must load and run object code on the *host* platform, but the compiler must generate code for the *target* platform. As you pointed out, this is a big deal. How clear of a delineation does TH have as far as what runs on each platform? I believe this segregation is fundamental to TH, which I?ll explain below. > There are ways around some of these problems; for one, we could compile every module twice, once for the host, and once for the target. I don?t think that?s necessary (or maybe I?m misunderstanding and we?re saying the same thing). Consider the following: 1. TH compiles to object code 2. The object code is run on the build machine, which generates haskell AST 3. ?Regular" GHC compiles the haskell AST to object code Currently, the notion of build, host, and target are sort of mashed together with the assumption that build and host will be the same. It seems like ?all? we have to do it tell the TH part of GHC to target the build arch, and the rest of GHC to target the host arch. But then there?s this... > There are many, many subtle points to consider if we go down this route - what happens for example if I cross compile from a 64bit machine to a 32bit one, but TemplateHaskell wants some knowledge like what "sizeOf (undefined :: CLong)" is? This comes back to the line between build and host in TH? there needs to be one. Perhaps there should be buildSizeOf and hostSizeOf for TH to use, and similar for other machine specific stuff? I think the messiest part of this it that existing packages assume build == host. Their maintainers would have to be prodded to respect the build/host division, and the packages would have to be updated. Actually, one advantage to adding in build and host variations to machine specific functions is that we can just deprecate the unsegregated versions and not break anyone?s stuff. Using one of the deprecated functions in a cross-compile would simply spit out an error and terminate the build, or instead perhaps fall back to double compilation. Regarding the many subtle points to consider, if the sort of path I describe is at all sane (please tell me if not!), I can open a trac ticket so we can chip away at them. *** Cross Compilation, Redux There is one more part to this story, however. Ultimately, a single build of ghc should be able to have multiple targets (or in other words, one build of ghc should be able to target multiple hosts). LLVM allows us to do this, but ghc?s notion of cross compiler is limited. Here is the current setup [2]: Stage 0: ? built on: --- ? runs on: host ? targets: host Libs Boot: ? built on: build ? runs on: build ? targets: --- Stage 1: ? built on: build ? runs on: host ? targets: target Libs Install: ? built on: build ? runs on: target ? targets: --- Stage 2: ? built on: build ? runs on: target ? targets: target What I propose is the following (stage 0 and libs boot are unchanged): Stage 1: ? built on: build ? runs on: build ? targets: targets Libs Toolchain Host: ? built on: build ? runs on: host ? targets: --- Libs Toolchain Target-x: ? built on: build ? runs on: target-x ? targets: --- Libs Toolchain Target-y: ? built on: build ? runs on: target-y ? targets: --- Libs Toolchain Target-z: ? built on: build ? runs on: target-z ? targets: --- Stage 2: ? built on: build ? runs on: host ? targets: host, target-x, target-y, target-z Most people will only want targets == host, in which case only the host toolchain will be built, so "regular" builds should be exactly the same as they are now. One may also produce a specialized cross-compiler (i.e. no host toolchain and one target toolchain), which is equivalent to how ghc currently builds a cross compiler. Or, one may choose to produce a compiler that targets whatever combination of targets one desires (currently impossible). A build of ghc that runs on the cloud (as proposed above), one might have host=linux-x86_64, targets=the-whole-shebang. For the compilers produced by the cloud, one would have targets == host, simply because we just want to be able to run the test suite on a given machine. *** Build Machine Needs > Really, we need to distinguish between two needs: > > 1) Continuous integration. > > 2) Nightly builds. > > These two systems have very different needs in practice: > > 1) A CI system needs to be *fast*, and it needs to have dedicated > resources to respond to changes quickly. This means we need to > *minimize* the amount of time for developer turn around to see > results. That includes minimizing the needed configurations. Shipping > builds to remote machines just for CI would greatly complicate this > and likely make it far longer on its own, not to mention it increases > with every system we add. > > 2) A nightly build system is under nowhere near the same time > constraints, although it also needs to be dedicated. If an ARM/Linux > machine takes 6 hours to build (perhaps it's shared or something, or > just really wimpy), that's totally acceptable. These can then report > nightly about the results and we can reasonably blame > people/changesets based on that. I totally agree on the distinction you?ve drawn here, though I don?t think the CI proposed above would increase build times. On the contrary, I think it would greatly reduce build times (assuming we use fast cloud compute nodes). I?ll try to collect some stats (and costs) to back that up. I didn?t realize Travis CI has a build time limit, so thanks for pointing that out. Fifty minutes, though! Not enough for us, certainly. I?ve read a fair amount about Jenkins CI [3], which is very actively developed, has zillions of plugins, and integrates with all sorts of sites. It?s also open source and locally installable, which means we could set it to email, generate online reports, tell Phabricator (or GitHub*) that a patch set is bogus, dispense coffee, etc. It might warrant more investigation as a possible replacement for buildbots. * I agree with most of your points with mixing so many tools, each with their own methodologies. Although I?d get a warm and fuzzy feeling from being able to fork and send a pull request that gets automatically validated, it probably doesn?t makes sense to pursue that right now. *** Oh my! This response has gotten pretty long! Apologies if I missed something, or otherwise misunderstood. Anyway, if there?s a path here that seems sensible, I?ll have a go at it. Will [1] http://haskell.inf.elte.hu/builders/ [2] https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation [3] http://jenkins-ci.org On Jun 18, 2014, at 7:53 PM, Austin Seipp wrote: > Hi William, > > Thanks for the email. Here're some things to consider. > > For one, cross compilation is a hot topic, but it is going to be a > rather large amount of work to fix and it won't be easy. The primary > problem is that we need to make Template Haskell cross-compile, but in > general this is nontrivial: TemplateHaskell must load and run object > code on the *host* platform, but the compiler must generate code for > the *target* platform. There are ways around some of these problems; > for one, we could compile every module twice, once for the host, and > once for the target. Upon requesting TH, the Host GHC would load Host > Object Code, but the final executable would link with the Target > Object Code. > > There are many, many subtle points to consider if we go down this > route - what happens for example if I cross compile from a 64bit > machine to a 32bit one, but TemplateHaskell wants some knowledge like > what "sizeOf (undefined :: CLong)" is? The host code sees a 64-bit > quantity while the target actually will deal with a 32bit one. This > could later explode horribly. And this isn't limited to different > endianness either - it applies to the ABI in general. 64bit Linux -> > 64bit Windows would be just as problematic with this exact case, as > one uses LP64, while the other uses LLP64 data models. > > So #1 by itself is a very, very non-trivial amount of work, and IMO I > don't think it's necessary for better builds. There are other routes > possible for cross compilation perhaps, but I'd speculate they are all > equally as non-trivial as this one. > > Finally, the remainder of the scheme, including shipping builds to > remote machines and have them be tested sounds a bit more complicated, > and I'm wondering what the advantages are. In particular it seems like > this merely exposes more opportunities for failure points in the CI > system, because now all CI depends on cross compilation working > properly, being able to ship reports back and forth, and more. > Depending on CC in particular is a huge burden it sounds: it makes it > hard to distinguish when a cross-compilation bug may cause a failure > as opposed to a changeset from a committer, which widens the scope of > what we need to consider. A CI system should be absolutely as > predictable as possible, and this adds a *lot* of variables to the > mix. Cross compilation is really something that's not just one big > task - there will be many *small* bugs laying in wait after that, the > pain of a thousand cuts. > > Really, we need to distinguish between two needs: > > 1) Continuous integration. > > 2) Nightly builds. > > These two systems have very different needs in practice: > > 1) A CI system needs to be *fast*, and it needs to have dedicated > resources to respond to changes quickly. This means we need to > *minimize* the amount of time for developer turn around to see > results. That includes minimizing the needed configurations. Shipping > builds to remote machines just for CI would greatly complicate this > and likely make it far longer on its own, not to mention it increases > with every system we add. > > 2) A nightly build system is under nowhere near the same time > constraints, although it also needs to be dedicated. If an ARM/Linux > machine takes 6 hours to build (perhaps it's shared or something, or > just really wimpy), that's totally acceptable. These can then report > nightly about the results and we can reasonably blame > people/changesets based on that. > > Finally, both of these become more complicated by the fact GHC is a > large project that has a highly variable number of configurations we > have to keep under control: static, dynamic, static+dynamic, > profiling, LLVM builds, builds where GHC itself is profiled, as well > as the matrix of those combinations: LLVM+GHC Profiled, etc etc etc. > Each of these configurations expose bugs in their own right. > Unfortunately doing #1 with all these configurations would be > ludicrous: it would explode the build times for any given system, and > it also drastically multiplies the hardware resources we'd need for CI > if we wanted them to respond quickly to any given changeset, because > you not only have to *build* them, you must run them. And now you have > to run a lot of them. A nightly build system is more reasonable for > these problems, because taking hours and hours is expected. These > problems would still be true even with cross compilation, because it > multiplies the amount of work every CI run must do no matter what. > > We actually already do have both of these already, too: Joachim > Breitner for example has set us up a Travis-CI[1] setup, while Gabor > Pali has set us up nightly builds[2]. Travis-CI does the job of fast > CI, but it's not good for a few reasons: > > 1) We have literally zero visibility into it for reports. Essentially > we only know when it explodes because Joachim yells at us (normally at > me :) This is because GitHub is not our center-of-the-universe, > despite how much people yearn for it to be so. > > 2) The time limit is unacceptable. Travis-CI for example actually > cannot do dynamic builds of GHC because it takes too long. Considering > GHC is shipping dynamically on major platforms now, that's quite a > huge loss for a CI system to miss (and no, a separate build matrix > configuration doesn't work here - GHC builds statically and > dynamically at the same time, and ships both - there's no way to have > "only static" and "only dynamic" entries.) > > 3) It has limited platform support - only recently did it have OS X, > and Windows is not yet in sight. Ditto for FreeBSD. These are crucial > for CI as well, as they encompass all our Tier-1 platforms. This could > be fixed with cross compilation, but again, that's a big, big project. > > And finally, on the GitHub note, as I said in the prior thread about > Phabricator, I don't actually think it offers us anything useful at > this point in time - literally almost nothing other than "other > projects use GitHub", which is not an advantage, it's an appeal to > popularity IMO. Webhooks still cannot do things like ban tabs, > trailing whitespace, or enforce submodule integrity. We have to have > our own setup for all of that. I'm never going to hit the 'Merge > Button' for PRs - validation is 100% mandatory on behalf of the > merger, and again, Travis-CI cannot provide coherent coverage even if > we could use it for that. And because of that there's no difference > between GitHub any other code site - I have to pull the branch > manually and test myself, which I could do with any random git > repository in the world. > > The code review tools are worse than Phabricator. Finally, if we are > going to accept patches from people, we need to have a coherent, > singular way to do it - mixing GitHub PRs, Phabricator, and uploading > patches to Trac is just a nightmare for pain, and not just for me, > even though I do most of the patch work - it incurs the burden on > *every* person who wants to review code to now do so in many separate > places. And we need to make code review *easier*, not harder! If > anything, we should be consolidating on a single place (obviously, I'd > vote for Phabricator), not adding more places to make changes that we > all have to keep up with, when we don't even use the service itself! > That's why I proposed Phabricator: because it is coherent and a > singular place to go to, and very good at what it does, and does not > attempt to 'take over' GHC itself. GitHub is a fairly all-or-nothing > proposition if you want any benefits it delivers, if you ask me (I say > this as someone who likes GitHub for smaller projects). I just don't > think their tools are suitable for us. > > So, back to the topic. I think the nightly builds are actually in an > OK state at the moment, since we do get reports from them, and > builders do check in regularly. The nightly builders also cover a more > diverse set of platforms than our CI will. But the CI and turnaround > could be *greatly* improved, I think, because ghc-complete is > essentially ignored or unknown by many people. > > So I'll also make a suggestion: just to actually get something that > will pull GHC's repo every 10 minutes or so, do a build, and then > email ghc-devs *only* if failures pop up. In fact, we could just > re-use the existing nightly build infrastructure for this, and just > make it check very regularly, and just run standard amd64/Linux and > Windows builds upon changes. I could provide hardware for this. This > would increase the visibility of reports, not require *any* new code, > and already works. > > Overall, I will absolutely help you in every possible way, because > this really is a problem for newcomers, and existing developers, when > we catch dumb failures later than we should. But I think the proposed > solution here is extraordinarily complex in comparison to what we > actually need right now. > > ... I will say that if you *did* fix cross compilation however to work > with TH you would be a hero to many people - myself included - > continuous integration aside! :) > > [1] https://github.com/nomeata/ghc-complete > [2] http://haskell.inf.elte.hu/builders/ > > On Wed, Jun 18, 2014 at 3:10 PM, William Knop > wrote: >> Hello all, >> >> I?ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It?s troublesome not only because it?s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: >> >> 1. Implement proper cross-compilation, such that build and host may be different? e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? >> >> 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. >> >> 3. Send the package to our buildbots, and run the test suite. >> >> 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. >> >> Cheers, >> Will >> >> >> * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don?t think this conflicts with the desire to use Phabricator, either, so I?ll send details and motivations to that thread. >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From william.knop.nospam at gmail.com Thu Jun 19 23:08:59 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Thu, 19 Jun 2014 19:08:59 -0400 Subject: Case expressions in STG In-Reply-To: <20140619072702.GC30126@henry> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> <20140619072702.GC30126@henry> Message-ID: Ah, yes, that's what I meant. I see your point about your example, now. Will > On Jun 19, 2014, at 3:27 AM, Tom Ellis wrote: > >> On Wed, Jun 18, 2014 at 07:40:26PM -0400, William Knop wrote: >> f = \x -> x >> g = \x -> (x,1) >> h = \x -> fst (g x) >> i = \x -> case f of >> f -> True >> _ -> False >> >> i f => True >> i h => ? >> >> If g isn't inlined into h and fst optimized out, wouldn't the head normal >> form of f and h be different, and the comparison fail even though it >> shouldn't? Or should it? I've taken function equality to be "f and g are >> equal iff f x == g x, for all x." > > You mean 'i = \x -> case x of' ... > > Anyway, I'm not suggesting using case to *compare* functions, simply force > their thunk before proceeding with a single default alternative. > > Tom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Fri Jun 20 00:09:33 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 19 Jun 2014 20:09:33 -0400 Subject: Proposal: Partial Type Signatures - Status update In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E658A@DB3PRD3001MB020.064d.mgd.msft.net> References: <532062AB.50108@cs.kuleuven.be> <444da7e93a51ade2b600a85a548e937a@cs.kuleuven.be> <56148909-E690-43C3-B107-2259477CD745@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF103E658A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <3C962160-4EB1-4820-8E22-FC840E078F2A@cis.upenn.edu> Great -- this agrees with the current proposal at the type level ((NEWCUSK) in the language of #9200.) Thanks for the quick response! Richard On Jun 19, 2014, at 6:00 PM, Simon Peyton Jones wrote: > > | So in general, if there is a partial type signature, the compiler > | tries to infer a type under the assumption that there is no > | polymorphic recursion, similar to what it does when there is no > | signature. > > Yes. The way to think of it (at both term and type level) is this. > > A full type signature breaks dependency loops, and supports polymorphic recursion. > > A partial type signature is treated exactly like *no* type signature, except that extra typing constraints are added. Where the signature has a variable, we insist that the result is a variable; where the signature are distinct variables we insist that the final inferred type has distinct variables. Moreover, the explicitly mentioned variables can lexically scope over the definition. > > But no polymorphic recursion at all, with a partial type signature. > > Simon > From kazu at iij.ad.jp Fri Jun 20 05:10:07 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 20 Jun 2014 14:10:07 +0900 (JST) Subject: clang warnings In-Reply-To: <20140514.133500.325427061403917868.kazu@iij.ad.jp> References: <20140514.133500.325427061403917868.kazu@iij.ad.jp> Message-ID: <20140620.141007.1060274973235227292.kazu@iij.ad.jp> Hi, I don't know whether or not this is new but it's worth sharing. > To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 > branch. Unfortunately, on my Mac, I saw many warnings which are not > displayed with GHC 7.8.2: > > clang: warning: argument unused during compilation: '-fno-stack-protector' > clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' > clang: warning: argument unused during compilation: '-I test' > clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' > clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' > clang: warning: argument unused during compilation: '-I dist/build/autogen' > clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' > > Is this a known issue? This is due to clang of Xcode 5.1. I found that the "-Qunused-arguments" option of clang disables these warnings. I think that "ghc-clang-wrapper" should include this option. --Kazu From simonpj at microsoft.com Fri Jun 20 07:10:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Jun 2014 07:10:49 +0000 Subject: Continuous Integration and Cross Compilation In-Reply-To: <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E6918@DB3PRD3001MB020.064d.mgd.msft.net> | This response has gotten pretty long! Apologies if I missed something, | or otherwise misunderstood. Anyway, if there's a path here that seems | sensible, I'll have a go at it. William, I am not qualified to comment on the details, but thank you for offering to help. I do urge you to pick some initial tasks that *don't* involve solving the full cross-compilation problem, desirable as it is. I fear that it is a swamp from which you will not emerge soon, and it'd be better to have some successes to encourage you, and some experience to build on, before diving into it. Everyone: no responses yet to my email below. Suppose Austin plays secretary: would people like to volunteer to be part of the GHC Nightly-Build/Continuous-Integration Task Force? Simon -----Original Message----- From: Simon Peyton Jones Sent: 18 June 2014 23:48 To: Simon Peyton Jones; P?li G?bor J?nos; Alain O'Dea Cc: ghc-devs at haskell.org; William Knop; Karel Gardas Subject: RE: Offering GHC builder build slaves Back in April I said: | Seriously, I advertised a couple of weeks ago for help with our | nightly- build infrastructure. Quite a few people responded -- thank | you very much. | | So we have willing horsepower. But the moment we lack leadership. | Alain rightly says "I don't know what the process is" because we don't | *have* a process. We need a mechanism for creating a process, taking | decisions, etc. | | I think what is needed is: | | * A group of people willing to act as a kind of committee. That | could be everyone who replied. You could create a mailing list, | or (initially better) just chat on ghc-devs. But it would be | useful to have a list of who is involved. | | * Someone (or a couple of people) to play the role of chair. | That doesn't mean an autocrat... it means someone who gently pushes | discussions to a conclusion, and says "I propose that we do X". | | * Then the group can formulate a plan and proceed with it. | For example, should Pali's efforts be "blessed"? I don't | know enough to know, but you guys do. | | In my experience, people are often unwilling to put themselves forward | as chair, not because they are unwilling, but because they feel it'd | be "pushy". So I suggest this: if you think (based on the traffic | you've | seen) that X would be a chair you'd trust, suggest them. | | In short: power to the people! GHC is your compiler. Since then various people have done various things, but so far as I know we don't have any of the three "*" items above. The people who seem in principle willing to help include Joachim Breitner Herbert Valerio Riedel P?li G?bor J?nos Karel Gardas Alain O'Dea William Knop Austin Seipp There may well be others! I sense that the problem is not willingness but simply that no one feels accredited to take the lead. Please, I would love someone to do so! I was reminded of this by William Knop's recent message below, in which he implicitly offers to help (thanks William). But his offer will fall on deaf ears unless that little group exists to welcome him in. In hope, and with thanks, Simon From carter.schonwald at gmail.com Fri Jun 20 08:04:28 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 20 Jun 2014 04:04:28 -0400 Subject: Continuous Integration and Cross Compilation In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E6918@DB3PRD3001MB020.064d.mgd.msft.net> References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E6918@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I thought Alain already replied? He and Pali are running some ghc-builder boxes, and i'm helping with code review for patches into ghc-builder On Fri, Jun 20, 2014 at 3:10 AM, Simon Peyton Jones wrote: > > | This response has gotten pretty long! Apologies if I missed something, > | or otherwise misunderstood. Anyway, if there's a path here that seems > | sensible, I'll have a go at it. > > William, I am not qualified to comment on the details, but thank you for > offering to help. I do urge you to pick some initial tasks that *don't* > involve solving the full cross-compilation problem, desirable as it is. I > fear that it is a swamp from which you will not emerge soon, and it'd be > better to have some successes to encourage you, and some experience to > build on, before diving into it. > > Everyone: no responses yet to my email below. Suppose Austin plays > secretary: would people like to volunteer to be part of the GHC > Nightly-Build/Continuous-Integration Task Force? > > Simon > > -----Original Message----- > From: Simon Peyton Jones > Sent: 18 June 2014 23:48 > To: Simon Peyton Jones; P?li G?bor J?nos; Alain O'Dea > Cc: ghc-devs at haskell.org; William Knop; Karel Gardas > Subject: RE: Offering GHC builder build slaves > > Back in April I said: > > | Seriously, I advertised a couple of weeks ago for help with our > | nightly- build infrastructure. Quite a few people responded -- thank > | you very much. > | > | So we have willing horsepower. But the moment we lack leadership. > | Alain rightly says "I don't know what the process is" because we don't > | *have* a process. We need a mechanism for creating a process, taking > | decisions, etc. > | > | I think what is needed is: > | > | * A group of people willing to act as a kind of committee. That > | could be everyone who replied. You could create a mailing list, > | or (initially better) just chat on ghc-devs. But it would be > | useful to have a list of who is involved. > | > | * Someone (or a couple of people) to play the role of chair. > | That doesn't mean an autocrat... it means someone who gently pushes > | discussions to a conclusion, and says "I propose that we do X". > | > | * Then the group can formulate a plan and proceed with it. > | For example, should Pali's efforts be "blessed"? I don't > | know enough to know, but you guys do. > | > | In my experience, people are often unwilling to put themselves forward > | as chair, not because they are unwilling, but because they feel it'd > | be "pushy". So I suggest this: if you think (based on the traffic > | you've > | seen) that X would be a chair you'd trust, suggest them. > | > | In short: power to the people! GHC is your compiler. > > Since then various people have done various things, but so far as I know > we don't have any of the three "*" items above. The people who seem in > principle willing to help include Joachim Breitner < > mail at joachim-breitner.de> Herbert Valerio Riedel > P?li G?bor J?nos Karel Gardas < > karel.gardas at centrum.cz> Alain O'Dea William > Knop Austin Seipp > > There may well be others! I sense that the problem is not willingness but > simply that no one feels accredited to take the lead. Please, I would love > someone to do so! > > I was reminded of this by William Knop's recent message below, in which he > implicitly offers to help (thanks William). But his offer will fall on > deaf ears unless that little group exists to welcome him in. > > In hope, and with thanks, > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Fri Jun 20 10:15:43 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Fri, 20 Jun 2014 12:15:43 +0200 Subject: Continuous Integration and Cross Compilation In-Reply-To: <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> Message-ID: Hello William, 2014-06-20 0:50 GMT+02:00 William Knop : > 1. We have a pretty good spread of buildbots, but as far as I know there aren?t > very many of them. Running only the test suite would increase their utility by > roughly 5x (from looking at the buildbot time breakdowns [1]). How would this increase their utility? I naively believe the purpose of CI is to rebuild and test the source code after each changeset to see if it was bringing regressions. Running the test suite only does not seem to convey this. Many of the regressions could be observed build-time, which means the most safe bet would be to rebuild and test everything on the very same platform. > 2. Building ghc is time and resource intensive, which makes it hard for people > to host buildbots. Even though my machines are relatively new, I can?t usually > host one because it would interfere with my other work. I would be more > tempted to if it was limited to just the test suite, and perhaps others would as > well. My buildbots complete the steps (git clone, full build, testing) in about 1 hour 40 minutes (with about 1 hour 15 minutes spent in the compilation phase), while they run in parallel with a shift about an hour. They run on the same machine, together with the coordination server. This is just a 3.4-GHz 4-core Intel Core i5, with a couple of GBs of RAM, I would not call it a high-end box, though. Note that it is on purpose that the builders do not use -j for builds, meaning that they do not parallelize the invoked make(1)-subprocesses, which automatically makes the builds longer. Perhaps it would be worth experimenting with incremental builds and allowing for parallel builds as they could cut down on the build times more efficiently. From shumovichy at gmail.com Fri Jun 20 14:03:27 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Fri, 20 Jun 2014 17:03:27 +0300 Subject: CmmLint error when doing safe ccall from cmm Message-ID: <1403273007.4708.8.camel@shum-lt> Hello, I'm trying to do safe ccall from cmm (see below for the code). It seems to work, but -dcmm-lint is not satisfied: /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp Cmm lint error: in basic block c4 in assignment: _c1::I32 = R1; Reg ty: I32 Rhs ty: I64 Program was: {offset c5: _c0::I64 = R1; _c2::I64 = c_test; _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); I64[(young + 8)] = c4; foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; c4: _c1::I32 = R1; R1 = %MO_SS_Conv_W32_W64(_c1::I32); call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } : Compilation had errors The same code without "safe" annotation passes cmm lint. Is it my error or ghc bug? How can I do safe ccall in cmm correctly? Here is the code: == c.c == #include int c_test(int i) { assert(i == 1); return 2; } == cmm.cmm #include "Cmm.h" cmm_test(W_ i) { CInt i1; (i1) = ccall c_test(W_TO_INT(i)) "safe"; return (TO_W_(i1)); } == hs.hs == {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} import GHC.Prim import GHC.Types import Control.Exception foreign import prim "cmm_test" test :: Int# -> Int# main :: IO () main = do let i1 = test 1# assert (I# i1 == 2) (return ()) Thanks, Yuras From eir at cis.upenn.edu Fri Jun 20 14:28:28 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 20 Jun 2014 10:28:28 -0400 Subject: clang warnings In-Reply-To: <20140620.141007.1060274973235227292.kazu@iij.ad.jp> References: <20140514.133500.325427061403917868.kazu@iij.ad.jp> <20140620.141007.1060274973235227292.kazu@iij.ad.jp> Message-ID: <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> Would this fix #9047? Yay! On Jun 20, 2014, at 1:10 AM, Kazu Yamamoto (????) wrote: > Hi, > > I don't know whether or not this is new but it's worth sharing. > >> To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 >> branch. Unfortunately, on my Mac, I saw many warnings which are not >> displayed with GHC 7.8.2: >> >> clang: warning: argument unused during compilation: '-fno-stack-protector' >> clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' >> clang: warning: argument unused during compilation: '-I test' >> clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' >> clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' >> clang: warning: argument unused during compilation: '-I dist/build/autogen' >> clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' >> >> Is this a known issue? > > This is due to clang of Xcode 5.1. I found that the > "-Qunused-arguments" option of clang disables these warnings. > > I think that "ghc-clang-wrapper" should include this option. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From conal at conal.net Fri Jun 20 17:59:14 2014 From: conal at conal.net (Conal Elliott) Date: Fri, 20 Jun 2014 10:59:14 -0700 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters Message-ID: I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Jun 20 20:11:17 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 20 Jun 2014 21:11:17 +0100 Subject: Uniquable RdrName instance In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E3EC4@DB3PRD3001MB020.064d.mgd.msft.net> References: <201406161345.03423.jan.stolarek@p.lodz.pl> <71E0D0E0-A671-4C56-924E-77D668A48BDA@cis.upenn.edu> <201406162133.06490.jan.stolarek@p.lodz.pl> <7C701CC2-41BF-453B-B2C5-55D22084A1CF@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF103E3EC4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53A49565.30305@gmail.com> On 17/06/14 20:53, Simon Peyton Jones wrote: > I would require a lot of convincing that we wanted Uniques for RdrNames. I seriously doubt that, once the dust has settled, you'll need a finite map indexed by RdrNames. But even if you do, you could use a TrieMap-like structure. I must be missing something... but what's wrong with Map RdrName? Cheers, Simon > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard > | Eisenberg > | Sent: 17 June 2014 15:01 > | To: Jan Stolarek > | Cc: ghc-devs at haskell.org > | Subject: Re: Uniquable RdrName instance > | > | So, without really trying to understand the code, what you are saying is > | this: you want a finite map from RdrNames. That seems sensible enough, if > | the domain elements all appear in the same scope in the Haskell source. I > | don't have enough perspective to say whether a Uniquable instance is the > | way to get to a finite map here. > | > | Richard > | > | On Jun 16, 2014, at 3:33 PM, Jan Stolarek wrote: > | > | >> Why do you want this? The danger I see lurking is that you might find > | two > | >> RdrNames that give the same answer to getUnique but represent > | different > | > Yes, that's exactly my concern. > | > > | >> Why do you want this? > | > I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet > | from desugaring of arrow > | > notation: > | > > | > leaves = concatMap leavesMatch matches > | > where > | > leavesMatch :: LMatch Id (Located (body Id)) -> [(Located (body Id), > | IdSet)] > | > leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) > | > = let defined_vars = mkVarSet (collectPatsBinders pats) > | `unionVarSet` > | > mkVarSet (collectLocalBinders > | binds) > | > in [(body, mkVarSet (collectLStmtsBinders stmts) > | `unionVarSet` defined_vars) | L _ > | > (GRHS stmts body) <- grhss] > | > > | > This is in the desugarer. But I need to also know `length leaves` at > | the renaming stage, which > | > means I need to call `concatMap leavesMatch matches`. The problem is > | that in the renamer my > | > datatypes are not parametrised by `Id`. I turned `Id` into a type > | parameter `id`, but then I > | > can't use VarSets. I could use more general UniqueSets but only if `id` > | type parameter is an > | > instance of Uniquable. And since in the renamer the datatypes are > | parametrized with RdrName this > | > leads me to wanting Uniqable RdrName instance. > | > > | > Janek > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Fri Jun 20 20:24:53 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 20 Jun 2014 21:24:53 +0100 Subject: CmmLint error when doing safe ccall from cmm In-Reply-To: <1403273007.4708.8.camel@shum-lt> References: <1403273007.4708.8.camel@shum-lt> Message-ID: <53A49895.5000503@gmail.com> On 20/06/14 15:03, Yuras Shumovich wrote: > Hello, > > I'm trying to do safe ccall from cmm (see below for the code). It seems > to work, but -dcmm-lint is not satisfied: > > /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp > Cmm lint error: > in basic block c4 > in assignment: > _c1::I32 = R1; > Reg ty: I32 > Rhs ty: I64 > Program was: > {offset > c5: _c0::I64 = R1; > _c2::I64 = c_test; > _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); > I64[(young + 8)] = c4; > foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; > c4: _c1::I32 = R1; > R1 = %MO_SS_Conv_W32_W64(_c1::I32); > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > } > > : > Compilation had errors I believe we only support 64-bit results on a 64-bit platform, but we you can always narrow to 32 bits with an MO_Conv afterwards if you want. This is essentially what happens when you call a function that returns CInt using the FFI - you can always try that and see what Cmm you get. Also, I'll be mildly surprised if using safe foreign calls from hand-written Cmm works, since I don't believe we use them anywhere so it isn't likely to be well tested :-) Cheers, Simon > The same code without "safe" annotation passes cmm lint. Is it my error > or ghc bug? How can I do safe ccall in cmm correctly? > > Here is the code: > > == c.c == > #include > > int c_test(int i) > { > assert(i == 1); > return 2; > } > > == cmm.cmm > #include "Cmm.h" > > cmm_test(W_ i) > { > CInt i1; > (i1) = ccall c_test(W_TO_INT(i)) "safe"; > return (TO_W_(i1)); > } > > == hs.hs == > {-# LANGUAGE GHCForeignImportPrim #-} > {-# LANGUAGE ForeignFunctionInterface #-} > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > {-# LANGUAGE UnliftedFFITypes #-} > > import GHC.Prim > import GHC.Types > import Control.Exception > > foreign import prim "cmm_test" test :: Int# -> Int# > > main :: IO () > main = do > let i1 = test 1# > assert (I# i1 == 2) (return ()) > > > Thanks, > Yuras > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From kazu at iij.ad.jp Fri Jun 20 20:57:43 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Sat, 21 Jun 2014 05:57:43 +0900 (JST) Subject: clang warnings In-Reply-To: <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> References: <20140514.133500.325427061403917868.kazu@iij.ad.jp> <20140620.141007.1060274973235227292.kazu@iij.ad.jp> <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> Message-ID: <20140621.055743.458133723082621815.kazu@iij.ad.jp> Hi Richard, > Would this fix #9047? Yay! I believe so. But currently "validate" itself fails: ---- for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconsta nts/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"; ranlib "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"/` basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/Users/kazu/work/ghc/bin disttest/install dir/lib/ghc-7.9.20140619" ; : "/Users/kazu/work/ghc/bindistt est/install dir/lib/ghc-7.9.20140619"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140 619" ;; *.dylib) /usr/bin/install -c -m 755 $i "/Users/kazu/work/ghc/bindistte st/install dir/lib/ghc-7.9.20140619";; *) /usr/bin/install -c -m 644 $i "/Us ers/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"; esac; done /usr/local/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unico de -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='"/Users/kazu/work/ghc/bindisttest/i nstall dir/lib/ghc-7.9.20140619"' -DINCLUDE_DIR='"/Users/kazu/work/ghc/bindist test/install dir/lib/ghc-7.9.20140619/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_L IB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes - Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconsta nts/header rts/package.conf.in -o rts/dist/package.conf.install.raw clang: error: no such file or directory: 'dir/lib/ghc-7.9.20140619"' clang: error: no such file or directory: 'dir/lib/ghc-7.9.20140619/include"' ---- In the bindisttest directory, the "dir" directory does not exist. Strangely "install dir" directory exist instead. P.S. Yesterday I could not "validate" for GHC HEAD on Linux either for another reason. --Kazu From shumovichy at gmail.com Fri Jun 20 21:23:21 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 21 Jun 2014 00:23:21 +0300 Subject: CmmLint error when doing safe ccall from cmm In-Reply-To: <53A49895.5000503@gmail.com> References: <1403273007.4708.8.camel@shum-lt> <53A49895.5000503@gmail.com> Message-ID: <1403299401.4799.10.camel@shum-lt> Simon, Sorry if I'm too stupid, but do you mean we only support 64-bit results from "prim" call? But I'm using TO_W_ macro to convert the result to 64-bit value before returning from cmm function. Or you mean result from "ccall" call? nativeGen/X86/CodeGen.hs:genCCall64 definitely supports that. And it works for unsafe "ccall". Looks like the issue is somewhere in translation from high level cmm to low level cmm. Thanks, Yuras On Fri, 2014-06-20 at 21:24 +0100, Simon Marlow wrote: > On 20/06/14 15:03, Yuras Shumovich wrote: > > Hello, > > > > I'm trying to do safe ccall from cmm (see below for the code). It seems > > to work, but -dcmm-lint is not satisfied: > > > > /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp > > Cmm lint error: > > in basic block c4 > > in assignment: > > _c1::I32 = R1; > > Reg ty: I32 > > Rhs ty: I64 > > Program was: > > {offset > > c5: _c0::I64 = R1; > > _c2::I64 = c_test; > > _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); > > I64[(young + 8)] = c4; > > foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; > > c4: _c1::I32 = R1; > > R1 = %MO_SS_Conv_W32_W64(_c1::I32); > > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; > > } > > > > : > > Compilation had errors > > I believe we only support 64-bit results on a 64-bit platform, but we > you can always narrow to 32 bits with an MO_Conv afterwards if you want. > This is essentially what happens when you call a function that returns > CInt using the FFI - you can always try that and see what Cmm you get. > > Also, I'll be mildly surprised if using safe foreign calls from > hand-written Cmm works, since I don't believe we use them anywhere so it > isn't likely to be well tested :-) > > Cheers, > Simon > > > > The same code without "safe" annotation passes cmm lint. Is it my error > > or ghc bug? How can I do safe ccall in cmm correctly? > > > > Here is the code: > > > > == c.c == > > #include > > > > int c_test(int i) > > { > > assert(i == 1); > > return 2; > > } > > > > == cmm.cmm > > #include "Cmm.h" > > > > cmm_test(W_ i) > > { > > CInt i1; > > (i1) = ccall c_test(W_TO_INT(i)) "safe"; > > return (TO_W_(i1)); > > } > > > > == hs.hs == > > {-# LANGUAGE GHCForeignImportPrim #-} > > {-# LANGUAGE ForeignFunctionInterface #-} > > {-# LANGUAGE MagicHash #-} > > {-# LANGUAGE UnboxedTuples #-} > > {-# LANGUAGE UnliftedFFITypes #-} > > > > import GHC.Prim > > import GHC.Types > > import Control.Exception > > > > foreign import prim "cmm_test" test :: Int# -> Int# > > > > main :: IO () > > main = do > > let i1 = test 1# > > assert (I# i1 == 2) (return ()) > > > > > > Thanks, > > Yuras > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > From william.knop.nospam at gmail.com Sat Jun 21 00:55:45 2014 From: william.knop.nospam at gmail.com (William Knop) Date: Fri, 20 Jun 2014 20:55:45 -0400 Subject: Continuous Integration and Cross Compilation In-Reply-To: References: <11C296CC-10A6-4E76-B959-13FBB4C69651@gmail.com> <2A968885-C68E-4D51-A374-1CF063D34FEC@gmail.com> Message-ID: Hi Pali and all, Sorry for the delayed replies; a bunch of things came up and I probably won?t be able to respond properly for two days or so. I am very interested in progressing with this as soon as I can. Many apologies! Will On Jun 20, 2014, at 6:15 AM, P?li G?bor J?nos wrote: > Hello William, > > 2014-06-20 0:50 GMT+02:00 William Knop : >> 1. We have a pretty good spread of buildbots, but as far as I know there aren?t >> very many of them. Running only the test suite would increase their utility by >> roughly 5x (from looking at the buildbot time breakdowns [1]). > > How would this increase their utility? I naively believe the purpose > of CI is to rebuild and test the source code after each changeset to > see if it was bringing regressions. Running the test suite only does > not seem to convey this. Many of the regressions could be observed > build-time, which means the most safe bet would be to rebuild and test > everything on the very same platform. > >> 2. Building ghc is time and resource intensive, which makes it hard for people >> to host buildbots. Even though my machines are relatively new, I can?t usually >> host one because it would interfere with my other work. I would be more >> tempted to if it was limited to just the test suite, and perhaps others would as >> well. > > My buildbots complete the steps (git clone, full build, testing) in > about 1 hour 40 minutes (with about 1 hour 15 minutes spent in the > compilation phase), while they run in parallel with a shift about an > hour. They run on the same machine, together with the coordination > server. This is just a 3.4-GHz 4-core Intel Core i5, with a couple of > GBs of RAM, I would not call it a high-end box, though. > > Note that it is on purpose that the builders do not use -j for builds, > meaning that they do not parallelize the invoked make(1)-subprocesses, > which automatically makes the builds longer. Perhaps it would be > worth experimenting with incremental builds and allowing for parallel > builds as they could cut down on the build times more efficiently. From hvriedel at gmail.com Sat Jun 21 10:09:44 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 21 Jun 2014 12:09:44 +0200 Subject: Int-based lexer flag bitmask exhausted Message-ID: <87wqca8tg7.fsf@gnu.org> Hello Simon (et al.), While doing #9224[1] as a finger-exercise to extend the lexer to support base-2 integer literals, I got stuck on the lexer extension map being represented as an 'Int', which (in GHC) is only guaranteed to hold least 32bits. -- for reasons of efficiency, flags indicating language extensions (eg, -- -fglasgow-exts or -XParallelArrays) are represented by a bitmap -- stored in an unboxed Int However, as all 32bits are already taken up by language extensions, and I'd need a 33th bit, I'm wondering how to proceed. Can we replace the 'Int' by an 'Int64' (or even better a Word64, ideally with a newtype or at least a type-synonym around it?) which would give us a bit more headroom while being semantically sound even for 'bitSize Int == 32'? [1]: https://ghc.haskell.org/trac/ghc/ticket/9224 Cheers, hvr From ezyang at mit.edu Sat Jun 21 11:09:31 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 21 Jun 2014 12:09:31 +0100 Subject: Int-based lexer flag bitmask exhausted In-Reply-To: <87wqca8tg7.fsf@gnu.org> References: <87wqca8tg7.fsf@gnu.org> Message-ID: <1403348951-sup-343@sabre> As long as you check the performance impact on 32-bit, sounds good to me. Edward Excerpts from Herbert Valerio Riedel's message of 2014-06-21 11:09:44 +0100: > Hello Simon (et al.), > > While doing #9224[1] as a finger-exercise to extend the lexer to support > base-2 integer literals, I got stuck on the lexer extension map being > represented as an 'Int', which (in GHC) is only guaranteed to hold least > 32bits. > > -- for reasons of efficiency, flags indicating language extensions (eg, > -- -fglasgow-exts or -XParallelArrays) are represented by a bitmap > -- stored in an unboxed Int > > However, as all 32bits are already taken up by language extensions, and > I'd need a 33th bit, I'm wondering how to proceed. Can we replace the > 'Int' by an 'Int64' (or even better a Word64, ideally with a newtype or > at least a type-synonym around it?) which would give us a bit more > headroom while being semantically sound even for 'bitSize Int == 32'? > > [1]: https://ghc.haskell.org/trac/ghc/ticket/9224 > > Cheers, > hvr From hvriedel at gmail.com Sat Jun 21 11:35:28 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 21 Jun 2014 13:35:28 +0200 Subject: Int-based lexer flag bitmask exhausted In-Reply-To: <1403348951-sup-343@sabre> (Edward Z. Yang's message of "Sat, 21 Jun 2014 12:09:31 +0100") References: <87wqca8tg7.fsf@gnu.org> <1403348951-sup-343@sabre> Message-ID: <874mzepkan.fsf@gmail.com> On 2014-06-21 at 13:09:31 +0200, Edward Z. Yang wrote: > As long as you check the performance impact on 32-bit, sounds good to > me. What's the currently accepted/canonical lexer/parser benchmark to evaluate that? From hvriedel at gmail.com Sat Jun 21 15:39:48 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 21 Jun 2014 17:39:48 +0200 Subject: Int-based lexer flag bitmask exhausted In-Reply-To: <874mzepkan.fsf@gmail.com> (Herbert Valerio Riedel's message of "Sat, 21 Jun 2014 13:35:28 +0200") References: <87wqca8tg7.fsf@gnu.org> <1403348951-sup-343@sabre> <874mzepkan.fsf@gmail.com> Message-ID: <87zjh6nuez.fsf@gmail.com> On 2014-06-21 at 13:35:28 +0200, Herbert Valerio Riedel wrote: > On 2014-06-21 at 13:09:31 +0200, Edward Z. Yang wrote: >> As long as you check the performance impact on 32-bit, sounds good to >> me. > > What's the currently accepted/canonical lexer/parser benchmark to evaluate that? PS: I've submitted a preparatory refactoring as https://phabricator.haskell.org/D23 for review, which allows upgrading to Word64 by simply modifying one source line. From simonpj at microsoft.com Sat Jun 21 16:00:25 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 21 Jun 2014 16:00:25 +0000 Subject: Case expressions in STG In-Reply-To: <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> References: <20140618134305.GA13172@henry> <26A5DB5C-9DCF-4442-BBBA-22A497326799@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103E5413@DB3PRD3001MB020.064d.mgd.msft.net> <60FC03CE-5D06-4146-A073-8D8A4BD90A45@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E78A8@DB3PRD3001MB020.064d.mgd.msft.net> | i = \x -> case f of | f -> True | _ -> False This case expression always succeeds with the first pattern. The second is entirely overlapped. Variable patterns always match. Simon | -----Original Message----- | From: William Knop [mailto:william.knop.nospam at gmail.com] | Sent: 19 June 2014 00:40 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org; tom-lists-ghc-devs at jaguarpaw.co.uk | Subject: Re: Case expressions in STG | | Whoops, looks like my phone dropped Tom from the CC (fixed). | | Simon, what about the following: | | f = \x -> x | g = \x -> (x,1) | h = \x -> fst (g x) | i = \x -> case f of | f -> True | _ -> False | | i f => True | i h => ? | | If g isn't inlined into h and fst optimized out, wouldn't the head | normal form of f and h be different, and the comparison fail even though | it shouldn't? Or should it? I've taken function equality to be "f and g | are equal iff f x == g x, for all x." | | Will | | | > On Jun 18, 2014, at 7:04 PM, Simon Peyton Jones | wrote: | > | > I've forgotten what I intended in the STG paper, but GHC's Core | language certainly allows case on a function; all it does is to force | the function to head normal form. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | William Knop | > | Sent: 18 June 2014 23:54 | > | To: ghc-devs at haskell.org | > | Subject: Re: Case expressions in STG | > | | > | Hi Tom, | > | | > | SPJ is surely more qualified to answer than I, but I'll take a stab. | > | | > | In general, it is computationally infeasible to compare functions. | > | Granted, in your example, the function isn't being compared-- and | > | therefore the case expr is extraneous. I don't think there exists a | > | feasible, uncontrived example, so I imagine that's why STG forbids | > | it (though I don't know where it's specified). | > | | > | Cheers, | > | Will | > | | > | | > | > On Jun 18, 2014, at 9:43 AM, Tom Ellis | devs at jaguarpaw.co.uk> wrote: | > | > | > | > I am reading SPJ's seminal work "Implementing lazy functional | > | > languages | > | on | > | > stock hardware: the Spinless Tagless G-machine" (1992). The paper | > | > is available here | > | > | > | > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 | > | > | > | > On p62 we see "The expression scrutinised by a case expression | > | > must eventually evaluate either to a primitive value or a | > | > constructor application.". | > | > | > | > This doesn't make sense to me. Isn't the following a valid STG | > | program? | > | > What am I missing? Where is it specified that the scrutinee of a | > | > case expression cannot be of a function type? | > | > | > | > {x} \n {z} -> let f = \{x} \n {y} -> g x y | > | > in case f of f' -> f' z | > | > | > | > Thanks, | > | > | > | > Tom | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs From bravit111 at gmail.com Sun Jun 22 14:47:19 2014 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sun, 22 Jun 2014 18:47:19 +0400 Subject: Fixing Trac #9046 (Panic in GHCi when using :print). Message-ID: Hello, I am trying to fix the bug #9046 (Panic in GHCi when using :print). I've discovered that It was introduced by this SPJ's commit (25 Nov 2013): https://ghc.haskell.org/trac/ghc/changeset/a8ac471d435214dbdc1fa70f938c63128993a1db/ghc and especially by this change: -type QuantifiedType = ([TyVar], Type) -- Make the free type variables explicit +type QuantifiedType = ([TyVar], Type) + -- Make the free type variables explicit + -- The returned Type should have no top-level foralls (I believe) quantifyType :: Type -> QuantifiedType --- Generalize the type: find all free tyvars and wrap in the appropiate ForAll. -quantifyType ty = (varSetElems (tyVarsOfType ty), ty) +-- Generalize the type: find all free and forall'd tyvars +-- and return them, together with the type inside, which +-- should not be a forall type. +-- +-- Thus (quantifyType (forall a. a->[b])) +-- returns ([a,b], a -> [b]) + +quantifyType ty = (varSetElems (tyVarsOfType rho), rho) + where + (_tvs, rho) = tcSplitForAllTys ty While this change looks reasonable to me it breaks exploiting thunks created by `:print` ghci's command from polymorphic values. Before this change we could have: $ ghci -fprint-explicit-foralls GHCi, version 7.6.3.20130421: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::forall a. [a] -> Int) > _t1 [1,2,3] 3 And now we have: $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::[a] -> Int) > _t1 [1,2,3] ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a{tv arw} [tv] This particular panic is caused by unification (compiler/typecheck/TcUnify.lhs line 1042). In case of `read` instead of `length` we get panic even earlier in simplification (compiler/typecheck/TcSimplify line 85). The concrete reason for the panic is wrong constructor used for tyvar (TyVar instead of TcTyVar). I see several ways to fix this: 1) rollback to forall-types in `:print` (requires change in cvObtainTerm, RtClosureInspect.hs); 2) skolemise free tyvar to RuntimeUnk (it becomes TcTyVar then): a) in cvObtainTerm; b) somewhere before typechecking. I can't decide the correct way to fix this bug or maybe there are other alternatives. Anyway I am ready to work on this though I need some advice. With best regards, Vitaly Bragilevsky From mark.lentczner at gmail.com Mon Jun 23 04:15:16 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 22 Jun 2014 21:15:16 -0700 Subject: building for Mac Message-ID: When the bin-dists are built, can we have them built with a 10.6 or 10.7 target? If built that way, they should run on all greater OSes. I don't think there is a reason not to. The current bindists, built on Mavericks, seg fault 11 when run an 10.7 or earlier. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Jun 23 06:17:38 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 22 Jun 2014 23:17:38 -0700 Subject: building for Mac In-Reply-To: References: Message-ID: This stackoverflow question seems to be the same issue: http://stackoverflow.com/questions/21676716/macos-compile-from-mavericks-lion-compatible-executable Also, minor but, Cabal docs (not the haddock, the user manual), didn't end up in the bindist. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jun 23 07:06:39 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 07:06:39 +0000 Subject: [commit: ghc] master: Fix #9047 (b847481) In-Reply-To: <20140623062819.1C84D2406D@ghc.haskell.org> References: <20140623062819.1C84D2406D@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E8939@DB3PRD3001MB020.064d.mgd.msft.net> Something clever/important is going on here, but no `Note` explains what, or even references the ticket :-(. I know I'm obsessive about this, but I've spent too long staring at code wondering why it is the way it is, when a pointer to the relevant ticket and a few remarks would have made it all clear. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 23 June 2014 07:28 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Fix #9047 (b847481) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/b84748121e777d098198f2583d11a9 | 424c1b1650/ghc | | >--------------------------------------------------------------- | | commit b84748121e777d098198f2583d11a9424c1b1650 | Author: Austin Seipp | Date: Mon Jun 23 00:07:10 2014 -0500 | | Fix #9047 | | Signed-off-by: Austin Seipp | | | >--------------------------------------------------------------- | | b84748121e777d098198f2583d11a9424c1b1650 | compiler/main/DriverPipeline.hs | 46 ++++++++++++++++++++++------------ | ------- | compiler/main/DynFlags.hs | 2 ++ | compiler/main/SysTools.lhs | 7 +++++-- | 3 files changed, 32 insertions(+), 23 deletions(-) | | diff --git a/compiler/main/DriverPipeline.hs | b/compiler/main/DriverPipeline.hs index 39df2a1..b90a821 100644 | --- a/compiler/main/DriverPipeline.hs | +++ b/compiler/main/DriverPipeline.hs | @@ -1206,6 +1206,7 @@ runPhase (RealPhase (As with_cpp)) input_fn dflags | -- might be a hierarchical module. | liftIO $ createDirectoryIfMissing True (takeDirectory | output_fn) | | + ccInfo <- liftIO $ getCompilerInfo dflags | let runAssembler inputFilename outputFilename | = liftIO $ as_prog dflags | ([ SysTools.Option ("-I" ++ p) | p <- | cmdline_include_paths ] @@ -1220,7 +1221,9 @@ runPhase (RealPhase (As | with_cpp)) input_fn dflags | ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | then [SysTools.Option "-mcpu=v9"] | else []) | - | + ++ (if ccInfo == AppleClang51 | + then [SysTools.Option "-Qunused-arguments"] | + else []) | ++ [ SysTools.Option "-x" | , if with_cpp | then SysTools.Option "assembler-with-cpp" | @@ -2129,26 +2132,27 @@ joinObjectFiles dflags o_files output_fn = do | let mySettings = settings dflags | ldIsGnuLd = sLdIsGnuLd mySettings | osInfo = platformOS (targetPlatform dflags) | - ld_r args ccInfo = SysTools.runLink dflags ([ | - SysTools.Option "-nostdlib", | - SysTools.Option "-Wl,-r" | - ] | - ++ (if ccInfo == Clang then [] | - else [SysTools.Option "-nodefaultlibs"]) | - ++ (if osInfo == OSFreeBSD | - then [SysTools.Option "-L/usr/lib"] | - else []) | - -- gcc on sparc sets -Wl,--relax | implicitly, but | - -- -r and --relax are incompatible for ld, | so | - -- disable --relax explicitly. | - ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | - && ldIsGnuLd | - then [SysTools.Option "-Wl,-no-relax"] | - else []) | - ++ map SysTools.Option ld_build_id | - ++ [ SysTools.Option "-o", | - SysTools.FileOption "" output_fn ] | - ++ args) | + ld_r args cc = SysTools.runLink dflags ([ | + SysTools.Option "-nostdlib", | + SysTools.Option "-Wl,-r" | + ] | + ++ (if any (cc ==) [Clang, AppleClang, | AppleClang51] | + then [] | + else [SysTools.Option "-nodefaultlibs"]) | + ++ (if osInfo == OSFreeBSD | + then [SysTools.Option "-L/usr/lib"] | + else []) | + -- gcc on sparc sets -Wl,--relax implicitly, | but | + -- -r and --relax are incompatible for ld, so | + -- disable --relax explicitly. | + ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | + && ldIsGnuLd | + then [SysTools.Option "-Wl,-no-relax"] | + else []) | + ++ map SysTools.Option ld_build_id | + ++ [ SysTools.Option "-o", | + SysTools.FileOption "" output_fn ] | + ++ args) | | -- suppress the generation of the .note.gnu.build-id section, | -- which we don't need and sometimes causes ld to emit a diff -- | git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs index | 7222af3..f82c404 100644 | --- a/compiler/main/DynFlags.hs | +++ b/compiler/main/DynFlags.hs | @@ -3757,6 +3757,8 @@ data LinkerInfo | data CompilerInfo | = GCC | | Clang | + | AppleClang | + | AppleClang51 | | UnknownCC | deriving Eq | | diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs | index dc9642d..51d5af1 100644 | --- a/compiler/main/SysTools.lhs | +++ b/compiler/main/SysTools.lhs | @@ -788,12 +788,15 @@ getCompilerInfo' dflags = do | -- Regular clang | | any ("clang version" `isPrefixOf`) stde = | return Clang | + -- XCode 5.1 clang | + | any ("Apple LLVM version 5.1" `isPrefixOf`) stde = | + return AppleClang51 | -- XCode 5 clang | | any ("Apple LLVM version" `isPrefixOf`) stde = | - return Clang | + return AppleClang | -- XCode 4.1 clang | | any ("Apple clang version" `isPrefixOf`) stde = | - return Clang | + return AppleClang | -- Unknown linker. | | otherwise = fail "invalid -v output, or compiler is | unsupported" | | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits From simonpj at microsoft.com Mon Jun 23 08:39:51 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 08:39:51 +0000 Subject: New GHC feature proposal: Pattern families In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E8C39@DB3PRD3001MB020.064d.mgd.msft.net> Baldur (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last name.) I'm glad you are enjoying pattern synonyms. Thanks for identifying #9226, which I guess is you. I honestly don't understand your pattern family proposal. Would you like to write a wiki page somewhere describing the syntax typing (static semantics) desugaring (dynamic semantics) as clearly and precisely as you can, independent of prisms, and using the simplest possible examples to illustrate. By all means say that prisms are a more advanced application, and give examples to show how. But in general to specify a language feature you need a lot more than a couple of examples! Then you can ask GHC users what they think. I have to say that I'm cautious about adding further features to pattern synonyms until we've gotten more user experience with what we have. (Do you think the explicitly bidirectional stuff on the wiki page is important? To me that seems like the first thing a user might stumble over.) Incidentally, I'd really like to replace view patterns with https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another thing that is awaiting cycles. Copying ghc-devs for interest Thanks Simon | -----Original Message----- | From: Baldur Bl?ndal [mailto:baldurpet at gmail.com] | Sent: 18 June 2014 04:31 | To: Simon Peyton Jones; gergo at erdi.hu | Subject: New GHC feature proposal: Pattern families | | Hello Peyton and Gergo, | | I'm a master's student at Chalmers, a minor GHC contributor and have | written about the pattern synonyms extension | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and | included is a proposal for an extension I call ?pattern families? | allowing users to create patterns parameterized by an expression. I feel | like patterns don't get nearly as much attention as the type system and | this is my attempt to balance things out :) | | I discussed the proposal with Edward Kmett who suggested an example with | prisms and that I contact you two for comments. The syntax is still in | flux. | | Some motivating examples for your consideration. | | PRISM PATTERNS | | Edward suggested a pattern to match a prism which would look like this: | an example where you want it is if you want to use a pattern | synonym to match a prism foo (Match _Left a) = ... | [...] | the example of a single pattern that can match every prism | would be a nice example | | which would be quite easy to implement: | | | pattern Match prism a ? ((^? prism) ? Just a) | | | | bar :: Either c (Either a b) ? a | | bar (Match (_Right._Left) a) = a | | bar _ = error "Not a Right (Left ...)" | | This can be used for any prism: | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" | | | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") | (Match (nth 1) a)))) = a | | ghci> foo jsonBlob | | Number 0.0 | | and defining more specilized patterns we can make it terser: | | pattern Get i a ? ((^? nth i) ? Just a) pattern Key str a ? ((^? key | | str) ? Just a) | | | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :? | | "someObject" :? "version" :? 1 :? a) = a | where | | pattern i :? a ? Get i a | | pattern str :? a ? Key str a | | So this is excellent for pattern matching on any sort of nested | structure: records, JSON, XML, HTML, ASTs, ? Since this also supports | pattern matching on any value that satisfies a predicate. | | N+K PATTERNS | Generalizing n+k patterns: We create a pattern family indexed by its | first argument: | | | pattern (a :+) :: Num a ? a ? a | | k :+ n ? (unSucc k ? Just n) -- [1] unSucc defined below | | where (a :+) indicates that 'k' is an index of the pattern family | allowing it to be supplied to the view pattern. | The pattern can be used as follows: | | fact 0 = 1 | | fact m@(1 :+ n) = m * fact n | | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note that | its second argument is the index here: | | pattern (:=~ String) :: RegexContext Regex a c ? a ? c | | n :=~ pattern ? ((=~ pattern) ? n) | | Used as: | | vowels :: RegexContext Regex src tgt ? src ? tgt vowels (n :=~ | | "[aeiou]") = n | | | | ghci> vowels "honorificabilitudinitatibus" ? Int | | 13 | | where you can of course pattern match on the resulting value: | | | has5Vowels :: String ? Int | | has5Vowels (5 :=~ "[aeiou]") = True | | has5Voewls _ = False | | TYPE INFERENCE | Here is an example of a snippet inferring the type of an if expression: | | | infer ? (If cond t e) = | | case (infer ? cond, infer ? t, infer ? e) of | | (Just TBool, Just ??, Just ??) | | | ?? == ?? = Just t? | | Here is how it might look with pattern families: | | | infer ? (If (Infer ? TBool) (Infer ? ??) (Infer ? ??)) | | | ?? == ?? = Just ?? | | (or even nicer if we use (:?) = Infer) | | infer ? (If (? :? TBool) (? :? ??) (? :? ??)) ? | | IMPLEMENTATION | From what I can see this is a relatively straight-forward translation | into view patterns where a variable bound by a view pattern is an | ?index? to the pattern family and unbound variables are regular | patterns. In the examples above I use special syntax for the index where | the type is included but even without any annotation it can be inferred | from context. | | If the proposal is fine by you I offer to do the implementation work, | all feedback welcome! | | Best regards, | Baldur Bl?ndal | | APPENDIX | | unSucc :: Int ? Int ? Maybe Int | | unSucc k n | | | n - k < 0 = Nothing | | | otherwise = Just (n - k) | | From simonpj at microsoft.com Mon Jun 23 10:00:06 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 10:00:06 +0000 Subject: Int-based lexer flag bitmask exhausted In-Reply-To: <87wqca8tg7.fsf@gnu.org> References: <87wqca8tg7.fsf@gnu.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E9048@DB3PRD3001MB020.064d.mgd.msft.net> I'm all for it. Just need to watch for performance regressions Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 21 June 2014 11:10 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Int-based lexer flag bitmask exhausted | | Hello Simon (et al.), | | While doing #9224[1] as a finger-exercise to extend the lexer to support | base-2 integer literals, I got stuck on the lexer extension map being | represented as an 'Int', which (in GHC) is only guaranteed to hold least | 32bits. | | -- for reasons of efficiency, flags indicating language extensions (eg, | -- -fglasgow-exts or -XParallelArrays) are represented by a bitmap | -- stored in an unboxed Int | | However, as all 32bits are already taken up by language extensions, and | I'd need a 33th bit, I'm wondering how to proceed. Can we replace the | 'Int' by an 'Int64' (or even better a Word64, ideally with a newtype or | at least a type-synonym around it?) which would give us a bit more | headroom while being semantically sound even for 'bitSize Int == 32'? | | [1]: https://ghc.haskell.org/trac/ghc/ticket/9224 | | Cheers, | hvr From simonpj at microsoft.com Mon Jun 23 11:41:24 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 11:41:24 +0000 Subject: Phabricator gifs Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E9333@DB3PRD3001MB020.064d.mgd.msft.net> Is it possible to not get the hugely distracting and pixel-consuming gifs in Phabricator displays. Eg see the one below. Simon [cid:image001.png at 01CF8EE0.70DAF510] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 239521 bytes Desc: image001.png URL: From marlowsd at gmail.com Mon Jun 23 12:20:11 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 23 Jun 2014 13:20:11 +0100 Subject: Phabricator gifs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E9333@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103E9333@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53A81B7B.7040706@gmail.com> Image macros are part of the charm of using Phabricator, and (IMO of course) they inject a little essential humour into the code review process. You don't have to use them, of course! I don't think there's a way to actually not display them, although you could probably install adblocker and right-click on the image and selecting the appropriate block option. You can also hit Ctrl-Esc to stop the animation (this is browser-specific, it works for me in Firefox). Cheers, Simon On 23/06/2014 12:41, Simon Peyton Jones wrote: > Is it possible to not get the hugely distracting and pixel-consuming > gifs in Phabricator displays. Eg see the one below. > > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Jun 23 12:54:12 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 12:54:12 +0000 Subject: CmmLint error when doing safe ccall from cmm In-Reply-To: <53A49895.5000503@gmail.com> References: <1403273007.4708.8.camel@shum-lt> <53A49895.5000503@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E9579@DB3PRD3001MB020.064d.mgd.msft.net> I'm not following this thread, but is it worth a ticket? Or better user manual documentation? Or something? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon | Marlow | Sent: 20 June 2014 21:25 | To: Yuras Shumovich; ghc-devs at haskell.org | Subject: Re: CmmLint error when doing safe ccall from cmm | | On 20/06/14 15:03, Yuras Shumovich wrote: | > Hello, | > | > I'm trying to do safe ccall from cmm (see below for the code). It | > seems to work, but -dcmm-lint is not satisfied: | > | > /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint | > -fforce-recomp Cmm lint error: | > in basic block c4 | > in assignment: | > _c1::I32 = R1; | > Reg ty: I32 | > Rhs ty: I64 | > Program was: | > {offset | > c5: _c0::I64 = R1; | > _c2::I64 = c_test; | > _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); | > I64[(young + 8)] = c4; | > foreign call "ccall" arg hints: [] result hints: [] | (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: | ([_c1::I32])ret_args: 8ret_off: 8; | > c4: _c1::I32 = R1; | > R1 = %MO_SS_Conv_W32_W64(_c1::I32); | > call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; | > } | > | > : | > Compilation had errors | | I believe we only support 64-bit results on a 64-bit platform, but we | you can always narrow to 32 bits with an MO_Conv afterwards if you want. | This is essentially what happens when you call a function that returns | CInt using the FFI - you can always try that and see what Cmm you get. | | Also, I'll be mildly surprised if using safe foreign calls from hand- | written Cmm works, since I don't believe we use them anywhere so it | isn't likely to be well tested :-) | | Cheers, | Simon | | | > The same code without "safe" annotation passes cmm lint. Is it my | > error or ghc bug? How can I do safe ccall in cmm correctly? | > | > Here is the code: | > | > == c.c == | > #include | > | > int c_test(int i) | > { | > assert(i == 1); | > return 2; | > } | > | > == cmm.cmm | > #include "Cmm.h" | > | > cmm_test(W_ i) | > { | > CInt i1; | > (i1) = ccall c_test(W_TO_INT(i)) "safe"; | > return (TO_W_(i1)); | > } | > | > == hs.hs == | > {-# LANGUAGE GHCForeignImportPrim #-} | > {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE MagicHash #-} | > {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} | > | > import GHC.Prim | > import GHC.Types | > import Control.Exception | > | > foreign import prim "cmm_test" test :: Int# -> Int# | > | > main :: IO () | > main = do | > let i1 = test 1# | > assert (I# i1 == 2) (return ()) | > | > | > Thanks, | > Yuras | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From kazu at iij.ad.jp Mon Jun 23 14:18:55 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 23 Jun 2014 23:18:55 +0900 (JST) Subject: clang warnings In-Reply-To: <20140621.055743.458133723082621815.kazu@iij.ad.jp> References: <20140620.141007.1060274973235227292.kazu@iij.ad.jp> <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> <20140621.055743.458133723082621815.kazu@iij.ad.jp> Message-ID: <20140623.231855.757563862468442069.kazu@iij.ad.jp> Hi, Cloning the fresh GHC source, I can validate GHC HEAD on Linux. And I understand "install dir" is correct. The problem on Mac is that "ghc-clang-wrapper" is a shell script. I cannot find a way to treat strings, which includes spaces, correctly with shell scripts. So, I replaced "install dir" to "install_dir" in three files and can validate GHC HEAD on Mac finally. Questions: * What is the purpose of spaces in "install dir"? * Would you tell me the plan to provide C preprocessor program by GHC itself? --Kazu > Hi Richard, > >> Would this fix #9047? Yay! > > I believe so. > > But currently "validate" itself fails: > > ---- > for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconsta > nts/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m > 644 $i "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"; > ranlib "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"/` > basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/Users/kazu/work/ghc/bin > disttest/install dir/lib/ghc-7.9.20140619" ; : "/Users/kazu/work/ghc/bindistt > est/install dir/lib/ghc-7.9.20140619"/`basename $i` ;; *.so) /usr/bin/install > -c -m 755 $i "/Users/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140 > 619" ;; *.dylib) /usr/bin/install -c -m 755 $i "/Users/kazu/work/ghc/bindistte > st/install dir/lib/ghc-7.9.20140619";; *) /usr/bin/install -c -m 644 $i "/Us > ers/kazu/work/ghc/bindisttest/install dir/lib/ghc-7.9.20140619"; esac; done > /usr/local/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unico > de -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='"/Users/kazu/work/ghc/bindisttest/i > nstall dir/lib/ghc-7.9.20140619"' -DINCLUDE_DIR='"/Users/kazu/work/ghc/bindist > test/install dir/lib/ghc-7.9.20140619/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_L > IB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes - > Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconsta > nts/header rts/package.conf.in -o rts/dist/package.conf.install.raw > clang: error: no such file or directory: 'dir/lib/ghc-7.9.20140619"' > clang: error: no such file or directory: 'dir/lib/ghc-7.9.20140619/include"' > ---- > > In the bindisttest directory, the "dir" directory does not exist. > Strangely "install dir" directory exist instead. > > P.S. > > Yesterday I could not "validate" for GHC HEAD on Linux either for > another reason. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Mon Jun 23 14:44:23 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 23 Jun 2014 09:44:23 -0500 Subject: Phabricator for patches and code review In-Reply-To: <201406180938.04852.jan.stolarek@p.lodz.pl> References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: Hi all, I went ahead and took some time to write some stuff down about Phabricator, including some basic tips on the workflows and applications here: https://ghc.haskell.org/trac/ghc/wiki/Phabricator It's definitely going to need more expanding. Do let me know if anything is confusing. On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek wrote: > Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) > > Janek > > Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: >> I read the friendly Arcanist manual and I wonder if we intend to have a >> default .arcconfig file in the GHC repo? From the docs it seems like a good >> idea. >> >> Janek >> >> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: >> > On 13/06/14 10:47, Jan Stolarek wrote: >> > > It seems that most people are in favour of using Phabricator for code >> > > review. So what are the next steps? Can we just start using the >> > > existing phabricator instance? I'm working on some code right now that >> > > definitely needs reviewing. >> > >> > You can use it, and a few of us have already been doing so. There isn't >> > any Trac integration yet, but it works nicely for patch review. >> > >> > There's a short intro doc here: >> > https://secure.phabricator.com/book/phabricator/article/differential/, >> > but it's not hard to figure out the basics, and you'll learn by watching >> > how other people use it. If you go to the Herald tool you have yourself >> > automatically subscribed to diffs that touch areas of the code that >> > you're interested in. >> > >> > Pro tip: the keyboard shortcuts are really useful, especially "z". Hit >> > "?" to see all the shortcuts. >> > >> > Cheers, >> > Simon >> > >> > > Janek >> > > >> > > Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >> > >> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >> > >>> So, why not put everything on GutHub and use pull requests and so on? >> > >> >> > >> github just isn't great for doing code reviews. No side-by-side diffs, >> > >> and it sends you a separate email for every single comment, there's no >> > >> concept of a "review" consisting of multiple inline comments (unless >> > >> I've missed something). I'm afraid if we were using this for regular >> > >> reviews I would have to disable the email notifications, which makes >> > >> it significantly less useful. >> > >> >> > >>> SimonM writes that Phabricator is better than GitHub. I?m happy to >> > >>> believe that, but he also writes that using it requires installing >> > >>> local software and quite a bit of work. Moreover, I like to add that >> > >>> lots of people already know how to use GitHub and probably few know >> > >>> Phabricator. >> > >>> >> > >>> So, we are talking about having a somewhat better tool in return for >> > >>> three very significant disadvantages: (1) local installation, (2) >> > >>> work to set up and maintain Phabricator, and (3) effort by many >> > >>> people to learn to use it. >> > >> >> > >> Well, you've tipped the balance with "somewhat" and "significant" >> > >> here, I'd say Phabricator is "significantly" better than github for >> > >> code reviews, while installing arc is "somewhat" annoying :-) >> > >> >> > >> I have to admit it's not a no-brainer, but I do worry that github just >> > >> wouldn't cut it for doing a lot of code reviewing, whereas I spend my >> > >> life inside Phabricator so I know it works really well. >> > >> >> > >> What's more, github doesn't let you put animated gifs in code reviews. >> > >> Need I say more? >> > >> >> > >> Cheers, >> > >> Simon >> > >> >> > >>> We also have a constant lack of sufficient men power. So, why spend >> > >>> effort on building our own infrastructure, which will only increase >> > >>> the hurdle for contributors (as they have to deal with an unknown >> > >>> system)? Let?s outsource the effort to GitHub. >> > >>> >> > >>> Manuel >> > >>> >> > >>> Simon Peyton Jones : >> > >>>> At the moment GHC's main sources aren't on github, which means that >> > >>>> that (in my highly imperfect understanding) people can't submit pull >> > >>>> requests or use their code review mechanisms. Moreover, most people >> > >>>> don't have commit rights on the main GHC server, so if someone wants >> > >>>> to offer a patch they can really only do so in textual form attached >> > >>>> to Trac. People with commit rights can make a branch, but there's a >> > >>>> danger that over a decade we'll accumulate zillions of dead branches >> > >>>> which people forgot to delete. I think on github the branch is in a >> > >>>> different repo, belonging to the patch author. >> > >>>> >> > >>>> So we really don't have a good work flow for creating, reviewing, >> > >>>> modifying, and finally apply patches. I am no expert on these >> > >>>> matters. If Phabricator would help with that I'm all for it. But >> > >>>> perhaps there are other alternatives? Or is Phab the lead thing. >> > >>>> Will it stay around? >> > >>>> >> > >>>> Also before going too far I'd really like someone to document the >> > >>>> workflow carefully, and make sure it works from Windows equally >> > >>>> well. >> > >>>> >> > >>>> I'm not too stressed out about losing the review trail of a patch. >> > >>>> Much of it will be commenting on stuff that no longer appears in the >> > >>>> final patch. Anything that's important should appear in a Note in >> > >>>> the source code; even the commit messages are invisible until you >> > >>>> really start digging. >> > >>>> >> > >>>> Simon >> > >>>> >> > >>>> | -----Original Message----- >> > >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> > >>>> | Austin Seipp >> > >>>> | Sent: 06 June 2014 05:06 >> > >>>> | To: ghc-devs at haskell.org >> > >>>> | Subject: RFC: Phabricator for patches and code review >> > >>>> | >> > >>>> | Hello all, >> > >>>> | >> > >>>> | Recently, while doing server maintenance, several of the >> > >>>> | administrators for Haskell.org set up an instance of >> > >>>> | Phabricator[1], located at https://phabricator.haskell.org >> > >>>> | >> > >>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of >> > >>>> | tools for software development. Think of it like a polished, >> > >>>> | semi-private GitHub with a lot of applications and tools for all >> > >>>> | kinds of needs. We've been using it to do issue tracking for >> > >>>> | Haskell.org maintenance and like it a lot so far. >> > >>>> | >> > >>>> | One very nice aspect of Phabricator though is it has a very nice >> > >>>> | code review tool, called 'Differential', that is very useful. For >> > >>>> | people who have used a tool like Review Board, it's similar. >> > >>>> | Furthermore, it has a very convenient userland tool called >> > >>>> | 'Arcanist' which makes it easy for newcomers to post a review and >> > >>>> | get it merged when it's ready all from the command line. >> > >>>> | >> > >>>> | I'd like to see if people are interested in using Phab _strictly_ >> > >>>> | for code review of GHC patches. It is a dedicated tool >> > >>>> | specifically for this, and I think it works much better than Trac >> > >>>> | or inline GitHub comments. >> > >>>> | >> > >>>> | Also, Phab can also support post-commit reviews. So if I touch >> > >>>> | something in the runtime system and just push, perhaps Simon or >> > >>>> | Edward would like to look, and they can be alerted right when I do >> > >>>> | this, and then yell if I did something stupid. >> > >>>> | >> > >>>> | Before I go much further, I'd like to ask: is there *any* interest >> > >>>> | in this? Or are people satisifed with Trac? The primary >> > >>>> | motivations are roughly, in no particular order: >> > >>>> | >> > >>>> | 1) Code review is good for everyone, a good way for people to >> > >>>> | learn the code and ask questions, and useful to give feedback to >> > >>>> | newcomers. And even experienced GHC hackers can learn things from >> > >>>> | reading code, as we all do regularly, or find things that need >> > >>>> | cleanup. >> > >>>> | >> > >>>> | 2) Phabricator in particular makes it very easy to submit patches >> > >>>> | for review. To submit a patch, I just run the command 'arc diff' >> > >>>> | and it Does The Right Thing. It also makes it easy to ensure >> > >>>> | people are *alerted* when a patch might be relevant to them. >> > >>>> | >> > >>>> | 3) They can be uploaded and created from the command line, and >> > >>>> | merged easily afterwords the same way. This is particularly useful >> > >>>> | for newcomers, and for me. :) >> > >>>> | >> > >>>> | 4) Differential is dedicated to code review, and much better at >> > >>>> | it than just reading patches on Trac IMO. >> > >>>> | >> > >>>> | 5) It supports both post-commit code review, as well as >> > >>>> | pre-commit review. Post commit would be especially useful for us >> > >>>> | too, I think. >> > >>>> | >> > >>>> | Point #2 and #3 are mostly relevant for me, because I mostly >> > >>>> | handle incoming patches. But I think in general it would be nice, >> > >>>> | and make it a lot easier for newcomers to submit patches, and us >> > >>>> | to look over them. >> > >>>> | >> > >>>> | Here's an example of a Differential code review: >> > >>>> | >> > >>>> | https://phabricator.haskell.org/D4 >> > >>>> | >> > >>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create >> > >>>> | an account to login, but it shouldn't be much trouble, you can >> > >>>> | login several ways. I'll fix the login requirement soon. Feel free >> > >>>> | to read the code, comment on it, and play around. It's more of a >> > >>>> | demonstration, but real code review would be welcome too. :) >> > >>>> | >> > >>>> | If people are interested in doing this, I can add notes to the >> > >>>> | wiki pages for newcomers, and I'll send another email about Phab >> > >>>> | so people can understand it a little better. But I want to ask >> > >>>> | first. >> > >>>> | >> > >>>> | There is an argument that our team is so small, code review has >> > >>>> | unnecessary burdens. But I think Phab could help a lot with >> > >>>> | tracking outside patches and getting good reviews for incoming >> > >>>> | patches, and it'll make it easier for newcomers. And experienced >> > >>>> | pros can probably learn a thing as well. >> > >>>> | >> > >>>> | Again, to be clear, I don't propose we migrate anything to >> > >>>> | Phabricator from, say, Trac. There's no real pressure to do so and >> > >>>> | it would be tons of work. I only propose we use it for code >> > >>>> | review, which is perfectly fine, and how other projects like LLVM >> > >>>> | do code review (they use Bugzilla). >> > >>>> | >> > >>>> | I also don't think the usage of Phabricator should be mandatory >> > >>>> | (unless we decide that later because we like it), but I would like >> > >>>> | to see people use it if possible. >> > >>>> | >> > >>>> | [1] http://phabricator.org >> > >>>> | >> > >>>> | -- >> > >>>> | Regards, >> > >>>> | >> > >>>> | Austin Seipp, Haskell Consultant >> > >>>> | Well-Typed LLP, http://www.well-typed.com/ >> > >>>> | _______________________________________________ >> > >>>> | ghc-devs mailing list >> > >>>> | ghc-devs at haskell.org >> > >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >> > >>>> >> > >>>> _______________________________________________ >> > >>>> ghc-devs mailing list >> > >>>> ghc-devs at haskell.org >> > >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >>> >> > >>> _______________________________________________ >> > >>> ghc-devs mailing list >> > >>> ghc-devs at haskell.org >> > >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> > >> _______________________________________________ >> > >> ghc-devs mailing list >> > >> ghc-devs at haskell.org >> > >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs at haskell.org >> > > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Jun 23 14:53:34 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 23 Jun 2014 09:53:34 -0500 Subject: GHC 7.10 plans Message-ID: Hello all, Let me redirect you to the following page, which lists out some of the plans for 7.10: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 The listing here is mostly based on what we had all put down during the May status reports. If you have something planned, please mention it with a paragraph on the page if you don't mind. Given the last release schedule, we'd like an RC by Christmas, and a release close to Feburary 2015. This will give the 7.10 branch a full year of changes. Do let me know if anything is unclear! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ekmett at gmail.com Mon Jun 23 15:30:50 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 23 Jun 2014 11:30:50 -0400 Subject: New GHC feature proposal: Pattern families In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E8C39@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103E8C39@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: The main thing Baldur had asked me about was if it makes sense to talk about patterns that are parameterized by expressions in places. I agree that the thought is very poorly fleshed out, but as a motivation, in some sense the previous form of view patterns already do this. Consider (->), which takes in an expression to apply on the left and a pattern for what to match against the result of it on the right. The question then becomes can we allow this for arbitrary patterns? There are a number of use cases for these. For example, A pattern to match a regular expression might look like Foo (x :~= "ab*") where you want "ab*" to be passed as a parameter to the code for the pattern synonym (:~=), not be something it is binding. This then speaks to needing some notion of mode for the different parameters. One of the reasons I'm under-excited about pattern synonyms is we already built all the machinery for working with prisms in lens to generalize them. =) In lens we have a combinator 'preview :: Prism' s a -> s -> Maybe a'. As a straw man proposal: It'd be nice to be able to do something like pattern (Match p a) <- (preview p -> Just a) and have it take the arguments that go to the left hand side of the -> as expressions, not patterns so that that can compile. Now, I'm somewhat dubious that it worth the pain to embellish the pattern language with something this complicated, but in some sense we already have a lot of the machinery to support it. e.g. IIRC we parse patterns first as expressions then convert them. -Edward On Mon, Jun 23, 2014 at 4:39 AM, Simon Peyton Jones wrote: > Baldur > > (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last > name.) > > I'm glad you are enjoying pattern synonyms. Thanks for identifying #9226, > which I guess is you. > > I honestly don't understand your pattern family proposal. Would you like > to write a wiki page somewhere describing the > syntax > typing (static semantics) > desugaring (dynamic semantics) > as clearly and precisely as you can, independent of prisms, and using the > simplest possible examples to illustrate. By all means say that prisms are > a more advanced application, and give examples to show how. But in general > to specify a language feature you need a lot more than a couple of examples! > > Then you can ask GHC users what they think. > > I have to say that I'm cautious about adding further features to pattern > synonyms until we've gotten more user experience with what we have. (Do > you think the explicitly bidirectional stuff on the wiki page is important? > To me that seems like the first thing a user might stumble over.) > > Incidentally, I'd really like to replace view patterns with > https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another > thing that is awaiting cycles. > > Copying ghc-devs for interest > > Thanks > > Simon > > > > | -----Original Message----- > | From: Baldur Bl?ndal [mailto:baldurpet at gmail.com] > | Sent: 18 June 2014 04:31 > | To: Simon Peyton Jones; gergo at erdi.hu > | Subject: New GHC feature proposal: Pattern families > | > | Hello Peyton and Gergo, > | > | I'm a master's student at Chalmers, a minor GHC contributor and have > | written about the pattern synonyms extension > | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and > | included is a proposal for an extension I call ?pattern families? > | allowing users to create patterns parameterized by an expression. I feel > | like patterns don't get nearly as much attention as the type system and > | this is my attempt to balance things out :) > | > | I discussed the proposal with Edward Kmett who suggested an example with > | prisms and that I contact you two for comments. The syntax is still in > | flux. > | > | Some motivating examples for your consideration. > | > | PRISM PATTERNS > | > | Edward suggested a pattern to match a prism which would look like this: > | an example where you want it is if you want to use a pattern > | synonym to match a prism foo (Match _Left a) = ... > | [...] > | the example of a single pattern that can match every prism > | would be a nice example > | > | which would be quite easy to implement: > | > | | pattern Match prism a ? ((^? prism) ? Just a) > | | > | | bar :: Either c (Either a b) ? a > | | bar (Match (_Right._Left) a) = a > | | bar _ = error "Not a Right (Left ...)" > | > | This can be used for any prism: > | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" > | | > | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") > | (Match (nth 1) a)))) = a > | | ghci> foo jsonBlob > | | Number 0.0 > | > | and defining more specilized patterns we can make it terser: > | | pattern Get i a ? ((^? nth i) ? Just a) pattern Key str a ? ((^? key > | | str) ? Just a) > | | > | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 > | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :? > | | "someObject" :? "version" :? 1 :? a) = a > | where > | | pattern i :? a ? Get i a > | | pattern str :? a ? Key str a > | > | So this is excellent for pattern matching on any sort of nested > | structure: records, JSON, XML, HTML, ASTs, ? Since this also supports > | pattern matching on any value that satisfies a predicate. > | > | N+K PATTERNS > | Generalizing n+k patterns: We create a pattern family indexed by its > | first argument: > | > | | pattern (a :+) :: Num a ? a ? a > | | k :+ n ? (unSucc k ? Just n) -- [1] unSucc defined below > | > | where (a :+) indicates that 'k' is an index of the pattern family > | allowing it to be supplied to the view pattern. > | The pattern can be used as follows: > | | fact 0 = 1 > | | fact m@(1 :+ n) = m * fact n > | > | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired > | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note that > | its second argument is the index here: > | | pattern (:=~ String) :: RegexContext Regex a c ? a ? c > | | n :=~ pattern ? ((=~ pattern) ? n) > | > | Used as: > | | vowels :: RegexContext Regex src tgt ? src ? tgt vowels (n :=~ > | | "[aeiou]") = n > | | > | | ghci> vowels "honorificabilitudinitatibus" ? Int > | | 13 > | > | where you can of course pattern match on the resulting value: > | > | | has5Vowels :: String ? Int > | | has5Vowels (5 :=~ "[aeiou]") = True > | | has5Voewls _ = False > | > | TYPE INFERENCE > | Here is an example of a snippet inferring the type of an if expression: > | > | | infer ? (If cond t e) = > | | case (infer ? cond, infer ? t, infer ? e) of > | | (Just TBool, Just ??, Just ??) > | | | ?? == ?? = Just t? > | > | Here is how it might look with pattern families: > | > | | infer ? (If (Infer ? TBool) (Infer ? ??) (Infer ? ??)) > | | | ?? == ?? = Just ?? > | > | (or even nicer if we use (:?) = Infer) > | | infer ? (If (? :? TBool) (? :? ??) (? :? ??)) ? > | > | IMPLEMENTATION > | From what I can see this is a relatively straight-forward translation > | into view patterns where a variable bound by a view pattern is an > | ?index? to the pattern family and unbound variables are regular > | patterns. In the examples above I use special syntax for the index where > | the type is included but even without any annotation it can be inferred > | from context. > | > | If the proposal is fine by you I offer to do the implementation work, > | all feedback welcome! > | > | Best regards, > | Baldur Bl?ndal > | > | APPENDIX > | | unSucc :: Int ? Int ? Maybe Int > | | unSucc k n > | | | n - k < 0 = Nothing > | | | otherwise = Just (n - k) > | | > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jun 23 16:36:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Jun 2014 16:36:00 +0000 Subject: Associated type instances Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration -------------- next part -------------- An HTML attachment was scrubbed... URL: From pointlessmonad at gmail.com Mon Jun 23 17:58:16 2014 From: pointlessmonad at gmail.com (Christopher Rodrigues) Date: Mon, 23 Jun 2014 12:58:16 -0500 Subject: GHC silently turns off dynamic output, should this be an error? Message-ID: Hello, I?ve investigated an issue (#9176) where ghc with --make -dynamic-too appears to run successfully but doesn?t generate some .dyn_hi files. The cause seems to be that GHC silently turns off dynamic-too output when it finds an inconsistency between the .hi and .dyn_hi interface hashes of an imported module. The symptom, for me, is that some cabal packages will build but fail to install. The real problem is most likely not in the failing package, but in an imported module from a package that?s already installed. I?m inclined to say that GHC should stop with an error in this situation, which would produce a visible error when the file fails to compile. However, since GHC carefully avoids bailing out, I wonder if I?m missing something. Is there a good reason to turn off dynamic-too output instead of reporting an error? Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? Or is it invalid data, in the same way that a corrupted .hi file is invalid data? I?m inclined to say that it is invalid data, because -dynamic-too promises to generate two different (static and dynamic) implementations of the same Haskell code, taking two different implementations of the same imported Haskell modules as input. If the inputs aren?t really two different implementations of the same Haskell code, you?ve somehow provided invalid input. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Jun 23 19:59:59 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 23 Jun 2014 15:59:59 -0400 Subject: GHC silently turns off dynamic output, should this be an error? In-Reply-To: References: Message-ID: I wonder if this is the source of the problem I had with ^C'ing parallel rebuilds. I'll often build, realizing I should be doing something differently, ^C out, tweak something start a build again, etc. but if I have -j on then I find that doing so occasionally causes me to start missing dyn_hi files after the package builds. If I ^C'd in between generating one and the other being written, could that be what is causing other consistency problems later in my build? I've hesitated on reporting it (other than mentioning it in passing to Austin) because it has been fiendishly hard to reproduce and only happens on my more er.. monolithic projects. I've gone back to sequential builds as a result of this though. -Edward On Mon, Jun 23, 2014 at 1:58 PM, Christopher Rodrigues < pointlessmonad at gmail.com> wrote: > Hello, > > I?ve investigated an issue (#9176) where ghc with --make -dynamic-too > appears to run successfully but doesn?t generate some .dyn_hi files. The > cause seems to be that GHC silently turns off dynamic-too output when it > finds an inconsistency between the .hi and .dyn_hi interface hashes of an > imported module. The symptom, for me, is that some cabal packages will > build but fail to install. The real problem is most likely not in the > failing package, but in an imported module from a package that?s already > installed. > > I?m inclined to say that GHC should stop with an error in this situation, > which would produce a visible error when the file fails to compile. > However, since GHC carefully avoids bailing out, I wonder if I?m missing > something. Is there a good reason to turn off dynamic-too output instead > of reporting an error? > > Additionally, is it ever valid to have a pair of .hi and .dyn_hi files > with different interface hashes? Or is it invalid data, in the same way > that a corrupted .hi file is invalid data? I?m inclined to say that it is > invalid data, because -dynamic-too promises to generate two different > (static and dynamic) implementations of the same Haskell code, taking two > different implementations of the same imported Haskell modules as input. > If the inputs aren?t really two different implementations of the same > Haskell code, you?ve somehow provided invalid input. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Jun 23 20:04:15 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Jun 2014 13:04:15 -0700 Subject: clang warnings In-Reply-To: <20140623.231855.757563862468442069.kazu@iij.ad.jp> References: <20140620.141007.1060274973235227292.kazu@iij.ad.jp> <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> <20140621.055743.458133723082621815.kazu@iij.ad.jp> <20140623.231855.757563862468442069.kazu@iij.ad.jp> Message-ID: I'm the source of ghc-clang-wrapper. I can add "-Qunused-arguments" easily enough. I just last night ran across the spaces problem - and I'm not entirely sure the bug is in ghc-clang-wrapper! I'll investigate... turns out all you need to do is try to compile something that is in a directory with spaces in it. - Mark ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Mon Jun 23 20:06:33 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 23 Jun 2014 15:06:33 -0500 Subject: clang warnings In-Reply-To: References: <20140620.141007.1060274973235227292.kazu@iij.ad.jp> <7AC30574-0BCD-43E1-9759-AE2611C8511C@cis.upenn.edu> <20140621.055743.458133723082621815.kazu@iij.ad.jp> <20140623.231855.757563862468442069.kazu@iij.ad.jp> Message-ID: Hi Mark, I've already merged two changesets into 7.8.3 - https://github.com/ghc/ghc/commit/52222f9e0bedc9b08b46619f8ed4d09f645d6ed4 and https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 - which add -Qunused-arguments to the C compiler invocation if the compiler is Clang. The GHC but is #9047 (The problem was Clang will ignore a lot of the flags we pass in the assembler stage, since it will be used as the assembler). So I don't think a workaround will be needed. On Mon, Jun 23, 2014 at 3:04 PM, Mark Lentczner wrote: > I'm the source of ghc-clang-wrapper. I can add "-Qunused-arguments" easily > enough. > > I just last night ran across the spaces problem - and I'm not entirely sure > the bug is in ghc-clang-wrapper! I'll investigate... turns out all you need > to do is try to compile something that is in a directory with spaces in it. > > - Mark > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From kazu at iij.ad.jp Tue Jun 24 00:55:12 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 24 Jun 2014 09:55:12 +0900 (JST) Subject: clang warnings In-Reply-To: References: <20140623.231855.757563862468442069.kazu@iij.ad.jp> Message-ID: <20140624.095512.815266150608695315.kazu@iij.ad.jp> Austin, > I've already merged two changesets into 7.8.3 - > https://github.com/ghc/ghc/commit/52222f9e0bedc9b08b46619f8ed4d09f645d6ed4 > and https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 > - which add -Qunused-arguments to the C compiler invocation if the > compiler is Clang. The GHC but is #9047 > > (The problem was Clang will ignore a lot of the flags we pass in the > assembler stage, since it will be used as the assembler). So I don't > think a workaround will be needed. Great. I confirmed that I can validate both GHC HEAD and the ghc-7.8 branch on Mac WITHOUT ghc-clang-wrapper. --Kazu From carter.schonwald at gmail.com Tue Jun 24 01:30:50 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 23 Jun 2014 21:30:50 -0400 Subject: clang warnings In-Reply-To: <20140624.095512.815266150608695315.kazu@iij.ad.jp> References: <20140623.231855.757563862468442069.kazu@iij.ad.jp> <20140624.095512.815266150608695315.kazu@iij.ad.jp> Message-ID: I ran a validate myself on OS X this evening, i can confirm things worked too :) On Mon, Jun 23, 2014 at 8:55 PM, Kazu Yamamoto wrote: > Austin, > > > I've already merged two changesets into 7.8.3 - > > > https://github.com/ghc/ghc/commit/52222f9e0bedc9b08b46619f8ed4d09f645d6ed4 > > and > https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 > > - which add -Qunused-arguments to the C compiler invocation if the > > compiler is Clang. The GHC but is #9047 > > > > (The problem was Clang will ignore a lot of the flags we pass in the > > assembler stage, since it will be used as the assembler). So I don't > > think a workaround will be needed. > > Great. > > I confirmed that I can validate both GHC HEAD and the ghc-7.8 branch > on Mac WITHOUT ghc-clang-wrapper. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Jun 24 04:34:14 2014 From: anthony_clayden at clear.net.nz (AntC) Date: Tue, 24 Jun 2014 04:34:14 +0000 (UTC) Subject: Associated type instances References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > Simon Peyton Jones microsoft.com> writes: > > Relevant bits of the user manual: ... > Thanks Simon, IIRC when assoc type families/instances were first introduced, the type's parameters had to exactly match the class header. Reading through the manual there, it all sounds like it's got a bit what Wirth called 'baroque' [describing Modula]. The complexity in assoc type instances looks as though it's mostly to support type defaults. I guess the effect is that assoc types are now not exactly shorthand for stand-alone type families(?) [It might be worth a note in the manual section 7.7.3.2. to say that defaulting takes assoc types beyond type families? Or at least that you should mentally expand the instances and fill in from default(s) before thinking in terms of type families?] I rarely use assoc types, preferring stand-alone families (even if I think of them as associated). > > Does anyone object? Not me. AntC From chak at cse.unsw.edu.au Tue Jun 24 08:05:40 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue, 24 Jun 2014 18:05:40 +1000 Subject: Associated type instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Simon, I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones : > Friends > > I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. > > Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl > > All of this arose when thinking about fixing Trac #9063. > > I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). > > Does anyone object? > > Thanks > > Simon > > > > The issue > > Consider this: > > class C a where > type T a b :: * > > instance C [x] where > type T [x] b = x -> b > That is just what you?d expect. But currently this is allowed too: > > instance C [x] where > type T [x] Int = x -> Int > type T [x] Bool = Bool -> x > That is, GHC 7.8 allows many associated type instances, provided they don?t overlap. But, oddly you can?t further instantiate the instance pattern. This would make just as much sense, but isn?t allowed: > > instance C [x] where > type T [Int] b = b -> Int > type T [Bool] b = Bool -> b > Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like > > class D a where > type S (b :: Bool) a :: * > Now this would make some kind of sense: > > instance D [x] where > type S True [x] = x -> x > type S False [x] = x > But for closed kinds, you really want a closed type family. So this would be better: > > instance D [x] where > type S b [x] = SHelp x b > > type family SHelp x b where > SHelp x True = x -> x > SHelp x False = x > > So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. > > All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it?s a bit more complicated and indirect. > > My solution > > I propose to simplify substantially, as follows: > > ? The ?shared arguments? of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is ?shared?; and in class D, the second argument position of S is shared. > > ? A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have > > o type variables in the non-shared argument positions, and > > o an exact copy of the corresponding instance header type in the shared positions > > ? For each associated type you can have > > o at most one default declaration in the class declaration > > o at most one type instance declaration in the class instance declaration > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jun 24 08:07:02 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 08:07:02 +0000 Subject: Associated type instances In-Reply-To: <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com> References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net> I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakravarty at me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs at haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones >: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Jun 24 10:18:48 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 24 Jun 2014 12:18:48 +0200 Subject: Phabricator gifs In-Reply-To: <53A81B7B.7040706@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF103E9333@DB3PRD3001MB020.064d.mgd.msft.net> <53A81B7B.7040706@gmail.com> Message-ID: <53A95088.2030703@fuuzetsu.co.uk> On 06/23/2014 02:20 PM, Simon Marlow wrote: > Image macros are part of the charm of using Phabricator, and (IMO of > course) they inject a little essential humour into the code review > process. You don't have to use them, of course! > > I don't think there's a way to actually not display them, although you > could probably install adblocker and right-click on the image and > selecting the appropriate block option. You can also hit Ctrl-Esc to > stop the animation (this is browser-specific, it works for me in Firefox). > > Cheers, > Simon > > On 23/06/2014 12:41, Simon Peyton Jones wrote: >> Is it possible to not get the hugely distracting and pixel-consuming >> gifs in Phabricator displays. Eg see the one below. >> >> Simon >> You can insert images on Trac too. Just because it can be done doesn't mean it should, it'd be nice to see the semi-professional setting there is on Trac preserved. Please think of anyone reading the tickets in the future, it'd be a shame to have to (mentally or automatically) filter through tickets to get at the content. Just my opinion of course. -- Mateusz K. From simonpj at microsoft.com Tue Jun 24 10:41:07 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 10:41:07 +0000 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I?m cc?ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn?t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it?s task could be to answer the question Is C |- D definitely a contradiction? where C are the ?given? constraints (from enclosing pattern matches) and D are the ?wanted? constraints (from the current pattern match that may be unreachable). I don?t think it would be hard to implement such a function. I?d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it?d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs at haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitris at microsoft.com Tue Jun 24 10:57:54 2014 From: dimitris at microsoft.com (Dimitrios Vytiniotis) Date: Tue, 24 Jun 2014 10:57:54 +0000 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> Yes it would be better in the sense that we don?t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can?t assess very well yet if this is a real problem though ? In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- From: Simon Peyton Jones Sent: Tuesday, June 24, 2014 11:41 AM To: Conal Elliott; ghc-devs at haskell.org Cc: Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias; Simon Peyton Jones Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I?m cc?ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn?t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it?s task could be to answer the question Is C |- D definitely a contradiction? where C are the ?given? constraints (from enclosing pattern matches) and D are the ?wanted? constraints (from the current pattern match that may be unreachable). I don?t think it would be hard to implement such a function. I?d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it?d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs at haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Jun 24 11:30:31 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 24 Jun 2014 13:30:31 +0200 Subject: GHC 7.10 plans In-Reply-To: References: Message-ID: <53A96157.6010902@fuuzetsu.co.uk> On 06/23/2014 04:53 PM, Austin Seipp wrote: > Hello all, > > Let me redirect you to the following page, which lists out some of the > plans for 7.10: > > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > > The listing here is mostly based on what we had all put down during > the May status reports. If you have something planned, please mention > it with a paragraph on the page if you don't mind. > > Given the last release schedule, we'd like an RC by Christmas, and a > release close to Feburary 2015. This will give the 7.10 branch a full > year of changes. > > Do let me know if anything is unclear! > I don't need to include any Haddock stuff, do I? -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Tue Jun 24 11:32:59 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 24 Jun 2014 13:32:59 +0200 Subject: GHC 7.10 plans In-Reply-To: <53A96157.6010902@fuuzetsu.co.uk> References: <53A96157.6010902@fuuzetsu.co.uk> Message-ID: <53A961EB.4000503@fuuzetsu.co.uk> On 06/24/2014 01:30 PM, Mateusz Kowalczyk wrote: > On 06/23/2014 04:53 PM, Austin Seipp wrote: >> Hello all, >> >> Let me redirect you to the following page, which lists out some of the >> plans for 7.10: >> >> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 >> >> The listing here is mostly based on what we had all put down during >> the May status reports. If you have something planned, please mention >> it with a paragraph on the page if you don't mind. >> >> Given the last release schedule, we'd like an RC by Christmas, and a >> release close to Feburary 2015. This will give the 7.10 branch a full >> year of changes. >> >> Do let me know if anything is unclear! >> > > I don't need to include any Haddock stuff, do I? > I also note that the page mentions -XTypedHoles which was in the end removed all together, wasn't it? -- Mateusz K. From simonpj at microsoft.com Tue Jun 24 11:43:57 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 11:43:57 +0000 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EAC70@DB3PRD3001MB020.064d.mgd.msft.net> we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can?t assess very well yet if this is a real problem though That is a very good point. Nevertheless, given ? the typechecked HsSyn (i.e. still in source form, but with type inference fully completed ? the independent contradiction-detector described below (which is independent of whether the contradiction problems it is given come from HsSyn or Core) it would be easy to give source-localised error messages Simon From: Dimitrios Vytiniotis Sent: 24 June 2014 11:58 To: Simon Peyton Jones; Conal Elliott; ghc-devs at haskell.org Cc: Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Yes it would be better in the sense that we don?t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can?t assess very well yet if this is a real problem though ? In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- From: Simon Peyton Jones Sent: Tuesday, June 24, 2014 11:41 AM To: Conal Elliott; ghc-devs at haskell.org Cc: Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias; Simon Peyton Jones Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I?m cc?ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn?t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it?s task could be to answer the question Is C |- D definitely a contradiction? where C are the ?given? constraints (from enclosing pattern matches) and D are the ?wanted? constraints (from the current pattern match that may be unreachable). I don?t think it would be hard to implement such a function. I?d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it?d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs at haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Tue Jun 24 12:11:59 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Tue, 24 Jun 2014 20:11:59 +0800 (SGT) Subject: Help needed: parsing pattern synonym contexts Message-ID: Hi, I'm working on adding type signatures to pattern synonyms. The syntax I'm after would look something like, e.g.: pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] My problem is with parsing the two contexts. I wrote the parser in the following way, which I felt natural (actions omitted for brevity) pattern_synonym_sig :: { LSig RdrName } : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType RdrName)) } : constr_stuff patsyn_context :: { LHsContext RdrName } : {- empty -} | forall context '=>' However, this doesn't work, no matter if those contexts are present or not. If I remove both contexts from the rules, i.e. if I replace pattern_synonym_sig with : 'pattern' patsyn_stuff '::' type then parsing succeeds when there are no contexts on either side. I've also tried : 'pattern' patsyn_stuff '::' ctype with the intention of recovering the required context from the ctype (and I could do similar tricks to get the provided context from the patsyn_stuff by using a modified version of constr_stuff); however, even that doesn't work as I expected it, i.e. with this latter version, this: pattern Single a :: (Eq a) => [a] fails with a parse error on "::". Can someone help me out here please? Thanks, Gergo From marlowsd at gmail.com Tue Jun 24 13:11:21 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 24 Jun 2014 14:11:21 +0100 Subject: CmmLint error when doing safe ccall from cmm In-Reply-To: <1403299401.4799.10.camel@shum-lt> References: <1403273007.4708.8.camel@shum-lt> <53A49895.5000503@gmail.com> <1403299401.4799.10.camel@shum-lt> Message-ID: <53A978F9.3030701@gmail.com> On 20/06/2014 22:23, Yuras Shumovich wrote: > Simon, > > Sorry if I'm too stupid, but > do you mean we only support 64-bit results from "prim" call? But I'm > using TO_W_ macro to convert the result to 64-bit value before returning > from cmm function. The result of your foreign call is a CInt, which is an I32. If you make it an I64 and then convert it to an I32, that should work. Cheers, Simon > Or you mean result from "ccall" call? > nativeGen/X86/CodeGen.hs:genCCall64 definitely supports that. And it > works for unsafe "ccall". > Looks like the issue is somewhere in translation from high level cmm to > low level cmm. > > Thanks, > Yuras > > On Fri, 2014-06-20 at 21:24 +0100, Simon Marlow wrote: >> On 20/06/14 15:03, Yuras Shumovich wrote: >>> Hello, >>> >>> I'm trying to do safe ccall from cmm (see below for the code). It seems >>> to work, but -dcmm-lint is not satisfied: >>> >>> /opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint -fforce-recomp >>> Cmm lint error: >>> in basic block c4 >>> in assignment: >>> _c1::I32 = R1; >>> Reg ty: I32 >>> Rhs ty: I64 >>> Program was: >>> {offset >>> c5: _c0::I64 = R1; >>> _c2::I64 = c_test; >>> _c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64); >>> I64[(young + 8)] = c4; >>> foreign call "ccall" arg hints: [] result hints: [] (_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8; >>> c4: _c1::I32 = R1; >>> R1 = %MO_SS_Conv_W32_W64(_c1::I32); >>> call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; >>> } >>> >>> : >>> Compilation had errors >> >> I believe we only support 64-bit results on a 64-bit platform, but we >> you can always narrow to 32 bits with an MO_Conv afterwards if you want. >> This is essentially what happens when you call a function that returns >> CInt using the FFI - you can always try that and see what Cmm you get. >> >> Also, I'll be mildly surprised if using safe foreign calls from >> hand-written Cmm works, since I don't believe we use them anywhere so it >> isn't likely to be well tested :-) >> >> Cheers, >> Simon >> >> >>> The same code without "safe" annotation passes cmm lint. Is it my error >>> or ghc bug? How can I do safe ccall in cmm correctly? >>> >>> Here is the code: >>> >>> == c.c == >>> #include >>> >>> int c_test(int i) >>> { >>> assert(i == 1); >>> return 2; >>> } >>> >>> == cmm.cmm >>> #include "Cmm.h" >>> >>> cmm_test(W_ i) >>> { >>> CInt i1; >>> (i1) = ccall c_test(W_TO_INT(i)) "safe"; >>> return (TO_W_(i1)); >>> } >>> >>> == hs.hs == >>> {-# LANGUAGE GHCForeignImportPrim #-} >>> {-# LANGUAGE ForeignFunctionInterface #-} >>> {-# LANGUAGE MagicHash #-} >>> {-# LANGUAGE UnboxedTuples #-} >>> {-# LANGUAGE UnliftedFFITypes #-} >>> >>> import GHC.Prim >>> import GHC.Types >>> import Control.Exception >>> >>> foreign import prim "cmm_test" test :: Int# -> Int# >>> >>> main :: IO () >>> main = do >>> let i1 = test 1# >>> assert (I# i1 == 2) (return ()) >>> >>> >>> Thanks, >>> Yuras >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> > > From eir at cis.upenn.edu Tue Jun 24 14:09:10 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 24 Jun 2014 10:09:10 -0400 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: Thanks so much for writing this! I have some questions: 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my "pull" origin is git://git.haskell.org/ghc.git and my "push" origin is ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. 3) You say "A change cannot be merged until at least one reviewer has signed off." Does this mean "merged with ghc-7.8" (or whatever the current stable branch is)? Or does it mean "merged with master"? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? I realize I've asked a lot here, and it might be too much to expect all of these answers to be on the page. If that's the case, could you perhaps link to relevant manuals or places to learn more? The way `arc` works, in particular, seems like magic; magic is very powerful, but it can be equally dangerous, and so I'd like to learn more. Thanks so much for doing all this! Richard On Jun 23, 2014, at 10:44 AM, Austin Seipp wrote: > Hi all, > > I went ahead and took some time to write some stuff down about > Phabricator, including some basic tips on the workflows and > applications here: > > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > It's definitely going to need more expanding. Do let me know if > anything is confusing. > > On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek wrote: >> Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) >> >> Janek >> >> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: >>> I read the friendly Arcanist manual and I wonder if we intend to have a >>> default .arcconfig file in the GHC repo? From the docs it seems like a good >>> idea. >>> >>> Janek >>> >>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: >>>> On 13/06/14 10:47, Jan Stolarek wrote: >>>>> It seems that most people are in favour of using Phabricator for code >>>>> review. So what are the next steps? Can we just start using the >>>>> existing phabricator instance? I'm working on some code right now that >>>>> definitely needs reviewing. >>>> >>>> You can use it, and a few of us have already been doing so. There isn't >>>> any Trac integration yet, but it works nicely for patch review. >>>> >>>> There's a short intro doc here: >>>> https://secure.phabricator.com/book/phabricator/article/differential/, >>>> but it's not hard to figure out the basics, and you'll learn by watching >>>> how other people use it. If you go to the Herald tool you have yourself >>>> automatically subscribed to diffs that touch areas of the code that >>>> you're interested in. >>>> >>>> Pro tip: the keyboard shortcuts are really useful, especially "z". Hit >>>> "?" to see all the shortcuts. >>>> >>>> Cheers, >>>> Simon >>>> >>>>> Janek >>>>> >>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >>>>>>> So, why not put everything on GutHub and use pull requests and so on? >>>>>> >>>>>> github just isn't great for doing code reviews. No side-by-side diffs, >>>>>> and it sends you a separate email for every single comment, there's no >>>>>> concept of a "review" consisting of multiple inline comments (unless >>>>>> I've missed something). I'm afraid if we were using this for regular >>>>>> reviews I would have to disable the email notifications, which makes >>>>>> it significantly less useful. >>>>>> >>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy to >>>>>>> believe that, but he also writes that using it requires installing >>>>>>> local software and quite a bit of work. Moreover, I like to add that >>>>>>> lots of people already know how to use GitHub and probably few know >>>>>>> Phabricator. >>>>>>> >>>>>>> So, we are talking about having a somewhat better tool in return for >>>>>>> three very significant disadvantages: (1) local installation, (2) >>>>>>> work to set up and maintain Phabricator, and (3) effort by many >>>>>>> people to learn to use it. >>>>>> >>>>>> Well, you've tipped the balance with "somewhat" and "significant" >>>>>> here, I'd say Phabricator is "significantly" better than github for >>>>>> code reviews, while installing arc is "somewhat" annoying :-) >>>>>> >>>>>> I have to admit it's not a no-brainer, but I do worry that github just >>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I spend my >>>>>> life inside Phabricator so I know it works really well. >>>>>> >>>>>> What's more, github doesn't let you put animated gifs in code reviews. >>>>>> Need I say more? >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>>> We also have a constant lack of sufficient men power. So, why spend >>>>>>> effort on building our own infrastructure, which will only increase >>>>>>> the hurdle for contributors (as they have to deal with an unknown >>>>>>> system)? Let?s outsource the effort to GitHub. >>>>>>> >>>>>>> Manuel >>>>>>> >>>>>>> Simon Peyton Jones : >>>>>>>> At the moment GHC's main sources aren't on github, which means that >>>>>>>> that (in my highly imperfect understanding) people can't submit pull >>>>>>>> requests or use their code review mechanisms. Moreover, most people >>>>>>>> don't have commit rights on the main GHC server, so if someone wants >>>>>>>> to offer a patch they can really only do so in textual form attached >>>>>>>> to Trac. People with commit rights can make a branch, but there's a >>>>>>>> danger that over a decade we'll accumulate zillions of dead branches >>>>>>>> which people forgot to delete. I think on github the branch is in a >>>>>>>> different repo, belonging to the patch author. >>>>>>>> >>>>>>>> So we really don't have a good work flow for creating, reviewing, >>>>>>>> modifying, and finally apply patches. I am no expert on these >>>>>>>> matters. If Phabricator would help with that I'm all for it. But >>>>>>>> perhaps there are other alternatives? Or is Phab the lead thing. >>>>>>>> Will it stay around? >>>>>>>> >>>>>>>> Also before going too far I'd really like someone to document the >>>>>>>> workflow carefully, and make sure it works from Windows equally >>>>>>>> well. >>>>>>>> >>>>>>>> I'm not too stressed out about losing the review trail of a patch. >>>>>>>> Much of it will be commenting on stuff that no longer appears in the >>>>>>>> final patch. Anything that's important should appear in a Note in >>>>>>>> the source code; even the commit messages are invisible until you >>>>>>>> really start digging. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> | -----Original Message----- >>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>>>>>>> | Austin Seipp >>>>>>>> | Sent: 06 June 2014 05:06 >>>>>>>> | To: ghc-devs at haskell.org >>>>>>>> | Subject: RFC: Phabricator for patches and code review >>>>>>>> | >>>>>>>> | Hello all, >>>>>>>> | >>>>>>>> | Recently, while doing server maintenance, several of the >>>>>>>> | administrators for Haskell.org set up an instance of >>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org >>>>>>>> | >>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of >>>>>>>> | tools for software development. Think of it like a polished, >>>>>>>> | semi-private GitHub with a lot of applications and tools for all >>>>>>>> | kinds of needs. We've been using it to do issue tracking for >>>>>>>> | Haskell.org maintenance and like it a lot so far. >>>>>>>> | >>>>>>>> | One very nice aspect of Phabricator though is it has a very nice >>>>>>>> | code review tool, called 'Differential', that is very useful. For >>>>>>>> | people who have used a tool like Review Board, it's similar. >>>>>>>> | Furthermore, it has a very convenient userland tool called >>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review and >>>>>>>> | get it merged when it's ready all from the command line. >>>>>>>> | >>>>>>>> | I'd like to see if people are interested in using Phab _strictly_ >>>>>>>> | for code review of GHC patches. It is a dedicated tool >>>>>>>> | specifically for this, and I think it works much better than Trac >>>>>>>> | or inline GitHub comments. >>>>>>>> | >>>>>>>> | Also, Phab can also support post-commit reviews. So if I touch >>>>>>>> | something in the runtime system and just push, perhaps Simon or >>>>>>>> | Edward would like to look, and they can be alerted right when I do >>>>>>>> | this, and then yell if I did something stupid. >>>>>>>> | >>>>>>>> | Before I go much further, I'd like to ask: is there *any* interest >>>>>>>> | in this? Or are people satisifed with Trac? The primary >>>>>>>> | motivations are roughly, in no particular order: >>>>>>>> | >>>>>>>> | 1) Code review is good for everyone, a good way for people to >>>>>>>> | learn the code and ask questions, and useful to give feedback to >>>>>>>> | newcomers. And even experienced GHC hackers can learn things from >>>>>>>> | reading code, as we all do regularly, or find things that need >>>>>>>> | cleanup. >>>>>>>> | >>>>>>>> | 2) Phabricator in particular makes it very easy to submit patches >>>>>>>> | for review. To submit a patch, I just run the command 'arc diff' >>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure >>>>>>>> | people are *alerted* when a patch might be relevant to them. >>>>>>>> | >>>>>>>> | 3) They can be uploaded and created from the command line, and >>>>>>>> | merged easily afterwords the same way. This is particularly useful >>>>>>>> | for newcomers, and for me. :) >>>>>>>> | >>>>>>>> | 4) Differential is dedicated to code review, and much better at >>>>>>>> | it than just reading patches on Trac IMO. >>>>>>>> | >>>>>>>> | 5) It supports both post-commit code review, as well as >>>>>>>> | pre-commit review. Post commit would be especially useful for us >>>>>>>> | too, I think. >>>>>>>> | >>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly >>>>>>>> | handle incoming patches. But I think in general it would be nice, >>>>>>>> | and make it a lot easier for newcomers to submit patches, and us >>>>>>>> | to look over them. >>>>>>>> | >>>>>>>> | Here's an example of a Differential code review: >>>>>>>> | >>>>>>>> | https://phabricator.haskell.org/D4 >>>>>>>> | >>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create >>>>>>>> | an account to login, but it shouldn't be much trouble, you can >>>>>>>> | login several ways. I'll fix the login requirement soon. Feel free >>>>>>>> | to read the code, comment on it, and play around. It's more of a >>>>>>>> | demonstration, but real code review would be welcome too. :) >>>>>>>> | >>>>>>>> | If people are interested in doing this, I can add notes to the >>>>>>>> | wiki pages for newcomers, and I'll send another email about Phab >>>>>>>> | so people can understand it a little better. But I want to ask >>>>>>>> | first. >>>>>>>> | >>>>>>>> | There is an argument that our team is so small, code review has >>>>>>>> | unnecessary burdens. But I think Phab could help a lot with >>>>>>>> | tracking outside patches and getting good reviews for incoming >>>>>>>> | patches, and it'll make it easier for newcomers. And experienced >>>>>>>> | pros can probably learn a thing as well. >>>>>>>> | >>>>>>>> | Again, to be clear, I don't propose we migrate anything to >>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do so and >>>>>>>> | it would be tons of work. I only propose we use it for code >>>>>>>> | review, which is perfectly fine, and how other projects like LLVM >>>>>>>> | do code review (they use Bugzilla). >>>>>>>> | >>>>>>>> | I also don't think the usage of Phabricator should be mandatory >>>>>>>> | (unless we decide that later because we like it), but I would like >>>>>>>> | to see people use it if possible. >>>>>>>> | >>>>>>>> | [1] http://phabricator.org >>>>>>>> | >>>>>>>> | -- >>>>>>>> | Regards, >>>>>>>> | >>>>>>>> | Austin Seipp, Haskell Consultant >>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ >>>>>>>> | _______________________________________________ >>>>>>>> | ghc-devs mailing list >>>>>>>> | ghc-devs at haskell.org >>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ghc-devs mailing list >>>>>>>> ghc-devs at haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Tue Jun 24 14:25:41 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 24 Jun 2014 10:25:41 -0400 Subject: Associated type instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com> <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu> I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right? If I'm right there, then no complaints from me. Richard On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones wrote: > I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? > > I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I?m just checking that no one has meanwhile become addicted to it. > > Simon > > From: Manuel Chakravarty [mailto:mchakravarty at me.com] > Sent: 24 June 2014 08:54 > To: Simon Peyton Jones > Cc: GHC List; ghc-devs at haskell.org > Subject: Re: Associated type instances > > Simon, > > I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? > > Manuel > > Simon Peyton Jones : > Friends > > I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. > > Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl > > All of this arose when thinking about fixing Trac #9063. > > I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). > > Does anyone object? > > Thanks > > Simon > > > > The issue > > Consider this: > > class C a where > type T a b :: * > > instance C [x] where > type T [x] b = x -> b > That is just what you?d expect. But currently this is allowed too: > > instance C [x] where > type T [x] Int = x -> Int > type T [x] Bool = Bool -> x > That is, GHC 7.8 allows many associated type instances, provided they don?t overlap. But, oddly you can?t further instantiate the instance pattern. This would make just as much sense, but isn?t allowed: > > instance C [x] where > type T [Int] b = b -> Int > type T [Bool] b = Bool -> b > Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like > > class D a where > type S (b :: Bool) a :: * > Now this would make some kind of sense: > > instance D [x] where > type S True [x] = x -> x > type S False [x] = x > But for closed kinds, you really want a closed type family. So this would be better: > > instance D [x] where > type S b [x] = SHelp x b > > type family SHelp x b where > SHelp x True = x -> x > SHelp x False = x > > So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. > > All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it?s a bit more complicated and indirect. > > My solution > > I propose to simplify substantially, as follows: > > ? The ?shared arguments? of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is ?shared?; and in class D, the second argument position of S is shared. > > ? A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have > > o type variables in the non-shared argument positions, and > > o an exact copy of the corresponding instance header type in the shared positions > > ? For each associated type you can have > > o at most one default declaration in the class declaration > > o at most one type instance declaration in the class instance declaration > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Jun 24 14:27:13 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 24 Jun 2014 16:27:13 +0200 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: I find the automatic squashing to rather harmful to the commit history. So if you have several nice commits that you want to send for review, don't use arc land to commit them, as it will ruin the history. Instead git push them as per normal and use `arc close` (IIRC) to close the code review. I also find it useful to remove lots of the arc gunk that was added to the commit message, to not pollute our revision history with data from some specific tool. On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg wrote: > Thanks so much for writing this! I have some questions: > > 1) I'm just setting things up on my machine. It says to `arc > install-certificate` in my GHC directory. Is it important precisely which > clone of GHC my directory is set up against? For example, my "pull" origin > is git://git.haskell.org/ghc.git and my "push" origin is ssh:// > git at git.haskell.org/ghc.git. Is this the right set-up? If this bit > matters, could you add it to the page? Or, if not, could you comment on > what `arc` is pulling from the ghc directory? > > 2) I'm confused about what, precisely, `arc diff` does. You describe that > it updates the review available online. Does that reference some git > commits? Do I need to push by `wip` branch before `arc diff`ing? Do I > *never* need to push my branch, because `arc diff` pushes it for me? Do I > *never* need to push my branch, because Phab uses other ways of moving the > code around? For better or worse, I tend to keep my branches local until > I'm ready to merge with master, and I want to know if this needs to change. > > 3) You say "A change cannot be merged until at least one reviewer has > signed off." Does this mean "merged with ghc-7.8" (or whatever the current > stable branch is)? Or does it mean "merged with master"? The former is the > status quo, but with a new route, so to speak. The latter is something new, > as several of us push directly to `master` without a review. I'm not > against such a change, per se, just trying to understand it. > > 4) Is it now compulsory to use Phab when contributing? This page makes it > sound that way. Again, no complaints -- just trying to understand it. > > 5) The page says to add `austin` as a reviewer. I would expect > `thoughtpolice`. What's up with Phab usernames? Do other people I know and > love have Phab usernames distinct from Trac usernames? > > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What > does the # signify? > > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but > I'm still unsure of what my local state and the git upstream state must be > beforehand for this to work. Will this ask me for a commit message? Will it > use the one I specified to Phab during `arc diff`? In general, I'm confused > about how much info `arc` pulls from various places to do its work. I know > I could learn by doing, but I'm afraid of mashing on the Phab and/or git > history as I do so. > > 8) Some of the same questions surround `arc patch`: What does my git state > need to be for this to work? > > 9) How do I contribute to others' revisions? Or, will this be obvious what > it comes to pass? > > I realize I've asked a lot here, and it might be too much to expect all of > these answers to be on the page. If that's the case, could you perhaps link > to relevant manuals or places to learn more? The way `arc` works, in > particular, seems like magic; magic is very powerful, but it can be equally > dangerous, and so I'd like to learn more. > > Thanks so much for doing all this! > Richard > > On Jun 23, 2014, at 10:44 AM, Austin Seipp wrote: > > > Hi all, > > > > I went ahead and took some time to write some stuff down about > > Phabricator, including some basic tips on the workflows and > > applications here: > > > > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > > > It's definitely going to need more expanding. Do let me know if > > anything is confusing. > > > > On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek > wrote: > >> Duh, ignore what I wrote. I just realized I'm working on a non-rebased > branch :-) > >> > >> Janek > >> > >> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: > >>> I read the friendly Arcanist manual and I wonder if we intend to have a > >>> default .arcconfig file in the GHC repo? From the docs it seems like a > good > >>> idea. > >>> > >>> Janek > >>> > >>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: > >>>> On 13/06/14 10:47, Jan Stolarek wrote: > >>>>> It seems that most people are in favour of using Phabricator for code > >>>>> review. So what are the next steps? Can we just start using the > >>>>> existing phabricator instance? I'm working on some code right now > that > >>>>> definitely needs reviewing. > >>>> > >>>> You can use it, and a few of us have already been doing so. There > isn't > >>>> any Trac integration yet, but it works nicely for patch review. > >>>> > >>>> There's a short intro doc here: > >>>> https://secure.phabricator.com/book/phabricator/article/differential/ > , > >>>> but it's not hard to figure out the basics, and you'll learn by > watching > >>>> how other people use it. If you go to the Herald tool you have > yourself > >>>> automatically subscribed to diffs that touch areas of the code that > >>>> you're interested in. > >>>> > >>>> Pro tip: the keyboard shortcuts are really useful, especially "z". > Hit > >>>> "?" to see all the shortcuts. > >>>> > >>>> Cheers, > >>>> Simon > >>>> > >>>>> Janek > >>>>> > >>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: > >>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > >>>>>>> So, why not put everything on GutHub and use pull requests and so > on? > >>>>>> > >>>>>> github just isn't great for doing code reviews. No side-by-side > diffs, > >>>>>> and it sends you a separate email for every single comment, there's > no > >>>>>> concept of a "review" consisting of multiple inline comments (unless > >>>>>> I've missed something). I'm afraid if we were using this for regular > >>>>>> reviews I would have to disable the email notifications, which makes > >>>>>> it significantly less useful. > >>>>>> > >>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy to > >>>>>>> believe that, but he also writes that using it requires installing > >>>>>>> local software and quite a bit of work. Moreover, I like to add > that > >>>>>>> lots of people already know how to use GitHub and probably few know > >>>>>>> Phabricator. > >>>>>>> > >>>>>>> So, we are talking about having a somewhat better tool in return > for > >>>>>>> three very significant disadvantages: (1) local installation, (2) > >>>>>>> work to set up and maintain Phabricator, and (3) effort by many > >>>>>>> people to learn to use it. > >>>>>> > >>>>>> Well, you've tipped the balance with "somewhat" and "significant" > >>>>>> here, I'd say Phabricator is "significantly" better than github for > >>>>>> code reviews, while installing arc is "somewhat" annoying :-) > >>>>>> > >>>>>> I have to admit it's not a no-brainer, but I do worry that github > just > >>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I spend > my > >>>>>> life inside Phabricator so I know it works really well. > >>>>>> > >>>>>> What's more, github doesn't let you put animated gifs in code > reviews. > >>>>>> Need I say more? > >>>>>> > >>>>>> Cheers, > >>>>>> Simon > >>>>>> > >>>>>>> We also have a constant lack of sufficient men power. So, why spend > >>>>>>> effort on building our own infrastructure, which will only increase > >>>>>>> the hurdle for contributors (as they have to deal with an unknown > >>>>>>> system)? Let?s outsource the effort to GitHub. > >>>>>>> > >>>>>>> Manuel > >>>>>>> > >>>>>>> Simon Peyton Jones : > >>>>>>>> At the moment GHC's main sources aren't on github, which means > that > >>>>>>>> that (in my highly imperfect understanding) people can't submit > pull > >>>>>>>> requests or use their code review mechanisms. Moreover, most > people > >>>>>>>> don't have commit rights on the main GHC server, so if someone > wants > >>>>>>>> to offer a patch they can really only do so in textual form > attached > >>>>>>>> to Trac. People with commit rights can make a branch, but there's > a > >>>>>>>> danger that over a decade we'll accumulate zillions of dead > branches > >>>>>>>> which people forgot to delete. I think on github the branch is > in a > >>>>>>>> different repo, belonging to the patch author. > >>>>>>>> > >>>>>>>> So we really don't have a good work flow for creating, reviewing, > >>>>>>>> modifying, and finally apply patches. I am no expert on these > >>>>>>>> matters. If Phabricator would help with that I'm all for it. But > >>>>>>>> perhaps there are other alternatives? Or is Phab the lead thing. > >>>>>>>> Will it stay around? > >>>>>>>> > >>>>>>>> Also before going too far I'd really like someone to document the > >>>>>>>> workflow carefully, and make sure it works from Windows equally > >>>>>>>> well. > >>>>>>>> > >>>>>>>> I'm not too stressed out about losing the review trail of a patch. > >>>>>>>> Much of it will be commenting on stuff that no longer appears in > the > >>>>>>>> final patch. Anything that's important should appear in a Note in > >>>>>>>> the source code; even the commit messages are invisible until you > >>>>>>>> really start digging. > >>>>>>>> > >>>>>>>> Simon > >>>>>>>> > >>>>>>>> | -----Original Message----- > >>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf > Of > >>>>>>>> | Austin Seipp > >>>>>>>> | Sent: 06 June 2014 05:06 > >>>>>>>> | To: ghc-devs at haskell.org > >>>>>>>> | Subject: RFC: Phabricator for patches and code review > >>>>>>>> | > >>>>>>>> | Hello all, > >>>>>>>> | > >>>>>>>> | Recently, while doing server maintenance, several of the > >>>>>>>> | administrators for Haskell.org set up an instance of > >>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org > >>>>>>>> | > >>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a suite > of > >>>>>>>> | tools for software development. Think of it like a polished, > >>>>>>>> | semi-private GitHub with a lot of applications and tools for all > >>>>>>>> | kinds of needs. We've been using it to do issue tracking for > >>>>>>>> | Haskell.org maintenance and like it a lot so far. > >>>>>>>> | > >>>>>>>> | One very nice aspect of Phabricator though is it has a very nice > >>>>>>>> | code review tool, called 'Differential', that is very useful. > For > >>>>>>>> | people who have used a tool like Review Board, it's similar. > >>>>>>>> | Furthermore, it has a very convenient userland tool called > >>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review > and > >>>>>>>> | get it merged when it's ready all from the command line. > >>>>>>>> | > >>>>>>>> | I'd like to see if people are interested in using Phab > _strictly_ > >>>>>>>> | for code review of GHC patches. It is a dedicated tool > >>>>>>>> | specifically for this, and I think it works much better than > Trac > >>>>>>>> | or inline GitHub comments. > >>>>>>>> | > >>>>>>>> | Also, Phab can also support post-commit reviews. So if I touch > >>>>>>>> | something in the runtime system and just push, perhaps Simon or > >>>>>>>> | Edward would like to look, and they can be alerted right when I > do > >>>>>>>> | this, and then yell if I did something stupid. > >>>>>>>> | > >>>>>>>> | Before I go much further, I'd like to ask: is there *any* > interest > >>>>>>>> | in this? Or are people satisifed with Trac? The primary > >>>>>>>> | motivations are roughly, in no particular order: > >>>>>>>> | > >>>>>>>> | 1) Code review is good for everyone, a good way for people to > >>>>>>>> | learn the code and ask questions, and useful to give feedback to > >>>>>>>> | newcomers. And even experienced GHC hackers can learn things > from > >>>>>>>> | reading code, as we all do regularly, or find things that need > >>>>>>>> | cleanup. > >>>>>>>> | > >>>>>>>> | 2) Phabricator in particular makes it very easy to submit > patches > >>>>>>>> | for review. To submit a patch, I just run the command 'arc diff' > >>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure > >>>>>>>> | people are *alerted* when a patch might be relevant to them. > >>>>>>>> | > >>>>>>>> | 3) They can be uploaded and created from the command line, and > >>>>>>>> | merged easily afterwords the same way. This is particularly > useful > >>>>>>>> | for newcomers, and for me. :) > >>>>>>>> | > >>>>>>>> | 4) Differential is dedicated to code review, and much better at > >>>>>>>> | it than just reading patches on Trac IMO. > >>>>>>>> | > >>>>>>>> | 5) It supports both post-commit code review, as well as > >>>>>>>> | pre-commit review. Post commit would be especially useful for us > >>>>>>>> | too, I think. > >>>>>>>> | > >>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly > >>>>>>>> | handle incoming patches. But I think in general it would be > nice, > >>>>>>>> | and make it a lot easier for newcomers to submit patches, and us > >>>>>>>> | to look over them. > >>>>>>>> | > >>>>>>>> | Here's an example of a Differential code review: > >>>>>>>> | > >>>>>>>> | https://phabricator.haskell.org/D4 > >>>>>>>> | > >>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create > >>>>>>>> | an account to login, but it shouldn't be much trouble, you can > >>>>>>>> | login several ways. I'll fix the login requirement soon. Feel > free > >>>>>>>> | to read the code, comment on it, and play around. It's more of a > >>>>>>>> | demonstration, but real code review would be welcome too. :) > >>>>>>>> | > >>>>>>>> | If people are interested in doing this, I can add notes to the > >>>>>>>> | wiki pages for newcomers, and I'll send another email about Phab > >>>>>>>> | so people can understand it a little better. But I want to ask > >>>>>>>> | first. > >>>>>>>> | > >>>>>>>> | There is an argument that our team is so small, code review has > >>>>>>>> | unnecessary burdens. But I think Phab could help a lot with > >>>>>>>> | tracking outside patches and getting good reviews for incoming > >>>>>>>> | patches, and it'll make it easier for newcomers. And experienced > >>>>>>>> | pros can probably learn a thing as well. > >>>>>>>> | > >>>>>>>> | Again, to be clear, I don't propose we migrate anything to > >>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do so > and > >>>>>>>> | it would be tons of work. I only propose we use it for code > >>>>>>>> | review, which is perfectly fine, and how other projects like > LLVM > >>>>>>>> | do code review (they use Bugzilla). > >>>>>>>> | > >>>>>>>> | I also don't think the usage of Phabricator should be mandatory > >>>>>>>> | (unless we decide that later because we like it), but I would > like > >>>>>>>> | to see people use it if possible. > >>>>>>>> | > >>>>>>>> | [1] http://phabricator.org > >>>>>>>> | > >>>>>>>> | -- > >>>>>>>> | Regards, > >>>>>>>> | > >>>>>>>> | Austin Seipp, Haskell Consultant > >>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ > >>>>>>>> | _______________________________________________ > >>>>>>>> | ghc-devs mailing list > >>>>>>>> | ghc-devs at haskell.org > >>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> ghc-devs mailing list > >>>>>>>> ghc-devs at haskell.org > >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> ghc-devs mailing list > >>>>>>> ghc-devs at haskell.org > >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>> > >>>>>> _______________________________________________ > >>>>>> ghc-devs mailing list > >>>>>> ghc-devs at haskell.org > >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>> > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> > > > > > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Jun 24 17:12:37 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 24 Jun 2014 12:12:37 -0500 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: Richard, Thanks, these are all actually really excellent questions. > 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my "pull" origin is git://git.haskell.org/ghc.git and my "push" origin is ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? The way 'arc install-certificate' knows what URL to use is based on a file in the GHC repository, called .arcconfig - this tells arcanist where the Phabricator instance is, and what the project callsign is. GHC's copy is here: https://github.com/ghc/ghc/blob/master/.arcconfig So all you need to do is run 'install-certificate' inside the main GHC repo, and you're done! If you've got a copy of HEAD from the past two weeks or so, you should be golden. Once install-certificate is done, it will write the certificate into a file called ~/.arcrc, so you don't have to install it again. > 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. You _never_ have to push a branch upstream if you don't want to (but if you'd like to keep your changes in a safe place until you merge them, feel free to put them on a wip/* branch!) What 'arc diff' does is this: when you run it, it calculates which commits you have made. It does this by comparing your current git repository to that of the *upstream* repository, the GHC repo. When it calculates the set of commits, 'arc diff' then sends them all for review. When you make a new commit, and say 'arc diff' again, it updates it. > 3) You say "A change cannot be merged until at least one reviewer has signed off." Does this mean "merged with ghc-7.8" (or whatever the current stable branch is)? Or does it mean "merged with master"? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. Not quite. All changes go into master first, after it has been reviewed. Afterwords, they may be picked onto the stable branch by me or Herbert. My only statement is that we cannot merge a patch from Phab to master until at least one person has given it the OK. If you put a review on Phabricator, I believe you should at least wait for one person to review it. That is, after all, what Phabricator is for! :) But note: you are *never* required to use Phabricator for your changes! If your workflow is good for you, I don't want to interrupt it. Instead, I want you to submit reviews so other people can read and understand your work - existing committers *are not* forced to do this. For example Richard, you obviously keep in close touch with Simon, so he's likely aware of your changes and their needs. There's no reason for you to ask SPJ for a review on a change you already have a handle on - just go ahead and push it! > 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. Nope! It might be so later (for external contributors without commit access), but I first need to document all the workflows so contributors can get a handle on it. So thanks for being the guinea pig :) But it won't ever be compulsory for all committers. Again, I want people to use Phab so they can have others read, understand, and comment about their work. There's no hard-line rule on if you should or should not submit a review - I will totally trust your judgement as to what you think is your best workflow. > 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? Sorry - I'm the only outlier. I believe every other person has the same username except for me. :P (This is partly due to the fact we use Phabricator for other Haskell.org projects as well, and we didn't explicitly plan to use it for GHC initially - so 'austin' was the name I picked when first setting up the instance). > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? Good question I totally forgot about. In Phabricator, there is a notion of 'projects', which have members. There is a project known as 'GHC', and in Phab, you can refer to this group of people within the project by a hashtag, essentially. So `#ghc` means "All people who are in the GHC project". The # is just a way of referring to a project or group, basically. Here's the current listing of people in the GHC project: https://phabricator.haskell.org/project/view/2/ - you should be able to (and feel free to) add yourself to that group from that linked page. > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. This is a good question, but it's one probably best answered with an example. I'll work something into the page to make this easier to understand. > 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? Ditto with this one - I'll work it into a tangible example to make it clearer. 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? Normally, you just do things 'the git way', so don't let Phab get in your way here. If you want to contribute to someone elses patches - work with them and send them your patch! Then they can update the review with you and their own work included. However, there is *another* related notion in Phab which is that of "commandeering" a review. Which should be pretty self explanatory: you take it over, and now *you* are in control of submitting new diffs. Sometimes this may happen if I work on something, leave it rotting, and someone else may want to pick it up. Anyway, thanks for all the excellent questions Richard, these were things that definitely would have confused others, so I'm glad you asked. I'll update the wiki page to be clearer. On Tue, Jun 24, 2014 at 9:09 AM, Richard Eisenberg wrote: > Thanks so much for writing this! I have some questions: > > 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my "pull" origin is git://git.haskell.org/ghc.git and my "push" origin is ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? > > 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. > > 3) You say "A change cannot be merged until at least one reviewer has signed off." Does this mean "merged with ghc-7.8" (or whatever the current stable branch is)? Or does it mean "merged with master"? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. > > 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. > > 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? > > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? > > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. > > 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? > > 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? > > I realize I've asked a lot here, and it might be too much to expect all of these answers to be on the page. If that's the case, could you perhaps link to relevant manuals or places to learn more? The way `arc` works, in particular, seems like magic; magic is very powerful, but it can be equally dangerous, and so I'd like to learn more. > > Thanks so much for doing all this! > Richard > > On Jun 23, 2014, at 10:44 AM, Austin Seipp wrote: > >> Hi all, >> >> I went ahead and took some time to write some stuff down about >> Phabricator, including some basic tips on the workflows and >> applications here: >> >> https://ghc.haskell.org/trac/ghc/wiki/Phabricator >> >> It's definitely going to need more expanding. Do let me know if >> anything is confusing. >> >> On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek wrote: >>> Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) >>> >>> Janek >>> >>> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: >>>> I read the friendly Arcanist manual and I wonder if we intend to have a >>>> default .arcconfig file in the GHC repo? From the docs it seems like a good >>>> idea. >>>> >>>> Janek >>>> >>>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: >>>>> On 13/06/14 10:47, Jan Stolarek wrote: >>>>>> It seems that most people are in favour of using Phabricator for code >>>>>> review. So what are the next steps? Can we just start using the >>>>>> existing phabricator instance? I'm working on some code right now that >>>>>> definitely needs reviewing. >>>>> >>>>> You can use it, and a few of us have already been doing so. There isn't >>>>> any Trac integration yet, but it works nicely for patch review. >>>>> >>>>> There's a short intro doc here: >>>>> https://secure.phabricator.com/book/phabricator/article/differential/, >>>>> but it's not hard to figure out the basics, and you'll learn by watching >>>>> how other people use it. If you go to the Herald tool you have yourself >>>>> automatically subscribed to diffs that touch areas of the code that >>>>> you're interested in. >>>>> >>>>> Pro tip: the keyboard shortcuts are really useful, especially "z". Hit >>>>> "?" to see all the shortcuts. >>>>> >>>>> Cheers, >>>>> Simon >>>>> >>>>>> Janek >>>>>> >>>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >>>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >>>>>>>> So, why not put everything on GutHub and use pull requests and so on? >>>>>>> >>>>>>> github just isn't great for doing code reviews. No side-by-side diffs, >>>>>>> and it sends you a separate email for every single comment, there's no >>>>>>> concept of a "review" consisting of multiple inline comments (unless >>>>>>> I've missed something). I'm afraid if we were using this for regular >>>>>>> reviews I would have to disable the email notifications, which makes >>>>>>> it significantly less useful. >>>>>>> >>>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy to >>>>>>>> believe that, but he also writes that using it requires installing >>>>>>>> local software and quite a bit of work. Moreover, I like to add that >>>>>>>> lots of people already know how to use GitHub and probably few know >>>>>>>> Phabricator. >>>>>>>> >>>>>>>> So, we are talking about having a somewhat better tool in return for >>>>>>>> three very significant disadvantages: (1) local installation, (2) >>>>>>>> work to set up and maintain Phabricator, and (3) effort by many >>>>>>>> people to learn to use it. >>>>>>> >>>>>>> Well, you've tipped the balance with "somewhat" and "significant" >>>>>>> here, I'd say Phabricator is "significantly" better than github for >>>>>>> code reviews, while installing arc is "somewhat" annoying :-) >>>>>>> >>>>>>> I have to admit it's not a no-brainer, but I do worry that github just >>>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I spend my >>>>>>> life inside Phabricator so I know it works really well. >>>>>>> >>>>>>> What's more, github doesn't let you put animated gifs in code reviews. >>>>>>> Need I say more? >>>>>>> >>>>>>> Cheers, >>>>>>> Simon >>>>>>> >>>>>>>> We also have a constant lack of sufficient men power. So, why spend >>>>>>>> effort on building our own infrastructure, which will only increase >>>>>>>> the hurdle for contributors (as they have to deal with an unknown >>>>>>>> system)? Let?s outsource the effort to GitHub. >>>>>>>> >>>>>>>> Manuel >>>>>>>> >>>>>>>> Simon Peyton Jones : >>>>>>>>> At the moment GHC's main sources aren't on github, which means that >>>>>>>>> that (in my highly imperfect understanding) people can't submit pull >>>>>>>>> requests or use their code review mechanisms. Moreover, most people >>>>>>>>> don't have commit rights on the main GHC server, so if someone wants >>>>>>>>> to offer a patch they can really only do so in textual form attached >>>>>>>>> to Trac. People with commit rights can make a branch, but there's a >>>>>>>>> danger that over a decade we'll accumulate zillions of dead branches >>>>>>>>> which people forgot to delete. I think on github the branch is in a >>>>>>>>> different repo, belonging to the patch author. >>>>>>>>> >>>>>>>>> So we really don't have a good work flow for creating, reviewing, >>>>>>>>> modifying, and finally apply patches. I am no expert on these >>>>>>>>> matters. If Phabricator would help with that I'm all for it. But >>>>>>>>> perhaps there are other alternatives? Or is Phab the lead thing. >>>>>>>>> Will it stay around? >>>>>>>>> >>>>>>>>> Also before going too far I'd really like someone to document the >>>>>>>>> workflow carefully, and make sure it works from Windows equally >>>>>>>>> well. >>>>>>>>> >>>>>>>>> I'm not too stressed out about losing the review trail of a patch. >>>>>>>>> Much of it will be commenting on stuff that no longer appears in the >>>>>>>>> final patch. Anything that's important should appear in a Note in >>>>>>>>> the source code; even the commit messages are invisible until you >>>>>>>>> really start digging. >>>>>>>>> >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> | -----Original Message----- >>>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>>>>>>>> | Austin Seipp >>>>>>>>> | Sent: 06 June 2014 05:06 >>>>>>>>> | To: ghc-devs at haskell.org >>>>>>>>> | Subject: RFC: Phabricator for patches and code review >>>>>>>>> | >>>>>>>>> | Hello all, >>>>>>>>> | >>>>>>>>> | Recently, while doing server maintenance, several of the >>>>>>>>> | administrators for Haskell.org set up an instance of >>>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org >>>>>>>>> | >>>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of >>>>>>>>> | tools for software development. Think of it like a polished, >>>>>>>>> | semi-private GitHub with a lot of applications and tools for all >>>>>>>>> | kinds of needs. We've been using it to do issue tracking for >>>>>>>>> | Haskell.org maintenance and like it a lot so far. >>>>>>>>> | >>>>>>>>> | One very nice aspect of Phabricator though is it has a very nice >>>>>>>>> | code review tool, called 'Differential', that is very useful. For >>>>>>>>> | people who have used a tool like Review Board, it's similar. >>>>>>>>> | Furthermore, it has a very convenient userland tool called >>>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review and >>>>>>>>> | get it merged when it's ready all from the command line. >>>>>>>>> | >>>>>>>>> | I'd like to see if people are interested in using Phab _strictly_ >>>>>>>>> | for code review of GHC patches. It is a dedicated tool >>>>>>>>> | specifically for this, and I think it works much better than Trac >>>>>>>>> | or inline GitHub comments. >>>>>>>>> | >>>>>>>>> | Also, Phab can also support post-commit reviews. So if I touch >>>>>>>>> | something in the runtime system and just push, perhaps Simon or >>>>>>>>> | Edward would like to look, and they can be alerted right when I do >>>>>>>>> | this, and then yell if I did something stupid. >>>>>>>>> | >>>>>>>>> | Before I go much further, I'd like to ask: is there *any* interest >>>>>>>>> | in this? Or are people satisifed with Trac? The primary >>>>>>>>> | motivations are roughly, in no particular order: >>>>>>>>> | >>>>>>>>> | 1) Code review is good for everyone, a good way for people to >>>>>>>>> | learn the code and ask questions, and useful to give feedback to >>>>>>>>> | newcomers. And even experienced GHC hackers can learn things from >>>>>>>>> | reading code, as we all do regularly, or find things that need >>>>>>>>> | cleanup. >>>>>>>>> | >>>>>>>>> | 2) Phabricator in particular makes it very easy to submit patches >>>>>>>>> | for review. To submit a patch, I just run the command 'arc diff' >>>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure >>>>>>>>> | people are *alerted* when a patch might be relevant to them. >>>>>>>>> | >>>>>>>>> | 3) They can be uploaded and created from the command line, and >>>>>>>>> | merged easily afterwords the same way. This is particularly useful >>>>>>>>> | for newcomers, and for me. :) >>>>>>>>> | >>>>>>>>> | 4) Differential is dedicated to code review, and much better at >>>>>>>>> | it than just reading patches on Trac IMO. >>>>>>>>> | >>>>>>>>> | 5) It supports both post-commit code review, as well as >>>>>>>>> | pre-commit review. Post commit would be especially useful for us >>>>>>>>> | too, I think. >>>>>>>>> | >>>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly >>>>>>>>> | handle incoming patches. But I think in general it would be nice, >>>>>>>>> | and make it a lot easier for newcomers to submit patches, and us >>>>>>>>> | to look over them. >>>>>>>>> | >>>>>>>>> | Here's an example of a Differential code review: >>>>>>>>> | >>>>>>>>> | https://phabricator.haskell.org/D4 >>>>>>>>> | >>>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create >>>>>>>>> | an account to login, but it shouldn't be much trouble, you can >>>>>>>>> | login several ways. I'll fix the login requirement soon. Feel free >>>>>>>>> | to read the code, comment on it, and play around. It's more of a >>>>>>>>> | demonstration, but real code review would be welcome too. :) >>>>>>>>> | >>>>>>>>> | If people are interested in doing this, I can add notes to the >>>>>>>>> | wiki pages for newcomers, and I'll send another email about Phab >>>>>>>>> | so people can understand it a little better. But I want to ask >>>>>>>>> | first. >>>>>>>>> | >>>>>>>>> | There is an argument that our team is so small, code review has >>>>>>>>> | unnecessary burdens. But I think Phab could help a lot with >>>>>>>>> | tracking outside patches and getting good reviews for incoming >>>>>>>>> | patches, and it'll make it easier for newcomers. And experienced >>>>>>>>> | pros can probably learn a thing as well. >>>>>>>>> | >>>>>>>>> | Again, to be clear, I don't propose we migrate anything to >>>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do so and >>>>>>>>> | it would be tons of work. I only propose we use it for code >>>>>>>>> | review, which is perfectly fine, and how other projects like LLVM >>>>>>>>> | do code review (they use Bugzilla). >>>>>>>>> | >>>>>>>>> | I also don't think the usage of Phabricator should be mandatory >>>>>>>>> | (unless we decide that later because we like it), but I would like >>>>>>>>> | to see people use it if possible. >>>>>>>>> | >>>>>>>>> | [1] http://phabricator.org >>>>>>>>> | >>>>>>>>> | -- >>>>>>>>> | Regards, >>>>>>>>> | >>>>>>>>> | Austin Seipp, Haskell Consultant >>>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ >>>>>>>>> | _______________________________________________ >>>>>>>>> | ghc-devs mailing list >>>>>>>>> | ghc-devs at haskell.org >>>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> ghc-devs mailing list >>>>>>>>> ghc-devs at haskell.org >>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ghc-devs mailing list >>>>>>>> ghc-devs at haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Jun 24 17:17:36 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 24 Jun 2014 12:17:36 -0500 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: Personally I don't particularly mind the fact Phabricator squashes things and adds onto the URL. For one it means we can always refer to the differential revision solely by the commit itself, as opposed to digging up some history. But also, Phab generally asks you to put some useful information in there. I've found myself to be much more explicit and verbose when filling out Phab commits than most other tools, and meaty, verbose commit messages are very useful IME. As for squashing, there's an argument to be made, I think, that this just requires a little practice to get comfortable with. :) For example, I have a review called D4: https://phabricator.haskell.org/D4 This really adds two separate things: it adds a set of flags to the frontend, and a set of optimizations to the backend (based on the flags). Really, this *should* be two reviews instead of one! The fact that Phabricator wants to squash them into a single commit when landing is a symptom of the problem, not the root problem, I think. So while I may have to fiddle to separate the two later (not really that hard,) I think this was more a case of me putting two unrelated things in one review. In fact it's very regular for GHC developers to squash commits themselves, and I know many of us do exactly that. So I think the main change is just having the tool embody this for us, as opposed to always doing it manually. On Tue, Jun 24, 2014 at 9:27 AM, Johan Tibell wrote: > I find the automatic squashing to rather harmful to the commit history. So > if you have several nice commits that you want to send for review, don't use > arc land to commit them, as it will ruin the history. Instead git push them > as per normal and use `arc close` (IIRC) to close the code review. I also > find it useful to remove lots of the arc gunk that was added to the commit > message, to not pollute our revision history with data from some specific > tool. > > > On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg > wrote: >> >> Thanks so much for writing this! I have some questions: >> >> 1) I'm just setting things up on my machine. It says to `arc >> install-certificate` in my GHC directory. Is it important precisely which >> clone of GHC my directory is set up against? For example, my "pull" origin >> is git://git.haskell.org/ghc.git and my "push" origin is >> ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit >> matters, could you add it to the page? Or, if not, could you comment on what >> `arc` is pulling from the ghc directory? >> >> 2) I'm confused about what, precisely, `arc diff` does. You describe that >> it updates the review available online. Does that reference some git >> commits? Do I need to push by `wip` branch before `arc diff`ing? Do I >> *never* need to push my branch, because `arc diff` pushes it for me? Do I >> *never* need to push my branch, because Phab uses other ways of moving the >> code around? For better or worse, I tend to keep my branches local until I'm >> ready to merge with master, and I want to know if this needs to change. >> >> 3) You say "A change cannot be merged until at least one reviewer has >> signed off." Does this mean "merged with ghc-7.8" (or whatever the current >> stable branch is)? Or does it mean "merged with master"? The former is the >> status quo, but with a new route, so to speak. The latter is something new, >> as several of us push directly to `master` without a review. I'm not against >> such a change, per se, just trying to understand it. >> >> 4) Is it now compulsory to use Phab when contributing? This page makes it >> sound that way. Again, no complaints -- just trying to understand it. >> >> 5) The page says to add `austin` as a reviewer. I would expect >> `thoughtpolice`. What's up with Phab usernames? Do other people I know and >> love have Phab usernames distinct from Trac usernames? >> >> 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What >> does the # signify? >> >> 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but >> I'm still unsure of what my local state and the git upstream state must be >> beforehand for this to work. Will this ask me for a commit message? Will it >> use the one I specified to Phab during `arc diff`? In general, I'm confused >> about how much info `arc` pulls from various places to do its work. I know I >> could learn by doing, but I'm afraid of mashing on the Phab and/or git >> history as I do so. >> >> 8) Some of the same questions surround `arc patch`: What does my git state >> need to be for this to work? >> >> 9) How do I contribute to others' revisions? Or, will this be obvious what >> it comes to pass? >> >> I realize I've asked a lot here, and it might be too much to expect all of >> these answers to be on the page. If that's the case, could you perhaps link >> to relevant manuals or places to learn more? The way `arc` works, in >> particular, seems like magic; magic is very powerful, but it can be equally >> dangerous, and so I'd like to learn more. >> >> Thanks so much for doing all this! >> Richard >> >> On Jun 23, 2014, at 10:44 AM, Austin Seipp wrote: >> >> > Hi all, >> > >> > I went ahead and took some time to write some stuff down about >> > Phabricator, including some basic tips on the workflows and >> > applications here: >> > >> > https://ghc.haskell.org/trac/ghc/wiki/Phabricator >> > >> > It's definitely going to need more expanding. Do let me know if >> > anything is confusing. >> > >> > On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek >> > wrote: >> >> Duh, ignore what I wrote. I just realized I'm working on a non-rebased >> >> branch :-) >> >> >> >> Janek >> >> >> >> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: >> >>> I read the friendly Arcanist manual and I wonder if we intend to have >> >>> a >> >>> default .arcconfig file in the GHC repo? From the docs it seems like a >> >>> good >> >>> idea. >> >>> >> >>> Janek >> >>> >> >>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: >> >>>> On 13/06/14 10:47, Jan Stolarek wrote: >> >>>>> It seems that most people are in favour of using Phabricator for >> >>>>> code >> >>>>> review. So what are the next steps? Can we just start using the >> >>>>> existing phabricator instance? I'm working on some code right now >> >>>>> that >> >>>>> definitely needs reviewing. >> >>>> >> >>>> You can use it, and a few of us have already been doing so. There >> >>>> isn't >> >>>> any Trac integration yet, but it works nicely for patch review. >> >>>> >> >>>> There's a short intro doc here: >> >>>> >> >>>> https://secure.phabricator.com/book/phabricator/article/differential/, >> >>>> but it's not hard to figure out the basics, and you'll learn by >> >>>> watching >> >>>> how other people use it. If you go to the Herald tool you have >> >>>> yourself >> >>>> automatically subscribed to diffs that touch areas of the code that >> >>>> you're interested in. >> >>>> >> >>>> Pro tip: the keyboard shortcuts are really useful, especially "z". >> >>>> Hit >> >>>> "?" to see all the shortcuts. >> >>>> >> >>>> Cheers, >> >>>> Simon >> >>>> >> >>>>> Janek >> >>>>> >> >>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >> >>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >> >>>>>>> So, why not put everything on GutHub and use pull requests and so >> >>>>>>> on? >> >>>>>> >> >>>>>> github just isn't great for doing code reviews. No side-by-side >> >>>>>> diffs, >> >>>>>> and it sends you a separate email for every single comment, there's >> >>>>>> no >> >>>>>> concept of a "review" consisting of multiple inline comments >> >>>>>> (unless >> >>>>>> I've missed something). I'm afraid if we were using this for >> >>>>>> regular >> >>>>>> reviews I would have to disable the email notifications, which >> >>>>>> makes >> >>>>>> it significantly less useful. >> >>>>>> >> >>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy to >> >>>>>>> believe that, but he also writes that using it requires installing >> >>>>>>> local software and quite a bit of work. Moreover, I like to add >> >>>>>>> that >> >>>>>>> lots of people already know how to use GitHub and probably few >> >>>>>>> know >> >>>>>>> Phabricator. >> >>>>>>> >> >>>>>>> So, we are talking about having a somewhat better tool in return >> >>>>>>> for >> >>>>>>> three very significant disadvantages: (1) local installation, (2) >> >>>>>>> work to set up and maintain Phabricator, and (3) effort by many >> >>>>>>> people to learn to use it. >> >>>>>> >> >>>>>> Well, you've tipped the balance with "somewhat" and "significant" >> >>>>>> here, I'd say Phabricator is "significantly" better than github for >> >>>>>> code reviews, while installing arc is "somewhat" annoying :-) >> >>>>>> >> >>>>>> I have to admit it's not a no-brainer, but I do worry that github >> >>>>>> just >> >>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I spend >> >>>>>> my >> >>>>>> life inside Phabricator so I know it works really well. >> >>>>>> >> >>>>>> What's more, github doesn't let you put animated gifs in code >> >>>>>> reviews. >> >>>>>> Need I say more? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Simon >> >>>>>> >> >>>>>>> We also have a constant lack of sufficient men power. So, why >> >>>>>>> spend >> >>>>>>> effort on building our own infrastructure, which will only >> >>>>>>> increase >> >>>>>>> the hurdle for contributors (as they have to deal with an unknown >> >>>>>>> system)? Let?s outsource the effort to GitHub. >> >>>>>>> >> >>>>>>> Manuel >> >>>>>>> >> >>>>>>> Simon Peyton Jones : >> >>>>>>>> At the moment GHC's main sources aren't on github, which means >> >>>>>>>> that >> >>>>>>>> that (in my highly imperfect understanding) people can't submit >> >>>>>>>> pull >> >>>>>>>> requests or use their code review mechanisms. Moreover, most >> >>>>>>>> people >> >>>>>>>> don't have commit rights on the main GHC server, so if someone >> >>>>>>>> wants >> >>>>>>>> to offer a patch they can really only do so in textual form >> >>>>>>>> attached >> >>>>>>>> to Trac. People with commit rights can make a branch, but there's >> >>>>>>>> a >> >>>>>>>> danger that over a decade we'll accumulate zillions of dead >> >>>>>>>> branches >> >>>>>>>> which people forgot to delete. I think on github the branch is >> >>>>>>>> in a >> >>>>>>>> different repo, belonging to the patch author. >> >>>>>>>> >> >>>>>>>> So we really don't have a good work flow for creating, reviewing, >> >>>>>>>> modifying, and finally apply patches. I am no expert on these >> >>>>>>>> matters. If Phabricator would help with that I'm all for it. But >> >>>>>>>> perhaps there are other alternatives? Or is Phab the lead thing. >> >>>>>>>> Will it stay around? >> >>>>>>>> >> >>>>>>>> Also before going too far I'd really like someone to document the >> >>>>>>>> workflow carefully, and make sure it works from Windows equally >> >>>>>>>> well. >> >>>>>>>> >> >>>>>>>> I'm not too stressed out about losing the review trail of a >> >>>>>>>> patch. >> >>>>>>>> Much of it will be commenting on stuff that no longer appears in >> >>>>>>>> the >> >>>>>>>> final patch. Anything that's important should appear in a Note >> >>>>>>>> in >> >>>>>>>> the source code; even the commit messages are invisible until you >> >>>>>>>> really start digging. >> >>>>>>>> >> >>>>>>>> Simon >> >>>>>>>> >> >>>>>>>> | -----Original Message----- >> >>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf >> >>>>>>>> Of >> >>>>>>>> | Austin Seipp >> >>>>>>>> | Sent: 06 June 2014 05:06 >> >>>>>>>> | To: ghc-devs at haskell.org >> >>>>>>>> | Subject: RFC: Phabricator for patches and code review >> >>>>>>>> | >> >>>>>>>> | Hello all, >> >>>>>>>> | >> >>>>>>>> | Recently, while doing server maintenance, several of the >> >>>>>>>> | administrators for Haskell.org set up an instance of >> >>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org >> >>>>>>>> | >> >>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a suite >> >>>>>>>> of >> >>>>>>>> | tools for software development. Think of it like a polished, >> >>>>>>>> | semi-private GitHub with a lot of applications and tools for >> >>>>>>>> all >> >>>>>>>> | kinds of needs. We've been using it to do issue tracking for >> >>>>>>>> | Haskell.org maintenance and like it a lot so far. >> >>>>>>>> | >> >>>>>>>> | One very nice aspect of Phabricator though is it has a very >> >>>>>>>> nice >> >>>>>>>> | code review tool, called 'Differential', that is very useful. >> >>>>>>>> For >> >>>>>>>> | people who have used a tool like Review Board, it's similar. >> >>>>>>>> | Furthermore, it has a very convenient userland tool called >> >>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review >> >>>>>>>> and >> >>>>>>>> | get it merged when it's ready all from the command line. >> >>>>>>>> | >> >>>>>>>> | I'd like to see if people are interested in using Phab >> >>>>>>>> _strictly_ >> >>>>>>>> | for code review of GHC patches. It is a dedicated tool >> >>>>>>>> | specifically for this, and I think it works much better than >> >>>>>>>> Trac >> >>>>>>>> | or inline GitHub comments. >> >>>>>>>> | >> >>>>>>>> | Also, Phab can also support post-commit reviews. So if I touch >> >>>>>>>> | something in the runtime system and just push, perhaps Simon or >> >>>>>>>> | Edward would like to look, and they can be alerted right when I >> >>>>>>>> do >> >>>>>>>> | this, and then yell if I did something stupid. >> >>>>>>>> | >> >>>>>>>> | Before I go much further, I'd like to ask: is there *any* >> >>>>>>>> interest >> >>>>>>>> | in this? Or are people satisifed with Trac? The primary >> >>>>>>>> | motivations are roughly, in no particular order: >> >>>>>>>> | >> >>>>>>>> | 1) Code review is good for everyone, a good way for people to >> >>>>>>>> | learn the code and ask questions, and useful to give feedback >> >>>>>>>> to >> >>>>>>>> | newcomers. And even experienced GHC hackers can learn things >> >>>>>>>> from >> >>>>>>>> | reading code, as we all do regularly, or find things that need >> >>>>>>>> | cleanup. >> >>>>>>>> | >> >>>>>>>> | 2) Phabricator in particular makes it very easy to submit >> >>>>>>>> patches >> >>>>>>>> | for review. To submit a patch, I just run the command 'arc >> >>>>>>>> diff' >> >>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure >> >>>>>>>> | people are *alerted* when a patch might be relevant to them. >> >>>>>>>> | >> >>>>>>>> | 3) They can be uploaded and created from the command line, and >> >>>>>>>> | merged easily afterwords the same way. This is particularly >> >>>>>>>> useful >> >>>>>>>> | for newcomers, and for me. :) >> >>>>>>>> | >> >>>>>>>> | 4) Differential is dedicated to code review, and much better >> >>>>>>>> at >> >>>>>>>> | it than just reading patches on Trac IMO. >> >>>>>>>> | >> >>>>>>>> | 5) It supports both post-commit code review, as well as >> >>>>>>>> | pre-commit review. Post commit would be especially useful for >> >>>>>>>> us >> >>>>>>>> | too, I think. >> >>>>>>>> | >> >>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly >> >>>>>>>> | handle incoming patches. But I think in general it would be >> >>>>>>>> nice, >> >>>>>>>> | and make it a lot easier for newcomers to submit patches, and >> >>>>>>>> us >> >>>>>>>> | to look over them. >> >>>>>>>> | >> >>>>>>>> | Here's an example of a Differential code review: >> >>>>>>>> | >> >>>>>>>> | https://phabricator.haskell.org/D4 >> >>>>>>>> | >> >>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to >> >>>>>>>> create >> >>>>>>>> | an account to login, but it shouldn't be much trouble, you can >> >>>>>>>> | login several ways. I'll fix the login requirement soon. Feel >> >>>>>>>> free >> >>>>>>>> | to read the code, comment on it, and play around. It's more of >> >>>>>>>> a >> >>>>>>>> | demonstration, but real code review would be welcome too. :) >> >>>>>>>> | >> >>>>>>>> | If people are interested in doing this, I can add notes to the >> >>>>>>>> | wiki pages for newcomers, and I'll send another email about >> >>>>>>>> Phab >> >>>>>>>> | so people can understand it a little better. But I want to ask >> >>>>>>>> | first. >> >>>>>>>> | >> >>>>>>>> | There is an argument that our team is so small, code review has >> >>>>>>>> | unnecessary burdens. But I think Phab could help a lot with >> >>>>>>>> | tracking outside patches and getting good reviews for incoming >> >>>>>>>> | patches, and it'll make it easier for newcomers. And >> >>>>>>>> experienced >> >>>>>>>> | pros can probably learn a thing as well. >> >>>>>>>> | >> >>>>>>>> | Again, to be clear, I don't propose we migrate anything to >> >>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do so >> >>>>>>>> and >> >>>>>>>> | it would be tons of work. I only propose we use it for code >> >>>>>>>> | review, which is perfectly fine, and how other projects like >> >>>>>>>> LLVM >> >>>>>>>> | do code review (they use Bugzilla). >> >>>>>>>> | >> >>>>>>>> | I also don't think the usage of Phabricator should be mandatory >> >>>>>>>> | (unless we decide that later because we like it), but I would >> >>>>>>>> like >> >>>>>>>> | to see people use it if possible. >> >>>>>>>> | >> >>>>>>>> | [1] http://phabricator.org >> >>>>>>>> | >> >>>>>>>> | -- >> >>>>>>>> | Regards, >> >>>>>>>> | >> >>>>>>>> | Austin Seipp, Haskell Consultant >> >>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ >> >>>>>>>> | _______________________________________________ >> >>>>>>>> | ghc-devs mailing list >> >>>>>>>> | ghc-devs at haskell.org >> >>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> ghc-devs mailing list >> >>>>>>>> ghc-devs at haskell.org >> >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> ghc-devs mailing list >> >>>>>>> ghc-devs at haskell.org >> >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> ghc-devs mailing list >> >>>>>> ghc-devs at haskell.org >> >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>>>> >> >>>>> _______________________________________________ >> >>>>> ghc-devs mailing list >> >>>>> ghc-devs at haskell.org >> >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>> >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs at haskell.org >> >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> >> > >> > >> > >> > -- >> > Regards, >> > >> > Austin Seipp, Haskell Consultant >> > Well-Typed LLP, http://www.well-typed.com/ >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Jun 24 16:16:58 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 16:16:58 +0000 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EB2B8@DB3PRD3001MB020.064d.mgd.msft.net> Sounds plausible to me, but please can this workflow be documented on the wiki page? From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 24 June 2014 15:27 To: Richard Eisenberg Cc: ghc-devs at haskell.org Subject: Re: Phabricator for patches and code review I find the automatic squashing to rather harmful to the commit history. So if you have several nice commits that you want to send for review, don't use arc land to commit them, as it will ruin the history. Instead git push them as per normal and use `arc close` (IIRC) to close the code review. I also find it useful to remove lots of the arc gunk that was added to the commit message, to not pollute our revision history with data from some specific tool. On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg > wrote: Thanks so much for writing this! I have some questions: 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my "pull" origin is git://git.haskell.org/ghc.git and my "push" origin is ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. 3) You say "A change cannot be merged until at least one reviewer has signed off." Does this mean "merged with ghc-7.8" (or whatever the current stable branch is)? Or does it mean "merged with master"? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? I realize I've asked a lot here, and it might be too much to expect all of these answers to be on the page. If that's the case, could you perhaps link to relevant manuals or places to learn more? The way `arc` works, in particular, seems like magic; magic is very powerful, but it can be equally dangerous, and so I'd like to learn more. Thanks so much for doing all this! Richard On Jun 23, 2014, at 10:44 AM, Austin Seipp > wrote: > Hi all, > > I went ahead and took some time to write some stuff down about > Phabricator, including some basic tips on the workflows and > applications here: > > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > It's definitely going to need more expanding. Do let me know if > anything is confusing. > > On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek > wrote: >> Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) >> >> Janek >> >> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: >>> I read the friendly Arcanist manual and I wonder if we intend to have a >>> default .arcconfig file in the GHC repo? From the docs it seems like a good >>> idea. >>> >>> Janek >>> >>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: >>>> On 13/06/14 10:47, Jan Stolarek wrote: >>>>> It seems that most people are in favour of using Phabricator for code >>>>> review. So what are the next steps? Can we just start using the >>>>> existing phabricator instance? I'm working on some code right now that >>>>> definitely needs reviewing. >>>> >>>> You can use it, and a few of us have already been doing so. There isn't >>>> any Trac integration yet, but it works nicely for patch review. >>>> >>>> There's a short intro doc here: >>>> https://secure.phabricator.com/book/phabricator/article/differential/, >>>> but it's not hard to figure out the basics, and you'll learn by watching >>>> how other people use it. If you go to the Herald tool you have yourself >>>> automatically subscribed to diffs that touch areas of the code that >>>> you're interested in. >>>> >>>> Pro tip: the keyboard shortcuts are really useful, especially "z". Hit >>>> "?" to see all the shortcuts. >>>> >>>> Cheers, >>>> Simon >>>> >>>>> Janek >>>>> >>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: >>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: >>>>>>> So, why not put everything on GutHub and use pull requests and so on? >>>>>> >>>>>> github just isn't great for doing code reviews. No side-by-side diffs, >>>>>> and it sends you a separate email for every single comment, there's no >>>>>> concept of a "review" consisting of multiple inline comments (unless >>>>>> I've missed something). I'm afraid if we were using this for regular >>>>>> reviews I would have to disable the email notifications, which makes >>>>>> it significantly less useful. >>>>>> >>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy to >>>>>>> believe that, but he also writes that using it requires installing >>>>>>> local software and quite a bit of work. Moreover, I like to add that >>>>>>> lots of people already know how to use GitHub and probably few know >>>>>>> Phabricator. >>>>>>> >>>>>>> So, we are talking about having a somewhat better tool in return for >>>>>>> three very significant disadvantages: (1) local installation, (2) >>>>>>> work to set up and maintain Phabricator, and (3) effort by many >>>>>>> people to learn to use it. >>>>>> >>>>>> Well, you've tipped the balance with "somewhat" and "significant" >>>>>> here, I'd say Phabricator is "significantly" better than github for >>>>>> code reviews, while installing arc is "somewhat" annoying :-) >>>>>> >>>>>> I have to admit it's not a no-brainer, but I do worry that github just >>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I spend my >>>>>> life inside Phabricator so I know it works really well. >>>>>> >>>>>> What's more, github doesn't let you put animated gifs in code reviews. >>>>>> Need I say more? >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>>> We also have a constant lack of sufficient men power. So, why spend >>>>>>> effort on building our own infrastructure, which will only increase >>>>>>> the hurdle for contributors (as they have to deal with an unknown >>>>>>> system)? Let?s outsource the effort to GitHub. >>>>>>> >>>>>>> Manuel >>>>>>> >>>>>>> Simon Peyton Jones >: >>>>>>>> At the moment GHC's main sources aren't on github, which means that >>>>>>>> that (in my highly imperfect understanding) people can't submit pull >>>>>>>> requests or use their code review mechanisms. Moreover, most people >>>>>>>> don't have commit rights on the main GHC server, so if someone wants >>>>>>>> to offer a patch they can really only do so in textual form attached >>>>>>>> to Trac. People with commit rights can make a branch, but there's a >>>>>>>> danger that over a decade we'll accumulate zillions of dead branches >>>>>>>> which people forgot to delete. I think on github the branch is in a >>>>>>>> different repo, belonging to the patch author. >>>>>>>> >>>>>>>> So we really don't have a good work flow for creating, reviewing, >>>>>>>> modifying, and finally apply patches. I am no expert on these >>>>>>>> matters. If Phabricator would help with that I'm all for it. But >>>>>>>> perhaps there are other alternatives? Or is Phab the lead thing. >>>>>>>> Will it stay around? >>>>>>>> >>>>>>>> Also before going too far I'd really like someone to document the >>>>>>>> workflow carefully, and make sure it works from Windows equally >>>>>>>> well. >>>>>>>> >>>>>>>> I'm not too stressed out about losing the review trail of a patch. >>>>>>>> Much of it will be commenting on stuff that no longer appears in the >>>>>>>> final patch. Anything that's important should appear in a Note in >>>>>>>> the source code; even the commit messages are invisible until you >>>>>>>> really start digging. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> | -----Original Message----- >>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>>>>>>> | Austin Seipp >>>>>>>> | Sent: 06 June 2014 05:06 >>>>>>>> | To: ghc-devs at haskell.org >>>>>>>> | Subject: RFC: Phabricator for patches and code review >>>>>>>> | >>>>>>>> | Hello all, >>>>>>>> | >>>>>>>> | Recently, while doing server maintenance, several of the >>>>>>>> | administrators for Haskell.org set up an instance of >>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org >>>>>>>> | >>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a suite of >>>>>>>> | tools for software development. Think of it like a polished, >>>>>>>> | semi-private GitHub with a lot of applications and tools for all >>>>>>>> | kinds of needs. We've been using it to do issue tracking for >>>>>>>> | Haskell.org maintenance and like it a lot so far. >>>>>>>> | >>>>>>>> | One very nice aspect of Phabricator though is it has a very nice >>>>>>>> | code review tool, called 'Differential', that is very useful. For >>>>>>>> | people who have used a tool like Review Board, it's similar. >>>>>>>> | Furthermore, it has a very convenient userland tool called >>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review and >>>>>>>> | get it merged when it's ready all from the command line. >>>>>>>> | >>>>>>>> | I'd like to see if people are interested in using Phab _strictly_ >>>>>>>> | for code review of GHC patches. It is a dedicated tool >>>>>>>> | specifically for this, and I think it works much better than Trac >>>>>>>> | or inline GitHub comments. >>>>>>>> | >>>>>>>> | Also, Phab can also support post-commit reviews. So if I touch >>>>>>>> | something in the runtime system and just push, perhaps Simon or >>>>>>>> | Edward would like to look, and they can be alerted right when I do >>>>>>>> | this, and then yell if I did something stupid. >>>>>>>> | >>>>>>>> | Before I go much further, I'd like to ask: is there *any* interest >>>>>>>> | in this? Or are people satisifed with Trac? The primary >>>>>>>> | motivations are roughly, in no particular order: >>>>>>>> | >>>>>>>> | 1) Code review is good for everyone, a good way for people to >>>>>>>> | learn the code and ask questions, and useful to give feedback to >>>>>>>> | newcomers. And even experienced GHC hackers can learn things from >>>>>>>> | reading code, as we all do regularly, or find things that need >>>>>>>> | cleanup. >>>>>>>> | >>>>>>>> | 2) Phabricator in particular makes it very easy to submit patches >>>>>>>> | for review. To submit a patch, I just run the command 'arc diff' >>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure >>>>>>>> | people are *alerted* when a patch might be relevant to them. >>>>>>>> | >>>>>>>> | 3) They can be uploaded and created from the command line, and >>>>>>>> | merged easily afterwords the same way. This is particularly useful >>>>>>>> | for newcomers, and for me. :) >>>>>>>> | >>>>>>>> | 4) Differential is dedicated to code review, and much better at >>>>>>>> | it than just reading patches on Trac IMO. >>>>>>>> | >>>>>>>> | 5) It supports both post-commit code review, as well as >>>>>>>> | pre-commit review. Post commit would be especially useful for us >>>>>>>> | too, I think. >>>>>>>> | >>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly >>>>>>>> | handle incoming patches. But I think in general it would be nice, >>>>>>>> | and make it a lot easier for newcomers to submit patches, and us >>>>>>>> | to look over them. >>>>>>>> | >>>>>>>> | Here's an example of a Differential code review: >>>>>>>> | >>>>>>>> | https://phabricator.haskell.org/D4 >>>>>>>> | >>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to create >>>>>>>> | an account to login, but it shouldn't be much trouble, you can >>>>>>>> | login several ways. I'll fix the login requirement soon. Feel free >>>>>>>> | to read the code, comment on it, and play around. It's more of a >>>>>>>> | demonstration, but real code review would be welcome too. :) >>>>>>>> | >>>>>>>> | If people are interested in doing this, I can add notes to the >>>>>>>> | wiki pages for newcomers, and I'll send another email about Phab >>>>>>>> | so people can understand it a little better. But I want to ask >>>>>>>> | first. >>>>>>>> | >>>>>>>> | There is an argument that our team is so small, code review has >>>>>>>> | unnecessary burdens. But I think Phab could help a lot with >>>>>>>> | tracking outside patches and getting good reviews for incoming >>>>>>>> | patches, and it'll make it easier for newcomers. And experienced >>>>>>>> | pros can probably learn a thing as well. >>>>>>>> | >>>>>>>> | Again, to be clear, I don't propose we migrate anything to >>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do so and >>>>>>>> | it would be tons of work. I only propose we use it for code >>>>>>>> | review, which is perfectly fine, and how other projects like LLVM >>>>>>>> | do code review (they use Bugzilla). >>>>>>>> | >>>>>>>> | I also don't think the usage of Phabricator should be mandatory >>>>>>>> | (unless we decide that later because we like it), but I would like >>>>>>>> | to see people use it if possible. >>>>>>>> | >>>>>>>> | [1] http://phabricator.org >>>>>>>> | >>>>>>>> | -- >>>>>>>> | Regards, >>>>>>>> | >>>>>>>> | Austin Seipp, Haskell Consultant >>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ >>>>>>>> | _______________________________________________ >>>>>>>> | ghc-devs mailing list >>>>>>>> | ghc-devs at haskell.org >>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ghc-devs mailing list >>>>>>>> ghc-devs at haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jun 24 16:37:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 16:37:49 +0000 Subject: Help needed: parsing pattern synonym contexts In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> What do you mean by "doesn't work"? Crashes? Fails to build with some error? Builds but doesn't parse what you expect? In the latter case, what happened to the shift/reduce and reduce/reduce errors reported by Happy? Esp the latter. If you are getting more you need to track them down. For exmape if I see pattern P ... and I've gotten to the P. Have I seen an empty forall, and this is the beginning of context, or have I seen an empty patsyn_context, and this is the beginning of constr_stuff. I think this'll be a reduce/reduce error. I think it may be helped by patsyn_contxt :: forall | forall context '=>' c.f the defn of 'constr'. IN haste Simoin | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 24 June 2014 13:12 | To: GHC Devs | Subject: Help needed: parsing pattern synonym contexts | | Hi, | | I'm working on adding type signatures to pattern synonyms. The syntax | I'm after would look something like, e.g.: | | pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] | | My problem is with parsing the two contexts. I wrote the parser in the | following way, which I felt natural (actions omitted for brevity) | | pattern_synonym_sig :: { LSig RdrName } | : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context | type | | patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType | RdrName)) } | : constr_stuff | | patsyn_context :: { LHsContext RdrName } | : {- empty -} | | forall context '=>' | | However, this doesn't work, no matter if those contexts are present or | not. If I remove both contexts from the rules, i.e. if I replace | pattern_synonym_sig with | | : 'pattern' patsyn_stuff '::' type | | then parsing succeeds when there are no contexts on either side. I've | also tried | | : 'pattern' patsyn_stuff '::' ctype | | with the intention of recovering the required context from the ctype | (and I could do similar tricks to get the provided context from the | patsyn_stuff by using a modified version of constr_stuff); however, even | that doesn't work as I expected it, i.e. with this latter version, this: | | pattern Single a :: (Eq a) => [a] | | fails with a parse error on "::". | | Can someone help me out here please? | | Thanks, | Gergo | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Jun 24 16:16:10 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 16:16:10 +0000 Subject: Associated type instances In-Reply-To: <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu> References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net> <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com> <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net> <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EB29F@DB3PRD3001MB020.064d.mgd.msft.net> Yes I should have said that originally. My proposed change has no loss of expressiveness; at worst you need a helper type family Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 24 June 2014 15:26 To: Simon Peyton Jones Cc: GHC List; Manuel Chakravarty; ghc-devs at haskell.org Subject: Re: Associated type instances I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right? If I'm right there, then no complaints from me. Richard On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones > wrote: I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakravarty at me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs at haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones >: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Tue Jun 24 20:36:09 2014 From: igloo at earth.li (Ian Lynagh) Date: Tue, 24 Jun 2014 21:36:09 +0100 Subject: GHC silently turns off dynamic output, should this be an error? In-Reply-To: References: Message-ID: <20140624203609.GA12853@matrix.chaos.earth.li> On Mon, Jun 23, 2014 at 12:58:16PM -0500, Christopher Rodrigues wrote: > > Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with > different interface hashes? You can, for example, compile package foo the vanilla way with -O, and the dynamic way without -O. You'll then get mismatched hashes. If you then try to compile bar (which depends on foo) with -dynamic-too then the idea was that it would transparently fall back to compiling the two ways separately. Otherwise every build system (Cabal, make rules, etc) that wants to use -dynamic-too would have to handle this failure and either fail or fall back itself. Thanks Ian From simonpj at microsoft.com Tue Jun 24 20:21:56 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Jun 2014 20:21:56 +0000 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EB8C1@DB3PRD3001MB020.064d.mgd.msft.net> Austin, replying by email is good, and your responses are helpful. But modifying the wiki page so that the next Richard will not even have to ask the questions is 10x better! Maybe you can just cut/paste text into it.... Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 24 June 2014 18:13 | To: Richard Eisenberg | Cc: ghc-devs at haskell.org | Subject: Re: Phabricator for patches and code review | | Richard, | | Thanks, these are all actually really excellent questions. | | > 1) I'm just setting things up on my machine. It says to `arc install- | certificate` in my GHC directory. Is it important precisely which clone | of GHC my directory is set up against? For example, my "pull" origin is | git://git.haskell.org/ghc.git and my "push" origin is | ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit | matters, could you add it to the page? Or, if not, could you comment on | what `arc` is pulling from the ghc directory? | | The way 'arc install-certificate' knows what URL to use is based on a | file in the GHC repository, called .arcconfig - this tells arcanist | where the Phabricator instance is, and what the project callsign is. | GHC's copy is here: https://github.com/ghc/ghc/blob/master/.arcconfig | | So all you need to do is run 'install-certificate' inside the main GHC | repo, and you're done! If you've got a copy of HEAD from the past two | weeks or so, you should be golden. Once install-certificate is done, | it will write the certificate into a file called ~/.arcrc, so you | don't have to install it again. | | > 2) I'm confused about what, precisely, `arc diff` does. You describe | that it updates the review available online. Does that reference some git | commits? Do I need to push by `wip` branch before `arc diff`ing? Do I | *never* need to push my branch, because `arc diff` pushes it for me? Do I | *never* need to push my branch, because Phab uses other ways of moving | the code around? For better or worse, I tend to keep my branches local | until I'm ready to merge with master, and I want to know if this needs to | change. | | You _never_ have to push a branch upstream if you don't want to (but | if you'd like to keep your changes in a safe place until you merge | them, feel free to put them on a wip/* branch!) | | What 'arc diff' does is this: when you run it, it calculates which | commits you have made. It does this by comparing your current git | repository to that of the *upstream* repository, the GHC repo. When it | calculates the set of commits, 'arc diff' then sends them all for | review. When you make a new commit, and say 'arc diff' again, it | updates it. | | > 3) You say "A change cannot be merged until at least one reviewer has | signed off." Does this mean "merged with ghc-7.8" (or whatever the | current stable branch is)? Or does it mean "merged with master"? The | former is the status quo, but with a new route, so to speak. The latter | is something new, as several of us push directly to `master` without a | review. I'm not against such a change, per se, just trying to understand | it. | | Not quite. All changes go into master first, after it has been | reviewed. Afterwords, they may be picked onto the stable branch by me | or Herbert. | | My only statement is that we cannot merge a patch from Phab to master | until at least one person has given it the OK. If you put a review on | Phabricator, I believe you should at least wait for one person to | review it. That is, after all, what Phabricator is for! :) | | But note: you are *never* required to use Phabricator for your | changes! If your workflow is good for you, I don't want to interrupt | it. Instead, I want you to submit reviews so other people can read and | understand your work - existing committers *are not* forced to do | this. For example Richard, you obviously keep in close touch with | Simon, so he's likely aware of your changes and their needs. There's | no reason for you to ask SPJ for a review on a change you already have | a handle on - just go ahead and push it! | | > 4) Is it now compulsory to use Phab when contributing? This page makes | it sound that way. Again, no complaints -- just trying to understand it. | | Nope! It might be so later (for external contributors without commit | access), but I first need to document all the workflows so | contributors can get a handle on it. So thanks for being the guinea | pig :) But it won't ever be compulsory for all committers. | | Again, I want people to use Phab so they can have others read, | understand, and comment about their work. There's no hard-line rule on | if you should or should not submit a review - I will totally trust | your judgement as to what you think is your best workflow. | | > 5) The page says to add `austin` as a reviewer. I would expect | `thoughtpolice`. What's up with Phab usernames? Do other people I know | and love have Phab usernames distinct from Trac usernames? | | Sorry - I'm the only outlier. I believe every other person has the | same username except for me. :P (This is partly due to the fact we use | Phabricator for other Haskell.org projects as well, and we didn't | explicitly plan to use it for GHC initially - so 'austin' was the name | I picked when first setting up the instance). | | > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What | does the # signify? | | Good question I totally forgot about. In Phabricator, there is a | notion of 'projects', which have members. There is a project known as | 'GHC', and in Phab, you can refer to this group of people within the | project by a hashtag, essentially. So `#ghc` means "All people who are | in the GHC project". The # is just a way of referring to a project or | group, basically. | | Here's the current listing of people in the GHC project: | https://phabricator.haskell.org/project/view/2/ - you should be able | to (and feel free to) add yourself to that group from that linked | page. | | > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but | I'm still unsure of what my local state and the git upstream state must | be beforehand for this to work. Will this ask me for a commit message? | Will it use the one I specified to Phab during `arc diff`? In general, | I'm confused about how much info `arc` pulls from various places to do | its work. I know I could learn by doing, but I'm afraid of mashing on the | Phab and/or git history as I do so. | | This is a good question, but it's one probably best answered with an | example. I'll work something into the page to make this easier to | understand. | | > 8) Some of the same questions surround `arc patch`: What does my git | state need to be for this to work? | | Ditto with this one - I'll work it into a tangible example to make it | clearer. | | 9) How do I contribute to others' revisions? Or, will this be obvious | what it comes to pass? | | Normally, you just do things 'the git way', so don't let Phab get in | your way here. If you want to contribute to someone elses patches - | work with them and send them your patch! Then they can update the | review with you and their own work included. | | However, there is *another* related notion in Phab which is that of | "commandeering" a review. Which should be pretty self explanatory: you | take it over, and now *you* are in control of submitting new diffs. | Sometimes this may happen if I work on something, leave it rotting, | and someone else may want to pick it up. | | Anyway, thanks for all the excellent questions Richard, these were | things that definitely would have confused others, so I'm glad you | asked. I'll update the wiki page to be clearer. | | On Tue, Jun 24, 2014 at 9:09 AM, Richard Eisenberg | wrote: | > Thanks so much for writing this! I have some questions: | > | > 1) I'm just setting things up on my machine. It says to `arc install- | certificate` in my GHC directory. Is it important precisely which clone | of GHC my directory is set up against? For example, my "pull" origin is | git://git.haskell.org/ghc.git and my "push" origin is | ssh://git at git.haskell.org/ghc.git. Is this the right set-up? If this bit | matters, could you add it to the page? Or, if not, could you comment on | what `arc` is pulling from the ghc directory? | > | > 2) I'm confused about what, precisely, `arc diff` does. You describe | that it updates the review available online. Does that reference some git | commits? Do I need to push by `wip` branch before `arc diff`ing? Do I | *never* need to push my branch, because `arc diff` pushes it for me? Do I | *never* need to push my branch, because Phab uses other ways of moving | the code around? For better or worse, I tend to keep my branches local | until I'm ready to merge with master, and I want to know if this needs to | change. | > | > 3) You say "A change cannot be merged until at least one reviewer has | signed off." Does this mean "merged with ghc-7.8" (or whatever the | current stable branch is)? Or does it mean "merged with master"? The | former is the status quo, but with a new route, so to speak. The latter | is something new, as several of us push directly to `master` without a | review. I'm not against such a change, per se, just trying to understand | it. | > | > 4) Is it now compulsory to use Phab when contributing? This page makes | it sound that way. Again, no complaints -- just trying to understand it. | > | > 5) The page says to add `austin` as a reviewer. I would expect | `thoughtpolice`. What's up with Phab usernames? Do other people I know | and love have Phab usernames distinct from Trac usernames? | > | > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What | does the # signify? | > | > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, but | I'm still unsure of what my local state and the git upstream state must | be beforehand for this to work. Will this ask me for a commit message? | Will it use the one I specified to Phab during `arc diff`? In general, | I'm confused about how much info `arc` pulls from various places to do | its work. I know I could learn by doing, but I'm afraid of mashing on the | Phab and/or git history as I do so. | > | > 8) Some of the same questions surround `arc patch`: What does my git | state need to be for this to work? | > | > 9) How do I contribute to others' revisions? Or, will this be obvious | what it comes to pass? | > | > I realize I've asked a lot here, and it might be too much to expect all | of these answers to be on the page. If that's the case, could you perhaps | link to relevant manuals or places to learn more? The way `arc` works, in | particular, seems like magic; magic is very powerful, but it can be | equally dangerous, and so I'd like to learn more. | > | > Thanks so much for doing all this! | > Richard | > | > On Jun 23, 2014, at 10:44 AM, Austin Seipp | wrote: | > | >> Hi all, | >> | >> I went ahead and took some time to write some stuff down about | >> Phabricator, including some basic tips on the workflows and | >> applications here: | >> | >> https://ghc.haskell.org/trac/ghc/wiki/Phabricator | >> | >> It's definitely going to need more expanding. Do let me know if | >> anything is confusing. | >> | >> On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek | wrote: | >>> Duh, ignore what I wrote. I just realized I'm working on a non- | rebased branch :-) | >>> | >>> Janek | >>> | >>> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: | >>>> I read the friendly Arcanist manual and I wonder if we intend to | have a | >>>> default .arcconfig file in the GHC repo? From the docs it seems like | a good | >>>> idea. | >>>> | >>>> Janek | >>>> | >>>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: | >>>>> On 13/06/14 10:47, Jan Stolarek wrote: | >>>>>> It seems that most people are in favour of using Phabricator for | code | >>>>>> review. So what are the next steps? Can we just start using the | >>>>>> existing phabricator instance? I'm working on some code right now | that | >>>>>> definitely needs reviewing. | >>>>> | >>>>> You can use it, and a few of us have already been doing so. There | isn't | >>>>> any Trac integration yet, but it works nicely for patch review. | >>>>> | >>>>> There's a short intro doc here: | >>>>> | https://secure.phabricator.com/book/phabricator/article/differential/, | >>>>> but it's not hard to figure out the basics, and you'll learn by | watching | >>>>> how other people use it. If you go to the Herald tool you have | yourself | >>>>> automatically subscribed to diffs that touch areas of the code that | >>>>> you're interested in. | >>>>> | >>>>> Pro tip: the keyboard shortcuts are really useful, especially "z". | Hit | >>>>> "?" to see all the shortcuts. | >>>>> | >>>>> Cheers, | >>>>> Simon | >>>>> | >>>>>> Janek | >>>>>> | >>>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: | >>>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: | >>>>>>>> So, why not put everything on GutHub and use pull requests and | so on? | >>>>>>> | >>>>>>> github just isn't great for doing code reviews. No side-by-side | diffs, | >>>>>>> and it sends you a separate email for every single comment, | there's no | >>>>>>> concept of a "review" consisting of multiple inline comments | (unless | >>>>>>> I've missed something). I'm afraid if we were using this for | regular | >>>>>>> reviews I would have to disable the email notifications, which | makes | >>>>>>> it significantly less useful. | >>>>>>> | >>>>>>>> SimonM writes that Phabricator is better than GitHub. I?m happy | to | >>>>>>>> believe that, but he also writes that using it requires | installing | >>>>>>>> local software and quite a bit of work. Moreover, I like to add | that | >>>>>>>> lots of people already know how to use GitHub and probably few | know | >>>>>>>> Phabricator. | >>>>>>>> | >>>>>>>> So, we are talking about having a somewhat better tool in return | for | >>>>>>>> three very significant disadvantages: (1) local installation, | (2) | >>>>>>>> work to set up and maintain Phabricator, and (3) effort by many | >>>>>>>> people to learn to use it. | >>>>>>> | >>>>>>> Well, you've tipped the balance with "somewhat" and "significant" | >>>>>>> here, I'd say Phabricator is "significantly" better than github | for | >>>>>>> code reviews, while installing arc is "somewhat" annoying :-) | >>>>>>> | >>>>>>> I have to admit it's not a no-brainer, but I do worry that github | just | >>>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I | spend my | >>>>>>> life inside Phabricator so I know it works really well. | >>>>>>> | >>>>>>> What's more, github doesn't let you put animated gifs in code | reviews. | >>>>>>> Need I say more? | >>>>>>> | >>>>>>> Cheers, | >>>>>>> Simon | >>>>>>> | >>>>>>>> We also have a constant lack of sufficient men power. So, why | spend | >>>>>>>> effort on building our own infrastructure, which will only | increase | >>>>>>>> the hurdle for contributors (as they have to deal with an | unknown | >>>>>>>> system)? Let?s outsource the effort to GitHub. | >>>>>>>> | >>>>>>>> Manuel | >>>>>>>> | >>>>>>>> Simon Peyton Jones : | >>>>>>>>> At the moment GHC's main sources aren't on github, which means | that | >>>>>>>>> that (in my highly imperfect understanding) people can't submit | pull | >>>>>>>>> requests or use their code review mechanisms. Moreover, most | people | >>>>>>>>> don't have commit rights on the main GHC server, so if someone | wants | >>>>>>>>> to offer a patch they can really only do so in textual form | attached | >>>>>>>>> to Trac. People with commit rights can make a branch, but | there's a | >>>>>>>>> danger that over a decade we'll accumulate zillions of dead | branches | >>>>>>>>> which people forgot to delete. I think on github the branch is | in a | >>>>>>>>> different repo, belonging to the patch author. | >>>>>>>>> | >>>>>>>>> So we really don't have a good work flow for creating, | reviewing, | >>>>>>>>> modifying, and finally apply patches. I am no expert on these | >>>>>>>>> matters. If Phabricator would help with that I'm all for it. | But | >>>>>>>>> perhaps there are other alternatives? Or is Phab the lead | thing. | >>>>>>>>> Will it stay around? | >>>>>>>>> | >>>>>>>>> Also before going too far I'd really like someone to document | the | >>>>>>>>> workflow carefully, and make sure it works from Windows equally | >>>>>>>>> well. | >>>>>>>>> | >>>>>>>>> I'm not too stressed out about losing the review trail of a | patch. | >>>>>>>>> Much of it will be commenting on stuff that no longer appears | in the | >>>>>>>>> final patch. Anything that's important should appear in a Note | in | >>>>>>>>> the source code; even the commit messages are invisible until | you | >>>>>>>>> really start digging. | >>>>>>>>> | >>>>>>>>> Simon | >>>>>>>>> | >>>>>>>>> | -----Original Message----- | >>>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On | Behalf Of | >>>>>>>>> | Austin Seipp | >>>>>>>>> | Sent: 06 June 2014 05:06 | >>>>>>>>> | To: ghc-devs at haskell.org | >>>>>>>>> | Subject: RFC: Phabricator for patches and code review | >>>>>>>>> | | >>>>>>>>> | Hello all, | >>>>>>>>> | | >>>>>>>>> | Recently, while doing server maintenance, several of the | >>>>>>>>> | administrators for Haskell.org set up an instance of | >>>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org | >>>>>>>>> | | >>>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a | suite of | >>>>>>>>> | tools for software development. Think of it like a polished, | >>>>>>>>> | semi-private GitHub with a lot of applications and tools for | all | >>>>>>>>> | kinds of needs. We've been using it to do issue tracking for | >>>>>>>>> | Haskell.org maintenance and like it a lot so far. | >>>>>>>>> | | >>>>>>>>> | One very nice aspect of Phabricator though is it has a very | nice | >>>>>>>>> | code review tool, called 'Differential', that is very useful. | For | >>>>>>>>> | people who have used a tool like Review Board, it's similar. | >>>>>>>>> | Furthermore, it has a very convenient userland tool called | >>>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a review | and | >>>>>>>>> | get it merged when it's ready all from the command line. | >>>>>>>>> | | >>>>>>>>> | I'd like to see if people are interested in using Phab | _strictly_ | >>>>>>>>> | for code review of GHC patches. It is a dedicated tool | >>>>>>>>> | specifically for this, and I think it works much better than | Trac | >>>>>>>>> | or inline GitHub comments. | >>>>>>>>> | | >>>>>>>>> | Also, Phab can also support post-commit reviews. So if I | touch | >>>>>>>>> | something in the runtime system and just push, perhaps Simon | or | >>>>>>>>> | Edward would like to look, and they can be alerted right when | I do | >>>>>>>>> | this, and then yell if I did something stupid. | >>>>>>>>> | | >>>>>>>>> | Before I go much further, I'd like to ask: is there *any* | interest | >>>>>>>>> | in this? Or are people satisifed with Trac? The primary | >>>>>>>>> | motivations are roughly, in no particular order: | >>>>>>>>> | | >>>>>>>>> | 1) Code review is good for everyone, a good way for people | to | >>>>>>>>> | learn the code and ask questions, and useful to give feedback | to | >>>>>>>>> | newcomers. And even experienced GHC hackers can learn things | from | >>>>>>>>> | reading code, as we all do regularly, or find things that | need | >>>>>>>>> | cleanup. | >>>>>>>>> | | >>>>>>>>> | 2) Phabricator in particular makes it very easy to submit | patches | >>>>>>>>> | for review. To submit a patch, I just run the command 'arc | diff' | >>>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure | >>>>>>>>> | people are *alerted* when a patch might be relevant to them. | >>>>>>>>> | | >>>>>>>>> | 3) They can be uploaded and created from the command line, | and | >>>>>>>>> | merged easily afterwords the same way. This is particularly | useful | >>>>>>>>> | for newcomers, and for me. :) | >>>>>>>>> | | >>>>>>>>> | 4) Differential is dedicated to code review, and much better | at | >>>>>>>>> | it than just reading patches on Trac IMO. | >>>>>>>>> | | >>>>>>>>> | 5) It supports both post-commit code review, as well as | >>>>>>>>> | pre-commit review. Post commit would be especially useful for | us | >>>>>>>>> | too, I think. | >>>>>>>>> | | >>>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly | >>>>>>>>> | handle incoming patches. But I think in general it would be | nice, | >>>>>>>>> | and make it a lot easier for newcomers to submit patches, and | us | >>>>>>>>> | to look over them. | >>>>>>>>> | | >>>>>>>>> | Here's an example of a Differential code review: | >>>>>>>>> | | >>>>>>>>> | https://phabricator.haskell.org/D4 | >>>>>>>>> | | >>>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need to | create | >>>>>>>>> | an account to login, but it shouldn't be much trouble, you | can | >>>>>>>>> | login several ways. I'll fix the login requirement soon. Feel | free | >>>>>>>>> | to read the code, comment on it, and play around. It's more | of a | >>>>>>>>> | demonstration, but real code review would be welcome too. :) | >>>>>>>>> | | >>>>>>>>> | If people are interested in doing this, I can add notes to | the | >>>>>>>>> | wiki pages for newcomers, and I'll send another email about | Phab | >>>>>>>>> | so people can understand it a little better. But I want to | ask | >>>>>>>>> | first. | >>>>>>>>> | | >>>>>>>>> | There is an argument that our team is so small, code review | has | >>>>>>>>> | unnecessary burdens. But I think Phab could help a lot with | >>>>>>>>> | tracking outside patches and getting good reviews for | incoming | >>>>>>>>> | patches, and it'll make it easier for newcomers. And | experienced | >>>>>>>>> | pros can probably learn a thing as well. | >>>>>>>>> | | >>>>>>>>> | Again, to be clear, I don't propose we migrate anything to | >>>>>>>>> | Phabricator from, say, Trac. There's no real pressure to do | so and | >>>>>>>>> | it would be tons of work. I only propose we use it for code | >>>>>>>>> | review, which is perfectly fine, and how other projects like | LLVM | >>>>>>>>> | do code review (they use Bugzilla). | >>>>>>>>> | | >>>>>>>>> | I also don't think the usage of Phabricator should be | mandatory | >>>>>>>>> | (unless we decide that later because we like it), but I would | like | >>>>>>>>> | to see people use it if possible. | >>>>>>>>> | | >>>>>>>>> | [1] http://phabricator.org | >>>>>>>>> | | >>>>>>>>> | -- | >>>>>>>>> | Regards, | >>>>>>>>> | | >>>>>>>>> | Austin Seipp, Haskell Consultant | >>>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ | >>>>>>>>> | _______________________________________________ | >>>>>>>>> | ghc-devs mailing list | >>>>>>>>> | ghc-devs at haskell.org | >>>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs | >>>>>>>>> | >>>>>>>>> _______________________________________________ | >>>>>>>>> ghc-devs mailing list | >>>>>>>>> ghc-devs at haskell.org | >>>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs | >>>>>>>> | >>>>>>>> _______________________________________________ | >>>>>>>> ghc-devs mailing list | >>>>>>>> ghc-devs at haskell.org | >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs | >>>>>>> | >>>>>>> _______________________________________________ | >>>>>>> ghc-devs mailing list | >>>>>>> ghc-devs at haskell.org | >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs | >>>>>> | >>>>>> _______________________________________________ | >>>>>> ghc-devs mailing list | >>>>>> ghc-devs at haskell.org | >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs | >>>> | >>>> _______________________________________________ | >>>> ghc-devs mailing list | >>>> ghc-devs at haskell.org | >>>> http://www.haskell.org/mailman/listinfo/ghc-devs | >>> | >>> | >> | >> | >> | >> -- | >> Regards, | >> | >> Austin Seipp, Haskell Consultant | >> Well-Typed LLP, http://www.well-typed.com/ | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | >> | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From jwlato at gmail.com Tue Jun 24 21:16:01 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 25 Jun 2014 05:16:01 +0800 Subject: GHC silently turns off dynamic output, should this be an error? In-Reply-To: <20140624203609.GA12853@matrix.chaos.earth.li> References: <20140624203609.GA12853@matrix.chaos.earth.li> Message-ID: On Jun 24, 2014 1:36 PM, "Ian Lynagh" wrote: > > On Mon, Jun 23, 2014 at 12:58:16PM -0500, Christopher Rodrigues wrote: > > > > Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with > > different interface hashes? > > You can, for example, compile package foo the vanilla way with -O, and > the dynamic way without -O. You'll then get mismatched hashes. Also, any file that uses Template Haskell could potentially generate different code at each compilation. But IMHO this isn't something ghc should try to support. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Jun 24 23:10:34 2014 From: conal at conal.net (Conal Elliott) Date: Tue, 24 Jun 2014 16:10:34 -0700 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EAC70@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103EAC70@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm glad for the interest and help. I can make an initial go of it. My current simple plan is to traverse expressions, collecting type equalities from bound coercion variables as I descend, combining them progressively with successive type unifications. The traversal is thus parametrized by a TvSubst and yields a Maybe TvSubst. The coercion variables will come from lambdas, let bindings and case alternatives. If an added equality is not unifiable given the current TvSubst, we've reached a contradiction. If the contradiction arises for one of the variables in a case alternative, then remove that alternative. How does this strategy sound? Some issues: * Nominal vs representational type equalities. * Will I want to normalize the types (with normaliseType) before unifying? * How can I unify while carrying along a type substitution environment? The Unify module exports tcUnifyTy, which takes no such environment, but not unify, which does. -- Conal On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones wrote: > we need to do a bit more work to re-connect to source pattern locations > and nested patterns? I can?t assess very well yet if this is a real problem > though > > > > That is a very good point. > > > > Nevertheless, given > > ? the typechecked HsSyn (i.e. still in source form, but with type > inference fully completed > > ? the independent contradiction-detector described below (which > is independent of whether the contradiction problems it is given come from > HsSyn or Core) > > it would be easy to give source-localised error messages > > > > Simon > > > > *From:* Dimitrios Vytiniotis > *Sent:* 24 June 2014 11:58 > *To:* Simon Peyton Jones; Conal Elliott; ghc-devs at haskell.org > *Cc:* Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias > > *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion > parameters > > > > > > Yes it would be better in the sense that we don?t really want to be > dealing with unification variables and evidence when we simply use the > constraint solver to detect inconsistencies in possibly missing patterns, > but the concern has been that if we are already desugared and in core maybe > we need to do a bit more work to re-connect to source pattern locations and > nested patterns? I can?t assess very well yet if this is a real problem > though ? > > > > In general I agree that a simple constraint solver for Core might be an > independently useful tool for this kind of optimization. (I think George > had thought about this too). > > > > Thanks! > > d- > > > > > > > > *From:* Simon Peyton Jones > *Sent:* Tuesday, June 24, 2014 11:41 AM > *To:* Conal Elliott; ghc-devs at haskell.org > *Cc:* Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); > George Karachalias; Simon Peyton Jones > *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion > parameters > > > > Conal > > > > This also relates to detecting redundant or overlapped patterns in source > programs. I know that Dimitrios is looking at this with Tom, Nikolas, > George who I?m cc?ing him. > > > > I think their current approach may be to integrate the overlap checking > with the constraint solver in the type checker. But that isn?t going to > work for optimising Core. > > > > An alternative approach would be to implement a specialised constraint > solver. It could be MUCH simpler than the one in the inference engine, > because (a) there are no unification variables to worry about, (b) there is > no need to gather evidence. More or less it?s task could be to answer the > question > > Is C |- D definitely a contradiction? > > where C are the ?given? constraints (from enclosing pattern matches) and D > are the ?wanted? constraints (from the current pattern match that may be > unreachable). > > > > I don?t think it would be hard to implement such a function. I?d be happy > to help advise if someone wants to take it on. > > > > Dimitrios: If we had such a function, then maybe it?d be better to use it > for the pattern-matching overlap detection too? > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org > ] *On Behalf Of *Conal Elliott > *Sent:* 20 June 2014 18:59 > *To:* ghc-devs at haskell.org > *Subject:* Pruning GADT case alternatives with uninhabitable coercion > parameters > > > > I'm looking for tips on pruning away impossible branches in `case` > expressions on GADTs, due to uninhabited coercion parameter types. > > Here's a simple example (rendered by HERMIT) from a type-specializion of > the Foldable instance a GADT for perfect leaf trees in which the tree depth > is part of the type: > > > case ds of wild (Sum Int) > > L (~# :: S (S Z) ~N Z) a1 -> f a1 > > B n1 (~# :: S (S Z) ~N S n1) uv -> ... > > Note the kind of the coercion parameter to the leaf constructor (`L`): `S > (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as > impossible. > > The reasoning gets subtler, however. > After inlining and simplifying in the second (`B`) alternative, the > following turns up: > > > case ds0 of wild0 (Sum Int) > > L (~# :: n1 ~N Z) a1 -> f0 a1 > > B n2 (~# :: n1 ~N S n2) uv0 -> ... > > Now I want to remove the first `L` alternative with `n1 ~ Z`, given that > the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` > alternative), so that `n1 ~ S Z`. With more inlining, more such equalities > pile up. Soon we get to an impossible `B` alternative, whose removal would > then eliminate the rest of the recursive unfolding. > > My questions: > > * Does this sort of transformation already live in GHC somewhere, and if > so, where? > * Are there gotchas / sources of unsoundness in the transformation I'm > suggesting? > * Is anyone else already working on this sort of transformation? > > -- Conal > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Jun 24 23:36:40 2014 From: conal at conal.net (Conal Elliott) Date: Tue, 24 Jun 2014 16:36:40 -0700 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103EAC70@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: My first go is at https://github.com/conal/hermit-extras/blob/master/src/HERMIT/Extras.hs#L1030 . It type-checks. I haven't tried running it yet. Comments most welcome! -- Conal On Tue, Jun 24, 2014 at 4:10 PM, Conal Elliott wrote: > I'm glad for the interest and help. I can make an initial go of it. My > current simple plan is to traverse expressions, collecting type equalities > from bound coercion variables as I descend, combining them progressively > with successive type unifications. The traversal is thus parametrized by a > TvSubst and yields a Maybe TvSubst. The coercion variables will come from > lambdas, let bindings and case alternatives. If an added equality is not > unifiable given the current TvSubst, we've reached a contradiction. If the > contradiction arises for one of the variables in a case alternative, then > remove that alternative. > > How does this strategy sound? > > Some issues: > > * Nominal vs representational type equalities. > * Will I want to normalize the types (with normaliseType) before > unifying? > * How can I unify while carrying along a type substitution environment? > The Unify module exports tcUnifyTy, which takes no such environment, but > not unify, which does. > > -- Conal > > > On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones > wrote: > >> we need to do a bit more work to re-connect to source pattern locations >> and nested patterns? I can?t assess very well yet if this is a real problem >> though >> >> >> >> That is a very good point. >> >> >> >> Nevertheless, given >> >> ? the typechecked HsSyn (i.e. still in source form, but with >> type inference fully completed >> >> ? the independent contradiction-detector described below (which >> is independent of whether the contradiction problems it is given come from >> HsSyn or Core) >> >> it would be easy to give source-localised error messages >> >> >> >> Simon >> >> >> >> *From:* Dimitrios Vytiniotis >> *Sent:* 24 June 2014 11:58 >> *To:* Simon Peyton Jones; Conal Elliott; ghc-devs at haskell.org >> *Cc:* Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias >> >> *Subject:* RE: Pruning GADT case alternatives with uninhabitable >> coercion parameters >> >> >> >> >> >> Yes it would be better in the sense that we don?t really want to be >> dealing with unification variables and evidence when we simply use the >> constraint solver to detect inconsistencies in possibly missing patterns, >> but the concern has been that if we are already desugared and in core maybe >> we need to do a bit more work to re-connect to source pattern locations and >> nested patterns? I can?t assess very well yet if this is a real problem >> though ? >> >> >> >> In general I agree that a simple constraint solver for Core might be an >> independently useful tool for this kind of optimization. (I think George >> had thought about this too). >> >> >> >> Thanks! >> >> d- >> >> >> >> >> >> >> >> *From:* Simon Peyton Jones >> *Sent:* Tuesday, June 24, 2014 11:41 AM >> *To:* Conal Elliott; ghc-devs at haskell.org >> *Cc:* Dimitrios Vytiniotis; Nikolaos S. Papaspyrou ( >> nickie at softlab.ntua.gr); George Karachalias; Simon Peyton Jones >> *Subject:* RE: Pruning GADT case alternatives with uninhabitable >> coercion parameters >> >> >> >> Conal >> >> >> >> This also relates to detecting redundant or overlapped patterns in source >> programs. I know that Dimitrios is looking at this with Tom, Nikolas, >> George who I?m cc?ing him. >> >> >> >> I think their current approach may be to integrate the overlap checking >> with the constraint solver in the type checker. But that isn?t going to >> work for optimising Core. >> >> >> >> An alternative approach would be to implement a specialised constraint >> solver. It could be MUCH simpler than the one in the inference engine, >> because (a) there are no unification variables to worry about, (b) there is >> no need to gather evidence. More or less it?s task could be to answer the >> question >> >> Is C |- D definitely a contradiction? >> >> where C are the ?given? constraints (from enclosing pattern matches) and >> D are the ?wanted? constraints (from the current pattern match that may be >> unreachable). >> >> >> >> I don?t think it would be hard to implement such a function. I?d be >> happy to help advise if someone wants to take it on. >> >> >> >> Dimitrios: If we had such a function, then maybe it?d be better to use it >> for the pattern-matching overlap detection too? >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org >> ] *On Behalf Of *Conal Elliott >> *Sent:* 20 June 2014 18:59 >> *To:* ghc-devs at haskell.org >> *Subject:* Pruning GADT case alternatives with uninhabitable coercion >> parameters >> >> >> >> I'm looking for tips on pruning away impossible branches in `case` >> expressions on GADTs, due to uninhabited coercion parameter types. >> >> Here's a simple example (rendered by HERMIT) from a type-specializion of >> the Foldable instance a GADT for perfect leaf trees in which the tree depth >> is part of the type: >> >> > case ds of wild (Sum Int) >> > L (~# :: S (S Z) ~N Z) a1 -> f a1 >> > B n1 (~# :: S (S Z) ~N S n1) uv -> ... >> >> Note the kind of the coercion parameter to the leaf constructor (`L`): `S >> (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as >> impossible. >> >> The reasoning gets subtler, however. >> After inlining and simplifying in the second (`B`) alternative, the >> following turns up: >> >> > case ds0 of wild0 (Sum Int) >> > L (~# :: n1 ~N Z) a1 -> f0 a1 >> > B n2 (~# :: n1 ~N S n2) uv0 -> ... >> >> Now I want to remove the first `L` alternative with `n1 ~ Z`, given that >> the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` >> alternative), so that `n1 ~ S Z`. With more inlining, more such equalities >> pile up. Soon we get to an impossible `B` alternative, whose removal would >> then eliminate the rest of the recursive unfolding. >> >> My questions: >> >> * Does this sort of transformation already live in GHC somewhere, and >> if so, where? >> * Are there gotchas / sources of unsoundness in the transformation I'm >> suggesting? >> * Is anyone else already working on this sort of transformation? >> >> -- Conal >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Wed Jun 25 05:26:28 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 25 Jun 2014 07:26:28 +0200 Subject: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85) In-Reply-To: <20140624174709.497982406D@ghc.haskell.org> References: <20140624174709.497982406D@ghc.haskell.org> Message-ID: <53AA5D84.1040409@fuuzetsu.co.uk> On 06/24/2014 07:47 PM, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc402aac3/ghc > >> --------------------------------------------------------------- > > commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > Author: Johan Tibell > Date: Mon Jun 9 11:43:21 2014 +0200 > > Add more primops for atomic ops on byte arrays > > Summary: > Add more primops for atomic ops on byte arrays > > Adds the following primops: > > * atomicReadIntArray# > * atomicWriteIntArray# > * fetchSubIntArray# > * fetchOrIntArray# > * fetchXorIntArray# > * fetchAndIntArray# > > Makes these pre-existing out-of-line primops inline: > > * fetchAddIntArray# > * casIntArray# > > >> --------------------------------------------------------------- > > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > compiler/cmm/CmmMachOp.hs | 19 ++ > compiler/cmm/CmmSink.hs | 4 + > compiler/cmm/PprC.hs | 4 + > compiler/codeGen/StgCmmPrim.hs | 94 +++++++ > compiler/llvmGen/Llvm/AbsSyn.hs | 7 + > compiler/llvmGen/Llvm/PpLlvm.hs | 18 +- > compiler/llvmGen/LlvmCodeGen/CodeGen.hs | 71 ++++-- > compiler/nativeGen/CPrim.hs | 50 +++- > compiler/nativeGen/PPC/CodeGen.hs | 4 + > compiler/nativeGen/SPARC/CodeGen.hs | 4 + > compiler/nativeGen/X86/CodeGen.hs | 92 +++++++ > compiler/nativeGen/X86/Instr.hs | 38 ++- > compiler/nativeGen/X86/Ppr.hs | 8 + > compiler/prelude/primops.txt.pp | 76 +++++- > includes/stg/MiscClosures.h | 1 - > libraries/ghc-prim/cbits/atomic.c | 280 +++++++++++++++++++++ > libraries/ghc-prim/ghc-prim.cabal | 1 + > rts/Linker.c | 1 - > rts/PrimOps.cmm | 12 - > testsuite/tests/concurrent/should_run/.gitignore | 1 + > .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++++++++++++++++++ > .../concurrent/should_run/AtomicPrimops.stdout | 7 + > testsuite/tests/concurrent/should_run/all.T | 1 + > 23 files changed, 984 insertions(+), 54 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/ -- Mateusz K. From johan.tibell at gmail.com Wed Jun 25 05:37:13 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 25 Jun 2014 07:37:13 +0200 Subject: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85) In-Reply-To: <53AA5D84.1040409@fuuzetsu.co.uk> References: <20140624174709.497982406D@ghc.haskell.org> <53AA5D84.1040409@fuuzetsu.co.uk> Message-ID: I don't understand the error (are we out of registers in the register allocator? what can we do about that?). Simon could you please explain. As for the continuos builds, can't we have them email the list upon breakages? On Wed, Jun 25, 2014 at 7:26 AM, Mateusz Kowalczyk wrote: > On 06/24/2014 07:47 PM, git at git.haskell.org wrote: > > Repository : ssh://git at git.haskell.org/ghc > > > > On branch : master > > Link : > http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc402aac3/ghc > > > >> --------------------------------------------------------------- > > > > commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > > Author: Johan Tibell > > Date: Mon Jun 9 11:43:21 2014 +0200 > > > > Add more primops for atomic ops on byte arrays > > > > Summary: > > Add more primops for atomic ops on byte arrays > > > > Adds the following primops: > > > > * atomicReadIntArray# > > * atomicWriteIntArray# > > * fetchSubIntArray# > > * fetchOrIntArray# > > * fetchXorIntArray# > > * fetchAndIntArray# > > > > Makes these pre-existing out-of-line primops inline: > > > > * fetchAddIntArray# > > * casIntArray# > > > > > >> --------------------------------------------------------------- > > > > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > > compiler/cmm/CmmMachOp.hs | 19 ++ > > compiler/cmm/CmmSink.hs | 4 + > > compiler/cmm/PprC.hs | 4 + > > compiler/codeGen/StgCmmPrim.hs | 94 +++++++ > > compiler/llvmGen/Llvm/AbsSyn.hs | 7 + > > compiler/llvmGen/Llvm/PpLlvm.hs | 18 +- > > compiler/llvmGen/LlvmCodeGen/CodeGen.hs | 71 ++++-- > > compiler/nativeGen/CPrim.hs | 50 +++- > > compiler/nativeGen/PPC/CodeGen.hs | 4 + > > compiler/nativeGen/SPARC/CodeGen.hs | 4 + > > compiler/nativeGen/X86/CodeGen.hs | 92 +++++++ > > compiler/nativeGen/X86/Instr.hs | 38 ++- > > compiler/nativeGen/X86/Ppr.hs | 8 + > > compiler/prelude/primops.txt.pp | 76 +++++- > > includes/stg/MiscClosures.h | 1 - > > libraries/ghc-prim/cbits/atomic.c | 280 > +++++++++++++++++++++ > > libraries/ghc-prim/ghc-prim.cabal | 1 + > > rts/Linker.c | 1 - > > rts/PrimOps.cmm | 12 - > > testsuite/tests/concurrent/should_run/.gitignore | 1 + > > .../tests/concurrent/should_run/AtomicPrimops.hs | 245 > ++++++++++++++++++ > > .../concurrent/should_run/AtomicPrimops.stdout | 7 + > > testsuite/tests/concurrent/should_run/all.T | 1 + > > 23 files changed, 984 insertions(+), 54 deletions(-) > > > > Diff suppressed because of size. To see it, use: > > > > git diff-tree --root --patch-with-stat --no-color > --find-copies-harder --ignore-space-at-eol --cc > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > > _______________________________________________ > > ghc-commits mailing list > > ghc-commits at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-commits > > > > I think the above killed compilation on 32-bit boxes. See the > usually-green boxes turn red at [1], specifically > validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The > error looks like: > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O > -package-name ghc-prim-0.3.1.0 -hide-all-packages -i > -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build > -ilibraries/ghc-prim/dist-install/build/autogen > -Ilibraries/ghc-prim/dist-install/build > -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. > -optP-include > -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h > -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 > -no-user-package-db -rtsopts -odir > libraries/ghc-prim/dist-install/build -hidir > libraries/ghc-prim/dist-install/build -stubdir > libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c > libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o > libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno > libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) > 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > make[1]: *** > [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > > It'd be great if the devs would look at [1] every day or so. > > [1]: http://haskell.inf.elte.hu/builders/ > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Wed Jun 25 05:54:19 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 25 Jun 2014 07:54:19 +0200 Subject: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85) In-Reply-To: References: <20140624174709.497982406D@ghc.haskell.org> <53AA5D84.1040409@fuuzetsu.co.uk> Message-ID: <53AA640B.4000309@fuuzetsu.co.uk> On 06/25/2014 07:37 AM, Johan Tibell wrote: > I don't understand the error (are we out of registers in the register > allocator? what can we do about that?). Simon could you please explain. > > As for the continuos builds, can't we have them email the list upon > breakages? > We could but I think there is no mechanism to tell what's meaningful breakage and how to present it. I think this should be part of the discussion in the ?Offering GHC builder build slaves? thread and someone just needs to sit down and hook it up. This includes fancier things such as blaming commit ranges for specific test changes &c. Short-term solution would be to subscribe to ghc-builds at haskell.org and filter out the contents so only failing builds are shown, taking care to exclude the slaves which are failing constantly due to unrelated reasons. -- Mateusz K. From hvr at gnu.org Wed Jun 25 06:59:47 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Jun 2014 08:59:47 +0200 Subject: validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18, Failure In-Reply-To: <53aa4544.25efc20a.274d.ffffcf97@mx.google.com> (Builder's message of "Wed, 25 Jun 2014 03:42:57 +0000") References: <53aa4544.25efc20a.274d.ffffcf97@mx.google.com> Message-ID: <87simtv5i4.fsf@gnu.org> Fyi, this also broke on the nightly PPA builds (which made me notice it): https://launchpadlibrarian.net/178475113/buildlog_ubuntu-precise-i386.ghc-head_7.9.20140624-1_FAILEDTOBUILD.txt.gz Cheers, hvr On 2014-06-25 at 05:42:57 +0200, Builder wrote: > validator1-linux-x86-head (Linux/x86 HEAD (Mateusz Kowalczyk)), build 18 > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > booting | Success > configuring | Success > compiling | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18.html [...] > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed > Makefile:64: recipe for target 'all' failed > make: *** [all] Error 2 From hvriedel at gmail.com Wed Jun 25 07:47:04 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 25 Jun 2014 09:47:04 +0200 Subject: HEADS-UP: Git submodule conversion imminent Message-ID: <87ionpv3bb.fsf@gmail.com> Hello GHC Devs! In order to not drag this out any longer, I'll completing the submodule conversion in the next few hours by converting the remaining sub-repo packages into proper submodules. This is represents phase 1 of the reorganization (phase 2 comprises officially transitioning the push-urls of *some* the packages to github.com/haskell as happened with haddock). However, this phase 1 is important to get done early (ideally half a year ago) in order to make 'ghc-complete' bit more redundant (I hope Joachim doesn't mind... :-) ) and allow to properly 'git bisect' as far back as possible into the past. While the workflow changes[1] to additionally have the sub-repo change also registed in ghc.git, practically, this should affect only a minority of you, as the remaining packages (see list at the bottom of this mail) to be converted into submodules are modified *very* seldom. This will be similiar to the conversion of haddock.git into a proper submodule of which you read up in * * * List of packages converted into proper submodules: * libffi-tarballs libffi-tarballs.git * utils/hsc2hs hsc2hs.git * libraries/array packages/array.git * libraries/deepseq packages/deepseq.git * libraries/directory packages/directory.git * libraries/filepath packages/filepath.git * libraries/haskell98 packages/haskell98.git * libraries/haskell2010 packages/haskell2010.git * libraries/hoopl packages/hoopl.git * libraries/hpc packages/hpc.git * libraries/old-locale packages/old-locale.git * libraries/old-time packages/old-time.git * libraries/process packages/process.git * libraries/unix packages/unix.git * nofib nofib.git * libraries/parallel packages/parallel.git * libraries/stm packages/stm.git * libraries/dph packages/dph.git Ideally, you won't have any outstanding changes in those repos (hint, hint!) to make the transition for your GHC clones easier. I'll follow up with more specific instructions as soon as I've pushed the changes. N.B.: ghc-tarballs will *not* become a submodule, as it would impose a non-neglible cost on everyone, not only the developers on windows and, moreover, the plan is to turn ghc-tarballs into a scripted download (or maybe something git-annex based) as Git is not really suited for such large blobs. See also discussion at [1]: For the new workflow in case you really happen to have to touch one of the affected modules, see the work-in-progress Wiki entry at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules From hvriedel at gmail.com Wed Jun 25 08:46:06 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 25 Jun 2014 10:46:06 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87ionpv3bb.fsf@gmail.com> (Herbert Valerio Riedel's message of "Wed, 25 Jun 2014 09:47:04 +0200") References: <87ionpv3bb.fsf@gmail.com> Message-ID: <87egydv0kx.fsf@gmail.com> It's done! After pulling the latest ghc.git commit (and assuming you have made sure you have no unpushed data laying around in the repos listed below) you'll have to either run - git submodule update --init *or* - ./sync-all get (a mere "./sync-all pull" will just call "git submodule update" w/o the "--init" option) After that, a 'git submodule status' (for ghc.git @ db19c665e) should look like a0088d1da0e171849ddb47a46c869856037a01d1 libffi-tarballs (ghc-7.8.1-release) 597ed8f613db327cfab958aa64da6c0f9e1ee291 libraries/Cabal (Cabal-1.20.0.0-release-1-g597ed8f) c51e81a43cd5e9540453bd5ca6da8992245a4774 libraries/Win32 (Win32-2.3.0.2-release) 26ff04744117b0ad8233a1a2b5635fa1277b88d9 libraries/array (array-0.5.0.0-release) 2647d42f19bedae46c020fc3af029073f5690d5b libraries/binary (binary-0.7.1.0-release-2-g2647d42) 6ad8c0d27bcff28c80684a29b57d7a8dbf00caca libraries/bytestring (bytestring-0.10.4.0-release) e84c5d2145415cb0beacce0909a551ae5e28d396 libraries/containers (containers-0.5.5.1-release-11-ge84c5d2) 3a9c431e4c89ca506aae8e80867cfcde8c099724 libraries/deepseq (deepseq-1.3.0.2-release-1-g3a9c431) 0c64d5420e54bb871f0407a4ec3155c6be600756 libraries/directory (directory-1.2.1.0-release) 3ebad521cd1e3b5573d97b483305ca465a9cba69 libraries/dph (2009-06-25-1145-g3ebad52) 486373cb6bc3de8bf7f0b8532558c5fff32df20a libraries/filepath (filepath-1.3.0.2-release) 5579fc2a2949a143ec8946b9bc9dd2ba957bf091 libraries/haskeline (0.7.1.2-2-g5579fc2) c0c87ad53e377aa00f4897bc729c261459b6048a libraries/haskell2010 (haskell2010-1.1.2.0-release-1-gc0c87ad) cc6bbbf2bf4eaea57062043cbb6e7c5d6c2f42a9 libraries/haskell98 (haskell98-2.0.0.3-release-1-gcc6bbbf) a2e34db038b737365c4126f69b1a32eae84dae6b libraries/hoopl (hoopl-3.10.0.1-release-1-ga2e34db) d6ac0c532f12d30af778eeb285da9031bb06fddb libraries/hpc (hpc-0.6.0.1-release-1-gd6ac0c5) 7e7f6722895af36ca4e2f60f2fdfdc056b70db0b libraries/old-locale (old-locale-1.0.0.6-release) 89017411036b24875393e4fd6ca8ef92fc181ad2 libraries/old-time (old-time-1.1.0.2-release) 03da43303ed05ace65cb24cee1dbc1766c694233 libraries/parallel (parallel-3.2.0.4-release) 110b105c491387a73dd37b4f86a686ed131767b2 libraries/pretty (pretty-1.1.1.1-release) be63ee15d961dc1b08bc8853b9ff97708551ef36 libraries/primitive (primitive-0.5.2.1-release) b39e340bb1fa887842e99db9824906858515cdf7 libraries/process (process-1.2.0.0-release-3-gb39e340) 180aa65507d5b7c63d9f438ff908774bafc88d0d libraries/random (random-1.0.1.1-release-4-g180aa65) 52c3028aff127fd957cdaf1ec7605fc533a59961 libraries/stm (stm-2.4.3-release-1-g52c3028) 1ce8379744179e5c7f8d88049aaed4d3be52e323 libraries/terminfo (0.4.0.0) adafac26307cffab0be20c126385ab161c259237 libraries/time (time-1.4.2-release) 5df683cd87cb0ed13f915f73b83a7673e18aa294 libraries/transformers (0_4_0_0) cdc3ae7b087ac7451298a5b87fe2548fb74c2fdc libraries/unix (unix-2.7.0.1-release-6-gcdc3ae7) a6049abce040713e9a5f175887cf70d12b9057c6 libraries/vector (vector-0.10.9.1-release-1-ga6049ab) fb9e0bbb69e15873682a9f25d39652099a3ccac1 libraries/xhtml (3000.2.1) d98f7038d1111e515db9cc27d5d3bbe237e6e14f nofib (2009-06-25-218-gd98f703) 5412c262f403e52be45d607b34eb3a5806ea2a76 utils/haddock (haddock-2.15-start-57-g5412c26) 4a0f67704d89712f8493a0c7eccffa9243d6ef09 utils/hsc2hs (2009-06-25-78-g4a0f677) N.B.: The very first character in each line is a single whitespace. If there's a '-' or '+' your submodule are not in the commit state recorded in ghc.git (a '-' specifically means the submodule is not initialized properly) For further information, please read the current documentation at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules and let me know what all needs to improved. On 2014-06-25 at 09:47:04 +0200, Herbert Valerio Riedel wrote: [...] > This will be similiar to the conversion of haddock.git into a proper > submodule of which you read up in > > * > * > * > > List of packages converted into proper submodules: > > * libffi-tarballs libffi-tarballs.git > * utils/hsc2hs hsc2hs.git > * libraries/array packages/array.git > * libraries/deepseq packages/deepseq.git > * libraries/directory packages/directory.git > * libraries/filepath packages/filepath.git > * libraries/haskell98 packages/haskell98.git > * libraries/haskell2010 packages/haskell2010.git > * libraries/hoopl packages/hoopl.git > * libraries/hpc packages/hpc.git > * libraries/old-locale packages/old-locale.git > * libraries/old-time packages/old-time.git > * libraries/process packages/process.git > * libraries/unix packages/unix.git > * nofib nofib.git > * libraries/parallel packages/parallel.git > * libraries/stm packages/stm.git > * libraries/dph packages/dph.git > > > Ideally, you won't have any outstanding changes in those repos (hint, > hint!) to make the transition for your GHC clones easier. I'll follow up > with more specific instructions as soon as I've pushed the changes. [...] From marlowsd at gmail.com Wed Jun 25 10:54:40 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 25 Jun 2014 11:54:40 +0100 Subject: Phabricator for patches and code review In-Reply-To: References: <53A03118.5000006@gmail.com> <201406180936.27364.jan.stolarek@p.lodz.pl> <201406180938.04852.jan.stolarek@p.lodz.pl> Message-ID: <53AAAA70.4020106@gmail.com> If you have several commits, then use separate 'arc diff' commands to send them to Phab. You can do this even if they depend on each other ("stacked diffs"). My usual workflow is something like this: git checkout -b hacking master .. hack hack .. git commit arc diff HEAD^ .. hack hack .. git commit arc diff HEAD^ Now you have a branch with two separate commits, and two Phab diffs. For landing, you can wait until they're all accepted and then do a single 'git push', or you can push them individually by cherry-picking onto master, pushing, and then rebasing the original branch. The squashing behavior of Phab is intended to squash the *revisions* of a diff into a single commit. Personally I don't use it this way, I just amend the original commit, because it's easier to do stacked diffs this way. Cheers, Simon On 24/06/2014 15:27, Johan Tibell wrote: > I find the automatic squashing to rather harmful to the commit history. > So if you have several nice commits that you want to send for review, > don't use arc land to commit them, as it will ruin the history. Instead > git push them as per normal and use `arc close` (IIRC) to close the code > review. I also find it useful to remove lots of the arc gunk that was > added to the commit message, to not pollute our revision history with > data from some specific tool. > > > On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg > wrote: > > Thanks so much for writing this! I have some questions: > > 1) I'm just setting things up on my machine. It says to `arc > install-certificate` in my GHC directory. Is it important precisely > which clone of GHC my directory is set up against? For example, my > "pull" origin is git://git.haskell.org/ghc.git > and my "push" origin is > ssh://git at git.haskell.org/ghc.git > . Is this the right set-up? If > this bit matters, could you add it to the page? Or, if not, could > you comment on what `arc` is pulling from the ghc directory? > > 2) I'm confused about what, precisely, `arc diff` does. You describe > that it updates the review available online. Does that reference > some git commits? Do I need to push by `wip` branch before `arc > diff`ing? Do I *never* need to push my branch, because `arc diff` > pushes it for me? Do I *never* need to push my branch, because Phab > uses other ways of moving the code around? For better or worse, I > tend to keep my branches local until I'm ready to merge with master, > and I want to know if this needs to change. > > 3) You say "A change cannot be merged until at least one reviewer > has signed off." Does this mean "merged with ghc-7.8" (or whatever > the current stable branch is)? Or does it mean "merged with master"? > The former is the status quo, but with a new route, so to speak. The > latter is something new, as several of us push directly to `master` > without a review. I'm not against such a change, per se, just trying > to understand it. > > 4) Is it now compulsory to use Phab when contributing? This page > makes it sound that way. Again, no complaints -- just trying to > understand it. > > 5) The page says to add `austin` as a reviewer. I would expect > `thoughtpolice`. What's up with Phab usernames? Do other people I > know and love have Phab usernames distinct from Trac usernames? > > 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? > What does the # signify? > > 7) I'm baffled by "Landing reviews". The `arc land` bit is clearer, > but I'm still unsure of what my local state and the git upstream > state must be beforehand for this to work. Will this ask me for a > commit message? Will it use the one I specified to Phab during `arc > diff`? In general, I'm confused about how much info `arc` pulls from > various places to do its work. I know I could learn by doing, but > I'm afraid of mashing on the Phab and/or git history as I do so. > > 8) Some of the same questions surround `arc patch`: What does my git > state need to be for this to work? > > 9) How do I contribute to others' revisions? Or, will this be > obvious what it comes to pass? > > I realize I've asked a lot here, and it might be too much to expect > all of these answers to be on the page. If that's the case, could > you perhaps link to relevant manuals or places to learn more? The > way `arc` works, in particular, seems like magic; magic is very > powerful, but it can be equally dangerous, and so I'd like to learn > more. > > Thanks so much for doing all this! > Richard > > On Jun 23, 2014, at 10:44 AM, Austin Seipp > wrote: > > > Hi all, > > > > I went ahead and took some time to write some stuff down about > > Phabricator, including some basic tips on the workflows and > > applications here: > > > > https://ghc.haskell.org/trac/ghc/wiki/Phabricator > > > > It's definitely going to need more expanding. Do let me know if > > anything is confusing. > > > > On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek > > wrote: > >> Duh, ignore what I wrote. I just realized I'm working on a > non-rebased branch :-) > >> > >> Janek > >> > >> Dnia ?roda, 18 czerwca 2014, Jan Stolarek napisa?: > >>> I read the friendly Arcanist manual and I wonder if we intend > to have a > >>> default .arcconfig file in the GHC repo? From the docs it seems > like a good > >>> idea. > >>> > >>> Janek > >>> > >>> Dnia wtorek, 17 czerwca 2014, Simon Marlow napisa?: > >>>> On 13/06/14 10:47, Jan Stolarek wrote: > >>>>> It seems that most people are in favour of using Phabricator > for code > >>>>> review. So what are the next steps? Can we just start using the > >>>>> existing phabricator instance? I'm working on some code right > now that > >>>>> definitely needs reviewing. > >>>> > >>>> You can use it, and a few of us have already been doing so. > There isn't > >>>> any Trac integration yet, but it works nicely for patch review. > >>>> > >>>> There's a short intro doc here: > >>>> > https://secure.phabricator.com/book/phabricator/article/differential/, > >>>> but it's not hard to figure out the basics, and you'll learn > by watching > >>>> how other people use it. If you go to the Herald tool you > have yourself > >>>> automatically subscribed to diffs that touch areas of the code > that > >>>> you're interested in. > >>>> > >>>> Pro tip: the keyboard shortcuts are really useful, especially > "z". Hit > >>>> "?" to see all the shortcuts. > >>>> > >>>> Cheers, > >>>> Simon > >>>> > >>>>> Janek > >>>>> > >>>>> Dnia niedziela, 8 czerwca 2014, Simon Marlow napisa?: > >>>>>> On 07/06/2014 07:21, Manuel M T Chakravarty wrote: > >>>>>>> So, why not put everything on GutHub and use pull requests > and so on? > >>>>>> > >>>>>> github just isn't great for doing code reviews. No > side-by-side diffs, > >>>>>> and it sends you a separate email for every single comment, > there's no > >>>>>> concept of a "review" consisting of multiple inline comments > (unless > >>>>>> I've missed something). I'm afraid if we were using this for > regular > >>>>>> reviews I would have to disable the email notifications, > which makes > >>>>>> it significantly less useful. > >>>>>> > >>>>>>> SimonM writes that Phabricator is better than GitHub. I?m > happy to > >>>>>>> believe that, but he also writes that using it requires > installing > >>>>>>> local software and quite a bit of work. Moreover, I like to > add that > >>>>>>> lots of people already know how to use GitHub and probably > few know > >>>>>>> Phabricator. > >>>>>>> > >>>>>>> So, we are talking about having a somewhat better tool in > return for > >>>>>>> three very significant disadvantages: (1) local > installation, (2) > >>>>>>> work to set up and maintain Phabricator, and (3) effort by many > >>>>>>> people to learn to use it. > >>>>>> > >>>>>> Well, you've tipped the balance with "somewhat" and > "significant" > >>>>>> here, I'd say Phabricator is "significantly" better than > github for > >>>>>> code reviews, while installing arc is "somewhat" annoying :-) > >>>>>> > >>>>>> I have to admit it's not a no-brainer, but I do worry that > github just > >>>>>> wouldn't cut it for doing a lot of code reviewing, whereas I > spend my > >>>>>> life inside Phabricator so I know it works really well. > >>>>>> > >>>>>> What's more, github doesn't let you put animated gifs in > code reviews. > >>>>>> Need I say more? > >>>>>> > >>>>>> Cheers, > >>>>>> Simon > >>>>>> > >>>>>>> We also have a constant lack of sufficient men power. So, > why spend > >>>>>>> effort on building our own infrastructure, which will only > increase > >>>>>>> the hurdle for contributors (as they have to deal with an > unknown > >>>>>>> system)? Let?s outsource the effort to GitHub. > >>>>>>> > >>>>>>> Manuel > >>>>>>> > >>>>>>> Simon Peyton Jones >: > >>>>>>>> At the moment GHC's main sources aren't on github, which > means that > >>>>>>>> that (in my highly imperfect understanding) people can't > submit pull > >>>>>>>> requests or use their code review mechanisms. Moreover, > most people > >>>>>>>> don't have commit rights on the main GHC server, so if > someone wants > >>>>>>>> to offer a patch they can really only do so in textual > form attached > >>>>>>>> to Trac. People with commit rights can make a branch, but > there's a > >>>>>>>> danger that over a decade we'll accumulate zillions of > dead branches > >>>>>>>> which people forgot to delete. I think on github the > branch is in a > >>>>>>>> different repo, belonging to the patch author. > >>>>>>>> > >>>>>>>> So we really don't have a good work flow for creating, > reviewing, > >>>>>>>> modifying, and finally apply patches. I am no expert on these > >>>>>>>> matters. If Phabricator would help with that I'm all for > it. But > >>>>>>>> perhaps there are other alternatives? Or is Phab the lead > thing. > >>>>>>>> Will it stay around? > >>>>>>>> > >>>>>>>> Also before going too far I'd really like someone to > document the > >>>>>>>> workflow carefully, and make sure it works from Windows > equally > >>>>>>>> well. > >>>>>>>> > >>>>>>>> I'm not too stressed out about losing the review trail of > a patch. > >>>>>>>> Much of it will be commenting on stuff that no longer > appears in the > >>>>>>>> final patch. Anything that's important should appear in a > Note in > >>>>>>>> the source code; even the commit messages are invisible > until you > >>>>>>>> really start digging. > >>>>>>>> > >>>>>>>> Simon > >>>>>>>> > >>>>>>>> | -----Original Message----- > >>>>>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org > ] On Behalf Of > >>>>>>>> | Austin Seipp > >>>>>>>> | Sent: 06 June 2014 05:06 > >>>>>>>> | To: ghc-devs at haskell.org > >>>>>>>> | Subject: RFC: Phabricator for patches and code review > >>>>>>>> | > >>>>>>>> | Hello all, > >>>>>>>> | > >>>>>>>> | Recently, while doing server maintenance, several of the > >>>>>>>> | administrators for Haskell.org set up an instance of > >>>>>>>> | Phabricator[1], located at https://phabricator.haskell.org > >>>>>>>> | > >>>>>>>> | For those who aren't aware, Phabricator (or "Phab") is a > suite of > >>>>>>>> | tools for software development. Think of it like a polished, > >>>>>>>> | semi-private GitHub with a lot of applications and tools > for all > >>>>>>>> | kinds of needs. We've been using it to do issue tracking for > >>>>>>>> | Haskell.org maintenance and like it a lot so far. > >>>>>>>> | > >>>>>>>> | One very nice aspect of Phabricator though is it has a > very nice > >>>>>>>> | code review tool, called 'Differential', that is very > useful. For > >>>>>>>> | people who have used a tool like Review Board, it's similar. > >>>>>>>> | Furthermore, it has a very convenient userland tool called > >>>>>>>> | 'Arcanist' which makes it easy for newcomers to post a > review and > >>>>>>>> | get it merged when it's ready all from the command line. > >>>>>>>> | > >>>>>>>> | I'd like to see if people are interested in using Phab > _strictly_ > >>>>>>>> | for code review of GHC patches. It is a dedicated tool > >>>>>>>> | specifically for this, and I think it works much better > than Trac > >>>>>>>> | or inline GitHub comments. > >>>>>>>> | > >>>>>>>> | Also, Phab can also support post-commit reviews. So if I > touch > >>>>>>>> | something in the runtime system and just push, perhaps > Simon or > >>>>>>>> | Edward would like to look, and they can be alerted right > when I do > >>>>>>>> | this, and then yell if I did something stupid. > >>>>>>>> | > >>>>>>>> | Before I go much further, I'd like to ask: is there > *any* interest > >>>>>>>> | in this? Or are people satisifed with Trac? The primary > >>>>>>>> | motivations are roughly, in no particular order: > >>>>>>>> | > >>>>>>>> | 1) Code review is good for everyone, a good way for > people to > >>>>>>>> | learn the code and ask questions, and useful to give > feedback to > >>>>>>>> | newcomers. And even experienced GHC hackers can learn > things from > >>>>>>>> | reading code, as we all do regularly, or find things > that need > >>>>>>>> | cleanup. > >>>>>>>> | > >>>>>>>> | 2) Phabricator in particular makes it very easy to > submit patches > >>>>>>>> | for review. To submit a patch, I just run the command > 'arc diff' > >>>>>>>> | and it Does The Right Thing. It also makes it easy to ensure > >>>>>>>> | people are *alerted* when a patch might be relevant to them. > >>>>>>>> | > >>>>>>>> | 3) They can be uploaded and created from the command > line, and > >>>>>>>> | merged easily afterwords the same way. This is > particularly useful > >>>>>>>> | for newcomers, and for me. :) > >>>>>>>> | > >>>>>>>> | 4) Differential is dedicated to code review, and much > better at > >>>>>>>> | it than just reading patches on Trac IMO. > >>>>>>>> | > >>>>>>>> | 5) It supports both post-commit code review, as well as > >>>>>>>> | pre-commit review. Post commit would be especially > useful for us > >>>>>>>> | too, I think. > >>>>>>>> | > >>>>>>>> | Point #2 and #3 are mostly relevant for me, because I mostly > >>>>>>>> | handle incoming patches. But I think in general it would > be nice, > >>>>>>>> | and make it a lot easier for newcomers to submit > patches, and us > >>>>>>>> | to look over them. > >>>>>>>> | > >>>>>>>> | Here's an example of a Differential code review: > >>>>>>>> | > >>>>>>>> | https://phabricator.haskell.org/D4 > >>>>>>>> | > >>>>>>>> | This is a demo using my 'wip/ermsb' patch. You'll need > to create > >>>>>>>> | an account to login, but it shouldn't be much trouble, > you can > >>>>>>>> | login several ways. I'll fix the login requirement soon. > Feel free > >>>>>>>> | to read the code, comment on it, and play around. It's > more of a > >>>>>>>> | demonstration, but real code review would be welcome too. :) > >>>>>>>> | > >>>>>>>> | If people are interested in doing this, I can add notes > to the > >>>>>>>> | wiki pages for newcomers, and I'll send another email > about Phab > >>>>>>>> | so people can understand it a little better. But I want > to ask > >>>>>>>> | first. > >>>>>>>> | > >>>>>>>> | There is an argument that our team is so small, code > review has > >>>>>>>> | unnecessary burdens. But I think Phab could help a lot with > >>>>>>>> | tracking outside patches and getting good reviews for > incoming > >>>>>>>> | patches, and it'll make it easier for newcomers. And > experienced > >>>>>>>> | pros can probably learn a thing as well. > >>>>>>>> | > >>>>>>>> | Again, to be clear, I don't propose we migrate anything to > >>>>>>>> | Phabricator from, say, Trac. There's no real pressure to > do so and > >>>>>>>> | it would be tons of work. I only propose we use it for code > >>>>>>>> | review, which is perfectly fine, and how other projects > like LLVM > >>>>>>>> | do code review (they use Bugzilla). > >>>>>>>> | > >>>>>>>> | I also don't think the usage of Phabricator should be > mandatory > >>>>>>>> | (unless we decide that later because we like it), but I > would like > >>>>>>>> | to see people use it if possible. > >>>>>>>> | > >>>>>>>> | [1] http://phabricator.org > >>>>>>>> | > >>>>>>>> | -- > >>>>>>>> | Regards, > >>>>>>>> | > >>>>>>>> | Austin Seipp, Haskell Consultant > >>>>>>>> | Well-Typed LLP, http://www.well-typed.com/ > >>>>>>>> | _______________________________________________ > >>>>>>>> | ghc-devs mailing list > >>>>>>>> | ghc-devs at haskell.org > >>>>>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> ghc-devs mailing list > >>>>>>>> ghc-devs at haskell.org > >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> ghc-devs mailing list > >>>>>>> ghc-devs at haskell.org > >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>>> > >>>>>> _______________________________________________ > >>>>>> ghc-devs mailing list > >>>>>> ghc-devs at haskell.org > >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>>>> > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> > > > > > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From gergo at erdi.hu Wed Jun 25 12:30:50 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Wed, 25 Jun 2014 20:30:50 +0800 (SGT) Subject: Help needed: parsing pattern synonym contexts In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Tue, 24 Jun 2014, Simon Peyton Jones wrote: > What do you mean by "doesn't work"? Crashes? Fails to build with some > error? Builds but doesn't parse what you expect? Yeah, sorry, when I wrote >> fails with a parse error on "::". what I meant was that the parser builds & runs, but fails with a parse error on the double-colon. I'll get back to you on the other points when I've had time to try them. From gergo at erdi.hu Wed Jun 25 13:20:08 2014 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Wed, 25 Jun 2014 21:20:08 +0800 (SGT) Subject: Help needed: parsing pattern synonym contexts In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Tue, 24 Jun 2014, Simon Peyton Jones wrote: > In the latter case, what happened to the shift/reduce and reduce/reduce > errors reported by Happy? Esp the latter. If you are getting more you > need to track them down. I think I've figured out what might be causing the problem. First, a couple figures. With these rules: pattern_synonym_decl : 'pattern' con vars0 patsyn_token pat | 'pattern' varid conop varid patsyn_token pat pattern_synonym_sig : 'pattern' patsyn_stuff '::' ctype patsyn_stuff : constr_stuff I'm getting 112 new reduce/reduce conflicts. If I add the context like you recommended: pattern_synonym_sig : 'pattern' patsyn_context patsyn_stuff '::' ctype patsyn_context :: { LHsContext RdrName } : forall | forall context '=>' then I get 54 new shift/reduce conflicts and no (new) reduce/reduce conflicts. My feeling is the problem is that patterns don't need any special parentheses around type annotations, which means the following is a legal pattern synonym definition: pattern Single x = [x] :: [Int] and I think that the difference (the '=' or '<-') is too 'deep' between this and something like pattern Single a :: [a] Unfortunately, I still have no idea how to solve this problem... From omeragacan at gmail.com Wed Jun 25 14:28:07 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 25 Jun 2014 17:28:07 +0300 Subject: Interesting whoCreated output (stack trace related) Message-ID: Hi all, I'm running this program: {-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} import GHC.Stack import Control.Exception.Base import Data.Typeable data MyException = MyException deriving (Show, Typeable) instance Exception MyException err1 :: IO Integer err1 = {-# SCC error1 #-} err2 >>= return err2 :: IO Integer err2 = {-# SCC error2 #-} throw MyException main = print =<< whoCreated =<< catch err1 =<< (\(_ :: MyException) -> return (42 :: Integer)) I'd expect `whoCreated` to return something like [Main.CAF, Main.main, Main.main.\] but instead this is the output: ["Main.CAF ()","Main.err2 (ioerr.hs:14:1-43)","Main.error2 (ioerr.hs:14:27-43)","Main.main (ioerr.hs:16:1-103)","Main.main.\\ (ioerr.hs:16:81-102)"] This output has two things that look somewhat weird to me. First, I'd expect cost-centre stack to be restored when exception is catched and then program would produce shorter stack trace like I mentioned above.(without err1 or err2 calls) Second, when no cost-centre restoring is done, I'd expect stack trace to include `Main.err1` and `Main.error1`. So can anyone explain my why stack trace contains err2 calls but not err1 calls? I think none of error1 and error2 should have been included in the stack trace or both of them should have been included. Thanks. --- ?mer Sinan A?acan http://osa1.net From marlowsd at gmail.com Wed Jun 25 14:49:55 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 25 Jun 2014 15:49:55 +0100 Subject: Interesting whoCreated output (stack trace related) In-Reply-To: References: Message-ID: <53AAE193.7050601@gmail.com> On 25/06/2014 15:28, ?mer Sinan A?acan wrote: > I'm running this program: > > {-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} > import GHC.Stack > import Control.Exception.Base > import Data.Typeable > > data MyException = MyException deriving (Show, Typeable) > > instance Exception MyException > > err1 :: IO Integer > err1 = {-# SCC error1 #-} err2 >>= return > > err2 :: IO Integer > err2 = {-# SCC error2 #-} throw MyException > > main = print =<< whoCreated =<< catch err1 =<< (\(_ :: MyException) > -> return (42 :: Integer)) > > I'd expect `whoCreated` to return something like [Main.CAF, Main.main, > Main.main.\] but instead this is the output: > > ["Main.CAF ()","Main.err2 > (ioerr.hs:14:1-43)","Main.error2 (ioerr.hs:14:27-43)","Main.main > (ioerr.hs:16:1-103)","Main.main.\\ (ioerr.hs:16:81-102)"] > > This output has two things that look somewhat weird to me. First, I'd > expect cost-centre stack to be restored when exception is catched and > then program would produce shorter stack trace like I mentioned > above.(without err1 or err2 calls) > > Second, when no cost-centre restoring is done, I'd expect stack trace > to include `Main.err1` and `Main.error1`. > > So can anyone explain my why stack trace contains err2 calls but not > err1 calls? I think none of error1 and error2 should have been > included in the stack trace or both of them should have been included. I have no idea, but I just want to point out that whoCreated is inherently fragile. If its argument is a thunk (as it might well be) then you'll see the CCS of the thunk, and not the CCS of the value. Optimisation flags can easily change the output you get here. To get more predictable output you could try forcing the value before passing it to whoCreated. Cheers, Simon From mainland at apeiron.net Wed Jun 25 17:26:15 2014 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 25 Jun 2014 13:26:15 -0400 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87egydv0kx.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> Message-ID: <53AB0637.1070305@apeiron.net> Thank you!!!! Geoff On 6/25/14, 4:46 AM, Herbert Valerio Riedel wrote: > It's done! > > After pulling the latest ghc.git commit (and assuming you have made sure > you have no unpushed data laying around in the repos listed below) > you'll have to either run > > - git submodule update --init > > *or* > > - ./sync-all get > > (a mere "./sync-all pull" will just call "git submodule update" w/o > the "--init" option) > > > After that, a 'git submodule status' (for ghc.git @ db19c665e) should look like > > a0088d1da0e171849ddb47a46c869856037a01d1 libffi-tarballs (ghc-7.8.1-release) > 597ed8f613db327cfab958aa64da6c0f9e1ee291 libraries/Cabal (Cabal-1.20.0.0-release-1-g597ed8f) > c51e81a43cd5e9540453bd5ca6da8992245a4774 libraries/Win32 (Win32-2.3.0.2-release) > 26ff04744117b0ad8233a1a2b5635fa1277b88d9 libraries/array (array-0.5.0.0-release) > 2647d42f19bedae46c020fc3af029073f5690d5b libraries/binary (binary-0.7.1.0-release-2-g2647d42) > 6ad8c0d27bcff28c80684a29b57d7a8dbf00caca libraries/bytestring (bytestring-0.10.4.0-release) > e84c5d2145415cb0beacce0909a551ae5e28d396 libraries/containers (containers-0.5.5.1-release-11-ge84c5d2) > 3a9c431e4c89ca506aae8e80867cfcde8c099724 libraries/deepseq (deepseq-1.3.0.2-release-1-g3a9c431) > 0c64d5420e54bb871f0407a4ec3155c6be600756 libraries/directory (directory-1.2.1.0-release) > 3ebad521cd1e3b5573d97b483305ca465a9cba69 libraries/dph (2009-06-25-1145-g3ebad52) > 486373cb6bc3de8bf7f0b8532558c5fff32df20a libraries/filepath (filepath-1.3.0.2-release) > 5579fc2a2949a143ec8946b9bc9dd2ba957bf091 libraries/haskeline (0.7.1.2-2-g5579fc2) > c0c87ad53e377aa00f4897bc729c261459b6048a libraries/haskell2010 (haskell2010-1.1.2.0-release-1-gc0c87ad) > cc6bbbf2bf4eaea57062043cbb6e7c5d6c2f42a9 libraries/haskell98 (haskell98-2.0.0.3-release-1-gcc6bbbf) > a2e34db038b737365c4126f69b1a32eae84dae6b libraries/hoopl (hoopl-3.10.0.1-release-1-ga2e34db) > d6ac0c532f12d30af778eeb285da9031bb06fddb libraries/hpc (hpc-0.6.0.1-release-1-gd6ac0c5) > 7e7f6722895af36ca4e2f60f2fdfdc056b70db0b libraries/old-locale (old-locale-1.0.0.6-release) > 89017411036b24875393e4fd6ca8ef92fc181ad2 libraries/old-time (old-time-1.1.0.2-release) > 03da43303ed05ace65cb24cee1dbc1766c694233 libraries/parallel (parallel-3.2.0.4-release) > 110b105c491387a73dd37b4f86a686ed131767b2 libraries/pretty (pretty-1.1.1.1-release) > be63ee15d961dc1b08bc8853b9ff97708551ef36 libraries/primitive (primitive-0.5.2.1-release) > b39e340bb1fa887842e99db9824906858515cdf7 libraries/process (process-1.2.0.0-release-3-gb39e340) > 180aa65507d5b7c63d9f438ff908774bafc88d0d libraries/random (random-1.0.1.1-release-4-g180aa65) > 52c3028aff127fd957cdaf1ec7605fc533a59961 libraries/stm (stm-2.4.3-release-1-g52c3028) > 1ce8379744179e5c7f8d88049aaed4d3be52e323 libraries/terminfo (0.4.0.0) > adafac26307cffab0be20c126385ab161c259237 libraries/time (time-1.4.2-release) > 5df683cd87cb0ed13f915f73b83a7673e18aa294 libraries/transformers (0_4_0_0) > cdc3ae7b087ac7451298a5b87fe2548fb74c2fdc libraries/unix (unix-2.7.0.1-release-6-gcdc3ae7) > a6049abce040713e9a5f175887cf70d12b9057c6 libraries/vector (vector-0.10.9.1-release-1-ga6049ab) > fb9e0bbb69e15873682a9f25d39652099a3ccac1 libraries/xhtml (3000.2.1) > d98f7038d1111e515db9cc27d5d3bbe237e6e14f nofib (2009-06-25-218-gd98f703) > 5412c262f403e52be45d607b34eb3a5806ea2a76 utils/haddock (haddock-2.15-start-57-g5412c26) > 4a0f67704d89712f8493a0c7eccffa9243d6ef09 utils/hsc2hs (2009-06-25-78-g4a0f677) > > N.B.: The very first character in each line is a single whitespace. If > there's a '-' or '+' your submodule are not in the commit state recorded > in ghc.git (a '-' specifically means the submodule is not initialized > properly) > > > For further information, please read the current documentation at > > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules > > and let me know what all needs to improved. > > > On 2014-06-25 at 09:47:04 +0200, Herbert Valerio Riedel wrote: > > [...] > >> This will be similiar to the conversion of haddock.git into a proper >> submodule of which you read up in >> >> * >> * >> * >> >> List of packages converted into proper submodules: >> >> * libffi-tarballs libffi-tarballs.git >> * utils/hsc2hs hsc2hs.git >> * libraries/array packages/array.git >> * libraries/deepseq packages/deepseq.git >> * libraries/directory packages/directory.git >> * libraries/filepath packages/filepath.git >> * libraries/haskell98 packages/haskell98.git >> * libraries/haskell2010 packages/haskell2010.git >> * libraries/hoopl packages/hoopl.git >> * libraries/hpc packages/hpc.git >> * libraries/old-locale packages/old-locale.git >> * libraries/old-time packages/old-time.git >> * libraries/process packages/process.git >> * libraries/unix packages/unix.git >> * nofib nofib.git >> * libraries/parallel packages/parallel.git >> * libraries/stm packages/stm.git >> * libraries/dph packages/dph.git >> >> >> Ideally, you won't have any outstanding changes in those repos (hint, >> hint!) to make the transition for your GHC clones easier. I'll follow up >> with more specific instructions as soon as I've pushed the changes. > [...] > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From kazu at iij.ad.jp Thu Jun 26 01:18:56 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jun 2014 10:18:56 +0900 (JST) Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87egydv0kx.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> Message-ID: <20140626.101856.1747069681359386562.kazu@iij.ad.jp> Herbert, > It's done! Thanks. I tried to build GHC HEAD on Mac. I did: % git clone git://git.haskell.org/ghc.git % cd ghc % ./sync-all get % CPUS=10 sh validate Unfortunately, I got the following errors: ---- "inplace/bin/ghc-stage1" -optc-m64 -optc-fno-stack-protector -optc-Werror -optc- Wall -optc-Ilibraries/unix/include -optc-I'/Users/kazu/work/ghc/libraries/time/i nclude' -optc-I'/Users/kazu/work/ghc/libraries/bytestring/include' -optc-I'/User s/kazu/work/ghc/libraries/base/include' -optc-I'/Users/kazu/work/ghc/libraries/i nteger-gmp/include' -optc-I'/Users/kazu/work/ghc/rts/dist/build' -optc-I'/Users/ kazu/work/ghc/includes' -optc-I'/Users/kazu/work/ghc/includes/dist-derivedconsta nts/header' -optc-Wno-unknown-pragmas -static -H32m -O -Werror -Wall -H64m -O0 -package-name unix-2.7.0.1 -hide-all-packages -i -ilibraries/unix/. -ilibrari es/unix/dist-install/build -ilibraries/unix/dist-install/build/autogen -Ilibrari es/unix/dist-install/build -Ilibraries/unix/dist-install/build/autogen -Ilibrari es/unix/include -optP-include -optPlibraries/unix/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package bytestring-0.10.4.0 -package time- 1.4.2 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-use r-package-db -rtsopts -c libraries/unix/cbits/dirUtils.c -o libraries/unix/ dist-install/build/cbits/dirUtils.o libraries/ghc-prim/cbits/atomic.c:108:10: error: implicit declaration of function '__sync_fetch_and_nand' is invalid : libraries/ghc-prim/cbits/atomic.c:108:10: note: did you mean '__sync_fetch_and_and'? libraries/ghc-prim/cbits/atomic.c:78:10: note: '__sync_fetch_and_and' declared here return __sync_fetch_and_and(x, (StgWord8) val); ^ 1 error generated. ---- I think that I could validate GHC HEAD yesterday. --Kazu From johan.tibell at gmail.com Thu Jun 26 05:49:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 07:49:05 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <20140626.101856.1747069681359386562.kazu@iij.ad.jp> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> <20140626.101856.1747069681359386562.kazu@iij.ad.jp> Message-ID: This looks like my fault. I will look into it. Which gcc are you using? clang? On Thu, Jun 26, 2014 at 3:18 AM, Kazu Yamamoto wrote: > Herbert, > > > It's done! > > Thanks. > > I tried to build GHC HEAD on Mac. I did: > > % git clone git://git.haskell.org/ghc.git > % cd ghc > % ./sync-all get > % CPUS=10 sh validate > > Unfortunately, I got the following errors: > > ---- > "inplace/bin/ghc-stage1" -optc-m64 -optc-fno-stack-protector -optc-Werror > -optc- > Wall -optc-Ilibraries/unix/include > -optc-I'/Users/kazu/work/ghc/libraries/time/i > nclude' -optc-I'/Users/kazu/work/ghc/libraries/bytestring/include' > -optc-I'/User > s/kazu/work/ghc/libraries/base/include' > -optc-I'/Users/kazu/work/ghc/libraries/i > nteger-gmp/include' -optc-I'/Users/kazu/work/ghc/rts/dist/build' > -optc-I'/Users/ > kazu/work/ghc/includes' > -optc-I'/Users/kazu/work/ghc/includes/dist-derivedconsta > nts/header' -optc-Wno-unknown-pragmas -static -H32m -O -Werror -Wall > -H64m -O0 > -package-name unix-2.7.0.1 -hide-all-packages -i -ilibraries/unix/. > -ilibrari > es/unix/dist-install/build -ilibraries/unix/dist-install/build/autogen > -Ilibrari > es/unix/dist-install/build -Ilibraries/unix/dist-install/build/autogen > -Ilibrari > es/unix/include -optP-include > -optPlibraries/unix/dist-install/build/autogen/cabal_macros.h -package > base-4.7.1.0 -package bytestring-0.10.4.0 -package time- > 1.4.2 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags > -no-use > r-package-db -rtsopts -c libraries/unix/cbits/dirUtils.c -o > libraries/unix/ > dist-install/build/cbits/dirUtils.o > > libraries/ghc-prim/cbits/atomic.c:108:10: > error: implicit declaration of function '__sync_fetch_and_nand' is > invalid > : > > libraries/ghc-prim/cbits/atomic.c:108:10: > note: did you mean '__sync_fetch_and_and'? > > libraries/ghc-prim/cbits/atomic.c:78:10: > note: '__sync_fetch_and_and' declared here > return __sync_fetch_and_and(x, (StgWord8) val); > ^ > 1 error generated. > ---- > > I think that I could validate GHC HEAD yesterday. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Jun 26 05:58:53 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jun 2014 14:58:53 +0900 (JST) Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: References: <87egydv0kx.fsf@gmail.com> <20140626.101856.1747069681359386562.kazu@iij.ad.jp> Message-ID: <20140626.145853.1867434920478902126.kazu@iij.ad.jp> Hi Johan, > This looks like my fault. I will look into it. Which gcc are you using? > clang? % which gcc /usr/bin/gcc % gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix I'm not using any wrappers for gcc(clang). --Kazu From johan.tibell at gmail.com Thu Jun 26 06:07:47 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 08:07:47 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <20140626.145853.1867434920478902126.kazu@iij.ad.jp> References: <87egydv0kx.fsf@gmail.com> <20140626.101856.1747069681359386562.kazu@iij.ad.jp> <20140626.145853.1867434920478902126.kazu@iij.ad.jp> Message-ID: As a very temporary (and wrong) workaround you can edit libraries/ghc-prim/cbits/atomic.c to have the functions involving nand all return 0. I should have a fix soon. On Thu, Jun 26, 2014 at 7:58 AM, Kazu Yamamoto wrote: > Hi Johan, > > > This looks like my fault. I will look into it. Which gcc are you using? > > clang? > > % which gcc > /usr/bin/gcc > % gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) > Target: x86_64-apple-darwin13.2.0 > Thread model: posix > > I'm not using any wrappers for gcc(clang). > > --Kazu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jun 26 06:42:14 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 08:42:14 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: References: <87egydv0kx.fsf@gmail.com> <20140626.101856.1747069681359386562.kazu@iij.ad.jp> <20140626.145853.1867434920478902126.kazu@iij.ad.jp> Message-ID: Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177. On Thu, Jun 26, 2014 at 8:07 AM, Johan Tibell wrote: > As a very temporary (and wrong) workaround you can edit > libraries/ghc-prim/cbits/atomic.c to have the functions involving nand all > return 0. I should have a fix soon. > > > On Thu, Jun 26, 2014 at 7:58 AM, Kazu Yamamoto wrote: > >> Hi Johan, >> >> > This looks like my fault. I will look into it. Which gcc are you using? >> > clang? >> >> % which gcc >> /usr/bin/gcc >> % gcc --version >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) >> Target: x86_64-apple-darwin13.2.0 >> Thread model: posix >> >> I'm not using any wrappers for gcc(clang). >> >> --Kazu >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Jun 26 07:21:06 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 26 Jun 2014 16:21:06 +0900 (JST) Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: References: <20140626.145853.1867434920478902126.kazu@iij.ad.jp> Message-ID: <20140626.162106.1438951259986064441.kazu@iij.ad.jp> Johan, > Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177. Thanks. "validate" is finished with new settings on Mac. :-) --Kazu From berthold at Mathematik.Uni-Marburg.de Thu Jun 26 08:12:08 2014 From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold) Date: Thu, 26 Jun 2014 10:12:08 +0200 Subject: 2nd call for contributions: Haskell Implementors' Workshop 2014 Message-ID: <53ABD5D8.1030603@mathematik.uni-marburg.de> Dear fellow Haskellers, We are 20 days away from the deadline for HIW 2014. If you have an exciting topic you would like to present, please propose a talk by submitting an abstract (through easychair, see below). Best regards Jost Berthold ==================================================================== Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014 Gothenburg, Sweden, 06 September, 2014 Co-located with ICFP 2014 http://www.icfpconference.org/icfp2014/ Important dates --------------- Proposal Deadline: Monday, 14 July, 2014 (anywhere on earth) Notification: 21 July 2014 Workshop: Saturday, 6 September 2014 The 6th Haskell Implementors' Workshop is to be held alongside ICFP 2014 this year in Gothenburg. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Attendance figures clearly reflect the growth of the Haskell user community and a constant interest in implementation aspects. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2014. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via EasyChair. The website is: https://www.easychair.org/conferences/?conf=hiw2014 If you don't have an account you can create one here: https://www.easychair.org/account/signup.cgi Because the submission is an abstract only, please click the "abstract only" button when you make your submission. There is no need to attach a separate file. We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Jost Berthold (co-chair) (University of Copenhagen) * Kevin Hammond (University of St.Andrews) * Gabriele Keller (University of New South Wales) * Paul Liu (Intel Labs) * Rita Loogen (Philipps-Universitat Marburg) * Geoffrey Mainland (co-chair) (Drexel University, Philadelphia) * Carter Schonwald (WellPosed Ltd) Contact ------- * hiw2014 at easychair.org * Jost Berthold * Geoffrey Mainland From karel.gardas at centrum.cz Thu Jun 26 08:55:46 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 26 Jun 2014 10:55:46 +0200 Subject: Two days old build breakage on i386. Message-ID: <53ABE012.8040104@centrum.cz> Hello, builders running on i386 building for this platform caught issue which shows as a build breakage: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed Have a look for example on linux-i386 buildot log here: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS independent and probably 32bit/i386 platform specific and it's two days old breakage now. The last two night builds fail on all mentioned buildbots. I'm not sure but perhaps: commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell Date: Mon Jun 9 11:43:21 2014 +0200 triggers that issue? I'm not claiming that the commit is actual culprit, this may be just recently un-hidden issue in linear regs allocator on i386! Thanks! Karel From johan.tibell at gmail.com Thu Jun 26 10:37:53 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 12:37:53 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <53ABE012.8040104@centrum.cz> References: <53ABE012.8040104@centrum.cz> Message-ID: I think it's reasonable to say my change triggers the issue, but I don't know why and I need someone who understand the register allocator better (e.g. Simon M) to at least give me some pointers on how to debug this. If this is causing more trouble than build bot breakages (which is bad enough), let me know and I'll either revert temporarily and or try to work around the issue. Also, how do I repro this if I don't have a x86 machine lying around? Have people been successful working on these kind of issues in a VM? On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas wrote: > > Hello, > > builders running on i386 building for this platform caught issue which > shows as a build breakage: > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem > 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] > Error 1 > libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- > install/build/GHC/PrimopWrappers.o' failed > > Have a look for example on linux-i386 buildot log here: > http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html > > Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so > it's OS independent and probably 32bit/i386 platform specific and it's two > days old breakage now. The last two night builds fail on all mentioned > buildbots. I'm not sure but perhaps: > > commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > Author: Johan Tibell > Date: Mon Jun 9 11:43:21 2014 +0200 > > triggers that issue? I'm not claiming that the commit is actual culprit, > this may be just recently un-hidden issue in linear regs allocator on i386! > > Thanks! > Karel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Thu Jun 26 11:33:44 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Thu, 26 Jun 2014 13:33:44 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> Message-ID: 2014-06-26 12:37 GMT+02:00 Johan Tibell : > Also, how do I repro this if I don't have a x86 machine lying around? Have > people been successful working on these kind of issues in a VM? For what it is worth, the FreeBSD/i386 builder actually runs in jail with a 32-bit userland on a 64-bit host, and it apparently can reproduce the problem. From karel.gardas at centrum.cz Thu Jun 26 11:42:47 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 26 Jun 2014 13:42:47 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> Message-ID: <53AC0737.4080005@centrum.cz> On 06/26/14 12:37 PM, Johan Tibell wrote: > I think it's reasonable to say my change triggers the issue, but I don't > know why and I need someone who understand the register allocator better > (e.g. Simon M) to at least give me some pointers on how to debug this. > If this is causing more trouble than build bot breakages (which is bad > enough), let me know and I'll either revert temporarily and or try to > work around the issue. it does not hurt me as long as it does not go to 7.10 release so it's enough time to fix that. So feel free not to revert your patch especially if you do have some time to look into real culprit in regs alloc. > Also, how do I repro this if I don't have a x86 machine lying around? > Have people been successful working on these kind of issues in a VM? My simplest way is to install VirtualBox and inside it i386-ubuntu, give it 2 GB RAM, 15GB drive and this should get you going really quickly. Then you will need to: sudo apt-get install gcc ghc make git (in ubuntu) which should be enough and then just follow ghc's wiki to obtain source tree and bootstrap on linux... Roughly it should be that IMHO. If not, I may do that myself and send you exact stepts to follow... Thanks! Karel > > > On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas > wrote: > > > Hello, > > builders running on i386 building for this platform caught issue > which shows as a build breakage: > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140624 for i386-unknown-linux): > RegAllocLinear.__allocRegsAndSpill: no spill candidates > allocating vreg: VirtualRegI n1Q6 > assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) > 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > Please report this as a GHC bug: > http://www.haskell.org/ghc/__reportabug > > make[1]: *** > [libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o] Error 1 > libraries/ghc-prim/ghc.mk:4 : recipe for target > 'libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o' failed > > Have a look for example on linux-i386 buildot log here: > http://haskell.inf.elte.hu/__builders/validator1-linux-x86-__head/18/7.html > > > Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 > so it's OS independent and probably 32bit/i386 platform specific and > it's two days old breakage now. The last two night builds fail on > all mentioned buildbots. I'm not sure but perhaps: > > commit d8abf85f8ca176854e9d5d0b12371c__4bc402aac3 > Author: Johan Tibell > > Date: Mon Jun 9 11:43:21 2014 +0200 > > triggers that issue? I'm not claiming that the commit is actual > culprit, this may be just recently un-hidden issue in linear regs > allocator on i386! > > Thanks! > Karel > > From simonpj at microsoft.com Thu Jun 26 12:13:08 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 12:13:08 +0000 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87ionpv3bb.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103ED38A@DB3PRD3001MB020.064d.mgd.msft.net> Thank you Herbert! Did you follow up with more specific instructions? In particular, - how do I bring an existing clean tree up to date? - if I have a tree with a bunch of as-yet-unpushed commits, what do I do? Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Herbert | Valerio Riedel | Sent: 25 June 2014 08:47 | To: ghc-devs | Subject: HEADS-UP: Git submodule conversion imminent | | Hello GHC Devs! | | In order to not drag this out any longer, I'll completing the submodule | conversion in the next few hours by converting the remaining sub-repo | packages into proper submodules. | | This is represents phase 1 of the reorganization (phase 2 comprises | officially transitioning the push-urls of *some* the packages to | github.com/haskell as happened with haddock). However, this phase 1 is | important to get done early (ideally half a year ago) in order to make | 'ghc-complete' bit more redundant (I hope Joachim doesn't mind... :-) ) | and allow to properly 'git bisect' as far back as possible into the | past. | | While the workflow changes[1] to additionally have the sub-repo change | also | registed in ghc.git, practically, this should affect only a minority of | you, as the remaining packages (see list at the bottom of this mail) to | be | converted into submodules are modified *very* seldom. | | This will be similiar to the conversion of haddock.git into a proper | submodule of which you read up in | | * | * | * | | List of packages converted into proper submodules: | | * libffi-tarballs libffi-tarballs.git | * utils/hsc2hs hsc2hs.git | * libraries/array packages/array.git | * libraries/deepseq packages/deepseq.git | * libraries/directory packages/directory.git | * libraries/filepath packages/filepath.git | * libraries/haskell98 packages/haskell98.git | * libraries/haskell2010 packages/haskell2010.git | * libraries/hoopl packages/hoopl.git | * libraries/hpc packages/hpc.git | * libraries/old-locale packages/old-locale.git | * libraries/old-time packages/old-time.git | * libraries/process packages/process.git | * libraries/unix packages/unix.git | * nofib nofib.git | * libraries/parallel packages/parallel.git | * libraries/stm packages/stm.git | * libraries/dph packages/dph.git | | | Ideally, you won't have any outstanding changes in those repos (hint, | hint!) to make the transition for your GHC clones easier. I'll follow up | with more specific instructions as soon as I've pushed the changes. | | | N.B.: ghc-tarballs will *not* become a submodule, as it would impose a | non-neglible cost on everyone, not only the developers on windows | and, moreover, the plan is to turn ghc-tarballs into a scripted | download (or maybe something git-annex based) as Git is not really | suited for such large blobs. | | See also discussion at | | | | [1]: For the new workflow in case you really happen to have to touch | one of the affected modules, see the work-in-progress Wiki entry at | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#M | akingchangestoGHCsubmodules | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Jun 26 12:13:02 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 12:13:02 +0000 Subject: Pruning GADT case alternatives with uninhabitable coercion parameters In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EAB01@DB3PRD3001MB020.064d.mgd.msft.net> <8A4BE71AF969544FA98E6D49C10DE5A60381D5BB@DB3PRD3001MB019.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103EAC70@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103ED366@DB3PRD3001MB020.064d.mgd.msft.net> I?m on a train, so can?t look at your code. But I urge you (or whoever) to split the task into two: ? Traverse the Core tree, gathering given constraints, deleting unreachable branches ? The Contradiction Checker (CCK) CCK is independently useful; for example George et al may use it when traversing HsSyn to report overlapping patterns. The API of CCK might look something like this: contradictionCheck :: FamInstEnvs -> [PredType] -> [PredType] -> Bool ? FamInstEnvs tells it what type-family-instances exist ? The first [PredType] are the enclosing givens ? The second [PredType] are the givens of a new pattern match ? Result is True if the new pattern match is inaccessible One might also consider a more incremental API, something like data ContradictionChecker newCCK :: FamInstEnvs -> ContradictionChecker check :: ContradictionChecker -> [PredType] -> Maybe ContradictionChecker Returns Nothing for a contradiction, (Just cc) if the branch is reachable, where you should use cc for the body of the branch. I like the latter API. For example a ContrdictionChecker might carry a renaming of type variables, to account for shadowing. Simon From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott Sent: 25 June 2014 00:11 To: Simon Peyton Jones Cc: Dimitrios Vytiniotis; ghc-devs at haskell.org; Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias Subject: Re: Pruning GADT case alternatives with uninhabitable coercion parameters I'm glad for the interest and help. I can make an initial go of it. My current simple plan is to traverse expressions, collecting type equalities from bound coercion variables as I descend, combining them progressively with successive type unifications. The traversal is thus parametrized by a TvSubst and yields a Maybe TvSubst. The coercion variables will come from lambdas, let bindings and case alternatives. If an added equality is not unifiable given the current TvSubst, we've reached a contradiction. If the contradiction arises for one of the variables in a case alternative, then remove that alternative. How does this strategy sound? Some issues: * Nominal vs representational type equalities. * Will I want to normalize the types (with normaliseType) before unifying? * How can I unify while carrying along a type substitution environment? The Unify module exports tcUnifyTy, which takes no such environment, but not unify, which does. -- Conal On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones > wrote: we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can?t assess very well yet if this is a real problem though That is a very good point. Nevertheless, given ? the typechecked HsSyn (i.e. still in source form, but with type inference fully completed ? the independent contradiction-detector described below (which is independent of whether the contradiction problems it is given come from HsSyn or Core) it would be easy to give source-localised error messages Simon From: Dimitrios Vytiniotis Sent: 24 June 2014 11:58 To: Simon Peyton Jones; Conal Elliott; ghc-devs at haskell.org Cc: Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Yes it would be better in the sense that we don?t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can?t assess very well yet if this is a real problem though ? In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- From: Simon Peyton Jones Sent: Tuesday, June 24, 2014 11:41 AM To: Conal Elliott; ghc-devs at haskell.org Cc: Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nickie at softlab.ntua.gr); George Karachalias; Simon Peyton Jones Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I?m cc?ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn?t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it?s task could be to answer the question Is C |- D definitely a contradiction? where C are the ?given? constraints (from enclosing pattern matches) and D are the ?wanted? constraints (from the current pattern match that may be unreachable). I don?t think it would be hard to implement such a function. I?d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it?d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs at haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 26 12:13:24 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 12:13:24 +0000 Subject: Two days old build breakage on i386. In-Reply-To: <53ABE012.8040104@centrum.cz> References: <53ABE012.8040104@centrum.cz> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> Aaaargh! Once again the Windows build is broken. I am utterly stalled. Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the fix to X and Y. Please can someone bisect to find out which patch is the culprit? I wish we had a more systematic way to find this out. I hate being the main person who gets stuck because some unrelated change has broken the Windows build. (Thanks for Karel, who got to it a day before me.) Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel | Gardas | Sent: 26 June 2014 09:56 | To: ghc-devs; Johan Tibell | Subject: Two days old build breakage on i386. | | | Hello, | | builders running on i386 building for this platform caught issue which | shows as a build breakage: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140624 for i386-unknown-linux): | RegAllocLinear.allocRegsAndSpill: no spill candidates | allocating vreg: VirtualRegI n1Q6 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] | freeRegs: FreeRegs 4282318848 | initFreeRegs: FreeRegs 4282318861 | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | make[1]: *** | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 | libraries/ghc-prim/ghc.mk:4: recipe for target | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed | | Have a look for example on linux-i386 buildot log here: | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html | | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so | it's OS independent and probably 32bit/i386 platform specific and it's | two days old breakage now. The last two night builds fail on all | mentioned buildbots. I'm not sure but perhaps: | | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 | Author: Johan Tibell | Date: Mon Jun 9 11:43:21 2014 +0200 | | triggers that issue? I'm not claiming that the commit is actual culprit, | this may be just recently un-hidden issue in linear regs allocator on | i386! | | Thanks! | Karel | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Thu Jun 26 12:24:40 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 14:24:40 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones wrote: > Aaaargh! Once again the Windows build is broken. I am utterly stalled. > > Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At > least they should elicit warnings saying that they are disabled pending the > fix to X and Y. > > Please can someone bisect to find out which patch is the culprit? > > I wish we had a more systematic way to find this out. I hate being the > main person who gets stuck because some unrelated change has broken the > Windows build. (Thanks for Karel, who got to it a day before me.) > > Thanks > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel > | Gardas > | Sent: 26 June 2014 09:56 > | To: ghc-devs; Johan Tibell > | Subject: Two days old build breakage on i386. > | > | > | Hello, > | > | builders running on i386 building for this platform caught issue which > | shows as a build breakage: > | > | ghc-stage1: panic! (the 'impossible' happened) > | (GHC version 7.9.20140624 for i386-unknown-linux): > | RegAllocLinear.allocRegsAndSpill: no spill candidates > | allocating vreg: VirtualRegI n1Q6 > | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) > | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > | freeRegs: FreeRegs 4282318848 > | initFreeRegs: FreeRegs 4282318861 > | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > | make[1]: *** > | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > | libraries/ghc-prim/ghc.mk:4: recipe for target > | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed > | > | Have a look for example on linux-i386 buildot log here: > | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html > | > | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so > | it's OS independent and probably 32bit/i386 platform specific and it's > | two days old breakage now. The last two night builds fail on all > | mentioned buildbots. I'm not sure but perhaps: > | > | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > | Author: Johan Tibell > | Date: Mon Jun 9 11:43:21 2014 +0200 > | > | triggers that issue? I'm not claiming that the commit is actual culprit, > | this may be just recently un-hidden issue in linear regs allocator on > | i386! > | > | Thanks! > | Karel > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Thu Jun 26 12:31:20 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 26 Jun 2014 14:31:20 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> Message-ID: <53AC1298.1090002@fuuzetsu.co.uk> On 06/26/2014 12:37 PM, Johan Tibell wrote: > I think it's reasonable to say my change triggers the issue, but I don't > know why and I need someone who understand the register allocator better > (e.g. Simon M) to at least give me some pointers on how to debug this. If > this is causing more trouble than build bot breakages (which is bad > enough), let me know and I'll either revert temporarily and or try to work > around the issue. > > Also, how do I repro this if I don't have a x86 machine lying around? Have > people been successful working on these kind of issues in a VM? > I can give you shell access to the machine in the OP but it's not the fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it. > > On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas > wrote: > >> >> Hello, >> >> builders running on i386 building for this platform caught issue which >> shows as a build breakage: >> >> ghc-stage1: panic! (the 'impossible' happened) >> (GHC version 7.9.20140624 for i386-unknown-linux): >> RegAllocLinear.allocRegsAndSpill: no spill candidates >> allocating vreg: VirtualRegI n1Q6 >> assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem >> 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >> freeRegs: FreeRegs 4282318848 >> initFreeRegs: FreeRegs 4282318861 >> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] >> Error 1 >> libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- >> install/build/GHC/PrimopWrappers.o' failed >> >> Have a look for example on linux-i386 buildot log here: >> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >> >> Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so >> it's OS independent and probably 32bit/i386 platform specific and it's two >> days old breakage now. The last two night builds fail on all mentioned >> buildbots. I'm not sure but perhaps: >> >> commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >> Author: Johan Tibell >> Date: Mon Jun 9 11:43:21 2014 +0200 >> >> triggers that issue? I'm not claiming that the commit is actual culprit, >> this may be just recently un-hidden issue in linear regs allocator on i386! >> >> Thanks! >> Karel >> > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Mateusz K. From johan.tibell at gmail.com Thu Jun 26 12:34:14 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 14:34:14 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <53AC1298.1090002@fuuzetsu.co.uk> References: <53ABE012.8040104@centrum.cz> <53AC1298.1090002@fuuzetsu.co.uk> Message-ID: On Thu, Jun 26, 2014 at 2:31 PM, Mateusz Kowalczyk wrote: > On 06/26/2014 12:37 PM, Johan Tibell wrote: > > I think it's reasonable to say my change triggers the issue, but I don't > > know why and I need someone who understand the register allocator better > > (e.g. Simon M) to at least give me some pointers on how to debug this. If > > this is causing more trouble than build bot breakages (which is bad > > enough), let me know and I'll either revert temporarily and or try to > work > > around the issue. > > > > Also, how do I repro this if I don't have a x86 machine lying around? > Have > > people been successful working on these kind of issues in a VM? > > > > I can give you shell access to the machine in the OP but it's not the > fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it. Thanks, but I'll try to see if I can install VirtualBox on my OS X machine first. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Jun 26 12:37:12 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 26 Jun 2014 14:37:12 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <53AC0737.4080005@centrum.cz> (Karel Gardas's message of "Thu, 26 Jun 2014 13:42:47 +0200") References: <53ABE012.8040104@centrum.cz> <53AC0737.4080005@centrum.cz> Message-ID: <8738erq22v.fsf@gmail.com> On 2014-06-26 at 13:42:47 +0200, Karel Gardas wrote: > On 06/26/14 12:37 PM, Johan Tibell wrote: [...] >> Also, how do I repro this if I don't have a x86 machine lying around? >> Have people been successful working on these kind of issues in a VM? > > My simplest way is to install VirtualBox and inside it i386-ubuntu, > give it 2 GB RAM, 15GB drive and this should get you going really > quickly. Then you will need to: Fwiw, on Ubuntu I'd rather recommend something more lightweight such as schroot or using LXC, i.e. https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-basic-usage as using such a container seems to have less SMP-scheduling overhead and memory overhead. From johan.tibell at gmail.com Thu Jun 26 12:37:26 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 14:37:26 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm going to push a revert to HEAD. I'm validating the commit now so it should reach HEAD soonish. On Thu, Jun 26, 2014 at 2:24 PM, Johan Tibell wrote: > Just to make sure this is the same breakage, are you on an i386 Windows > machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. > > > On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > wrote: > >> Aaaargh! Once again the Windows build is broken. I am utterly stalled. >> >> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At >> least they should elicit warnings saying that they are disabled pending the >> fix to X and Y. >> >> Please can someone bisect to find out which patch is the culprit? >> >> I wish we had a more systematic way to find this out. I hate being the >> main person who gets stuck because some unrelated change has broken the >> Windows build. (Thanks for Karel, who got to it a day before me.) >> >> Thanks >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel >> | Gardas >> | Sent: 26 June 2014 09:56 >> | To: ghc-devs; Johan Tibell >> | Subject: Two days old build breakage on i386. >> | >> | >> | Hello, >> | >> | builders running on i386 building for this platform caught issue which >> | shows as a build breakage: >> | >> | ghc-stage1: panic! (the 'impossible' happened) >> | (GHC version 7.9.20140624 for i386-unknown-linux): >> | RegAllocLinear.allocRegsAndSpill: no spill candidates >> | allocating vreg: VirtualRegI n1Q6 >> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) >> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >> | freeRegs: FreeRegs 4282318848 >> | initFreeRegs: FreeRegs 4282318861 >> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> | make[1]: *** >> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 >> | libraries/ghc-prim/ghc.mk:4: recipe for target >> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed >> | >> | Have a look for example on linux-i386 buildot log here: >> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >> | >> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so >> | it's OS independent and probably 32bit/i386 platform specific and it's >> | two days old breakage now. The last two night builds fail on all >> | mentioned buildbots. I'm not sure but perhaps: >> | >> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >> | Author: Johan Tibell >> | Date: Mon Jun 9 11:43:21 2014 +0200 >> | >> | triggers that issue? I'm not claiming that the commit is actual culprit, >> | this may be just recently un-hidden issue in linear regs allocator on >> | i386! >> | >> | Thanks! >> | Karel >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Jun 26 12:44:38 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 26 Jun 2014 14:44:38 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103ED38A@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Thu, 26 Jun 2014 12:13:08 +0000") References: <87ionpv3bb.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103ED38A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87y4wjon61.fsf@gmail.com> Hi Simon, On 2014-06-26 at 14:13:08 +0200, Simon Peyton Jones wrote: > Did you follow up with more specific instructions? > > In particular, > - how do I bring an existing clean tree up to date? I tought I addressed that right at the start of http://www.haskell.org/pipermail/ghc-devs/2014-June/005311.html ? > - if I have a tree with a bunch of as-yet-unpushed commits, what do I > do? If you have as-yet-unpushed commits in ghc.git, there shouldn't be anything special to handle. Or were you referring to the case of having unpushed commits in the converted sub-repos? Cheers, hvr From simonpj at microsoft.com Thu Jun 26 12:47:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 12:47:00 +0000 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103ED520@DB3PRD3001MB020.064d.mgd.msft.net> Thanks. It?s blocking me from building GHC at all on my laptop, so temporary reversion would be great Thank you! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 26 June 2014 11:38 To: Karel Gardas Cc: Simon Marlow; ghc-devs Subject: Re: Two days old build breakage on i386. I think it's reasonable to say my change triggers the issue, but I don't know why and I need someone who understand the register allocator better (e.g. Simon M) to at least give me some pointers on how to debug this. If this is causing more trouble than build bot breakages (which is bad enough), let me know and I'll either revert temporarily and or try to work around the issue. Also, how do I repro this if I don't have a x86 machine lying around? Have people been successful working on these kind of issues in a VM? On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas > wrote: Hello, builders running on i386 building for this platform caught issue which shows as a build breakage: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed Have a look for example on linux-i386 buildot log here: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS independent and probably 32bit/i386 platform specific and it's two days old breakage now. The last two night builds fail on all mentioned buildbots. I'm not sure but perhaps: commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell > Date: Mon Jun 9 11:43:21 2014 +0200 triggers that issue? I'm not claiming that the commit is actual culprit, this may be just recently un-hidden issue in linear regs allocator on i386! Thanks! Karel -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 26 12:49:24 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 12:49:24 +0000 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 [master f958079] Revert "Add more primops for atomic ops on byte arrays" 23 files changed, 86 insertions(+), 1016 deletions(-) rewrite compiler/nativeGen/CPrim.hs (62%) delete mode 100644 libraries/ghc-prim/cbits/atomic.c delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 HEAD $ What now? Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 26 June 2014 13:25 To: Simon Peyton Jones Cc: Karel Gardas; ghc-devs Subject: Re: Two days old build breakage on i386. Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > wrote: Aaaargh! Once again the Windows build is broken. I am utterly stalled. Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the fix to X and Y. Please can someone bisect to find out which patch is the culprit? I wish we had a more systematic way to find this out. I hate being the main person who gets stuck because some unrelated change has broken the Windows build. (Thanks for Karel, who got to it a day before me.) Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel | Gardas | Sent: 26 June 2014 09:56 | To: ghc-devs; Johan Tibell | Subject: Two days old build breakage on i386. | | | Hello, | | builders running on i386 building for this platform caught issue which | shows as a build breakage: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140624 for i386-unknown-linux): | RegAllocLinear.allocRegsAndSpill: no spill candidates | allocating vreg: VirtualRegI n1Q6 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] | freeRegs: FreeRegs 4282318848 | initFreeRegs: FreeRegs 4282318861 | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | make[1]: *** | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 | libraries/ghc-prim/ghc.mk:4: recipe for target | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed | | Have a look for example on linux-i386 buildot log here: | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html | | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so | it's OS independent and probably 32bit/i386 platform specific and it's | two days old breakage now. The last two night builds fail on all | mentioned buildbots. I'm not sure but perhaps: | | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 | Author: Johan Tibell > | Date: Mon Jun 9 11:43:21 2014 +0200 | | triggers that issue? I'm not claiming that the commit is actual culprit, | this may be just recently un-hidden issue in linear regs allocator on | i386! | | Thanks! | Karel | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jun 26 12:51:17 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 14:51:17 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed this morning) which is fine. You should be in a good state now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones wrote: > git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > > [master f958079] Revert "Add more primops for atomic ops on byte arrays" > > 23 files changed, 86 insertions(+), 1016 deletions(-) > > rewrite compiler/nativeGen/CPrim.hs (62%) > > delete mode 100644 libraries/ghc-prim/cbits/atomic.c > > delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs > > delete mode 100644 > testsuite/tests/concurrent/should_run/AtomicPrimops.stdout > > HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 > > fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 > > HEAD $ > > What now? > > Simon > > > > *From:* Johan Tibell [mailto:johan.tibell at gmail.com] > *Sent:* 26 June 2014 13:25 > *To:* Simon Peyton Jones > *Cc:* Karel Gardas; ghc-devs > *Subject:* Re: Two days old build breakage on i386. > > > > Just to make sure this is the same breakage, are you on an i386 Windows > machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. > > > > On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > wrote: > > Aaaargh! Once again the Windows build is broken. I am utterly stalled. > > Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At > least they should elicit warnings saying that they are disabled pending the > fix to X and Y. > > Please can someone bisect to find out which patch is the culprit? > > I wish we had a more systematic way to find this out. I hate being the > main person who gets stuck because some unrelated change has broken the > Windows build. (Thanks for Karel, who got to it a day before me.) > > Thanks > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel > | Gardas > | Sent: 26 June 2014 09:56 > | To: ghc-devs; Johan Tibell > | Subject: Two days old build breakage on i386. > | > | > | Hello, > | > | builders running on i386 building for this platform caught issue which > | shows as a build breakage: > | > | ghc-stage1: panic! (the 'impossible' happened) > | (GHC version 7.9.20140624 for i386-unknown-linux): > | RegAllocLinear.allocRegsAndSpill: no spill candidates > | allocating vreg: VirtualRegI n1Q6 > | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) > | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] > | freeRegs: FreeRegs 4282318848 > | initFreeRegs: FreeRegs 4282318861 > | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > | make[1]: *** > | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 > | libraries/ghc-prim/ghc.mk:4: recipe for target > | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed > | > | Have a look for example on linux-i386 buildot log here: > | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html > | > | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so > | it's OS independent and probably 32bit/i386 platform specific and it's > | two days old breakage now. The last two night builds fail on all > | mentioned buildbots. I'm not sure but perhaps: > | > | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > | Author: Johan Tibell > | Date: Mon Jun 9 11:43:21 2014 +0200 > | > | triggers that issue? I'm not claiming that the commit is actual culprit, > | this may be just recently un-hidden issue in linear regs allocator on > | i386! > | > | Thanks! > | Karel > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jun 26 13:05:53 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 15:05:53 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Herbert pushed my revert for me a minute ago. Everyone should be good once they sync. On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell wrote: > I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I > pushed this morning) which is fine. You should be in a good state now when > d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. > > > On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones > wrote: > >> git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >> >> [master f958079] Revert "Add more primops for atomic ops on byte arrays" >> >> 23 files changed, 86 insertions(+), 1016 deletions(-) >> >> rewrite compiler/nativeGen/CPrim.hs (62%) >> >> delete mode 100644 libraries/ghc-prim/cbits/atomic.c >> >> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs >> >> delete mode 100644 >> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout >> >> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >> >> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >> >> HEAD $ >> >> What now? >> >> Simon >> >> >> >> *From:* Johan Tibell [mailto:johan.tibell at gmail.com] >> *Sent:* 26 June 2014 13:25 >> *To:* Simon Peyton Jones >> *Cc:* Karel Gardas; ghc-devs >> *Subject:* Re: Two days old build breakage on i386. >> >> >> >> Just to make sure this is the same breakage, are you on an i386 Windows >> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. >> >> >> >> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> Aaaargh! Once again the Windows build is broken. I am utterly stalled. >> >> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At >> least they should elicit warnings saying that they are disabled pending the >> fix to X and Y. >> >> Please can someone bisect to find out which patch is the culprit? >> >> I wish we had a more systematic way to find this out. I hate being the >> main person who gets stuck because some unrelated change has broken the >> Windows build. (Thanks for Karel, who got to it a day before me.) >> >> Thanks >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel >> | Gardas >> | Sent: 26 June 2014 09:56 >> | To: ghc-devs; Johan Tibell >> | Subject: Two days old build breakage on i386. >> | >> | >> | Hello, >> | >> | builders running on i386 building for this platform caught issue which >> | shows as a build breakage: >> | >> | ghc-stage1: panic! (the 'impossible' happened) >> | (GHC version 7.9.20140624 for i386-unknown-linux): >> | RegAllocLinear.allocRegsAndSpill: no spill candidates >> | allocating vreg: VirtualRegI n1Q6 >> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) >> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >> | freeRegs: FreeRegs 4282318848 >> | initFreeRegs: FreeRegs 4282318861 >> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> | make[1]: *** >> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 >> | libraries/ghc-prim/ghc.mk:4: recipe for target >> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed >> | >> | Have a look for example on linux-i386 buildot log here: >> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >> | >> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so >> | it's OS independent and probably 32bit/i386 platform specific and it's >> | two days old breakage now. The last two night builds fail on all >> | mentioned buildbots. I'm not sure but perhaps: >> | >> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >> | Author: Johan Tibell >> | Date: Mon Jun 9 11:43:21 2014 +0200 >> | >> | triggers that issue? I'm not claiming that the commit is actual culprit, >> | this may be just recently un-hidden issue in linear regs allocator on >> | i386! >> | >> | Thanks! >> | Karel >> >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jun 26 18:17:29 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 20:17:29 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm trying to understand the output from the register allocator: (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Without understanding exactly what's wrong, the message above suggests that we're trying to allocate a reg for n1nD, but there's already an assignment for that virtual reg, is that right? On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell wrote: > Herbert pushed my revert for me a minute ago. Everyone should be good once > they sync. > > > On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell > wrote: > >> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I >> pushed this morning) which is fine. You should be in a good state now when >> d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. >> >> >> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >>> git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>> >>> [master f958079] Revert "Add more primops for atomic ops on byte arrays" >>> >>> 23 files changed, 86 insertions(+), 1016 deletions(-) >>> >>> rewrite compiler/nativeGen/CPrim.hs (62%) >>> >>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c >>> >>> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs >>> >>> delete mode 100644 >>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout >>> >>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>> >>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>> >>> HEAD $ >>> >>> What now? >>> >>> Simon >>> >>> >>> >>> *From:* Johan Tibell [mailto:johan.tibell at gmail.com] >>> *Sent:* 26 June 2014 13:25 >>> *To:* Simon Peyton Jones >>> *Cc:* Karel Gardas; ghc-devs >>> *Subject:* Re: Two days old build breakage on i386. >>> >>> >>> >>> Just to make sure this is the same breakage, are you on an i386 Windows >>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. >>> >>> >>> >>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> Aaaargh! Once again the Windows build is broken. I am utterly stalled. >>> >>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. >>> At least they should elicit warnings saying that they are disabled pending >>> the fix to X and Y. >>> >>> Please can someone bisect to find out which patch is the culprit? >>> >>> I wish we had a more systematic way to find this out. I hate being the >>> main person who gets stuck because some unrelated change has broken the >>> Windows build. (Thanks for Karel, who got to it a day before me.) >>> >>> Thanks >>> >>> Simon >>> >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>> Karel >>> | Gardas >>> | Sent: 26 June 2014 09:56 >>> | To: ghc-devs; Johan Tibell >>> | Subject: Two days old build breakage on i386. >>> | >>> | >>> | Hello, >>> | >>> | builders running on i386 building for this platform caught issue which >>> | shows as a build breakage: >>> | >>> | ghc-stage1: panic! (the 'impossible' happened) >>> | (GHC version 7.9.20140624 for i386-unknown-linux): >>> | RegAllocLinear.allocRegsAndSpill: no spill candidates >>> | allocating vreg: VirtualRegI n1Q6 >>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) >>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >>> | freeRegs: FreeRegs 4282318848 >>> | initFreeRegs: FreeRegs 4282318861 >>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >>> | make[1]: *** >>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 >>> | libraries/ghc-prim/ghc.mk:4: recipe for target >>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed >>> | >>> | Have a look for example on linux-i386 buildot log here: >>> | >>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >>> | >>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so >>> | it's OS independent and probably 32bit/i386 platform specific and it's >>> | two days old breakage now. The last two night builds fail on all >>> | mentioned buildbots. I'm not sure but perhaps: >>> | >>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>> | Author: Johan Tibell >>> | Date: Mon Jun 9 11:43:21 2014 +0200 >>> | >>> | triggers that issue? I'm not claiming that the commit is actual >>> culprit, >>> | this may be just recently un-hidden issue in linear regs allocator on >>> | i386! >>> | >>> | Thanks! >>> | Karel >>> >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jun 26 18:39:53 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 26 Jun 2014 20:39:53 +0200 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Here's some more debug output. Can someone interpret it: genRaInsn cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4) r_dying = [%vI_n1nD, %vI_n1nE, %vI_n1nF] w_dying = [] virt_read = [%vI_n1nD, %vI_n1nE, %vI_n1nF] virt_written = [] freeregs = FreeRegs 4282318848 assig = [n1nD :-> InMem 0, n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg (RealRegSingle 3)] ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 (i.e. it's the cmpxchg instruction which is causing the failure.) On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell wrote: > I'm trying to understand the output from the register allocator: > > (GHC version 7.9.20140626 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1nD > assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle > 2)),(n1nF,InReg (RealRegSingle 3))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Without understanding exactly what's wrong, the message above suggests > that we're trying to allocate a reg for n1nD, but there's already an > assignment for that virtual reg, is that right? > > > > On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell > wrote: > >> Herbert pushed my revert for me a minute ago. Everyone should be good >> once they sync. >> >> >> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell >> wrote: >> >>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which >>> I pushed this morning) which is fine. You should be in a good state now >>> when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. >>> >>> >>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>>> git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> >>>> [master f958079] Revert "Add more primops for atomic ops on byte arrays" >>>> >>>> 23 files changed, 86 insertions(+), 1016 deletions(-) >>>> >>>> rewrite compiler/nativeGen/CPrim.hs (62%) >>>> >>>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c >>>> >>>> delete mode 100644 >>>> testsuite/tests/concurrent/should_run/AtomicPrimops.hs >>>> >>>> delete mode 100644 >>>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout >>>> >>>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>>> >>>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 >>>> >>>> HEAD $ >>>> >>>> What now? >>>> >>>> Simon >>>> >>>> >>>> >>>> *From:* Johan Tibell [mailto:johan.tibell at gmail.com] >>>> *Sent:* 26 June 2014 13:25 >>>> *To:* Simon Peyton Jones >>>> *Cc:* Karel Gardas; ghc-devs >>>> *Subject:* Re: Two days old build breakage on i386. >>>> >>>> >>>> >>>> Just to make sure this is the same breakage, are you on an i386 Windows >>>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. >>>> >>>> >>>> >>>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones < >>>> simonpj at microsoft.com> wrote: >>>> >>>> Aaaargh! Once again the Windows build is broken. I am utterly >>>> stalled. >>>> >>>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. >>>> At least they should elicit warnings saying that they are disabled pending >>>> the fix to X and Y. >>>> >>>> Please can someone bisect to find out which patch is the culprit? >>>> >>>> I wish we had a more systematic way to find this out. I hate being the >>>> main person who gets stuck because some unrelated change has broken the >>>> Windows build. (Thanks for Karel, who got to it a day before me.) >>>> >>>> Thanks >>>> >>>> Simon >>>> >>>> >>>> | -----Original Message----- >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>>> Karel >>>> | Gardas >>>> | Sent: 26 June 2014 09:56 >>>> | To: ghc-devs; Johan Tibell >>>> | Subject: Two days old build breakage on i386. >>>> | >>>> | >>>> | Hello, >>>> | >>>> | builders running on i386 building for this platform caught issue which >>>> | shows as a build breakage: >>>> | >>>> | ghc-stage1: panic! (the 'impossible' happened) >>>> | (GHC version 7.9.20140624 for i386-unknown-linux): >>>> | RegAllocLinear.allocRegsAndSpill: no spill candidates >>>> | allocating vreg: VirtualRegI n1Q6 >>>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) >>>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] >>>> | freeRegs: FreeRegs 4282318848 >>>> | initFreeRegs: FreeRegs 4282318861 >>>> | Please report this as a GHC bug: >>>> http://www.haskell.org/ghc/reportabug >>>> | make[1]: *** >>>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 >>>> | libraries/ghc-prim/ghc.mk:4: recipe for target >>>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed >>>> | >>>> | Have a look for example on linux-i386 buildot log here: >>>> | >>>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html >>>> | >>>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 >>>> so >>>> | it's OS independent and probably 32bit/i386 platform specific and it's >>>> | two days old breakage now. The last two night builds fail on all >>>> | mentioned buildbots. I'm not sure but perhaps: >>>> | >>>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 >>>> | Author: Johan Tibell >>>> | Date: Mon Jun 9 11:43:21 2014 +0200 >>>> | >>>> | triggers that issue? I'm not claiming that the commit is actual >>>> culprit, >>>> | this may be just recently un-hidden issue in linear regs allocator on >>>> | i386! >>>> | >>>> | Thanks! >>>> | Karel >>>> >>>> | _______________________________________________ >>>> | ghc-devs mailing list >>>> | ghc-devs at haskell.org >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 26 19:31:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 19:31:45 +0000 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EDBD5@DB3PRD3001MB020.064d.mgd.msft.net> Thank you!! From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 26 June 2014 14:06 To: Simon Peyton Jones Cc: Karel Gardas; ghc-devs Subject: Re: Two days old build breakage on i386. Herbert pushed my revert for me a minute ago. Everyone should be good once they sync. On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell > wrote: I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed this morning) which is fine. You should be in a good state now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones > wrote: git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 [master f958079] Revert "Add more primops for atomic ops on byte arrays" 23 files changed, 86 insertions(+), 1016 deletions(-) rewrite compiler/nativeGen/CPrim.hs (62%) delete mode 100644 libraries/ghc-prim/cbits/atomic.c delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 HEAD $ What now? Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 26 June 2014 13:25 To: Simon Peyton Jones Cc: Karel Gardas; ghc-devs Subject: Re: Two days old build breakage on i386. Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > wrote: Aaaargh! Once again the Windows build is broken. I am utterly stalled. Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the fix to X and Y. Please can someone bisect to find out which patch is the culprit? I wish we had a more systematic way to find this out. I hate being the main person who gets stuck because some unrelated change has broken the Windows build. (Thanks for Karel, who got to it a day before me.) Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel | Gardas | Sent: 26 June 2014 09:56 | To: ghc-devs; Johan Tibell | Subject: Two days old build breakage on i386. | | | Hello, | | builders running on i386 building for this platform caught issue which | shows as a build breakage: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140624 for i386-unknown-linux): | RegAllocLinear.allocRegsAndSpill: no spill candidates | allocating vreg: VirtualRegI n1Q6 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] | freeRegs: FreeRegs 4282318848 | initFreeRegs: FreeRegs 4282318861 | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | make[1]: *** | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 | libraries/ghc-prim/ghc.mk:4: recipe for target | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed | | Have a look for example on linux-i386 buildot log here: | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html | | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so | it's OS independent and probably 32bit/i386 platform specific and it's | two days old breakage now. The last two night builds fail on all | mentioned buildbots. I'm not sure but perhaps: | | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 | Author: Johan Tibell > | Date: Mon Jun 9 11:43:21 2014 +0200 | | triggers that issue? I'm not claiming that the commit is actual culprit, | this may be just recently un-hidden issue in linear regs allocator on | i386! | | Thanks! | Karel | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 26 19:31:53 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 19:31:53 +0000 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EDC76@DB3PRD3001MB020.064d.mgd.msft.net> After your reversion, I can build again. Thanks! From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 26 June 2014 13:51 To: Simon Peyton Jones Cc: Karel Gardas; ghc-devs Subject: Re: Two days old build breakage on i386. I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed this morning) which is fine. You should be in a good state now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones > wrote: git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 [master f958079] Revert "Add more primops for atomic ops on byte arrays" 23 files changed, 86 insertions(+), 1016 deletions(-) rewrite compiler/nativeGen/CPrim.hs (62%) delete mode 100644 libraries/ghc-prim/cbits/atomic.c delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 HEAD $ What now? Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 26 June 2014 13:25 To: Simon Peyton Jones Cc: Karel Gardas; ghc-devs Subject: Re: Two days old build breakage on i386. Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > wrote: Aaaargh! Once again the Windows build is broken. I am utterly stalled. Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the fix to X and Y. Please can someone bisect to find out which patch is the culprit? I wish we had a more systematic way to find this out. I hate being the main person who gets stuck because some unrelated change has broken the Windows build. (Thanks for Karel, who got to it a day before me.) Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel | Gardas | Sent: 26 June 2014 09:56 | To: ghc-devs; Johan Tibell | Subject: Two days old build breakage on i386. | | | Hello, | | builders running on i386 building for this platform caught issue which | shows as a build breakage: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140624 for i386-unknown-linux): | RegAllocLinear.allocRegsAndSpill: no spill candidates | allocating vreg: VirtualRegI n1Q6 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] | freeRegs: FreeRegs 4282318848 | initFreeRegs: FreeRegs 4282318861 | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | make[1]: *** | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 | libraries/ghc-prim/ghc.mk:4: recipe for target | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed | | Have a look for example on linux-i386 buildot log here: | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html | | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so | it's OS independent and probably 32bit/i386 platform specific and it's | two days old breakage now. The last two night builds fail on all | mentioned buildbots. I'm not sure but perhaps: | | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 | Author: Johan Tibell > | Date: Mon Jun 9 11:43:21 2014 +0200 | | triggers that issue? I'm not claiming that the commit is actual culprit, | this may be just recently un-hidden issue in linear regs allocator on | i386! | | Thanks! | Karel | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jun 26 19:31:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Jun 2014 19:31:49 +0000 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87y4wjon61.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF103ED38A@DB3PRD3001MB020.064d.mgd.msft.net> <87y4wjon61.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EDC16@DB3PRD3001MB020.064d.mgd.msft.net> | > - if I have a tree with a bunch of as-yet-unpushed commits, what do I | > do? | | If you have as-yet-unpushed commits in ghc.git, there shouldn't be | anything special to handle. Or were you referring to the case of having | unpushed commits in the converted sub-repos? I meant mainly in ghc.git, so what you say is reassuring. Thank you! Simon From ggreif at gmail.com Thu Jun 26 22:33:20 2014 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 27 Jun 2014 00:33:20 +0200 Subject: TypeLits question, how to build a Type Application with Symbol index Message-ID: Hello devs, I have {{{ data D (n :: Symbol) }}} in my module, and I want to obtain a type {{{ D "YAY!" }}} programmatically. Where can I find code that performs this (or something similar)? 1) I have to look up |D| in the current TyEnv (what if it is in a specific module?), 2) I have to build the type index (of kind Symbol), this involves FastString, looks non-trivial, 3) Apply 1) on 2), this is easy. Any hints welcome! Thanks and cheers, Gabor PS: some morsels I have so far: for 1) compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit "GHC.Generics") From simonpj at microsoft.com Fri Jun 27 09:22:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 27 Jun 2014 09:22:05 +0000 Subject: Haskell on windows 7 installation instructions In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EEBA4@DB3PRD3001MB020.064d.mgd.msft.net> Very helpful Artella. Your page is about *using* Haskell or GHC on Windows. That is usefully distinct from how to *build* GHC on Windows; there is a separate page on the Trac wiki about that. I?ve added a clarifying sentence to your page, and added links from each to the other. I?m cc?ing a few others who have Windows knowledge. I would love it if you guys formed a GHC-on-Windows Task Force, who tried to make sure that the Windows experience was always good. At the moment we have lots of Windows users but very few who are willing to help make it work, the recipients of this email being honourable exceptions. Simon From: Artella Coding [mailto:artella.coding at googlemail.com] Sent: 25 June 2014 11:54 To: Simon Peyton Jones Subject: Haskell on windows 7 installation instructions Hi, I saw the installation instructions in http://www.gundersen.net/haskell-on-windows/ which cover installing in windows with msys (you suggested to the author that he put the instructions up on haskellwiki). However I wanted to install with the newer msys2 (which allows copying and pasting) and had quite a few problems initially (especially when trying to build hoogle). I have worked out all the issues, and have taken the liberty of writing the instructions at : http://www.haskell.org/haskellwiki/Windows which might require further editing. It took me a whole week to sort this out and thought it might be of help to others. I found that if you don't define the MSYSTEM environment variable (if you use the "msys2_shell.bat" instead of the "mingw32_shell.bat" or "mingw64_shell.bat" then this environment variable is not defined), then when you build hoogle you get some strange linker error messages https://github.com/haskell/cabal/issues/1950 . I didnt want to make the instructions too long, so omitted any explanation of why this environment variable is needed. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Fri Jun 27 09:51:24 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 27 Jun 2014 11:51:24 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code Message-ID: Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with "notes", which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: - Programmers comment code they think is "complex enough to warrant a comment". The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. - Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. *Proposal: *I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong "broken window" effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. *First example* In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was "what does RUR stand for?" Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean "read" in the enclosing function and "updating" is related to "reading" so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting platform) src That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. *Second example* In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: -- | Returns which registers are read and written by this -- instruction, as a (read, written) pair. This info is used -- by the register allocator. x86_regUsageOfInstr :: Platform -> Instr -> RegUsage The reason mentioning that the return value is essentially a (read, written) pair is helpful is because the body of the function a big case statement full of lines like this one: GCMP _ src1 src2 -> mkRUR [src1,src2] ... FDIV _ src dst -> usageRM src dst It's not immediately clear that all the various helper functions used here just end up computing a pair of the above form. A top-level comment lets you understand what's going on without understanding exactly what all these helper functions are doing. Thoughts? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jun 27 10:17:53 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 27 Jun 2014 10:17:53 +0000 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> I?d be OK with this, (it?s a bit like requiring signatures on all top level functions) but I don?t know how we?d enforce it. Do you think the requirement should be for all top-level functions or just exported ones? I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won?t be able to make much sense of it. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 27 June 2014 10:51 To: ghc-devs at haskell.org Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with "notes", which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: * Programmers comment code they think is "complex enough to warrant a comment". The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. * Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. Proposal: I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong "broken window" effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. First example In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was "what does RUR stand for?" Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean "read" in the enclosing function and "updating" is related to "reading" so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting platform) src That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. Second example In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: -- | Returns which registers are read and written by this -- instruction, as a (read, written) pair. This info is used -- by the register allocator. x86_regUsageOfInstr :: Platform -> Instr -> RegUsage The reason mentioning that the return value is essentially a (read, written) pair is helpful is because the body of the function a big case statement full of lines like this one: GCMP _ src1 src2 -> mkRUR [src1,src2] ... FDIV _ src dst -> usageRM src dst It's not immediately clear that all the various helper functions used here just end up computing a pair of the above form. A top-level comment lets you understand what's going on without understanding exactly what all these helper functions are doing. Thoughts? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Jun 27 11:14:08 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 27 Jun 2014 12:14:08 +0100 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53AD5200.4020505@gmail.com> The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required <= 2. Really we ought to have 4 usable regs, but for that to happen we need to change the calling convention and swap R1 with Sp, but we can't easily do that because it needs a change in LLVM too (sigh). Cheers, Simon On 26/06/2014 19:39, Johan Tibell wrote: > Here's some more debug output. Can someone interpret it: > > genRaInsn > cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4) > r_dying = [%vI_n1nD, %vI_n1nE, %vI_n1nF] > w_dying = [] > virt_read = [%vI_n1nD, %vI_n1nE, %vI_n1nF] > virt_written = [] > freeregs = FreeRegs 4282318848 > assig = [n1nD :-> InMem 0, > n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg > (RealRegSingle 3)] > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140626 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1nD > assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle > 2)),(n1nF,InReg (RealRegSingle 3))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > (i.e. it's the cmpxchg instruction which is causing the failure.) > > > On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell > wrote: > > I'm trying to understand the output from the register allocator: > > (GHC version 7.9.20140626 for i386-unknown-linux): > RegAllocLinear.allocRegsAndSpill: no spill candidates > > allocating vreg: VirtualRegI n1nD > assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle > 2)),(n1nF,InReg (RealRegSingle 3))] > freeRegs: FreeRegs 4282318848 > initFreeRegs: FreeRegs 4282318861 > > Without understanding exactly what's wrong, the message above > suggests that we're trying to allocate a reg for n1nD, but there's > already an assignment for that virtual reg, is that right? > > > > On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell > > wrote: > > Herbert pushed my revert for me a minute ago. Everyone should be > good once they sync. > > > On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell > > wrote: > > I guess you don't have > 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed > this morning) which is fine. You should be in a good state > now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. > > > On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones > > wrote: > > git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 ____ > > [master f958079] Revert "Add more primops for atomic ops > on byte arrays"____ > > 23 files changed, 86 insertions(+), 1016 deletions(-)____ > > rewrite compiler/nativeGen/CPrim.hs (62%)____ > > delete mode 100644 libraries/ghc-prim/cbits/atomic.c____ > > delete mode 100644 > testsuite/tests/concurrent/should_run/AtomicPrimops.hs____ > > delete mode 100644 > testsuite/tests/concurrent/should_run/AtomicPrimops.stdout____ > > HEAD $ git revert > 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 ____ > > fatal: bad object > 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177____ > > HEAD $____ > > What now?____ > > Simon____ > > __ __ > > *From:*Johan Tibell [mailto:johan.tibell at gmail.com > ] > *Sent:* 26 June 2014 13:25 > *To:* Simon Peyton Jones > *Cc:* Karel Gardas; ghc-devs > *Subject:* Re: Two days old build breakage on i386.____ > > __ __ > > Just to make sure this is the same breakage, are you on > an i386 Windows machine? If so git > revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get > unstuck.____ > > __ __ > > On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones > > > wrote:____ > > Aaaargh! Once again the Windows build is broken. I > am utterly stalled. > > Moreover -fregs-graph and -fregs-iterative now > *silently* do nothing. At least they should elicit > warnings saying that they are disabled pending the > fix to X and Y. > > Please can someone bisect to find out which patch is > the culprit? > > I wish we had a more systematic way to find this > out. I hate being the main person who gets stuck > because some unrelated change has broken the Windows > build. (Thanks for Karel, who got to it a day > before me.) > > Thanks > > Simon____ > > > | -----Original Message----- > | From: ghc-devs > [mailto:ghc-devs-bounces at haskell.org > ] On Behalf Of > Karel > | Gardas > | Sent: 26 June 2014 09:56 > | To: ghc-devs; Johan Tibell > | Subject: Two days old build breakage on i386. > | > | > | Hello, > | > | builders running on i386 building for this > platform caught issue which > | shows as a build breakage: > | > | ghc-stage1: panic! (the 'impossible' happened) > | (GHC version 7.9.20140624 for i386-unknown-linux): > | RegAllocLinear.allocRegsAndSpill: no spill candidates > | allocating vreg: VirtualRegI n1Q6 > | assignment: [(c1PV,InMem 2),(n1Q5,InBoth > (RealRegSingle 3) > | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg > (RealRegSingle 2))] > | freeRegs: FreeRegs 4282318848 > | initFreeRegs: FreeRegs 4282318861 > | Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > | make[1]: *** > | > [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] > Error 1 > | libraries/ghc-prim/ghc.mk:4 : > recipe for target > | > 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' > failed > | > | Have a look for example on linux-i386 buildot log > here: > | > http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html > | > | Anyway, this happens on Linux, FreeBSD and Solaris > buildbots on i386 so > | it's OS independent and probably 32bit/i386 > platform specific and it's > | two days old breakage now. The last two night > builds fail on all > | mentioned buildbots. I'm not sure but perhaps: > | > | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 > | Author: Johan Tibell > > | Date: Mon Jun 9 11:43:21 2014 +0200 > | > | triggers that issue? I'm not claiming that the > commit is actual culprit, > | this may be just recently un-hidden issue in > linear regs allocator on > | i386! > | > | Thanks! > | Karel____ > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs____ > > __ __ > > > > > From johan.tibell at gmail.com Fri Jun 27 11:19:48 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 27 Jun 2014 13:19:48 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones wrote: > I?d be OK with this, (it?s a bit like requiring signatures on all top level functions) but I don?t know how we?d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. > Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). > I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won?t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. -- Johan From johan.tibell at gmail.com Fri Jun 27 11:23:31 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 27 Jun 2014 13:23:31 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <53AD5200.4020505@gmail.com> References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> <53AD5200.4020505@gmail.com> Message-ID: On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow wrote: > The problem is that this instruction requires three separate registers, but > cmpxchgl already reads and writes %eax leaving only two free registers (%ecx > and %edx). > > You'll need to arrange to not use the complicated addressing modes with > cmpxchg on i386, and keep the number of free regs required <= 2. Where's the best place to arrange for that? If I switch from using getAmode to computing the address into a temp register in StgCmmPrim will that ensure that the address is simple, or could some optimization replace my temp register computation with a complex address again? From marlowsd at gmail.com Fri Jun 27 11:27:50 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 27 Jun 2014 12:27:50 +0100 Subject: Two days old build breakage on i386. In-Reply-To: References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> <53AD5200.4020505@gmail.com> Message-ID: <53AD5536.5010901@gmail.com> On 27/06/2014 12:23, Johan Tibell wrote: > On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow wrote: >> The problem is that this instruction requires three separate registers, but >> cmpxchgl already reads and writes %eax leaving only two free registers (%ecx >> and %edx). >> >> You'll need to arrange to not use the complicated addressing modes with >> cmpxchg on i386, and keep the number of free regs required <= 2. > > Where's the best place to arrange for that? If I switch from using > getAmode to computing the address into a temp register in StgCmmPrim > will that ensure that the address is simple, or could some > optimization replace my temp register computation with a complex > address again? There aren't any optimisations that happen on the instructions after codegen, and if there were, they would have to respect the same rule. So using a register is the right thing, yes. Cheers, Simon From dsf at seereason.com Fri Jun 27 13:26:56 2014 From: dsf at seereason.com (David Fox) Date: Fri, 27 Jun 2014 06:26:56 -0700 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. On Fri, Jun 27, 2014 at 4:19 AM, Johan Tibell wrote: > On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones > wrote: > > I?d be OK with this, (it?s a bit like requiring signatures on all top > level functions) but I don?t know how we?d enforce it. > > I think social enforcement is enough. If we agree that this is > something we want to do and communicate that to ghc-devs@, put a note > in our style guide, and kindly remind people to add comments when we > do code reviews, we'll eventually end up with a culture of writing > Haddocks. > > I think the most important part right now is that current contributors > agree that this is something we want to do. > > Aside: people usually say that they find it hard to know what to > document in their own code, because they don't know what others will > find difficult. My advice is this: add a sentence or two about what > the function does and why it exists, no matter how obvious you think > that statement is. > > > Do you think the requirement should be for all top-level functions or > just exported ones? > > I take what I can get, but I think documenting all top-level functions > makes sense in the case of GHC, as there's so much that goes on in our > modules but we often only export a handful of functions. For example, > compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 > functions. For someone that wants to work on that module for the first > time only have docs on those three functions is helpful, but likely > not enough. FWIW I document all top-level functions in my projects > (and when I don't I often regret it later). > > > I agree that Notes have a different purpose. But it should be OK style > to refer to a Note from a top-level function comment, even though Haddock > won?t be able to make much sense of it. > > Sure. Personally I would refer to the note from the function body if > it talks mostly about the implementation, as opposed to how to use the > function. > > -- Johan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Fri Jun 27 15:49:05 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 27 Jun 2014 17:49:05 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53AD9271.9020201@fuuzetsu.co.uk> On 06/27/2014 01:19 PM, Johan Tibell wrote: > On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones > wrote: >> I?d be OK with this, (it?s a bit like requiring signatures on all top level functions) but I don?t know how we?d enforce it. > > I think social enforcement is enough. If we agree that this is > something we want to do and communicate that to ghc-devs@, put a note > in our style guide, and kindly remind people to add comments when we > do code reviews, we'll eventually end up with a culture of writing > Haddocks. > > I think the most important part right now is that current contributors > agree that this is something we want to do. > > Aside: people usually say that they find it hard to know what to > document in their own code, because they don't know what others will > find difficult. My advice is this: add a sentence or two about what > the function does and why it exists, no matter how obvious you think > that statement is. > >> Do you think the requirement should be for all top-level functions or just exported ones? > > I take what I can get, but I think documenting all top-level functions > makes sense in the case of GHC, as there's so much that goes on in our > modules but we often only export a handful of functions. For example, > compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 > functions. For someone that wants to work on that module for the first > time only have docs on those three functions is helpful, but likely > not enough. FWIW I document all top-level functions in my projects > (and when I don't I often regret it later). > >> I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won?t be able to make much sense of it. > > Sure. Personally I would refer to the note from the function body if > it talks mostly about the implementation, as opposed to how to use the > function. Notes could be moved into the module header if necessary so that they are rendered by Haddock. Alternatively, one function can contain the note and other places can refer to it by means of an anchor. > -- Johan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > My personal gripe of trying to read docs for GHC modules/types is that some older modules are in .lhs format which means we have to dive out of nicely-rendered HTML and go into source. Was there ever talk of converting Literate Haskell files into more Haddock-friendly format? -- Mateusz K. From mail at joachim-breitner.de Fri Jun 27 16:00:00 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 27 Jun 2014 09:00:00 -0700 Subject: Make -fno-write-interface to all modes of GHC, not just -fno-code. Message-ID: <1403884800.2324.1.camel@kirk> Hi, it seems that commit 05120ecd95b2ebf9b096a95304793cd78be9506e Author: Edward Z. Yang Date: Fri Jun 27 13:48:19 2014 +0100 Make -fno-write-interface to all modes of GHC, not just -fno-code. Signed-off-by: Edward Z. Yang broke stuff: libraries/base/GHC/IO.hs-boot:6:1: Failed to load interface for ???GHC.Types??? There are files missing in the ???ghc-prim??? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/ghc-prim/GHC/Classes.hs:24:1: Failed to load interface for ???GHC.Magic??? It is a member of the hidden package ???ghc-prim???. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:26:1: Failed to load interface for ???GHC.Tuple??? It is a member of the hidden package ???ghc-prim???. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:27:1: Failed to load interface for ???GHC.Types??? It is a member of the hidden package ???ghc-prim???. Use -v to see a list of the files searched for. make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Classes.o] Error 1 (https://s3.amazonaws.com/archive.travis-ci.org/jobs/28588528/log.txt) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From howard_b_golden at yahoo.com Fri Jun 27 16:07:44 2014 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Fri, 27 Jun 2014 09:07:44 -0700 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1403885264.46421.YahooMailNeo@web120804.mail.ne1.yahoo.com> I don't think this is mutually exclusive with Johan's proposal. Let me suggest an amendment: Developers (both new and old) would be encouraged to submit patches adding or improving documentation in the source code. Documentation patches would be vetted as any others would be. Discouraging source code comments is the worst legacy of Unix. IMO (contradicting K&R) even incorrect comments are better than none. Howard ________________________________ From: David Fox To: Johan Tibell Cc: "ghc-devs at haskell.org" Sent: Friday, June 27, 2014 6:26 AM Subject: Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) ?This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. From ggreif at gmail.com Fri Jun 27 16:50:33 2014 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 27 Jun 2014 18:50:33 +0200 Subject: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index Message-ID: I succeeded to solve all of them :-) But now I am blocked on on a panic "not in scope during type checking, but it passed the renamer". I suspect that while "deriving Generic" some instances are defined in some empty TcEnv, which does not contain my definition in context. Is there a way to inject some type constructor into the TcEnv? Thanks, Gabor On 6/27/14, Gabor Greif wrote: > Hello devs, > > I have > > {{{ > data D (n :: Symbol) > }}} > > in my module, and I want to obtain a type > > {{{ > D "YAY!" > }}} > > programmatically. Where can I find code that performs this (or > something similar)? > > 1) I have to look up |D| in the current TyEnv (what if it is in a > specific module?), > 2) I have to build the type index (of kind Symbol), this involves > FastString, looks non-trivial, > 3) Apply 1) on 2), this is easy. > > Any hints welcome! > > Thanks and cheers, > > Gabor > > > PS: some morsels I have so far: > > for 1) > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit > "GHC.Generics") > From fuuzetsu at fuuzetsu.co.uk Fri Jun 27 18:11:01 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 27 Jun 2014 20:11:01 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <53ADB3B5.6060406@fuuzetsu.co.uk> On 06/27/2014 03:26 PM, David Fox wrote: > I would counter propose a place on hackage for people to type in or modify > the documentation for functions, designed in such a way that the > documentation would easily find its way back into the project's source code > (with developer approval.) This way the documentation can be generated by > people who only recently came to understand the function, so the questions > a newcomer has are fresh in their mind. > Are you asking for a wiki-like thing for documentation? There were a few times where this has been proposed such as https://github.com/haskell/haddock/issues/72 but in general it turns out that there's not enough interest for anyone to sit down and implement it and make sure it all works properly. Patches should be going straight to upstream rather than lingering on Hackage until someone notices them (even with automated tools, it's a pain). I doubt many people would use it for anything but typos because if you have enough knowledge about a function to document it, you're likely to already be involved with the project in some way and have means to report it properly. > > On Fri, Jun 27, 2014 at 4:19 AM, Johan Tibell > wrote: > >> On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones >> wrote: >>> I?d be OK with this, (it?s a bit like requiring signatures on all top >> level functions) but I don?t know how we?d enforce it. >> >> I think social enforcement is enough. If we agree that this is >> something we want to do and communicate that to ghc-devs@, put a note >> in our style guide, and kindly remind people to add comments when we >> do code reviews, we'll eventually end up with a culture of writing >> Haddocks. >> >> I think the most important part right now is that current contributors >> agree that this is something we want to do. >> >> Aside: people usually say that they find it hard to know what to >> document in their own code, because they don't know what others will >> find difficult. My advice is this: add a sentence or two about what >> the function does and why it exists, no matter how obvious you think >> that statement is. >> >>> Do you think the requirement should be for all top-level functions or >> just exported ones? >> >> I take what I can get, but I think documenting all top-level functions >> makes sense in the case of GHC, as there's so much that goes on in our >> modules but we often only export a handful of functions. For example, >> compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 >> functions. For someone that wants to work on that module for the first >> time only have docs on those three functions is helpful, but likely >> not enough. FWIW I document all top-level functions in my projects >> (and when I don't I often regret it later). >> >>> I agree that Notes have a different purpose. But it should be OK style >> to refer to a Note from a top-level function comment, even though Haddock >> won?t be able to make much sense of it. >> >> Sure. Personally I would refer to the note from the function body if >> it talks mostly about the implementation, as opposed to how to use the >> function. >> >> -- Johan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Mateusz K. From iavor.diatchki at gmail.com Fri Jun 27 21:56:01 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 27 Jun 2014 14:56:01 -0700 Subject: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: References: Message-ID: Hello, I am a bit unclear on what you mean by "programatically": do you mean from within GHC or is that using something like Template Haskell? -Iavor On Thu, Jun 26, 2014 at 3:33 PM, Gabor Greif wrote: > Hello devs, > > I have > > {{{ > data D (n :: Symbol) > }}} > > in my module, and I want to obtain a type > > {{{ > D "YAY!" > }}} > > programmatically. Where can I find code that performs this (or > something similar)? > > 1) I have to look up |D| in the current TyEnv (what if it is in a > specific module?), > 2) I have to build the type index (of kind Symbol), this involves > FastString, looks non-trivial, > 3) Apply 1) on 2), this is easy. > > Any hints welcome! > > Thanks and cheers, > > Gabor > > > PS: some morsels I have so far: > > for 1) > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit > "GHC.Generics") > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Sat Jun 28 05:48:16 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat, 28 Jun 2014 15:48:16 +1000 Subject: Cabal for GHC 7.8 Message-ID: I noticed that the Cabal package doesn?t have a branch for ghc-7.8: http://git.haskell.org/packages/Cabal.git Is that intended? Maybe as a result the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources to check out a branch from the *GitHub mirror repos* doesn?t work either. It fails with == running git submodule update Cloning into 'libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name Email support at github.com for help Clone of 'git at github.com:ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed git failed: 256 at ./sync-all line 122. Manuel From johan.tibell at gmail.com Sat Jun 28 05:56:10 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat, 28 Jun 2014 07:56:10 +0200 Subject: Cabal for GHC 7.8 In-Reply-To: References: Message-ID: We could create a branch for 7.8, but I don't know which commit to branch of. If someone can figure out which cabal 7.8 shipped with we can add the branch. On Sat, Jun 28, 2014 at 7:48 AM, Manuel M T Chakravarty < chak at cse.unsw.edu.au> wrote: > I noticed that the Cabal package doesn?t have a branch for ghc-7.8: > > http://git.haskell.org/packages/Cabal.git > > Is that intended? Maybe as a result the instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources > > to check out a branch from the *GitHub mirror repos* doesn?t work either. > It fails with > > == running git submodule update > Cloning into 'libraries/Cabal'... > fatal: remote error: > ghc/packages/Cabal is not a valid repository name > Email support at github.com for help > Clone of 'git at github.com:ghc/packages/Cabal.git' into submodule path > 'libraries/Cabal' failed > git failed: 256 at ./sync-all line 122. > > Manuel > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sat Jun 28 06:46:41 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 28 Jun 2014 08:46:41 +0200 Subject: Cabal for GHC 7.8 In-Reply-To: (Manuel M. T. Chakravarty's message of "Sat, 28 Jun 2014 15:48:16 +1000") References: Message-ID: <874mz5y1im.fsf@gmail.com> On 2014-06-28 at 07:48:16 +0200, Manuel M T Chakravarty wrote: > I noticed that the Cabal package doesn?t have a branch for ghc-7.8: > > http://git.haskell.org/packages/Cabal.git > > Is that intended? A ghc-7.8 branch is not really needed, as Cabal is registered as submodule in ghc.git's ghc-7.8 branch. It's just sync-all that > Maybe as a result the instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources > > to check out a branch from the *GitHub mirror repos* doesn?t work > either. For cloning via the GitHub-mirror[1] I'd recommend using the scheme as described in [2]. That is, set up url-rewrites (that take also into account the 'packages/foo' -> 'packages-foo' rewriting): git config --global url."git://github.com/ghc/".insteadOf git://git.haskell.org/ git config --global url."git://github.com/ghc/packages-".insteadOf git://git.haskell.org/packages/ and then clone as if you would from git://git.haskell.org git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-7.8 cd ghc-7.8 ./sync-all get -b ghc-7.8 all network access will be redirected to github.com instead. [1]: Btw, why do you want to use the github mirror instead of git://git.haskell.org? [2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingtheGitHubGHCMirror From ggreif at gmail.com Sat Jun 28 08:10:34 2014 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 28 Jun 2014 10:10:34 +0200 Subject: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: References: Message-ID: On 6/27/14, Iavor Diatchki wrote: > Hello, > > I am a bit unclear on what you mean by "programatically": do you mean from > within GHC or is that using something like Template Haskell? Not TH, just the compiler/typecheck APIs. But the problem is mostly solved already. N.B. I am in the process of extending the generic-deriving mechanism to make it amenable to techniques like propositional equality testing and type-level reasoning. Cheers and thanks, Gabor > > -Iavor > > > On Thu, Jun 26, 2014 at 3:33 PM, Gabor Greif wrote: > >> Hello devs, >> >> I have >> >> {{{ >> data D (n :: Symbol) >> }}} >> >> in my module, and I want to obtain a type >> >> {{{ >> D "YAY!" >> }}} >> >> programmatically. Where can I find code that performs this (or >> something similar)? >> >> 1) I have to look up |D| in the current TyEnv (what if it is in a >> specific module?), >> 2) I have to build the type index (of kind Symbol), this involves >> FastString, looks non-trivial, >> 3) Apply 1) on 2), this is easy. >> >> Any hints welcome! >> >> Thanks and cheers, >> >> Gabor >> >> >> PS: some morsels I have so far: >> >> for 1) >> compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit >> "GHC.Generics") >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > From chak at cse.unsw.edu.au Sat Jun 28 10:34:59 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat, 28 Jun 2014 20:34:59 +1000 Subject: Cabal for GHC 7.8 In-Reply-To: <874mz5y1im.fsf@gmail.com> References: <874mz5y1im.fsf@gmail.com> Message-ID: <2D54C55F-F43E-42D4-A1A7-E68C6E3C0312@cse.unsw.edu.au> Thanks, Herbert. I eventually noticed that it the Cabal repo is a submodule, but I wasn?t aware of the Git?s support to rewrite URLs. To answer your questions: cloning from GitHub is useful as I can fork the repos on GitHub. At haskell.org, I need to use branches, which I don?t like. Manuel Herbert Valerio Riedel : > On 2014-06-28 at 07:48:16 +0200, Manuel M T Chakravarty wrote: >> I noticed that the Cabal package doesn?t have a branch for ghc-7.8: >> >> http://git.haskell.org/packages/Cabal.git >> >> Is that intended? > > A ghc-7.8 branch is not really needed, as Cabal is registered as > submodule in ghc.git's ghc-7.8 branch. It's just sync-all that > >> Maybe as a result the instructions at >> >> https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources >> >> to check out a branch from the *GitHub mirror repos* doesn?t work >> either. > > For cloning via the GitHub-mirror[1] I'd recommend using the scheme as > described in [2]. That is, set up url-rewrites (that take also into > account the 'packages/foo' -> 'packages-foo' rewriting): > > git config --global url."git://github.com/ghc/".insteadOf git://git.haskell.org/ > git config --global url."git://github.com/ghc/packages-".insteadOf git://git.haskell.org/packages/ > > and then clone as if you would from git://git.haskell.org > > git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-7.8 > cd ghc-7.8 > ./sync-all get -b ghc-7.8 > > all network access will be redirected to github.com instead. > > > [1]: Btw, why do you want to use the github mirror instead of git://git.haskell.org? > > [2]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingtheGitHubGHCMirror > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From ggreif at gmail.com Sat Jun 28 11:49:15 2014 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 28 Jun 2014 13:49:15 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87egydv0kx.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> Message-ID: Hi herbert, I followed your instructions, and one of my repos converted well: e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm (stm-2.4.3-release-3-ge8a901f) the other gave: -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm How can I salvage the situation? Thanks, Gabor On 6/25/14, Herbert Valerio Riedel wrote: > > It's done! > > After pulling the latest ghc.git commit (and assuming you have made sure > you have no unpushed data laying around in the repos listed below) > you'll have to either run > > - git submodule update --init > > *or* > > - ./sync-all get > > (a mere "./sync-all pull" will just call "git submodule update" w/o > the "--init" option) > > > After that, a 'git submodule status' (for ghc.git @ db19c665e) should look > like > > [snip] From hvriedel at gmail.com Sat Jun 28 12:10:26 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 28 Jun 2014 14:10:26 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: (Gabor Greif's message of "Sat, 28 Jun 2014 13:49:15 +0200") References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> Message-ID: <87r429w7yl.fsf@gmail.com> On 2014-06-28 at 13:49:15 +0200, Gabor Greif wrote: > Hi herbert, > > I followed your instructions, and one of my repos converted well: > > e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm > (stm-2.4.3-release-3-ge8a901f) > > the other gave: > > -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm > > How can I salvage the situation? That (the '-'-sign) simply means the 'libraries/stm' submodule wasn't properly initalized; running 'git submodule update --init' should usually take care of initializing newly added submodules. From ggreif at gmail.com Sat Jun 28 12:19:15 2014 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 28 Jun 2014 14:19:15 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87r429w7yl.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> <87r429w7yl.fsf@gmail.com> Message-ID: Hmm, I guess this was the reason, when I did that, I got > fatal: Needed a single revision > Unable to find current revision in submodule path 'libraries/parallel' so the other submodules were not initialized. What might be wrong with 'libraries/parallel' ? Thanks, Gabor On 6/28/14, Herbert Valerio Riedel wrote: > On 2014-06-28 at 13:49:15 +0200, Gabor Greif wrote: >> Hi herbert, >> >> I followed your instructions, and one of my repos converted well: >> >> e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm >> (stm-2.4.3-release-3-ge8a901f) >> >> the other gave: >> >> -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm >> >> How can I salvage the situation? > > That (the '-'-sign) simply means the 'libraries/stm' submodule wasn't > properly initalized; > > running 'git submodule update --init' should usually take care of > initializing newly added submodules. > From hvriedel at gmail.com Sat Jun 28 12:32:49 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 28 Jun 2014 14:32:49 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: (Gabor Greif's message of "Sat, 28 Jun 2014 14:19:15 +0200") References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> <87r429w7yl.fsf@gmail.com> Message-ID: <87k381w6xa.fsf@gmail.com> On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote: > Hmm, I guess this was the reason, > when I did that, I got > >> fatal: Needed a single revision >> Unable to find current revision in submodule path 'libraries/parallel' > > so the other submodules were not initialized. > > What might be wrong with 'libraries/parallel' ? Tbh, not sure, but if you know you have nothing important in libraries/parallel, rm -rf libraries/parallel and retry a 'git submodule update --init' This is essentially the suggested course of action according to http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.html#x22-10400014.1.4 and other results you may get if you google for that error > > Thanks, > > Gabor > > On 6/28/14, Herbert Valerio Riedel wrote: >> On 2014-06-28 at 13:49:15 +0200, Gabor Greif wrote: >>> Hi herbert, >>> >>> I followed your instructions, and one of my repos converted well: >>> >>> e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm >>> (stm-2.4.3-release-3-ge8a901f) >>> >>> the other gave: >>> >>> -e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm >>> >>> How can I salvage the situation? >> >> That (the '-'-sign) simply means the 'libraries/stm' submodule wasn't >> properly initalized; >> >> running 'git submodule update --init' should usually take care of >> initializing newly added submodules. >> -- "Elegance is not optional" -- Richard O'Keefe From ggreif at gmail.com Sat Jun 28 12:51:40 2014 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 28 Jun 2014 14:51:40 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: <87k381w6xa.fsf@gmail.com> References: <87ionpv3bb.fsf@gmail.com> <87egydv0kx.fsf@gmail.com> <87r429w7yl.fsf@gmail.com> <87k381w6xa.fsf@gmail.com> Message-ID: On 6/28/14, Herbert Valerio Riedel wrote: > On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote: >> Hmm, I guess this was the reason, >> when I did that, I got >> >>> fatal: Needed a single revision >>> Unable to find current revision in submodule path 'libraries/parallel' >> >> so the other submodules were not initialized. >> >> What might be wrong with 'libraries/parallel' ? > > Tbh, not sure, but if you know you have nothing important in > libraries/parallel, > > rm -rf libraries/parallel > > and retry a 'git submodule update --init' > > This is essentially the suggested course of action according to > > > http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.html#x22-10400014.1.4 > > and other results you may get if you google for that error Great, that helped! Cheers, Gabor > > > From ggreif at gmail.com Sat Jun 28 14:21:44 2014 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 28 Jun 2014 16:21:44 +0200 Subject: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: References: Message-ID: For the record, I have started branch 'wip/generics-propeq' and documented it here: https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches Cheers, Gabor On 6/28/14, Gabor Greif wrote: > On 6/27/14, Iavor Diatchki wrote: >> Hello, >> >> I am a bit unclear on what you mean by "programatically": do you mean >> from >> within GHC or is that using something like Template Haskell? > > Not TH, just the compiler/typecheck APIs. But the problem is mostly > solved already. N.B. I am in the process of extending the > generic-deriving mechanism to make it amenable to techniques like > propositional equality testing and type-level reasoning. > > Cheers and thanks, > > Gabor > >> >> -Iavor >> >> >> On Thu, Jun 26, 2014 at 3:33 PM, Gabor Greif wrote: >> >>> Hello devs, >>> >>> I have >>> >>> {{{ >>> data D (n :: Symbol) >>> }}} >>> >>> in my module, and I want to obtain a type >>> >>> {{{ >>> D "YAY!" >>> }}} >>> >>> programmatically. Where can I find code that performs this (or >>> something similar)? >>> >>> 1) I have to look up |D| in the current TyEnv (what if it is in a >>> specific module?), >>> 2) I have to build the type index (of kind Symbol), this involves >>> FastString, looks non-trivial, >>> 3) Apply 1) on 2), this is easy. >>> >>> Any hints welcome! >>> >>> Thanks and cheers, >>> >>> Gabor >>> >>> >>> PS: some morsels I have so far: >>> >>> for 1) >>> compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit >>> "GHC.Generics") >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> > From mark.lentczner at gmail.com Sat Jun 28 15:31:41 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Jun 2014 08:31:41 -0700 Subject: cc & ld extra flags Message-ID: I'd like to build GHC, and all the base libs, with an extra flag supplied to cc (well gcc) and ld commands: I thought I could just add this to mk/build.mk: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 But this seems very inconsistently applied. For example: This part of the build of the RTS gets it: "inplace/bin/ghc-stage1" -optc-m64 -optc-fno-stack-protector *-optc-mmacosx-version-min=10.7* -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-DBE_CONSERVATIVE -optc-DDTRACE -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Hash.c -o rts/dist/build/Hash.o But this part doesn't: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.1 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.2.20140623 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Utf8.hs -o utils/haddock/dist/build/Haddock/Utf8.dyn_o I think it might have to do with the dyn_o and thr_o targets? So - Is there a better way to ensure these flags are applied? I suppose I could wrap gcc (clang) and ld.... but that seems ham-handed. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From slyich at gmail.com Sat Jun 28 19:42:04 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Sat, 28 Jun 2014 22:42:04 +0300 Subject: cc & ld extra flags In-Reply-To: References: Message-ID: <20140628224204.6b22827f@sf> On Sat, 28 Jun 2014 08:31:41 -0700 Mark Lentczner wrote: > I'd like to build GHC, and all the base libs, with an extra flag supplied > to cc (well gcc) and ld commands: > > I thought I could just add this to mk/build.mk: > > SRC_CC_OPTS = -mmacos-version-min=10.7 > SRC_LD_OPTS = -mmacos-version-min=10.7 > But this seems very inconsistently applied. For example: Hi Mark! The best way to set all 3 vars: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 SRC_HC_OPTS = -optc-mmacos-version-min=10.7 -optl-mmacos-version-min=10.7 and, maybe even -optP. CC/LD_OPTS is more for non-haskell code from build system perspective. http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#forcing-options-through -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From baldurpet at gmail.com Sun Jun 29 08:00:23 2014 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Sun, 29 Jun 2014 10:00:23 +0200 Subject: New GHC feature proposal: Pattern families In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103E8C39@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yes I reported #9226 :) I created a wiki page for pattern families (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole host of examples, trying to keep them simple so do let me know it anything is unclear. In the area of pattern synonyms I agree with testing the waters a bit, personally I'd like to change the syntax since it doesn't really scale for using complicated view patterns (forcing you to define auxiliary functions) and looks a bit awkward when adding type annotations and explicitely bidirectional patterns. I'd say explicitely bidirectional patterns are the next step forward but it depends on the priorities: ? End users: Explicitely bidirectional patterns (#8581) and associated pattern synonyms (#8583) are the biggest two, although the latter can be ?faked? with type classes: If #8581/#8583 are implemented and if (:)/[] weren't built-in syntax libraries like Data.Text could be used as a drop-in replacement for String, currently users must change every pattern match to a case statement (but I digress) ? Library authors: Exhaustiveness checks (#8779) are important for getting abstract data types on par with normal data types. Since you mentioned VPA (ViewPatternsAlternative) I took the liberty of using several examples from the VPA wiki page and contrasting them with the example found there, most of the ones I did not mention (like ?join lists?) can be implemented using PatternSynonyms, I feel some of the VPA examples are better motivating examples than what I presented before. Best regards, Baldur 2014-06-29 9:40 GMT+02:00, Baldur Bl?ndal : > Yes I reported #9226 :) > > I created a wiki page for pattern families > (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole > host of examples, trying to keep them simple so do let me know it > anything is unclear. > > In the area of pattern synonyms I agree with testing the waters a bit, > personally I'd like to change the syntax since it doesn't really scale > for using complicated view patterns (forcing you to define auxiliary > functions) and looks a bit awkward when adding type annotations and > explicitely bidirectional patterns. > > I'd say explicitely bidirectional patterns are the next step forward > but it depends on the priorities: > ? End users: Explicitely bidirectional patterns (#8581) and associated > pattern synonyms (#8583) are the biggest two, although the latter can > be ?faked? with type classes: If #8581/#8583 are implemented and if > (:)/[] weren't built-in syntax libraries like Data.Text could be used > as a drop-in replacement for String, currently users must change every > pattern match to a case statement (but I digress) > ? Library authors: Exhaustiveness checks (#8779) are important for > getting abstract data types on par with normal data types. > > Since you mentioned VPA (ViewPatternsAlternative) I took the liberty > of using several examples from the VPA wiki page and contrasting them > with the example found there, most of the ones I did not mention (like > ?join lists?) can be implemented using PatternSynonyms, I feel some of > the VPA examples are better motivating examples than what I presented > before. > > Best regards, > Baldur > > 2014-06-23 17:30 GMT+02:00, Edward Kmett : >> The main thing Baldur had asked me about was if it makes sense to talk >> about patterns that are parameterized by expressions in places. >> >> I agree that the thought is very poorly fleshed out, but as a motivation, >> in some sense the previous form of view patterns already do this. >> >> Consider (->), which takes in an expression to apply on the left and a >> pattern for what to match against the result of it on the right. >> >> The question then becomes can we allow this for arbitrary patterns? >> >> There are a number of use cases for these. For example, >> >> A pattern to match a regular expression might look like >> >> Foo (x :~= "ab*") >> >> where you want "ab*" to be passed as a parameter to the code for the >> pattern synonym (:~=), not be something it is binding. >> >> This then speaks to needing some notion of mode for the different >> parameters. >> >> One of the reasons I'm under-excited about pattern synonyms is we already >> built all the machinery for working with prisms in lens to generalize >> them. >> =) >> >> In lens we have a combinator 'preview :: Prism' s a -> s -> Maybe a'. >> >> As a straw man proposal: >> >> It'd be nice to be able to do something like >> >> pattern (Match p a) <- (preview p -> Just a) >> >> and have it take the arguments that go to the left hand side of the -> as >> expressions, not patterns so that that can compile. >> >> Now, I'm somewhat dubious that it worth the pain to embellish the pattern >> language with something this complicated, but in some sense we already >> have >> a lot of the machinery to support it. e.g. IIRC we parse patterns first >> as >> expressions then convert them. >> >> -Edward >> >> >> On Mon, Jun 23, 2014 at 4:39 AM, Simon Peyton Jones >> >> wrote: >> >>> Baldur >>> >>> (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last >>> name.) >>> >>> I'm glad you are enjoying pattern synonyms. Thanks for identifying >>> #9226, >>> which I guess is you. >>> >>> I honestly don't understand your pattern family proposal. Would you >>> like >>> to write a wiki page somewhere describing the >>> syntax >>> typing (static semantics) >>> desugaring (dynamic semantics) >>> as clearly and precisely as you can, independent of prisms, and using >>> the >>> simplest possible examples to illustrate. By all means say that prisms >>> are >>> a more advanced application, and give examples to show how. But in >>> general >>> to specify a language feature you need a lot more than a couple of >>> examples! >>> >>> Then you can ask GHC users what they think. >>> >>> I have to say that I'm cautious about adding further features to pattern >>> synonyms until we've gotten more user experience with what we have. (Do >>> you think the explicitly bidirectional stuff on the wiki page is >>> important? >>> To me that seems like the first thing a user might stumble over.) >>> >>> Incidentally, I'd really like to replace view patterns with >>> https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another >>> thing that is awaiting cycles. >>> >>> Copying ghc-devs for interest >>> >>> Thanks >>> >>> Simon >>> >>> >>> >>> | -----Original Message----- >>> | From: Baldur Bl?ndal [mailto:baldurpet at gmail.com] >>> | Sent: 18 June 2014 04:31 >>> | To: Simon Peyton Jones; gergo at erdi.hu >>> | Subject: New GHC feature proposal: Pattern families >>> | >>> | Hello Peyton and Gergo, >>> | >>> | I'm a master's student at Chalmers, a minor GHC contributor and have >>> | written about the pattern synonyms extension >>> | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and >>> | included is a proposal for an extension I call ?pattern families? >>> | allowing users to create patterns parameterized by an expression. I >>> feel >>> | like patterns don't get nearly as much attention as the type system >>> and >>> | this is my attempt to balance things out :) >>> | >>> | I discussed the proposal with Edward Kmett who suggested an example >>> with >>> | prisms and that I contact you two for comments. The syntax is still in >>> | flux. >>> | >>> | Some motivating examples for your consideration. >>> | >>> | PRISM PATTERNS >>> | >>> | Edward suggested a pattern to match a prism which would look like >>> this: >>> | an example where you want it is if you want to use a pattern >>> | synonym to match a prism foo (Match _Left a) = ... >>> | [...] >>> | the example of a single pattern that can match every prism >>> | would be a nice example >>> | >>> | which would be quite easy to implement: >>> | >>> | | pattern Match prism a ? ((^? prism) ? Just a) >>> | | >>> | | bar :: Either c (Either a b) ? a >>> | | bar (Match (_Right._Left) a) = a >>> | | bar _ = error "Not a Right (Left ...)" >>> | >>> | This can be used for any prism: >>> | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" >>> | | >>> | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") >>> | (Match (nth 1) a)))) = a >>> | | ghci> foo jsonBlob >>> | | Number 0.0 >>> | >>> | and defining more specilized patterns we can make it terser: >>> | | pattern Get i a ? ((^? nth i) ? Just a) pattern Key str a ? ((^? key >>> | | str) ? Just a) >>> | | >>> | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 >>> | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :? >>> | | "someObject" :? "version" :? 1 :? a) = a >>> | where >>> | | pattern i :? a ? Get i a >>> | | pattern str :? a ? Key str a >>> | >>> | So this is excellent for pattern matching on any sort of nested >>> | structure: records, JSON, XML, HTML, ASTs, ? Since this also supports >>> | pattern matching on any value that satisfies a predicate. >>> | >>> | N+K PATTERNS >>> | Generalizing n+k patterns: We create a pattern family indexed by its >>> | first argument: >>> | >>> | | pattern (a :+) :: Num a ? a ? a >>> | | k :+ n ? (unSucc k ? Just n) -- [1] unSucc defined >>> below >>> | >>> | where (a :+) indicates that 'k' is an index of the pattern family >>> | allowing it to be supplied to the view pattern. >>> | The pattern can be used as follows: >>> | | fact 0 = 1 >>> | | fact m@(1 :+ n) = m * fact n >>> | >>> | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired >>> | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note >>> that >>> | its second argument is the index here: >>> | | pattern (:=~ String) :: RegexContext Regex a c ? a ? c >>> | | n :=~ pattern ? ((=~ pattern) ? n) >>> | >>> | Used as: >>> | | vowels :: RegexContext Regex src tgt ? src ? tgt vowels (n :=~ >>> | | "[aeiou]") = n >>> | | >>> | | ghci> vowels "honorificabilitudinitatibus" ? Int >>> | | 13 >>> | >>> | where you can of course pattern match on the resulting value: >>> | >>> | | has5Vowels :: String ? Int >>> | | has5Vowels (5 :=~ "[aeiou]") = True >>> | | has5Voewls _ = False >>> | >>> | TYPE INFERENCE >>> | Here is an example of a snippet inferring the type of an if >>> expression: >>> | >>> | | infer ? (If cond t e) = >>> | | case (infer ? cond, infer ? t, infer ? e) of >>> | | (Just TBool, Just ??, Just ??) >>> | | | ?? == ?? = Just t? >>> | >>> | Here is how it might look with pattern families: >>> | >>> | | infer ? (If (Infer ? TBool) (Infer ? ??) (Infer ? ??)) >>> | | | ?? == ?? = Just ?? >>> | >>> | (or even nicer if we use (:?) = Infer) >>> | | infer ? (If (? :? TBool) (? :? ??) (? :? ??)) ? >>> | >>> | IMPLEMENTATION >>> | From what I can see this is a relatively straight-forward translation >>> | into view patterns where a variable bound by a view pattern is an >>> | ?index? to the pattern family and unbound variables are regular >>> | patterns. In the examples above I use special syntax for the index >>> where >>> | the type is included but even without any annotation it can be >>> inferred >>> | from context. >>> | >>> | If the proposal is fine by you I offer to do the implementation work, >>> | all feedback welcome! >>> | >>> | Best regards, >>> | Baldur Bl?ndal >>> | >>> | APPENDIX >>> | | unSucc :: Int ? Int ? Maybe Int >>> | | unSucc k n >>> | | | n - k < 0 = Nothing >>> | | | otherwise = Just (n - k) >>> | | >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> > From mark.lentczner at gmail.com Sun Jun 29 22:39:02 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Jun 2014 15:39:02 -0700 Subject: cc & ld extra flags In-Reply-To: <20140628224204.6b22827f@sf> References: <20140628224204.6b22827f@sf> Message-ID: After some deep investigation (including reading the clang source), turns out the easiest way is to just set an environment variable for the duration of the GHC configure/build sequence: export MACOSX_DEPLOYMENT_TARGET=10.7 ?Will "do the right thing" in all contexts throughout the build without needing to thread command options through. I've tested this and it works. It does raise the issue of should set it as far back as 10.6? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sun Jun 29 23:13:33 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 30 Jun 2014 01:13:33 +0200 Subject: GHC 7.8.3 release In-Reply-To: References: Message-ID: <53B09D9D.9020907@fuuzetsu.co.uk> On 05/27/2014 10:06 AM, Austin Seipp wrote: > Hello all, > > After a long week, I've finally gotten a little time to reply to > emails, and I mainly have one question I'd like to ask. > > First, please direct your attention to this: > > https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority > > This is the 7.8.3 milestone, but it only considers things that are: > > - 1) Fixed > - 2) Going to be merged > - 3) Are a patch to be still merged. > > That is, it is a solid representation of the difference between 7.8.2 > and the 7.8 branch tip. > > The question is: when should we do the release? There are several bugs > there that seem quite problematic for users - #9045, #7097, #9001, > #8768 and #9078 in particular. > > If these bugs are really problematic (and I sort of feel they are) > then the release can happen soon. I can do it within a week from now, > and we could punt more to a 7.8.4 release. > > I ask this because my time to dedicate to GHC is a bit thin right now, > so you must help me decide what's important! So please let me know - > just a general vote in favor of doing it within some X timeframe (even > 'real soon' or 'a week would be great') would be nice. > > PS: I apologize for the lack of status updates and brief email - my > time for GHC has been in very short order the past two weeks in > particular, and I've finally just returned to a computer (not mine) > for right now to ask this. > > PPS: This might also impact the 7.10 schedule, but last Simon and I > talked, we thought perhaps shooting for ICFP this time (and actually > hitting it) was a good plan. So I'd estimate on that a 7.8.4 might > happen a few months from now, after summer. > It has been a month since and the general opinion seems to have been Real Soon Now, are there any big blockers? -- Mateusz K. From mark.lentczner at gmail.com Mon Jun 30 06:04:20 2014 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Jun 2014 23:04:20 -0700 Subject: the case of the missing Cabal doc Message-ID: In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Jun 30 06:45:57 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 30 Jun 2014 08:45:57 +0200 Subject: HEADS-UP: Git submodule conversion imminent In-Reply-To: References: <87ionpv3bb.fsf@gmail.com> <87k381w6xa.fsf@gmail.com> Message-ID: <201406300845.57744.jan.stolarek@p.lodz.pl> Herbert, all, I just pulled the new HEAD and have a question which I believe was not addressed so far. In my work on the GHC tree I never pulled the dph subrepo because the only thing it adds for me is extra build time (of course I pull it for my validation tree because I have no choice). Now it seems that getting rid of dph is not that simple. If I `rm -df libraries/dph` then it gets restored after `./sync-all pull`. Running `rm -df libraries/dph/*` seems to prevent that but I imagine there will be problems if the dph submodule actually gets modified and I try to pull the latest version. Moreover in both cases `git status` lists the submodule content as modified, which I see as noise. So is there a good way of removing dph from the source tree? The only solution I see is to remove library/dph from the build tree (I use the lndir trick). This means I have DPH in the source tree but not in the symlinked build tree, which is not perfect, but acceptable. Janek Dnia sobota, 28 czerwca 2014, Gabor Greif napisa?: > On 6/28/14, Herbert Valerio Riedel wrote: > > On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote: > >> Hmm, I guess this was the reason, > >> when I did that, I got > >> > >>> fatal: Needed a single revision > >>> Unable to find current revision in submodule path 'libraries/parallel' > >> > >> so the other submodules were not initialized. > >> > >> What might be wrong with 'libraries/parallel' ? > > > > Tbh, not sure, but if you know you have nothing important in > > libraries/parallel, > > > > rm -rf libraries/parallel > > > > and retry a 'git submodule update --init' > > > > This is essentially the suggested course of action according to > > > > > > http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.htm > >l#x22-10400014.1.4 > > > > and other results you may get if you google for that error > > Great, that helped! > > Cheers, > > Gabor > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From hvriedel at gmail.com Mon Jun 30 08:23:49 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 30 Jun 2014 10:23:49 +0200 Subject: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea) In-Reply-To: <20140630003752.20ED72406D@ghc.haskell.org> (git-4Dsf34iY's message of "Mon, 30 Jun 2014 00:37:52 +0000 (UTC)") References: <20140630003752.20ED72406D@ghc.haskell.org> Message-ID: <87zjguyfe2.fsf@gnu.org> Hi, Fyi, this changeset seems to have broken ./validate: utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning: Fields of ?ClsInstDecl? not initialised: cid_overlap_mode In the first argument of ?return?, namely ?(ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})? In a stmt of a 'do' block: return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) In the expression: do { ltype' <- renameLType ltype; lATs' <- mapM (mapM renameTyFamInstD) lATs; lADTs' <- mapM (mapM renameDataFamInstD) lADTs; return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) } : Failing due to -Werror. make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] Error 1 make: *** [all] Error 2 On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/NkouOHNgZ69ag at public.gmane.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178/ghc > >>--------------------------------------------------------------- > > commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > Author: Iavor S. Diatchki > Date: Sun Jun 29 17:22:16 2014 -0700 > > Overlapable pragmas for individual instances (#9242) > > Programmers may provide a pragma immediately after the `instance` keyword > to control the overlap/incoherence behavior for individual instances. > For example: > > instance {-# OVERLAP #-} C a where ... > > I chose this notation, rather than the other two outlined in the ticket > for these reasons: > > 1. Having the pragma after the type looks odd, I think. > 2. Having the pragma after there `where` does not work for > stand-alone derived instances > > I have implemented 3 pragams: > > 1. NO_OVERLAP > 2. OVERLAP > 3. INCOHERENT > > These correspond directly to the internal modes currently supported by > GHC. If a pragma is specified, it will be used no matter what flags are > turned on. For example, putting `NO_OVERLAP` on an instance will mark > it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on for the > module. > > >>--------------------------------------------------------------- > > 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > compiler/hsSyn/Convert.lhs | 2 +- > compiler/hsSyn/HsDecls.lhs | 24 ++++++++++++++++---- > compiler/parser/Lexer.x | 6 +++++ > compiler/parser/Parser.y.pp | 21 +++++++++++++----- > compiler/rename/RnSource.lhs | 7 ++++-- > compiler/typecheck/TcDeriv.lhs | 46 +++++++++++++++++++++++++-------------- > compiler/typecheck/TcInstDcls.lhs | 5 ++++- > 7 files changed, 82 insertions(+), 29 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 -- "Elegance is not optional" -- Richard O'Keefe From jan.stolarek at p.lodz.pl Mon Jun 30 09:28:27 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 30 Jun 2014 11:28:27 +0200 Subject: Cleanup of RnExpr, RnEnv and RnSource Message-ID: <201406301128.28016.jan.stolarek@p.lodz.pl> Dear all, RnExpr, RnEnv and RnSource (in compiler/renamer) declare locally: \begin{code} -- XXX thenM :: Monad a => a b -> (b -> a c) -> a c thenM = (>>=) thenM_ :: Monad a => a b -> a c -> a c thenM_ = (>>) \end{code} and then use these aliases instead of >>= and >>. These were introduced by Ian in 6c7b41cc2b24f533697a62bf1843507ae043fc97 in 2008 and later partially cleaned up by Simon in f0c99958649b8909612b1b9c9b48aad970dfce05 in 2009. Would there be objections if I cleand this up (ie. remove thenM and thenM_ and use >>= and >>)? Is anyone doing any substantial changes on any of these files and suspects that this could introduce merge conflicts for him? I'm at the moment changing some things in RnExpr, so doing this will only add little extra work for me and I'd like to take this oportunity to have cleaner code. Janek From simonpj at microsoft.com Mon Jun 30 09:41:20 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 30 Jun 2014 09:41:20 +0000 Subject: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF103F20DC@DB3PRD3001MB020.064d.mgd.msft.net> You'll need to give a lot more info than this before I can help Gabor. Currently I have only the vaguest idea about what you are trying to accomplish. Is there a wiki page that describes the design (user's eye view) in detail? I see you have a branch. If you are stuck, and give me repro instructions, I can attempt to help. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 27 June 2014 17:51 | To: ghc-devs | Subject: Resolved+new Q: TypeLits question, how to build a Type | Application with Symbol index | | I succeeded to solve all of them :-) | | But now I am blocked on on a panic | | "not in scope during type checking, but it passed the renamer". | | I suspect that while "deriving Generic" some instances are defined in | some empty TcEnv, which does not contain my definition in context. | | Is there a way to inject some type constructor into the TcEnv? | | Thanks, | | Gabor | | On 6/27/14, Gabor Greif wrote: | > Hello devs, | > | > I have | > | > {{{ | > data D (n :: Symbol) | > }}} | > | > in my module, and I want to obtain a type | > | > {{{ | > D "YAY!" | > }}} | > | > programmatically. Where can I find code that performs this (or | > something similar)? | > | > 1) I have to look up |D| in the current TyEnv (what if it is in a | > specific module?), | > 2) I have to build the type index (of kind Symbol), this involves | > FastString, looks non-trivial, | > 3) Apply 1) on 2), this is easy. | > | > Any hints welcome! | > | > Thanks and cheers, | > | > Gabor | > | > | > PS: some morsels I have so far: | > | > for 1) | > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit | > "GHC.Generics") | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Jun 30 09:59:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 30 Jun 2014 09:59:05 +0000 Subject: Cleanup of RnExpr, RnEnv and RnSource In-Reply-To: <201406301128.28016.jan.stolarek@p.lodz.pl> References: <201406301128.28016.jan.stolarek@p.lodz.pl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103F2266@DB3PRD3001MB020.064d.mgd.msft.net> Or better still use do-notation like the rest of the compiler. That'd be great thatnks. You could de-tabify and remove white space at the same time SImon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan | Stolarek | Sent: 30 June 2014 10:28 | To: ghc-devs at haskell.org | Subject: Cleanup of RnExpr, RnEnv and RnSource | | Dear all, | | RnExpr, RnEnv and RnSource (in compiler/renamer) declare locally: | | \begin{code} | -- XXX | thenM :: Monad a => a b -> (b -> a c) -> a c thenM = (>>=) | | thenM_ :: Monad a => a b -> a c -> a c | thenM_ = (>>) | \end{code} | | and then use these aliases instead of >>= and >>. These were introduced | by Ian in | 6c7b41cc2b24f533697a62bf1843507ae043fc97 in 2008 and later partially | cleaned up by Simon in | f0c99958649b8909612b1b9c9b48aad970dfce05 in 2009. Would there be | objections if I cleand this up (ie. remove thenM and thenM_ and use >>= | and >>)? Is anyone doing any substantial changes on any of these files | and suspects that this could introduce merge conflicts for him? I'm at | the moment changing some things in RnExpr, so doing this will only add | little extra work for me and I'd like to take this oportunity to have | cleaner code. | | Janek | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From ggreif at gmail.com Mon Jun 30 11:27:26 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 30 Jun 2014 13:27:26 +0200 Subject: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103F20DC@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103F20DC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks, Simon! Yes I have a branch, and it works! A bunch of things is still missing (notably record selectors), but I have a proof-of-concept with a gdiff library hooked up to GHC.Generics, and by appealing to type-level reasoning I can obtain a difference tree from True to False (which looks good) by using the reflection (i.e. class Generic) only, no need for TH or hand-coding. Comparing bigger trees (and then 'patch'ing them) appears to be SMOP from here. My current obstacle is that for each instance Datatype (Dat "MyModule" "Foo") ... I get an 'orphan instance' warning. I believe that these are harmless, so is there a way to suppress them? Since I never insert tyvars in the instance head, there should never be any overlap too. Cheers, Gabor On 6/30/14, Simon Peyton Jones wrote: > You'll need to give a lot more info than this before I can help Gabor. > Currently I have only the vaguest idea about what you are trying to > accomplish. Is there a wiki page that describes the design (user's eye > view) in detail? > > I see you have a branch. If you are stuck, and give me repro instructions, > I can attempt to help. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor > | Greif > | Sent: 27 June 2014 17:51 > | To: ghc-devs > | Subject: Resolved+new Q: TypeLits question, how to build a Type > | Application with Symbol index > | > | I succeeded to solve all of them :-) > | > | But now I am blocked on on a panic > | > | "not in scope during type checking, but it passed the renamer". > | > | I suspect that while "deriving Generic" some instances are defined in > | some empty TcEnv, which does not contain my definition in context. > | > | Is there a way to inject some type constructor into the TcEnv? > | > | Thanks, > | > | Gabor > | > | On 6/27/14, Gabor Greif wrote: > | > Hello devs, > | > > | > I have > | > > | > {{{ > | > data D (n :: Symbol) > | > }}} > | > > | > in my module, and I want to obtain a type > | > > | > {{{ > | > D "YAY!" > | > }}} > | > > | > programmatically. Where can I find code that performs this (or > | > something similar)? > | > > | > 1) I have to look up |D| in the current TyEnv (what if it is in a > | > specific module?), > | > 2) I have to build the type index (of kind Symbol), this involves > | > FastString, looks non-trivial, > | > 3) Apply 1) on 2), this is easy. > | > > | > Any hints welcome! > | > > | > Thanks and cheers, > | > > | > Gabor > | > > | > > | > PS: some morsels I have so far: > | > > | > for 1) > | > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit > | > "GHC.Generics") > | > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Jun 30 11:56:55 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 30 Jun 2014 11:56:55 +0000 Subject: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103F20DC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103F26C0@DB3PRD3001MB020.064d.mgd.msft.net> | Yes I have a branch, and it works! A bunch of things is still missing | (notably record selectors), but I have a proof-of-concept with a gdiff | library hooked up to GHC.Generics, and by appealing to type-level | reasoning I can obtain a difference tree from True to False (which | looks good) by using the reflection (i.e. class Generic) only, no need | for TH or hand-coding. Comparing bigger trees (and then 'patch'ing | them) appears to be SMOP from here. Do you have a wiki page explaining what "it" is (the thing that works). | instance Datatype (Dat "MyModule" "Foo") ... | | I get an 'orphan instance' warning. I believe that these are harmless, The downside of orphan instances is that GHC must visit every .hi file that has an orphan instance, just in case it contains a relevant instance decl. That slows down *every* compilation, whether or not it uses the instance. The best way to get rid of it is to declare something local that is "from this module". Something like data MyModule_Foo instance DataType (Dat MyModule_Foo) where ... Now MyModule_Foo is a data type from the module currently being compiled. That tells GHC which .hi file to look in, and means the instance isn't orphan. Simon | so is there a way to suppress them? Since I never insert tyvars in the | instance head, there should never be any overlap too. | | Cheers, | | Gabor | | On 6/30/14, Simon Peyton Jones wrote: | > You'll need to give a lot more info than this before I can help Gabor. | > Currently I have only the vaguest idea about what you are trying to | > accomplish. Is there a wiki page that describes the design (user's eye | > view) in detail? | > | > I see you have a branch. If you are stuck, and give me repro | instructions, | > I can attempt to help. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Gabor | > | Greif | > | Sent: 27 June 2014 17:51 | > | To: ghc-devs | > | Subject: Resolved+new Q: TypeLits question, how to build a Type | > | Application with Symbol index | > | | > | I succeeded to solve all of them :-) | > | | > | But now I am blocked on on a panic | > | | > | "not in scope during type checking, but it passed the renamer". | > | | > | I suspect that while "deriving Generic" some instances are defined in | > | some empty TcEnv, which does not contain my definition in context. | > | | > | Is there a way to inject some type constructor into the TcEnv? | > | | > | Thanks, | > | | > | Gabor | > | | > | On 6/27/14, Gabor Greif wrote: | > | > Hello devs, | > | > | > | > I have | > | > | > | > {{{ | > | > data D (n :: Symbol) | > | > }}} | > | > | > | > in my module, and I want to obtain a type | > | > | > | > {{{ | > | > D "YAY!" | > | > }}} | > | > | > | > programmatically. Where can I find code that performs this (or | > | > something similar)? | > | > | > | > 1) I have to look up |D| in the current TyEnv (what if it is in a | > | > specific module?), | > | > 2) I have to build the type index (of kind Symbol), this involves | > | > FastString, looks non-trivial, | > | > 3) Apply 1) on 2), this is easy. | > | > | > | > Any hints welcome! | > | > | > | > Thanks and cheers, | > | > | > | > Gabor | > | > | > | > | > | > PS: some morsels I have so far: | > | > | > | > for 1) | > | > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule | (fsLit | > | > "GHC.Generics") | > | > | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs | > From simonpj at microsoft.com Mon Jun 30 13:04:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 30 Jun 2014 13:04:59 +0000 Subject: Help needed: parsing pattern synonym contexts In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF103EB3F2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF103F294F@DB3PRD3001MB020.064d.mgd.msft.net> Gergo It's just a question of chasing down the reduce/reduce errors. You can give a flag to Happy that makes it dump a file with all the info about it parsing states, and where the reduce/reduce errors come from, and you can go from there. If you don't know how to interpret that file, just commit your best try to your wip/ branch and maybe some other ghc devs will help you. Maybe me. But without being able to reproduce it, it's hard to help. Simon | -----Original Message----- | From: Dr. ERDI Gergo [mailto:gergo at erdi.hu] | Sent: 25 June 2014 14:20 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: RE: Help needed: parsing pattern synonym contexts | | On Tue, 24 Jun 2014, Simon Peyton Jones wrote: | | > In the latter case, what happened to the shift/reduce and | > reduce/reduce errors reported by Happy? Esp the latter. If you are | > getting more you need to track them down. | | I think I've figured out what might be causing the problem. | | First, a couple figures. With these rules: | | pattern_synonym_decl | : 'pattern' con vars0 patsyn_token pat | | 'pattern' varid conop varid patsyn_token pat | | pattern_synonym_sig | : 'pattern' patsyn_stuff '::' ctype | | patsyn_stuff | : constr_stuff | | I'm getting 112 new reduce/reduce conflicts. | | If I add the context like you recommended: | | pattern_synonym_sig | : 'pattern' patsyn_context patsyn_stuff '::' ctype | | patsyn_context :: { LHsContext RdrName } | : forall | | forall context '=>' | | | then I get 54 new shift/reduce conflicts and no (new) reduce/reduce | conflicts. | | My feeling is the problem is that patterns don't need any special | parentheses around type annotations, which means the following is a | legal pattern synonym definition: | | pattern Single x = [x] :: [Int] | | and I think that the difference (the '=' or '<-') is too 'deep' between | this and something like | | pattern Single a :: [a] | | Unfortunately, I still have no idea how to solve this problem... From eir at cis.upenn.edu Mon Jun 30 14:19:21 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 30 Jun 2014 10:19:21 -0400 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: Message-ID: Thanks, Johan, for starting this discussion. I mostly agree with the proposal. However, one (at times, serious) drawback to using Haddock is that it means that editing comments can cause parse failures. The way the GHC build works, these failures may not be detected until the end of a hacking session (if I'm using, say, `make 2`, as I tend to do) and then can be hard to diagnose. I've actually been bitten by this when working on GHC. So, I have to ask: why use Haddock? Do folks read the Haddock docs for GHC? (I don't, but perhaps that's because the docs aren't so good right now.) Would it be acceptable to change this proposal not to require Haddock docs? Even if we decide to keep this proposal about Haddock docs specifically, I would strongly request that correct rendering of the Haddock docs not be scrutinized. At the end of a hacking session (which is hard enough to find time for, as is), I don't want to be expected to look through the generated HTML to make sure that my typewriter font and italics are rendering correctly. This is something of a corollary to Simon's comment about wanting to refer to Notes from Haddock comments -- I would want the Haddock output to be quite secondary to the proper documentation in the source code. (Note that this "demotion" of the role of Haddock is certainly not my practice in released libraries! But, Haddock is much less useful in an application like GHC than in a library.) All that said, I do agree with the intent of this proposal and am happy to take on my part of the burden of documenting new (and perhaps some old) functions as I work. I have been very guilty of the "broken window" effect in not documenting new code. Thanks, Richard On Jun 27, 2014, at 5:51 AM, Johan Tibell wrote: > Hi! > > I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. > > GHC code is sometimes commented with "notes", which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. > > Lack of documentation, in GHC and other software projects, usually has (at least) two causes: > Programmers comment code they think is "complex enough to warrant a comment". The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. > Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. > I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. > > Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. > > Proposal: I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. > > I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong "broken window" effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. > > We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. > > To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. > > First example > In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. > > The first question that I asked upon seeing uses of that function was "what does RUR stand for?" Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean "read" in the enclosing function and "updating" is related to "reading" so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: > > -- | Create register usage info for instruction that only > -- reads registers. > mkRUR src = src' `seq` RU src' [] > where src' = filter (interesting platform) src > > That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. > > Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. > > Second example > In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. > > I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: > > -- | Returns which registers are read and written by this > -- instruction, as a (read, written) pair. This info is used > -- by the register allocator. > x86_regUsageOfInstr :: Platform -> Instr -> RegUsage > > The reason mentioning that the return value is essentially a (read, written) pair is helpful is because the body of the function a big case statement full of lines like this one: > > GCMP _ src1 src2 -> mkRUR [src1,src2] > ... > FDIV _ src dst -> usageRM src dst > > It's not immediately clear that all the various helper functions used here just end up computing a pair of the above form. A top-level comment lets you understand what's going on without understanding exactly what all these helper functions are doing. > > Thoughts? > > -- Johan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Mon Jun 30 15:32:50 2014 From: dsf at seereason.com (David Fox) Date: Mon, 30 Jun 2014 08:32:50 -0700 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: <53ADB3B5.6060406@fuuzetsu.co.uk> References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> <53ADB3B5.6060406@fuuzetsu.co.uk> Message-ID: On Fri, Jun 27, 2014 at 11:11 AM, Mateusz Kowalczyk wrote: > On 06/27/2014 03:26 PM, David Fox wrote: > > I would counter propose a place on hackage for people to type in or > modify > > the documentation for functions, designed in such a way that the > > documentation would easily find its way back into the project's source > code > > (with developer approval.) This way the documentation can be generated > by > > people who only recently came to understand the function, so the > questions > > a newcomer has are fresh in their mind. > > > > Are you asking for a wiki-like thing for documentation? There were a few > times where this has been proposed such as > https://github.com/haskell/haddock/issues/72 but in general it turns out > that there's not enough interest for anyone to sit down and implement it > and make sure it all works properly. Patches should be going straight to > upstream rather than lingering on Hackage until someone notices them > (even with automated tools, it's a pain). I doubt many people would use > it for anything but typos because if you have enough knowledge about a > function to document it, you're likely to already be involved with the > project in some way and have means to report it properly. > > My thought was that it would end up in the library's source code, not that it would reside in a wiki. The question is whether anyone has the motivation to write a sufficiently smooth mechanism to achieve this. If I was editing a package that I normally upload to hackage and I could look at a nice presentation of alternative documentation strings people have suggested for the different functions in my library, I would be happy to cut and paste them into the source code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Mon Jun 30 15:42:13 2014 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Mon, 30 Jun 2014 17:42:13 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: Message-ID: <53B18555.5040900@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey list, I am strongly in favour of the proposal. As a pedestrian-level GHC contributor, the *vast* majority of my time is spent trying to figure out what certain things do, when the answer could be found in a one- or two-line comment above a definition. As for Richard's remark, > So, I have to ask: why use Haddock? Do folks read the Haddock docs > for GHC? (I don't, but perhaps that's because the docs aren't so > good right now.) I find Haddock very useful for one major reason: it allows me an HTML overview over all exported definitions (in the index), which is a big plus when you're searching for things. Greetings, David/quchen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTsYVUAAoJELrQsaT5WQUsKawIAIMHt9Ha4qTWtJO6qwOjN5RD JOx1MnuPlDLosbyE9+BlkEV1tRnnG/snyxwFTgmtFSO9fAV2FPZEbtzZ2AZd4xbb VgORhTAeL1n1aBitGNaAzT1T60tS2JNict2S0pUWa0Qt3nYWwoRw1B+OOaZRuuaR cHkOFKMbzU5knmeD/RyDIE+oRxZvjAKdAaaQ0vJ70ovNUptjtfDeX6Nxto65qFis sKsWjsL++TgeOscejw7DNLeCei/cwrzjOSNOB6xFGAxPHUHZFvSkbuVAMNWIgbic 55tbDIog/l9P/N8RoUQh4PLjh3TG3xT3vsM5iiTKl3UZ7eTMpzmzAKhvikoHGOU= =w6S7 -----END PGP SIGNATURE----- From johan.tibell at gmail.com Mon Jun 30 20:14:06 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 30 Jun 2014 22:14:06 +0200 Subject: Two days old build breakage on i386. In-Reply-To: <53AD5536.5010901@gmail.com> References: <53ABE012.8040104@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF103ED3BD@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF103ED59A@DB3PRD3001MB020.064d.mgd.msft.net> <53AD5200.4020505@gmail.com> <53AD5536.5010901@gmail.com> Message-ID: I fixed the x86 issue and re-commited my work as 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49. On Fri, Jun 27, 2014 at 1:27 PM, Simon Marlow wrote: > On 27/06/2014 12:23, Johan Tibell wrote: >> >> On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow wrote: >>> >>> The problem is that this instruction requires three separate registers, >>> but >>> cmpxchgl already reads and writes %eax leaving only two free registers >>> (%ecx >>> and %edx). >>> >>> You'll need to arrange to not use the complicated addressing modes with >>> cmpxchg on i386, and keep the number of free regs required <= 2. >> >> >> Where's the best place to arrange for that? If I switch from using >> getAmode to computing the address into a temp register in StgCmmPrim >> will that ensure that the address is simple, or could some >> optimization replace my temp register computation with a complex >> address again? > > > There aren't any optimisations that happen on the instructions after > codegen, and if there were, they would have to respect the same rule. So > using a register is the right thing, yes. > > Cheers, > Simon > From johan.tibell at gmail.com Mon Jun 30 20:16:52 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 30 Jun 2014 22:16:52 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: <53B18555.5040900@gmail.com> References: <53B18555.5040900@gmail.com> Message-ID: Richard, Not requiring contributors to check that the Haddock render well is OK. As long as the comments are there someone with free time on their hands can always tidy up the rendering. I'm looking forward to the day I can browse the GHC Haddocks and make sense of them. I tried in the past but the generated docs aren't accessible enough without any actual comments. From johan.tibell at gmail.com Mon Jun 30 20:18:10 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 30 Jun 2014 22:18:10 +0200 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <53B18555.5040900@gmail.com> Message-ID: Left hold off one more week to give more contributors a change to voice their thoughts. If no one protests I will announce the new policy next Monday. Sounds good? From igloo at earth.li Mon Jun 30 20:25:03 2014 From: igloo at earth.li (Ian Lynagh) Date: Mon, 30 Jun 2014 21:25:03 +0100 Subject: the case of the missing Cabal doc In-Reply-To: References: Message-ID: <20140630202503.GA29322@matrix.chaos.earth.li> On Sun, Jun 29, 2014 at 11:04:20PM -0700, Mark Lentczner wrote: > In times of yore (prior to 7.8), when GHC build a bindist, it included the > generated HTML manual for Cabal. As of 7.8, this seems to have gone > missing-in-action. > > Anyone know where it went? It was converted to markdown, and GHC's build system doesn't know how to build markdown docs. It's in libraries/Cabal/Cabal/doc/. Thanks Ian From iavor.diatchki at gmail.com Mon Jun 30 20:27:16 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 30 Jun 2014 13:27:16 -0700 Subject: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea) In-Reply-To: <87zjguyfe2.fsf@gnu.org> References: <20140630003752.20ED72406D@ghc.haskell.org> <87zjguyfe2.fsf@gnu.org> Message-ID: Sorry about this. It would appear that I am not allowed to push to the `haddock` repo, so I've attached a patch, for someone with permissions to apply. Also, could I be given permissions to modify haddock, since GHC and haddock are closely related changes like the one I made often need to be propagated in both. -Iavor On Mon, Jun 30, 2014 at 1:23 AM, Herbert Valerio Riedel wrote: > Hi, > > Fyi, this changeset seems to have broken ./validate: > > utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning: > Fields of ?ClsInstDecl? not initialised: cid_overlap_mode > In the first argument of ?return?, namely > ?(ClsInstDecl > {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], > cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})? > In a stmt of a 'do' block: > return > (ClsInstDecl > {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], > cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) > In the expression: > do { ltype' <- renameLType ltype; > lATs' <- mapM (mapM renameTyFamInstD) lATs; > lADTs' <- mapM (mapM renameDataFamInstD) lADTs; > return > (ClsInstDecl > {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = > [], > cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) } > > : > Failing due to -Werror. > make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] > Error 1 > make: *** [all] Error 2 > > > On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/ > NkouOHNgZ69ag at public.gmane.org wrote: > > Repository : ssh://git at git.haskell.org/ghc > > > > On branch : master > > Link : > http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178/ghc > > > >>--------------------------------------------------------------- > > > > commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > > Author: Iavor S. Diatchki > > Date: Sun Jun 29 17:22:16 2014 -0700 > > > > Overlapable pragmas for individual instances (#9242) > > > > Programmers may provide a pragma immediately after the `instance` > keyword > > to control the overlap/incoherence behavior for individual instances. > > For example: > > > > instance {-# OVERLAP #-} C a where ... > > > > I chose this notation, rather than the other two outlined in the > ticket > > for these reasons: > > > > 1. Having the pragma after the type looks odd, I think. > > 2. Having the pragma after there `where` does not work for > > stand-alone derived instances > > > > I have implemented 3 pragams: > > > > 1. NO_OVERLAP > > 2. OVERLAP > > 3. INCOHERENT > > > > These correspond directly to the internal modes currently supported > by > > GHC. If a pragma is specified, it will be used no matter what flags > are > > turned on. For example, putting `NO_OVERLAP` on an instance will > mark > > it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on > for the > > module. > > > > > >>--------------------------------------------------------------- > > > > 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > > compiler/hsSyn/Convert.lhs | 2 +- > > compiler/hsSyn/HsDecls.lhs | 24 ++++++++++++++++---- > > compiler/parser/Lexer.x | 6 +++++ > > compiler/parser/Parser.y.pp | 21 +++++++++++++----- > > compiler/rename/RnSource.lhs | 7 ++++-- > > compiler/typecheck/TcDeriv.lhs | 46 > +++++++++++++++++++++++++-------------- > > compiler/typecheck/TcInstDcls.lhs | 5 ++++- > > 7 files changed, 82 insertions(+), 29 deletions(-) > > > > Diff suppressed because of size. To see it, use: > > > > git diff-tree --root --patch-with-stat --no-color > --find-copies-harder --ignore-space-at-eol --cc > 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > > -- > "Elegance is not optional" -- Richard O'Keefe > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Propagate-overloading-mode-for-instance-declarations.patch Type: text/x-patch Size: 1483 bytes Desc: not available URL: From iavor.diatchki at gmail.com Mon Jun 30 20:34:35 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 30 Jun 2014 13:34:35 -0700 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: References: <53B18555.5040900@gmail.com> Message-ID: I think that's a good idea, as long as we do enforce it as "social policy" rather than a script. In other words, we should encourage folks to add comments documenting functions, but not necessarily require them *everywhere*, and leave it I also share Richard's concern about using Haddock notation, and the possibility of introducing build-failures due to typos in the documentation. -Iavor On Mon, Jun 30, 2014 at 1:18 PM, Johan Tibell wrote: > Left hold off one more week to give more contributors a change to > voice their thoughts. If no one protests I will announce the new > policy next Monday. Sounds good? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Mon Jun 30 20:42:50 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 30 Jun 2014 16:42:50 -0400 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: <53B18555.5040900@gmail.com> References: <53B18555.5040900@gmail.com> Message-ID: <8738em2kol.fsf@gmail.com> David Luposchainsky writes: > Hey list, > > I am strongly in favour of the proposal. As a pedestrian-level GHC > contributor, the *vast* majority of my time is spent trying to figure > out what certain things do, when the answer could be found in a one- > or two-line comment above a definition. > I'd like to second this. As an occassional contributor, I find myself wading through a lot of code to deduce functions' purpose. While I'm often pleasantly surprised by the quality of the notes scattered about the code, per-definition Haddocks would fill in the many remaining gaps and provide a nice overview of each module. I agree that enforcing the quality of the rendered Haddocks is unnecessary. Once the language has been written there are many contributors (such as myself) who can further clean up the formatting. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From hvriedel at gmail.com Mon Jun 30 21:02:49 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 30 Jun 2014 23:02:49 +0200 Subject: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea) In-Reply-To: (Iavor Diatchki's message of "Mon, 30 Jun 2014 13:27:16 -0700") References: <20140630003752.20ED72406D@ghc.haskell.org> <87zjguyfe2.fsf@gnu.org> Message-ID: <87vbrixg92.fsf@gmail.com> On 2014-06-30 at 22:27:16 +0200, Iavor Diatchki wrote: > Sorry about this. It would appear that I am not allowed to push to the > `haddock` repo, so I've attached a patch, for someone with permissions to > apply. > > Also, could I be given permissions to modify haddock, since GHC and haddock > are closely related changes like the one I made often need to be propagated > in both. Sure, I've just added you to the set of users allowed to push to GitHub's haskell/haddock repo. There's a ghc-devs team in the haskell github organization, https://github.com/orgs/haskell/teams/ghc-devs which should ideally contain all committers listed at https://ghc.haskell.org/trac/ghc/wiki/TeamGHC but it's probably out of sync currently. From djsamperi at gmail.com Mon Jun 30 21:22:08 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Mon, 30 Jun 2014 17:22:08 -0400 Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF103EECD8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Given the examples provided with this proposal it looks like this change is targeted mostly at compiler hackers, and not at library/package developers. For the latter community it would be nice to establish a policy for libraries and packages that encourages ("nudges") developers to include comments and examples, something more useful than type signatures or pointers to the literature on type theory. For example, the R stats system encourages package developers to include examples, and these examples are run as part of the package checking process, thus encouraging developers to keep the examples up-to-date. This kind of change might help Haskell move beyond its current role as a research and teaching tool, and an incubator for new programming ideas that are eventually implemented and popularized in other programming languages... Cheers, Dominick On Fri, Jun 27, 2014 at 6:17 AM, Simon Peyton Jones wrote: > I'd be OK with this, (it's a bit like requiring signatures on all top level > functions) but I don't know how we'd enforce it. > > > > Do you think the requirement should be for all top-level functions or just > exported ones? > > > > I agree that Notes have a different purpose. But it should be OK style to > refer to a Note from a top-level function comment, even though Haddock won't > be able to make much sense of it. > > > > Simon > > > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan > Tibell > Sent: 27 June 2014 10:51 > To: ghc-devs at haskell.org > Subject: Proposal: require Haddock comment for every new top-level function > and type in GHC source code > > > > Hi! > > > > I found myself exploring new parts of the GHC code base the last few weeks > (exciting!), which again reminded me of my biggest frustration when working > on GHC: the lack of per-function/type (Haddock) comments. > > > > GHC code is sometimes commented with "notes", which are great but tend to > (1) mostly cover the exceptional cases and (2) talk about the implementation > of a function, not how a caller might use it or why. > > > > Lack of documentation, in GHC and other software projects, usually has (at > least) two causes: > > Programmers comment code they think is "complex enough to warrant a > comment". The problem is that the author is usually a poor judge of what's > complex enough, because he/she is too familiar with the code and tends to > under-document code when following this principle. > Documenting is boring and tends to have little benefit the person writing to > documentation. Given lack of incentives we tend to document less than we > ought to. > > I've only seen one successful way to combat the lack of documentation that > stems from the above: have the project's style guide mandate that top-level > functions and types (or at least those that are exported) have > documentation. This works well at Google. > > > > Anecdote: we have one code base inside Google that was until recently exempt > from this rule and documentation is almost completely absent in that code > base, even though hundreds of engineers work on and need to understand it > every day. This breeds institutional knowledge problems i.e. if the author > of a core piece of code leaves, lots of knowledge is lost. > > > > Proposal: I propose that we require that new top-level functions and types > have Haddock comments, even if they start out as a single, humble sentence. > > > > I've found that putting even that one sentence (1) helps new users and (2) > establishes a place for improvements to be made. There's a strong "broken > window" effect to lack of comments, in that lack of comments breeds more > lack of comments as developers follow established practices. > > > > We should add this requirement to the style guide. Having it as a written > down policy tends to prevent having to re-hash the whole argument about > documentation over and over again. This has also helped us a lot at Google, > because programmers can spend endless amount of time arguing about comments, > placement of curly braces, etc. and having a written policy helps cut down > on that. > > > > To give an idea of how to write good comments, here are two examples of > undocumented code I ran into in GHC and how better comments would have > helped. > > > > First example > > In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, > which is a helper function use when computing instruction register usage. > > > > The first question that I asked upon seeing uses of that function was "what > does RUR stand for?" Given the context the function is in, I guessed it > stands for read-update-read, because R is used to mean "read" in the > enclosing function and "updating" is related to "reading" so that must be > what U stands for. It turns out that it stands for RegUsageReadonly. Here's > a comment that would have captured, in a single sentence, what this function > is for: > > > > -- | Create register usage info for instruction that only > > -- reads registers. > > mkRUR src = src' `seq` RU src' [] > > where src' = filter (interesting platform) src > > > > That already a big improvement. A note about the register filtering, which > means that not all registers you pass to the function will be recorded as > being read in the end, could also be useful. > > > > Aside: providing a type signature, which would have made it clear that the > return type is RU, might also have helped in this particular case. > > > > Second example > > In the same file there a function called x86_regUsageOfInstr. It's the > function that encloses the local function mkRUR above. > > > > I could figure out that this function has something to do with register > usage, of the instruction passed as an argument, and that register usage is > important for the register allocator. However, trying to understand in more > detail what that meant was more of challenge than it needed to be. First, a > comment more clearly explaining what computing register usage means in > practice would be helpful: > > > > -- | Returns which registers are read and written by this > > -- instruction, as a (read, written) pair. This info is used > > -- by the register allocator. > > x86_regUsageOfInstr :: Platform -> Instr -> RegUsage > > > > The reason mentioning that the return value is essentially a (read, written) > pair is helpful is because the body of the function a big case statement > full of lines like this one: > > > > GCMP _ src1 src2 -> mkRUR [src1,src2] > > ... > > FDIV _ src dst -> usageRM src dst > > > > It's not immediately clear that all the various helper functions used here > just end up computing a pair of the above form. A top-level comment lets you > understand what's going on without understanding exactly what all these > helper functions are doing. > > > > Thoughts? > > > > -- Johan > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >