[00:01] <fullermd> Noldorin: I have vague memories that say it has an env variable you can use to point at an object store elsewhere at least...
[00:02] <jelmer> Noldorin: somewhat
[00:02] <Noldorin> fullermd, hrmm. sounds hacky
[00:02] <Noldorin> basically i just don't want to pull all the RCS crud.
[00:02] <jelmer> Noldorin: you can create a tree in a different location and then set an environment variable
[00:03] <fullermd> Noldorin: Well, you did say "git", didncha?   ;>
[00:03] <Noldorin> fullermd, fair point ;-)
[00:03] <jelmer> Noldorin: yeah, as fullermd says
[00:03] <Noldorin> would it let me avoid pulling all the branch data?
[00:03] <fullermd> I expect it only works on local disk.
[00:03] <achiang> hello, is there a way to get the diff of my tree, starting from -r -1 to the current dirty state?
[00:03] <fullermd> (well, mounted filesystem anyway.  A little NFS across the internet never hurt anybody...)
[00:04] <fullermd> achiang: Wouldn't that just be 'bzr diff'?
[00:04] <jelmer> Noldorin: it doesn't work for remote repositories
[00:04] <Noldorin> jelmer, fullermd ah, so i thought. oh well to that idea then.... thanks anyway :-)
[00:05] <achiang> fullermd: hm, i didn't explain myself... i fixed something in -r -1 based on a review comment, but pretty much rewrote the commit at the top of the tree. I want to show what the diff would look like if i never committed -1 at all...
[00:05] <achiang> so i want -r -2 to current state, i think
[00:07] <fullermd> Do you mean "if I hadn't run 'ci' with what's in -r-1" or "if I'd not made the changes in -r-1"?
[00:07] <fullermd> The former would be -r-2.  The latter would be...   uh...   magic.
[00:07] <wgrant> achiang: 'bzr diff -r-2..' will show you the combined differences.
[00:07] <achiang> well, asked another way, i want the output that loggerhead might show you if you submitted an MP consisting of 2 commits that modified the same section of source
[00:08] <wgrant> "diff -r -2.."
[00:08] <fullermd> No, "-r-2.." is equivalent to "-r-2..-1".  You want "-r-2".
[00:08] <achiang> i tried bzr diff -r -2 (with a space)
[00:08] <achiang> oops, i mean i tried bzr diff -r -2..
[00:09] <achiang> i have uncommitted changes... any way to get those into the combined diff?
[00:09] <fullermd> That's what "-r-2" does.
[00:10] <fullermd> Though I imagine what the MP shows is actually more like a merge --preview from the other side, which may not correspond to that diff if there are other changes.
[00:10] <achiang> fullermd: hm, it works now. i *thought* that is what i was typing, but i must have gotten it wrong
[00:10] <achiang> thanks all
[06:29] <vila> hi all !
[06:58] <poolie> hi there vila
[06:58] <mgz> morning all
[06:58] <vila> poolie: hey, 1-on-1 ?
[06:58] <vila> mgz: heya
[06:59] <poolie> yes please
[07:06] <jam> morning all
[07:57] <jam> poolie, vila, mgz, Riddell, jelmer: standup?
[07:58] <poolie> hi
[07:58] <poolie> absolutely
[07:58] <poolie> mumblicious?
[07:59] <jam> i'm on
[08:00] <jam> but I'm all alone
[08:00] <jam> well, jelmer stopped by for a second :)
[08:00] <jam> http://pad.ubuntu.com/RXCaDM4J3u
[08:27] <poolie> Riddell: have a 'dulce et decorum' badge :)
[08:34] <mgz> poolie: like jelmer asked earlier, what's the plan on 1-1s?
[08:35] <mgz> I'd managed to miss a google calendar thing from you last week as well.
[09:04] <poolie> jam, mgz, did you see http://people.mozilla.com/~tglek/lpc2011/ - you might like it
[09:06]  * mgz looks
[09:06] <poolie> wow especially: http://glandium.org/blog/?p=1764
[09:07] <poolie> running a busy-loop in the background makes the benchmark faster
[09:07] <poolie> (through not letting the cpu spin down)
[09:07] <mwhudson> there was an SMP bug on ARM recently where running ping -f localhost made usb transfers go 10x faster
[09:13] <mgz> hm, been seeing the updates going by on p.m.o but presentation is new to me
[09:17] <lifeless> mwhudson: win
[09:18] <mwhudson> lifeless: turns out assumptions along the lines of "this architecture will only ever be uniprocessor" are dangerous :-)
[09:18]  * mwhudson puts the computer down
[09:33] <nigelb> mwhudson: Really? o_O
[10:48] <lifeless> mgz: did you see my ping about FixtureResource ?
[10:50] <lifeless> mgz: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops-amqp/trunk/view/head:/oops_amqp/tests/__init__.py#L83 - example of use
[10:50] <mgz> lifeless: thanks
[10:51] <lifeless> mgz: RabbitServer() is a Fixture. That declaration is using a resource
[10:52] <lifeless> mgz: and you wrap the test suite in an OptimisingTestSuite(); done.
[10:53] <mgz> where do I find rabbitfixture?
[10:54] <mgz> also, I'd be very sad if I was a test given a resource called 'rabbit' and it wasn't an actual bunny
[10:54] <lifeless> mgz: pypi rabbitfixture ;)
[10:54] <mgz> woho! a fluffy friend... wait no... ;_;
 is 404?
