Camelia, the Perl 6 bug

IRC log for #darcs, 2012-12-04

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

All times shown according to UTC.

Time Nick Message
00:06 kmels joined #darcs
00:54 favonia joined #darcs
00:57 gh_ joined #darcs
01:36 amgarchIn9 joined #darcs
01:55 mizu_no_oto joined #darcs
02:07 intripoon_ joined #darcs
02:43 mizu_no_oto joined #darcs
02:51 favonia joined #darcs
08:41 schlaftier joined #darcs
09:46 donri joined #darcs
10:26 thorkilnaur_ joined #darcs
10:28 kmels joined #darcs
10:36 owst joined #darcs
10:37 jyyou_ joined #darcs
11:03 raichoo joined #darcs
13:16 dixie joined #darcs
13:23 iago joined #darcs
13:32 mizu_no_oto joined #darcs
15:03 mizu_no_oto joined #darcs
15:25 markstos joined #darcs
16:31 donri joined #darcs
17:06 mizu_no_oto joined #darcs
17:30 iago joined #darcs
18:07 markstos Good day. Why is darcs preventing me from rolling back a patch that is beneath a tag, without also rolling back the tag? That tag states that the repo was previously in a specific state.  Adding a rollback patch to the stack doesn't change or invert that.
18:12 sm hi markstos. It does seem intuitively that a rollback after an intervening tag should be legal
18:14 markstos I decide to proceed anyway, and I'm reviewing the results now. ATM, I can't find the the rollback patch in "darcs changes" that I thougth I just created. :) I'll keep investigating.
18:14 markstos Thanks for the feedback, sm.
18:16 markstos Oh, I see, "rollback" just modified my working copy. I was expecting it to create a patch. I guess I forgot. So this won't be a problem at all. The tags are still present, and I can create the new rollback patch I want on top of them.
18:17 markstos Then it was a UI bug, I think. Darcs should not have shown me the tags as things that must be rolled back to rollback the underlying patch. Because the modified working directly shows no signs of rolled back tags.
18:17 markstos I realized tags depend on all patches below them, but I think they are a special case here.
18:23 amgarchIn9 joined #darcs
18:26 donri joined #darcs
18:30 Heffalump markstos: that's right; a few people have run into this before. SOmething definitely should be done.
18:31 Heffalump rollback changed to only rollback in the working copy recently, because that's what everyone actually wanted
18:31 markstos It's OK with me, too.
18:32 Heffalump there is a more general case for the tags thing: consider a very small patch that depends on a very large patch. If you want to rollback some unrelated part of the very large patch, you'll still have to say 'y' to the small patch and then 'n' to its hunks.
18:32 * Heffalump goes to check if this is already raised on the tracker
18:33 Heffalump yes: http://bugs.darcs.net/issue2234
18:33 markstos I can understand where a newer patch changed the lines of a patch you want to rollback, but tags are fundamentally different.
18:33 * markstos looks
18:35 markstos Thanks, Heffalump. I've commented there and joined the Nosy list.
18:40 markstos I just ran "darcs optimize --reorder" and it took about 5 minutes to think before warning me that it "make unrevert impossible!". Then it took about 10 seconds to finish the optimization. Odd.
19:06 favonia joined #darcs
19:08 markstos Are there any efforts underway to improve darcs performance on multi-core machines? Or are the necessary CPU operations generally all "serial",  and not easily altered to take advantage of multiple cores? ( I've been waiting almost 30 minutes for "darcs optimize --reorder" to finish on a repo. 1 CPU is at 100%, while 3 others are idle)
19:42 Heffalump markstos: sorry for disappearing, internet connection failed
19:43 markstos Heffalump: no problem. Good to see you got that resolved, though.
19:44 sm markstos: ouch
19:44 Heffalump not exactly, it was my mobile one that's getting increasingly unreliable, but I'm home now
19:44 markstos sm. Yep. Still running: 63 minutes and counting. Oddly, a parallel repo finished in < 10 minutes on the same machine, with the same darcs.
19:45 * sm gets confused about how rollback is different from unrecord now
19:45 markstos I hope all this effort is being put into more than calculating the "unrevert" question.
19:45 markstos Too bad, I didn't use the "--verbose" flag.
19:46 sm yeah.. don't you wish such a long operation saved partial progress, so you could quit and resume
19:46 Heffalump I'd have to think about whether commutation is parallelisable
19:46 Heffalump sm: unrecord edits an existing patch (and doesn't change working)
19:46 Heffalump rollback doesn't edit the patch, and does change working
19:47 sm aha, thank you
19:48 markstos I'm working on the assumption that I could speed up local pushes and pulls but getting more common tags into the involved repos, and then run "optimize --reorder" on all repos involved.
19:50 schlaftier joined #darcs
19:52 Heffalump markstos: that sounds likely
20:04 Heffalump hmm, parallel commuting is like parallel sorting but where swapping adjacent elements is O(1)
20:06 markstos So is that finding for against it being responsible to do? :)
20:07 markstos I quit my "darcs optimize --reorder" after 90 minutes, and started it again with "--debug-verbose". At first I thought it was getting hung on an operation of copyFileUsingCache, but after a few minutes, it got past that patch.
20:08 markstos I'm not quite clear on why it's copying patches in or out of  _darcs/patches. I thought the operation just re-organized metadata.
20:09 Heffalump could the repo be lazy?
20:09 markstos What's the best way to check that?
20:10 Heffalump that's a good question
20:10 Heffalump if you run darcs check, when it finishes the repo won't be lazy...
20:11 markstos When I do: "darcs show repo", I do see an out-of-date entry in the "Cache:" line. Now I just need to find where to prune that out.
20:14 Heffalump you can edit _darcs/prefs/sources. I'm not sure if there's a way using darcs commands
20:14 markstos Interesting, I can see now using --default-verbose that it went in a loop. It's back to pausing on the patch it paused on the first time.
20:15 markstos Now that I've removed a bad entry from _darcs/prefs/sources, I'm going to restart again and see if that helps.
20:17 markstos I removed _darcs/prefs/sources completely,  and "darcs optimize --repair" continues to be doing a lot of "copyFileUsingCache".  I wonder why.
20:18 markstos I mean "--reorder", not --repair.
20:19 Heffalump I think there's some code in darcs that makes in-memory patches lazy again by writing them to disk and reloading them
20:21 markstos So, maybe it's a way to limit memory size with working on large repos (like mine)? I did see that the memory use appeared relatively stable.
20:21 Heffalump yes, I think so
20:23 markstos Oh well, I'm giving up "darcs optimize --reorder" on that repo for the day, and settling with "darcs optimize".
20:24 Heffalump how far back is the last tag?
20:24 markstos You mean the most recent tag, by patch count?
20:25 Heffalump yes - and by "how far back" I mean how many patches don't depend on it
20:25 * markstos calculates
20:27 markstos I  did this:
20:27 markstos darcs changes  --from-match 'hash 20121128214514-81fb4-783c7313f2​d2251ccc496436b4eeb0228ffa3f67'
20:27 markstos And the answer it gave me is "1", but I don't believe that.
20:28 Heffalump you could pull the tag into a new repo, but that might also prove time consuming
20:28 Heffalump (and it's an alternate way to get the effect of optimize --reorder - pull the tag first, then pull everything else)
20:30 markstos Here's some insight into the strangeness:
20:30 markstos In my developer repo where "optimize --reorder ran in about 7 minutes", there are 930 patches "above" the last tag.
20:30 markstos However, in the shared "alpha" repo, it's reporting there is just one.
20:31 markstos But one of these tags is from production and was tagged back in "August".
20:31 Heffalump ok, so there are probably several hundred patches to be commuted past the tag
20:31 Heffalump it still does sound alarmingly slow
20:31 markstos In both repos the set of 6 tags I got from production are shown next to each other in "changes", although they should each have about ~50 patches "between" each of them.
20:32 markstos I suppose I could leave it running overnight.
20:32 markstos It should either finish or run out of memory. :)
20:33 markstos This is on an Amazon EC2 volume backed by EBS. They are not known for their screaming I/O performance.
20:34 markstos Thanks for help Heffalump. I'm going to switch gears now to work on another task.
20:36 Heffalump I think I need to get this repo obfuscator written!
20:36 markstos I would certainly have an interesting test case to offer.
20:40 mizu_no_oto joined #darcs
20:50 markstos Given the details in "darcs changes --xml", can I determine what the related file name is in _darcs/patches?
20:52 markstos I found what I needed by looking in the "inventories" files.
23:03 nomeata joined #darcs
23:07 stepcut joined #darcs
23:30 mizu_no_oto joined #darcs

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