[00:01] mwhudson, ta [00:01] beuno: i'm a pushover :) [00:03] very effective pushover ;) [00:34] Good morning. [00:34] hai [00:39] hi [00:40] morning... haha === Kissaki is now known as Kissaki^0ff [01:11] igc: how important do you think it is to finish Bug 328598? [01:11] Launchpad bug 328598 in qbzr "Create a revisions selector widget. Use in commands like push/pull." [Medium,In progress] https://launchpad.net/bugs/328598 [01:12] garyvdm: pretty important ... [01:12] at a minimum, we want a placeholder class so ... [01:13] that all GUIs get nicer revision selection as the widget changes/improves [01:13] garyvdm: the first implementation doesn't need to be too clever - it just needs to exist :-) [01:13] It's current status is that it works, but some time one 1 cell gets selected, rather than the whole row. [01:14] and you can't select multiple rows - which would be nice for things like merge - to do cherry picks [01:14] http://www.xaprb.com/blog/2009/06/07/the-cache-oblivious-algorithms-inside-tokuteks-tokudb/ [01:15] garyvdm: where can I see it in action now? [01:15] can I specify a file to always be overwritten in new revisions? [01:15] igc: lp:~qbzr-dev/qbzr/revision-selector [01:16] then bzr pull [01:16] err bzr qpull [01:16] * igc grabs it [01:17] damn - AbsentContentFactory exception :-( [01:18] igc: unfortunately to fix the problems with it, I need to rewrite some of the qt combo box code so I can modify it's behaviour [01:18] Gnx-: can you explain in a bit more detail [01:19] Do you want the file to be overwritten when you pull a new revision? [01:19] garyvdm: well I'd like to include a sqlite database, and it does not like merging [01:19] but I'd want it to always be the version from the lats commit [01:19] last [01:20] Gnx-: with you now - but I don't know the answer [01:20] sorry [01:20] so basically I'd like to have the overwrite option for just one file [01:21] I know I can have it for push/pull in their entirety [01:21] Gnx- does bzr detect that it is a binary file, or does it think it's a text file and try merge it? [01:22] garyvdm: it thinks its a text file [01:22] and throws content conflict [01:22] Gnx- Hmm - that seems like a bug :-( [01:23] Gnx- Bug 218128 [01:23] garyvdm: so it should detect binary files? [01:23] Launchpad bug 218128 in bzr "some binary files detected as text: provide a way to flag files binary?" [Wishlist,Confirmed] https://launchpad.net/bugs/218128 [01:24] Hmm before I make a complete fool of myself, is there an IRC channel for TortoiseBZR? [01:24] this is i [01:24] Haven't found anything via google yet [01:24] it [01:24] Seablade - no - you can ask here [01:24] Ahh ok, now to make a fool of myself then:) [01:25] Is there a way using tortoisebzr to checkout from an SVN server with credentials? I can't seem to find a place to enter them, and the checkout process seems to be hanging so I assume it is looking for them [01:26] Seablade - I think you have to put the password in the url. [01:26] TortoiseBZR installed as part of the Bzr for windows installer for the record [01:26] garyvdm: Hmm didn't try that, now I gotta remember the syntax for doing that, thanks [01:26] garyvdm: I will let you know if it works [01:27] I know jelmer added ui code that asks for a username and password. Qbzr only implements the just password version. (TortoiseBZR - uses qbzr btw) [01:28] jam: pyrex for heads I think [01:28] jam: when you're into inner function removal for optimisation... [01:29] Sorry igc: that AbsentContentFactory exception - was that using the revision selector? [01:29] garyvdm: Yes I knew that much of TortoiseBZR and QBzr were the same, just wasn't sure how much. Hmm looks like the username and password in the URL seems to be crashing it, gotta do a sanity check but I think I got everything correct [01:31] garyvdm: Hmm there should be no need for quotes when supplying username and password through the URL is there? [01:31] igc: use nosmart+ should avoid the error [01:31] garyvdm: you need to run the branch repairer [01:31] yep - plain http worked as well [01:32] poolie: I had no further changes to make to the advisory I drafted; abentley suggested including more of the immediate actions in it, which I could work in if you like, or we could send it out [01:32] mwhudson: where are you guys at in runing the repairer over all stacked branches? [01:32] lifeless: somewhat stalled, i guess [01:32] Seablade: You should only need to specify a username - it will then ask you for the password. [01:33] garyvdm: Hmm let me try that, the protocol should just be https if it is checking out over svn+https correct? [01:33] Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) [01:33] what exactly does "or" mean there? [01:33] Seablade - I don't know that - have not use bzr-svn much. [01:34] garyvdm: Looks like it, it is checking out now, or at least seems to be, thanks [01:34] idnar: inclusive [01:34] well, I mean, why can't it tell me which one it actually is? [01:35] idnar: because the ui is trying to be too smart [01:35] idnar: what it means is 'this is the style of checkout you get with any of the above formats' [01:35] garyvdm: do you think if I slipped some non-text in the beginning of the file it would behave correctly in bzr? [01:35] ah, okay [01:35] idnar: because they all share the same 'working tree' code [01:36] so I guess I'd want to run bzr info against the repository I checked out [01:37] garyvdm: Ok I can reproduce that crash at least, it seems to happen when in tortoiseBzr I tell it to checkout to a location(destination) that does not end in the svn repository name [01:37] garyvdm: So for isntance if I checkout https://blah/els to C:\Projects it dies, but doesn't if I do it to C:\Projects\els [01:39] sorry Gnx-, Seablade - I'm a bit busy atm. [01:40] garyvdm: np, just tossing it out there if anyone needs the info, I have the checkout working at least, which was the main goal. If I have to deal with a slittle screwy directory structure I certainly can;) [01:48] idnar: depends on what you want to find out, but yes [01:48] is it possible the bzr 1.14 release branch never got merged back to bzr.dev? [01:48] (or that it did, but after the 1.15 branch was cut?)_ [01:48] i guess i can find these things out for myself [01:56] I sure hope so [02:01] are bzr+ssh URLs relative to $HOME? [02:02] idnar: I think you need a /~/ if you want that [02:03] hmm, /~/ doesn't work but specifying the full absolute path does [02:03] idnar: no, they are abspath to the virtual root (which depends on server config as normal) [02:04] idnar: host/~/ is used with sftp to mean '.' in the SFTP protocol, as it has no good mapping in std66 and the I-D for sftp [02:04] :// was bong [02:04] spiv has a patch (not landed I think) to let /~/ be used with bzr+ssh too [02:06] ":// was bong" ? [02:09] SamB: sftp:// was bong [02:10] bong [02:10] v : ring loudly and deeply; "the big bell bonged" [02:17] lifeless: just confirmation before I delete them, but the content of obsolete_packs is ok to delete if no bzr commands are in progress right? [02:17] lifeless: when do obsolete_packs get cleaned out? [02:20] thumper: when bzr does a pack [02:20] thumper: which is every 10 commits on average [02:20] lifeless: I don't believe that [02:20] thumper: check the code if you like [02:21] lifeless: because I just pulled stuff in that seemed to do a pack [02:21] and I hve stuff there from over a month ago [02:21] thumper: file a bug then [02:21] thumper: The pack algorithm is as follows: [02:21] a) make new pack [02:21] I have 2.3 gig of obsolete_packs in my LP repo [02:21] b) delete obsolete_packs contents [02:21] c) activate new pack [02:22] d) move obsoleted packs and indices to obsolete_paks [02:29] * igc off for lunch and medical stuff [02:45] How come bzr pull . -rsubmit: --overwrite only pulls the lca of . and :submit? I thought it would pull the tip of :submit like bzr pull :submit --overwrite [02:48] garyvdm: because ". -rsubmit:" resolves to that particular revision [02:49] * garyvdm re reads bzr help revisionspec [02:50] submit: is the lastmerged rev of the submit branch [02:54] Ok - I thought that -rsumbit: gave you the tip of :submit. [02:54] I thought wrong... [02:56] lifeless: hi [02:58] Hmm - so -r ancestor::submit == -r submit: [02:58] lifeless: which advisory? [03:03] poolie: about stacked repositories [03:03] garyvdm: yes [03:06] lifeless: certainly I agree about pyrex if I was fully fine tuning. Mostly I'm algorithm exploring, and wanted to make sure it was comparable to our existing code [03:43] jam, lifeless, i'd like to do 1.16rc1 a bit early, like this week, to help with brisbane-core testing [03:43] and to let it be rolled into launcphad [03:43] poolie: sure [03:43] do you see any problems, or any bugs that'd block it? [03:46] lifeless: spiv does have a patch for ~ but he agreed it was bad to do it at the ssh level so he's going to rethink it [03:46] ie it's still in his queue [03:50] lifeless, jam, also, what do you think about changing both the on-disk marker and the ui name for this format to say '2a' [03:50] poolie: I think we should make it 2 or 2-something [03:50] vincent agreed this morning [03:51] until i was writing that mail i was going to say just '2' or '2.0' but the thing is [03:51] at least in the general case if not here [03:51] we can't rule out changing it before code 2.0 comes out [03:51] and having obviously different but related names seems to be useful [03:53] '2a' seems like a reasonable compromise given the constraints (such as lack of time machine). [03:54] ok [03:54] i'll put up a patch [04:01] poolie: well its a dev format already [04:02] and currently we promise not to break them [04:02] poolie: I'm fine with the next change to it being e.g. 2.0beta [04:13] (I mean, I agree that we should put 2.0 in the disk format asap) [04:23] poolie: https://code.edge.launchpad.net/~jspashett/bzr/76616_ignored_on_add_confusing/+merge/4864 has a comment from you saying "looks good, I'll merge", but lp doesn't think it is merged? [04:25] jelmer: awake still? [04:27] * mwhudson sends mail instead [04:30] spiv: i think i rebased his patch [04:30] he also said that i might have merged the wrong thing [04:30] chalk up another way rebase interferes ;) [04:30] i'll come back to it sometime [04:31] lifeless: i can't work out whether you're agreeing about format names or not [04:31] I'm trying to debug an ssh error; how do I set BZR_SSH again? [04:31] (For debugging purposes, I mean.) [04:32] poolie: I think we should have the next production format be called 2.0 on disk in some way; If we have no further planned changes then I think changing the format label would break early adopters and we should instead add another format with only a disk label change [04:32] poolie: ok. When the current PQM queue clears that will be the only proposal left on https://code.edge.launchpad.net/bzr/+approvedmerges, if that's extra incentive :) [04:32] poolie: It wasn't clear to me what you were proposing to do [04:33] KhaZ: I'm not sure, it might be one of openssh/paramiko/... [04:33] Ah; got it! Looks like I got owned by hosts.deny. Whoops. ;) [04:34] * spiv -> lunch [04:44] Cool, my Loggerhead repo fails a check. :D [04:46] Peng_: which one? [04:47] lifeless: Which repo or which check? [04:47] whih check [04:47] if (self.text_sha1 != tree._repository.texts.get_sha1s([key])[key]): KeyError: ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') [04:48] hax! [04:48] (thats actually fairly serious) [04:48] we need tools to repair this [04:48] please file a bug [04:48] Crap, real [04:48] The copy on my server passes, so even in the worst case I've lost little to no data. [04:49] Err, really?* [04:50] lifeless: Any chance of ruining a remote repo if I push to it? [04:50] well it means there is an inventory claiming that ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') exists, and yet its missing. [04:50] so that revision can't be reconstructed [04:51] I don't think you'll make it worse pushing to it [04:51] What if I push a revision in this repo to a remote one, though? [04:51] Argh, this is a pain. [04:52] backup the target repo first [04:52] Indeed. [04:59] lifeless: If another repo passes check, it's safe to say it isn't broken in this way? [04:59] probably :) [05:00] lifeless: Any idea how this could've happened? [05:01] Sigh, I want a faster CPU. Check is slow. :P [05:01] Peng_: bzr-svn possibly [05:01] Peng_: or a bug [05:02] lifeless: This isn't a bzr-svn repo, though. [05:03] Anyway, I'll file a bug once I'm done working around this. [05:06] Well, the good news is it looks like this hasn't affected my serfer or lp:loggerhead. [05:06] Peng_: it could be a fetch ailure, or a knit related ordering bug back some time ago [05:07] if that key exists in your other repo, try fetching a stream directly in python to fill it [05:07] lifeless: How should I test if it exists? [05:08] Peng_: _repository.texts.get_sha1s([key])[key]) [05:08] with key = ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') and so on [05:08] And the key is that tuple? [05:08] :) [05:09] poolie: available for a call? [05:12] jml: do you want to get together for the europython talk and do some notes/whatever [05:12] lifeless: yes, sounds like a great idea [05:12] jml: if so I'd be delighted, but I'll let you drive it (as I'm not going) [05:12] cool [05:13] lifeless: how's thursday evening? [05:14] this week is kinda full - but next week anytime should be fine [05:15] lifeless: ok cool. [05:18] lifeless: My other repo does not have that key. [05:21] Peng_: then you have a local rev (perhaps jelmer@samba.org-20090529150418-05on2fgizfqs77fj) which is either a ghost in other repos, or part of a dead branch, that is faulty. [05:24] lifeless: Ohhhhhhh! I just remembered! [05:24] * Peng_ suddenly pings out, never to be seen again. [05:25] haha [05:25] jml: hi [05:25] poolie: I'm just out of batteries, may I call you on your mobile? [05:25] jml: am a bit starving at the moment, would about 3pm be ok? [05:25] poolie: 3pm is perfec.n [05:25] k [05:25] * jml off. [05:25] off to post ian's swag and get lunch [05:26] lifeless: Anyway. There was a branch, lp:~jelmer/loggerhead/smart-server (since deleted) that was, like, broken. I tried to branch it into this repo. Maybe that introduced the bad revision. [05:27] Peng_: likely [05:28] lifeless: Yeah, I just checked .bzr/branch/last-revision on my copy of the branch, and it is indeed that revision. [05:28] lifeless: Still think I should file a bug? [05:28] Peng_: how long ago was that [05:29] Peng_: and do you have knits locally? [05:29] lifeless: Note the date in the revid, 2009-05-29. My repo was (and still is) 1.9-rich-root. The remote repo presumably was too, since I don't remember a knit warning when branching it. [05:29] Peng_: actually yes. File a bug - we should neither have permitted the damage, nor your repo to be damaged, and we should allow it to be fixed. [05:32] .bzr.log++ [05:40] lifeless: Filed https://bugs.edge.launchpad.net/bzr/+bug/385054 [05:40] Launchpad bug 385054 in bzr "check: Missing key in get_sha1s" [Undecided,New] [05:41] jelmer: do you have that original source branch? [05:42] lifeless: Do you think the repo is safe to use as long as I don't interact with that revision? [05:42] jelmer: That is, the original, broken lp:~jelmer/loggerhead/smart-server [05:43] Peng_: yes [05:44] lifeless: So I can keep using it? You sure? :D [05:44] Why am I suddenly paranoid? [05:45] I don't know. Are they after you ? [05:45] lifeless: The Illuminati corrupted jelmer's branch to interfere with my work! or something! [05:45] Peng_: don't answer that, he's one of them! [05:45] Oh crap! [05:46] now you've done it, the Admiral will be here any second [05:47] Quick favor: Could someone link bug #241133 with the 1.13 milestone? [05:47] Launchpad bug 241133 in bzr "Don't suggest the user specify -Dhpss" [Medium,Fix released] https://launchpad.net/bugs/241133 [05:48] Peng_: I can't; the 1.13 milestone is no longer an option in the dropdown. 1.14rc2 is as far back as it goes. [05:49] spiv: OK. Thanks. [05:49] Peng_: don't stress. [05:59] * jml is back [06:05] lifeless: You're just saying that because adrenalin makes it harder to read my mind! [06:06] poolie: whenever you're ready [06:08] bzr check seems to fail over bzr+ssh. "revno does not match len(mainline) 366 != 0". [06:08] Oh, actually, it had already checked the repo. That was just the branch. [06:23] jml, hi! [06:24] poolie: skype? [06:24] if you like [06:30] lifeless: hmm, pqm is still silently swallowing my merge requests for lp: URLs :( [06:34] spm: ^ [07:12] jml: i'm going to change 1.16 to that date -- https://edge.launchpad.net/bzr/1.16 [07:13] "bzr check" sure is dreadfully inefficient over the smart server. :) [07:13] Peng_: yes [07:13] poolie: thanks [07:13] Peng_: feel free to add a verb for it [07:14] * Peng_ runs away. [07:22] hi all [07:23] hello vila [07:24] poolie: I've started a buildbot. Only jaunty and OSX 10.5 to start with. [07:24] poolie: selftest is failing right now :-) [07:25] even on jaunty? [07:25] poolie: at least one failure is related to pb noise, I was wondering if you had pending changes in that area ? [07:25] are the results public? [07:25] the only test failing on jaunty is one testing 'bzr --version' stderr and finding some pb artifacts there, really not a big problem [07:26] it's a bit surprising [07:26] i do have some changes pending [07:26] Y'know, I had some weird test failures the other day I mentioned here... [07:26] * fullermd digs. [07:27] test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7. [07:27] poolie: the buildbot is not public so far, but is under bzr and I keep notes [07:35] spiv, hi? [07:36] can you tell me more about bug 380314? [07:36] Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed] https://launchpad.net/bugs/380314 [07:36] poolie: hello [07:37] i guess specifically [07:37] are you working on it, and is it needed for 1.16? (it seems so) [07:37] To be honest, I'd forgotten about it, but I targetted it to 1.16 for a reason :) [07:41] I'll start on that basically right now. [07:41] Huh, I can't get "bzr check --branch bzr+ssh://..." to fail again. [07:41] Maybe it only does if I check the whole repo too. [07:41] ok [07:42] what were you doing before i disrupted you? :) [07:42] It shouldn't be a lot of work, I ought to have it done in time for the probable rc on Thursday. [07:42] :) [07:42] Today I've been closing off various small things, e.g. approved branches, a little bit of administrivia. [07:42] fullermd: and only that test ? [07:43] Specifically, right when you pinged me on IRC I had just finished making a coffee :) [07:43] :) [07:51] poolie: sorry, get distracted, does your pending changes includes setting the ui from an env var ? [07:53] not yet [07:53] i know it needs to be done [07:53] at the moment i'm trying to make sure it gets cleaned off when there's other output [07:53] i will come back to that [07:57] lifeless: it's a good document [07:57] you could put it in devnotes [08:03] poolie: Sure. Is devnotes a branch of bzr itself? [08:05] no [08:06] vila: Well, I didn't run the whole test suite. I just noticed that by accident since it got run when I was checking something else. [08:07] fullermd: ok, may be worth filing a bug for it so that it doesn't get lost :-/ [08:07] poolie: can I ask why it isn't ? [08:08] I thought the developer docs subdir was working well [08:08] I've got a new workstation in pieces across my office. Was planning to try a full testsuite run after I got it live, just to see what it's like when it takes less'n an hour to run... [08:08] fullermd: yeah ! [08:09] fullermd: what processor/memory ? [08:09] Phenom II 955, 8 gig DDR2-800 [08:10] fullermd: thats amd yead? [08:10] Yah. [08:10] Intel's still made it impossible for me to buy their chips, the bastiches. [08:11] I'd'a considered the i7 if the memory controller weren't b0rked :| [08:11] fullermd: I'm curious to know about 'bzr selftest --parallel=fork' timings on it :-) [08:12] as soon as all tests pass there of course :) [08:12] I'm just dreaming of what it'll be like when firefox is merely really annoyingly slow. [08:15] fullermd: impossible? [08:15] Let me have my dreams. [08:15] fullermd: I'm sure they will take your money [08:16] They always have before. Consistency is a virtue. [08:18] fullermd: why are the memory controller borked ? [08:18] Oh. Because they integrated a memory controller, and then didn't let it support ECC. [08:19] AMD did. So I can grab any AMD chip and put decent memory in. With Intel, you always either had to be VERY careful and picky about motherboards, or buy Xeon. [08:19] And now that they've integrated the memory controller, you can't even be picky about motherboards anymore. [08:20] But don't you want the fastest DDR3 memory anyway ? [08:20] I don't care HOW fast I can get the wrong answer :p [08:21] I care about my data; I don't consider ECC to be optional. [08:21] You have to educate me here I'm affraid because I may not understand what ECC is about then :-/ [08:21] Detecting and correcting bit errors. [08:23] Same reason the new system is running ZFS with SHA256 block checksums. [08:23] And DDR3 don't do that ? [08:23] (I'm not paranoid. I've been around long enough to know my hardware really _is_ out to get me!) [08:24] Oh, it can. But DDR3 is still twice the price of DDR2, and the speed difference isn't near big enough to justify that. [08:24] Maybe in a couple years, I'll replace the board and load up on DDR3 when the price is down and 4GB DIMM's are at a good price point. The processor will handle either. [08:25] Oh I see, the *other* strategy :-) [08:25] (it's a lie of course, I'll probably sit on the system unchanged for 6 or 8 or 10 years, like I always do. But it's a nice dream :P) [08:26] fullermd: I suggest you do yourself a favor and buy an SSD, you won't believe the impact on raw performances... [08:27] Oh, with my EXTRA money? :p [08:27] * fullermd doesn't have a couple grand to spend on storage... [08:27] you can find some for 150$ these days, worth the price for ~64GB to play with [08:27] lifeless: because it's not a branch of bzr [08:28] they're not really in sync with each other, like the user documentation is meant to be [08:28] The cheap ones all have abysmal random write performance. You gotta get up into the $600 or so ones before they don't fall apart there. [08:28] Then double the price to get 2 of 'em to mirror... [08:28] if we're landing something that is in sync, like documentation of code that's actually come in, that does belong in there [08:29] back [08:29] vila: I've got the new series Velociraptors. They're plenty fast. [08:29] vila: (anyway, the hard drives could be pretty slow and still be a nice improvement over my current ~12 year old ones :P) [08:29] haaa, Monsieur is using mirrored velociraptors and is talking about PRICE ? :-) [08:29] hello igc [08:30] Hey, the raptors WERE the cheap option. I'm a SCSI nazi. [08:30] pfew, I gave up with SCSI years ago :-/ [08:30] if I do 'bzr init foo' inside a brisbane-core repo, the branch is format6 -- is this expected? [08:30] igc, a large bag of UDS shwag is in the mail :) [08:30] spiv, want a quick call? [08:30] jml: yes its a defence of repositories as currently defined [08:31] defect [08:31] lifeless: ok thanks. [08:31] poolie: have we moved all the extant theory documents out then ? [08:31] poolie: sure [08:31] poolie: I'd rather not have two places to go looking for such things [08:32] how would I upgrade those branches to branch7 format? [08:32] jml: upgrade -- [08:32] lifeless: what goes into [08:33] ay [08:33] whatever you used to make your repo [08:34] no, i haven't cleaned up all existing documents [08:34] this is mostly an alternative to putting them on the wiki, which [08:34] is annoying to edit especially when you're flying or on a super flakey network [08:34] oh [08:35] well, with this sort of think I would normally get some feedback and land it in bzr.dev. [08:35] Do you want this to change? [08:35] s/think/thing/ (Sorry about typos, am really EOD'd already) [08:35] or an alternative to having it just on the list [08:36] oh of course the other difference with this branch is that, like the wiki, unlike dev, it's clearly not pre-review [08:36] ah, [that wasn't clear] [08:37] i did send a mail [08:37] which may have been unclear :) [08:37] its likely in my backlog, I was a little distracted [08:37] so, it's ok to land it in bzr.dev [08:37] i do have some qualms about having speculative or thinking-out-loud documentation there [08:38] i kind of feel if it's in a release it ought to all relate to that release [08:38] also, possibly having somewhere it's shared and mutually editable without going through review is good [08:38] though we could of course do that with just a devnotes branch of bzr [08:38] or a loom even :P [08:39] I didn't make this repo :( [08:39] jml: well, --development-rich-root should do it, but I haven't checked [08:40] thanks poolie [08:40] ahh right, was running in wrong directory [08:41] thanks. [08:42] poolie: I agree that there is a tension between the timelines of documents [08:43] poolie: this shows up a lot in translations [08:44] poolie: yeah, your email about that was pretty much sent right before the weekend between allhands and UDS; as you know monday morning had me emulating a chicken [08:45] poolie: I encourage you to put some thought into devnotes-as-an-experiment [08:46] so for instance, how do you get the same degree of review and consideration of whats in it as bzr.dev gets from the reviews on the list [08:47] I will look at it tomorrow and make sure I've read whats in it [08:49] but I really have to EoD now [09:01] lifeless: [09:01] > Perhaps weakrefs? [09:01] [ ] metaprogramming [09:01] [ ] code generation [09:01] [ ] C extensions [09:01] [ ] kernel module [09:01] [ ] flub [09:01] weakrefs on the progress bars in the thing that maintains the stack [09:02] maybe [09:02] then it can cleanly discard the most recent addition if a generator is existed early [09:02] FSVO clean [09:02] the thing is [09:02]