2009-07-14

Logging modules for perl

I recently decided not to create a logging class of my own, since there must already be a lot out there. Not surprisingly this proved to be a correct decision.

I started looking for packages already available for Ubuntu, and found Log::Handler, Log::Log4perl, and Log::LogLite. I started drafting prototypes for them.

2009-07-01

F: {alignments} -> {tree topologies} is continuous

If the title is not clear enough, it means that the function that maps alignments of genetic information to phylogenetic tree topologies is continuous. Well, kind of. It's a scientific proof, not a mathematical one, so it's based on evidence. But as far as evidence goes, it makes a compelling argument in favor of the thesis.

The paper is Wong, et al, 2008 (Science) "Alignment Uncertainty and Genomic Analysis". DOI: 10.1126/science.1151532 .

The relevance IMHO of this paper is not to estabilish that 'common sense' is usually correct (although it is important in its own matter to know when it's possible to infer things solely from ituition). The authors make the case for interpreting alignments themselves as random variables, and in doing so, they conclude that (in a very precise way) small variations in alignments produce small variations in tree topologies inferred from those alignments. More so, they indicate this result is robust in respect to methods of inferring phylogenetic trees.

For the mathematically inclined, they defined a metric in the set of alignments, a metric in tree topologies, generated alignments (via MCMC) that were near the reference alignment, and observed that the resulting trees all had topologies near the reference topology in the given metric.

This CPU intensive work was done for alignments of whole genomes, with several alignment techniques and tree inferring algorithms, with similar results for most cases. Definitely worth a read.

(UPDATE: fixed title typo)

Migrating mail filters from MUA to MDA

I like freedom of choice. A lot. I even like to be able to choose different alternatives for common tasks during the course of the day. Call it a whim, but when it comes to mail programs, I can never decide, really, what's the best for me. Maybe this is because I never found one that suits all my needs.

Nevertheless, I used to use KDE before I became an Ubuntu user, and from that time I kept my whole PIM suite in the KDE stack from Dapper 6.06 to Hardy 8.04. Enough is enough, and if I'm not using KDE I wasting precious RAM and cycles keeping all those libraries loaded just for kmail and amarok. I will surely miss amarok, and kmail was great but it's time to move on.

I wanted my PIM to sync both from my Palm PDA and my home desktop, laptop, and workstation at work. I'm not a big fan of third party cloud services, if I can't be sure who has access to my data, so I decided to go back in time and migrate from a fully-featured-MUA centered setup to a home cloud-like setup. Provided I can access my PIM data from whatever MUA I choose, I can use pretty much anything that talks IMAP (which is anything these days). I'll be truly free, then, to use a great GUI app for the daily routine, a light GUI app if I need RAM to do more resource intensive work, and good old pine (ressurected as alpine) if I need to access my mail remotely, via ssh.

The project is basically to store everything in the desktop an imap server in my desktop machine, POP3 accounts fetched by fetchmail , and fed to an MDA (procmail or maildrop).

I already had kmail store my mails in maildir format, so installing an imapd server was a matter of installing the package. After a brief poll in ubuntu-users mailing list I installed dovecot, and kept using kmail for a year or so later to pull my gmail mail via POP3. Now, I'm only accesssing my mail via IMAP since the upgrade to Jaunty, so my home cloud project is kind of stalled.

I'm in the process of testing gnome-pilot and opensync to keep my PIM and Palm PDA synced.

All that remains is to migrate my mail filters from kmail to an MDA (be it procmail or maildrop), and then use fetchmail to get mail via POP. This is where I'm stomped. So far, the only think I've found that resembles a solution is this perl script, except it's the oposite of what I want. I'm not even sure I can use it to create the reverse solution I need.

I've drafted a little perl script, and I'll probably have to do it from scratch since my needs are pretty modest. I have 100+ filters (too many to convert manually), but most or all are the kind of 'match and move to a folder' simple filters. I'm just trying to scratch my own itch, not create a general purpose application, so it's probabl y a matter of simple Perl, once I decide what exactly will I output to.

Since time is always in short supply, if anyone knows a way to convert filters to either procmail or maildrop, I'll be glad to hear it. I also welcome suggestions on which of these MDAs to use.