[00:08] emmajane: ping [00:35] Hello! I apologize if this is the wrong place to ask this, but does anyone here use the bzr-p4 plugin? I'm trying to understand just what it does but the documentation on it appears to be rather minimal. [00:36] you can try bzr help p4 (if thats what the directory for the plugin is called) [00:36] I don't know how complete it is [00:36] Ah, OK. I supopse I'll isntall it. Just trying to read more of it before I install it - not sure if it will solve my problems or not. [00:37] but most foreign VCS plugins allow 'bzr pull' 'bzr branch' etc to Just Work with urls/locations in those systems [00:37] Ah, neat. Maybe that is something similar to what I want. Is bzr push normally facilitated as well, or is it usually up to the client to use the other VCS' tool for that? [00:37] depends on how complete the plugin is :) [00:38] Ah, but it's not out of the qeustion then at least. [00:38] but yes, certainly for bzr-svn and bzr-git the whole gamut of push/pull/branch/merge commands work [00:38] Swank. I will have to dabble with this. Perforce is getting on my nerves. [01:16] ALright, dumb question. How can I see what plugin directory bzr is scanning for? I'm running cygwin on vista, and I've tried $APPDATA/bazaar/2.0/plugins and ~/.bazaar/plugins, and yet bzr plugins doesn't return me any of my nifty plugins. Is there an easy way to get it to spit out the path it's looking up? [01:18] Not directly, I don't think. But it should be a 'plugins/' subdir under the 'Bazaar configuration' dir that `bzr version` spits out, I think. [01:19] Genius, that works. Thanks fullermd. [01:20] Ah, right. I had reset my BZR_HOME in order to try and keep my linux/windows configurations the same. D'oh, should've checked the env. variables. :/ [01:20] Maybe there should be an arg to 'plugins' to list the search path. [01:20] I was hoping --verbose would show it [01:20] fullermd: Might be a nice add. [01:20] Nah, that just shows where the existing plugins are from. [01:20] i'm getting the following error after attempting to bzr co with http basic auth against loggerhead: [01:20] bzr: ERROR: exceptions.KeyError: 'user' [01:21] (interactive or provided in the url) [01:21] fullermd: Right. I guess my assumption was it woudl say, "Found the following plugins from scanning these paths [searchpath1,searchpath2,searchpath3]: plugin1 [plugin1path], etc." [01:21] Not that it matters, but that was where my intuition took me. [01:24] It's a reasonable intuition. You should file a bug on it. [01:26] jdub: hmm, sounds crummy. pastebin a full traceback? [01:27] spiv: http://www.gnome.org/~jdub/2009/bzr-20091021002215-9259.crash [01:31] fullermd: Good idea. Done: https://bugs.launchpad.net/bzr/+bug/456834 [01:31] Launchpad bug 456834 in bzr "Command "bzr plugins" - would be nice to output searchpaths somehow." [Undecided,New] [01:47] jdub: is loggerhead doing the auth, or some front-end web server? [01:48] lifeless: front end [01:48] how are you passing the user details to the backend then ? :) [01:49] lifeless: not sure i am; if anything, i don't want to [01:49] jdub: i'm suspicious of the bzr-svn in that traceback [01:50] mwhudson: you think bzr-svn on the client might be screwing with it? [01:50] it's possible [01:51] ah, you know, yes [01:51] it might be trying to use bzr svn on the http url? [01:51] jdub@sliver:/tmp$ bzr co bzr+http://whitlam.crikey.com.au/code/live/bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://whitlam.crikey.com.au/code/live/.bzr/smart: Unknown response code 403 [01:51] I think you should: [01:51] file a bug [01:51] remove bzr-svn if you don't need it [01:51] see if that helps [01:51] there is a bug, thats for sure. [01:51] jdub: that seems like a more plausible problem in some ways [01:52] jdub: note that bzr+http shouldn't be needed - http:// will probe for .smart anyway. [01:52] yeah [01:52] jdub@sliver:/tmp$ bzr co http://whitlam.crikey.com.au/code/live/ [01:52] bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://whitlam.crikey.com.au/code/live/.bzr/branch-format [01:52] ^ without bzr-svn installed [01:53] ooh, what a lovely little mess :-) [01:53] jdub: 403 sounds like you aren't passing POST to the backend, to me. [01:53] that interactive password request dudie did seem a little svn-riffic [02:01] lifeless: naw, looks like i'm not serving static files at all :_) [02:03] jdub: yes but that doesn't matter [02:03] jdub: there should be a 'smart' POST attempt in the log [02:03] if that is passed through to loggerhead properly, bzr will talk to that, not to static files. [02:05] right [02:05] the smart post hits the frontend with a 403 [02:06] how to bzr pull --preview merge-directive.patch? [02:06] or bzr mssing it [02:18] lifeless: does the smart check attempt to auth before posting? [02:19] jdub: auth is on-demand, when the server gives 401 [02:19] RenatoSilva: I'm not sure missing works with merge diectives [02:20] RenatoSilva: pull --preview should just work [02:22] lifeless: aaaaaaaahhhhhhhhh [02:22] lifeless: *lightbulb* [02:22] lifeless: i should not bar access to .bzr on this host :) [02:23] you want .bzr/smart to work [02:23] not the rest [02:23] [or at least, you *shouldn't need* the rest] [02:23] right [02:23] and you want it auth protected. [02:25] yeah [02:25] does loggerhead work as a smart server with no extra configuration? [02:25] lifeless: oh man... new issue [02:25] bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-46030224:///"') [02:25] james_w: recent versions, yeah [02:25] jdub: ah, shared repo ? [02:26] lifeless: yeah :| [02:26] jdub: there is a bug, Peng will know more [02:26] that's neat [02:26] basically it needs to make the chroot in the backend higher up. [02:26] so I know what needs to be done, I haven't gone and looked at it [02:26] jdub: look for Chroot in the loggerhead code, you can probably figure it out [02:27] jdub: rather than branch.base, it will be branch.repository.bzrdir.root_transport, for the chroot root path [02:28] lifeless: looks like that might be a bzrlib thing [02:28] jdub: nope [02:28] smart server handles this fine ;) [02:28] there's no Chroot in loggerhead [02:28] ugh [02:28] look for smart then [02:29] can i /msg for a moment? [02:30] of course [02:30] wsgi_app = wsgi.SmartWSGIApp(self.transport) [02:31] that's in loggerhead/apps/transport.py, line 85 [02:31] so self.transport needs to be adjusted [02:31] you'll need to find the actual root you want [02:31] and probably need to pass in some adjuster - spiv knwos this much better than I :) [02:32] which in turn gets transport from make_app_for_config_and_path, which gets it from the config [02:33] Which apparently defaults to '.', unless you pass a command line arg? [02:34] I don't really know my way around the loggerhead codebase very well. [02:34] yeah [02:34] spiv: yes, but you know the wsgi helpers in bzrlib [02:34] spiv: you see the problem, right? [02:36] lifeless: pull --preview didn't work [02:36] lifeless: not really, it's calling the right wsgi helper, I would expect that so long as it feeds the right path to it is all good. [02:38] lifeless: iirc someone here noted that pull doesn't have --preview as expected [02:38] lifeless: but I don't know enough about how self.transport is created to know where loggerhead is going wrong [02:39] or where jdub's configuration of loggerhead is going wrong, perhaps? [02:39] spiv: i'm just passing it a path (to the repo) [02:39] spiv: then attempting to co the branch under it [02:40] loggerhead autoserves branches under a repo [02:41] spiv: its the transport of the branch, not the repo [02:41] lifeless: oh, right, yes, I got that bit :) [02:42] spiv: it needs to be shifted up to the repo; but requests at that path need to be shifted down to the branches relative path [02:42] lifeless: I don't know why; the code I've read suggests it shouldn't be [02:42] lifeless: i.e. the code I've seen so far looks like it is doing things correctly [02:43] spiv: if you're not bogged down with critical stuff, I think this is actually well worth treating as high and digging into [02:43] spiv: 0.17 or beyond? [02:43] Hmm, the UserBranchesFromTransportRoot looks a bit suspicious [02:43] jdub: I'm reading the code in trunk [02:43] Not sure how that relates to version numbers ;) [02:44] lifeless: I'm certainly happy to dig for a while [02:44] lifeless: I just posted a patch for that "second push failed to complete" bug [02:44] thanks dudes :-) [02:44] spiv: awesome; I saw it, but got distracted just as I hit the diff [02:44] Lynne has the lurgy now too [02:45] Urgh, lucky Lynne :( [02:46] mary and I think we've been fighting off something this week, so far not so bad but not quite feeling 100% either. [03:02] Ah, found it I think. [03:02] spiv: vitamin C! [03:08] can anyone with windows experience comment on https://bugs.launchpad.net/bugs/455636 to say where to put the ssh key that bzr will use? [03:08] Launchpad bug 455636 in launchpad-code "r/o code download with lp: prefix asks for ssh key" [Undecided,Incomplete] [03:11] thumper: there isn't a place AIUI [03:12] thumper: you run a gui - pageant - and tell it to add the key [03:12] lifeless: hmm, that's about as much as I know too [03:12] that really ought to be in the help file :-( [03:34] * igc lunch [03:39] Hi.. in perforce if I see a change #, I can say 'p4 describe ######' and it shows me al the changes associated with that.. does bzr have something similar? Right now I have to find the previous revision and use bzr diff.. [03:39] jdub, lifeless: so I have a fix for your bug, but now I'm hitting https://bugs.edge.launchpad.net/bzr/+bug/348308 [03:39] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308) [03:39] spiv: boh! [03:40] jdub, lifeless: will keep poking after lunch, that bug was going to bubble to the top of my list sooner or later [03:41] SpamapS: You don't have to find the previous revision, you can use '-c'. [03:41] fullermd: ahh thats what I get for only paying attention to the examples and not reading the whole manual. ;) [03:42] SpamapS: (and technically you don't need it with -r either, -c is just less typing ;) [03:43] SpamapS: "bzr diff -c$REV" == "bzr diff -rbefore:$REV..$REV" [03:51] spiv: sweet [03:51] spiv: that is the bug isn't it :) [04:04] oh _that_ bug! [04:05] fullermd: thank you.. :) [04:20] I've been using a workflow like: bzr init-repo repo; bzr branch svn-trunk bzr-trunk; bzr branch bzr-trunk bzr-feature; hack on bzr feature; cd bzr-trunk; bzr merge ../bzr-feature; bzr push [04:20] Trying to bzr diff -c a merge commit from a branch outside that repository causes bzr to crash. Are there any workarounds for this? [04:21] huh. what version of bzr? [04:21] 2.0.1 from the jaunty ppa [04:21] huh, dang. [04:22] I've never seen that happen [04:22] what crash [04:22] bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository(path) has no revision [04:24] interesting [04:24] can you try -r before:X..X PATH/TO/BRANCH [04:24] as in 'bzr diff -r before ..... [04:25] Sorry, what should the X's be? The revision number of the merge commit? [04:25] If so, the same crash happens [04:26] fullets: yes, exactly. [04:26] Also -r m..n that cross the merge commit give the same crash [04:26] fullets: if you cd to that branhc [04:26] and then run the command, does it work? [04:27] It crashes whether the branch, repo, or the repo's parent dir are my cwd [04:29] does 'bzr log' work when the branch is your cwd [04:31] Yes, both displaying the whole log and the log for the merge commit work. Trying to show the merged revisions with --include-merges shows none of the merges [04:33] log -n0 will do that [04:33] I think you should file a bug [04:33] if log works but diff -c doesn't, there is something very strange going on. [04:35] I shall file a bug once I finish putting steps to reproduce together :) [04:42] fullets: please file the bug earlier [04:42] fullets: as you may need our help to diagnose it, and bugs provide a place to track the conversation [04:42] Very good [04:53] how do I create a branch with the LCA of two other branches? [04:54] thumper: cd two; bzr revision-info -r ancestor:one [04:54] then bzr branch -r revid:.... one [04:55] lifeless: https://bugs.launchpad.net/bzr/+bug/456908 [04:55] thanks [04:55] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456908) [04:55] bug 456908 [04:55] Launchpad bug 456908 in bzr "Merge commits in branch of subversion repository crash on diffing" [Undecided,New] https://launchpad.net/bugs/456908 [04:55] lifeless: ta === kirkland` is now known as kirkland [06:17] jdub: http://bzr.pastebin.com/m5e6d6205 [06:18] jdub: there's a couple of minor debug droppings in that (the print statement and the commented out pdb line), but that makes serve-branches work for me with a shared repo [06:18] jdub: I'm working on a proper fix for the bzr bug that works around [06:20] spiv: rocking -- thanks! :-) [06:20] spiv: nice [06:21] spiv: beautiful :-) [06:22] spiv: what are the chances that will work with --allow-write? :-) [06:24] jdub: I don't see why it wouldn't :) [06:28] thumper: btw, https://answers.edge.launchpad.net/bzr/+questions?field.search_text=ssh+windows&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status=ANSWERED&field.status=SOLVED&field.status-empty-marker=1 has some info about ssh and windows if you're prepared to dig a bit === obstriege is now known as obst [06:33] spiv: it does, btw :-) [06:37] spiv: You rock! Thanks for working on this! :) [06:40] james_w: is there a PPA with bzr builder in it? [07:16] mwhudson: ping [07:37] hello all [07:37] Hi. :) [07:47] Ah good, I have what seems to be a working fix for the bzr+http bug and a draft of a reasonable test. [07:48] * spiv heads to yoga class feeling satisfied [07:48] spiv: I love you. :) [08:46] sigh. dependancy hell for the win. === weigon_ is now known as weigon [09:39] * igc dinner [09:49] hello all [09:50] long time ago, I found a plugin for bzr that implemented a "make-log" command a la tla [09:51] Now I can't find it anymore... anyone ever heard of it? [09:57] what did make-log do? [10:00] It created a log file, to which you appended what you were doing until commit [10:00] and you couldn't commit without that log file [10:01] what does it do different to 'touch x ; edit x ; bzr ci -F x' [10:02] not much, but you can commit anyway this way [10:07] and make-log sort of forced you to behave [10:14] Is `bzr svn-import` supposed to work from a client checkout of an svn repo? [10:15] Kamping_Kaiser: Not sure. It's not hard to get the URL, though. [10:15] I gen an error "bzr: ERROR: No Repository found at gns/builder-clean. For individual branches, use 'bzr branch'." when trying to run it against an svn checkout (I don't hae access to the svn repo) [10:15] Peng_: ah, i'm supposed to run it on the url? [10:16] * Kamping_Kaiser tries [10:18] aaah. *yay* [10:18] Peng_: thanks :) [10:19] Kamping_Kaiser: :) [10:19] Kamping_Kaiser: FYI, if you *did* have a copy of the repo locally, you could run it against the directory path too. [10:19] Probably. [10:22] good to know, thanks. [10:28] lifeless: https://edge.launchpad.net/~dailydebs-team/+archive/bzr-builder [10:32] perhaps a strange question: having vampired out of the svn repo, i have a 34mb .bzr directory, and the builder/ directory is empty. is there a non-obvious step involved in making the repository useful? [10:33] Kamping_Kaiser: svn-import doesn't create working trees by default. cd to a branch and run "bzr checkout". [10:33] ah. [10:34] Peng_: would it be worth noting that somehow on the help (bzr help svn-import)? (sorry if it is, in newer versions) [10:34] Kamping_Kaiser: I'm running the bzr-svn trunk, and it does mention it. [10:34] Peng_: no worries then. thanks for checking! [10:42] caw. its there [10:42] thanks so much\o/ [10:43] jam: StaticTuple.as_tuple() doesn't recursively convert other StaticTuples inside the StaticTuple to tuples. Do you think it should? [10:43] jam: In other words, is that a bug or a feature? :) [11:38] beuno: ping [12:10] шпсЖ зштп [12:10] igc: ping [12:10] hi bialix [12:11] I want to convert cvs repo of FTE to bzr [12:11] I've managed to rsync entire repo from sf.net [12:11] can you point me where to start? [12:11] should I use instructions from here: http://cvs2svn.tigris.org/cvs2bzr.html [12:12] bialix: start with http://doc.bazaar-vcs.org/migration/en/data-migration/index.html [12:12] or your plugin has inside something else? [12:13] bialix: if the instructions aren't clear, we need to improve them [12:13] ok, I'll read [12:13] will ask questions tomorrow [12:13] bialix: fast-export-from-cvs calls cvs2bzr to do the export [12:13] aha [12:14] cvs2bzr page mentions some options.file [12:15] bialix: hopefully you don't need a custom options file. If you do, I think fast-export-from-cvs allows you to provide one [12:16] igc: I have installed TortoiseCVS [12:17] I hope it will be enough to use cvs2svn [12:17] as I know it can work with RCS co utility or cvs executable [12:17] do you control this aspect somehow? [12:18] igc: ok, help for fast-export-from-cvs is clear, I'll start experimenting and will report all issues I'll encounter [12:19] bialix: thanks. we need to get the process *clearly* documented [12:19] Peng_: test added, patch up for review [12:20] Peng_: feel free to sneak it into your deployment right now and get rid of your monkey patch ;) [12:20] igc: my mileage as typical windows/tortoisecvs user will vary [12:21] Peng_: Btw I discovered that doing that fix was exactly as painful and confusing as I thought it would be, so I feel less bad about not doing it sooner now :P [12:21] igc: and btw, I found gnuwin32.sf.net project is better than unxutils.sf.net [12:22] Peng_: (even though the eventual patch is actually quite clear I think, but fully analysing this stuff is always makes me go a bit cross-eyed) [12:24] igc: unxutils.sf.net is no more maintained and I'm unable to download sort there [12:27] spiv: Heh, that makes me feel better about not trying to figure it out myself. [12:33] spiv: I just confirmed that your fix works. I love you! :) [12:46] Peng_: great, thanks for testing :) [12:51] Peng_: yeah, it's not so much that it's hard exactly. Just that there are just enough confusingly similar variables involved that it's hard to keep track of what's going on. [12:52] spiv: Not to rush you, but you're working on a fix for Loggerhead too, right? What's the status of that? [12:52] All the various path the user sees/path the http request is delivered to/path in the hpss request/path adjusted relative to server backing transport/path relative to request handler etc [12:53] Oh yeah, good point. [12:53] I've even tested that it works (with my fix for bzrlib) [12:53] So I'll file that merge directive now [13:00] Peng_: https://code.edge.launchpad.net/~spiv/loggerhead/shared-repo-fix/+merge/13701 [13:02] spiv: Great. :) [13:03] This is missing the point, but testing with "bzr revno" is clever. I always use "bzr log -r -1 -n 1", which takes a while [13:04] Peng_: :) [13:04] Peng_: a while to type if nothing else! [13:04] Yeah, that too. [13:10] night all [13:11] g'night [13:19] Peng_, hi [13:24] beuno: I just wanted to say that lp:~beuno/loggerhead/yui3-0-0 is redundant. I pushed a similar branch to lp:~mnordhoff/loggerhead/yui-3.0.0 and lp:~loggerhead-team/loggerhead/yui-3.0.0, which also handles a couple of renamed files better. === mrevell is now known as mrevell-lunch [13:26] Peng_, did you get it working? [13:31] beuno: No. I didn't do anything more than update the copy of YUI. [13:33] Peng_, gotcha. I will see if I can spend an afternoon fixing it. I have some idea of what needs to be tweaked [13:34] Oh, good. :) [13:35] Peng_, did you get the LP tshirt? [13:36] beuno: Not yet. [13:37] mrevell-lunch, do you know anything ^ [13:37] * beuno has delegated the problem to a smarter person [13:40] Hi! [13:41] Is bzr able to handle concurrent commits on a "dumb" server (like FTP)? [13:41] nil1, yes [13:41] thanks! [13:42] There are very brief windows where the repo will be write-locked, though, no? [13:42] Does it require a reliable locking mechanism? [13:43] (locking in the sense of a .lock file being written) [13:43] nil1: Yes. Bazaar implements said reliable locking mechanism itself. It works fine over FTP. [13:43] yes, it locks the repo for brief moments [13:43] I guess that would limit how concurrent it can be [13:44] I use the FTP interface of the Tahoe storage grid, where the latency is probably higher than on a normal FTP server [13:47] I'll ask them if writes are reasonably atomic [13:47] (them = Tahoe devs) [13:47] nil1, let is know :) [13:47] will do! === mrevell-lunch is now known as mrevell [13:52] Using StaticTuple in Loggerhead is fun. There are currently fewer tuples than lists in memory. :D [13:55] Peng_, did it have an impact in memory usage? [13:57] beuno: It's way too dynamic to be sure. [13:59] Peng_ Your t-shirt'll be in the post today. [14:00] mrevell: Yay! [14:02] thanks mrevell [14:08] Peng_ I've just been told that it has now been sent. [14:10] Peng_, spiv's branch looks good to land now, want to merge it yourself or want me to? [14:12] beuno: You can if you want to. [14:12] mrevell: Thanks! :) [14:12] beuno: But I don't mind doing it. [14:12] Peng_: woo [14:12] * spiv -> zzz [14:13] spiv, thanks [14:13] Peng_, go for it [14:13] beuno: 'kay [14:17] Pushing now [14:19] woo! [14:22] (Pushed again, cuz I forgot to mention bug #348308 in NEWS.) [14:22] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308) [14:22] I can never merge something in just one revision. :P [14:24] heh [14:33] jam: ping === Island_Usurper is now known as IslandUsurper === pickscrape_ is now known as pickscrape [14:36] Could someone explain to me what the --incremental option of bzr svn-import does? [14:39] pickscrape: "bzr svn-import --incremental" is to "bzr svn-import" as "bzr pull" is to "bzr branch". [14:40] Peng_: Ah, so if I have an import that I have to kill due to it using 13G of ram, using that option will allow it to carry on from where it left off? [14:41] pickscrape: ...Probably. [14:41] Peng_: thanks, I'll try that the next time I have to kill it [14:42] pickscrape: I'm not sure how much of the import will have been saved if you kill it, but it probably will include most of the repo. === abentley1 is now known as abentley === sabdfl1 is now known as sabdfl [15:00] morning all [15:00] spiv: thanks for the reviews, sleep well [15:00] Peng_: wave [15:01] jelmer: it looks like we need an updated bzr-rewrite as wel [15:04] jam: First of all, I'm sorry about pestering you to keep adding features to StaticTuple. Thanks to all of your work, I finally got the Loggerhead branch working. :) [15:05] Peng_: good to hear. Did you see my recent patch to support more object types? [15:05] That should land in bzr.dev today [15:05] jam: Yeah, I'm using it. [15:05] it will change slightly, but not dramatically [15:05] jam: Anyway, on to the continued pestering: The only other things I could want are these, but they're not necessary: Pickle support, and the ability to pass a generator to from_sequence. [15:06] jam: What do you think? Like I said, they're not necessary, but they would be nice. [15:07] Peng_: from_sequence(tuple(generator)) should work fine :) [15:07] and essentially give the same results [15:07] I have to iterate the generator because ST is a fixed-width object [15:07] jam: OK. [15:07] given that, from_sequence(list(generator)) might be better [15:07] I'm not clear on the tuple internals wrt a generator [15:08] from_sequence(list(generator)) might be better than from_sequence(tuple(generator))? Why? [15:08] Peng_: because tuple() is also fixed width, so it has to somehow stage the whole generator result somewhere [15:08] and then create a tuple [15:08] *list* can grow [15:09] so it can stage the contents into itself [15:09] jam: Ahh, interesting. ...It probably doesn't matter much, though. [15:09] Peng_: looking at the internals of PySequence_Tuple() it re-allocates the internal tuple [15:10] holding a size of 10, and then reallocating over and over as it grows [15:10] so I guess ~ the same as List does [15:10] Pickle support... I really don't know what it takes to tell pickle about a custom type [15:11] I think these tuples are only like 1 or 2 items long, so it shouldn't matter much. [15:12] http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types [15:12] Oh, I hadn't scrolled down that far in the docs. [15:13] jam: BTW, your merge proposal got the LP equivalent of bb:tweak, more or less. Have you seen it yet? [15:13] Peng_: yeah, I'm cleaning it up now [15:13] jam: ok :) [15:19] Peng_: so if pickling is important to you, I'm happy to look over a patch, give suggestions, etc. I'm probably not going to worry about it myself, though. [15:19] In general, I think it wouldn't be too hard [15:19] you just have to implement __reduce__() and __setstate__() [15:20] except __setstate__() sounds like it happens *after* the class has been instantiated [15:20] Step 1: Learn C. :P [15:20] Peng_: if you wrote it sufficiently in Python, translating it to C wouldn't be hard (for someone) [15:21] you could try doing it on the pure python StaticTuple type to start with [15:21] or if it 'just gets' it from 'tuple', check what to do there [15:22] they also mention that you can do this 'after-the-fact' by registering with the 'copy_reg' module [15:23] http://docs.python.org/library/copy_reg.html#module-copy_reg [15:23] that may work better, as it can [15:23] 1) probably be done in pure python [15:24] 2) you can be more sure that you don't have to construct an object and then call __setstate__ on it [15:24] hmm.. maybe no nee [15:24] need [15:24] given the callable you pass takes a tuple of arguments for the callable [15:25] I just tested a copy_reg one-liner. It whined about __builtin__.StaticTuple not existing. [15:26] Peng_: did you have _static_tuple_c imported before you did the unpickle? [15:28] jam: I had "from bzrlib.static_tuple import StaticTuple". [15:29] so potentially that is the pure python class, though not if everything is working correctly [15:29] jam: It's the C version. [15:29] I note that the C StaticTuple has no __module__ attribute. [15:32] interesting, given that 'tuple' itself does [15:35] Peng_: actually *instances* of tuple do not have the __module__ attribute, but t.__class__.__module__ does [15:35] and [15:35] >>> _static_tuple_c.StaticTuple.__module__ [15:35] '__builtin__' [15:35] I don't specifically know how to change that [15:35] as I don't see where it is set [15:40] it seems to be in 'typeobject.c' a function called type_module() [15:40] and it looks like if you set "tp_name" to "bzrlib._static_tuple_c.StaticTuple" then it will get a module [15:41] otherwise it defaults to __builtins__ [15:42] Peng_: give this a shot: http://paste.ubuntu.com/298325/ [15:44]