Camelia, the Perl 6 bug

IRC log for #darcs, 2010-08-09

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:29 balor joined #darcs
00:45 mornfall Now that's better. darcs convert --import fastimport-tahoe-lafs  211,68s user 3,05s system 95% cpu 3:45,49 total
00:58 zooko joined #darcs
01:20 mornfall Hm. Could be that a map of bytestrings is becoming rather slow on the order of ~10k items in it?
01:21 mornfall (of the form 1, 2, ... 10000, in form of decimal strings...)
01:38 mornfall Something's utterly wrong. My profiling binary is twice as fast as non-profiling?
01:45 mornfall Just a little over one minute. \o/
01:56 mornfall ... can't win... it's either fast or correct, but not both
02:06 lispy mornfall: I think my parser is now either just as fast as the previous darcs parser or faster (any jitter during benchmarks makes it impossible to get a good reading)
02:07 mornfall :)
02:07 mornfall Sounds good.
02:12 mornfall git -> darcs, tahoe-lafs 3 minutes, ghc-testsuite 6m30... not blazing-fast but not unusably slow either
02:39 mornfall tahoe-lafs down to 1:20 (and staying OK) ... so much for cutting times in half
02:42 mornfall (ghc-testsuite to 3m20 which is not as nice, but still not bad)
02:43 mornfall So tomorrow boring stuff like parsing/converting dates and tags and authors...
02:51 lispy oh.  Hrm.  I just realized my 'darcs-unmodified' that I bench against includes my refactor now
02:51 lispy So, I guess I sped it up relative to the stuff Heffalump applied, but maybe not relative to without it
03:17 abuiles joined #darcs
03:18 abuiles sm, are you around ?
03:22 sshc_ joined #darcs
03:29 sm hi abuiles
03:29 abuiles sm, how is it going ?
03:29 sm good, relaxing. What's up ?
03:30 sm I'm not really here, just checking if you need something
03:30 abuiles sm, my patch has been applied, maybe when you have a chance could you check if it the problem you were having still appears.. ( it shouldn't )
03:30 sm ah, thanks
03:30 exlevan joined #darcs
03:30 sm I forgot the issue, do you remember the number ?
03:31 exlevan morning
03:31 abuiles sm: not sure if you open a ticket, but it was the one of darcs hanging up
03:31 abuiles hi exlevan
03:32 sm thanks
03:33 abuiles sm: cool,  thanks to you too.
03:39 sshc joined #darcs
03:40 twb joined #darcs
04:03 zooko joined #darcs
04:12 bos joined #darcs
04:28 abuiles left #darcs
04:55 clochette joined #darcs
05:16 lispy mapPrimFL is buggy
06:02 twb joined #darcs
07:00 Quiark joined #darcs
07:02 darcscommitbot joined #darcs
07:03 darcswikibot joined #darcs
07:18 twb joined #darcs
07:56 Quiark I don't understand this behaviour - when there is a conflict and I do a revert, the conflicted piece of code simply disappears and darcs says everything is ok...?
08:07 Jaak joined #darcs
08:19 Quiark Which probably also explains why the lines which resolve a conflict are marked as + even though they were there before.
08:24 twb joined #darcs
08:50 mornfall exlevan: Early, duh. :) I went to sleep maybe 30 minutes before you got up :D
08:58 mornfall Quiark: That's because conflict in behaves as "neither side has happened". That's because this is the simplest unique resolution of a conflict. Anything you want to add on top has to be done explicitly (the resolution).
08:58 mornfall +darcs
08:59 Quiark So maybe I didn't accidentally remove the function - I just did a revert after a conflict.
09:00 Quiark Anyway, I gave up investigating and simply recorded a new patch with the correct contents.
09:01 kowey joined #darcs
09:01 kowey good morning
09:01 lambdabot kowey: You have 3 new messages. '/msg lambdabot @messages' to read them.
09:02 kowey Quiark: I've been reading the logs, sorry conflicts are being so tricky! It's one of the weak spots in the Darcs UI
09:02 kowey Quiark: I'm trying to encourage more use of the FAQs within #darcs, for example, http://wiki.darcs.net/ConflictsFAQ
09:04 mornfall : - )
09:04 kowey I think the general model is a friendly FAQ link followed by personalised advice
09:05 kowey so Quiark, in your case, if you make a conflict disappear by reverting, you can always recover it by doing "darcs mark-conflicts"
09:06 twb Though if you only reverted some things, it might make a mess of other files' unrecorded changes
09:07 Quiark I think I understand it better now. There is even a chance I actually did it right, but I'm not sure :)
09:07 kowey one severe error I made in #darcs was when tibbe was complaining about conflicts, I tried to justify the behaviour as it stemming from Darcs trying really hard to get things right
09:08 kowey (he was saying that "getting conflicts right is important" [paraphrasing])
09:08 kowey now, this sort of statement makes sense if you're a Darcs hacker
09:08 kowey but for a frustrated user like tibbe... argh!
09:11 kowey Quiark: if there's anything Darcs can do to give you confidence you did it right, let me know
09:11 twb built-in pep talks
09:12 kowey one issue is that Darcs does not give a "patch X conflicts with patch Y"
09:12 twb Tell me about it
09:12 twb And it defaults to --allow-conflicts, which imo is evil
09:12 kowey only for pull
09:12 twb I guess
09:13 kowey it actually defaults to --mark-conflicts for pull
09:13 kowey and --dont-allow-conflicts for apply
09:14 kowey which translates to --dont-allow-conflicts for push
09:14 kowey the conflicts FAQ should maybe start talking about --skip-conflicts
09:15 twb !
09:15 twb I never knew that one
09:15 Quiark kowey, it seems the biggest problem was that I didn't understand that doing a revert on a conflicted repo is what made the function disappear
09:16 twb I've been looping over --dont-allow-conflicts
09:16 kowey it's a relatively new feature by Heffalump
09:16 kowey introduced in Darcs 2.4
09:16 Quiark kowey, so I was trying to find the patch in which I deleted it
09:17 mornfall kowey: About the Mac, give it some time I guess. Things at uni tend to be slow, moreso during summer holidays.
09:17 mornfall kowey: If we are in a hurry, I'd suggest trying to get it hosted in the US.
09:17 kowey thanks, mornfall.. just launching things in parallel
09:18 kowey perhaps osuosl would be able to oblige
09:18 kowey or maybe this sort of thing is way outside their remit
09:18 mornfall Well, I have a KVM farm now. Maybe OSX runs in KVM? :)
09:19 kowey hmm! http://osuosl.org/services/hosting/policy
09:19 kowey google says: http://www.insanelymac.com/for​um/index.php?showtopic=133321
09:20 kowey actually maybe getting it hosted at osuosl would be the sanest solution
09:20 kowey and would be long-term safest (in terms of what happens when we get a Dr mornfall)
09:20 * kowey sends them an email to see if it'd be possible
09:27 mornfall It seems that Darwin is dead.
09:27 mornfall (If it wasn't I'd install that somewhere.)
09:27 kowey there is a PureDarwin project which tries to take up the mantle
09:27 kowey but they haven't gotten to the release an ISO stage, if I understand
09:27 mornfall True, I have an ISO. I'll see if it boots in KVM (it didn't in VirtualBox).
09:27 kowey this would also avoid the issue of being against Apple's EULA
09:28 mornfall But if we can have a Mac Mini at OSUOSL, that'd be probably the simplest & cleanest.
09:29 kowey so I described the problem (we want a Mac to buildbot, benchmark and debug darcs on) and asked generally if they could help
09:30 kowey I think I'm angling for an answer like "oh actually, we have a bunch of XServe's sitting around that need using"
09:31 kowey anyway thanks for saying the "hosted-in-USA" keyword... that was just what I needed to trigger thinking about osuosl
09:31 kowey wish it occurred to me months ago when I first mentioned it.
09:32 kowey Quiark: I wonder if darcs changes should display something like "pending conflicts..." (hunks) on top
09:33 kowey Quiark: there is one corner case to account for, which is that some users in some circumstances may actually want the both-sides-cancel out resolution (doubtful)
09:39 dcoutts joined #darcs
09:39 dcoutts joined #darcs
09:48 Quiark kowey, I don't know. The other VCS have it easier, because the repo and working copy are more independent there.
09:57 kowey what do you mean?
09:58 Quiark for example a merge in svn only modifies the working copy unless I commit. So a revert really does revert to a state which the user understands.
09:59 Quiark I don't have that much experience with merges in hg or git though
10:00 twb I have enough experience with them that I don't ever want to do them again
10:01 twb They made me angrier than anything else, except using literal tabs
10:11 mornfall :D
10:16 Quiark I guess that when darcs has already spent 12 minutes applying a patch bundle on a strong machine, it's time to kill it and investigate?
10:18 mornfall Anyone can think of some test repositories to import? :)
10:18 twb mornfall: that zoo stuff?
10:18 mornfall Oh, I mean git repos.
10:18 twb linux
10:18 mornfall :P
10:18 mornfall Something a bit lighter for start maybe.
10:19 Quiark go to github.org
10:19 twb curl -s http://code.haskell.org/~tw​b/Preferences/.bin/twb-get | grep git
10:19 twb Hum, not too helpful without a -B1, but you get the idea
10:19 twb mornfall: emacs!
10:19 * mornfall tries gitit
10:20 kowey maybe some bits and pieces of gnome or kde
10:21 kowey Quiark: maybe --skip-conflicts to see how much you can apply first?
10:21 kowey Quiark: thanks for your comments on merging (I'll try to think more after lunch)
10:23 Quiark kowey, you're welcome
10:24 intripoon joined #darcs
10:25 twb kowey: you need to offline your brain to digest food, eh?
10:27 kowey :-), just trying to get myself to focus on work-work
10:40 mornfall Gitit converted OK.
10:40 * mornfall trying midori
10:41 mornfall Now I wonder how to get git fast-export list also tags...
10:44 kowey another candidate would be the git git repo
10:49 twb mornfall: if you can git->darcs an etckeeper repo, I'll be happy
11:06 mornfall Tags are tricky. :\
11:11 JaffaCake joined #darcs
11:13 twb Apart from anything else, "tag" means different things to different VCSs
11:14 Quiark kowey, if you want to talk about conflicts, I have one more use case :)
11:16 kowey gah, my university insist on tampering my email and sometimes breaking GPG
11:17 kowey *tampering with - they like to append a "this message has been spam scanned" footer directly on the body
11:17 kowey Quiark: let's hear it! :-)
11:18 Quiark kowey, I write code on my local machine and let WinSCP automatically upload it to a remote machine where I compile and run it. Both source and destination are under darcs. I realise this is somewhat nasty and other possibilities may be better, but anyway.
11:18 mornfall Hmm!
11:20 twb kowey: are you attaching or inlining your sig?
11:20 kowey so you winscp the contents of the working directory?
11:20 kowey attaching, twb
11:20 twb Hum
11:20 Quiark kowey, I record changes on my local machine and now I do darcs push to the remote machine. Of course there are conflicts, because the working copy there already has the changes which I'm pushing.
11:20 twb then LART is the only workaround
11:20 Quiark kowey, yep, _darcs remains untouched
11:20 kowey it's actually normally clever enough to not do its tampering on signed messages
11:20 kowey but sometimes MessageLab's cleverness fails
11:21 mornfall I can import --all dumps now! And I get darcs tags.
11:21 kowey twb, I sent a plea requesting that their "this message is phishproof!" footers be added as attachments
11:21 kowey knowing that it will have no effect, as their priority (understandably) is to cater to the Windows users here
11:21 twb Tell them to use Disposition: inline and it'll look the same in their fucked up outlook client
11:22 Quiark kowey, in other VCS when I do this I just do a revert and that's it. In darcs, I'm in a rather strange state now, because it says there are conflicts, but the patches in the repo themselves are ok.
11:22 kowey Quiark: wait, what?
11:22 kowey oh, I see
11:23 kowey Is this with a darcs 2 format repository?
11:23 kowey (darcs show repo)
11:23 Quiark yes
11:24 kowey OK, and so using darcs push would be unacceptable to you because you're doing Work in Progress and are not yet ready to record, right?
11:24 kowey I'm somewhat surprised that this isn't picked up by darcs' duplicate patch handling on darcs-2 format repos
11:25 Quiark kowey, yes, amend-record probably isn't a way either. And WinSCP is much faster
11:26 kowey hmm
11:27 kowey Quiark: I think the only thing may be to have a prehook for push that does a remote revert
11:27 Quiark it's rather messy now because I had to apply the patches in batches and do reverts a few times in between, otherwise it would hang (doing something but don't know what)
11:28 kowey something along the lines of "ssh example.com darcs revert --repo foo -a"
11:31 Quiark Yeah, that would probably help. But I still don't understand the situation right now, because I think the patches in the repo are not conflicting (because they are the same as on my local machine which is ok).
11:32 kowey Quiark: another thing which you could try is to have a non-darcs-managed build repo
11:32 kowey so you winscp to the build repo, but you darcs push to the src repo
11:32 Quiark yes, that's what I'm probably going to do
11:33 * kowey is starving... can we pick this up later?
11:33 Quiark kowey, oh, you haven't eaten yet, sure
11:34 kowey timezone diff :-) back in a bit
11:44 * mornfall sends off his convert work and goes to look for food as well...
12:12 mornfall Oh dear. The emacs git repo goes back to 1992.
12:12 mornfall That's going to take a while.
12:16 mornfall 27k/546k objects... see you tomorrow :D
12:16 burp 546k patches with darcs? :O
12:16 burp that's gonna be a good test
12:16 mornfall No, objects. There's going to be maybe a tenth of the number of commits.
12:17 burp hm, ok still :>
12:17 mornfall Well, GHC has 20k patches. 50k is on the same order, I guess...
12:17 burp and it works well with darcs? nice
12:18 mornfall Optimistic extrapolation says it should be done in about 3 hours.
12:18 mornfall Unless I run out of space on $HOME...
12:30 mornfall (10 % done... anyway, those libc and gcc tags in the emacs repo look real funky)
12:31 mornfall and I guess I need to go out since it's beautiful wheather and I'm starting to freak out here
12:33 burp mornfall: do you use "darcs-fast-import" unmodified?
12:33 mornfall Not at all.
12:34 mornfall I am using darcs convert --import that I just implemented. :)
12:34 burp oh
12:34 burp can I pull that from somewhere?
12:34 mornfall I am just testing it, I have no need to own a darcs copy of emacs history.
12:35 mornfall burp: Not yet, I need to update hashed-storage first...
12:35 burp ok
12:35 mornfall I'll do that when I get back from out. :)
12:35 burp looking forward for it
12:35 mornfall :))
12:35 mornfall Glad to hear that.
12:35 * mornfall runs out.
12:36 kowey Quiark: so about conflicts...
12:37 Quiark kowey, I think I will resolve the situation somehow, but I'm just curious about the state the repo is in now (the patches are ok, but I have a conflict nevertheless)
12:37 kowey what does darcs whatsnew report?
12:38 kowey and did you say you pushed the changes in batches?
12:39 Quiark When I did darcs apply on everything, it hung (CPU at 100% but no info). Then I did apply --skip-conflicts
12:39 Quiark then revert, then some more applying, when it froze again revert and so on :)
12:40 Quiark so I'm after a revert now and whatsnew shows no changes
12:53 kowey can you share this repo, by the way?
12:54 kowey I'm just curious about the cause for the hanging
12:54 kowey Quiark: sorry, I was distracted by trying to deal with the public domain code in our test suite
12:55 kowey also, you did a revert after apply --skip-conflicts
12:55 kowey that means you reverted everything, right?
12:57 Quiark emm..I don't know :)
12:58 kowey OK, and what do you mean when you say "when it froze again, revert"
12:58 kowey If I understand correctly, apply is atomic
12:59 kowey so if you C-c an apply with lots of patches, then none of them get applied...
13:00 Quiark I'm not sure if I did a revert right after apply --skip-conflicts
13:00 kowey ok
13:00 Quiark maybe I did apply one more patch
13:00 kowey hard to keep track of the details without a typescript, huh?
13:01 kowey is it possible that the conflicts come from the patches themselves?
13:01 kowey ie. do you have multiple branches of development with conflicting patches (ignoring working dir)
13:02 Quiark Probably yes, I work on my branch of mornfall's code, sometimes there are conflicts. But they should be already resolved.
13:02 kowey ah!
13:03 kowey ok, so one thing that you may want to know about
13:03 kowey is that if you push patches A and B which conflict with each other
13:03 kowey without also pushing C (a patch that resolves the conflict)
13:03 kowey then Darcs will complain that you have a conflict
13:03 kowey and mark it up
13:03 Quiark but I think I pushed C too
13:04 Quiark see the repo here http://www.fi.muni.cz/~xplasil/tmp/darcsprob/
13:04 kowey that's with all the patches?
13:05 Quiark yes
13:05 kowey how far back does this push go?
13:06 Quiark so when i do mark-conflicts and whatsnew -s, only the file divine/explain.h is conflicting. Which is a file which only exists in my repo. So it seems that darcs got most of it right and there's just some smaller problem with this file.
13:08 Quiark I wonder which patches are in conflict
13:08 kowey this is what's most interesting for me
13:09 kowey this is sort of a chance for us to think about how to make darcs conflicts easier for users to cope with
13:09 kowey because right now there's a lot of "argh! I don't get it!"
13:09 kowey which is not how you want your revision control systems to be :-(
13:09 kowey particularly one that prides itself on being very very easy to use
13:10 kowey Quiark: darcs changes -s could be helpful here
13:11 Quiark kowey, I think one of the biggest problems with darcs is that it works differently from git/hg or even svn.
13:11 kowey particularly darcs changes -i -s
13:12 kowey that's probably unlikely to change
13:12 kowey but even within a patch-oriented way of looking at things, we're not doing a good enough job with users and conflicts
13:12 Quiark Yeah. When someone learns git, he thinks he knows all the DVCS.
13:13 kowey sort of there being two reasons (1) unfamiliar and (2) bad
13:13 kowey we can't fix (1), but we should be working on (2)
13:13 kowey just setting sights higher now that we've made a bit of performance progress :-)
13:14 kowey so if you do a darcs changes -s -i, you'll get a summary on each patch
13:14 kowey and you can step through them interactively
13:14 kowey this is useful because when you see a bang, as in M! ./divine/explain.test.h
13:14 kowey you know it's a patch with a conflict in it
13:14 kowey and you can hit 'v' to see the contents
13:15 mornfall I overshoot a bit with those 50k patches ... 87k objects converted and I've already got 44k patches.
13:16 kowey when I fetched that repo, Quiark, I noticed that not all conflicts were resolved
13:16 kowey I did darcs mark-conflicts
13:16 mornfall In other news, there's a whole lot of young mothers with small children outside in the park.
13:16 kowey and then darcs whatsnew -s
13:16 kowey M ./divine/algorithm/explain.h +551
13:16 * mornfall everywhere. :D
13:17 Quiark kowey, yep, this is the problematic repo. The local one from which I pushed is ok.
13:17 mornfall Lemme patch that hashed-storage so I can move on to other stuff.
13:18 kowey Quiark: right, so basically what we have here is one of those A+B but not C situations
13:18 Quiark so I should try pushing to it again
13:18 kowey in your local repo, I think there may be a patch you have not yet pushed, which resolves the conflict in ./divine/algorithm/explain.h
13:19 kowey so what I *think* will work is if you revert in the darcsprob repo (which is marked up, see http://www.fi.muni.cz/~xplasil/tmp/d​arcsprob/divine/algorithm/explain.h) and push the patch in question
13:19 kowey one trick is darcs push --match 'touch divine/algorithm/explain.h'
13:22 arjanb joined #darcs
13:28 Quiark kowey, ok, by comparing darcs changes from both repos I found that on the problematic machine is one more patch which is most likely causing the problem
13:29 kowey ah! darcs pull --dry-run
13:29 kowey (and darcs push --dry-run)
13:29 kowey is the easy way to compare changes
13:29 kowey for future reference...
13:30 Quiark It did not occur to me that the other repo might have a bogus patch.
13:30 kowey you can also do darcs changes on just a file, darcs changes divine/algorithm/explain.h
13:30 kowey ok, so you've hopefully solved your immediate problem
13:31 Quiark yes, it seems to be fine now, thanks
13:31 balor joined #darcs
13:31 Quiark as for user friendliness, maybe darcs should show info about the conflicts (which patches are conflicting) at some point (don't know which point though :)
13:32 kowey great! we're still left with the general "users look at darcs conflicts, and go WTF?" problem to deal with in the long term
13:32 kowey Quiark: well, there's 3 basic things I can think of
13:32 kowey the first is the mark-up problem: http://bugs.darcs.net/issue833
13:32 Quiark and the thing that revert removes the changes from working dir and then darcs looks like everything is perfectly fine
13:33 kowey the second is the which patch conflicts with what problem
13:33 kowey and the third is the notification problem, which I think you're pointing to
13:34 kowey so the tricky thing, Quiark is that darcs doesn't yet know the difference between mark up it introduced and stuff you typed
13:34 kowey maybe darcs revert by default should do a mark-conflicts
13:35 kowey so that you always revert to a conflicted state...
13:35 mornfall kowey: I guess the invisible conflicts problem could be fixed by darcs printing a WARNING: You have unresolved conflicts in this repository.
13:35 mornfall kowey: Whenever you do things like pull/push/...
13:35 kowey or whatsnew
13:35 Quiark maybe. Or just be loud about the fact that there is a conflict. Not just at revert but at other times as well
13:38 kowey Quiark: one tiny way you could help the cause, http://bugs.darcs.net/issue1681
13:38 kowey won't change much, but it will at least make the notifications we do print more visible
13:39 kowey Quiark: I'd like to file some tickets for this.  May I make you nosy on them?
13:41 mornfall Darn. There's a leak in convert --import. :(
13:41 kowey :-(
13:42 mornfall Ohwell.
13:43 mornfall (Or maybe it's not a leak, just that those 100+ thousand objects for which I hold hashes in memory are just too big...)
13:44 * mornfall kills the conversion and repairs the result...
13:45 mornfall So I need a priority queue. How do you do that in Haskell? :)
13:46 * mornfall googles
13:47 burp http://hackage.haskell.org/pa​ckages/archive/pkg-list.html
13:47 burp there are a few priority queue implementations
13:49 Quiark kowey, I'm sorry, I don't have haskell platform installed any more and I'm quite busy now
13:50 mornfall Let's try the pure one.
13:50 kowey Quiark: no problem, just doing it-never-hurts-to-ask
13:50 Quiark :)
13:51 kowey Quiark: but OK if I add you to some conflicts-related tickets?
13:51 kowey it means you may get some CC traffic
13:51 zooko joined #darcs
13:52 kowey (and feel free to say no! noise-mgmt is a very important and individual thing)
13:53 Quiark kowey, ok, add me, I can always unlist myself
13:53 kowey thanks
13:54 mornfall It seems I actually need a priority-set.
13:54 mornfall :D
13:56 lispy joined #darcs
14:09 mornfall Ok, that space leak is not new. It's in darcs-2.4 as well (it also happens during check).
14:11 kowey for the interested, the conflict UI tickets that I can think of are http://bugs.darcs.net/issue833 (marking), issue1911 (dependencies), issue1912 (notification) and issue1681 (notification ez)
14:36 zooko` joined #darcs
15:16 zooko joined #darcs
15:19 mornfall gets update >>= ($ x) . ($ path)
15:19 mornfall Haskell rocks.
15:19 mornfall :D
15:23 kowey is that the same as gets update >>= (\f -> f path x)?
15:23 lispy ?unpl gets update >>= ($ x) . ($ path)
15:23 lambdabot ((gets update) >>= \ e -> e path x)
15:24 balor joined #darcs
15:24 lispy Not sure if lambdabot understands >>=
15:24 lispy ?redo gets update >>= ($ x) . ($ path)
15:24 lambdabot Maybe you meant: do read todo undo
15:24 lispy ?do gets update >>= ($ x) . ($ path)
15:24 lambdabot do { a <- gets update; (($ x) . ($ path)) a}
15:24 lispy ?unpl \a -> (($ x) . ($ path)) a
15:24 lambdabot \ a -> a path x
15:25 lispy I guess it does
15:25 mornfall :)
15:37 lispy where is the ratify stuff now?
15:38 kowey it's a module Ratified (src/Ratified.hs)
15:38 lispy so how do you ban something?
15:38 lispy It seems anyone can just stick a function in there and import it as they see fit?
15:38 kowey contrib/darcs-errors.hlint I think
15:39 lispy right so I add something to .hlint and then to get around it they can just put it in ratified and import it?
15:39 kowey I think that's the idea.
15:40 lispy does anyone actually check for that in patch review?
15:40 kowey one thing to add is System.FilePath.(</>) [should be System.Posix.FilePath.(</>)]
15:40 kowey ... although there's an example that just doesn't need ratification
15:40 kowey since the answer is just to use some other module instead
15:41 kowey check for what, lispy?
15:41 balor joined #darcs
15:41 kowey oh, that ratified uses are sensible?
15:41 lispy yes
15:41 kowey a third piece of the puzzle is that Ratified should be imported qualified
15:41 kowey (huh, seems like something haskell_policy should enforce)
15:42 kowey so it kinda sticks out on patch review
15:42 kowey but it's still up to the reviewer to say "hey! that's a ratified thing, better see if it makes sense to use it"
15:43 lispy someone inserted a bunch of unnecessary unsafeCoerce# and it's making me insane
15:44 lispy why have the type witnesses if we're just going to litter the code with unsafeCoerce??
15:45 mornfall Missing out a lift can have dire consequences. The errors are totally opaque...
15:45 bos joined #darcs
15:47 lispy how do I run the hlist stuff?
15:47 lispy er, hlint
15:48 kowey you can just cabal test tests/haskell_policy.sh
15:48 kowey which in turn runs hlint with a flag to pick up the errors from darcs-errors.hlint
15:52 zooko` joined #darcs
15:54 kowey hmm, http://lackingrhoticity.blogspot.com/201​0/08/cvss-problems-resurface-in-git.html
15:55 kowey the author points at Darcs set-of-patches style repos as a possible solution to problem of splitting/merging repos
15:56 kowey I think we can only go so far, ourselves, though
15:56 kowey splitting can be blocked on dependencies, and merging on duplicates (eg. Makefile)
15:57 mornfall kowey: merging can be fixed by not having add-add conflicts.
15:57 kowey right
15:58 mornfall kowey: and splitting can be fixed by splitting named patches into prims (which never have cross-file-boundary dependencies, at least for now)
15:58 kowey as suggested by Ganesh in http://wiki.darcs.net/Ideas/AddAddConflicts (add/add)
15:59 kowey so the answer is that yes, Darcs approach would solve the problem, but not Darcs-2010
15:59 mornfall Yes, it's a very nice property (because subtree checkouts fall out of it for free).
16:00 mornfall (Which are easy with SVN but mostly impossible with GIT.)
16:00 kowey maybe I should write a short comment
16:01 kowey although every time I comment on a blog, I want to say "gah! shut up, already, Eric"
16:14 zooko joined #darcs
17:05 balor joined #darcs
17:07 exlevan joined #darcs
17:38 bos joined #darcs
17:42 abuiles joined #darcs
18:20 lispy1 joined #darcs
18:21 lispy1 ?tell Heffalump have you ever read this paper? http://homepages.inf.ed.ac.u​k/wadler/papers/composable/  I haven't had a chance yet.  But section 3.6 has indexed monads that look a lot like RIO.  More over, as I explained on my blog delimited continuations seems to have a connection to VCS.  That paper uses index monads to type composable continuations (same idea, different terminology).  So I think there may actually be something interesting to pursue here.
18:21 lambdabot Consider it noted.
18:25 [1]intripoon joined #darcs
18:27 mornfall burp: I have updated patch332, so you can have a go at the patches if you like
18:28 burp nice
18:28 burp I will try
18:29 mornfall burp: http://bugs.darcs.net/file1688/add-__impor​t-and-__export-to-available-flags_.dpatch should be the patchfile, http://bugs.darcs.net/patch332 has some instructions :)
18:29 mornfall Hm. Make that "--progress=500", git barfs with the space... (sigh).
18:30 mornfall And off I go to bed. See you around. :)
18:30 balor joined #darcs
18:36 lispy1 joined #darcs
18:39 burp mornfall: hm, sadly your patch doesn't build for me
18:42 Heffalump lispy1: I've seen the general line of work, though I'm not sure about that paper. I'm still not really convinced about the connection, I just haven't had time to disagree properly :-) Also I think some of the problems are with just mundane stuff like still having do notation both for the indexed monads and the normal ones in the same file.
18:42 lambdabot Heffalump: You have 1 new message. '/msg lambdabot @messages' to read it.
18:46 * burp runs darcs trackdown "cabal install"
18:46 burp hm or better cabal configure && cabal build
18:53 tux_rocker joined #darcs
19:00 tux_rocker hi
19:02 tux_rocker i have some trouble at work now with an application that went berserk for a change
19:02 tux_rocker darcs 2.5 beta 3 may have to wait a couple of days
19:02 abuiles left #darcs
19:05 burp mornfall:
19:05 burp Trying without the patch: Mon Aug  9 01:25:46 CEST 2010  Petr Rockai <me@mornfall.net>   UNDO: First version of a fast-importer (convert --import). Success!
19:05 burp this is the first one that compiles :/
19:26 mornfall burp: How come?
19:26 mornfall burp: Do you have hashed-storage HEAD?
19:26 burp yes
19:26 burp not off to bed yet? then I can paste the error
19:26 mornfall I got up again.
19:27 mornfall I'll retry in a bit, so hurry up with the error. :)
19:28 burp http://paste.railsbox.eu/show/325/
19:28 mornfall Oh! You have to build with -f-library.
19:28 burp this is with your whole patch stack applied
19:28 burp oh
19:28 mornfall I screwed the witnesses.
19:28 mornfall I *knew* I wanted to add something important to that TODO list.
19:29 * mornfall adds a comment
19:29 burp *tries compiling now*
19:30 burp yay, it worked
19:34 burp I have an exported file from hg-fast-export.py, that should work with your import, right?
19:34 mornfall Well, no idea. I only tried with git fast-export. :)
19:34 mornfall And with darcs convert --export.
19:34 burp let's try
19:34 burp cat /tmp/bzr-fastimport/exporters/hedgewars.export | ~/build/darcs.net/dist/build/darcs/darcs convert --import foo
19:35 burp "foo" is growing :D
19:37 burp mhm, already 800MB ram usage, I'll give it 2GB and then abort :>
19:37 mornfall How big is the project?
19:37 burp ~700MB
19:37 mornfall Oh dear. :)
19:38 mornfall Hm. The converter also doesn't quite support binaries...
19:38 mornfall (It'll create text patches no matter what.)
19:38 burp oh�
19:38 lispy1 Heffalump: well, they are definitely connected, even if only because del. cont. are powerful enough to describe all the state transitions
19:39 lispy1 Heffalump: It's possible you disagree with my mapping of darcs into del. cont. operations.  That part is still fuzzy (although, I did create a .hs file to demonstrate a merge)
19:39 burp you need to handle that next then ;)
19:39 mornfall burp: darcs in general doesn't like binaries
19:39 burp you mean in the sense, that it doesn't use binary diffs?
19:40 lispy1 burp: Yes,  but binary diffs are sort of bad anyway.
19:40 mornfall burp: Well, it stores binaries *extremely* inefficiently.
19:40 lispy1 burp:  the real problem is yeah what mornfall just said
19:40 burp hm ok
19:40 lispy1 burp: In darcs, binary really means "don't merge this with other versions of this file."
19:40 burp it's stable at 1.5G ram usage now
19:41 lispy1 burp: and that's an important abstraction to have.  Any machine generated content you typically don't want humans trying to merge because they may not understand the bytes.
19:42 lispy1 burp: so binary serves as a way to say, 'hey, when there are multiple updates to this blob, don't try to merge them.'
19:42 Heffalump lispy1: VCS is related to a turing machine because you can implement it on one, but that's not particularly useful
19:42 lispy1 Then we endup with binary format that stores all the new and all the old
19:43 lispy1 Heffalump: Sure it is.  That's how we were able to implement darcs in Haskell :)
19:43 Heffalump there's a trivial optimisation to that format that noone's got round to implementing (it'd also be backwards incompatible in terms of darcs versions, though not in terms of patch theory)
19:43 Heffalump lispy1: :-p
19:44 burp "\o/ It seems we survived. Enjoy your new repo."
19:44 mornfall burp: wow.
19:44 burp it's mainly binary stuff, because it's a game repository
19:44 lispy1 Heffalump: but to be fair, there is a deeper connection (I'm sure of it, regardless of how poorly I've explained it) between vcs and del. cont.  And I think it's a useful connection too.
19:44 mornfall yeah, I derived that from the name and size :)
19:45 lispy1 Heffalump: I just have to get to a point where I can explain what I'm seeing
19:47 burp <mornfall> Hm. The converter also doesn't quite support binaries... - hmm
19:47 lispy1 Heffalump: to be fair, I'm not confident that darcs fits elegantly into it -- which to me says that the patch theory might have some warts.  Some warts that it may help point out.
19:47 burp what do you mean by that? as far as I can see it worked here
19:48 burp the changes say things like "addfile ./share/hedgewars/Data/Map​s/FlightJoust/preview.png binary ./share/hedgewars/Data/Map​s/FlightJoust/preview.png "
19:48 mornfall Huh?
19:48 lispy1 burp: darcs does some magic to find binary files.  So it may have auto detected that one as binary
19:48 mornfall I don't think that should be possible. :)
19:49 mornfall burp: Oh!
19:49 mornfall burp: I see.
19:49 mornfall burp: If they are "obviously" binary then it works.
19:49 mornfall burp: But the normal regex filtering that darcs does is not implemented.
19:49 burp hm ok
19:50 mornfall (Obviously meaning they contain funky characters like ^Z or such...)
19:50 lispy1 mornfall: but the is_funky is still there right?
19:50 lispy1 or maybe it's isFunky these days.  Not sure how far Eric's refactors have gone
19:50 burp well, that I should be fine with that repository, as graphics and sounds are probably all "obvious"
19:50 lispy1 Heffalump: in other news, I noticed that we have unsafeCoerce# in Prim.lhs when it can (and should be) unsafeCoerceP
19:50 lispy1 Heffalump: in a _lot_ of places.
19:51 lispy1 Heffalump: I'd like to add GHC.Base ( unsafeCoerce# ) to the banned imports list
19:51 lispy1 Heffalump: I started working on that this morning before going to work but I accidentally unpulled my patch right before sending :(
19:51 Heffalump oops :-(
19:51 Heffalump sounds fine, anyway
19:52 lispy1 Do unpulled matches continue to exist though?  They are just removed from inventory right?
19:52 lispy1 If so, i might be able to find it with find later
19:52 lispy1 Heffalump: I also discovered that mapPrimFL is a very dangerous function.
19:53 lispy1 Heffalump: it reorders the patches using an Ord instance
19:53 lispy1 Heffalump: and so it cannot enforce its invariants nor can it check them
19:53 lispy1 Heffalump: I'm not sure what to do about it yet though
19:53 lispy1 It just has to assume that Ord for Prim is correct
19:54 lispy1 We really need a variant of Data.Map that lets you create it with specified compartor
19:54 lispy1 That would help a lot
19:54 lispy1 (in mean in general, not just for mapPrimFL)
19:58 Heffalump lispy1: I think so (re obliterate)
19:59 Heffalump lispy1: I know mapPrimFL is a bit dangerous looking, but it's a useful looking optimisation
19:59 Heffalump and it's been there a long time and has never been implicated in any trouble
19:59 Heffalump it's nothing to do with Ord being correct.
20:00 lispy1 Heffalump: Well, it has been in the critical path of bugs.  issue525
20:00 Heffalump it's a question of whether the code as a whole is correct in its assumption that it can freely reorder patches that touch different files
20:00 Igloo What are the keys in the map it makes?
20:00 Heffalump I did vaguely consider dropping the optimisation when I was doing the witnesses
20:00 Heffalump Igloo: FileName
20:00 lispy1 Igloo: files
20:00 Heffalump and it rejects move patche
20:01 lispy1 It only takes patches that can be converted to Simple
20:01 Igloo Ah, OK
20:01 Heffalump lispy1: I don't see anything in the comments on that bug about it
20:01 Heffalump lispy1: if we benchmark we could consider removing it. I don't think it's worth worrying about too much though.
20:02 * Igloo wonders when it's actually used with patches that aren't already sorted by filename
20:02 lispy1 Heffalump: sortCoalenceFL is implemented using mapPrimFL.  The comment in the source says: -- Running canonize twice is apparently necessary to fix issue525;
20:02 lispy1 -- would be nice to understand why.
20:02 lispy1 The first call is before sortCoaleseFL and the second is after it
20:02 lispy1 Heffalump: well, removing it breaks darcs
20:02 Heffalump lispy1: removing what?
20:03 lispy1 Heffalump: I was going to do exactly that benchmark
20:03 Heffalump the optimisation?
20:03 Heffalump you're saying that mapPrimFL f ps = f ps causes the tests to fail?
20:03 lispy1 Heffalump: Yeah, maybe my refactor was wrong but I did, mapPrimFL f x = f x
20:03 lispy1 yes
20:03 Heffalump and it breaks 525?
20:03 lispy1 It broke many things, but I didn't test issue525 directly
20:04 Heffalump well, that sucks. It looks like it should be an optimisation only.
20:04 lispy1 Heffalump: So, I think the patches come out the other end sorted by file name
20:04 lispy1 And that probably interacts with the shrinking and other things
20:04 Heffalump yeah, they would
20:04 Heffalump lovely. Not.
20:05 Heffalump that means that if you stick a move into a sequence of patches, darcs' behaviour will change
20:05 Heffalump on the other patches too
20:05 Heffalump any move, even one unrelated to the existing patches
20:06 lispy1 hm
20:06 lispy1 Heffalump: So it's not the ordering of Prims that matters here is it?  I mean my complaint about Ord
20:06 lispy1 It's using Ord on String
20:09 lispy1 Heffalump: so then do you have an idea for how to demonstrate a bug in the current implementation?
20:10 Heffalump lispy1: well, I guess the ordering does sort of matter, but I suspect it's more to do with the bucketing by filename.
20:10 Heffalump lispy1: sounds like you already have. If replacing something described as an optimisation causes a behaviour change, that's a bug.
20:11 Heffalump if you want an external case I guess boil down one of the test failures you get.
20:11 lispy1 Heffalump: that's a good idea.
20:11 lispy1 Heffalump: I just thought maybe you had a sequence in mind (I don't)
20:11 balor joined #darcs
20:11 Heffalump lispy1: I don't know what actually goes wrong. I wouldn't have expected anything to.
20:12 Heffalump generally, taking a sequence of Prims on the same file that can be coalesced, and comparing behaviour with a sequence of Prims + an unrelated move, might be the way to demonstrate a difference
20:12 lispy1 Heffalump: Well, I suspect that what really goes wrong is that things don't 'replay' in the right order.  I recall one of the tests that failed was complaining it couldn't create a file in a directory that doesn't exist.
20:12 Heffalump I think the "proper" fix is to figure out how to make canonize actually canonize things, rather than just sort of try to improve them a bit
20:13 Heffalump oh, that's the same problem as I found with treeDiff the other day. It turns out treeDiff produces wrong patches, but if you run canonizeFL on the result they get fixed.
20:13 Heffalump I guess mapPrimFL is the mechanism by which they get fixed.
20:13 Heffalump so it might be that fixing treeDiff solves the problem
20:14 Igloo I don't understand why that doesn't break remove patches
20:14 Heffalump Igloo: I don't even want to understand. I just want to fix it :-)
20:14 Igloo Amen
20:15 Igloo Although understanding that might be useful in fixing it correctly
20:15 Igloo Aha, toSimple (DP _ RmDir) = Nothing
20:16 Igloo So the "optimisation" is necessary to fix adds, but would break removes
20:17 Igloo And you can presumably easily make darcs fail, or produce a bad patch, with a patch that adds a directory and file, while at the same time removing another one
20:17 Heffalump oh, good point
20:18 lispy1 Igloo: oh, that might be what EXAMPLE.sh does
20:18 lispy1 mkdir d e; echo 'Example content.' > d/f; record -lam; darcs mv d/f e/; record -am
20:18 Heffalump Igloo: I made a patch that does that, and it's clearly in the wrong order, but darcs check doesn't fail
20:19 Heffalump the slightly stricter checker I wrote for my shrinker will though
20:19 lispy1 Heffalump: I'm 90% sure that EXAMPLE.sh was one of the failing ones
20:19 lispy1 Heffalump: so you might start with it
20:20 Heffalump oh, darcs has broken. It doesn't know that the file I added exists, even though it's in the patch.
20:20 * lispy1 gets HEAD to do a test
20:20 Igloo Hmm, I can't make it fail with 2.4.3
20:20 Heffalump so I was able to record the add again. darcs check still doesn't complain though.
20:20 Igloo Is this code newer than that?
20:20 exlevan joined #darcs
20:21 Heffalump I rewrote it (mapPrimFL) for witnesses, but I didn't intend to change the behaviour.
20:21 lispy1 Heffalump: I don't think you did
20:22 mornfall Igloo: I don't think anything changed since 2.4 in that dept.
20:22 Heffalump except that mapPrimFL got rewritten by me
20:22 lispy1 Heffalump: if I get the 2.4.0 tag it won't have your rewrite, right?
20:23 mornfall Heffalump: Oh?
20:23 Heffalump mornfall: just to add witnesses.
20:23 Heffalump but that wasn't completely mechanical given that it's fundamentally unwitnessable
20:23 mornfall Ok, I must have reviewed that I guess. :D
20:23 Igloo Hmm. Shouldn't http://paste.debian.net/82667/ tickle the bug?
20:24 Heffalump Igloo: yes, I think so
20:24 Igloo Does it in HEAD?
20:24 mornfall It might be failing to do so due the thick layer of pending magic.
20:25 Heffalump Igloo: no.
20:25 Heffalump I'll make a paste of what I did
20:25 Igloo Ah, good spot. This breaks:
20:26 Igloo http://paste.debian.net/82668/
20:26 Heffalump yes, I think you have to use -l
20:27 Igloo Someone please feel free to add that as a test, with whichever licence will cause the fewest arguments
20:27 mornfall :D
20:27 Heffalump I think each contributor should have their own licence.
20:28 mornfall A different one, hopefully.
20:28 mornfall So that we get to put multiple license boilerplates to each test... :D
20:28 lispy1 Heffalump: I just reviewed your refactor.  I think it's fine.  I can't see how it would change the behavior we care about
20:29 Heffalump Igloo: you get that breaking with 2.4 too, right?
20:29 Igloo That's 2.4.3
20:29 Heffalump which I think dispels the suspicion that something has changed
20:29 Igloo And so actually, in the case I guessed the optimisation might actually optimise, the optimisation isn't actually used
20:31 lispy1 Heffalump: So one thing I don't get.  (fromSimple . toSimple) /= id, right?
20:31 lispy1 Heffalump: You necessarily lose patches here or I'm not seeing something?
20:31 Heffalump so, I think the route to fixing this, is (a) make treeDiff produce things in the right order and (b) check whether mapPrimFL still changes behaviour.
20:31 Igloo (c) remove mapPrimFL unless someone can give an example of something that it optimises
20:32 Heffalump lispy1: that equality is not type correct, even if you ignore currying
20:32 Heffalump Igloo: I'd put that in reverse: remove mapPrimFL if someone checks the benchmarks first.
20:32 Heffalump lispy1: and the extra Maybe is what's key to it not being id
20:32 lispy1 Heffalump: Well, I guess I'm just asking, "Doesn't it remove patches and then you can't recover them because it's a surjection?"
20:33 Heffalump where does it remove patches? mapPrimFL falls back.
20:33 Heffalump which is the root of the test case Igloo mentioned
20:33 lispy1 > mapM (\x -> if x == 1 then Just 2 else Nothing) [Just 1, Just 2, Just 3]
20:33 lambdabot No instance for (GHC.Num.Num (Data.Maybe.Maybe t))
20:33 lambdabot arising from the lite...
20:33 Igloo (fromSimple . toSimple) would lose patches, but it isn't used
20:33 lispy1 :t mapM
20:33 lambdabot forall a (m :: * -> *) b. (Monad m) => (a -> m b) -> [a] -> m [b]
20:34 Heffalump mapM f xs on the Maybe monad fails if f fails on any element of xs
20:34 lispy1 > mapM (\x -> if x == 1 then Just 2 else Nothing) [1, 2, 3]
20:34 lambdabot Nothing
20:34 lispy1 Okay
20:34 lispy1 So they have to all be simple patches
20:35 lispy1 Otherwise we just do f x
20:35 Igloo Right
20:36 lispy1 So how is that code really splitting things into chunks?
20:37 lispy1 That happens inside mapWithKey I guess
20:37 lispy1 So, I wonder how that's an optimization
20:38 * Igloo can't read "fromSimples" other than in a meerkat voice </UK-only comment>
20:38 Heffalump is that a chipmunks reference?
20:39 Igloo No
20:39 Heffalump lispy1: it's an optimisation if f is quadratic on the list it gets passed
20:39 Heffalump which most functions that do significant commutation are
20:39 lispy1 Heffalump: Oh.  Right
20:39 Heffalump the right general fix is to make commutation faster, somehow. I've been thinking about that for a while.
20:39 lispy1 I get it now, yes
20:39 Igloo http://www.youtube.com/watch?v=4Ust9YBlEfY
20:39 Heffalump (faster in time complexity)
20:40 lispy1 Igloo: hehe, nice
20:40 Heffalump Igloo: I don't watch enough TV to get that :-)
20:41 abuiles joined #darcs
20:41 Heffalump IM to have got that before the youtube link
20:41 Igloo Oh, I see. So it's probably still worth chunking the patches by filename; just not sorting them first
20:42 lispy1 Heffalump: so mapPrimFL is using the map to partition things.  The assumption it makes is that if everything is "simple" then you can divide the patches up based on the paths of things they modify.
20:42 Igloo That's a pretty scary thing for mapPrimFL to be doing, though. I guess it's probably safe in practice, but it still scares me.
20:42 mornfall Heffalump: Not using consed lists could help, maybe?
20:43 lispy1 mornfall: you want to use something like Data.Vector isntead?
20:43 Heffalump mornfall: for commutation in general?
20:43 mornfall Heffalump: For commutation, yes.
20:43 Igloo Now I actually look at it, mapPrimFL isn't a map at all
20:43 Heffalump you need good summary information for trees to help.
20:43 Heffalump Igloo: agreed
20:43 lispy1 mornfall: what do you mean by consed lists?
20:44 lispy1 Igloo: it is in the fmap sense
20:44 mornfall lispy1: The functional version of linked list. :)
20:44 Heffalump lispy1: no it's not
20:44 Heffalump the unoptimised version is just ($)
20:44 Heffalump mornfall: the complexity is the fact that every patch has to commute past every other.
20:44 mornfall Heffalump: Well, you could do a radix sort then. :]
20:45 mornfall Heffalump: Based on filenames...
20:45 mornfall Just like mapPrimFL does.
20:45 Heffalump mornfall: sure, but moves get in the way
20:45 Heffalump and within a single file you're still screwed, though it may not matter in practice
20:45 mornfall Heffalump: That's why you want to avoid the filename-based hunks.
20:45 mornfall Heffalump: Among other things.
20:45 Heffalump you mean have filepatches apply to unique id, not filename?
20:46 mornfall Just stick in a good ol' UUID and you can radix through like a hot knife through butter.
20:46 Heffalump until we get hunk move
20:46 mornfall Right. Then you are screwed again.
20:46 mornfall But there's no proof that hunk move is even possible.
20:46 Heffalump sez who?
20:46 mornfall me... is there?
20:46 lispy1 Are you saying it's not map/fmap because it reorders the list?
20:47 Heffalump well, depends what you mean by a proof.
20:47 Heffalump lispy1: I'm saying it's not map or fmap because it just isn't the same :-)
20:47 mornfall Heffalump: Well, let's say that there's also no proof that conflictors actually work (unless Igloo has made some further advances that I don't know about). :)
20:47 Heffalump ah, but we have positive evidence they don't work :-)
20:48 mornfall Well, I mean, at all.
20:48 Heffalump I'm pretty certain hunk move does work, it's just a question of getting the right commute rules.
20:48 mornfall We have definitely good evidence that they don't work very well.
20:49 Igloo lispy1: mapped functions only see one element, not a list
20:49 mornfall Heffalump: Hunk move would commute by teleporting other hunks when they overlap, right? (And like ordinary hunks for non-overlaps and fails for partial overlaps?)
20:49 Igloo Heffalump: I'm not convinced camp's conflictors don't work (but also don't have a proof that they do)
20:50 mornfall I've been always saying that we should just not allow conflicted repositories to exist. :)
20:50 lispy1 Igloo: yeah, I guess I was (incorrectly) thinking of that chunk as one big value that it gets.  Sort of like if you map (f :: [a] -> [a]) over [[a]]
20:50 Heffalump mornfall: correct (if by overlap you mean containment and partial overlaps you mean offsetting)
20:50 Heffalump and re conflictors, we know they have bad time complexity
20:50 mornfall And space complexity, too.
20:50 Heffalump they're just bad. Graphs FTW ;-)
20:51 mornfall But there's a reasonable chance that there's a lower bound on size of conflict representation that commutes correctly that's not O(1)...
20:51 Heffalump Do you mean O(n)?
20:52 mornfall I mean O(1).
20:52 mornfall Anything beyond O(1) leads to quadratic repositories.
20:52 Heffalump O(1) in what?
20:52 mornfall In number of conflicted patches.
20:52 Heffalump so you have k conflicted patches and then they don't get stored at all in the conflict?
20:53 mornfall Right. So that's impossible so I conjecture that any self-contained conflict representation will lead to quadratic repositories.
20:53 Heffalump as long as you only store each patch in one conflictor, the repository doesn't grow.
20:53 Heffalump IM not in complexity terms.
20:53 Heffalump and you only ever need to store it in one conflictor, because once it's undone it can't be redone
20:54 mornfall How do you conflate the patches into a single conflictor?
20:55 Heffalump conflate what patches?
20:55 mornfall All that conflict.
20:55 mornfall I mean, if you have a conflict fight...
20:55 mornfall you get conflict among conflictors
20:55 Heffalump a conflict fight has resolution patches
20:55 mornfall how do you avoid storing the confictors that conflict in the new patch?
20:55 Heffalump you don't need to
20:56 Heffalump just don't store them :-)
20:56 Heffalump hmm. Perhaps it's not that simple.
20:56 Heffalump but it might be.
20:56 mornfall I have some issues with believing that you can define correct commute.
20:56 mornfall (Without storing them.)
20:57 Heffalump If you don't locally know what you conflict with, it might be hard to know when you can unconflict yourself.
20:57 Heffalump You might need to keep a count of things you conflicted with that aren't actually stored with you.
20:58 Igloo If you don't know what you conflict with, you can't know if you are being commuted to the left of something you conflict with or a dependency, can you?
20:58 mornfall It'd be interesting to know that you can get away with just a counter...
20:58 mornfall Igloo: Sounds like a problem indeed.
21:00 Heffalump you can't get up to something you conflict with without having that stored in you
21:00 Heffalump perhaps
21:01 Igloo DYM in A+B+C, C would only store A?
21:01 Igloo If so, how do you handle A and B being commuted?
21:01 Heffalump what's in conflict?
21:01 Igloo All of them
21:02 mornfall (I know it's getting old, but I am a bit sceptical about solving a global problem (conflicts) locally (in commute) :P)
21:03 Heffalump A[B|A][C|]
21:03 Igloo Is that all the information that would be stored?
21:04 Heffalump dunno yet :-) In my current idea, yes.
21:04 Heffalump though as I said C might need to store the count 2 as well.
21:04 Igloo What would it look like if B and C don't conflict?
21:04 Heffalump ok, let's add numbers
21:04 Heffalump A[B|A,0][C|,2]
21:05 Heffalump and A[B|A,0][C|,1]
21:05 lispy1 mornfall: re: global vs. local.  Yes, that's my feeling as well.
21:05 Heffalump in the initial case and your new one
21:05 mornfall (I have a nagging feeling that I have seen this representation somewhere.)
21:05 * Igloo is not optimistic about this
21:07 Heffalump I see your point :-)
21:07 Heffalump well, we can at least eliminate internal redudancy in a single conflictor by using a graph
21:07 Igloo DYM you can make it more space efficient?
21:07 Heffalump yes
21:11 mornfall Ok, my 2008 representation is fairly different.
21:12 Heffalump look, even if it's wrong I need my own conflict representation or I'll never be a proper darcs hacker!
21:12 Igloo :-)
21:12 lispy1 haha
21:12 lispy1 monad tutorial : haskell :: conflictor representation : darcs hacking
21:14 mornfall :)
21:17 mornfall My current position is that handling conflicts at a repository level would work a lot better.
21:32 abuiles hi
21:32 Heffalump hi abuiles. Have you produced a conflictor representation yet? ;-)
21:33 mornfall :D
21:33 abuiles hi Heffalump, what ?
21:33 abuiles ohh sorry,
21:34 abuiles I wasn't reading the log.
21:34 Heffalump that's ok, we'll forgive you as long as you produce one by tomorrow.
21:34 abuiles I need to do first a monad tutorial.
21:35 Heffalump god, how did you ever get accepted for GSoC without that basic qualification?
21:35 Heffalump standards must be slipping!
21:35 abuiles I was pure.
21:35 Igloo It's quite an easy task. All you need to do is write down an algorithm that doesn't work.
21:37 arjanb and you have to invent a new notation for it
21:37 mornfall :D
21:38 mornfall It's reminding me of those days of revctl where everyone had their own dag-aware text merge algorithm.
21:41 abuiles mornfall, I just send the patch to support the environment variable for setting the timeout, I'm not adding support for HTTP yet.
21:42 burp mornfall: have you tried if the stuff in the repository is still correct for your imported repositories?
21:42 burp I mean, in case of branches
21:44 mornfall burp: In what sense?
21:45 mornfall burp: The tags get mangled somewhat by branch switching, for one.
21:45 burp that it still compiles for example, as changes from different branches are not "mixed up"
21:45 mornfall burp: If I unpull patches? No I haven't tried that.
21:45 mornfall burp: The history is linearised and you get warnings about that.
21:46 burp but the latest one should work
21:46 burp (let me try again)
21:46 mornfall Yes, heads should be identical.
21:46 mornfall diff -ruN -x .git -x _darcs gitrepo darcsrepo
22:00 burp sadly not the case
22:01 mornfall Bummer.
22:01 burp but might be that the hg-fast-export.py is fault
22:01 mornfall Try importing it into git, then.
22:01 mornfall It may also help to pass it through real git: git fast-import and then fast-export the result again.
22:09 burp ok, git fast-import worked, I will reexport there now
22:18 Igloo joined #darcs
22:18 Heffalump joined #darcs
22:22 burp ok, nice with git fast-export one can export just one branch� that works in any case
22:25 burp interesting, the _darcs directory gets much bigger now through git fast-export
22:27 mornfall burp: That's probably because git uses "blob" commands in the stream.
22:27 mornfall burp: Which need to be stored until the operation finishes, since they can be referenced at any time.
22:28 mornfall burp: Darcs will clean that up after finishing (assuming it finishes).
22:28 burp ok
22:28 mornfall Btw. there's fast-export --all.
22:28 mornfall But fast-export HEAD (or master) should work fairly reliably, yes.
22:32 burp hm, no such cleanup it ~300MB bigger, but at least works :>
22:33 Igloo Did anyone do anything with that testcase, or should I file a ticket?
22:38 burp darcs optimize did it's job :) down from 1.1GB to 780MB
22:38 burp mornfall: will you create support for incremental imports?
22:39 mornfall burp: That's missing optimize at the end I guess, sorry. :)
22:40 mornfall burp: Eventually, I guess so, although I'll be busy with other stuff for a while.
22:40 burp ok
22:40 mornfall It'll probably just use tags with marks in it. Shouldn't be too hard.
22:41 mornfall lambdabot: @src fix
22:41 lambdabot fix f = let x = f x in x
22:42 mornfall What good is it? : - P
22:45 mornfall I want iterate-until-fixpoint. :|
22:56 balor joined #darcs
23:36 Igloo mornfall: Any idea why darcs thinks a file should be removed, when the file exists in working and there is noting in pending?
23:37 abuiles left #darcs
23:37 FunctorSalad joined #darcs
23:37 Igloo Hmm, recording a patch that doesn't include those changes has made darcs no longer want to record them

| Channels | #darcs index | Today | | Search | Google Search | Plain-Text | summary