Life... draining... out..., ruby-1.8 to blame

I wish Ruby were as useful as Perl. I wish the following had the arguments like I'd get from any perl program using Carp. I also wish this code had just used perror(3) so it'd report the ordinary message "Address already in use" instead of making up its own message "no acceptor."

My phone knows perl

It's cool to run perl on my phone. I tried compiling bleadperl on it just now but it didn't generate a Makefile. I guess I'm going to learn how the configuration system works now. The last few weeks have been endless yak shaving. I tracked down some debuild problem through diff to FSF's diffutils and all their various versions, learned how to override parts of Makefiles for ExtUtils::MakeMaker, installed and set up Gnus, have been getting into the internals of Git in a fairly serious way.

debuild makes both the binary and source packages. It's nice for presenting the whole picture to someone trying to follow along later. debuild uses dpkg-source to generate a diff between the vendor's source package and the source tree used in the actual debian build. dpkg-source uses your diff which probably comes from diffutils-2.8.1 which was the last release in 2002 (http://ftp.gnu.org/pub/gnu/diffutils/).

You'll miss composable functions

In perl or almost any other functional language (I guess) you can combine functions together and the innards of one thing aren't going to affect the flow control of the other. Here's a simple bit of perl:

method trap (CodeRef $block) { $block->() } uffda(); # Called in Perl, not called in Ruby}

method moo (... ) { trap( sub {

# Early return because... return... if...;

... } );}

Writing the equivalent flow control in Ruby and I found out today that the return() calls go all the way through and past the wrapping "trap" function.

WTF? I don't think I understand how Ruby programmers put up with this. Maybe 1.9 is better about this.

git up to date

One of my esteemed prior co-workers recommends that I follow git releases very closely. I've added a "git-update" command into my path so I can just say "git update" occasionally to get all the newest features and bugs.

Add remote debugging terminal to mod_perl

Occasionally my mod_perl servers go sour and it's useful to attach a remote debugger. There's typically no useful console and production doesn't run under the debugger. I'm forced into two things: force load the debugger with Enbugger and then have it connect to a remote terminal.

Loading DB routines from perl5db.pl version 1.28Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

xmain::((eval 982):1): print STDERR $@ DB<1> 0 0 DB<1>

Step 6: Now detach to resume your program. You've interrupted your program at two levels. First at perl, so run "c" to continue out from the perl debugger. Second, in gdb so "detach" or "quit" to continue the process.

12:05 AM

Get a stack trace from your running perl

When you've got a process that's spinning and don't know what's going on, it's useful to get a perl level stack trace. There's a "simple" gdb function to get your perl to write its call stack to STDERR. It's not entirely without risk to corrupting your process. I've used it just fine against my mod_perl in prod when all our other normal methods of inspection failed.

Step 2: Get a C level backtrace to see if that's informative enough. In this case, I can see the program is current in some sleep functions. In prod, I've seen things like bugs in libxslt show up nicely here - I could see the stack extending down into the libxml/libxslt libraries which eventually lead me to solve the problem by upgrade my libxml library.

Step 3: Get your thread context pointer. For threaded perl, you'll need to pass in a thread context pointer. If this step returns 0x0, you don't have threaded perl and shouldn't pass this argument in. If you get something other than 0x0, you'll need to use this value.