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."
(shell-command-on-region (point) (mark) "perltidy -q" nil t)
(defun perltidy-all ()
"Run perltidy on the current region."
(let ((p (point)))
(shell-command-on-region (point-min) (point-max) "perltidy -q" nil t)
(global-set-key "\M-t" `perltidy-region)
(global-set-key "\M-T" `perltidy-all)
/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
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
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.
$ perl -MDateTime -e 'print DateTime->now()'
$ 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")'
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!
$ export FOO=bar
$ echo $FOO
$ 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:
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!
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:
I sent the patch to the MIME::Lite maintainer, so hopefully this code will be available to all someday soon.
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.
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:
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.
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.
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.
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.