| === mw is now known as mw|out | ||
| schierbeck | jelmer: hi | 01:56 |
|---|---|---|
| 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:57 |
| schierbeck | now they're trying to take it out on me | 01:58 |
| schierbeck | sorry about the rant | 01:58 |
| Peng | ......... | 02:02 |
| abentley | lifeless: Was it just delayed or am I confused? | 02:04 |
| jelmer | Peng: ... indeed | 02:04 |
| lifeless | abentley: was what delayed? | 02:10 |
| abentley | find_text_key_references | 02:11 |
| lifeless | I sent it in first | 02:11 |
| 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:12 |
| Peng | Gack! | 02:14 |
| Peng | First time I try to push the pack repo, and I get an error! | 02:14 |
| 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:15 |
| Peng | Woah! bzr serve is still running. | 02:19 |
| * Peng pokes lifeless. | 02:21 | |
| Peng | Seems it's a NotImplementedError. | 02:21 |
| * Peng wanders off. | 02:22 | |
| Peng | server's .bzr.log: http://paste.pocoo.org/show/10721/ | 02:25 |
| * Peng wanders off. | 02:25 | |
| === Verterok is now known as Verterok_ | ||
| * Peng pushes over sftp. | 02:43 | |
| * Peng wanders off. | 02:44 | |
| * 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 | 02:54 |
| lifeless | Peng: I have a faster reconcile patch -> list | 03:11 |
| lifeless | Peng: pack reconcile on monday I hope | 03:12 |
| Peng | What about this traceback? | 03:16 |
| * Peng wanders off. | 03:17 | |
| === bigdo1 is now known as bigdog | ||
| 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:22 |
| === keir__ is now known as keir | ||
| igc | YGingras: I believe our merging is based on Codeville's merge algorithm which is a bit more intelligent | 05:28 |
| 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:29 |
| 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:30 |
| poolie | YGingras, you can get that with --show-base i think | 05:31 |
| YGingras | print "".join(m.merge_lines(base_marker="|||||||")) | 05:31 |
| 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:32 |
| 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:33 |
| YGingras | abentley: but the diff is much easier to read | 05:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| YGingras | abentley: but you can hightlight what is a conflict and what is context with the base | 05:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| YGingras | abentley: yes | 05:43 |
| YGingras | I mean, by merge3 you mean merge with conflicts makers? | 05:43 |
| 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:44 |
| abentley | So that only lines that differ between THIS and OTHER can conflict. | 05:45 |
| YGingras | abentley: asside from the fact that GNU diff3 defaults to show the base, any note worthy differences in the acutal merge? | 05:46 |
| 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:47 |
| abentley | I don't remember the exact commandline it used. | 05:48 |
| YGingras | I'll dig the source | 05:48 |
| YGingras | thanks for the pointers | 05:49 |
| abentley | No problem. | 05:49 |
| 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:50 |
| 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 | 05:51 |
| YGingras | can I know if there was a conflict or do I have to parse the merge? | 06:39 |
| === keir__ is now known as keir | ||
| YGingras | oh, it's "base, my, your", not "my, base, your". No wonder I didn't get the right merge... | 06:46 |
| YGingras | but the command line is "my, base, your". You guys are playing tricks to the API users? ; ) | 06:47 |
| YGingras | and you flipped it the otherway around for merge_lines() | 06:50 |
| fullermd | Just making sure you're paying attention ;) | 06:53 |
| YGingras | would you merge a patch straightening this up a bit? | 06:55 |
| * YGingras imagine the havok | 06:55 | |
| YGingras | is this the right error message: exceptions.TypeError: sequence item %zd: expected string, %.80s found | 07:09 |
| === keir_ is now known as keir | ||
| YGingras | anyone sees what I did wrong: http://pylonshq.com/pasties/553 | 07:24 |
| YGingras | seems to be a proble with workingenv | 07:28 |
| YGingras | virtualenv seems to be just fine | 07:28 |
| lifeless | YGingras: we'd definately consider a patch making things more clear in the api | 07:32 |
| poolie | ok, i'm signing off | 07:35 |
| YGingras | lifeless: that will silently break all existing code | 07:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| lifeless | I'm off for family time | 07:42 |
| lifeless | ciao | 07:42 |
| YGingras | later | 07:42 |
| * igc food | 08:08 | |
| Peng | lifeless: Now that packs are in bzr.dev, is your repository branch abandoned? | 08:22 |
| * Peng wanders off. | 08:22 | |
| lifeless | Peng: no, it has various not-yet-merged improvements | 09:07 |
| === 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 | ||
| TeXitoi | hi | 14:59 |
| 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:00 |
| TeXitoi | bzr seems unable to commit in a directory with non-ascii character. | 15:01 |
| LeoNerd | Works for me | 15:02 |
| TeXitoi | LeoNerd: devel or last stable version? | 15:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| TeXitoi | see the pastebin | 15:07 |
| TeXitoi | fr_FR.UTF-8 | 15:07 |
| beuno | TeXitoi, you're not running Cygwin, are you? | 15:09 |
| TeXitoi | no | 15:09 |
| TeXitoi | debian testing | 15:09 |
| 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:10 |
| 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:11 |
| * 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:12 |
| 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:13 |
| beuno | TeXitoi, I can file it for you, I'll try and reproduce it here | 15:15 |
| beuno | TeXitoi, I can reproduce it perfectly, I'll file it now | 15:17 |
| 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:18 |
| 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:19 |
| vila | please add a comment inside that bug instead of creating a new one if it's still possible | 15:20 |
| vila | Oh, and the obvious work-around is to not use accented letters in the directory name (TeXitoi) | 15:22 |
| TeXitoi | vila: I know ;-) | 15:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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] | 15:31 |
| 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:06 |
| YGingras_ | lifeless: so, did you find enlightenment on the right order in your sleep? | 16:27 |
| 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:32 |
| 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:33 |
| jam-laptop | So it might just be process spawn overhead on this machine | 16:34 |
| === jam-laptop is now known as jam | ||
| 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:34 |
| 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:35 |
| YGingras_ | so, we think that a bit of uniformito might help | 16:36 |
| YGingras_ | jam: Gazest: http://ygingras.net/gazest | 16:36 |
| jam | well, if you use our code, can you at least put up our name on the About section :) | 16:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| YGingras_ | which gives me mostly the same stuff as diff3 -E -m | 16:46 |
| jam | right | 16:47 |
| === jam is now known as jam-lapto | ||
| 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:50 |
| === jam-lapto is now known as jam | ||
| 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:51 |
| 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:52 |
| 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:53 |
| jam | I'm guessing that our "maintain backwards compatibility" general rule will outweigh the benefit of renaming... but maybe not | 16:54 |
| YGingras__ | "?rev_id=6" is an artefact of Routes memory | 16:56 |
| 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:57 |
| 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:58 | |
| 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 | 16:59 |
| === YGingras__ is now known as YGingras | ||
| YGingras | I hate my ISP | 17:04 |
| YGingras | jam: did by remarks on routes memory made it through? | 17:29 |
| 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:37 |
| vila | jam: ping | 17:47 |
| jam | hi vila | 17:47 |
| 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:48 |
| 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:49 |
| vila | with a traceback ending with: file_label = gtk.Label(_('Files')) | 17:50 |
| vila | Does that ring a bell or should I investigate ? | 17:50 |
| vila | hmmm, I smell a gtk initialization pb again... | 17:54 |
| vila | hmm, I bet cmd_gselftest.run taking care of sys.getdefaultenconding() may have something to do with it... | 17:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| jam | yeah, I'm not seeing where it is actually triggering yet | 18:05 |
| jam | it might be gobject or pango | 18:06 |
| jam | pango is pretty likely | 18:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| lifeless | woot, my string.find bug has been fixed | 18:11 |
| lifeless | so in about 5 years we can use it | 18:11 |
| lifeless | http://bugs.python.org/issue1259 | 18:12 |
| lifeless | later, wow calls | 18:14 |
| vila | later, dinner with friends calls :) | 18:15 |
| 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:16 |
| 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:17 |
| 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:21 |
| jam | trying to wrap __builtin__ I'm still getting "has no member __import__" ... | 18:22 |
| jam | which breaks everything | 18:22 |
| 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:24 |
| 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:27 |
| 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:32 |
| beuno | Zenom, absolutely, it does the same (and more) as other VCS | 18:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| beuno | you can write up some tests to ake sure nothing breaks trunk before committing to it | 18:46 |
| === cprov-lunch is now known as cprov-away | ||
| === fo1 is now known as fog | ||
| === fo1 is now known as fog | ||
| 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) | 22:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!