Evolution spam
Ok I think I’ve got it now. Here’s how I did it:
- Install Bogofilter
- Remove the spamassassin plugin. Disabling it is not enough, I had to dorm /usr/lib/evolution/2.8/plugins/org-gnome-sa-junk-plugin.eplugI noticed this problem when running evolution from command line, which spits out a warning that one plugin couldn’t be loaded because another one is already installed. Pretty stupid bug if you ask me.
- Feed bogofilter with some spam (that’s the easy part, simply mark at least one incoming spam mail as such) and some ham (that’s a little tricky because all mail initially comes into the inbox. I did this to learn one random mail from my inbox:cd .evolution/mail/imap/roman@kennke.org/folders/INBOX
bogofilter -n 9999.
Now it seems to at least do something. Lets see how it works out when the filter is trained better.
Today I’ve been working a little more on Jamaica’s WindML implementation for BufferedImage, which is shaping up nicely now. ARGB8888 is now quite fast (not accelerated by the hardware though) as is ARGB1555 (this one’s hardware supported but not really accelerated as it’s represented in the generic memory pool). The missing pieces are RGB565 images and VolatileImage for the real accelerated stuff in video memory. Somehow I enjoy doing close-to-the-hardware stuff.
February 3rd, 2007 at 3:09 am
Hey Roman,
pretty interesting. How fast is the per-pixel access (via BufferedImage.getRaster().get/setRGB to an image with native databuffer?
Dmitri
February 3rd, 2007 at 7:25 am
Somehow I enjoy doing close-to-the-hardware stuff.
John Carmack said it best: “Low-level programming is good for the programmer’s soul.”
February 3rd, 2007 at 2:37 pm
Dmitri: Well depends. For the ARGB888 buffer the performance is as good as it can get because it’s a plain memory buffer. The ARGB1555 buffer is different because that one is managed by the graphics chip. The incoming/outgoing pixel data must be converted to/from a device depended representation by the graphics driver, which supposedly slows down the transfer. OTOH, the big win is that these images can be blitted and drawn upon_much_ faster than the ARGB8888 images (which need alpha conversion and copying because the graphics driver does not support alpha channel). I haven’t done isolated benchmarks on the implementation but in the context of an application that I have here it certainly feels much faster. And after all, pushing and pulling pixel data is not what most application normally do.
February 4th, 2007 at 9:19 am
> And after all, pushing and pulling pixel data is not what most application normally do.
You’d be surprised =) After all, BufferedImages were added in part to ease direct access to pixels.
Well, sounds good anyway.
Dmitri