Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

arhuman (1672)

arhuman
  (email not shown publicly)
http://www.stixo.com/

Journal of arhuman (1672)

Friday February 22, 2002
06:11 AM

Just another day...

[ #3031 ]
And one another day where I'm kept out out of the monastery (www.perlmonks.org)

I suppose, it's a sign I should write more here ;-)

So for the news :
  • I managed to screw my debian laptop
    (I REALLY broke the pcmcia part and thus the networking part...)
  • I go on participating to the 'CPAN testing crusade'
    (I really like this picture :-)
    I have several ongoing projects about it...
    Probably more on this soon (I hope)
  • I'm working on a module with a quite unusual interface (using filter) to assist debugging

I know I should ask to the CPAN mailing list, but maybe some of you have an Idea :
What name should I use for a module helping in the Debug Process,
the uncommon aspect is that all the provided functions are called through comments !

For example :
my $a; #!watch($a)!

will trigger a monitoring on $a telling me each time $a is accessed
Most of you have already recognized the monitor's idea
described in 'Advanced programming in Perl' from Sriram Srinivasan.
I also have an assert() function (I know there is a Carp::Assert) called the same way through comments.
A wait(<var>,<cond>) which will wait that <var> match the <cond> to carp/croak a message.
and of course a print() function.

As nothing is new you may wonder why I code already existing things.
Well, I thought that the non-intrusive module idea could be interesting :
As the functions are called through comments,
all you have to do to trigger on/off the debugging is to comment the 'use <yet-undefined-module-name>;' line...
There will be no remaining debugging code, not even a $DEBUG var...
Furthermore the filter approach helps me (I hope) to hide some unnecessary technical difficulties
(about the watch() feature for example...)

But may be I'm just plain wrong about the whole thing, so any advice (about what to add, the name...
and/or any opinion (about its usefulness, its interface) will be really welcome...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Attributes would be a much more elegant (and simple for you) solution here:

      my $a : watch;
    • I'm mostly playing with the "non-intrusive" Idea,
      I mean look at the following code :

      #use MyDebug; my $a;#!watch($a)! for my $i (1..10) { $a*=$i; } print $a;
      This is perfectly valid code.
      Now If I uncomment the 'use Mydebug;' line it will alsos works,
      And I'll get a message each time $a is accessed.

      If I understand well the Attribute::Handlers module, there's no easy way to turn on/off the features.
      (There will be the 'use AttribDecl;' line and the code will be crippled with ': watch;')
      In the e
      • I think its just that your way looks like an icky hack, though I do see the value in being able to just not use your module and have the code still work.

        But appearances count ;)

        Plus with attributes typos will be caught (like "wathc") whereas if its in a comment there's no validation. So it has the additional nicety of being a bit more formal.
        • But appearances count ;)

          Point taken...
          You're totally right on this.
          It's quite hard to find the balance between a simple clean syntax and a syntax which could be clearly distinguished from "normal" comments.
          I clearly emphazized the later...
          Any suggestion is welcome, I wonder if 'watch($a)' anywhere in a comment wouldn't be enough...

          BTW: What would be your proposition for this module's name ?
  • There will be no remaining debugging code, not even a $DEBUG var...

    Well, you know that use constant doesn't change the behaviour or performance of your program...

    use constant DEBUG => 1;
    if( DEBUG ) {
    # debug code is optimised away
    # when you set DEBUG to 0
    # you can easily check this with B::Deparse
    }

    Naturally, this adds to the code, but I'd say it's more natural than comments. Or you could use pod: Michael Schwern is working on =for testing, you could as well add =for debug...

    Side com