[10:57] <lifeless> bwah. it should be
[10:57] <lifeless> lp:rabbitfixture too, for sure
[10:57] <mgz> lp will do.
[10:57] <lifeless> (not that its code is particularly relevant
[10:58] <lifeless> (its convoluted due to dealing with heinous erlang stuff)
[10:59] <mgz> lifeless: I'm curious how reset is handled.
[10:59] <mgz> the answer seems to be... it's not
[11:00] <mgz> but actually there is quite a lot of interesting code in there
[11:01] <lifeless> mgz: reset defaults to stop(); start()
[11:01] <lifeless> mgz: doing a smarter one is an optimisation rather than a semantic facility
[11:02] <mgz> right.
[11:03] <mgz> but is also the whole point, in some respects
[11:03] <lifeless> sure
[11:04] <mgz> the way this uses TempDir and EnvrionmentalVariableFixture is enlightening too
[11:04] <lifeless> :)
[11:04] <lifeless> cool
[11:09] <lifeless> mgz: is that a good thing ?
[11:14] <mgz> understanding is always good
[11:15] <lifeless> :>
[11:15] <mgz> so the way useFixture is used there helps seperate concerns, but punts entirely on resource reusage
[11:17] <lifeless> right
[11:17] <lifeless> this is the Fixture-does-not-have-introspection-apis issue I was trying to explain
[11:18] <lifeless> fixture is a neat easy api, but hard to do layers-of-resource-reuse with
[11:18] <mgz> the filesystem is prepared seperately from the environment, and then a super-fixture inits and uses both
[11:18] <lifeless> its totally easy to take the end result and wrap that as a Resource
[11:23] <mgz> okay, and I can see how FixtureResource could be changed to split RabbitServerResources and RabbitServerRunner and have the latter depend on the former
[11:23] <mgz> ...in fact, let me do that as an exercise
[11:24] <lifeless> ah, thats where its tricky
[11:24] <lifeless> because the optimiser runs before setUp
[11:24] <lifeless> by definition
[11:25] <lifeless> and because RabbitServer acquires its dependencies by calling useFixture(new object)
[11:25] <lifeless> but please - have a fiddle :)
[11:25] <mgz> okay, I see the problem
[11:25] <lifeless> but that said, you can use the testresources contract with a fixture that expects it
[11:25] <lifeless> testresources injects the dependencies as attributes
[11:26] <lifeless> so a fixture which expects a self.config to exist before its setup and go after its cleaned up, will work fine in conjunction with testresources - but not standalone :)
[11:27] <lifeless> so the handwaving plan is to expose a static, optional, graph api for fixture
[11:27] <lifeless> which testresources can introspect and do its thing on, and which fixtures can bring up itself if its running standalone
[11:33] <mgz> I don't see why fixtures shouldn't init other fixtures in their init
[11:33] <mgz> is there a reason that might be a bad thing?
[11:33] <lifeless> mgz: well, init != setUp
[11:33] <mgz> right.
[11:34] <lifeless> mgz: is 1230am; thats a good question, but I'm just barely managing to delete unneeded tests right now ;)
[11:34] <lifeless> mgz: let me get back to you on it; see if I can page in m thoughts (if I had any prior ones)
[11:34]  * mgz cuts lifeless some slack
[12:00] <mgz> okay
[12:01] <mgz> lifeless, mind if I just propose this to lp:python-oops-ampq so you can look at the diff at your leisure?
[12:01] <lifeless> mgz: uhm yeah :) - 20 folk will get mail, and someone will review it
[12:02] <mgz> ...maybe pastebin would be wiser
[12:02] <lifeless> you could just push a branch up, no need for the proposal angle
[12:02] <mgz> good plan
[12:05] <mgz> okay, `bzr diff -r2..3 lp:~gz/python-oops-amqp/rabbitserverresource`
[12:05] <mgz> I think that's correct, and should do bascially the same thing as the current formulation
[12:07] <mgz> it doesn't seem very generalisable without defining a specific interface on top of fixtures though
[12:08] <lifeless> I will look tomorrowish at it; 1am now, just winding down for halt()
[12:08] <mgz> night :)
[12:26] <deni> hi guys.... does bzr have something like git submodule?
[12:57] <deni> anyone?
[13:01] <briandealwis> deni: I've not actually used git submodule, but from what I vaguely understand, you might want to check out bzr-externals
[13:02] <briandealwis> deni: there's a similar project called scmproj that has a different approach
[13:18] <deni> briandealwis: tnx i'll check it out
[15:25] <jelmer> maxb: hi
[15:25] <maxb> hi
[15:25] <jelmer> maxb: Is there a branch with the python-helper used in the daily PPA?
[15:25] <maxb> there is
[15:26] <maxb> somewhere.... :-)
[15:26]  * maxb hunts
[15:27] <maxb> https://code.launchpad.net/~maxb/ubuntu/maverick/python-backport-helper/ppa
[15:27] <maxb> apparently
[15:27] <maxb> Which surprises even me
[15:27] <maxb> Suggestions of a better place welcome
[15:28] <jelmer> maxb: Is it used by just bzr at this point? If so, would you mind having it owned by ~bzr?
[15:28] <maxb> That's fine
[15:29] <maxb> It's not used elsewhere
[15:29] <maxb> (But having it under ubuntu/maverick isn't exactly helpful either)
[15:29] <jelmer> yeah
[15:29] <mgz> if I'm a plugin, how do I go about adding something to the library_state?
[15:30] <jelmer> mgz: that's a good question
[15:31] <mgz> it seems I can address it as bzrlib.global_state by the time I'm imported, but I don't know if that's the right way or not
[15:31] <jelmer> maxb: and that's used by both lucid and maverick?
[15:31] <maxb> yes
[23:53] <poolie> hi maxb
[23:54] <maxb> hello