Ian leaving and the glorious future

[Richard Eisenberg]

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.

Richard

On 2013-08-09 11:13, Yuri de Wit wrote:
> Richard,
> 
> 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>
> wrote:
> 
>> OK -- the page is up at
>> http://ghc.haskell.org/trac/ghc/wiki/Newcomers [1]   Please improve
>> it as you see fit!
>> 
>> Richard
>> 
>> 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
>> ICFP.
>> 
>> 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
>> low
>> hanging fruits for newcomers. I think it's very worthwhile, and
>> have
>> 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
>> curate
>> the second half part of the list.
> 
>  _______________________________________________
>  ghc-devs mailing list
>  ghc-devs at haskell.org
>  http://www.haskell.org/mailman/listinfo/ghc-devs [2]
> 
> 
> 
> Links:
> ------
> [1] http://ghc.haskell.org/trac/ghc/wiki/Newcomers
> [2] http://www.haskell.org/mailman/listinfo/ghc-devs