Wednesday, October 21, 2009

Making Catalyst Debug Logs Really Be Quiet

I have recently been adding and updating tests to my biggest Catalyst project and have been a bit perplexed by the debugging output...in particular that I was seeing any of it! Generally, I like to see all that output scroll by, but when running Test::WWW::Mechanize::Catalyst tests over and over again, it just clutters things and obfuscates any failures.

I had removed -Debug from the plugin list and tried CATALYST_DEBUG=0 env variable, but I continued to see a lot of the debug messages. After a bit of googling, I finally learned that this was a feature.

The -Debug flag and CATALYST_DEBUG env variable are just for the internal Catalyst debug logs. What I needed to do was to set the log levels with MyApp->log->levels to control what is dumped with $c->log->debug and its brethren. In general, I want my custom debugging and the internal Catalyst debugging to be tied together, so I added the following to lib/MyApp.pm after __PACKAGE__->setup:

Wednesday, October 14, 2009

Moving to a Mac... which Perl?

We'll after neglecting this blog for quite some time, I'm now back. I had to swap my laptop during the summer, and I decided to give one of the MacBook Pros a try. So I'll be adding Perl on the Mac and the Mac in general to the topics covered here. My first dilemma with the new Mac was which perl to use.

Leopard only had 5.8 installed, and I've been hooked on 5.10 for a while now. (Snow Leopard has added 5.10, but by the time I got the upgrade I was commited to the ideal of keeping the system perl separate from my development perl.)

Having come from Arch Linux, I stumbled upon and really liked Arch OS/X. Unfortunately, it appears that it isn't as well tested as MacPorts. In order to build any Perl modules that us XS with the Arch OS/X perl, I needed to use:

Ummm... I don't think so! While I created an bash alias for it, cpan/cpanp where requiring constant tweaks. I assume I could have exported those variable from my bashrc, but I would rather avoid global changes like that.

Next I tried compiling my own perl. I ended up doing it several times as I learned where to put it, and realized I had forgotten to enable things like threads. This really seems to be the best way to go, but I would rather someone else keep up with security patches, new versions, etc.

So finally I tried MacPorts. So far so good. I have had trouble remembering to check the variants (port variants <port-file>), but otherwise thumbs up.

One thing I realized that I want, is a record of all the ports that I have installed (not a list of all the installed ports, just those that I had purposely installed). So, I wrote a short bash script that I stuck in ~/bin/port to keep a log:

Now anytime I run port install perl5.10 +shared +threads it is added to a log file. Rebuilding the system should be a snap. (I'm sure I could have gotten this by grepping for sudo and port install from the /var/log/system.log* files, but I like having it all in one place and not worrying about log files being rotated out.)

One other tweak I need to make, was for CPANPLUS. I wanted to be able to install modules in either the system perl (by running /usr/bin/cpanp) or the MacPort perl (/opt/local/bin/cpanp), but both of those read my user config file (~/.cpanplus/lib/CPANPLUS/Config/User.pm) which need a full path for perlwrapper => '/usr/bin/cpanp-run-perl'. So I moved just that part of the config to the system config file by runnning the following in each cpanp:

$ s save system
$ s edit system

Then removing everything but the perlwrapper configuration. And finally taking the perlwrapper configuration out of my User.pm file. One other thing I needed to do to make 5.10 the default perl. MacPort defaults to perl5.8, but the following took care of that: