Evolution spam

Ok I think I’ve got it now. Here’s how I did it:

  1. Install Bogofilter
  2. 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.
  3. 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.

Advertisements

4 Responses to Evolution spam

  1. Dmitri Trembovetski says:

    Hey Roman,

    pretty interesting. How fast is the per-pixel access (via BufferedImage.getRaster().get/setRGB to an image with native databuffer?

    Dmitri

  2. Seo Sanghyeon says:

    Somehow I enjoy doing close-to-the-hardware stuff.

    John Carmack said it best: “Low-level programming is good for the programmer’s soul.”

  3. roman says:

    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.

  4. Dmitri Trembovetski says:

    > 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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: