[00:00] ok, I'm on it, thanks! [00:00] lifeless, spiv, jam, igc, call in a minute if you want [00:02] Good morning. [00:06] poolie: sure, call me [00:08] jam: ping [00:10] lifeless: pong [00:10] poolie: Just made it back into the house, is the call still going? [00:10] jam: it is [00:11] lifeless: can someone on the call ring me? I can at least listen in [00:11] (silent jam) [00:12] jam: thanks for tweaking my patch; is the rest ok with you? time to land ... [00:17] thanks for the help guys, turns out I hadn't unlocked my ssh key [00:20] * beuno wished Loggerhead had tests [00:21] beuno: *write* them :) [00:21] jam, I'm trying wishing first [00:22] mwhudson, does it seem sensible that TemplatedBranchView finds the last revid if none is provided, instead of each controller? [00:24] beuno: yes, i think [00:29] markh: was there anything you specifically wanted for 1.7 that hasn't landed? I'd like to cut 1.7rc1 and i just want to make sure things aren't missing. [00:29] jam: those setup changes would be nice [00:29] I just mailed the list [00:29] markh: I did the TBZR ones [00:29] not sure what other ones [00:29] alex's - remove survey etc [00:29] and maybe the icon? ;) [00:30] markh: I did the icon as well [00:30] thx! [00:30] markh: Well, BB says that Alexander's change is already merged [00:30] so I'm tempted to say it is already there [00:30] is it missing for you? [00:30] I guess I was trusting bundle-buggy - lemme look... [00:31] it wasn't a few days ago iirc [00:31] jam: we still on bzr.dev right? [00:31] markh: well, we do have a branch, but it is 99.99% bzr.dev [00:32] oh - I missed word of that too. [00:33] markh: As near as I can tell, it is in bzr.dev [00:33] BB says 8/21 it landed [00:34] jam: yes, it looks to me like it has too - thanks! [00:34] markh: K, cutting tarballs [00:35] yeah, BB says it is merged, but I don't see a mail from BB in that thread saying it was merged. Oh well, at least it is - thanks! [00:35] Well, good thing we did 1.6.1... [00:37] jam: thanks for tweaking my patch; is the rest ok with you? time to land it? [00:58] mwhudson, http://bazaar.launchpad.net/~beuno/loggerhead/abstract_paths/revision/220 [00:59] Hey. Managed to cause bzr to crash. 1.3.1 on hardy. I tried to --force remove a directory that had already been removed by hand. [01:00] bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: tests/gupnp-test [01:00] Now I cannot use bzr status at all [01:00] Any way to patch the branch up? [01:01] hi wasabi [01:01] "tests/" was what you removed? [01:01] no. tests/gupnp-test [01:01] tests is still there [01:01] mkdir tests/gupnp-test; bzr add tests/gupnp-test; bzr st; bzr rm tests/gupnp-test; [01:01] that should fix it I believe [01:02] that did it [01:02] the bug is fixed in later versions [01:02] 1.6 I believe [01:02] K. [01:02] Thanks. ;) [01:02] no problem [01:02] happy hacking [01:05] spiv: any reason your faster branch isn't up for review? [01:06] * beuno_ -> home === beuno_ is now known as beuno [01:16] gar [01:16] beuno: the stuff to do with all_same_author is cruft since the new_theme landing? [01:16] oh right, it says so in the commit message [01:17] beuno: you don't need to call fix_revid in annotate_ui [01:19] path = None [01:19] [01:19] [01:19] 81 [01:19] if len(args) > 1: [01:19] [01:19] [01:19] 82 [01:19] path = args[1] [01:19] oops [01:19] beuno: ^ that doesn't look right [01:19] for e.g. annotate/100/file/in/subdir [01:23] * jml reads the startup time RFC [01:23] it would be nice if that got summarised into a more static document. [01:24] I didn't expect *quite* that enthusiastic a discussion [01:27] lifeless: it's an interesting topic :) [01:27] lifeless: speaking of enthusiastic discussions, when can we bury the adsorbSuite hatchet? [01:33] lunchtime? [01:34] lifeless: because it was just idle hackery, and I haven't (yet) re-read what I've done to make sure it's not too hackish. [01:37] lifeless: sounds good to me. [01:39] jml: shall we say 12:30? [01:40] cool core. [01:40] mwhudson_, you're right. I'll fix it [01:41] spiv: be useful to write up notes :P [01:41] beuno: i think that you can just path_info_pop the revid, then take the rest of the environ['PATH_INFO'] as the path [01:41] beuno: also, there's some confusion about whether path should start with or end with a / [01:42] beuno: i suggest normalizing it in TemplatedView and then getting rid of the silliness in the subclasses [01:42] mwhudson_, cool, will do. Cleanups are always fun [01:42] right === mwhudson_ is now known as mwhudson === mw is now known as mw|out [02:05] mwhudson: is there a good 'am I leaking references from my C module' tester? [02:05] lifeless: not really [02:05] bugger [02:06] do you know [02:06] lifeless: there's a trackrefs class somewhere [02:06] does PyTuple_SetItem [02:06] dereference the old value at that place? [02:06] or refuse to set the item altogether? [02:06] i don't know [02:07] but overwriting a tuple item is kinda breaking the rules... [02:07] do you know where the tuple code is defined [02:08] mwhudson: I'm creating it in a long winded way [02:08] lifeless: Objects/tupleobject.c [02:08] and writing to the C api, so kthxblah [02:08] (though it might even be a macro) [02:08] ok cool [02:08] it dereferences an old tuple item [02:09] yay for sanity [02:09] lifeless: it decrefs the old value [02:09] the python/c api is *mostly* sane [02:10] I *Love* open source [02:10] being able to check that code myself, FTW> [02:13] lol [02:13] :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))" [02:13] Traceback (most recent call last): [02:14] Command terminated [02:18] lifeless: about startup-time, cleaning up a bit xmloutput plugin, 0.20s gain in 'bzr rocks'. WOW! [02:20] maybe a major call to plugin developers, could help a bit on that area :) [02:27] Verterok: so thats good; better would be 0.2s gained on 'bzr st' [02:27] Verterok: which xmloutput also hooks into, yes ? [02:27] lifeless: indeed [02:27] lifeless: not any more [02:27] mwhudson: how do I found out the refcount of an object? [02:28] lifeless: xmloutput don't override any builtin :) [02:28] now it provides it own hidden command xml* [02:28] Verterok: oh cool, its the rpc service one right? [02:28] yes [02:28] excellent news, thank you :) [02:29] can I pull the new one yet ? [02:29] revno 99? [02:30] lifeless: the point I tried to higlight was that those 0.2s came from not using lazy_import :) [02:31] Verterok: ah right [02:31] lifeless: what branch? [02:31] lifeless: sys.getrefcoutn [02:31] http://bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc/ [02:32] lifeless: branch from lp:bzr-xmloutput, I moved xmlrpc branch to trunk [02:33] Verterok: so the theory of lazy import is 'defer reading code that is not needed', which is good; but its granularity is limited [02:33] Verterok: which is my somewhat more troubling point :) [02:35] lifeless: while moving things to lazy_import I foudn some corner cases, like the need to import SimpleXMLRPCServer (the module) and then doing SimpleXMLRPCServer.SimpleXMLRPCServer :p [02:35] poolie: down to 888ms [02:36] Verterok: yah, moving those to separate modules that you only load when you actually need the subclass might help [02:36] jam: where should I put the 1.7 binaries for windows? [02:36] Verterok: but only if you only need the subclass sometimes [02:36] (bzr's launchpad page has the most recent announcement as 1.6rc4 being released...) [02:37] because if I lazy_imported SimpleXMLRPCServer (the class), I get: "TypeError: Error when calling the metaclass bases" [02:38] Verterok: heh [02:38] Verterok: thats a bug in something, I don't recall if its the class machinery or lazy import [02:38] lifeless: yes, I did exactly that, moved all cmd_* to __init__.py, and most heavy imports into modules not used in cmd_* declaration [02:39] poolie: you're welcome to work from here tomorrow, btw. [02:40] http://rafb.net/p/7lNeKY31.html [02:40] lifeless: the traceback, in case it helps ^ [02:40] mwhudson: you'll probably shoot me when you see my code :P [02:41] 848ms per loop now [02:43] lifeless, relative to what? [02:43] spiv, thanks very much [02:44] spiv, if i'm organized enough to go before rush hour i'll turn up just before the 9am call, otherwise later [02:44] (in which case i may miss it) [02:46] you could turn up here if you'd like. [02:47] being something close to a midpoint [02:47] poolie: 1000ms in bzr.dev [02:47] jml: where is here now? [02:47] 812ms now [02:48] lifeless: lindfield. [02:48] i assume he means pymble or lindfield [02:48] i'm taking my bike to the shop in hornsby, so it's logically closer [02:49] poolie: oh, I see. [02:49] to get a new shlock absorber so i can cope with robert's puns [02:49] heh [02:51] but it would be nice to come over some time [02:54] poolie: schlock mercenary ftw [02:59] damn [02:59] I locked myself out of my server [02:59] lol === beuno_ is now known as beuno [03:00] damn [03:01] real world result: [03:01] :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])' [03:01] 10 loops, best of 3: 3.68 sec per loop [03:01] :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])' [03:01] 10 loops, best of 3: 3.84 sec per loop [03:02] I'm going to keep driving it down === beuno_ is now known as Guest88559 [03:26] jml: now ok? [03:35] dinner! [03:50] lifeless: * resource dirty markers on non current resources - ignore? keep a history ? [04:02] I want to keep some db schemas in a nicely diffable format [04:02] does anyone know of something good that will do that? [04:02] (sorta OT I know) [04:03] mlh, do you mean as an alternative to sql data definition language (if that's the right name) [04:06] (replying to this naming thread) [04:09] 745ms [04:09] EFOOD [04:17] poolie: well ddl defines the db, I want to go the other way; db-> ddl [04:18] I know of a bunch of products that would do it ok, but I'm particularly looking for a complete, portable (ok, oracle) version [04:18] mature [04:20] i don't know [04:21] aiui launchpad commits to a bazaar branch a series of 'alter table' etc statements which are replayed in order to update the database [04:21] then from time to time they checkpoint the entire definition [04:21] yeah that's what we do currently (except the for checkpointing :-) [04:22] but rather than commit 'alter table' statements, I'd rather commit the state of the db everytime and derive 'alter table' statements from that [04:24] so I could generate sql ddl but it might not be so easy to derive the 'alter ...' statements [04:24] right [04:24] in particular explicit relations are not enough to define logical sanity [04:24] IDEALLY, you'd build the entire database every time, like you'd do a compile [04:24] mlh, the alter statements have information about how to update existing data that's not present in the creation from scratch [04:24] but it's just far too expensive for any decent size database [04:24] deltas -> snapshot is possible, snapshots -> deltas isn't, unless all possible constraints are defined within the db [04:24] well, that's not enough if you need to update existing data [04:25] poolie: example? [04:25] uhm [04:25] my syntax will be wrong but [04:26] alter table customers rename column hair to hair_color; [04:27] well I won't disagree, but I'm thinking it's not a fundamental restriction [04:27] well, a diff between the overall ddl would presumably just drop and add that column [04:27] so, at some level the information about how they relate needs to be captured [04:28] oh ok. I could infer a rename, git style :-) [04:28] this is what I mean, that you can start with deltas, but not with snapshots [04:28] and we know how well that works :) [04:28] but that is kind of a trivial example, suppose you're renormalizing to split a table into two or more [04:29] well fair enough [04:29] at a first passt (and possibly ultimate) I was more interested in validating a schema rather than producing it [04:29] so I upgrade the db as usualy with 'alter ...' and whatever [04:30] at some point I'd save the ddl [04:31] I can then double check the upgrade operation by dumping the ddl and comparing to what's in bzr (dumped from the 'official' db) [04:34] fwiw, in my experience tables hardly ever get normalized .. it's just too hard [04:34] heh [04:34] mlh: theres a bunch of stuff in the xp world on managing db evolution [04:35] mlh: basically revolves around having a apply, revert methods on a class per evolution step [04:35] you could generate a 'is this correct' by doing that to an empty db and dumping the resulting schema [04:36] 3.51 seconds for st now [04:36] down from 3.84 === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available! please test bzr-1.7rc1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [05:25] markh: https://edge.launchpad.net/bzr/1.7/1.7rc1 [05:25] I just uploaded the official tarball [05:28] I just saw the svn plugin die a strange death (but it wasn't obvious it was the null-pointer issue in that bug). I might see if I can repro that again... [05:29] the svn plugin seems very slow doing tests - I'm currently at "[590/982 in 65m26s,..." :( [05:32] poolie: ping [05:32] jam, oh, hi [05:32] congrats on the release [05:32] thanks [05:32] I still need to get the email out. [05:33] mwhudson: how do people profile extension modules. [05:33] mwhudson: its driving me batty [05:35] jam, shall we talk? [05:35] i'm a bit distracted by these disk errors tbh [05:35] lifeless: i don't know [05:35] lifeless: I inspect the raw C code to make sure it doesn't have stuff like "PyGetAttr" all over the place. [05:35] lifeless: callgrind? [05:36] poolie: I'd like to talk sometime, but it's almost midnight here, so I'm fine doing it some other time [05:37] poolie: do we have an idea on 1.8 RM? [05:37] jam: I know thats what you do; its laughably primitive compared to what I'd do on a regular C program with symbols. [05:38] jam: because its slow, manual, prone to errors [05:38] jam: [05:38] jam, i'm happy to do it again, though it sounded like you might want to? [05:38] :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))" [05:38] i think we should work out if we want to keep the changes you did or not [05:39] 10 loops, best of 3: 695 msec per loop [05:39] down from 1000ms [05:39] like having a trunk freeze period [05:39] lifeless: sounds good, just make sure you have a good test suite behind it :) I've certainly gotten caught up in benchmarking only to find out it was fast because it was wrong. [05:40] poolie: I'm fine relaxing some of that freeze. I think I was mostly coming off of the 1.6 delay and wanting to not have 10 more regression releases. [05:40] I *do* think we want it to be "1 week of minimal disruption" [05:40] And was sort of thinking that way going towards 1.8 [05:41] But 1.6rc5 and 1.6.1rc2 was not particularly pleasant. [05:41] (And that was after what, 1.6b3 ?) [05:41] i'm sure [05:41] it wasn't very nice for me either leading up to that [05:41] jam: thats another reason I want to avoid putting complex C logic in pyrex; its kinda hard to test from python, given that the whole speed thing is about not exposing each logical step to python [05:42] i guess i'd rather branch earlier and leave trunk open [05:42] i can understand the temptation to try to make robert work on the release but it didn't seem to work :-) [05:42] jam: uploading now [05:43] i can't believe Windows has no builtin ability to write an iso to disk [05:43] amazing [05:43] poolie: 'antitrust' [05:43] poolie: I think it started to [05:43] In XP or so [05:43] But no built-in DVD player, etc. [05:43] Even if you *buy* a DVD drive, you always get some random 3rd party tool [05:44] which you may forget about when re-installing. [05:44] not in vista afaics - you can write single files but not an iso [05:44] imgburn is a reasonable freebie for burning [05:44] poolie: ah, you're right. It supports a different method. [05:44] markh: Is that upload from the official tarballs, or did you use bzr.dev? [05:44] jam: I'm currently writing a pure C walk-and-stat-loop [05:45] jam: from the branch [05:45] jam: I want to have an accessible 'this is what we should expect' [05:45] markh: I just want to make sure you had the latest tip. I had to fix NEWS as a last commit. [05:45] I accidentally called it 1.7 instead of 1.7rc1 [05:45] lifeless: Depending on what you want, I'll wrap the inner functions in a python wrapper so I can test them directly [05:46] but the C code ignores the python form [05:46] markh, thanks [05:46] cdef versus def [05:46] etc [05:46] i can get around it, i probably have a copy of nero somewhere, i just think it's bizarre [05:46] but it's probably antitrust as robert says [05:47] jam: nope, I missed that last change. I've cancelled the upload. [05:48] should only take a few mins to rebuild [05:48] poolie: Well, I'd rather they had a synaptic style package manager, too... :) [05:48] Getting bootstrapped on win32 is always a pain. [05:48] most nero oem versions know the drive model they were sold with! [05:49] and refuse to work on others [05:49] well - I've seen that more than once, so I'm calling it "most" :) [05:49] poolie: what is our general policy about 3rd-party announcements? [05:50] I just saw a "bzr-gedit" email on bazaar-announce [05:50] onto our announce list? [05:50] i think it's ok for plugins [05:50] whats its there for really ;) [05:50] unless you think it's too noisy, in which case maybe ask them to throttle back [05:50] I'm thinking to let it through. [05:51] Just have to be careful, because I almost hit a spam entry. [05:51] Well, *I'm* the noisy one in the bzr-1.6 release. [05:51] With what, 7 announcements in a week? [05:51] Though I throttled myself. [05:52] jam: that sounds uncomfortable ;) [05:52] spiv: It can be, but you pass out before you cause real harm :) [05:54] jam, so you should go to bed [05:54] i'll be working from spiv's couch as i said but just ping me tomorrow [05:54] and we'll talk [05:55] poolie: sure [05:55] I'm just getting 1.8 opened in bzr.dev [06:00] my vote is less stress on releases [06:00] let the steady state drive things [06:01] if that state is too low, stressful releases won't fix it [06:03] poolie, jam: is the fix for https://bugs.edge.launchpad.net/bzr/+bug/261315 going to be in 1.7 ? [06:03] Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,Fix committed] [06:04] I approved it, but I don't think Martin submitted it. [06:07] * jml frowns. [06:12] rc2 is just a release away if it is important :) [06:12] it's important [06:26] ok [06:26] now this is interesting [06:26] :!time ./readdir [06:26] Count: 5769 [06:26] real 0m0.662s [06:26] user 0m0.232s [06:26] sys 0m0.428s [06:27] :!time find ../test-repos/mozilla/ -size 0 -size 1 [06:27] real 0m0.344s [06:27] user 0m0.092s [06:27] sys 0m0.236s [06:27] >< [06:27] still, this is encouraging, that a naive C program is slower in sys time than find :P [06:28] (than find's total time) [06:34] far out [06:34] time to mail this out [06:38] find caches some stuff dunnit? [06:42] also avoids stat-ing things if it can [06:49] mlh: fchdir() is the magic [06:49] mwhudson: nothing to do with it [06:52] mail to the list, enjoy, taking a breather [06:52] 615ms now [07:04] Good morning readdir [07:04] errr bazaar [07:09] morning vila [07:10] hi Guillermo ! [07:25] ERROR [08:14] and st is down to 3.34 seconds from 3.84 [10:48] ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file [10:48] now what ? [10:48] I killed while committing.... [10:48] am I lost ? [10:49] can I copy the file from another developer ? or regenerate it ? [10:51] actually, I've no /srv/ dir, so could be on the server side [10:52] hi folks ! [10:53] ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file [10:53] speakman: any idea about the above ? (I killed 'bzr' while committing) [10:55] strk: hmm, it seems you killed it at a very bad time [10:55] lifeless: ^ [10:55] strk: and it does sound like it is server side then [10:55] I've got an issue which I'm not sure how to deal with; If I have one mainline called "trunk" and a branch of that called "new_feature", both laying in my homedir like "~/myproject/trunk" resp. "~/myproject/new_feature". Now, if there has been some greate improvments on the trunk - is it okay to first merge all new stuff from "trunk" into "new_feature", and when all conflicts are solved merge the "new_feature" branch into "trunk"? [10:55] strk: you can probably regenerate the file [10:55] and it made *every* shared branch unusable :( [10:56] speakman: yes, that's perfectly fine [10:57] james_w: is it the prefered way to go? [10:57] (aka, or are there any other way to do it?) [10:57] speakman: either way works [10:58] you could just merge "new_feature" in to "trunk" [10:59] but i might still need to continue working on the "new_feature" branch, but I also need the improvments from "trunk" to make it work (conditions has changed, and fixes are in "trunk"). Thats my issue right now. === kiko-fud is now known as kiko-zzz [11:00] the former way seems to do the trick, but I wasn't sure about how messed up the "trunk" log will be when merging "new_feature" branch since "trunk"'s already in "new_feature". [11:01] I'm pretty new to VCS if it wasn't obvious :) [11:04] I just wanted to know if it will mess up anything to regulary merge trunk into feature-branches. [11:12] james_w: I'm really not here [11:12] james_w: please look at the rename code, it probably wrote to a temporary name, so its recoverable [11:13] speakman: not at all, and it won't mess up your "trunk" log [11:13] lifeless: thanks [11:13] james_w: can you help with fixing the broken thing ? [11:13] james_w: start with the method in pack-repo, which does the insertion, follow it into sftp transport [11:13] strk: yes, just looking [11:13] strk: you're using sftp right ? [11:13] lifeless: yes [11:14] does james_w have access to the server ? [11:14] strk: sftp prevent atomic renames (acts likes windows not posix) so there is an an unavoidable race [11:14] I wonder why they switched to it then [11:14] strk: he'll learn a little about the guts of this, then probably get you to use 'sftp' or 'hitchiker' or some such to do the recovery [11:15] strk: no idea, they did not discuss with me, or any bzr dev I know of [11:21] strk: so, there should be a temporary file 'at /srv/bzr/gnash/.bzr/repository/%s.tmp.%.9f.%d.%d' % (abspath, time.time(), os.getpid(), random.randint(0,0x7FFFFFFF)) [11:21] there may actually be two [11:21] strk: lifeless seems to suggest that you don't have ssh access to the server, is that correct? [11:25] * kinkie is away: lunch [11:25] no idea, I might have it [11:25] lemme try [11:25] uhm, Permission denied (publickey). [11:25] never logged before [11:26] lemme ask on #savannah too [11:27]