IRC_Meetings: ghc-meeting-2008-07-30.log

File ghc-meeting-2008-07-30.log, 28.4 KB (added by nominolo, 6 years ago)

ghc meeting 2008-07-30

Line 
117:00 < JaffaCake> welcome all
217:01 < JaffaCake> so shall we start with the build system issues that rl raised?
317:01              >>> Judith!n=rohloff@luthien.uebb.cs.tu-berlin.de
417:01 <       rl_> i didn't want to take over the meeting...
517:02 < JaffaCake> no problem! we don't have to take the whole hour
617:02 < JaffaCake> rl: so in what way does Cabal not have the necessary functionality, as you said in your message?
717:02 <     Igloo> OK; I don't think that trying to implement all the functionality in Cabal before actually using any of it is feasible
817:02 <   dcoutts> http://www.haskell.org/pipermail/glasgow-haskell-users/2008-July/015115.html
917:02 < lambdabot> Title: Build system woes, http://tinyurl.com/5mrz4e
1017:03 <     Igloo> It's only when you actually start to try to do things that you realise you also need to be able to do X
1117:03 <     Igloo> Also, if no-one is trying to do X, then no-one will be adding support for X in Cabal
1217:03 <       rl_> right
1317:03 <       rl_> but perhaps that could be done in a branch?
1417:03 <       ndm> there is also the general tension that anyone trying to do stuff in a Setup.hs file will have it broken
1517:03              >>> TuringTest!n=TuringTe@pamac-cek10.st-and.ac.uk
1617:03 <   dcoutts> that's true, Cabal development is pretty much reactive not proactive. We respond to requests for features.
1717:04 <       rl_> since it involves a lot of experiments
1817:04 < JaffaCake> having a single shared build system for everyone is a good thing
1917:04 <   dcoutts> ndm: though only if they're using the devel version of Cabal and using black magic. The API of releases is stable (and mostly compatible eg 1.2 -> 1.4)
2017:04 <     Igloo> Doing it in a branch doesn't help me find the cases that my machines don't cover
2117:05 <   dcoutts> having more machines to run validate on might help
2217:05 <       rl_> dcoutts: validate is not the only problem
2317:05 <   dcoutts> eg if Igloo could validate on his box, and fire off jobs on OSX, Windows etc
2417:05 <  nominolo> or, a branch before 'head'?
2517:05 < JaffaCake> dcoutts: I think it would help to some degree, but we still have no clue how to fix bizarre linker errors that occur on OS X
2617:05 <       rl_> does anyone apart from the guys hacking Cabal & build system understand how it all works?
2717:06 <  nominolo> rl_: did you have one for the Make-based system?
2817:06 <  malcolmw> ghc-'s build system has always been a little baroque, so has anyone ever understood it fully?
2917:06 <      BSP_> personally i view the build system as a black box
3017:06 <   dcoutts> JaffaCake: we figured out the last one ok, just took a while. If we'd known it didn't validate we could have done that discovery process without it remaining broken on OSX.
3117:07 <       rl_> well, a Makefile-based system is at least somewhat modular
3217:07 < JaffaCake> rl_: I didn't understand how the new build system for GHC worked until I looked at it last week
3317:07 <       rl_> I know how make will be called in my subdirectory
3417:07              <   jyp!n=jyp@dhcp2-225152.cs.chalmers.se ["Leaving"]
3517:08 <       ndm> i've always wondered why there isn't a pending repo, and patches get moved from pending to branch after a the buildbots kick in? might ensure you never end up with validation failures
3617:08 < JaffaCake> dcoutts: I'm referring to the latest one, scattered reloc r_address too large for inferred architecture i386
3717:08 <   dcoutts> JaffaCake: oh 'k
3817:08 < JaffaCake> wtf? :)
3917:08 <  nominolo> ndm: yup, but that only works well if we have build bots for all platforms
4017:08 <       rl_> JaffaCake: I'm going to look into this one
4117:08 <      BSP_> do we have an os x buildbot?
4217:08 <       ndm> nominolo: which are you lacking?
4317:08 <      BSP_> maybe we should all chip in and get GHC HQ a mac mini :)
4417:09 <    judahj> JaffaCake: I'm also making some progress in tracking down that issue
4517:09 <  nominolo> osx 10.4
4617:09 <       ndm> thorkilnaur is bound to offer a OS X buildbot if asked
4717:09 < JaffaCake> BSP_: money is not the issue, time is
4817:09 < JaffaCake> judahj: great!
4917:09 <  nominolo> ndm: he has a buildbot, but it's PPC and it's too slow -- it times out
5017:10 <  malcolmw> heh, google's results for "scattered reloc r_address too large for inferred architecture" all point to ghc bug trackers...
5117:11 <  Deewiant> one's for eiffel
5217:12 < JaffaCake> rl_: so as I understand it you need to add functionality to Cabal for dph?
5317:12 <   simonpj> My sense is that part of the difficulty is that it's hard to know where to start if something goes wrong.  It'd be a real help to have some kind of overview documentation.  The kind of thing in this email http://www.haskell.org/pipermail/glasgow-haskell-users/2008-July/015117.html is fantastically helpful.  I understand that writing documentation is no fun, esp if the system is in flux, but perhaps we are under-investing in wiki-docs for th
5417:12 < lambdabot> Title: Build system woes, http://tinyurl.com/5nquas
5517:12 <       rl_> JaffaCake: yes
5617:13 <   dcoutts> really, dph needs support in a build system for building libs in multiple 'ways' par, seq
5717:13              gbeshers wonders what dph is...
5817:13 <   dcoutts> which is slightly more general than the old/current ghc build system notion of ways
5917:13 <   simonpj> data parallel haskell
6017:13 <   dcoutts> since it applies to dependent packages too
6117:13 <       rl_> dcoutts: no only libs, I expect that every app which uses dph will want to allow the user to select the backend
6217:13 < JaffaCake> ok, so this is something completely new that we haven't needed before
6317:13 <   dcoutts> rl_: right, every package
6417:14 <   dcoutts> every package that depends on dph needs support for building in two flavours/ways
6517:14 <   dcoutts> and said libs need to be parallel-installable
6617:14 <  nominolo> simonpj: you got cut off in your previous message
6717:14 <       rl_> n ways, we are going to add more in the future (hopefully)
6817:14 <  nominolo> "... in wiki-docs for th"
6917:14 <   dcoutts> and neither the existing ghc build system or Cabal support that yet
7017:14 <       ndm> dcoutts: this seems very similar to the profiling/not distinction as well, and we only need a few people to give a few ways and we get combinatorial explosion
7117:15 < JaffaCake> Igloo said he'd update the wiki when things have settled down
7217:15 <       rl_> but really, my point is that I don't want to have to ask igloo & dcoutts to implement every little thing we need
7317:15 < JaffaCake> IIRC
7417:15 <       ndm> but the profile/not stuff could be reused
7517:15 <  gbeshers> Actually, could I argue for both NUMA and cluster to make it 4 ways.
7617:15 <   dcoutts> ndm: yes it is similar to profiling, and ideally we could have one mechanism that covers them both
7717:15 <   simonpj> nominolo: ...under-investing in wiki-docs for the build system?  Better docs might reduce the feeling of helplessness in the face of failure that I sense Roman emanating.
7817:15              malcolmw recalls when nhc98 had combinable profiling, time-profiling, and tracing ways.  it was difficult to maintain
7917:16 <   dcoutts> rl_: ways isn't a little thing of course, adding hidden packages is easy and something you could do yourself
8017:16 < JaffaCake> dcoutts_: and shared/not-shared
8117:16 <   dcoutts> JaffaCake: right
8217:16 <       rl_> dcoutts: how?
8317:16 < JaffaCake> I've been thinking about that actually
8417:16 <       ndm> the profiling thing is already quite annoying, i often have to go back and reinstall a pile of libraries when i decide to profile soemthing
8517:16 <   dcoutts> rl_: send patches to Cabal (preferred) or implement it in Setup.hs for individual packages
8617:17 <   dcoutts> JaffaCake: and then the ability to install some flavours only and track which flavours are installed for all packages. It's not trivial.
8717:17 <       rl_> but I don't have the time to get into Cabal hacking
8817:17 <  nominolo> simonpj: thanks.
8917:17 <       rl_> and I have no idea how to do it in Setup.hs in a stable way
9017:17 < JaffaCake> rl_: but it's just the build system, you'd have to hack it anyway
9117:17 <  nominolo> who could provide more documentation?  dcoutts, Igloo ?
9217:18 <       rl_> JaffaCake: for me, the build system is the stuff in the ghc repo
9317:18 <       rl_> the stuff in the Cabal repo is like make
9417:18 <   dcoutts> that part of the Cabal code is pretty self explanatory, for the feature of allowing hidden packages anyone could do it using copy & paste
9517:18 <  nominolo> Cabal is in /ghc/libraries/Cabal ;)
9617:18 <       rl_> I shouldn't have to hack that
9717:18 <       rl_> it's a lot of code
9817:18              >>> tibell!n=tibell@193.142.125.1
9917:18 < JaffaCake> rl_: the division isn't the same: Cabal is make + a bunch of rules for building stuff that we all share
10017:19 <       rl_> dcoutts: I don't even know *which* part of the code to look at
10117:19 <   dcoutts> rl_: grep would work pretty well
10217:19 <       rl_> grep for what?
10317:20 <  nominolo> also, there's a high-level overview of cabal
10417:20 <   simonpj> rl_: is the problem this?  If you need to extend Cabal by writing code in Setup.hs, you need to be familiar with the Cabal API, not the Cabal user manual.  And you aren't.
10517:20 <       rl_> but really, having to hack the build system *and* Cabal is much more complicated than just a bunch of makefiles
10617:20 <     Igloo> FWIW, I think how you feel about Cabal is the same as a lot of people felt about the old mk/ and Makfiles scattered through the tree
10717:21 <     Igloo> It's just that you're familiar with the old build system
10817:21 <   simonpj> ...presumably the Cabal implementors have in mind some modules that you are expected to call; and vast tracts of internals that
10917:21 <       rl_> simonpj: the things that I need usually can't be done by Setup.hs
11017:21 <   simonpj> ...that someone adding to Setup.hs would not need to.
11117:21 <       rl_> anyway
11217:21 <   simonpj> rl_: oh.  Darn.  That's the Cabal extension mechanism.
11317:22 < JaffaCake> rl_: so partly the problem is that Cabal is more general than just "the GHC build system", so it's inherently bigger and more complex
11417:22 <       rl_> I'm not arguing that we should go back to makefiles
11517:22 <       rl_> but if I want to change something
11617:22 <       ndm> I think the movement is away from custom setup files, and it seems that often its a particularly trick thing to do, as its not been done before
11717:22 <       rl_> then "somewhere in libraries/Cabal" isn't a very precise location
11817:22 <  malcolmw> it might be helpful to have some specific examples of the kind of thing you need to do, that Setup.lhs cannot help with.
11917:22 <       ndm> for example, there is a Test hook, and I think I was the first ever user of it, and its broken at least once, and provides nearly nothing
12017:23 <   dcoutts> rl_: right, anything apart from the 'ways' and the hidden by default?
12117:23 <       ndm> i think a list of examples of Setup.hs files an the kind of things it can do would be useful
12217:23 <       rl_> dcoutts: probably
12317:23 <       rl_> we will have to vectorise all libs eventually, for instance
12417:24 <       rl_> including base
12517:24 <       rl_> and that might lead to funny dependencies
12617:24 <       rl_> as in base -> dph -> vectorised base
12717:24 <       rl_> (perhaps, I don't know yet)
12817:24 <  malcolmw> rl_: right, that is a problem we came across for the Hat tracer too (and have not solved)
12917:24 < JaffaCake> hmm
13017:25 <  gbeshers> rl_: you are missing build environment vs. the environment being built are you not?
13117:25 <       rl_> i think so
13217:25 < JaffaCake> rl_: so it sounds like there's some design work to be done before we can even modify the build system
13317:25 <  gbeshers> So what you really need is an old stable version and an experimental version.
13417:26 <  gbeshers> With something like "chroot" for the new one.
13517:26 <  gbeshers> ?
13617:26 <       rl_> versions of what? i do need the latest head
13717:27 <  gbeshers> That is what you are building or what you are building iwth
13817:27 <  gbeshers> ?
13917:27 <     Igloo> rl_: Does dph there need to depend on base?
14017:27 <       rl_> gbeshers: both
14117:27 <       rl_> Igloo: it does atm
14217:28 <       rl_> I'm not sure, perhaps it won't in the future
14317:28 <  gbeshers> rl_ so its a bootstraping problem... ?
14417:28 <       rl_> well, we have the vectoriser which is part of the compiler and which depends on a couple of packages
14517:29 <       rl_> like, say, the generics stuff
14617:29 <       rl_> but the problem is that I need to change things in the build system
14717:29 <       rl_> and if the build system includes Cabal that's over 40K LOCs to choose from
14817:30 <       rl_> so a bit more separation between Cabal and GHC would be helpful
14917:31 <       rl_> I understand that it's easy to say :)
15017:31 <     claus> would it have been possible to keep the old and the new build system in parallel, allowing rl_ to modify the old one, while cabalists think about replicating the old one's features in the new one?
15117:31 < JaffaCake> rl_: perhaps you could describe what you need in an email to cabal-devel, because it sounds like we need to incorproate it in a general mechanism
15217:32 < JaffaCake> claus: it's really hard to keep two build systems working at the same time
15317:32 <     Igloo> rl_: I don't think you need to change Cabal, but I'm a bit worried about this "dph'd base dependes on normal base" plan
15417:32 <     Igloo> Well, you might need more generic way support from Cabal, but that's something that we need anyway
15517:33 <  nominolo> can't we load two versions of the same package at the same time?
15617:33 <  nominolo> i mean, if they don't export the same names?
15717:33 < JaffaCake> rl_: surely as a short-term measure you could hack it by running a preprocessor over the dph sources to generate the two versions? or something?
15817:33 <     Igloo> nominolo: We can't specify which way we want to load at the moment
15917:33 <       rl_> Igloo hacked it and it works now
16017:33 <       rl_> I'm just worried that I can't maintain it
16117:34 < JaffaCake> nominolo: yes, and even if they export the same names
16217:34              gbeshers thinks rl_ has a valid point
16317:34 <       rl_> in any case, it's not just this particular problem
16417:35 <       rl_> because I'm sure it's not the last one
16517:35 <     Igloo> rl_: So are you asking for more/better docs, or for something more than that?
16617:35 <       rl_> docs + stability
16717:35 <  nominolo> rl_: for a start, there is http://hackage.haskell.org/trac/hackage/wiki/SourceGuide
16817:35 < lambdabot> Title: SourceGuide - Hackage - Trac
16917:36 <     claus> btw, is there a transition guide, explaining the new build system to users of the old one?
17017:36 <  nominolo> what's missing are the specifics of how GHC uses Cabal
17117:36 <     Igloo> OK, and is it docs for GHC's build system, for Cabal's public interfaces, or Cabal's internals that you think are most needed?
17217:36 <       rl_> but that docs don't help if the interface keeps changing
17317:36 <  nominolo> Igloo: i'd say GHC build system is most important
17417:36 <     Igloo> Stability is tough at the moment
17517:36 <   dcoutts> Cabal's interfaces do not really keep changing
17617:37 <     Igloo> We have the same problem with the GHC API
17717:37 <     Igloo> dcoutts: They do in teh sense that the whole of Cabal is an interface to Setup.hs writers
17817:37 <   dcoutts> it's been pretty stable since 1.4 came out
17917:37 <       rl_> dcoutts: well, I count at least 3 dph patches purely for tracking Cabal changes this month
18017:37 <   dcoutts> rl_: but are they all trivial newtype wrappers?
18117:38 <       rl_> dcoutts: probably, but I had to find out about that which took time
18217:39 < JaffaCake> Igloo: so you'll update http://hackage.haskell.org/trac/ghc/wiki/Building?
18317:39 < lambdabot> Title: Building - GHC - Trac
18417:39 <     Igloo> Yup
18517:39 < JaffaCake> great
18617:39 <   simonpj> What docs?  My suggestion is: an overview of how GHC's bulid system works, esp for the libraries part, and how Cabal is used.  That stuff about cabal.bin, runghc.wrapper etc.  That has the merit that it doesn't change too fast either. It's not going to directly help with versions etc, but I'm guessing it'd help.
18717:39 < JaffaCake> there's lots of useful stuff in there
18817:40              <   TuringTest!n=TuringTe@pamac-cek10.st-and.ac.uk []
18917:41 < JaffaCake> shall we move onto version control?
19017:42 < JaffaCake> http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation is full of useful stuff thanks to BSP_
19117:42              >>> pheaver!n=user@97-115-33-26.ptld.qwest.net
19217:42 < lambdabot> Title: DarcsEvaluation - GHC - Trac
19317:42              <   pheaver!n=user@97-115-33-26.ptld.qwest.net ["ERC Version 5.2 (IRC client for Emacs)"]
19417:42 <     Igloo> and nominolo
19517:42 <      BSP_> it would be nice if people took some time to try out the various ghc repos i've put up and see what they think of the various systems
19617:43              Igloo will be doing that this week
19717:43 < JaffaCake> BSP_: could you put links to the repos on that page?
19817:43 <      BSP_> they already are linked
19917:43 < JaffaCake> oh, sorry!
20017:43 < JaffaCake> ah, I see
20117:43 <     Igloo> There was a thing on reddit saying we were using hg and git wrong; if that's right then can anyone tell us what using them right would mean?
20217:43 <      BSP_> we probably need at least one windows user in that group, given that git isn't reported to work well with windows
20317:44 <      BSP_> i've posted a reply to that guy asking him to elaborate
20417:44 <     Igloo> OK, great
20517:44 <     Igloo> I can do some testing on Windows
20617:44 <      BSP_> great
20717:44 < JaffaCake> Igloo: I think he means not cherry-picking
20817:44 < JaffaCake> i.e. we'd fix on the stable branch, then merge into head
20917:45 < JaffaCake> it's one option, but I like the way we do things now
21017:45 <    tibell> I can answer questions about git workflow as I use it for all my projects now when I'm (happily) off darcs
21117:46 <      BSP_> tibell: ok great, if you have any comments about the git stuff on that page please add them to the wiki
21217:46 < JaffaCake> tibell: so do you cherry-pick with git?
21317:46 <  nominolo> i was a bit surprised that hg help screens are so small.  either it's a lot less complex or it's just missing lots of features or it's not well-documented
21417:46 <    tibell> JaffaCake: no
21517:47 <  Deewiant> nominolo: I find it to be really well documented, but YMMV I suppose :-)
21617:48 <    tibell> I can say I don't find git's interface complex anymore
21717:48 <    tibell> it's very convenient
21817:48 < JaffaCake> so I guess what's most important to us is the speed and ease of use for common operations
21917:48 <  nominolo> Deewiant: take a look at the git man pages then ;)
22017:48 < JaffaCake> plus good support for merging
22117:48 <    tibell> JaffaCake: I use maybe a handful commands daily
22217:49 <    tibell> you do loads of merging in git, I usually have 1-3 topic branches, a development branch and a master branch going at the same time
22317:49 <  nominolo> JaffaCake: apparently, Git has 5 merge modes...
22417:49 <    tibell> nominolo, it's picks the automatically
22517:50 <    tibell> nominolo, it says something like "Merged by X"
22617:50 < JaffaCake> tibell: so I'll normally want to do a rebase whenever I do a pull, does that happen automatically in git?
22717:50 <     Igloo> nominolo: Lots of docs and lots of merge modes both sound like negatives to me...
22817:50 <  nominolo> tibell: do you have others commit to the same repo
22917:50 <  nominolo> Igloo: git command have lots of command line options.  you don't need most
23017:50 <    tibell> JaffaCake: you can set it to always rebase yes
23117:51 <  Deewiant> nominolo: looking at the docs, it seems awfully complicated :-P
23217:51 <  nominolo> Igloo: the question is whether you like to have the option
23317:51 <    tibell> nominolo, yes but not many
23417:51 <    tibell> Igloo: look at it this way, I've never read those docs and the different merge strategies makes merges succeed more often
23517:52 <    tibell> JaffaCake: I always rebase on all non public branches I have
23617:52 < JaffaCake> right
23717:52 < JaffaCake> I don't like the idea of getting bogus merge commits whenever I pull
23817:52 <    tibell> the git index is also very useful for crafting a nice patch
23917:52 <  nominolo> tibell: yup, very much
24017:52 <    tibell> JaffaCake: yeah, with rebase you don't get those merges
24117:53 <     Igloo> What is the git index?
24217:53 <      BSP_> JaffaCake: i heard you can also avoid those with a workflow based on rerere (http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html)
24317:53 <    tibell> JaffaCake: I think people in the linux kernel prefer that people rebase before sending changes
24417:53 <  nominolo> i think they call that fast-forwarding
24517:53 < JaffaCake> yes, but why did they call it the "index", that's a completly unhelpful name
24617:53 <    tibell> Igloo: it's a staging area were you select what goes into the patch (if you want that that is)
24717:53 < JaffaCake> Igloo: the index is the staging area before you commit
24817:53              <   mnislaih!n=pepe@55.Red-80-32-15.staticIP.rima-tde.net []
24917:53 <    tibell> Igloo: so you add whole or partial files, review the diff (optional but a good idea), and commit
25017:54 <     Igloo> So it's like the interactive darcs record?
25117:54 < JaffaCake> yep
25217:54 <    tibell> Igloo: I guess the difference is that darcs have you do that as you commit while git lets you stage first, edit, and then commit
25317:54 <  nominolo> Igloo: yes, except that you can stop and continue later
25417:54 < JaffaCake> you also have interactive hunk adding
25517:54 <    tibell> yes
25617:54 <  nominolo> with the possibility to split a patch
25717:55 <  nominolo> very useful sometimes
25817:55 <  nominolo> i mean, split a diff
25917:55 < JaffaCake> and importantly, they have an emacs extension like darcsum
26017:55 <    tibell> rebase also lets you rearrange patches locally if you made two patches you really wanted to be a single one
26117:55              JaffaCake like darcsum a lot
26217:55 <     Igloo> If you have one in the index waiting to be finished, can you record a separate patch?
26317:55 <  nominolo> JaffaCake: yes, but it fails sometimes
26417:56 < JaffaCake> the git version does?
26517:56 <  nominolo> JaffaCake: no darcsum
26617:56 < JaffaCake> oh, when?  I use it for most records
26717:56 <  nominolo> i tried it last week and it failed
26817:57 <  nominolo> no idea why.
26917:57 < JaffaCake> it's a bit sensitive to the darcs version
27017:57 <    tibell> you can also temporary stash away changes on a stack to reapply them later
27117:57 <  nominolo> could be because i used 2.0.2
27217:57 < JaffaCake> could be
27317:57 <    tibell> say if you have some edits and want to do a small quick fix in the same working dir on the same branch
27417:57 < JaffaCake> hmm, but I'm using 2.0.2
27517:57              tibell has no experience with hg.
27617:58 <  nominolo> maybe i have the wrong version of darcsum then
27717:58 <      BSP_> hg has stash, and is getting rebase in the summer of code
27817:58 <  Deewiant> hg is evidently getting some kind of rebase as part of the summer of code
27917:58 < JaffaCake> nominolo: get the version from darcs, it's working well for me
28017:58 <  nominolo> BSP_: most soc projects aren't releaseble immediately
28117:58 < JaffaCake> tibell: so the main thing that worries me about git is that it doesn't track file renames
28217:59 <    tibell> JaffaCake: how come?
28317:59 < JaffaCake> I'm sure it's often not a problem in practice, but it just seems wrong
28417:59 <      BSP_> nominolo: right, and it's not probably not going to be as bug free or capable as gits for a while yet
28517:59 <    tibell> JaffaCake: I think Linux argues the opposite ;)
28618:00 < JaffaCake> Linus you mean?
28718:00              tibell have tried to put some of Google's codebase on git.
28818:00 <    tibell> it's nice and fast
28918:00 <    tibell> JaffaCake: yes
29018:00 <    tibell> even with very many files
29118:00 < JaffaCake> I bet they don't move things around much
29218:01 <    tibell> on linux?
29318:01 <    tibell> internally I think they do
29418:01 < JaffaCake> yes
29518:01 <    tibell> of course not in the public interface
29618:01 <    tibell> hmm, git has a move command
29718:01 <    tibell> I don't remember using it though
29818:02 < JaffaCake> right, but I don't think it records anything in the commit
29918:02 <      BSP_> git is just an alias for remove + add
30018:02 <      BSP_> git move*&
30118:02 < JaffaCake> yep
30218:02 <    tibell> I have to run to a meeting
30318:02 <  malcolmw> I did a google on git-rebase to learn what it means, and one of the early hits is "rebase considered harmful", written by a happy git convert (from darcs)
30418:02 < JaffaCake> I have to go too...
30518:02              ~   tibell is now tibbe|away
30618:03 < JaffaCake> malcolmw: heh
30718:03 < tibbe|awa> malcolmw: I think it's about rebasing a published repo, you shouldn't do that
30818:03 <     claus> JaffaCake: often, when darcs goes wrong, the left-overs point to moves/renames; might be a coincidence, but..
30918:03 < tibbe|awa> malcolmw: there are replies out there
31018:03 < JaffaCake> malcolmw: rebase is for doing what darcs does for you
31118:03 <     Igloo> malcolmw: It's harmful in the same sense that darcs amend is harmful
31218:04 < JaffaCake> bye folks!
31318:04 <     Igloo> See ya!
31418:04 <      BSP_> bye JaffaCake!
31518:04 < tibbe|awa> bye!
31618:04 <       ndm> it seems there are more Git -> Hg converts
31718:04 <       ndm> I mean Darcs -> Git converts
31818:04 <       ndm> compared to Darcs -> Hg converts
31918:05 <      BSP_> right, and git is certainly the most popular DVCS out there
32018:05 <       ndm> which makes it moer likely that the common darcs FAQ's will have answers people know
32118:05 <  nominolo> in general, there seem to be more Git users
32218:05              <   Judith!n=rohloff@luthien.uebb.cs.tu-berlin.de []
32318:06 <       ndm> so i'd say that makes Git the default choice, unless it has a particular failing
32418:06 <      BSP_> i'm personally leaning towards git too
32518:06 <      BSP_> but we need to see how well it works on windows
32618:06 <  Deewiant> I just worry about Windows users
32718:06 <  Deewiant> yeah
32818:07 <      BSP_> anyway, theres a fair amount of information on the wiki people can use to come to their own conclusions
32918:08 <   dcoutts> btw, are we just talking about converting the ghc repo itself and not the other libs right?
33018:09 <   simonpj> I'm ignorant about all this, but I'm very keen on using a system that has a large user base, and is out of the experimental, just developed  phase
33118:09              gbeshers winces at the inconsistency...
33218:09 <   dcoutts> I don't really want to convert Cabal for example, I'm happy with git
33318:09 <   dcoutts> erm I'm happy with darcs
33418:09 <      BSP_> right, i don't think we plan to convert any other repos for now
33518:09 <       ndm> "Examples of projects that have publicly ruled out any use of Git, due to Git's poor support of Windows, include Mozilla[52] and Ruby.[53]" - from Wikipedia
33618:09 <      BSP_> but yes, it is going to be annoying that there are two command sets to deal with
33718:10 <       ndm> that doesn't bode well...
33818:10 <      BSP_> ndm: OTOH, we actually require cygwin to build GHC, and installing git in cygwin is painless
33918:10 <       ndm> the article suggests that a Wndows port of Git is in the works, but has a issues etc
34018:10 <       ndm> BSP_: mmm, true
34118:10 <      BSP_> wikipedia also claims that the recently recoded a lot of stuff in c instead of shell scripts, improving windows performance
34218:11              >>> mib_q0jl0s!i=8d390986@gateway/web/ajax/mibbit.com/x-213a85a3b1e47104
34318:11 <      BSP_> so i think we'll need to try it out for ourselves
34418:11              <   rl_!n=rl@124-170-154-173.dyn.iinet.net.au []
34518:11 <       ndm> true, aer there any Windows GHC developers?
34618:11 <      BSP_> simonpj: right, we certainly want a well supported system. i think hg and git are the best contenders there, bzr apparently has a somewhat smaller user base
34718:12 <      BSP_> i think JaffaCake is on windows
34818:12 <      BSP_> and simonpj is
34918:12 <     Igloo> We don't need bygwin to build GHC; you can do it with msys instead
35018:12 <      BSP_> there is also a msys git build, actually
35118:13 <   simonpj> Working well on Windows is really important.  If git doesn't, that's a real problem.  So we need to try that before committing. ANyone willing?
35218:13 <       ndm> simonpj: it needs to be a real windows developer on GHC, not just someone testing it - so the options are limited
35318:13              <   waern!i=53915df2@gateway/web/ajax/mibbit.com/x-c9b7dd11fbf4c908 ["http://www.mibbit.com ajax IRC Client"]
35418:14 <       ndm> I'd be happy to give it a go once I get back to my Cgwin machine, but i don't think it will tell us much without a real developer doing all the interesting bits
35518:14 <   simonpj> Neil mitchell?
35618:14 <       ndm> simonpj: yep
35718:14 <     Igloo> I can give it a try
35818:17 <      dons> btw, the darcs/ghc story is on the reddit front page.
35918:17 < lambdabot> dons: You have 3 new messages. '/msg lambdabot @messages' to read them.
36018:19              ndm has to go, bye!