[00:10] <lifeless> :( search selftest is failing
[00:10] <lifeless> jelmer: AttributeError: '_LeafNode' object has no attribute 'items'
[00:11] <jelmer> lifeless: :-( IIRC it was passing a couple of weeks ago, I did a Debian upload early March
[00:12] <jelmer> lifeless: what version of bzr are you using? It passes here with bzr.dev
[00:15] <lifeless> 2.2.4-0ubuntu1
[00:18] <jelmer> hmm
[00:18] <jelmer> the error looks vaguely familiar; it's likely somebody fix it in bzr.dev but I don't see any relevant NEWS items
[00:19] <jelmer> Given your comment about commitfromnews I guess you might have been doing the same thing..
[00:20] <lifeless> I looked up whether you use oo or ö for your name in bzr's NEWS
[00:21] <lifeless> and noticed it was in multiple files now
[00:21] <lifeless> which is wh I mentioned commitfromnews
[00:23] <jelmer> ah
[00:23] <jelmer> lifeless: thanks for the review and merge
[00:27] <lifeless> my copy of bzr.dev does this:
[00:27] <lifeless>  ~/source/baz/bzr.dev/bzr selftest plugins.search
[00:27] <lifeless> 'module' object has no attribute '_parse_into_chk'
[00:27] <lifeless> I'll pull in a sec
[00:29] <lifeless> https://bugs.launchpad.net/bzr/+bug/707075/comments/27
[19:09] <glyph> So, the very first time I try to integrate bzr into an official process for Twisted: https://bugs.launchpad.net/bzr/+bug/769973
[19:10] <glyph> getting the branch works normally, just not in my shared repository.
[19:33] <mgz> bug 485601?
[19:34] <mgz> poke jelmer for more info.
[19:36] <mgz> comment #25 there may be useful to you.
[19:36] <mgz> ...and comment #26 is from you.
[19:43] <glyph> Does 'in progress' mean that he figured out the cause?
[19:43] <mgz> it sort of implies it, but I don't know more.
[19:45] <jelmer> hi glyph, mgz
[19:45] <jelmer> Yes, I have figured out the cause. It's basically the thing I'll be working on next week.
[19:46] <jelmer> it's the blocker for bzr-svn 1.1.0
[19:49]  * jelmer hops on a train
[19:51] <glyph> excellent! thanks, jelmer
[20:08] <glyph> Okay, now https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/769992 is gumming up the same process.
[21:51] <lifeless> jelmer:  bzr st
[21:51] <lifeless> 'module' object has no attribute '_parse_into_chk'
[21:51] <lifeless> 'module' object has no attribute '_parse_into_chk'
[21:51] <lifeless> /home/robertc/.bazaar/plugins/loom/formats.py:57: DeprecationWarning: __builtin__.type.register_format was deprecated in version 2.4.0.
[21:51] <lifeless>   map(_mod_branch.BranchFormat.register_format, branch_formats)
[21:51] <lifeless> type object 'BzrDirFormat' has no attribute 'register_control_format'
[21:51] <lifeless> 'module' object has no attribute '_parse_into_chk'
[21:51] <lifeless> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_parse_into_chk'
[21:51] <lifeless> jelmer: tip bzr.dev
[21:53] <jelmer> lifeless: that should be fixed with newer revisions of bzr-loom
[21:54] <jelmer> lifeless, the deprecation warning / 'register_control_format' thing I mean
[21:54] <jelmer> I'm not sure about _parse_into_chk
[21:55] <jelmer> lifeless: Can you reproduce this with --no-plugins as well?
[21:57] <lifeless> yes
[21:57] <lifeless> and after doing a make clean
[21:57] <lifeless>   File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/btree_index.py", line 1596, in <module>
[21:57] <lifeless>     _gcchk_factory = _btree_serializer._parse_into_chk
[21:57] <lifeless> AttributeError: 'module' object has no attribute '_parse_into_chk'
[21:57] <lifeless> bzr 2.4.0dev2 on python 2.6.6 (Linux-2.6.35-28-generic-x86_64-with-
[21:57] <lifeless>     Ubuntu-10.10-maverick)
[21:58] <lifeless> arguments: ['/home/robertc/bin/bzr', 'st', '--no-plugins']
[22:01] <lifeless> ah
[22:01] <lifeless> wrong dir
[22:01] <jelmer> I can't reproduce it, neither with nor without compiled extensions and current tip
[22:01] <jelmer> ah
[22:02] <lifeless> I was rebuilding bzr.dev, but running from bzr-test-fixes
[22:02] <lifeless> doh ;)
[22:03] <lifeless> jelmer: robertc@lifeless-64:~/source/baz/plugins/loom/trunk$ bzr st
[22:03] <lifeless> type object 'BzrDirFormat' has no attribute 'register_control_format'
[22:03] <lifeless> remaining fallout
[22:04] <lifeless> ah
[22:04] <lifeless> cvs
[22:04] <lifeless> done
[22:04] <jelmer> great
[22:07] <lifeless> jelmer: did my review of your fixup branch make sense ?
[22:07] <lifeless> jelmer: also I meant to suggest, but forgot, that perhaps some folk would want to add in ids via a regex
[22:07] <jelmer> lifeless, yes, thanks
[22:08] <jelmer> I'll make a few improvements
[22:08] <lifeless> jelmer: though thats clearly a future enhancement
[22:08] <jelmer> yeah, I had that in mind too. That's what Samba does at the moment.
[22:08] <jelmer> train arriving.. back later
[22:50] <mgz> jelmer: the twisted guys also filed bug 769992 if you were off for that bit of the chat.
[22:52] <lifeless> mgz: whats the story for py3 and you ?
[22:53] <mgz> I have a build of their trunk around, but don't use it for day to day programming.
[22:53] <lifeless> mgz: I'd like to talk about subunit, unicode and bytes.
[22:53] <mgz> surething.
[22:53] <lifeless> this branch
[22:53] <lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/subunit/py3
[22:54] <lifeless> has tres initial work fixed up and additional work from me
[22:54] <lifeless> we have code like this
[22:54] <lifeless> :
[22:54] <lifeless> -        protocol.readFrom(StringIO(output))
[22:54] <lifeless> which I'm proposing to change to
[22:54] <lifeless> -        protocol.readFrom(BytesIO(output))
[22:55] <lifeless> because subunit defines a byte protocol not a string protocol; it shouldn't crash if someone shoves crap into it
[22:56] <lifeless> which any decode-before-processing approach would do
[22:56] <lifeless> do you see any interactions with windows code pages etc if I do this?
[22:56] <mgz> yeah, the meaning of StringIO has shifted a bit
[22:56] <lifeless> on 2.6 BytesIO will be StringIO
[22:56] <lifeless> on 3 io.BytesIO
[22:56] <mgz> I've always used it more as a file-like bytestream more than a text stream, in fact I don't think cStringIO does unicode at all
[22:57] <lifeless> https://code.launchpad.net/~lifeless/testtools/misc/ adds that to testtools
[22:57] <lifeless> cStringIO does unicode, but has a wonderful bug if you do cStringIO.StringIO(u"foooo")
[22:57] <lifeless> you then get to read the octets back out
[22:57] <mgz> the only real pain on windows is when the pipe happens to be pointing at a console
[22:57] <mgz> which generally it won't be for subunit
[22:58] <lifeless> in or out? or either ?
[22:58] <lifeless> also I'm again feeling motivated to bitch about the lack of startswith etc on bytes.
[22:58] <lifeless> WTF were they thinking/.
[22:59] <mgz> potentially both. there's a wide api that can be used, but generic code uses a bytes-only approach that does mbcs transcoding
[22:59] <lifeless> mgz: so, GIGO applies; if we get some pastiche of uncide + a jpeg or whatever in
[22:59] <lifeless> we should preserve it in subunit-filter
[23:00] <lifeless> mgz: I'm planning on saying 'we serialise by utf8 for backtraces'
[23:01] <mgz> I can't imagine many people will expect typing in a subunit stream to work at all, and printing junk to the console is just an annoyance.
[23:01] <lifeless> mgz: and for passing old-style backtraces (the [...] encoding) do a decode(error=replace) for things that need to be passed to python code
[23:03] <mgz> well, did subunit previously do anything special for non-ascii in tracebacks?
[23:03] <lifeless> it didn't matter
[23:03] <lifeless> py2
[23:04] <lifeless> you could pass ascii around and yawn
[23:04] <mgz> ah, so you just got whatever bytes you had anyway, and if it was junk it was junk.
[23:04] <lifeless> but remember all the headaches you had on testtools ?
[23:04] <mgz> yeah, I just wondered if you encoded anything
[23:04] <lifeless> I'm trying to fit in nicely with that :)
[23:04] <lifeless> theres some primitive stuff
[23:04] <mgz> so, just using utf-8 consistently will be like a bugfix, no?
[23:05] <lifeless> I think I can make that case
[23:05] <mgz> before you might get non-ascii in a traceback and not know what it is.
[23:05] <mgz> now with py3 it'll be utf-8 all the time.
[23:05] <lifeless> once I get over this rage about having to workaround useful functions being removed.
[23:06] <mgz> I wouldn't mind a pretty serious cut down of string methods if python had a good alternative for bytes-wrangling
[23:07] <mgz> but when I have to deal with microlanguages is one of the few times I find myself pining for perl
[23:09] <mgz> it's annoying how much python needs to be written to do something as basic as interpret a particular http header field correctly.
[23:10] <lifeless> yeah
[23:11] <mgz> the diff of the last few revs in that subunit branch looks fine to me.
[23:12] <lifeless> yeah, thats the easy mechanical
[23:12] <lifeless> now I'm into
[23:12] <lifeless>   File "/home/robertc/source/unittest/subunit/working/python/subunit/__init__.py", line 215, in lineReceived
[23:12] <lifeless>     cmd = cmd.rstrip(':')
[23:12] <lifeless> TypeError: Type str doesn't support the buffer API
[23:13] <mgz> you got split still?
[23:13] <mgz> that's a workable alternative idiom
[23:13]  * mgz checks
[23:14] <mgz> hm, that's just a confusing error message.
[23:15] <mgz> cmd = cmd.rstrip(_b(':')) would work, but maybe rearranging is preferable.
[23:18] <lifeless> yeah
[23:18] <lifeless> I've just tweeted all that ;)
[23:18] <lifeless> I really think the balance is wrong.
[23:23] <mgz> I think the py3k approach to strings is a bit last-decade.
[23:23] <mgz> ...or even two decades.
[23:24] <mgz> unicode-by-default was the motivating factor for the windows switch to 'wide' apis
[23:25] <LeoNerd> Except they did it in UCS-2
[23:25] <mgz> using typing to avoid injection attacks and limit transcoding seems more trendy these days.
[23:27] <mgz> ^so does Python, LeoNerd. or (in some ways) worse, UTF32
[23:28] <LeoNerd> UTF-32 / UCS-4 is fine
[23:28] <mgz> which is part of the complaint about extra overhead from some applications looking at porting currently.
[23:29] <LeoNerd> It gives constant-width lookup to any codepoint in the string.
[23:29] <LeoNerd> It's UTF-16 that's the killer.. all the bad points about UCS-4 (uses null bytes, inefficient for ASCII) combined with all the bad points about UTF-8 (variable-width encoding)
[23:29] <mgz> lots of things are just about moving bytes around, not doing much parsing on them, and the extra allocation hurts.
[23:30] <mgz> utf-16 most people don't handle astral characters properly anyway, so there's no extra parsing overhead
[23:30] <mgz> it's just sometimes, in ways nearly no one will notice, incorrect.
[23:31]  * maxb lols at "astral characters"
[23:31] <maxb> very apt. I like it
[23:31] <lifeless> python's build on ubuntu is 4-byte chars
[23:31] <lifeless> its -terrible-=
[23:31] <lifeless> want to know why bzr uses so much memory? dingdingdingding
[23:32] <mgz> yeah, and there aren't handy ways of using more compact data structures in python when that's what you want.
[23:32] <LeoNerd> maxb: You've never heard them called the Astral planes, before?
[23:32] <lifeless> the common case for /some/ apps will be a bunch of kanji or whatever; but the common case for bzr is ascii strings - so we pay 300% overhead for the common case
[23:33] <LeoNerd> I was talking about Planes of Unicode on #perl a while ago.. someone made a joke wondering if there's any snakes on them
[23:33] <maxb> First time I've heard that particular pun
[23:33] <LeoNerd> Turns out, yes.. there's two: CJK RADICAL SNAKE and COMBINING SNAKE. :)
[23:33] <lifeless> awesome
[23:34] <LeoNerd> U+2E92
[23:34] <lifeless> \o/ test engine completes now
[23:34] <lifeless> time to fix the tests
[23:34] <lifeless> mgz:   File "/home/robertc/source/unittest/subunit/working/python/subunit/__init__.py", line 1141, in _make_stream_binary
[23:34] <lifeless>     _make_binary_on_windows(stream.fileno())
[23:34] <lifeless> io.UnsupportedOperation: fileno
[23:35] <mgz> heh.
[23:35] <mgz> if we're lucky... they do that be default now.
[23:36] <lifeless> mgz: I've pushed rev 145
[23:36] <mgz> if we're unlucky, the rewriters decided people shouldn't be allowed to look at the underlying handles any more.
[23:37] <lifeless> which triggers that error for me on Ubuntu
[23:37] <lifeless> if you want to look at the windows path
[23:37] <mgz> most likely, it'll just need a different spelling.
[23:42] <mgz> `sys.stdout.buffer.raw.fileno()` looks like it'll do
[23:42] <mgz> which is a bit daft just to get `1`
[23:42] <lifeless>   File "/home/robertc/source/unittest/testtools/working/testtools/content.py", line 64, in __eq__
[23:42] <lifeless>     _join_b(self.iter_bytes()) == _join_b(other.iter_bytes()))
[23:42] <lifeless> TypeError: sequence item 0: expected bytes, str found
[23:43] <lifeless> recursion, see under recursion
[23:43] <mgz> hm, I remember frowning at that method before.
[23:44] <lifeless> one of the content objects has a string the other a bytes
[23:44] <lifeless> or possibly both
[23:45] <mgz> yeah, and the way it's spelt doesn't tell you which or where.
[23:45] <mgz> but I guess otherwise you're trying to compare lists with different length byte chunks in, which is also a pain
[23:50] <mgz> okay, so the previous error was just their heirachy stuff means lots of things have fileno method that will just raise
[23:52] <mgz> perhaps switching to `try:_make_binary_on_windows(stream.fileno());except (AttributeError, io.UnsupportedOperation):return;` would work but finding a compatible way to spell that may be hard
[23:53] <mgz> `no_fileno = _is_py3k and io.UnsupportedOperation or AttributeError` in long form maybe.
[23:54] <lifeless> I'm just chasing lower level things atm
[23:54] <lifeless> I can try that in a bit
[23:54] <lifeless> unless you have a ubuntu vm or something?
[23:55] <mgz> sec, I'll try setting up here then can maybe give you a branch for some specific things.
[23:57] <lifeless> hhhha
[23:57] <lifeless> and after all the fuss about type safet
[23:57] <lifeless> y
[23:57] <lifeless>             if cmd in ('test', 'testing'):
[23:57] <lifeless> guess what that doesn't do
[23:57] <lifeless> if cmd is b'test'
[23:59] <mgz> heh.
[23:59] <lifeless>   File "/usr/lib/python3.1/unittest.py", line 1395, in startTest
[23:59] <lifeless>     self.stream.write(self.getDescription(test))
[23:59] <lifeless> TypeError: must be str, not bytes
[23:59] <lifeless> >< >< ><