=== mw is now known as mw|out [01:56] jelmer: hi [01:57] schierbeck: hi [01:57] shit, i'm high as hell [01:57] these two american dudes are subverting me [01:57] they managed to get hold of a bong [01:58] now they're trying to take it out on me [01:58] sorry about the rant [02:02] ......... [02:04] lifeless: Was it just delayed or am I confused? [02:04] Peng: ... indeed [02:10] abentley: was what delayed? [02:11] find_text_key_references [02:11] I sent it in first [02:12] Okay, I was confused earlier, and thought I needed to look for [MERGE] _generate_text_key_index [02:12] It appears I haven't received any email about find_text_key_references [02:14] Gack! [02:14] First time I try to push the pack repo, and I get an error! [02:15] lifeless: Okay, found it. [02:15] It got marked superseded. [02:15] Which is my bug, not your fault. [02:15] bzr: ERROR: Could not understand response from smart server: ('error', "") [02:19] Woah! bzr serve is still running. [02:21] * Peng pokes lifeless. [02:21] Seems it's a NotImplementedError. [02:22] * Peng wanders off. [02:25] server's .bzr.log: http://paste.pocoo.org/show/10721/ [02:25] * Peng wanders off. === Verterok is now known as Verterok_ [02:43] * Peng pushes over sftp. [02:44] * Peng wanders off. [02:54] * beuno is playing around with bug #162264 and woders if "Transfer phase" isn't better then "Fetch phase" considering it uses the same for push/pull. Hacking around to display different things for each seems like an overkill [02:54] Launchpad bug 162264 in bzr "Push progress bar shouldn't say "Fetch..."" [Undecided,New] https://launchpad.net/bugs/162264 [03:11] Peng: I have a faster reconcile patch -> list [03:12] Peng: pack reconcile on monday I hope [03:16] What about this traceback? [03:17] * Peng wanders off. === bigdo1 is now known as bigdog [05:22] I'm playging with bzrlib.merge3, I don't get the same merge as GNU diff3. Anyone can tell what kind of differences to expect? === keir__ is now known as keir [05:28] YGingras: I believe our merging is based on Codeville's merge algorithm which is a bit more intelligent [05:29] igc: you don't seem to have the "|||||||" section when there is a conflict [05:29] any way to change the labels? [05:30] I'm not sure if it's packaged separately to "bzrlib.merge3" or just included within it. abentley can tell you the details [05:30] no idea sorry [05:30] ok, I found the lables [05:31] YGingras, you can get that with --show-base i think [05:31] print "".join(m.merge_lines(base_marker="|||||||")) [05:32] this gets me more or less the same stuff [05:32] poolie: I'm integrating with the API only, I don't use bzr (yet?) [05:33] YGingras: diff3 and merge3 used in that way don't minimize conflicts, because minimizing conflicts destroys the correlation between the base and the conflicted region [05:34] abentley: but the diff is much easier to read [05:35] maybe try without base and call with the base when there are conflicts anyway [05:35] that should be done on a hunk by hunk basis [05:35] humm I won't sleep early tonight [05:36] No, you're not getting what I mean. [05:36] showing the base will not cause a merge to conflict when it would otherwise not conflict. [05:36] But it will make the conflict regions longer than they have to be. [05:36] oh [05:37] btw, long time no see. [05:37] so, the only non-crap solution is visual side-by-side? [05:37] abentley: indeed : ) [05:37] Visual side-by-side will have the same issue if you're showing the base. [05:38] abentley: but you can hightlight what is a conflict and what is context with the base [05:39] kdiff3 has a not too confusing color code [05:39] Well, just be aware that in some places you'll have the base in conflict with THIS and OTHER, while THIS and OTHER are in harmony. [05:41] Personally, I'll take a merge3 with minimized conflicts over side-by-side any day. [05:41] abentley: this is for a wiki, most of the time this should be easy to merge anyway but I plan full-namespace branching later on: this one will require good merge and conflict resolve gui [05:41] Yes, a colleague pointed out your wiki. [05:41] abentley: you mean with the makers? [05:42] since I force long lines spliting, markers are no too bad [05:42] I'm not sure what you mean. [05:42] Are you asking what I mean by merge3? [05:42] it was the complete hell when I allowed one line per para [05:43] abentley: yes [05:43] I mean, by merge3 you mean merge with conflicts makers? [05:44] by merge3, I mean the kind of merge output that Bazaar gives by default. [05:44] Yes, with conflict markers. [05:44] and without the base [05:44] Right, and with conflict reduction enabled. [05:45] So that only lines that differ between THIS and OTHER can conflict. [05:46] abentley: asside from the fact that GNU diff3 defaults to show the base, any note worthy differences in the acutal merge? [05:47] can diff3 even hide the base? [05:47] We use a sequence matcher that finds the longest common subsequence, instead of the longest common substring. [05:47] YGingras: Sure. Remember Arch? [05:47] yes [05:47] It used diff3? [05:47] Yes. [05:48] I don't remember the exact commandline it used. [05:48] I'll dig the source [05:49] thanks for the pointers [05:49] No problem. [05:50] I keep you posted, bzrlib will be the fallback if I can't find diff3, or should it be the other way around? [05:51] I think either is a worthy choice. We didn't want a dependency on diff3, so we built our own. [05:51] the magic spell is: diff3 -E -m my.txt base.txt your.txt [06:39] can I know if there was a conflict or do I have to parse the merge? === keir__ is now known as keir [06:46] oh, it's "base, my, your", not "my, base, your". No wonder I didn't get the right merge... [06:47] but the command line is "my, base, your". You guys are playing tricks to the API users? ; ) [06:50] and you flipped it the otherway around for merge_lines() [06:53] Just making sure you're paying attention ;) [06:55] would you merge a patch straightening this up a bit? [06:55] * YGingras imagine the havok [07:09] is this the right error message: exceptions.TypeError: sequence item %zd: expected string, %.80s found === keir_ is now known as keir [07:24] anyone sees what I did wrong: http://pylonshq.com/pasties/553 [07:28] seems to be a proble with workingenv [07:28] virtualenv seems to be just fine [07:32] YGingras: we'd definately consider a patch making things more clear in the api [07:35] ok, i'm signing off [07:35] lifeless: that will silently break all existing code [07:36] YGingras: we have good support for versioning API's. See our developers documentation and the symbol_versioning module. [07:36] poolie: night! [07:36] poolie: I don't have transport to john's thing ... [07:36] and therefore you're wanting transport, or you're not going? [07:37] lifeless: I'll see what it involves. What do you prefer? (my, old, your)? [07:37] it could go either way :) [07:37] YGingras: I haven't looked closely enough at the situation to tell why its unclear. [07:38] YGingras: e.g. maybe it just needs a better docstring, or - whatever. [07:38] lifeless: the order change gratuitouly from one call to the other [07:38] I'd pick one order and stick to it [07:39] YGingras: that sounds fair to me [07:39] instead of requiring to read the docstring for every single method call [07:39] anyhow, I don't have an opinion [07:39] on the 'right' order yet [07:39] I think left/right/base makes most sense [07:39] (my, old, your) is easier to remember, there is a mnemonic [07:40] but I forget what is was... : \ [07:40] because 2-way is left/right only [07:40] so this makes three-way an extension [07:40] OTOH for diff you have old/new so base/left/right might be better [07:40] :) [07:41] no help at all I realise :) [07:41] "diff3 MINE OLDER YOURS" " [07:41] You can remember the order of the arguments by noting that they are in [07:41] alphabetical order. [07:41] " [07:41] ok, the mnemonic is crap [07:42] I'm off for family time [07:42] ciao [07:42] later [08:08] * igc food [08:22] lifeless: Now that packs are in bzr.dev, is your repository branch abandoned? [08:22] * Peng wanders off. [09:07] Peng: no, it has various not-yet-merged improvements === fredp-afk is now known as fredp === quicksil1er is now known as quicksilver === cfbolz_ is now known as cfbolz === weigon__ is now known as weigon === mw|out is now known as mw === cprov is now known as cprov-lunch === mwhudson_ is now known as mwhudson [14:59] hi [15:00] bug: try this: [15:00] pinot@pc-pinot:~/tmp$ mkdir Thèse [15:00] pinot@pc-pinot:~/tmp$ cd Thèse/ [15:00] pinot@pc-pinot:~/tmp/Thèse$ bzr init . [15:00] pinot@pc-pinot:~/tmp/Thèse$ echo foo > bar [15:00] pinot@pc-pinot:~/tmp/Thèse$ bzr add . [15:00] added bar [15:00] pinot@pc-pinot:~/tmp/Thèse$ bzr commit [15:01] bzr seems unable to commit in a directory with non-ascii character. [15:02] Works for me [15:02] LeoNerd: devel or last stable version? [15:03] I have debian's 0.92.0 [15:03] TeXitoi, what error are you getting? traceback? [15:03] Bazaar (bzr) 0.92.0.candidate.1 [15:03] yes [15:03] From debian/unstable [15:04] maybe it's bug #63324? [15:04] Launchpad bug 63324 in bzr "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character" [Medium,Confirmed] https://launchpad.net/bugs/63324 [15:04] or #77533 [15:04] bug #77533 [15:04] Launchpad bug 77533 in bzr "bzr crashes with invalid filenames" [Low,Confirmed] https://launchpad.net/bugs/77533 [15:06] http://pastebin.com/m60424600 [15:06] http://paste.leonerd.org.uk/?show=1866 <== output from my successful run [15:06] What's $LANG set to..? Mine has en_GB.UTF-8 [15:07] see the pastebin [15:07] fr_FR.UTF-8 [15:09] TeXitoi, you're not running Cygwin, are you? [15:09] no [15:09] debian testing [15:10] It work with bzr ci -m "bla" but not with bzr ci [15:10] LeoNerd: try [15:10] echo foo > bar [15:10] TeXitoi, would you mind filing a bug with all this information? [15:10] bzr ci [15:11] Ahh... yes [15:11] beuno: If you think the bug is not yet reported, sure [15:11] Mmm [15:11] edit_commit_message_encoded() in the stack trace [15:11] Whereas, ci -m "message" doesn't [15:11] TeXitoi, it does sound like an unreported bug, yes [15:11] I need to create a lanchpad account for that? [15:12] * TeXitoi hates creating accounts [15:12] I might be wrong, but the worst that can happen is it gets marked as a duplicate [15:12] TeXitoi, it's a one time thing :p [15:13] beuno: I know, but I don't like to use non free software [15:13] I'll ask a friend that have an account [15:15] TeXitoi, I can file it for you, I'll try and reproduce it here [15:17] TeXitoi, I can reproduce it perfectly, I'll file it now [15:18] nop [15:18] TeXitoi, nop? [15:18] or it will be duplicated [15:18] oh, you're filing it already? [15:18] A friend is doing the bug report [15:18] I think it's bug 84403 [15:18] Launchpad bug 84403 in firefox "Firefox crashes unexpectedly (dup-of: 73536)" [Undecided,Incomplete] https://launchpad.net/bugs/84403 [15:18] Launchpad bug 73536 in firefox "MASTER Firefox crashes on instant X server shutdown" [Medium,In progress] https://launchpad.net/bugs/73536 [15:19] ghaa I meant 84043 [15:19] ghaa I meant bug 84043 [15:19] Launchpad bug 84043 in bzr "commit fails to invoke external editor in non-ascii directory" [Medium,Confirmed] https://launchpad.net/bugs/84043 [15:19] vila, that sounds about right [15:19] traceback looks pretty similar [15:20] please add a comment inside that bug instead of creating a new one if it's still possible [15:22] Oh, and the obvious work-around is to not use accented letters in the directory name (TeXitoi) [15:24] vila: I know ;-) [15:25] TeXitoi: ok, just wanted to be sure. I'm pretty sure I've seen the subject discussed recently so rest assured that the problem is taken care of [15:26] vila: are you sure that it must be a comment to that bug? [15:26] it seems closer, but the trace is much longer in my case [15:27] the important part is the end so if they match you can be pretty sure it's the same root cause, if you're unsure file a new bug but mention the old one so that anyone fixing one will not miss the other [15:27] ok [15:27] it will be a comment [15:31] or not finaly, but with ref : https://bugs.launchpad.net/bzr/+bug/163123 [15:31] Launchpad bug 163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New] [16:06] New bug: #163123 in bzr "Crash when repository is in a directory with non ascii characters" [Undecided,New] https://launchpad.net/bugs/163123 [16:27] lifeless: so, did you find enlightenment on the right order in your sleep? [16:32] YGingras_: lifeless is in Australia, so won't be online for another couple hours [16:32] (he just got back, so he may still be jetlagged and come online a bit earlier than usual) [16:32] YGingras_: you were here yesterday talking about using the code for a wiki, right? [16:33] jam-laptop: oh, I'll wait a bit then : ) Yes, I do use the code in the wiki now [16:33] By the way, while git may be fast, I found that spawning it in a pipe isn't all that, at least I was working on a converter, and spawning it 16 times to set up a branch put data in, etc was quite slow [16:33] the 'git fast-import' stuff was pretty quick, though [16:34] So it might just be process spawn overhead on this machine === jam-laptop is now known as jam [16:34] YGingras_: I can try to help. I'm not sure what the "right order" you are talking about (I don't see it in your earlier conversation.) [16:35] what wiki is it, by the way [16:35] jam, in merge3.py, many function calls take the 3 params (mine, old, yours) [16:35] jam: but they keep changing the orger [16:35] order [16:36] so, we think that a bit of uniformito might help [16:36] jam: Gazest: http://ygingras.net/gazest [16:37] well, if you use our code, can you at least put up our name on the About section :) [16:38] jam: sure : ) [16:38] in merge3.py I only see 2 places that a user would call [16:38] Merge3(base, a b) [16:38] and Merge3.merge_lines() [16:38] Though I agree that merge_lines(name_base, name_a, name_b) would probably be better [16:39] I think it is expected that you would explicitly call the parameters [16:39] so [16:39] merge_lines(name_base='foo', name_a='a', name_b='b', ...) [16:39] In which case you can supply them in any order. [16:39] jam: the command line interface has yet another order [16:40] YGingras_: the command line order is because that is what diff3 and other tools expect [16:40] so better to be compatible [16:40] that way you can be a 'drop-in' replacement [16:40] But I think "base, mine, other" is probably a more logical layout [16:40] I suppose we could go either way [16:41] though if we call them 'a' and 'b' it is a bit odd [16:41] 'a', 'base', 'b' [16:41] If they were renamed it would probably be okay [16:41] I think we generaly use [16:41] THIS, BASE, OTHER [16:41] jam: no order is really good and mnemonic but the diff3 one has been with us for so long that we assume it [16:41] which makes it clearer anyway. [16:42] I think the problem is calling them 'a' and 'b' doesn't give you a hint about them [16:42] jam: yeah, a rename would probably be in order [16:44] hmm... it seems like python merge3.py isn't really meant to be a diff3 substitute [16:44] since it always annotated [16:44] annotates [16:44] probably more for Aaron (who wrote the code) to see what was going on [16:45] the api is ok [16:45] I do merge = list(m3.merge_lines(MY, YOUR, OLD, MARKERS[0], MARKERS[2], MARKERS[-1])) [16:46] which gives me mostly the same stuff as diff3 -E -m [16:47] right === jam is now known as jam-lapto [16:50] YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6 [16:50] How do you populate the 'rev_id' ? [16:50] At least it seems like you are using the number 6, but there are only 3 revisions === jam-lapto is now known as jam [16:51] silly chat program... [16:51] anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6 [16:51] it says that it might differ [16:51] but it seems to be the most up-to-date version [16:52] jam-lapto: YGingras_: when going to pages like http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/hist?rev_id=6 [16:52] [10:50am] jam-lapto: How do you populate the 'rev_id' ? [16:52] [10:50am] jam-lapto: At least it seems like you are using the number 6, but there are only 3 revisions [16:52] [10:51am] You are now known as jam. [16:52] [10:51am] jam: silly chat program... [16:52] [10:51am] jam: anyway, When you look at: http://gazdemo.ygingras.net/wiki/Files/Plotgui.py/rev/6 [16:52] [10:51am] jam: it says that it might differ [16:52] [10:51am] jam: but it seems to be the most up-to-date version [16:52] I was trying to go to the history page to see what the current version is [16:52] and it was pretty unclear [16:52] that I was already at the most recent [16:53] jam: just wave me when abentley and lifeless are around; we'll see if a patch is really in order [16:53] sure [16:54] I'm guessing that our "maintain backwards compatibility" general rule will outweigh the benefit of renaming... but maybe not [16:56] "?rev_id=6" is an artefact of Routes memory [16:57] I'm using Routes as the dispatcher and it recalls stuff so I can do "< a href=%s..." % url_for(action="edit") [16:57] and forget about the other params [16:57] but once in a while, it recalls too much and that clutters the URLs [16:58] jam: yeah I'm not sure about the patch either but lifeless seems to imply that you have a super flexible versionning system that will brevent any breakage [16:58] * YGingras__ shrugs [16:59] its more about having people like you who might be using it outside of the scope of our little project :) [16:59] and not wanting to cause you grief because of arbitrary parameter renaming === YGingras__ is now known as YGingras [17:04] I hate my ISP [17:29] jam: did by remarks on routes memory made it through? [17:37] YGingras: "that sometimes it remembers too much" yes [17:37] YGingras__: but once in a while, it recalls too much and that clutters the URLs [17:37] good : ) [17:47] jam: ping [17:47] hi vila [17:48] hi :) I just run the bzr test suite and get 31 errors related to gtk (up to date from http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/) [17:48] but if I run bzr test-gtk I got: Ran 63 tests in 2.896s [17:49] I thought test-gtk was running all gtk tests >-/ [17:49] by the way they all failed with: 'int' object is not callable [17:50] with a traceback ending with: file_label = gtk.Label(_('Files')) [17:50] Does that ring a bell or should I investigate ? [17:54] hmmm, I smell a gtk initialization pb again... [17:59] hmm, I bet cmd_gselftest.run taking care of sys.getdefaultenconding() may have something to do with it... [18:02] jam: bzr selftest --no-plugins works and bzr selftest gtk works too :-) They just can't agree when running together. [18:02] vila: something is overwriting _ [18:02] and gtk sets it as a builtin [18:02] I'm guessing that we have code which does [18:02] _, foo, bar = ... [18:03] hmm [18:03] import gtk [18:03] import builtins [18:03] In the global name space ? [18:03] del builtins._ [18:03] :) [18:04] import __builtin__ [18:04] >>> import __builtin__ [18:04] >>> import gtk [18:04] >>> __builtin__._ [18:04] Traceback (most recent call last): [18:04] File "", line 1, in [18:04] AttributeError: 'module' object has no attribute '_' [18:04] >>> print _ [18:04] Traceback (most recent call last): [18:04] File "", line 1, in [18:04] NameError: name '_' is not defined [18:05] yeah, I'm not seeing where it is actually triggering yet [18:06] it might be gobject or pango [18:06] pango is pretty likely [18:07] >>> import pango [18:07] >>> __builtin__._ [18:07] Traceback (most recent call last): [18:07] File "", line 1, in [18:07] AttributeError: 'module' object has no attribute '_' [18:07] >>> print _ [18:07] Traceback (most recent call last): [18:07] File "", line 1, in [18:07] NameError: name '_' is not defined [18:07] >>> [18:08] I don't see anything in the bzr-gtk code which is doing it [18:08] maybe it is a side effect of creating a window? [18:08] I'm trying to find it [18:09] it gets put in builtins right ? [18:09] bleh [18:09] as near as I can tell [18:09] ok try this [18:09] it certainly isn't being put into the local namespace each time [18:09] create a fake module [18:09] (Pdb) _ [18:09] > [18:09] put that in sys.modules [18:09] jam: check in __builtin__ [18:09] (Pdb) import __builtin__ [18:09] (Pdb) __builtin__._ [18:09] > [18:09] yep [18:09] it is in __builtin__ [18:10] jam: don't add pdb to the equation [18:10] anyhow, put a module which is a regular object with setattr hooked to pdb [18:10] import gettext [18:10] in sys.modules['__builtin__'] [18:10] I'm pretty sure that gettext doesn't do it automatically [18:10] but I'll check that too [18:10] it will need to hold a reference to the original __built__ [18:10] and answer getattr from that [18:10] if you do that, then when gtk setattrs _ on __builtin__, it should trap [18:10] and you can get a backtrace [18:11] woot, my string.find bug has been fixed [18:11] so in about 5 years we can use it [18:12] http://bugs.python.org/issue1259 [18:14] later, wow calls [18:15] later, dinner with friends calls :) [18:16] jam: I'll read the log if you find any fix or work-around (not urgent anyway) [18:16] vila: sure, I'm trying to track it down [18:16] but yeah, having a __builtins__._() is not a great way to do i18n [18:17] but it also means we should change our code base to avoid the '_' object [18:17] lifeless: have fun [18:17] It seems, though, that doing __get_attribute__ seems to cause problems with __import__ not being found :( [18:17] still looking [18:21] What about using 'i18n' instead of '_' ? [18:21] I would be happy enough with that, it just isn't the standard 'gettext()' way [18:21] and it just happens that gettext conflicts [18:21] with a common python idiom [18:21] of using '_' as a "I don't care about this" variable [18:21] (and as a last action variable) [18:21] yup, perl heritage :) [18:22] trying to wrap __builtin__ I'm still getting "has no member __import__" ... [18:22] which breaks everything [18:24] hmm.. it seems to have triggered by the time plugins have imported [18:24] which is *before* gtk should be imported [18:24] maybe in 'gettext.install('olive-gtk')' ? [18:24] yep [18:24] gettext.install does bad things [18:27] vila: 'grep -rnI "\<_\>" bzrlib' shows it being used in quite a few places in our codebase [18:27] dirstate.py [18:27] fetch.py [18:27] and a few others [18:32] If we have 3 programmers constantly working on the same project (for instance a new project) and we are a kind of jack of all trades, can bzr still help us ? [18:34] Zenom, absolutely, it does the same (and more) as other VCS [18:35] beuno: i guess my concern is like 2 of us could be working on the same code [18:35]