[06:09] <parthm> 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] <parthm> nevermind. found an example in tests\test_http.py
[06:49] <lifeless> parthm: uhm, don't do it ?
[06:49] <lifeless> parthm: capturing stdout/stderr is pretty evil and makes it very hard to debug things. Why do you want to do that ?
[06:50] <parthm> lifeless: i have a fix for bug #430785 which prints a warning in case clean-tree cannot delete a file.
[06:50] <parthm> ui.ui_factory.show_warning ... so i am writing a unit test to verify it.
[06:50] <lifeless> parthm: I don't see why that implies capturing stdout/stderr
[06:51] <parthm> lifeless: is there any other way of ensuring that the warning is being printed?
[06:51] <parthm> or generated.
[06:51] <lifeless> use a known api and confirm that the api is claled
[06:52] <lifeless> in this particular case, the test UI should accumulate the api calls made on it
[06:52] <lifeless> so you can just assert that show_warning was called
[06:52] <lifeless> also
[06:52] <lifeless>   """Show warning for errors seen by rmtree.
[06:52] <lifeless>  98        """
[06:52] <lifeless> one line for one-liners please
[06:53] <lifeless> """Show warning for errors seen by rmtree."""
[06:53] <parthm> lifeless: ah. good idea. so i can overrideAttr show_warning. i will do that.
[06:53] <lifeless> huh
[06:53] <lifeless> no
[06:53] <lifeless> there is a test specific UI
[06:54] <lifeless> it gathers things into strings
[06:54] <parthm> lifeless: is there any test case i can look at as an example?
[06:55] <lifeless> hmm, its changed, I could swear we used to have one
[06:56] <lifeless> anyhow, bzrlib.ui contains SilentUIFactory
[06:56] <lifeless> ah
[06:56] <lifeless> its in bzrlib.tests
[06:56] <lifeless> bzrlib.tests.TestUIFactory
[06:56] <lifeless> it needs a small tweak to have a show_warning
[06:57] <lifeless> but even without it
[06:57] <lifeless> def test_clean_tree_warning(self):
[06:58] <lifeless>     out = String()
[06:58]  * parthm greps for TestUIFactory usage
[06:59] <lifeless>     self.overrideAttr(ui, 'ui_factory', tests.TestUIFactory(stdout=out))
[06:59] <lifeless>     clean_tree(...)
[06:59] <lifeless>     self.assertContainsRe('needle', out.getvalue())
[06:59] <lifeless> # this should do for now, we should make it better and more structured though
[07:00] <parthm> 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] <parthm> lifeless: thanks.
[07:01] <lifeless> parthm: ah, I thought you found something using apply_redirected
[07:02] <lifeless> which is really quite different :)
[07:02] <lifeless> becaues *that* does alter stdout/stderr/stdin its very hard to debug within it.
[07:02] <parthm> lifeless: :) ... no it was test_http. ... test_prompt_for_username
[07:06] <kyan> 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] <kyan> I looked at macports but it needs admin access.
[07:06] <kyan> I don't have it.
[07:07] <kyan> Admin access, that is.
[07:08] <kyan> This is one of many reasons I hate mac os: software is next to nonexistant for it.
[07:08] <kyan> :-p
[07:10] <lifeless> bai ?
[07:11] <lifeless> spiv: btw
[07:11] <lifeless> spiv: I wish there was a pypi operationswithcleanups BSD module. Just saying.
[10:17] <lifeless> spiv: http://twitter.com/rbtcollins/status/21218747637 is why
[16:57] <lvh> Hey
[16:58] <lvh> If I have questions about using bzr with VC (the version control system in emacs23); should I ask here or in #emacs?
[16:58] <marienz> I only lightly use that integration
[16:58] <lvh> I used to use DVC
[16:59] <lvh> Now I'm trying VC since it's supposed to be good
[16:59] <lvh> basically I made some changes; I was expecting C-u C-x v v to let me use a different branch
[16:59] <marienz> I haven't used dvc much
[16:59] <lvh> (currently on "trunk", I'd like to put these changes in a new branch)
[17:00] <marienz> 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] <lvh> I was expecting it to be really clever and understand how repositories work
[17:03] <lvh> So how are you supposed to branch from emacs
[17:05] <marienz> repositories can work however you want them to. I just use bzr commandline commands to branch
[17:06] <marienz> "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] <marienz> that's not really something I'm interested in teaching emacs how to do
[17:06] <lvh> But M-x term is so many keystrokes :-(
[17:06] <lvh> I'll try #emacs, if that doesn't help I'm moving back to DVC
[17:07] <marienz> I don't know enough about vc to know if this is something it is interested in doing for you
[18:08] <nhandler> 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] <Noldorin> has anyone had any success using bzr-svn with codeplex?
[20:40] <Noldorin> doesn't seem to be working for me
[20:42] <jelmer> Noldorin: the codeplex svn server is broken
[20:42] <lvh> Hey
[20:42] <Noldorin> jelmer, ah i see.
[20:42] <lvh> So what's the reccomended emacs integration for bzr
[20:42] <jelmer> Noldorin: it returns inconsistent data
[20:43] <Noldorin> jelmer, have the codeplex admins been notified of thisw?
[20:43] <lvh> there's DVC, there's VC
[20:44] <jelmer> 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] <Noldorin> right
[20:44] <Noldorin> i think i remember you telling me now some time ago actually!
[20:44] <Noldorin> ah well
[20:45] <lvh> there's BzrEmacs which is kind of old
[20:48] <Noldorin> jelmer, any idea what the status of bzr-tfs is like?
[21:11] <jelmer> lvh: Sorry, I'm not an emacs user. Perhaps there's some folks on the Bazaar mailing list that can help.
[21:11] <jelmer> Noldorin, what's bzr-tfs?
[21:13] <fullermd> Talisman For Soupmaking?
[21:13] <Noldorin> jelmer, https://launchpad.net/bzr-tfs
[21:15] <fullermd> Shucks.  I was looking forward to soup   :(
[21:22] <lvh> jelmer: Thanks, I'll give it a try
[21:23] <jelmer> Noldorin, ah, neat - I hadn't seen that yet
[21:25] <Noldorin> jelmer, indeed. unfortunately i can't get it to run here though...
[21:26] <Noldorin> needs some ntlm module
[21:27] <jelmer> Noldorin: perhaps ask the author and cc the bazaar list?
[22:10] <jelmer> the bzr-tfs plugin looks nice
[22:10] <jelmer> too bad I don't have a Microsoft Team Foundation Server to test with :-P
[22:16] <jelmer> Noldorin, it looks like you need to install the python-ntlm module
[22:19] <Noldorin> jelmer, codeplex provides free TFS repos :)
[22:20] <Noldorin> jelmer, also, i installed python-ntlm, but no lucky...
[22:21] <jelmer> 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] <Noldorin> jelmer, sure, will give that a go. cheers
[23:35] <lifeless> mgz: hey
[23:40] <mgz> hey lifeless
[23:40] <mgz> was hoping you'd be around
[23:40] <lifeless> indeedy
[23:43] <mgz> so, the basic idea which is a bit hard to see in the big diff
[23:44] <mgz> is that inside TestSuite.run running each TestCase is delegated to a teeny function that only returns a weakref
[23:45] <lifeless> ...
[23:45] <lifeless> (Why?)
[23:45] <mgz> because we need to drop the reference, and then check whether the case is in fact still alive
[23:45] <lifeless> theres a missing cause/assumption here
[23:45] <lifeless> I'm at sea
[23:46] <mgz> hm... I'll try another angle.
[23:46] <mgz> we want to deallocate test case instances after they run, and *check* they're gone
[23:46] <lifeless> also, lp:python-fixtures; new shiny for you
[23:46] <lifeless> mgz: why do we want to check that they are gone ?
[23:46] <mgz> because otherwise we get regressions.
[23:47] <lifeless> this seems like a very hard proposition
[23:47] <mgz> 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] <lifeless> 'do not think of the elephant'
[23:47] <mgz> and... it's not that hard
[23:47] <lifeless> mgz: yes, agree we need a means to improve and debug this
[23:47] <lifeless> I'm just trying to make sure I get each step of the logic properly ;)
[23:48] <mgz> a weakref will return None when called, if the object it points at is gone
[23:48] <lifeless> so
[23:48] <mgz> if the case returned is None, all is fine, if it's still a test case, we complain
[23:48] <lifeless> this implies a few things
[23:48] <mgz> complaining means I can find cycles.
[23:48] <lifeless> a) knowing if a given thing *should* be gone
[23:48] <poolie> hello mgz, lifeless
[23:49] <mgz> hey poolie
[23:49] <lifeless> poolie: heya
[23:49] <mgz> I agree this is complicated and annoying.
[23:49] <lifeless> so, you could extend TestResult to permit querying 'are you still holding on to X'
[23:49] <mgz> 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] <lifeless> if it says 'no', then a weakref to X should return None
[23:50] <mgz> which problem are we trying to solve here?
[23:50] <lifeless> mgz: sure, my goal is to help you do this
[23:50] <mgz> I can live with the test result holding failed tests, in general, that should be a small number.
[23:51] <mgz> 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] <lifeless> 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] <mgz> 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] <lifeless> well, meliae can tell, I expect.
[23:53] <mgz> I wondered if it might, I've just not tried.
[23:53] <lifeless> so we could have an option to use it for folk that want to debug these things
[23:55] <mgz> 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] <lifeless> ok
[23:56] <mgz> 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] <lifeless> that works for me
[23:58] <mgz> 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] <mgz> well, the first is if it's going to upset anything