Journal: The mod_perl debugger you've always wanted on 2010.07.22 12:53
"The mod_perl debugger you've always wanted" is on my new blog at: http://bit.ly/agzWSU
"The mod_perl debugger you've always wanted" is on my new blog at: http://bit.ly/agzWSU
I need a system tray launcher too. I realized today that my newest work in the perl debugger really wants a desktop component so that I can just keep my running debugger multi-prompt going and ready for new connections, etc but have an appropriate UI to it.
Hi,
This blog post is actually at http://blogs.perl.org/users/josh_ben_jore/2010/07/unicode-in-perl-ftw.html.
Hi, I posted to my new blog at blogs.perl.org:
http://blogs.perl.org/users/josh_ben_jore/2010/07/under-the-covers-of-perldoc.h
Hey, what's with the bitwise operators? Would ordinary boolean operators work here or are you doing this for some invisible-to-me precedence reason?
In http://nerds-central.blogspot.com/2009/09/tuning-jvm-for-unusual-uses-have-some
Allegedly adding -XX:-DontCompileHugeMethods to the command line eliminates this limit.
Hi, this API is lacking. You're modifying state and expecting it to get used elsewhere and maybe it or maybe it won't or maybe something else now will fall over because things are possibly "strange."
Further, there's little reason for a user to think that loading something that looks like a class isn't going to be the normal sort of idempotent action we normally expect "Yes please, this I require that class X be loaded".
Quite sure this use of use() ought to look unlike a regular class-loading use of use(). Or the class loading could load HomeDir but replace it's environmental db with something custom?
Perhaps something like:
sub import {
$File::HomeDir::ENV = {
%main::ENV,
HOME =>...
};
}
I was debugging some test failures earlier this morning but they were in the middle of a long test script. I thought it'd be nice if I could step through the test with the debugger and just stop whenever a test failed.
Here's the result. A test failure immediately followed by being in the debugger:
not ok 236
14: return $result;
DB<1>
I use Zeus zxtm's SOAP API. IIRC, when I look at the wrong place I get documentation like "this is a char[]". The SOAP API documentation does actually get around to naming what the available keys are. Thus far I've never actually had to resort to reverse engineering because the entire API really did seem to be documented (if lightly fragmented).
I'm using using WSDLs from Rake in Ruby. Works fine.
I made it into a shell script so I'd have a working groups program since Mac OS X 10.6.2 has a "wrong" version. The shell script is dumb and just assumes it's ok to read 32 ints.
#!/bin/bash
cat >/tmp/groups.gdb <<EOF
print \$ngroups = (int)getgroups(0,0)
set \$groups = (int*)malloc(4092)
set \$ngroups = (int)getgroups(\$ngroups,\$groups)
x/32d \$groups
call (void)free(\$groups)
detach
quit
EOF
gdb -x/tmp/groups.gdb -p $1
Ah. Ok, it works provided the value is valid UTF-X, Perl's more permissive variant of UTF-8. When I'd tried your snippet I copied my original post but the rendered blog post had a space inserted into the middle of the string which made the value no longer be valid UTF-X.
Also, utf8::decode returns a boolean indicating whether it did anything. Presumable this means your function should read as follows. This leaves both the interpretation of the string up to Perl and also lets us eventually abort when there's no more work to be done according to perl.
1 while utf8::decode( $str );
As a note, utf8::decode is implemented by sv_utf8_decode of sv.c which will abort when the string stops being valid UTF-X.
Actually, that would apparently work if the value being decoded were fully valid but it doesn't because the input was an abuse of Unicode.