=== parthm_ is now known as parthm [06:09] hello. whats a good way to capture stdout/stderr in a bzr unittest. i have a unit test that prints ui.ui_factory.show_warning. i want to assertContainsRe that the output has this warning. [06:47] nevermind. found an example in tests\test_http.py [06:49] parthm: uhm, don't do it ? [06:49] parthm: capturing stdout/stderr is pretty evil and makes it very hard to debug things. Why do you want to do that ? [06:50] lifeless: i have a fix for bug #430785 which prints a warning in case clean-tree cannot delete a file. [06:50] Launchpad bug 430785 in Bazaar "bzr clean-tree --force --detritus stops on io error (file in use) (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/430785 [06:50] ui.ui_factory.show_warning ... so i am writing a unit test to verify it. [06:50] parthm: I don't see why that implies capturing stdout/stderr [06:51] lifeless: is there any other way of ensuring that the warning is being printed? [06:51] or generated. [06:51] use a known api and confirm that the api is claled [06:52] in this particular case, the test UI should accumulate the api calls made on it [06:52] so you can just assert that show_warning was called [06:52] also [06:52] """Show warning for errors seen by rmtree. [06:52] 98 """ [06:52] one line for one-liners please [06:53] """Show warning for errors seen by rmtree.""" [06:53] lifeless: ah. good idea. so i can overrideAttr show_warning. i will do that. [06:53] huh [06:53] no [06:53] there is a test specific UI [06:54] it gathers things into strings [06:54] lifeless: is there any test case i can look at as an example? [06:55] hmm, its changed, I could swear we used to have one [06:56] anyhow, bzrlib.ui contains SilentUIFactory [06:56] ah [06:56] its in bzrlib.tests [06:56] bzrlib.tests.TestUIFactory [06:56] it needs a small tweak to have a show_warning [06:57] but even without it [06:57] def test_clean_tree_warning(self): [06:58] out = String() [06:58] * parthm greps for TestUIFactory usage [06:59] self.overrideAttr(ui, 'ui_factory', tests.TestUIFactory(stdout=out)) [06:59] clean_tree(...) [06:59] self.assertContainsRe('needle', out.getvalue()) [06:59] # this should do for now, we should make it better and more structured though [07:00] lifeless: yes. thats the example i found in tests/test_http.py. i will implement this. i agree. confirming that the api is called would be nicer. [07:01] lifeless: thanks. [07:01] parthm: ah, I thought you found something using apply_redirected [07:02] which is really quite different :) [07:02] becaues *that* does alter stdout/stderr/stdin its very hard to debug within it. [07:02] lifeless: :) ... no it was test_http. ... test_prompt_for_username [07:06] Is there any way to upload files to Launchpad using a web interface, as an alternative to a command-line interface? I'm new to Bazaar/version control software, and have been unable to learn, despite some struggling — it seems to require Mac OS 10.5 (I have 10.4). Thanks! [07:06] I looked at macports but it needs admin access. [07:06] I don't have it. [07:07] Admin access, that is. [07:08] This is one of many reasons I hate mac os: software is next to nonexistant for it. [07:08] :-p [07:10] bai ? [07:11] spiv: btw [07:11] spiv: I wish there was a pypi operationswithcleanups BSD module. Just saying. [10:17] spiv: http://twitter.com/rbtcollins/status/21218747637 is why [16:57] Hey [16:58] If I have questions about using bzr with VC (the version control system in emacs23); should I ask here or in #emacs? [16:58] I only lightly use that integration [16:58] I used to use DVC [16:59] Now I'm trying VC since it's supposed to be good [16:59] basically I made some changes; I was expecting C-u C-x v v to let me use a different branch [16:59] I haven't used dvc much [16:59] (currently on "trunk", I'd like to put these changes in a new branch) [17:00] I don't understand how that'd work (that sounds like it'd require VC knowing much more about how my branches are organized on-disk than it normally does) [17:02] I was expecting it to be really clever and understand how repositories work [17:03] So how are you supposed to branch from emacs [17:05] repositories can work however you want them to. I just use bzr commandline commands to branch [17:06] "branch" in my case frequently means "create a new branch in a no-trees repository emacs knows nothing about, and then switch the lightweight checkout I work in" [17:06] that's not really something I'm interested in teaching emacs how to do [17:06] But M-x term is so many keystrokes :-( [17:06] I'll try #emacs, if that doesn't help I'm moving back to DVC [17:07] I don't know enough about vc to know if this is something it is interested in doing for you [18:08] I'm playing around with setting up a pre-commit bzr hook for a branch. It would simply run a single shell command. I saw the shell-hooks plugin, which looks like it would be better suited than writting a python plugin for the hook. I'm just having a problem figuring out a) where the plugin looks for the shell script (so I can use a relative path instead ofabsolute) and b) Where the shell script is actually run from [20:40] has anyone had any success using bzr-svn with codeplex? [20:40] doesn't seem to be working for me [20:42] Noldorin: the codeplex svn server is broken [20:42] Hey [20:42] jelmer, ah i see. [20:42] So what's the reccomended emacs integration for bzr [20:42] Noldorin: it returns inconsistent data [20:43] jelmer, have the codeplex admins been notified of thisw? [20:43] there's DVC, there's VC [20:44] Noldorin: I don't know; I don't use any codeplex repositories but I've mentioned what the issue was to several people who ran into issues with codeplex. [20:44] right [20:44] i think i remember you telling me now some time ago actually! [20:44] ah well [20:45] there's BzrEmacs which is kind of old [20:48] jelmer, any idea what the status of bzr-tfs is like? [21:11] lvh: Sorry, I'm not an emacs user. Perhaps there's some folks on the Bazaar mailing list that can help. [21:11] Noldorin, what's bzr-tfs? [21:13] Talisman For Soupmaking? [21:13] jelmer, https://launchpad.net/bzr-tfs [21:15] Shucks. I was looking forward to soup :( [21:22] jelmer: Thanks, I'll give it a try [21:23] Noldorin, ah, neat - I hadn't seen that yet [21:25] jelmer, indeed. unfortunately i can't get it to run here though... [21:26] needs some ntlm module [21:27] Noldorin: perhaps ask the author and cc the bazaar list? [22:10] the bzr-tfs plugin looks nice [22:10] too bad I don't have a Microsoft Team Foundation Server to test with :-P [22:16] Noldorin, it looks like you need to install the python-ntlm module [22:19] jelmer, codeplex provides free TFS repos :) [22:20] jelmer, also, i installed python-ntlm, but no lucky... [22:21] Noldorin: Can you follow-up to the mailing list? The original author announced it there a month ago, he might be able to help. [22:21] jelmer, sure, will give that a go. cheers === AfC2 is now known as AfC [23:35] mgz: hey [23:40] hey lifeless [23:40] was hoping you'd be around [23:40] indeedy [23:43] so, the basic idea which is a bit hard to see in the big diff [23:44] is that inside TestSuite.run running each TestCase is delegated to a teeny function that only returns a weakref [23:45] ... [23:45] (Why?) [23:45] because we need to drop the reference, and then check whether the case is in fact still alive [23:45] theres a missing cause/assumption here [23:45] I'm at sea [23:46] hm... I'll try another angle. [23:46] we want to deallocate test case instances after they run, and *check* they're gone [23:46] also, lp:python-fixtures; new shiny for you [23:46] mgz: why do we want to check that they are gone ? [23:46] because otherwise we get regressions. [23:47] this seems like a very hard proposition [23:47] we've had hundreds of revs of the test suite being slow and flakey on my machine without the cause being very clear [23:47] 'do not think of the elephant' [23:47] and... it's not that hard [23:47] mgz: yes, agree we need a means to improve and debug this [23:47] I'm just trying to make sure I get each step of the logic properly ;) [23:48] a weakref will return None when called, if the object it points at is gone [23:48] so [23:48] if the case returned is None, all is fine, if it's still a test case, we complain [23:48] this implies a few things [23:48] complaining means I can find cycles. [23:48] a) knowing if a given thing *should* be gone [23:48] hello mgz, lifeless [23:49] hey poolie [23:49] poolie: heya [23:49] I agree this is complicated and annoying. [23:49] so, you could extend TestResult to permit querying 'are you still holding on to X' [23:49] But I think I can do most of the annoying bits without inflicting them on everyone else who just has 8GB of ram and doesn't care. [23:49] if it says 'no', then a weakref to X should return None [23:50] which problem are we trying to solve here? [23:50] mgz: sure, my goal is to help you do this [23:50] I can live with the test result holding failed tests, in general, that should be a small number. [23:51] the main issues are cycles (which is a judgment between avoiding them or running a gc collection after every test), and the decorators [23:51] mgz: well, we want several things AIUI; actual cycles generated in the code should be obvious (like that stack one - meep); the test suite itself shouldn't create cycles [thus your detection logic]; the tests suite should run fast [23:52] I think those are achievable goals, the only thing being I've currently got "test not collected" but not any simple way of pointing out where the cycle is [23:53] well, meliae can tell, I expect. [23:53] I wondered if it might, I've just not tried. [23:53] so we could have an option to use it for folk that want to debug these things [23:55] it's much easier to see the problem when it's in code you've just written, so if I fix the remaining ones then make non-collection into some kind of test failure I think that's sustainable [23:56] ok [23:56] if you've just written a test that closes over the test instance and pqm rejects it, I'd hope it wouldn't be hard to resolve. [23:56] that works for me [23:58] so if you're okay with that general approach, I think the remaining possible problem areas are that I've taken a hammer to the TestDecorator classes, and the new unit test _ExpectedFailure [23:59] well, the first is if it's going to upset anything