Wednesday, October 8, 2008

Problem with Email::Valid and newlines

Found a strange problem in Email::Valid:

use strict;

use Test::More tests => 4;

my $email;

$email = '' . "\r";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = '' . "\r\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r\n" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = '' . "\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\n" at the end return undefined');
diag ("'" . Email::Valid->address(-address => $email) ."'");

From what I expect, that last test should pass. Email::Valid's docs do say that if address can munge the address, it'll return the munged address, instead of undef - but I have munging (or "fudging, in this module" *off* - as it is off by default). Carriage returns aren't munged, so why newlines?

Perhaps it's the last line in the module:

# Regular expression built using Jeffrey Friedl's example in
# _Mastering Regular Expressions_ (

$RFC822PAT = <<'EOF';
# Possibly the most insane regex... possible

$RFC822PAT =~ s/\n//g;

The test for validity changes the actual string being validated. Drrrrr.

And that kind of brings up another point: Why is a module called, Email::Valid and its validating method (address) also doing double-duty with wanting to munge the string I give it so it may possibly be validated? Sounds like you just need to methods there, validate() and, gimme_back_an_address_if_at_all_possible(),



Sunday, October 5, 2008

Perl Semaphores 'n stuff

This is a pretty good and gentle introduction into file locking and using semaphores in Perl:

I was having the exact problems being described:

Unfortunately, this means trouble for our flock-using code. Notably, there can still be a problem with instances being out of phase — since we can’t lock a file without already having opened it, things can still happen in that brief moment between opening the file and locking it. Consider when one instance is updating counter.dat just as another new instance is about to read it:

Instance 1                         Instance 2
----------------- -----------------
open COUNTER, ">counter.dat"
or die "Can't write-open: $!";
open COUNTER, "<counter.dat"
or die "Can't read-open: $!";
my $hits = <COUNTER>;


There, the OS dutifully kept two instances at once from having an exclusive lock on the file. But the locking is too late, because instance 1, just by opening the file, has already overwritten counter.dat with a zero-length file, just as instance 2 was about to read it. So we’re back to the same problem that existed before we had any flock calls at all: two processes accessing a file that we wish only one process at a time could access.

In a very very complex part of my app, that has to do with basically managing a queueing system - something that really really really should be written using a transaction capable SQL backend. If only I knew how to do that.

I combined the semaphore file with the, Highlander, THERE CAN BE ONLY ONE! Idea:

So if I can't get a lock, I can wait a little longer. I thought, "Hey, sounds like a good idea". It also sorta kinda puts a queueing system to the resources that a lot of different thingies want to hit, and hopefully, stop the programming from giving back errors like, all the fucking time. We'll see.

All the tests pass (you do write tests, right?), but using the app doesn't really... um, work. It's timing out. Most likely from the Highlander idea. More whackin' to do...


I've decided what computer programming is to me at the moment:

It's a hobby. It's a hobby that currently pays my bills, but to call it a job or a company that I have is not what's going on. I know this, because I explicitly attempt not to do what companies attempt to do really really well. One of these things is to try to sell you the product.

The product I make is free, so there goes that baby/bathwater.

I also write a book about the thing.

The book is just a bunch of HTML I create from a simple doc format. It's akin to me selling you plans on how to make your own land mower from the back of Popular Mechanics, or something.

Another thingy that companys are good at, especially in computer-stuff is automation. I do provide services to install the program. But I do it manually. There's no installer. And, that's stupid.

But if this is just a hobby - one that takes a lot of my time, I don't have a job. And art isn't making any money.

This is all going to come to a head, soon enough. But at least it allows me to identify myself as a, "hacker" rather than a software engineer, which I couldn't possibly be.

It also gives me something to put on my artsy résumé: Computer Hacker. That sounds almost hip. Would you like a painter that has a hobby of collecting pogs, or a painter that also has a hobby of hacking computers?

yeah, you're right, pogs win again.