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