[00:00] got a minute? [00:00] beuno: adding + and - would be a prereq, I don't know if it sufficient [00:00] oh hello jam [00:05] beuno: sure, what should I look at ? [00:06] lifeless, have the mockups for loggerhead landed in your email? [00:18] beuno: newer ones? [00:19] lifeless, yes, a week ago, max [00:19] the diff view, specifically [00:19] the ones via joey ? [00:19] yeao [00:19] *yeap [00:20] yes, I have it [00:21] good, well, how does it look to you? [00:21] lifeless: can I merge my loom status branch? [00:21] I am able to tell the red and green apart [00:21] ah, yay! :) [00:22] thanks lifeless [00:22] however, I'm only red-green colour insensitive [00:22] there are emulators for all colourblindness types [00:22] if you haven't, you should simply view the page view them [00:22] *via* [00:22] yes, I'll make sure we test it with some tool (GIMP seems to have something that does that) [00:23] but I think the reason is solely that red is left and green is right [00:23] any change on one side is one colour in that layout [00:23] so you could use one colour 'change from this side' [00:23] :P [00:24] jml: did it get the tick ? [00:24] hrm, I wonder if it would be too invasive to cross out the actual text being deleted [00:24] lifeless: it hasn't got any reply yet that I've seen [00:25] I have a queue for loom reviews [00:25] two for aaron [00:25] and that one needs its final pass I think [00:25] and 2 pqm branches to me [00:25] *merge* [00:27] 'evening beuno, jml, lifeless [00:27] lifeless: any news on bzr-gtk pqm and/or a shallow-branches+bzr.dev merge? [00:27] jelmer: hello. [00:27] hey jelmer [00:27] lifeless: that was the tick right? [00:28] jml: I think thats what I mean [00:28] :) === mark1 is now known as markh [01:18] lifeless: ping [01:19] hi [01:28] lifeless: what's the current status of shallow branches? Planned for 1.7 ? [01:28] jelmer: 1.6 hopefull [01:29] jelmer: igc has posted a merged copy [01:29] lifeless: ah, I must've missed that [01:29] 17:28 < igc> current state of merging bzr.dev into the stacked branches loom is now pushed to http://people.ubuntu.com/~ianc/bzr/shallow-branch/ [01:29] lifeless: thanks, I'll see if I can get bzr-svn to implement it then or at least cope with the new API :-) [01:30] jelmer: cool [01:31] jelmer: ping me with questions [01:31] jelmer: I'm sure there will be various [01:31] lifeless: will do [01:35] lifeless: also, the bzr-gtk pqm: should I keep asking you about it or would it just be easier to set up something outside of the core bzr infrastructure ? [01:36] I will mail you today a set of questions [01:36] then you reply and I forward to RT [01:37] lifeless: ah, cool - thanks again :-) [01:38] I've been meaning to make up good answers myself [01:38] but clearly that isn't working [01:40] ah, ok [02:13] "bzr missing" to a launchpad url isn't really fast [02:14] Pieter: the Launchpad code server is running much slower than normal at the moment. We're trying to fix it now. [02:15] ah ok :) [02:15] jml: have you announced this anywhere? [02:16] lifeless: no. just about to. [02:16] jml: /topic here and /launchpad is my normal first port of call [02:16] jml: as soon as I know there is a problem === jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | bazaar.launchpad.net running slower than usual, we're fixing it now [02:21] (also, put it at the left, GUI clients hide the right hand edge) === jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [02:53] igc: ping === gotgenes_ is now known as gotgenes [03:58] hi all [03:58] thumper: pong [04:11] igc: quick call? [04:11] thumper: sure [04:11] skype is ok if you wish [04:14] jam: still here? [04:14] jam: why would cvsps-import hang on 'creating a dump' [04:15] stracing the cvps process its stuck in read(), cvs is stuck in select .. [04:30] lifeless: I couldn't tell you for sure, if it was up to me, I would run cvsps manually and pass cvsps-import the dumpfile [04:30] I've found it [04:30] write(4, "Argument gnash\n", 15) = 15 [04:30] write(4, "rlog\n", 5) = 5 [04:30] read(5, "E cvs rlog: Logging gnash\n", 4096) = 26 [04:30] read(5, "E cvs [rlog aborted]: cannot stat /var/lock/cvs/sources/gnash: No such file or directory\n", 4096) = 89 [04:30] read(5, "error \n", 4096) = 8 [04:31] cvsps doesn't handle rlog failures [04:31] at least the version on tungsten [04:31] I'm going to fix the modules file and note this somewhere [04:31] for cscvs when we get a cvs tarball it manually creates a clean cvs configuration [04:32] I think cvsps-import needs to do the same [04:33] jam: I have another question now though :P [04:33] have you seen [04:33] request for non-existent rev 1.6573 in file ChangeLog [04:33] before ? [04:34] there is such a version [04:34] at least in the commit info metadata [04:35] and in the main content too [04:36] lifeless: is the content considered deleted, etc though? [04:36] or is there a Attic file hiding somewhere? [04:36] do you mean is it flagged -k ? [04:36] this file is not in the Attic [04:36] nor is it shadowed in the attic [04:38] corrupt ~/.cvsps/#home#bzr_conversion#conversions#gnash#gnash-cvs#gnash file [04:39] and here I thought cvsps was stateless; its not! hahaha cscvs sounds more and more attractive to me ;P [04:40] haha [04:40] lifeless: Well, if it had been public, and someone else had been willing to work on it, I probably wouldn't have used cvsps either [04:40] this stuff was started 2-ish years ago [04:40] I know :) [04:41] I wasn't intending criciscm [04:54] spiv: is there a urlutils.unescape that doesn't go to unicode? [04:54] spiv: I really want to just unescape :P [04:55] nvm, I'll use urllib directly === BasicPRO is now known as BasicOSX [05:43] * igc pick up kids [06:43] lifeless: hi, still around? [06:44] yes the diet hasn't worked yet [06:44] heh [06:44] i'm i'm working on test_get_texts_eol_variation again [06:46] it's failing in a way i don't remember seeing last week [06:46] http://pastebin.ubuntu.com/16771/ [06:47] you don't need to work on it i think i just need a teddybear [06:49] * abentley has disconcerting visions of poolie using lifeless as a teddy bear [06:49] hm ok maybe it's losing a line-ending therefore the serialized form is wrong [06:54] that indicates that a full text or delta was written as [06:54] prefix\n [06:54] content [06:54] suffix\n [06:55] one likely cause is the initial bug: a basis text with an unchanged line doesn't have the \n for the internal canonical form and thus is copied across corrupting the full text at a snapshot point [06:56] right [06:56] so taking out the cleanup_eol call, as my original patch was going to do [06:57] does fix that, but causes some failures in TestKnitMerge, a bit surprisingly [06:57] maybe also due to aliasing bugs... [06:59] what are the failures? incorrect assignment of annotations? [07:01] lifeless: I need your help if you have a moment. See http://rafb.net/p/Th8E4140.html [07:01] That's the source of the broken test [07:01] ah ok [07:02] it's doing an annotation-based knit and the final newline is incorrect [07:02] basically get_ancestry (revision_id) was throwing NoSuchRevision and I need to do the same in your replacement code [07:04] lifeless: if found_ids is the empty set, can I then raise NoSuchRevision? [07:04] igc: thats what was coming to my mind [07:04] igc: please be sure to commit this to the appropriate thread, not just the top of the stack :) [07:04] yay [07:04] lifeless: of course [07:04] poolie: found a matching bug elsewhere? [07:05] yep, similar bug in handling annotated content [07:05] igc: ;) as you haven't been working with looms I'm being cautious is all [07:05] lifeless: no problems. I'll try that anyhow. [07:15] lifeless: no luck with that ... [07:16] igc: what thread is this? [07:16] both found_ids and result_set = frozenset(['pizza']) [07:16] is pizza what is meant to be missing? [07:16] StackableBranch [07:16] yep [07:16] it's the revision-id :-) [07:16] ok [07:17] you need to unpack that _breadth_first_searcher use [07:17] there are two next() methods on BFS [07:17] one returns the ids [07:17] one checks for ghosts and returns (present, absent) [07:17] you need to use the latter for the first step [07:17] and then you can switch back to the former for the rest of history [07:17] what's the chain(*...) about? [07:18] pydoc itertools.chain [07:18] I read that [07:18] :) [07:18] ok, uhm, at this point I think its easier for me to do it [07:18] update for #234748 sent if someone wants to look at it [07:18] or at least, I can't do what I need to do know if what I've described isn't enough for you to be unblocked [07:19] (my head is full of cotton wool - ask jml what I sounded like on the phone) [07:19] lifeless: no - I'll do it [07:19] you're busy enough [07:19] hmm. pizza *is* missing. [07:19] basically for the first step use the more complex api on the searcher [07:19] ok [07:19] if you get a ghost back raise [07:20] then you can use the pithy logic for the rest [07:20] ok [07:22] lifeless: would you please send your 'add_lines' patch to pqm, it looks good to me too [07:22] poolie: I was expecting you to merge it into your branch [07:22] poolie: because my fix wasn't necessarily good standalone foo; and they are really about the same stuff [07:23] oh ok [07:23] i can do that [07:24] e.g. I have a hacky workaround [07:24] the test in mine is good to have, the extra assertion is good, but the [07:25] if thing not ending in newline give it one [07:25] that code shouldn't have to exist [07:25] jml: is tonight or thurs better for you ? [07:26] lifeless: tonight has become impossible since I wrote the email. [07:26] sadness [07:26] snort [07:26] (not at you) [07:27] also, ECHANNEL, fixed [07:40] lifeless: ok i merged your change into mine [07:41] cool, thanks [07:41] every thing passes [07:41] um [07:41] and you removed that hacky thing of mine ? [07:41] i think the situation i was just talking about before will obviate the need for the "add a newline back in" [07:41] not yet [07:41] would like to, i agree it's gross [07:42] can you read my patch and see if you agree it will do instead? [07:42] url? [07:44] http://bundlebuggy.aaronbentley.com/request/%3Ce01316480806032317p11b6b885n396cb037dc55c001%40mail.gmail.com%3E [07:45] jml: latin login support for hardy: https://edge.launchpad.net/~lifeless/+archive/+builds [07:46] poolie: your XXX: in check will spuriously conflict with my mega branch [07:46] kk [07:46] lifeless: sweet. [07:46] well it should be easy to resolve :) [07:46] * jml corrects himself [07:46] lifeless: bonus! [07:47] ridere ex [07:48] (ewww, I know thats wrong) [07:51] poolie: did you ring me? [07:51] nup [07:59] poolie: the reasons are not historical, they are current [07:59] poolie: the reason is that this layout is the internal form used on disk by knits, so its more efficient to keep it in this form during all transformations until we need to hand it to a user [08:00] poolie: your repr is buggy; if you really want a naked except be sure to not catch KeyboardInterrupt and SystemExit, but I question wanting that at all [08:01] poolie: finally, yes I think you should be able to remove my hack with your patch present [08:02] though I wonder perhaps if we're unwinding a performance tweak (presumably johns, he was focused on annotate) and whether this needs verification in that sense) [08:03] lifeless: i think naked except doesn't catch them, does it? [08:03] it catches everything [08:03] the general rule for it is 'it is never correct to use it' [08:03] seeing it -> red flag [08:03] except when it is :) [08:04] but the flag is still there. [08:04] jml: thats why its a general rule ;P [08:06] ok, catching Exception lets it pass through but bare except does not [08:06] i thought they were the same [08:07] I'm still unclear why you want to catch Exception [08:07] what errors are you expecting [08:07] i want to avoid an error in repr masking the real underlying exception [08:07] poolie: There's a BaseException now [08:08] poolie: I can't see anything that can error there [08:08] the particular case that has bitten several times is when the object is not fully initialized [08:09] for example if the transport doesn't exist or isn't working yet [08:09] on *KnitAccess* ?! [08:09] poolie: it's new in 2.5. SystemExit and KeyboardInterrupt in particular are now based from BaseException rather than Exception [08:09] i sent a patch proposing that we should as a general pattern we should make reprs defensive [08:09] it is not about this specific case [08:09] oh [08:09] It smells to me. I'll need to think about it I guess [08:10] i agree that catching interrupts is bad [08:10] poolie: the other thing "except Exception:" won't catch is string exceptions. Bare except always catches everything. [08:10] it should at most be 'except Exception' [08:11] it smells to me of bug masking [08:11] (trying to hunt down my dislike of this concept) [08:12] poolie: regarding reprs, another approach is to define a safe_repr method. [08:12] Well, bugs in __repr__ are generally unimportant bugs. We use __repr__ for debugging rather than user output (except maybe in bzrlib.errors I guess). [08:13] jml, yes, we could call that from code that might be handling broken objects... [08:13] spiv, yes, that was my reasoning; i would rather get teh real error and only a faint indication there's a problem in repr than vice versa [08:13] spiv: not bugs in __repr__. bugs in other code, both design and simple omissions etc which don't get diagnosed and fixed as such because they are only percieved as 'makes repr print 'unprintable'' [08:13] It certainly seems like a poor tradeoff if a bug in writing to a rarely-read log file (the ~/.bzr.log) causes a more serious problem. [08:13] perhaps just catching AttributeError would be enough. [08:14] spiv: For me, I'd rather know that something deep is wrong and have to go fix it than have a repr that hides that from me [08:14] lifeless: well, if the bugs are in the category of "an incompletely initialized object can be seen by other code" it's pretty hard to fix/avoid in python [08:15] poolie: __init__ is relatively easy to make very robust [08:15] lifeless: well, in debugging situations you can still sometimes see half-initialised objects. [08:15] lifeless: e.g. when attaching a gdb, or looking at gc.get_objects() when looking for a memory leak. [08:16] well, those are perhaps edge cases [08:16] That said, it hasn't often happened to me. [08:16] I haven't seen it happen ever to me [08:16] i guess we could require __init__ always create all attributes with None first before doing anything that could possibly fai [08:16] or do them on the class... [08:16] poolie: does this happen often to you ? [08:16] a few times [08:17] arch [08:17] is it usually on code you are crafting, or when diagnosing an existing bug ? [08:17] i have to say the absence of reprs altogether annoys me more than this [08:17] oops [08:17] the second [08:17] hello :) [08:18] poolie: I think we have quite different debugging styles; this may cause you to want a smoother repr facility [08:19] possibly [08:19] poolie: also, I'd rather than we make __init__ on objects which are fragile in this way for you be cleaner, than use naked exceptions [08:19] i'm not talking about just interactive debugging but also tracebacks and test failures [08:19] poolie: yes thats the broad category of 'debugging styles' I was referring to [08:20] sure, if this ever trips it is in a senes a bug [08:20] I have some code that enhances the default traceback which I keep meaning to tidy up and submit [08:20] however, i'm concerned with catching information on first failure as much as possible [08:20] therefore catching the most important error [08:20] which is not really that __init__ has an impossible-to-totally-avoid bug [08:21] well [08:21] s/really/usually [08:21] I think there are other approaches to do that [08:21] an object graph walk for instance will gather much more data [08:21] and can be made much more robust in general [08:22] as well as not requiring scatterings of partial-object-dump code in every class [08:22] walking the whole dir() of the classes? [08:23] objgrep ftw! [08:23] (your _KnitAccess repr is IMO hiding import data about its internals such as _need_to_create), and I often find that repr() functions bitrot, which is one reason I rarely add them - I can't depend on them so I don't [08:24] poolie: e.g. pickle to a text backend [08:24] Except that pickle isn't exactly robust. [08:24] which can be human read [08:24] spiv: 'e.g.' [08:25] lifeless: sure, but solutions that are theoretical are less helpful than concrete ones :) [08:26] spiv: well, concretely - walk the __dict__ [08:26] (pickle in particular is even more sensitive to the exact unexpected-object-state problem than repr) [08:26] spiv: you could always post process the pickle into XML [08:26] oh wait, this isn't #zope [08:26] ok this is definitely a difference in debugging style [08:26] i am looknig for a hint as to what it is,not the whole details [08:27] mwh i think just complained that one of them was very big [08:27] Inventory specifically I believe [08:27] it prints its content [08:27] (which I find useful if I am going to poke at an inventory) [08:28] lifeless: it sounds like you're suggesting an alternative to gathering simple tracebacks. I don't think that's what poolie is talking about; he's happy with simple tracebacks, he just wants to make sure that generating them doesn't occasionally fall over and lose the original error. [08:28] not so good if someone gets a traceback contaninig one on a real tree [08:29] poolie: I would argue its quite useful actually, it has enough to reconstruct most if not all of the inventory here and check it for consistency [08:29] not that we've written a parser [08:29] Having richer debug tools than tracebacks could be useful, but I think is solving a different problem. [08:29] spiv: sure, but it comes back to debugging style I think [08:30] "what poolie is talking about" <-- correct [08:30] so I get that that is what poolie is talking about :) [08:30] anyhow... [08:30] i agree the bare except is too strong [08:31] and I've already put my vote in which is that I would rather we fix those bugs than add 4 lines of hand holding to every single repr; and if we're going to have repr's as a policy thing, not an occasionally useful thing, thats a whole lotta code [08:31] nix [08:32] any other comments on the meet of that patch? [08:32] meat* [08:32] * gour has problem switching buffers today [08:32] poolie: other than what I've raised I think its good [08:33] ok so [08:33] 1- correct comment about 'historical reasons' [08:34] 2- check with John about performance with this applied [08:35] 3-repr mumble mumble mumble [08:35] i'll take out the except; i'll leave the repr if that's ok with you [08:35] thats fine [08:35] thank you === gour is now known as gour|afk [08:36] ugh [08:36] so one way in which check is slow [08:36] is that it appears to check every text weave twice [08:37] i think so [08:37] not your XXX: [08:37] your XXX: refers to w.check() and for thing in w: [08:37] there are two code sites calling w.check() [08:38] oh well at least twice then [08:38] so there is w.check(), w.check() and for thing in w: [08:38] I think your XXX: is flawed because w.check() and for thing in w: can be different statements of correctness. [08:40] indeed, confirmed [08:40] i didn't mean strictly redundant [08:40] perhaps that is unclear [08:40] it is [08:40] also the code doesn't exist anymore here :) not in such a form anyhow [08:40] there is a lot of overlap but not complete overlap [08:41] otherwise i would have killed it already [08:41] check_one_rev also checks the revision tree [08:41] and the file text scan does that too [08:41] which is overlap [08:45] I'll be happy to give that comment a new home [08:45] if you want to make it a bit clearer that would help [08:46] hmm, interesting [08:46] tbh the only thing i am confident in is that check could be faster [08:46] I get 10 inconsistent parents for a test that wants 9 :P [08:46] :) [08:47] FWIW that comment is in the class of comments I don't make; because folk wanting random things to do go to the bugtracker, and folk optimising generally start with a profile :) [08:47] (But I don't object to them existing, just explaining why I tend not to make them) [08:48] ok [08:49] lifeless, poolie, jml: rev 3250 of http://people.ubuntu.com/~ianc/bzr/shallow-branch/ now passes all tests [08:50] igc: thanks!. the next thing for that loom is to start peeling off threads from the bottom and updating them with review comments and merging [08:50] I guess the next step is to break it up into different bits for review? [08:50] igc: it comes pre-broken :) [08:50] true [08:50] I think the bottom one - errors - is already merged [08:50] igc: all the threads up to and includin external_reference_tests should be reviewed-with-comments already [08:51] ah [08:51] that's good [08:51] I'll chase down those reviews [08:51] note that 'revno' doesn't really apply to a loom, you need the loom's revno, which isn't currently exposed :) [08:51] ok, that was weird: [08:51] bzr pull http://people.ubuntu.com/~ianc/bzr/shallow-branch/ [08:51] http://people.ubuntu.com/%7Eianc/bzr/shallow-branch is permanently redirected to http://people.ubuntu.com/~ianc/bzr/shallow-branch/ [08:52] note the / -> no / -> / [08:53] lifeless: have you already applied the reviewed comments for those early threads? [08:53] igc: I don't believe so [08:53] igc: I was already context switched [08:54] lifeless: so I'm happy to do that but ... [08:54] I'll then assume someone else - beyond you and I - will review the result [08:54] (I'm concerned about reviewing my own tweaks to your code if that makes sense) [08:55] if you did the original review I think its fine for me to ack the actual changes made [08:55] it does - bounce them to me for +1 [08:56] lifeless: so to confirm, I'll do a review of each thread and make the tweaks requested so far and my own [08:57] lifeless: you'll then approve the final result [08:57] i.e. review [08:57] and merge to bzr.dev [08:57] I'll approve, I'm happy for you to do the merges [08:57] :-) [08:58] the less I do until I finish the weave_store removal the better; I'm a single point of effort at the moment [08:58] np - I agree [08:59] check seems happy now (though I'm sure I have some tests to update :P) [09:00] * igc dinner [09:08] spiv: one reason knit reconcile is slow [09:08] spiv: it does list_dir() of the knits tree on every loop [09:08] lifeless: ouch [09:08] len(weave_store) -> much IO [09:09] Its the general side effect of len being unclear about implications [09:09] don't worry, I'm deleting the code :P [09:10] Deleting code is a wonderful thing. [09:10] * spiv heads off for a swim [09:25] Hello. I upgraded to 1.5 and bzr+ssh is broken. I keep getting "The server's host key is not cached in the registry": http://pastebin.com/d52c7ea5b [09:26] Where _is_ the registry? :) [09:28] on linux, ~/.ssh/host_keys I think [09:28] here's the Python traceback in case it's relevant: http://pastebin.com/d17386e [09:29] 'registry' is a bit of a vague term, unless its referring to windows, where it may well be in the registry somewhere ( the registry is a windows configuration database) [09:29] I don't see anything in the actual Windows registry [09:29] the install log didn't say it was doing anything in there anyways [09:30] In the previous version I was using, the host keys were in C:\Documents and Settings\user\Application Data\bazaar\2.0\ssh_host_keys [09:31] I'm afraid I don't know enough about windows ssh stuff these days to help you much :( [09:31] is it possible the server's host key changed after the recent ssl issue on debian machines? [09:32]