[00:07] poolie: it rang out, trying again === mw is now known as mw|out [00:57] 68 failing now [01:20] 8 === kiko is now known as kiko-zzz [01:29] heads down on ssh locking [01:58] woo [01:58] full test time, think its finally hammered into submission [02:01] lunch time too [02:02] lifeless: when you get some free time, can I harass you about the get_parent_map/old-server reauthenticate-over-ssh issue again? [02:05] why doesn't this work: $ bzr log -r date:2008-03-14.. [02:05] bzr: ERROR: Requested revision: u'date:2008-03-14' does not exist in branch: BzrBranch6(...) [02:06] note it is the first one _after_ that date according to the source [02:06] still, it seems a strange error [02:08] you'd rather "no revisions after xxx"? [02:08] anyhow is it in fact true there are no revisions on or after that date? [02:08] or did you expect it to just log nothing? [02:28] * Odd_Bloke would expect it to log nothing. [02:29] Logging nothing or saying "no revisions after xxx" both make sense to me [02:29] Logging nothing is more consistent with what we do in an empty branch. [02:31] printing the error message avoids the user wondering why there was nothing logged though [02:31] similarly, I wouldn't be opposed to printing "Empty branch" when running bzr log in an empty branch [02:33] Nor I, I was just commenting on current behaviour. [02:33] I can't say I'm massively bothered either way. [02:34] poolie: there are no revisions after that date [02:35] what jelmer said is what I think ( Logging nothing or saying "no revisions after xxx" both make sense to me) [02:44] I also find the default silence of bzr to be a little eerie sometimes [02:52] remind me how to do this: I've made some changes in a working tree, I haven't committed, and now I realise I want them in a new branch. [02:52] jml: make a new branch [02:52] cd into it [02:52] bzr merge --uncommitted ../old-branch [02:53] bzr reconfigure --checkout ; bzr branch . wherever ; bzr switch ../wherver [02:53] mwhudson: thanks. [03:38] ok really the last time. fingers crossed [03:41] lifeless: why do you not want the inventory_validator_type in Revision objects? [03:42] I think its making an abstraction violation worse [03:43] I would be quite happy to ditch the validator entirely, but if we're keeping it, I think we need to know what it means. [03:43] I think it is happily hidden behind Repository/Revision themselves. [03:43] The validator? [03:43] yes [03:44] its exposed at the moment, and only well defined some of the time, but all the uses for it are things that should be methods on either Revision or (probably better given our current object use style) Repository [03:45] So if I were to introduce a new repo format whose revisions didn't have validators in their serialization, that would be fine with you? [03:45] if we can somehow validate the revisions without that, in principle, yes. [03:45] You mean "validate the inventories"? [03:46] no, I mean the revision - which is a transitive validation of all the stored data [03:46] The inventory_sha1 does not validate the revision. [03:46] thats true [03:47] I was making a more general statement. I really precise one would be 'if it is no less capable of validating the inventory for that revision', but thats much more awkward [03:48] lifeless: It sounds like you're significantly increasing the difficulty level. [03:48] Validating the inventory is one thing-- validating the whole revision is another. [03:48] right now we get revision validation via the revision signature [03:48] clearly if thats not there we only have validation of the data the revision references [03:49] and I did not intend to raise the barrier higher than that [03:51] I don't really get your second statement. [03:51] ok, well lets start over [03:51] are you planning on removing inventory validation? [03:52] (aka not reenabling it) [03:52] No. I was planning to ignore it until you started saying this was a blocker for rich-root-pack [03:53] I think its a pretty severe defect in the current code [03:53] Now I want to do the minimum necessary to keep you happy and ensure we don't have this problem again. [03:54] I will be happy if: pack-rich-root repositories validate their inventory [03:54] during 'check' [03:54] If I simply introduce a new revision serialization just to indicate the inventory serialization, that's going to be wasteful. [03:54] such that an edited inventory causes a check failure [03:54] Because I'll have to introduce at least two, and possibly many more as time goes on. [03:54] I don't think you need to introduce a new serialisation, but you were adamant that you needed to [03:55] If we don't know what a validator is, we can't hope to use it correctly. [03:55] erm [03:55] clearly that statement is true, but we know what validators we have [03:56] I wrote the code to fix things so that I would be happy [03:57] I think that sticking the validator in the revision is horrid. It's local data; it doesn't belong there. [03:57] its very simple: change repository.get_inventory_sha to actually use the text, and change fetch to update the sha1 during rich root tree root addition [03:57] those two changes, in total, made me happy. [03:57] At the cost of making me tremendously unhappy. [03:58] Because bazaar is a distributed system, and values should really be write-once. [03:58] which is not an acceptable cost [03:58] well given that the inventory is being rewritten *already* [03:59] the inventory validator being updated is a consequence of the rewrite being done by the plain->rich root fetcher [04:00] lifeless: it is being rewritten, true, but in a deterministic way. The new values are implied by the existing values. [04:00] the same holds for the inventory sha change [04:00] in the format under discussion the new inventory serialisation is deterministic, as is the resulting sha [04:01] The problem with the inventory sha change is that it is tied to the inventory format, but affects the revision format. [04:01] If the revision format implied that validator, that would be acceptable to me. [04:02] uhm, those two things are part of a repository format though; they can't be used in isolation or arbitrary combinations [04:02] you can't use an original format revision serialiser today [04:02] You can shove anything in a bundle, and it will translate as necessary into the target serializers. [04:03] directly? or via install_revisions? bundles should not be serialising, they should be using the object model [04:04] I would have to check. [04:04] if they use serializers directly they are profoundly hostile to e.g. bzr-svn [04:05] serialisers are private on a repository [04:06] Well, it looks like it only handles inventory, not revisions. [04:07] If the repository doesn't use the same inventory serializer as the bundle, then it converts it to an object and calls Repository.add_inventory [04:09] so the basic thing here seems to be - we have individually versioned formats for code reuse and to catch some cases of bugs; There are dependencies between our formats such that changing anything about e.g. inventory changes the value of fields in e.g. revision [04:09] so yes, I think you need a new revision format to be strictly correct; the new format needs no changes other than a version string bump IMO. [04:10] and I think every inventory change will do that if you want to be able to analyse serialised revisions outside of the repository that owns them. (I think that being able to do that is of questionable value FWIW). [04:11] And as you can imagine, I don't want that kind of churn. [04:12] I'd rather specify what the validator means. [04:13] maybe I don't understand what you mean [04:13] but unless you define the validator as being an arbitrary datatype (and thus needing a format bump _anyway_ when it changes), I don't see it preventing any churn [04:14] hello, i've kind of goofed up my bzr history on the bzr repository/server. i didn't do a bzr bind, and several other people committed changes that i just merged in, and then pushed up a few of my changes. the content is accurate, but the history is fscked. is there a way to fix/correct the history? [04:15] what do you want it to look like? [04:15] i want the prior history to be shown. 108 revisions were removed from the branch, and replaced by my generic 'a bunch of updates' commit messages. [04:16] :( [04:16] j1mc: sure thing, what you need to do is do 'bzr branch -r revid:XXX trunk local; cd local; bzr merge -r revid:YYYY ../trunk; bzr commit; bzr push --overwrite ../trunk' [04:16] lifeless, can you please explain to me what that will do? [04:16] j1mc: where XXX is the revision id (not revision number) of the last commit that should have been on the mainline before you pushed [04:16] (thanks, btw) [04:17] j1mc: and YYY is the revision id of the tip of your branch (possibly even the current mainline tip) [04:17] j1mc: what it will do is do the merge that bind would have done via 'bzr update' [04:18] j1mc: you can get revision ids via bzr log --show-ids [04:18] lifeless: this is on launchpad, will it cause 108 emails to be sent out with the updated revision history [04:18] s/updated/corrected [04:18] j1mc: presumably :(. thumper ^ [04:18] haha [04:19] after you ahve done this [04:19] there is an option you can turn on in your branch to prevent this mistake [04:19] its in the manual I believe [04:20] Kamping_Kaiser: look at that ^^ [04:20] thanks... [04:20] lifeless: If we have different types of inventories, we can just specify the validator type, e.g. "inventory6sha1" [04:20] That means we don't need a different format for every inventory format. [04:20] abentley: so the validator becomes a tuple essentially - (type, validator) [04:21] Sure. [04:21] abentley: this seems redundant to me, because the repository already knows the type. Which is why I don't think we need a new revision format in the first place. [04:22] The bundle does not know the type. It is not in a repository format. [04:23] abentley: but if you feel its essential in the disk format, go ahead I guess. I really think its wrong, but we seem to be at an impasse [04:24] I think bundles are buggy then (grin-joke) [04:24] well, play on words. I really do think that a bundle has the same duty of integrity as any other revision storage format [04:24] A few minutes ago, you said "I think you need a new revision format to be strictly correct" [04:25] I can see the logic for why you want one; I don't think its needed because its conflating two different things [04:25] lifeless: Bundles have very good integrity checking. [04:26] good; so they _must_ know whether they came from a rich root or non rich root repository [04:26] and if they know that, they know whether the sha in their revision is for a rich root or plain inventory [04:26] sha for the inventory in their revision [04:27] The one does not follow from the other. [04:27] given our data model I think it does [04:27] They store a sha1 of the expected text output. [04:27] The sha1 of the fulltext. [04:28] But this is stored in private data-- the text of the revision is completely ignored. [04:29] which clearly will differ if the source and target repository differ [04:30] If the source and target differ in format, it generates the fulltext of the source, verifies it, and then convert it into the target format. [04:30] where you mean 'serialisation of a single object type' by format [04:30] and when I talk formats I mean 'entire repository' [04:30] Right. [04:31] if bundles had the repository format there would be no problem, you wouldn't try to use a fast path that doesn't fit [04:32] Or alternatively, if inventory format didn't affect revision contents, there would also be no problem-- we could mix and match. [04:32] anyhow, we agreed on a compromise in London, which was a new revision format, so lets do that. I'm really unkeen on inventory_validator being (type, opaque_data), because you have to have a new bzr to read new types and validate them anyway [04:32] so I don't see that we gain anything over just revving the revision serialiser itself; which is trivial and tiny amount of code [04:35] lifeless: Okay, fine. I'll implement two revision formats, one for each inventory format. [04:36] But *you* get to implement the new revision format when you do journalled inventories. [04:36] surely its [04:36] class SubX(parent): [04:36] revision_version = 7 [04:36] class SubY(parent): [04:37] revision_version = 8 [04:38] I have no idea. [04:38] I suspect it's a bit more than that. [04:38] Once you've implemented the serializers, you've got to update the places they're used. [04:39] assuming you ditch knit based rich root and subtrees [04:39] which I recommend [04:39] then its just a new subclass of the two Pack repo formats, with a single line override in the same manner [04:42] lifeless: you responded pretty quickly to my "history" issue above. is that a common situation? [04:42] j1mc: no [04:43] you just know bzr well. and other people bind their branches.... so it doesn't happen to them? [04:43] lifeless: And registering the formats in xml_serializer.format_registry, and I'm pretty sure they pop up in some other places. [04:44] abentley: ok, so 10 lines then ? :] [04:44] j1mc: I'm one of the old hands yeah :) [04:45] ok [04:45] :) thanks so much for your help, lifeless [04:45] I've nuked VersionedFile.get_parents, now to make the implementation within knit.py smooth. Then a patch we shall see. [04:45] btw, i'm in the general vicinity of john meinel (sp?). i've met him once before... he's a good guy. [04:46] j1mc: cool, yes he is [04:46] abentley: btw, export-loom, am I expecting a new patch, or should I remove the default and commit myself? [04:46] Please go ahead. [04:47] abentley: will do [04:48] I'm for bed. [04:48] wow [04:48] must be very late now [04:49] hmm, I think I forgot something.. [04:49] Eh, not even 1:00am [04:49] jelmer: hah! [04:49] jelmer: Was it 'going to bed'? Because I've done exactly the same... [04:51] Odd_Bloke: :-) [04:54] I'm new to Bazaar and I'm having problems figuring out how to pull an older revision of a branch. Could somebody help me out with the command? [04:58] Symgeosis: bzr pull -r revno --overwrite [04:58] Thanks Lifeless. [05:01] lifeless: i have an additional question about your prior suggestion. [05:01] lifeless: I lost the context, can you explain (launchpad emails)? [05:01] you wrote, "and YYY is the revision id of the tip of your branch (possibly even the current mainline tip)" [05:02] would that be a revid of one of the earlier revisions? [05:02] i don't know what a branch "tip" is [05:03] thumper: http://pastebin.ca/948485 (context) [05:03] j1mc: The branch tip is the revision that the branch points to. The head, in git terminology (I think). [05:05] Odd_Bloke: thanks, but i still don't quite understand. [05:05] j1mc: you could set you subscription level to "No email" for the change and then edit it back afterwards to avoid the email [05:11] hm, so should i do this locking change by passing a parameter down saying "don't wait", or by having the smartserver set a global option not to wait for locks? [05:12] relying on global state is undesirable, certainly [05:12] otoh it really should not normally be waiting [05:13] lifeless: sorry to keep bugging you (if you are even still around), but i'm having a hard time knowing what i should be selecting as the second (XXX) revid. [05:14] would it be a recent revid (from just before i goofed up the history)? or one of the ones from earlier in the history? [05:18] do you mean second (YYY)? [05:19] bob2: yes, the second YYY [05:19] j1mc: it's the last one that had what you consider "good" history [05:19] probably the one just before your merge [05:20] YYY should be the revid of the top of your branch (second part of the output of bzr revision-info) [05:21] maybe it would help if i posted the last good revision to pastebin [05:21] http://pastebin.ca/948518 [05:22] 3651.1.108 is the last good revno [05:22] i think i would use that for the XXX part [05:23] (that's a revision number, not a revision id) [05:23] bob2: correct [05:23] revision-id:asommer70... [05:23] that's the revid [05:24] i'm hesitant to use the "asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa" as both XXX and YYY, but that's what i think is being suggested. [05:25] XXX is supposed to be the last revision id before things went wrong, YYY is the tip of your currently wrong branch (which, as lifeless said, might still be the tip of the lp trunk) [05:26] afaict [05:27] so in that example, my "incorrec" push has a revid of "jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp" that would be YYY [05:27] (it is the most recent push to the branch" [05:27] (sorry for the typos, it's late) [05:32] bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk [05:33] does "bzr log" in trunk show what you want it to show? [05:33] hi soerry [05:33] been on phone [05:33] bob2: yes. [05:34] on my local copy [05:34] lifeless: np [05:34] j1mc: so [05:34] j1mc: to find XXX, run bzr log --show-ids [05:35] j1mc: somewhere amongst your merged revisions will be a commit to the trunk that *should* be on the mainline (that is have a whole number revision number, with no dots), but that is shown nested [05:35] j1mc: the first one of those, is the one you want as XXX [05:35] http://pastebin.ca/948518 [05:36] the first one listed is the most recent commit and push to the branch. it's the one that screwed everything up. the one after that is the last good one [05:36] based on that, i think this is correct: [05:36] bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk [05:37] where "asomer..." is the last good one [05:37] j1mc: ok, then use asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa as XXX [05:37] and where "jwcampbell..." is the tip, or most recent commit [05:37] and whatever revision id revno 3666 has for YYYY [05:44] lifeless: in my log, there is no 3666 [05:45] uhm [05:45] 3667 and after a while 3666 and so on [05:45] what command are ou running [05:45] to get the log [05:45] do you have an alias set overriding revision selection [05:45] bzr log --show-ids > ~/Desktop/ids [05:45] no [05:46] then look further down the file :) [05:46] :) got it [05:53] lifeless: i see the smart server locking tests specifically ask for knit repositories [05:54] do you suppose that is an accident, or because they want one that has more locking than packs? [05:54] hm [05:54] the former I believe [05:55] i'll mail spiv [05:56] annotate doesn't blame me ? [05:56] * poolie looks [05:56] btw did you know gannotate supports Ctrl+F [05:56] yes [05:57] ah yes, it is you [05:57] > Make test_smart use specific formats as needed to exercise locked and unlocked repositories. [05:59] so do you still want it? [05:59] yes thanks [06:00] running against packs may be interesting too, but running against knits is essential until we stop using them. [06:00] i'm confused [06:00] you said it was an accident [06:00] but you still want it? [06:00] oh [06:00] I meant deliberate;) [06:01] gee look at the time, gotta go :P [06:03] (seriously, I woke at 4am, I am rather shattered - getting former and latter confused is not good. I'm going to go have a cat nap) [06:06] hehehe [06:13] sure [06:29] actually, going to call it a work-day [06:31] I need to dig up the python C api and turn a list to a tuple to finish this patch [06:47] lifeless: you rock. your command helped me to fix it. [06:48] \o/ [07:01] hi ho [07:01] hi === jml_ is now known as jml [07:02] So many jmls! [07:03] Odd_Bloke: ... I'm j1mc :) [07:03] but yeah... kind of strange [07:04] I'm on a crippled system atm. [07:06] jml: :( [07:13] Night! [08:26] is 'bzr selftest' supposed to work using the 1.3rc1 debian package? [09:03] siretart: are you seeing failures? [09:35] james_w: http://paste.debian.net/51435 [09:39] siretart: wow. you're not in a directory with a directory named "tests" or a "tests.py" are you? [09:42] james_w: no, I'm not [09:43] bzr & bzrtools seemed to work anyways, so I've decided to just upload bzrtools 1.3.0 to sid [09:43] I saw that, thanks. [09:45] is that perhaps because of python 2.4 instead of python 2.5? [09:45] no, doesn't seem so [09:47] is tests/* shipped in the binary package? [09:47] ha, it seems that builddeb is breaking selftest [09:47] after removing bzr-builddeb, the 'selftest' command works fine again [09:47] ah, you're not doing bzr --no-plugins selftest [09:47] well, I wanted to run the selftests on bzrtools [09:47] ok. I want to prepare a builddeb upload today, and it should fix all of this nonsense. [09:47] great! [09:48] sorry for breaking it. [09:48] just drop me a note, I'll sponsor it [09:48] no worries [09:48] great, thanks. [09:48] btw, are you DM or was that just jelmer? [09:48] that was just jelmer [09:48] ok [10:04] I use cygwin on Windows. Am I generally better using the cygwin supplied bzr or the windows version? [10:05] cygwin's python is usually slower [10:05] I'm currently using the Windows version which mostly seems OK but I am having problems with the sftp protocol. [10:05] VSpike: would you like to describe the problems? [10:05] I've found this https://lists.ubuntu.com/archives/bazaar/2008q1/036410.html [10:05] commit to sftp repo freezes [10:05] works from dos box, freezes in cygwin bash [10:06] so you have exported that variable? [10:07] I tried export BZR_SSH="paramiko" and that makes it output an extra line "Connected (version 2.0, client OpenSSH_4.6p1)" before freezing [10:08] I have not set up keys, so in DOS it prompts for password. I was basically wondering as next step, either try to set up keys or try out a full cygwin stack instead [10:09] I can install Cygwin paramiko, but I think I will have to use cygwin bzr to take advantage of it? [10:10] In the DOS box, it outputs exactly the same line and then prompts for a password [10:11] I thought paramiko linked to putty/pageant not openssh? [10:23] my windows bzr is 1.2 and the cygwin version is 1.1 ... will i have any problems if i downgrade? [10:30] Due to the fuss from the emacs camp, does 1.3 have any speedups for trees with large file counts? [10:31] cd .. [10:31] oops [10:32] awilkins: I think it was all a bit late for much stuff to go in to 1.3 [10:32] and it's not the large file count that the operations they are discussing are having problems with, it's the depth of history [10:32] which is >87000 revisions [10:33] Ah, ok then [10:33] My problems are the opposite :-) - 8000-ish revisions, about 30,000 files [10:34] But it's still worlds faster than SVN [10:34] (except the branching-from-svn part :-) ) [10:37] awilkins: that should hopefully be sped up soon. (if you are using bzr-svn) [10:37] awilkins: Yes, I hear those new pyrex bindings are the bees knees [10:37] awilkins: if you are having trouble with large trees posting to the list with the operations and profile data may help. [10:37] * awilkins is talking to himself again [10:37] :-) [10:38] james_w: I think my problems are less to do with bzr and more to do with filesystem performance on Win32 [10:38] it's more the "don't pack after every commit" that will make a difference, that's a separate issue to the bindings [10:38] james_w: I'll consider it, but as I said, it kicks the pants off SVN [10:38] james_w: Yes, that too [10:38] awilkins: ah, well you're on your own then :-) [10:39] seriously though, there may be ways to speed it up, so consider it [10:39] I can help you collect the profile data if you like. [10:39] james_w: Yup, after thursday I'll have some time ; I want to have a crack at building those pyrex bindings on Win32 (I have MinGW AND the MS 2003 compiler sitting in the wings wiating) [10:40] that would be very valuable, thanks. [10:40] Big Feature Push on at the moment (ie, meeting the consumers for an iteration meeting tomorrow :-) ) [10:40] james_w: I had a try at building them last week ; it's a TOTAL pain in the arse [10:41] I can imagine. [10:41] It's mostly SVNs fault ; APR is a breeze to build on Win32 [10:41] "Load the Visual Studio project we provide and as long as you have the SDK it works" [10:42] * awilkins rolls on the drum for Vista SP1 [10:44] "Your computer will reboot several times during installation" (you could write that on Bill GAtes grave....) [10:48] james_w: Are pack repos reverse-delta or forward-delta? [10:48] awilkins: they are based on knits [10:49] * awilkins is ignorant of what a knit is [10:49] hang on, which way round is reverse-delta? [10:49] You keep the current revision verbatim and store the deltas to get back to the previous revision [10:49] (at least, that's what I mean when I say it) [10:49] What RCS does [10:50] awilkins: no, it's forward-delta then I think. [10:50] I was thinking maybe if you had checkpointed verbatim revisions in there it might make the emacs deep-history thing better [10:50] But I am a novice :-) [10:51] it's graph/index operations that are slow, not the delta decompression of actual files === doko_ is now known as doko [10:51] oh, I think it does store full texts when the delta chain is too long or an individual delta is too large. [10:52] Jolly good, I'm glad something so obvious as to occur to me wasn't overlooked :-) [10:52] but as luks says, operations like log etc. are what they are talking about, which doesn't access the texts [10:52] Are per-file logs slow? [10:52] (as opposed to whole-tree logs)? [10:52] any log [10:53] * awilkins is surprised [10:53] log in bzr needs to sort the graph in many ways, in git just dumps the (almost) raw index [10:53] which is one reason why it's slower [10:54] Fair enough.... time to reboot for me, back in a mo [10:55] luks: git does need to sort the revisions, it just has less constraints on the sort. [10:56] in particular it needs to load all revisions with pointers to their parents, and then traverse the graph once before it can output any revisions. [10:56] it still takes bzr about 10s to do even that on the emacs repo [10:57] james_w: if I'm not mistaken, git doesn't even topologically sort them by default [10:57] luks: true, sorry, it date sorts them. [10:57] However it can still topo sort them very quickly. [10:58] but I was surpsised that with my toy repository format I was playing with a few months ago, I had log faster than in hg [10:58] and hg does much less work on sorting there [10:58] git log --date-order > /dev/null 2.76s user 0.09s system 98% cpu 2.900 total [10:58] luks: that's good to hear. How did your repository format differ? [10:58] getting rid of the xml revision format would also help bzr [10:59] --date-order is the strictest git log format, and the above is warm cache. [10:59] different indexes, bulk reads, no xml, ... [10:59] luks: that sounds good. [11:06] Well, you can say almost anything, and as long as you include "no XML" it sounds good :p [11:06] "I like to eat babies with mustard, relish, and no XML." "Wow, really? That sounds great!" [11:07] luks: What became of your toy format? [11:08] empty disk space, I think :) [11:08] or maybe it's still somewhere on the laptop [11:09] It sounds like it was good work. [11:10] well, in my experience with submitting patches to bzr, something like that would never be accepted [11:11] SVN working copies used to use XML, they traded "down" to a KV format instead and got large perfomance increases [11:11] I had a few more interesting private branches here, but almost never finished them because I realized I'm just wasting my time [11:12] I'm surprised that BZA is using XML in any of it's disk formats, to be honest [11:12] it's legacy thing, I guess [11:12] XML is not a serious bottleneck and if it works, why replace it [11:12] luks: why do you think they wouldn't be accepted [11:12] I mean, what, just loading those enormous libraries must account for a substantial fraction of startup time :-) [11:13] james_w: because even trivial patches sit in BB for months [11:13] awilkins: it doesn't use the large libraries I don't think. [11:13] luks: but if it has benefits I'm sure it will be appreciated, and I think it would get people looking at it pretty quickly. [11:14] james_w: Hmmph, I wrote a toy library for parsing XML in VB3 once ; I was amazed by the speed you can get when you just walk a pointer through a string buffer on it. [11:14] james_w: as an example, see the ML discusion about the revno patch [11:14] luks: If you still have it at least I would like to have a look. [11:14] james_w: I sent two mails to the mailing list, it improves performance significantly, and I got no responses [11:14]