Code updates, and change discussion

[chr...@gmail.com]

Hi everyone

I've joined only on the last meeting. I've pushed Luigis and my work (we paired up) to:

 https://github.com/pflanze/LambdaWars

(Luigi: if you want to see the original history, it's there, too, as the tag drop_patchtool_Thu_Mar_21_112306_GMT_2013.)

This includes changes to allow the code to be run from ghci. From an Emacs started from the base directory, run "C-u M-x run-haskell ./run-ghci", then it should just work (use "C-c C-l" from an open *.hs file to load it there).

== Change discussion==

For those who weren't there, we had a discussion about changes to make it more attractive for people to join. I didn't participate in that discussion much because that was my first time, but really I wasn't sure about why to change much of anything. The suggestions for changes in the code base were good (make it loadable from ghci, now +- done, perhaps restructure the code more logically?, design document, split core from UI and make individual pieces testable separately, ..). I think those don't need a restart. Refactoring may be worth the time because I'll learn what was there and why it didn't fit? But if you've got good ideas about how to restart, that may look fine to me too.

Basically I'm just a bit: I'm mostly a newbie, too, and I'm fine with what's there, so why should it be changed to be made more newbie friendly? I haven't coded on the core yet, though; will there really be unexpected unfriendly issues for me? Is there a reason other people didn't stay that can be solved now (through a restart)? If so, then fine with me, of course.

There were other suggestions which I think make a lot of sense. I'll restate those that I've already made at the meeting:

* I'll be happy volunteering to write a document explaining the code base (a HACKING.txt or .md).

* I've offered to pair up with Tim (for him) to prepare a talk about Automatons; I don't know anything about them currently but would be interested to learn and might be able to help shape the talk by discussing it. If it's not over my head I might also do the actual talk if Tim doesn't have the time/energy/inclination to do it.

and I'll add those:

* 2 hours feels awfully short for doing real work during a meeting. I'd be happy to come during weekends instead, for e.g. two 3 hour blocks with a lunch break inbetween. And have the (short, 15(-30)' I would suggest) talks at the beginning of each meeting about something concerning the project, as someone has suggested already. Otherwise I guess the meetings really need to concentrate on discussion and coordination and actual coding needs to be done between them. Which I'm ok with, too; I wonder if we could find some preferred working times then and join an IRC chatroom, though?

* If there's a need to learn how to use Git (in the context of this work), I can offer to give a short talk. (I'm thinking of something rather interactive, find out and explain what's not known or clear. I know Git rather well. Haven't done a talk about it before, though.)


Note: I'll probably be away from London two times (for about a weak each time) during April.

Christian.