Slashdot Mirror
Pro Perl Debugging
Michael J. Ross writes "The typical computer program has more bugs than there are ants at a picnic -- except ants are usually easier to find. Programs written in Perl are no exception, because the compactness of the language does not make any existent bugs easier to spot; they can simply be packed into fewer lines of code. To help remedy this problem, Richard Foley and Andy Lester, two seasoned Perl programmers, offer a new book, Pro Perl Debugging: From Professional to Expert." Read the rest of Michael's review.
Pro Perl Debugging: From Professional to Expert
author
Richard Foley with Andy Lester
pages
269
publisher
Apress
rating
8
reviewer
Michael J. Ross
ISBN
1590594541
summary
A comprehensive tutorial and reference for the Perl debugger
This title was published in hardcover in March 2005 by Apress, a relatively new member of the technical publishing world. The publisher has a Web page for the book that includes links to all of the source code in a Zip file, the table of contents in PDF format, and a form for submitting errata. The book comprises 269 pages, the majority of which are organized into 16 chapters: Introduction (not to be confused with the true Introduction immediately preceding it), Inspecting Variables and Getting Help, Controlling Program Execution, Debugging a Simple Command Line Program, Tracing Execution, Debugging Modules, Debugging Object-Oriented Perl, Using the Debugger As a Shell, Debugging a CGI Program, Perl Threads and Forked Processes, Debugging Regular Expressions, Debugger Customization, Optimization and Performance Hints and Tips, Command Line and GUI Debuggers, Comprehensive Command Reference, Book References and URLs.
For programmers who wish to learn how to fully utilize Perl's debugger, what options are open to them? A terse summary of the debugger's commands are always close by, within the debugger itself. Those Perl coders who have yet to try the built-in Perl debugger, really owe it to themselves to give it a whirl. In most cases, it is superior to embedding lots of "print" statements in your scripts, and then wading through the results. Simply include perl.exe's -d flag on the system command line, and you should be put right into the debugger, and see the debugger's "DB<1>" command prompt -- the "1" meaning that it is ready for your first command. To display the aforementioned command summary, simply enter "h", or "|h" to see the output one screen-ful at a time, which you will probably want to do unless your system window can show all of the dozens of lines at once. The command summary is best used as a quick reference, and naturally cannot be expected to serve as any sort of tutorial. Yet it has its use, and for that, it's fine.
Most Perl books devote at least some space to explaining the basics of firing up and using Perl's debugger. The (in)famous "camel book," Larry Wall's Programming Perl, has a chapter on the debugger. It covers breakpoints, running, stepping, tracing, displaying code, commands, debugger customization, debugger options, unattended execution, creating your own debugger, and performance profiling. Aside from that last topic, the chapter is mostly an expansion of the command summary mentioned earlier. It is sparse on examples, and does not cover any advanced topics, such as using the debugger in the context of forking, threads, and POE, as well as the debugger's special capabilities for regular expressions, CGI programs, and shelling out.
The advanced topics are where Pro Perl Debugging really shines in relation to the coverage that I have seen in any other book, partly because the authors have the space to thoroughly explore those topics in depth, and to provide much more meaty examples, with adequately illustrative sample code. Even for the more complex topics, the writing is clear, and the examples are worthwhile.
The authors clearly intend for the book to serve as both a comprehensive tutorial and a reference for the Perl debugger. In both respects, they succeed admirably. But the practical value of their accomplishment could be called into question by any programmer who has grown tired of the limitations of the Perl debugger, and has switched over to any Perl-capable standalone GUI debugger or integrated development environment (IDE). More specifically, watching a variable change value, while stepping through the lines of a Perl script using the debugger, requires that the programmer manually or programmatically echo that variable's value, by issuing a print command ("p") followed by the variable name, one way or another. This process quickly becomes tedious when multiple variables need to be watched, because each individual variable must be printed, one at a time. Admittedly, previously entered print statements can be recalled by using the up-arrow key, but only if the particular command has not been pushed out of the debugger's limited storage. This usually becomes even more frustrating when trying to print the values of indexed arrays, hashes, and nested arrays and other structures. There are workarounds, but none are pretty, and even the most promising techniques still seem to require excessive focusing on the debugger commands themselves, drawing attention away from the code being debugged.
As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative, in the form of IDEs, which can automatically report the changing values of a large set of variables, none of which need to be typed in, owing to the drag-and-drop capabilities of most IDEs. There are many IDEs available, including freeware and open source offerings. Most if not all of them support advanced editing, syntax highlighting and verification, visual breakpoints, and other much-appreciated capabilities. Even if they were to lack all of these features, and only have the advantage of easily and dynamically displaying the current values of variables, then they would be much more pleasant to use than the built-in Perl debugger. This is especially true in the case of nested structures, which can be expanded with a mouse click within most IDEs. All of this being said, it should be noted that the authors include a chapter that briefly touches upon the most well-known Perl GUI debuggers -- but at only seven pages in length, the chosen applications get only a cursory treatment, highlighting their major features.
Nonetheless, given the intended purpose of Pro Perl Debugging, and its target audience, the book cannot be faulted for its contents nor its approach to presenting the material. Anyone looking for a detailed and competent explication of the native Perl debugger, would likely not be able to find a more thorough treatment anywhere else.
Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."
You can purchase Pro Perl Debugging from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This title was published in hardcover in March 2005 by Apress, a relatively new member of the technical publishing world. The publisher has a Web page for the book that includes links to all of the source code in a Zip file, the table of contents in PDF format, and a form for submitting errata. The book comprises 269 pages, the majority of which are organized into 16 chapters: Introduction (not to be confused with the true Introduction immediately preceding it), Inspecting Variables and Getting Help, Controlling Program Execution, Debugging a Simple Command Line Program, Tracing Execution, Debugging Modules, Debugging Object-Oriented Perl, Using the Debugger As a Shell, Debugging a CGI Program, Perl Threads and Forked Processes, Debugging Regular Expressions, Debugger Customization, Optimization and Performance Hints and Tips, Command Line and GUI Debuggers, Comprehensive Command Reference, Book References and URLs.
For programmers who wish to learn how to fully utilize Perl's debugger, what options are open to them? A terse summary of the debugger's commands are always close by, within the debugger itself. Those Perl coders who have yet to try the built-in Perl debugger, really owe it to themselves to give it a whirl. In most cases, it is superior to embedding lots of "print" statements in your scripts, and then wading through the results. Simply include perl.exe's -d flag on the system command line, and you should be put right into the debugger, and see the debugger's "DB<1>" command prompt -- the "1" meaning that it is ready for your first command. To display the aforementioned command summary, simply enter "h", or "|h" to see the output one screen-ful at a time, which you will probably want to do unless your system window can show all of the dozens of lines at once. The command summary is best used as a quick reference, and naturally cannot be expected to serve as any sort of tutorial. Yet it has its use, and for that, it's fine.
Most Perl books devote at least some space to explaining the basics of firing up and using Perl's debugger. The (in)famous "camel book," Larry Wall's Programming Perl, has a chapter on the debugger. It covers breakpoints, running, stepping, tracing, displaying code, commands, debugger customization, debugger options, unattended execution, creating your own debugger, and performance profiling. Aside from that last topic, the chapter is mostly an expansion of the command summary mentioned earlier. It is sparse on examples, and does not cover any advanced topics, such as using the debugger in the context of forking, threads, and POE, as well as the debugger's special capabilities for regular expressions, CGI programs, and shelling out.
The advanced topics are where Pro Perl Debugging really shines in relation to the coverage that I have seen in any other book, partly because the authors have the space to thoroughly explore those topics in depth, and to provide much more meaty examples, with adequately illustrative sample code. Even for the more complex topics, the writing is clear, and the examples are worthwhile.
The authors clearly intend for the book to serve as both a comprehensive tutorial and a reference for the Perl debugger. In both respects, they succeed admirably. But the practical value of their accomplishment could be called into question by any programmer who has grown tired of the limitations of the Perl debugger, and has switched over to any Perl-capable standalone GUI debugger or integrated development environment (IDE). More specifically, watching a variable change value, while stepping through the lines of a Perl script using the debugger, requires that the programmer manually or programmatically echo that variable's value, by issuing a print command ("p") followed by the variable name, one way or another. This process quickly becomes tedious when multiple variables need to be watched, because each individual variable must be printed, one at a time. Admittedly, previously entered print statements can be recalled by using the up-arrow key, but only if the particular command has not been pushed out of the debugger's limited storage. This usually becomes even more frustrating when trying to print the values of indexed arrays, hashes, and nested arrays and other structures. There are workarounds, but none are pretty, and even the most promising techniques still seem to require excessive focusing on the debugger commands themselves, drawing attention away from the code being debugged.
As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative, in the form of IDEs, which can automatically report the changing values of a large set of variables, none of which need to be typed in, owing to the drag-and-drop capabilities of most IDEs. There are many IDEs available, including freeware and open source offerings. Most if not all of them support advanced editing, syntax highlighting and verification, visual breakpoints, and other much-appreciated capabilities. Even if they were to lack all of these features, and only have the advantage of easily and dynamically displaying the current values of variables, then they would be much more pleasant to use than the built-in Perl debugger. This is especially true in the case of nested structures, which can be expanded with a mouse click within most IDEs. All of this being said, it should be noted that the authors include a chapter that briefly touches upon the most well-known Perl GUI debuggers -- but at only seven pages in length, the chosen applications get only a cursory treatment, highlighting their major features.
Nonetheless, given the intended purpose of Pro Perl Debugging, and its target audience, the book cannot be faulted for its contents nor its approach to presenting the material. Anyone looking for a detailed and competent explication of the native Perl debugger, would likely not be able to find a more thorough treatment anywhere else.
Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."
You can purchase Pro Perl Debugging from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
...there's something about an interpreted language which can be optimized down to nearly the size of machine code, only less readable.
"Made up/misattributed quote that makes me look smart. I am on
extant, surely?
James P. Barrett
Properly placed and well-thought out, I can leave:
print "a bunch o' stuff\n" if $Debugging;
in my code forever and never have to go through the trouble of firing up an IDE.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Perl is a very bloated scripted language, now ruby is compact, and python somewhat compact, but Perl is surely the RPG-II of the scripting language world. And yes, I've been using Perl for over 9 years, and written tcp daemons and web portals in Perl. I love/hate it.
I suppose this might be handy a bit the same way knowing something like ed or vi is handy for anybody using UNIX (or similar) systems -- even the absolute strangest distribution (or installation) will almost inevitably include at least that much and it's pretty consistent. OTOH, debugging Perl on a machine that hasn't really been equipped for it doesn't sound to me like a lot better idea than using ed to write most of my code...
The universe is a figment of its own imagination.
Also, lets see if we can debug the website and make that next button work......Not functioning in FF1.5/Win
-B
The only thing harder to spot in Perl is the good code. My rule of thumb is: If I can understand it easy in Perl, it's probably a bug.
Debugging perl? Doesn't that defeat the whole point?
May the Maths Be with you!
this symbol must be scalar.
Unless the moon is gibbous.
illegitimii non ingravare
I once tried to debug a perl script, but the problem was obvious. The 'programmer' who originally wrote the script had just made a symlink to /dev/urandom.
#! /usr/local/bin/perl
#
# Two things that make debugging perl easy:
#
use strict;
use Data::Dumper;
The first one will solve most peoples perl problems, and the second one is helpfull sometimes when dealing with complex datastructures.
#!/usr/bin/perl $_='A=15; B=30; select(stdin); $|=1; select(stdout);$|=1; system "stty -echo -icanon eol \001"; for C(split(/\s/,"010.010.010.010 77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.". "000")){D=0;for E(split(/\./,C)){F=0;for G(split("",E)){C[P][F++ ][D]=G} D++}J[P]=F; I[P++] =D}%L=split(/ /,"m _".chr(72)." c 2".
chr(74)." a _m");sub a{for K(split(/ /,shift)){(K,L)=split(/=/,K
);K=L{K};K=~s/_/L/; printf "%c[K",27}}sub u{a("a=40");for D(0..B
-1){for F(0..A-1){M=G[F][D];if(R[F][D]!=M) {R[F][D]=M;a("m"."=".
(5+D).";".(F*2+5)); a("a=".(40+M).";" .(30+M));print " "x2}}}a(
"m=0;0 a=37;40")}sub r{(N)=@_;while(N--) {Q=W;W=O=H;H=Q;for F( 0 ..Q-1){for D(0..O-1) {Q[F][D]=K[F][D]}}for F(0..O-1){for D(0..Q-
1){K[F][D]= Q[Q-D-1][F]}}}}sub l{for F(0..W-1){for D(0..H-1){(K[
F][D]&& ((G[X+F][Y+D])|| (X+F=A)|| (Y+D>=B)))&& return
0}}1}sub p{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[X+F][Y+D]
=K[F][D]) }}1}sub o{for F(0..W-1){for D(0..H-1){(K[F][D]>0)&&(G[
X+F][ Y+D]=0)}}}sub n{C=int(rand(P)) ;W=J[C];H=I[C];X=int(A/2)-1 ;Y=0;for F(0..W-1){for D(0..H-1){K[F][D]= C[C][F][D]}}r(int(rand
(4)));l&&p}sub c{d:for(D=B;D>=0;D--){for F(0..A-1){G[F][D]||next
d}for(D2=D;D2>=0; D2--){for F(0..A-1){G[F][D2]= (D2>1)?G[F][D2-1
]:0; }}u;}}a ("m=0;0 a=0;37;40 c");print "\n\n".4x" "." "x(A-4).
"perltris\n".(" "x4)."--"xA."\n".((" "x3)."|"." "x(A*2)."|\n")xB .(" "x4). "--"xA."\n";n;for(;;) {u;R=chr(1); (S,T)=select(R,U,V,
0.01);if(S) {Z=getc;}else {if($e++>20){Z=" ";$e=0;}else{next;} }
if(Z eq "k"){o;r(1);l||r(3);p}; if(Z eq "j"){o;X--;l||X++;p}; if
(Z eq "l"){o;X++;l||X--;p};if(Z eq " "){o;Y++;(E=l)||Y--;p;E|| c
|c|c|c|c|n||goto g;};if(Z eq "q"){last;}}g: a("a=0 m=".(B+8).";0
" ); system "stty sane"; '; s/([A-Z])/\$$1/g; s/\%\$/\%/g; eval;
I'm not fat, just big boned...
I figure this parent post will be flagged as Flamebait, but I agree. Perl != Relevant anymore.
Nah, you're just going to be marked as someone who doesn't know what's going on. Perl is very relevant, used in a lot of high profile areas. I don't know what you think 'replaced' perl, but I know that a lot of languages have 'joined' it in many tasks. Web development, system administration, you name it.
- oZ
// i am here.
we don't care if you think perl produces gibberish intelligent people effectively use perl every day, we seem to cope just like the lisp folks, C junkies, etc i no longer care if you can read it, i will continue to write one line of perl where you write twenty lines of java.
In other words, the reviewer is a horrible programmer. Maybe he should stick to reviewing books about writing web sites, or whatever his consulting service does. His review is full of buzz words that he probably picked up through Google. Nowhere does he show any insight into testing/debugging a modern program. The book may or may not be any good, but we'll never know based on this review.
Actually, after ~25 years of writing code, I've found that 'print' statements are the best alternative. I've used every kind of debugger and IDE in the past, but in the last couple of years I've found that I rarely use them.
When you're in a debugger, you're down in the trees and it's hard to see the forest. With skillfully placed print statements that pick out the relevant data, stack traces for exceptions and a decent language, you can get a commanding overview of what's going on in your app. With a good editor, you can manipulate print statements just about as fast as breakpoints in an IDE, too. Just map a function key in your editor to "save file; make go".
Thanks, I'd like to remind everybody that the 3 older books are still very worthwhile:
Effective Perl, Hall and Schwartz
Debugging Perl, Martin Brown
Perl Debugged, Scott / Wright
I've found that debugging loops can be tedious in most of the 'normal' ways of going about it. I finally got sick of lots of 'print' output and discovered that using 'warn' statements and trapping the '__WARN__' signal (using a BEGIN) provided an especially effective method of debugging loops: store the warning text as the key of a hash where the value is incremented each time. Inside an END block, write the contents of the hash to your favorite stream.
This method will debug loops of all kinds, and if each 'warn' is labeled well, it's very easy to see what happened.
(Note: the above may or may not depend on the use of '#!/usr/bin/perl -w' (warnings) as your interpreter.)
Let S_n = {nst+us+vt : s,t in Z \ {0}, u,v in {-1,1}}. For all n in Z where |n| > 2, Z \ S_n is infinite... right?
> More specifically, watching a variable change value, while stepping
... ...
> through the lines of a Perl script using the debugger, requires that
> the programmer manually or programmatically echo that variable's value,
> by issuing a print command ("p") followed by the variable name, one
> way or another.
$ perl -d -e 1
DB h
h [db_cmd] Get help on command w expr Add a watch expression
h h Complete help page W expr|* Delete a/all watch exprs
Admittedly, the watch expressions don't detect changes in deep data structures. But it works just find on dependant expressions. I'll regularrly set watches on a loop index and a data structure being indexed by said loop var. The watch expressions will display both results.
In addition, the 'x' command works much better than 'p'. 'x' dumps the data structure, so it will display arbitrarily complex and deep data.
Tell me, what major sites have been build using Ruby?
I can list several very high volume sites/applications that use Perl.
I love the debugger -- my background is BASIC, assembler, C and finally Perl, so it fits right in with all those "programmning down to the bare metal" tools.
However, a way cooler method is to use logging. The one I use these days is Log::Log4perl, a terrific logger that you can turn on and off at will. Thus, if you have a bit of disk space, you can turn the knob up to 11 (DEBUG) and let the application go until you get to the Weird Bug. Then it's just a matter of pawing through the log files to find all of your excellent messages. Print statements sprinkled through the code? Please.
And the bit about having to print the variable value every step in the debugger is a bit of a red herring .. you can set up commands that get executed before and after each step. Yes, it's a geeky thing to do .. that's why they call it Engineering.
Whenever I use the perl debugger, I find that I have to hit enter (after pressing n, or s) over and over, is there a way to tell it to do something x number of times, like n 5?
By the time I was done, it had turned into C code.
Personally, I'm anti perl debugging.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
Yet another instance of spamming the book reviews with his Amazon-referral-laden links.
And "if you're a pro, why do you need to debug"? Clearly he has no clue about programming, and is only in it for the $0.05 per click you give him.
You seem to have forgotten Amazon.com, which uses HTML::Mason (a Perl/mod_perl templating system) to serve every customer-facing page.
For me, the real problems come when I'm debugging a Perl program that's linked to someone else's C library. I have an app that had been stable for a long time, until I found that with recent releases of Perl/Tk it suddenly started crashing once a week or so. A stack trace shows that it's crashing inside a certain C function in Perl/Tk, but my lack of C skills have stopped me from getting to the point where I could file a useful bug report. This is what I really need a book on. AFAICT, I would have to compile Perl/Tk myself using certain options, and the options that work for most C software don't actually seem to be the right ones for Perl/Tk. Then I would have to dust off my decades-old C and C debugging skills and figure out what was wrong. Ugh!
Find free books.
I do. So do about half the *IX people I know. It won't be obsolete any time soon.
Not everything needs objects, though Perl can certainly do that. Also, there are fairly large bodies of code written in Perl, which require maintenance. What most orgs use for an IT budget these days isn't going to allow a rewrite of running code unless there's a very clear reason for it. I most cases, you'd have to prove a stunning performance win, or some thumping great decrease in maintenance costs, etc. It would probably not be easy to do.
If you'd said less relevant, I'd probably have agreed with you, though with some exceptions, like system admin. But not relevant? Nah, I can't buy that at all.
What you do with a computer does not constitute the whole of computing.
I like to use a hash and a function, so there's a finer control over which sections of code are debugged. That way once a section is working as advertised, I can easily shut off debugging output for it. Likewise, using labels like "normal", "serious", "verbose", or "wtf" can let you escalate the debugging level and drop it back as needed.
$Debugging = 1;$DBG{'regex'} = 1 * ${Debugging} * 1;
$DBG{'html'} = 1 * ${Debugging} * 2;
$DBG{'higher'} = 1 * ${Debugging} * 4;
sub debug
main:
{
my($i);
while($_=<>)
}
Barnes & Noble pays for references aka clicks just like amazon and the click links to his account.
Also work4hire refers to his website to make his google page rank go up.
http://saveie6.com/
Also, there are fairly large bodies of code written in Perl, which require maintenance.
Yep, they require lots of maintenance, because perl is crap.
I've found myself lately using the open perl IDE (http://open-perl-ide.sourceforge.net/) for debugging. I can set breakpoints in it and trace variables in a little bar on the side. It isn't perfect--I don't know how well it works in a multithreaded environment in particular, but it has saved my ass many times. Of course it can't fix the "Not a SCALAR reference" crap when dealing with various data types, but that's where Perl 6 will fix things.
No I'm not trolling.
Perl is still a great replacement for shell scripts, sed and awk. It's native regex support is ahead of it's time. You can do crazy string manipulation and statistical gathering with no effort at all. A bunch of web log parsers were written in Perl and it's easy to see why, because the language was designed for that sort of purpose. Perl is to server administration and string parsing what PHP is to CGI.
yeah, but for real job security, nothing's as good as being the only person to understand the company's major application written in perl, and even better, you don't have to try very hard to make it so!!!
-- Note to mods: this is an attempt at humour.Yawn.
What you do with a computer does not constitute the whole of computing.
Given that a big theme of the article is that graphical IDEs are better than the debugger for almost all purposes, it would be nice to have a list of some of these perl-capable IDEs so that we can assess the claim.
If you want to hear an interview with Richard about the book, you can download the audio from http://perlcast.com/2005/11/23/interview-with-rich ard-foley/.
It's only 17 million lines of documented unit tested code (ignoring the 1 million lines of crap), it should only take what... 4-5 years?
And don't forget all those high-volume sites using Visual Studio.
Luke's First Law of the Computer Industry: Quality is inversely proportional to Popularity.
#!/usr/bin/perl
/, 'm _H c 2J a _m', 0); /, shift @_, 0)) { .. $B - 1) { .. $A - 1) { .. $Q - 1) { .. $O - 1) { .. $O - 1) { .. $Q - 1) {
$A = 15;
$B = 30;
select stdin;
$| = 1;
select stdout;
$| = 1;
system "stty -echo -icanon eol \cA";
foreach $C (split(/\s/, '010.010.010.010 77.77 022.020.020 330.030.030 440.044.000 055.550.000 666.060.000', 0)) {
$D = 0;
foreach $E (split(/\./, $C, 0)) {
$F = 0;
foreach $G (split(//, $E, 0)) {
$C[$P][$F++][$D] = $G;
}
++$D;
}
$J[$P] = $F;
$I[$P++] = $D;
}
(%L) = split(/
sub a {
foreach $K (split(/
($K, $L) = split(/=/, $K, 3);
$K = $L{$K};
$K =~ s/_/$L/;
printf "%c[$K", 27;
}
}
sub u {
a 'a=40';
foreach $D (0
foreach $F (0
$M = $G[$F][$D];
if ($R[$F][$D] != $M) {
$R[$F][$D] = $M;
a 'm=' . (5 + $D) . ';' . ($F * 2 + 5);
a 'a=' . (40 + $M) . ';' . (30 + $M);
print ' ' x 2;
}
}
}
a 'm=0;0 a=37;40';
}
sub r {
($N) = @_;
while ($N--) {
$Q = $W;
$W = $O = $H;
$H = $Q;
foreach $F (0
foreach $D (0
$Q[$F][$D] = $K[$F][$D];
}
}
foreach $F (0
foreach $D (0
$K[$F][$D] = $Q[$Q - $D - 1][$F];
}
}
}
}
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
sub l ; ; ; ; ; ;
sub p
sub o
sub n
sub c
a 'm=0;0 a=0;37;40 c';
print "\n\n" . 4 x ' ' . ' ' x ($A - 4) . "perltris\n" . ' ' x 4 . '--' x $A . "\n" . (' ' x 3 . '|' . ' ' x ($A * 2) . "|\n") x $B . ' ' x 4 . '--' x $A . "\n";
n
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
while (1) { ; ; ; ; ; ; ; ; ; ; ; ;
u
$R = chr 1;
($S, $T) = select($R, $U, $V, 0.01);
if ($S) {
$Z = getc;
}
else {
if ($e++ > 20) {
$Z = ' ';
$e = 0;
}
else {
next;
}
}
if ($Z eq 'k') {
o
r 1;
r 3 unless l
p
}
if ($Z eq 'j') {
o
$X--;
$X++ unless l
p
}
if ($Z eq 'l') {
o
$X++;
$X-- unless l
p
}
if ($Z eq ' ') {
o
$Y++;
$Y-- unless $E = l();
p
goto g unless $E or c() | c() | c() | c() | c() | n();
}
if ($Z eq 'q') {
last;
}
}
g: a 'a=0 m=' . ($B + 8) . ';0 ';
system 'stty sane';
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Here's another one:@args, @data, %hash, $tmp, and, as an extra bonus, $tmp2! All in an ultra-meaningfully-named function called "Tmploop". I'm glad that the comment "for every variable if defined" was included, as the ultra-obscure meaning of the for loop was severerly clouding my understadning of what $tmp2=0;@{$args[0]}>$tmp2;++$tmp2 was trying to convey.
I've described debugging this former associate's code as "the herpes of this job".
I don't make the rules. I just make fun of them.
Runs on X11, works for CGI scripts as well as locally-executed scripts, and is very, very nice.
just install Devel::ptkdb from CPAN, or here, on the CPAN site.
It uses Tk and is very much usable over an 11Mbps wifi link, is fast, understands perl objects, hashrefs, etc.
Best of all, it doesn't impose a monolithic IDE on your development process.
Yes, but that is nonsense in this context. Perl isn't aggressively marketed by the world's largest software corporation, piloted by the richest man on earth. Thus a decision to use Perl is much more likely based on experienced merit versus perceived merit.
I hope it's not written in perl
Perl is the most widely used language in Bioinformatics and hence in life sciences.
flamebait I know, but have any of you seen the amount of crud that Java projects accumulate these days, unless you know the syntax for the XML files and inheritance hierarchy for all the different MVC/ORM/IOC etc frameworks that get used you are in for a whole load of headaches. If you *dont* use them then you are in for a headache from having to write reams of tiresome code that would just a few short lines in a language such as perl.
Bush and Blair ate my sig!
i used to use komodo or ptkdb or print "something" for perl debugging but recently i have been using epic, the perl IDE for eclipse.
:wq
it has a graphical debugger and a heap of other useful features for developing in perl (see the sf.net page for more details...). another advantage: if you need to develop in other languages, there is likely a plugin for them as well, so that you can do everything without leaving your ide (yes: i know about emacs. no: i never did take the time to learn it...)
--
"i would rather maintain someone else's language than someone else's perl..."
It is amazing what people come up with when presented with a problem.
Our common problem is Perl. It is a fantastic language, but when things go south it *is* one of the more difficult languages to debug.
My solution (since most of my code runs unattended most of the time) is a nice little "logging" routine. I specify the "logging" level (debug, warnings, errors etc) and only those message get written to the output log.
This way i can find out where things go wrong. (both code and things that go wrong whilst later on when the code is in production)
Also liberal use of die() statements in development come in handy!
A Tale of 2 idle hands
Perl is a write-once language - it is often far easier to rewrite Perl code that doesn't work than to try to understand the cryptic crap most Perl programmers write.
Personally, I think the author of Perl sat down and thought, "You know, programmers just don't use the shift key enough...". I wore the lettering off of the shift keys in just one three-month Perl project. No joke.
TFA's setting PHPSESSID to 2bae32d66becd696d755dd30b38b2f96! ;-)
There's a bug that makes it look like the 1337 Perl site is masquerading as PHP code.
Obviously that's a bug that needs to be squished.
+5, Funny
They must be trying to protect their servers from t3h 1337 h4X0rz from Slashdot.
(Or fool everything into thinking that they've got a secure edition of PHP, such as PHP 6, which doesn't exist yet.)
+5, Insightful
With code this good, no wonder I spend so much^H^H^H^Hlittle time debugging in PHP^H^H^H^HPerl.
-1, Flamebait
Disclaimer: I'm not karma whore.
+1, Extra 'Insightful' modifier
Karma Total: 10.
Oh, come on! I started my post with this comment: "The worst thing about Perl is its coders. I willfully self-impugn with that statement."
Of course it's not Perl's fault! It's *always* the coder's fault!
I don't make the rules. I just make fun of them.
On the other hand, you might want to Forget the debugger.
The new version of http://www.penny-arcade.com/ was built using Ruby (on Rails).
Once we had to ship some code to a company that took over our developed applications. Little was specified as to how we should deliver the code to them, only that it had to work on their side.
We started thinking about replacing variable names with randomly created other names, etc etc. The usual.
The one I liked best was to collect all the comments from the code, shuffle them randomly and stick them back in. And you can create a random-comment generator, which makes life for the Other Developers so wonderful.
Of course you can do the same with all variable names. The only problem there is that when someone uses the great Perl eval-function (TM) on some strings, it is unsure that the strings contain the correct code. And with modules you need to take care that you 'fix' the right routine names everywhere, in all modules.
But the best way to create Horrible Code (TM) is of course to start out without specs because your project manager says YouHaveToFinishItSoonBecauseHeHasPromisedIt, find out every other day that the specs have changed without your knowledge or consent, having to publish the unfinished code to a production environment and work on it for two more months because the basic specs of the system turn out to be invalid while some of the customers are already working with the system. No, I am not kidding.
Guess why I have chosen a new job now...
PERL has got to be one of the most stupid computer languages ever devised. It needs a debugger to step through what is being done but that help comes at a cost of learning the debugger - a PERL derivative. What intelligence cries out for is a language that is written in readable code that is far from the madding crowd of open source meddlers. Reading books about PERL basics tells you that it was invented by happenstance without the slightest guidelines. It uses octal numbering for Pete's sake. Going further with debiugging guides makes understanding exponentially more difficult. A loser follows a loser. Jim
http://jobs.perl.org