From ben at well-typed.com Thu Sep 1 05:30:20 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 01 Sep 2016 01:30:20 -0400 Subject: Phabricator diffs not viewable by non-logged in users In-Reply-To: <1472678320-sup-7483@sabre> References: <1472678320-sup-7483@sabre> Message-ID: <87d1kofaqb.fsf@smart-cactus.org> "Edward Z. Yang" writes: > For example, if I am not logged in (try an incognito/private > browsing session), https://phabricator.haskell.org/D2501 reports > an error. > Indeed I had noticed this as well and it has been on my list of things to look in to. I agree that you shouldn't need to be logged in to view differentials. Austin, do you have any idea why this is the case? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From facundo.dominguez at tweag.io Thu Sep 1 15:02:00 2016 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Thu, 1 Sep 2016 12:02:00 -0300 Subject: Last call for merge requests for 8.0.2 In-Reply-To: <87oa4bh02u.fsf@smart-cactus.org> References: <87oa4bh02u.fsf@smart-cactus.org> Message-ID: Ben, We'd like to have the patch to this bug [1] included as well, if possible. Thanks, Facundo [1] https://ghc.haskell.org/trac/ghc/ticket/12559 On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari wrote: > tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see > merged into 8.0.2 and isn't already present in the tree, please > speak up! > > > Hello everyone, > > Over the last week I have been working down the (rather long) merge > queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this > point I think have merged nearly everything which will likely make it in > to 8.0.2. > > If you have a patch which hasn't made it to the ghc-8.0 branch that you > would like to see merged, please raise your concern on the appropriate > Trac ticket. > > Thanks! > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From austin at well-typed.com Thu Sep 1 20:28:04 2016 From: austin at well-typed.com (Austin Seipp) Date: Thu, 1 Sep 2016 15:28:04 -0500 Subject: Phabricator diffs not viewable by non-logged in users In-Reply-To: <87d1kofaqb.fsf@smart-cactus.org> References: <1472678320-sup-7483@sabre> <87d1kofaqb.fsf@smart-cactus.org> Message-ID: The error message was fairly self explanatory: it mentions the restriction was on the Build Plan object, not the Differential revision (if you view it in private/incognito mode). In Phabricator, various objects can have their own policies. Objects can be attached to others, like builds to diffs. Diffs had been set to be public on creation, but for some reason, all the Harbormaster build plans required 'All Users' to view them, which requires a login. I've fixed this by changing all the build plans to be public, which they should have been in the first place. On Thu, Sep 1, 2016 at 12:30 AM, Ben Gamari wrote: > "Edward Z. Yang" writes: > > > For example, if I am not logged in (try an incognito/private > > browsing session), https://phabricator.haskell.org/D2501 reports > > an error. > > > Indeed I had noticed this as well and it has been on my list of things > to look in to. I agree that you shouldn't need to be logged in to view > differentials. > > Austin, do you have any idea why this is the case? > > Cheers, > > - Ben > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Fri Sep 2 02:45:58 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Fri, 2 Sep 2016 02:45:58 +0000 Subject: Build GHC on Windows using Hadrian and Stack Message-ID: Hi all, Summary: Building GHC on Windows using Hadrian and Stack got even simpler - see https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. To build GHC on Windows you usually need to jump through a lot of hoops [1], which may be confusing even for experienced GHC developers [2]. Hadrian to the rescue! Hadrian, a new build system for GHC that I've been developing [3], is written in Haskell and can therefore be built and run via Stack that can install appropriate bootstrapping GHC and MSYS2 environment in an automated and robust way. This was first pointed out by Neil Mitchell [4], and I've recently simplified build instructions even further. Here are all the steps: git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://github.com/snowleopard/hadrian cd hadrian stack setup stack exec -- pacman -S autoconf automake-wrapper make patch tar --noconfirm stack build stack exec hadrian -- --directory ".." -j --flavour=quickest See more details here: https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. NB: Hadrian can build Stage2 GHC, but there are still many limitations [5]. Help make it better! [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [2] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012340.html [3] https://github.com/snowleopard/hadrian [4] http://neilmitchell.blogspot.co.uk/2016/03/compiling-ghc-on-windows.html [5] https://github.com/snowleopard/hadrian#current-limitations Cheers, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Sep 2 03:15:48 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 1 Sep 2016 23:15:48 -0400 Subject: Unprincipled defaults In-Reply-To: References: Message-ID: On occasion, it can be useful to have default definitions that don't typecheck even with DefaultSignatures. It would be nice to be able to use them anyway. For example, if we have class Semigroup1 f where op :: f a -> f a -> f a then we could, hypothetically, give a default definition for (<>): default (<>) :: Semigroup1 f => f a -> f a -> f a (<>) = op But we can't give a default definition op = (<>) because there's no way to write its signature. However, for any F with instance Semigroup (F a) where ... the definition op = (<>) is perfectly fine. Would it be possible to offer a completely wild defaulting mechanism allowing *any expression* as a default, and only checking its type and compiling it when it's actually used? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Sep 2 08:47:25 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 02 Sep 2016 01:47:25 -0700 Subject: Build GHC on Windows using Hadrian and Stack In-Reply-To: References: Message-ID: <1472806035-sup-389@sabre> Nice work! Edward Excerpts from Andrey Mokhov's message of 2016-09-02 02:45:58 +0000: > Hi all, > > Summary: Building GHC on Windows using Hadrian and Stack got even simpler - see https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. > > > To build GHC on Windows you usually need to jump through a lot of hoops [1], which may be confusing even for experienced GHC developers [2]. > > Hadrian to the rescue! > > Hadrian, a new build system for GHC that I've been developing [3], is written in Haskell and can therefore be built and run via Stack that can install appropriate bootstrapping GHC and MSYS2 environment in an automated and robust way. This was first pointed out by Neil Mitchell [4], and I've recently simplified build instructions even further. Here are all the steps: > > git clone --recursive git://git.haskell.org/ghc.git > cd ghc > git clone git://github.com/snowleopard/hadrian > cd hadrian > stack setup > stack exec -- pacman -S autoconf automake-wrapper make patch tar --noconfirm > stack build > stack exec hadrian -- --directory ".." -j --flavour=quickest > > See more details here: https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. > > NB: Hadrian can build Stage2 GHC, but there are still many limitations [5]. Help make it better! > > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012340.html > [3] https://github.com/snowleopard/hadrian > [4] http://neilmitchell.blogspot.co.uk/2016/03/compiling-ghc-on-windows.html > [5] https://github.com/snowleopard/hadrian#current-limitations > > Cheers, > Andrey From rae at cs.brynmawr.edu Fri Sep 2 16:39:04 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 2 Sep 2016 12:39:04 -0400 Subject: Unprincipled defaults In-Reply-To: References: Message-ID: <2244744C-8744-4D0F-941A-8E6DAE323FAF@cs.brynmawr.edu> I feel like I must be missing something, but what's wrong with > class Semigroup1 f where > op :: f a -> f a -> f a > > default op :: Monoid (f a) => f a -> f a -> f a > op = (<>) ? Does that do what you like? Richard > On Sep 1, 2016, at 11:15 PM, David Feuer wrote: > > On occasion, it can be useful to have default definitions that don't typecheck even with DefaultSignatures. It would be nice to be able to use them anyway. For example, if we have > > class Semigroup1 f where > op :: f a -> f a -> f a > > then we could, hypothetically, give a default definition for (<>): > > default (<>) :: Semigroup1 f => f a -> f a -> f a > (<>) = op > > But we can't give a default definition > > op = (<>) > > because there's no way to write its signature. However, for any F with > > instance Semigroup (F a) where ... > > the definition op = (<>) is perfectly fine. > > Would it be possible to offer a completely wild defaulting mechanism allowing *any expression* as a default, and only checking its type and compiling it when it's actually used? > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Sep 2 16:45:46 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Sep 2016 12:45:46 -0400 Subject: Unprincipled defaults In-Reply-To: <2244744C-8744-4D0F-941A-8E6DAE323FAF@cs.brynmawr.edu> References: <2244744C-8744-4D0F-941A-8E6DAE323FAF@cs.brynmawr.edu> Message-ID: Whoa. I was far too confident that wouldn't work! On Sep 2, 2016 12:39 PM, "Richard Eisenberg" wrote: > I feel like I must be missing something, but what's wrong with > > class Semigroup1 f where > op :: f a -> f a -> f a > > default op :: Monoid (f a) => f a -> f a -> f a > op = (<>) > > > ? Does that do what you like? > > Richard > > > On Sep 1, 2016, at 11:15 PM, David Feuer wrote: > > On occasion, it can be useful to have default definitions that don't > typecheck even with DefaultSignatures. It would be nice to be able to use > them anyway. For example, if we have > > class Semigroup1 f where > op :: f a -> f a -> f a > > then we could, hypothetically, give a default definition for (<>): > > default (<>) :: Semigroup1 f => f a -> f a -> f a > (<>) = op > > But we can't give a default definition > > op = (<>) > > because there's no way to write its signature. However, for any F with > > instance Semigroup (F a) where ... > > the definition op = (<>) is perfectly fine. > > Would it be possible to offer a completely wild defaulting mechanism > allowing *any expression* as a default, and only checking its type and > compiling it when it's actually used? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcook at rcook.org Sat Sep 3 14:58:56 2016 From: rcook at rcook.org (Richard Cook) Date: Sat, 3 Sep 2016 07:58:56 -0700 Subject: Increasing version number of hsc2hs etc. Message-ID: Hi, I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the process around bumping the version number of hsc2hs and publishing a new version of this package to Hackage? -Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Sep 3 15:20:30 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 03 Sep 2016 11:20:30 -0400 Subject: Increasing version number of hsc2hs etc. In-Reply-To: References: Message-ID: <87eg51dn7l.fsf@smart-cactus.org> Richard Cook writes: > Hi, > > I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the > process around bumping the version number of hsc2hs and publishing a new > version of this package to Hackage? > I can handle this. Thanks for mentioning it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Sun Sep 4 13:32:10 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 04 Sep 2016 09:32:10 -0400 Subject: Increasing version number of hsc2hs etc. In-Reply-To: References: Message-ID: <87a8fneqp1.fsf@smart-cactus.org> Richard Cook writes: > Hi, > > I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the > process around bumping the version number of hsc2hs and publishing a new > version of this package to Hackage? > Richard, for the record Herbert said he would prefer to wait until we are closer to the 8.0.2 release until we push the new release. I've opened GHC Trac #12568 to ensure that we don't lose track of this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From rcook at rcook.org Sun Sep 4 13:56:26 2016 From: rcook at rcook.org (Richard Cook) Date: Sun, 4 Sep 2016 06:56:26 -0700 Subject: Increasing version number of hsc2hs etc. Message-ID: <-1025141162266060915@unknownmsgid> Perfect! Thanks for taking care of this. -RichardFrom: Ben Gamari Sent: ‎9/‎4/‎2016 6:32 AM To: rcook at rcook.org; ghc-devs at haskell.org Subject: Re: Increasing version number of hsc2hs etc. Richard Cook writes: > Hi, > > I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the > process around bumping the version number of hsc2hs and publishing a new > version of this package to Hackage? > Richard, for the record Herbert said he would prefer to wait until we are closer to the 8.0.2 release until we push the new release. I've opened GHC Trac #12568 to ensure that we don't lose track of this. Cheers, - Ben From ben at well-typed.com Mon Sep 5 16:15:03 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Sep 2016 12:15:03 -0400 Subject: Call for Nominations: GHC Steering Committee In-Reply-To: <87r39dq76d.fsf@smart-cactus.org> References: <87r39dq76d.fsf@smart-cactus.org> Message-ID: <87wpiqcohk.fsf@smart-cactus.org> Hello everyone, As you likely know, over the last few months we have been discussing options for reforming the process for proposing language and compiler changes to GHC. After much discussion, we have a process [1] which, while not perfect, is acceptable to a majority of our contributor base and will be an improvement over the status quo. While we invite suggestions for future improvements, we are at a point where we can move ahead with implementation. Consequently, we are seeking nominations for the initial GHC steering committee. This body is responsible for overseeing the progression of proposals through the process, working with authors on refining their ideas, and evaluating proposals for acceptance. The committee will consist of five to eight members of diverse backgrounds. We would like to offer the following as a criteria for membership. Note that a candidate is not expected to satisfy all or even most of these criteria, but a good candidate should satisfy at least one: * A history of contributions to the design of new language features * Experience developing Haskell libraries and applications * A demonstrated track record of contributing code to GHC * A pedagogical background, with experience in either teaching or authoring educational materials * Experience in compiler development * Knowledge of functional programming language theory I'd like to emphasize that committee membership is as much a duty as it is a privilege. Membership is not intended to be a platform to be used by members to drive their own ideas; rather it is a way of serving the Haskell community by helping other community members refine and advance their proposals. This, of course, requires an investment of time and effort, which you should be willing and able to consistently put forth. If you'd like to be considered for committee membership then please write a statement describing why you feel you are well-qualified to serve, in terms of the criteria above and any others that you would like to offer. Please send your statements to ben at well-typed.com by September 30th. The initial committee selection will be made by the Simons soon thereafter. Thanks to everyone for their feedback and cooperation so far! Cheers, - Ben [1] http://github.com/ghc-proposals/ghc-proposals -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Sep 5 16:40:59 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Sep 2016 16:40:59 +0000 Subject: cabal Message-ID: I’m trying to follow the instructions for https://ghc.haskell.org/trac/ghc/ticket/12562 But I get cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 cabal: unrecognised command: new-build (try --help) simonpj at cam-05-unx:~/tmp/llvm-general$ Maybe my Cabal is too old. I tried bash$ cabal install Cabal Resolving dependencies... Downloading Cabal-1.24.0.0... Configuring Cabal-1.24.0.0... Building Cabal-1.24.0.0... Installed Cabal-1.24.0.0 That worked. But I get the same message. Alas bash$ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library bash$ which cabal /home/simonpj/.cabal/bin/cabal Maybe I need 1.24. Which claims to be installed. But WHERE is it installed? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 5 16:45:17 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Sep 2016 12:45:17 -0400 Subject: cabal In-Reply-To: References: Message-ID: <87twducn36.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > I’m trying to follow the instructions for > https://ghc.haskell.org/trac/ghc/ticket/12562 > But I get > > cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 > > cabal: unrecognised command: new-build (try --help) > Indeed new-build is a new feature of cabal-install 1.24. > > simonpj at cam-05-unx:~/tmp/llvm-general$ > Maybe my Cabal is too old. I tried > > bash$ cabal install Cabal > > Resolving dependencies... > > Downloading Cabal-1.24.0.0... > > Configuring Cabal-1.24.0.0... > > Building Cabal-1.24.0.0... > > Installed Cabal-1.24.0.0 > That worked. But I get the same message. Alas > It's terribly confusing but the `cabal` executable is provided by the `cabal-install` package. Try `cabal install cabal-install`. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From allbery.b at gmail.com Mon Sep 5 16:50:18 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Sep 2016 12:50:18 -0400 Subject: cabal In-Reply-To: References: Message-ID: On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > bash$ which cabal > > /home/simonpj/.cabal/bin/cabal > > Maybe I need 1.24. Which claims to be installed. But WHERE is it > installed? > > Try "type cabal". "which" has a nasty tendency to show you what the next shell you open (or sometimes the next time you login) will see; shells remember what they've already seen, so it's probably still running the old one (likely in /usr/bin or /usr/local/bin). POSIX requires "type" to show what the *current* shell (thinks it) knows, not what some future shell will see. "hash -r" should work to reset the shell's idea of where cabal is, if "type" says it's running a different cabal. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Sep 5 18:27:26 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Sep 2016 20:27:26 +0200 Subject: Tooling-friendly ModSummary Message-ID: At the moment the standard way to use the GHC API is something like _ <- load LoadAllTargets modSum <- getModSummary mn p <- parseModule modSum And likewise if renamed or typechecked ASTs are needed. But the `load` step already does all those phases. So, would there be any objection to modifying the ModSummary to possibly retain those artifacts, configurable via a DynFlag? I would expect the flag would default to retaining none, but could then either provide for returning all artifacts, or just for the targets explicitly listed in the `setTargets` call (i.e. not the full `depanal` result). Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Sep 5 18:32:49 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Sep 2016 20:32:49 +0200 Subject: Tooling-friendly ModSummary In-Reply-To: References: Message-ID: And I gather I can do this with the compiler hooks. Alan On Mon, Sep 5, 2016 at 8:27 PM, Alan & Kim Zimmerman wrote: > At the moment the standard way to use the GHC API is something like > > _ <- load LoadAllTargets > modSum <- getModSummary mn > p <- parseModule modSum > > And likewise if renamed or typechecked ASTs are needed. > > But the `load` step already does all those phases. > > So, would there be any objection to modifying the ModSummary to possibly > retain those artifacts, configurable via a DynFlag? > > I would expect the flag would default to retaining none, but could then > either provide for returning all artifacts, or just for the targets > explicitly listed in the `setTargets` call (i.e. not the full `depanal` > result). > > Regards > Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 5 20:38:02 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Sep 2016 20:38:02 +0000 Subject: cabal In-Reply-To: References: Message-ID: Thanks Brandon. But I think Ben was probably right; I need cabal install cabal-install. Somehow this ought to be easier. I’ll try that when I next get a chance SImion From: Brandon Allbery [mailto:allbery.b at gmail.com] Sent: 05 September 2016 17:50 To: Simon Peyton Jones Cc: GHC developers Subject: Re: cabal On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs > wrote: bash$ which cabal /home/simonpj/.cabal/bin/cabal Maybe I need 1.24. Which claims to be installed. But WHERE is it installed? Try "type cabal". "which" has a nasty tendency to show you what the next shell you open (or sometimes the next time you login) will see; shells remember what they've already seen, so it's probably still running the old one (likely in /usr/bin or /usr/local/bin). POSIX requires "type" to show what the *current* shell (thinks it) knows, not what some future shell will see. "hash -r" should work to reset the shell's idea of where cabal is, if "type" says it's running a different cabal. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Sep 5 21:23:49 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 05 Sep 2016 14:23:49 -0700 Subject: Tooling-friendly ModSummary In-Reply-To: References: Message-ID: <1473108530-sup-3286@sabre> Hello Alan, SPJ and I both think that GhcMake is well overdue for a rewrite. But it's not altogether obvious what the rewrite should look like. I've made some remarks here: https://gist.github.com/ezyang/50004e0f842eec5848acad5cf1c22240 I'm OK with small, incremental changes that make tooling's life better. But adding renamed/typechecked ASTs is almost certainly the wrong thing to do. The ModSummary is produced by looking at an hs file and doing the bare minimum processing to get the import graph. The way the pipeline works is a ModSummary is eventually turned into a HomeModInfo by the typechecking process. So one possibility is that if it is requested (retaining renamed, typechecked ASTs increases memory consumption for clients that don't need it) the things you want could be stashed in HomeModInfo. So you'd probably augment FrontendResult to return the information you need, and then hscIncrementalCompile to stick it in HomeModInfo. Things to be careful about: - You will NOT get this info if you load the HomeModInfo from disk rather than compile it directly. I am assuming that you have a way to convince 'load' to rebuild; I don't actually know how to do this. - We don't want to save this info by default; it will increase memory usage for anyone who doesn't need it (e.g., ghc --make) Hope that helps, Edward Excerpts from Alan & Kim Zimmerman's message of 2016-09-05 20:27:26 +0200: > At the moment the standard way to use the GHC API is something like > > _ <- load LoadAllTargets > modSum <- getModSummary mn > p <- parseModule modSum > > And likewise if renamed or typechecked ASTs are needed. > > But the `load` step already does all those phases. > > So, would there be any objection to modifying the ModSummary to possibly > retain those artifacts, configurable via a DynFlag? > > I would expect the flag would default to retaining none, but could then > either provide for returning all artifacts, or just for the targets > explicitly listed in the `setTargets` call (i.e. not the full `depanal` > result). > > Regards > Alan From matthewtpickering at gmail.com Tue Sep 6 08:34:36 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 6 Sep 2016 09:34:36 +0100 Subject: OSX Test Failures Message-ID: Occasionally a do a full validate on OSX, there are usually some tests which fail but not on other systems. I usually don't report these failures as there are always some and they are usually do to do with parts of the compiler I don't know anything about. However, on https://phabricator.haskell.org/D2485 Richard (Fung) and Ben were discussing these failures which I have also seen so it seems I would have wasted less time if I had reported these somewhere. What is the expectation for OSX? Should the test suite be entirely clean? Should I create issues when some of the tests get broken? Matt From ben at well-typed.com Tue Sep 6 14:04:18 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 06 Sep 2016 10:04:18 -0400 Subject: OSX Test Failures In-Reply-To: References: Message-ID: <87r38xruot.fsf@smart-cactus.org> Matthew Pickering writes: > Occasionally a do a full validate on OSX, there are usually some tests > which fail but not on other systems. I usually don't report these > failures as there are always some and they are usually do to do with > parts of the compiler I don't know anything about. > > However, on https://phabricator.haskell.org/D2485 Richard (Fung) and > Ben were discussing these failures which I have also seen so it seems > I would have wasted less time if I had reported these somewhere. > > What is the expectation for OSX? Should the test suite be entirely > clean? Should I create issues when some of the tests get broken? > Indeed it should always build. Really OS X is Tier 1 platform and as such should have a build bot. I'm trying to get Futurice's OS X machine setup as a Harbormaster node but technology has a way of fighting back. Regardless, it would be quite helpful if you could file a bug documenting these. By the way, do you recall when you started seeing these failures? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Tue Sep 6 14:34:10 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 6 Sep 2016 15:34:10 +0100 Subject: OSX Test Failures In-Reply-To: <87r38xruot.fsf@smart-cactus.org> References: <87r38xruot.fsf@smart-cactus.org> Message-ID: The last time I did a full validate was about two weeks ago, I saw the same failures as you described on the ticket. I will report the issues from now. Matt On Tue, Sep 6, 2016 at 3:04 PM, Ben Gamari wrote: > Matthew Pickering writes: > >> Occasionally a do a full validate on OSX, there are usually some tests >> which fail but not on other systems. I usually don't report these >> failures as there are always some and they are usually do to do with >> parts of the compiler I don't know anything about. >> >> However, on https://phabricator.haskell.org/D2485 Richard (Fung) and >> Ben were discussing these failures which I have also seen so it seems >> I would have wasted less time if I had reported these somewhere. >> >> What is the expectation for OSX? Should the test suite be entirely >> clean? Should I create issues when some of the tests get broken? >> > Indeed it should always build. Really OS X is Tier 1 platform and as > such should have a build bot. I'm trying to get Futurice's OS X machine > setup as a Harbormaster node but technology has a way of fighting back. > > Regardless, it would be quite helpful if you could file a bug > documenting these. By the way, do you recall when you started seeing > these failures? > > Cheers, > > - Ben From david.feuer at gmail.com Wed Sep 7 14:39:34 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 7 Sep 2016 10:39:34 -0400 Subject: Custom warning suppression In-Reply-To: References: Message-ID: Currently, the only way to suppress custom warnings and deprecations is with -fno-warn-warnings-deprecations, which is a rather large hammer. I see two ways we can improve this, and I propose that we should do both. 1. Per-binding suppression Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and -fdeprecate-binding options. These would take the (optionally qualified) name of a binding and control warnings tied to it. So if you invoked -fno-warn-binding "sillyFunction", then GHC would not warn you about the silliness of anything named sillyFunction. -fno-warn-binding "Data.Silly.sillyFunction" would limit the suppression to the silly function in Data.Silly. -fno-deprecate-binding would refrain from emitting deprecation warnings for the binding in question. -fno-deprecate-binding would presumably imply no-warn-binding, since someone who doesn't care that a function is going to be removed probably also doesn't care what else is wrong with it. 2. Named warning classes I'd like to add an optional "warning class" to the WARNING pragma, preceding the warning description. This would be a short string indicating what sort of warning is involved. This would be totally free-form, but the documentation would suggest a few conventional options such as "partial" and "slow". Then whole warning classes could be controlled with -fno-warn-class and -first-class. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Sep 7 15:09:02 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 7 Sep 2016 11:09:02 -0400 Subject: Custom warning suppression In-Reply-To: References: Message-ID: Seems reasonable and useful to me. Is this a good use of the process here? https://github.com/ghc-proposals/ghc-proposals > On Sep 7, 2016, at 10:39 AM, David Feuer wrote: > > Currently, the only way to suppress custom warnings and deprecations is with -fno-warn-warnings-deprecations, which is a rather large hammer. I see two ways we can improve this, and I propose that we should do both. > > 1. Per-binding suppression > > Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and -fdeprecate-binding options. These would take the (optionally qualified) name of a binding and control warnings tied to it. So if you invoked -fno-warn-binding "sillyFunction", then GHC would not warn you about the silliness of anything named sillyFunction. -fno-warn-binding "Data.Silly.sillyFunction" would limit the suppression to the silly function in Data.Silly. -fno-deprecate-binding would refrain from emitting deprecation warnings for the binding in question. -fno-deprecate-binding would presumably imply no-warn-binding, since someone who doesn't care that a function is going to be removed probably also doesn't care what else is wrong with it. > > 2. Named warning classes > > I'd like to add an optional "warning class" to the WARNING pragma, preceding the warning description. This would be a short string indicating what sort of warning is involved. This would be totally free-form, but the documentation would suggest a few conventional options such as "partial" and "slow". Then whole warning classes could be controlled with -fno-warn-class and -first-class. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Sep 7 15:39:25 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 07 Sep 2016 11:39:25 -0400 Subject: Restartable sequences Message-ID: <87inu7sor6.fsf@smart-cactus.org> While I'll admit that I'm not terribly familiar with our STM implementation, it came to mind while I was reading this article [1] on the restartable sequences mechanism that might someday land in the Linux kernel. I thought you both might be interested. Cheers, - Ben [1] http://lwn.net/Articles/697979/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Wed Sep 7 16:28:53 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 07 Sep 2016 12:28:53 -0400 Subject: Grand Plan for 8.0.2 Message-ID: <87fupbsmgq.fsf@smart-cactus.org> tl;dr: GHC 8.0.2 is coming, however there are a number of issues we would like to see resolved. Consequently it's not entirely clear when it will arrive, but if things go well it may be as early as this Friday. Hello everyone, Over the past few weeks I've been making preparations for the coming 8.0.2 release. I've merged a few more patches to the stable branch in response to last week's call for merge requests, bringing the total up to 180 commits since 8.0.1. At this point there are only a couple things that remain to be cleared up, * #12220, #12533: These are unfortunate behaviors of default signatures, #12220 being an interaction with type applications and #12533 being an obscure corner case. While we have a fix for these (d2958bd0), the fix changes the behavior of the typechecker's inaccessible code check, breaking some code on Hackage; this is documented as #12466. There are some tricky unresolved questions here regarding how we want the inaccessible code here to behave. At the moment I am leaning towards simply punting these off to 8.2.1. If you would like to see them fixed in 8.0.2, please say so. Moreover, please contribute your thoughts on #12466 as resolving the remaining questions on that ticket is a prerequisite for merging the fix for #12220. * #12954: Currently Haddock does not produce documentation for bundled pattern synonyms. There is a pull request [1] that may fix this but it is currently needing reviewers. It would be great to fix this for 8.0.2, but ultimately someone is going to need to finish this up. * #10986: This is a rather unfortunate leak of temporary files which we would ideally fix since it can produce rather large temporary directories on the user's system. * #12519: Haddock inexplicably forgets to render the class members of Eq and Ord. It would be great if someone could get to the bottom of this. * #12433 is a rather nasty correctness bug which currently has no resolution. * #11819: There are still a number of full validation issues which would be nice to sort out. I would like to be able to say that we have a concrete timeline for a 8.0.2 release and I was originally planning to propose a candidate source release for late this week, however in light of the the large number of unresolved issues, I think it would be unwise to commit to this timeframe. I'll say that the candidate source tarball could come as early as Friday, although sometime next week is far more likely. As always, any help that you could offer on any of the above issues would be greatly appreciated. Cheers, - Ben [1] https://github.com/haskell/haddock/pull/494/commits/7984c8fb8f238793641a419c93fbcb4f6e933ae5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From david.feuer at gmail.com Wed Sep 7 18:32:50 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 7 Sep 2016 14:32:50 -0400 Subject: Feature request bounty Message-ID: I'd like to place a small bounty on https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . If someone implements this request by GHC 8.2, I will buy them 24 bottles of high-end root beer (e.g., Maine Root) or something of similar value agreeable to both parties. (*) Thanks, David Feuer (*) Recipient responsible for customs/duty/taxes/shipping fees beyond US$10. From eacameron at gmail.com Wed Sep 7 18:36:59 2016 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 7 Sep 2016 14:36:59 -0400 Subject: Custom warning suppression In-Reply-To: References: Message-ID: I would love this. Especially if we then added "partial" warnings to the many Prelude/base functions that fit this description. On Wed, Sep 7, 2016 at 11:09 AM, Richard Eisenberg wrote: > Seems reasonable and useful to me. Is this a good use of the process here? > https://github.com/ghc-proposals/ghc-proposals > > On Sep 7, 2016, at 10:39 AM, David Feuer wrote: > > Currently, the only way to suppress custom warnings and deprecations is > with -fno-warn-warnings-deprecations, which is a rather large hammer. I > see two ways we can improve this, and I propose that we should do both. > > 1. Per-binding suppression > > Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and > -fdeprecate-binding options. These would take the (optionally qualified) > name of a binding and control warnings tied to it. So if you invoked > -fno-warn-binding "sillyFunction", then GHC would not warn you about the > silliness of anything named sillyFunction. -fno-warn-binding > "Data.Silly.sillyFunction" would limit the suppression to the silly > function in Data.Silly. -fno-deprecate-binding would refrain from emitting > deprecation warnings for the binding in question. -fno-deprecate-binding > would presumably imply no-warn-binding, since someone who doesn't care that > a function is going to be removed probably also doesn't care what else is > wrong with it. > > 2. Named warning classes > > I'd like to add an optional "warning class" to the WARNING pragma, > preceding the warning description. This would be a short string indicating > what sort of warning is involved. This would be totally free-form, but the > documentation would suggest a few conventional options such as "partial" > and "slow". Then whole warning classes could be controlled with > -fno-warn-class and -first-class. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 7 20:46:49 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Sep 2016 20:46:49 +0000 Subject: Feature request bounty In-Reply-To: References: Message-ID: I can advise about how (see comment:9 of #1965). I can only see how to do it in an un-typed way in the back end. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David | Feuer | Sent: 07 September 2016 19:33 | To: ghc-devs | Subject: Feature request bounty | | I'd like to place a small bounty on | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . | | If someone implements this request by GHC 8.2, I will buy them 24 bottles | of high-end root beer (e.g., Maine Root) or something of similar value | agreeable to both parties. (*) | | Thanks, | David Feuer | | (*) Recipient responsible for customs/duty/taxes/shipping fees beyond | US$10. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74 | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda | ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d From david.feuer at gmail.com Wed Sep 7 20:58:09 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 7 Sep 2016 16:58:09 -0400 Subject: Feature request bounty In-Reply-To: References: Message-ID: I can't guarantee I'll be able to understand things well enough to take your advice, but I'd be willing to give it a shot. Where would be the right place to stick this? I am not at all familiar with the GHC code generation system. Also, what might I have to do to avoid forcing the same object repeatedly? If I have multiple such constructors, and someone does case x of Con1 (Con2 (Con3 (Con4 y))) -> e I want to smash this down to something that looks like case x of y { _ -> e } Do I need to worry about this, or will some later C-- pass take care of it? On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones wrote: > I can advise about how (see comment:9 of #1965). I can only see how to do it in an un-typed way in the back end. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David > | Feuer > | Sent: 07 September 2016 19:33 > | To: ghc-devs > | Subject: Feature request bounty > | > | I'd like to place a small bounty on > | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . > | > | If someone implements this request by GHC 8.2, I will buy them 24 bottles > | of high-end root beer (e.g., Maine Root) or something of similar value > | agreeable to both parties. (*) > | > | Thanks, > | David Feuer > | > | (*) Recipient responsible for customs/duty/taxes/shipping fees beyond > | US$10. > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask > | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74 > | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda > | ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d From rrnewton at gmail.com Wed Sep 7 21:32:21 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 7 Sep 2016 17:32:21 -0400 Subject: Do we have free bits in the info pointer itself? Message-ID: Our heap object header is one word -- an info table pointer . Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the object header for other purposes, right? Is there any problem with using these other than having to mask the info table pointer each time it is dereferenced? Thanks, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Sep 7 22:10:27 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 07 Sep 2016 15:10:27 -0700 Subject: Thoughts on CallStack and withFrozenCallStack Message-ID: <1473285524-sup-5531@sabre> I've been adding CallStack to Cabal's source code, and I noticed a common pattern that doesn't seem to be supported by the GHC.Stack API. Imagine I'm writing a general purpose logging function: debug :: Verbosity -> String -> IO () I'd like this function to print out the SrcLoc of the person who called; as an additional requirement, I only want to print the top-most stack frame by default (someone can ask for the full stack if they really want to). If I look at callStack, it is going to contain a stack frame for debug itself. That's not so great; the obvious way to fix this is to pop off the irrelevant frame manually. But now suppose that I have a pprDebug which itself calls debug. I don't want pprDebug to show up in the stack frame! Declaratively, I want to say, "Please don't add me to the call stack", at the function *definition*, not the call-site (which is what withFrozenCallStack) gives me. Does this seem like a reasonable request? I have several other ways to do this: - You could just use withFrozenCallStack at the definition site. Then when pprDebug calls debug, debug will get the call stack that pprDebug had; thus, there will always only be one irrelevant frame to pop off. - One problem with using withFrozenCallStack is that you *do* lose useful trace information, which you kind of might actually want if you are being verbose. So it almost seems like, the frozen API should still *push* frames, but just not make them visible by default. - Something that does NOT work is having functions edit the call stack to remove themselves. There's no way to tell if the stack is frozen or not, and thus no way to tell if you are actually on the stack (and need to remove it.) Thanks, Edward From eric at seidel.io Thu Sep 8 01:14:16 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 07 Sep 2016 18:14:16 -0700 Subject: Thoughts on CallStack and withFrozenCallStack In-Reply-To: <1473285524-sup-5531@sabre> References: <1473285524-sup-5531@sabre> Message-ID: <1473297256.2540341.719059337.3BBA9F12@webmail.messagingengine.com> On Wed, Sep 7, 2016, at 15:10, Edward Z. Yang wrote: > I've been adding CallStack to Cabal's source code, and I noticed > a common pattern that doesn't seem to be supported by the GHC.Stack > API. > > Imagine I'm writing a general purpose logging function: > > debug :: Verbosity -> String -> IO () > > I'd like this function to print out the SrcLoc of the person who > called; as an additional requirement, I only want to print the > top-most stack frame by default (someone can ask for the full > stack if they really want to). > > If I look at callStack, it is going to contain a stack frame for debug > itself. That's not so great; the obvious way to fix this is to pop off > the irrelevant frame manually. Inside debug, the top element of the callStack should be the call-site of debug, which should be exactly what you want. (NB this is new behavior as of GHC 8.0.1, in GHC 7.10.2 you would get an extra frame for the occurrence of ?callStack) > But now suppose that I have a pprDebug > which itself calls debug. I don't want pprDebug to show up in the stack > frame! > > Declaratively, I want to say, "Please don't add me to the call stack", > at the function *definition*, not the call-site (which is what > withFrozenCallStack) gives me. Does this seem like a reasonable request? Indeed, this sounds useful. The approach I recently took with adding CallStacks to logs was to have the internal functions (eg formatting and actually printing the logs) take an *explicit* CallStack, and have the external functions take an *implicit* CallStack. Thus the internal functions are excluded from the stack. But this does give us slightly less reuse as, in your example, you couldn't implement pprDebug in terms of debug if you also want to export debug. > I have several other ways to do this: > > - You could just use withFrozenCallStack at the definition site. > Then when pprDebug calls debug, debug will get the call stack that > pprDebug had; thus, there will always only be one irrelevant frame > to pop off. > > - One problem with using withFrozenCallStack is that you *do* lose > useful trace information, which you kind of might actually want > if you are being verbose. So it almost seems like, the frozen > API should still *push* frames, but just not make them visible > by default. Good point! Another way this could be useful is if you happen to have a frozen CallStack already in-scope at the call-site of debug/pprDebug. In that scenario, the call-site of the logging function would be lost, and you'd end up printing whatever location was at the top of the frozen stack, which would be quite confusing! Thanks for the comments! Eric From omeragacan at gmail.com Thu Sep 8 01:19:32 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 7 Sep 2016 21:19:32 -0400 Subject: Feature request bounty In-Reply-To: References: Message-ID: Simon, As far as I understand we want to do these two transformations: (when D is a newtype-like data type constructor) First: D arg1 arg2 ... argN ==> nv_arg (where nv_arg is the only non-void argument) (but we somehow need to bind other args or do substitution. If we do this Stg though we don't need to bind those args as unarise doesn't care about what a void argument is as long as it's void it gets rid of it and it can check void-ness by looking at Id's type) Second: case of D arg1 arg2 ... argN -> ==> let arg1 = ... arg2 = ... arg3 = ... in (we know only one of these args will be non-void, but all of them should be bound as they can be referred in ) Am I right? I think if we do this in Stg we lose some optimization opportunities and generate ugly code. For example, if the first transformation happens in a let-binding RHS maybe simplifier decides to inline it as it can't duplicate work after the transformation. Similarly it can decide to inline the non-void argument after second transformation which may lead to further optimizations etc. For an example of an ugly code, suppose we had this: case of D (T x) -> in Stg this looks like case of D v -> case v of T x -> So now if we do the second transformation we get let v = in case v of T x -> but ideally we'd get case of T x -> I think simplifier would be able to do this after the second transformation. Am I making any sense? I have no idea how to do this in the simplifier without losing type safety though... Are these two transformations also what you had in mind or do you have something else? - Omer 2016-09-07 16:58 GMT-04:00 David Feuer : > I can't guarantee I'll be able to understand things well enough to > take your advice, but I'd be willing to give it a shot. Where would be > the right place to stick this? I am not at all familiar with the GHC > code generation system. Also, what might I have to do to avoid forcing > the same object repeatedly? If I have multiple such constructors, and > someone does > > case x of > Con1 (Con2 (Con3 (Con4 y))) -> e > > I want to smash this down to something that looks like > > case x of y { > _ -> e } > > Do I need to worry about this, or will some later C-- pass take care of it? > > On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones > wrote: >> I can advise about how (see comment:9 of #1965). I can only see how to do it in an un-typed way in the back end. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David >> | Feuer >> | Sent: 07 September 2016 19:33 >> | To: ghc-devs >> | Subject: Feature request bounty >> | >> | I'd like to place a small bounty on >> | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . >> | >> | If someone implements this request by GHC 8.2, I will buy them 24 bottles >> | of high-end root beer (e.g., Maine Root) or something of similar value >> | agreeable to both parties. (*) >> | >> | Thanks, >> | David Feuer >> | >> | (*) Recipient responsible for customs/duty/taxes/shipping fees beyond >> | US$10. >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.hask >> | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e4408d3d74 >> | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636088699768302440&sda >> | ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ekmett at gmail.com Thu Sep 8 03:16:07 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 7 Sep 2016 23:16:07 -0400 Subject: Do we have free bits in the info pointer itself? In-Reply-To: References: Message-ID: Mostly just that GHC still works on 32 bit platforms. -Edward On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton wrote: > Our heap object header is one word -- an info table pointer > > . > > Well, a 64 bit info table pointer leaves *at least* 16 high bits inside > the object header for other purposes, right? > > Is there any problem with using these other than having to mask the info > table pointer each time it is dereferenced? > > Thanks, > -Ryan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Thu Sep 8 03:55:38 2016 From: rwbarton at gmail.com (Reid Barton) Date: Wed, 7 Sep 2016 23:55:38 -0400 Subject: Do we have free bits in the info pointer itself? In-Reply-To: References: Message-ID: Good point. Also * the high bits are free now, but they may not be free forever (though that's not a great reason to avoid using them in the meantime) * masking off the high bits when entering is rather expensive, at least in code size, compared to a simple "jmp *%rax" or especially "jmp *symb", which appears at the end of almost every Haskell function * modifying the low bits of a pointer will leave it pointing at the same cache line, so the hardware prefetcher may decide to prefetch the contents (hopefully at an appropriate time) while modifying the high bits will make it not look like a pointer at all. But it's hard to know how much we currently gain from hardware prefetching, if anything. Certainly these downsides are not necessarily deal-breakers, as demonstrated by NaN-boxing as used in major JavaScript engines. What did you intend to use the high bits for? Regards, Reid Barton On Wed, Sep 7, 2016 at 11:16 PM, Edward Kmett wrote: > Mostly just that GHC still works on 32 bit platforms. > > -Edward > > On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton wrote: >> >> Our heap object header is one word -- an info table pointer. >> >> Well, a 64 bit info table pointer leaves *at least* 16 high bits inside >> the object header for other purposes, right? >> >> Is there any problem with using these other than having to mask the info >> table pointer each time it is dereferenced? >> >> Thanks, >> -Ryan >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ezyang at mit.edu Thu Sep 8 04:40:07 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 07 Sep 2016 21:40:07 -0700 Subject: Thoughts on CallStack and withFrozenCallStack In-Reply-To: <1473297256.2540341.719059337.3BBA9F12@webmail.messagingengine.com> References: <1473285524-sup-5531@sabre> <1473297256.2540341.719059337.3BBA9F12@webmail.messagingengine.com> Message-ID: <1473308192-sup-2766@sabre> So, I also experimented with setting up this type alias in our Prelude: type IO a = HasCallStack => Prelude.IO a It hasn't caused many type checking errors, but here are some observations: - It can cause a lot of redundant constraint warnings. Often with good reason (sometimes, it indicates somewhere that could use the call stack profitably, but isn't at the moment.) In cases where it doesn't, I've been suppressing the message with "_ = callStack", which works well enough :) - When interoperating with functions like 'bracket' which take an IO action as an argument, I often need to take the type "a -> HasCallStack => Prelude.IO b" into "a -> Prelude.IO b" (so that I can use the function defined in base.) This function lets me do the conversion: withLexicalCallStack :: (a -> WithCallStack (IO b)) -> WithCallStack (a -> IO b) withLexicalCallStack f = let stk = ?callStack in \x -> let ?callStack = stk in f x I'm obviously happy to bikeshed names. - I don't think adding implicit parameters in this way can ever cause us to lose tail-call optimization, but the CallStack might grow really big. I guess there isn't any pruning done? Essentially, you have to be very careful about IO actions which call themselves in loops. Also, here are some responses to Eric's message: Excerpts from Eric Seidel's message of 2016-09-07 18:14:16 -0700: > Inside debug, the top element of the callStack should be the call-site > of debug, which should be exactly what you want. (NB this is new > behavior as of GHC 8.0.1, in GHC 7.10.2 you would get an extra frame for > the occurrence of ?callStack) Yes, you are right! > Indeed, this sounds useful. The approach I recently took with adding > CallStacks to logs was to have the internal functions (eg formatting and > actually printing the logs) take an *explicit* CallStack, and have the > external functions take an *implicit* CallStack. Thus the internal > functions are excluded from the stack. But this does give us slightly > less reuse as, in your example, you couldn't implement pprDebug in terms > of debug if you also want to export debug. Yes, that workaround does work, but I don't like it! > Good point! Another way this could be useful is if you happen to have a > frozen CallStack already in-scope at the call-site of debug/pprDebug. In > that scenario, the call-site of the logging function would be lost, and > you'd end up printing whatever location was at the top of the frozen > stack, which would be quite confusing! Precisely. From rrnewton at gmail.com Thu Sep 8 04:42:06 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Thu, 8 Sep 2016 00:42:06 -0400 Subject: Do we have free bits in the info pointer itself? In-Reply-To: References: Message-ID: > > What did you intend to use the high bits for? > Nothing right now. Just speculation. I was actually pondering how our headers are rather svelte compared to many languages. Java, for instance, saves a full word for a hash. There are endless bits of metadata to speculate about... - whether or not the heap object is frozen to disallow further modification (e.g. for MutVars) - whether or not the heap object is part of a contiguous CNF - a flag to invoke some alternate GC behavior - metadata to avoid dereferencing the info table pointer in some circumstances (common type tags?) - you could even index 2^16 per-type values that live off of the info table But most likely it would have to be something that would give across the board perf improvements that would pay for the extra cost in masking. Good point re: HW prefetching. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Sep 8 07:19:52 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 8 Sep 2016 09:19:52 +0200 Subject: Grand Plan for 8.0.2 In-Reply-To: <87fupbsmgq.fsf@smart-cactus.org> References: <87fupbsmgq.fsf@smart-cactus.org> Message-ID: I imagine I have completely missed the boat on this one, but would like to test the waters on including the following [1] patch --------------------------------------------- Add hook for creating ghci external interpreter The external interpreter is launched by calling 'System.Process.createProcess' with a 'CreateProcess' parameter. The current value for this has the 'std_in', 'std_out' and 'std_err' fields use the default of 'Inherit', meaning that the remote interpreter shares the stdio with the original ghc/ghci process. This patch introduces a new hook to the DynFlags, which has an opportunity to override the 'CreateProcess' fields, launch the process, and retrieve the stdio handles actually used. So if a ghci external interpreter session is launched from the GHC API the stdio can be redirected if required, which is useful for tooling/IDE integration. ----------------------------- It is not behaviour-changing unless the hook is actually used, but does make a change to Hooks and hence DynFlags. I think it can potentially make a lot more options available for IDE tooling, and it would be great to have it available in GHC 8.0.x already. Alan [1] https://github.com/alanz/ghc/commit/6225d94056400c525a2b710aa31a74b5ea1d5f62 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Sep 8 11:21:55 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 8 Sep 2016 11:21:55 +0000 Subject: Feature request bounty In-Reply-To: References: Message-ID: Omer: yes you have it right. I agree with your remarks about follow-up simplifications. That's jolly annoying. I don't know a good path here. I suppose we could make a simple STG simplifier.... Stuff on email gets lost/buried. Would you like to extend the wiki page with your implementation notes? That would capture them. Simon | -----Original Message----- | From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] | Sent: 08 September 2016 02:20 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: Feature request bounty | | Simon, | | As far as I understand we want to do these two transformations: | | (when D is a newtype-like data type constructor) | | | First: | D arg1 arg2 ... argN | ==> | nv_arg (where nv_arg is the only non-void argument) | | (but we somehow need to bind other args or do substitution. If we do | this | Stg though we don't need to bind those args as unarise doesn't care | about | what a void argument is as long as it's void it gets rid of it and it | can | check void-ness by looking at Id's type) | | Second: | case of | D arg1 arg2 ... argN -> | ==> | let arg1 = ... | arg2 = ... | arg3 = ... | in | (we know only one of these args will be non-void, but all of them | should be | bound as they can be referred in ) | | Am I right? | | I think if we do this in Stg we lose some optimization opportunities and | generate ugly code. For example, if the first transformation happens in a | let-binding RHS maybe simplifier decides to inline it as it can't | duplicate work after the transformation. Similarly it can decide to | inline the non-void argument after second transformation which may lead | to further optimizations etc. | | For an example of an ugly code, suppose we had this: | | case of | D (T x) -> | | in Stg this looks like | | case of | D v -> case v of | T x -> | | So now if we do the second transformation we get | | let v = in | case v of | T x -> | | but ideally we'd get | | case of | T x -> | | I think simplifier would be able to do this after the second | transformation. | Am I making any sense? | | I have no idea how to do this in the simplifier without losing type | safety though... | | Are these two transformations also what you had in mind or do you have | something else? | | - Omer | | 2016-09-07 16:58 GMT-04:00 David Feuer : | > I can't guarantee I'll be able to understand things well enough to | > take your advice, but I'd be willing to give it a shot. Where would be | > the right place to stick this? I am not at all familiar with the GHC | > code generation system. Also, what might I have to do to avoid forcing | > the same object repeatedly? If I have multiple such constructors, and | > someone does | > | > case x of | > Con1 (Con2 (Con3 (Con4 y))) -> e | > | > I want to smash this down to something that looks like | > | > case x of y { | > _ -> e } | > | > Do I need to worry about this, or will some later C-- pass take care of | it? | > | > On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones | > wrote: | >> I can advise about how (see comment:9 of #1965). I can only see how | to do it in an un-typed way in the back end. | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | >> | David Feuer | >> | Sent: 07 September 2016 19:33 | >> | To: ghc-devs | >> | Subject: Feature request bounty | >> | | >> | I'd like to place a small bounty on | >> | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . | >> | | >> | If someone implements this request by GHC 8.2, I will buy them 24 | >> | bottles of high-end root beer (e.g., Maine Root) or something of | >> | similar value agreeable to both parties. (*) | >> | | >> | Thanks, | >> | David Feuer | >> | | >> | (*) Recipient responsible for customs/duty/taxes/shipping fees | >> | beyond US$10. | >> | _______________________________________________ | >> | ghc-devs mailing list | >> | ghc-devs at haskell.org | >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai | >> | l.hask | >> | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | >> | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e440 | >> | 8d3d74 | >> | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c6360886997683024 | >> | 40&sda ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=02%7c01%7csi | > monpj%40microsoft.com%7c0cd3f91c657b41f8492108d3d7864917%7c72f988bf86f | > 141af91ab2d7cd011db47%7c1%7c0%7c636088944161132661&sdata=mfmxH%2bRbgRs | > XHzv6O0gBDC0DKzgi%2fNdNGxpxFOWEWqo%3d From omeragacan at gmail.com Thu Sep 8 20:58:34 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 8 Sep 2016 16:58:34 -0400 Subject: Feature request bounty In-Reply-To: References: Message-ID: I updated implementation section of the wiki page (https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS). 2016-09-08 7:21 GMT-04:00 Simon Peyton Jones : > Omer: yes you have it right. > > I agree with your remarks about follow-up simplifications. That's jolly annoying. > > I don't know a good path here. I suppose we could make a simple STG simplifier.... > > Stuff on email gets lost/buried. Would you like to extend the wiki page with your implementation notes? That would capture them. > > Simon > > | -----Original Message----- > | From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] > | Sent: 08 September 2016 02:20 > | To: Simon Peyton Jones > | Cc: ghc-devs > | Subject: Re: Feature request bounty > | > | Simon, > | > | As far as I understand we want to do these two transformations: > | > | (when D is a newtype-like data type constructor) > | > | > | First: > | D arg1 arg2 ... argN > | ==> > | nv_arg (where nv_arg is the only non-void argument) > | > | (but we somehow need to bind other args or do substitution. If we do > | this > | Stg though we don't need to bind those args as unarise doesn't care > | about > | what a void argument is as long as it's void it gets rid of it and it > | can > | check void-ness by looking at Id's type) > | > | Second: > | case of > | D arg1 arg2 ... argN -> > | ==> > | let arg1 = ... > | arg2 = ... > | arg3 = ... > | in > | (we know only one of these args will be non-void, but all of them > | should be > | bound as they can be referred in ) > | > | Am I right? > | > | I think if we do this in Stg we lose some optimization opportunities and > | generate ugly code. For example, if the first transformation happens in a > | let-binding RHS maybe simplifier decides to inline it as it can't > | duplicate work after the transformation. Similarly it can decide to > | inline the non-void argument after second transformation which may lead > | to further optimizations etc. > | > | For an example of an ugly code, suppose we had this: > | > | case of > | D (T x) -> > | > | in Stg this looks like > | > | case of > | D v -> case v of > | T x -> > | > | So now if we do the second transformation we get > | > | let v = in > | case v of > | T x -> > | > | but ideally we'd get > | > | case of > | T x -> > | > | I think simplifier would be able to do this after the second > | transformation. > | Am I making any sense? > | > | I have no idea how to do this in the simplifier without losing type > | safety though... > | > | Are these two transformations also what you had in mind or do you have > | something else? > | > | - Omer > | > | 2016-09-07 16:58 GMT-04:00 David Feuer : > | > I can't guarantee I'll be able to understand things well enough to > | > take your advice, but I'd be willing to give it a shot. Where would be > | > the right place to stick this? I am not at all familiar with the GHC > | > code generation system. Also, what might I have to do to avoid forcing > | > the same object repeatedly? If I have multiple such constructors, and > | > someone does > | > > | > case x of > | > Con1 (Con2 (Con3 (Con4 y))) -> e > | > > | > I want to smash this down to something that looks like > | > > | > case x of y { > | > _ -> e } > | > > | > Do I need to worry about this, or will some later C-- pass take care of > | it? > | > > | > On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones > | > wrote: > | >> I can advise about how (see comment:9 of #1965). I can only see how > | to do it in an un-typed way in the back end. > | >> > | >> Simon > | >> > | >> | -----Original Message----- > | >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | >> | David Feuer > | >> | Sent: 07 September 2016 19:33 > | >> | To: ghc-devs > | >> | Subject: Feature request bounty > | >> | > | >> | I'd like to place a small bounty on > | >> | https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . > | >> | > | >> | If someone implements this request by GHC 8.2, I will buy them 24 > | >> | bottles of high-end root beer (e.g., Maine Root) or something of > | >> | similar value agreeable to both parties. (*) > | >> | > | >> | Thanks, > | >> | David Feuer > | >> | > | >> | (*) Recipient responsible for customs/duty/taxes/shipping fees > | >> | beyond US$10. > | >> | _______________________________________________ > | >> | ghc-devs mailing list > | >> | ghc-devs at haskell.org > | >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai > | >> | l.hask > | >> | ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | >> | devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac6406e1e440 > | >> | 8d3d74 > | >> | d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c6360886997683024 > | >> | 40&sda ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=02%7c01%7csi > | > monpj%40microsoft.com%7c0cd3f91c657b41f8492108d3d7864917%7c72f988bf86f > | > 141af91ab2d7cd011db47%7c1%7c0%7c636088944161132661&sdata=mfmxH%2bRbgRs > | > XHzv6O0gBDC0DKzgi%2fNdNGxpxFOWEWqo%3d From mail at joachim-breitner.de Thu Sep 8 21:05:10 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 08 Sep 2016 17:05:10 -0400 Subject: Feature request bounty In-Reply-To: References: Message-ID: <1473368710.16816.0.camel@joachim-breitner.de> Hi, slightly related (an other optimization around data types that is possible in STG, but not in Core): https://ghc.haskell.org/trac/ghc/ticket/9291 Greetings, Joachim Am Donnerstag, den 08.09.2016, 16:58 -0400 schrieb Ömer Sinan Ağacan: > I updated implementation section of the wiki page > (https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS). > > 2016-09-08 7:21 GMT-04:00 Simon Peyton Jones : > > > > Omer: yes you have it right. > > > > I agree with your remarks about follow-up simplifications.  That's > > jolly annoying. > > > > I don't know a good path here.  I suppose we could make a simple > > STG simplifier.... > > > > Stuff on email gets lost/buried. Would you like to extend the wiki > > page with your implementation notes?  That would capture them. > > > > Simon > > > > > > > > -----Original Message----- > > > From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] > > > Sent: 08 September 2016 02:20 > > > To: Simon Peyton Jones > > > Cc: ghc-devs > > > Subject: Re: Feature request bounty > > > > > > Simon, > > > > > > As far as I understand we want to do these two transformations: > > > > > > (when D is a newtype-like data type constructor) > > > > > > > > > First: > > >     D arg1 arg2 ... argN > > >     ==> > > >     nv_arg (where nv_arg is the only non-void argument) > > > > > >     (but we somehow need to bind other args or do substitution. > > > If we do > > > this > > >     Stg though we don't need to bind those args as unarise > > > doesn't care > > > about > > >     what a void argument is as long as it's void it gets rid of > > > it and it > > > can > > >     check void-ness by looking at Id's type) > > > > > > Second: > > >     case of > > >       D arg1 arg2 ... argN -> > > >     ==> > > >     let arg1 = ... > > >         arg2 = ... > > >         arg3 = ... > > >      in > > >      (we know only one of these args will be non-void, but all of > > > them > > > should be > > >      bound as they can be referred in ) > > > > > > Am I right? > > > > > > I think if we do this in Stg we lose some optimization > > > opportunities and > > > generate ugly code. For example, if the first transformation > > > happens in a > > > let-binding RHS maybe simplifier decides to inline it as it can't > > > duplicate work after the transformation. Similarly it can decide > > > to > > > inline the non-void argument after second transformation which > > > may lead > > > to further optimizations etc. > > > > > > For an example of an ugly code, suppose we had this: > > > > > >     case of > > >       D (T x) -> > > > > > > in Stg this looks like > > > > > >     case of > > >       D v -> case v of > > >                T x -> > > > > > > So now if we do the second transformation we get > > > > > >     let v = in > > >     case v of > > >       T x -> > > > > > > but ideally we'd get > > > > > >     case of > > >       T x -> > > > > > > I think simplifier would be able to do this after the second > > > transformation. > > > Am I making any sense? > > > > > > I have no idea how to do this in the simplifier without losing > > > type > > > safety though... > > > > > > Are these two transformations also what you had in mind or do you > > > have > > > something else? > > > > > > - Omer > > > > > > 2016-09-07 16:58 GMT-04:00 David Feuer : > > > > > > > > I can't guarantee I'll be able to understand things well enough > > > > to > > > > take your advice, but I'd be willing to give it a shot. Where > > > > would be > > > > the right place to stick this? I am not at all familiar with > > > > the GHC > > > > code generation system. Also, what might I have to do to avoid > > > > forcing > > > > the same object repeatedly? If I have multiple such > > > > constructors, and > > > > someone does > > > > > > > > case x of > > > >   Con1 (Con2 (Con3 (Con4 y))) -> e > > > > > > > > I want to smash this down to something that looks like > > > > > > > > case x of y { > > > >   _ -> e } > > > > > > > > Do I need to worry about this, or will some later C-- pass take > > > > care of > > > it? > > > > > > > > > > > > On Wed, Sep 7, 2016 at 4:46 PM, Simon Peyton Jones > > > > wrote: > > > > > > > > > > I can advise about how (see comment:9 of #1965).  I can only > > > > > see how > > > to do it in an un-typed way in the back end. > > > > > > > > > > > > > > > > > > > Simon > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On > > > > > > Behalf Of > > > > > > David Feuer > > > > > > Sent: 07 September 2016 19:33 > > > > > > To: ghc-devs > > > > > > Subject: Feature request bounty > > > > > > > > > > > > I'd like to place a small bounty on > > > > > > https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationFo > > > > > > rGADTS . > > > > > > > > > > > > If someone implements this request by GHC 8.2, I will buy > > > > > > them 24 > > > > > > bottles of high-end root beer (e.g., Maine Root) or > > > > > > something of > > > > > > similar value agreeable to both parties. (*) > > > > > > > > > > > > Thanks, > > > > > > David Feuer > > > > > > > > > > > > (*) Recipient responsible for customs/duty/taxes/shipping > > > > > > fees > > > > > > beyond US$10. > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list > > > > > > ghc-devs at haskell.org > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a% > > > > > > 2f%2fmai > > > > > > l.hask > > > > > > ell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > > > > > > devs&data=02%7c01%7csimonpj%40microsoft.com%7cf392a423fac64 > > > > > > 06e1e440 > > > > > > 8d3d74 > > > > > > d61be%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c63608869 > > > > > > 97683024 > > > > > > 40&sda ta=jfQ62xjhLsZ8okc09JLpi6csdqDV2Y8IiLTvXwb5fN4%3d > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2 > > > > fmail.h > > > > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > > > > devs&data=02%7c01%7csi > > > > monpj%40microsoft.com%7c0cd3f91c657b41f8492108d3d7864917%7c72f9 > > > > 88bf86f > > > > 141af91ab2d7cd011db47%7c1%7c0%7c636088944161132661&sdata=mfmxH% > > > > 2bRbgRs > > > > XHzv6O0gBDC0DKzgi%2fNdNGxpxFOWEWqo%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Thu Sep 8 22:21:03 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Sep 2016 18:21:03 -0400 Subject: Grand Plan for 8.0.2 In-Reply-To: References: <87fupbsmgq.fsf@smart-cactus.org> Message-ID: <87fupaqbhs.fsf@smart-cactus.org> Alan & Kim Zimmerman writes: > I imagine I have completely missed the boat on this one, but would like to > test the waters on including the following [1] patch > Given that it's a pretty small patch and seems like it would be quite handy I'd certainly willing to consider it. Let's first get it merged into master though. Can you put it up on Phabricator? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alan.zimm at gmail.com Fri Sep 9 07:49:01 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 9 Sep 2016 09:49:01 +0200 Subject: Grand Plan for 8.0.2 In-Reply-To: <87fupaqbhs.fsf@smart-cactus.org> References: <87fupbsmgq.fsf@smart-cactus.org> <87fupaqbhs.fsf@smart-cactus.org> Message-ID: Done, see https://phabricator.haskell.org/D2518 -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sat Sep 10 19:43:08 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 10 Sep 2016 15:43:08 -0400 Subject: -fno-warn lines in the lexer can be removed with Alex 3.1.5 Message-ID: I was working on the lexer today and realized that we can now remove -fno-warn lines in the lexer if we're OK with requiring Alex >=3.1.5. From ben at well-typed.com Sat Sep 10 20:00:12 2016 From: ben at well-typed.com (Ben Gamari) Date: Sat, 10 Sep 2016 16:00:12 -0400 Subject: IRC: Logging #ghc with ircbrowse.net? Message-ID: <87poobpltf.fsf@ben-laptop.smart-cactus.org> Hello GHC developers, In the past we have relied upon Phabricator's Chatlog application to log the #ghc freenode channel. While Chatlog did its job admirably, it seems that Phacility has deprecated it with no proposed replacement. Thankfully, there appears to be no shortage of alternatives. In particular, Chris Done's ircbrowse.net seems to offer a great deal of functionality and already mirrors a number of other Haskell-related channels. Would anyone be opposed to adding #ghc to the list of channels monitored by ircbrowse.net? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Sat Sep 10 23:18:34 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 10 Sep 2016 19:18:34 -0400 Subject: IRC: Logging #ghc with ircbrowse.net? In-Reply-To: <87poobpltf.fsf@ben-laptop.smart-cactus.org> References: <87poobpltf.fsf@ben-laptop.smart-cactus.org> Message-ID: +1 from me. I don't have any preference to which service to use, as long as we have a logger with good uptime. I was regularly checking the logs when it was working. 2016-09-10 16:00 GMT-04:00 Ben Gamari : > Hello GHC developers, > > In the past we have relied upon Phabricator's Chatlog application to log > the #ghc freenode channel. While Chatlog did its job admirably, it seems > that Phacility has deprecated it with no proposed replacement. > > Thankfully, there appears to be no shortage of alternatives. In > particular, Chris Done's ircbrowse.net seems to offer a great deal of > functionality and already mirrors a number of other Haskell-related > channels. > > Would anyone be opposed to adding #ghc to the list of channels monitored > by ircbrowse.net? > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ryan.gl.scott at gmail.com Sun Sep 11 13:03:16 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 11 Sep 2016 09:03:16 -0400 Subject: -fno-warn lines in the lexer can be removed with Alex 3.1.5 Message-ID: That sounds like a reasonable suggestion to me. I'm not aware of any support window for we have for alex/happy, but since alex-3.1.5 is already about one year old, I can't imagine requiring it as a minimum would cause any problems. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 12 16:11:33 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 12 Sep 2016 12:11:33 -0400 Subject: vectorisation code? In-Reply-To: <5733542E.4030509@apeiron.net> References: <54C039D0.4020206@apeiron.net> <6AA9EDDD-2444-4ADE-8675-793745BBA374@cse.unsw.edu.au> <618BE556AADD624C9C918AA5D5911BEF562AF251@DB3PRD3001MB020.064d.mgd.msft.net> <54C10257.5030907@apeiron.net> <87twziq0fo.fsf@gmail.com> <54C11F26.9080201@apeiron.net> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org> <56A7A7AD.6030105@apeiron.net> <874ma462cc.fsf@smart-cactus.org> <5733542E.4030509@apeiron.net> Message-ID: <87d1k9p07e.fsf@ben-laptop.smart-cactus.org> Geoffrey Mainland writes: > Hi Ben, > > Progress is stalled on a rewrite of DPH's use of TH since TH is no > longer available in stage1. There is no reason this can't be worked > around, just that it's more work than I initially expected. > > I agree that it would be good to get this taken care of soon, but that > is generically true of almost all things :) I was planning on getting > this done for 8.2. If there is a reason for more urgency, let's discuss. > Hi Geoff, Hsa there been any news here? It would be great if we could have this taken care of by mid-October or so; the time right before a new release is always quite busy so the more things we can handle earlier the better. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From george.colpitts at gmail.com Mon Sep 12 16:57:00 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 12 Sep 2016 16:57:00 +0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <057.7b3f9412a36d327ef2778555ff05659d@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> <057.7b3f9412a36d327ef2778555ff05659d@haskell.org> Message-ID: Thanks Ben, np. On Mon, Sep 12, 2016 at 11:33 AM GHC wrote: > #8763: forM_ [1..N] does not get fused (10 times slower than go function) > -------------------------------------+------------------------------------- > Reporter: nh2 | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 8.2.1 > Component: Compiler | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 8.0.2 => 8.2.1 > > > Comment: > > I'm afraid 8.0.2 is out of the question. However, 8.2.1 is a possibility. > Of course, any help that you, the reader, can offer would expedite the > process. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Sep 13 15:38:16 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 13 Sep 2016 15:38:16 +0000 Subject: Better perf? Message-ID: I’m getting this perf improvement from T5837, which is type-function heavy. Is anyone else seeing this bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5837(normal) bytes allocated: 48507272 +/-10% Lower bound T5837(normal) bytes allocated: 43656544 Upper bound T5837(normal) bytes allocated: 53358000 Actual T5837(normal) bytes allocated: 42384144 Deviation T5837(normal) bytes allocated: -12.6 % Its good, but I’d quite like to know which patch made the difference. Could it be commit 03541cbae50f0d1cdf99120ab88698f29a278159 Author: Simon Peyton Jones Date: Fri Sep 9 17:42:42 2016 +0100 Be less picky about reporing inaccessible code Seems implausible, but possible I suppose. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Sep 13 16:00:05 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 13 Sep 2016 12:00:05 -0400 Subject: Better perf? In-Reply-To: References: Message-ID: <1473782405.8459.0.camel@joachim-breitner.de> Hi, according to https://perf.haskell.org/ghc/#graph/tests/alloc/T5837 it was  commit a48de37dcca98e7d477040b0ed298bcd1b3ab303 Author: Sergei Trofimovich Date:   Thu Sep 1 17:34:58 2016 +0100     restore -fmax-worker-args handling (Trac #11565) Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Sep 13 16:34:31 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 13 Sep 2016 16:34:31 +0000 Subject: Better perf? In-Reply-To: <1473782405.8459.0.camel@joachim-breitner.de> References: <1473782405.8459.0.camel@joachim-breitner.de> Message-ID: Cool. Perhaps someone can update the numbers with a comment pointing to the relevant commit? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 13 September 2016 17:00 | To: ghc-devs at haskell.org | Subject: Re: Better perf? | | Hi, | | according to | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fperf. | haskell.org%2fghc%2f%23graph%2ftests%2falloc%2fT5837&data=02%7c01%7csi | monpj%40microsoft.com%7ca9cef754e1f246ad325e08d3dbef0f3a%7c72f988bf86f | 141af91ab2d7cd011db47%7c1%7c0%7c636093792210134741&sdata=fh4bxFFGsWKAA | 8iZ0J%2faz6d3p4eLv2ZbX2K0qM%2b7GZY%3d | it was | | commit a48de37dcca98e7d477040b0ed298bcd1b3ab303 | Author: Sergei Trofimovich | Date:   Thu Sep 1 17:34:58 2016 +0100 | |     restore -fmax-worker-args handling (Trac #11565) | | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner |   mail at joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.j | oachim- | breitner.de%2f&data=02%7c01%7csimonpj%40microsoft.com%7ca9cef754e1f246 | ad325e08d3dbef0f3a%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636093 | 792210144750&sdata=gv6NQVusbo5hJ0w4vvHZyyJGsXWe6iPadR6emQWaKZo%3d |   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F |   Debian Developer: nomeata at debian.org From carter.schonwald at gmail.com Fri Sep 16 14:31:02 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 16 Sep 2016 10:31:02 -0400 Subject: Add a signaling Nans rts option to ghc? Message-ID: Hello All! I had some interesting conversations yesterday with a few folks and the take away was that I might experiment with adding an off by default rts flag that on applicable architectures that makes all floating point computations that yield Nans signaling , plus mayve some HS side hooks to enable or disable that per green thread if it doesn't harm no fib. Kinda like the way green threads track and save / restore the state of the magic c error tracking variable Would this be something folks would be open to adding once I hack it out? Most modern CPUs have some built in support for this, but having better rts integration might make things way nicer. Plus part of the point of the sheer diversity of Nans as per the IEEE report is to encode the nature of the source of the nan error. (There are other parts of IEEE that I think should be ignored / we should change the behavior in a way that disagrees with IEEE choices that hinder debugging and such ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Sep 16 15:40:08 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 16 Sep 2016 11:40:08 -0400 Subject: Add a signaling Nans rts option to ghc? In-Reply-To: References: Message-ID: <87y42rn99j.fsf@ben-laptop.smart-cactus.org> Carter Schonwald writes: > Hello All! > I had some interesting conversations yesterday with a few folks and the > take away was that I might experiment with adding an off by default rts > flag that on applicable architectures that makes all floating point > computations that yield Nans signaling , plus mayve some HS side hooks to > enable or disable that per green thread if it doesn't harm no fib. Kinda > like the way green threads track and save / restore the state of the magic > c error tracking variable > Sounds reasonable to me; debugging floating point issues is certainly a chore and this could only help. Regarding a per-thread handling I think we'd certainly need to benchmark. Note that rts/posix/Signals.c already has some logic to handle SIGFPE, although it has been disabled for over a decade due to an infinite loop where the handler immediately threw another FPE. It would be nice to have a solution to this issue; looping is quite bad. Do you lump infinities into the class of NaN values? I'm not sure how much code would fail due to "legitimate" uses of infinity if so. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at nh2.me Fri Sep 16 15:50:47 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Fri, 16 Sep 2016 17:50:47 +0200 Subject: Add a signaling Nans rts option to ghc? In-Reply-To: References: Message-ID: <324573d4-26a8-19e2-0a67-d8168c1ab284@nh2.me> Count me in as interested, I'd appreciate a feature to notice accidental NaNs in my code. From ben at smart-cactus.org Fri Sep 16 16:41:43 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 16 Sep 2016 12:41:43 -0400 Subject: -fno-warn lines in the lexer can be removed with Alex 3.1.5 In-Reply-To: References: Message-ID: <87vaxvn6ew.fsf@ben-laptop.smart-cactus.org> Ömer Sinan Ağacan writes: > I was working on the lexer today and realized that we can now remove > -fno-warn lines in the lexer if we're OK with requiring Alex >=3.1.5. No objection from me; 3.1.5 was released nearly a year ago and it's easy enough to update. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri Sep 16 18:32:31 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 16 Sep 2016 14:32:31 -0400 Subject: Add a signaling Nans rts option to ghc? In-Reply-To: References: <87y42rn99j.fsf@ben-laptop.smart-cactus.org> Message-ID: IEEE standard specify infinities as distinguished from NAN. Not that the IEEE standard always makes the best choices (semantics of min and max being the naughtiest ). But to the extent that hardware supoorts toggling what values trigger failure it should be reasonably toggle -able For Intel hardware I'll presume only hardware that has sse2 and newer, and maybe a warm-up or sibling patch would be to excise x87 float support from the code gen in GHC Amusingly one intended use for the large space of nan values was to encode the nature of the computation that created the nan. And this was intended to be used by language implementors. Not sure if that will be useful. Anyways, this and the other positive response is encouraging and I'll see about making the time to dig into this stuff. Merry friday all! -Carter On Sep 16, 2016 11:40 AM, "Ben Gamari" wrote: Carter Schonwald writes: > Hello All! > I had some interesting conversations yesterday with a few folks and the > take away was that I might experiment with adding an off by default rts > flag that on applicable architectures that makes all floating point > computations that yield Nans signaling , plus mayve some HS side hooks to > enable or disable that per green thread if it doesn't harm no fib. Kinda > like the way green threads track and save / restore the state of the magic > c error tracking variable > Sounds reasonable to me; debugging floating point issues is certainly a chore and this could only help. Regarding a per-thread handling I think we'd certainly need to benchmark. Note that rts/posix/Signals.c already has some logic to handle SIGFPE, although it has been disabled for over a decade due to an infinite loop where the handler immediately threw another FPE. It would be nice to have a solution to this issue; looping is quite bad. Do you lump infinities into the class of NaN values? I'm not sure how much code would fail due to "legitimate" uses of infinity if so. Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Fri Sep 16 23:02:48 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 17 Sep 2016 01:02:48 +0200 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: (Mikhail Glushenkov's message of "Tue, 9 Aug 2016 02:46:10 +0200") References: <1470679294-sup-321@sabre> Message-ID: <87oa3nwiqv.fsf@mid.deneb.enyo.de> * Mikhail Glushenkov: > Hi, > > On 9 August 2016 at 01:32, David Terei wrote: >> I imagine in Java, that I can construct an invalid pointer in foreign >> code, and then cause segfaults without the Java code having any >> issues. Just guessing at this, so very interested to know how it's >> prevented if I can't. > > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using > sun.misc.Unsafe [2], one can cause segfaults even from pure Java. You can also bring the JVM into an unstable state by triggering a VirtualMachineError, basically an out-of-memory condition, a stack overflow, or any other unrecoverable error. You can also exhaust limited resources such as file descriptors pretty easily. From fw at deneb.enyo.de Fri Sep 16 23:06:34 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 17 Sep 2016 01:06:34 +0200 Subject: Do we have free bits in the info pointer itself? In-Reply-To: (Ryan Newton's message of "Wed, 7 Sep 2016 17:32:21 -0400") References: Message-ID: <87k2ebwikl.fsf@mid.deneb.enyo.de> * Ryan Newton: > Our heap object header is one word -- an info table pointer > . > > Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the > object header for other purposes, right? x86_64 has signed pointers, so the uppoer 16 bits are either all zero or all ones. Some systems use both, but it's rare on Linux. Other 64-bit platforms use more bits. From gale at sefer.org Sun Sep 18 12:45:29 2016 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 18 Sep 2016 15:45:29 +0300 Subject: Grand Plan for 8.0.2 In-Reply-To: <87fupbsmgq.fsf@smart-cactus.org> References: <87fupbsmgq.fsf@smart-cactus.org> Message-ID: Are there any updates on 8.0.2? Thanks! To put things in the perspective of yesod-based commercial GHC users: Due to #12130, GHC 8 is useless to us until 8.0.2. So for us this is the most important GHC release in years. In our particular case, our products are now being held back in very concrete ways, because there are some critical libraries we can no longer update. The ecosystem has moved on to GHC 8, and we have been left behind. In anticipation of the release, and after the delay in the RC builds, we are now trying to compile GHC from source on multiple platforms just so that we can already start on all the infrastructure work we need to do for this major upgrade. That way we hopefully will be able to sprint from the gate as soon as there is an actual release. But obviously we would prefer to use RC builds for that. Thanks to all on the GHC team for all your great work! Yitz On Wed, Sep 7, 2016 at 7:28 PM, Ben Gamari wrote: > > tl;dr: GHC 8.0.2 is coming, however there are a number of issues we > would like to see resolved. Consequently it's not entirely clear > when it will arrive, but if things go well it may be as early as > this Friday. > > > Hello everyone, > > Over the past few weeks I've been making preparations for the coming > 8.0.2 release. I've merged a few more patches to the stable branch in > response to last week's call for merge requests, bringing the total up > to 180 commits since 8.0.1. > > At this point there are only a couple things that remain to be cleared > up, > > * #12220, #12533: These are unfortunate behaviors of > default signatures, #12220 being an interaction with type > applications and #12533 being an obscure corner case. While we have a > fix for these (d2958bd0), the fix changes the behavior of the > typechecker's inaccessible code check, breaking some code on Hackage; > this is documented as #12466. There are some tricky unresolved > questions here regarding how we want the inaccessible code here to > behave. > > At the moment I am leaning towards simply punting these off to 8.2.1. > If you would like to see them fixed in 8.0.2, please say so. > Moreover, please contribute your thoughts on #12466 as resolving the > remaining questions on that ticket is a prerequisite for merging the > fix for #12220. > > * #12954: Currently Haddock does not produce documentation for bundled > pattern synonyms. There is a pull request [1] that may fix this but > it is currently needing reviewers. It would be great to fix this for > 8.0.2, but ultimately someone is going to need to finish this up. > > * #10986: This is a rather unfortunate leak of temporary files which we > would ideally fix since it can produce rather large temporary > directories on the user's system. > > * #12519: Haddock inexplicably forgets to render the class members of > Eq and Ord. It would be great if someone could get to the bottom of > this. > > * #12433 is a rather nasty correctness bug which currently has no > resolution. > > * #11819: There are still a number of full validation issues which > would be nice to sort out. > > I would like to be able to say that we have a concrete timeline for a > 8.0.2 release and I was originally planning to propose a candidate > source release for late this week, however in light of the the large > number of unresolved issues, I think it would be unwise to commit to > this timeframe. I'll say that the candidate source tarball could come as > early as Friday, although sometime next week is far more likely. > > As always, any help that you could offer on any of the above issues > would be greatly appreciated. > > Cheers, > > - Ben > > > [1] https://github.com/haskell/haddock/pull/494/commits/7984c8fb8f238793641a419c93fbcb4f6e933ae5 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Sun Sep 18 13:07:24 2016 From: ben at well-typed.com (Ben Gamari) Date: Sun, 18 Sep 2016 09:07:24 -0400 Subject: Grand Plan for 8.0.2 In-Reply-To: References: <87fupbsmgq.fsf@smart-cactus.org> Message-ID: <8760ptmk4z.fsf@ben-laptop.smart-cactus.org> Yitzchak Gale writes: > Are there any updates on 8.0.2? Thanks! > > To put things in the perspective of yesod-based commercial GHC users: > Due to #12130, GHC 8 is useless to us until 8.0.2. So for us this is > the most important GHC release in years. > At the moment I'm trying to work out some issues with merging #12466. This is the last issue on my queue other than doing basic build testing on the other architectures. Sadly next week I'll be at ICFP so it's unlikely that much progress will be made until the following week. > In our particular case, our products are now being held back in very > concrete ways, because there are some critical libraries we can no > longer update. The ecosystem has moved on to GHC 8, and we have been > left behind. > Thanks for the data-point! It's very helpful for prioritization to know these sorts of things. Don't hesitate to bring this up this sort of thing early in the future. > In anticipation of the release, and after the delay in the RC builds, > we are now trying to compile GHC from source on multiple platforms > just so that we can already start on all the infrastructure work we > need to do for this major upgrade. That way we hopefully will be able > to sprint from the gate as soon as there is an actual release. But > obviously we would prefer to use RC builds for that. > > Thanks to all on the GHC team for all your great work! Thanks Yitz! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gale at sefer.org Sun Sep 18 13:16:38 2016 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 18 Sep 2016 16:16:38 +0300 Subject: Grand Plan for 8.0.2 In-Reply-To: <8760ptmk4z.fsf@ben-laptop.smart-cactus.org> References: <87fupbsmgq.fsf@smart-cactus.org> <8760ptmk4z.fsf@ben-laptop.smart-cactus.org> Message-ID: Ben, thanks much for the update. It's not sad that you'll be at ICFP - I wish I could be there too! :) Historically ICFP has provided much of the juice that GHC runs on. Enjoy, and good luck with the release. Regards, Yitz On Sun, Sep 18, 2016 at 4:07 PM, Ben Gamari wrote: > Yitzchak Gale writes: > >> Are there any updates on 8.0.2? Thanks! >> >> To put things in the perspective of yesod-based commercial GHC users: >> Due to #12130, GHC 8 is useless to us until 8.0.2. So for us this is >> the most important GHC release in years. >> > At the moment I'm trying to work out some issues with merging #12466. > This is the last issue on my queue other than doing basic build testing > on the other architectures. Sadly next week I'll be at ICFP so it's > unlikely that much progress will be made until the following week. > >> In our particular case, our products are now being held back in very >> concrete ways, because there are some critical libraries we can no >> longer update. The ecosystem has moved on to GHC 8, and we have been >> left behind. >> > Thanks for the data-point! It's very helpful for prioritization to know > these sorts of things. Don't hesitate to bring this up this sort of > thing early in the future. > >> In anticipation of the release, and after the delay in the RC builds, >> we are now trying to compile GHC from source on multiple platforms >> just so that we can already start on all the infrastructure work we >> need to do for this major upgrade. That way we hopefully will be able >> to sprint from the gate as soon as there is an actual release. But >> obviously we would prefer to use RC builds for that. >> >> Thanks to all on the GHC team for all your great work! > > Thanks Yitz! > > Cheers, > > - Ben From carter.schonwald at gmail.com Sun Sep 18 21:02:21 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 18 Sep 2016 21:02:21 +0000 Subject: 8.0 tip doesn't build sans reverting c51caafae7669d Message-ID: I had to revert c51caafae7669d4246f4efd3d1a6858020780e02 to get the tip of 8.0 to work current tip for me as of this checkout d3ac6ce08f282060ca6dc61de527b5b77885ab88 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Sep 19 01:49:19 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 18 Sep 2016 21:49:19 -0400 Subject: Grand Plan for 8.0.2 In-Reply-To: References: <87fupbsmgq.fsf@smart-cactus.org> <8760ptmk4z.fsf@ben-laptop.smart-cactus.org> Message-ID: i hit a funny issue with the near term -hb patch, i'll try to track it down, but reverting it allowed me to get a mac build of 8.0 master in shape On Sun, Sep 18, 2016 at 9:16 AM, Yitzchak Gale wrote: > Ben, thanks much for the update. > > It's not sad that you'll be at ICFP - I wish I could be there too! :) > Historically ICFP has provided much of the juice that GHC runs on. > Enjoy, and good luck with the release. > > Regards, > Yitz > > > On Sun, Sep 18, 2016 at 4:07 PM, Ben Gamari wrote: > > Yitzchak Gale writes: > > > >> Are there any updates on 8.0.2? Thanks! > >> > >> To put things in the perspective of yesod-based commercial GHC users: > >> Due to #12130, GHC 8 is useless to us until 8.0.2. So for us this is > >> the most important GHC release in years. > >> > > At the moment I'm trying to work out some issues with merging #12466. > > This is the last issue on my queue other than doing basic build testing > > on the other architectures. Sadly next week I'll be at ICFP so it's > > unlikely that much progress will be made until the following week. > > > >> In our particular case, our products are now being held back in very > >> concrete ways, because there are some critical libraries we can no > >> longer update. The ecosystem has moved on to GHC 8, and we have been > >> left behind. > >> > > Thanks for the data-point! It's very helpful for prioritization to know > > these sorts of things. Don't hesitate to bring this up this sort of > > thing early in the future. > > > >> In anticipation of the release, and after the delay in the RC builds, > >> we are now trying to compile GHC from source on multiple platforms > >> just so that we can already start on all the infrastructure work we > >> need to do for this major upgrade. That way we hopefully will be able > >> to sprint from the gate as soon as there is an actual release. But > >> obviously we would prefer to use RC builds for that. > >> > >> Thanks to all on the GHC team for all your great work! > > > > Thanks Yitz! > > > > Cheers, > > > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berman.josh at gmail.com Mon Sep 19 11:23:52 2016 From: berman.josh at gmail.com (Josh Berman) Date: Mon, 19 Sep 2016 14:23:52 +0300 Subject: building ghc-8.0 branch on Win10 Message-ID: Hi, I was able to build the "master" branch of ghc 8.0.1 using the instructions found here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows When I switched to the "ghc-8.0" branch, though, I get the following error: configure: error: > You've selected: > BUILD: x86_64-w64-mingw32 (the architecture we're building on) > HOST: x86_64-unknown-mingw32 (the architecture the compiler we're > building will execute on) > TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're > building will produce code for) > BUILD must equal HOST; that is, we do not support building GHC itself > with a cross-compiler. To cross-compile GHC itself, set TARGET: stage > 1 will be a cross-compiler, and stage 2 will be the cross-compiled > GHC. Anyone know off the top of their heads what the issue is? Thanks, - Josh Berman -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Sep 19 11:37:01 2016 From: lonetiger at gmail.com (Phyx) Date: Mon, 19 Sep 2016 11:37:01 +0000 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: Hi Josh, Yes you are hitting a bug in configure that was exposed due to changes in msys. Cherry-pick this commit to your branch https://ghc.haskell.org/trac/ghc/ticket/12487 Tamar On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: > Hi, > > I was able to build the "master" branch of ghc 8.0.1 using the > instructions found here: > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > When I switched to the "ghc-8.0" branch, though, I get the following error: > > configure: error: >> You've selected: >> BUILD: x86_64-w64-mingw32 (the architecture we're building on) >> HOST: x86_64-unknown-mingw32 (the architecture the compiler we're >> building will execute on) >> TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're >> building will produce code for) >> BUILD must equal HOST; that is, we do not support building GHC itself >> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage >> 1 will be a cross-compiler, and stage 2 will be the cross-compiled >> GHC. > > > > Anyone know off the top of their heads what the issue is? > > Thanks, > - Josh Berman > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berman.josh at gmail.com Mon Sep 19 11:38:09 2016 From: berman.josh at gmail.com (Josh Berman) Date: Mon, 19 Sep 2016 14:38:09 +0300 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: Yeah, I just saw that bug report, too. Thanks. On Mon, Sep 19, 2016 at 2:37 PM, Phyx wrote: > Hi Josh, > > Yes you are hitting a bug in configure that was exposed due to changes in > msys. > > Cherry-pick this commit to your branch https://ghc.haskell.org/trac/ > ghc/ticket/12487 > > Tamar > > On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: > >> Hi, >> >> I was able to build the "master" branch of ghc 8.0.1 using the >> instructions found here: >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows >> >> When I switched to the "ghc-8.0" branch, though, I get the following >> error: >> >> configure: error: >>> You've selected: >>> BUILD: x86_64-w64-mingw32 (the architecture we're building on) >>> HOST: x86_64-unknown-mingw32 (the architecture the compiler we're >>> building will execute on) >>> TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're >>> building will produce code for) >>> BUILD must equal HOST; that is, we do not support building GHC itself >>> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage >>> 1 will be a cross-compiler, and stage 2 will be the cross-compiled >>> GHC. >> >> >> >> Anyone know off the top of their heads what the issue is? >> >> Thanks, >> - Josh Berman >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berman.josh at gmail.com Mon Sep 19 12:39:15 2016 From: berman.josh at gmail.com (Josh Berman) Date: Mon, 19 Sep 2016 15:39:15 +0300 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: Sorry to pester - now 'make' is failing: ===--- building phase 0 > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \ > -optc-Wall -optc-Werror -optc-fno-stack-protector \ > \ > -hide-all-packages \ > -package base -package array -package time -package containers > -package bytestring -package deepseq -package process -package pretty > -package directory -package Win32 \ > --make utils/ghc-cabal/Main.hs -o > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ > -no-user-package-db \ > -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ > -DCABAL_VERSION= 1,25,0,0 \ > -DMIN_VERSION_binary_0_8_0 \ > -DBOOTSTRAPPING \ > -optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \ > -odir bootstrapping \ > -hidir bootstrapping \ > -ilibraries/Cabal/Cabal \ > -ilibraries/binary/src -DGENERICS \ > -ilibraries/filepath \ > -ilibraries/hpc \ > target `1,25,0,0' is not a module name or a source file > ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory > make[1]: *** [utils/ghc-cabal/ghc.mk:48: > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 > make: *** [Makefile:130: all] Error 2 I updated my cabal to be 1.25, thinking that might be the issue, but now I realize that was probably irrelevant. Any further ideas? (This time, I searched trac before emailing... but didn't find anything). Thanks, - Josh On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman wrote: > Yeah, I just saw that bug report, too. Thanks. > > On Mon, Sep 19, 2016 at 2:37 PM, Phyx wrote: > >> Hi Josh, >> >> Yes you are hitting a bug in configure that was exposed due to changes in >> msys. >> >> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g >> hc/ticket/12487 >> >> Tamar >> >> On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: >> >>> Hi, >>> >>> I was able to build the "master" branch of ghc 8.0.1 using the >>> instructions found here: >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows >>> >>> When I switched to the "ghc-8.0" branch, though, I get the following >>> error: >>> >>> configure: error: >>>> You've selected: >>>> BUILD: x86_64-w64-mingw32 (the architecture we're building on) >>>> HOST: x86_64-unknown-mingw32 (the architecture the compiler >>>> we're building will execute on) >>>> TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're >>>> building will produce code for) >>>> BUILD must equal HOST; that is, we do not support building GHC itself >>>> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage >>>> 1 will be a cross-compiler, and stage 2 will be the cross-compiled >>>> GHC. >>> >>> >>> >>> Anyone know off the top of their heads what the issue is? >>> >>> Thanks, >>> - Josh Berman >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Sep 19 12:42:45 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 19 Sep 2016 21:42:45 +0900 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: <1474288926-sup-7305@sabre> This is a dumb build system problem. One way to hack around it is edit libraries/Cabal/Cabal/Cabal.cabal and remove the spaces before 1.25.0.0. I thought I fixed this in HEAD so there may be a patch you could backport too. Edward Excerpts from Josh Berman's message of 2016-09-19 15:39:15 +0300: > Sorry to pester - now 'make' is failing: > > ===--- building phase 0 > > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > > "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \ > > -optc-Wall -optc-Werror -optc-fno-stack-protector \ > > \ > > -hide-all-packages \ > > -package base -package array -package time -package containers > > -package bytestring -package deepseq -package process -package pretty > > -package directory -package Win32 \ > > --make utils/ghc-cabal/Main.hs -o > > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ > > -no-user-package-db \ > > -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ > > -DCABAL_VERSION= 1,25,0,0 \ > > -DMIN_VERSION_binary_0_8_0 \ > > -DBOOTSTRAPPING \ > > -optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \ > > -odir bootstrapping \ > > -hidir bootstrapping \ > > -ilibraries/Cabal/Cabal \ > > -ilibraries/binary/src -DGENERICS \ > > -ilibraries/filepath \ > > -ilibraries/hpc \ > > target `1,25,0,0' is not a module name or a source file > > ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory > > make[1]: *** [utils/ghc-cabal/ghc.mk:48: > > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 > > make: *** [Makefile:130: all] Error 2 > > > I updated my cabal to be 1.25, thinking that might be the issue, but now I > realize that was probably irrelevant. > > Any further ideas? (This time, I searched trac before emailing... but > didn't find anything). > > Thanks, > - Josh > > On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman wrote: > > > Yeah, I just saw that bug report, too. Thanks. > > > > On Mon, Sep 19, 2016 at 2:37 PM, Phyx wrote: > > > >> Hi Josh, > >> > >> Yes you are hitting a bug in configure that was exposed due to changes in > >> msys. > >> > >> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g > >> hc/ticket/12487 > >> > >> Tamar > >> > >> On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: > >> > >>> Hi, > >>> > >>> I was able to build the "master" branch of ghc 8.0.1 using the > >>> instructions found here: > >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > >>> > >>> When I switched to the "ghc-8.0" branch, though, I get the following > >>> error: > >>> > >>> configure: error: > >>>> You've selected: > >>>> BUILD: x86_64-w64-mingw32 (the architecture we're building on) > >>>> HOST: x86_64-unknown-mingw32 (the architecture the compiler > >>>> we're building will execute on) > >>>> TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're > >>>> building will produce code for) > >>>> BUILD must equal HOST; that is, we do not support building GHC itself > >>>> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage > >>>> 1 will be a cross-compiler, and stage 2 will be the cross-compiled > >>>> GHC. > >>> > >>> > >>> > >>> Anyone know off the top of their heads what the issue is? > >>> > >>> Thanks, > >>> - Josh Berman > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>> > >> > > From ggreif at gmail.com Mon Sep 19 16:21:51 2016 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 19 Sep 2016 18:21:51 +0200 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: http://git.haskell.org/ghc.git/blobdiff/db5a22627b3e6bcc9fa17fbc070daac0919b552a..1101045cbdbd6f240fa7e2438d9488822cd604fb:/utils/ghc-cabal/ghc.mk This might help... Cheers, Gabor Em segunda-feira, 19 de setembro de 2016, Josh Berman escreveu: > Sorry to pester - now 'make' is failing: > > ===--- building phase 0 >> make --no-print-directory -f ghc.mk phase=0 phase_0_builds >> "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \ >> -optc-Wall -optc-Werror -optc-fno-stack-protector \ >> \ >> -hide-all-packages \ >> -package base -package array -package time -package containers >> -package bytestring -package deepseq -package process -package pretty >> -package directory -package Win32 \ >> --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe >> \ >> -no-user-package-db \ >> -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ >> -DCABAL_VERSION= 1,25,0,0 \ >> -DMIN_VERSION_binary_0_8_0 \ >> -DBOOTSTRAPPING \ >> -optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \ >> -odir bootstrapping \ >> -hidir bootstrapping \ >> -ilibraries/Cabal/Cabal \ >> -ilibraries/binary/src -DGENERICS \ >> -ilibraries/filepath \ >> -ilibraries/hpc \ >> target `1,25,0,0' is not a module name or a source file >> ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory >> make[1]: *** [utils/ghc-cabal/ghc.mk:48: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] >> Error 1 >> make: *** [Makefile:130: all] Error 2 > > > I updated my cabal to be 1.25, thinking that might be the issue, but now I > realize that was probably irrelevant. > > Any further ideas? (This time, I searched trac before emailing... but > didn't find anything). > > Thanks, > - Josh > > > On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman > wrote: > >> Yeah, I just saw that bug report, too. Thanks. >> >> On Mon, Sep 19, 2016 at 2:37 PM, Phyx > > wrote: >> >>> Hi Josh, >>> >>> Yes you are hitting a bug in configure that was exposed due to changes >>> in msys. >>> >>> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g >>> hc/ticket/12487 >>> >>> Tamar >>> >>> On Mon, Sep 19, 2016, 12:24 Josh Berman >> > wrote: >>> >>>> Hi, >>>> >>>> I was able to build the "master" branch of ghc 8.0.1 using the >>>> instructions found here: >>>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows >>>> >>>> When I switched to the "ghc-8.0" branch, though, I get the following >>>> error: >>>> >>>> configure: error: >>>>> You've selected: >>>>> BUILD: x86_64-w64-mingw32 (the architecture we're building on) >>>>> HOST: x86_64-unknown-mingw32 (the architecture the compiler >>>>> we're building will execute on) >>>>> TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're >>>>> building will produce code for) >>>>> BUILD must equal HOST; that is, we do not support building GHC itself >>>>> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage >>>>> 1 will be a cross-compiler, and stage 2 will be the cross-compiled >>>>> GHC. >>>> >>>> >>>> >>>> Anyone know off the top of their heads what the issue is? >>>> >>>> Thanks, >>>> - Josh Berman >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berman.josh at gmail.com Mon Sep 19 16:38:57 2016 From: berman.josh at gmail.com (Josh Berman) Date: Mon, 19 Sep 2016 19:38:57 +0300 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: Yeah, I cherry-picked that in, too - thanks! Build works; thanks everyone. On Mon, Sep 19, 2016 at 7:21 PM, Gabor Greif wrote: > http://git.haskell.org/ghc.git/blobdiff/db5a22627b3e6bcc9fa17fbc070daa > c0919b552a..1101045cbdbd6f240fa7e2438d9488822cd604fb:/utils/ghc-cabal/ > ghc.mk > > This might help... > > Cheers, > > Gabor > > > Em segunda-feira, 19 de setembro de 2016, Josh Berman < > berman.josh at gmail.com> escreveu: > >> Sorry to pester - now 'make' is failing: >> >> ===--- building phase 0 >>> make --no-print-directory -f ghc.mk phase=0 phase_0_builds >>> "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \ >>> -optc-Wall -optc-Werror -optc-fno-stack-protector \ >>> \ >>> -hide-all-packages \ >>> -package base -package array -package time -package containers >>> -package bytestring -package deepseq -package process -package pretty >>> -package directory -package Win32 \ >>> --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe >>> \ >>> -no-user-package-db \ >>> -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ >>> -DCABAL_VERSION= 1,25,0,0 \ >>> -DMIN_VERSION_binary_0_8_0 \ >>> -DBOOTSTRAPPING \ >>> -optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \ >>> -odir bootstrapping \ >>> -hidir bootstrapping \ >>> -ilibraries/Cabal/Cabal \ >>> -ilibraries/binary/src -DGENERICS \ >>> -ilibraries/filepath \ >>> -ilibraries/hpc \ >>> target `1,25,0,0' is not a module name or a source file >>> ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory >>> make[1]: *** [utils/ghc-cabal/ghc.mk:48: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] >>> Error 1 >>> make: *** [Makefile:130: all] Error 2 >> >> >> I updated my cabal to be 1.25, thinking that might be the issue, but now >> I realize that was probably irrelevant. >> >> Any further ideas? (This time, I searched trac before emailing... but >> didn't find anything). >> >> Thanks, >> - Josh >> >> >> On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman >> wrote: >> >>> Yeah, I just saw that bug report, too. Thanks. >>> >>> On Mon, Sep 19, 2016 at 2:37 PM, Phyx wrote: >>> >>>> Hi Josh, >>>> >>>> Yes you are hitting a bug in configure that was exposed due to changes >>>> in msys. >>>> >>>> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g >>>> hc/ticket/12487 >>>> >>>> Tamar >>>> >>>> On Mon, Sep 19, 2016, 12:24 Josh Berman wrote: >>>> >>>>> Hi, >>>>> >>>>> I was able to build the "master" branch of ghc 8.0.1 using the >>>>> instructions found here: >>>>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows >>>>> >>>>> When I switched to the "ghc-8.0" branch, though, I get the following >>>>> error: >>>>> >>>>> configure: error: >>>>>> You've selected: >>>>>> BUILD: x86_64-w64-mingw32 (the architecture we're building on) >>>>>> HOST: x86_64-unknown-mingw32 (the architecture the compiler >>>>>> we're building will execute on) >>>>>> TARGET: x86_64-unknown-mingw32 (the architecture the compiler >>>>>> we're building will produce code for) >>>>>> BUILD must equal HOST; that is, we do not support building GHC itself >>>>>> with a cross-compiler. To cross-compile GHC itself, set TARGET: stage >>>>>> 1 will be a cross-compiler, and stage 2 will be the cross-compiled >>>>>> GHC. >>>>> >>>>> >>>>> >>>>> Anyone know off the top of their heads what the issue is? >>>>> >>>>> Thanks, >>>>> - Josh Berman >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 19 23:18:36 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Sep 2016 19:18:36 -0400 Subject: building ghc-8.0 branch on Win10 In-Reply-To: References: Message-ID: <87eg4flbqr.fsf@ben-laptop.smart-cactus.org> Josh Berman writes: > Yeah, I cherry-picked that in, too - thanks! > > Build works; thanks everyone. > Excellent! Thanks for the testing. I was hoping someone would try the ghc-8.0 build as my Windows test machine is still in transit to my new apartment. Anyways, I'll be sure to merge these. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Tue Sep 20 22:05:58 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Sep 2016 22:05:58 +0000 Subject: Test T12504 on Windows Message-ID: Test hsc2hs/T12504 is failing thus on Windows. Something path-y. Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-} -{-# LINE 2 "T12504/path/to/T12504.hsc" #-} +{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-} +{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-} *** unexpected failure for T12504(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Sep 20 22:10:52 2016 From: lonetiger at gmail.com (Phyx) Date: Tue, 20 Sep 2016 22:10:52 +0000 Subject: Test T12504 on Windows In-Reply-To: References: Message-ID: The new output is correct. hsc2hs was patched to fix the error messages it gives. We missed a test it seems. I'll update the test output when I get home. Thanks Simon, Tamar On Tue, Sep 20, 2016, 23:06 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Test hsc2hs/T12504 is failing thus on Windows. Something path-y. > > Simon > > > > -{-# LINE 1 "T12504/path/to/T12504.hsc" #-} > > -{-# LINE 2 "T12504/path/to/T12504.hsc" #-} > > +{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-} > > +{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-} > > *** unexpected failure for T12504(normal) > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Wed Sep 21 01:03:50 2016 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Wed, 21 Sep 2016 02:03:50 +0100 Subject: Test T12504 on Windows In-Reply-To: References: Message-ID: <57e1dc76.898b1c0a.b0412.2a71@mx.google.com> I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcook at rcook.org Wed Sep 21 02:12:47 2016 From: rcook at rcook.org (Richard Cook) Date: Tue, 20 Sep 2016 19:12:47 -0700 Subject: Test T12504 on Windows Message-ID: <9snmqao0kw2a2kc7ey13kflw.1474423967402@email.android.com> Thanks! Yes, I did mean to reply all. -Richard Sent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone -------- Original message --------From: lonetiger at gmail.com Date: 9/20/16 6:03 PM (GMT-08:00) To: Richard Cook , Simon Peyton Jones , ghc-devs at haskell.org Subject: RE: Test T12504 on Windows I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook Sent: Tuesday, September 20, 2016 23:35 To: Phyx Subject: Re: Test T12504 on Windows Dear All, This is the test case that was added to validate the fix to hsc2hs. Here's the commit that added the test case: https://git.haskell.org/ghc.git/commitdiff/76286af5c621f032c4afab1f26b992e8ffa7f84d Output on Windows should include backslashes, other platforms should use forward slashes. This is keyed off the WINDOWS Makefile variable. -Richard  On Tue, Sep 20, 2016 at 3:10 PM, Phyx wrote:The new output is correct. hsc2hs was patched to fix the error messages it gives. We missed a test it seems. I'll update the test output when I get home. Thanks Simon, Tamar  On Tue, Sep 20, 2016, 23:06 Simon Peyton Jones via ghc-devs wrote:Test hsc2hs/T12504 is failing thus on Windows. Something path-y.Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-}-{-# LINE 2 "T12504/path/to/T12504.hsc" #-}+{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-}+{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-}*** unexpected failure for T12504(normal)_______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs   -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Sat Sep 24 00:31:21 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Fri, 23 Sep 2016 17:31:21 -0700 Subject: Custom warning suppression In-Reply-To: References: Message-ID: Interesting ideas! What if #1 was implemented as a new declaration type that is allowed in where clauses? f x = SomeConstant where { unused x } For #2, I would love to have a general system for declaring new types of warnings that come with a way to dispatch the specific warning. So, picking some random new names for these: {-# NEW_VALUE_WARNING partial "This function is partial, and so should be used with care" #-} {-# VALUE_WARNING partial unsafePerformIO #-} -- Additional detail text is optional!! Lots of potential for bike shedding, a variety of choices in the tradeoff between complexity and boilerplate. On Wed, Sep 7, 2016 at 7:39 AM, David Feuer wrote: > Currently, the only way to suppress custom warnings and deprecations is with > -fno-warn-warnings-deprecations, which is a rather large hammer. I see two > ways we can improve this, and I propose that we should do both. > > 1. Per-binding suppression > > Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and > -fdeprecate-binding options. These would take the (optionally qualified) > name of a binding and control warnings tied to it. So if you invoked > -fno-warn-binding "sillyFunction", then GHC would not warn you about the > silliness of anything named sillyFunction. -fno-warn-binding > "Data.Silly.sillyFunction" would limit the suppression to the silly function > in Data.Silly. -fno-deprecate-binding would refrain from emitting > deprecation warnings for the binding in question. -fno-deprecate-binding > would presumably imply no-warn-binding, since someone who doesn't care that > a function is going to be removed probably also doesn't care what else is > wrong with it. > > 2. Named warning classes > > I'd like to add an optional "warning class" to the WARNING pragma, preceding > the warning description. This would be a short string indicating what sort > of warning is involved. This would be totally free-form, but the > documentation would suggest a few conventional options such as "partial" and > "slow". Then whole warning classes could be controlled with -fno-warn-class > and -first-class. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Sat Sep 24 01:44:25 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 24 Sep 2016 01:44:25 +0000 Subject: Notes from Ben's "contribute to ghc" discussion Message-ID: Friends Here are the notes I took from session 2 of the Haskell Implementors Meeting. The bolding is my choice of emphasis. Simon * Doc bugs. Two kinds o Typos. Friction stops me o Explanations needed e.g. read/show * Lightweight pushes * Make user manual into its own repo, to make it easier to take pull requests. But that makes it harder when making synchronised changes to GHC and user manual. * Auto-push: Ability to push to Phab and have it committed automatically if it validates. * Style guides. Is having a defined style solving a problem we don't really have? One piece of guidance: adhere to the style of the surrounding code. Low priority. * Docker images. We should have one. * Remove old documentation! * Cross compilation is difficult. * Have a GHC StackOverflow on haskell.org (Jacob Zalewski jakzale at gmail.com offers to do this! - thank you). It has a useful new Documentation feature. Eg this would be good for "how do I look up a RdrName to get a Name... there seem to be six different functions that do that". -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Sat Sep 24 04:56:13 2016 From: eric at seidel.io (Eric Seidel) Date: Fri, 23 Sep 2016 21:56:13 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: <1474692973.2255232.735514977.0D1FB3D1@webmail.messagingengine.com> I found a list of StackOverflow clones. (I don't know how difficult it is to get an official StackExchange site, or if we would even want that) http://meta.stackexchange.com/questions/2267/stack-exchange-clones On Fri, Sep 23, 2016, at 18:44, Simon Peyton Jones via ghc-devs wrote: > Friends > > Here are the notes I took from session 2 of the Haskell Implementors > Meeting. The bolding is my choice of emphasis. > > Simon > > > * Doc bugs. Two kinds > > o Typos. Friction stops me > > o Explanations needed e.g. read/show > > * Lightweight pushes > > * Make user manual into its own repo, to make it easier to take > pull requests. But that makes it harder when making > synchronised changes > to GHC and user manual. > > * Auto-push: Ability to push to Phab and have it committed > automatically if it validates. > > * Style guides. Is having a defined style solving a problem we > don't really have? One piece of guidance: adhere to the style of the > surrounding code. Low priority. > > * Docker images. We should have one. > > * Remove old documentation! > > * Cross compilation is difficult. > > * Have a GHC StackOverflow on haskell.org (Jacob Zalewski > jakzale at gmail.com offers to do this! - thank > you). It has a useful new Documentation feature. Eg this > would be good > for "how do I look up a RdrName to get a Name... there seem to be six > different functions that do that". > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Sep 24 06:46:45 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 24 Sep 2016 15:46:45 +0900 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: <1474699605.17351.1.camel@joachim-breitner.de> Hi, I’ll add some notes to extend the discussion to the mailing list. Am Samstag, den 24.09.2016, 01:44 +0000 schrieb Simon Peyton Jones via ghc-devs: > > ·        Make user manual into its own repo, to make it easier to > take pull requests.  But that makes it harder when making > synchronised changes to GHC and user manual. I don’t think we need a separate repo in order to allow contributors to easily build the manual on its own, and to accept contributions to via GitHub. > > ·        Auto-push: Ability to push to Phab and have it committed > automatically if it validates. \o/ > > ·        Have a GHC StackOverflow on haskell.org   (Jacob Zalewski > jakzale at gmail.com offers to do this! – thank you).  It has a useful > new Documentation feature.   Eg this would be good for “how do I look > up a RdrName to get a Name… there seem to be six different functions > that do that”. Any reason not to use http://stackoverflow.com/? Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From eric at seidel.io Sat Sep 24 07:31:22 2016 From: eric at seidel.io (Eric Seidel) Date: Sat, 24 Sep 2016 00:31:22 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474699605.17351.1.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> Message-ID: <1474702282.2282408.735565593.5AE94039@webmail.messagingengine.com> On Fri, Sep 23, 2016, at 23:46, Joachim Breitner wrote: > Any reason not to use http://stackoverflow.com/? That would certainly be the easiest solution. The questions that occur to me are: 1. Do GHC-dev questions fit within the purview of StackOverflow? I think so, there are plenty of library-specific questions on SO, so questions like "what's the best way to lookup a Name?" ought to be in scope. But maybe there are other kinds of questions (not specifically programming-related) that we'd like to collect answers to. If that's the case the SO mods might close those other questions as off-topic. 2. Do we want to exercise more control over the GHC Q&A site than a tag on SO would allow? We do host a lot of infrastructure ourselves and I assume there are good reasons for that. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sat Sep 24 18:55:47 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 24 Sep 2016 18:55:47 +0000 Subject: Adding ConApp to Core Message-ID: Andres, Richard, Stephanie The more I think about our idea of introducing ConApp the more I like it. I wrote it up in a ticket https://ghc.haskell.org/trac/ghc/ticket/12618 Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sat Sep 24 19:01:35 2016 From: lonetiger at gmail.com (Phyx) Date: Sat, 24 Sep 2016 20:01:35 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474699605.17351.1.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> Message-ID: >> >> · Auto-push: Ability to push to Phab and have it committed >> automatically if it validates. > > \o/ How would this work? Could there be a cooldown period? e.g. commits sit a day before being auto-committed? Validate really only validates Linux x86_64. The situation is already quite dire for other architectures and OSes, I fear making it worse by not allowing people time to object. Would this be a per person setting? This just raises so many questions. And I don't quite see what problem it's solving because presumably code is tested before it's put on Phab isn't it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Sep 24 21:33:17 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 24 Sep 2016 17:33:17 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474699605.17351.1.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> Message-ID: <87k2e1j84i.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi, > Thanks everyone for your comments, and to Simon for collecting these notes. > I’ll add some notes to extend the discussion to the mailing list. > > Am Samstag, den 24.09.2016, 01:44 +0000 schrieb Simon Peyton Jones via > ghc-devs: >> >> ·        Make user manual into its own repo, to make it easier to >> take pull requests.  But that makes it harder when making >> synchronised changes to GHC and user manual. > > I don’t think we need a separate repo in order to allow contributors to > easily build the manual on its own, and to accept contributions to via > GitHub. > The only slightly tricky part here is the users guide parts generated by utils/mkUserGuidePart. This is currently built by stage1, but strictly speaking there's no reason why it couldn't be built with stage0. >> >> ·        Auto-push: Ability to push to Phab and have it committed >> automatically if it validates. > I'll look into how we might be able to accomplish this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Sat Sep 24 21:37:09 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 24 Sep 2016 17:37:09 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> Message-ID: <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Phyx writes: >>> >>> · Auto-push: Ability to push to Phab and have it committed >>> automatically if it validates. >> >> \o/ > > How would this work? Could there be a cooldown period? e.g. commits sit a > day before being auto-committed? > > Validate really only validates Linux x86_64. The situation is already quite > dire for other architectures and OSes, > I fear making it worse by not allowing people time to object. > The solution here is to extend Harbormaster coverage, which is on my list anyways. My priorities is roughly, > Would this be a per person setting? This just raises so many questions. And > I don't quite see what problem it's solving > because presumably code is tested before it's put on Phab isn't it? I think the we'd want to restrict this to Diffs submitted by contributors who already possess commit bits and specifically include a "no-review" tag in the summary. The idea here is to provide an alternative to pushing directly to master, extending the coverage of Harbormaster without inconveniencing contributors. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Sat Sep 24 22:56:21 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 24 Sep 2016 23:56:21 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: There is a phabricator module, ponder [1], which looks suitable for the Q&A feature. Surely we all agree that it is easier to setup this module than to host a completely separate service ourselves! This also has the advantage of being able to reference commits, differentials and tickets in an easy manner. Another question about administration, it doesn't seem like many people have permissions to modify the phabricator installation. How easy is it to give some people more elevated positions to deal with things like updating the home page, giving badges, moderating "ponder" and so on? The homepage hasn't been updated for quite a while, the "recent events" tab makes it look like the project is quite dead. If anyone has ever talked to me about this, it should be clear that I am a massive phabricator fanboy and think that we should utilise it more. There are lots of modules [2] that we don't use and the product is just going to get better as other companies (ie facebook) continue to drive it. I think that in the future it would be beneficial to port the wiki and bug tracker from trac to the corresponding phabricator features, phriction and maniphest respectively. Firstly, I think phabricator is just better than trac but the primary reason is that trac is not very actively developed. So three separate thoughts in this email, only one of which is relevant to the thread. With regards to the other points in Simon's email, I don't feel qualified to opine too much as GHC is the only "large" project I have contributed to. Bear that in mind when reading my comments inline below. I'll make sure to check out the video when it is released as well. [1]: https://secure.phabricator.com/ponder/ [2]: https://secure.phabricator.com/w/starmap/ > · Doc bugs. Two kinds > > o Typos. Friction stops me > > o Explanations needed e.g. read/show The biggest friction is the fact some of the user guide is generated so you have to build the whole compiler to build the user guide. It seems like it would be possible to just not include this generated section if you wanted to compile the guide in order to check you didn't make a syntax mistake or something. Perhaps it would be good if the build bots made the generated user guide available for each build it did. I don't know how feasible this is. > > · Lightweight pushes What does this mean? > > · Make user manual into its own repo, to make it easier to take pull > requests. But that makes it harder when making synchronised changes to GHC > and user manual. Submodules are annoying to update, everyone knows this. Separating out the two makes synchronous updates harder to review together but makes drive-by updates easier. I think it would be nice if there was a web-interface which allowed people to edit the user guide in the browser rather than have to setup an entire development environment. > > · Auto-push: Ability to push to Phab and have it committed > automatically if it validates. This seems like a reasonable idea but perhaps not worth the effort needed to set it up. My usual workflow is to put most of my commits onto phabrictor with the thought that it's better for less people to directly interact with the main branch. If Ben would prefer less control then I can merge more things myself without issues! > > · Style guides. Is having a defined style solving a problem we don’t > really have? One piece of guidance: adhere to the style of the surrounding > code. Low priority. I think a consistent style wouldn't be a bad thing. The code is a bit strange as Simon perfers the semi-colon style which not many people other than him in the whole community uses. The more pressing concern to me is the scale of the API to some modules is very large, there are lots of exposed functions which aren't documented at all which do slightly different things with subtle invariants. A much more beneficial change would be to enforce that new library style functions should get haddock comments saying what they do! Cutting back these APIs is hard as it requires a very good knowledge of the compiler which not many people have. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From cma at bitemyapp.com Sat Sep 24 23:36:55 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 24 Sep 2016 18:36:55 -0500 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87h995j7y2.fsf@ben-laptop.smart-cactus.org> References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: >I think the we'd want to restrict this to Diffs submitted by contributors who already possess commit bits and specifically include a "no-review" tag in the summary. Is this intended to address the issues new contributors have in contributing to GHC? This looks more insider stuff that misses the point if so. If new contributors are not part of a conversation about contributing to GHC, when and where did that conversation happen and what is being done about it? On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari wrote: > Phyx writes: > >>>> >>>> · Auto-push: Ability to push to Phab and have it committed >>>> automatically if it validates. >>> >>> \o/ >> >> How would this work? Could there be a cooldown period? e.g. commits sit a >> day before being auto-committed? >> >> Validate really only validates Linux x86_64. The situation is already quite >> dire for other architectures and OSes, >> I fear making it worse by not allowing people time to object. >> > The solution here is to extend Harbormaster coverage, which is on my > list anyways. My priorities is roughly, > >> Would this be a per person setting? This just raises so many questions. And >> I don't quite see what problem it's solving >> because presumably code is tested before it's put on Phab isn't it? > > I think the we'd want to restrict this to Diffs submitted by > contributors who already possess commit bits and specifically include a > "no-review" tag in the summary. The idea here is to provide an > alternative to pushing directly to master, extending the coverage of > Harbormaster without inconveniencing contributors. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Sat Sep 24 23:41:58 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 25 Sep 2016 08:41:58 +0900 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: <1474760518.2704.3.camel@joachim-breitner.de> Hi, Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen: > > > > I think the we'd want to restrict this to Diffs submitted by > > contributors who already possess commit bits and specifically > > include a "no-review" tag in the summary. > > Is this intended to address the issues new contributors have in > contributing to GHC? This looks more insider stuff that misses the > point if so. > > If new contributors are not part of a conversation about contributing > to GHC, when and where did that conversation happen and what is being > done about it? Let me clarify: The auto-commit-after-build feature is completely unrelated to new contributors, and purely a way to reduce friction for regular contributors. (But everyone benefits as the repo is broken less often with such a feature at our fingertips.) Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Sat Sep 24 23:46:02 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 24 Sep 2016 18:46:02 -0500 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474760518.2704.3.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <1474760518.2704.3.camel@joachim-breitner.de> Message-ID: Seems reasonable, but much of the consternation over GHC dev process has been about the relative illegibility of it, even for working programmers who've hacked on compilers before. It's concerning to see a list of items about a "contribute to GHC" discussion that seemingly includes nothing that addresses this. Can you point me to any discussions among GHC devs on this since the last time it was raised? On Sat, Sep 24, 2016 at 6:41 PM, Joachim Breitner wrote: > Hi, > > Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen: >> > >> > I think the we'd want to restrict this to Diffs submitted by >> > contributors who already possess commit bits and specifically >> > include a "no-review" tag in the summary. >> >> Is this intended to address the issues new contributors have in >> contributing to GHC? This looks more insider stuff that misses the >> point if so. >> >> If new contributors are not part of a conversation about contributing >> to GHC, when and where did that conversation happen and what is being >> done about it? > > Let me clarify: The auto-commit-after-build feature is completely > unrelated to new contributors, and purely a way to reduce friction for > regular contributors. > > (But everyone benefits as the repo is broken less often with such a > feature at our fingertips.) > > Greetings, > Joachim > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Sat Sep 24 23:53:31 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 25 Sep 2016 08:53:31 +0900 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <1474760518.2704.3.camel@joachim-breitner.de> Message-ID: <1474761211.2704.9.camel@joachim-breitner.de> Hi, Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen: > Seems reasonable, but much of the consternation over GHC dev process > has been about the relative illegibility of it, even for working > programmers who've hacked on compilers before. It's concerning to see > a list of items about a "contribute to GHC" discussion that seemingly > includes nothing that addresses this. > > Can you point me to any discussions among GHC devs on this since the > last time it was raised? I’m not sure why this proposal is causing unease here? Regular contributors are contributors too! Also, the idea of accepting trivial commits via GitHub (which are then pushed by someone with commit access) works much better if the latter can be done efficient, i.e. in a fire-and-forget, but still safe and checked, mode. And the list does include a few things that are meant to help new contributors:  * Accepting contributions where a quick review suffices via     GitHub (that’s the item “lightweight pushes”).  * Not imposing style guides that people have to learn first  * Docker images to quickly get started.  * Easier ways of learning about GHC development (by removing old docs,    and leverating SO). That list is not meant to be exhaustive, if you have other ideas how to make GHC hacking more accessible, please tell us! I am under the impression that there is some misunderstanding here, because there really is nothing not be wound up about here. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Sun Sep 25 00:17:07 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 24 Sep 2016 19:17:07 -0500 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474761211.2704.9.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <1474760518.2704.3.camel@joachim-breitner.de> <1474761211.2704.9.camel@joachim-breitner.de> Message-ID: Why are contributions via Github limited to things that don't require review? That won't encourage anyone to get started because they know that as soon as they move on to something substantive, they'll hit the same brick wall. You can't boil a frog by taking it out of the pot of lukewarm water and tossing it into the roiling kettle. Have you looked at how Rust handles contributions to the compiler? https://github.com/rust-lang/rust They don't rely on bare Github, they use bots to automate and add structure in the ways you're trying to wring out of Phabricator. The automation and community they've built here is above and beyond anything I've seen in any other community, it is _outstanding_ and it behooves us to learn what they do and to take it seriously. Rust has five times the contributors GHC does and the depth of contributions do not trail off as quickly. Rust has been around for less time than many popular Haskell libraries! To see more of how Rust developers and users discuss new features and improvements, this forum is illuminating: https://internals.rust-lang.org/ I work with someone that has contributed to GHCJS more than once, but will not go anywhere near GHC. This is almost entirely because of the opaque process. Another: https://github.com/purescript/purescript 94 contributors, only a couple years old, written in Haskell but has many users who came from JS and don't know any Haskell, used mostly for frontend work. Putting aside Github's new code review functionality (which seems fine but isn't anything terribly impressive), there are lots of ways to skin the code review cat without putting new contributors in a typo-fix PR ghetto. On Sat, Sep 24, 2016 at 6:53 PM, Joachim Breitner wrote: > Hi, > > Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen: >> Seems reasonable, but much of the consternation over GHC dev process >> has been about the relative illegibility of it, even for working >> programmers who've hacked on compilers before. It's concerning to see >> a list of items about a "contribute to GHC" discussion that seemingly >> includes nothing that addresses this. >> >> Can you point me to any discussions among GHC devs on this since the >> last time it was raised? > > I’m not sure why this proposal is causing unease here? Regular > contributors are contributors too! > > Also, the idea of accepting trivial commits via GitHub (which are then > pushed by someone with commit access) works much better if the latter > can be done efficient, i.e. in a fire-and-forget, but still safe and > checked, mode. > > And the list does include a few things that are meant to help new > contributors: > * Accepting contributions where a quick review suffices via > GitHub (that’s the item “lightweight pushes”). > * Not imposing style guides that people have to learn first > * Docker images to quickly get started. > * Easier ways of learning about GHC development (by removing old docs, > and leverating SO). > > That list is not meant to be exhaustive, if you have other ideas how to > make GHC hacking more accessible, please tell us! > > I am under the impression that there is some misunderstanding here, > because there really is nothing not be wound up about here. > > Greetings, > Joachim > > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From matthewtpickering at gmail.com Sun Sep 25 00:17:27 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 25 Sep 2016 01:17:27 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: I think this comment is useful because it highlights the point that it isn't very clear what "the point" even is. Is the problem that the code review process happens on phabricator and trac rather than github? It seems unlikely the project will move to github, phabricator works well for existing developers. In fact, phabricator was the best thing to ever happen to increase accessibility to newcomers. Thomie create some stats about the new contributors and there was a large spike after the more to phab. Is the problem that the way which new features are proposed is opaque? Ben worked on a new proposals process to help with this - https://github.com/ghc-proposals/ghc-proposals Is the problem technical? Is the build system not suitable? Is the code base poorly organised? This should be said but ultimately the project is a volunteer based effort. People don't like spending their time doing refactoring. It would take someone who particularly cared about newcomer contributors to do some of the cleanup work. Ultimately, I'm not sure what exactly what the point is. I read posts like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html ) and find myself disagreeing with almost every point. The comments in the reddit thread provide most of the refutations. The post doesn't address the fact that the feature was a small syntactic change which as erik pointed out, it perhaps the most difficult change to integrate as it must certainly pay it's way. Contributing to any project requires a certain amount of investment. Empirically, it seems to me that if the user makes the investment to build GHC and fix an issue then the last step, setting up phabricator, is not a point of friction. There are good instructions on the wiki which describe this process. Recently I have witnessed a new contributor independently provide a patch and when prompted to submit to phabricator, did so within a few hours. Phabricator doesn't seem to be a serious issue. Could you perhaps point to some concrete examples of people who have tried to contribute and where the sticking points are? As you observe, we are well meaning with this list but not very well placed to solve this problem as it is not clear even if there is a problem to solve and if there is, what the *exact* problem is. At the end of the day it is the core contributors who contribute the most code so the process should be optimised for them. As you probably read in my last email, phabricator works well for me but I am interested in helping newcomers get involved in the project. I think the best way to do this is managing the issue tracker well and providing 1-1 personal assistance to people when they need it. After a few patches, it gets much easier. If this comment makes no sense to you, then it would be even more beneficial if you could explain to me how other people perceive the process. Matt On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen wrote: >>I think the we'd want to restrict this to Diffs submitted by contributors who already possess commit bits and specifically include a "no-review" tag in the summary. > > Is this intended to address the issues new contributors have in > contributing to GHC? This looks more insider stuff that misses the > point if so. > > If new contributors are not part of a conversation about contributing > to GHC, when and where did that conversation happen and what is being > done about it? > > On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari wrote: >> Phyx writes: >> >>>>> >>>>> · Auto-push: Ability to push to Phab and have it committed >>>>> automatically if it validates. >>>> >>>> \o/ >>> >>> How would this work? Could there be a cooldown period? e.g. commits sit a >>> day before being auto-committed? >>> >>> Validate really only validates Linux x86_64. The situation is already quite >>> dire for other architectures and OSes, >>> I fear making it worse by not allowing people time to object. >>> >> The solution here is to extend Harbormaster coverage, which is on my >> list anyways. My priorities is roughly, >> >>> Would this be a per person setting? This just raises so many questions. And >>> I don't quite see what problem it's solving >>> because presumably code is tested before it's put on Phab isn't it? >> >> I think the we'd want to restrict this to Diffs submitted by >> contributors who already possess commit bits and specifically include a >> "no-review" tag in the summary. The idea here is to provide an >> alternative to pushing directly to master, extending the coverage of >> Harbormaster without inconveniencing contributors. >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From allbery.b at gmail.com Sun Sep 25 00:28:32 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Sep 2016 20:28:32 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <1474760518.2704.3.camel@joachim-breitner.de> <1474761211.2704.9.camel@joachim-breitner.de> Message-ID: On Sat, Sep 24, 2016 at 8:17 PM, Christopher Allen wrote: > They don't rely on bare Github, they use bots to automate and add > structure in the ways you're trying to wring out of Phabricator. > Other way around: they, and pretty much every large project, are forced to invent their own bots and automation to wring some usability out of github's minimal functionality. Which is why other large projects use phabricator, gerrit, etc. instead of dumping a massive amount of effort into trying to make github do what they need. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sun Sep 25 00:37:06 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 25 Sep 2016 01:37:06 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <1474760518.2704.3.camel@joachim-breitner.de> <1474761211.2704.9.camel@joachim-breitner.de> Message-ID: I don't understand this fascination with Rust the Haskell community has. The two projects are very different. As you say in the post, GHC is a much older project and as a result has much less hype around it. Rust is the definition of a "hot new thing" and so it makes sense that there are more contributors. I am sure that github contributes to some contributors but this discussion is pointless unless this common assertion is put into context. Not only this but mozilla has many more full-time rust developers to facilitate the process. I couldn't find the exact number so I will avoid quoting it but GHC has only 1 full time developer. This is a significant increase in man power and also leaves time for the ability to more closely manage and cultivate the community of contributors. We don't have that luxury. You also say why github is an unsuitable tool for such a project. The fact that they have had to develop their own sophisticated bots in order to deal with the issue tracker is just indicative that github doesn't provide the flexibility necessary. The new projects interface does look more promising but it is lightyears behind what phab provides. Github is good for small projects as the interface is optimised for them but I don't believe that it scales well. The essential argument seems to be that moving to github would "solve all the problems with GHC development" but its seems to be based on false premises. In order for this discussion to move forward it seems that we could all do with vocalising the issues that we perceive to make sure that we're all working on the same page. It doesn't appear to be the case at the moment. And some comments inline: > I work with someone that has contributed to GHCJS more than once, but > will not go anywhere near GHC. This is almost entirely because of the > opaque process. What is opaque about the process? What does he want to contribute but feels unable to? > Putting aside Github's new code review functionality (which seems fine > but isn't anything terribly impressive), there are lots of ways to > skin the code review cat without putting new contributors in a > typo-fix PR ghetto. What does this comment mean? What is a "type-fix PR ghetto"? It seems that you are suggesting moving to github but then using a different service to do code review? Matt From cma at bitemyapp.com Sun Sep 25 00:38:34 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 24 Sep 2016 19:38:34 -0500 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: My point is that at almost every level, contributing to GHC is a chore. Phabricator/Github is simply a good place to start for opening things up, but it's far from the only thing. http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the ring of verisimilitude to me and most working Haskellers I know. This bright line between the users of Haskell and the contributors to the primary compiler is not healthy long-term. The consistently dismissive attitude towards these objections is not good either. GHC has a very poor showing compared to other compilers with similar sets of users (FP, typed, or modern) in terms of onboarding new people and you won't take these critiques seriously. You do the bare minimum just so you can say you did something, but not substantive is open for discussion. This fools no-one! >I don't understand this fascination with Rust the Haskell community has. The two projects are very different. As you say in the post, GHC is a much older project and as a result has much less hype around it. Rust is the definition of a "hot new thing" and so it makes sense that there are more contributors. Hype draws consumers, not producers! Excellent process, documentation, and community is what turns those consumers into producers! This is so short-sighted and wrong that I don't think there's any point in my saying more. You've made it clear you don't care. On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering wrote: > I think this comment is useful because it highlights the point that it > isn't very clear what "the point" even is. > > Is the problem that the code review process happens on phabricator and > trac rather than github? > It seems unlikely the project will move to github, phabricator works > well for existing developers. In fact, phabricator was the best thing > to ever happen to increase accessibility to newcomers. Thomie create > some stats about the new contributors and there was a large spike > after the more to phab. > > Is the problem that the way which new features are proposed is opaque? > Ben worked on a new proposals process to help with this - > https://github.com/ghc-proposals/ghc-proposals > > Is the problem technical? Is the build system not suitable? Is the > code base poorly organised? > This should be said but ultimately the project is a volunteer based > effort. People don't like spending their time doing refactoring. It > would take someone > who particularly cared about newcomer contributors to do some of the > cleanup work. > > Ultimately, I'm not sure what exactly what the point is. I read posts > like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html > ) and find myself disagreeing with almost every point. The comments in > the reddit thread provide most of the refutations. The post doesn't > address the > fact that the feature was a small syntactic change which as erik > pointed out, it perhaps the most difficult change to integrate as it > must certainly pay it's way. > > Contributing to any project requires a certain amount of investment. > Empirically, it seems to me that > if the user makes the investment to build GHC and fix an issue then > the last step, setting up phabricator, > is not a point of friction. There are good instructions on the wiki > which describe this process. Recently I have witnessed a new > contributor independently provide a patch and > when prompted to submit to phabricator, did so within a few hours. > Phabricator doesn't seem to be a serious issue. > > Could you perhaps point to some concrete examples of people who have > tried to contribute and where the sticking points are? > As you observe, we are well meaning with this list but not very well > placed to solve this problem as it is not clear even if there > is a problem to solve and if there is, what the *exact* problem is. > > At the end of the day it is the core contributors who contribute the > most code so the process should be optimised for them. As you probably > read in my last email, > phabricator works well for me but I am interested in helping newcomers > get involved in the project. I think the best way to do this is > managing the issue tracker well and providing 1-1 personal assistance > to people when they need it. After a few patches, it gets much easier. > > If this comment makes no sense to you, then it would be even more > beneficial if you could explain to me how other people perceive the > process. > > Matt > > On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen wrote: >>>I think the we'd want to restrict this to Diffs submitted by contributors who already possess commit bits and specifically include a "no-review" tag in the summary. >> >> Is this intended to address the issues new contributors have in >> contributing to GHC? This looks more insider stuff that misses the >> point if so. >> >> If new contributors are not part of a conversation about contributing >> to GHC, when and where did that conversation happen and what is being >> done about it? >> >> On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari wrote: >>> Phyx writes: >>> >>>>>> >>>>>> · Auto-push: Ability to push to Phab and have it committed >>>>>> automatically if it validates. >>>>> >>>>> \o/ >>>> >>>> How would this work? Could there be a cooldown period? e.g. commits sit a >>>> day before being auto-committed? >>>> >>>> Validate really only validates Linux x86_64. The situation is already quite >>>> dire for other architectures and OSes, >>>> I fear making it worse by not allowing people time to object. >>>> >>> The solution here is to extend Harbormaster coverage, which is on my >>> list anyways. My priorities is roughly, >>> >>>> Would this be a per person setting? This just raises so many questions. And >>>> I don't quite see what problem it's solving >>>> because presumably code is tested before it's put on Phab isn't it? >>> >>> I think the we'd want to restrict this to Diffs submitted by >>> contributors who already possess commit bits and specifically include a >>> "no-review" tag in the summary. The idea here is to provide an >>> alternative to pushing directly to master, extending the coverage of >>> Harbormaster without inconveniencing contributors. >>> >>> Cheers, >>> >>> - Ben >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Chris Allen Currently working on http://haskellbook.com From allbery.b at gmail.com Sun Sep 25 00:40:23 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Sep 2016 20:40:23 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen wrote: > This is so short-sighted and wrong that I don't think there's any > point in my saying more. You've made it clear you don't care. > And --- note that I am not a ghc developer --- have made it clear that you do not care how much extra work you make for already massively overworked ghc developers. You're not contributing. You're not helping. You're derailing. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Sun Sep 25 00:41:19 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sun, 25 Sep 2016 10:41:19 +1000 Subject: Adding ConApp to Core In-Reply-To: References: Message-ID: I like this. Having the DataCon only in IdDetails always felt a bit off. Manuel > Simon Peyton Jones via ghc-devs : > > Andres, Richard, Stephanie > > The more I think about our idea of introducing ConApp the more I like it. I wrote it up in a ticket > > https://ghc.haskell.org/trac/ghc/ticket/12618 > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sun Sep 25 00:51:46 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 25 Sep 2016 01:51:46 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: It really is difficult to proceed when the problem is not well defined. I also find it insulting that you suggest that I (and other developers) don't care about bringing new users to the project. The nebulous suggestion that GHC developers have ulterior motives is also not becoming of a productive discussion. There's clearly much more to be said but it seems pointless to proceed any further. Matt On Sun, Sep 25, 2016 at 1:38 AM, Christopher Allen wrote: > My point is that at almost every level, contributing to GHC is a > chore. Phabricator/Github is simply a good place to start for opening > things up, but it's far from the only thing. > > http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the > ring of verisimilitude to me and most working Haskellers I know. This > bright line between the users of Haskell and the contributors to the > primary compiler is not healthy long-term. > > The consistently dismissive attitude towards these objections is not > good either. > > GHC has a very poor showing compared to other compilers with similar > sets of users (FP, typed, or modern) in terms of onboarding new people > and you won't take these critiques seriously. You do the bare minimum > just so you can say you did something, but not substantive is open for > discussion. This fools no-one! > >>I don't understand this fascination with Rust the Haskell community has. The two projects are very different. As you say in the post, GHC is a much older project and as a result has much less hype around it. Rust is the definition of a "hot new thing" and so it makes sense that there are more contributors. > > Hype draws consumers, not producers! Excellent process, documentation, > and community is what turns those consumers into producers! > > This is so short-sighted and wrong that I don't think there's any > point in my saying more. You've made it clear you don't care. > > On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering > wrote: >> I think this comment is useful because it highlights the point that it >> isn't very clear what "the point" even is. >> >> Is the problem that the code review process happens on phabricator and >> trac rather than github? >> It seems unlikely the project will move to github, phabricator works >> well for existing developers. In fact, phabricator was the best thing >> to ever happen to increase accessibility to newcomers. Thomie create >> some stats about the new contributors and there was a large spike >> after the more to phab. >> >> Is the problem that the way which new features are proposed is opaque? >> Ben worked on a new proposals process to help with this - >> https://github.com/ghc-proposals/ghc-proposals >> >> Is the problem technical? Is the build system not suitable? Is the >> code base poorly organised? >> This should be said but ultimately the project is a volunteer based >> effort. People don't like spending their time doing refactoring. It >> would take someone >> who particularly cared about newcomer contributors to do some of the >> cleanup work. >> >> Ultimately, I'm not sure what exactly what the point is. I read posts >> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html >> ) and find myself disagreeing with almost every point. The comments in >> the reddit thread provide most of the refutations. The post doesn't >> address the >> fact that the feature was a small syntactic change which as erik >> pointed out, it perhaps the most difficult change to integrate as it >> must certainly pay it's way. >> >> Contributing to any project requires a certain amount of investment. >> Empirically, it seems to me that >> if the user makes the investment to build GHC and fix an issue then >> the last step, setting up phabricator, >> is not a point of friction. There are good instructions on the wiki >> which describe this process. Recently I have witnessed a new >> contributor independently provide a patch and >> when prompted to submit to phabricator, did so within a few hours. >> Phabricator doesn't seem to be a serious issue. >> >> Could you perhaps point to some concrete examples of people who have >> tried to contribute and where the sticking points are? >> As you observe, we are well meaning with this list but not very well >> placed to solve this problem as it is not clear even if there >> is a problem to solve and if there is, what the *exact* problem is. >> >> At the end of the day it is the core contributors who contribute the >> most code so the process should be optimised for them. As you probably >> read in my last email, >> phabricator works well for me but I am interested in helping newcomers >> get involved in the project. I think the best way to do this is >> managing the issue tracker well and providing 1-1 personal assistance >> to people when they need it. After a few patches, it gets much easier. >> >> If this comment makes no sense to you, then it would be even more >> beneficial if you could explain to me how other people perceive the >> process. >> >> Matt >> >> On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen wrote: >>>>I think the we'd want to restrict this to Diffs submitted by contributors who already possess commit bits and specifically include a "no-review" tag in the summary. >>> >>> Is this intended to address the issues new contributors have in >>> contributing to GHC? This looks more insider stuff that misses the >>> point if so. >>> >>> If new contributors are not part of a conversation about contributing >>> to GHC, when and where did that conversation happen and what is being >>> done about it? >>> >>> On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari wrote: >>>> Phyx writes: >>>> >>>>>>> >>>>>>> · Auto-push: Ability to push to Phab and have it committed >>>>>>> automatically if it validates. >>>>>> >>>>>> \o/ >>>>> >>>>> How would this work? Could there be a cooldown period? e.g. commits sit a >>>>> day before being auto-committed? >>>>> >>>>> Validate really only validates Linux x86_64. The situation is already quite >>>>> dire for other architectures and OSes, >>>>> I fear making it worse by not allowing people time to object. >>>>> >>>> The solution here is to extend Harbormaster coverage, which is on my >>>> list anyways. My priorities is roughly, >>>> >>>>> Would this be a per person setting? This just raises so many questions. And >>>>> I don't quite see what problem it's solving >>>>> because presumably code is tested before it's put on Phab isn't it? >>>> >>>> I think the we'd want to restrict this to Diffs submitted by >>>> contributors who already possess commit bits and specifically include a >>>> "no-review" tag in the summary. The idea here is to provide an >>>> alternative to pushing directly to master, extending the coverage of >>>> Harbormaster without inconveniencing contributors. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > Chris Allen > Currently working on http://haskellbook.com From mgsloan at gmail.com Sun Sep 25 01:05:45 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 24 Sep 2016 18:05:45 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: As a side observer, I find Christopher's comments to be spot on. My lack of familiarity with phab has definitely de-railed my in-flight patch, adding implicit parameter and recursive do support to Template Haskell. Certainly my own fault, but also induced by friction that feels unnecessary. On Sat, Sep 24, 2016 at 5:40 PM, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen > wrote: >> >> This is so short-sighted and wrong that I don't think there's any >> point in my saying more. You've made it clear you don't care. > > > And --- note that I am not a ghc developer --- have made it clear that you > do not care how much extra work you make for already massively overworked > ghc developers. > You're not contributing. You're not helping. You're derailing. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From chak at justtesting.org Sun Sep 25 01:08:01 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sun, 25 Sep 2016 11:08:01 +1000 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Why are you so hostile to Chris? I don’t think that this is an appropriate way to treat somebody who is making a suggestion in good faith. Chris may not have contributed to GHC, but apart from co-authoring the currently most popular Haskell book, he has consistently contributed to helping people who are new to the language (on Slack, IRC, in blog posts, etc). He has suck a ton of time into moving the language forward. Moreover, he knows a thing or two about helping newcomers in an effective manner. And he is right in his critique that it is hard to contribute to GHC. For example, I recently wrote a patch concerning compatibility with macOS Sierra and even posted about it on this list: https://mail.haskell.org/pipermail/ghc-devs/2016-July/012512.html It’s a small patch, and I just don’t have the time to jump through all the hoops to get it into the repo. And now before you accuse me of not having contributed to GHC, maybe check the git logs first. In summary, if you don’t want to consider that maybe it is harder to contribute to GHC than it has to be and making it easier maybe would lead to more contributions, that is one thing. However, I do insist that suggestions made in good faith on this list are treated politely and not being brutally shot down. Simon, I imagine you agree with me here. Manuel > Brandon Allbery : > > > On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen > wrote: > This is so short-sighted and wrong that I don't think there's any > point in my saying more. You've made it clear you don't care. > > And --- note that I am not a ghc developer --- have made it clear that you do not care how much extra work you make for already massively overworked ghc developers. > You're not contributing. You're not helping. You're derailing. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Sep 25 01:13:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Sep 2016 21:13:11 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sat, Sep 24, 2016 at 9:05 PM, Michael Sloan wrote: > As a side observer, I find Christopher's comments to be spot on. They're missing quite a bit, actually. Like how Rust had a bunch of contributors even before they started, and Mozilla Corp. backing them. Rust's solution is only viable if someone wants to bring those to the table along with it; it's just not possible otherwise. There aren't enough people *now* to build a whole new infrastructure. I work with another open source project that is as short on contributors as ghc is. It's part of my day job, even, and it's a regular topic at team meetings. One comes to understand why this is not something that can be done on a whim. (And my employer isn't big enough to do the heavy lifting or provide bodies --- even ignoring that we feel it's best for us and our customers that this project remain independent, not controlled by or beholden to any company, which makes contributing somewhat difficult as a political matter although we do our best.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Sep 25 01:19:33 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Sep 2016 21:19:33 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < chak at justtesting.org> wrote: > Why are you so hostile to Chris? I don’t think that this is an appropriate > way to treat somebody who is making a suggestion in good faith. It may be in good faith. but it's not in good sense. There is a lot in the background that made Rust's setup possible, and he's not bringing that to the table, just assuming it'll somehow happen or that everyone else will drop everything for the next few months and make it happen. And I feel like he's being really pushy about committing already overworked people to this --- and insisting that anyone opposed must have a hidden agenda or otherwise cannot possibly have good reason to be opposed. It's not helpful at all; it's basically a good way to stall ghc for the next few months at least. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Sun Sep 25 01:29:33 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 24 Sep 2016 20:29:33 -0500 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: I'd be willing to help with work required to open up GHC development more along multiple lines including: Bots/automation for Github Talking to Rust devs about what works, what doesn't Talking to GHC devs about what works, what doesn't, comparing/contrasting with other processes such as Rust's Papering all this up into a "where we are, where we'd like to go" document Writing documentation and tutorials for getting new developers on board Manually on-boarding new developers I am willing to do this work in addition to my 9-5 work using Haskell, the book(s) which are a full-time job unto themselves, and the open source work I do. I will not do any of this as long as this is the attitude of GHC developers. I can not in good conscience encourage people to contribute to a project controlled and represented with such hostility and dismissiveness. The needs of the community and of new and casual contributors have to be taken seriously. This is not for their sake alone, it's to ease the workload of the maintainers and to mend the worsening culture gap. On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty > wrote: >> >> Why are you so hostile to Chris? I don’t think that this is an appropriate >> way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or otherwise > cannot possibly have good reason to be opposed. It's not helpful at all; > it's basically a good way to stall ghc for the next few months at least. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -- Chris Allen Currently working on http://haskellbook.com From minesasecret at gmail.com Sun Sep 25 01:43:00 2016 From: minesasecret at gmail.com (Richard Fung) Date: Sat, 24 Sep 2016 18:43:00 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: I suppose I'll take this opportunity to bring this thread back on topic and have everyone read my thoughts guilt free. As a newcomer who recently submitted my first patch, I disagree with Chris's points. I'm just a junior developer who has never worked on a compiler before, so maybe the experience will be different for people from other backgrounds. I guess you're allowed to disagree with me even if you're from a similar background. In my (short) experience, Github vs Phabricator, using Arc, and the points mentioned in the linked blog like coding style and comments were all non issues. Again, this is just my experience and others might feel differently, but if so I encourage them to raise their points and hopefully also explain in detail the issues encountered. For me the only issue was being able to understand the code base. Sadly, this was actually a huge barrier because, rather embarrassingly, after months of reading through the code, in the end I only managed to submit a patch after Simon told me exactly what I needed to do. Even more depressingly, the other Simon (Marlow) was unhappy because it caused a performance regression so the patch was rejected! Sad life.. In other words, I found the difficulty in actually being able to contribute a meaningful patch is far greater than any difficulty in learning to use the tools and process required to submit a patch. Of course this is to be expected from a code base as large, old, and complicated as GHC's, and I'm not too sure what can be done from a technical standpoint to address this, besides better documentation. From a process standpoint though, if I didn't have personal assistance from Simon and Ben (Thank you!!!) I imagine I would have given up much sooner, despite having been relatively motivated. I don't know if this would be possible of course considering GHC developers are very busy as it is, but it would be great if newcomers could be assigned a mentor to contact when in need of help. Maybe I am just weird, but I actually felt bad emailing everyone for help, so I would typically go much longer than comfortable before asking for help. As you can imagine, as the struggle increases, the likelihood of giving up also does, and I will admit I thought about giving up many times. I realize this would probably be difficult to scale, but hopefully as new developers come, they would also be able to mentor others. I think this is similar to what is done in the industry by many companies as well. In summary, difficulty of understanding code base >>> difficulty of using tools and following documentation. On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen wrote: > I'd be willing to help with work required to open up GHC development > more along multiple lines including: > > Bots/automation for Github > > Talking to Rust devs about what works, what doesn't > > Talking to GHC devs about what works, what doesn't, > comparing/contrasting with other processes such as Rust's > > Papering all this up into a "where we are, where we'd like to go" document > > Writing documentation and tutorials for getting new developers on board > > Manually on-boarding new developers > > I am willing to do this work in addition to my 9-5 work using Haskell, > the book(s) which are a full-time job unto themselves, and the open > source work I do. > > I will not do any of this as long as this is the attitude of GHC > developers. I can not in good conscience encourage people to > contribute to a project controlled and represented with such hostility > and dismissiveness. The needs of the community and of new and casual > contributors have to be taken seriously. This is not for their sake > alone, it's to ease the workload of the maintainers and to mend the > worsening culture gap. > > > On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery > wrote: > > > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty > > wrote: > >> > >> Why are you so hostile to Chris? I don’t think that this is an > appropriate > >> way to treat somebody who is making a suggestion in good faith. > > > > > > It may be in good faith. but it's not in good sense. There is a lot in > the > > background that made Rust's setup possible, and he's not bringing that to > > the table, just assuming it'll somehow happen or that everyone else will > > drop everything for the next few months and make it happen. And I feel > like > > he's being really pushy about committing already overworked people to > this > > --- and insisting that anyone opposed must have a hidden agenda or > otherwise > > cannot possibly have good reason to be opposed. It's not helpful at all; > > it's basically a good way to stall ghc for the next few months at least. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b at gmail.com > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Sun Sep 25 01:44:23 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 24 Sep 2016 18:44:23 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: Sorry, but I see little sense in what you are bringjng to this discussion. Chris's points sre explaining some systemic reasons WHY there is a dearth of contributors, and attempting to make a constructive plan to address them. Why should GHC not try to emulate a community that has fantasic cohesion, unity, and participation? It is irrelevant why Rust has an advantage. Lets please emulate their successful strategies instead of in-fighting. To me it seems you are just attacking his view with bluster and ad hominem, with undertones of a personal vendetta against Rust. On Saturday, September 24, 2016, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > chak at justtesting.org > > wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Sep 25 01:56:38 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Sep 2016 21:56:38 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan wrote: > It is irrelevant why Rust has an advantage. Lets please emulate their > successful strategies instead of in-fighting. > Does that include having Mozilla Corp. backing them? What is your suggestion for this? I understand that you think this is an important cause for the dearth of contributors --- I've watched enough would-be contributors bounce off the code base (long before even considering the tooling) and give up to have major doubts, as underlined by Richard's recent message --- but throwing everything out and building a new infrastructure is not something that happens by itself. It needs *people* and it needs *time*. And it's harder (and needs more people and more time) when you have a couple decades' worth of history (which Rust did not). If you have a solution to this problem, I'm sure people would like to hear it. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Sun Sep 25 06:16:52 2016 From: dagitj at gmail.com (Jason Dagit) Date: Sat, 24 Sep 2016 23:16:52 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen wrote: > I'd be willing to help with work required to open up GHC development > more along multiple lines including: > > Bots/automation for Github > > Talking to Rust devs about what works, what doesn't > Last year I approached some folks in the rust community because I wanted to learn how to contribute to the rust compiler. In my experience, the really special thing they had was an identified pool of contributors who were willing and able to provide mentoring. I got hooked up with a mentor and that made all the difference. I had a real live person I could talk to about the process, the process-meta, and that person had context with me. Pretty much everything else was just details. GHC dev probably has mentors too, but I don't know because I've never thought to check or ask. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Sun Sep 25 06:37:12 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 25 Sep 2016 12:07:12 +0530 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: It will be great to have something like that. Something that you figure out digging at ghc trac wiki pages, mailing lists, google search etc will be a few minutes job for a mentor. It may be a bit taxing on the mentors but they can limit how many newbies they are mentoring and also breed new mentors to keep the cycle going. -harendra On 25 September 2016 at 11:46, Jason Dagit wrote: > > > On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen > wrote: > >> I'd be willing to help with work required to open up GHC development >> more along multiple lines including: >> >> Bots/automation for Github >> >> Talking to Rust devs about what works, what doesn't >> > > Last year I approached some folks in the rust community because I wanted > to learn how to contribute to the rust compiler. In my experience, the > really special thing they had was an identified pool of contributors who > were willing and able to provide mentoring. I got hooked up with a mentor > and that made all the difference. I had a real live person I could talk to > about the process, the process-meta, and that person had context with me. > Pretty much everything else was just details. > > GHC dev probably has mentors too, but I don't know because I've never > thought to check or ask. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Sep 25 07:18:23 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 25 Sep 2016 16:18:23 +0900 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: <1474787903.6881.2.camel@joachim-breitner.de> Hi, > It will be great to have something like that. Something that you > figure out digging at ghc trac wiki pages, mailing lists, google > search etc will be a few minutes job for a mentor. It may be a bit > taxing on the mentors but they can limit how many newbies they are > mentoring and also breed new mentors to keep the cycle going. I hope and assume that already now that every possible contributor who has questions like this and asks (e.g. on irc) will get a helpful answer. Is that insufficient? Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From harendra.kumar at gmail.com Sun Sep 25 08:23:32 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 25 Sep 2016 13:53:32 +0530 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1474787903.6881.2.camel@joachim-breitner.de> References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> <1474787903.6881.2.camel@joachim-breitner.de> Message-ID: On 25 September 2016 at 12:48, Joachim Breitner wrote: > Hi, > > > It will be great to have something like that. Something that you > > figure out digging at ghc trac wiki pages, mailing lists, google > > search etc will be a few minutes job for a mentor. It may be a bit > > taxing on the mentors but they can limit how many newbies they are > > mentoring and also breed new mentors to keep the cycle going. > > I hope and assume that already now that every possible contributor who > has questions like this and asks (e.g. on irc) will get a helpful > answer. Is that insufficient? Maybe. Though irc seems to be quite popular among Haskell community and other open source communities I have never been able to utilize it somehow. I don't know if there is something wrong with it or with me. I installed an irc client logged into it once or twice but never got hooked to it. Such questions on ghc-devs maybe a nuisance for a lot of other people or at least that's what I felt as a newbie. I usually tend to do a lot of homework before sending a question to ghc-devs. Maybe a ghc-newbies like mailing list (one more list!) can give the impression of a lower barrier for sending stupid or operational questions. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sun Sep 25 08:35:08 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 25 Sep 2016 09:35:08 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> <1474787903.6881.2.camel@joachim-breitner.de> Message-ID: If we loop this discussion back to the original post. There is a suggestion in there which seems to be what you are looking for. > Have a GHC StackOverflow on haskell.org (Jacob Zalewski jakzale at gmail.com offers to do this! – thank you). It has a useful new Documentation feature. Eg this would be good for “how do I look up a RdrName to get a Name… there seem to be six different functions that do that”. It is also probably lost that I said there was a phabricator module 'ponder' which gives this kind of functionality so it should be quick and easy to setup. Matt On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar wrote: > > > On 25 September 2016 at 12:48, Joachim Breitner > wrote: >> >> Hi, >> >> > It will be great to have something like that. Something that you >> > figure out digging at ghc trac wiki pages, mailing lists, google >> > search etc will be a few minutes job for a mentor. It may be a bit >> > taxing on the mentors but they can limit how many newbies they are >> > mentoring and also breed new mentors to keep the cycle going. >> >> I hope and assume that already now that every possible contributor who >> has questions like this and asks (e.g. on irc) will get a helpful >> answer. Is that insufficient? > > > Maybe. Though irc seems to be quite popular among Haskell community and > other open source communities I have never been able to utilize it somehow. > I don't know if there is something wrong with it or with me. I installed an > irc client logged into it once or twice but never got hooked to it. Such > questions on ghc-devs maybe a nuisance for a lot of other people or at least > that's what I felt as a newbie. I usually tend to do a lot of homework > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing list > (one more list!) can give the impression of a lower barrier for sending > stupid or operational questions. > > -harendra > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eacameron at gmail.com Sun Sep 25 11:47:04 2016 From: eacameron at gmail.com (Elliot Cameron) Date: Sun, 25 Sep 2016 07:47:04 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> <1474787903.6881.2.camel@joachim-breitner.de> Message-ID: Oh how the chatroom hath slain its thousands, and email its ten thousands! Flattening real, hard-working, deep-thinking people into a few paragraphs of letters does such injustice to propinquity that it's a wonder it ever works at all! It's for that very reason I want to voice my approval of the idea of mentors. The thing that IRC cannot give you is a (real) name and a real face. The true fabric underlying any process or system is the people that make it happen. If the relationships of the people are broken, no virtual system will ever be able to recover the loss. I can't help but believe that the best way to improve the community of contributors is to improve the relationships of the people in it. Therefore, having a process of providing mentorship could be the most effective way to address the myriad technical difficulties of contributing to GHC. Love covers a multitude of wrongs. A friendly helper could easily make up for the technical infelicities or inexperience. In the long term, the improved strength of community could begin to address any technical issues as well. That said, I am not sure if mentorship is a burden the current "in-crowd" would be able to bear. But even with minimal hand-holding the improvement to propinquity could have significant effect. Lastly, as one who is building his business, in part, on the advantage of Haskell, I want to express my deep gratitude to both sides of the debate. Chris, your efforts to improve the "on-boarding" process are truly herculean and a massive investment to the community. Thank you! Matthew, and other core devs, your hard work and world-class insight make Haskell the technology that it is today and I cannot thank you enough. Elliot Cameron On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > If we loop this discussion back to the original post. There is a > suggestion in there which seems to be what you are looking for. > > > Have a GHC StackOverflow on haskell.org (Jacob Zalewski > jakzale at gmail.com offers to do this! – thank you). It has a useful new > Documentation feature. Eg this would be good for “how do I look up a > RdrName to get a Name… there seem to be six different functions that do > that”. > > It is also probably lost that I said there was a phabricator module > 'ponder' which gives this kind of functionality so it should be quick > and easy to setup. > > Matt > > On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar > wrote: > > > > > > On 25 September 2016 at 12:48, Joachim Breitner < > mail at joachim-breitner.de> > > wrote: > >> > >> Hi, > >> > >> > It will be great to have something like that. Something that you > >> > figure out digging at ghc trac wiki pages, mailing lists, google > >> > search etc will be a few minutes job for a mentor. It may be a bit > >> > taxing on the mentors but they can limit how many newbies they are > >> > mentoring and also breed new mentors to keep the cycle going. > >> > >> I hope and assume that already now that every possible contributor who > >> has questions like this and asks (e.g. on irc) will get a helpful > >> answer. Is that insufficient? > > > > > > Maybe. Though irc seems to be quite popular among Haskell community and > > other open source communities I have never been able to utilize it > somehow. > > I don't know if there is something wrong with it or with me. I installed > an > > irc client logged into it once or twice but never got hooked to it. Such > > questions on ghc-devs maybe a nuisance for a lot of other people or at > least > > that's what I felt as a newbie. I usually tend to do a lot of homework > > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing > list > > (one more list!) can give the impression of a lower barrier for sending > > stupid or operational questions. > > > > -harendra > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakzale at gmail.com Sun Sep 25 14:09:23 2016 From: jakzale at gmail.com (Jakub Zalewski) Date: Sun, 25 Sep 2016 14:09:23 +0000 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> <1474787903.6881.2.camel@joachim-breitner.de> Message-ID: Hi all, I agree with Elliot that the idea of a mentor is really cool, but may not be feasible at the moment. While the "on-demand" support (irc, reddit) from the community is great, I believe that a potential new contributor should be able to go as far as possible on their own because: - newcomers may be hesitant to ask dumb questions about GHC (I know I was). - newcomers may get turned away as the task will seems more complicated that it is. - the number of people working full-time on GHC is low. For that, there needs to be a single and accessible place, where newcomers can go and learn about ghc internals, the overall process, and what should the do next to contribute. Currently, there is wiki on trac, which is sometimes correct, sometimes outdated, sometimes slightly chaotic, and sometimes difficult to use. In addition to wiki, every member in the community is actively encouraged to try out new features in ghc and blog about their experience, which works perfectly fine for a tightly knit community, but presents an insurmountable barrier of entry for newcomers. I proposed using stack overflow, as they are adding a new feature called [documentation](http://stackoverflow.com/documentation), which allows to maintain a list of examples for a given tag. For instance, there is a stack overflow documentation for [haskell]( http://stackoverflow.com/documentation/haskell/topics). Furthermore, I believe that most potential newcomers will be familiar with using stack overflow. Next week, I will start cleaning up the wiki, as there are some pages and guides for newcomers which are out of date and cause unnecessary headaches for people that are unfamiliar with ghc. I will figure out and fill any missing information regarding checking out the source and I will check if there are any wiki entries that need to be deduplicated. Best wishes, Jakub On Sun, 25 Sep 2016 at 20:47, Elliot Cameron wrote: > Oh how the chatroom hath slain its thousands, and email its ten thousands! > Flattening real, hard-working, deep-thinking people into a few paragraphs > of letters does such injustice to propinquity that it's a wonder it ever > works at all! > > It's for that very reason I want to voice my approval of the idea of > mentors. The thing that IRC cannot give you is a (real) name and a real > face. The true fabric underlying any process or system is the people that > make it happen. If the relationships of the people are broken, no virtual > system will ever be able to recover the loss. I can't help but believe that > the best way to improve the community of contributors is to improve the > relationships of the people in it. Therefore, having a process of providing > mentorship could be the most effective way to address the myriad technical > difficulties of contributing to GHC. Love covers a multitude of wrongs. A > friendly helper could easily make up for the technical infelicities or > inexperience. In the long term, the improved strength of community could > begin to address any technical issues as well. > > That said, I am not sure if mentorship is a burden the current "in-crowd" > would be able to bear. But even with minimal hand-holding the improvement > to propinquity could have significant effect. > > Lastly, as one who is building his business, in part, on the advantage of > Haskell, I want to express my deep gratitude to both sides of the debate. > Chris, your efforts to improve the "on-boarding" process are truly > herculean and a massive investment to the community. Thank you! Matthew, > and other core devs, your hard work and world-class insight make Haskell > the technology that it is today and I cannot thank you enough. > > Elliot Cameron > > On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > >> If we loop this discussion back to the original post. There is a >> suggestion in there which seems to be what you are looking for. >> >> > Have a GHC StackOverflow on haskell.org (Jacob Zalewski >> jakzale at gmail.com offers to do this! – thank you). It has a useful new >> Documentation feature. Eg this would be good for “how do I look up a >> RdrName to get a Name… there seem to be six different functions that do >> that”. >> >> It is also probably lost that I said there was a phabricator module >> 'ponder' which gives this kind of functionality so it should be quick >> and easy to setup. >> >> Matt >> >> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar >> wrote: >> > >> > >> > On 25 September 2016 at 12:48, Joachim Breitner < >> mail at joachim-breitner.de> >> > wrote: >> >> >> >> Hi, >> >> >> >> > It will be great to have something like that. Something that you >> >> > figure out digging at ghc trac wiki pages, mailing lists, google >> >> > search etc will be a few minutes job for a mentor. It may be a bit >> >> > taxing on the mentors but they can limit how many newbies they are >> >> > mentoring and also breed new mentors to keep the cycle going. >> >> >> >> I hope and assume that already now that every possible contributor who >> >> has questions like this and asks (e.g. on irc) will get a helpful >> >> answer. Is that insufficient? >> > >> > >> > Maybe. Though irc seems to be quite popular among Haskell community and >> > other open source communities I have never been able to utilize it >> somehow. >> > I don't know if there is something wrong with it or with me. I >> installed an >> > irc client logged into it once or twice but never got hooked to it. Such >> > questions on ghc-devs maybe a nuisance for a lot of other people or at >> least >> > that's what I felt as a newbie. I usually tend to do a lot of homework >> > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing >> list >> > (one more list!) can give the impression of a lower barrier for sending >> > stupid or operational questions. >> > >> > -harendra >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Sep 25 14:58:55 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 25 Sep 2016 10:58:55 -0400 Subject: Adding ConApp to Core In-Reply-To: References: Message-ID: I'm in favor as well. I've some experiments I'd like to do on ghc (and that work would support me focusing on!!!) that become dramatically simpler to get the the Simons seal of approval if core already gets multiple arg / simultaneous arg saturated application (a la type are calling or sequent core ). :) -Carter On Saturday, September 24, 2016, Manuel M T Chakravarty < chak at justtesting.org> wrote: > I like this. Having the DataCon only in IdDetails always felt a bit off. > > Manuel > > Simon Peyton Jones via ghc-devs >: > > Andres, Richard, Stephanie > > The more I think about our idea of introducing ConApp the more I like it. > I wrote it up in a ticket > > https://ghc.haskell.org/trac/ghc/ticket/12618 > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Sep 25 14:59:56 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 25 Sep 2016 10:59:56 -0400 Subject: Adding ConApp to Core In-Reply-To: References: Message-ID: Also this whole multi arg thing was something I was hoping to talk with Stephanie and or Richard about at hac phi next month. On Sunday, September 25, 2016, Carter Schonwald wrote: > I'm in favor as well. > > I've some experiments I'd like to do on ghc (and that work would support > me focusing on!!!) that become dramatically simpler to get the the Simons > seal of approval if core already gets multiple arg / simultaneous arg > saturated application (a la type are calling or sequent core ). > :) > -Carter > > On Saturday, September 24, 2016, Manuel M T Chakravarty < > chak at justtesting.org > > wrote: > >> I like this. Having the DataCon only in IdDetails always felt a bit off. >> >> Manuel >> >> Simon Peyton Jones via ghc-devs : >> >> Andres, Richard, Stephanie >> >> The more I think about our idea of introducing ConApp the more I like >> it. I wrote it up in a ticket >> >> https://ghc.haskell.org/trac/ghc/ticket/12618 >> >> Simon >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sun Sep 25 18:05:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 25 Sep 2016 18:05:38 +0000 Subject: Getting rid of -XImpredicativeTypes Message-ID: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial.... if it works, it's really a fluke. We don't really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter... if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I'm on a plane, so I'm going to at least start with an email. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Sep 25 18:16:31 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 25 Sep 2016 14:16:31 -0400 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: Sounds good to me. Such a change actually probably be good for reducing ghc support load around flags that don't work and increase reasons why using explicit type application will be awesome / more expressive than what I would otherwise be able to do with proxy arguments Tldr +1 A) reduces amount of community support load around unsupported flags B) makes visible type application extension meaningfully stronger / more powerful than proxy value approaches On Sunday, September 25, 2016, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Friends > > > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to > support impredicative polymorphism. But it is vestigial…. if it works, > it’s really a fluke. We don’t really have a systematic story here at all. > > > > I propose, therefore, to remove it entirely. That is, if you use > -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. > complete no-op) and you should remove it. > > > > Before I pull the trigger, does anyone think they are using it in a > mission-critical way? > > > > Now that we have Visible Type Application there is a workaround: if you > want to call a polymorphic function at a polymorphic type, you can > explicitly apply it to that type. For example: > > > > {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} > > module Vta where > > f x = id @(forall a. a->a) id @Int x > > > > You can also leave out the @Int part of course. > > > > Currently we have to use -XImpredicativeTypes to allow the @(forall a. > a->a). Is that sensible? Or should we allow it regardless? I rather > think the latter… if you have Visible Type Application (i.e. > -XTypeApplications) then applying to a polytype is nothing special. So I > propose to lift that restriction. > > > > I should go through the GHC Proposals Process for this, but I’m on a > plane, so I’m going to at least start with an email. > > > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun Sep 25 18:26:04 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 25 Sep 2016 11:26:04 -0700 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: <1474827921-sup-8493@sabre> A ghc-proposals is a good way to solicit feedback and publicize more widely. At least a proposal is worth it (and I am in favor of removing ImpredicativeTypes, FWIW). Edward Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-25 18:05:38 +0000: > Friends > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial.... if it works, it's really a fluke. We don't really have a systematic story here at all. > > I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete no-op) and you should remove it. > > Before I pull the trigger, does anyone think they are using it in a mission-critical way? > > Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: > > > {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} > > module Vta where > > f x = id @(forall a. a->a) id @Int x > > You can also leave out the @Int part of course. > > Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter... if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. > > I should go through the GHC Proposals Process for this, but I'm on a plane, so I'm going to at least start with an email. > > Simon From mgsloan at gmail.com Sun Sep 25 19:57:13 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Sun, 25 Sep 2016 12:57:13 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> <1474787903.6881.2.camel@joachim-breitner.de> Message-ID: Ideally, sure, having Mozilla backing would be great and thoroughly appreciated! I understand that change takes effort. I think the core problem is participant psychology. How do we encourage people to take ownership for these problems? Perhaps more importantly, how does power get delegated such that things get done by new enthusiastic contributors? I am not very involved in GHC development (yet! we'll see - I've got a lot to do elsewhere), so I don't have a very concrete proposal. To me, seems imminently reasonable to directly emulate the approach of similar opensource projects,which have healthy, inspiring participation. I am not saying that GHC dev is sickly - we all appreciate the massive amount of effort you guys undertake on a regular basis. I am saying that we should strive to reduce participation friction and lower the barrier to entry. Lowering the barrier to entry is not trivial, it can also be accompanied by a reduction in quality. However, I think in the long run having many more contributors, many more eyes on the code, will be a net boon, even if individual contribution quality is initially lower than the current high bar of excellence. Directly emulating projects like Rust can cut through the indecision and give a direct way to reuse the efforts that community has already undertaken to solve these systemic issues. On the code review side of things, I have my preferences (github), due to its popularity and my personal familiarity with it, but I also understand that there is a lot of momentum and expertise around phabricator. If we can knock down these barriers without a herculean effort, why not give it a try? -Michael Sloan On Sat, Sep 24, 2016 at 6:56 PM, Brandon Allbery > wrote: > > On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan > wrote: >> >> It is irrelevant why Rust has an advantage. Lets please emulate their >> successful strategies instead of in-fighting. > > > Does that include having Mozilla Corp. backing them? What is your suggestion > for this? > > I understand that you think this is an important cause for the dearth of > contributors --- I've watched enough would-be contributors bounce off the > code base (long before even considering the tooling) and give up to have > major doubts, as underlined by Richard's recent message --- but throwing > everything out and building a new infrastructure is not something that > happens by itself. It needs *people* and it needs *time*. And it's harder > (and needs more people and more time) when you have a couple decades' worth > of history (which Rust did not). If you have a solution to this problem, I'm > sure people would like to hear it. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Sep 25 22:02:47 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 25 Sep 2016 18:02:47 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion Message-ID: In writing the following huge wall of text, I had and idea that I think many folks would find palatable: What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple! What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever! My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period. Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both. My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup. I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that! I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against ) On Saturday, September 24, 2016, Brandon Allbery wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > chak at justtesting.org > > wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Sun Sep 25 23:53:56 2016 From: dan.doel at gmail.com (Dan Doel) Date: Sun, 25 Sep 2016 19:53:56 -0400 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: I don't use the extension, because it's more pleasant to use newtypes with polymorphic contents. But here are some questions: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? Anyhow, if it can't be fixed, I think not having the extension is superior to its current state. And really, I think even if fixing it were on the roadmap, it'd be better to get rid of it until it were actually fixed. -- Dan On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Friends > > > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to > support impredicative polymorphism. But it is vestigial…. if it works, > it’s really a fluke. We don’t really have a systematic story here at all. > > > > I propose, therefore, to remove it entirely. That is, if you use > -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. > complete no-op) and you should remove it. > > > > Before I pull the trigger, does anyone think they are using it in a > mission-critical way? > > > > Now that we have Visible Type Application there is a workaround: if you > want to call a polymorphic function at a polymorphic type, you can > explicitly apply it to that type. For example: > > > > {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} > > module Vta where > > f x = id @(forall a. a->a) id @Int x > > > > You can also leave out the @Int part of course. > > > > Currently we have to use -XImpredicativeTypes to allow the @(forall a. > a->a). Is that sensible? Or should we allow it regardless? I rather > think the latter… if you have Visible Type Application (i.e. > -XTypeApplications) then applying to a polytype is nothing special. So I > propose to lift that restriction. > > > > I should go through the GHC Proposals Process for this, but I’m on a > plane, so I’m going to at least start with an email. > > > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Sep 26 01:27:04 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 25 Sep 2016 21:27:04 -0400 Subject: How, precisely, can we improve? Message-ID: Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. I'd like to move the conversation forward -- and I'd like to do so on a technical basis. So, I ask: How, precisely, can we improve? I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html), I look forward to a similarly technical, respectful discussion on our contribution process. Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Mon Sep 26 03:03:38 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Mon, 26 Sep 2016 11:03:38 +0800 Subject: How, precisely, can we improve? In-Reply-To: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> Message-ID: <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Richard, thank you for trying to give this some technical basis. As someone who as contributed some tiny bugfixes to ghc, I found the process a bit cumbersome, yet manageable[1]. I’d however like to propose some concrete changes, and please excuse if these have been discussed and found to not be actionable. What I’d really like to see improved is the “multiple (web)services, multiple accounts” issue solved. As it is right now I need to have a github account (ghc-proposals, soon tiny PR against ghc), a trac account (for the wiki and issue tracker; which never seems to remember me), a phabricator account[2], likely a stack overflow account for questions and answers. On top of that I also need to be on a large set of mailing lists if I want to not miss anything, and an irc client and twitter client to tap into the most recent discussions. And there’s another wiki on haskell.org for which I would need to sign up and get an approved account. I’d like to see the following: 1. Unify the issue tracker and code review into phabricator. Hence *if* I want to contribute to the ghc codebase, I essentially only need a phabricator account[3]. And a simple one page website on haskell.org that runs me through the “Contributing to GHC” as in: > GHC Development is facilitated through phabricator. > > Please go to https://phabricator.haskell.org[4] and > create an account. > > If you want to report a bug, please file a bugreport through > the “Maniphest” module, you can find on the left. > > If you are looking for something to contribute, and browse the > Open Tasks at https://phabricator.haskell.org/maniphest/query/open/[5] > > Clone the GHC tree and build it > [ clone and build instructions here; note about stage2 pinning to reduce compile times and other > build system features ] > > Hack to your hearts content on GHC (you might get some quick responses > regarding ghc’s internals at irc://irc.freenode.net/ghc, as well as in > the ghc commentary at …[6], or the ghc-dev mailing list for which you > can sign up at ...) > > Validate your build [ plus instructions how to do so, and how to run > performance measurements on the changed ghc; if one is interested in > that as well ] > > Upload your patch to GHC using the arc command line tool. You will have > to set up your token during the first use, just follow the instructions. > > To upload your patch, commit your local changes; and run > $ arc diff origin/master > > arc will run a few linters against your diff, and provide you with a form > to fill in all the details regarding your patch. This form is usually > prepopulated with the commit messages from your local commits. > > During the review process you might have to update your diff. To do so > you can rebase your changes against the most recent master and/or add > additional commits to it; once you are done updating your patch, run > $ arc diff --update > > Once your diff has been accepted, someone with commit rights with “land” your > diff into the official ghc tree. And have this prominently liked from https://www.haskell.org/ under “Contributing” 2. Move the Wiki someplace else. I don’t know if the wiki in phabricator is any good, I’ve never used it. However, finding something in the ghc wiki has been more hit and miss for me than anything else. The built in search almost never reveals what I’m looking for, and resorting to a search engine only sometimes helps me find what I’m looking for. (This might totally be my fault). 3. Reduce the number of Mailing lists. I’m supposedly not on the haskell ml; so I missed https://mail.haskell.org/pipermail/haskell/2016-September/024995.html, and only saw it due to https://twitter.com/ezyang/status/780134457101516800. Are our MLs really that high volume that we need so many? 4. I like the idea of trivial pull requests to be accepted on GH as well. And I don’t see it as a big hurdle to ask someone to please be so kind and submit the patch through phabricator if it’s more involved with a link to https://www.haskell.org/contributing (see above). In conclusion I’d like to propose to reduce the fragmentation of tooling, and accept the status quo of what open source development seems looks like to many (github for code, stackoverflow questions (and documentation soon?)) as much as we can. Cheers, Moritz — [1]: I didn’t understand phabriactor and arc in the beginning, however today I appreciate the process phabricator and arc offer a lot! (Over PRs) [2]: for which you can actually use your bitbucket, github, twitter, … account. [3]: I will also need some access to the staging area, if I want to use that feature. [4]: Can we have http://phabricator.haskell.org redirect to https://phabricator.haskell.org? Instead of having both? [5]: I guess one could create some Trivial, Easy, Medium and Hard queries. [6]: This is currently scattered across the trac wiki. > On Sep 26, 2016, at 9:27 AM, Richard Eisenberg wrote: > > Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. > > I'd like to move the conversation forward -- and I'd like to do so on a technical basis. > > So, I ask: > How, precisely, can we improve? > > I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. > > As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. > > "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) > > "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) > > "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html > > "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. > > "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. > > Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html), I look forward to a similarly technical, respectful discussion on our contribution process. > > Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mgsloan at gmail.com Mon Sep 26 06:33:55 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Sun, 25 Sep 2016 23:33:55 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: I like this solution a lot, Carter! Mailing patches directly to the ghc-devs list could be intimidating for newcomers. Having a list specific to patch review could make the process less intimidating. From a perspective of overall contribution intimidation, these 2 pages make it seem like a ton of extra work to contribute to GHC: 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures Of course, I understand that these exist for a reason. Contributing to GHC isn't easy, and it does need processes, and those processes should be followed! However, for documentation patches and minor fixes, these pages make it seem like you really have to put in quite a bit to get started, and that the process is bureaucratic. Atop getting accounts setup and figuring out how to get ghc compiled, the amount of time investment to get in a simple patch already seems like it is on the order of hours, if not a full days worth of work. At the risk of accumulating spam, perhaps the list shouldn't even require membership? Just have it filter based on containing an attachment (perhaps even require a "*.patch" attachment?) I also think that there should be an easy way to put a stop to iterating via email and sending .patch files, and escalate to a phabricator review. Perhaps this could be scripted? Is there any way for people to use phabricator without using archanist? Not a criticism of the tech, but it is more to learn, and foreign to most. One thing I've learned from maintaining stack, is that it can be really helpful to accept patches that are imperfect. Here's how this works: 1) Some user wants to fix something, and doesn't quite nail it. Maybe makes some style mistakes, spelling errors in comments, or perhaps writes some part of the code in a less direct way than possible 2) If the overall change is an improvement and the fixes are easy, I go ahead and merge the imperfect patch, and then commit my own fixes to the issues I saw. I then say something like "Thanks for the patch!! I fixed a few things in e5cbda" I feel like this is a highly valuable approach. The contributor appreciates being thanked, and also appreciates directly seeing the ways that their patch could have been better. This is antithetical to the "google style" of code review, where every single thing is nit-picked and the author must fix it. I think that approach only works well when you already have an established membership to that culture of code review (particularly if you are getting paid for it). With that approach, all of the bad behaviors get beaten out of contributors, and they eventually learn their lesson, and either leave or become good contributors. I think this can scare some people off, that might otherwise become regular contributors. Who knows if this will work out, but I think it is really worth a shot! Especially if the wiki is updated to indicate that there is now an "easy mode" for contributing to ghc. -Michael On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald wrote: > In writing the following huge wall of text, I had and idea that I think many > folks would find palatable: > > What if simple small patches (such as hypothetical drive by doc patches ) > had a mailing list where folks could email the simple / small patches as > email attachments plus a body text that summarizes the patch, what it does, > and why it's simple! > > What's even nice about this is its future proof and even agnostic to how the > contributor made the change set locally! They could use mercurial or fossil > for all we care. Or github. Or whatever! > > > > My personal stance is that ghc already way easier to contribute to / get > involved with than it was 2-5 years ago. This is even more impressive when > you consider the number of contributors (who aren't students) that focus on > ghc work full time has actually DECREASED over that period. > > Community engagement / management is a totally orthogonal skill from > contributing. Both take effort. Guiding new contributors requires both. > > My personal stance is that ghc keeps on getting better and getting more > contributors. And occasionally chatting about ways to make things better > that we have the bandwidth to do is something that should happen every year > or so. Like a health checkup. > > I suspect one funnel for improvement may be figuring out how to make it more > visible how many contributors / how actively deved various subsystems are. > I feel like many new folks veer towards subsystems that are already actively > worked on, which are often the ones that are both the most mature and thus > hardest to easily contribute to! Perhaps I should see if there's an easy way > to quantify that in a way that's easy to communicate to new contributors. > There's an interesting data presentation challenge in that! > > I've definitely found that for new potential contributors that orienting > them to focus on subsystem that's important but doesn't get much activity > leads to more successful first contributions. But that requires someone > actively helping orient folks, which I like to think I've helped out with at > points in recent years. Making this something that's easy to point at / > discover along with "newcomer tickets" might help a lot > > Tweaking the way we do tickets or code review I think doesn't change the > important / fundamental challenges of doing a good patch for a project like > ghc or llvm. (I think in some ways that llvm / gcc / clang are the right > size projects to compare ghc against ) > > > > On Saturday, September 24, 2016, Brandon Allbery > wrote: >> >> >> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty >> wrote: >>> >>> Why are you so hostile to Chris? I don’t think that this is an >>> appropriate way to treat somebody who is making a suggestion in good faith. >> >> >> It may be in good faith. but it's not in good sense. There is a lot in the >> background that made Rust's setup possible, and he's not bringing that to >> the table, just assuming it'll somehow happen or that everyone else will >> drop everything for the next few months and make it happen. And I feel like >> he's being really pushy about committing already overworked people to this >> --- and insisting that anyone opposed must have a hidden agenda or otherwise >> cannot possibly have good reason to be opposed. It's not helpful at all; >> it's basically a good way to stall ghc for the next few months at least. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From lonetiger at gmail.com Mon Sep 26 06:37:00 2016 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Mon, 26 Sep 2016 07:37:00 +0100 Subject: A few technical suggestions Message-ID: <57e8c20c.a699c20a.501d5.c921@mx.google.com> Hi All, I wanted to give my own thoughts/suggestions for things we could do on the short/medium term To make things a bit better. As a whole I may be one of the few who likes the current setup so I Propose enhancing the current toolset. I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest. And the discussion quickly becomes hard to follow as it branches lot. My proposals (sorry for the brevity, I can expand if needed): * Link phab to github Phabricator seems to have build in OAuth support. As you'll likely need a github account anyway, why not also support github logins? This would reduce the barrier of needing multiple accounts that is often a complaint. Would it be possible to maybe also extract the user's public key from github automatically? That would reduce one of the barriers as well. https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/ * Link Trac to github - used to login (OAuth support) - readonly issues (to begin with?). we already have a code mirror, why not mirror more content. - sync issues back between the two - gives us an ability to see which github users an issue affects since they can then reference it. - updates the users when an issue is fixed since it will be closed on GH. - Gives us an indication of the importance of the tickets As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, both of which seem to be quite bare and simple in what they provide. I am not in favor of ditching it. Also we have and continue to accept patches just uploaded to Trac as a diff. We tend to ask people to upload it to phab for better reviews and so it's attributed to them when we commit. Some don't (and we then do it ourselves), most due. If they don't need another login then I suspect almost all would. There's a (seemingly) actively maintained project that does all the above, could we leverage it? https://github.com/trac-hacks/trac-github * There is a trac plugin to generate a new section on trac /doc which allows you to render and edit documentations checked into repo. Could this be used to allow easier editing of non generated documentation? It's currently based on SVN, but maybe a git one exists too? https://github.com/trac-hacks/tracdocs * Newcomers - Expose newcomers information more by creating a new landing page - Clean up build instructions. For windows, I have scripts to automate setup. Often heard complain is that it is hard, but never hear why it's hard. In any case, my setup script for a 100% unattended build env setup for Windows are here: https://github.com/Mistuke/GhcDevelChoco/releases These are entirely self contained environments that can be removed by a simple rm -rf /. You can have as many as you want on the same machine without them interfering with eachother or with whatever else you might have done to your GHC already installed. It's not 100% production ready but it works and does so well. * Updated Phab reviewers list to be more automated - Assign reviewers next to the static list (as is currently done) to maybe also include significant contributors to that file? The reason for this is that currently it's always the same people reviewing patches. Their time is spread thin. Particularly on less popular platforms it basically comes down to 4 people. * Update trac linters and pre-commit linters to be the same. - particularly reject summaries that would be rejected on commit. Often when I try landing patches (especially from others) I have to edit the summary. Maybe arc should reject the diff if a push would fail? Also I want to say I love the summary document you have to fill in. It ensures useful information is there later when I have to find out why a change was made. So whatever we do, don't remove this. * Phab plugin to on signup ask for public key if none found. - It's recently been made a requirement to require a public key to push to phab. The error you get when you don't do this and try to push a patch is very very cryptic and unintuitive. Could we make a plugin that asks the user to upload a public key on trac if they haven't done so? Like a banner at the top? * Automate trac tickets - Particular on new tickets post a friendly reminder that if they want they can give it a hand in fixing it themselves. - Parse information added, in particular check if reproduction steps are there etc. - If stack is used, kindly ask if a repo without can be used. The amount of bug reports with stack is increasing and regardless of my own opinion on the tool, these reports are not very useful as is. - Maybe automatically CC people from a pool based on the information in the ticket? I tend to miss tickets because my filters are quite strict. Generally if the ticket doesn't mention my name, is directed at me or has "Windows" in the body somewhere it will skip my inbox. I review filtered tickets only once a week. - If a newcomer assigns a ticket to themselves, have trac automatically post links to useful pages: * how to setup build environment. * how to get help * assign a mentor? * after x amount of time with no progress, remind them again that help is available Kind Regards, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Sep 26 06:49:31 2016 From: lonetiger at gmail.com (Phyx) Date: Mon, 26 Sep 2016 06:49:31 +0000 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart. I have multiple mailing rules and other things just so I can keep track of comments. And then volume makes patches disappear into a void. We already have a lightweight process. Lots of people just attach the patch to trac. And we still accept it. Going to trac forces you to give me useful information about what you are trying to fix. A mailing list doesn't force a submitter to give me basic information about the patch. Such as which platform it effects. Also you can use phabricator.haskell.org without arc. You can manually upload a patch file to it. Again, phabricator's summerary file I find very useful. It may be annoying for drive by commiters, but when I have to come back to this code a year or so later, I need to know why it was added. On Mon, Sep 26, 2016, 07:34 Michael Sloan wrote: > I like this solution a lot, Carter! > > Mailing patches directly to the ghc-devs list could be intimidating > for newcomers. Having a list specific to patch review could make the > process less intimidating. From a perspective of overall contribution > intimidation, these 2 pages make it seem like a ton of extra work to > contribute to GHC: > > 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs > 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures > > Of course, I understand that these exist for a reason. Contributing > to GHC isn't easy, and it does need processes, and those processes > should be followed! > > However, for documentation patches and minor fixes, these pages make > it seem like you really have to put in quite a bit to get started, and > that the process is bureaucratic. Atop getting accounts setup and > figuring out how to get ghc compiled, the amount of time investment to > get in a simple patch already seems like it is on the order of hours, > if not a full days worth of work. > > At the risk of accumulating spam, perhaps the list shouldn't even > require membership? Just have it filter based on containing an > attachment (perhaps even require a "*.patch" attachment?) > > I also think that there should be an easy way to put a stop to > iterating via email and sending .patch files, and escalate to a > phabricator review. Perhaps this could be scripted? Is there any way > for people to use phabricator without using archanist? Not a > criticism of the tech, but it is more to learn, and foreign to most. > > > One thing I've learned from maintaining stack, is that it can be > really helpful to accept patches that are imperfect. Here's how this > works: > > 1) Some user wants to fix something, and doesn't quite nail it. Maybe > makes some style mistakes, spelling errors in comments, or perhaps > writes some part of the code in a less direct way than possible > > 2) If the overall change is an improvement and the fixes are easy, I > go ahead and merge the imperfect patch, and then commit my own fixes > to the issues I saw. I then say something like "Thanks for the > patch!! I fixed a few things in e5cbda" > > I feel like this is a highly valuable approach. The contributor > appreciates being thanked, and also appreciates directly seeing the > ways that their patch could have been better. > > This is antithetical to the "google style" of code review, where every > single thing is nit-picked and the author must fix it. I think that > approach only works well when you already have an established > membership to that culture of code review (particularly if you are > getting paid for it). With that approach, all of the bad behaviors > get beaten out of contributors, and they eventually learn their > lesson, and either leave or become good contributors. I think this > can scare some people off, that might otherwise become regular > contributors. > > > Who knows if this will work out, but I think it is really worth a > shot! Especially if the wiki is updated to indicate that there is now > an "easy mode" for contributing to ghc. > > -Michael > > On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald > wrote: > > In writing the following huge wall of text, I had and idea that I think > many > > folks would find palatable: > > > > What if simple small patches (such as hypothetical drive by doc patches ) > > had a mailing list where folks could email the simple / small patches as > > email attachments plus a body text that summarizes the patch, what it > does, > > and why it's simple! > > > > What's even nice about this is its future proof and even agnostic to how > the > > contributor made the change set locally! They could use mercurial or > fossil > > for all we care. Or github. Or whatever! > > > > > > > > My personal stance is that ghc already way easier to contribute to / get > > involved with than it was 2-5 years ago. This is even more impressive > when > > you consider the number of contributors (who aren't students) that focus > on > > ghc work full time has actually DECREASED over that period. > > > > Community engagement / management is a totally orthogonal skill from > > contributing. Both take effort. Guiding new contributors requires both. > > > > My personal stance is that ghc keeps on getting better and getting more > > contributors. And occasionally chatting about ways to make things better > > that we have the bandwidth to do is something that should happen every > year > > or so. Like a health checkup. > > > > I suspect one funnel for improvement may be figuring out how to make it > more > > visible how many contributors / how actively deved various subsystems > are. > > I feel like many new folks veer towards subsystems that are already > actively > > worked on, which are often the ones that are both the most mature and > thus > > hardest to easily contribute to! Perhaps I should see if there's an easy > way > > to quantify that in a way that's easy to communicate to new contributors. > > There's an interesting data presentation challenge in that! > > > > I've definitely found that for new potential contributors that orienting > > them to focus on subsystem that's important but doesn't get much activity > > leads to more successful first contributions. But that requires someone > > actively helping orient folks, which I like to think I've helped out > with at > > points in recent years. Making this something that's easy to point at / > > discover along with "newcomer tickets" might help a lot > > > > Tweaking the way we do tickets or code review I think doesn't change the > > important / fundamental challenges of doing a good patch for a project > like > > ghc or llvm. (I think in some ways that llvm / gcc / clang are the right > > size projects to compare ghc against ) > > > > > > > > On Saturday, September 24, 2016, Brandon Allbery > > wrote: > >> > >> > >> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty > >> wrote: > >>> > >>> Why are you so hostile to Chris? I don’t think that this is an > >>> appropriate way to treat somebody who is making a suggestion in good > faith. > >> > >> > >> It may be in good faith. but it's not in good sense. There is a lot in > the > >> background that made Rust's setup possible, and he's not bringing that > to > >> the table, just assuming it'll somehow happen or that everyone else will > >> drop everything for the next few months and make it happen. And I feel > like > >> he's being really pushy about committing already overworked people to > this > >> --- and insisting that anyone opposed must have a hidden agenda or > otherwise > >> cannot possibly have good reason to be opposed. It's not helpful at all; > >> it's basically a good way to stall ghc for the next few months at least. > >> > >> -- > >> brandon s allbery kf8nh sine nomine > >> associates > >> allbery.b at gmail.com > >> ballbery at sinenomine.net > >> unix, openafs, kerberos, infrastructure, xmonad > >> http://sinenomine.net > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Sep 26 07:00:16 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 03:00:16 -0400 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: <877f9zjgcf.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Friends > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt > to support impredicative polymorphism. But it is vestigial.... if it > works, it's really a fluke. We don't really have a systematic story > here at all. > Out of curiosity, what ever happened to the most recent attempt at addressing impredicativity [1]? As far as the proposal process is concerned, it would likely be a good idea to put together a proposal so we have somewhere to collect comments. That being said, it needn't be terribly lengthy given that we are merely removing a feature. Incidentally, that reminds me that I have some documentation fixes to the ghc-proposals repository that I should proof-read and push. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorphism/Impredicative-2015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From trupill at gmail.com Mon Sep 26 07:10:51 2016 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 26 Sep 2016 09:10:51 +0200 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: <877f9zjgcf.fsf@ben-laptop.smart-cactus.org> References: <877f9zjgcf.fsf@ben-laptop.smart-cactus.org> Message-ID: 2016-09-26 9:00 GMT+02:00 Ben Gamari : > Simon Peyton Jones via ghc-devs writes: > > > Friends > > > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt > > to support impredicative polymorphism. But it is vestigial.... if it > > works, it's really a fluke. We don't really have a systematic story > > here at all. > > > Out of curiosity, what ever happened to the most recent attempt at > addressing impredicativity [1]? > It turned our that the new system being proposed was not better than the current one. In particular, it was almost impossible to know upfront whether a program using impredicative types would need an annotation to typecheck. Furthermore, I think it would imply a humongous amount of changes to GHC, for not a very large gain. > > As far as the proposal process is concerned, it would likely be a good > idea to put together a proposal so we have somewhere to collect > comments. That being said, it needn't be terribly lengthy given that we > are merely removing a feature. > > Incidentally, that reminds me that I have some documentation fixes to > the ghc-proposals repository that I should proof-read and push. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorphism/ > Impredicative-2015 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon Sep 26 07:13:22 2016 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 26 Sep 2016 09:13:22 +0200 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: What would be the story for the types of the arguments. Would I be allowed to write the following? > f (lst :: [forall a. a -> a]) = head @(forall a. a -> a) lst 3 Regards, Alejandro 2016-09-25 20:05 GMT+02:00 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > Friends > > > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to > support impredicative polymorphism. But it is vestigial…. if it works, > it’s really a fluke. We don’t really have a systematic story here at all. > > > > I propose, therefore, to remove it entirely. That is, if you use > -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. > complete no-op) and you should remove it. > > > > Before I pull the trigger, does anyone think they are using it in a > mission-critical way? > > > > Now that we have Visible Type Application there is a workaround: if you > want to call a polymorphic function at a polymorphic type, you can > explicitly apply it to that type. For example: > > > > {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} > > module Vta where > > f x = id @(forall a. a->a) id @Int x > > > > You can also leave out the @Int part of course. > > > > Currently we have to use -XImpredicativeTypes to allow the @(forall a. > a->a). Is that sensible? Or should we allow it regardless? I rather > think the latter… if you have Visible Type Application (i.e. > -XTypeApplications) then applying to a polytype is nothing special. So I > propose to lift that restriction. > > > > I should go through the GHC Proposals Process for this, but I’m on a > plane, so I’m going to at least start with an email. > > > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 26 07:17:18 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Sep 2016 03:17:18 -0400 Subject: Solaris feature_tests.h Message-ID: <8737knjfk1.fsf@ben-laptop.smart-cactus.org> Hi Karel, A few months ago we reverted a cleanup [1] to PosixSource.h due to breakage on Solaris. I believe I have found [2] a build log from a failing build, but sadly it's far from clear what is going on. Do you suppose you could send us your /usr/include/sys/feature_tests.h? I suspect this will shed some light on what has gone wrong. For the record, I've opened #12624 to track this issue. Cheers, - Ben [1] https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e8fdedce9 [2] http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Sep 26 08:49:42 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Sep 2016 08:49:42 +0000 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) Yes, they’d disappear. 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? It’s just a swamp. I have tried multiple times to fix ImpredicativeTypes, and failed every time. Which is not to say that someone shouldn’t try again, with new thinking. Simon From: Dan Doel [mailto:dan.doel at gmail.com] Sent: 26 September 2016 00:54 To: Simon Peyton Jones Cc: ghc-users at haskell.org; ghc-devs at haskell.org Subject: Re: Getting rid of -XImpredicativeTypes I don't use the extension, because it's more pleasant to use newtypes with polymorphic contents. But here are some questions: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? Anyhow, if it can't be fixed, I think not having the extension is superior to its current state. And really, I think even if fixing it were on the roadmap, it'd be better to get rid of it until it were actually fixed. -- Dan On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs > wrote: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Mon Sep 26 08:52:41 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 26 Sep 2016 10:52:41 +0200 Subject: Solaris feature_tests.h In-Reply-To: <8737knjfk1.fsf@ben-laptop.smart-cactus.org> References: <8737knjfk1.fsf@ben-laptop.smart-cactus.org> Message-ID: <57E8E1D9.6020703@centrum.cz> Hi Ben, sending Oracle copyrighted header file to public mailing list is no-go for me, I hope you understand it. :-) Anyway, the problem with the patch[1] is simple: Oracle's Solaris 11 supports max: #define _POSIX_C_SOURCE 200112L #define _XOPEN_SOURCE 600 the patch[1] assigned values: #define _POSIX_C_SOURCE 200809L #define _XOPEN_SOURCE 700 which are not recognized by Oracle's feature_tests.h hence the complain and #error. I've verified this fact on both Solaris 11.2 and Solaris 11.3. On the other hand Illumos derivates should be OK with the definition of patch[1] as Illumos sometime in its history added handling for XPG7[2]. Basically if you look into history of Illumos feature_tests.h and you get the first commit[3], then you basically will see what's in Solaris 11.2/11.3 minus few really unrelated changes done in Solaris. I hope it's more clear now, what's happened with[1] on Solaris. Thanks! Karel [1] https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e8fdedce9 [2]: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/feature_tests.h [3]: https://raw.githubusercontent.com/illumos/illumos-gate/7c478bd95313f5f23a4c958a745db2134aa03244/usr/src/uts/common/sys/feature_tests.h On 09/26/16 09:17 AM, Ben Gamari wrote: > Hi Karel, > > A few months ago we reverted a cleanup [1] to PosixSource.h due to > breakage on Solaris. I believe I have found [2] a build log from a > failing build, but sadly it's far from clear what is going on. Do you > suppose you could send us your /usr/include/sys/feature_tests.h? I > suspect this will shed some light on what has gone wrong. > > For the record, I've opened #12624 to track this issue. > > Cheers, > > - Ben > > > [1] https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e8fdedce9 > [2] http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html > From marlowsd at gmail.com Mon Sep 26 09:24:26 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 26 Sep 2016 10:24:26 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: I would rather we *didn't* accept contributions via github, even for small patches, and instead put more effort into streamlining the Phabricator workflow. - Adding another input method complicates the workflow, users have to decide which one to use - Github is not integrated with our other infrastructure, while Phabricator is - Mutliple sources of contributions makes life harder for maintainers Let's make the Phabricator workflow easier. - Why not put arc in the repo, or provide a script that automatically downloads it and sets it up? - I also like the idea of auto-push if validate succeeds. Or a button that you can press on the diff that would do the same thing, so you can get code review first. - +1 to making the manual easier to build. The same goes for Haddocks; it's really hard to make a simple patch to the docs and test it right now. One other thing that came up but wasn't mentioned in the notes: let's be more prompt about reverting patches that break validate, even if they only break a test. Now that we have better CI support, we can easily identify breaking patches and revert them. Cheers Simon On 24 September 2016 at 02:44, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Friends > > > > Here are the notes I took from session 2 of the Haskell Implementors > Meeting. The bolding is my choice of emphasis. > > > > Simon > > > > · Doc bugs. Two kinds > > o Typos. Friction stops me > > o Explanations needed e.g. read/show > > · Lightweight pushes > > · Make user manual into its own repo, to make it easier to take > pull requests. But that makes it harder when making synchronised changes > to GHC and user manual. > > · *Auto-push*: Ability to push to Phab and have it committed > automatically if it validates. > > · Style guides. Is having a defined style solving a problem we > don’t really have? One piece of guidance: *adhere to the style of the > surrounding code*. Low priority. > > · Docker images. We should have one. > > · Remove old documentation! > > · Cross compilation is difficult. > > · *Have a GHC StackOverflow on haskell.org * > (Jacob Zalewski jakzale at gmail.com offers to do this! – thank you). It > has a useful new Documentation feature. Eg this would be good for “how do > I look up a RdrName to get a Name… there seem to be six different functions > that do that”. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Sep 26 11:26:07 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 26 Sep 2016 12:26:07 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: Thank you for this comment Anthony. I thought about it over the last day and think you have it spot on. This is the key sentence: > The truth is that it what I complained about is *not a problem* > for GHC devs in so far as they are happy doing GHC development! It seems that the point that you are getting at is that currently the development process is heavily optimised for existing developers. There are quite a few moving parts but once you get a handle on them all it works well for me at least. The argument seems to be that we should (much) more heavily optimise for new contributors. (I think this is what Chris is saying as well). What I am trying to say is that we should meet in the middle. We should keep using phabricator as for regular contributors github is too painful to use for a project of GHC's size (as rust exemplifies with the custom bots). In order to improve the newcomer's experience it would be beneficial to consolidate as much as possible to one domain so that new contributors have only one place to look. Does this sound sensible to you? I would also like to take this chance to apologies to Chris for cutting off the discussion we were having. I would appreciate it if you would directly respond to the suggestions in this message. Matt On Sun, Sep 25, 2016 at 2:13 AM, Anthony Cowley wrote: > On Sat, Sep 24, 2016 at 8:17 PM, Matthew Pickering > wrote: >> I think this comment is useful because it highlights the point that it >> isn't very clear what "the point" even is. >> > [snip] >> >> Ultimately, I'm not sure what exactly what the point is. I read posts >> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html >> ) and find myself disagreeing with almost every point. The comments in >> the reddit thread provide most of the refutations. The post doesn't >> address the >> fact that the feature was a small syntactic change which as erik >> pointed out, it perhaps the most difficult change to integrate as it >> must certainly pay it's way. > > > Matthew, if you are going to claim that you champion the concerns of > new contributers, you must do more than dismiss criticism without > offering a single word of reply. As I was involved in the discussion > you linked and remember it very differently than you, I went back to > try to understand what you possibly could have read. The top-level > replies are: > > - Me clarifying that I like GHC > - Someone who likes arc and notes, but hates the build system > - Someone who argued that a syntactic change would be the "deep end of > the difficulty pool" because they apparently did not realize the patch > was already done. > - Someone arguing that consistent style is not important > - A strangely worded suggestion that there exist refutations but it > would be inappropriate to mention them > - Agreement that GHC dev is off-putting > - Agreement that GHC dev is off-putting > - GHC is a great compiler > - Someone who likes GHC dev > - A pro GitHub post > - Someone complaining about how I was treated > > So, you read those comments in response to a specific, itemized, > literally bullet-pointed complaint that getting changes into GHC by an > outsider requires an ill-defined marathon of mailing lists and forums > in which GHC devs do not participate very much, and what you took away > from it was that the post was largely refuted. > > GHC is a fine research compiler and several people do tremendous work > on it. But please do not keep asking what the problem is if you are > going to completely ignore it when it is written down time and time > again. The truth is that it what I complained about is *not a problem* > for GHC devs in so far as they are happy doing GHC development! > Mystery solved, we can all move on with our lives productively using > GHC or contributing to it. Chris's reaction to the title of the talk > is entirely understandable to me, as I had interpreted it the same > way. > > Anthony From johnw at newartisans.com Mon Sep 26 16:00:10 2016 From: johnw at newartisans.com (John Wiegley) Date: Mon, 26 Sep 2016 09:00:10 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: (Carter Schonwald's message of "Sun, 25 Sep 2016 18:02:47 -0400") References: Message-ID: >>>>> "CS" == Carter Schonwald writes: CS> What if simple small patches (such as hypothetical drive by doc patches ) CS> had a mailing list where folks could email the simple / small patches as CS> email attachments plus a body text that summarizes the patch, what it CS> does, and why it's simple! Btw, the "patchwork" system was created to do just this: Observe patches sent to a mailing list, and collect them into a web-based list, where discussion and review can happen in a patch-centric way. Example: https://patchwork.kernel.org/project/kvm/list/ The Linux project has been using this system to manage patch contributions for many years now. It may be a bit too webby, but it's example of another system that tries to address this bit of the process. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From ben at smart-cactus.org Mon Sep 26 18:30:30 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 14:30:30 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> Message-ID: <87vaxiike1.fsf@ben-laptop.smart-cactus.org> Christopher Allen writes: >>I think the we'd want to restrict this to Diffs submitted by >>contributors who already possess commit bits and specifically include >>a "no-review" tag in the summary. > > Is this intended to address the issues new contributors have in > contributing to GHC? This looks more insider stuff that misses the > point if so. > To reiterate Joachim's point, this is a feature to try to make it easier for contributors who would normally push directly `master` to instead use Phabricator and hence go through CI. The tree being broken is bad for everyone: users, new- and regular-contributors alike. I think it's fair to say that this change will improve everyone's experience, even if it's aimed at regular contributors. > If new contributors are not part of a conversation about contributing > to GHC, when and where did that conversation happen and what is being > done about it? > It is important to remember that the ideas that were described at the head of this thread arose at a discussion at ICFP; I think it's fair to say that there is significantly more GHC-hacking experience per head in this group than average. Consequently, it's quite understandable if the ideas discussed there may have focused more on regular contributors than new contributors. However, I would like to emphasize that this does /not/ mean that we have no interest in hearing from beginning contributors. I would love to hear from those who feel lost in the current scheme. I spoke with a number of new contributors at ICFP who reported varying degrees of success. I would love to hear more experiences! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 26 18:45:11 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 14:45:11 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Carter Schonwald writes: > In writing the following huge wall of text, I had and idea that I think > many folks would find palatable: > > What if simple small patches (such as hypothetical drive by doc patches ) > had a mailing list where folks could email the simple / small patches as > email attachments plus a body text that summarizes the patch, what it does, > and why it's simple! > I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list. The problem of course is what subset of patches do we want to allow to be taken via GitHub. My suggested answer to that is any patch which, if I were to write it myself, I would feel comfortable pushing directly to the tree. Then there is the question of what do we do with pull requests opened which do not satisfy this criterion. In this case I would likely open a Phabricator Differential with the pull request and close the pull request with a link to the Diff. In the ideal case this will inspire the contributor to join the review process on Phabricator; in the worst case review turns up issues in the patch and the user gives up. Either way, at least the contributor feels his patch has been seen and given the attention it deserves. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 26 18:49:26 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 14:49:26 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: <87mviuijih.fsf@ben-laptop.smart-cactus.org> Phyx writes: > I dislike this approach, having to already deal with a project that does > patches via mailing lists it is very hard to follow conversations. As soon > as multiple people get involved things fall apart. > I think accepting pull requests via GitHub can be done with minimal involvement from existing contributors. All we need is one or two people to keep an eye on the PR queue and merge or transition-to-Phabricator PRs as they arrive. > I have multiple mailing rules and other things just so I can keep track of > comments. And then volume makes patches disappear into a void. > > We already have a lightweight process. Lots of people just attach the patch > to trac. And we still accept it. > > Going to trac forces you to give me useful information about what you are > trying to fix. A mailing list doesn't force a submitter to give me basic > information about the patch. Such as which platform it effects. > A commit message as you are forced to provide by Git should usually be sufficient here. Of course, there are always cases where users will offer insufficient commit descriptions, but this is something that only the pull request monitors should need to worry about. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 26 18:55:22 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 14:55:22 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: <87k2dyij8l.fsf@ben-laptop.smart-cactus.org> Jason Dagit writes: > On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen > wrote: > >> I'd be willing to help with work required to open up GHC development >> more along multiple lines including: >> >> Bots/automation for Github >> >> Talking to Rust devs about what works, what doesn't >> > > Last year I approached some folks in the rust community because I wanted to > learn how to contribute to the rust compiler. In my experience, the really > special thing they had was an identified pool of contributors who were > willing and able to provide mentoring. I got hooked up with a mentor and > that made all the difference. I had a real live person I could talk to > about the process, the process-meta, and that person had context with me. > Pretty much everything else was just details. > > GHC dev probably has mentors too, but I don't know because I've never > thought to check or ask. > Indeed we do! If you ever have questions just ask me via IRC or email. I'd be very happy to help. Even while I may not know the answer I (or anyone else in #ghc) will likely be able to send you to someone who does. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mgsloan at gmail.com Mon Sep 26 19:07:02 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 12:07:02 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution I think it would be acceptable for larger GitHub PRs to have some automated boilerplate response. Ideally this would look like: """ Thanks for making this patch! I've turned this into a Phab Differential xxx and closed this PR. Please create a differential account associated with your email address ..." """ The email address can be automatically pulled from commit metadata. If one is absent, then this automated process isn't possible. If it is present and So, I'm imagining a utility that interfaces between both GitHub and Phab,allowing the following commands: * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the patch to differential. It may attempt to migrate body and title of the initial post, but lets not bother with migrating any review data. * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the patch. This is used for merging small patches. It would not do an automated push. Maybe have "--push" also perform the push? So like if you are on master, then "ghc-hub merge https://github.com/ghc/ghc/pull/1 --push" would merge the patches and push to master. How does this sound? I like the idea a lot, and would enjoy helping with implementation, time permitting. I could possibly start hacking on it if others give the go ahead of "Yes, lets do that". -Michael On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: > Carter Schonwald writes: > >> In writing the following huge wall of text, I had and idea that I think >> many folks would find palatable: >> >> What if simple small patches (such as hypothetical drive by doc patches ) >> had a mailing list where folks could email the simple / small patches as >> email attachments plus a body text that summarizes the patch, what it does, >> and why it's simple! >> > I completely agree that for small (e.g. documentation) patches our > current system is quite heavy. For this reason I suggested at ICFP that > we simply begin accepting small patches via GitHub pull requests. > Frankly, this is less work for me than merging patches from a mailing > list and I believe many users feel that GitHub is more accessible than a > mailing list. > > The problem of course is what subset of patches do we want to allow to > be taken via GitHub. My suggested answer to that is any patch which, if > I were to write it myself, I would feel comfortable pushing directly to > the tree. > > Then there is the question of what do we do with pull requests opened > which do not satisfy this criterion. In this case I would likely open a > Phabricator Differential with the pull request and close the pull > request with a link to the Diff. In the ideal case this will inspire the > contributor to join the review process on Phabricator; in the worst case > review turns up issues in the patch and the user gives up. Either way, at > least the contributor feels his patch has been seen and given the > attention it deserves. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mgsloan at gmail.com Mon Sep 26 19:09:43 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 12:09:43 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: Argh, sent too soon. The first paragraph, revised: This sounds like an ideal solution, Ben! As has been discussed many times before, GitHub has many users familiar with its interface. By allowing GitHub PRs, the initial contribution barrier will be lowered. If there is an easy and straightforward process for shifting big patches to Phabricator, then people who are regularly contributing via GitHub PRs can be incrementally on-boarded to the Phabricator / Arcanist workflow. On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: > This sounds like an ideal solution, Ben! As has been discussed many > times before, GitHub has many users familiar with its interface. By > allowing GitHub PRs, the initial contribution > > I think it would be acceptable for larger GitHub PRs to have some > automated boilerplate response. Ideally this would look like: > > """ > Thanks for making this patch! I've turned this into a Phab > Differential xxx and closed this PR. Please create a differential > account associated with your email address ..." > """ > > The email address can be automatically pulled from commit metadata. > If one is absent, then this automated process isn't possible. If it > is present and > > So, I'm imagining a utility that interfaces between both GitHub and > Phab,allowing the following commands: > > * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the > patch to differential. It may attempt to migrate body and title of > the initial post, but lets not bother with migrating any review data. > > * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the > patch. This is used for merging small patches. It would not do an > automated push. Maybe have "--push" also perform the push? So like > if you are on master, then "ghc-hub merge > https://github.com/ghc/ghc/pull/1 --push" would merge the patches and > push to master. > > How does this sound? I like the idea a lot, and would enjoy helping > with implementation, time permitting. I could possibly start hacking > on it if others give the go ahead of "Yes, lets do that". > > -Michael > > On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >> Carter Schonwald writes: >> >>> In writing the following huge wall of text, I had and idea that I think >>> many folks would find palatable: >>> >>> What if simple small patches (such as hypothetical drive by doc patches ) >>> had a mailing list where folks could email the simple / small patches as >>> email attachments plus a body text that summarizes the patch, what it does, >>> and why it's simple! >>> >> I completely agree that for small (e.g. documentation) patches our >> current system is quite heavy. For this reason I suggested at ICFP that >> we simply begin accepting small patches via GitHub pull requests. >> Frankly, this is less work for me than merging patches from a mailing >> list and I believe many users feel that GitHub is more accessible than a >> mailing list. >> >> The problem of course is what subset of patches do we want to allow to >> be taken via GitHub. My suggested answer to that is any patch which, if >> I were to write it myself, I would feel comfortable pushing directly to >> the tree. >> >> Then there is the question of what do we do with pull requests opened >> which do not satisfy this criterion. In this case I would likely open a >> Phabricator Differential with the pull request and close the pull >> request with a link to the Diff. In the ideal case this will inspire the >> contributor to join the review process on Phabricator; in the worst case >> review turns up issues in the patch and the user gives up. Either way, at >> least the contributor feels his patch has been seen and given the >> attention it deserves. >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From ben at smart-cactus.org Mon Sep 26 19:13:09 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 15:13:09 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Simon Marlow writes: > I would rather we *didn't* accept contributions via github, even for small > patches, and instead put more effort into streamlining the Phabricator > workflow. > > > - Adding another input method complicates the workflow, users have to > decide which one to use > I think we would want to try to sell the GitHub route as "if you would like to contribute then we would strongly prefer you use Phabricator, but if you must and it's a small patch, we will accept it via GitHub." > - Github is not integrated with our other infrastructure, while > Phabricator is > True, but I suspect for the small documentation patches that we are currently consider this shouldn't matter so much. > - Mutliple sources of contributions makes life harder for maintainers > It does certainly put yet another task on our plates, but I would argue that it's actually easier than accepting patches via Trac, which we already do. > Let's make the Phabricator workflow easier. > > - Why not put arc in the repo, or provide a script that automatically > downloads it and sets it up? > I'm not sure how much of a difference placing arc in the repo will make; the user will still at very least need to install PHP manually. > - I also like the idea of auto-push if validate succeeds. Or a button > that you can press on the diff that would do the same thing, so you can get > code review first. > To be clear, I'm a bit weary of opening up the auto-push feature to new contributors. While regular contributors know what changes can be safely pushed and which require review, we have no guarantee that a new contributor has developed these sensibilities. > - +1 to making the manual easier to build. The same goes for Haddocks; > it's really hard to make a simple patch to the docs and test it right now. > The users guide should be quite possible to do. I don't believe there is any reliable way to allow a contributor to build the haddocks without having built GHC (since you need GHC master to parse `base`, et al.); that being said, we could have Harbormaster upload built documentation somewhere and then leave a link to it on the Diff. > One other thing that came up but wasn't mentioned in the notes: let's be > more prompt about reverting patches that break validate, even if they only > break a test. Now that we have better CI support, we can easily identify > breaking patches and revert them. > Agreed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From michal.terepeta at gmail.com Mon Sep 26 19:28:41 2016 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Mon, 26 Sep 2016 19:28:41 +0000 Subject: How, precisely, can we improve? In-Reply-To: <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: Hi, I just wanted to add a few things from a perspective of a GHC newbie. Not everything is a concrete proposal on how to improve things, but I hope it's still useful. First of all, a big +1 on what Moritz said - having everything in one system like Phab would be really nice. But I also want to second what Richard Fung said in another thread - the biggest barrier for involvement for me is understanding the code (i.e., it’s a complex and large project). Yes, Phab/Trac are an additional hassle, but for me not really that significant compared to the task of understanding what’s happening in the compiler (although small, localized contributions might be an exception here!). So let's start with the things that I personally find helpful :-) - Some of the documentation on Trac is great (e.g., "I know kung fu: learning STG by example" [1] is amazing!) - “Notes” in the code (especially the ones that give concrete examples of how we want to transform the code and why!) are super useful. - Modify & compile cycle is super quick when using `make 1` or `make 2` in `compiler/`. - Ability to use `Outputable` instances with `Debug.Trace.trace` works surprisingly well. (Although mapping the output from `Outputable` back to AST can be non-trivial!) Things that I find problematic: - Some of the documentation on Trac is outdated or appears to be a "work in progress" but hasn't been updated in years. So getting a clear idea of what’s the current status, is not always easy. Also, it's not always easy to find... Maybe documentation on the wiki could follow the directory/module structure more closely? (also making it more obvious when it gets out of date) - There's a lot of knowledge that seems to be assumed from the reader. I'm guessing that most of the key concepts are obvious for regular contributors. But this can be quite challenging for newcomers and unfortunately explanations can be spread around across code, papers, etc. (e.g., it took me a while to understand what's the deal with "join-points" and "let-no-escape"). Not sure how to solve this, except for having better documentation... - Validate often fails. Workaround: run `./validate` without a patch and then with the patch. If there are no differences, it's probably unrelated. It'd be much nicer if this wasn't necessary. - Coding style. I personally do find it quite distracting to jump between modules that are using a different style (often wildly different!). It definitely does slow me down. And bad formatting can be actually pretty harmful, e.g., not that long ago, I wasted half an hour just because of a weird formatting of a do-block! [3] Finally, note that coding style is pretty much a standard today, so many people expect it in well maintained codebases and might see the current state as "messy". (And perceptions do matter sometimes!) The solution here would be to adopt an official coding style (e.g., [2]). Anyway, I hope you find this useful. :-) Cheers, Michal [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCode [2] https://github.com/tibbe/haskell-style-guide [3] I was looking at a do-block like this: do { A ; … … … … ; B } where it seems that both A and B should always execute. Except that, after closer examination, there were two blocks present! do { A ; … … foobar $ \x -> do … ; B } They were just indented to make it appear as if there was just one! :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From minesasecret at gmail.com Mon Sep 26 19:32:11 2016 From: minesasecret at gmail.com (Richard Fung) Date: Mon, 26 Sep 2016 12:32:11 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Message-ID: > > Indeed we do! If you ever have questions just ask me via IRC or email. > I'd be very happy to help. First of all thank you for the help you've given me so far. Maybe I'm different from others, but my workflow as a newcomer was just reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers. My extremely unsophisticated idea is to just update this wiki page so that it's obvious there are people who are willing to mentor newcomers. It seems as though we already have mentors or people willing to be mentors, but we also have people who did not know this was available. More specifically, I think it would be useful if under the "Finding a Ticket" section, as an alternative to just picking a ticket, we suggest people to ask either through email or on IRC for a starter ticket. Then, hopefully the people who would be willing to mentor this person can suggest tickets they are equipped to deal with themselves. By having newcomers ask for a ticket, we can guarantee that if this person gets a response there would be a mentor available. Also, if someone is too busy to be a mentor, then that person could just choose not to volunteer so that nobody should get overburdened, or at least any more overburdened than they already are. It might seem silly and I am probably just too shy, but as someone new I am always very hesitant to email the entire mailing list for help. On the other hand, I also feel bad for emailing a specific person because I figure they are likely very busy. If I were assigned someone to ask for help, especially someone who volunteered himself or herself, I suspect I would not feel so embarrassed to ask for help. I probably should have asked for help more on IRC but to be honest I have only used IRC once or twice in my life, incidentally also for help on Haskell, so it's not something I really remember. On Mon, Sep 26, 2016 at 12:13 PM, Ben Gamari wrote: > Simon Marlow writes: > > > I would rather we *didn't* accept contributions via github, even for > small > > patches, and instead put more effort into streamlining the Phabricator > > workflow. > > > > > > - Adding another input method complicates the workflow, users have to > > decide which one to use > > > I think we would want to try to sell the GitHub route as "if you would > like to contribute then we would strongly prefer you use Phabricator, > but if you must and it's a small patch, we will accept it via GitHub." > > > - Github is not integrated with our other infrastructure, while > > Phabricator is > > > True, but I suspect for the small documentation patches that we are > currently consider this shouldn't matter so much. > > > - Mutliple sources of contributions makes life harder for maintainers > > > It does certainly put yet another task on our plates, but I would argue > that it's actually easier than accepting patches via Trac, which we > already do. > > > Let's make the Phabricator workflow easier. > > > > - Why not put arc in the repo, or provide a script that automatically > > downloads it and sets it up? > > > I'm not sure how much of a difference placing arc in the repo will make; > the user will still at very least need to install PHP manually. > > > - I also like the idea of auto-push if validate succeeds. Or a button > > that you can press on the diff that would do the same thing, so you > can get > > code review first. > > > To be clear, I'm a bit weary of opening up the auto-push feature to new > contributors. While regular contributors know what changes can be safely > pushed and which require review, we have no guarantee that a new > contributor has developed these sensibilities. > > > - +1 to making the manual easier to build. The same goes for > Haddocks; > > it's really hard to make a simple patch to the docs and test it right > now. > > > The users guide should be quite possible to do. > > I don't believe there is any reliable way to allow a contributor to > build the haddocks without having built GHC (since you need GHC master to > parse `base`, et al.); that being said, we could have Harbormaster > upload built documentation somewhere and then leave a link to it on the > Diff. > > > One other thing that came up but wasn't mentioned in the notes: let's be > > more prompt about reverting patches that break validate, even if they > only > > break a test. Now that we have better CI support, we can easily identify > > breaking patches and revert them. > > > Agreed. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Sep 26 19:40:07 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 26 Sep 2016 20:40:07 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Message-ID: On 26 September 2016 at 20:13, Ben Gamari wrote: > Simon Marlow writes: > > > I would rather we *didn't* accept contributions via github, even for > small > > patches, and instead put more effort into streamlining the Phabricator > > workflow. > > > > > > - Adding another input method complicates the workflow, users have to > > decide which one to use > > > I think we would want to try to sell the GitHub route as "if you would > like to contribute then we would strongly prefer you use Phabricator, > but if you must and it's a small patch, we will accept it via GitHub." > But this is opening the floodgates a crack... how do we know what a "small" patch is? What happens when someone submits a patch that's too large? The patches will get larger, we'll have to do code reviews on two different tools, and it will be really hard to go back. I just have a bad feeling about this. > - Github is not integrated with our other infrastructure, while > > Phabricator is > > > True, but I suspect for the small documentation patches that we are > currently consider this shouldn't matter so much. > > > - Mutliple sources of contributions makes life harder for maintainers > > > It does certainly put yet another task on our plates, but I would argue > that it's actually easier than accepting patches via Trac, which we > already do. > We should stop accepting patches via Trac too :) Cheers Simon > > - I also like the idea of auto-push if validate succeeds. Or a button > > that you can press on the diff that would do the same thing, so you > can get > > code review first. > > > To be clear, I'm a bit weary of opening up the auto-push feature to new > contributors. While regular contributors know what changes can be safely > pushed and which require review, we have no guarantee that a new > contributor has developed these sensibilities. > > > - +1 to making the manual easier to build. The same goes for > Haddocks; > > it's really hard to make a simple patch to the docs and test it right > now. > > > The users guide should be quite possible to do. > > I don't believe there is any reliable way to allow a contributor to > build the haddocks without having built GHC (since you need GHC master to > parse `base`, et al.); that being said, we could have Harbormaster > upload built documentation somewhere and then leave a link to it on the > Diff. > > > One other thing that came up but wasn't mentioned in the notes: let's be > > more prompt about reverting patches that break validate, even if they > only > > break a test. Now that we have better CI support, we can easily identify > > breaking patches and revert them. > > > Agreed. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Mon Sep 26 20:26:49 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 13:26:49 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Message-ID: On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow wrote: > On 26 September 2016 at 20:13, Ben Gamari wrote: >> >> Simon Marlow writes: >> >> > I would rather we *didn't* accept contributions via github, even for >> > small >> > patches, and instead put more effort into streamlining the Phabricator >> > workflow. >> > >> > >> > - Adding another input method complicates the workflow, users have to >> > decide which one to use >> > >> I think we would want to try to sell the GitHub route as "if you would >> like to contribute then we would strongly prefer you use Phabricator, >> but if you must and it's a small patch, we will accept it via GitHub." > > > But this is opening the floodgates a crack... how do we know what a "small" > patch is? What happens when someone submits a patch that's too large? The > patches will get larger, we'll have to do code reviews on two different > tools, and it will be really hard to go back. I just have a bad feeling > about this. I agree that this would certainly happen - people would get used to the new workflow and want to use it for large patches. I've said similar things in a post I made to Carter's thread about a ghc-simple-patch-propose list. Please consider this approach: If a patch requires substantial revision, move it to Phabricator. How do we know when it requires substantial revision? There are two conditions for this: 1) When it is clear to the reviewer that it will take multiple iterations 2) After a single iteration of review has occurred on GitHub, and there is still more to do. This way, any substantial review process will be captured as a differential. We need a way to make this as easy and efficient as possible for maintainers and contributors alike. In particular, maintainer / reviewer time is very valuable. As such, I propose the following: 1) A tool called "ghc-hub", which supports "ghc-hub migrate URL", to migrate a PR to a Differential, without migrating any review metadata (to keep the implementation simple). It would also support "ghc-hub merge URL", . Using PR URLs on the commandline like this is inspired by github's hub tool - https://github.com/github/hub . 2) Eventually, have a GitHub bot which does the following: * Notices if a patch is particularly large, and recommends using the "ghc-hub" tool to perform the migration. * Notices if a patch has already gone through a review and hasn't been merged for a while, and automatically migrates it to a differential. Note that having these tools ready is not necessary to begin this new workflow, but I think they will be helpful for making this new workflow a sustainable approach. If you guys are on board with this approach, I would enjoy writing the initial version of "ghc-hub". Though I cannot at this time guarantee that I would be willing to entirely champion / maintain it - I'll need some help. >> > - Github is not integrated with our other infrastructure, while >> > Phabricator is >> > >> True, but I suspect for the small documentation patches that we are >> currently consider this shouldn't matter so much. >> >> > - Mutliple sources of contributions makes life harder for maintainers >> > >> It does certainly put yet another task on our plates, but I would argue >> that it's actually easier than accepting patches via Trac, which we >> already do. > > > We should stop accepting patches via Trac too :) > > Cheers > Simon > > > >> >> > - I also like the idea of auto-push if validate succeeds. Or a >> > button >> > that you can press on the diff that would do the same thing, so you >> > can get >> > code review first. >> > >> To be clear, I'm a bit weary of opening up the auto-push feature to new >> contributors. While regular contributors know what changes can be safely >> pushed and which require review, we have no guarantee that a new >> contributor has developed these sensibilities. >> >> > - +1 to making the manual easier to build. The same goes for >> > Haddocks; >> > it's really hard to make a simple patch to the docs and test it right >> > now. >> > >> The users guide should be quite possible to do. >> >> I don't believe there is any reliable way to allow a contributor to >> build the haddocks without having built GHC (since you need GHC master to >> parse `base`, et al.); that being said, we could have Harbormaster >> upload built documentation somewhere and then leave a link to it on the >> Diff. >> >> > One other thing that came up but wasn't mentioned in the notes: let's be >> > more prompt about reverting patches that break validate, even if they >> > only >> > break a test. Now that we have better CI support, we can easily >> > identify >> > breaking patches and revert them. >> > >> Agreed. >> >> Cheers, >> >> - Ben >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at smart-cactus.org Mon Sep 26 21:42:02 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 17:42:02 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Message-ID: <87zimugwyd.fsf@ben-laptop.smart-cactus.org> Richard Fung writes: >> Indeed we do! If you ever have questions just ask me via IRC or email. >> I'd be very happy to help. > > First of all thank you for the help you've given me so far. > Of course! I'm happy that I could help. Moreover, thanks for writing this. This sort of feedback is worth its byte count in gold. > Maybe I'm different from others, but my workflow as a newcomer was just > reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers. > > My extremely unsophisticated idea is to just update this wiki page so that > it's obvious there are people who are willing to mentor newcomers. It seems > as though we already have mentors or people willing to be mentors, but we > also have people who did not know this was available. > That is a great point; it's easy for me to forget how I felt when I was a beginner. I've added a brief paragraph to the Newcomers page, If you have any questions along the way don't hesitate to reach out to the community. There are people on the mailing lists and IRC who will gladly help you (although you may need to be patient). Don't forget that all GHC developers are still learning; your question is never too silly to ask. Can you see any way this could be improved? > More specifically, I think it would be useful if under the "Finding a > Ticket" section, as an alternative to just picking a ticket, we suggest > people to ask either through email or on IRC for a starter ticket. Then, > hopefully the people who would be willing to mentor this person can suggest > tickets they are equipped to deal with themselves. > That is a fair point; I've added some language to the Newcomers page encouraging these sorts of inqueries, == Finding a ticket == Now that you can build GHC, let's get hacking. But first, you'll need to identify a goal. GHC's Trac tickets are a great place to find starting points. You are encouraged to ask for a starting point on IRC or the ghc-devs mailing list. There someone familiar with the process can help you find a ticket that matches your expertise and help you when troubles arise. If you want to get a taste for possible starting tasks, below is a list of tickets that appear to be "low-hanging fruit" -- things that might be reasonable for a newcomer to GHC hacking. Of course, we can't ever be sure of how hard a task is before doing it, so apologies if one of these is too hard. Is this better? > By having newcomers ask for a ticket, we can guarantee that if this person > gets a response there would be a mentor available. Also, if someone is too > busy to be a mentor, then that person could just choose not to volunteer so > that nobody should get overburdened, or at least any more overburdened than > they already are. > > It might seem silly and I am probably just too shy, but as someone new I am > always very hesitant to email the entire mailing list for help. On the > other hand, I also feel bad for emailing a specific person because I figure > they are likely very busy. If I were assigned someone to ask for help, > especially someone who volunteered himself or herself, I suspect I would > not feel so embarrassed to ask for help. I probably should have asked for > help more on IRC but to be honest I have only used IRC once or twice in my > life, incidentally also for help on Haskell, so it's not something I really > remember. > IRC is a great tool; personally I felt much more empowered to ask questions after I started using it. Regardless, I'm certain that you are not the only one who is reluctant to ask a large group. I've now tried to really emphasize the importance of asking questions on the Newcomers page but I agree that having a mentor would lower the barrier to asking significantly. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 26 21:51:15 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2016 17:51:15 -0400 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> Message-ID: <87wphygwj0.fsf@ben-laptop.smart-cactus.org> Simon Marlow writes: > But this is opening the floodgates a crack... how do we know what a "small" > patch is? What happens when someone submits a patch that's too large? > I tried to address these questions in the "Create a ghc-simple-patch-propose list?" thread where I said, Ben Gamari writes: > I completely agree that for small (e.g. documentation) patches our > current system is quite heavy. For this reason I suggested at ICFP that > we simply begin accepting small patches via GitHub pull requests. > Frankly, this is less work for me than merging patches from a mailing > list and I believe many users feel that GitHub is more accessible than a > mailing list. > > The problem of course is what subset of patches do we want to allow to > be taken via GitHub. My suggested answer to that is any patch which, if > I were to write it myself, I would feel comfortable pushing directly to > the tree. > > Then there is the question of what do we do with pull requests opened > which do not satisfy this criterion. In this case I would likely open a > Phabricator Differential with the pull request and close the pull > request with a link to the Diff. In the ideal case this will inspire the > contributor to join the review process on Phabricator; in the worst case > review turns up issues in the patch and the user gives up. Either way, at > least the contributor feels his patch has been seen and given the > attention it deserves. Does this help? Simon Marlow writes: > The patches will get larger, we'll have to do code reviews on two > different tools, and it will be really hard to go back. I just have a > bad feeling about this. > I share your worry that the GitHub patch sizes will "creep". That being said, I think that as long as we can easily move to Phabricator for reviewing larger patches it will be manageable. Moreover, I suspect that once someone has submitted a patch via GitHub, the effort that they have sunk into it will mean that they will be more likely to follow the patch to Phabricator to participate in review (and hopefully revision) if we move it. >> It does certainly put yet another task on our plates, but I would argue >> that it's actually easier than accepting patches via Trac, which we >> already do. > > We should stop accepting patches via Trac too :) > Heh, it would certainly make my life easier. That being said, there (thankfully) aren't too many that come in via this channel at this point. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From minesasecret at gmail.com Mon Sep 26 22:56:05 2016 From: minesasecret at gmail.com (Richard Fung) Date: Mon, 26 Sep 2016 15:56:05 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87wphygwj0.fsf@ben-laptop.smart-cactus.org> References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> <87wphygwj0.fsf@ben-laptop.smart-cactus.org> Message-ID: > > That is a great point; it's easy for me to forget how I felt when I was > a beginner. I've added a brief paragraph to the Newcomers page, > If you have any questions along the way don't hesitate to reach out > to the community. There are people on the mailing lists and IRC who > will gladly help you (although you may need to be patient). Don't > forget that all GHC developers are still learning; your question is > never too silly to ask. > Can you see any way this could be improved? > That is a fair point; I've added some language to the Newcomers page > encouraging these sorts of inqueries, > == Finding a ticket == > Now that you can build GHC, let's get hacking. But first, you'll > need to identify a goal. GHC's Trac tickets are a great place to > find starting points. You are encouraged to ask for a starting point > on IRC or the ghc-devs mailing list. There someone familiar with the > process can help you find a ticket that matches your expertise and > help you when troubles arise. > If you want to get a taste for possible starting tasks, below is a > list of tickets that appear to be "low-hanging fruit" -- things that > might be reasonable for a newcomer to GHC hacking. Of course, we > can't ever be sure of how hard a task is before doing it, so > apologies if one of these is too hard. > Is this better? I think both of these are great. Thanks! On Mon, Sep 26, 2016 at 2:51 PM, Ben Gamari wrote: > Simon Marlow writes: > > > But this is opening the floodgates a crack... how do we know what a > "small" > > patch is? What happens when someone submits a patch that's too large? > > > I tried to address these questions in the "Create a > ghc-simple-patch-propose list?" thread where I said, > > Ben Gamari writes: > > > I completely agree that for small (e.g. documentation) patches our > > current system is quite heavy. For this reason I suggested at ICFP that > > we simply begin accepting small patches via GitHub pull requests. > > Frankly, this is less work for me than merging patches from a mailing > > list and I believe many users feel that GitHub is more accessible than a > > mailing list. > > > > The problem of course is what subset of patches do we want to allow to > > be taken via GitHub. My suggested answer to that is any patch which, if > > I were to write it myself, I would feel comfortable pushing directly to > > the tree. > > > > Then there is the question of what do we do with pull requests opened > > which do not satisfy this criterion. In this case I would likely open a > > Phabricator Differential with the pull request and close the pull > > request with a link to the Diff. In the ideal case this will inspire the > > contributor to join the review process on Phabricator; in the worst case > > review turns up issues in the patch and the user gives up. Either way, at > > least the contributor feels his patch has been seen and given the > > attention it deserves. > > Does this help? > > > Simon Marlow writes: > > > The patches will get larger, we'll have to do code reviews on two > > different tools, and it will be really hard to go back. I just have a > > bad feeling about this. > > > I share your worry that the GitHub patch sizes will "creep". That being > said, I think that as long as we can easily move to Phabricator for > reviewing larger patches it will be manageable. > > Moreover, I suspect that once someone has submitted a patch via GitHub, > the effort that they have sunk into it will mean that they will be more > likely to follow the patch to Phabricator to participate in review (and > hopefully revision) if we move it. > > >> It does certainly put yet another task on our plates, but I would argue > >> that it's actually easier than accepting patches via Trac, which we > >> already do. > > > > We should stop accepting patches via Trac too :) > > > Heh, it would certainly make my life easier. That being said, there > (thankfully) aren't too many that come in via this channel at this > point. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Sep 27 03:09:07 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 27 Sep 2016 13:09:07 +1000 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. Manuel > Michael Sloan : > > Argh, sent too soon. The first paragraph, revised: > > This sounds like an ideal solution, Ben! As has been discussed many > times before, GitHub has many users familiar with its interface. By > allowing GitHub PRs, the initial contribution barrier will be lowered. If > there is an easy and straightforward process for shifting big patches > to Phabricator, then people who are regularly contributing via GitHub > PRs can be incrementally on-boarded to the Phabricator / Arcanist > workflow. > > On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >> This sounds like an ideal solution, Ben! As has been discussed many >> times before, GitHub has many users familiar with its interface. By >> allowing GitHub PRs, the initial contribution >> >> I think it would be acceptable for larger GitHub PRs to have some >> automated boilerplate response. Ideally this would look like: >> >> """ >> Thanks for making this patch! I've turned this into a Phab >> Differential xxx and closed this PR. Please create a differential >> account associated with your email address ..." >> """ >> >> The email address can be automatically pulled from commit metadata. >> If one is absent, then this automated process isn't possible. If it >> is present and >> >> So, I'm imagining a utility that interfaces between both GitHub and >> Phab,allowing the following commands: >> >> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >> patch to differential. It may attempt to migrate body and title of >> the initial post, but lets not bother with migrating any review data. >> >> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >> patch. This is used for merging small patches. It would not do an >> automated push. Maybe have "--push" also perform the push? So like >> if you are on master, then "ghc-hub merge >> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >> push to master. >> >> How does this sound? I like the idea a lot, and would enjoy helping >> with implementation, time permitting. I could possibly start hacking >> on it if others give the go ahead of "Yes, lets do that". >> >> -Michael >> >> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>> Carter Schonwald writes: >>> >>>> In writing the following huge wall of text, I had and idea that I think >>>> many folks would find palatable: >>>> >>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>> had a mailing list where folks could email the simple / small patches as >>>> email attachments plus a body text that summarizes the patch, what it does, >>>> and why it's simple! >>>> >>> I completely agree that for small (e.g. documentation) patches our >>> current system is quite heavy. For this reason I suggested at ICFP that >>> we simply begin accepting small patches via GitHub pull requests. >>> Frankly, this is less work for me than merging patches from a mailing >>> list and I believe many users feel that GitHub is more accessible than a >>> mailing list. >>> >>> The problem of course is what subset of patches do we want to allow to >>> be taken via GitHub. My suggested answer to that is any patch which, if >>> I were to write it myself, I would feel comfortable pushing directly to >>> the tree. >>> >>> Then there is the question of what do we do with pull requests opened >>> which do not satisfy this criterion. In this case I would likely open a >>> Phabricator Differential with the pull request and close the pull >>> request with a link to the Diff. In the ideal case this will inspire the >>> contributor to join the review process on Phabricator; in the worst case >>> review turns up issues in the patch and the user gives up. Either way, at >>> least the contributor feels his patch has been seen and given the >>> attention it deserves. >>> >>> Cheers, >>> >>> - Ben >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From svenpanne at gmail.com Tue Sep 27 07:46:18 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 27 Sep 2016 09:46:18 +0200 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: * We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/ It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org, i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Sep 27 11:05:09 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 27 Sep 2016 12:05:09 +0100 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87wphygwj0.fsf@ben-laptop.smart-cactus.org> References: <87eg46iiey.fsf@ben-laptop.smart-cactus.org> <87wphygwj0.fsf@ben-laptop.smart-cactus.org> Message-ID: On 26 September 2016 at 22:51, Ben Gamari wrote: > Simon Marlow writes: > > > But this is opening the floodgates a crack... how do we know what a > "small" > > patch is? What happens when someone submits a patch that's too large? > > > I tried to address these questions in the "Create a > ghc-simple-patch-propose list?" thread where I said, > > Ben Gamari writes: > > > I completely agree that for small (e.g. documentation) patches our > > current system is quite heavy. For this reason I suggested at ICFP that > > we simply begin accepting small patches via GitHub pull requests. > > Frankly, this is less work for me than merging patches from a mailing > > list and I believe many users feel that GitHub is more accessible than a > > mailing list. > > > > The problem of course is what subset of patches do we want to allow to > > be taken via GitHub. My suggested answer to that is any patch which, if > > I were to write it myself, I would feel comfortable pushing directly to > > the tree. > > > > Then there is the question of what do we do with pull requests opened > > which do not satisfy this criterion. In this case I would likely open a > > Phabricator Differential with the pull request and close the pull > > request with a link to the Diff. In the ideal case this will inspire the > > contributor to join the review process on Phabricator; in the worst case > > review turns up issues in the patch and the user gives up. Either way, at > > least the contributor feels his patch has been seen and given the > > attention it deserves. > > Does this help? > Well ok. I'm still concerned that adding a new contribution method is not making things simpler, and that we have even more process and things to document, which might itself be discouraging to new users. But if you say it's easy for you to accept patches this way, and that the rest of us can mostly ignore github then I guess that limits the downsides. Of course if people say this is what they actually want, then who am I to disagree :) Cheers Simon > > > Simon Marlow writes: > > > The patches will get larger, we'll have to do code reviews on two > > different tools, and it will be really hard to go back. I just have a > > bad feeling about this. > > > I share your worry that the GitHub patch sizes will "creep". That being > said, I think that as long as we can easily move to Phabricator for > reviewing larger patches it will be manageable. > > Moreover, I suspect that once someone has submitted a patch via GitHub, > the effort that they have sunk into it will mean that they will be more > likely to follow the patch to Phabricator to participate in review (and > hopefully revision) if we move it. > > >> It does certainly put yet another task on our plates, but I would argue > >> that it's actually easier than accepting patches via Trac, which we > >> already do. > > > > We should stop accepting patches via Trac too :) > > > Heh, it would certainly make my life easier. That being said, there > (thankfully) aren't too many that come in via this channel at this > point. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Tue Sep 27 11:30:49 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Tue, 27 Sep 2016 19:30:49 +0800 Subject: Improving the contributing to ghc experience Message-ID: Friends, as you all have seen over the last few days, making the contributing to ghc experience easier for those who have not yet contributed to ghc, is a topic of interest to many of us. I’d like to thank Edward Z. Yang for seizing the opportunity to convince us to test drive the ghc-proposal process for this as well. Hence I went ahead and created the proposal with the help of others! So far it’s basically a small collection of what was mentioned on the mailing list. The hope is that facilitating the discussion though the ghc-proposal process would produce a coherent set of proposed changes and help making this a reality. I henceforth invite you to add your comments, critique and suggestions to the proposal that can be found at https://github.com/ghc-proposals/ghc-proposals/pull/9 Cheers, Moritz From ben at well-typed.com Tue Sep 27 13:43:12 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Sep 2016 09:43:12 -0400 Subject: Improving the contributing to ghc experience In-Reply-To: References: Message-ID: <87lgydh30v.fsf@ben-laptop.smart-cactus.org> Moritz Angermann writes: > Friends, > > as you all have seen over the last few days, making the > contributing to ghc experience easier for those who > have not yet contributed to ghc, is a topic of interest > to many of us. > Thanks for Moritz, You describe quite a lot there and I do wonder whether it might be helpful to break apart some of these ideas. Nevertheless, I've added some review comments. Thanks again for taking the time to collect these ideas. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Tue Sep 27 13:48:21 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Sep 2016 09:48:21 -0400 Subject: Improving the contributing to ghc experience In-Reply-To: References: Message-ID: <87inthh2sa.fsf@ben-laptop.smart-cactus.org> Moritz Angermann writes: > Friends, > Hi Moritz, I have fixed a few minor stylistic issues that I noticed in my read-through on this branch [1]. I would have liked to open a pull request against your branch, but sadly GitHub is strangely not cooperating (is the ghc-megacorp/ghc-proposals not a fork of ghc-proposals/ghc-proposals? GitHub seems to think not). Anyways, you might consider merging these when you go to revise your proposal. That being said, I wouldn't merge until there has been more of an opportunity for discussion as I suspect pushing a new revision may invalidate some of the comments that have been left in review. Cheers, - Ben [1] https://github.com/bgamari/ghc-proposals/tree/improved-ghc-development -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From moritz at lichtzwerge.de Tue Sep 27 13:51:33 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Tue, 27 Sep 2016 21:51:33 +0800 Subject: Improving the contributing to ghc experience In-Reply-To: <87lgydh30v.fsf@ben-laptop.smart-cactus.org> References: <87lgydh30v.fsf@ben-laptop.smart-cactus.org> Message-ID: > You describe quite a lot there and I do wonder whether it might be > helpful to break apart some of these ideas. That might very well be. Maybe this proposal outgrows itself and needs to be split into multiple proposals down the line? I’d suggest to facilitate the initial feedback in the current one to get a better grip on what we are up against :) From ben at well-typed.com Tue Sep 27 14:12:59 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Sep 2016 10:12:59 -0400 Subject: Improving the contributing to ghc experience In-Reply-To: References: <87lgydh30v.fsf@ben-laptop.smart-cactus.org> Message-ID: <87fuolh1n8.fsf@ben-laptop.smart-cactus.org> Moritz Angermann writes: >> You describe quite a lot there and I do wonder whether it might be >> helpful to break apart some of these ideas. > > That might very well be. Maybe this proposal outgrows itself and needs > to be split into multiple proposals down the line? I’d suggest to > facilitate the initial feedback in the current one to get a better grip > on what we are up against :) Of course, I think the current approach is certainly better than nothing. It's quite valuable to even have a consolidated list of potential improvements. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Tue Sep 27 14:22:24 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Sep 2016 14:22:24 +0000 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/ I didn’t even know about the third of these, but the first two have clearly differentiated goals: · https://wiki.haskell.org/Haskell is about user-facing, and often user-generated, documentation. Guidance about improving performance, programming idioms, tutorials etc. · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, oriented to people who want to understand how GHC works, and how to modify it. I think this separation is actually quite helpful. I agree with what you and others say about the difficulty of keeping wikis organised. But that’s not primarily a technology issue: there is a genuinely difficult challenge here. How do you build and maintain up-to-date, navigable, well-organised information about a large, complex, and rapidly changing artefact like GHC? A wiki is one approach that has the merit that anyone can improve it; control is not centralised. But I’d love there to be other, better solutions. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sven Panne Sent: 27 September 2016 08:46 To: ghc-devs Subject: Re: How, precisely, can we improve? Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: * We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/ It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org, i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Sep 27 14:22:28 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Sep 2016 14:22:28 +0000 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <1474699605.17351.1.camel@joachim-breitner.de> <87h995j7y2.fsf@ben-laptop.smart-cactus.org> <5906BBF6-F771-4CB1-9768-EC36C0945DBE@justtesting.org> Message-ID: Friends Wow! I didn't expect my scrappy notes to generate so much traffic! Some quick thoughts: * My notes were typed in real-time, during an open 70-person discussion during the Haskell Implementors Workshop. Air-time was limited, and I just wanted to capture suggestions that people made. They do not reflect a thoughtful agreement or a concrete plan. * As it happens, some of the subsequent traffic illustrates rather well the challenges that I wanted to address in my "Respect" post to haskell.org, although I posted the latter before seeing the former. The good thing is that we ALL share the same goals: to make it as easy as possible for both newcomers and hard-core developers to contribute to GHC; to preserve GHC's conceptual integrity; to operate within the limits of what a bunch of volunteers can do. We may differ in our judgements about how best to achieve those goals, but I'm certain that, if we take a little care, we can do so in the language of colleagues not adversaries. Happily, everything has calmed down a bit now, but still I'd like to renew my plea for courtesy; and in particular, to start from an assumption of good faith. Nobody here is seeking to be hostile, dismissive, or excluding. If my behaviour appears to you to be any of those things, please talk me privately, not in public; I have probably just failed to express myself well. * Turning to the main issue of substance -- reducing the barrier to entry for new contributors -- one plea is "Just do it on Github, the same as everyone else". I can see the force of that argument; Chris Allen calls it "legibility": simply being similar to other workflows reduces the barrier to entry. (Chris and I had a useful conversation last night; thanks Chris.) I do not have a well-informed opinion about whether Github can do the job for us -- it's not the same Github as when we last consciously decided not to go that route. Even if we stick with Phab we could probably do a better job of explaining the workflow, so that someone new is in no doubt about how to contribute. But the choice of technology is, in the end, a judgement call about the balance of plusses and minuses. * I really like Jakub Zalewski's suggestion of having a GHC-specific StackOverflow instance. StackOverflow seems to have captured a great way for people to have a technical questions and answers. That might be better than the GHC wiki, or at least a great complement to it. Better still, Jakub has volunteered to spin one up, an offer I think we should grab with both hands. * I'm open to the idea of mentors -- if we could find enough people willing to act as mentors. I'm not confident we have enough supply to meet the demand, but perhaps we should try and see? * It's worth remembering that we are in the midst of revising the process of how to propose a change to GHC, and the language it compiles, in direct response to feedback from the GHC developer community. Onward and upward Simon From alan.zimm at gmail.com Tue Sep 27 14:54:11 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 27 Sep 2016 16:54:11 +0200 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: I think this is relevant to the dicussion: http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation Alan On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > We currently have *3* wikis: > > > > https://wiki.haskell.org/Haskell > > > https://ghc.haskell.org/trac/ghc > > https://phabricator.haskell.org/w/ > > > > I didn’t even know about the third of these, but the first two have > clearly differentiated goals: > > · https://wiki.haskell.org/Haskell > > is about user-facing, and often user-generated, documentation. Guidance > about improving performance, programming idioms, tutorials etc. > > · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, > oriented to people who want to understand how GHC works, and how to modify > it. > > > > I think this separation is actually quite helpful. > > > > I agree with what you and others say about the difficulty of keeping wikis > organised. But that’s not primarily a technology issue: there is a > genuinely difficult challenge here. How do you build and maintain > up-to-date, navigable, well-organised information about a large, complex, > and rapidly changing artefact like GHC? A wiki is one approach that has > the merit that anyone can improve it; control is not centralised. But I’d > love there to be other, better solutions. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Sven > Panne > *Sent:* 27 September 2016 08:46 > *To:* ghc-devs > *Subject:* Re: How, precisely, can we improve? > > > > Just a remark from my side: The documentation/tooling landscape is a bit > more fragmented than it needs to be IMHO. More concretely: > > > > * We currently have *3* wikis: > > > > https://wiki.haskell.org/Haskell > > > https://ghc.haskell.org/trac/ghc > > https://phabricator.haskell.org/w/ > > > > > > It's clear to me that they have different emphases and different > origins, but in the end this results in valuable information being > scattered around. Wikis in general are already quite hard to navigate (due > to their inherent chaotic "structure"), so having 3 of them makes things > even worse. It would be great to have *the* single Haskell Wiki directly on > haskell.org > > in an easily reachable place. > > > > * To be an active Haskell community member, you need quite a few > different logins: Some for the Wikis mentioned above, one for Hackage, > another one for Phabricator, perhaps an SSH key here and there... > Phabricator is a notable exception: It accepts your GitHub/Google+/... > logins. It would be great if the other parts of the Haskell ecosystem > accepted those kinds of logins, too. > > > > * https://haskell-lang.org/ > > has great stuff on it, but its relationship to haskell.org > > is unclear to me. Their "documentation" sub-pages look extremely similar, > but haskell-lang.org > > has various (great!) tutorials and a nice overview of common libraries on > it. From an external POV it seems to me that haskell-lang.org > > should be seamlessly integrated into haskell.org > , > i.e. merged into it. Having an endless sea of links on haskell.org > > is not the same as having content nicely integrated into it, sorted by > topic, etc. > > > > All those points are not show-stoppers for people trying to be more active > in the Haskell community, but nevertheless they make things harder than > they need to be, so I fear we lose people quite early. To draw an analogy: > As probably everybody who actively monitors their web shop/customer site > knows, even seemlingy small things moves customers totally away from your > site. One unclear payment form? The vast majority of your potential > customers aborts the purchase immediately and forever. One confusing > interstitial web page? Say goodbye to lots of people. One hard-to-find > button/link? A forced login/new account? => Commercial disaster, etc. etc. > > > > Furthermore, I'm quite aware of the technical/social difficulties of my > proposals, but that shouldn't let us stop trying to improve... > > > > Cheers, > > S. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Tue Sep 27 15:20:19 2016 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Tue, 27 Sep 2016 18:20:19 +0300 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: I think I'm a bit late for the party. I'm speaking with the newcomer hat on, as basically I have contributed only few trivial patches. So not sure if my experience matter. Originally I was submitting patches using Trac, but then was kindly asked (IIRC by Simon Marlow) to use Phab instead. Surprisingly enough I had no problems with Phab, and setup took about 15 minutes (most of that time I spend on php compilation). Student that I used to co-mentor this year on HSoC also said that he had zero problems with Phab and that it took 5 minutes to set everything up. So from my personal point of view problem of the Phabricator are heavily overrated. Whenever you do non trivial (not simple documentation fix) amount of work and documentation needs to be read highly preside the complexity of the work for submitting patch. Review requests and email that is sent is greatly structured, latest changes on github makes small step toward but anyway not that good. Also for almost all the changes I had to contact #ghc or persons who is familiar with that subsystem and always had great and prompt feedback. What I'm written above doesn't mean that it's nowhere to improve. Documentation on the wiki may be structured better and sometimes it's very hard to get the actual state by reading it. Especially if there was some ongoing discussion without highlighting the outcome. As many already highlighted in this thread having a single account for trac, phab and ideally popular system people people already use will be beneficial. Without that I think other improvements will not work well. Also it would be nice if it was possible to automate some actions like adding a link from trac to Phab. I remember spending much time on trying to recall correct syntax to add link to Phab. About GitHub based contribution. It looks great for me for *all types* of the patches. But.. bot (or for some time person) should migrate *all* the patches to Phab, closing the threads for comments. Bot should write some welcome message than with a link to Phab request and intruction how to allow Phab to use github account and read email if there is no account yet. This way when review had happened author will automatically receive all review comments with links to Phab, I'll hardly get that following a link to github is any harder than following link to Phab (assuming Phab to login using github account). If user addressed comment he should be able to just force-push/update his branch and new revision should be created by bot. PR on github should be closed whenever Phab request will be closed, so it would be trackable using GitHub only. This way github-ish users could use tool that they used to, but also reviewers to use the tool they also used to. All the review comments will be stored in the single place, no revisions will be lost. This way could be automated and there will be no strange questions about what is large patch and what is not. The only people who use are ones that doesn't use email to receive review comments and can use only GitHub interface to read that, but I doubt that such users exists. -- Alexander On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs wrote: > Friends > > > > Here are the notes I took from session 2 of the Haskell Implementors > Meeting. The bolding is my choice of emphasis. > > > > Simon > > > > · Doc bugs. Two kinds > > o Typos. Friction stops me > > o Explanations needed e.g. read/show > > · Lightweight pushes > > · Make user manual into its own repo, to make it easier to take pull > requests. But that makes it harder when making synchronised changes to GHC > and user manual. > > · Auto-push: Ability to push to Phab and have it committed > automatically if it validates. > > · Style guides. Is having a defined style solving a problem we don’t > really have? One piece of guidance: adhere to the style of the surrounding > code. Low priority. > > · Docker images. We should have one. > > · Remove old documentation! > > · Cross compilation is difficult. > > · Have a GHC StackOverflow on haskell.org (Jacob Zalewski > jakzale at gmail.com offers to do this! – thank you). It has a useful new > Documentation feature. Eg this would be good for “how do I look up a > RdrName to get a Name… there seem to be six different functions that do > that”. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Alexander From eric at seidel.io Tue Sep 27 15:32:36 2016 From: eric at seidel.io (Eric Seidel) Date: Tue, 27 Sep 2016 08:32:36 -0700 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> Thanks for the link Alan. I can personally attest to being intimidated by GHC's wiki when I started contributing. I think having a review mechanism in place would have helped, because then you at least know that one or two other people think your content is clear. On a more minor note, I know the trac wiki has a history feature, but for some reason I find it much less useful than a git history. Perhaps this is just an issue of familiarity. On Tue, Sep 27, 2016, at 07:54, Alan & Kim Zimmerman wrote: > I think this is relevant to the dicussion: > http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation > > Alan > > On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > > We currently have *3* wikis: > > > > > > > > https://wiki.haskell.org/Haskell > > > > > > https://ghc.haskell.org/trac/ghc > > > > https://phabricator.haskell.org/w/ > > > > > > > > I didn’t even know about the third of these, but the first two have > > clearly differentiated goals: > > > > · https://wiki.haskell.org/Haskell > > > > is about user-facing, and often user-generated, documentation. Guidance > > about improving performance, programming idioms, tutorials etc. > > > > · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, > > oriented to people who want to understand how GHC works, and how to modify > > it. > > > > > > > > I think this separation is actually quite helpful. > > > > > > > > I agree with what you and others say about the difficulty of keeping wikis > > organised. But that’s not primarily a technology issue: there is a > > genuinely difficult challenge here. How do you build and maintain > > up-to-date, navigable, well-organised information about a large, complex, > > and rapidly changing artefact like GHC? A wiki is one approach that has > > the merit that anyone can improve it; control is not centralised. But I’d > > love there to be other, better solutions. > > > > > > > > Simon > > > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Sven > > Panne > > *Sent:* 27 September 2016 08:46 > > *To:* ghc-devs > > *Subject:* Re: How, precisely, can we improve? > > > > > > > > Just a remark from my side: The documentation/tooling landscape is a bit > > more fragmented than it needs to be IMHO. More concretely: > > > > > > > > * We currently have *3* wikis: > > > > > > > > https://wiki.haskell.org/Haskell > > > > > > https://ghc.haskell.org/trac/ghc > > > > https://phabricator.haskell.org/w/ > > > > > > > > > > > > It's clear to me that they have different emphases and different > > origins, but in the end this results in valuable information being > > scattered around. Wikis in general are already quite hard to navigate (due > > to their inherent chaotic "structure"), so having 3 of them makes things > > even worse. It would be great to have *the* single Haskell Wiki directly on > > haskell.org > > > > in an easily reachable place. > > > > > > > > * To be an active Haskell community member, you need quite a few > > different logins: Some for the Wikis mentioned above, one for Hackage, > > another one for Phabricator, perhaps an SSH key here and there... > > Phabricator is a notable exception: It accepts your GitHub/Google+/... > > logins. It would be great if the other parts of the Haskell ecosystem > > accepted those kinds of logins, too. > > > > > > > > * https://haskell-lang.org/ > > > > has great stuff on it, but its relationship to haskell.org > > > > is unclear to me. Their "documentation" sub-pages look extremely similar, > > but haskell-lang.org > > > > has various (great!) tutorials and a nice overview of common libraries on > > it. From an external POV it seems to me that haskell-lang.org > > > > should be seamlessly integrated into haskell.org > > , > > i.e. merged into it. Having an endless sea of links on haskell.org > > > > is not the same as having content nicely integrated into it, sorted by > > topic, etc. > > > > > > > > All those points are not show-stoppers for people trying to be more active > > in the Haskell community, but nevertheless they make things harder than > > they need to be, so I fear we lose people quite early. To draw an analogy: > > As probably everybody who actively monitors their web shop/customer site > > knows, even seemlingy small things moves customers totally away from your > > site. One unclear payment form? The vast majority of your potential > > customers aborts the purchase immediately and forever. One confusing > > interstitial web page? Say goodbye to lots of people. One hard-to-find > > button/link? A forced login/new account? => Commercial disaster, etc. etc. > > > > > > > > Furthermore, I'm quite aware of the technical/social difficulties of my > > proposals, but that shouldn't let us stop trying to improve... > > > > > > > > Cheers, > > > > S. > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Tue Sep 27 15:46:07 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 11:46:07 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: To sum up, this proposes the following: 1. Allow PRs on GitHub. 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. 3. Small GitHub PRs can be merged directly, by ghc-hub. 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. Is this worth sending through ghc-proposals? Thanks for volunteering item (2), Michael! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: > > Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. > > Manuel > >> Michael Sloan : >> >> Argh, sent too soon. The first paragraph, revised: >> >> This sounds like an ideal solution, Ben! As has been discussed many >> times before, GitHub has many users familiar with its interface. By >> allowing GitHub PRs, the initial contribution barrier will be lowered. If >> there is an easy and straightforward process for shifting big patches >> to Phabricator, then people who are regularly contributing via GitHub >> PRs can be incrementally on-boarded to the Phabricator / Arcanist >> workflow. >> >> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>> This sounds like an ideal solution, Ben! As has been discussed many >>> times before, GitHub has many users familiar with its interface. By >>> allowing GitHub PRs, the initial contribution >>> >>> I think it would be acceptable for larger GitHub PRs to have some >>> automated boilerplate response. Ideally this would look like: >>> >>> """ >>> Thanks for making this patch! I've turned this into a Phab >>> Differential xxx and closed this PR. Please create a differential >>> account associated with your email address ..." >>> """ >>> >>> The email address can be automatically pulled from commit metadata. >>> If one is absent, then this automated process isn't possible. If it >>> is present and >>> >>> So, I'm imagining a utility that interfaces between both GitHub and >>> Phab,allowing the following commands: >>> >>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>> patch to differential. It may attempt to migrate body and title of >>> the initial post, but lets not bother with migrating any review data. >>> >>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>> patch. This is used for merging small patches. It would not do an >>> automated push. Maybe have "--push" also perform the push? So like >>> if you are on master, then "ghc-hub merge >>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>> push to master. >>> >>> How does this sound? I like the idea a lot, and would enjoy helping >>> with implementation, time permitting. I could possibly start hacking >>> on it if others give the go ahead of "Yes, lets do that". >>> >>> -Michael >>> >>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>> Carter Schonwald writes: >>>> >>>>> In writing the following huge wall of text, I had and idea that I think >>>>> many folks would find palatable: >>>>> >>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>> had a mailing list where folks could email the simple / small patches as >>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>> and why it's simple! >>>>> >>>> I completely agree that for small (e.g. documentation) patches our >>>> current system is quite heavy. For this reason I suggested at ICFP that >>>> we simply begin accepting small patches via GitHub pull requests. >>>> Frankly, this is less work for me than merging patches from a mailing >>>> list and I believe many users feel that GitHub is more accessible than a >>>> mailing list. >>>> >>>> The problem of course is what subset of patches do we want to allow to >>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>> I were to write it myself, I would feel comfortable pushing directly to >>>> the tree. >>>> >>>> Then there is the question of what do we do with pull requests opened >>>> which do not satisfy this criterion. In this case I would likely open a >>>> Phabricator Differential with the pull request and close the pull >>>> request with a link to the Diff. In the ideal case this will inspire the >>>> contributor to join the review process on Phabricator; in the worst case >>>> review turns up issues in the patch and the user gives up. Either way, at >>>> least the contributor feels his patch has been seen and given the >>>> attention it deserves. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Tue Sep 27 16:06:26 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 12:06:26 -0400 Subject: How, precisely, can we improve? In-Reply-To: <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> Message-ID: <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> Yes, I agree with Michael’s observations in the blog post. However, one thing that’s easier about a wiki is that the editing process is much more lightweight than making a PR. But GitHub has a wonderful feature (that I have rarely used) that mitigates this problem. Viewing a file in GitHub offers a little pencil icon in the top-right. It allows you to make arbitrary changes in the file and then automates the construction of a PR. The owner of the file can then accept the PR very, very easily. If the editor has commit rights, you can make your edits into a commit right away. No need to fork, pull and push. Is this perhaps an easy improvement we can enact? Note that we’re already moving in this direction with ghc-proposals, which subsumes a large part of what the GHC dev wiki has been used for. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 27, 2016, at 11:32 AM, Eric Seidel wrote: > > Thanks for the link Alan. > > I can personally attest to being intimidated by GHC's wiki when I > started contributing. I think having a review mechanism in place would > have helped, because then you at least know that one or two other people > think your content is clear. > > On a more minor note, I know the trac wiki has a history feature, but > for some reason I find it much less useful than a git history. Perhaps > this is just an issue of familiarity. > > On Tue, Sep 27, 2016, at 07:54, Alan & Kim Zimmerman wrote: >> I think this is relevant to the dicussion: >> http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation >> >> Alan >> >> On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs < >> ghc-devs at haskell.org> wrote: >> >>> We currently have *3* wikis: >>> >>> >>> >>> https://wiki.haskell.org/Haskell >>> >>> >>> https://ghc.haskell.org/trac/ghc >>> >>> https://phabricator.haskell.org/w/ >>> >>> >>> >>> I didn’t even know about the third of these, but the first two have >>> clearly differentiated goals: >>> >>> · https://wiki.haskell.org/Haskell >>> >>> is about user-facing, and often user-generated, documentation. Guidance >>> about improving performance, programming idioms, tutorials etc. >>> >>> · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, >>> oriented to people who want to understand how GHC works, and how to modify >>> it. >>> >>> >>> >>> I think this separation is actually quite helpful. >>> >>> >>> >>> I agree with what you and others say about the difficulty of keeping wikis >>> organised. But that’s not primarily a technology issue: there is a >>> genuinely difficult challenge here. How do you build and maintain >>> up-to-date, navigable, well-organised information about a large, complex, >>> and rapidly changing artefact like GHC? A wiki is one approach that has >>> the merit that anyone can improve it; control is not centralised. But I’d >>> love there to be other, better solutions. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Sven >>> Panne >>> *Sent:* 27 September 2016 08:46 >>> *To:* ghc-devs >>> *Subject:* Re: How, precisely, can we improve? >>> >>> >>> >>> Just a remark from my side: The documentation/tooling landscape is a bit >>> more fragmented than it needs to be IMHO. More concretely: >>> >>> >>> >>> * We currently have *3* wikis: >>> >>> >>> >>> https://wiki.haskell.org/Haskell >>> >>> >>> https://ghc.haskell.org/trac/ghc >>> >>> https://phabricator.haskell.org/w/ >>> >>> >>> >>> >>> >>> It's clear to me that they have different emphases and different >>> origins, but in the end this results in valuable information being >>> scattered around. Wikis in general are already quite hard to navigate (due >>> to their inherent chaotic "structure"), so having 3 of them makes things >>> even worse. It would be great to have *the* single Haskell Wiki directly on >>> haskell.org >>> >>> in an easily reachable place. >>> >>> >>> >>> * To be an active Haskell community member, you need quite a few >>> different logins: Some for the Wikis mentioned above, one for Hackage, >>> another one for Phabricator, perhaps an SSH key here and there... >>> Phabricator is a notable exception: It accepts your GitHub/Google+/... >>> logins. It would be great if the other parts of the Haskell ecosystem >>> accepted those kinds of logins, too. >>> >>> >>> >>> * https://haskell-lang.org/ >>> >>> has great stuff on it, but its relationship to haskell.org >>> >>> is unclear to me. Their "documentation" sub-pages look extremely similar, >>> but haskell-lang.org >>> >>> has various (great!) tutorials and a nice overview of common libraries on >>> it. From an external POV it seems to me that haskell-lang.org >>> >>> should be seamlessly integrated into haskell.org >>> , >>> i.e. merged into it. Having an endless sea of links on haskell.org >>> >>> is not the same as having content nicely integrated into it, sorted by >>> topic, etc. >>> >>> >>> >>> All those points are not show-stoppers for people trying to be more active >>> in the Haskell community, but nevertheless they make things harder than >>> they need to be, so I fear we lose people quite early. To draw an analogy: >>> As probably everybody who actively monitors their web shop/customer site >>> knows, even seemlingy small things moves customers totally away from your >>> site. One unclear payment form? The vast majority of your potential >>> customers aborts the purchase immediately and forever. One confusing >>> interstitial web page? Say goodbye to lots of people. One hard-to-find >>> button/link? A forced login/new account? => Commercial disaster, etc. etc. >>> >>> >>> >>> Furthermore, I'm quite aware of the technical/social difficulties of my >>> proposals, but that shouldn't let us stop trying to improve... >>> >>> >>> >>> Cheers, >>> >>> S. >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eric at seidel.io Tue Sep 27 16:18:36 2016 From: eric at seidel.io (Eric Seidel) Date: Tue, 27 Sep 2016 09:18:36 -0700 Subject: How, precisely, can we improve? In-Reply-To: <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> Message-ID: <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: > Yes, I agree with Michael’s observations in the blog post. However, one > thing that’s easier about a wiki is that the editing process is much more > lightweight than making a PR. > > But GitHub has a wonderful feature (that I have rarely used) that > mitigates this problem. Viewing a file in GitHub offers a little pencil > icon in the top-right. It allows you to make arbitrary changes in the > file and then automates the construction of a PR. The owner of the file > can then accept the PR very, very easily. If the editor has commit > rights, you can make your edits into a commit right away. No need to > fork, pull and push. Indeed, GitHub also supports git-backed wikis, so you can have nicely rendered and inter-linked pages *and* have the option for web-based or git-based editing. Though, based on my limited experience with GitHub wikis, I wonder if they would scale to the size of GHC's wiki.. There's also a tool called gitit (https://github.com/jgm/gitit) that seems to offer the same set of features, but apparently with a more traditional (and I assume customizable) layout. I think having the option for simple, immediate edits or peer-reviewed edits (the peer-review is much more important to me than having an explicitly file-based system) would be a big win. Perhaps there's even a trac module that implements something like this? Then we could decouple it from the question/task of migrating the existing content elsewhere. Eric From ben at smart-cactus.org Tue Sep 27 16:27:33 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Sep 2016 12:27:33 -0400 Subject: How, precisely, can we improve? In-Reply-To: <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> Message-ID: <87bmz9gvey.fsf@ben-laptop.smart-cactus.org> Eric Seidel writes: > Thanks for the link Alan. > > I can personally attest to being intimidated by GHC's wiki when I > started contributing. I think having a review mechanism in place would > have helped, because then you at least know that one or two other people > think your content is clear. > > On a more minor note, I know the trac wiki has a history feature, but > for some reason I find it much less useful than a git history. Perhaps > this is just an issue of familiarity. > I agree, Trac's history feature is quite painful to use. I think that the issue runs deeper than just familiarity. Being restricted comparing revisions in a pairwise manner poses quite a usability problem. Git is simply far more powerful in this area which is one of the advantages that the new proposals process has relative to the Trac wiki. Thankfully, this power isn't strictly necessary for most of the non-proposal content currently in the Wiki. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From carter.schonwald at gmail.com Tue Sep 27 17:18:45 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 27 Sep 2016 13:18:45 -0400 Subject: Adding ConApp to Core In-Reply-To: References: Message-ID: I'm trying to google the System IF spj mentioned earlier in this topic/ or on trac. Google and other search tools are failing me. Can anyone kindly direct me to what papers or expositions on this system f variant ? -Carter > On Sep 25, 2016, at 10:59 AM, Carter Schonwald wrote: > > Also this whole multi arg thing was something I was hoping to talk with Stephanie and or Richard about at hac phi next month. > >> On Sunday, September 25, 2016, Carter Schonwald wrote: >> I'm in favor as well. >> >> I've some experiments I'd like to do on ghc (and that work would support me focusing on!!!) that become dramatically simpler to get the the Simons seal of approval if core already gets multiple arg / simultaneous arg saturated application (a la type are calling or sequent core ). >> :) >> -Carter >> >>> On Saturday, September 24, 2016, Manuel M T Chakravarty wrote: >>> I like this. Having the DataCon only in IdDetails always felt a bit off. >>> >>> Manuel >>> >>>> Simon Peyton Jones via ghc-devs : >>>> >>>> Andres, Richard, Stephanie >>>> >>>> The more I think about our idea of introducing ConApp the more I like it. I wrote it up in a ticket >>>> >>>> https://ghc.haskell.org/trac/ghc/ticket/12618 >>>> >>>> Simon >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Sep 27 18:04:27 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Sep 2016 14:04:27 -0400 Subject: Adding ConApp to Core In-Reply-To: References: Message-ID: <87wphxfcd0.fsf@ben-laptop.smart-cactus.org> Carter Schonwald writes: > I'm trying to google the System IF spj mentioned earlier in this > topic/ or on trac. Google and other search tools are failing me. Can > anyone kindly direct me to what papers or expositions on this system f > variant ? You are looking for Jay and Peyton Jones. "Scrap Your Type Applications" (2008) [1]. Cheers, - Ben [1] https://www.microsoft.com/en-us/research/people/simonpj/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mgsloan at gmail.com Tue Sep 27 21:25:05 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 14:25:05 -0700 Subject: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: Message-ID: On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov wrote: > > About GitHub based contribution. It looks great for me for *all > types* of the patches. But.. bot (or for some time person) should > migrate *all* the patches to Phab, closing the threads for comments. > Bot should write some welcome message than with a link to Phab > request and intruction how to allow Phab to use github account > and read email if there is no account yet. > This way when review had happened author will automatically receive > all review comments with links to Phab, I'll hardly get that following > a link to github is any harder than following link to Phab (assuming > Phab to login using github account). If user addressed comment > he should be able to just force-push/update his branch and new revision > should be created by bot. PR on github should be closed whenever Phab > request will be closed, so it would be trackable using GitHub only. I think this could make a great deal of sense. This will allow us to use the familiar GitHub interface for creating PRs, but all PRs will be maintained within phabricator. Creating a PR should automatically cause the user to create an account on Phabricator, if possible. I've done a quick search to see if a tool exists for this, and all I found was this abandoned patch in the phabricator project itself. https://secure.phabricator.com/D8775 Unfortunately (or fortunately, hah!), I do not know PHP. However, if phabricator has a RESTful API it seems imminently feasible to implement this as a bot written in Haskell. > This way github-ish users could use tool that they used to, but also > reviewers to use the tool they also used to. All the review > comments will be stored in the single place, no revisions will be lost. > This way could be automated and there will be no strange questions > about what is large patch and what is not. The only people who use > are ones that doesn't use email to receive review comments and can > use only GitHub interface to read that, but I doubt that such users exists. > > -- > Alexander > > On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs > wrote: >> Friends >> >> >> >> Here are the notes I took from session 2 of the Haskell Implementors >> Meeting. The bolding is my choice of emphasis. >> >> >> >> Simon >> >> >> >> · Doc bugs. Two kinds >> >> o Typos. Friction stops me >> >> o Explanations needed e.g. read/show >> >> · Lightweight pushes >> >> · Make user manual into its own repo, to make it easier to take pull >> requests. But that makes it harder when making synchronised changes to GHC >> and user manual. >> >> · Auto-push: Ability to push to Phab and have it committed >> automatically if it validates. >> >> · Style guides. Is having a defined style solving a problem we don’t >> really have? One piece of guidance: adhere to the style of the surrounding >> code. Low priority. >> >> · Docker images. We should have one. >> >> · Remove old documentation! >> >> · Cross compilation is difficult. >> >> · Have a GHC StackOverflow on haskell.org (Jacob Zalewski >> jakzale at gmail.com offers to do this! – thank you). It has a useful new >> Documentation feature. Eg this would be good for “how do I look up a >> RdrName to get a Name… there seem to be six different functions that do >> that”. >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Alexander > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mgsloan at gmail.com Tue Sep 27 21:32:14 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 14:32:14 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: You're welcome Richard! I look forward to helping make it happen. In the other thread, Alexander Vershilov mentioned that we might instead consider the following more straightforward workflow: 0) Have a bot that watches github for PRs. 1) Submit whatever you want to github as a PR. 2) It will be automatically closed and migrated to Phabricator. I would like it to automatically create a Phabricator account if you do not already have one. The message from the bot will tell you about this action, and explain how to log in, perhaps even linking to resources about Phabricator. Is this worth it? I think it is for the one-off cases. However, you will have to be prepared that this means that people won't have arcanist setup, and therefore are less likely to actually iterate on their PR. Perhaps we should extend this to the following: 3) Subsequent pushes to the branch for the PR will update the Phabricator differential as if you had pushed via Arcanist. I think with this in place, we would have a fully streamlined system that allows people to use their familiar GitHub workflows, without needing to learn Arcanist. Interactions would then still occur on , of course. This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" tool! Could name the bot that, though! Thoughts? I think it would be great for this to be proposed formally soon so that we can make it happen. I am eager to be able to use my normal git workflows, as my little experience with Arcanist induced some head-scratching. Not the fault of the tool, just a result of lack of familiarity. -Michael On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: > To sum up, this proposes the following: > > 1. Allow PRs on GitHub. > > 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. > > 3. Small GitHub PRs can be merged directly, by ghc-hub. > > 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. > > Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. > > Is this worth sending through ghc-proposals? > > Thanks for volunteering item (2), Michael! > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > >> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: >> >> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. >> >> Manuel >> >>> Michael Sloan : >>> >>> Argh, sent too soon. The first paragraph, revised: >>> >>> This sounds like an ideal solution, Ben! As has been discussed many >>> times before, GitHub has many users familiar with its interface. By >>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>> there is an easy and straightforward process for shifting big patches >>> to Phabricator, then people who are regularly contributing via GitHub >>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>> workflow. >>> >>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>> This sounds like an ideal solution, Ben! As has been discussed many >>>> times before, GitHub has many users familiar with its interface. By >>>> allowing GitHub PRs, the initial contribution >>>> >>>> I think it would be acceptable for larger GitHub PRs to have some >>>> automated boilerplate response. Ideally this would look like: >>>> >>>> """ >>>> Thanks for making this patch! I've turned this into a Phab >>>> Differential xxx and closed this PR. Please create a differential >>>> account associated with your email address ..." >>>> """ >>>> >>>> The email address can be automatically pulled from commit metadata. >>>> If one is absent, then this automated process isn't possible. If it >>>> is present and >>>> >>>> So, I'm imagining a utility that interfaces between both GitHub and >>>> Phab,allowing the following commands: >>>> >>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>>> patch to differential. It may attempt to migrate body and title of >>>> the initial post, but lets not bother with migrating any review data. >>>> >>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>>> patch. This is used for merging small patches. It would not do an >>>> automated push. Maybe have "--push" also perform the push? So like >>>> if you are on master, then "ghc-hub merge >>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>>> push to master. >>>> >>>> How does this sound? I like the idea a lot, and would enjoy helping >>>> with implementation, time permitting. I could possibly start hacking >>>> on it if others give the go ahead of "Yes, lets do that". >>>> >>>> -Michael >>>> >>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>>> Carter Schonwald writes: >>>>> >>>>>> In writing the following huge wall of text, I had and idea that I think >>>>>> many folks would find palatable: >>>>>> >>>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>>> had a mailing list where folks could email the simple / small patches as >>>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>>> and why it's simple! >>>>>> >>>>> I completely agree that for small (e.g. documentation) patches our >>>>> current system is quite heavy. For this reason I suggested at ICFP that >>>>> we simply begin accepting small patches via GitHub pull requests. >>>>> Frankly, this is less work for me than merging patches from a mailing >>>>> list and I believe many users feel that GitHub is more accessible than a >>>>> mailing list. >>>>> >>>>> The problem of course is what subset of patches do we want to allow to >>>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>>> I were to write it myself, I would feel comfortable pushing directly to >>>>> the tree. >>>>> >>>>> Then there is the question of what do we do with pull requests opened >>>>> which do not satisfy this criterion. In this case I would likely open a >>>>> Phabricator Differential with the pull request and close the pull >>>>> request with a link to the Diff. In the ideal case this will inspire the >>>>> contributor to join the review process on Phabricator; in the worst case >>>>> review turns up issues in the patch and the user gives up. Either way, at >>>>> least the contributor feels his patch has been seen and given the >>>>> attention it deserves. >>>>> >>>>> Cheers, >>>>> >>>>> - Ben >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mgsloan at gmail.com Tue Sep 27 21:58:43 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 14:58:43 -0700 Subject: How, precisely, can we improve? In-Reply-To: <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> Message-ID: On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: > On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> Yes, I agree with Michael’s observations in the blog post. However, one >> thing that’s easier about a wiki is that the editing process is much more >> lightweight than making a PR. >> >> But GitHub has a wonderful feature (that I have rarely used) that >> mitigates this problem. Viewing a file in GitHub offers a little pencil >> icon in the top-right. It allows you to make arbitrary changes in the >> file and then automates the construction of a PR. The owner of the file >> can then accept the PR very, very easily. If the editor has commit >> rights, you can make your edits into a commit right away. No need to >> fork, pull and push. > > Indeed, GitHub also supports git-backed wikis, so you can have nicely > rendered and inter-linked pages *and* have the option for web-based or > git-based editing. Though, based on my limited experience with GitHub > wikis, I wonder if they would scale to the size of GHC's wiki.. I agree, I don't think GitHub wikis are sufficient for GHC. We've tried using GitHub wikis, and found that they were clunkier than just having wiki / docs in your repo. GHC would probably want to have a separate docs repo, as otherwise the commit history will get filled with commits related to proposals, etc. It may be worth considering a similar approach with the GHC documentation. We've had great success in stack with using https://readthedocs.org/ . The way this works is that you have a branch that readthedocs points at ("stable"), which provides the current version to display. I realize that ghc would want to have multiple versions of the docs up, but I'm sure that's feasible. Github itself has pretty nice markdown rendering, and the ability to edit directly. Note that there is no GitHub lock-in here - it is just a collection of markdown files, organized however you like them. The risk with such a migration is that the old wiki(s?) don't get fully migrated and shut down. If that happens, then information will be even more spread out and hard to find. Perhaps we can use pandoc to automatically migrate much of the wiki content to markdown? It probably will not be a lossfree conversion. > There's also a tool called gitit (https://github.com/jgm/gitit) that > seems to offer the same set of features, but apparently with a more > traditional (and I assume customizable) layout. > > I think having the option for simple, immediate edits or peer-reviewed > edits (the peer-review is much more important to me than having an > explicitly file-based system) would be a big win. Perhaps there's even a > trac module that implements something like this? Then we could decouple > it from the question/task of migrating the existing content elsewhere. > > Eric > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Tue Sep 27 23:13:24 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 28 Sep 2016 08:13:24 +0900 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since: 1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that! Thoughts? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott wrote: > Hello, everyone! Sorry for not being able to respond to some of the > recent feedback. > > Well, it seems I'm at a bit of an impasse again. I originally changed > "builtin" to "bespoke" because enough GHC devs voiced their > displeasure (ranging from moderate to severe) with "builtin". I hoped > that choosing "bespoke" would strike a happy medium where we could > have a term that (1) reasonably describes its intended purpose, (2) > wouldn't be highly misleading upon an initial glance, and (3) wouldn't > be too off-putting to use as a reserved keyword. > > Unfortunately, I over-estimated how well "bespoke" meets criterion 3, > since several people have _also_ voiced their displeasure with it! > (Again, ranging from moderate to severe.) So we're back to square one, > it seems. I don't want to push this patch without a general feeling of > community consensus, but the patch is complete after all, with the > exception of bikeshedding, so I'd like to try and come up with a > colo(u)r that folks will be happy with so we can proceed and I can > work on other things that need this feature. > > So, instead of "builtin" and "bespoke", I propose reconsidering an > earlier suggestion of Elliot Cameron's: "standard". I had previously > expressed reservations about "standard" before, since I felt it might > be miscontrued as meaning "a Haskell standard" (e.g., the Haskell > Report). But upon further thought, I have actually come to like the > word "standard". Here's why: > > 1. It's simple. "Standard" is recognizable whether you speak American > English, British English, or pretty much any other variant that I'm > aware of. > 2. It has precedent. A GHC error message already uses the phrase > "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we > adopt "standard" as our keyword, then we could endow this phrase with > a more precise meaning. > 3. It reflects history. This deriving strategy (that I'm proposing to > name "standard") was the very first deriving strategy that GHC > supported (to my knowledge), so it makes sense to refer to this > strategy as the "standard" one, since all other strategies were added > later. > 4. It's not too ambiguous. As opposed to say, "default" (which could > be confused with -XDefaultSignatures, i.e., the anyclass strategy), I > think that "standard" has a pretty obvious connotation in the context > of deriving. There is the possibility of misinterpreting "standard" to > refer to the Haskell Report, but that wouldn't be the worst > misconception in the world to make, since several "standard derivable > classes" are actually in the Haskell Report (whereas neither > GeneralizedNewtypeDeriving nor DeriveAnyClass are). > > What does everyone think? > > Ryan S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 27 23:49:43 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 27 Sep 2016 19:49:43 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right? While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land Otherwise : standard or stock all sound good to me. On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote: > Sorry to keep changing my mind on this topic, but I'd like to make one > last alternate suggestion, which I think surpasses all the previous ones. > Joachim proposed that what was called "bespoke", "standard", or "builtin" > in the past be called "stock" instead [1]. I like this idea since: > > 1. "Stock" is a short, instantly recognizable English word, no matter > where you live (I think). > 2. It conveys the right meaning, as "stock" indicates something > straightforward or normal (in contrast to GND and DAC, which do something a > bit more novel). "Stock" has other meanings, but in this context I believe > it's clear what it indicates. > 3. It doesn't have the disadvantages of the other suggestions. Besides the > points already covered, Joachim noted that "bespoke" has connotations of > giving instances that would be tailor-fit for a datatype (e.g., "ignore > field x in the Eq instance, because it is just a cached value that depends > on the other"), when in reality, the strategy is far more mechanical than > that! > > Thoughts? > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 > > On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott > wrote: > >> Hello, everyone! Sorry for not being able to respond to some of the >> recent feedback. >> >> Well, it seems I'm at a bit of an impasse again. I originally changed >> "builtin" to "bespoke" because enough GHC devs voiced their >> displeasure (ranging from moderate to severe) with "builtin". I hoped >> that choosing "bespoke" would strike a happy medium where we could >> have a term that (1) reasonably describes its intended purpose, (2) >> wouldn't be highly misleading upon an initial glance, and (3) wouldn't >> be too off-putting to use as a reserved keyword. >> >> Unfortunately, I over-estimated how well "bespoke" meets criterion 3, >> since several people have _also_ voiced their displeasure with it! >> (Again, ranging from moderate to severe.) So we're back to square one, >> it seems. I don't want to push this patch without a general feeling of >> community consensus, but the patch is complete after all, with the >> exception of bikeshedding, so I'd like to try and come up with a >> colo(u)r that folks will be happy with so we can proceed and I can >> work on other things that need this feature. >> >> So, instead of "builtin" and "bespoke", I propose reconsidering an >> earlier suggestion of Elliot Cameron's: "standard". I had previously >> expressed reservations about "standard" before, since I felt it might >> be miscontrued as meaning "a Haskell standard" (e.g., the Haskell >> Report). But upon further thought, I have actually come to like the >> word "standard". Here's why: >> >> 1. It's simple. "Standard" is recognizable whether you speak American >> English, British English, or pretty much any other variant that I'm >> aware of. >> 2. It has precedent. A GHC error message already uses the phrase >> "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we >> adopt "standard" as our keyword, then we could endow this phrase with >> a more precise meaning. >> 3. It reflects history. This deriving strategy (that I'm proposing to >> name "standard") was the very first deriving strategy that GHC >> supported (to my knowledge), so it makes sense to refer to this >> strategy as the "standard" one, since all other strategies were added >> later. >> 4. It's not too ambiguous. As opposed to say, "default" (which could >> be confused with -XDefaultSignatures, i.e., the anyclass strategy), I >> think that "standard" has a pretty obvious connotation in the context >> of deriving. There is the possibility of misinterpreting "standard" to >> refer to the Haskell Report, but that wouldn't be the worst >> misconception in the world to make, since several "standard derivable >> classes" are actually in the Haskell Report (whereas neither >> GeneralizedNewtypeDeriving nor DeriveAnyClass are). >> >> What does everyone think? >> >> Ryan S. >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Tue Sep 27 23:55:43 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 28 Sep 2016 08:55:43 +0900 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: > This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right? A valid concern! Rest assured, you'd still be able to use "stock" as, say, a variable in a function, since GHC's parser has a production just for IDs that have meanings in special contexts. (If you want to win at Haskell trivia night, the current special IDs are "as", "qualified", "hiding", "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", "javascript", and "group" [1]). In my implementation, I make "stock" and "anyclass" special IDs, so they only become keywords when used after "deriving". Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f57676574d338be1f5:/compiler/parser/Parser.y#l3054 [2] On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > This wouldn't eat up Stock as a data type or type classes or stock in any > other syntactic context right? > > While this term in the finance context hasn't come up in my own work this > past year, just want to make sure it won't eat a key word piece of name > space in value or types land > > Otherwise : standard or stock all sound good to me. > > On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote: > >> Sorry to keep changing my mind on this topic, but I'd like to make one >> last alternate suggestion, which I think surpasses all the previous ones. >> Joachim proposed that what was called "bespoke", "standard", or "builtin" >> in the past be called "stock" instead [1]. I like this idea since: >> >> 1. "Stock" is a short, instantly recognizable English word, no matter >> where you live (I think). >> 2. It conveys the right meaning, as "stock" indicates something >> straightforward or normal (in contrast to GND and DAC, which do something a >> bit more novel). "Stock" has other meanings, but in this context I believe >> it's clear what it indicates. >> 3. It doesn't have the disadvantages of the other suggestions. Besides >> the points already covered, Joachim noted that "bespoke" has connotations >> of giving instances that would be tailor-fit for a datatype (e.g., "ignore >> field x in the Eq instance, because it is just a cached value that depends >> on the other"), when in reality, the strategy is far more mechanical than >> that! >> >> Thoughts? >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 >> >> On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott >> wrote: >> >>> Hello, everyone! Sorry for not being able to respond to some of the >>> recent feedback. >>> >>> Well, it seems I'm at a bit of an impasse again. I originally changed >>> "builtin" to "bespoke" because enough GHC devs voiced their >>> displeasure (ranging from moderate to severe) with "builtin". I hoped >>> that choosing "bespoke" would strike a happy medium where we could >>> have a term that (1) reasonably describes its intended purpose, (2) >>> wouldn't be highly misleading upon an initial glance, and (3) wouldn't >>> be too off-putting to use as a reserved keyword. >>> >>> Unfortunately, I over-estimated how well "bespoke" meets criterion 3, >>> since several people have _also_ voiced their displeasure with it! >>> (Again, ranging from moderate to severe.) So we're back to square one, >>> it seems. I don't want to push this patch without a general feeling of >>> community consensus, but the patch is complete after all, with the >>> exception of bikeshedding, so I'd like to try and come up with a >>> colo(u)r that folks will be happy with so we can proceed and I can >>> work on other things that need this feature. >>> >>> So, instead of "builtin" and "bespoke", I propose reconsidering an >>> earlier suggestion of Elliot Cameron's: "standard". I had previously >>> expressed reservations about "standard" before, since I felt it might >>> be miscontrued as meaning "a Haskell standard" (e.g., the Haskell >>> Report). But upon further thought, I have actually come to like the >>> word "standard". Here's why: >>> >>> 1. It's simple. "Standard" is recognizable whether you speak American >>> English, British English, or pretty much any other variant that I'm >>> aware of. >>> 2. It has precedent. A GHC error message already uses the phrase >>> "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we >>> adopt "standard" as our keyword, then we could endow this phrase with >>> a more precise meaning. >>> 3. It reflects history. This deriving strategy (that I'm proposing to >>> name "standard") was the very first deriving strategy that GHC >>> supported (to my knowledge), so it makes sense to refer to this >>> strategy as the "standard" one, since all other strategies were added >>> later. >>> 4. It's not too ambiguous. As opposed to say, "default" (which could >>> be confused with -XDefaultSignatures, i.e., the anyclass strategy), I >>> think that "standard" has a pretty obvious connotation in the context >>> of deriving. There is the possibility of misinterpreting "standard" to >>> refer to the Haskell Report, but that wouldn't be the worst >>> misconception in the world to make, since several "standard derivable >>> classes" are actually in the Haskell Report (whereas neither >>> GeneralizedNewtypeDeriving nor DeriveAnyClass are). >>> >>> What does everyone think? >>> >>> Ryan S. >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Sep 28 01:47:14 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 21:47:14 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided the integration works smoothly, I quite like this idea. Richard > On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote: > > You're welcome Richard! I look forward to helping make it happen. In > the other thread, Alexander Vershilov mentioned that we might instead > consider the following more straightforward workflow: > > 0) Have a bot that watches github for PRs. > 1) Submit whatever you want to github as a PR. > 2) It will be automatically closed and migrated to Phabricator. I > would like it to automatically create a Phabricator account if you do > not already have one. The message from the bot will tell you about > this action, and explain how to log in, perhaps even linking to > resources about Phabricator. > > Is this worth it? I think it is for the one-off cases. However, you > will have to be prepared that this means that people won't have > arcanist setup, and therefore are less likely to actually iterate on > their PR. Perhaps we should extend this to the following: > > 3) Subsequent pushes to the branch for the PR will update the > Phabricator differential as if you had pushed via Arcanist. I think > with this in place, we would have a fully streamlined system that > allows people to use their familiar GitHub workflows, without needing > to learn Arcanist. Interactions would then still occur on , of > course. > > This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" > tool! Could name the bot that, though! > > Thoughts? I think it would be great for this to be proposed formally > soon so that we can make it happen. I am eager to be able to use my > normal git workflows, as my little experience with Arcanist induced > some head-scratching. Not the fault of the tool, just a result of > lack of familiarity. > > -Michael > > On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: >> To sum up, this proposes the following: >> >> 1. Allow PRs on GitHub. >> >> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. >> >> 3. Small GitHub PRs can be merged directly, by ghc-hub. >> >> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. >> >> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. >> >> Is this worth sending through ghc-proposals? >> >> Thanks for volunteering item (2), Michael! >> >> Richard >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: >>> >>> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. >>> >>> Manuel >>> >>>> Michael Sloan : >>>> >>>> Argh, sent too soon. The first paragraph, revised: >>>> >>>> This sounds like an ideal solution, Ben! As has been discussed many >>>> times before, GitHub has many users familiar with its interface. By >>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>>> there is an easy and straightforward process for shifting big patches >>>> to Phabricator, then people who are regularly contributing via GitHub >>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>>> workflow. >>>> >>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>> times before, GitHub has many users familiar with its interface. By >>>>> allowing GitHub PRs, the initial contribution >>>>> >>>>> I think it would be acceptable for larger GitHub PRs to have some >>>>> automated boilerplate response. Ideally this would look like: >>>>> >>>>> """ >>>>> Thanks for making this patch! I've turned this into a Phab >>>>> Differential xxx and closed this PR. Please create a differential >>>>> account associated with your email address ..." >>>>> """ >>>>> >>>>> The email address can be automatically pulled from commit metadata. >>>>> If one is absent, then this automated process isn't possible. If it >>>>> is present and >>>>> >>>>> So, I'm imagining a utility that interfaces between both GitHub and >>>>> Phab,allowing the following commands: >>>>> >>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>>>> patch to differential. It may attempt to migrate body and title of >>>>> the initial post, but lets not bother with migrating any review data. >>>>> >>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>>>> patch. This is used for merging small patches. It would not do an >>>>> automated push. Maybe have "--push" also perform the push? So like >>>>> if you are on master, then "ghc-hub merge >>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>>>> push to master. >>>>> >>>>> How does this sound? I like the idea a lot, and would enjoy helping >>>>> with implementation, time permitting. I could possibly start hacking >>>>> on it if others give the go ahead of "Yes, lets do that". >>>>> >>>>> -Michael >>>>> >>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>>>> Carter Schonwald writes: >>>>>> >>>>>>> In writing the following huge wall of text, I had and idea that I think >>>>>>> many folks would find palatable: >>>>>>> >>>>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>>>> had a mailing list where folks could email the simple / small patches as >>>>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>>>> and why it's simple! >>>>>>> >>>>>> I completely agree that for small (e.g. documentation) patches our >>>>>> current system is quite heavy. For this reason I suggested at ICFP that >>>>>> we simply begin accepting small patches via GitHub pull requests. >>>>>> Frankly, this is less work for me than merging patches from a mailing >>>>>> list and I believe many users feel that GitHub is more accessible than a >>>>>> mailing list. >>>>>> >>>>>> The problem of course is what subset of patches do we want to allow to >>>>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>>>> I were to write it myself, I would feel comfortable pushing directly to >>>>>> the tree. >>>>>> >>>>>> Then there is the question of what do we do with pull requests opened >>>>>> which do not satisfy this criterion. In this case I would likely open a >>>>>> Phabricator Differential with the pull request and close the pull >>>>>> request with a link to the Diff. In the ideal case this will inspire the >>>>>> contributor to join the review process on Phabricator; in the worst case >>>>>> review turns up issues in the patch and the user gives up. Either way, at >>>>>> least the contributor feels his patch has been seen and given the >>>>>> attention it deserves. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> - Ben >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From moritz at lichtzwerge.de Wed Sep 28 01:49:20 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Wed, 28 Sep 2016 09:49:20 +0800 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> Message-ID: <7C41C4D9-D9DF-4ED8-8CF8-F7DB3DC3B323@lichtzwerge.de> Hi, I think it would be great if this was proposed formally. If we could integrate this with the improved ghc development proposal[1], this would be great! Or turn it into a separate proposal and remove the similar parts from the one mentioned. However, on the topic, I’d like to share a few thoughts: Do we know how many of these GitHub Pull Requests we will actually receive? If we migrate *everything* over to phabricator, isn’t that just going to increase complexity for most of the minor pull request? If someone fixes a spelling mistake or adds a short comment to explain something in more detail, I see no reason why we need to employ any heavy machinery and duplication across different tools. These, so I would hope, would be trivially merged by a small team of ghc devs watching the GitHub PR, especially if we don’t even know how much PRs we will receive through GitHub. On the other hand, if a PR is non-trivial (yes this is a bit of an ambiguous term), I’m in favor of asking the person who issued the PR to open an account with Phabricator[2], and run `$ arc diff origin/master` on his branch, or let us know that he considers this too much effort (and is willing to have someone else take over, should there be interest). The reasoning behind this is the following: first of all it’s the persons work, and unless someone else is willing to take it through the review process, this is going to end up being a dead diff in phabricator which adds additional overhead there. If there is not enough interest to follow a simple few steps document on how to push a non-trivial patch to phabricator, can we expect there to be sufficient interest in actually following up on the review process? I see this more as an onboarding problem than a continuous development issue. Those who are in the phabricator workflow, will likely just continue using it, no? I certainly would! However I might be browsing ghc source on GH just because I don’t have that code locally available right now and stumble on a spelling mistake, quickly use the editor provided by GH and submit one of these trivial PRs. Those who haven’t used phabricator yet, but are accustomed to the GH PR Flow, would start there and then be gently guided towards using phabricator and arc. We can do much better at explaining and showing the phabricator and arc workflow. In essence I’d like us see accepting GH Pull Requests and then do more data-driven on-demand incremental improvements, instead of trying to go all out with excessive tooling. Cheers, Moritz [1]: https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/0000-improved-ghc-development.rst [2]: See the contributing to ghc section in [1]. > On Sep 28, 2016, at 5:32 AM, Michael Sloan wrote: > > You're welcome Richard! I look forward to helping make it happen. In > the other thread, Alexander Vershilov mentioned that we might instead > consider the following more straightforward workflow: > > 0) Have a bot that watches github for PRs. > 1) Submit whatever you want to github as a PR. > 2) It will be automatically closed and migrated to Phabricator. I > would like it to automatically create a Phabricator account if you do > not already have one. The message from the bot will tell you about > this action, and explain how to log in, perhaps even linking to > resources about Phabricator. > > Is this worth it? I think it is for the one-off cases. However, you > will have to be prepared that this means that people won't have > arcanist setup, and therefore are less likely to actually iterate on > their PR. Perhaps we should extend this to the following: > > 3) Subsequent pushes to the branch for the PR will update the > Phabricator differential as if you had pushed via Arcanist. I think > with this in place, we would have a fully streamlined system that > allows people to use their familiar GitHub workflows, without needing > to learn Arcanist. Interactions would then still occur on , of > course. > > This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" > tool! Could name the bot that, though! > > Thoughts? I think it would be great for this to be proposed formally > soon so that we can make it happen. I am eager to be able to use my > normal git workflows, as my little experience with Arcanist induced > some head-scratching. Not the fault of the tool, just a result of > lack of familiarity. > > -Michael > > On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: >> To sum up, this proposes the following: >> >> 1. Allow PRs on GitHub. >> >> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. >> >> 3. Small GitHub PRs can be merged directly, by ghc-hub. >> >> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. >> >> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. >> >> Is this worth sending through ghc-proposals? >> >> Thanks for volunteering item (2), Michael! >> >> Richard >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: >>> >>> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. >>> >>> Manuel >>> >>>> Michael Sloan : >>>> >>>> Argh, sent too soon. The first paragraph, revised: >>>> >>>> This sounds like an ideal solution, Ben! As has been discussed many >>>> times before, GitHub has many users familiar with its interface. By >>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>>> there is an easy and straightforward process for shifting big patches >>>> to Phabricator, then people who are regularly contributing via GitHub >>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>>> workflow. >>>> >>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>> times before, GitHub has many users familiar with its interface. By >>>>> allowing GitHub PRs, the initial contribution >>>>> >>>>> I think it would be acceptable for larger GitHub PRs to have some >>>>> automated boilerplate response. Ideally this would look like: >>>>> >>>>> """ >>>>> Thanks for making this patch! I've turned this into a Phab >>>>> Differential xxx and closed this PR. Please create a differential >>>>> account associated with your email address ..." >>>>> """ >>>>> >>>>> The email address can be automatically pulled from commit metadata. >>>>> If one is absent, then this automated process isn't possible. If it >>>>> is present and >>>>> >>>>> So, I'm imagining a utility that interfaces between both GitHub and >>>>> Phab,allowing the following commands: >>>>> >>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>>>> patch to differential. It may attempt to migrate body and title of >>>>> the initial post, but lets not bother with migrating any review data. >>>>> >>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>>>> patch. This is used for merging small patches. It would not do an >>>>> automated push. Maybe have "--push" also perform the push? So like >>>>> if you are on master, then "ghc-hub merge >>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>>>> push to master. >>>>> >>>>> How does this sound? I like the idea a lot, and would enjoy helping >>>>> with implementation, time permitting. I could possibly start hacking >>>>> on it if others give the go ahead of "Yes, lets do that". >>>>> >>>>> -Michael >>>>> >>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>>>> Carter Schonwald writes: >>>>>> >>>>>>> In writing the following huge wall of text, I had and idea that I think >>>>>>> many folks would find palatable: >>>>>>> >>>>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>>>> had a mailing list where folks could email the simple / small patches as >>>>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>>>> and why it's simple! >>>>>>> >>>>>> I completely agree that for small (e.g. documentation) patches our >>>>>> current system is quite heavy. For this reason I suggested at ICFP that >>>>>> we simply begin accepting small patches via GitHub pull requests. >>>>>> Frankly, this is less work for me than merging patches from a mailing >>>>>> list and I believe many users feel that GitHub is more accessible than a >>>>>> mailing list. >>>>>> >>>>>> The problem of course is what subset of patches do we want to allow to >>>>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>>>> I were to write it myself, I would feel comfortable pushing directly to >>>>>> the tree. >>>>>> >>>>>> Then there is the question of what do we do with pull requests opened >>>>>> which do not satisfy this criterion. In this case I would likely open a >>>>>> Phabricator Differential with the pull request and close the pull >>>>>> request with a link to the Diff. In the ideal case this will inspire the >>>>>> contributor to join the review process on Phabricator; in the worst case >>>>>> review turns up issues in the patch and the user gives up. Either way, at >>>>>> least the contributor feels his patch has been seen and given the >>>>>> attention it deserves. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> - Ben >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Wed Sep 28 01:51:22 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 21:51:22 -0400 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> Message-ID: <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> I'm quite leery of using a new site (readthedocs.org), as it creates yet another platform for contributors to understand. Reducing the number of platforms has been a fairly clearly-stated goal of these recent conversations, as I've read it. Despite agreeing that wikis are sometimes wonky, I thought of a solid reason against moving: we lose the Trac integration. A Trac wiki page can easily link to tickets and individual comments, and can use dynamic features such as lists of active tickets. These are useful and well-used features. I don't know what's best here, but thinking about the real loss associated with moving away from these features gives me pause. Richard > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: > > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>> Yes, I agree with Michael’s observations in the blog post. However, one >>> thing that’s easier about a wiki is that the editing process is much more >>> lightweight than making a PR. >>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>> mitigates this problem. Viewing a file in GitHub offers a little pencil >>> icon in the top-right. It allows you to make arbitrary changes in the >>> file and then automates the construction of a PR. The owner of the file >>> can then accept the PR very, very easily. If the editor has commit >>> rights, you can make your edits into a commit right away. No need to >>> fork, pull and push. >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >> rendered and inter-linked pages *and* have the option for web-based or >> git-based editing. Though, based on my limited experience with GitHub >> wikis, I wonder if they would scale to the size of GHC's wiki.. > > I agree, I don't think GitHub wikis are sufficient for GHC. We've > tried using GitHub wikis, and found that they were clunkier than just > having wiki / docs in your repo. GHC would probably want to have a > separate docs repo, as otherwise the commit history will get filled > with commits related to proposals, etc. > > It may be worth considering a similar approach with the GHC > documentation. We've had great success in stack with using > https://readthedocs.org/ . The way this works is that you have a > branch that readthedocs points at ("stable"), which provides the > current version to display. I realize that ghc would want to have > multiple versions of the docs up, but I'm sure that's feasible. > > Github itself has pretty nice markdown rendering, and the ability to > edit directly. Note that there is no GitHub lock-in here - it is just > a collection of markdown files, organized however you like them. > > The risk with such a migration is that the old wiki(s?) don't get > fully migrated and shut down. If that happens, then information will > be even more spread out and hard to find. Perhaps we can use pandoc > to automatically migrate much of the wiki content to markdown? It > probably will not be a lossfree conversion. > >> There's also a tool called gitit (https://github.com/jgm/gitit) that >> seems to offer the same set of features, but apparently with a more >> traditional (and I assume customizable) layout. >> >> I think having the option for simple, immediate edits or peer-reviewed >> edits (the peer-review is much more important to me than having an >> explicitly file-based system) would be a big win. Perhaps there's even a >> trac module that implements something like this? Then we could decouple >> it from the question/task of migrating the existing content elsewhere. >> >> Eric >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Wed Sep 28 02:06:01 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 22:06:01 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: +1 on `stock` from me. Though I was all excited to get my class next semester jazzed for PL work by explaining that I had slipped a new keyword `bespoke` into a language. :) Richard > On Sep 27, 2016, at 7:55 PM, Ryan Scott wrote: > > > This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right? > > A valid concern! Rest assured, you'd still be able to use "stock" as, say, a variable in a function, since GHC's parser has a production just for IDs that have meanings in special contexts. (If you want to win at Haskell trivia night, the current special IDs are "as", "qualified", "hiding", "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", "javascript", and "group" [1]). In my implementation, I make "stock" and "anyclass" special IDs, so they only become keywords when used after "deriving". > > Ryan S. > ----- > [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f57676574d338be1f5:/compiler/parser/Parser.y#l3054 > [2] > > On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald > wrote: > This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right? > > While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land > > Otherwise : standard or stock all sound good to me. > > > On Sep 27, 2016 7:14 PM, "Ryan Scott" > wrote: > Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since: > > 1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). > 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. > 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that! > > Thoughts? > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 > > On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott > wrote: > Hello, everyone! Sorry for not being able to respond to some of the > recent feedback. > > Well, it seems I'm at a bit of an impasse again. I originally changed > "builtin" to "bespoke" because enough GHC devs voiced their > displeasure (ranging from moderate to severe) with "builtin". I hoped > that choosing "bespoke" would strike a happy medium where we could > have a term that (1) reasonably describes its intended purpose, (2) > wouldn't be highly misleading upon an initial glance, and (3) wouldn't > be too off-putting to use as a reserved keyword. > > Unfortunately, I over-estimated how well "bespoke" meets criterion 3, > since several people have _also_ voiced their displeasure with it! > (Again, ranging from moderate to severe.) So we're back to square one, > it seems. I don't want to push this patch without a general feeling of > community consensus, but the patch is complete after all, with the > exception of bikeshedding, so I'd like to try and come up with a > colo(u)r that folks will be happy with so we can proceed and I can > work on other things that need this feature. > > So, instead of "builtin" and "bespoke", I propose reconsidering an > earlier suggestion of Elliot Cameron's: "standard". I had previously > expressed reservations about "standard" before, since I felt it might > be miscontrued as meaning "a Haskell standard" (e.g., the Haskell > Report). But upon further thought, I have actually come to like the > word "standard". Here's why: > > 1. It's simple. "Standard" is recognizable whether you speak American > English, British English, or pretty much any other variant that I'm > aware of. > 2. It has precedent. A GHC error message already uses the phrase > "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we > adopt "standard" as our keyword, then we could endow this phrase with > a more precise meaning. > 3. It reflects history. This deriving strategy (that I'm proposing to > name "standard") was the very first deriving strategy that GHC > supported (to my knowledge), so it makes sense to refer to this > strategy as the "standard" one, since all other strategies were added > later. > 4. It's not too ambiguous. As opposed to say, "default" (which could > be confused with -XDefaultSignatures, i.e., the anyclass strategy), I > think that "standard" has a pretty obvious connotation in the context > of deriving. There is the possibility of misinterpreting "standard" to > refer to the Haskell Report, but that wouldn't be the worst > misconception in the world to make, since several "standard derivable > classes" are actually in the Haskell Report (whereas neither > GeneralizedNewtypeDeriving nor DeriveAnyClass are). > > What does everyone think? > > Ryan S. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Wed Sep 28 02:20:28 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 19:20:28 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <7C41C4D9-D9DF-4ED8-8CF8-F7DB3DC3B323@lichtzwerge.de> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <7C41C4D9-D9DF-4ED8-8CF8-F7DB3DC3B323@lichtzwerge.de> Message-ID: On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann wrote: > Hi, > > I think it would be great if this was proposed formally. If we could > integrate this with the improved ghc development proposal[1], this > would be great! Or turn it into a separate proposal and remove the > similar parts from the one mentioned. Cool! Should I do the integration? I wouldn't mind if someone else took these thoughts and integrated them, though I'd like to see how they get integrated! > However, on the topic, I’d like to share a few thoughts: > > Do we know how many of these GitHub Pull Requests we will actually > receive? If we migrate *everything* over to phabricator, isn’t that > just going to increase complexity for most of the minor pull request? We don't know how many, hopefully lots, right? What's the usual complexity for a minor patch to GHC - does it just skip differential and end up getting committed directly to master? In that case, yes this would cause there to be a lot more differentials. Is that a bad thing? We could certainly consider something more like the "ghc-hub" tool I've described elsewhere. This would give more direct control of what happens to GitHub PRs, but would also require manual oversight of incoming GitHub PRs. > If someone fixes a spelling mistake or adds a short comment to > explain something in more detail, I see no reason why we need to employ > any heavy machinery and duplication across different tools. These, so > I would hope, would be trivially merged by a small team of ghc devs > watching the GitHub PR, especially if we don’t even know how much PRs > we will receive through GitHub. > > On the other hand, if a PR is non-trivial (yes this is a bit of an > ambiguous term), I’m in favor of asking the person who issued the PR > to open an account with Phabricator[2], and run `$ arc diff origin/master` > on his branch, or let us know that he considers this too much effort > (and is willing to have someone else take over, should there be interest). > The reasoning behind this is the following: first of all it’s the persons > work, and unless someone else is willing to take it through the review > process, this is going to end up being a dead diff in phabricator which > adds additional overhead there. If there is not enough interest to follow > a simple few steps document on how to push a non-trivial patch to > phabricator, can we expect there to be sufficient interest in actually > following up on the review process? > > I see this more as an onboarding problem than a continuous development > issue. Those who are in the phabricator workflow, will likely just > continue using it, no? I certainly would! However I might be browsing > ghc source on GH just because I don’t have that code locally available > right now and stumble on a spelling mistake, quickly use the editor > provided by GH and submit one of these trivial PRs. Exactly! GH has great support for creating trivial PRs. It is also a workflow people are familiar with. As soon as you ask people to install a piece of software and learn to use it (arcanist), there is immediately a cognitive barrier. Even if the software is easy to learn. I recall being confused about arcanist squashing, for example. I haven't used it in a long time, so I don't recall details. I can see the attitude of "Well, if you're hacking on GHC, you are probably capable of learning some new tools." This is true, but this stuff is adding cognitive load atop the existing cognitive load of creating a patch for GHC. > Those who haven’t used phabricator yet, but are accustomed to the GH > PR Flow, would start there and then be gently guided towards using > phabricator and arc. We can do much better at explaining and showing > the phabricator and arc workflow. Yup! That's how I see this as well. It is leveraging GH PRs as an easy way to attract contribution, but also guiding people towards Phabricator. As things stand, you need to learn both Phabricator and Arcanist at the same time. This way, we can start with onboarding people with phabricator, and later get them to start using archanist directly. Some won't make it to that stage, but it will still be valuable to get GH PRs from them! > In essence I’d like us see accepting GH Pull Requests and then do > more data-driven on-demand incremental improvements, instead of trying > to go all out with excessive tooling. This is a wise approach! I think it makes sense to try the manual labor version of this process before automating it. Automation should be on the minds of those doing the work, though, and they can be reassured that it will get easier once automation is in place. > Cheers, > Moritz > > > [1]: https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/0000-improved-ghc-development.rst > [2]: See the contributing to ghc section in [1]. >> On Sep 28, 2016, at 5:32 AM, Michael Sloan wrote: >> >> You're welcome Richard! I look forward to helping make it happen. In >> the other thread, Alexander Vershilov mentioned that we might instead >> consider the following more straightforward workflow: >> >> 0) Have a bot that watches github for PRs. >> 1) Submit whatever you want to github as a PR. >> 2) It will be automatically closed and migrated to Phabricator. I >> would like it to automatically create a Phabricator account if you do >> not already have one. The message from the bot will tell you about >> this action, and explain how to log in, perhaps even linking to >> resources about Phabricator. >> >> Is this worth it? I think it is for the one-off cases. However, you >> will have to be prepared that this means that people won't have >> arcanist setup, and therefore are less likely to actually iterate on >> their PR. Perhaps we should extend this to the following: >> >> 3) Subsequent pushes to the branch for the PR will update the >> Phabricator differential as if you had pushed via Arcanist. I think >> with this in place, we would have a fully streamlined system that >> allows people to use their familiar GitHub workflows, without needing >> to learn Arcanist. Interactions would then still occur on , of >> course. >> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" >> tool! Could name the bot that, though! >> >> Thoughts? I think it would be great for this to be proposed formally >> soon so that we can make it happen. I am eager to be able to use my >> normal git workflows, as my little experience with Arcanist induced >> some head-scratching. Not the fault of the tool, just a result of >> lack of familiarity. >> >> -Michael >> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: >>> To sum up, this proposes the following: >>> >>> 1. Allow PRs on GitHub. >>> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. >>> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub. >>> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. >>> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. >>> >>> Is this worth sending through ghc-proposals? >>> >>> Thanks for volunteering item (2), Michael! >>> >>> Richard >>> >>> -=-=-=-=-=-=-=-=-=-=- >>> Richard A. Eisenberg >>> Asst. Prof. of Computer Science >>> Bryn Mawr College >>> Bryn Mawr, PA, USA >>> cs.brynmawr.edu/~rae >>> >>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: >>>> >>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. >>>> >>>> Manuel >>>> >>>>> Michael Sloan : >>>>> >>>>> Argh, sent too soon. The first paragraph, revised: >>>>> >>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>> times before, GitHub has many users familiar with its interface. By >>>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>>>> there is an easy and straightforward process for shifting big patches >>>>> to Phabricator, then people who are regularly contributing via GitHub >>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>>>> workflow. >>>>> >>>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>>> times before, GitHub has many users familiar with its interface. By >>>>>> allowing GitHub PRs, the initial contribution >>>>>> >>>>>> I think it would be acceptable for larger GitHub PRs to have some >>>>>> automated boilerplate response. Ideally this would look like: >>>>>> >>>>>> """ >>>>>> Thanks for making this patch! I've turned this into a Phab >>>>>> Differential xxx and closed this PR. Please create a differential >>>>>> account associated with your email address ..." >>>>>> """ >>>>>> >>>>>> The email address can be automatically pulled from commit metadata. >>>>>> If one is absent, then this automated process isn't possible. If it >>>>>> is present and >>>>>> >>>>>> So, I'm imagining a utility that interfaces between both GitHub and >>>>>> Phab,allowing the following commands: >>>>>> >>>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>>>>> patch to differential. It may attempt to migrate body and title of >>>>>> the initial post, but lets not bother with migrating any review data. >>>>>> >>>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>>>>> patch. This is used for merging small patches. It would not do an >>>>>> automated push. Maybe have "--push" also perform the push? So like >>>>>> if you are on master, then "ghc-hub merge >>>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>>>>> push to master. >>>>>> >>>>>> How does this sound? I like the idea a lot, and would enjoy helping >>>>>> with implementation, time permitting. I could possibly start hacking >>>>>> on it if others give the go ahead of "Yes, lets do that". >>>>>> >>>>>> -Michael >>>>>> >>>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>>>>> Carter Schonwald writes: >>>>>>> >>>>>>>> In writing the following huge wall of text, I had and idea that I think >>>>>>>> many folks would find palatable: >>>>>>>> >>>>>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>>>>> had a mailing list where folks could email the simple / small patches as >>>>>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>>>>> and why it's simple! >>>>>>>> >>>>>>> I completely agree that for small (e.g. documentation) patches our >>>>>>> current system is quite heavy. For this reason I suggested at ICFP that >>>>>>> we simply begin accepting small patches via GitHub pull requests. >>>>>>> Frankly, this is less work for me than merging patches from a mailing >>>>>>> list and I believe many users feel that GitHub is more accessible than a >>>>>>> mailing list. >>>>>>> >>>>>>> The problem of course is what subset of patches do we want to allow to >>>>>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>>>>> I were to write it myself, I would feel comfortable pushing directly to >>>>>>> the tree. >>>>>>> >>>>>>> Then there is the question of what do we do with pull requests opened >>>>>>> which do not satisfy this criterion. In this case I would likely open a >>>>>>> Phabricator Differential with the pull request and close the pull >>>>>>> request with a link to the Diff. In the ideal case this will inspire the >>>>>>> contributor to join the review process on Phabricator; in the worst case >>>>>>> review turns up issues in the patch and the user gives up. Either way, at >>>>>>> least the contributor feels his patch has been seen and given the >>>>>>> attention it deserves. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> - Ben >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mgsloan at gmail.com Wed Sep 28 02:22:13 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 19:22:13 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> Message-ID: Exactly! So we will be using Phabricator for the review process, but with the github PRs you can use plain git. This means that new contributors will only need to learn about phabricator, and arc will be non-mandatory though probably recommended. Glad you like the idea :) -Michael On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg wrote: > So you're suggesting that GitHub would function as a sort of alternate front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly dislike arc, which tries to be too clever for my tastes. Provided the integration works smoothly, I quite like this idea. > > Richard > >> On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote: >> >> You're welcome Richard! I look forward to helping make it happen. In >> the other thread, Alexander Vershilov mentioned that we might instead >> consider the following more straightforward workflow: >> >> 0) Have a bot that watches github for PRs. >> 1) Submit whatever you want to github as a PR. >> 2) It will be automatically closed and migrated to Phabricator. I >> would like it to automatically create a Phabricator account if you do >> not already have one. The message from the bot will tell you about >> this action, and explain how to log in, perhaps even linking to >> resources about Phabricator. >> >> Is this worth it? I think it is for the one-off cases. However, you >> will have to be prepared that this means that people won't have >> arcanist setup, and therefore are less likely to actually iterate on >> their PR. Perhaps we should extend this to the following: >> >> 3) Subsequent pushes to the branch for the PR will update the >> Phabricator differential as if you had pushed via Arcanist. I think >> with this in place, we would have a fully streamlined system that >> allows people to use their familiar GitHub workflows, without needing >> to learn Arcanist. Interactions would then still occur on , of >> course. >> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" >> tool! Could name the bot that, though! >> >> Thoughts? I think it would be great for this to be proposed formally >> soon so that we can make it happen. I am eager to be able to use my >> normal git workflows, as my little experience with Arcanist induced >> some head-scratching. Not the fault of the tool, just a result of >> lack of familiarity. >> >> -Michael >> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg wrote: >>> To sum up, this proposes the following: >>> >>> 1. Allow PRs on GitHub. >>> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks interfacing between GitHub and Phab. This utility would be used only by GHC HQ and not by contributors. >>> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub. >>> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would be issued a polite email explaining how to set up a Phab account to continue to follow their contribution. >>> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted exactly this for a while. >>> >>> Is this worth sending through ghc-proposals? >>> >>> Thanks for volunteering item (2), Michael! >>> >>> Richard >>> >>> -=-=-=-=-=-=-=-=-=-=- >>> Richard A. Eisenberg >>> Asst. Prof. of Computer Science >>> Bryn Mawr College >>> Bryn Mawr, PA, USA >>> cs.brynmawr.edu/~rae >>> >>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty wrote: >>>> >>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about fragmentation of dev attention. >>>> >>>> Manuel >>>> >>>>> Michael Sloan : >>>>> >>>>> Argh, sent too soon. The first paragraph, revised: >>>>> >>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>> times before, GitHub has many users familiar with its interface. By >>>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If >>>>> there is an easy and straightforward process for shifting big patches >>>>> to Phabricator, then people who are regularly contributing via GitHub >>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >>>>> workflow. >>>>> >>>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan wrote: >>>>>> This sounds like an ideal solution, Ben! As has been discussed many >>>>>> times before, GitHub has many users familiar with its interface. By >>>>>> allowing GitHub PRs, the initial contribution >>>>>> >>>>>> I think it would be acceptable for larger GitHub PRs to have some >>>>>> automated boilerplate response. Ideally this would look like: >>>>>> >>>>>> """ >>>>>> Thanks for making this patch! I've turned this into a Phab >>>>>> Differential xxx and closed this PR. Please create a differential >>>>>> account associated with your email address ..." >>>>>> """ >>>>>> >>>>>> The email address can be automatically pulled from commit metadata. >>>>>> If one is absent, then this automated process isn't possible. If it >>>>>> is present and >>>>>> >>>>>> So, I'm imagining a utility that interfaces between both GitHub and >>>>>> Phab,allowing the following commands: >>>>>> >>>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates the >>>>>> patch to differential. It may attempt to migrate body and title of >>>>>> the initial post, but lets not bother with migrating any review data. >>>>>> >>>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >>>>>> patch. This is used for merging small patches. It would not do an >>>>>> automated push. Maybe have "--push" also perform the push? So like >>>>>> if you are on master, then "ghc-hub merge >>>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and >>>>>> push to master. >>>>>> >>>>>> How does this sound? I like the idea a lot, and would enjoy helping >>>>>> with implementation, time permitting. I could possibly start hacking >>>>>> on it if others give the go ahead of "Yes, lets do that". >>>>>> >>>>>> -Michael >>>>>> >>>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari wrote: >>>>>>> Carter Schonwald writes: >>>>>>> >>>>>>>> In writing the following huge wall of text, I had and idea that I think >>>>>>>> many folks would find palatable: >>>>>>>> >>>>>>>> What if simple small patches (such as hypothetical drive by doc patches ) >>>>>>>> had a mailing list where folks could email the simple / small patches as >>>>>>>> email attachments plus a body text that summarizes the patch, what it does, >>>>>>>> and why it's simple! >>>>>>>> >>>>>>> I completely agree that for small (e.g. documentation) patches our >>>>>>> current system is quite heavy. For this reason I suggested at ICFP that >>>>>>> we simply begin accepting small patches via GitHub pull requests. >>>>>>> Frankly, this is less work for me than merging patches from a mailing >>>>>>> list and I believe many users feel that GitHub is more accessible than a >>>>>>> mailing list. >>>>>>> >>>>>>> The problem of course is what subset of patches do we want to allow to >>>>>>> be taken via GitHub. My suggested answer to that is any patch which, if >>>>>>> I were to write it myself, I would feel comfortable pushing directly to >>>>>>> the tree. >>>>>>> >>>>>>> Then there is the question of what do we do with pull requests opened >>>>>>> which do not satisfy this criterion. In this case I would likely open a >>>>>>> Phabricator Differential with the pull request and close the pull >>>>>>> request with a link to the Diff. In the ideal case this will inspire the >>>>>>> contributor to join the review process on Phabricator; in the worst case >>>>>>> review turns up issues in the patch and the user gives up. Either way, at >>>>>>> least the contributor feels his patch has been seen and given the >>>>>>> attention it deserves. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> - Ben >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > From eacameron at gmail.com Wed Sep 28 03:37:49 2016 From: eacameron at gmail.com (Elliot Cameron) Date: Tue, 27 Sep 2016 23:37:49 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: With the "stock option" might I also suggest "OEM"? ;) +1 stock On Tue, Sep 27, 2016 at 10:06 PM, Richard Eisenberg wrote: > +1 on `stock` from me. Though I was all excited to get my class next > semester jazzed for PL work by explaining that I had slipped a new keyword > `bespoke` into a language. :) > > Richard > > On Sep 27, 2016, at 7:55 PM, Ryan Scott wrote: > > > This wouldn't eat up Stock as a data type or type classes or stock in > any other syntactic context right? > > A valid concern! Rest assured, you'd still be able to use "stock" as, say, > a variable in a function, since GHC's parser has a production just for IDs > that have meanings in special contexts. (If you want to win at Haskell > trivia night, the current special IDs are "as", "qualified", "hiding", > "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", > "javascript", and "group" [1]). In my implementation, I make "stock" and > "anyclass" special IDs, so they only become keywords when used after > "deriving". > > Ryan S. > ----- > [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f5767657 > 4d338be1f5:/compiler/parser/Parser.y#l3054 > [2] > > On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> This wouldn't eat up Stock as a data type or type classes or stock in >> any other syntactic context right? >> >> While this term in the finance context hasn't come up in my own work this >> past year, just want to make sure it won't eat a key word piece of name >> space in value or types land >> >> Otherwise : standard or stock all sound good to me. >> >> On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote: >> >>> Sorry to keep changing my mind on this topic, but I'd like to make one >>> last alternate suggestion, which I think surpasses all the previous ones. >>> Joachim proposed that what was called "bespoke", "standard", or "builtin" >>> in the past be called "stock" instead [1]. I like this idea since: >>> >>> 1. "Stock" is a short, instantly recognizable English word, no matter >>> where you live (I think). >>> 2. It conveys the right meaning, as "stock" indicates something >>> straightforward or normal (in contrast to GND and DAC, which do something a >>> bit more novel). "Stock" has other meanings, but in this context I believe >>> it's clear what it indicates. >>> 3. It doesn't have the disadvantages of the other suggestions. Besides >>> the points already covered, Joachim noted that "bespoke" has connotations >>> of giving instances that would be tailor-fit for a datatype (e.g., "ignore >>> field x in the Eq instance, because it is just a cached value that depends >>> on the other"), when in reality, the strategy is far more mechanical than >>> that! >>> >>> Thoughts? >>> >>> Ryan S. >>> ----- >>> [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 >>> >>> On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott >>> wrote: >>> >>>> Hello, everyone! Sorry for not being able to respond to some of the >>>> recent feedback. >>>> >>>> Well, it seems I'm at a bit of an impasse again. I originally changed >>>> "builtin" to "bespoke" because enough GHC devs voiced their >>>> displeasure (ranging from moderate to severe) with "builtin". I hoped >>>> that choosing "bespoke" would strike a happy medium where we could >>>> have a term that (1) reasonably describes its intended purpose, (2) >>>> wouldn't be highly misleading upon an initial glance, and (3) wouldn't >>>> be too off-putting to use as a reserved keyword. >>>> >>>> Unfortunately, I over-estimated how well "bespoke" meets criterion 3, >>>> since several people have _also_ voiced their displeasure with it! >>>> (Again, ranging from moderate to severe.) So we're back to square one, >>>> it seems. I don't want to push this patch without a general feeling of >>>> community consensus, but the patch is complete after all, with the >>>> exception of bikeshedding, so I'd like to try and come up with a >>>> colo(u)r that folks will be happy with so we can proceed and I can >>>> work on other things that need this feature. >>>> >>>> So, instead of "builtin" and "bespoke", I propose reconsidering an >>>> earlier suggestion of Elliot Cameron's: "standard". I had previously >>>> expressed reservations about "standard" before, since I felt it might >>>> be miscontrued as meaning "a Haskell standard" (e.g., the Haskell >>>> Report). But upon further thought, I have actually come to like the >>>> word "standard". Here's why: >>>> >>>> 1. It's simple. "Standard" is recognizable whether you speak American >>>> English, British English, or pretty much any other variant that I'm >>>> aware of. >>>> 2. It has precedent. A GHC error message already uses the phrase >>>> "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we >>>> adopt "standard" as our keyword, then we could endow this phrase with >>>> a more precise meaning. >>>> 3. It reflects history. This deriving strategy (that I'm proposing to >>>> name "standard") was the very first deriving strategy that GHC >>>> supported (to my knowledge), so it makes sense to refer to this >>>> strategy as the "standard" one, since all other strategies were added >>>> later. >>>> 4. It's not too ambiguous. As opposed to say, "default" (which could >>>> be confused with -XDefaultSignatures, i.e., the anyclass strategy), I >>>> think that "standard" has a pretty obvious connotation in the context >>>> of deriving. There is the possibility of misinterpreting "standard" to >>>> refer to the Haskell Report, but that wouldn't be the worst >>>> misconception in the world to make, since several "standard derivable >>>> classes" are actually in the Haskell Report (whereas neither >>>> GeneralizedNewtypeDeriving nor DeriveAnyClass are). >>>> >>>> What does everyone think? >>>> >>>> Ryan S. >>>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Wed Sep 28 06:08:02 2016 From: monkleyon at googlemail.com (MarLinn) Date: Wed, 28 Sep 2016 08:08:02 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: On 2016-09-28 04:06, Richard Eisenberg wrote: > +1 on `stock` from me. Though I was all excited to get my class next > semester jazzed for PL work by explaining that I had slipped a new > keyword `bespoke` into a language. :) Maybe there's still a spot you can slip it in, e.g. bespoke error messages. ;) I agree that "stock" is an acceptable alternative. MarLinn From simonpj at microsoft.com Wed Sep 28 08:36:33 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 28 Sep 2016 08:36:33 +0000 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: Interesting article. Michael suggests using markdown in repo-controlled files rather than a wiki. I can see the force of that. Maybe we should consider it. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 27 September 2016 15:54 To: Simon Peyton Jones Cc: Sven Panne ; ghc-devs Subject: Re: How, precisely, can we improve? I think this is relevant to the dicussion: http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation Alan On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs > wrote: We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/ I didn’t even know about the third of these, but the first two have clearly differentiated goals: • https://wiki.haskell.org/Haskell is about user-facing, and often user-generated, documentation. Guidance about improving performance, programming idioms, tutorials etc. • https://ghc.haskell.org/trac/ghc is about GHC’s implementation, oriented to people who want to understand how GHC works, and how to modify it. I think this separation is actually quite helpful. I agree with what you and others say about the difficulty of keeping wikis organised. But that’s not primarily a technology issue: there is a genuinely difficult challenge here. How do you build and maintain up-to-date, navigable, well-organised information about a large, complex, and rapidly changing artefact like GHC? A wiki is one approach that has the merit that anyone can improve it; control is not centralised. But I’d love there to be other, better solutions. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sven Panne Sent: 27 September 2016 08:46 To: ghc-devs > Subject: Re: How, precisely, can we improve? Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: * We currently have *3* wikis: https://wiki.haskell.org/Haskell https://ghc.haskell.org/trac/ghc https://phabricator.haskell.org/w/ It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org, i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... Cheers, S. _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Sep 28 08:44:08 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 28 Sep 2016 09:44:08 +0100 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> Message-ID: Well, let's be careful here. I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR. Perhaps you could build something that would allow revisions to PRs too... that would be cool. Cheers Simon On 28 September 2016 at 03:22, Michael Sloan wrote: > Exactly! So we will be using Phabricator for the review process, but > with the github PRs you can use plain git. This means that new > contributors will only need to learn about phabricator, and arc will > be non-mandatory though probably recommended. > > Glad you like the idea :) > > -Michael > > On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg > wrote: > > So you're suggesting that GitHub would function as a sort of alternate > front-end to Phab. While I've grown to enjoy Phab quite a bit, I still > strongly dislike arc, which tries to be too clever for my tastes. Provided > the integration works smoothly, I quite like this idea. > > > > Richard > > > >> On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote: > >> > >> You're welcome Richard! I look forward to helping make it happen. In > >> the other thread, Alexander Vershilov mentioned that we might instead > >> consider the following more straightforward workflow: > >> > >> 0) Have a bot that watches github for PRs. > >> 1) Submit whatever you want to github as a PR. > >> 2) It will be automatically closed and migrated to Phabricator. I > >> would like it to automatically create a Phabricator account if you do > >> not already have one. The message from the bot will tell you about > >> this action, and explain how to log in, perhaps even linking to > >> resources about Phabricator. > >> > >> Is this worth it? I think it is for the one-off cases. However, you > >> will have to be prepared that this means that people won't have > >> arcanist setup, and therefore are less likely to actually iterate on > >> their PR. Perhaps we should extend this to the following: > >> > >> 3) Subsequent pushes to the branch for the PR will update the > >> Phabricator differential as if you had pushed via Arcanist. I think > >> with this in place, we would have a fully streamlined system that > >> allows people to use their familiar GitHub workflows, without needing > >> to learn Arcanist. Interactions would then still occur on , of > >> course. > >> > >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" > >> tool! Could name the bot that, though! > >> > >> Thoughts? I think it would be great for this to be proposed formally > >> soon so that we can make it happen. I am eager to be able to use my > >> normal git workflows, as my little experience with Arcanist induced > >> some head-scratching. Not the fault of the tool, just a result of > >> lack of familiarity. > >> > >> -Michael > >> > >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg > wrote: > >>> To sum up, this proposes the following: > >>> > >>> 1. Allow PRs on GitHub. > >>> > >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates > tasks interfacing between GitHub and Phab. This utility would be used only > by GHC HQ and not by contributors. > >>> > >>> 3. Small GitHub PRs can be merged directly, by ghc-hub. > >>> > >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The > contributor would be issued a polite email explaining how to set up a Phab > account to continue to follow their contribution. > >>> > >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve > wanted exactly this for a while. > >>> > >>> Is this worth sending through ghc-proposals? > >>> > >>> Thanks for volunteering item (2), Michael! > >>> > >>> Richard > >>> > >>> -=-=-=-=-=-=-=-=-=-=- > >>> Richard A. Eisenberg > >>> Asst. Prof. of Computer Science > >>> Bryn Mawr College > >>> Bryn Mawr, PA, USA > >>> cs.brynmawr.edu/~rae > >>> > >>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty < > chak at justtesting.org> wrote: > >>>> > >>>> Sounds like a great idea to me and might alleviate SimonM’s concerns > about fragmentation of dev attention. > >>>> > >>>> Manuel > >>>> > >>>>> Michael Sloan : > >>>>> > >>>>> Argh, sent too soon. The first paragraph, revised: > >>>>> > >>>>> This sounds like an ideal solution, Ben! As has been discussed many > >>>>> times before, GitHub has many users familiar with its interface. By > >>>>> allowing GitHub PRs, the initial contribution barrier will be > lowered. If > >>>>> there is an easy and straightforward process for shifting big patches > >>>>> to Phabricator, then people who are regularly contributing via GitHub > >>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist > >>>>> workflow. > >>>>> > >>>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan > wrote: > >>>>>> This sounds like an ideal solution, Ben! As has been discussed many > >>>>>> times before, GitHub has many users familiar with its interface. By > >>>>>> allowing GitHub PRs, the initial contribution > >>>>>> > >>>>>> I think it would be acceptable for larger GitHub PRs to have some > >>>>>> automated boilerplate response. Ideally this would look like: > >>>>>> > >>>>>> """ > >>>>>> Thanks for making this patch! I've turned this into a Phab > >>>>>> Differential xxx and closed this PR. Please create a differential > >>>>>> account associated with your email address ..." > >>>>>> """ > >>>>>> > >>>>>> The email address can be automatically pulled from commit metadata. > >>>>>> If one is absent, then this automated process isn't possible. If it > >>>>>> is present and > >>>>>> > >>>>>> So, I'm imagining a utility that interfaces between both GitHub and > >>>>>> Phab,allowing the following commands: > >>>>>> > >>>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates > the > >>>>>> patch to differential. It may attempt to migrate body and title of > >>>>>> the initial post, but lets not bother with migrating any review > data. > >>>>>> > >>>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the > >>>>>> patch. This is used for merging small patches. It would not do an > >>>>>> automated push. Maybe have "--push" also perform the push? So like > >>>>>> if you are on master, then "ghc-hub merge > >>>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches > and > >>>>>> push to master. > >>>>>> > >>>>>> How does this sound? I like the idea a lot, and would enjoy helping > >>>>>> with implementation, time permitting. I could possibly start > hacking > >>>>>> on it if others give the go ahead of "Yes, lets do that". > >>>>>> > >>>>>> -Michael > >>>>>> > >>>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari > wrote: > >>>>>>> Carter Schonwald writes: > >>>>>>> > >>>>>>>> In writing the following huge wall of text, I had and idea that I > think > >>>>>>>> many folks would find palatable: > >>>>>>>> > >>>>>>>> What if simple small patches (such as hypothetical drive by doc > patches ) > >>>>>>>> had a mailing list where folks could email the simple / small > patches as > >>>>>>>> email attachments plus a body text that summarizes the patch, > what it does, > >>>>>>>> and why it's simple! > >>>>>>>> > >>>>>>> I completely agree that for small (e.g. documentation) patches our > >>>>>>> current system is quite heavy. For this reason I suggested at ICFP > that > >>>>>>> we simply begin accepting small patches via GitHub pull requests. > >>>>>>> Frankly, this is less work for me than merging patches from a > mailing > >>>>>>> list and I believe many users feel that GitHub is more accessible > than a > >>>>>>> mailing list. > >>>>>>> > >>>>>>> The problem of course is what subset of patches do we want to > allow to > >>>>>>> be taken via GitHub. My suggested answer to that is any patch > which, if > >>>>>>> I were to write it myself, I would feel comfortable pushing > directly to > >>>>>>> the tree. > >>>>>>> > >>>>>>> Then there is the question of what do we do with pull requests > opened > >>>>>>> which do not satisfy this criterion. In this case I would likely > open a > >>>>>>> Phabricator Differential with the pull request and close the pull > >>>>>>> request with a link to the Diff. In the ideal case this will > inspire the > >>>>>>> contributor to join the review process on Phabricator; in the > worst case > >>>>>>> review turns up issues in the patch and the user gives up. Either > way, at > >>>>>>> least the contributor feels his patch has been seen and given the > >>>>>>> attention it deserves. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> - Ben > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> ghc-devs mailing list > >>>>>>> ghc-devs at haskell.org > >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>>>>>> > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>>> > >>>> _______________________________________________ > >>>> ghc-devs mailing list > >>>> ghc-devs at haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbouscal at gmail.com Wed Sep 28 10:44:52 2016 From: nbouscal at gmail.com (Nathan Bouscal) Date: Wed, 28 Sep 2016 11:44:52 +0100 Subject: How, precisely, can we improve? In-Reply-To: References: Message-ID: On Mon, Sep 26, 2016 at 2:27 AM, Richard Eisenberg wrote: > > > "Accept PRs on GitHub" *is* an answer to this question, but one we have > revisited several times in recent memory. (I believe https://mail.haskell. > org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) > Perhaps we can revisit this yet again, but it would be great if new > technical content can be injected into the debate. I hope the rejection of > the proposal linked there is not considered "dismissive", as the proposal > generated vigorous debate -- the opposite of dismissiveness. (For what it's > worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no > experience setting up or maintaining infrastructure for an open source > project and have happily deferred to those who have such experience and who > have come out against this idea.) > It may be worth pointing out that one of the most common objections in that debate was GitHub's code review process, and in the time since that process has been completely overhauled . -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Wed Sep 28 12:29:04 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 28 Sep 2016 21:29:04 +0900 Subject: How, precisely, can we improve? In-Reply-To: <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: Apologies if I’m missing context. Potential contributors need information from wiki. I feel current wiki’s problems are following: (a) reachability "Where is the page I need?" (b) outdated pages "Is this page up-to-date?" (c) update method "How Can I update the page?" About (a): It's difficult to find pages they need. Maybe reasons are following: * We have multiple wiki sites. * Desired contents structure is different for each member. So single wiki site is not enough from latter. Therefore, what about "a search system for multiple wiki sites"? About (b): Haskell's evolution is fast. New contributor encounters sometimes outdated pages. But they don't still know how to correct them. Therefore, what about putting "outdated mark" to the page by them? They can easily contribute. And if possible, they send update request with any way. We’ll preferentially update many requested pages. About (c): We have multiple wiki sites. Someone is unfamiliar about them. Github is one of the solutions for new contents. But I don't have idea about this for current contents. Regards, Takenobu 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : > I'm quite leery of using a new site (readthedocs.org), as it creates yet > another platform for contributors to understand. Reducing the number of > platforms has been a fairly clearly-stated goal of these recent > conversations, as I've read it. > > Despite agreeing that wikis are sometimes wonky, I thought of a solid > reason against moving: we lose the Trac integration. A Trac wiki page can > easily link to tickets and individual comments, and can use dynamic > features such as lists of active tickets. These are useful and well-used > features. I don't know what's best here, but thinking about the real loss > associated with moving away from these features gives me pause. > > Richard > > > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: > > > > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: > >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: > >>> Yes, I agree with Michael’s observations in the blog post. However, one > >>> thing that’s easier about a wiki is that the editing process is much > more > >>> lightweight than making a PR. > >>> > >>> But GitHub has a wonderful feature (that I have rarely used) that > >>> mitigates this problem. Viewing a file in GitHub offers a little pencil > >>> icon in the top-right. It allows you to make arbitrary changes in the > >>> file and then automates the construction of a PR. The owner of the file > >>> can then accept the PR very, very easily. If the editor has commit > >>> rights, you can make your edits into a commit right away. No need to > >>> fork, pull and push. > >> > >> Indeed, GitHub also supports git-backed wikis, so you can have nicely > >> rendered and inter-linked pages *and* have the option for web-based or > >> git-based editing. Though, based on my limited experience with GitHub > >> wikis, I wonder if they would scale to the size of GHC's wiki.. > > > > I agree, I don't think GitHub wikis are sufficient for GHC. We've > > tried using GitHub wikis, and found that they were clunkier than just > > having wiki / docs in your repo. GHC would probably want to have a > > separate docs repo, as otherwise the commit history will get filled > > with commits related to proposals, etc. > > > > It may be worth considering a similar approach with the GHC > > documentation. We've had great success in stack with using > > https://readthedocs.org/ . The way this works is that you have a > > branch that readthedocs points at ("stable"), which provides the > > current version to display. I realize that ghc would want to have > > multiple versions of the docs up, but I'm sure that's feasible. > > > > Github itself has pretty nice markdown rendering, and the ability to > > edit directly. Note that there is no GitHub lock-in here - it is just > > a collection of markdown files, organized however you like them. > > > > The risk with such a migration is that the old wiki(s?) don't get > > fully migrated and shut down. If that happens, then information will > > be even more spread out and hard to find. Perhaps we can use pandoc > > to automatically migrate much of the wiki content to markdown? It > > probably will not be a lossfree conversion. > > > >> There's also a tool called gitit (https://github.com/jgm/gitit) that > >> seems to offer the same set of features, but apparently with a more > >> traditional (and I assume customizable) layout. > >> > >> I think having the option for simple, immediate edits or peer-reviewed > >> edits (the peer-review is much more important to me than having an > >> explicitly file-based system) would be a big win. Perhaps there's even a > >> trac module that implements something like this? Then we could decouple > >> it from the question/task of migrating the existing content elsewhere. > >> > >> Eric > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 28 12:32:26 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 28 Sep 2016 12:32:26 +0000 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: Fine with me! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Scott Sent: 28 September 2016 00:13 To: GHC developers Subject: Re: Request for feedback: deriving strategies syntax Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since: 1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that! Thoughts? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott > wrote: Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Wed Sep 28 13:23:18 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 28 Sep 2016 22:23:18 +0900 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: > Therefore, what about "a search system for multiple wiki sites"? sorry, less information. I mean like this. Google search: "dependent haskell site:ghc.haskell.org/trac/ghc/wiki OR site: wiki.haskell.org" Regards, Takenobu 2016-09-28 21:29 GMT+09:00 Takenobu Tani : > Apologies if I’m missing context. > > > > Potential contributors need information from wiki. > > I feel current wiki’s problems are following: > > > > (a) reachability > > "Where is the page I need?" > > > > (b) outdated pages > > "Is this page up-to-date?" > > > > (c) update method > > "How Can I update the page?" > > > > > > About (a): > > > > It's difficult to find pages they need. Maybe reasons are following: > > * We have multiple wiki sites. > > * Desired contents structure is different for each member. > > > > So single wiki site is not enough from latter. > > > > Therefore, what about "a search system for multiple wiki sites"? > > > > > > About (b): > > > > Haskell's evolution is fast. > > New contributor encounters sometimes outdated pages. > > But they don't still know how to correct them. > > > > Therefore, what about putting "outdated mark" to the page by them? > > > > They can easily contribute. > > And if possible, they send update request with any way. > > We’ll preferentially update many requested pages. > > > > > > About (c): > > > > We have multiple wiki sites. Someone is unfamiliar about them. > > Github is one of the solutions for new contents. > > But I don't have idea about this for current contents. > > > > Regards, > > Takenobu > > > > 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : > >> I'm quite leery of using a new site (readthedocs.org), as it creates yet >> another platform for contributors to understand. Reducing the number of >> platforms has been a fairly clearly-stated goal of these recent >> conversations, as I've read it. >> >> Despite agreeing that wikis are sometimes wonky, I thought of a solid >> reason against moving: we lose the Trac integration. A Trac wiki page can >> easily link to tickets and individual comments, and can use dynamic >> features such as lists of active tickets. These are useful and well-used >> features. I don't know what's best here, but thinking about the real loss >> associated with moving away from these features gives me pause. >> >> Richard >> >> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >> > >> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> >>> Yes, I agree with Michael’s observations in the blog post. However, >> one >> >>> thing that’s easier about a wiki is that the editing process is much >> more >> >>> lightweight than making a PR. >> >>> >> >>> But GitHub has a wonderful feature (that I have rarely used) that >> >>> mitigates this problem. Viewing a file in GitHub offers a little >> pencil >> >>> icon in the top-right. It allows you to make arbitrary changes in the >> >>> file and then automates the construction of a PR. The owner of the >> file >> >>> can then accept the PR very, very easily. If the editor has commit >> >>> rights, you can make your edits into a commit right away. No need to >> >>> fork, pull and push. >> >> >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >> >> rendered and inter-linked pages *and* have the option for web-based or >> >> git-based editing. Though, based on my limited experience with GitHub >> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >> > >> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >> > tried using GitHub wikis, and found that they were clunkier than just >> > having wiki / docs in your repo. GHC would probably want to have a >> > separate docs repo, as otherwise the commit history will get filled >> > with commits related to proposals, etc. >> > >> > It may be worth considering a similar approach with the GHC >> > documentation. We've had great success in stack with using >> > https://readthedocs.org/ . The way this works is that you have a >> > branch that readthedocs points at ("stable"), which provides the >> > current version to display. I realize that ghc would want to have >> > multiple versions of the docs up, but I'm sure that's feasible. >> > >> > Github itself has pretty nice markdown rendering, and the ability to >> > edit directly. Note that there is no GitHub lock-in here - it is just >> > a collection of markdown files, organized however you like them. >> > >> > The risk with such a migration is that the old wiki(s?) don't get >> > fully migrated and shut down. If that happens, then information will >> > be even more spread out and hard to find. Perhaps we can use pandoc >> > to automatically migrate much of the wiki content to markdown? It >> > probably will not be a lossfree conversion. >> > >> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >> >> seems to offer the same set of features, but apparently with a more >> >> traditional (and I assume customizable) layout. >> >> >> >> I think having the option for simple, immediate edits or peer-reviewed >> >> edits (the peer-review is much more important to me than having an >> >> explicitly file-based system) would be a big win. Perhaps there's even >> a >> >> trac module that implements something like this? Then we could decouple >> >> it from the question/task of migrating the existing content elsewhere. >> >> >> >> Eric >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Sep 28 13:29:19 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 28 Sep 2016 09:29:19 -0400 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: I like your perspective on this On Wednesday, September 28, 2016, Takenobu Tani wrote: > Apologies if I’m missing context. > > > > Potential contributors need information from wiki. > > I feel current wiki’s problems are following: > > > > (a) reachability > > "Where is the page I need?" > > > > (b) outdated pages > > "Is this page up-to-date?" > > > > (c) update method > > "How Can I update the page?" > > > > > > About (a): > > > > It's difficult to find pages they need. Maybe reasons are following: > > * We have multiple wiki sites. > > * Desired contents structure is different for each member. > > > > So single wiki site is not enough from latter. > > > > Therefore, what about "a search system for multiple wiki sites"? > > > > > > About (b): > > > > Haskell's evolution is fast. > > New contributor encounters sometimes outdated pages. > > But they don't still know how to correct them. > > > > Therefore, what about putting "outdated mark" to the page by them? > > > > They can easily contribute. > > And if possible, they send update request with any way. > > We’ll preferentially update many requested pages. > > > > > > About (c): > > > > We have multiple wiki sites. Someone is unfamiliar about them. > > Github is one of the solutions for new contents. > > But I don't have idea about this for current contents. > > > > Regards, > > Takenobu > > > > 2016-09-28 10:51 GMT+09:00 Richard Eisenberg >: > >> I'm quite leery of using a new site (readthedocs.org), as it creates yet >> another platform for contributors to understand. Reducing the number of >> platforms has been a fairly clearly-stated goal of these recent >> conversations, as I've read it. >> >> Despite agreeing that wikis are sometimes wonky, I thought of a solid >> reason against moving: we lose the Trac integration. A Trac wiki page can >> easily link to tickets and individual comments, and can use dynamic >> features such as lists of active tickets. These are useful and well-used >> features. I don't know what's best here, but thinking about the real loss >> associated with moving away from these features gives me pause. >> >> Richard >> >> > On Sep 27, 2016, at 5:58 PM, Michael Sloan > > wrote: >> > >> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel > > wrote: >> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> >>> Yes, I agree with Michael’s observations in the blog post. However, >> one >> >>> thing that’s easier about a wiki is that the editing process is much >> more >> >>> lightweight than making a PR. >> >>> >> >>> But GitHub has a wonderful feature (that I have rarely used) that >> >>> mitigates this problem. Viewing a file in GitHub offers a little >> pencil >> >>> icon in the top-right. It allows you to make arbitrary changes in the >> >>> file and then automates the construction of a PR. The owner of the >> file >> >>> can then accept the PR very, very easily. If the editor has commit >> >>> rights, you can make your edits into a commit right away. No need to >> >>> fork, pull and push. >> >> >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >> >> rendered and inter-linked pages *and* have the option for web-based or >> >> git-based editing. Though, based on my limited experience with GitHub >> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >> > >> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >> > tried using GitHub wikis, and found that they were clunkier than just >> > having wiki / docs in your repo. GHC would probably want to have a >> > separate docs repo, as otherwise the commit history will get filled >> > with commits related to proposals, etc. >> > >> > It may be worth considering a similar approach with the GHC >> > documentation. We've had great success in stack with using >> > https://readthedocs.org/ . The way this works is that you have a >> > branch that readthedocs points at ("stable"), which provides the >> > current version to display. I realize that ghc would want to have >> > multiple versions of the docs up, but I'm sure that's feasible. >> > >> > Github itself has pretty nice markdown rendering, and the ability to >> > edit directly. Note that there is no GitHub lock-in here - it is just >> > a collection of markdown files, organized however you like them. >> > >> > The risk with such a migration is that the old wiki(s?) don't get >> > fully migrated and shut down. If that happens, then information will >> > be even more spread out and hard to find. Perhaps we can use pandoc >> > to automatically migrate much of the wiki content to markdown? It >> > probably will not be a lossfree conversion. >> > >> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >> >> seems to offer the same set of features, but apparently with a more >> >> traditional (and I assume customizable) layout. >> >> >> >> I think having the option for simple, immediate edits or peer-reviewed >> >> edits (the peer-review is much more important to me than having an >> >> explicitly file-based system) would be a big win. Perhaps there's even >> a >> >> trac module that implements something like this? Then we could decouple >> >> it from the question/task of migrating the existing content elsewhere. >> >> >> >> Eric >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Sep 28 16:06:32 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 28 Sep 2016 12:06:32 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> Message-ID: <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> Simon Marlow writes: > Well, let's be careful here. I like the idea, but it's not a complete > solution for people who don't want to use arc, because you can't revise a > patch after submission in response to reviews, you would have to open a new > PR. > I have considered building something like this in the past since posting series of patches via Arc is exceedingly painful. It's not entirely clear what it would look like, but I was thinking the tool would, 1. take a branch of commits, for instance, A -- B -- C -- D -- E -- F -- origin/master ^ HEAD 2. allow you to decide how to break it into Diffs. for instance, new diff A B new diff C D E new diff F which would produce three diffs: * one containing commits A and B * one containing commits C, D, and E * another containing F 3. run `arc diff` to upload each Diff to Phabricator, setting up the appropriate dependency structure between the created Diffs 4. rewrite history of your branch to add an annotation to the commit messages saying which diff each belongs to You are then free to continue modifying and even rebasing your branch and later the tool can be used to update the diffs from the current state of your branch. The tool could do this automatically, reconstructing where each commit belongs from the annotations added during upload. That being said, I ultimately decided it would be easier to just continue carrying out this workflow by hand considering I don't post large series of patches *that* often. I'm also a bit more eager to squash now than I used to be, in part due to the pain of submitting fine-grained patch sets. On the whole I do wish that Phabricator were more Git-like. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mgsloan at gmail.com Wed Sep 28 20:03:55 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 28 Sep 2016 13:03:55 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> Message-ID: On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote: > That being said, I ultimately decided it would be easier to just > continue carrying out this workflow by hand considering I don't post > large series of patches *that* often. I'm also a bit more eager to > squash now than I used to be, in part due to the pain of submitting > fine-grained patch sets. On the whole I do wish that Phabricator were > more Git-like. Indeed, I do not know the details of phab / arc, but when encountering them, the workflow seemed unlike ordinary git workflows. It felt like it is working hard to implement an atypical git workflow, and learning this new workflow takes work. From the perspective of a contributor, it seemed strange since git's usual workflows are wildly successful and popular. Granted, it is easy for people to screw those up too, such as by using "git pull" instead of "git pull --rebase" orso. -Michael From moritz at lichtzwerge.de Thu Sep 29 00:44:45 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 08:44:45 +0800 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> Message-ID: I don't think Phabricator tries to be or emulate fit in any way; I think this is a misconception. The way I see it, phabricator is just a glorified diff-dump, which is supposed to work with any VCS in principle. All that arc essentially does is, compute the diff from an offset (e.g. master) to the current HEAD and upload that to a new or existing (--update) differential. It also adds some meta information about the range, such that arc patch supposedly knows into which commit to apply the patch to. By default arc does not preserve history if memory serves me right but uses the summary field exclusively for the commit message. Hence you can go wild on your local branches (use what ever development model suites your needs) and get one final squashed commit with an extensive summary. In my experience much of the frustration with arc comes from trying to use arc as git and grafting a hit workflow onto arc. To me, git is the organizing (branches and commits) and snapshotting solution to keep me sane and allow for experimentations without fear of loosing anything. Arc however is the tool that allows me to take my local mess and manage it as a reviewable patch I can update from my local tree if need be. Cheers, Moritz Sent from my iPhone > On 29 Sep 2016, at 4:03 AM, Michael Sloan wrote: > >> On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote: >> That being said, I ultimately decided it would be easier to just >> continue carrying out this workflow by hand considering I don't post >> large series of patches *that* often. I'm also a bit more eager to >> squash now than I used to be, in part due to the pain of submitting >> fine-grained patch sets. On the whole I do wish that Phabricator were >> more Git-like. > > Indeed, I do not know the details of phab / arc, but when encountering > them, the workflow seemed unlike ordinary git workflows. It felt like > it is working hard to implement an atypical git workflow, and learning > this new workflow takes work. From the perspective of a contributor, > it seemed strange since git's usual workflows are wildly successful > and popular. Granted, it is easy for people to screw those up too, > such as by using "git pull" instead of "git pull --rebase" orso. > > -Michael > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Thu Sep 29 01:37:07 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 28 Sep 2016 21:37:07 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> Message-ID: <87a8erebb0.fsf@ben-laptop.smart-cactus.org> Moritz Angermann writes: > I don't think Phabricator tries to be or emulate fit in any way; I > think this is a misconception. The way I see it, phabricator is just a > glorified diff-dump, which is supposed to work with any VCS in > principle. > > All that arc essentially does is, compute the diff from an offset > (e.g. master) to the current HEAD and upload that to a new or existing > (--update) differential. It also adds some meta information about the > range, such that arc patch supposedly knows into which commit to apply > the patch to. > > By default arc does not preserve history if memory serves me right but > uses the summary field exclusively for the commit message. > > Hence you can go wild on your local branches (use what ever > development model suites your needs) and get one final squashed commit > with an extensive summary. > Sure, but this leads to generally unreviewable patches IMHO. In order to stay sane I generally split up my work into a set of standalone patches with git rebase and then create a Diff of each of these commits. Phabricator supports this by having a notion of dependencies between Diffs, but arcanist has no sensible scheme for taking a branch and conveniently producing a series of Diffs. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From moritz at lichtzwerge.de Thu Sep 29 02:27:36 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 10:27:36 +0800 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87a8erebb0.fsf@ben-laptop.smart-cactus.org> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> Message-ID: >> Hence you can go wild on your local branches (use what ever >> development model suites your needs) and get one final squashed commit >> with an extensive summary. >> > Sure, but this leads to generally unreviewable patches IMHO. In order to > stay sane I generally split up my work into a set of standalone patches > with git rebase and then create a Diff of each of these commits. > Phabricator supports this by having a notion of dependencies between > Diffs, but arcanist has no sensible scheme for taking a branch and > conveniently producing a series of Diffs. Yes, this has been a constant source of frustration for us as well. Dealing with dependent diffs is just plain painful with arc :( What I usually end up doing, and I assume that’s what you are describing is: Turning A -- B -- C -- D -- E -- F -- origin/master ^ HEAD into: branch B1: E -- F -- origin/master / branch B2: C -- D / branch B3: A -- B and producing three diffs: $ git checkout E $ arc diff origin/master # producing D1 $ git checkout C $ arc diff B1 # adding “depends on D1" into the summary field $ git checkout A $ git diff B2 # adding “depends on D2” into the summary field and then rebase B2 and B3 when changes to D1 on B1 are necessary. Running `arc patch` with dependent diffs often resulted in trouble; this seems to be getting better with the staging areas though. So clearly we can see there are drawbacks. All I wanted to say in the previous email was essentially that from my experience frustration with arc often came from trying to make arc be git. Cheers, Moritz From chak at justtesting.org Thu Sep 29 02:30:50 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 29 Sep 2016 12:30:50 +1000 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> Message-ID: <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Michael’s arguments are compelling. Manuel > Simon Peyton Jones via ghc-devs : > > Interesting article. Michael suggests using markdown in repo-controlled files rather than a wiki. I can see the force of that. Maybe we should consider it. > > Simon >   <> > From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > Sent: 27 September 2016 15:54 > To: Simon Peyton Jones > Cc: Sven Panne ; ghc-devs > Subject: Re: How, precisely, can we improve? > > I think this is relevant to the dicussion: http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation > Alan > > On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs > wrote: > We currently have *3* wikis: > > https://wiki.haskell.org/Haskell > https://ghc.haskell.org/trac/ghc > https://phabricator.haskell.org/w/ > > I didn’t even know about the third of these, but the first two have clearly differentiated goals: > · https://wiki.haskell.org/Haskell is about user-facing, and often user-generated, documentation. Guidance about improving performance, programming idioms, tutorials etc. > > · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, oriented to people who want to understand how GHC works, and how to modify it. > > > I think this separation is actually quite helpful. > > I agree with what you and others say about the difficulty of keeping wikis organised. But that’s not primarily a technology issue: there is a genuinely difficult challenge here. How do you build and maintain up-to-date, navigable, well-organised information about a large, complex, and rapidly changing artefact like GHC? A wiki is one approach that has the merit that anyone can improve it; control is not centralised. But I’d love there to be other, better solutions. > > Simon >   <> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org ] On Behalf Of Sven Panne > Sent: 27 September 2016 08:46 > To: ghc-devs > > Subject: Re: How, precisely, can we improve? > > Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: > > * We currently have *3* wikis: > > https://wiki.haskell.org/Haskell > https://ghc.haskell.org/trac/ghc > https://phabricator.haskell.org/w/ > > > It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. > > * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. > > * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org , i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. > > All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. > > Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... > > Cheers, > S. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Thu Sep 29 02:43:41 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 28 Sep 2016 22:43:41 -0400 Subject: How, precisely, can we improve? In-Reply-To: <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Message-ID: Here's a pre-proposal (which could be formalized into a proper proposal) to address the wiki discussion: - Configure the wiki to display the date of last edit prominently. - If the date of last edit is sufficiently long ago (1 year?) loudly warn the reader that the content may be out-of-date. And that's it! I think that solves the problem. The reason this solves the problem is that the ghc-proposals process is already en route to providing the git-backed files that have been floated as the alternative to a wiki. Thus, language features, etc., will be memorialized through the ghc-proposals process. As I understand it, that process already requires the proposal to be updated to a description of the feature as the feature is implemented and refined. We will be left with a nice git repo of feature descriptions. The wiki can remain as a place for less permanent discussions (such as pre-proposals) or pages that use the nice dynamic features of Trac. Is this proposal possible to implement? Does it solve the wiki problem sufficiently? Sometimes, solutions are easy. :) Richard > On Sep 28, 2016, at 10:30 PM, Manuel M T Chakravarty wrote: > > Michael’s arguments are compelling. > > Manuel > >> Simon Peyton Jones via ghc-devs >: >> >> Interesting article. Michael suggests using markdown in repo-controlled files rather than a wiki. I can see the force of that. Maybe we should consider it. >> >> Simon >>   <> >> From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com ] >> Sent: 27 September 2016 15:54 >> To: Simon Peyton Jones > >> Cc: Sven Panne >; ghc-devs > >> Subject: Re: How, precisely, can we improve? >> >> I think this is relevant to the dicussion: http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation >> Alan >> >> On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs > wrote: >> We currently have *3* wikis: >> >> https://wiki.haskell.org/Haskell >> https://ghc.haskell.org/trac/ghc >> https://phabricator.haskell.org/w/ >> >> I didn’t even know about the third of these, but the first two have clearly differentiated goals: >> · https://wiki.haskell.org/Haskell is about user-facing, and often user-generated, documentation. Guidance about improving performance, programming idioms, tutorials etc. >> >> · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, oriented to people who want to understand how GHC works, and how to modify it. >> >> >> I think this separation is actually quite helpful. >> >> I agree with what you and others say about the difficulty of keeping wikis organised. But that’s not primarily a technology issue: there is a genuinely difficult challenge here. How do you build and maintain up-to-date, navigable, well-organised information about a large, complex, and rapidly changing artefact like GHC? A wiki is one approach that has the merit that anyone can improve it; control is not centralised. But I’d love there to be other, better solutions. >> >> Simon >>   <> >> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org ] On Behalf Of Sven Panne >> Sent: 27 September 2016 08:46 >> To: ghc-devs > >> Subject: Re: How, precisely, can we improve? >> >> Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: >> >> * We currently have *3* wikis: >> >> https://wiki.haskell.org/Haskell >> https://ghc.haskell.org/trac/ghc >> https://phabricator.haskell.org/w/ >> >> >> It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. >> >> * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. >> >> * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org , i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. >> >> All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. >> >> Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... >> >> Cheers, >> S. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Thu Sep 29 02:46:18 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 10:46:18 +0800 Subject: How, precisely, can we improve? In-Reply-To: <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Message-ID: I’d like to see a git based ascii markup based tool as well. Simon pointed out that there are inherent complexities coming with wikis. I don’t think changeing those would be necessarily solved with such an approach. As Takenobu pointed out, a core part of the interface should be search. Looking at another big wiki, many of us have probably used, wikipedia: I don’t think I’m alone in querying wikipedia through duckduckgo or google using “wiki ”. However, this requires me to know what I’m searching for or at least have an idea what I’m looking for, and only from there I can discover new things. For an alien technology, where I might not actually *know* the terms I’m looking for, some form ob browsing by some kind of “Tag” could be helpful to narrow down what I’m looking for. With a new approach I would like to see Search and Tagging being central features to the UI. Cheers, Moritz > On Sep 29, 2016, at 10:30 AM, Manuel M T Chakravarty wrote: > > Michael’s arguments are compelling. > > Manuel > >> Simon Peyton Jones via ghc-devs : >> >> Interesting article. Michael suggests using markdown in repo-controlled files rather than a wiki. I can see the force of that. Maybe we should consider it. >> >> Simon >> >> From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] >> Sent: 27 September 2016 15:54 >> To: Simon Peyton Jones >> Cc: Sven Panne ; ghc-devs >> Subject: Re: How, precisely, can we improve? >> >> I think this is relevant to the dicussion: http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation >> >> Alan >> >> On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs wrote: >> We currently have *3* wikis: >> >> https://wiki.haskell.org/Haskell >> https://ghc.haskell.org/trac/ghc >> https://phabricator.haskell.org/w/ >> >> I didn’t even know about the third of these, but the first two have clearly differentiated goals: >> · https://wiki.haskell.org/Haskell is about user-facing, and often user-generated, documentation. Guidance about improving performance, programming idioms, tutorials etc. >> >> · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, oriented to people who want to understand how GHC works, and how to modify it. >> >> >> I think this separation is actually quite helpful. >> >> I agree with what you and others say about the difficulty of keeping wikis organised. But that’s not primarily a technology issue: there is a genuinely difficult challenge here. How do you build and maintain up-to-date, navigable, well-organised information about a large, complex, and rapidly changing artefact like GHC? A wiki is one approach that has the merit that anyone can improve it; control is not centralised. But I’d love there to be other, better solutions. >> >> Simon >> >> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sven Panne >> Sent: 27 September 2016 08:46 >> To: ghc-devs >> Subject: Re: How, precisely, can we improve? >> >> Just a remark from my side: The documentation/tooling landscape is a bit more fragmented than it needs to be IMHO. More concretely: >> >> * We currently have *3* wikis: >> >> https://wiki.haskell.org/Haskell >> https://ghc.haskell.org/trac/ghc >> https://phabricator.haskell.org/w/ >> >> >> It's clear to me that they have different emphases and different origins, but in the end this results in valuable information being scattered around. Wikis in general are already quite hard to navigate (due to their inherent chaotic "structure"), so having 3 of them makes things even worse. It would be great to have *the* single Haskell Wiki directly on haskell.org in an easily reachable place. >> >> * To be an active Haskell community member, you need quite a few different logins: Some for the Wikis mentioned above, one for Hackage, another one for Phabricator, perhaps an SSH key here and there... Phabricator is a notable exception: It accepts your GitHub/Google+/... logins. It would be great if the other parts of the Haskell ecosystem accepted those kinds of logins, too. >> >> * https://haskell-lang.org/ has great stuff on it, but its relationship to haskell.org is unclear to me. Their "documentation" sub-pages look extremely similar, but haskell-lang.org has various (great!) tutorials and a nice overview of common libraries on it. From an external POV it seems to me that haskell-lang.org should be seamlessly integrated into haskell.org, i.e. merged into it. Having an endless sea of links on haskell.org is not the same as having content nicely integrated into it, sorted by topic, etc. >> >> All those points are not show-stoppers for people trying to be more active in the Haskell community, but nevertheless they make things harder than they need to be, so I fear we lose people quite early. To draw an analogy: As probably everybody who actively monitors their web shop/customer site knows, even seemlingy small things moves customers totally away from your site. One unclear payment form? The vast majority of your potential customers aborts the purchase immediately and forever. One confusing interstitial web page? Say goodbye to lots of people. One hard-to-find button/link? A forced login/new account? => Commercial disaster, etc. etc. >> >> Furthermore, I'm quite aware of the technical/social difficulties of my proposals, but that shouldn't let us stop trying to improve... >> >> Cheers, >> S. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ————————————————— Moritz Angermann +49 170 54 33 0 74 moritz at lichtzwerge.de lichtzwerge GmbH Raiffeisenstr. 8 93185 Michelsneukirchen Amtsgericht Regensburg HRB 14723 Geschäftsführung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From cma at bitemyapp.com Thu Sep 29 03:01:49 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 28 Sep 2016 22:01:49 -0500 Subject: How, precisely, can we improve? In-Reply-To: <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Message-ID: I tend to agree, particularly as it would permit automated processing and conversion of the documentation much more readily than a website really ever has. I don't think I've ever used a public wiki that enforced broken link checking, whereas that's a sundry CI check for static markdown documentation. Markdown files can become anything somebody wants, including a web server hosting it as HTML documentation that looks however they want. This approach doesn't prevent separating docs for the community vs. implementors either. Just a subdirectory if you wanted. On Wed, Sep 28, 2016 at 9:30 PM, Manuel M T Chakravarty wrote: > Michael’s arguments are compelling. > > Manuel > > Simon Peyton Jones via ghc-devs : > > Interesting article. Michael suggests using markdown in repo-controlled > files rather than a wiki. I can see the force of that. Maybe we should > consider it. > > Simon > > From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > Sent: 27 September 2016 15:54 > To: Simon Peyton Jones > Cc: Sven Panne ; ghc-devs > Subject: Re: How, precisely, can we improve? > > > I think this is relevant to the dicussion: > http://www.yesodweb.com/blog/2015/08/thoughts-on-documentation > > Alan > > On Tue, Sep 27, 2016 at 4:22 PM, Simon Peyton Jones via ghc-devs > wrote: > > We currently have *3* wikis: > > https://wiki.haskell.org/Haskell > https://ghc.haskell.org/trac/ghc > https://phabricator.haskell.org/w/ > > I didn’t even know about the third of these, but the first two have clearly > differentiated goals: > > · https://wiki.haskell.org/Haskell is about user-facing, and often > user-generated, documentation. Guidance about improving performance, > programming idioms, tutorials etc. > > · https://ghc.haskell.org/trac/ghc is about GHC’s implementation, > oriented to people who want to understand how GHC works, and how to modify > it. > > > I think this separation is actually quite helpful. > > I agree with what you and others say about the difficulty of keeping wikis > organised. But that’s not primarily a technology issue: there is a genuinely > difficult challenge here. How do you build and maintain up-to-date, > navigable, well-organised information about a large, complex, and rapidly > changing artefact like GHC? A wiki is one approach that has the merit that > anyone can improve it; control is not centralised. But I’d love there to be > other, better solutions. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sven Panne > Sent: 27 September 2016 08:46 > To: ghc-devs > Subject: Re: How, precisely, can we improve? > > Just a remark from my side: The documentation/tooling landscape is a bit > more fragmented than it needs to be IMHO. More concretely: > > * We currently have *3* wikis: > > https://wiki.haskell.org/Haskell > https://ghc.haskell.org/trac/ghc > https://phabricator.haskell.org/w/ > > > It's clear to me that they have different emphases and different > origins, but in the end this results in valuable information being scattered > around. Wikis in general are already quite hard to navigate (due to their > inherent chaotic "structure"), so having 3 of them makes things even worse. > It would be great to have *the* single Haskell Wiki directly on haskell.org > in an easily reachable place. > > * To be an active Haskell community member, you need quite a few > different logins: Some for the Wikis mentioned above, one for Hackage, > another one for Phabricator, perhaps an SSH key here and there... > Phabricator is a notable exception: It accepts your GitHub/Google+/... > logins. It would be great if the other parts of the Haskell ecosystem > accepted those kinds of logins, too. > > * https://haskell-lang.org/ has great stuff on it, but its relationship > to haskell.org is unclear to me. Their "documentation" sub-pages look > extremely similar, but haskell-lang.org has various (great!) tutorials and a > nice overview of common libraries on it. From an external POV it seems to me > that haskell-lang.org should be seamlessly integrated into haskell.org, i.e. > merged into it. Having an endless sea of links on haskell.org is not the > same as having content nicely integrated into it, sorted by topic, etc. > > All those points are not show-stoppers for people trying to be more active > in the Haskell community, but nevertheless they make things harder than they > need to be, so I fear we lose people quite early. To draw an analogy: As > probably everybody who actively monitors their web shop/customer site knows, > even seemlingy small things moves customers totally away from your site. One > unclear payment form? The vast majority of your potential customers aborts > the purchase immediately and forever. One confusing interstitial web page? > Say goodbye to lots of people. One hard-to-find button/link? A forced > login/new account? => Commercial disaster, etc. etc. > > Furthermore, I'm quite aware of the technical/social difficulties of my > proposals, but that shouldn't let us stop trying to improve... > > Cheers, > S. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From spam at scientician.net Thu Sep 29 03:55:16 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 29 Sep 2016 05:55:16 +0200 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Message-ID: On 2016-09-29 04:43, Richard Eisenberg wrote: > Here's a pre-proposal (which could be formalized into a proper proposal) > to address the wiki discussion: > > - Configure the wiki to display the date of last edit prominently. > > - If the date of last edit is sufficiently long ago (1 year?) loudly > warn the reader that the content may be out-of-date. > I see at least one major issue with this: Search engines don't care if you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial problem that search engines keep linking out of date material just because such material tends to be linked more (simply because of age). There are few tings as infuriating as going through a bunch of search results and getting pages from 10 years ago. Regards, From moritz at lichtzwerge.de Thu Sep 29 04:08:00 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 12:08:00 +0800 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> Message-ID: <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> Just a quick note: Google provides the “Date range” filter found under search options. This allows to narrow down the date range. > On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: > > On 2016-09-29 04:43, Richard Eisenberg wrote: >> Here's a pre-proposal (which could be formalized into a proper proposal) >> to address the wiki discussion: >> >> - Configure the wiki to display the date of last edit prominently. >> >> - If the date of last edit is sufficiently long ago (1 year?) loudly >> warn the reader that the content may be out-of-date. >> > > I see at least one major issue with this: Search engines don't care if > you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial > problem that search engines keep linking out of date material just > because such material tends to be linked more (simply because of age). > > There are few tings as infuriating as going through a bunch of search > results and getting pages from 10 years ago. > > Regards, > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From cma at bitemyapp.com Thu Sep 29 04:24:45 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 28 Sep 2016 23:24:45 -0500 Subject: How, precisely, can we improve? In-Reply-To: <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> Message-ID: Why not just do the better thing to begin with rather than obligating people to think to use this feature? Most, even those who know it's an option, aren't going to think to do this in the heat of trying to track down an answer to something. On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann wrote: > Just a quick note: Google provides the “Date range” filter found under > search options. This allows to narrow down the date range. > >> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: >> >> On 2016-09-29 04:43, Richard Eisenberg wrote: >>> Here's a pre-proposal (which could be formalized into a proper proposal) >>> to address the wiki discussion: >>> >>> - Configure the wiki to display the date of last edit prominently. >>> >>> - If the date of last edit is sufficiently long ago (1 year?) loudly >>> warn the reader that the content may be out-of-date. >>> >> >> I see at least one major issue with this: Search engines don't care if >> you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial >> problem that search engines keep linking out of date material just >> because such material tends to be linked more (simply because of age). >> >> There are few tings as infuriating as going through a bunch of search >> results and getting pages from 10 years ago. >> >> Regards, >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Chris Allen Currently working on http://haskellbook.com From moritz at lichtzwerge.de Thu Sep 29 04:33:26 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 12:33:26 +0800 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> Message-ID: <1E59D074-642E-4C4A-A750-156E2A07A804@lichtzwerge.de> Chris, I’m all in favor of a better system! My only intention was to point to a solution that might help with the current system, right now. I’ve come to use that feature quite frequently even outside of this specific use case, as many of the results are often full of interesting yet stale information. Anyhow, I don’t want to obligate anyone to do anything, and if this was perceived that way, I’m truly sorry. Cheers, Moritz > On Sep 29, 2016, at 12:24 PM, Christopher Allen wrote: > > Why not just do the better thing to begin with rather than obligating > people to think to use this feature? Most, even those who know it's an > option, aren't going to think to do this in the heat of trying to > track down an answer to something. > > On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann > wrote: >> Just a quick note: Google provides the “Date range” filter found under >> search options. This allows to narrow down the date range. >> >>> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: >>> >>> On 2016-09-29 04:43, Richard Eisenberg wrote: >>>> Here's a pre-proposal (which could be formalized into a proper proposal) >>>> to address the wiki discussion: >>>> >>>> - Configure the wiki to display the date of last edit prominently. >>>> >>>> - If the date of last edit is sufficiently long ago (1 year?) loudly >>>> warn the reader that the content may be out-of-date. >>>> >>> >>> I see at least one major issue with this: Search engines don't care if >>> you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial >>> problem that search engines keep linking out of date material just >>> because such material tends to be linked more (simply because of age). >>> >>> There are few tings as infuriating as going through a bunch of search >>> results and getting pages from 10 years ago. >>> >>> Regards, >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > Chris Allen > Currently working on http://haskellbook.com From cma at bitemyapp.com Thu Sep 29 04:37:35 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 28 Sep 2016 23:37:35 -0500 Subject: How, precisely, can we improve? In-Reply-To: <1E59D074-642E-4C4A-A750-156E2A07A804@lichtzwerge.de> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> <1E59D074-642E-4C4A-A750-156E2A07A804@lichtzwerge.de> Message-ID: Makes sense, no problem! I think my main personal complaints with docs have been: Poor discoverability — neither wikis nor search solve this, I want a dir listing. Slow search — almost every wiki has slow search. bouncing out to google is annoying. just let me grep. Broken links — this is particularly annoying as unis like to shut down student accounts hosting papers. I had to do some archaeology on an obscure Chinese FTP server to find some of Don Stewart's papers and slides recently. I believe there can be a convincing solution to all of this and more. On Wed, Sep 28, 2016 at 11:33 PM, Moritz Angermann wrote: > Chris, > > I’m all in favor of a better system! My only intention was to point > to a solution that might help with the current system, right now. > > I’ve come to use that feature quite frequently even outside of this > specific use case, as many of the results are often full of > interesting yet stale information. > > Anyhow, I don’t want to obligate anyone to do anything, and if this > was perceived that way, I’m truly sorry. > > Cheers, > Moritz > >> On Sep 29, 2016, at 12:24 PM, Christopher Allen wrote: >> >> Why not just do the better thing to begin with rather than obligating >> people to think to use this feature? Most, even those who know it's an >> option, aren't going to think to do this in the heat of trying to >> track down an answer to something. >> >> On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann >> wrote: >>> Just a quick note: Google provides the “Date range” filter found under >>> search options. This allows to narrow down the date range. >>> >>>> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: >>>> >>>> On 2016-09-29 04:43, Richard Eisenberg wrote: >>>>> Here's a pre-proposal (which could be formalized into a proper proposal) >>>>> to address the wiki discussion: >>>>> >>>>> - Configure the wiki to display the date of last edit prominently. >>>>> >>>>> - If the date of last edit is sufficiently long ago (1 year?) loudly >>>>> warn the reader that the content may be out-of-date. >>>>> >>>> >>>> I see at least one major issue with this: Search engines don't care if >>>> you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial >>>> problem that search engines keep linking out of date material just >>>> because such material tends to be linked more (simply because of age). >>>> >>>> There are few tings as infuriating as going through a bunch of search >>>> results and getting pages from 10 years ago. >>>> >>>> Regards, >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com > -- Chris Allen Currently working on http://haskellbook.com From moritz at lichtzwerge.de Thu Sep 29 05:01:06 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 13:01:06 +0800 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> <1E59D074-642E-4C4A-A750-156E2A07A804@lichtzwerge.de> Message-ID: <081336C3-3630-4A70-8F2D-D7FC449E6D74@lichtzwerge.de> That is an interesting way to interact with the wiki, I had never thought about using it that way! So what you are proposing is a version controlled text based documentation system, precisely you can download the wiki and use your own cli/editor finding/indexing tools on it? This would of course be covered by almost any of the static side generation tools that work off of git I assume. I’m still uncertain how to accommodate Richards dynamic features into this? And I believe he’s not the only one who relies on them? Regarding the stale wiki page issue, scanning the history for files could potentially provide a list of “old” items, and eventually one could just delete them from master (automatically?) > On Sep 29, 2016, at 12:37 PM, Christopher Allen wrote: > > Makes sense, no problem! > > I think my main personal complaints with docs have been: > > Poor discoverability — neither wikis nor search solve this, I want a > dir listing. > > Slow search — almost every wiki has slow search. bouncing out to > google is annoying. just let me grep. > > Broken links — this is particularly annoying as unis like to shut down > student accounts hosting papers. I had to do some archaeology on an > obscure Chinese FTP server to find some of Don Stewart's papers and > slides recently. > > I believe there can be a convincing solution to all of this and more. > > On Wed, Sep 28, 2016 at 11:33 PM, Moritz Angermann > wrote: >> Chris, >> >> I’m all in favor of a better system! My only intention was to point >> to a solution that might help with the current system, right now. >> >> I’ve come to use that feature quite frequently even outside of this >> specific use case, as many of the results are often full of >> interesting yet stale information. >> >> Anyhow, I don’t want to obligate anyone to do anything, and if this >> was perceived that way, I’m truly sorry. >> >> Cheers, >> Moritz >> >>> On Sep 29, 2016, at 12:24 PM, Christopher Allen wrote: >>> >>> Why not just do the better thing to begin with rather than obligating >>> people to think to use this feature? Most, even those who know it's an >>> option, aren't going to think to do this in the heat of trying to >>> track down an answer to something. >>> >>> On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann >>> wrote: >>>> Just a quick note: Google provides the “Date range” filter found under >>>> search options. This allows to narrow down the date range. >>>> >>>>> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: >>>>> >>>>> On 2016-09-29 04:43, Richard Eisenberg wrote: >>>>>> Here's a pre-proposal (which could be formalized into a proper proposal) >>>>>> to address the wiki discussion: >>>>>> >>>>>> - Configure the wiki to display the date of last edit prominently. >>>>>> >>>>>> - If the date of last edit is sufficiently long ago (1 year?) loudly >>>>>> warn the reader that the content may be out-of-date. >>>>>> >>>>> >>>>> I see at least one major issue with this: Search engines don't care if >>>>> you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial >>>>> problem that search engines keep linking out of date material just >>>>> because such material tends to be linked more (simply because of age). >>>>> >>>>> There are few tings as infuriating as going through a bunch of search >>>>> results and getting pages from 10 years ago. >>>>> >>>>> Regards, >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com From cma at bitemyapp.com Thu Sep 29 05:10:30 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 29 Sep 2016 00:10:30 -0500 Subject: How, precisely, can we improve? In-Reply-To: <081336C3-3630-4A70-8F2D-D7FC449E6D74@lichtzwerge.de> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <25429C13-B4FC-4571-A23B-AB61E1F08CDB@justtesting.org> <0DE0C4A5-013B-406A-80A1-94DA104ABBB4@lichtzwerge.de> <1E59D074-642E-4C4A-A750-156E2A07A804@lichtzwerge.de> <081336C3-3630-4A70-8F2D-D7FC449E6D74@lichtzwerge.de> Message-ID: I was thinking of what Richard was describing as shoring up the insufficiencies of the existing infra, rather than something to be directly targeted in any possible alternative. Hypothetically could be made automatic or a git hook, if you wanted things like last-modified timestamps injected into the documents. I don't have strong feelings on this other than to say that there are simpler ways to represent and serve documentation that let people use whatever layer on top they want. For example, if someone _did_ want the readthedocs specifically, they could mirror the repo into the RTD branch and point it at the docs directory or similar. Git repos mean not being blocked by trac slowness/downtime, the content being more widely mirrored, all kinds of nice to be potentially had. On Thu, Sep 29, 2016 at 12:01 AM, Moritz Angermann wrote: > That is an interesting way to interact with the wiki, I had > never thought about using it that way! > > So what you are proposing is a version controlled text based > documentation system, precisely you can download the wiki and > use your own cli/editor finding/indexing tools on it? > > This would of course be covered by almost any of the static > side generation tools that work off of git I assume. > > I’m still uncertain how to accommodate Richards dynamic features > into this? And I believe he’s not the only one who relies on them? > > Regarding the stale wiki page issue, scanning the history for > files could potentially provide a list of “old” items, and > eventually one could just delete them from master (automatically?) > > >> On Sep 29, 2016, at 12:37 PM, Christopher Allen wrote: >> >> Makes sense, no problem! >> >> I think my main personal complaints with docs have been: >> >> Poor discoverability — neither wikis nor search solve this, I want a >> dir listing. >> >> Slow search — almost every wiki has slow search. bouncing out to >> google is annoying. just let me grep. >> >> Broken links — this is particularly annoying as unis like to shut down >> student accounts hosting papers. I had to do some archaeology on an >> obscure Chinese FTP server to find some of Don Stewart's papers and >> slides recently. >> >> I believe there can be a convincing solution to all of this and more. >> >> On Wed, Sep 28, 2016 at 11:33 PM, Moritz Angermann >> wrote: >>> Chris, >>> >>> I’m all in favor of a better system! My only intention was to point >>> to a solution that might help with the current system, right now. >>> >>> I’ve come to use that feature quite frequently even outside of this >>> specific use case, as many of the results are often full of >>> interesting yet stale information. >>> >>> Anyhow, I don’t want to obligate anyone to do anything, and if this >>> was perceived that way, I’m truly sorry. >>> >>> Cheers, >>> Moritz >>> >>>> On Sep 29, 2016, at 12:24 PM, Christopher Allen wrote: >>>> >>>> Why not just do the better thing to begin with rather than obligating >>>> people to think to use this feature? Most, even those who know it's an >>>> option, aren't going to think to do this in the heat of trying to >>>> track down an answer to something. >>>> >>>> On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann >>>> wrote: >>>>> Just a quick note: Google provides the “Date range” filter found under >>>>> search options. This allows to narrow down the date range. >>>>> >>>>>> On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: >>>>>> >>>>>> On 2016-09-29 04:43, Richard Eisenberg wrote: >>>>>>> Here's a pre-proposal (which could be formalized into a proper proposal) >>>>>>> to address the wiki discussion: >>>>>>> >>>>>>> - Configure the wiki to display the date of last edit prominently. >>>>>>> >>>>>>> - If the date of last edit is sufficiently long ago (1 year?) loudly >>>>>>> warn the reader that the content may be out-of-date. >>>>>>> >>>>>> >>>>>> I see at least one major issue with this: Search engines don't care if >>>>>> you write "THIS MAY BE OUT OF DATE" on the page. It's a perennial >>>>>> problem that search engines keep linking out of date material just >>>>>> because such material tends to be linked more (simply because of age). >>>>>> >>>>>> There are few tings as infuriating as going through a bunch of search >>>>>> results and getting pages from 10 years ago. >>>>>> >>>>>> Regards, >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>>> -- >>>> Chris Allen >>>> Currently working on http://haskellbook.com >>> >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com > -- Chris Allen Currently working on http://haskellbook.com From eric at seidel.io Thu Sep 29 05:58:27 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 28 Sep 2016 22:58:27 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <87a8erebb0.fsf@ben-laptop.smart-cactus.org> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> Message-ID: <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: > Moritz Angermann writes: > > > All that arc essentially does is, compute the diff from an offset > > (e.g. master) to the current HEAD and upload that to a new or existing > > (--update) differential. It also adds some meta information about the > > range, such that arc patch supposedly knows into which commit to apply > > the patch to. > > > Sure, but this leads to generally unreviewable patches IMHO. In order to > stay sane I generally split up my work into a set of standalone patches > with git rebase and then create a Diff of each of these commits. > Phabricator supports this by having a notion of dependencies between > Diffs, but arcanist has no sensible scheme for taking a branch and > conveniently producing a series of Diffs. I completely understand how this would be frustrating for core contributors (more specifically for people submitting large patches), but for new or casual contributors it's actually quite freeing. I don't have to worry about how messy my local history gets, because arc will throw it all away regardless! It absolves me of an extra responsibility, and lowers the barrier to contributing. It would be nice to support both workflows though :) From dct25-561bs at mythic-beasts.com Thu Sep 29 06:12:48 2016 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Thu, 29 Sep 2016 07:12:48 +0100 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> Message-ID: Hi, You can alter the content of a GitHub PR after its initial creation. The semantics of a PR is "please merge my branch named B into your repo" where the branch B is a mutable pointer to a commit. A workflow I've used a few times is to craft a nice sequence of commits for review and, once accepted, updated the PR to a squashed version of the same. Not that I like squashing, but that's what upstream wanted. In fact, the mutability of a PR is something you have to be a bit careful about on GitHub as you may not be accepting what you reviewed. It doesn't seem very easy to see how the branch has changed over time: there is no audit facility. I'd have thought the tooling discussed earlier should be able to take care of this problem. Cheers, On 28 Sep 2016 09:44, "Simon Marlow" wrote: > Well, let's be careful here. I like the idea, but it's not a complete > solution for people who don't want to use arc, because you can't revise a > patch after submission in response to reviews, you would have to open a new > PR. > > Perhaps you could build something that would allow revisions to PRs too... > that would be cool. > > Cheers > Simon > > On 28 September 2016 at 03:22, Michael Sloan wrote: > >> Exactly! So we will be using Phabricator for the review process, but >> with the github PRs you can use plain git. This means that new >> contributors will only need to learn about phabricator, and arc will >> be non-mandatory though probably recommended. >> >> Glad you like the idea :) >> >> -Michael >> >> On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg >> wrote: >> > So you're suggesting that GitHub would function as a sort of alternate >> front-end to Phab. While I've grown to enjoy Phab quite a bit, I still >> strongly dislike arc, which tries to be too clever for my tastes. Provided >> the integration works smoothly, I quite like this idea. >> > >> > Richard >> > >> >> On Sep 27, 2016, at 5:32 PM, Michael Sloan wrote: >> >> >> >> You're welcome Richard! I look forward to helping make it happen. In >> >> the other thread, Alexander Vershilov mentioned that we might instead >> >> consider the following more straightforward workflow: >> >> >> >> 0) Have a bot that watches github for PRs. >> >> 1) Submit whatever you want to github as a PR. >> >> 2) It will be automatically closed and migrated to Phabricator. I >> >> would like it to automatically create a Phabricator account if you do >> >> not already have one. The message from the bot will tell you about >> >> this action, and explain how to log in, perhaps even linking to >> >> resources about Phabricator. >> >> >> >> Is this worth it? I think it is for the one-off cases. However, you >> >> will have to be prepared that this means that people won't have >> >> arcanist setup, and therefore are less likely to actually iterate on >> >> their PR. Perhaps we should extend this to the following: >> >> >> >> 3) Subsequent pushes to the branch for the PR will update the >> >> Phabricator differential as if you had pushed via Arcanist. I think >> >> with this in place, we would have a fully streamlined system that >> >> allows people to use their familiar GitHub workflows, without needing >> >> to learn Arcanist. Interactions would then still occur on , of >> >> course. >> >> >> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub" >> >> tool! Could name the bot that, though! >> >> >> >> Thoughts? I think it would be great for this to be proposed formally >> >> soon so that we can make it happen. I am eager to be able to use my >> >> normal git workflows, as my little experience with Arcanist induced >> >> some head-scratching. Not the fault of the tool, just a result of >> >> lack of familiarity. >> >> >> >> -Michael >> >> >> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg < >> rae at cs.brynmawr.edu> wrote: >> >>> To sum up, this proposes the following: >> >>> >> >>> 1. Allow PRs on GitHub. >> >>> >> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates >> tasks interfacing between GitHub and Phab. This utility would be used only >> by GHC HQ and not by contributors. >> >>> >> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub. >> >>> >> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The >> contributor would be issued a polite email explaining how to set up a Phab >> account to continue to follow their contribution. >> >>> >> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve >> wanted exactly this for a while. >> >>> >> >>> Is this worth sending through ghc-proposals? >> >>> >> >>> Thanks for volunteering item (2), Michael! >> >>> >> >>> Richard >> >>> >> >>> -=-=-=-=-=-=-=-=-=-=- >> >>> Richard A. Eisenberg >> >>> Asst. Prof. of Computer Science >> >>> Bryn Mawr College >> >>> Bryn Mawr, PA, USA >> >>> cs.brynmawr.edu/~rae >> >>> >> >>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty < >> chak at justtesting.org> wrote: >> >>>> >> >>>> Sounds like a great idea to me and might alleviate SimonM’s concerns >> about fragmentation of dev attention. >> >>>> >> >>>> Manuel >> >>>> >> >>>>> Michael Sloan : >> >>>>> >> >>>>> Argh, sent too soon. The first paragraph, revised: >> >>>>> >> >>>>> This sounds like an ideal solution, Ben! As has been discussed many >> >>>>> times before, GitHub has many users familiar with its interface. By >> >>>>> allowing GitHub PRs, the initial contribution barrier will be >> lowered. If >> >>>>> there is an easy and straightforward process for shifting big >> patches >> >>>>> to Phabricator, then people who are regularly contributing via >> GitHub >> >>>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist >> >>>>> workflow. >> >>>>> >> >>>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan >> wrote: >> >>>>>> This sounds like an ideal solution, Ben! As has been discussed >> many >> >>>>>> times before, GitHub has many users familiar with its interface. >> By >> >>>>>> allowing GitHub PRs, the initial contribution >> >>>>>> >> >>>>>> I think it would be acceptable for larger GitHub PRs to have some >> >>>>>> automated boilerplate response. Ideally this would look like: >> >>>>>> >> >>>>>> """ >> >>>>>> Thanks for making this patch! I've turned this into a Phab >> >>>>>> Differential xxx and closed this PR. Please create a differential >> >>>>>> account associated with your email address ..." >> >>>>>> """ >> >>>>>> >> >>>>>> The email address can be automatically pulled from commit metadata. >> >>>>>> If one is absent, then this automated process isn't possible. If >> it >> >>>>>> is present and >> >>>>>> >> >>>>>> So, I'm imagining a utility that interfaces between both GitHub and >> >>>>>> Phab,allowing the following commands: >> >>>>>> >> >>>>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1" - migrates >> the >> >>>>>> patch to differential. It may attempt to migrate body and title of >> >>>>>> the initial post, but lets not bother with migrating any review >> data. >> >>>>>> >> >>>>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1" - merges the >> >>>>>> patch. This is used for merging small patches. It would not do an >> >>>>>> automated push. Maybe have "--push" also perform the push? So >> like >> >>>>>> if you are on master, then "ghc-hub merge >> >>>>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches >> and >> >>>>>> push to master. >> >>>>>> >> >>>>>> How does this sound? I like the idea a lot, and would enjoy >> helping >> >>>>>> with implementation, time permitting. I could possibly start >> hacking >> >>>>>> on it if others give the go ahead of "Yes, lets do that". >> >>>>>> >> >>>>>> -Michael >> >>>>>> >> >>>>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari >> wrote: >> >>>>>>> Carter Schonwald writes: >> >>>>>>> >> >>>>>>>> In writing the following huge wall of text, I had and idea that >> I think >> >>>>>>>> many folks would find palatable: >> >>>>>>>> >> >>>>>>>> What if simple small patches (such as hypothetical drive by doc >> patches ) >> >>>>>>>> had a mailing list where folks could email the simple / small >> patches as >> >>>>>>>> email attachments plus a body text that summarizes the patch, >> what it does, >> >>>>>>>> and why it's simple! >> >>>>>>>> >> >>>>>>> I completely agree that for small (e.g. documentation) patches our >> >>>>>>> current system is quite heavy. For this reason I suggested at >> ICFP that >> >>>>>>> we simply begin accepting small patches via GitHub pull requests. >> >>>>>>> Frankly, this is less work for me than merging patches from a >> mailing >> >>>>>>> list and I believe many users feel that GitHub is more accessible >> than a >> >>>>>>> mailing list. >> >>>>>>> >> >>>>>>> The problem of course is what subset of patches do we want to >> allow to >> >>>>>>> be taken via GitHub. My suggested answer to that is any patch >> which, if >> >>>>>>> I were to write it myself, I would feel comfortable pushing >> directly to >> >>>>>>> the tree. >> >>>>>>> >> >>>>>>> Then there is the question of what do we do with pull requests >> opened >> >>>>>>> which do not satisfy this criterion. In this case I would likely >> open a >> >>>>>>> Phabricator Differential with the pull request and close the pull >> >>>>>>> request with a link to the Diff. In the ideal case this will >> inspire the >> >>>>>>> contributor to join the review process on Phabricator; in the >> worst case >> >>>>>>> review turns up issues in the patch and the user gives up. Either >> way, at >> >>>>>>> least the contributor feels his patch has been seen and given the >> >>>>>>> attention it deserves. >> >>>>>>> >> >>>>>>> Cheers, >> >>>>>>> >> >>>>>>> - Ben >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> ghc-devs mailing list >> >>>>>>> ghc-devs at haskell.org >> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>>>>>> >> >>>>> _______________________________________________ >> >>>>> ghc-devs mailing list >> >>>>> ghc-devs at haskell.org >> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>>> >> >>>> _______________________________________________ >> >>>> ghc-devs mailing list >> >>>> ghc-devs at haskell.org >> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>> >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Sep 29 07:10:44 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 29 Sep 2016 09:10:44 +0200 Subject: How, precisely, can we improve? In-Reply-To: <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> (Richard Eisenberg's message of "Tue, 27 Sep 2016 21:51:22 -0400") References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: <87twcz9o5n.fsf@gmail.com> On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote: [...] > Despite agreeing that wikis are sometimes wonky, I thought of a solid > reason against moving: we lose the Trac integration. A Trac wiki page > can easily link to tickets and individual comments, and can use > dynamic features such as lists of active tickets. These are useful and > well-used features. I don't know what's best here, but thinking about > the real loss associated with moving away from these features gives me > pause. I'd like to emphasize this point; Trac's main strength, design philosophy, and selling point is its tight integration between SCM, Wiki and Issue tracking and resulting synergies (same markup features, extensions, syntax usable seamless), whereas the issue tracking part is its strongest feature. If you rip away its Wiki (and replace it by something decoupled/non-integrated as e.g. GitHub's Git-backed Wiki[1]), you weaken it to the point where it becomes quite harder to argue to keep Trac at all. It's already sub-optimal we spread discussions/information across Trac and Phabricator (you often have to read both, the Diff discussions and the associated Trac ticket discussion to get the full picture); I doubt a 3rd more or less isolated tool which weakens cohesion would improve things. [1]: Personally, I consider GitHub's Wiki quite weak and inconvenient to use. It's stylesheet is not as optimised as Trac's and structuring the content is also significantly worse than with Trac. And finally GH-flavoured Markdown is very limiting compared to Trac's rich extensible wiki syntax; Github's Wiki doesn't even recognize #123 or Git-shas like 993d20a2e9b8fb29a (and then provide mouse-over hoover texts with a title of the respective referenced commit or ticket); you have to paste full urls and manually include a title. So IMO Github's wiki is not suitable for GHC's use at all. A highly customized/forked Gitit instance, however, may be a more reasonable alternative, but then the question is who is gonna customize, implement and maintain it. Or we can drop the idea of a wiki altogether, and go for statically generated docs. Then we could just keep the wiki-content as restructedText (which btw is more expressive and extensible than .md) and have sphinx generated output. But then that's a totally different medium compared to a Wiki... However, I'm still missing a compelling reason in this discussion to justify the cost of changing the status-quo. From alan.zimm at gmail.com Thu Sep 29 07:19:31 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 29 Sep 2016 09:19:31 +0200 Subject: How, precisely, can we improve? In-Reply-To: <87twcz9o5n.fsf@gmail.com> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> <87twcz9o5n.fsf@gmail.com> Message-ID: For me the biggest problem is that each of the three Wiki's has a different markup syntax. So the mental motivation to do anything is tempered by having to look up everything to make sure you are using the right markup for *this* Wiki. Reducing it to one, wherever it is, would help a lot. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Thu Sep 29 08:10:48 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 29 Sep 2016 16:10:48 +0800 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> <87twcz9o5n.fsf@gmail.com> Message-ID: <797117BE-FB83-4FC4-BC84-D54E504A486D@lichtzwerge.de> Friends, after the recent discussion here and on #ghc, I’ve taken the liberty to extract a small part of this into a proposal[1]. In essence this does not cover *all* of the wiki, but the commentary and documentation part, after Herbert mentioned that would be something he could see happening. So let’s see if we can make this happen! Cheers, Moritz -- [1]: https://github.com/ghc-proposals/ghc-proposals/pull/10 From mgsloan at gmail.com Thu Sep 29 10:05:08 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Thu, 29 Sep 2016 03:05:08 -0700 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> Message-ID: On Wednesday, September 28, 2016, Eric Seidel wrote: > On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: > > Moritz Angermann > writes: > > > > > All that arc essentially does is, compute the diff from an offset > > > (e.g. master) to the current HEAD and upload that to a new or existing > > > (--update) differential. It also adds some meta information about the > > > range, such that arc patch supposedly knows into which commit to apply > > > the patch to. > > > > > Sure, but this leads to generally unreviewable patches IMHO. In order to > > stay sane I generally split up my work into a set of standalone patches > > with git rebase and then create a Diff of each of these commits. > > Phabricator supports this by having a notion of dependencies between > > Diffs, but arcanist has no sensible scheme for taking a branch and > > conveniently producing a series of Diffs. > > I completely understand how this would be frustrating for core > contributors (more specifically for people submitting large patches), > but for new or casual contributors it's actually quite freeing. I don't > have to worry about how messy my local history gets, because arc will > throw it all away regardless! It absolves me of an extra responsibility, > and lowers the barrier to contributing. I dislike this workflow because I am already used to doing a lot of git rebasing / amending / auto squashing. So using arc means taking away my ability to write multi commit stories of how the change was crafted. For large changes there are often multiple logical inter related steps. Squashing them into one big commit makes it much harder to review. I can easily do that myself by marking everything as squash in a rebase. It feels like arcanist is just taking away power, not giving it (note i have not used it much - voice of a newbie here) I am beginning to change my feelings on this, away from thinking of GitHub as an auxilliary source of didferentials. Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used. -Michael > > It would be nice to support both workflows though :) > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Thu Sep 29 11:37:29 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 29 Sep 2016 20:37:29 +0900 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: Hi Carter, Thank you very much :) We love haskell, Takenobu 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > I like your perspective on this > > > On Wednesday, September 28, 2016, Takenobu Tani > wrote: > >> Apologies if I’m missing context. >> >> >> >> Potential contributors need information from wiki. >> >> I feel current wiki’s problems are following: >> >> >> >> (a) reachability >> >> "Where is the page I need?" >> >> >> >> (b) outdated pages >> >> "Is this page up-to-date?" >> >> >> >> (c) update method >> >> "How Can I update the page?" >> >> >> >> >> >> About (a): >> >> >> >> It's difficult to find pages they need. Maybe reasons are following: >> >> * We have multiple wiki sites. >> >> * Desired contents structure is different for each member. >> >> >> >> So single wiki site is not enough from latter. >> >> >> >> Therefore, what about "a search system for multiple wiki sites"? >> >> >> >> >> >> About (b): >> >> >> >> Haskell's evolution is fast. >> >> New contributor encounters sometimes outdated pages. >> >> But they don't still know how to correct them. >> >> >> >> Therefore, what about putting "outdated mark" to the page by them? >> >> >> >> They can easily contribute. >> >> And if possible, they send update request with any way. >> >> We’ll preferentially update many requested pages. >> >> >> >> >> >> About (c): >> >> >> >> We have multiple wiki sites. Someone is unfamiliar about them. >> >> Github is one of the solutions for new contents. >> >> But I don't have idea about this for current contents. >> >> >> >> Regards, >> >> Takenobu >> >> >> >> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >> >>> I'm quite leery of using a new site (readthedocs.org), as it creates >>> yet another platform for contributors to understand. Reducing the number of >>> platforms has been a fairly clearly-stated goal of these recent >>> conversations, as I've read it. >>> >>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>> reason against moving: we lose the Trac integration. A Trac wiki page can >>> easily link to tickets and individual comments, and can use dynamic >>> features such as lists of active tickets. These are useful and well-used >>> features. I don't know what's best here, but thinking about the real loss >>> associated with moving away from these features gives me pause. >>> >>> Richard >>> >>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >>> > >>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>> one >>> >>> thing that’s easier about a wiki is that the editing process is much >>> more >>> >>> lightweight than making a PR. >>> >>> >>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>> pencil >>> >>> icon in the top-right. It allows you to make arbitrary changes in the >>> >>> file and then automates the construction of a PR. The owner of the >>> file >>> >>> can then accept the PR very, very easily. If the editor has commit >>> >>> rights, you can make your edits into a commit right away. No need to >>> >>> fork, pull and push. >>> >> >>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>> >> rendered and inter-linked pages *and* have the option for web-based or >>> >> git-based editing. Though, based on my limited experience with GitHub >>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>> > >>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>> > tried using GitHub wikis, and found that they were clunkier than just >>> > having wiki / docs in your repo. GHC would probably want to have a >>> > separate docs repo, as otherwise the commit history will get filled >>> > with commits related to proposals, etc. >>> > >>> > It may be worth considering a similar approach with the GHC >>> > documentation. We've had great success in stack with using >>> > https://readthedocs.org/ . The way this works is that you have a >>> > branch that readthedocs points at ("stable"), which provides the >>> > current version to display. I realize that ghc would want to have >>> > multiple versions of the docs up, but I'm sure that's feasible. >>> > >>> > Github itself has pretty nice markdown rendering, and the ability to >>> > edit directly. Note that there is no GitHub lock-in here - it is just >>> > a collection of markdown files, organized however you like them. >>> > >>> > The risk with such a migration is that the old wiki(s?) don't get >>> > fully migrated and shut down. If that happens, then information will >>> > be even more spread out and hard to find. Perhaps we can use pandoc >>> > to automatically migrate much of the wiki content to markdown? It >>> > probably will not be a lossfree conversion. >>> > >>> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >>> >> seems to offer the same set of features, but apparently with a more >>> >> traditional (and I assume customizable) layout. >>> >> >>> >> I think having the option for simple, immediate edits or peer-reviewed >>> >> edits (the peer-review is much more important to me than having an >>> >> explicitly file-based system) would be a big win. Perhaps there's >>> even a >>> >> trac module that implements something like this? Then we could >>> decouple >>> >> it from the question/task of migrating the existing content elsewhere. >>> >> >>> >> Eric >>> >> _______________________________________________ >>> >> ghc-devs mailing list >>> >> ghc-devs at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > ghc-devs at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Thu Sep 29 14:20:35 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 29 Sep 2016 09:20:35 -0500 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> Message-ID: >Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used. Many problems are caused by letting your inner tinkerer/genius tailor dictate how things should be dealt with. Better to cut the gordian knot. I think Michael's right. On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote: > > > On Wednesday, September 28, 2016, Eric Seidel wrote: >> >> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: >> > Moritz Angermann writes: >> > >> > > All that arc essentially does is, compute the diff from an offset >> > > (e.g. master) to the current HEAD and upload that to a new or existing >> > > (--update) differential. It also adds some meta information about the >> > > range, such that arc patch supposedly knows into which commit to apply >> > > the patch to. >> > > >> > Sure, but this leads to generally unreviewable patches IMHO. In order to >> > stay sane I generally split up my work into a set of standalone patches >> > with git rebase and then create a Diff of each of these commits. >> > Phabricator supports this by having a notion of dependencies between >> > Diffs, but arcanist has no sensible scheme for taking a branch and >> > conveniently producing a series of Diffs. >> >> I completely understand how this would be frustrating for core >> contributors (more specifically for people submitting large patches), >> but for new or casual contributors it's actually quite freeing. I don't >> have to worry about how messy my local history gets, because arc will >> throw it all away regardless! It absolves me of an extra responsibility, >> and lowers the barrier to contributing. > > > I dislike this workflow because I am already used to doing a lot of git > rebasing / amending / auto squashing. So using arc means taking away my > ability to write multi commit stories of how the change was crafted. For > large changes there are often multiple logical inter related steps. > Squashing them into one big commit makes it much harder to review. I can > easily do that myself by marking everything as squash in a rebase. It feels > like arcanist is just taking away power, not giving it (note i have not used > it much - voice of a newbie here) > > I am beginning to change my feelings on this, away from thinking of GitHub > as an auxilliary source of didferentials. Instead perhaps GitHub's new > review system may be the way forward for GHC. It allows you to easily use > git in the way it's meant to be used. > > -Michael > >> >> >> It would be nice to support both workflows though :) >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From ben at well-typed.com Thu Sep 29 17:54:57 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 29 Sep 2016 13:54:57 -0400 Subject: GHC 8.0.2 status Message-ID: <8760peeglq.fsf@ben-laptop.smart-cactus.org> Hello everyone, The week before ICFP I was able to get the ghc-8.0 branch ready for an 8.0.2 release, which I intended to cut this week. In the intervening time an additional rather serious issue was reported affected Mac OS X Sierra (#12479). Since this issue affects the usability of GHC on the new OS X release, we'll be deferring the 8.0.2 release until it has been resolved. While there appears to be an actionable path forward on this ticket, we will need someone with an affected machine and an understanding of GHC's use of dynamic linking to step up to implement. Otherwise it looks like the release will be delayed at least until October 9, when darchon has time to have a look. Sorry to be the bearer of bad news! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From rae at cs.brynmawr.edu Thu Sep 29 18:55:55 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 29 Sep 2016 14:55:55 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> Message-ID: <0AE28D3A-01E7-426F-8D31-F56642E43C79@cs.brynmawr.edu> I have tried to gather the ideas from this thread into a formal proposal: https://github.com/ghc-proposals/ghc-proposals/pull/11 Please feel free to make suggestions to improve this, especially if I've captured anyone's contributions incorrectly. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 29, 2016, at 10:20 AM, Christopher Allen wrote: > >> Instead perhaps GitHub's new review system may be the way forward for GHC. It allows you to easily use git in the way it's meant to be used. > > Many problems are caused by letting your inner tinkerer/genius tailor > dictate how things should be dealt with. Better to cut the gordian > knot. I think Michael's right. > > On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan wrote: >> >> >> On Wednesday, September 28, 2016, Eric Seidel wrote: >>> >>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: >>>> Moritz Angermann writes: >>>> >>>>> All that arc essentially does is, compute the diff from an offset >>>>> (e.g. master) to the current HEAD and upload that to a new or existing >>>>> (--update) differential. It also adds some meta information about the >>>>> range, such that arc patch supposedly knows into which commit to apply >>>>> the patch to. >>>>> >>>> Sure, but this leads to generally unreviewable patches IMHO. In order to >>>> stay sane I generally split up my work into a set of standalone patches >>>> with git rebase and then create a Diff of each of these commits. >>>> Phabricator supports this by having a notion of dependencies between >>>> Diffs, but arcanist has no sensible scheme for taking a branch and >>>> conveniently producing a series of Diffs. >>> >>> I completely understand how this would be frustrating for core >>> contributors (more specifically for people submitting large patches), >>> but for new or casual contributors it's actually quite freeing. I don't >>> have to worry about how messy my local history gets, because arc will >>> throw it all away regardless! It absolves me of an extra responsibility, >>> and lowers the barrier to contributing. >> >> >> I dislike this workflow because I am already used to doing a lot of git >> rebasing / amending / auto squashing. So using arc means taking away my >> ability to write multi commit stories of how the change was crafted. For >> large changes there are often multiple logical inter related steps. >> Squashing them into one big commit makes it much harder to review. I can >> easily do that myself by marking everything as squash in a rebase. It feels >> like arcanist is just taking away power, not giving it (note i have not used >> it much - voice of a newbie here) >> >> I am beginning to change my feelings on this, away from thinking of GitHub >> as an auxilliary source of didferentials. Instead perhaps GitHub's new >> review system may be the way forward for GHC. It allows you to easily use >> git in the way it's meant to be used. >> >> -Michael >> >>> >>> >>> It would be nice to support both workflows though :) >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at cs.brynmawr.edu Thu Sep 29 19:14:18 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 29 Sep 2016 15:14:18 -0400 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: <73702D9C-F495-462C-8220-ECCE08B62AAB@cs.brynmawr.edu> I've spent some time thinking about how and what to synthesize from this conversation. Moritz has captured much of these ideas in the proposal he submitted. Thanks. But that proposal tackles only one part of the problem: what to do in the future. It does not address the insufficiencies of the wiki as it now stands, and these drawbacks seem to be the dangling fibers of this thread. Two specific complaints are that (1) search engines still find out-of-date documentation and (2) the wiki is not discoverable. I agree with both of these, but I can't think of any (easy) way to help either one. For (1), the "obvious" solution is to pull old pages. However, old pages still serve as useful documentary evidence when we need to revisit a decision made in the past. I think simply deleting out-of-date pages may lose useful info. Could we remove the pages from the wiki but keep them somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? I wouldn't want to keep it somewhere private, lest it be unavailable to the person that needs it. I think clearly labeling out-of-date info as such is the best compromise. For (2), there is an index to the wiki: https://ghc.haskell.org/trac/ghc/wiki/TitleIndex It's long and rambly, but may be of use. I agree that grepping would be nice. Does anyone know if there is a way to extract plaintext from a Trac wiki? I agree that making such a feature available would be helpful. In the future, though, even a git-backed collection will run into discoverability problems, unless someone continually keeps it organized. (It will be greppable, though.) As to the point of shoring up existing infra vs. looking more broadly: I suppose I am interesting in shoring up the existing infra, but I'm considering "existing infra" to include all the platforms I'm aware of. This explicitly includes the idea of dropping, say, Trac entirely and moving exclusively to GitHub. I think that would be a terrible idea, but it's in scope in my thinking. What's *not* in scope (in my thinking) is the idea of creating new tools that do exactly what we want. We're all developers and can imagine wonderful things, but wonderful things do not come cheaply, and we are but poor. So I'm at a loss of what to do about these remaining fibers. Concrete suggestions, anyone? Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 29, 2016, at 7:37 AM, Takenobu Tani wrote: > > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald >: > I like your perspective on this > > > On Wednesday, September 28, 2016, Takenobu Tani > wrote: > Apologies if I’m missing context. > > > Potential contributors need information from wiki. > > I feel current wiki’s problems are following: > > > (a) reachability > > "Where is the page I need?" > > > (b) outdated pages > > "Is this page up-to-date?" > > > (c) update method > > "How Can I update the page?" > > > > About (a): > > > It's difficult to find pages they need. Maybe reasons are following: > > * We have multiple wiki sites. > > * Desired contents structure is different for each member. > > > So single wiki site is not enough from latter. > > > Therefore, what about "a search system for multiple wiki sites"? > > > > About (b): > > > Haskell's evolution is fast. > > New contributor encounters sometimes outdated pages. > > But they don't still know how to correct them. > > > Therefore, what about putting "outdated mark" to the page by them? > > > They can easily contribute. > > And if possible, they send update request with any way. > > We’ll preferentially update many requested pages. > > > > About (c): > > > We have multiple wiki sites. Someone is unfamiliar about them. > > Github is one of the solutions for new contents. > > But I don't have idea about this for current contents. > > > Regards, > > Takenobu > > > > 2016-09-28 10:51 GMT+09:00 Richard Eisenberg >: > I'm quite leery of using a new site (readthedocs.org ), as it creates yet another platform for contributors to understand. Reducing the number of platforms has been a fairly clearly-stated goal of these recent conversations, as I've read it. > > Despite agreeing that wikis are sometimes wonky, I thought of a solid reason against moving: we lose the Trac integration. A Trac wiki page can easily link to tickets and individual comments, and can use dynamic features such as lists of active tickets. These are useful and well-used features. I don't know what's best here, but thinking about the real loss associated with moving away from these features gives me pause. > > Richard > > > On Sep 27, 2016, at 5:58 PM, Michael Sloan > wrote: > > > > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel > wrote: > >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: > >>> Yes, I agree with Michael’s observations in the blog post. However, one > >>> thing that’s easier about a wiki is that the editing process is much more > >>> lightweight than making a PR. > >>> > >>> But GitHub has a wonderful feature (that I have rarely used) that > >>> mitigates this problem. Viewing a file in GitHub offers a little pencil > >>> icon in the top-right. It allows you to make arbitrary changes in the > >>> file and then automates the construction of a PR. The owner of the file > >>> can then accept the PR very, very easily. If the editor has commit > >>> rights, you can make your edits into a commit right away. No need to > >>> fork, pull and push. > >> > >> Indeed, GitHub also supports git-backed wikis, so you can have nicely > >> rendered and inter-linked pages *and* have the option for web-based or > >> git-based editing. Though, based on my limited experience with GitHub > >> wikis, I wonder if they would scale to the size of GHC's wiki.. > > > > I agree, I don't think GitHub wikis are sufficient for GHC. We've > > tried using GitHub wikis, and found that they were clunkier than just > > having wiki / docs in your repo. GHC would probably want to have a > > separate docs repo, as otherwise the commit history will get filled > > with commits related to proposals, etc. > > > > It may be worth considering a similar approach with the GHC > > documentation. We've had great success in stack with using > > https://readthedocs.org/ . The way this works is that you have a > > branch that readthedocs points at ("stable"), which provides the > > current version to display. I realize that ghc would want to have > > multiple versions of the docs up, but I'm sure that's feasible. > > > > Github itself has pretty nice markdown rendering, and the ability to > > edit directly. Note that there is no GitHub lock-in here - it is just > > a collection of markdown files, organized however you like them. > > > > The risk with such a migration is that the old wiki(s?) don't get > > fully migrated and shut down. If that happens, then information will > > be even more spread out and hard to find. Perhaps we can use pandoc > > to automatically migrate much of the wiki content to markdown? It > > probably will not be a lossfree conversion. > > > >> There's also a tool called gitit (https://github.com/jgm/gitit ) that > >> seems to offer the same set of features, but apparently with a more > >> traditional (and I assume customizable) layout. > >> > >> I think having the option for simple, immediate edits or peer-reviewed > >> edits (the peer-review is much more important to me than having an > >> explicitly file-based system) would be a big win. Perhaps there's even a > >> trac module that implements something like this? Then we could decouple > >> it from the question/task of migrating the existing content elsewhere. > >> > >> Eric > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org <> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org <> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org <> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at tweag.io Thu Sep 29 20:55:40 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Thu, 29 Sep 2016 22:55:40 +0200 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: <0AE28D3A-01E7-426F-8D31-F56642E43C79@cs.brynmawr.edu> References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> <0AE28D3A-01E7-426F-8D31-F56642E43C79@cs.brynmawr.edu> Message-ID: Hi Richard! thanks for creating the pull request with a full proposal. You beat me to it - tried writing up much the same before stopping for dinner, essentially capturing just one of the points in Moritz's earlier (large) proposal. Moritz, I would encourage you like Richard did earlier to split the remaining points in your proposal into separate PR's too. So Richard, I created a PR to your PR to add in a little bit more detail: keeping the two mirrors in sync, role of the release manager to ensure that adequate reviewers get identified so that patches don't go unnoticed by an interested party who'd specifically want to review the patch on Phabricator, etc. https://github.com/goldfirere/ghc-proposals/pull/1 I also moved one of the two choices you mention to the "alternatives" section of the document, thinking that's the pupose of the section. On another note, I solicited an experience report from Gabriel Scherer earlier this week. The Ocaml community likewise pondered using GitHub back in 2014, and in fact lauched an experiment to that effect. So I was curious to hear how it went after 2 years of data. You can see the announcement here: http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30 Gabriel tells me that the initial situation for Ocaml was different from that of GHC: they had no formal code review tool in use, but would swap around patches on the Mantis issue tracker. Be it as it may, it's interesting to note just how much the number of contributions to Ocaml has increased in recent years, after this experiment started: https://github.com/ocaml/ocaml/graphs/contributors This experiment is today considered a big success. A key ingredient I gather is that Gabriel volunteered to triage the GitHub PR's and play the go-between to make sure all Mantis users were aware of any proposed changes relevant to them. The key insight I would put forth here is that how-to-accept-patches and where-to-review-them should be an agreement between the contributor and the assigned reviewer(s), in particular for trivial changes. For any given patch, provided the reviewer(s) is/are game, and provided all protential reviewers are made aware of its existence, it shouldn't matter much whether the patch came from Trac, Phabricator or GitHub. PS: Gabriel was very kind to also point out that the LLVM community has been big users of Phabricator and pondering introducing GitHub into the mix too. The discussion there should be relevant to this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html Best, -- Mathieu Boespflug Founder at http://tweag.io. -- Mathieu Boespflug Founder at http://tweag.io. On 29 September 2016 at 20:55, Richard Eisenberg wrote: > I have tried to gather the ideas from this thread into a formal proposal: > https://github.com/ghc-proposals/ghc-proposals/pull/11 > > Please feel free to make suggestions to improve this, especially if I've > captured anyone's contributions incorrectly. > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > > On Sep 29, 2016, at 10:20 AM, Christopher Allen > wrote: > > > >> Instead perhaps GitHub's new review system may be the way forward for > GHC. It allows you to easily use git in the way it's meant to be used. > > > > Many problems are caused by letting your inner tinkerer/genius tailor > > dictate how things should be dealt with. Better to cut the gordian > > knot. I think Michael's right. > > > > On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan > wrote: > >> > >> > >> On Wednesday, September 28, 2016, Eric Seidel wrote: > >>> > >>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: > >>>> Moritz Angermann writes: > >>>> > >>>>> All that arc essentially does is, compute the diff from an offset > >>>>> (e.g. master) to the current HEAD and upload that to a new or > existing > >>>>> (--update) differential. It also adds some meta information about the > >>>>> range, such that arc patch supposedly knows into which commit to > apply > >>>>> the patch to. > >>>>> > >>>> Sure, but this leads to generally unreviewable patches IMHO. In order > to > >>>> stay sane I generally split up my work into a set of standalone > patches > >>>> with git rebase and then create a Diff of each of these commits. > >>>> Phabricator supports this by having a notion of dependencies between > >>>> Diffs, but arcanist has no sensible scheme for taking a branch and > >>>> conveniently producing a series of Diffs. > >>> > >>> I completely understand how this would be frustrating for core > >>> contributors (more specifically for people submitting large patches), > >>> but for new or casual contributors it's actually quite freeing. I don't > >>> have to worry about how messy my local history gets, because arc will > >>> throw it all away regardless! It absolves me of an extra > responsibility, > >>> and lowers the barrier to contributing. > >> > >> > >> I dislike this workflow because I am already used to doing a lot of git > >> rebasing / amending / auto squashing. So using arc means taking away my > >> ability to write multi commit stories of how the change was crafted. For > >> large changes there are often multiple logical inter related steps. > >> Squashing them into one big commit makes it much harder to review. I > can > >> easily do that myself by marking everything as squash in a rebase. It > feels > >> like arcanist is just taking away power, not giving it (note i have not > used > >> it much - voice of a newbie here) > >> > >> I am beginning to change my feelings on this, away from thinking of > GitHub > >> as an auxilliary source of didferentials. Instead perhaps GitHub's new > >> review system may be the way forward for GHC. It allows you to easily > use > >> git in the way it's meant to be used. > >> > >> -Michael > >> > >>> > >>> > >>> It would be nice to support both workflows though :) > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > > > > > -- > > Chris Allen > > Currently working on http://haskellbook.com > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Sep 29 21:33:57 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 29 Sep 2016 22:33:57 +0100 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> <0AE28D3A-01E7-426F-8D31-F56642E43C79@cs.brynmawr.edu> Message-ID: Thanks for the useful data point Mathieu. I think it should also be noted that GHC contributions spiked after switching to phabricator so it could just be the effect of moving to *some* code review tool. Could you perhaps summarise the salient points in the LLVM thread? It is very long with lots of discussion points. FWIW, I think that we should accept pull requests but only if they are mirrored and reviewed on phabricator. This is important for three reasons: 1. Reviewers only need to look in one place and can clearly see when they are expected to review. Herald rules will also not trigger if a pull request is solely dealt with on github which could mean the right eyes don't land on the ticket. 2. Pull requests (differentials) are able to be referred to by their unique differential number rather than the pull request identifier which clashes with trac ticket numbers. 3. Differentials integrate (and are able to be integrated) with the existing infrastructure. I hope that in the future we improve this integration by moving the issue tracker to maniphest. Facebook have a bot which does the mirroring for some of their repositories but it isn't open-sourced. I believe we should be trying to consolidate rather than spread everything even thinner. Matt On Thu, Sep 29, 2016 at 9:55 PM, Boespflug, Mathieu wrote: > Hi Richard! > > thanks for creating the pull request with a full proposal. You beat me to it > - tried writing up much the same before stopping for dinner, essentially > capturing just one of the points in Moritz's earlier (large) proposal. > Moritz, I would encourage you like Richard did earlier to split the > remaining points in your proposal into separate PR's too. > > So Richard, I created a PR to your PR to add in a little bit more detail: > keeping the two mirrors in sync, role of the release manager to ensure that > adequate reviewers get identified so that patches don't go unnoticed by an > interested party who'd specifically want to review the patch on Phabricator, > etc. > > https://github.com/goldfirere/ghc-proposals/pull/1 > > I also moved one of the two choices you mention to the "alternatives" > section of the document, thinking that's the pupose of the section. > > On another note, I solicited an experience report from Gabriel Scherer > earlier this week. The Ocaml community likewise pondered using GitHub back > in 2014, and in fact lauched an experiment to that effect. So I was curious > to hear how it went after 2 years of data. > > You can see the announcement here: > > http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30 > > Gabriel tells me that the initial situation for Ocaml was different from > that of GHC: they had no formal code review tool in use, but would swap > around patches on the Mantis issue tracker. Be it as it may, it's > interesting to note just how much the number of contributions to Ocaml has > increased in recent years, after this experiment started: > > https://github.com/ocaml/ocaml/graphs/contributors > > This experiment is today considered a big success. A key ingredient I gather > is that Gabriel volunteered to triage the GitHub PR's and play the > go-between to make sure all Mantis users were aware of any proposed changes > relevant to them. > > The key insight I would put forth here is that how-to-accept-patches and > where-to-review-them should be an agreement between the contributor and the > assigned reviewer(s), in particular for trivial changes. For any given > patch, provided the reviewer(s) is/are game, and provided all protential > reviewers are made aware of its existence, it shouldn't matter much whether > the patch came from Trac, Phabricator or GitHub. > > PS: Gabriel was very kind to also point out that the LLVM community has been > big users of Phabricator and pondering introducing GitHub into the mix too. > The discussion there should be relevant to this thread: > > http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html > > Best, > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > On 29 September 2016 at 20:55, Richard Eisenberg > wrote: >> >> I have tried to gather the ideas from this thread into a formal proposal: >> https://github.com/ghc-proposals/ghc-proposals/pull/11 >> >> Please feel free to make suggestions to improve this, especially if I've >> captured anyone's contributions incorrectly. >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >> > On Sep 29, 2016, at 10:20 AM, Christopher Allen >> > wrote: >> > >> >> Instead perhaps GitHub's new review system may be the way forward for >> >> GHC. It allows you to easily use git in the way it's meant to be used. >> > >> > Many problems are caused by letting your inner tinkerer/genius tailor >> > dictate how things should be dealt with. Better to cut the gordian >> > knot. I think Michael's right. >> > >> > On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan >> > wrote: >> >> >> >> >> >> On Wednesday, September 28, 2016, Eric Seidel wrote: >> >>> >> >>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: >> >>>> Moritz Angermann writes: >> >>>> >> >>>>> All that arc essentially does is, compute the diff from an offset >> >>>>> (e.g. master) to the current HEAD and upload that to a new or >> >>>>> existing >> >>>>> (--update) differential. It also adds some meta information about >> >>>>> the >> >>>>> range, such that arc patch supposedly knows into which commit to >> >>>>> apply >> >>>>> the patch to. >> >>>>> >> >>>> Sure, but this leads to generally unreviewable patches IMHO. In order >> >>>> to >> >>>> stay sane I generally split up my work into a set of standalone >> >>>> patches >> >>>> with git rebase and then create a Diff of each of these commits. >> >>>> Phabricator supports this by having a notion of dependencies between >> >>>> Diffs, but arcanist has no sensible scheme for taking a branch and >> >>>> conveniently producing a series of Diffs. >> >>> >> >>> I completely understand how this would be frustrating for core >> >>> contributors (more specifically for people submitting large patches), >> >>> but for new or casual contributors it's actually quite freeing. I >> >>> don't >> >>> have to worry about how messy my local history gets, because arc will >> >>> throw it all away regardless! It absolves me of an extra >> >>> responsibility, >> >>> and lowers the barrier to contributing. >> >> >> >> >> >> I dislike this workflow because I am already used to doing a lot of git >> >> rebasing / amending / auto squashing. So using arc means taking away >> >> my >> >> ability to write multi commit stories of how the change was crafted. >> >> For >> >> large changes there are often multiple logical inter related steps. >> >> Squashing them into one big commit makes it much harder to review. I >> >> can >> >> easily do that myself by marking everything as squash in a rebase. It >> >> feels >> >> like arcanist is just taking away power, not giving it (note i have not >> >> used >> >> it much - voice of a newbie here) >> >> >> >> I am beginning to change my feelings on this, away from thinking of >> >> GitHub >> >> as an auxilliary source of didferentials. Instead perhaps GitHub's new >> >> review system may be the way forward for GHC. It allows you to easily >> >> use >> >> git in the way it's meant to be used. >> >> >> >> -Michael >> >> >> >>> >> >>> >> >>> It would be nice to support both workflows though :) >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > >> > >> > >> > -- >> > Chris Allen >> > Currently working on http://haskellbook.com >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From amindfv at gmail.com Thu Sep 29 22:39:11 2016 From: amindfv at gmail.com (Tom Murphy) Date: Fri, 30 Sep 2016 07:39:11 +0900 Subject: How, precisely, can we improve? In-Reply-To: <73702D9C-F495-462C-8220-ECCE08B62AAB@cs.brynmawr.edu> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> <73702D9C-F495-462C-8220-ECCE08B62AAB@cs.brynmawr.edu> Message-ID: On Fri, Sep 30, 2016 at 4:14 AM, Richard Eisenberg wrote: > I've spent some time thinking about how and what to synthesize from this > conversation. Moritz has captured much of these ideas in the proposal he > submitted. Thanks. > > But that proposal tackles only one part of the problem: what to do in the > future. It does not address the insufficiencies of the wiki as it now > stands, and these drawbacks seem to be the dangling fibers of this thread. > Two specific complaints are that (1) search engines still find out-of-date > documentation and (2) the wiki is not discoverable. I agree with both of > these, but I can't think of any (easy) way to help either one. > > For (1), the "obvious" solution is to pull old pages. However, old pages > still serve as useful documentary evidence when we need to revisit a > decision made in the past. I think simply deleting out-of-date pages may > lose useful info. Could we remove the pages from the wiki but keep them > somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? > I wouldn't want to keep it somewhere private, lest it be unavailable to the > person that needs it. I think clearly labeling out-of-date info as such is > the best compromise. > > +1 to keeping (maybe with "this is old" labels): I would much rather have a page with a series of pointers to how something was done a few years ago than to have no information at all. I'd also like to +1 the fact that having Trac's up-to-date ticket labels (e.g. crossed-out links for completed tickets) is invaluable. Tom > For (2), there is an index to the wiki: https://ghc.haskell.org/ > trac/ghc/wiki/TitleIndex It's long and rambly, but may be of use. I > agree that grepping would be nice. Does anyone know if there is a way to > extract plaintext from a Trac wiki? I agree that making such a feature > available would be helpful. In the future, though, even a git-backed > collection will run into discoverability problems, unless someone > continually keeps it organized. (It will be greppable, though.) > > As to the point of shoring up existing infra vs. looking more broadly: I > suppose I am interesting in shoring up the existing infra, but I'm > considering "existing infra" to include all the platforms I'm aware of. > This explicitly includes the idea of dropping, say, Trac entirely and > moving exclusively to GitHub. I think that would be a terrible idea, but > it's in scope in my thinking. What's *not* in scope (in my thinking) is the > idea of creating new tools that do exactly what we want. We're all > developers and can imagine wonderful things, but wonderful things do not > come cheaply, and we are but poor. > > So I'm at a loss of what to do about these remaining fibers. Concrete > suggestions, anyone? > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > On Sep 29, 2016, at 7:37 AM, Takenobu Tani wrote: > > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani >> wrote: >> >>> Apologies if I’m missing context. >>> >>> >>> Potential contributors need information from wiki. >>> >>> I feel current wiki’s problems are following: >>> >>> >>> (a) reachability >>> >>> "Where is the page I need?" >>> >>> >>> (b) outdated pages >>> >>> "Is this page up-to-date?" >>> >>> >>> (c) update method >>> >>> "How Can I update the page?" >>> >>> >>> >>> About (a): >>> >>> >>> It's difficult to find pages they need. Maybe reasons are following: >>> >>> * We have multiple wiki sites. >>> >>> * Desired contents structure is different for each member. >>> >>> >>> So single wiki site is not enough from latter. >>> >>> >>> Therefore, what about "a search system for multiple wiki sites"? >>> >>> >>> >>> About (b): >>> >>> >>> Haskell's evolution is fast. >>> >>> New contributor encounters sometimes outdated pages. >>> >>> But they don't still know how to correct them. >>> >>> >>> Therefore, what about putting "outdated mark" to the page by them? >>> >>> >>> They can easily contribute. >>> >>> And if possible, they send update request with any way. >>> >>> We’ll preferentially update many requested pages. >>> >>> >>> >>> About (c): >>> >>> >>> We have multiple wiki sites. Someone is unfamiliar about them. >>> >>> Github is one of the solutions for new contents. >>> >>> But I don't have idea about this for current contents. >>> >>> >>> Regards, >>> >>> Takenobu >>> >>> >>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >>> >>>> I'm quite leery of using a new site (readthedocs.org), as it creates >>>> yet another platform for contributors to understand. Reducing the number of >>>> platforms has been a fairly clearly-stated goal of these recent >>>> conversations, as I've read it. >>>> >>>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>>> reason against moving: we lose the Trac integration. A Trac wiki page can >>>> easily link to tickets and individual comments, and can use dynamic >>>> features such as lists of active tickets. These are useful and well-used >>>> features. I don't know what's best here, but thinking about the real loss >>>> associated with moving away from these features gives me pause. >>>> >>>> Richard >>>> >>>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >>>> > >>>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >>>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>>> one >>>> >>> thing that’s easier about a wiki is that the editing process is >>>> much more >>>> >>> lightweight than making a PR. >>>> >>> >>>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>>> pencil >>>> >>> icon in the top-right. It allows you to make arbitrary changes in >>>> the >>>> >>> file and then automates the construction of a PR. The owner of the >>>> file >>>> >>> can then accept the PR very, very easily. If the editor has commit >>>> >>> rights, you can make your edits into a commit right away. No need to >>>> >>> fork, pull and push. >>>> >> >>>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>>> >> rendered and inter-linked pages *and* have the option for web-based >>>> or >>>> >> git-based editing. Though, based on my limited experience with GitHub >>>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>>> > >>>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>>> > tried using GitHub wikis, and found that they were clunkier than just >>>> > having wiki / docs in your repo. GHC would probably want to have a >>>> > separate docs repo, as otherwise the commit history will get filled >>>> > with commits related to proposals, etc. >>>> > >>>> > It may be worth considering a similar approach with the GHC >>>> > documentation. We've had great success in stack with using >>>> > https://readthedocs.org/ . The way this works is that you have a >>>> > branch that readthedocs points at ("stable"), which provides the >>>> > current version to display. I realize that ghc would want to have >>>> > multiple versions of the docs up, but I'm sure that's feasible. >>>> > >>>> > Github itself has pretty nice markdown rendering, and the ability to >>>> > edit directly. Note that there is no GitHub lock-in here - it is just >>>> > a collection of markdown files, organized however you like them. >>>> > >>>> > The risk with such a migration is that the old wiki(s?) don't get >>>> > fully migrated and shut down. If that happens, then information will >>>> > be even more spread out and hard to find. Perhaps we can use pandoc >>>> > to automatically migrate much of the wiki content to markdown? It >>>> > probably will not be a lossfree conversion. >>>> > >>>> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >>>> >> seems to offer the same set of features, but apparently with a more >>>> >> traditional (and I assume customizable) layout. >>>> >> >>>> >> I think having the option for simple, immediate edits or >>>> peer-reviewed >>>> >> edits (the peer-review is much more important to me than having an >>>> >> explicitly file-based system) would be a big win. Perhaps there's >>>> even a >>>> >> trac module that implements something like this? Then we could >>>> decouple >>>> >> it from the question/task of migrating the existing content >>>> elsewhere. >>>> >> >>>> >> Eric >>>> >> _______________________________________________ >>>> >> ghc-devs mailing list >>>> >> ghc-devs at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> > _______________________________________________ >>>> > ghc-devs mailing list >>>> > ghc-devs at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Sep 30 01:30:05 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 29 Sep 2016 21:30:05 -0400 Subject: A few technical suggestions In-Reply-To: <57e8c20c.a699c20a.501d5.c921@mx.google.com> References: <57e8c20c.a699c20a.501d5.c921@mx.google.com> Message-ID: <75C07D4D-8282-440D-9FA4-C9B3A153100D@cs.brynmawr.edu> In a sweep to make sure that the concerns raised here get heard, I see this great list of suggestions. I believe they have all been incorporated into https://github.com/ghc-proposals/ghc-proposals/pull/9, so please check there. Personally, I think these suggestions will get better discussion and be more actionable if broken up into smaller PRs that can easily be debated separately. However, I will leave it to others to make this decision and do the restructuring. Thanks for these suggestions forward! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 26, 2016, at 2:37 AM, lonetiger at gmail.com wrote: > > Hi All, > > I wanted to give my own thoughts/suggestions for things we could do on the short/medium term > To make things a bit better. As a whole I may be one of the few who likes the current setup so I > Propose enhancing the current toolset. > > I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest. > And the discussion quickly becomes hard to follow as it branches lot. > > My proposals (sorry for the brevity, I can expand if needed): > > * Link phab to github > Phabricator seems to have build in OAuth support. > As you'll likely need a github account anyway, why not > also support github logins? This would reduce the barrier of > needing multiple accounts that is often a complaint. > Would it be possible to maybe also extract the user's public > key from github automatically? That would reduce one of the barriers as well. > https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/ > > * Link Trac to github > - used to login (OAuth support) > - readonly issues (to begin with?). > we already have a code mirror, why not mirror more content. > - sync issues back between the two > - gives us an ability to see which github users an issue affects > since they can then reference it. > - updates the users when an issue is fixed since it will be closed on GH. > - Gives us an indication of the importance of the tickets > > As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, > both of which seem to be quite bare and simple in what they provide. I am not > in favor of ditching it. Also we have and continue to accept patches just uploaded > to Trac as a diff. We tend to ask people to upload it to phab for better reviews > and so it's attributed to them when we commit. Some don't (and we then do it ourselves), > most due. If they don't need another login then I suspect almost all would. > There's a (seemingly) actively maintained project that does all the above, could we leverage it? > https://github.com/trac-hacks/trac-github > * There is a trac plugin to generate a new section on trac > /doc which allows you to render and edit documentations checked into repo. > Could this be used to allow easier editing of non generated documentation? > > It's currently based on SVN, but maybe a git one exists too? > https://github.com/trac-hacks/tracdocs > > * Newcomers > - Expose newcomers information more by creating a new landing page > - Clean up build instructions. For windows, I have scripts to automate setup. > Often heard complain is that it is hard, but never hear why it's hard. > > In any case, my setup script for a 100% unattended build env setup for Windows > are here: https://github.com/Mistuke/GhcDevelChoco/releases > > These are entirely self contained environments that can be removed by a simple rm -rf /. > You can have as many as you want on the same machine without them interfering with eachother > or with whatever else you might have done to your GHC already installed. > > It's not 100% production ready but it works and does so well. > > * Updated Phab reviewers list to be more automated > - Assign reviewers next to the static list (as is currently done) > to maybe also include significant contributors to that file? > > The reason for this is that currently it's always the same people reviewing patches. > Their time is spread thin. Particularly on less popular platforms it basically comes > down to 4 people. > * Update trac linters and pre-commit linters to be the same. > - particularly reject summaries that would be rejected on commit. > Often when I try landing patches (especially from others) I have to > edit the summary. Maybe arc should reject the diff if a push would fail? > > Also I want to say I love the summary document you have to fill in. > It ensures useful information is there later when I have to find out why > a change was made. So whatever we do, don't remove this. > > * Phab plugin to on signup ask for public key if none found. > - It's recently been made a requirement to require a public key to push to phab. > The error you get when you don't do this and try to push a patch is very very > cryptic and unintuitive. Could we make a plugin that asks the user to upload > a public key on trac if they haven't done so? Like a banner at the top? > > * Automate trac tickets > - Particular on new tickets post a friendly reminder that if they want they can give it a hand in fixing it themselves. > - Parse information added, in particular check if reproduction steps are there etc. > - If stack is used, kindly ask if a repo without can be used. The amount of bug reports with stack is increasing and regardless of my own opinion on the tool, these reports are not very useful as is. > - Maybe automatically CC people from a pool based on the information in the ticket? I tend to miss tickets because my filters are quite strict. Generally if the ticket doesn't mention my name, is directed at me or has "Windows" in the body somewhere it will skip my inbox. I review filtered tickets only once a week. > - If a newcomer assigns a ticket to themselves, have trac automatically post links to useful pages: > * how to setup build environment. > * how to get help > * assign a mentor? > * after x amount of time with no progress, remind them again that help is available > > Kind Regards, > Tamar > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Sep 30 02:37:18 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 29 Sep 2016 22:37:18 -0400 Subject: A few technical suggestions In-Reply-To: <57e8c20c.a699c20a.501d5.c921@mx.google.com> References: <57e8c20c.a699c20a.501d5.c921@mx.google.com> Message-ID: <8737kidsf5.fsf@ben-laptop.smart-cactus.org> lonetiger at gmail.com writes: > Hi All, > Sorry Tamar, it seems I overlooked this. > I wanted to give my own thoughts/suggestions for things we could do on the short/medium term > To make things a bit better. As a whole I may be one of the few who likes the current setup so I > Propose enhancing the current toolset. > > I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest. > And the discussion quickly becomes hard to follow as it branches lot. > > My proposals (sorry for the brevity, I can expand if needed): > > * Link phab to github > Phabricator seems to have build in OAuth support. > As you'll likely need a github account anyway, why not > also support github logins? This would reduce the barrier of > needing multiple accounts that is often a complaint. > Our Phabricator instance already supports GitHub logins. This is indeed my primary means of authentication. > Would it be possible to maybe also extract the user's public > key from github automatically? That would reduce one of the barriers as well. > https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/ > Sadly it seems that Phacility may be reluctant to implement this [1]. > * Link Trac to github > - used to login (OAuth support) > - readonly issues (to begin with?). > we already have a code mirror, why not mirror more content. Unfortunately GitHub doesn't allow one to override the automatically assigned ticket numbering, so we'd end up with two different sets of ticket numbers. I think this would be worse than no mirror. This pretty much sinks any possibility for using GitHub issues. > - sync issues back between the two > - gives us an ability to see which github users an issue affects > since they can then reference it. > - updates the users when an issue is fixed since it will be closed on GH. > - Gives us an indication of the importance of the tickets > > As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, > both of which seem to be quite bare and simple in what they provide. I agree that Trac's ticket system is great. It is without doubt much more capable than GitHub, which would be quite painful given our ticket load. That being said, I am beginning to waver its merits relative to Phabricator. Matthew Pickering pointed out that Phabricator indeed supports custom fields, which is what gives Trac much of its power (this and the ability to define custom ticket workflows, which Phabricator does not support AFAIK). > I am not in favor of ditching it. Also we have and continue to accept > patches just uploaded to Trac as a diff. We tend to ask people to > upload it to phab for better reviews and so it's attributed to them > when we commit. Some don't (and we then do it ourselves), most due. > If they don't need another login then I suspect almost all would. > I don't mind this. Trac tickets are relatively few and far between. > There's a (seemingly) actively maintained project that does all the above, could we leverage it? > https://github.com/trac-hacks/trac-github > Perhaps. > * There is a trac plugin to generate a new section on trac > /doc which allows you to render and edit documentations checked into repo. > Could this be used to allow easier editing of non generated documentation? > > It's currently based on SVN, but maybe a git one exists too? > https://github.com/trac-hacks/tracdocs > > * Newcomers > - Expose newcomers information more by creating a new landing page > - Clean up build instructions. For windows, I have scripts to automate setup. > Often heard complain is that it is hard, but never hear why it's hard. > > In any case, my setup script for a 100% unattended build env setup for Windows > are here: https://github.com/Mistuke/GhcDevelChoco/releases > > These are entirely self contained environments that can be removed by a simple rm -rf /. > You can have as many as you want on the same machine without them interfering with eachother > or with whatever else you might have done to your GHC already installed. > > It's not 100% production ready but it works and does so well. > > * Updated Phab reviewers list to be more automated > - Assign reviewers next to the static list (as is currently done) > to maybe also include significant contributors to that file? > > The reason for this is that currently it's always the same people reviewing patches. > Their time is spread thin. Particularly on less popular platforms it basically comes > down to 4 people. > Agreed. However, I suspect this would need to be a manual effort. There is no easy way to achieve this with Herald as far as I know. > * Update trac linters and pre-commit linters to be the same. > - particularly reject summaries that would be rejected on commit. > Often when I try landing patches (especially from others) I have to > edit the summary. Maybe arc should reject the diff if a push would fail? > Again, I'm not sure that this is possible. Phabricator's linter support doesn't cover commit messages AFAIK. Moreover, Phabricator itself sadly requires the "Summary:" tag. > Also I want to say I love the summary document you have to fill in. > It ensures useful information is there later when I have to find out why > a change was made. So whatever we do, don't remove this. > > * Phab plugin to on signup ask for public key if none found. > - It's recently been made a requirement to require a public key to push to phab. > The error you get when you don't do this and try to push a patch is very very > cryptic and unintuitive. Could we make a plugin that asks the user to upload > a public key on trac if they haven't done so? Like a banner at the top? > Do you mean s/a public key on trac/a public key on Phabricator/? > * Automate trac tickets > - Particular on new tickets post a friendly reminder that if they > want they can give it a hand in fixing it themselves. > - Parse information added, in particular check if reproduction steps > are there etc. > - If stack is used, kindly ask if a repo without can be used. The > amount of bug reports with stack is increasing and regardless of my > own opinion on the tool, these reports are not very useful as is. > - Maybe automatically CC people from a pool based on the information > in the ticket? I tend to miss tickets because my filters are quite > strict. Generally if the ticket doesn't mention my name, is directed > at me or has "Windows" in the body somewhere it will skip my inbox. I > review filtered tickets only once a week. > - If a newcomer assigns a ticket to themselves, have trac > automatically post links to useful pages: > * how to setup build environment. > * how to get help > * assign a mentor? > * after x amount of time with no progress, remind them again that > help is available > I'm honestly not sure how much of this is worth automating with Trac. My last attempt at using Trac's XML-RPC interface ended in fruitless frustration. Cheers, - Ben [1] https://secure.phabricator.com/T4587 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Fri Sep 30 02:53:14 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Sep 2016 22:53:14 -0400 Subject: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion In-Reply-To: References: <87ponqijpk.fsf@ben-laptop.smart-cactus.org> <4B26A359-0937-4BEA-A071-D24BDF26C2DB@cs.brynmawr.edu> <8760pgf1pz.fsf@ben-laptop.smart-cactus.org> <87a8erebb0.fsf@ben-laptop.smart-cactus.org> <1475128707.1189598.740457233.75435773@webmail.messagingengine.com> <0AE28D3A-01E7-426F-8D31-F56642E43C79@cs.brynmawr.edu> Message-ID: <87wphucd45.fsf@ben-laptop.smart-cactus.org> Matthew Pickering writes: > Thanks for the useful data point Mathieu. I think it should also be > noted that GHC contributions spiked after switching to phabricator so > it could just be the effect of moving to *some* code review tool. > Could you perhaps summarise the salient points in the LLVM thread? It > is very long with lots of discussion points. As far as I know the LLVM folks were merely considering moving from SVN to Git, using GitHub to host their reposistory. I don't believe that moving to GitHub for issue tracking, code review, or any other functionality was ever seriously on the table. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Fri Sep 30 10:47:24 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 10:47:24 +0000 Subject: git question Message-ID: Friends I have a batch of several commits lined up on my local machine, validated, and ready to push to the master. But one seems to have accidentally got diff --git a/utils/haddock b/utils/haddock index 073d899..a3309e7 160000 --- a/utils/haddock +++ b/utils/haddock @@ -1 +1 @@ -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a I did not want to meddle with Haddock. Question: how can I remove this change from my commit? I know how to do git rebase –interactive, and I can aske to “edit” that commit… but what then? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Sep 30 10:53:09 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 30 Sep 2016 03:53:09 -0700 Subject: git question In-Reply-To: References: Message-ID: <1475232726-sup-9478@sabre> Get to the commit you want to edit, then cd utils/haddock git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b cd ../.. git commit --amend -a Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30 10:47:24 +0000: > Friends > I have a batch of several commits lined up on my local machine, validated, and ready to push to the master. > But one seems to have accidentally got > > diff --git a/utils/haddock b/utils/haddock > > index 073d899..a3309e7 160000 > > --- a/utils/haddock > > +++ b/utils/haddock > > @@ -1 +1 @@ > > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b > > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a > I did not want to meddle with Haddock. > Question: how can I remove this change from my commit? I know how to do git rebase –interactive, and I can aske to “edit” that commit… but what then? > Thanks > Simon From takenobu.hs at gmail.com Fri Sep 30 10:56:41 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 30 Sep 2016 19:56:41 +0900 Subject: How, precisely, can we improve? In-Reply-To: <73702D9C-F495-462C-8220-ECCE08B62AAB@cs.brynmawr.edu> References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> <73702D9C-F495-462C-8220-ECCE08B62AAB@cs.brynmawr.edu> Message-ID: Hi, Richard said: (1) search engines still find out-of-date documentation (2) the wiki is not discoverable I know trac is treasure house. And I realized old pages are valuable for decision. My concrete suggestion is here: For (1): When we find out-of-date documentation, we directly modify head of the document. We manually insert a comment like "This content is out-of-date for GHC8.0". (New contributors easy can do it.) For (2): We provide manually-written multiple indexes for different views on a portal page of the wiki site. Contributors could maintain each index themselves. (New comers will choose his favorite index for his exploring.) Furthermore, we provide a simple search box for multiple wiki sites. (Please wait for a while. I'll prepare simple-conceptual demonstration with web.) Diversity is strength of Haskell community, Takenobu 2016-09-30 4:14 GMT+09:00 Richard Eisenberg : > I've spent some time thinking about how and what to synthesize from this > conversation. Moritz has captured much of these ideas in the proposal he > submitted. Thanks. > > But that proposal tackles only one part of the problem: what to do in the > future. It does not address the insufficiencies of the wiki as it now > stands, and these drawbacks seem to be the dangling fibers of this thread. > Two specific complaints are that (1) search engines still find out-of-date > documentation and (2) the wiki is not discoverable. I agree with both of > these, but I can't think of any (easy) way to help either one. > > For (1), the "obvious" solution is to pull old pages. However, old pages > still serve as useful documentary evidence when we need to revisit a > decision made in the past. I think simply deleting out-of-date pages may > lose useful info. Could we remove the pages from the wiki but keep them > somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? > I wouldn't want to keep it somewhere private, lest it be unavailable to the > person that needs it. I think clearly labeling out-of-date info as such is > the best compromise. > > For (2), there is an index to the wiki: https://ghc.haskell.org/ > trac/ghc/wiki/TitleIndex It's long and rambly, but may be of use. I > agree that grepping would be nice. Does anyone know if there is a way to > extract plaintext from a Trac wiki? I agree that making such a feature > available would be helpful. In the future, though, even a git-backed > collection will run into discoverability problems, unless someone > continually keeps it organized. (It will be greppable, though.) > > As to the point of shoring up existing infra vs. looking more broadly: I > suppose I am interesting in shoring up the existing infra, but I'm > considering "existing infra" to include all the platforms I'm aware of. > This explicitly includes the idea of dropping, say, Trac entirely and > moving exclusively to GitHub. I think that would be a terrible idea, but > it's in scope in my thinking. What's *not* in scope (in my thinking) is the > idea of creating new tools that do exactly what we want. We're all > developers and can imagine wonderful things, but wonderful things do not > come cheaply, and we are but poor. > > So I'm at a loss of what to do about these remaining fibers. Concrete > suggestions, anyone? > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > On Sep 29, 2016, at 7:37 AM, Takenobu Tani wrote: > > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani >> wrote: >> >>> Apologies if I’m missing context. >>> >>> >>> Potential contributors need information from wiki. >>> >>> I feel current wiki’s problems are following: >>> >>> >>> (a) reachability >>> >>> "Where is the page I need?" >>> >>> >>> (b) outdated pages >>> >>> "Is this page up-to-date?" >>> >>> >>> (c) update method >>> >>> "How Can I update the page?" >>> >>> >>> >>> About (a): >>> >>> >>> It's difficult to find pages they need. Maybe reasons are following: >>> >>> * We have multiple wiki sites. >>> >>> * Desired contents structure is different for each member. >>> >>> >>> So single wiki site is not enough from latter. >>> >>> >>> Therefore, what about "a search system for multiple wiki sites"? >>> >>> >>> >>> About (b): >>> >>> >>> Haskell's evolution is fast. >>> >>> New contributor encounters sometimes outdated pages. >>> >>> But they don't still know how to correct them. >>> >>> >>> Therefore, what about putting "outdated mark" to the page by them? >>> >>> >>> They can easily contribute. >>> >>> And if possible, they send update request with any way. >>> >>> We’ll preferentially update many requested pages. >>> >>> >>> >>> About (c): >>> >>> >>> We have multiple wiki sites. Someone is unfamiliar about them. >>> >>> Github is one of the solutions for new contents. >>> >>> But I don't have idea about this for current contents. >>> >>> >>> Regards, >>> >>> Takenobu >>> >>> >>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >>> >>>> I'm quite leery of using a new site (readthedocs.org), as it creates >>>> yet another platform for contributors to understand. Reducing the number of >>>> platforms has been a fairly clearly-stated goal of these recent >>>> conversations, as I've read it. >>>> >>>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>>> reason against moving: we lose the Trac integration. A Trac wiki page can >>>> easily link to tickets and individual comments, and can use dynamic >>>> features such as lists of active tickets. These are useful and well-used >>>> features. I don't know what's best here, but thinking about the real loss >>>> associated with moving away from these features gives me pause. >>>> >>>> Richard >>>> >>>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >>>> > >>>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >>>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>>> one >>>> >>> thing that’s easier about a wiki is that the editing process is >>>> much more >>>> >>> lightweight than making a PR. >>>> >>> >>>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>>> pencil >>>> >>> icon in the top-right. It allows you to make arbitrary changes in >>>> the >>>> >>> file and then automates the construction of a PR. The owner of the >>>> file >>>> >>> can then accept the PR very, very easily. If the editor has commit >>>> >>> rights, you can make your edits into a commit right away. No need to >>>> >>> fork, pull and push. >>>> >> >>>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>>> >> rendered and inter-linked pages *and* have the option for web-based >>>> or >>>> >> git-based editing. Though, based on my limited experience with GitHub >>>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>>> > >>>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>>> > tried using GitHub wikis, and found that they were clunkier than just >>>> > having wiki / docs in your repo. GHC would probably want to have a >>>> > separate docs repo, as otherwise the commit history will get filled >>>> > with commits related to proposals, etc. >>>> > >>>> > It may be worth considering a similar approach with the GHC >>>> > documentation. We've had great success in stack with using >>>> > https://readthedocs.org/ . The way this works is that you have a >>>> > branch that readthedocs points at ("stable"), which provides the >>>> > current version to display. I realize that ghc would want to have >>>> > multiple versions of the docs up, but I'm sure that's feasible. >>>> > >>>> > Github itself has pretty nice markdown rendering, and the ability to >>>> > edit directly. Note that there is no GitHub lock-in here - it is just >>>> > a collection of markdown files, organized however you like them. >>>> > >>>> > The risk with such a migration is that the old wiki(s?) don't get >>>> > fully migrated and shut down. If that happens, then information will >>>> > be even more spread out and hard to find. Perhaps we can use pandoc >>>> > to automatically migrate much of the wiki content to markdown? It >>>> > probably will not be a lossfree conversion. >>>> > >>>> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >>>> >> seems to offer the same set of features, but apparently with a more >>>> >> traditional (and I assume customizable) layout. >>>> >> >>>> >> I think having the option for simple, immediate edits or >>>> peer-reviewed >>>> >> edits (the peer-review is much more important to me than having an >>>> >> explicitly file-based system) would be a big win. Perhaps there's >>>> even a >>>> >> trac module that implements something like this? Then we could >>>> decouple >>>> >> it from the question/task of migrating the existing content >>>> elsewhere. >>>> >> >>>> >> Eric >>>> >> _______________________________________________ >>>> >> ghc-devs mailing list >>>> >> ghc-devs at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> > _______________________________________________ >>>> > ghc-devs mailing list >>>> > ghc-devs at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Fri Sep 30 11:06:11 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 30 Sep 2016 19:06:11 +0800 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> <73702D9C-F495-462 C-8220-ECCE08B62AAB@cs.brynmawr.edu> Message-ID: Dear Takenobu, may I politely direct you to https://github.com/ghc-proposals/ghc-proposals/pull/10, and ask you to add your comments there as well, as that proposal tries to track these changes in a central place through the new ghc-proposal process. Cheers, Moritz > On Sep 30, 2016, at 6:56 PM, Takenobu Tani wrote: > > Hi, > > Richard said: > (1) search engines still find out-of-date documentation > (2) the wiki is not discoverable > > I know trac is treasure house. > And I realized old pages are valuable for decision. > > > My concrete suggestion is here: > > For (1): > When we find out-of-date documentation, we directly modify head of the document. > We manually insert a comment like "This content is out-of-date for GHC8.0". > (New contributors easy can do it.) > > For (2): > We provide manually-written multiple indexes for different views on a portal page of the wiki site. > Contributors could maintain each index themselves. > (New comers will choose his favorite index for his exploring.) > > Furthermore, we provide a simple search box for multiple wiki sites. > (Please wait for a while. I'll prepare simple-conceptual demonstration with web.) > > > Diversity is strength of Haskell community, > Takenobu > > > 2016-09-30 4:14 GMT+09:00 Richard Eisenberg : > I've spent some time thinking about how and what to synthesize from this conversation. Moritz has captured much of these ideas in the proposal he submitted. Thanks. > > But that proposal tackles only one part of the problem: what to do in the future. It does not address the insufficiencies of the wiki as it now stands, and these drawbacks seem to be the dangling fibers of this thread. Two specific complaints are that (1) search engines still find out-of-date documentation and (2) the wiki is not discoverable. I agree with both of these, but I can't think of any (easy) way to help either one. > > For (1), the "obvious" solution is to pull old pages. However, old pages still serve as useful documentary evidence when we need to revisit a decision made in the past. I think simply deleting out-of-date pages may lose useful info. Could we remove the pages from the wiki but keep them somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? I wouldn't want to keep it somewhere private, lest it be unavailable to the person that needs it. I think clearly labeling out-of-date info as such is the best compromise. > > For (2), there is an index to the wiki: https://ghc.haskell.org/trac/ghc/wiki/TitleIndex It's long and rambly, but may be of use. I agree that grepping would be nice. Does anyone know if there is a way to extract plaintext from a Trac wiki? I agree that making such a feature available would be helpful. In the future, though, even a git-backed collection will run into discoverability problems, unless someone continually keeps it organized. (It will be greppable, though.) > > As to the point of shoring up existing infra vs. looking more broadly: I suppose I am interesting in shoring up the existing infra, but I'm considering "existing infra" to include all the platforms I'm aware of. This explicitly includes the idea of dropping, say, Trac entirely and moving exclusively to GitHub. I think that would be a terrible idea, but it's in scope in my thinking. What's *not* in scope (in my thinking) is the idea of creating new tools that do exactly what we want. We're all developers and can imagine wonderful things, but wonderful things do not come cheaply, and we are but poor. > > So I'm at a loss of what to do about these remaining fibers. Concrete suggestions, anyone? > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > >> On Sep 29, 2016, at 7:37 AM, Takenobu Tani wrote: >> >> Hi Carter, >> >> Thank you very much :) >> >> We love haskell, >> Takenobu >> >> >> 2016-09-28 22:29 GMT+09:00 Carter Schonwald : >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani wrote: >> Apologies if I’m missing context. >> >> >> Potential contributors need information from wiki. >> >> I feel current wiki’s problems are following: >> >> >> (a) reachability >> >> "Where is the page I need?" >> >> >> (b) outdated pages >> >> "Is this page up-to-date?" >> >> >> (c) update method >> >> "How Can I update the page?" >> >> >> >> About (a): >> >> >> It's difficult to find pages they need. Maybe reasons are following: >> >> * We have multiple wiki sites. >> >> * Desired contents structure is different for each member. >> >> >> So single wiki site is not enough from latter. >> >> >> Therefore, what about "a search system for multiple wiki sites"? >> >> >> >> About (b): >> >> >> Haskell's evolution is fast. >> >> New contributor encounters sometimes outdated pages. >> >> But they don't still know how to correct them. >> >> >> Therefore, what about putting "outdated mark" to the page by them? >> >> >> They can easily contribute. >> >> And if possible, they send update request with any way. >> >> We’ll preferentially update many requested pages. >> >> >> >> About (c): >> >> >> We have multiple wiki sites. Someone is unfamiliar about them. >> >> Github is one of the solutions for new contents. >> >> But I don't have idea about this for current contents. >> >> >> Regards, >> >> Takenobu >> >> >> >> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >> I'm quite leery of using a new site (readthedocs.org), as it creates yet another platform for contributors to understand. Reducing the number of platforms has been a fairly clearly-stated goal of these recent conversations, as I've read it. >> >> Despite agreeing that wikis are sometimes wonky, I thought of a solid reason against moving: we lose the Trac integration. A Trac wiki page can easily link to tickets and individual comments, and can use dynamic features such as lists of active tickets. These are useful and well-used features. I don't know what's best here, but thinking about the real loss associated with moving away from these features gives me pause. >> >> Richard >> >> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >> > >> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> >>> Yes, I agree with Michael’s observations in the blog post. However, one >> >>> thing that’s easier about a wiki is that the editing process is much more >> >>> lightweight than making a PR. >> >>> >> >>> But GitHub has a wonderful feature (that I have rarely used) that >> >>> mitigates this problem. Viewing a file in GitHub offers a little pencil >> >>> icon in the top-right. It allows you to make arbitrary changes in the >> >>> file and then automates the construction of a PR. The owner of the file >> >>> can then accept the PR very, very easily. If the editor has commit >> >>> rights, you can make your edits into a commit right away. No need to >> >>> fork, pull and push. >> >> >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >> >> rendered and inter-linked pages *and* have the option for web-based or >> >> git-based editing. Though, based on my limited experience with GitHub >> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >> > >> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >> > tried using GitHub wikis, and found that they were clunkier than just >> > having wiki / docs in your repo. GHC would probably want to have a >> > separate docs repo, as otherwise the commit history will get filled >> > with commits related to proposals, etc. >> > >> > It may be worth considering a similar approach with the GHC >> > documentation. We've had great success in stack with using >> > https://readthedocs.org/ . The way this works is that you have a >> > branch that readthedocs points at ("stable"), which provides the >> > current version to display. I realize that ghc would want to have >> > multiple versions of the docs up, but I'm sure that's feasible. >> > >> > Github itself has pretty nice markdown rendering, and the ability to >> > edit directly. Note that there is no GitHub lock-in here - it is just >> > a collection of markdown files, organized however you like them. >> > >> > The risk with such a migration is that the old wiki(s?) don't get >> > fully migrated and shut down. If that happens, then information will >> > be even more spread out and hard to find. Perhaps we can use pandoc >> > to automatically migrate much of the wiki content to markdown? It >> > probably will not be a lossfree conversion. >> > >> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >> >> seems to offer the same set of features, but apparently with a more >> >> traditional (and I assume customizable) layout. >> >> >> >> I think having the option for simple, immediate edits or peer-reviewed >> >> edits (the peer-review is much more important to me than having an >> >> explicitly file-based system) would be a big win. Perhaps there's even a >> >> trac module that implements something like this? Then we could decouple >> >> it from the question/task of migrating the existing content elsewhere. >> >> >> >> Eric >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ————————————————— Moritz Angermann +49 170 54 33 0 74 moritz at lichtzwerge.de lichtzwerge GmbH Raiffeisenstr. 8 93185 Michelsneukirchen Amtsgericht Regensburg HRB 14723 Geschäftsführung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From simonpj at microsoft.com Fri Sep 30 11:10:35 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 11:10:35 +0000 Subject: git question In-Reply-To: <1475232726-sup-9478@sabre> References: <1475232726-sup-9478@sabre> Message-ID: Thanks... that worked. Somehow it ought to be possible to un-stage the haddock change rather that carefully undo it manually. But it worked so I'm not complaining! Thank you Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 30 September 2016 11:53 | To: ghc-devs | Subject: Re: git question | | Get to the commit you want to edit, then | | cd utils/haddock | git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b | cd ../.. | git commit --amend -a | | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30 | 10:47:24 +0000: | > Friends | > I have a batch of several commits lined up on my local machine, | validated, and ready to push to the master. | > But one seems to have accidentally got | > | > diff --git a/utils/haddock b/utils/haddock | > | > index 073d899..a3309e7 160000 | > | > --- a/utils/haddock | > | > +++ b/utils/haddock | > | > @@ -1 +1 @@ | > | > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b | > | > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a | > I did not want to meddle with Haddock. | > Question: how can I remove this change from my commit? I know how | to do git rebase –interactive, and I can aske to “edit” that commit… | but what then? | > Thanks | > Simon | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C6d4ef4135a94439fb54708d3 | e91ffd21%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=rNLWdOI3SNnfXPYj | PMHXC8U1l5sxI3eOwjHWaKpsBaY%3D&reserved=0 From takenobu.hs at gmail.com Fri Sep 30 11:13:35 2016 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 30 Sep 2016 20:13:35 +0900 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: Dear Moritz, Oh, thank you for teaching me. I'll write to it. Thanks, Takenobu 2016-09-30 20:06 GMT+09:00 Moritz Angermann : > Dear Takenobu, > > may I politely direct you to https://github.com/ghc- > proposals/ghc-proposals/pull/10, > and ask you to add your comments there as well, as that proposal tries to > track these > changes in a central place through the new ghc-proposal process. > > Cheers, > Moritz > > > On Sep 30, 2016, at 6:56 PM, Takenobu Tani > wrote: > > > > Hi, > > > > Richard said: > > (1) search engines still find out-of-date documentation > > (2) the wiki is not discoverable > > > > I know trac is treasure house. > > And I realized old pages are valuable for decision. > > > > > > My concrete suggestion is here: > > > > For (1): > > When we find out-of-date documentation, we directly modify head of the > document. > > We manually insert a comment like "This content is out-of-date for > GHC8.0". > > (New contributors easy can do it.) > > > > For (2): > > We provide manually-written multiple indexes for different views on a > portal page of the wiki site. > > Contributors could maintain each index themselves. > > (New comers will choose his favorite index for his exploring.) > > > > Furthermore, we provide a simple search box for multiple wiki sites. > > (Please wait for a while. I'll prepare simple-conceptual demonstration > with web.) > > > > > > Diversity is strength of Haskell community, > > Takenobu > > > > > > 2016-09-30 4:14 GMT+09:00 Richard Eisenberg : > > I've spent some time thinking about how and what to synthesize from this > conversation. Moritz has captured much of these ideas in the proposal he > submitted. Thanks. > > > > But that proposal tackles only one part of the problem: what to do in > the future. It does not address the insufficiencies of the wiki as it now > stands, and these drawbacks seem to be the dangling fibers of this thread. > Two specific complaints are that (1) search engines still find out-of-date > documentation and (2) the wiki is not discoverable. I agree with both of > these, but I can't think of any (easy) way to help either one. > > > > For (1), the "obvious" solution is to pull old pages. However, old pages > still serve as useful documentary evidence when we need to revisit a > decision made in the past. I think simply deleting out-of-date pages may > lose useful info. Could we remove the pages from the wiki but keep them > somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? > I wouldn't want to keep it somewhere private, lest it be unavailable to the > person that needs it. I think clearly labeling out-of-date info as such is > the best compromise. > > > > For (2), there is an index to the wiki: https://ghc.haskell.org/trac/ > ghc/wiki/TitleIndex It's long and rambly, but may be of use. I agree > that grepping would be nice. Does anyone know if there is a way to extract > plaintext from a Trac wiki? I agree that making such a feature available > would be helpful. In the future, though, even a git-backed collection will > run into discoverability problems, unless someone continually keeps it > organized. (It will be greppable, though.) > > > > As to the point of shoring up existing infra vs. looking more broadly: I > suppose I am interesting in shoring up the existing infra, but I'm > considering "existing infra" to include all the platforms I'm aware of. > This explicitly includes the idea of dropping, say, Trac entirely and > moving exclusively to GitHub. I think that would be a terrible idea, but > it's in scope in my thinking. What's *not* in scope (in my thinking) is the > idea of creating new tools that do exactly what we want. We're all > developers and can imagine wonderful things, but wonderful things do not > come cheaply, and we are but poor. > > > > So I'm at a loss of what to do about these remaining fibers. Concrete > suggestions, anyone? > > > > Richard > > > > -=-=-=-=-=-=-=-=-=-=- > > Richard A. Eisenberg > > Asst. Prof. of Computer Science > > Bryn Mawr College > > Bryn Mawr, PA, USA > > cs.brynmawr.edu/~rae > > > >> On Sep 29, 2016, at 7:37 AM, Takenobu Tani > wrote: > >> > >> Hi Carter, > >> > >> Thank you very much :) > >> > >> We love haskell, > >> Takenobu > >> > >> > >> 2016-09-28 22:29 GMT+09:00 Carter Schonwald >: > >> I like your perspective on this > >> > >> > >> On Wednesday, September 28, 2016, Takenobu Tani > wrote: > >> Apologies if I’m missing context. > >> > >> > >> Potential contributors need information from wiki. > >> > >> I feel current wiki’s problems are following: > >> > >> > >> (a) reachability > >> > >> "Where is the page I need?" > >> > >> > >> (b) outdated pages > >> > >> "Is this page up-to-date?" > >> > >> > >> (c) update method > >> > >> "How Can I update the page?" > >> > >> > >> > >> About (a): > >> > >> > >> It's difficult to find pages they need. Maybe reasons are following: > >> > >> * We have multiple wiki sites. > >> > >> * Desired contents structure is different for each member. > >> > >> > >> So single wiki site is not enough from latter. > >> > >> > >> Therefore, what about "a search system for multiple wiki sites"? > >> > >> > >> > >> About (b): > >> > >> > >> Haskell's evolution is fast. > >> > >> New contributor encounters sometimes outdated pages. > >> > >> But they don't still know how to correct them. > >> > >> > >> Therefore, what about putting "outdated mark" to the page by them? > >> > >> > >> They can easily contribute. > >> > >> And if possible, they send update request with any way. > >> > >> We’ll preferentially update many requested pages. > >> > >> > >> > >> About (c): > >> > >> > >> We have multiple wiki sites. Someone is unfamiliar about them. > >> > >> Github is one of the solutions for new contents. > >> > >> But I don't have idea about this for current contents. > >> > >> > >> Regards, > >> > >> Takenobu > >> > >> > >> > >> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : > >> I'm quite leery of using a new site (readthedocs.org), as it creates > yet another platform for contributors to understand. Reducing the number of > platforms has been a fairly clearly-stated goal of these recent > conversations, as I've read it. > >> > >> Despite agreeing that wikis are sometimes wonky, I thought of a solid > reason against moving: we lose the Trac integration. A Trac wiki page can > easily link to tickets and individual comments, and can use dynamic > features such as lists of active tickets. These are useful and well-used > features. I don't know what's best here, but thinking about the real loss > associated with moving away from these features gives me pause. > >> > >> Richard > >> > >> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: > >> > > >> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: > >> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: > >> >>> Yes, I agree with Michael’s observations in the blog post. However, > one > >> >>> thing that’s easier about a wiki is that the editing process is > much more > >> >>> lightweight than making a PR. > >> >>> > >> >>> But GitHub has a wonderful feature (that I have rarely used) that > >> >>> mitigates this problem. Viewing a file in GitHub offers a little > pencil > >> >>> icon in the top-right. It allows you to make arbitrary changes in > the > >> >>> file and then automates the construction of a PR. The owner of the > file > >> >>> can then accept the PR very, very easily. If the editor has commit > >> >>> rights, you can make your edits into a commit right away. No need to > >> >>> fork, pull and push. > >> >> > >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely > >> >> rendered and inter-linked pages *and* have the option for web-based > or > >> >> git-based editing. Though, based on my limited experience with GitHub > >> >> wikis, I wonder if they would scale to the size of GHC's wiki.. > >> > > >> > I agree, I don't think GitHub wikis are sufficient for GHC. We've > >> > tried using GitHub wikis, and found that they were clunkier than just > >> > having wiki / docs in your repo. GHC would probably want to have a > >> > separate docs repo, as otherwise the commit history will get filled > >> > with commits related to proposals, etc. > >> > > >> > It may be worth considering a similar approach with the GHC > >> > documentation. We've had great success in stack with using > >> > https://readthedocs.org/ . The way this works is that you have a > >> > branch that readthedocs points at ("stable"), which provides the > >> > current version to display. I realize that ghc would want to have > >> > multiple versions of the docs up, but I'm sure that's feasible. > >> > > >> > Github itself has pretty nice markdown rendering, and the ability to > >> > edit directly. Note that there is no GitHub lock-in here - it is just > >> > a collection of markdown files, organized however you like them. > >> > > >> > The risk with such a migration is that the old wiki(s?) don't get > >> > fully migrated and shut down. If that happens, then information will > >> > be even more spread out and hard to find. Perhaps we can use pandoc > >> > to automatically migrate much of the wiki content to markdown? It > >> > probably will not be a lossfree conversion. > >> > > >> >> There's also a tool called gitit (https://github.com/jgm/gitit) that > >> >> seems to offer the same set of features, but apparently with a more > >> >> traditional (and I assume customizable) layout. > >> >> > >> >> I think having the option for simple, immediate edits or > peer-reviewed > >> >> edits (the peer-review is much more important to me than having an > >> >> explicitly file-based system) would be a big win. Perhaps there's > even a > >> >> trac module that implements something like this? Then we could > decouple > >> >> it from the question/task of migrating the existing content > elsewhere. > >> >> > >> >> Eric > >> >> _______________________________________________ > >> >> ghc-devs mailing list > >> >> ghc-devs at haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ————————————————— > Moritz Angermann > +49 170 54 33 0 74 > moritz at lichtzwerge.de > > lichtzwerge GmbH > Raiffeisenstr. 8 > 93185 Michelsneukirchen > > Amtsgericht Regensburg HRB 14723 > Geschäftsführung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Sep 30 11:20:19 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 30 Sep 2016 16:50:19 +0530 Subject: git question In-Reply-To: References: <1475232726-sup-9478@sabre> Message-ID: When you do 'git rebase -i', to exclude the commit you can just delete that commit from the list of commits. -harendra On 30 September 2016 at 16:40, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Thanks... that worked. > > Somehow it ought to be possible to un-stage the haddock change rather that > carefully undo it manually. But it worked so I'm not complaining! > > Thank you > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Edward Z. Yang > | Sent: 30 September 2016 11:53 > | To: ghc-devs > | Subject: Re: git question > | > | Get to the commit you want to edit, then > | > | cd utils/haddock > | git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b > | cd ../.. > | git commit --amend -a > | > | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30 > | 10:47:24 +0000: > | > Friends > | > I have a batch of several commits lined up on my local machine, > | validated, and ready to push to the master. > | > But one seems to have accidentally got > | > > | > diff --git a/utils/haddock b/utils/haddock > | > > | > index 073d899..a3309e7 160000 > | > > | > --- a/utils/haddock > | > > | > +++ b/utils/haddock > | > > | > @@ -1 +1 @@ > | > > | > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b > | > > | > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a > | > I did not want to meddle with Haddock. > | > Question: how can I remove this change from my commit? I know how > | to do git rebase –interactive, and I can aske to “edit” that commit… > | but what then? > | > Thanks > | > Simon > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C6d4ef4135a94439fb54708d3 > | e91ffd21%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=rNLWdOI3SNnfXPYj > | PMHXC8U1l5sxI3eOwjHWaKpsBaY%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 30 11:21:45 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 11:21:45 +0000 Subject: git question In-Reply-To: References: <1475232726-sup-9478@sabre> Message-ID: Ah yes, but it had a lot of OTHER stuff that I wanted. It was only the accidental change to a submodule that I wanted to kill off. From: Harendra Kumar [mailto:harendra.kumar at gmail.com] Sent: 30 September 2016 12:20 To: Simon Peyton Jones Cc: Edward Z. Yang ; ghc-devs Subject: Re: git question When you do 'git rebase -i', to exclude the commit you can just delete that commit from the list of commits. -harendra On 30 September 2016 at 16:40, Simon Peyton Jones via ghc-devs > wrote: Thanks... that worked. Somehow it ought to be possible to un-stage the haddock change rather that carefully undo it manually. But it worked so I'm not complaining! Thank you Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 30 September 2016 11:53 | To: ghc-devs > | Subject: Re: git question | | Get to the commit you want to edit, then | | cd utils/haddock | git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b | cd ../.. | git commit --amend -a | | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30 | 10:47:24 +0000: | > Friends | > I have a batch of several commits lined up on my local machine, | validated, and ready to push to the master. | > But one seems to have accidentally got | > | > diff --git a/utils/haddock b/utils/haddock | > | > index 073d899..a3309e7 160000 | > | > --- a/utils/haddock | > | > +++ b/utils/haddock | > | > @@ -1 +1 @@ | > | > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b | > | > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a | > I did not want to meddle with Haddock. | > Question: how can I remove this change from my commit? I know how | to do git rebase –interactive, and I can aske to “edit” that commit… | but what then? | > Thanks | > Simon | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C6d4ef4135a94439fb54708d3 | e91ffd21%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=rNLWdOI3SNnfXPYj | PMHXC8U1l5sxI3eOwjHWaKpsBaY%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbouscal at gmail.com Fri Sep 30 14:18:29 2016 From: nbouscal at gmail.com (Nathan Bouscal) Date: Fri, 30 Sep 2016 15:18:29 +0100 Subject: git question In-Reply-To: References: <1475232726-sup-9478@sabre> Message-ID: You can unstage a change using 'git reset', e.g. 'git reset utils/haddock'. As part of an interactive rebase, my approach would be to 'edit' the commit in question, then use 'git reset HEAD^' to undo that commit but keep the changes in your working directory (but unstaged), then either stage the changes you do want to keep using 'git add', or stage everything using 'git add -A' and then unstage the haddock change with 'git reset utils/haddock', followed finally by creating a new commit and continuing the rebase. Hope this helps. -Nathan On Fri, Sep 30, 2016 at 12:21 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Ah yes, but it had a lot of OTHER stuff that I wanted. It was only the > accidental change to a submodule that I wanted to kill off. > > > > *From:* Harendra Kumar [mailto:harendra.kumar at gmail.com] > *Sent:* 30 September 2016 12:20 > *To:* Simon Peyton Jones > *Cc:* Edward Z. Yang ; ghc-devs > *Subject:* Re: git question > > > > When you do 'git rebase -i', to exclude the commit you can just delete > that commit from the list of commits. > > > > -harendra > > > > On 30 September 2016 at 16:40, Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Thanks... that worked. > > Somehow it ought to be possible to un-stage the haddock change rather that > carefully undo it manually. But it worked so I'm not complaining! > > Thank you > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Edward Z. Yang > | Sent: 30 September 2016 11:53 > | To: ghc-devs > | Subject: Re: git question > | > | Get to the commit you want to edit, then > | > | cd utils/haddock > | git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b > | cd ../.. > | git commit --amend -a > | > | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30 > | 10:47:24 +0000: > | > Friends > | > I have a batch of several commits lined up on my local machine, > | validated, and ready to push to the master. > | > But one seems to have accidentally got > | > > | > diff --git a/utils/haddock b/utils/haddock > | > > | > index 073d899..a3309e7 160000 > | > > | > --- a/utils/haddock > | > > | > +++ b/utils/haddock > | > > | > @@ -1 +1 @@ > | > > | > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b > | > > | > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a > | > I did not want to meddle with Haddock. > | > Question: how can I remove this change from my commit? I know how > | to do git rebase –interactive, and I can aske to “edit” that commit… > | but what then? > | > Thanks > | > Simon > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h > | askell.org > > %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com > > %7C6d4ef4135a94439fb54708d3 > | e91ffd21%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=rNLWdOI3SNnfXPYj > | PMHXC8U1l5sxI3eOwjHWaKpsBaY%3D&reserved=0 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 30 15:29:47 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 15:29:47 +0000 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: Alejandro: excellent point. I mis-spoke before. In my proposal we WILL allow types like (Tree (forall a. a->a)). I’m trying to get round to writing a proposal (would someone else like to write it – it should be short), but the idea is this: When you have -XImpredicativeTypes · You can write a polytype in a visible type argument; eg. f @(forall a. a->a) · You can write a polytype as an argument of a type in a signature e.g. f :: [forall a. a->a] -> Int And that’s all. A unification variable STILL CANNOT be unified with a polytype. The only way you can call a polymorphic function at a polytype is to use Visible Type Application. So using impredicative types might be tiresome. E.g. type SID = forall a. a->a xs :: [forall a. a->a] xs = (:) @SID id ( (:) @SID id ([] @ SID)) In short, if you call a function at a polytype, you must use VTA. Simple, easy, predictable; and doubtless annoying. But possible. Simon From: Alejandro Serrano Mena [mailto:trupill at gmail.com] Sent: 26 September 2016 08:13 To: Simon Peyton Jones Cc: ghc-users at haskell.org; ghc-devs at haskell.org Subject: Re: Getting rid of -XImpredicativeTypes What would be the story for the types of the arguments. Would I be allowed to write the following? > f (lst :: [forall a. a -> a]) = head @(forall a. a -> a) lst 3 Regards, Alejandro 2016-09-25 20:05 GMT+02:00 Simon Peyton Jones via ghc-devs >: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 30 16:36:33 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 16:36:33 +0000 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> Message-ID: rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] Sent: 30 September 2016 17:31 To: Simon Peyton Jones Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Fri Sep 30 16:39:15 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 30 Sep 2016 11:39:15 -0500 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> Message-ID: It's a bit tricky, you have to follow these steps: Click the commit link in the email: https://phabricator.haskell.org/rGHC3f27237b0e6d Click the build link on the commit page: B11120: rGHC3f27237b0e6d: Make tcrun042 fail ! Click another build link on the build page: [GHC] Linux/amd64: Continuous Integration Then you're here: https://phabricator.haskell.org/harbormaster/build/13355/ which has the build output. On Fri, Sep 30, 2016 at 11:36 AM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > rn003 is failing apparently (see below) > > But it’s fine on my machine. I don’t know how to see the actual error > message. > > > > Any ideas? > > > Simon > > > > *From:* noreply at phabricator.haskell.org [mailto:noreply at phabricator. > haskell.org] > *Sent:* 30 September 2016 17:31 > *To:* Simon Peyton Jones > *Subject:* [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail > > > > Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! > > > > *BRANCHES* > > master > > > > *USERS* > > simonpj (Author) > O7 (Auditor) > > > > *COMMIT* > > https://phabricator.haskell.org/rGHC3f27237b0e6d > > > > *EMAIL PREFERENCES* > > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > > > *To: *simonpj, Harbormaster > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 30 16:43:35 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Sep 2016 16:43:35 +0000 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> Message-ID: Thanks Chris, that’s helpful. I got to your final link, but it didn’t show me what rn003 did. There seem to be two logs for some reason. I tried clicking “Unlimited” lines, but I still didn’t see a clear failure from rn003. Does it fail for anyone else? From: Christopher Allen [mailto:cma at bitemyapp.com] Sent: 30 September 2016 17:41 To: Simon Peyton Jones Subject: Re: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail For some contrast, at work if I get notification that a build failed, if I click the Red X in the Github PR I go straight to the build and its output. (Screenshot attached of where it takes me) On Fri, Sep 30, 2016 at 11:39 AM, Christopher Allen > wrote: It's a bit tricky, you have to follow these steps: Click the commit link in the email: https://phabricator.haskell.org/rGHC3f27237b0e6d Click the build link on the commit page: B11120: rGHC3f27237b0e6d: Make tcrun042 fail! Click another build link on the build page: [GHC] Linux/amd64: Continuous Integration Then you're here: https://phabricator.haskell.org/harbormaster/build/13355/ which has the build output. On Fri, Sep 30, 2016 at 11:36 AM, Simon Peyton Jones via ghc-devs > wrote: rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] Sent: 30 September 2016 17:31 To: Simon Peyton Jones > Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Chris Allen Currently working on http://haskellbook.com -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Fri Sep 30 17:22:48 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Sat, 1 Oct 2016 02:22:48 +0900 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> Message-ID: It works for me. There are two logs because one corresponds to stdout and the other to stderr. I'm not sure if that distinction is present on Windows. It so happens that the test runner uses stdout, so that's the interesting one. Searching for the test name reveals: Timeout happened...killed process "cd "/tmp/ghctest-wSvwjx/test spaces/./rename/should_compile/rn003.run" && "/var/drydock/workingcopy-13/repo/glasgow-haskell-compiler/bindisttest/install dir/bin/ghc" -c rn003.hs -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups "... Which can mean one of the these things: 1) The test legitimately got slower or loops, resulting in a timeout 2) Harbormaster machine was slightly overloaded when running this test 3) This test is flaky The fact that it works on my machine (with DEBUG even!) suggests that 1) is unlikely. There's another commit being tested right now (see the top of https://phabricator.haskell.org/diffusion/GHC/history/master/), unless the test fails on that as well, I would classify this as infra failure. 2016-10-01 1:43 GMT+09:00 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > Thanks Chris, that’s helpful. I got to your final link, but it didn’t > show me what rn003 did. There seem to be two logs for some reason. I > tried clicking “Unlimited” lines, but I still didn’t see a clear failure > from rn003. > > > > Does it fail for anyone else? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 30 17:26:28 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 30 Sep 2016 13:26:28 -0400 Subject: How, precisely, can we improve? In-Reply-To: References: <7D482DF4-9AF7-4F41-8406-06247028F808@gmail.com> <6BBCE6FC-D792-43FB-8291-2BCE2AF744A0@lichtzwerge.de> <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: We all do!. And I really appreciate your clear positive suggestions around "what are we trying to understand or ask our selves" no matter what conclusions we come to this day / month / year, its something we will need to revisit (and should) every once in a while. change happens, as does "growth" (for various notions of growth :) ) On Sep 29, 2016 7:37 AM, "Takenobu Tani" wrote: > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani >> wrote: >> >>> Apologies if I’m missing context. >>> >>> >>> >>> Potential contributors need information from wiki. >>> >>> I feel current wiki’s problems are following: >>> >>> >>> >>> (a) reachability >>> >>> "Where is the page I need?" >>> >>> >>> >>> (b) outdated pages >>> >>> "Is this page up-to-date?" >>> >>> >>> >>> (c) update method >>> >>> "How Can I update the page?" >>> >>> >>> >>> >>> >>> About (a): >>> >>> >>> >>> It's difficult to find pages they need. Maybe reasons are following: >>> >>> * We have multiple wiki sites. >>> >>> * Desired contents structure is different for each member. >>> >>> >>> >>> So single wiki site is not enough from latter. >>> >>> >>> >>> Therefore, what about "a search system for multiple wiki sites"? >>> >>> >>> >>> >>> >>> About (b): >>> >>> >>> >>> Haskell's evolution is fast. >>> >>> New contributor encounters sometimes outdated pages. >>> >>> But they don't still know how to correct them. >>> >>> >>> >>> Therefore, what about putting "outdated mark" to the page by them? >>> >>> >>> >>> They can easily contribute. >>> >>> And if possible, they send update request with any way. >>> >>> We’ll preferentially update many requested pages. >>> >>> >>> >>> >>> >>> About (c): >>> >>> >>> >>> We have multiple wiki sites. Someone is unfamiliar about them. >>> >>> Github is one of the solutions for new contents. >>> >>> But I don't have idea about this for current contents. >>> >>> >>> >>> Regards, >>> >>> Takenobu >>> >>> >>> >>> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >>> >>>> I'm quite leery of using a new site (readthedocs.org), as it creates >>>> yet another platform for contributors to understand. Reducing the number of >>>> platforms has been a fairly clearly-stated goal of these recent >>>> conversations, as I've read it. >>>> >>>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>>> reason against moving: we lose the Trac integration. A Trac wiki page can >>>> easily link to tickets and individual comments, and can use dynamic >>>> features such as lists of active tickets. These are useful and well-used >>>> features. I don't know what's best here, but thinking about the real loss >>>> associated with moving away from these features gives me pause. >>>> >>>> Richard >>>> >>>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >>>> > >>>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >>>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>>> one >>>> >>> thing that’s easier about a wiki is that the editing process is >>>> much more >>>> >>> lightweight than making a PR. >>>> >>> >>>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>>> pencil >>>> >>> icon in the top-right. It allows you to make arbitrary changes in >>>> the >>>> >>> file and then automates the construction of a PR. The owner of the >>>> file >>>> >>> can then accept the PR very, very easily. If the editor has commit >>>> >>> rights, you can make your edits into a commit right away. No need to >>>> >>> fork, pull and push. >>>> >> >>>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>>> >> rendered and inter-linked pages *and* have the option for web-based >>>> or >>>> >> git-based editing. Though, based on my limited experience with GitHub >>>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>>> > >>>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>>> > tried using GitHub wikis, and found that they were clunkier than just >>>> > having wiki / docs in your repo. GHC would probably want to have a >>>> > separate docs repo, as otherwise the commit history will get filled >>>> > with commits related to proposals, etc. >>>> > >>>> > It may be worth considering a similar approach with the GHC >>>> > documentation. We've had great success in stack with using >>>> > https://readthedocs.org/ . The way this works is that you have a >>>> > branch that readthedocs points at ("stable"), which provides the >>>> > current version to display. I realize that ghc would want to have >>>> > multiple versions of the docs up, but I'm sure that's feasible. >>>> > >>>> > Github itself has pretty nice markdown rendering, and the ability to >>>> > edit directly. Note that there is no GitHub lock-in here - it is just >>>> > a collection of markdown files, organized however you like them. >>>> > >>>> > The risk with such a migration is that the old wiki(s?) don't get >>>> > fully migrated and shut down. If that happens, then information will >>>> > be even more spread out and hard to find. Perhaps we can use pandoc >>>> > to automatically migrate much of the wiki content to markdown? It >>>> > probably will not be a lossfree conversion. >>>> > >>>> >> There's also a tool called gitit (https://github.com/jgm/gitit) that >>>> >> seems to offer the same set of features, but apparently with a more >>>> >> traditional (and I assume customizable) layout. >>>> >> >>>> >> I think having the option for simple, immediate edits or >>>> peer-reviewed >>>> >> edits (the peer-review is much more important to me than having an >>>> >> explicitly file-based system) would be a big win. Perhaps there's >>>> even a >>>> >> trac module that implements something like this? Then we could >>>> decouple >>>> >> it from the question/task of migrating the existing content >>>> elsewhere. >>>> >> >>>> >> Eric >>>> >> _______________________________________________ >>>> >> ghc-devs mailing list >>>> >> ghc-devs at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> > _______________________________________________ >>>> > ghc-devs mailing list >>>> > ghc-devs at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Sep 30 17:34:56 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 30 Sep 2016 13:34:56 -0400 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> Message-ID: <87bmz5cmv3.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > rn003 is failing apparently (see below) > But it’s fine on my machine. I don’t know how to see the actual error message. > It works for me as well. The Harbormaster failure is quite odd: tc042 appears to fail with, Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( tcrun042.hs, tcrun042.o ) tcrun042.hs:5:5: error: • Couldn't match expected type ‘forall c. c -> c -> c’ with actual type ‘b0 -> b0 -> b0’ • In the expression: (, "Hello" ++ "World",) In an equation for ‘e’: e = (, "Hello" ++ "World",) *** unexpected failure for tcrun042(normal) I don't see how this could fail in a environment-sensitive manner. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Fri Sep 30 17:37:30 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 30 Sep 2016 13:37:30 -0400 Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail In-Reply-To: <87bmz5cmv3.fsf@ben-laptop.smart-cactus.org> References: <20160930163123.20991.5987.0DFFE0AE@phabricator.haskell.org> <87bmz5cmv3.fsf@ben-laptop.smart-cactus.org> Message-ID: <878tu9cmqt.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > [ Unknown signature status ] > Simon Peyton Jones via ghc-devs writes: > >> rn003 is failing apparently (see below) >> But it’s fine on my machine. I don’t know how to see the actual error message. >> > It works for me as well. > > The Harbormaster failure is quite odd: tc042 appears to fail with, > Oh dear, ignore me. I missed the fact that this was marked as expect_fail in a later commit. It looks like rn003 failed with a timeout. It's unclear what causes this but it's not the first time I've seen it during a Harbormaster build. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From spam at scientician.net Fri Sep 30 17:58:34 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 30 Sep 2016 19:58:34 +0200 Subject: How, precisely, can we improve? In-Reply-To: References: <1474990356.4064381.738574073.34877450@webmail.messagingengine.com> <1F34D095-6E7F-44B1-B47F-AA7E9CEFBEAC@cs.brynmawr.edu> <1474993116.4076453.738641009.0E1FACB7@webmail.messagingengine.com> <62BFC158-B5B6-4C65-9D24-7BB064DEF696@cs.brynmawr.edu> Message-ID: On 2016-09-30 19:26, Carter Schonwald wrote: > We all do!. I dont. (Sorry, just had to put that Monty Python joke in there. At least I *think* it was MP?) Obviously, yes, we all *really* *REALLY* like Haskell, otherwise we wouldn't be arguing about it, would we? ;) Regards, From baldurpet at gmail.com Fri Sep 30 22:36:47 2016 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Fri, 30 Sep 2016 22:36:47 +0000 Subject: Getting rid of -XImpredicativeTypes In-Reply-To: References: Message-ID: Shot in the dark: Would extensions like QuantifiedConstraints or ImplicationConstraints, if implemented, help with ImpredicativeTypes? 2016-09-30 15:29 GMT+00:00 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > Alejandro: excellent point. I mis-spoke before. In my proposal we WILL > allow types like (Tree (forall a. a->a)). > > > > I’m trying to get round to writing a proposal (would someone else like to > write it – it should be short), but the idea is this: > > > > *When you have -XImpredicativeTypes* > > · *You can write a polytype in a visible type argument; eg. f > @(forall a. a->a)* > > · *You can write a polytype as an argument of a type in a > signature e.g. f :: [forall a. a->a] -> Int* > > > > *And that’s all. A unification variable STILL CANNOT be unified with a > polytype. The only way you can call a polymorphic function at a polytype > is to use Visible Type Application.* > > > > *So using impredicative types might be tiresome. E.g.* > > * type SID = forall a. a->a* > > > > * xs :: [forall a. a->a]* > > * xs = (:) @SID id ( (:) @SID id ([] @ SID))* > > > > *In short, if you call a function at a polytype, you must use VTA. > Simple, easy, predictable; and doubtless annoying. But possible*. > > > > Simon > > > > *From:* Alejandro Serrano Mena [mailto:trupill at gmail.com] > *Sent:* 26 September 2016 08:13 > *To:* Simon Peyton Jones > *Cc:* ghc-users at haskell.org; ghc-devs at haskell.org > *Subject:* Re: Getting rid of -XImpredicativeTypes > > > > What would be the story for the types of the arguments. Would I be allowed > to write the following? > > > f (lst :: [forall a. a -> a]) = head @(forall a. a -> a) lst 3 > > Regards, > > Alejandro > > > > 2016-09-25 20:05 GMT+02:00 Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org>: > > Friends > > > > GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to > support impredicative polymorphism. But it is vestigial…. if it works, > it’s really a fluke. We don’t really have a systematic story here at all. > > > > I propose, therefore, to remove it entirely. That is, if you use > -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. > complete no-op) and you should remove it. > > > > Before I pull the trigger, does anyone think they are using it in a > mission-critical way? > > > > Now that we have Visible Type Application there is a workaround: if you > want to call a polymorphic function at a polymorphic type, you can > explicitly apply it to that type. For example: > > > > {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} > > module Vta where > > f x = id @(forall a. a->a) id @Int x > > > > You can also leave out the @Int part of course. > > > > Currently we have to use -XImpredicativeTypes to allow the @(forall a. > a->a). Is that sensible? Or should we allow it regardless? I rather > think the latter… if you have Visible Type Application (i.e. > -XTypeApplications) then applying to a polytype is nothing special. So I > propose to lift that restriction. > > > > I should go through the GHC Proposals Process for this, but I’m on a > plane, so I’m going to at least start with an email. > > > > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: