use Perl

perl-tidy-mode

From the docs it sounds like it runs perltidy when you save your file. That doesn't sound terrible, but I like my solution better. I have bindings so I can run perltidy on-demand, either on the whole file or on a particular region. Check it:

(defun perltidy-region ()
    "Run perltidy on the current region."
    (interactive)
    (save-excursion
      (shell-command-on-region (point) (mark) "perltidy -q" nil t)
      (cperl-mode)))

(defun perltidy-all ()
    "Run perltidy on the current region."
    (interactive)
    (let ((p (point)))
      (save-excursion
        (shell-command-on-region (point-min) (point-max) "perltidy -q" nil t)
        )
      (goto-char p)
      (cperl-mode)))

(global-set-key "\M-t" `perltidy-region)
(global-set-key "\M-T" `perltidy-all)

-sam

/home/stregar/bin/spamc: Transport endpoint is not connected
procmail: Program failure (126) of "/home/stregar/bin/spamc"

That's coming from a call to SpamAssassin's spamc client program, but the same error happened with any pipe call in my .procmailrc. I spent a long time distracted by the "Transport endpoint" business. It just sounds so authoritative and networky. But as far as I could tell the network was completely normal.

Finally I turned to the next line with it's enigmatic magic number 126. Turns out that's a return code from the shell call to run the pipe. And 126 is bash for "file not found." It all came together when I realized that $HOME on the mail-recieving host was no longer /home/stregar! As soon as I switched to using $HOME instead of hard-coding the path everything started working.

So, google, if you would be so kind, please index this report so that others may not have to stumble around for quite so long.

-sam

   $ perl -MDateTime -e 'print DateTime->now()'
   2006-04-04T23:08:37

   $ perl -e 'print scalar localtime'
   Tue Apr  4 19:09:10 2006

It seems that DateTime->now() doesn't do what I thought it did. I thought it returned the current date and time at this point on the planet. What it actually does is return the current date and time in UTC! (And please don't tell me that DateTime can't reliably figure out my timezone. Perl's localtime() manages just fine!) (You can, however, lambaste me for not reading the DateTime docs, since it's quite clear that now() doesn't return local time.)

Unfortunately I discovered this only in the late stages of testing version 3 of a large application that makes moderately extensive use of Datetime. That means the "easy" way to fix this, namely:

    $ perl -MDateTime -e 'print DateTime->now(time_zone => "local")'
    2006-04-04T19:12:03

Isn't so easy, as it would mean touching a lot of files.

As far as I can tell I don't have a lot of good options here. I'm going to make a sub-class of DateTime which defaults to "local" for now(), new() and from_epoch(), but that will still mean touching lots of files. I did find discussion of this problem on the DateTime lists, but I don't think a solution made it into the module.

I did discover that Tim Bunce considers my chosen solution "trivial", whatever that means!

-sam

   $ export FOO=bar
   $ echo $FOO
   bar
   $ sudo bash -c 'echo $FOO'

   $

That's right, sudo no longer passes through environment variables by default. I don't know about you, but this seems quite likely to bite lots of code I write. I often do environment setup (PERL5LIB, PATH, directory roots, etc) and then run a sub-process as another user via sudo. I'm expecting a flood of reports of problems from DBD::Oracle users as they find that ORA_HOME mysteriously stopped working when the upgrade to FC5.

The fix is easy, just undo the change discussed here:

http://www.redhat.com/archives/fedora-devel-list/2006-February/msg00382.html

I like Josh Bresser's comment about this change:

as long as there is a release note about it, it will only surprise the people who don't read the release notes

I guess that's true. Only problem is, it wasn't put in the release notes!

-sam

PS: Shout out to Michael Peters for tracking this one down.

There's nothing quite like some justified optimization to get the heart pumping. I've been working on a system which needs to produce multipart MIME messages very quickly. It's using MIME::Lite, which, it turns out, isn't actually all that lite. After solving the other bottlenecks in my code I was left with around 30% of my processing time locked-up in MIME::Lite's code.

