Perl: March 2006 Archives

Luckily, I now have half of a solution to the Komodo Remote Debugging issue I previously wrote about, thanks to Peter.

I still don't have a solution to the PerlEx debugging issue. No matter how hard I try, there's no way I can get it to communicate with Komodo. I'm not too worried about it, though. It's not often you need to debug a perl application while in production, and I can deal with it later.

Peter found the same issue that I did. ActiveState's documentation states that you must change the application mapping in IIS to reflect 'perl.exe -d "%s" %s' to get perl to go into debug mode. This doesn't work, for a variety of reasons. Turns out, if you change the shebang in your cgi (#!/usr/bin/perl and the like) to add -d, but leave it out of the app mapping, debug mode starts up properly.

Sure enough, I tried it out on my IIS machine in a virtual directory, went to the script, and Komodo lit up just fine on my Mac.

Thanks, Peter.

After really getting into the idea of Catalyst, I've been inundated with projects that require a quick lead time and implementation. Hence, I've been going with the standard CGI::Application/Template::Toolkit suite within Perl to deploy applications. They're fast and work well, but don't have the raw sex that Catalyst seems capable of.

I've been rewriting the whatthefuck.com codebase over the past who knows how long to reflect the things I've learned in the years since I created the site. The current codebase has a lot of perl code surrounded by a lot of print qq~ ~; statements to render HTML. It's not pretty, it's not 'strict', and it's not mod_perl compliant. This rewrite has happened in CGI::Application, and has changed three times since I started it.

I figured, "screw it," and started rewriting it in Catalyst. I'm using the same templates, and the same general database schema, but moving it into a data modeled system on the Catalyst framework. Milestone 1 was hit tonight: the damn thing renders in Catalyst.

I'm on a Komodo kick here, sorry about that. I'm having some hell of a time trying to figure out remote debugging within Komodo.

So I'm using Komodo Personal 3.5 on Mac OS X, test environment is a Windows XP SP2 machine running IIS, no firewall, no port blocking, no antivirus, no antispyware. Komodo's running on a Mac OS X 10.4.5 machine.

I have:

• Installed the Windows Remote Debug for Komodo package (to c:\Perl \KomodoDebug)
• Set Komodo to listen to port 9000
• Set PERL5LIB to C:\Perl\KomodoDebug
• Set PERLDB_OPTS to RemotePort=[my mac's ip]:9000
• From the command line, started perl -d , and Komodo successfully did the remote debugging thing.

So, now I want it to work in IIS. Specifically, I want to know why this application dies in certain modules under PerlEx 3 with the ActiveState Perl 5.8.7 (815) package.

First, I tried changing the app mapping in IIS to 'c:\perl\bin\perl.exe -d "% s" %s', and it prompts for me to download the application. I manually edit the MIME types in IIS to always output text/html, and it just spins and spins and spins in the browser.

Okay, fine, I'll skip the perl CGI and go to PerlEx.

I create a key in HKLM/SOFTWARE/ActiveState/PerlEx/3.0/Classes called 'nx-d'. Inside are three string values: (LF being the ALT-1-0 trick)
CommandLineOptions = -d
Environment = PERL5LIB=C:\Perl\KomodoDebug[LF] PERLDB_OPTS=RemotePort=[my mac's IP]:9000
ScriptLocation=[full path to script, starting with c:, using backticks. seems to work.]

When running the CGI, it spins and spins and spins and never starts anything within Komodo on the OS X machine. I've noticed, once in a while, Windows shows an application unexpectedly quit issue regarding a COM loader. This is probably related.

I don't friggin get it. I was hoping writing it down would make some light bulb go off in my head.

No such luck.

Update: Debugging is now working using the standard perl executable!