Re: apt-show-versions rewrite
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.
Reply to: