[00:02] I wish I had a meliae for Perl. :-| [00:06] I wish there was one and only one python memory tool instead of the five or so currently used [00:06] Well, at least they are reasonable and sane. [00:07] mgz: there is only one.... worth knowing [00:07] mgz: I've done subunit and testtools releases. [00:07] mgz: is that thread fully pulled on now ? [00:08] I believe so. Got some updates for bzr, but that wants to lag a bit anyway. [00:10] bug 582113 and some other misc testtools regressions that I've still not got round to filing, then maybe followup for Parth and Alexander who got stuck on writing unicode tests prviously [00:10] Launchpad bug 582113 in Bazaar "Tests don't run under Python 2.7 (unittest._WritelnDecorator has moved) (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/582113 [00:10] ^fix that by using testtools bits rather than unittest bits [00:11] lets nuke the use of WritelnDecorator too [00:11] right. it's a fantasically pointless class. [00:11] its surprising for new players [00:11] anyway, we want testtools runner and texttestresult [00:11] which avoids the issues with 2.7 [06:25] any reviewers around ? [06:48] The plot was thin, and the actors seemed both disinterested and wooden. A script rewrite is in order. [06:48] well roughly [06:53] turns out that using bzrlib.lsprof.profile in a threaded app is a little .. risky [07:38] https://code.edge.launchpad.net/~lifeless/bzr/lsprof_lockout/+merge/29165 is the result [07:54] risky as well as being pointless as per bug 579185? [07:54] Launchpad bug 579185 in Bazaar "lsprof records profile from sub threads, but does not save them. (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/579185 [07:56] shrug [07:56] that is fixable - I thought GaryvdM had a fix pending in fact [07:56] mgz: but since you are here, you can review my patches ;) [07:56] didn't look easy to do cleanly when we looked at it, but part of that was just the display of the results [07:58] the locking you've added looks sane to me, but I don't understand the actual problem [07:58] minimally showing them as separate top level entry points would be better than nothing [07:58] we call threading.setprofile [07:58] thats a 'change a global [07:58] so when 579185 is fixed [07:58] say you have a threaded webapp - I dunno, a wsgi server, or launchpad, or whatever. [07:59] if in two threads at once you do 'profile(sublayer, args)' [07:59] the second entrant to profiler.start() [07:59] will override threading.setprofile [07:59] new threads started by *either* request [07:59] will get collected to the second entrant. [08:00] also new threads started after either exit will not get collected at all because we reset the profile function for new threads to None [08:02] ah, right, I get it, thanks. [08:05] seems like threading._profile_hook should really be thread-local [08:05] so new threads would use a trampoline to pass it on each time as well [08:05] and you'd get a graph of threads with it set appropriately? Yes. [08:06] that would be nice. [08:06] yup. your fix looks good, I'll just test it here. [08:06] thanks [08:07] have I mentioned I hate distutils ? [08:07] who doesn't? [08:07] tar tzf ../testtools-0.9.4.tar.gz | grep compat [08:07] I hate setuptools/distribute more [08:07] likewise. [08:08] |o/ [08:08] distutils is just messy and barely documented. setuputils is actively evil. [08:08] *setuptools [08:09] god, why isn't it finding it [08:10] hmm, interesting [08:10] return _win32_fixdrive(mkdtemp(*args, **kwargs).replace('\\', '/')) [08:10] RuntimeError: maximum recursion depth exceeded [08:10] wonder what the *top* of that stack was [08:11] \o/ [08:11] I'm fairly sure thats not my patch :> [08:11] IMBW [08:11] I'll try dev and see if it's a recent thing there [08:12] yup, it's on dev... gra. [08:13] >< [08:13] have you perhaps looked into how distutils finds files before ? [08:13] ooh, I just upgraded testtools yesterday [08:14] mgz: teehee [08:14] wonder if it's related to that rather than a bzrlib change... hope not. [08:15] ok, MANIFEST existing messes setup.py up. [08:15] >< [08:16] nope, regression from r5326 - sorry vila [08:16] /o\ [08:17] the problem with tests... need them to be static to be reliable, but then they become full of cruft and bad examples [08:17] well [08:18] I don't really care about old cruft badness; I care about performance and maintainability. [08:18] Folk that use tests as examples of production code are being optimistic IME. [08:18] the problem with that is expecting new contributors to write tests when bzr has changed style substantively several times across its lifetime [08:19] and new tests have fluent folk reviewing, so at most a little rework happens when someone copies. [08:19] which the reviewer can usually trivially do. [08:19] I'm still not sure how to write a bunch of things I'd like to be testing... and I quite like tests [08:19] mgz: yeah, there is some overhead there, but new contributor % vs total-test-base-size :> [08:19] mgz: just ask ! [08:20] okay, poping the stack, need to check your lsprof ones still [08:21] passes with 5326 merged out. [08:25] today is yak shaving day. [08:25] /o\ [08:27] james_w: if you're up, have you looked into bug 588060 any further? I'm hitting it now with a fairly simple rename (util.py -> compat.py in testtools) [08:27] Launchpad bug 588060 in bzr-builddeb "unversioned executability issue, perhaps in builddeb (affected: 2, heat: 8)" [High,Triaged] https://launchpad.net/bugs/588060 [08:33] okay, fixing osutils is easy, though I'm a little confused as to what vila was trying to change there [08:35] ah, I see, ugly lazy import interaction [08:36] and mostly pointless, I don't think you can even do `bzr rocks` without importing tempfile [08:36] lazy import is a bit overused as a tool [08:36] osutils should just... not shadow things in the os module, it's bad, wrong, and confusing [08:37] no real opinion either way here [08:37] OT1H the function names are well defined and we do supply less broken versions [08:37] OTOH they are shadowing the real ones. [08:40] well, it's better than monkey patching ntpath at least, but what, off the top of your head, is the difference between os.rename and osutils.rename for instance? [08:41] handles open files [08:41] that one is more questionable [08:44] ...think I'll keep this a one-line fix, rather than trying to make the code sane [08:44] :> [08:48] that reminds me [08:48] have you seen withhacks? I think you'll appreciate the evilness [08:48] mgz: ^ [08:50] ah, no, but... I've seen the sort of things ruby people do [08:50] http://pypi.python.org/pypi/withhacks [08:50] using with to create tree structures like html DOMs and anything else they want an indent for [09:01] okay, that really is quite horrid. the javascript-style with is bad enough, but the xargs class is just... insane [09:01] why would anyone ever think doing that is a good idea... [09:03] one thing I would like the with statement for (and I'm not all that keen on it, it's a whoops-we-screwed-up-scoping-originally type modification like the javascript 'let') [09:03] https://lp-oops.canonical.com/oops.py/?oopsid=we [09:03] is lazy imports. [09:03] could do lazy imports with with, and then not have any of that string parsing mess [09:11] mgz: there was a thread on that on python-ideas just recently [09:12] I stopped reading python-ideas shortly after it was created [09:12] :) [09:12] seemed like python-shutup-and-get-off-dev, has it improved? [09:13] what was the thread subject? [09:14] looking [09:16] explicitation lines [09:19] reading. [09:25] seems very alien for python (and not just because of the french word)... [09:26] using to just being able to read forwards, rather than in every direction at once as per functional languages [09:26] *used [09:27] hi guys, I've checked out from a .htaccess password protected directory repository. Now each time I bzr up it asks me the username/password twice.. is this a bug? [09:27] yes. [09:29] ok, I'm on bzr 2.1.2.. new versions fixes that? [09:31] I've not heard of the bug before [09:31] trying to find bug, but I might have hallucinated it. [09:32] I'd check you have your authentication.conf setup correctly. [09:33] mgz: set a message on your installer merge... and land it:) [09:33] mgz: you can use lp-propose -m to set the message when you create it [09:34] fax8: other thing you can try is -Dhttp and look at the log [09:34] have I got perms to land on the installer project lifeless? [09:35] mgz: you put a merge up for bzr [09:35] mgz: you would for the installers if you joined ~bzr no ~bzr-core, I think. [09:35] oh, that bit, doh. [09:36] ...maybe I should join ~bzr, given yesterday [09:37] poking bzr lead to changes across three different projects [09:40] here is the log http://pastebin.com/wfPS3VmQ [09:41] I'm still not too bzr savy to understand what's happening there [09:41] mgz: Was your fix a one-line change to use tempfile.mkdtemp instead of mkdtemp ? [09:41] * vila passing around *very* briefly [09:42] it was: https://code.launchpad.net/~gz/bzr/win32_mkdtemp_infinite_recursion/+merge/29166 [09:42] fax8: so, the thing that jumps out there is the 401-401-401-200 sequence [09:43] *401-404-401-200 [09:43] ok, what should I do? [09:43] SHUDDER, introduced after a review tweak :-( And as such not tested on babune :-( :-( [09:43] vila: regressions hide around every change [09:44] which is daunting as this was part of an effort to make the test suite *pass* on windows :-( [09:44] lifeless: yeah, I don't run enough tests... [09:45] to avoid it for the moment you can probably put the password in authentication.conf as lifeless suggested earlier [09:45] I'll have a go at repoing here later. [09:45] * vila goes back tightening his hanging rope [09:45] fax8: `bzr help authentication` [09:47] what was I doing... oh yeah, commit message [09:47] mgz: was it at least caught by a fialing test ? [09:47] it made the whole test suite blow up. [09:47] * vila put the rope aside [09:48] mgz: sorry for that and thanks for the fish^H^Hx [09:55] ...launchpad doesn't seem to have a way of unproposing yourself of a team [10:04] mgz: did you mistakenly try to join worldcup-fr? [10:04] * mneptok woggles an eyebrow at all the French present [10:04] heh [10:06] Hi all [10:07] morning gary. [10:09] mgz: Any luck with removing the win32 installer stuff out of setup.py? [10:10] ha, I'm too smart to launch on that one ;) [10:11] mgz: I think I'm going to have to add to if for launchpadlib, and it feels wrong putting it in to bzr.dev/setup.py.... [10:11] s/if/it [10:12] GaryvdM: to shave the yak, or yak the shave? [10:13] yeah, half the file is qbzr/tbzr/py2exe already... needs doing, just a little painful [10:13] the question to ask is [10:13] 'if someone is installing directly from source, do they need this' [10:14] if the answer is yes, do it in setup.py (or something imported into setup.py) [10:15] I feel the answer is no. [10:15] then do it outside of setup.py [10:16] whatever is in setup.py is irrelevant at this point :) [10:31] on the fax8 http auth problem from earlier, does this (typing guest/password as prompted): [10:31] bzr branch http://float.endofinternet.org/bazaar/testauth [10:31] also prompt twice for everyone else? [10:32] there are a lot variables with bzr and http [10:37] twice [10:37] love the domain [10:38] thanks, I'll poke around later and see if I can find the problem. [11:45] mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167 [11:45] we'll want to port the basic support for this to bzrtools too [11:50] 20:44 < lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167 [11:50] 20:44 < lifeless> we'll want to port the basic support for this to bzrtools too === lifeless_ is now known as lifeless [12:00] now where was I [12:00] thats right, merge-upstreaming [12:06] is it possible to get the changes to file contents from a TransformPreview object? [12:08] should be possible [12:08] I think it offers the tree interface [12:08] and thus tree.get_file(file_id) -> file contents [12:10] .get_preview_tree.get_file(file_id).read()? [12:10] yea [12:11] thanks [12:32] lifeless: how would I do the same thing post-commit? (I'm using a builder to do the commit) [12:32] I need a little more context to help [12:34] lifeless: so I'm looking to get all the file contents of all the files in my branch after a commit [12:36] are you using the API ? [12:37] or command line [12:40] ....and packages for testtools and subunit uploaded to debian. [12:40] bzrlib [12:40] so, you have two options [12:40] a post comit hook [12:40] or after calling commit, you can obtain the revision tree from the repository for the committed revision [12:41] revid = tree.commit(..) [12:41] revtree = tree.branch.repository.revision_tree(revid) [12:41] revtree.lock_read() [12:41] revtree.get_file(fileid) [12:41] etc [12:42] mgz: I've managed to move the py2exe code to it's own file in bzr-windows-installers. It feels a bit hackey. Maybe you could take a look, tell me what you think. http://bazaar.launchpad.net/~garyvdm/bzr-windows-installers/maybe/annotate/head:/build_bzr_py2exe.py [12:44] Let me see if I can build an installer with it... [13:11] ok, I have the following code: http://dpaste.com/214454/ and the following trace: http://dpaste.com/214456/. For some reason post-commit the file hasn't changed even though the TransformPreview contains a change to the repo. Why is this? [14:06] nit [14:07] (Sorry, empathy window stole my keyboard focus.) === khmarbaise_ is now known as khmarbaise [18:34] hi guys, does bzr make 2 copies of images when a client do a fetch/checkout, i'm using svn right now, and if my image folder has 100 images inside .svn it has the same so it uses 2x the space [18:58] PrinceAMD: no [18:58] it will have a compressed copy in the local repository, but it doesn't need the pristine copy that svn uses [19:01] ok jam , also image does not compress that well, so i might end up with same result [19:05] PrinceAMD: there will be a fair amount of 'it depends' involved. [19:05] such as, you could do a lightweight checkout [19:05] or if you have a shared repo, there is only 1 copy across all your branches, etc. [19:09] hm.. lightweight checkout looks nice, i'll test it [19:19] Hi jam. [23:10] mgz: small meta: when commenting on bugs, be lovely if you can triage at the same time. [23:10] you don't have too, and perhaps you usually do - if either apply just ignore me :) [23:20] GaryvdM: the py2exe move looks pretty good to me, surely it's not that easy though :) [23:21] lifeless: I don't have perms. well, I can confirm, and assign to myself, but I can't set prio or any of the rest [23:21] garh [23:21] ok [23:21] so I can add you to bzr; want to be in there ? cost: lots of mail. pros: no more process friction. [23:21] I was looking at that this morning [23:22] the main is gmail won't let you filter on X-Launchpad-Message-Rationale [23:22] +pain [23:22] oh [23:22] so, it'd probably nuke my nice orderly mailinglist account [23:22] I filter on the rationale paragraph at the bottom of the mail [23:23] 'because you are a member of' :P [23:23] ah, the "You received this bug notification because..." [23:23] you can also do a direct subscription in LP [23:23] that sounds like it'd work [23:23] and then turn off things [23:23] e.g. don't care about mac installers? subscribe to that with a no-mail subscription [23:25] mgz: your mkdtemp patch needs landing :) [23:26] hm, this might be a bug, it seems "because you are a member of..." overrides "because you are a direct subscriber..." [23:26] don't want to archive bugs I actually filed [23:27] so this is something deryck is very interested in [23:27] they are overhauling the bugs subscription stuff at the moment. [23:32] I can has review? https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/29139 [23:33] me no know looms 'm 'fraid [23:33] ah, you're just deleting something. and... is adding the matchers there serving any purpose? [23:38] oh! oversight [23:38] I was going to make the same change I made a few revisions earlier to per_interbranch [23:38] where the test is duplicated [23:38] I changed my mind. [23:42] ...either I'm going mad, or there's no way to add the "inbox" label back to a thread with the basic gmail web interface [23:43] o/~ I hate huawei E160's o/~ [23:43] 08:38 < lifeless> oh! oversight [23:43] 08:38 < lifeless> I was going to make the same change I made a few revisions earlier to per_interbranch [23:43] 08:38 < lifeless> where the test is duplicated [23:43] 08:38 < lifeless> I changed my mind. [23:44] Isee. [23:45] (changed and deleted instead) === lifeless_ is now known as lifeless [23:58] does per_interbranch cover what per_branch is testing anyway?