Ian leaving and the glorious future
eir at cis.upenn.edu
Fri Aug 9 15:01:40 CEST 2013
I've had to deal with the stage 1 compiler for two different reasons:
- I check out a new tree to work on a new task, and I forget to build
before modifying the code.
- I'm working on a tree with a working stage-1 compiler, but then I
change the interface file format. After the stage-2 compiler builds, it
can't do anything because it can't read any of the libraries.
Another nice benefit of working on stage 1 is that I can put off dealing
with Template Haskell until the core functionality is working.
I always get a little confused with the git commands to generate patches
in just the right way. If someone else feels confident about this, you
can add the section -- I agree it would be an improvement.
On 2013-08-09 11:13, Yuri de Wit wrote:
> thanks for this! One item that probably deserves it's own section is
> how to generate and submit a patch.
> And as an aside question, when would one need to compile state 1 vs
> stage 2 (aside from the first compilation)?
> On Fri, Aug 9, 2013 at 6:56 AM, Richard Eisenberg <eir at cis.upenn.edu>
>> OK -- the page is up at
>> http://ghc.haskell.org/trac/ghc/wiki/Newcomers  Please improve
>> it as you see fit!
>> On 2013-08-06 07:04, Vincent Hanquez wrote:
>> On 08/05/2013 10:51 AM, Richard Eisenberg wrote:
>> I think a hacking session is a great idea, either over IRC or at
>> I'm also thinking about how to foster involvement from newcomers on
>> a more continual basis. Every several months, someone posts saying,
>> essentially "I'd like a project. Give me one." The answers seem to
>> be, "Find an interesting ticket and fix it." The problem is that,
>> often, the *interesting* tickets are the ones that newcomers would
>> have a hard time with. What if there were a page with a curated list
>> of newcomer-friendly tickets? Every few weeks, I see a bug come up
>> that looks easy enough to fix, but very non-critical. I would be
>> happy to set up this page and serve as its maintainer. I would want
>> to add a link to it from the main "working on GHC" wiki page, so
>> it's easy for newcomers to find. The idea would be that a newcomer
>> fixes a few tickets there, and then has enough knowledge to tackle
>> something harder.
>> I think that's exactly what i was describing with having a list of
>> hanging fruits for newcomers. I think it's very worthwhile, and
>> this list refreshed every few weeks make it probably even better.
>> The piece of this that I would help with is that I'm only familiar
>> with the first stages of the compiler (to varying degrees): lexing,
>> parsing, renaming, typechecking, desugaring, Core, and a bit of the
>> simplifier. After that (optimizations, code generation, cmm, stg,
>> ...) is a murky haze to me.
>> Do we think such a page is a good idea? As I said, I'm happy to
>> write it and maintain it, as well as serve as an email contact to
>> people who want to contribute and want help. And, is there someone
>> willing to curate the part of the page (and perhaps answer email)
>> about the "second half" of ghc?
>> I'm by no mean an expert in code generation and lower layers, but
>> unless someone more knowledgeable want to do that, I can help
>> the second half part of the list.
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs 
>  http://ghc.haskell.org/trac/ghc/wiki/Newcomers
>  http://www.haskell.org/mailman/listinfo/ghc-devs
More information about the ghc-devs