[00:13] lifeless: The LP URL isn't stored anywhere. The code can usually guess it, but not always. [00:13] lifeless: Plus, not every branch is mirrored on LP. [00:13] lifeless: It's probably still do-able, but it requires a little thinking, which I haven't wanted to do. :P [00:14] Peng: americans these days! [00:14] Why are the branches not hosted on LP? [00:14] wgrant: Why don't I host my branches on LP? [00:14] Peng_: Right. [00:15] wgrant: Eh. If I did host them on LP, I'd only be using my VPS for ntp and irssi. How'd that be fun? [00:18] Peng: it sounds better if you claim to be "testing" it ;-P === davidstrauss__ is now known as davidstrauss [01:41] morning (ish) [01:41] hello [01:41] how're the old positrons? :) [01:47] they keep annihilating the electrons. === jam1 is now known as jam [02:30] hi poolie! [02:30] hi igc [02:30] poolie: how's the email mountain? :-) [02:31] substantial :) [02:34] .-=^=-. [03:54] mwhudson: question about python for you [03:54] It seems that subclassing from tuple gives me an object that is 8-bytes bigger [03:54] until I add an attribute, then it seems to grow a __dict__ and blossom another 140 bytes [03:54] heh [03:54] Even adding __slots__ = () [03:54] it still seems to have the extra 8 bytes [03:54] do you know why? [03:55] python type vs native type? [03:55] lifeless: yeah, I was worried that the pure-python StaticTuple would have a __dict__ all the time, so I added __slots__ = (), only to find 0 change on normal instances. === Adys_ is now known as Adys [03:57] anyway, I haven't found the code that handles subclassing builtins, other than "tuple_subtype_new" [03:57] but that doesn't seem to indicate what 'tp_alloc' is set to for the new class instance [03:59] jam: hmm, that does seem to be the key question [03:59] spiv: anyway, I can live with 8 bytes overhead for StaticTuple instances when they don't compile extensions [04:00] versus 28 for the ST instance if we wrapped a tuple instead of subclassing it [04:00] jam: not off the top of my head [04:01] jam: gdb says PyType_GenericAlloc [04:01] mwhudson: I thought you might have some inkling, as I thought you mentioned when 'tp_dict' is negative [04:01] jam: i probably knew once :) [04:01] spiv: right and that is just based on "tp_itemsize" and "tp_basicsize" [04:01] so we need to figure out what is setting "tp_basicsize" [04:02] * igc lunch [04:03] jam: for me, the tp_itemsize and tp_basicsize are the same for a trival "class T(tuple): __slots__ = ()" and tuple. [04:04] spiv: so I posted some testing here: [04:04] https://code.launchpad.net/~jameinel/bzr/2.1-pure-static-tuple/+merge/14006 [04:04] can you reproduce? [04:04] (creating 1M instances of a child of tuple is 8 bytes more memory than 1M instances of tuple) [04:04] which is 16 bytes more memory than 1M instances of _static_tuple_c.StaticTuple [04:04] regardless of __slots__ [04:07] spiv: I *do* see that if you have "add_dict" set, then it adds a pointer to the end of the instance. And I think I see that add_dict should be set to 0 if __slots__ is set. [04:08] but that doesn't seem to be what I'm seeing in practice... [04:11] sure its not a type pointer? [04:11] * lifeless is speculating [04:12] lifeless: all objects in python have a type pointer, even 'tuple' [04:12] so it should be able to just re-use that location [04:12] since it is fixed for inspection [04:12] it could be a mro or something like that [04:13] however, looking at "typeobject.c" [04:13] essentially "type->tp_basicsize = base->tp_basicsize + (add_dict ? 1 : 0) + (add_weakref ? 1 : 0) + (num_slots) [04:17] spiv: in my testing, I even see it if I comment out all of StaticTuple's implementation except for the __slots__ statement. [04:18] jam: I see no memory difference under 2.6 between [tuple([n]) for n in range(1000000)] and s/tuple/T/, where T is that trivial subclass with empty __slots__. [04:19] spiv: oddly enough, I *do* [04:20] jam: I *do* see different results with zero-length tuples [04:20] i.e. pass [] instead of [n] [04:20] spiv: well there it is because 'tuple()' is a singleton [04:20] Right. [04:21] jam: my testing method is pretty simple, I'm running this: [04:21] python -c "T = type('T', (tuple,), {'__slots__': ()}); x = [T([n]) for n in range(1000000)]; print 'ready'; raw_input()" [04:21] jam: and then looking at /proc//status [04:21] jam: what python version do you have? [04:21] lifeless: 2.6.2 [04:21] spiv: and you ? [04:21] spiv: "trace.debug_memory()" on windows [04:21] which looks at /proc/pid/status on linux [04:21] 2.6.4rc2 [04:21] right [04:22] I suspect its the __slots__ change which broken boost-python in 2.6.3 [04:22] * lifeless handwaves furiously [04:22] lifeless: that could be... [04:27] spiv: on Python 2.4.3 under linux I see no difference with __slots__ and 8 bytes without __slots__ [04:31] jam: *nod* [04:34] spiv: I just upgraded to python 2.6.4, and I still see the same thing... [04:34] very very strange [04:35] w/ or w/o __slots__ it adds 8 bytes [04:35] maybe an alignment thing? [04:35] subclasses not being as tightly aligned... [04:36] anyway, the merge proposal is still good to have, as it helps somewhere (on spiv's machine. :) [04:45] * jam wanders off to bed [04:46] jam: I just hit approve, btw [04:46] jam: in case you want to do a PQM submission from bed ;) [05:40] lifeless: do your changes in dirstate2 reduce it's size? IIRC, you were looking to take one of the 'columns' out weren't you? [05:56] igc: I haven't done that [06:29] Will anything blow up if I symlink a shared repo's .bzr into a subdirectory, in order to segregate my branches? [06:30] wgrant: the .bzr/repository directory? [06:30] mm [06:30] it's not really supported [06:30] poolie: I was thinking the entire .bzr. [06:30] what exactly do you mean? [06:31] poolie: I have ~/launchpad/lp-branches with lots of branches in it. [06:31] I have a particular line of work which will need about a dozen branches. [06:31] I want this to live in a subdirectory. [06:32] So the related branches are obvious and separated from the rest. [06:32] ok [06:32] igc: I'd be delighted to brain dump/find my old notes on removing columns [06:32] wgrant: it will work fine [06:33] so i don't think you need to do anything with symlinks [06:33] wgrant: but its not need, just use a subdir [06:33] lifeless: That's what I thought, but best to be safe. Thanks. [06:33] just make a subdir [06:33] wgrant: 'mkdir project'; bzr branch trunk project/1 [06:33] etc [06:33] wgrant: you can have an arbitrary number of subdirectories between a repo and a branch, though.. [06:33] spiv: Oh, it will look all the way up? [06:33] wgrant: yes [06:33] That's convenient. [06:33] didn't know that... [06:33] wgrant: we aim to please [06:33] lifeless: I think there was a bug report for removing a column. Maybe add them there? [06:33] lifeless: You succeed. [06:33] :) [06:34] igc: are you considering picking up dirstate2 and running with it? [06:34] I won't be following up for a while.. [06:34] wgrant: if there's somewhere in the doc I should change to make that more obvious, please let me know [06:34] lifeless: no [06:34] lifeless: I was just trying to understand some benchmark results [06:35] igc: I haven't read the bzr docs in at least three years. I have no idea what they're like now. [06:35] lifeless: see #461651 [06:36] wgrant: I guess that answers that question :-) [06:36] bug 461651 [06:36] Launchpad bug 461651 in bzr "Implicit packing during branch is often suboptimal" [Medium,Invalid] https://launchpad.net/bugs/461651 [06:36] igc: yes, I saw that [06:37] 11M for a FireFox dirstate seemed large [06:41] igc: getting rid of the the extra tree columns wouldn't shrink that any [06:41] as its not a merged dirstate [06:42] lifeless: ah - ok. Thanks [07:10] hi all [07:10] hello vila! [07:11] welcome back poolie :) [07:12] thanks, it's good to be back [07:18] hi vila! [07:24] igc: So, I decided I should read through some of the docs. They really are excellent these days. [07:24] (where do I file typos in them?) [07:25] wgrant: the docs are genuinely a community effort but, hey, I'll take the credit :-) :-) [07:25] wgrant: unfortunately, it depends [07:25] wgrant: most of the docs are in the core but some, like the migration docs, are separate projects [07:26] wgrant: if you file doc bugs against the core, we can shuffle the assigned project if appropriate [07:26] igc: 'Why Switch to Bazaar?' is the one I just found a typo in. [07:26] wgrant: it's in lp:bzr-migration-docs [07:27] igc: Thanks. [07:32] igc: One other thing I noticed (horrible horrible nitpicking, I know) is that the migration docs don't seem sure on whether to use sentence or title case for various levels of headings. It just makes it look that bit unpolished. [07:33] wgrant: the unwritten rule is Title case for document headings, sentence case otherwise [07:37] igc: I'd be a lot happier if all the docs were in the core [07:37] so the debian package would include them [07:38] lifeless: all the docs can't be in the core - many of them are built from plugins [07:39] igc: I thought that was just the plugin guide one? [07:39] lifeless: other like the website and doc-website bridge multiple releases [07:39] igc: well, the website is differnet [07:40] its /docs/ I care about [07:40] * wgrant will submit a couple of migration docs MPs later tonight. [07:40] if the ReST were generated and committed to trunk, then it could be included in the deb package === GaryvdM is now known as Guest54289 === GaryvdM_ is now known as GaryvdM [08:21] Hi lifeless [08:21] lifeless: I'm looking at bug 320236. [08:21] Launchpad bug 320236 in bzr-search "Index authors" [Wishlist,Triaged] https://launchpad.net/bugs/320236 [08:21] lifeless: Would it be allright if specified the field that a term applies to in the document_key [08:22] lifeless: e.g. for authors/commiter : ('r','a',rev_id) [08:23] I'd hesitate to do that [08:23] its not a good use of the index space [08:23] either index with a more appropriate term [08:24] ('author', 'fred') [08:24] or query the matching revisions to filter more [08:24] lifeless: Ok - I think I'll index with a more appropriate term [08:25] GaryvdM: my advice though [08:25] GaryvdM: post process [08:25] accessing revisions is fast [08:25] and you'll already have a short list [08:25] lifeless: Ok [08:25] adding more data to the search index is likely to just slow things down [08:26] *if* data shows that it would make a huge difference, then I'll happily drill into this in more detail with you [08:27] consider though - how many revisions would have a hit for 'Robert' and not have that be author/committer [08:27] [remember that you won't be comparing against file texts here] [08:28] lifeless: Yes - that makes sense. [08:40] lifeless: you know there are still 3 test failures for loom ? (Related to switch) [08:40] vila: no, I didn't [08:40] unless, perhaps, I put up a branch for review [08:44] lifeless: ./bzr selftest -s bb.test_switch trigger them all [08:47] * igc dinner [08:49] vila: have you filed a bug on loom? if not, please do so [08:51] lifeless: ok [08:54] bug #461743 [08:54] Launchpad bug 461743 in bzr-loom "test failures related to switch" [Undecided,New] https://launchpad.net/bugs/461743 === GaryvdM_ is now known as GaryvdM [09:36] anybody have experience with bzr support in maven? it seems that bzr protocol is unsupported and sf.net servers does not provide http access to bzr repo [12:27] Hi igc [12:28] hi garyvdm [12:29] igc: I've been thinking about rename/move for qbzr. [12:29] I want to hear your ideas on ui. [12:29] And bounce some of my own. [12:31] bug 298242 [12:31] Launchpad bug 298242 in qbzr "New dialog for auto rename" [Low,Confirmed] https://launchpad.net/bugs/298242 [12:31] garyvdm:^ [12:32] So the idea I have is that from the treewidget (i.e. qcommit, and qbrowse) you can right click, rename, or you can drag and drop move [12:33] garyvdm: sounds great [12:33] igc: Sorry - I forgot that you had the right up in the bug. [12:34] garyvdm:I like you ideas [12:34] And the other idea that I have is that you can highlight a missing file, and a unversioned file, and right click, "Mark as Move" [12:34] igc: Cool [12:34] we could combine them by just showing the dialog I outlined, with ... [12:35] the relevant radio button pre-selected [12:35] igc: I see [12:37] drag n drop would be really nice for move [12:37] garyvdm:^ [12:39] garyvdm: it's my bed time - any other questions? [12:39] igc: Nope. Thanks for your time. [12:39] igc: Sleep well. [12:39] garyvdm: thanks! [12:40] night all === pickscrape_ is now known as pickscrape === mrevell is now known as mrevell-lunch === lamont` is now known as lamont === mrevell-lunch is now known as mrevell [13:53] morning all [13:57] morning jam !!! [13:58] did you intended to vote but forgot on the dwim revspec ? [14:00] jam: the tone of your comment sounds like a vibrant approve but... :) [14:01] vila: I intended to enter the discussion. [14:01] though I do approve the change [14:02] vila: there, feel better :) [14:03] lol, thanks for fullermd :) [14:09] Peng: https://code.edge.launchpad.net/~jameinel/bzr/2.1-st-from-iterable/+merge/14027 [14:13] vila: I'll go ahead and submit his patch then. [14:14] jam: I'm doing right now if you haven't started... [14:14] vila: ah, please do [14:14] I just didn't see it in PQM yet [14:14] pqm'ed [14:15] I had some... weirdness-I-dont-even-want-to-start-looking-at [14:15] rockstar: are you around for a bit of a chat? [14:19] The question is, how do I mark my merge proposal as superseded? [14:37] mwhudson: hi, have you got a tarball of the generated bzrlib API? [14:58] Peng_: you can mark it as "work in progress" and it will be hidden from the review queue [14:59] or "Merged" if you want to treat it as merged into mine... [14:59] I don't have a better way [15:01] Peng_: Or just wait until the patch lands and see if lp marks it merged for you [15:09] jam, hi [15:10] good morning rockstar [15:10] I hope you've had your coffee this morning :) [15:10] jam: I'm confident that LP will mark it merged. [15:10] I'd like to pick your brain a bit about things that the bzr team can do to help you guys [15:10] Huh, set(['foo bar']) is a lot faster than set(StaticTuple('foo bar')) [15:10] most notably, things that *I* should focus on :) [15:11] jam, great. I don't drink coffee shop, but I'm about to head out to one. === cody-somerville_ is now known as cody-somerville [15:11] jam, can it wait about an hour? I have some branches to land. [15:11] rockstar: absolutely [15:11] jam, great. [15:13] when I do a bzr add dir it says it ignored 2 files but doesn't say which [15:13] any ideas how to find out which? [15:15] Bear10_: bzr ignored [15:24] thanks [15:25] see :) [15:25] woops wrong window === deryck is now known as deryck[lunch] [15:40] jam: Thanks for all of your help recently. :) [15:48] Peng_: thanks for your interest [16:04] has anyone experienced problems where the icons just never update, and you have to manually update to see if your still on the same version as the binded branch? === beuno is now known as beuno-lunch [16:49] does bazaar support commit hooks such as buildbots, special handling of certain file types (ie, unzipping an ODF so it's contents are stored in VCS and diffed vs the zip as a binary blob, metadata checked and passed, etc) [16:49] Bazaar does have good hook support, so they can probably be used for all of that. [16:50] do the hook distribute to users? [16:50] or do they need to be manually installed by each committer [16:52] looking at bazaar from the mercurial model [16:52] especially for hosting media [16:54] Arc: Manually installed. [16:55] so we're not really better off with bzr over hg [16:56] except for perhaps the licensing issue, which hg is very sub-optimal for [16:57] It is? [16:57] mornin' [16:57] GPLv2 only vs GPLv2+ [16:57] GPLv2-only is not AGPLv3 compatible [16:57] Arc: I think they're working on GPLv2+. === deryck[lunch] is now known as deryck [16:57] Or already did it. [16:58] really? I thought their maintainer was dead set against it [17:00] Arc: I think he suddenly and quietly changed his mind. I'm not sure, though. [17:00] ok [17:02] Is GPLv2+ AGPLv3 compatible? [17:02] I wouldn't have thought that it would be [17:03] yes, because the GPLv3 is AGPLv3 compatible [17:04] GPLv2->GPLv3->AGPLv3 [17:04] GPLv3 section 13 makes it so [17:06] ah, thanks [17:07] we're building a web framework for our project that is licensed under the AGPLv3, and would really like to get mercurial integration [17:11] Arc: See the thread in mercurial-devel "Re-licensing email", starting 2009-10-14. [17:12] Peng_: i just read, thanks :-) [17:14] is there anything special I need to do to `import bzrlib` on windows, having installed with the default installer? [17:17] aha, got it! [17:17] didn't think to look in the zipfile [17:32] jelmer: can I interest you in what appears to be a bzr-svn data corruption bug? it's happening to the grub project, who are just looking at adopting bzr; unfortunately at the moment they're using the bzr/bzr-svn from Debian lenny (but could be persuaded to upgrade if I can demonstrate that some of their problems would go away with newer code) [17:33] jelmer: jml took a look at it here and said "uh, this probably needs John or Jelmer" :-) [17:34] anyone with python on win64 want to do a `python -c "import sys; print sys.platform"` for me? [17:34] cjwatson, I was _so_ much more eloquent than that. [17:35] cjwatson, I was using internal rhyme and everything. [17:35] jml: :-) [17:36] mwhudson: ping, if you don't mind doing some hand-holding. [17:36] Tak: Maybe try #python. [17:37] What OSes are used at Canonical? Just Ubuntu? :D [17:37] or maybe not!!! [17:37] Tak: Why not? [17:40] Peng_: bzr is cross platform! === beuno-lunch is now known as beuno [17:46] jelmer: bug 462109, if you're interested [17:46] Launchpad bug 462109 in bzr-svn "corrupted branch with bzr 1.5, bzr-svn 0.4.10, and roundtripping" [Undecided,New] https://launchpad.net/bugs/462109 [17:50] mwhudson: Semi-unping. (Sorry, I know that's not very helpful.) [17:55] in case anybody cares, the result is "win32" === EdwinGrubbs is now known as Edwin-lunch [18:02] Hi [18:03] Is there a way to get a tree for NULL_REVISION without a reference to a repository? [18:05] Ah - nvm - I grep and I grep, but I could not find. I asked here, then switch back to my IDE, and it was right in my face :-P [18:05] RevisionTree(self, Inventory(root_id=None), NULL_REVISION) [18:30] I'm trying to figure out how to prevent the merging of a particular file whenever I merge between two branches. We have a hierarchical branch setup, with branch "A" as our release branch, and "A.1", "A.2", etc. as development branches. When a dev branch is ready to release, it merges to branch "A", and then that code is merged down to the rest of the development branches. But I have one branch-specific file that can't be merged during this process. [18:30] must be version controlled, because it is needed in checkouts of the development branches. Any ideas of how to do this? Thanks. [18:30] bzr revert it in between merge and commit, always? [18:30] BrianBatchelder: revert it before you commit the merge? [18:31] I'm not the only one who does the merges, so I'd like it to be automatic. [18:31] shell script time :) [18:32] Is there a simple way to hook the merge operation and automatically revert it? [18:36] Or perhaps limit the users who can modify that file? === asac_ is now known as asac [19:15] Peng_: good