David, especially after reading http://raphaelhertzog.com/2010/12/10/people-behind-debian-david-kalnischkies-an-apt-developer/,
I can see how my original post would totally get under your skin. I definitely didn't intend to do that; apologies! This project was motivated by one major thing: certain operations involving libapt are way slower than they need to be. You mention that "time spent rewriting parsing code is time that could add new features." That's surely true, but the functionality of APT as stands is sufficient for my needs. The performance of that functionality is not. I do *not* intend to rewrite the entirety of APT -- I hoped to rewrite the underbelly, the part furthest away from the user. As soon as I can, I'll then take the current APT code, and drape it over what I have. I suspected it would be easier to graft the toplayer onto a new bottom layer designed for multicore/fastdisk than it would be to retrofit the existing code. Reading your quoted words: "APT2 isn’t much more than the name—which I completely dislike—currently from a user point of view, so I can’t really comment on that. All of them make me sad as each line invested in boilerplate code like configuration file parsing would be in my eyes better be spent in a bugfix..." raptorial currently has 150 lines of lexing, a third of which is comments. Not that much boilerplate code. The emphasis here is on parallelism and algorithmic improvements. As you and others pointed out, mine is a "fairly limited" lexer. That is by design, as lexing files is a solved problem. I had hoped that by presenting advanced technology for the sinews holding things together, it would be assumed that I could handle copying over crap lexing state machines. Apparently not. "be spent in a bugfix or new feature instead, but I am not here to tell anyone what they should do in their free time…" If you accept my point of view that lackluster performance is a bug, I've been working on a bugfix, though admittedly a highly invasive one. One can't point at DBTS, perhaps, because if someone say went and filed a bug claiming "your shit is slow", I think we can all agree they'd be invited to provide patches and measurements, if the bug wasn't closed outright. Well, your shit is slow (though feature-awesome!), and my shit is fast (though feature-starved!), and I'll provide timings if you're interested, or I can happily just keep it in SprezzOS. But every time someone's wrenched from a solid work flow by waiting around on some APT ecosystem operation for that sick second that separates smooth interactivity from "slow piece of garbage computer!!", it's a bug to them. I'm on #debian-apt and will hang out there today. Perhaps threading out the existing APT core won't be as painful as I expected, especially since a viable design effecting proven speedup already exists? Let's talk. Hack on! --nick -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130315113042.ga22...@qemfd.net
