IRC_Meetings: ghc-meeting-2008-08-13.log

File ghc-meeting-2008-08-13.log, 65.1 KB (added by nominolo, 6 years ago)

Meeting log 2008-08-13

Line 
117:00 < JaffaCake> GHC meeting time again :)
217:00 <     tibbe> yay!
317:00 <     tibbe> fun
417:01 <  dcoutts_> Igloo: we were using Control.Exception.catch, so that catches exit exceptions
517:01 <     Igloo> dcoutts_: Right, but we don't use that any more  :-)
617:01 <  dcoutts_> Igloo: right, you broke it ;-)
717:01 <     Igloo> Agreed, but for all versions of GHC, not just 6.
817:01 <     Igloo> 9
917:01 < JaffaCake> suggestions for things to talk about so far: (a) what to do about the library repos, (b) the base breakup
1017:01 <     tibbe> JaffaCake: is there always an I/O manager thread running in the RTS? if I don't use any of the I/O functions in GHC.Conc will it still send this over a pipe to  it?
1117:02              dcoutts_ finds topic (a) all rather depressing
1217:02 < ndmitchel> (a) - as in whether to git them?
1317:02 < JaffaCake> tibbe: yes to the first question (with -threaded)
1417:02 <     tibbe> JaffaCake: sounds like good topic since many people still have strong feelinfs about the topic
1517:02 < JaffaCake> tibbe: for the second question, what is "this"?
1617:02              ~   ndmitchell is now ndm
1717:02 <      SamB> you can't force upstream to switch to git, for those libraries that have an upstream
1817:03 <  nominolo> how much/many are is upstream?
1917:03 <       ndm> leaving them in darcs seems a good choice, as there is no compelling reason to switch
2017:03 <      SamB> but you *could* convert all of them to hashed format
2117:03 <  nominolo> (modulo grammar)
2217:03 <     Igloo> If we're going to do (a), can I ask whether there is any possibility of reconsidering ghc moving to git in light of the what-to-do-with-the-libraries problem?
2317:03 <     tibbe> JaffaCake: sorry, I meant to say is there always some communication over a pipe to that thread even if I create my own I/O functions using the FFI?
2417:03 <       ndm> plus there are other compilers that aren't GHC, which are sticking with darcs :)
2517:04 <      SamB> Igloo: I don't think that will help any
2617:04 <     Igloo> nominolo: In some sense all of them do, e.g. malcolmw is an upstream
2717:04 <     tibbe> SamB: I'm not sure that I would do that since the hashed format haven't seen that much testing yet
2817:04 <  nominolo> Igloo: both SimonPJ and SimonM said that the move is definite
2917:04 <      SamB> tibbe: it seems less prone to breaking than --partial!
3017:04 < JaffaCake> Igloo: speaking for myself, I'd still like to switch
3117:04 <  dcoutts_> personally I'd like to wait and switch to darcs 2 when its perf improves, but I'm not the one suffering with the immediate problems
3217:05 <     tibbe> SamB: quite possibly, I wouldn't know
3317:05 <     tibbe> SamB: I'm scared of putting any source in Darcs 2
3417:05 <      SamB> well, --hashed isn't darcs 2 per-se
3517:05 < JaffaCake> does anyone have a sense of how hard it would be to maintain a branch of each library repo in git?
3617:05 <     tibbe> dcoutts_: why do you think it will improve?
3717:05 <      BSP_> ndm: I think the key benefits of switching all repos to git are a) being able to address a consistent snapshot of GHC (using Git submodules) b) only one VCS to deal with and c) no dual-vcs branches to maintain (as in some of the proposed solutions)
3817:06 <  nominolo> JaffaCake: you mean as separate repos, like now?
3917:06 <  dcoutts_> tibbe: because there are several clever and dedicated people working on it
4017:06 <     tibbe> dcoutts_: from what I've seen most people seem to abandon the project :(
4117:06 <  dcoutts_> tibbe: they've got pretty comprehensive tests, more so than in darcs 1
4217:06 < JaffaCake> nominolo: I hadn't really considered not using separate repos, but I suppose that's an option too, yes
4317:06 <  dcoutts_> tibbe: I've been talking to the hackers, not the users who read the 2.0 release announcement
4417:07 <  nominolo> JaffaCake: with git-submodules it's certainly not as easy as it could be, but probably better than it is now
4517:07 < JaffaCake> dcoutts_: I'm encouraged by what I'm reading about darcs2, it does seem to be gathering momentum
4617:07 <     tibbe> dcoutts_: so when will the new faster darcs be released?
4717:07 <      SamB> JaffaCake: I wouldn't advise it for any libary not meant to be tied to GHC -- only the GHC.* hierarchy comes to mind ...
4817:07 <       ndm> BSP_: the second seems less important people are still going to have to know darcs), c) only relates to certain plans
4917:07 <       ndm> and can we not do a) in some other way?
5017:07 < JaffaCake> nominolo: git submodules don't work the way I thought they worked - it's just a very thin layer over separate repositories really
5117:07 <  dcoutts_> JaffaCake: we had a good discussion with Erik and Jason after AngloHaskell
5217:08 <  nominolo> JaffaCake: yes, sadly.  but i've seen some wrapper scripts
5317:08 <  dcoutts_> tibbe: we're currently benchmarking with 2.1GB of repos from code.h.o
5417:08 <      SamB> JaffaCake: is there a problem with thin layers?
5517:08 <       ndm> tibbe: they are bringing it back together, darcs 2 is not dead (even if it really really appeared to be)
5617:08 < JaffaCake> nominolo: I thought submodules would be like separate branches in the same repo
5717:08 <     Igloo> I think forking the repos in a different VCS is a really bad idea. Merging patches back sounds like it will be a pain, and for that and other reasons I believe the packages will tend to diverge greatly
5817:08 <  malcolmw> if the base breakup were to separate out all of the ghc-only parts of base into a dfferent package, that might well solve problem (a)
5917:08 <      SamB> it's pretty simple ...
6017:08 <     tibbe> dcoutts_: will it become as fast as Git, i.e. sub second run times for many commands?
6117:08 <  nominolo> SamB: in particular you have to be careful which repo you commit to
6217:08              <   ttt--!n=ubuntu@78-23-117-225.access.telenet.be [Remote closed the connection]
6317:08 <      SamB> nominolo: hmm.
6417:08 <  dcoutts_> tibbe: probably never, but probably fast enough for the commands that are important in workflow
6517:09              SamB hopes darcs becomes a tool for use with git at some point
6617:09 < JaffaCake> malcolmw: I don't think it solves the problem on its own, we still need to share base
6717:09 <  nominolo> dcoutts_: how can we know it won't corrupt the repo?
6817:09 <  dcoutts_> tibbe: partly the issue there seems to be that it's david doing the release announcements rather than people like Erik, so we've not been getting an accurate picture of the state of darcs 2
6917:09 <     tibbe> dcoutts_: I can never again image working with a VCS which have multi second run times for important operations. it forces a completely different workflow
7017:09 <     Igloo> tibbe: For things like whatsnew, there's no reason darcs needs to be slower than git
7117:09 <  dcoutts_> nominolo: comprehensive testing that the devs do in nightly builds
7217:10 <     tibbe> Igloo: but it is right?
7317:10 <       ndm> with any luck, there will be a change of maintainer
7417:10 < JaffaCake> Igloo: I'm interested in performance in practice, not theory :)
7517:10 <      BSP_> Igloo: i think a more serious issue is that darcs discourages branching (both in its UI and darcs1s bad conflict handling), which contributes to our unstable-HEAD issue
7617:10 <  malcolmw> JaffaCake: my point was that the shared base would be much less volatile if the ghc-only bits were elsewhere
7717:10 <     tibbe> Igloo: so in some uncertain future it might not be, do we really wanna bet on that when we have something that works much better already?
7817:10 <  dcoutts_> tibbe: if by multi second you mean two seconds then I disagree, if you mean 10 then yes. darcs 2 falls into the 2 sec for most things I've tested.
7917:10 <     tibbe> malcolmw: I agree
8017:10 <      SamB> BSP_: I agree
8117:11 <      SamB> malcolmw: does anyone not think that?
8217:11 <     Igloo> I was answering "< tibbe> dcoutts_: will it become as fast as Git" - that's a question about the future!
8317:11 < JaffaCake> malcolmw: but base will have to use a stable API to the underlying bits, which means nhc98 will have to provide that API too
8417:11 <     tibbe> dcoutts_: there are lots of studies showing that you need ~250ms for an action not to seem instantanious
8517:11 <  dcoutts_> tibbe: and remote darcs pull should be much faster in 2, they're using a custom protocol between client and server
8617:11 <  nominolo> dcoutts_: no it doesn't,  in particular darcs changes is still slow
8717:12 <     tibbe> dcoutts_: my point being is that there are lots of shoulds and woulds and have been as long as I've used darcs (years)
8817:12              >>> thoughtpolice!n=austinse@c75-111-138-147.plaicmtc01.tx.dh.suddenlink.net
8917:12 <      BSP_> dcoutts_: any prospect of the case sensitivity issue being fixed? that really raising the barrier for getting the GHC sources
9017:12 <     tibbe> dcoutts_: merges still hang
9117:12 <     tibbe> dcoutts_: in fact merging in darcs is painful even when it's not slow
9217:12 <  dcoutts_> tibbe: you're talking about darcs 2 with v2 format repos? if you find merges going slow there then you need to report them.
9317:13 <  dcoutts_> BSP_: apparently yes
9417:13 <  nominolo> BSP_: it works with darcs2
9517:13 <     tibbe> dcoutts_: I've given up on darcs about 4 months ago, I was wasting too much time on my VCS
9617:13 < JaffaCake> dcoutts_: I think merging is still hard with darcs, for the reasons I gave on the list
9717:13 <  nominolo> BSP_: but i don't know if we want to use darcs2 format already
9817:13 <  dcoutts_> JaffaCake: the UI issues you mean
9917:13 < JaffaCake> yep
10017:13 <     tibbe> dcoutts_: I'm mot more productive now, git has a much better UI
10117:13 <      BSP_> dcoutts_: thats good to hear, at least
10217:13 <  dcoutts_> JaffaCake: right, doesn't sound insolvable
10317:14 < JaffaCake> not insolvable no... like most problems with darcs
10417:14 <      SamB> really?
10517:14 <      BSP_> darcs is a minority sport and will remain one, so i think inevitably it will always be buggier / less mature / have less gui + tool + website ecosystem than git will
10617:14 <  dcoutts_> tibbe: but if it's just a question of 2s vs 0.2s then is that really a reason to make the whole community switch
10717:14              SamB really likes the way git actually records (much of) the development history of a project
10817:14 <  nominolo> darcs *could* have submodule support, darcs *could* have local branchs, darcs *might* be able to get faster ...
10917:15 <  malcolmw> because darcs is in Haskell, one might hope it has better quality control than a bunch of shell scripts
11017:15 <     Igloo> darcs deliberately doesn't have local branches for simplicity
11117:15 <     Igloo> (of UI)
11217:15 <      SamB> that is, I like the way it can record what trees people may have tested
11317:15 <  dcoutts_> nominolo: it's rather unfortunate timing, they spent ages fixing the merge issue, and now just as they're getting round to addressing the perf issues, we decide to leave because of the poor perf.
11417:15 <      SamB> malcolmw: darcs is an awful lot more complicated though
11517:16 < JaffaCake> malcolmw: right, but you can get pretty good quality control when there a *lot* of people working on it, regardless of the underlying technology
11617:16 <  nominolo> dcoutts_: so why do you expect those to be fixed soon, when before they needed ages?
11717:16 <      BSP_> Igloo: do you not agree that cheap local branches would have encouraged e.g. doing the cabalisation in a branch?
11817:16 <  malcolmw> yeah, "all bugs are shallow given enough eyes"
11917:16 <  dcoutts_> nominolo: because that's what the maintainers tell me
12017:16 <  nominolo> dcoutts_: yeah.  i don't quite believe that
12117:16 <  dcoutts_> nominolo: and before the most pressing issue was the merging
12217:16 <     tibbe> dcoutts_: I can't make anyone do anything. I've personally decided I won't use darcs again, it's up to the GHC developers to decide what they want to do
12317:16 <     Igloo> BSP_: No
12417:16 <      SamB> dcoutts_: and you believe them?
12517:17 <      SamB> they are optimists
12617:17 < JaffaCake> dcoutts_: we can always come back...
12717:17 <     Igloo> BSP_: I would have done it the same way whatever VCS I was using
12817:17 <  dcoutts_> SamB: yes. I think that's a bit unfair.
12917:17 <     tibbe> Igloo: therefore it's really painful to use branches in darcs
13017:17 <      SamB> well, I mean, most programmers are
13117:17 <     tibbe> Igloo: I create and destroy branches daily in Git, I never used them in darcs
13217:17 <  malcolmw> I don't really understand these complaints about branches in darcs - they seem rather easy and straightforward to me
13317:17 <       ndm> SamB: i looked at Erik, he told me it was under control, I believed him - their biggest issue is PR
13417:17 < JaffaCake> tibbe: I have several local branches of ghc, fwiw
13517:18 <  dcoutts_> JaffaCake: true, but it's inertia isn't it.
13617:18 <        TD> Can we always come back?  I know there is a darcs2git, but the other way doesn't have a git2darcs for ready use.
13717:18 <  nominolo> JaffaCake: exactly, if Darcs really *does* get better, there's nothing stopping us from going back
13817:18 <     tibbe> dcoutts_: I also believe Git's model for storing the repo is much more sound
13917:18 <      BSP_> TD: tailor will do that
14017:18 <        TD> ... Does he know that? ;-)
14117:18 <       ndm> converting source is painful, if GHC leaves, it will never go back without a pressing advantage, which I doubt will happen
14217:18 <      SamB> TD: tailor is a program ;-P
14317:18 <  dcoutts_> ndm: right
14417:18 <     tibbe> JaffaCake: yes, it's just easier to do them in Git which means you tend to do the more often and get the benefits more often
14517:19 <    ghcbot> Build x86 Windows head fast #2551 finished: Failure (failed boottestsuite runtestsuite)
14617:19 <    ghcbot> Build details are at http://darcs.haskell.org/buildbot/all/builders/x86%20Windows%20head%20fast/builds/2551
14717:19 < JaffaCake> Igloo: btw, what up with this ^^^^^
14817:19 <     tibbe> ndm: does that also imply there is no pressing advantage to use darcs in the first place?
14917:19 <      SamB> tibbe: there was ... over CVS!
15017:20 < JaffaCake> right
15117:20 <  dcoutts_> if it were possible to hold off the change for a bit I'd suggest setting an ultimatum, set perf goals and if they're not met in a realistic time frame then switch.
15217:20 <       ndm> tibbe: darcs > cvs, but darcs' >==== git at best, where darcs' = darcs + everything fixed + everyones wishlist
15317:20 < JaffaCake> although at lesat CVS could do annotate :)
15417:20 <     Igloo> Oh, is that the disappearing pwd? I meant to ask you if you had any idea. I'll do a Windows build and see if I can reproduce it
15517:20 <     tibbe> SamB: right, so darcs is indeed better than CVS
15617:20 <  dcoutts_> JaffaCake: someone is working on that
15717:20 <      SamB> dcoutts_: well, to make it an ultimatum you have to say what timeframe in the ultimatum
15817:20 <      SamB> just FYI
15917:20 <     tibbe> ndm: put Git + fairy dust is >> darcs
16017:20 <  dcoutts_> SamB: of course
16117:20 <  nominolo> dcoutts_: haven't we been doing that for the last year or so?
16217:20 < JaffaCake> Igloo: it didn't happen for me in a validate
16317:20 <  dcoutts_> nominolo: not really
16417:20 <       ndm> tibbe: Git doesn't have lambda fairy dust :)
16517:20 < JaffaCake> I can investigate more if you don't know what it is
16617:20 <  nominolo> dcoutts_: i mean it was a known problem
16717:21 <     tibbe> ndm: so is darcs better than Git at anything today?
16817:21 <      SamB> dcoutts_: okay, just making sure ;-)
16917:21 <       ndm> nominolo: they've had internal politic issues, making it hard to effectively communiate to darcs and get response back
17017:21 <     Igloo> JaffaCake: Oh, I've just realised what it is. It's because the buildbots remake utils with stage1, so that fix I have for John's problem will fix it
17117:21 <       ndm> tibbe: the Windows support is good, the git windows support seems to really want Cygwin, which would suck totally
17217:21 <  nominolo> dcoutts_: just, darcs now jumping because of ghc's threat, isn't exactly a convincing argument that things will actually change
17317:21 <  dcoutts_> nominolo: and because they were concentrating on bug #1
17417:21 < JaffaCake> Igloo: ok, cool
17517:21 <     tibbe> ndm: I don't use Windows so I really wouldn't know
17617:22 <     tibbe> ndm: that's the case with much open source stuff though
17717:22 < JaffaCake> ndm: the MSYS git seems to work (i only tried it briefly though)
17817:22 <      BSP_> ndm: apparently the msys version works fine, and is available for download from the main pagej
17917:22 <     Igloo> The MSYS one doesn't work properly over SSH, unfortunately. I haven't tried the cygwin one yet
18017:22 <       ndm> JaffaCake, BSP_: does that work if you haven't got mingw/msys installed?
18117:22 <  dcoutts_> nominolo: they were working on an internal rebuild, it's hard to optimise at the same time. That's why we might expect it to be different now.
18217:23 < JaffaCake> ndm: yes
18317:23 <     Igloo> ndm: It looks like it basically bundles an msys install with itself
18417:23 <     tibbe> dcoutts_: are there any design docs showing how darcs are going to reach these new performance heights?
18517:23 <  dcoutts_> tibbe: I'll ask
18617:23 <     tibbe> dcoutts_: thanks :)
18717:23 < JaffaCake> dcoutts_: my impression is that the on-disk repo structure needs a rethink in darcs
18817:23 <     tibbe> dcoutts_: I think that's one of the problems, you can't tack on performance after the fact
18917:24 <     tibbe> JaffaCake: me too
19017:24 <     Igloo> JaffaCake: For things like annotate, yes, but for things like whatsnew all you need to do is stat a bunch of files and compare them
19117:24 < JaffaCake> most operations are O(patches), unless you tag, which is bad
19217:24 <     tibbe> dcoutts_: how does darcs checksum the repo to prevent corrpution?
19317:24 <  dcoutts_> whatsnew is already blindingly fast
19417:24 <     Igloo> dcoutts_: I thought that was something JaffaCake said had become too slow?
19517:24 <  dcoutts_> I could not reproduce that
19617:24 <     tibbe> Igloo: state them efficiently, darcs just never comes back when I tried it on some Google code
19717:24 < JaffaCake> whatsnew is quite a bit slower, for me at least
19817:25 <  dcoutts_> JaffaCake: you're not using nfs or something right?
19917:25 <     tibbe> Igloo: stat*
20017:25 < JaffaCake> I am
20117:25 <  dcoutts_> for me whatsnew was 0.2s
20217:25 <  dcoutts_> even after touching loads of files
20317:25 <     tibbe> dcoutts_: if there are any performance improvements to darcs I could try them out at work
20417:26 < JaffaCake> I've got rid of my hashed repo so I can't try it now
20517:26 <  dcoutts_> tibbe: I didn't test any old versions, so I don't know what's improved recently, only what it's like now
20617:26 <     tibbe> dcoutts_: OK
20717:26 <       ndm> I'm personally thinking, even as a darcs fanboy, that moving to Git for GHC is the right choice, but leaving everything else in darcs makes sense
20817:26 <     Igloo> ndm: So using 2 VCSs in a GHC tree?
20917:26 <       ndm> Igloo: yes
21017:26 < JaffaCake> ndm: the trouble with that is that some people are digging in their heels and saying we absoluately can't do it that way
21117:27 <     Igloo> (that's my preferred solution too, if GHC is to move to git)
21217:27 <     tibbe> Igloo: better than one that doesn't work
21317:27 <      SamB> ndm: unless upstream wants to switch too
21417:27 <       ndm> JaffaCake: why not? I may have missed those arguments (my @haskell.org folder has 250 conversations in it)
21517:27 <      SamB> JaffaCake: just do it anyway
21617:27 <  dcoutts_> tibbe: I think we should be specific about what operations we need to be fast, and how fast exactly.
21717:27 < JaffaCake> fwiw, I wouldn't mind using 2 VCSs
21817:27 <       ndm> SamB: upstream tends to be libraries@, and they haven't switched, and would have to push it through a library proposal
21917:27 <      SamB> JaffaCake: show them that it is possible
22017:27 <     tibbe> dcoutts_: we want similar pull speeds for sure as slows pulls can turn off contributors
22117:28 <     tibbe> dcoutts_: better and faster merging
22217:28 <  dcoutts_> tibbe: I agree, fast pulls is important.
22317:28 <      SamB> ndm: hey, aren't you upstream for at least one package?
22417:28 <     tibbe> dcoutts_: as in better UI and better success
22517:28              quicksilver laughs as ChilliX offers to buy malcolmw an introductory software engineering textbook.
22617:28 <     tibbe> dcoutts_: efficient packed format
22717:28 <      SamB> dcoutts_: --hashed?
22817:28 <     tibbe> dcoutts_: checksum commits
22917:28 <       ndm> SamB: kinda, i think i pushed that one off to libraries@ though
23017:28 < JaffaCake> SamB: good point
23117:28 <  malcolmw> no-one has yet been able to show me how to do the equivalent of darcs pull using git
23217:28 <      SamB> ndm: oh?
23317:28 <  nominolo> dcoutts_: fast annotate would be nice too
23417:28 <      SamB> ndm: I don't think they could stop you from taking it back could they?
23517:29 <  dcoutts_> nominolo: indeed, and changes. Both can be solved in the same way apparently.
23617:29 < JaffaCake> malcolmw: git doesn't have a direct equivalent
23717:29 <       ndm> SamB: once it got included in teh core packages, i think libraries@ took over it - at least its fuzzy, more of a kind of cooperation
23817:29 <       ndm> SamB: i'm not going to, so i guess whether they could is a moot point
23917:29 <       ndm> SamB: if i started screwing it up, someone would fork it and everyone would use that
24017:29 <      SamB> ndm: well true
24117:29 <     tibbe> malcolmw: what do you mean?
24217:30 <      SamB> but switching to git isn't the same as screwing it up ;-)
24317:30 <     tibbe> malcolmw: being asked once of each patch?
24417:30 <      SamB> anyway, this was just an example
24517:30 <  malcolmw> tibbe: "we want similar pull speeds" -> similar to what?
24617:30 <     tibbe> malcolmw: I would like darcs to have better cheery picking for chunks that go into a patch, Git does it much better with rebase --interactive
24717:30 <     tibbe> malcolmw: to Git
24817:31 <     tibbe> malcolmw: There's a comparison on the Wiki
24917:31 <  malcolmw> tibbe: my point was that git doesn't seem to do "pull", so what are you comparing against?
25017:31 <     tibbe> malcolmw: I have no idea what you're talking about now :)
25117:31 <      BSP_> malcolmw: do you just want interactive pull?
25217:31 <     tibbe> malcolmw: what do you mean doesn't do a pull, what about git pull?
25317:32 <      SamB> ndm: your website is still the homepage for filepath, at any rate
25417:32 <  malcolmw> tibbe: oh, so people have been telling me there is no direct equivalent in git to darcs pull - but there is, and it is called "git pull"?
25517:32 <     tibbe> malcolmw: maybe we could discuss build breakages during this meeting too?
25617:32 <  dcoutts_> tibbe: you can say that we want all these good aspects that git has, but not all of those are what we're complaining about wrt darcs1. It has some specific problems which if were addressed would presumably mean we'd be happy to stick. Extra stuff is cool but not a requirement.
25717:32 <     tibbe> malcolmw: yes, git pull
25817:32 <      BSP_> malcolmw: git pull is not interactive, which is why we say it is not like "darcs pull"
25917:33 <      SamB> it's like darcs pull -a
26017:33 <     tibbe> dcoutts_: right, that's up to the GHC developers, they would be requirements for me to consider darcs again since I'm more productive with those features
26117:33 <  dcoutts_> tibbe: I mean sure, it's your first choice for a new project, but this isn't a new project, or one with just a few users to covert. There are huge dependencies.
26217:33 <       ndm> SamB: yeah, its an issue, but i think if GHC still say "we'd like our libraries in darcs please", people will follow
26317:33 <      SamB> what ever happened to avoiding success at all costs anyway?
26417:34 <     tibbe> dcoutts_: do we agree that darcs is not working for GHC, as is, today?
26517:34 <  dcoutts_> tibbe: of course
26617:34 <  dcoutts_> tibbe: darcs v1 with the v1 format
26717:34 < JaffaCake> SamB: we're doing our best :)
26817:34 < quicksilv> SamB: success hit us like a freight train and we're stuck to the front.
26917:34 <      SamB> at least avoid the costs of success!
27017:34 <     tibbe> dcoutts_: I haven't seen anything that convinces me that anything is going to improve, lots of people are scrambling because people are leaving darcs
27117:34 < quicksilv> SamB: can't seem to peel off :)
27217:34 <      SamB> i.e. switch to git anyway ;-)
27317:34 <  dcoutts_> tibbe: that's mostly PR
27417:34 <     tibbe> dcoutts_: I haven't seen anything concrete
27517:35 <     tibbe> dcoutts_: a good start would be to actually present a good repository format, that would be step 1a in a good VCS
27617:35 <  dcoutts_> tibbe: it really is absolutely terrible PR, I didn't know half the good things that are cooking until I talked to darcs devs in person.
27717:35 <      SamB> tibbe: what a coincidence
27817:35 <       ndm> tibbe: trust me and duncan, they are improving, they do care
27917:36 <       ndm> they suffer from the worst release annoucement in history, its hard to recover from, but they are trying
28017:36 <     tibbe> dcoutts_: then they should write these good things down and convince us that they will work, the default position should be that they won't because it doesn't work at the moment
28117:36 < quicksilv> but on the other hand, what darcs will be in the future is probably not relevant.
28217:36 <     tibbe> ndm: no I don't
28317:36 < quicksilv> Unless the future is tomorrow.
28417:36 <     tibbe> ndm: sorry
28517:36 < JaffaCake> ndm: submitting a few encouraging stories to reddit would probably help a lot
28617:36 < quicksilv> what is relevant is what choices GHC has now.
28717:37 < JaffaCake> right
28817:37 <     tibbe> I'm hearing lots of things about a magical high performance future which is the same as I've heard as long as I've used darcs
28917:37 <       ndm> tibbe: i can totally understand your position, i didn't believe until Friday :)
29017:37 <  dcoutts_> JaffaCake: we'll announce shortly our conversion of code.h.o
29117:37 < quicksilv> (relevant to this discussion; obviously it's interesting to discuss the future of the darcs project but that's not the scope of this meeting, AIUI)
29217:37 <     tibbe> ndm: I could be convinced if someone actually showed me some evidence, we have lots of evidence that supports that's Git is better
29317:38 < JaffaCake> dcoutts_: time darcs whatsnew --> 16.64s real   9.39s user   4.77s system   85% darcs whatsnew
29417:38 < JaffaCake> on a hashed testsuite repo I just created
29517:38 <  dcoutts_> JaffaCake: over nfs right?
29617:38 < JaffaCake> yep
29717:38 <     tibbe> ndm: just as I don't run my OS on an experimental kernel I don't put my source on an experimental source control system, both are too important for that
29817:38 <  dcoutts_> JaffaCake: have you tried on a local disk?
29917:38 < thoughtpo> tibbe: i agreed with you on glasgow-haskell-users, tbh besides familiarity i'm really wondering what darcs buys us that git can't
30017:39 < JaffaCake> using a darcs v1 repo, it take < 1s
30117:39 < JaffaCake> also over nfs
30217:39 <     Igloo> We could also show you lots of evidence that git is worse, e.g. people talking about the UI, the fact that you can't find out the dependencies of patches when cherry-picking, the fact that a load of people will have to learn how to use another tool
30317:39 <  dcoutts_> JaffaCake: interesting.
30417:39 <     tibbe> thoughtpolice: I don't buy the better interface either, Git actually allows me to do what I want but darcs doesn't
30517:39 <      SamB> tibbe: ndm was in favour of switching anyway ...
30617:39 <  malcolmw> I'm a bit worried about whether it is even possible to do the equivalent of "darcs push" in git.  The git tutorial suggests "email the remote repo owner and tell them to do a pull".
30717:39 <     tibbe> Igloo: the UI in Git is better, darcs UI is simplistic not simple, I can't do what I want to do with it
30817:39 <      SamB> tibbe: darcs has in some sense a better interface to what it does support than git has
30917:40 < thoughtpo> tibbe: everyday git is simple i've found - plus if you get into more complicated matters that might affect your history you've got e.g. git-reflog as a safety net
31017:40 <  nominolo> malcolmw: it works
31117:40 <     tibbe> SamB: right it's better in the case when you really don't need a good UI and worse when it's really critical like when merging
31217:40 < JaffaCake> malcolmw: it's possible to do a push, but they don't recommend that model of development, I think the user manual is a bit lacking there
31317:40 <      SamB> I mean, why else are git stealing the ideas ?
31417:40 <     tibbe> malcolmw: I push to my repo every day
31517:40 <      SamB> tibbe: well, see, darcs doesn't support merging adequately
31617:40 <      SamB> it's not a UI issue -- it is much worse than that
31717:40 <  nominolo> tibbe: sending a patch is way simpler in darcs than in git
31817:40 <     tibbe> malcolmw: however people who use git want to review the patches first generally
31917:40 <      BSP_> Igloo: the ui really isn't that bad, though there is a lot of whinging. the cherry-picking thing is a real issue, but git has more users and a distinctly positive trend in that number of users so i think instead i would argue that ghc staying with darcs forces people to learn /that/
32017:40 <  dcoutts_> JaffaCake: actually that's still pretty odd as that says 4.77s user time, which wouldn't make sense if it's just nfs.
32117:41 <   simonpj> Question 1.  Does anyone know how hard the following is: (a) treat darcs core-library repos as masters (b) keep git shadow copies in GHC git repo, (c) manually propagate changes in both directions, occasionally.  Advantages: destablising changes in *either* direction are done in batches rather than incrementally (we do this for Cabal already); one VCS reqd to build GHC (very strongly advocated by some); no cost to non-GHC folk.   The questi
32217:41 <  nominolo> tibbe: although it's probably just a matter of time
32317:41 <      SamB> whereas nearly all issues with git are UI issues, afaict
32417:41 <       ndm> who is advocating only one VCS?
32517:41 <     tibbe> SamB: right, merging and branching are the two most important operations in a DVCS imho and darcs doesn't do either well
32617:41 <  dcoutts_> simonpj: try slightly shorter Qs, you got cut off at "The quest..."
32717:41 < quicksilv> simonpj: you got clipped at 'The questi'
32817:41 < JaffaCake> dcoutts_: it was 9s user, 5s system, roughly
32917:42 <      SamB> (not to say bad things about git, it just seems like the UI is almost the only place that can have the issues ...)
33017:42 <       ndm> I can't see hwo that makes sense, when we have say both Happy and Parsec as Haskell parsing solutions, which are way more different
33117:42 <   simonpj> ...one VCS reqd to build GHC (very strongly advocated by some); no cost to non-GHC folk.   The question is: how hard is (c)?  Has anyone tried it?
33217:42 <     tibbe> nominolo: yes it's a bit simpler in darcs which is nice
33317:42 <      SamB> simonpj: well, it would be easy to offer that option without using it for development
33417:42 <  dcoutts_> JaffaCake: I can't explain the discrepancy, I get 0.2s real time on darcs v2 format ghc repo. So user time must be tiny there.
33517:43 <  nominolo> simonpj: the git->darcs way is a bit tricky
33617:43 < quicksilv> simonpj: it's easy enough from any of the VCSes being discussed to generate a manual .diff file
33717:43 < JaffaCake> this is a testsuite repo, that might make a difference
33817:43 <      SamB> we could quite easily offer git mirrors of all the required darcs repositories for people who wish to build with only one VCS
33917:43 < quicksilv> simonpj: the question is whetver or not you care about maintaining resolution of commits
34017:43 <  dcoutts_> JaffaCake: ok, I'll try it
34117:43 <  nominolo> simonpj: because it's lossy (history information from git gets lost)
34217:43 < quicksilv> if it came in as 8 separate commits are you happy to apply it as one big one
34317:43 <     Igloo> dcoutts_: It could be doing something silly like opening all the files unnecessarily. That would mean that lots of extra NFS stuff would have to go on under the hood
34417:43 <     tibbe> nominolo: Git typically uses a pull model in e.g. the Linux kernel
34517:43 < quicksilv> if you want to keep the resolution of commits/patches it's *HARD* because the git and darcs models are simply different.
34617:43 <     tibbe> nominolo: github supports that workflow very well
34717:43 <  dcoutts_> Igloo: aye, we should check :-) strace
34817:44 <  nominolo> tibbe: i know. but we want the change to be less disruptive
34917:44 <     Igloo> What's a pull model?
35017:44 <      BSP_> simonpj: i think 2-way sync will be a source of headaches.. 1-way might be possible (e.g. force ghc maintainers to commit to darcs upstream and then pull the synced git repo)
35117:44 <      SamB> simonpj: I think the best option is to keep git mirrors of the darcs repositories for build-only use
35217:44 <  nominolo> tibbe: especially, occasional contributors shouldn't need to require a github account
35317:44 <     tibbe> nominolo: I don't know if they are that disruptive actually, it took me less than a week, there are really good video tutorials out there
35417:44 <      SamB> read-only mirrors
35517:45 <     tibbe> Igloo: I publish my changes in my repo, you pull from me into yours, that's how Linus creates his official repo, pulls from his "lieutenants"
35617:45 < matthew-_> flowing revisions between the two systems can only result in data being lost and will lead to pain when a particular revision can be selected in one system and not the other.
35717:45 <  nominolo> tibbe: less than a week is too long.   it should be git pull ...; hack;  send patch to mailing list
35817:45 <     tibbe> nominolo: you can email then to, it's just one command, I think it even sends the email for you
35917:45 <  nominolo> tibbe: not quite
36017:45 < thoughtpo> the basic premise for a pull model is just that everybody has their own repo and pulls from everyone else
36117:45 < thoughtpo> it works well
36217:45 <     tibbe> matthew-_: I agree
36317:46 <  nominolo> tibbe: at least i haven't figured out how to do that correctly
36417:46 <      SamB> thoughtpolice: well, you don't have to use one or the other model exclusively
36517:46 <     tibbe> nominolo: yes you could that, it takes less than one week to rethink the way you use your DVCS and get a better work flow though
36617:46 <     tibbe> nominolo: learn how to effectively make use branches e.g.
36717:46 <  nominolo> tibbe: yes, i don't doubt that.  but we really need a cheat sheet
36817:46 < thoughtpo> SamB: i'm not saying it cuts any other model out, just that the pull one works well
36917:46 <       ndm> so, exactly who is it that is demanding on VCS? and how many of these people are there? it seems quite clear we aren't going to satisfy everyone and that seems like it would satisfy a lot of people
37017:47 <       ndm> * on -> one
37117:47 <      BSP_> ndm: ChilliX for one
37217:47 <      SamB> thoughtpolice: sure
37317:47 <     Igloo> Manuel was the first to say it
37417:47 <      BSP_> ndm: and dons IIRC
37517:47 <      SamB> hmm, I have to go now -- I have a final
37617:47 <     Igloo> I can't remember who else has agreed
37717:47 < JaffaCake> bye SamB
37817:47 <       ndm> does they have any compelling reason why they can't use two VCS's?
37917:47 <   simonpj> Sadly, read-only git mirrors loses most advantages: ghc devs have to use to VCSs (beause much GHC development involves library changes); and changes in the libs appear incrementally (as now admittedly). Oh well.
38017:47 < thoughtpo> in the case of occasional contributions  git-format-patch works pretty well too
38117:47 <  nominolo> tibbe: any help with http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers will be appreciated
38217:47 <      BSP_> ndm: having two VCSes increases the # of points of failure and makes it harder to get the GHC repo
38317:47 < thoughtpo> you don't have to use git-send-email, sometimes I just make a normal email with regular attachment
38417:48 <     tibbe> nominolo: a cheat sheet is a fine start, there are only a couple of different commands, what I'm trying to sent is that Git is meant to be used with a different workflow which works better for it
38517:48 <       ndm> BSP_: yes, but not by a large margin - having perl in the sources is a bigger issue, i would have thought
38617:48 < JaffaCake> so, if multiple VCSs is out, and GHC-only branches is out, we have no solutions
38717:48 < matthew-_> I think your not going to find out useful answers to these issues by asking questions. I think you are going to have to try each proposed system for a week or so and loose lots of time to work out what to do
38817:48 < JaffaCake> except moving all the libraries to git, of course
38917:49 < thoughtpo> tibbe: right - darcs is familiar but emulating it with git won't get you the most out of it
39017:49 <      BSP_> ndm: i'm not necessarily advocating those reasons, but those are the points important to dons/chillix
39117:49 <      BSP_> argue it out with them :)
39217:49 <     tibbe> nominolo: I'll try to add something whenever people complain about problems :)
39317:49 <       ndm> BSP_: will do, when i find the appropriate email :)
39417:50 < JaffaCake> malcolmw: would you object to using git for the base library?
39517:50 <  nominolo> tibbe: yeah, well, that doesn't really help
39617:50 <     tibbe> JaffaCake: I've been thinking that GHC only branches of core libraries is a good idea anyway because of the breakage of different compilers sharing code with compiler specific things in them
39717:50 <  malcolmw> JaffaCake: if I knew more about git, I might be able to answer that
39817:51 < JaffaCake> dcoutts_: ooh, a darcs-2 repo is quite a bit faster, but still not as fast as a darcs-1 repo
39917:51 <     tibbe> nominolo: maybe I could try to talk a bit about topic branches when I find some time
40017:51 < JaffaCake> 3.53s real   0.95s user   0.52s system   41% darcs wh
40117:51 <  malcolmw> JaffaCake: I have been investigating git, but haven't yet found answers to all of my questions
40217:51 <     tibbe> malcolmw: maybe I could try to answer some
40317:51 < thoughtpo> tibbe: yeah, it would also clear things up hopefully (we wouldn't necessarily need so many #ifdef's to control everything)
40417:51 <  malcolmw> someone on #darcs fixed whatsnew to be a lot faster a few days ago
40517:52              tibbe wishes there was an easy way to do this over a video conference.
40617:52 <  dcoutts_> JaffaCake: ok, so user time is down. For abs time, I wonder if it's just as Igloo says that it's doing something that nfs doesn't like.
40717:52 <     Igloo> I think using git for the libraries will raise the bar for patches from the community
40817:52 <     Igloo> I know that I had great pain when trying to make a couple of small patches to send to ohloh
40917:52 <     tibbe> thoughtpolice: I've refrained from editing the code because of all these ifdefs
41017:52 <       ndm> i agre with Igloo
41117:52 <  malcolmw> tibbe: what I hear you saying is "don't use the push model, use pull instead", but that is not very satisfactory for my type of workflow
41217:52 <  nominolo> tibbe: the gitcast screencasts are pretty bad.  way too confusing
41317:52 <     tibbe> thoughtpolice: it's easier to e.g. rewrite the whole socket library to use bytestrings than trying to reuse parts of Network.Socket
41417:52 <       ndm> i.e. having the filepath library, one of the core ones, move to git, would be a bit annoying
41517:52              <   dolio!n=dolio@216.68.186.59 [Read error: 104 (Connection reset by peer)]
41617:53              >>> dolio!n=dolio@216.68.186.59
41717:53 <     tibbe> nominolo: there's a really good one, let me see if I bookmarked it
41817:53 < JaffaCake> ndm: annoying in what sense?
41917:53 < thoughtpo> tibbe: yeah there's no telling if you'll break one thing or the other. ghc has already quite heavily modified many of these libraries, so ghc-specfic branches don't seem like an insane idea to me
42017:53 <     tibbe> malcolmw: perhaps you could start by describing what you want to do?
42117:54 <     tibbe> thoughtpolice: I agree, JaffaCake, I think we should consider GHC only branches no matter what happens to the VCS discussion
42217:54 <  malcolmw> tibbe: workflow one: pull latest changes from upstream repo, fix bugs, record, test, amend-record, test, push back upstream
42317:54 <       ndm> JaffaCake: all libraries are in darcs, having some in darcs and some in git, based on whether ghc uses them, will make a large difference with no good reason
42417:54 < JaffaCake> tibbe: yes, I agree - the question is whether it's feasible
42517:55 <     tibbe> malcolmw: use git pull; git commit; git commit --amend; git push
42617:55 <       ndm> i.e. two VCS's are sensible in two different plcaes, but having two VCS's for one thing (hackage libraries) is less sensible
42717:55 <     tibbe> JaffaCake: yeah, I would like to take a stab at it but I have three other projects running atm
42817:55 <       ndm> how much is it Chillx and dons want one VCS, and how much do they just want darcs?
42917:55 <  dcoutts_> JaffaCake: btw, would it be possible to use a local disk, it makes builds quite a bit faster too, especially linking.
43017:55 <  nominolo> malcolmw: can you add those to the wiki page?
43117:55 <       ndm> (darcs -> git)
43217:55 <  nominolo> malcolmw: i think that's a much better permanent location
43317:56 <     tibbe> ndm: did dons want darcs?
43417:56 < JaffaCake> dcoutts_: I use local disk for my builds, nfs for my source
43517:56 <  malcolmw> nominolo: I could add it, if darcs.haskell.org was responding (which it isn't)
43617:56 < JaffaCake> because nfs is backed up
43717:56 <      BSP_> ndm: iirc chiiix prefers darcs and dons wants git, but both think having two VCses is going to be a problem
43817:56 <  dcoutts_> JaffaCake: right, yes. Hmm.
43917:56 < thoughtpo> imo just wrapping everything up in #ifdefs in the core libs just adds a lot of complexity, there's a lot of really ghc-specific code there that I'm sure changes all the time. breaking them off to be ghc-specific might be tough but I think it would undoubtly clean things up
44017:57 < thoughtpo> i think it's worth further looking into, anyway
44117:57 <     Igloo> thoughtpolice: We're working on reducing the ifdefs
44217:57 < JaffaCake> tibbe: dons is a git fan, I think
44317:57 <     tibbe> malcolmw: if you have any pending changes in your local copy when you pull and your repo is not published you it's recommended that you do git pull --rebase so it appears like your changes were made after the ones in the official repo
44417:57 <     tibbe> JaffaCake: that's what I thought
44517:57 <  nominolo> JaffaCake: a working solution would be to have the ghc library branch in Git, with two branches darcs-import, and master
44617:57 <  dcoutts_> tibbe: as I understand it, dons wants a single scm for ghc and he's convinced git is better for ghc. He still advocates darcs for the rest of the community and smaller projects.
44717:57 < JaffaCake> nominolo: right, I think I suggested that on the list
44817:58 <  nominolo> JaffaCake: if the darcs-import history remains linear, transfering patches could work
44917:58 <  malcolmw> tibbe: workflow 2: edit in master repo, record, push to backup repo, switch to laptop, pull from backup repo, edit, record, push to backup repo, repeat
45017:58 < thoughtpo> tibbe: right, then you won't have a recursive merge which can make the branch flow look a little messy
45117:58 <  nominolo> JaffaCake: maybe better even: darcs-mirror, darcs-outgoing, master
45217:58 <     tibbe> dcoutts_: as far as I'm concerned people can use what they want, I just don't want people to 1) have a problem like GHC and 2) sit and wait for magic darcs
45317:59 <     tibbe> malcolmw: push and pull in git, there's no difference
45417:59 < JaffaCake> nominolo: the problem as I see it that we'd push patches upstream, and then get them back again via darcs-mirror and have to re-merge
45517:59 <     tibbe> thoughtpolice: exactly
45617:59 < thoughtpo> i would love to be proven wrong about darcs, it would make this whole conversation go away. i'm just not convinced it can be done in a reasonable amount of time
45717:59 <  nominolo> JaffaCake: not if we keep our local branches anyway
45817:59 < thoughtpo> and i've already found home with git for the most part, because I don't see how I've lost anything personally
45917:59 <     Igloo> JaffaCake: At some point someone is going to have to merge conflicts when pushing upstream, too
46017:59 <  nominolo> JaffaCake: i mean, GHC-branches
46118:00 <     tibbe> dcoutts_: I would also be happy if some developers tried Git and found out how much better it is, just for their personal productivity
46218:00 <     Igloo> JaffaCake: And probably someone not familiar with the changes in question
46318:00 <     Igloo> s/merge/resolve/
46418:00 <     tibbe> dcoutts_: IMHO
46518:00 <  nominolo> JaffaCake: the problem is that changes may not go back into the darcs repo due to inconvenience
46618:00 <  nominolo> JaffaCake: i.e., the incentive to keep them in sync is smaller
46718:01 < JaffaCake> right
46818:01 <     tibbe> Igloo: right, and malcolmw can pull whenever he feels ready to merge things that might potentially break NHC
46918:01 <  dcoutts_> tibbe: people typically only do that when they perceive they have a problem with their existing system. That's clearly the case for ghc, but not for most everything else.
47018:01 < matthew-_> it would seem to me that the people who are in pain, and thus have the motivation to move are the ghc devs, and moving creates pain for others who have no motivation to move. This helps no one, I know, but if discussion doesn't get anywhere, I think unilateral action is better than continuing to suffer
47118:01 <       ndm> ok, i have to head off, i still advocate git for ghc and darcs for everything else, but get the feeling i'm going to be learning git anyway
47218:01 < JaffaCake> but we'd only be able to make a release with fixed versions of the libraries, which would necessitate a merge
47318:02 <     tibbe> dcoutts_: maybe we could just switch GHC and the developers will switch the libraries after using Git and darcs side by side for a month :)
47418:02 <     Igloo> JaffaCake: Wouldn't the GHC branch already have the fixes?
47518:02 < quicksilv> JaffaCake: The merge problems are starting to convince me it's better to leave the libraries entirely in darcs.
47618:02 <       ndm> tibbe: now that sounds like a great plan, staged move, and follow if it turns out to be really good
47718:02 <     Igloo> JaffaCake: Or do you mean we'd have to release directory 2.0, which would mean merging the changes first?
47818:02 < JaffaCake> yes
47918:02 < quicksilv> Igloo: if you stay with in one VCS, it can recognise "I've already got this patch".
48018:03 < quicksilv> Igloo: if you round-trip via a different VCS, it thinks it it a fresh patch
48118:03 < quicksilv> and gets confused.
48218:03 < quicksilv> that's JaffaCake's point I think.
48318:03 <     tibbe> ndm: but as I mentioned to JaffaCake I think they should branch all core libraries because they are compiler specific and sharing them creates lots of troubles
48418:03 < JaffaCake> quicksilver: right
48518:03 < JaffaCake> two branches both in git would be easy
48618:03 <     Igloo> tibbe: We are working on making them much less compiler-specific
48718:03 <     tibbe> ndm: with the two combined they would only use darcs to get patches from upstream
48818:03 <     Igloo> tibbe: Branching them will only make this harder
48918:04 <     tibbe> Igloo: that's a loosing battle, over time new compiler dependent things will only creep back in
49018:04 <  dcoutts_> tibbe: then you'd get nhc's base exporting an even more different api than now, and I'd pull my hair out trying to make Cabal work with hugs, ghc, nhc, yhc etc.
49118:04 <     tibbe> Igloo: it's inherit in the model
49218:05 <     Igloo> tibbe: I don't think you're right. Once things are shared, it should be easy to keep it that way
49318:05 < JaffaCake> changes will have cross-library dependencies, which means we have to merge them all at once too
49418:05 <     tibbe> dcoutts_: the problem there is that there's no agreed API no?
49518:05 <     tibbe> dcoutts_: if they all exported the same API that would be fine?
49618:05 <  dcoutts_> tibbe: there's a mostly agreed api, which is the vast majority of stuff that's not inside ifdefs
49718:06              <   ndm!i=8afbf104@gateway/web/ajax/mibbit.com/x-d6e848e13f6588db ["http://www.mibbit.com ajax IRC Client"]
49818:06 < JaffaCake> I have to go... thanks for a lively discussion folks!
49918:06 <     tibbe> dcoutts_: so the right solution would be to come up with a whole API then?
50018:06 <  dcoutts_> tibbe: where it goes wrong is when we add stuff that's ghc-specific and then other things start depending on that.
50118:06 <     tibbe> dcoutts_: it sounds like you're creating new problems because the base problem is not being tackled
50218:06 <  dcoutts_> tibbe: no, just have fewer #ifdefed things
50318:06 <     Igloo> See ya, JaffaCake
50418:06 <      BSP_> JaffaCake: bye!
50518:06 <  dcoutts_> JaffaCake: taraa
50618:06 <     tibbe> JaffaCake: bye
50718:07 <  dcoutts_> tibbe: I agree with Igloo, we should keep base shared and work on reducing the level of #ifdeferry
50818:07 <  dcoutts_> tibbe: eg by extracting ghc-specific primitive out of the bottom of base into another package
50918:07 <  dcoutts_> tibbe: leaving base with less #ifdefs and importing base-nhc, base-ghc etc for a common set of primitives
51018:08 <     tibbe> dcoutts_: if all compiler specific things can go out of base that would of course be good too
51118:08 <     tibbe> dcoutts_: it's in fact the same solution
51218:08 <  dcoutts_> tibbe: that's the goal as I understand it, and we're getting closer
51318:08 <  dcoutts_> Igloo: have I got that right?
51418:08 <     Igloo> Yup
51518:09              <   leather!n=leather@dyn245.cs.uu.nl []
51618:09 < matthew-_> if forking the core libraries and moving everything over to git from there on downwards meant that the ghc devs were more productive and ghc development was faster and more exciting then I would  think that would be the way forwards
51718:10 <     tibbe> matthew-_: me too
51818:10 < thoughtpo> agreed
51918:11 <     tibbe> it's really great that there are many implementations but not if the minor ones hold the major one back
52018:11 <     Igloo> matthew-_: Permanently forking, you mean?
52118:11 < thoughtpo> tibbe: i also agree, i do not mean to discredit ndm or malcolmw's work, but ghc is easily the most active implementation and fastest moving target
52218:11 <     tibbe> Igloo: I think that makes total sense, GCC wouldn't share libc with Visual C++
52318:12 <  dcoutts_> thoughtpolice: of course that's true, but there's a limit where we make it impossible to maintain non-ghc with the available level of effort
52418:12 < thoughtpo> compatability with other compilers is good but should we go through extraordinary amount of pains to keep it the way it is? i think forking the core libs at the very least is feasible while keeping those other implementations working
52518:12 <     tibbe> Igloo: at some level there can be no sharing, maybe we could push that level lower but somewhere we should expect that each compiler has to provide its own implementation
52618:12 <  dcoutts_> having no other working Haskell systems is a loss
52718:13 <     tibbe> dcoutts_: I don't think that's an argument for holding GHC back. If there's not enough people around to maintain other compilers that doesn't mean that the GHC developers should
52818:13 <  dcoutts_> there are enough people at the moment
52918:13 <  malcolmw> I hope people do not get the impression that it is other compilers that are holding ghc back from great strides.  That would be completely false.
53018:14              <   TD!n=tmdubui@144.51.26.41 []
53118:14 < matthew-_> dcoutts_: at least to me, there is no other working Haskell system as Haskell to me is not h98 but h98 with 90% of the GHC extensions in
53218:14 <     tibbe> dcoutts_: but then there's no problem with having the libraries split no?
53318:14 <  malcolmw> Most of the pain that GHC developers experience is the fault of other GHC developers.
53418:14 <  malcolmw> and perhaps of darcs.
53518:14 <     tibbe> malcolmw: it's holding me back from editing the code in the core libraries
53618:14 < thoughtpo> project management is also apart of the problem I think, darcs as well
53718:14 <  dcoutts_> tibbe: I'm not qualified to comment on the difficulty of merging back and forth between upstream darcs repos and downstream git ones
53818:15 <     tibbe> dcoutts_: this issue is kinda separate
53918:15 <     tibbe> dcoutts_: it applies even if everyone used the same vcas
54018:15 <     tibbe> vcs
54118:15 <  nominolo> dcoutts_: i don't think git would be downstream
54218:15              >>> ttt--!n=ubuntu@78-23-117-225.access.telenet.be
54318:15              <   carp_!n=jmc@sneezy.cs.nott.ac.uk ["My damn controlling terminal disappeared!"]
54418:15 <  dcoutts_> tibbe: well, Cabal already has a ghc fork, but it's fairly regularly synced from Cabal HEAD
54518:16 <     tibbe> malcolmw: that's another good point (about other GHC developers). it probably exists because so many people can push to head
54618:16 <  dcoutts_> nominolo: it would if ghc's Cabal repo were in git
54718:16 <     Igloo> dcoutts_: It's not really a fork, it's just a lagged copy
54818:16 <     tibbe> dcoutts_: couldn't we do the same with other libraries?
54918:16 <  dcoutts_> Igloo: right
55018:16 <     Igloo> We never have local changes (except when I forget to push to the right place)
55118:16 <     Igloo> tibbe: It makes things less convenient
55218:16 <  nominolo> dcoutts_: but only because pushing to cabal's main repo is less hassle (no validate)
55318:16 <  dcoutts_> tibbe: perfectly possible, but it doesn't buy you a whole lot if you still need to use two vcs's to push to the upstream repos
55418:17 <  dcoutts_> nominolo: right, that's why we lag it
55518:17 <  dcoutts_> which seems to work pretty well
55618:17 <  dcoutts_> Igloo syncs occasionally and validates in batches
55718:17 <  dcoutts_> so I don't have to validate on every single push
55818:18 <     tibbe> Igloo: I can't just see how a model where different implementations share the same file with implementation details that differ will ever work
55918:18 <  nominolo> right, so for base, malcolm would have to sync from the git repo to the darcs repo
56018:18 <  malcolmw> eek!
56118:18 <  dcoutts_> nominolo: it's a question of who does it, the original comtter, or the ghc devs
56218:18 <     Igloo> tibbe: Everything can be built on top of very little per-impl datatypes and primitives
56318:18 <  dcoutts_> nominolo: it's a question of which is upstream vs down
56418:19 <  nominolo> dcoutts_: ok, that'd mean that malcolm would need to use both vcs's.  yeah, doesn't really solve anything
56518:19 < quicksilv> matthew-_: to be fair, you're not typical because you recently did a very large project involving type-hackery.
56618:19 <     tibbe> Igloo: that would be great
56718:19 <     tibbe> Igloo: that is the solution that I am proposing
56818:19 <     Igloo> tibbe: OK, but that doesn't require any forking
56918:19 <  dcoutts_> nominolo: not if upstream was darcs and there is a git mirror
57018:19 < quicksilv> matthew-_: furthermore, it would be sad to push things further apart; it's nice to keep the bar as low as possible for one of the other implementations to keep up
57118:19 < quicksilv> matthew-_: hugs is certainly very widely used.
57218:19 <     tibbe> Igloo: *if* that is possible we should be able to get rid of all the if-defs. If we can't get rid of them all it's probably because it's not possible at the level we're trying to do it
57318:19 <  malcolmw> I've spent time maintaining a separate fork of the base library once before.  It slips away from the mainstream amazingly quickly, and leads to lots of complaints from users.
57418:19 <  nominolo> dcoutts_: then it'd be harder for the ghc developers to add patches
57518:20 < matthew-_> quicksilver: oh true. I know I'm not typical, but I suspect that probably over 50% use non h98 extensions and a good chunk of those use ghc only extensions
57618:20 <     tibbe> Igloo: you could use a module hierarchy to divide the different compilers if you would like to
57718:20 <  dcoutts_> nominolo: yes, we can't have both a common upstream in darcs and make it easy for ghc devs to push using just one vcs.
57818:20 <     tibbe> Igloo: your build could still break however
57918:20 <     Igloo> matthew-_: If H' ever gets completed then things should improve
58018:20 < quicksilv> matthew-_: I suspect the number is closer to 3% than 50%. Can you prove it? :)
58118:20 <  dcoutts_> nominolo: which is what brings us to moving all the ghc+libs or none
58218:21 < matthew-_> quicksilver: no, but I have a "feeling" ... ;)
58318:21 <  nominolo> dcoutts_: i wonder how hard a bidirectional mirror really is
58418:21              <   jdcmm!n=t-jodias@nat/microsoft/x-6822481535607c96 ["User disconnected"]
58518:21 <  dcoutts_> nominolo: it sounds pretty terrifying :-)
58618:21 <  nominolo> why?
58718:21 <  dcoutts_> nominolo: since the conflicts would happen just at the point where you're converting systems
58818:21 <  dcoutts_> so you get none of the clever stuff that either system uses to resolve conflicts
58918:21 <      BSP_> nominolo: the tailor wiki has a report from the author that two-way sync is really difficult.. and i would tend to believe him
59018:21              malcolmw wonders how much ChilliX and rl actually ever modify the core libs?
59118:21 < matthew-_> Igloo, whereas, if you fork, there's arguably less need for H'
59218:22 <     tibbe> nominolo: I think it would be lossy
59318:22 < matthew-_> I think it would be lossy too
59418:23 <  dcoutts_> tibbe: you're thinking of an implementation defined language, we've been happy historically with a spec defined language. We realise of course that ghc drives developments in the language.
59518:23 < quicksilv> you can do two-way sync fairly reliably between systems with compatible underlying models, although it still requires a lot of work
59618:23 < quicksilv> bzr <-> git, say
59718:23 < quicksilv> git and darcs have incompatible models in important ways.
59818:23 < matthew-_> really? conflicting commits? atomicity issue?
59918:23 < quicksilv> darcs has patches which commute.
60018:23 < quicksilv> git has a tree of versions with merge points
60118:24 < quicksilv> you can find adjunctions between these two categories
60218:24 < quicksilv> but not a two-sided inverse
60318:24 < quicksilv> if you'll excuse the category excursion.
60418:24 <  nominolo> quicksilver: git has rebase
60518:25              <   simonpj!n=simonpj@nat/microsoft/x-e86c1613f8b40c5f []
60618:25 <  nominolo> and git can recognise if you have the same patches in two branches but with a different history
60718:25 < quicksilv> of course.
60818:25 < quicksilv> but that's still not enough.
60918:25 < quicksilv> I don't believe.
61018:25 <  nominolo> whereas darcs doesn't (really) care about history
61118:26 <  nominolo> no, it's not simple
61218:26 < quicksilv> Yeah. Darcs is like a big cloud of patches with dependencies.
61318:26 <     tibbe> dcoutts_: I'm not really sure what you're saying
61418:26 < quicksilv> Git really is like a tree annotated with merge points.
61518:26 <  nominolo> but maybe with a minimum number of rules it could be doable
61618:26 < quicksilv> You can 'twist' the tree, which is what rebase does
61718:26 < quicksilv> but all that does it permute what you consider the 'main branch'
61818:26 < quicksilv> as it happens I actually find the git/bzr model a more accurate one for the way I think of systems development.
61918:26 < matthew-_> quicksilver: also, the hugs count isn't important, because everyone using hugs could use ghc. The important count is the number of people using ghc who cannot use hugs or other implementations. And you only have to look at all the people using fundeps or associated data types or so forth to realise how many people stay at the bleeding edge of the language
62018:27 <  nominolo> i'm saying that the darcs import/export branch simply has a linear history
62118:28 <  nominolo> so you have a branch on the git side and a branch for staying in sync with darcs
62218:28 < thoughtpo> matthew-_: even smaller extensions like generalised newtype deriving, overlapping instances and even smaller ones like type operators
62318:28 <  nominolo> though, the big Q is what happens in case of a commit.  and where does it happen
62418:29 <     tibbe> thoughtpolice: I find 2 rank types neccesary to do any fold based I/O
62518:29 <     tibbe> new type deriving is very pratical
62618:29 <     tibbe> and some other deriving
62718:29 <     tibbe> bang patterns
62818:29 < thoughtpo> tibbe: yes, there are lots of small extensions that many people use that I don't think many people think about
62918:30 < thoughtpo> (i love newtype deriving!)
63018:30 <  nominolo> pattern signatures
63118:30 <     tibbe> that one too
63218:30 <  nominolo> (needed for extensible exceptions, btw)
63318:30 < thoughtpo> cribbing hackage isn't indicative of it either, because many people might use {-# LANGUAGE .. #-} pragmas rather than specifying extensions in .cabal files
63418:30              tibbe wants extensible exceptions
63518:30 <  malcolmw> matthew-_: there are people who are unable to use ghc, because it won't build on their platform, and who use nhc98 instead
63618:30 < thoughtpo> extensible exceptions look awesome :)
63718:31 <     tibbe> malcolmw: that's great :D
63818:31 <     tibbe> malcolmw: a good selling point for nhc
63918:31 < thoughtpo> but there are a lot of extensions enabled by GHC, and about 90% those are only implemented about GHC, and many projects use these, if only one
64018:31 <  malcolmw> tibbe: nhc98 can even cross-compile for other architectures
64118:31 < thoughtpo> malcolmw: I used nhc98 on my dragonflbsd box when I had it up, very nice :)
64218:31 <     tibbe> malcolmw: cool!
64318:32 < thoughtpo> mainly because I ran into some complications trying to port GHC
64418:32 <     tibbe> malcolmw: I hope you understand that I don't have anything against nhc98, I'm trying to make a move towards a model that works better for all
64518:32 <     tibbe> currently the build is breaking a lot
64618:32 < thoughtpo> which - i only hope - will get better in the future
64718:32 <  malcolmw> tibbe: I think we all want that
64818:32 < thoughtpo> (although now it looks like I'll have to port libffi...)
64918:32 <     tibbe> and I think that's because the model we use today is flawed in a few ways
65018:33 <     tibbe> 1. mixing the particular with the general in the core libs
65118:33 <     tibbe> 2. too many people commiting directly to ghc could be another
65218:34 <     Igloo> nominolo: You don't need pattern sigs for ext exceps, it just makes them easier to use
65318:38 <  mnislaih> nominolo: thanks for the useful darcs-git equivalence at the wiki. are you aware of any git idiom for 'darcs put' ?
65418:38 <     tibbe> mnislaih: what's the difference between push and put, does put create a new repo?
65518:39              <   Svrog!n=ivan@d5153048F.access.telenet.be ["Ex-Chat"]
65618:39 <  mnislaih> tibbe, put is like get but in the other direction
65718:39 <     tibbe> mnislaih: ok
65818:39 <     tibbe> Git uses much more of a pull model for so many things
65918:39 <  mnislaih> put is handy when you want to copy a repo to a remote ssh box but your machine is not accesible
66018:39 <     tibbe> mnislaih: yeah
66118:40 <     tibbe> mnislaih: how can you do it if the machine is not accessible?
66218:41 <  mnislaih> I am behind a NAT router for instance, I can ssh into other boxes, but the other way around is much more inconvenient
66318:41 <  malcolmw> yeah, I have the same situation, which is why push is so important
66418:42 <     tibbe> push works but I don't know if put exists
66518:44 <  dcoutts_> put isn't so important
66618:45 <  dcoutts_> since put is fairly rare and can be done using ssh + tar
66718:45 <  mnislaih> dcoutts_: agreed, put can be lived without, but it is often handy
66818:45 <  dcoutts_> or maybe other people use it a lot
66918:46 <  dcoutts_> mnislaih: aye
67018:46 <     tibbe> dcoutts_: I just use a github repo
67118:46 <     tibbe> so I can always pull from there if I'm behind a firewall
67218:46              >>> danten!n=danten@194-237-165-218-no48.tbcn.telia.com
67318:46 <     tibbe> it's a really sweet service
67418:46 <  dcoutts_> tibbe: aye, much like code.haskell.org
67518:47 <     tibbe> probably why so many open source projects are moving there
67618:47 <     tibbe> :)
67718:47 < thoughtpo> agreed, github rocks :)
67818:47 < thoughtpo> don't know about the pay-thing but if I was *that* cheap there is always gitorious or repo.or.cz still
67918:47 <     tibbe> it really supports the git model well
68018:48              >>> andyjgill_!n=andy@150.67.124.24.cm.sunflower.com
68118:48 <     tibbe> just click the for button and you have a repo others can pull from
68218:48 < quicksilv> malcolmw: FWIW, bzr doesn't have 'put' but in that circumstance I 'push' to some third box.
68318:48 < quicksilv> malcolmw: and then 'get' from it.
68418:48 < quicksilv> as it happens I generally have access to some third box they can all see.
68518:50              <   andyjgill!n=andy@150.67.124.24.cm.sunflower.com [Read error: 60 (Operation timed out)]
68618:51 <  mnislaih> dcoutts_: ah, maybe there is no need to tar + ssh . Shouldn't init and then push do it ?
68718:51 <  dcoutts_> mnislaih: no, push has to be to an existing repo, that's what makes put different.
68818:52 <  dcoutts_> put creates the new repo on the far side
68918:52 <  mnislaih>  dcoutts_ I mean init an empty repo on the remote side and then push to that
69018:52 <  dcoutts_> mnislaih: yes, that'd work I suppose
69118:52 <  dcoutts_> mnislaih: it's a neat feature but hardly earth shattering
69218:53 <  dcoutts_> and we're not really supposed to be debating which of git or darcs is the cooler
69318:53 <  mnislaih> dcoutts_: I'm not on that discussion really
69418:53 <  mnislaih> just happened to be using git and came to ask for help
69518:53 <  dcoutts_> mnislaih: it's a tiring discussion :-)
69618:53 <    glguy_> when making your centralized repo, remembe to: git --bare init --shared
69718:54 <     tibbe> yes
69818:54 <  mnislaih> glguy_: thanks, but what doesthat mean?
69918:54 <     tibbe> I don't remember needing the --shared
70018:54 <     tibbe> what's it for?
70118:54 <    glguy_> --shared sets the group permissions
70218:54 <  dcoutts_> mnislaih: btw, I'm going to try and do the conversion you started of cabal-install's config stuff
70318:54 <    glguy_> and sticky bits
70418:54 <     tibbe> mnislaih: bare means that there's no working copy
70518:54 <     tibbe> mnislaih: you can't work in the repo
70618:54 <    glguy_> --shared -> --shared=group
70718:54 <     tibbe> glguy_: oh I see
70818:54 <    glguy_> --bare is good for a push repo, because push in git doesn't update the working directory
70918:55 <  mnislaih> dcoutts_: go ahead, and sorry, I'm too busy and low energy these days
71018:55 <     tibbe> glguy_: you don't want to have people working directly in a published repo
71118:55 <    glguy_> and you don't want to make changes in a directory that is getting pushed to
71218:55 <  dcoutts_> mnislaih: no probs, you did the majority of the work
71318:55 <  mnislaih> tibbe, glguy_ thanks for the tips
71418:56 <     tibbe> you're welcome
71518:56 <    glguy_> :)