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