My first stop was MIME::Fast. It certainly is fast, but unfortunately it also has some large memory leaks. Running at full speed it was losing around 5MB per second! I spent a few hours confirming that the leaks are somewhere in the huge XS codebase of MIME::Fast and not in the underlying gmime library. I gave up and filed a bug with the author.

That left me back with MIME::Lite, so I decided to see if I could speed it up. After a few hours of work I've come up with a patch which offers a 50% speedup for my use-case (creating two-part messages from parts in memory). For the curious, here's my work-log:

• Starting work => MIME::Lite is building messages at 750/s
• Use direct hash access for Attrs => 900/s
• Change how Attrs are stored, moved sub-attrs into a separate structure. This avoids the {''} access for the vastly more common case of attribs without sub-attribs. => 980/s
• Did some work optimizing fields() which is a hot method. => 1046/s
• Tightened-up fields_as_string a bit. Might be worth making the pretty-printing optional if the spec doesn't require it. => 1057/s
• Started testing with more realistic part sizes, new base => 910/s
• inlined the popular routine known_types() => 930/s
• Played with speeding up IO_* to little effect. Removing the wrap() indirection entirely would no-doubt help but it's a big project.

I sent the patch to the MIME::Lite maintainer, so hopefully this code will be available to all someday soon.

-sam

I released HTML::PopupTreeSelect::Dynamic yesterday, a dynamic AJAXified version of HTML::PopupTreeSelect. Instead of sending the entire tree to the client when the page loads, the new dynamic version renders the tree on-demand, retrieving nodes via AJAX requests. The result is a widget that can browse arbitrarily large trees without imposing long initial page-load times.

This was a learning experience for me - I'd never used the Prototype library before. Now I'm wishing I'd encountered it earlier - it would have made a number of Javascript-intensive projects much easier. I also got a chance to play with HTML::Prototype, which makes using the Prototype library from Perl a breeze.

All this learning will hopefully help me in the near future. I'm planning a much more involved DHTML/AJAX application as part of the continued development of Arcos at Plus Three.

-sam

Working on MKDoc can be hard. It's a great system in many ways but every so often I get completely lost. I'm starting to think that fundamentally it's a naming problem. For example, consider the word "editor." MKDoc uses "editor" to mean four different things:

1. The table which holds all users is called Editor.
2. A user is considered an "editor" if they have editing rights to at least one document.
3. The code that controls the part of the UI where users edit content is called an "editor." The base class is flo::Component but all the sub-classes live in flo/editor.
4. The code that allows a document to be loaded and saved to the database lives in flo::Editor. This one is the hardest to characterize - it's probably implementing a design-pattern I don't know. Maybe the "editor" pattern? God, I hope so.

All this means that when you see a variables called $editor in MKDoc you really have no idea what you're dealing with. It could be a user, a specific type of user, a UI editor or an abstract encapsulation of the act of editing a document. That's hard.

So please, people, get your names right from the start. And if you can't get them right at least be consistent and careful. Having even two things named the same is bad. Having four is like declaring war on maintainance programmers.

-sam

http://sam.tregar.com/dbiprof_progress.png

That's the screen that pops up when you access a runmode of a CGI::App using the module. It shows profiling data for all DBI usage triggered by the request.

Of course, if it was done I'd be releasing it. I need to figure out why I'm getting bogus statement-less profile nodes (might be the fault of my test app rather than DBI::Profile). I also need to test it with a persistent DB handle between requests. I think I might need to make a patch to DBI::ProfileDumper to get that working right.

I'll also need to wait for CGI::Application v4.0 to release the module since it uses the new callback interface.

-sam

http://search.cpan.org/~samtregar/Data-Phrasebook-Loader-ApacheFormat/

I'm in the design stages for another module which will leverage this one - basically a CPAN version of the Krang::Message user-alerting system. More on that later.

-sam

http://jobs.perl.org/job/2690

Speaking personally, I highly recommend you apply for this job immediately if you live in New York, love coding in Perl and would like to see the Democrats regain control of America. I've been loving my time at Plus Three and I'm sure you will too.

-sam