[00:14] <wgrant> cjwatson: That's quite a nice diff...
[00:50] <cjwatson> blr: BTW in one of your test cases I noticed that you had " \n" as an inter-patch junk line, which seems inaccurate - normally in bzr it would just be an empty line, "\n"
[00:50] <cjwatson> I begin to wonder whether just copying the code from bzrlib.patches and customising it to our particular needs mightn't be more sensible at this point.
[00:51] <cjwatson> wgrant: Quite :-)  I ran a subset of tests to my satisfaction, though not the whole suite
[00:51] <cjwatson> Will land tomorrow, don't want to have to testfix tonight
[00:52] <wgrant> cjwatson: Heh, good plan.
[00:53] <blr> cjwatson: wouldn't have mattered in that case, it just incremented the linecount for every dirty header other than the first
[00:54] <cjwatson> Right, but in general a line starting with a space is part of a patch.
[00:54] <cjwatson> So it probably wouldn't have actually been considered dirty.
[00:56] <cjwatson> Hence why line.strip() is inaccurate - line.rstrip("\n") would be better, although it still only catches a restrictive subset of non-patch lines where really we should be open-ended.
[00:57] <blr> as far as I can tell, bzrlib patches would need to be re-written, it has no notion of intra-patch junk
[00:57] <blr> it only parses junk until the first patch header
[00:59] <blr> it only works currently as we're explicitly matching against "[00:59] <cjwatson> So, there are two basic approaches.
[01:00] <cjwatson> Instead of throwing away lines that don't fit into any of its categories, it could remember them to attach as dirty headers to the next patch (maybe some slightly special handling of "[01:01] <cjwatson> Or, given that we have a full list of the lines in Launchpad and that bzrlib is currently returning a subset of them in monotonic order, we could spot when it's skipped lines
[01:01] <blr> sorry called to lunch, but please continue
[01:01] <cjwatson> The second could be done while continuing to use bzrlib.patches as it stands today
[01:02] <cjwatson> But it involves at least one extra string comparison per line, so is less efficient
[01:02] <cjwatson> The first could perhaps be done in bzrlib.patches, but rather than continuing to hack that about and fiddle with its semantics, it's not that much code, maybe it's better at this point to just clone-and-hack it and make it handle unrecognised lines in some more useful way for us than "continue"
[01:22] <blr> ls
[01:22] <blr> well, that could have been worse
[01:22] <blr> cjwatson: I'll try that latter
[01:29] <blr> will give me opportunity to remove the semicolons at least.
[01:54] <blr> wgrant: cjwatson: shall we land this in it's current state to fix prod? https://code.launchpad.net/~blr/launchpad/bug-1472045-demangle-inlinecomment-mail/+merge/264105
[01:55] <blr> will continue to work on a more general solution
[01:55] <wgrant> blr: Have you tested whether that makes the git situation worse?
[01:56] <blr> wgrant: no, there are no git specific tests.
[02:03] <blr> hmm cgit renders a space between patches
[02:32] <blr> wgrant: have a test with a simple git diff, could you have a look?
[02:36] <wgrant> blr: That has a blank line between patches, unlike real git diffs.
[03:10] <blr> wgrant: I've added a space in a hunk in the test, and fixed the spaces between patches.
[03:13] <blr> it does appear to be working, aware that it could be better.
[05:34] <blr> wgrant: where best to document the origin of patches.py, before or after the copyright notice?
[05:36] <wgrant> blr: Perhaps the top.
[05:56] <blr> wgrant: see you at some ungodly hour :)
[05:59] <wgrant> blr: Heh, yep.
[05:59] <wgrant> blr: Hm, test failure.
[06:06] <wgrant> Ah, small.diff is buggy, fixing.
[06:07] <wgrant> It has a blank line when it should contain a single space.
[06:07] <wgrant> Trust the least thorough test to be the one that breaks :)
[06:20] <blr> gah sorry, only ran the TestInlineCommentsSection tests.
[06:20] <blr> wgrant: want me to get that, or are you already on to it?
[06:22] <wgrant> blr: Just running the rest to ensure it doesn't break anything.
[06:25] <blr> thanks
[06:25] <wgrant> blr: Looks like it was just that. Will submit when it fails in a minute.
[06:39] <blr> wgrant: great thanks
[08:47] <wgrant> Ahhh
[08:47] <wgrant> I know why elmo's diff was weird now.
[08:47] <wgrant> bzrlib is quite cunning.
[08:48] <wgrant> '\ No newline at end of file' ends up tacked onto the end of the preceding line.
[08:48] <wgrant> So there's a line with two \ns.
[09:30] <blr> wgrant: hmm, well that and the blank line handling
[09:31] <wgrant> blr: Right, but we worked out that that didn't explain all of it.
[09:31] <blr> hmm, any ideas on resolving that?
[09:31] <wgrant> I have a fix which isn't too bad, writing a test atm.
[09:32] <blr> ah great. although, I _did_ reparse elmo's diff and it seemed to align?
[09:47] <wgrant> Oh, indeed, it doesn't suffer from this case.
[09:47] <wgrant> I just threw other big diffs at it until it went wrong.
[10:29] <wgrant> cjwatson: https://code.launchpad.net/~wgrant/launchpad/diff-no-newline/+merge/264254
[10:37] <blr> wgrant: huh, that is surprising.
[10:38] <wgrant> blr: Yes, not exactly what I'd expected.
[10:41] <blr> thanks for persisting with that wgrant
[10:42] <wgrant> blr: Thanks for the review. Will land once Colin fixes the weird xx-person-edit.txt failure.
[10:42] <wgrant> That is also not the sort of thing I'd expect...
[10:42] <cjwatson> wgrant: How entertaining, although the "line is a ContextLine/ReplaceLine" comment can no longer be true.
[10:42] <cjwatson> wgrant: Annoyingly, I spotted the problem by code inspection just before buildbot did.
[10:42] <wgrant> cjwatson: Ah, fair point.
[10:42] <wgrant> Heh
[10:43] <cjwatson> Misplaced (and unnecessary) classImplements transformation
[10:43]  * wgrant out for a bit.
[10:44] <blr> see you in a few hours
[11:31] <wgrant> Huh
[11:31] <wgrant> cjwatson: Interesting failures now...
[11:32] <cjwatson> the hell?
[11:32] <wgrant> I was going to go a bit stronger than that, but yes.
[11:33] <cjwatson> I mean, sure, I touched announcement, but only rather trivially.
[11:34] <wgrant> It also didn't fail last time, did it?
[11:34] <cjwatson> Nope.
[11:34] <wgrant> And the test count was at least roughly corrrect.
[11:34] <wgrant> It doesn't look plausibly spurious, but it must be.
[11:36] <cjwatson> Not in stdio from the last run either.
[11:36] <wgrant> Unless a testrunner died, but I don't see that either.
[11:36] <wgrant> Force and pray.
[11:36] <cjwatson> And you'd expect more missing tests from that.
[11:36] <cjwatson> I'll just run those ones locally a few times to make sure
[11:36] <wgrant> Unless you caught the end of a small layerr.
[11:36] <wgrant> Indeed.
[11:36] <wgrant> gah, bad keyboard.
[11:45] <wgrant> cjwatson: No luck reproducing the failures?
[11:47] <cjwatson> wgrant: Sorry, that container was busy with other tests at the time, I'm running them now
[11:54] <cjwatson> Can't reproduce so far.  Forcing and praying.
[11:58] <wgrant> Yep...
[11:59] <wgrant> postgres was probably just having a bad day.
[12:22] <wgrant> Looks like buildbot is happy, good.
[12:27] <cjwatson> Don't jinx it!
[12:29] <wgrant> Come at me, buildbot.
[12:37] <wgrant> cjwatson: Not even a thousand lines?
[12:39] <wgrant> 79 +@adapter(IBugBranch, IWebServiceClientRequest)
[12:39] <wgrant> 80  @implementer(Interface)
[12:39] <wgrant> Does that actually make sense?
[12:41] <wgrant> Hm, something must be referencing it. How odd.
[12:42] <wgrant> Oh, the registration is named, right.
[13:30] <blr> night
[13:30] <wgrant> Night blr
[13:41] <cjwatson> night, thanks
[20:07] <cjwatson> wgrant,blr: If you could get QA done and a deployment sorted out over my night, that would be very helpful to the phone folks
[20:08] <cjwatson> Then I could turn on ubuntu-rtm/15.04 translation imports
[20:44] <blr> cjwatson: ack
[20:54] <pepee> hi. how come comments in launchpad don't have anchor tags?
[20:58] <blr> pepee: if that would be useful to you, by all means file a bug and tag it 'feature ui'
[20:59] <pepee> ... I'm guessing it would be useful for me and everyone else. I haven't found a way of showing a comment in its context
[20:59] <pepee> I doubt no one has suggested that
[21:00] <blr> pepee: yep, appears there is a bug
[21:00] <pepee> which one?
[21:01] <blr> https://bugs.launchpad.net/launchpad/+bug/124166
[21:01] <mup> Bug #124166: browsing to bug comment permalink should show comment in context <lp-bugs> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/124166>
[21:01] <blr> https://bugs.launchpad.net/launchpad/+bug/627252
[21:01] <mup> Bug #627252: no comment permalinks for issue comments <lp-answers> <ui> <Launchpad itself:Triaged> <https://launchpad.net/bugs/627252>
[21:01] <pepee> hehe
[21:01] <blr> I'll see if I can get to those next week, shouldn't be too hard.
[21:02] <pepee> thanks!
[23:47] <wgrant> blr: Yeah, I'd much prefer that the comment-specific URLs redirected to an anchor on the bug page. The dynamic loading JS complicates that, however.
[23:53] <blr> wgrant: yep, the single comment view is of questionable value.
[23:54] <blr> wgrant: we could check the location on comment load for an anchor and scrollTo
[23:54] <wgrant> blr: But we'd have to also force that chunk of comments to load.
[23:55] <pepee> can there be both things? like a URL parameter to select between a single comment and the whol context
[23:55] <pepee> like in forums...
[23:56] <blr> wgrant: true, that is a little tricky. could we always pre-render a map of ids to comment chunks?
[23:57] <blr> err s/render/generate/
[23:57] <blr> on load, check the location for an achor, match to the map, load the appropriate chunks
[23:58] <blr> no idea how feasible that is, I need to look at the code again
[23:58] <wgrant> pepee: Why?
[23:58] <wgrant> What's the use of seeing just the comment?
[23:59] <pepee> wgrant, same reason people do both things in forums, some may want to show only one comment, some may want to show the whole thread, and one specific comment in context