Time  Nick         Message
04:51 sm           owst: it redirects properly after merging now
09:23 gal_bolle    hi owst
09:24 owst         hi gal_bolle
13:25 kowey        hello!
13:38 owst         Afternoon kowey
15:55 kowey        hi bsrk, ready to start?
15:55 bsrk         yes
15:55 kowey        how did your week go?
15:56 bsrk         My  school semester just started,
15:56 bsrk         an unfortunately the internet facility does not support ssh connections. I could not upload my work into the repo.
15:57 kowey        hmm
15:57 bsrk         I will upload it tomorrow using a third party connection.
15:57 kowey        are you going to be able to continue working in a full time capacity?
15:57 bsrk         yes.
15:58 bsrk         my classes are like 18hrs per week
15:58 bsrk         and my gsoc work is like 20hrs per week.
15:58 kowey        you do realise that GSoC runs on 40hrs per week?
15:59 kowey        I mean, nobody is here to follow you around with a stopwatch…
15:59 bsrk         I am talking about how *I* did it. But yes, it is supposed to be 40 hrs a week. :-)
16:00 kowey        hmm
16:01 bsrk         So, this week I wrote the tests planned
16:01 bsrk         (1) Testing based on properties of patch index structures
16:02 bsrk         (2) Expand the shell test, and testing with expected correlation
16:02 bsrk         I have completed the timing tests
16:02 bsrk         and updated the google docs
16:03 kowey        less computer crashing this time
16:03 bsrk         I have updated the documentation on structures.
16:03 bsrk         Actually they continued to crash
16:03 bsrk         I have split up the work
16:04 bsrk         into smaller chunks
16:04 bsrk         and ran them indivdually
16:05 kowey        have you learned anything from the timing tests?
16:07 bsrk         Patch index is worth it. :-)
16:07 bsrk         It saves 15sec on average at cold in annotate, and 13 sec on average at cold in changes.
16:08 kowey        what is average?
16:09 kowey        hmm, sorry not a clear question
16:09 kowey        have you thought carefully about what you mean when you say “on average”
16:09 kowey        is that notion even sensible?
16:09 bsrk         https://docs.google.com/spreadsheet/ccc?key=0AtdxF5AhJcuwdHFlMm0xd1poeTROYW1KN0ZGR2U0enc
16:09 bsrk         https://docs.google.com/spreadsheet/ccc?key=0AtdxF5AhJcuwdGdrT2lLMGZXbktZblFxWmhxNkxXRVE
16:09 kowey        are you familiar with the distinction between the mean and the median?
16:10 bsrk         Of course. In this case I took the mean of all the files in darcs repo.
16:10 kowey        (I'm not sure how rigorous we really need to be about this)
16:10 kowey        I guess what I'm concerned about is “how meaningful a metric is this?”
16:11 kowey        like what's the distribution of times and savings?
16:11 kowey        well, it's hard for me personally to expect much more statistical/experimental sophistication when I myself don't know what I'm doing
16:12 bsrk         For what it is worth, it seems that patch index saves more time than costs.
16:12 bsrk         My experience is only with hot repos,
16:12 bsrk         but I am not noticing any lag for update
16:12 bsrk         and the lag of create is not too bad.
16:13 bsrk         Most of my queries with changes, annotate give instantaneous responses.
16:14 kowey        have you had time to look into darcs-benchmark?
16:14 bsrk         I did not look into it any further. :-(
16:14 kowey        not enough time?
16:15 kowey        sorry, perhaps a bit harsh
16:15 bsrk         Is it a priority? I want to finish up the formal goals first.
16:15 kowey        tell me about the mailing list discussion
16:15 bsrk         I don't really have an excuse of "not enough time". :-)
16:15 kowey        how did that go?
16:16 bsrk         There were a few good ideas. But mostly I am concerned with the amount of miscommunication.
16:17 kowey        what do you mean?
16:18 bsrk         1) Feedback at patch index creation: If you run patch index on an old repo, you will get a message saying patch index is being created.
16:20 bsrk         2) Patch index is updated/created, after the actual operations. ie you can do a control-c, and the operation will still succeed with an old pi state.
16:22 bsrk         3) If patch index is created at get, it will be fast. Even if it is created from a cold state, it is still creatively not bad (around 4x the average changes)
16:23 bsrk         So, basically the good suggestions were:
16:24 bsrk         1) Renaming no-patch-index to disable-patch-index.
16:25 bsrk         2) An explicit statement that ctrl-c is okay when pi is being created/updated. The user should know that the main operation is over though..
16:28 kowey        what are you going to do now that people have given you feedback on the list?
16:29 bsrk         I will clear up issues with a follow up post, and implement the suggestions. :-)
16:30 kowey        so anything else to report for the week?
16:31 bsrk         I basically completed goal 4 of testing.
16:32 bsrk         I asked Benedikt for review of goal 2 (using pi in changes/annotate)
16:33 bsrk         and goal 3 is in progress. (I started a little, and hope to make more progress in the weekend)
16:34 kowey        have you been meeting with Benedikt these few weeks?
16:35 bsrk         yes?
16:36 bsrk         yes. :-)
16:36 kowey        how's that going?
16:37 bsrk         We discuss some issues, and he has a few suggestions.
16:41 kowey        ok
16:41 kowey        so weeks 11-13
16:41 kowey        what have you got planned?
16:41 kowey        you mentioned getting back to the people who took the time to respond to your request
16:43 bsrk         I will finish up documentation, Implement suggestions from Benedikt's reviews, and respond back to the users post. (next week)
16:45 kowey        there's also darcs-benchmark you could work on
16:45 kowey        but I do understand that documentation can be pretty hard work
16:45 kowey        as usual, I'll do what I can to give you feedback
16:45 kowey        anything else?
16:46 bsrk         yes. I will work on benchmark after I finish up the documentation on tests.
16:46 kowey        well, I guess I have some stuff to report
16:46 kowey        I'm still working on rebasing your patches
16:47 kowey        it's slow going, partly because I'm being a bit perfectionistic
16:47 kowey        trying to tease things about into patches that would be easy to review
16:47 * Heffalump  is having the same issue with rebasing rebase :-)
16:47 kowey        :-)
16:47 Heffalump    though I'm kind of coming to the conclusion that most of the development history is uninteresting
16:47 Heffalump    (I've also been fixing new problems I found in rebase as I go)
16:47 kowey        I am getting the hang of using the rebase stack
16:47 kowey        for example, if I want to split a patch over its precedessors
16:48 kowey        I now, unrecord, amend, suspend, amend, suspend, amend, unsuspend, unsupsend
16:48 kowey        probably a bit more fiddly than git users would like
16:48 kowey        but being able to focus on only one thing at a time like that with the darcs interactive ui is also nice
16:48 kowey        (not fiddly like complicated, just that you have to mentally work out how to achieve what you want)
16:48 kowey        oh sorry, bsrk, I'm letting myself get distracted
16:49 kowey        so yeah, basically still rebasing your work
16:49 kowey        otherwise
16:50 kowey        I'll have to admit I'm a bit unhappy about this 20h work week thing
16:50 kowey        there's not much I can say here, now, because it's just an immediate reaction
16:50 kowey        but I'll have to take some time to sort through my feelings/thoughts about it
16:51 kowey        and figure out a response that would be good for you and past/future GSoCers
16:51 kowey        sorry if I'm being a bit too upfront about it
16:51 bsrk         Nah, I understand.
16:52 kowey        alright, well good luck for next week
16:52 kowey        do use me for documentation feedback
16:52 kowey        I'm mostly offline Mon-Wed as I'm focusing on work
16:53 kowey        see you around
20:27 davidsarah   hello
20:27 davidsarah   we have a reproducible test case where 'darcs get --tag' does the wrong thing, in darcs 2.5.2
20:27 davidsarah   (am installing 2.8.1 now to test with that)
20:27 davidsarah   does that sound like a known bug?
20:28 davidsarah   it seems similar to this: http://irclog.perlgeek.de/darcs/2012-05-28
20:30 davidsarah   script that reproduces the bug: http://codepad.org/vH2N04lo
20:31 davidsarah   expected output (using darcs 2.4.4): http://codepad.org/OUae28Km
20:32 davidsarah   incorrect output (using darcs 2.5.2): http://codepad.org/U5MZX830
20:33 davidsarah   same problem with 2.8.1
20:34 davidsarah   the problem seems to be that the later darcs versions are not unapplying patches that need to be unapplied in order to reproduce the tagged revision
20:53 Heffalump    davidsarah: doesyour tag situation sound similar?
20:53 Heffalump    i.e. could the tag be "not clean", i.e. have patches before it that aren't actually in the tag
20:54 Heffalump    I thought I actually made a test case for dmwit's problem
20:54 Heffalump    but I'd have to check the bug tracker as I can't see any mention of it in the onversation log
21:25 * davidsarah reads the log again
21:27 davidsarah   our test case seems simpler than that one, but it *could* be the same bug
21:28 davidsarah   yes, the "Unapplying 0 patches" (when you'd expect some patches to be unapplied to get to the tag) sounds the same
21:30 Heffalump    ah, I did flag a bug about it: http://bugs.darcs.net/issue2199
21:30 Heffalump    no test case, but it suggests I did reproduce it as that
21:31 davidsarah   I'm unclear what you mean by a tag being "dirty"
21:32 Heffalump    "not clean" as above - an internal representation thing really, but it bleeds into darcs beaviour sometimes
21:32 davidsarah   please look at http://codepad.org/vH2N04lo and tell me what it is doing to produce a dirty tag, if that's the problem
21:33 Heffalump    ooh, a test case, great! :-0
21:33 davidsarah   does "dirty" mean that some patches have to be unapplied to get to the tag?
21:33 Heffalump    and it fails in mut?
21:34 Heffalump    no, it means that some patches that are before the tag in the repo can be unpulled without unpulling the tag
21:34 davidsarah   hmm
21:34 Heffalump    assuming I'm right that it fails in mut and not in orig, the reason is the record you do in mutant before pullnig th tag
21:34 davidsarah   (21:31:09) davidsarah: expected output (using darcs 2.4.4): http://codepad.org/OUae28Km
21:34 davidsarah   (21:32:29) davidsarah: incorrect output (using darcs 2.5.2): http://codepad.org/U5MZX830
21:34 davidsarah   (21:33:12) davidsarah: same problem with 2.8.1
21:35 Heffalump    it's not your fault, it's a clear bu
21:35 * davidsarah nods
21:35 Heffalump    and yes, you're getting exactly what I'd expect if that ws the characterisation of the bug.
21:35 davidsarah   ok, thanks
21:35 Heffalump    I guess I should fix it instead of talking about it so much :-)
21:35 davidsarah   :-)
21:36 davidsarah   (22:34:57) Heffalump: assuming I'm right that it fails in mut and not in orig, the reason is the record you do in mutant before pulling the tag
21:37 davidsarah   yes, that's what I thought it must be