Some clever twit figured out that if you HTML-escaped URLs then MT-Blacklist would miss 'em and you could get junk postings onto otherwise protected blogs.
There's a patch, or you can get the whole plugin (I definitely recommend it, along with the automatic blacklist updater, if you're running a MT setup) from here.
Mark Lentcsner, a very brave soul indeed, has put together "A periodic table of Perl 6's operators". There are an awful lot of 'em, aren't there?
Spammers have managed to pollute my bayesian filters. Dammit. And not in a safe way.
Just because, I decided to take a look at my spam folder. Normally I don't, I just unconditionally delete the damn thing. Today... well, I figured I'd look. Couldn't hurt, right? Only 10K messages, about 91M of crud, and it's not like there are words I've never seen in it.
Unfortunately stuff in there did upset me. Not because it was foul, obscene, tasteless, or lacking in any sort of aesthetic. Nope, it's because there was mail I recognized. For some reason the autolearning that SpamAssassin does picked up on some regular mailing list mail and mail from people I know. On the first page. Making me very unhappy, because now I need to wade through all the crap. (Well, only 6.5K more messages, though now I need to clean my shoes) Damn.
Topping it off, for some reason SpamAssassin thinks there's exactly one message in my training ham folder. (There isn't, there's about 25) And 1 message in the training spam folder (nope--about 2K). So something's busted there too. Gah. I hate software.
So, if you've not heard from me, don't be too surprised, and try again--you might've gotten caught by a rogue bayesian network.
So, like the good sysadmin I am, my home servers are completely un-backed-up. (Cobbler's kids always have no shoes, y'know) It's time to fix that, though.
Anyone have a recommendation for a good backup solution (with full and incremental backups) for Linux systems with CD-Rs as the target backup media? This beastie has about 160G of disk space and I'd hate to have to redownload and recreate all the stuff on it.
As I've been digging through the python bytecode decoder I found out where things were going "wrong" with it. As it turns out they weren't, there were just a few sensible but incorrect assumptions made in the decoding code. (Mainly that there's only one code object, which turns out not to be the case) It also explains why dis.py and Python::Bytecode were giving different answers--dis.py decodes the first code object in the file while Python::Bytecode got the last one. The fix is a touch convoluted, but not too bad to do.
Oh, and I've got about half the python bytecode instructions having direct parrot equivalents after doing a bit of stack-to-register decoding. The easy ones, of course, but you've gotta start somewhere. (I think I'm going to have to implement a good chunk of extended-precision math for this, since that's part of the python core. Parrot's got some that needs some swamping out, so I'll probably start there)
Or at least some of it.
The hacked-up version of Python::Bytecode will now load up the bytecode files that python 2.3.3 generated for the parrot benchmark tests. Of course, they're all wrong, but... first things first, I expect.
As I find poking around in the guts of Python::Bytecode. In this case, it looks like some bits of the python bytecode spec went from being 16-bit to 32-bit quantities. As you might imagine that makes just the tiniest difference when digging the guts out.
Looks like I need to implement a few extra basic types (at the moment python's extended precision integer) to get this all working properly. Should be fun.
As I'll be in Boston June 17th to give a talk to the Boston chapter of the ACM. Details on the details page. (The summary: An overview of parrot's architecture, then some in-depth on the tools we've built and the techniques we're using to actually create the software, since we do some odd things that folks may or may not have thought of)
I spent a chunk of this weekend working on the Pie-thon conversion setup. Since folks seem interested in this sort of thing (I'm not sure whether it's as a record of success or abject failure, so we just won't go there right now :) I figure I ought to note down what's going on--it's not like it'll make much difference one way or the other with the contest, so there's no harm as I see it.
There's also a new category for this if you're into that sort of thing. (Official trackback ping URL is http://www.sidhe.org/oldblog/mt-tb.cgi/253 according to MT) No RSS feed just for it. (And yes, I realize the "WTHI" feed is actually a glommed-together category feed, and I need to fix that too)
Anyway, here's where we stand so far.
I've been working with Simon Cozens' Python::Bytecode module as my starting point--it disassembles python bytecode to a readable text stream, pretty much the same way that the dis module in the python distribution does. Seemed to be a good place to start, given I know far more perl than python.
The module, unfortunately, only comes knowing about the v2.1 and 2.2 bytecode formats. Things have changed a bit for v2.3 and, while I've got a version I hacked up to try and load v2.3 bytecode, there's been no joy there so far--it gets to the magic number identification OK, but the bytecode past that it doesn't recognize, and a hexdump shows it being a bit different from 2.2 bytecode. Some poking around in the Python core has been instructive, but not enough that I've been able to get it going. (I expect that once I can get it to get to the actual code it'll work, but...) There may be a few extra constants in there now that I look at the hex dumps again. Hrm. Going to have to poke in the python source some more. (I now see the value of editors with function name completion, FWIW)
In the mean time, I've been taking a look at the dis module instead. This ships with python and provides disassembly services along with a command-line interface that'll take python source, compile it, and provide the disassembled bytecode. I've gotten a bit further with this, though it's got a serious limitation that's getting in the way--it only disassembles the first function in the source, and doesn't dump the constants out in a useful way. (Not that this is a bad thing as such. It's still quite useful) Still, a place to start.
I've also got the start of a conversion scheme from python bytecode ops to parrot ops. This has the additional issue of having to do stack to register scheme translation, which could be a big deal in hand-rolled code but I expect it won't be a problem here. I think I may well do at least one intermediate representation, though, rather than a direct conversion. We'll see.
I'll post the code for this stuff as I get it going.
Though I suppose it's well past that time.
SixApart announced the new licensing scheme for Movable Type 3.0. I'd figured something was coming down the pike reasonably soon--given their setup there wasn't any way they could sustain their development and actually have people eat. And, while the new prices seem more than a touch high, well... hell, it's their code, they can do what they want with it. The part I haven't been looking forward to isn't the cost, but rather the inevitable whining. Boy, has there been whining.
Most of it has been "Oh, this software which I have no intention of ever paying anything for I now must pay for! Never! I shall use something else, and that'll show those mercenary bastards!" Or... maybe it won't. If you never paid for it in the first place why the hell should they give a damn what you do? (And no, you aren't good advertising. Please, by all means, get over yourself) And if you did then you got the software you paid for (2.661's actually quite nice) and if you want to be pissed then yell at the people who leeched off the folks that made it possible. The only folks with legitimate gripes are the ones who moved over to the betas of 3.0 and may get left stranded. They ought to be getting free licenses if they'd be in violation otherwise.
SixApart made a toy once, and said please pay for it but we won't force you, and generally people didn't. That was OK, you didn't have to.
Now they're making a new toy and saying you have to pay for it if you want to do much with it. That's fine too.
Bloody hell, when someone offers you something you smile and nod and either say "Thanks!" or "No thanks!" Bitching that the thing you're being offered doesn't meet your standards is unbecoming. (And that pain you feel is the cuts from your shattered illusions. Life does suck sometimes, doesn't it?) The outrage is just public ego wanking, and the world'd be a better place if people did that in private and washed their hands afterwards.
If they've screwed themselves over with the new pricing scheme then they'll fail. There are alternatives out there--if they're good enough, people will move, and if they're not good enough but the price is enough to make up for it, people will move. That's the way this stuff works.
Tuesday May 11 2004 will forever go down in history as the day Invader ZIM officially hit DVD.
I think I can feel my wallet quaking in fear over the doom about to befall it.
No, it's not done, but I'm starting in on it. The original one got sufficient of whatever O'Reilly wants from OnLamp articles to warrant a second, so...
Since there's still some (though not a whole lot) of time before I start in, this'd be a good time to weigh in with suggestions on what should be in the article. I figure on at least control flow (since, y'know, being able to do if statements is awfully nice) and maybe subroutines, but beyond that it's up in the air.
If there's a definite want of something, add a comment.